简介这是一份讲解SAP LSMW录屏批量上载操作的手册面向需要完成数据迁移的SAP实施顾问、内部顾问与运维人员。资源采用Batch Input Recording这一常用录屏方式围绕LSMW工具的操作主线展开覆盖Project/Subproject创建、批输入录制、源字段与结构映射、固定值设置、字段规则指定、模板文件制作、数据读取与转换以及通过SM35运行批处理会话并查看执行结果基本对应迁移上线的完整操作链路。包体为1个docx文档约4.97MB结构紧凑适合在实际项目中按步骤对照使用。已有774人学习/下载。相比泛泛的操作说明这份手册按操作顺序拆解关键节点并补充重复录制处理漏录、Char/N字段类型替换、常量规则设置、对应关系修正等实战细节可帮助初学者有效降低录屏批导入门门槛同时为有经验者提供快速查阅的流程参考。1. LSMW 录屏批量上载不写 ABAP却是最容易被低估的批导路径「LSMW 录屏批量上载」这个组合里真正干活的其实是后半句——Batch Input Recording录屏。原理很直白你手工在 SAP 屏幕上做一笔业务操作系统把你的每次输入、回车、保存记录成一段脚本LSMW 再把这段脚本套到一份几千行的 Excel 数据上一行一行替你重放。在 SAP 官方主推 BAPI、IDoc 的今天录屏方式常被贴上「过时」的标签但一线项目里它反而是被用得最多的 LSMW 批导手段不写 ABAP 就能交付业务顾问自己就能完成数据导入审计还能顺着录屏 ID 追溯到每一行数据的操作轨迹。它适合几千到几万条的主数据、单据导入场景不适合动辄几十万条的超大数据量也不适合需要复杂业务校验的场景。这篇笔记把这条路从录屏到执行完整拆开重点放在参数设置和那些一踩就翻车的格式坑上。2. 录屏Batch Input Recording的执行原理先用 SHDB 录一次LSMW 才能批量重放录屏的本质是把一次屏幕操作翻译成 BDCBatch Data Communication记录。BDC 记录的基本单位是「屏幕描述 字段技术名 字段值 OKCODE 功能码」LSMW 的重放引擎按这份记录逐屏执行。理解了这个结构后面所有排错都会有抓手录屏对你来说就不再是一个黑匣子。为什么强调先用 SHDB 录而不是直接在 LSMW 里点录屏因为 SHDB 是独立的录屏维护工具录完可以立刻 Test 重放一遍验证还能在多个 LSMW 对象之间复用同一个录屏 ID。LSMW 自带的录屏入口本质上也是调用 SHDB但少了中间验证这一步出了问题要返工的成本更高。我一般建议团队统一走「SHDB 录屏 → 验证 → LSMW 引用」这条路径尤其在多人协作时录屏 ID 可以像公共组件一样共享。2.1 录屏前必做的三件准备工作第一在开发或测试环境用一个权限完整的账号录屏。SAP 的权限不足会在屏幕上弹出授权警告这个弹窗会占据一个屏幕位置录进 BDC 记录里批量重放时如果用户权限不同屏幕序列就会错位直接中断。所以在录屏前先确认目标事务码比如物料主数据 MM01、采购信息记录 ME11、财务凭证 FB50在你当前账号下能完整走完。第二保证屏幕环境干净。初次登录改密码、密码过期提醒、系统消息弹窗这些都会打断录制。更隐蔽的是某些事务在特定工厂或公司代码下有自定义校验会在保存前多弹一个确认框。录屏时如果没碰到批量执行时遇到对应数据就会卡住。通常做法是先用一条标准数据手工完整跑一遍确认没有额外弹窗再开始录。第三想清楚录哪些字段。录屏是「所见即所得」——你在屏幕上输过的每个字段都会被记录没碰过的字段不会被包含在 BDC 记录里。这意味着你得有意识地把该业务对象的关键字段、必填字段都点一遍并输入值而不是只填最基础的几个。漏了字段后续映射阶段就找不到这个屏幕字段只能重录。2.2 SHDB 录屏步骤与 LSMW 对象引用SHDB 录屏的完整操作路径如下事务代码 SHDB 进入录屏管理界面点屏幕左上角的「New recordings」按钮。系统会弹出对话框要求输入录屏名称和目标事务代码。录屏名称建议用 Z 开头比如 ZMM01_001后面追加日期或版本号ZMM01_202502_001因为录屏 ID 在系统里是全局的起名太随意很容易跟别人的冲突尤其是多人协作换环境时目标系统里可能已经存在同名录屏。输入完录屏名和事务码后点「Start recording」开始录制系统会跳转到目标事务的初始屏幕。从这一刻起你每一次回车、填值、点按钮都在被记录。把业务操作完整走完直到保存成功——注意保存动作本身也要录进去很多新手录到数据填完就退出了结果 BDC 记录里没有保存功能码批量执行时全是只填不存的废会话。保存成功后录屏结束返回 SHDB 列表。此时可以双击刚才的录屏名选择 Display显示查看 BDC 记录内容或者选择 Test 模式直接重放一次。Test 重放非常关键——它在当前系统里把录屏再执行一遍如果这一步就报错说明录屏本身有问题不要带着问题进 LSMW。验证通过后进入 LSMW 事务代码创建 Project项目、Subproject子项目、Object对象对象类型选 Batch Input Recording在对象属性里填上录屏 ID 和事务码这个 LSMW 对象就和录屏绑定上了。下面是一段典型的 BDC 记录内容理解它比记住界面按钮更有用BDC: Transaction code: MM01 Screen: SAPLMGMM 0060 BDC_OKCODE: /00 RMMG1-MBRSH: M RMMG1-MTART: ROH RMMG1-MATNR: ZTEST-001 Screen: SAPLMGMM 0070 BDC_OKCODE: /00 MAKT-MAKTX: 测试物料 Screen: SAPLMGMM 0070 BDC_OKCODE: /11每个 Screen 块代表一次屏幕交互BDC_OKCODE 是这次交互触发的事件/00 表示回车继续/11 表示保存/12 表示返回或取消。字段名是屏幕字段的技术名称比如 RMMG1-MATNR 是物料号输入框。排错时如果发现 OKCODE 停在某个位置不动就能直接定位是哪一步断在了哪个屏幕上。字段技术名在 F1 帮助里可以看到SHDB 的 Display 界面也会原样展示。2.3 录屏重放的条件与时序敏感点录屏重放依赖两个条件一是目标屏幕在当前系统里仍然存在且字段名未变二是屏幕出现的顺序必须完全一致。SAP 版本升级、增强实施都可能导致屏幕顺序变化最典型的是在原有屏幕上插入了一个新的子屏幕录屏重放时系统期待下一屏是 A实际出现的却是 Bsession 直接报「屏幕不存在」之类的错误。实际项目里常见两种录屏思路。一种是把整个事务的完整流程录下来字段全部填满好处是适用性强坏处是录屏长、重放慢、容易被弹窗打断。另一种是只录最短路径——只填必填字段和关键字段屏幕能跳过就跳过好处是快且稳坏处是后续想补录字段必须重新录屏。两种做法我都试过目前更偏向短路径。LSMW 的固定值功能可以补很多录屏里没录的字段无需重录。具体怎么补下一章展开。3. 字段映射与转换规则把 Excel 列变成屏幕字段录屏解决的是「屏幕怎么走」映射解决的是「数据怎么填」。LSMW 在这个阶段的界面分为左侧步骤树和右侧操作区需要依次完成维护源字段Source Fields、维护结构关系Structure Relations、维护字段映射与转换规则Field Mapping and Conversion Rules、维护固定值与转换规则Fixed Values, Translations, User-Defined Rules。这些步骤大多数人只用到其中两三个但理解它们之间的关系能省很多返工。所谓源字段是你给数据文件里的每一列起的代号它不是 SAP 屏幕字段只是 Excel 列和 BDC 记录之间的中间层。源字段的顺序必须与数据文件列的顺序严格一致这是整个 LSMW 配置里最容易出错的地方。3.1 源字段定义文件列和录屏字段的对应关系进入「Maintain Source Fields」界面上会列出当前对象的所有源字段。默认可能什么都没有需要手动添加。字段名建议用和业务含义一致的名字比如材料号字段叫 MATERIAL工厂叫 PLANT数量叫 QTY。不建议直接用 MARD-WERKS 这类技术名做源字段因为源字段会出现在日志和排错界面里业务化的名字一眼能看懂。字段顺序必须与文件列顺序一致。常见的翻车场景Excel 里列顺序是物料号、工厂、物料类型、行业领域但源字段定义成了物料号、物料类型、工厂、行业领域。LSMW 读文件时按位置取数不会智能匹配列头于是物料类型列读进了工厂字段执行时工厂全部非法。排错时从第一个字段开始向右核对往往能发现错位从中间某一列开始通常是新增列时插在了中间位置。源字段的数据类型也值得关注。LSMW 的源字段默认跟着录屏字段类型走但如果你手动维护源字段类型可以选 CHAR、NUM、DATS 等。一般来说让 LSMW 自动带出即可不需要手工指定只有在跑固定长度文件时才需要精确控制长度。3.2 转换规则选型固定值、XKOMB、NUM、DATUM 怎么配源字段定义完成后进入「Maintain Field Mapping and Conversion Rules」。这个界面左侧列出源字段右侧列出录屏里的屏幕字段需要逐个建立映射。映射后文件里的值会直接赋给对应屏幕字段。但真实项目里经常需要做二次处理这时就要用到转换规则。常用的有四种。第一种是 KONST固定值把某个屏幕字段固定为常数比如行业领域字段直接固定为 M营销行业不管文件里有没有值都以此为准。第二种是 XKOMB组合把多个源字段拼成一个屏幕字段值比如把物料类型和工厂拼接成评估类或用物料号加下划线加版本号生成内部编号。第三种是 NUM处理数字格式问题比如德国格式的 1.234,56 转成 SAP 可识别的 1234.56。第四种是 DATUM把各种日期写法转成 SAP 内部格式 YYYYMMDD。下面这张表是我常用的选型参考抄作业时直接对照就可以转换类型作用典型场景注意事项直接映射文件值原样填入屏幕字段物料号、文本描述、数量格式必须已在文件层处理干净KONST固定为常数行业领域、物料类型、公司代码优先级高于文件值注意别覆盖XKOMB多个源字段拼接组合编号、评估类派生拼接顺序决定输出分隔符用下划线或斜杠NUM数字格式转换带千分位或德语小数点的金额源字段类型选 NUM转换规则选 NUMDATUM日期格式转换把 2024-02-15 转成 20240215源文件里日期不要带时分秒XKOMB 有一个容易忽略的参数拼接时的填充字符和长度。比如把物料类型4 位和工厂4 位拼接如果中间不加分隔符生成的串是 ROH1000可读性差加了下划线变成 ROH_1000后续排错肉眼可见地省力。在转换规则界面XKOMB 的配置行里可以指定连接符留空就是直接拼接。NUM 转换有个适用范围的问题它处理的是字符串里的数字格式如果文件里已经出现字母或特殊字符转换会报错。所以 NUM 规则只适用于确认内容是纯数字的字段像物料号这种字符型编号不要用 NUM否则前导零会被吃掉主数据匹配直接失败这个坑在第五章会细说。3.3 固定值维护与映射对检查映射关系建好后进入「Maintain Fixed Values, Translations, User-Defined Rules」。这个界面负责三件事给屏幕字段设固定值、做翻译比如代码转文本、写用户自定义规则。固定值的优先级要清楚固定值 文件值 录屏默认值。如果你在录屏时填过某个字段又在 LSMW 里设了固定值实际执行时以固定值为准。所以录屏时填过的字段如果在批量导入时想用文件值覆盖不需要改录屏直接在映射里建立对应关系即可如果想让所有行都统一用某个值则在固定值界面维护。录屏里出现过、但映射里没建关系、也没设固定值的字段会使用录屏当时的默认值。这一层覆盖关系务必核实一遍否则会出现「为什么我文件里没填这个字段生成的数据却有值」的困惑。映射完成后的检查手段有三个。第一个是在映射界面逐行扫一遍源字段和屏幕字段的对应关系确认没有错配第二个是「Display」映射概览把映射对导出成列表核对第三个是进入后续「Read Data」后用真实数据逐条对照。前面两个检查是静态的第三个才是动态验证。我习惯在映射阶段先在映射界面右侧的格式列确认每个屏幕字段的数据类型和文件里的实际值做个目测匹配。4. 文件读取与数据格式核验数据翻车的集中营映射配置做得再漂亮文件读进来时列对不上一切白搭。LSMW 的文件处理分为指定文件Specify Files、分配文件Assign Files、读取数据Read Data、显示数据Display Read Data四步。前两步很多人不重视后两步才是真正暴露问题的地方。这一章把文件读取的完整链路和那些反复出现的格式问题讲透。4.1 文件类型与读取参数变量格式优先于固定格式在「Specify Files」界面LSMW 要求选择文件类型。两个选项Variable Format变量格式和 Fixed Format固定长度。变量格式用分隔符区分列典型代表就是 CSV固定长度格式按字符位置切分列每列的起始位置和长度严格定义。变量格式维护简单文件可读性强是绝大多数场景的首选。固定长度一般用于对接旧系统的导出文件且需要精确到每一列的位置维护成本高只在对方系统只能输出这种格式时才用。选完文件类型后进入「Assign Files」这里指定文件路径。LSMW 支持两种路径文件在应用服务器上路径以 /usr/sap 开头或在前端 PC 上通过 SAP GUI 的打开对话框选择。两者的差异直接影响性能前端路径适合小文件几千行以内应用服务器路径适合较大文件因为读取过程不经过网络传输。常见做法是数据量不大时直接前端选文件操作直接数据量超过十万行时让 Basis 把文件放到应用服务器临时目录用服务器路径读。变量格式的读取参数里有几个关键设置字段顺序Field Order是否与源字段定义一致、第一个数据行是否需要跳过Skip First Data Row对应 Excel 里带标题行的场景、分隔符用的是逗号、分号还是制表符。分隔符的选择有个潜规则如果文件里某些字段内容本身含逗号比如文本描述CSV 解析会把字段拆断整行错位。这种情况下建议导出时改用分号分隔或者给文本字段加英文双引号包裹LSMW 的变量格式解析器能识别引号包裹。下面是一份典型的 CSV 数据文件样例对应前文定义的源字段MATERIAL,PLANT,MBRSH,MTART,MAKTX 000123,1000,M,ROH,工业润滑油 001024,1000,M,ROH,液压油 002087,1000,M,ROH,齿轮油注意物料号列带前导零这是 SAP 主数据管理的硬性要求。如果这个文件是用 Excel 编辑后再另存的000123 大概率已经变成 123需要提前发现。这种问题在文件读取阶段看不出来——LSMW 忠实地读入了 123执行阶段匹配不到物料号才会报错。所以文件准备阶段的核验比执行阶段更重要。4.2 CSV 文件的格式陷阱前导零、日期、分隔符与编码第一个陷阱就是前导零。Excel 默认把纯数字列当数值处理打开 CSV 文件保存时会把 000123 变成 123。解决方式有两个层面文件层面在 Excel 里把物料号列预先设置为文本格式再粘贴数据重新另存为 CSV或者干脆不用 Excel 编辑 CSV用 VS Code、Notepad 这类文本编辑器做字段增删避免任何隐式类型转换。LSMW 层面如果文件里确实丢了前导零可以尝试用字符串处理函数补零但前提是编号长度固定——比如物料号最长 18 位从右往左补到 18 位。实现方式是映射规则里选 XKOMB 拼接固定长度填充实际操作起来不如直接在文件层解决省心。第二个陷阱是日期格式。SAP 内部日期是 CCYYMMDD比如 2025 年 2 月 15 日写作 20250215。Excel 里常见的写法是 2025-02-15 或 15.02.2025这些在 LSMW 里都不能直接用。如果文件里是 YYYY-MM-DD不要指望 DATUM 转换规则能识别所有格式——DATUM 支持的核心场景是带点和斜杠的欧洲格式、美国格式最稳妥的做法是在 Excel 里把日期列设成文本用文本函数拼成 YYYYMMDD或者导出后再用文本编辑器替换。日期字段一旦解析错误批导数据会在后台表里留下一堆 00000000 或报错信息。第三个陷阱是分隔符与区域设置。欧洲用户的 Excel 逗号和高位默认是千分位分隔符另存 CSV 时生成的分隔符是分号而非逗号。如果 LSMW 里选的是逗号文件里却是分号读出来整列串到一起。判断办法是拿文本编辑器打开文件看一行内容数一下分隔符数量是否等于字段数减一。第四是编码问题中文描述在 UTF-8 编码下 SAP GUI 读取时可能乱码尤其当操作用户的操作系统区域设置是中文时UTF-8 文件读进来会出现「锟斤拷」这类经典乱码。解决办法是把 CSV 另存为 ANSI 编码注意 Excel 中文环境的 ANSI 即 GBKSAP GUI 的代码页设置为中文即可正常显示。如果公司内部既有中文又有欧洲用户这类问题尤其烦建议把编码检查列入交付前的检查清单。4.3 Read Data 之后必查的两个屏幕点「Read Data」读取文件后LSMW 只是把数据读进了内存此时要立刻进「Display Read Data」做验证。这个界面按源字段定义列出每一列的取值情况逐行翻看重点确认三件事列是否对位、关键字段是否有值、日期和数字是否已转成期望格式。第一屏出现错位意味着源字段顺序和文件列顺序不一致回到「Maintain Source Fields」调整顺序即可不需要改录屏也不需要碰映射关系。第二个必查的屏幕是「Display Field Mapping」这里展示的是映射后的效果——源字段的值经过转换规则处理后即将填入屏幕字段的最终值。比如源字段里是 2025-02-15经过 DATUM 转换后这里应该显示 20250215如果是直接映射这里应该和源字段值一致。这个界面的价值在于动态验证转换规则配置是否正确而不只是静态检查语法。我每次配完新规则都会在读取数据后翻一翻这个界面看到的不是预期格式就直接改规则重读不带到批导会话里。Read Data 阶段还有一个常见问题读取时提示字段数不匹配。现象是读取过程没有报错但 Display Read Data 里看到最后一列全部为空或者第一列包含了文件中的前两列内容。原因是源字段定义的数量和文件实际列数不一致。排查思路是用文本编辑器打开文件数一下表头里的字段数量再和源字段列表数量对比缺列或多余列一目了然。最让人头疼的是文件里有可见行的尾部逗号或多余分隔符会造成「看起来有 N1 列但实际内容是 N 列」的假象这种情况直接改文件比改 LSMW 配置更快。5. LSMW 录屏批量上载常见问题5 个高频踩坑与排查路径这一章写的是录屏批导里反复出现的五类问题每条按「现象 → 原因 → 解决」来拆。这些内容来自我做过的真实项目也吸收了不少社区里公认的经验属于交了学费才能换来的血泪笔记。5.1 录屏重放报「字段必须输入」却不知道漏了哪个现象在 LSMW 的「Create Batch Input Session」之后到 SM35 执行会话系统提示「字段 XXX 必须输入」但录屏时明明输入过这个字段。原因录屏阶段你可能是通过 F4 帮助或者默认值带出这个字段的而 SHDB 只记录你显式输入的字段F4 选择的内容如果最后落到了屏幕字段上通常会被记录但默认值不会。还有一种情况是录屏时屏幕上有残留值——上一个页面的值带到了下一个屏幕字段里SHDB 只记录改变的部分批量执行时新数据没有这个残留值字段就空了。解决回到 SHDB 里查看录屏的 BDC 记录确认该字段是否在记录中。如果没有重新录屏时务必在目标字段上显式输入一个值哪怕随便输个占位值后续 LSMW 映射里用文件值或固定值覆盖。如果录屏记录里有字段但没值字段名后面跟着空值说明录屏时该字段实际是空的同样需要重录或补录。这个问题的排查路径就是从报错字段反查 BDC 记录看它是否存在、是否有值。5.2 前导零消失物料号、客户号对不上主数据现象批导执行成功但生成的物料主数据在 MM03 里查不到或者 ME11 创建采购信息记录时提示物料号不存在。用 SE16N 查表发现物料号存的是 123 而不是 000123。原因Excel 打开 CSV 文件时把物料号列当数值处理丢掉了前导零。LSMW 读取文件时忠实读取了 123录屏里的物料号字段虽然是字符型但录入的值本身就没有前导零SAP 主数据编号规则要求 18 位字符不足部分左侧补零但 LSMW 不会自动补。解决文件层解决最直接——在 Excel 里把编号列设为文本重新录入或粘贴然后另存为 CSV。如果文件已经生成且丢失前导零可以回到 LSMW 映射规则里用自定义规则补零比如映射物料号时用 XKOMB 把常量「000000000000000000」和源字段拼接后取右侧 18 位这样 123 会变成 18 位补零后的物料号。还有更省心的方案直接把物料号改成从 SAP 系统导出时不丢零的格式比如前导加单引号在文本编辑器里批量处理。我个人的习惯是每批数据执行后必查一次目标表的 MATNR 字段确认前导零补齐。5.3 SM35 会话执行到一半停在某个屏幕日志看不懂现象SM35 里跑批导会话进度停在某一条数据上双击查看时屏幕停在事务的中间页面没有明显的错误消息数据既没保存也没报错。原因录屏时屏幕序列和当前数据触发的屏幕序列不一致。通常是因为录屏时用的是标准路径但文件里某条数据触发了额外校验比如物料类型和行业的组合非法SAP 弹出了一个录屏中不存在的提示屏幕。此时 LSMW 重放找不到匹配的屏幕就停住了。解决先看停在哪个屏幕、提示什么。如果是数据值违法业务规则修正数据文件后从 SM35 里重置该 session 或重新生成 session如果是弹窗未被录屏覆盖在 SHDB 里重录录屏故意用边界数据触发这个弹窗把「处理弹窗」的动作也录进去。用边界值重录的技巧是录屏时故意输错一次或选到非法组合让系统弹窗然后处理掉再回到正常流程这样一个录屏里就包含弹窗处理的片段后续遇到类似情况就能自动继续了。5.4 中文乱码物料描述录进去成了「锟斤拷」现象批导执行成功但物料的描述字段在 MM03 里显示为乱码或者文本字段被截断。原因CSV 文件编码与 SAP 系统的代码页不匹配。最常见的是文件为 UTF-8 编码但 SAP GUI 的代码页是中文 GBKLSMW 读取时按 GBK 解析 UTF-8 字节序列产生乱码。反过来GBK 文件在 UTF-8 代码页的系统里也会乱。解决在「Assign Files」界面查看读取文件的字符集设置LSMW 通常在读取文件时跟随当前 GUI 的代码页。如果文件是 UTF-8可以在文本编辑器里另存为 ANSI/GBK 编码再读。这个问题在混合语言环境的项目里特别常见比如国内团队配了英文系统语言或欧洲代码页处理中文文件就会出现。预防手段是统一约定文件编码为 ANSI 中文并且在 Read Data 后第一屏就检查中文字段发现乱码立刻停止后续步骤改编码重读。5.5 批导数据量过大导致会话超时或卡顿现象LSMW 创建 Batch Input Session 时提示会话条数超过限制或者在 SM35 里处理大量数据时前端卡死、后台报内存不足。原因单个会话包含的事务数据太多。SAP 对 Batch Input Session 有容量限制具体值取决于系统参数且一条录屏重放涉及的屏幕数越多内存和更新进程开销越大。几万条数据塞进一个 session前端执行时会长时间无响应后台执行也可能因为更新进程满载而排队。解决在创建 session 前把源文件按批次拆分常见做法是每 500 到 1000 条数据生成一个 session文件名带批次号。LSMW 的「Create Batch Input Session」界面虽然没有直接的「按批次」选项但你可以通过分批读取文件来实现——把 Excel 文件拆成多个 CSV分别读入 LSMW或者利用 LSMW 的「数据包」功能如果版本支持。更稳妥的方案是每批数据跑完一个 session 后去 SM35 查看结果确认无误再跑下一批。拆批是录屏批导的日常操作不要嫌麻烦一次失败要重跑的代价远大于多建几个 session。6. 进阶技巧LSMW 对象跨环境迁移与会话执行控制6.1 LSMW 导入导出操作跨环境迁移时录屏 ID 才是关键把 LSMW 对象从开发环境搬到测试或生产环境是项目上线前最常做的事。LSMW 主界面菜单里有现成的导入导出功能可以把整个对象包含源字段、映射、固定值、文件参数导出为一个本地文件到目标环境再导入。实际操作中绝大多数配置都能原样带过去唯一需要处理后的是录屏本身。LSMW 对象里存放的是录屏 ID而不是录屏内容。录屏内容存在 SHDB 里随系统传输或手工复制才能迁移。目标环境里如果不存在同名录屏LSMW 导入后执行时会直接报「录屏不存在」或找不到事务码。解决方式是在目标环境先用 SHDB 复制录屏或者干脆在目标环境重新录一遍同名录屏注意录屏名必须和 LSMW 对象里引用的一致。我的习惯是导出 LSMW 对象的同时在 SHDB 里把录屏也用传输请求带走这样目标系统只做一次导入和验证不会出现两边录屏版本不一致的问题。跨环境迁移后还有一个隐含风险录屏的目标屏幕可能因为系统版本不同而变化。开发环境录的屏测试环境还能跑生产环境升级过就未必。所以迁移后必须拿一条真实数据走一遍 Test 模式确认录屏在当前版本下有效再执行正式批导。6.2 会话执行控制与事后验证SM35 参数和目标表检查SM35 里执行 Batch Input Session有三种处理方式前台执行Process / Foreground逐屏显示整个操作过程前台显示错误Display errors only只在发生错误时弹出屏幕后台执行Process / Background不显示任何屏幕。首次批导建议选「Display errors only」——它比全前台快得多又能及时看到报错屏幕是效率和排查的平衡点。确认数据稳定后再用后台执行处理剩余批次。会话的更新模式也要区分Synchronous同步更新在每条数据提交后立即写库并返回结果适合小批量精确控制Asynchronous异步更新会有一个更新延迟适合大批量。如果系统在批导过程中因更新进程繁忙导致 DB 锁等待改用同步模式往往能更早暴露锁冲突问题。事后验证是批导的最后一环也是最容易被省略的一环。跑完 session 后我至少做三件事去 SM35 确认 session 状态为已完成且无错误记录用 SE16N 查目标表的数据行数是否等于文件行数比如物料主数据查 MARA物料描述查 MAKT财务凭证查 BKPF/BSEG随机抽三到五条数据在事务里查看关键字段是否完整。这三件事做完才算真正收工。我早年有过批导后不看数据就发交付邮件第二天用户反馈物料描述缺了一半从此养成「SM35 绿了不算完表里数对了才算完」的习惯。这套流程跑顺之后LSMW 录屏批导会更省心希望帮到你。本文还有配套的精品资源点击获取 LSMW录屏批量上载全解析：从SHDB录屏到字段映射与排错
简介这是一份讲解SAP LSMW录屏批量上载操作的手册面向需要完成数据迁移的SAP实施顾问、内部顾问与运维人员。资源采用Batch Input Recording这一常用录屏方式围绕LSMW工具的操作主线展开覆盖Project/Subproject创建、批输入录制、源字段与结构映射、固定值设置、字段规则指定、模板文件制作、数据读取与转换以及通过SM35运行批处理会话并查看执行结果基本对应迁移上线的完整操作链路。包体为1个docx文档约4.97MB结构紧凑适合在实际项目中按步骤对照使用。已有774人学习/下载。相比泛泛的操作说明这份手册按操作顺序拆解关键节点并补充重复录制处理漏录、Char/N字段类型替换、常量规则设置、对应关系修正等实战细节可帮助初学者有效降低录屏批导入门门槛同时为有经验者提供快速查阅的流程参考。1. LSMW 录屏批量上载不写 ABAP却是最容易被低估的批导路径「LSMW 录屏批量上载」这个组合里真正干活的其实是后半句——Batch Input Recording录屏。原理很直白你手工在 SAP 屏幕上做一笔业务操作系统把你的每次输入、回车、保存记录成一段脚本LSMW 再把这段脚本套到一份几千行的 Excel 数据上一行一行替你重放。在 SAP 官方主推 BAPI、IDoc 的今天录屏方式常被贴上「过时」的标签但一线项目里它反而是被用得最多的 LSMW 批导手段不写 ABAP 就能交付业务顾问自己就能完成数据导入审计还能顺着录屏 ID 追溯到每一行数据的操作轨迹。它适合几千到几万条的主数据、单据导入场景不适合动辄几十万条的超大数据量也不适合需要复杂业务校验的场景。这篇笔记把这条路从录屏到执行完整拆开重点放在参数设置和那些一踩就翻车的格式坑上。2. 录屏Batch Input Recording的执行原理先用 SHDB 录一次LSMW 才能批量重放录屏的本质是把一次屏幕操作翻译成 BDCBatch Data Communication记录。BDC 记录的基本单位是「屏幕描述 字段技术名 字段值 OKCODE 功能码」LSMW 的重放引擎按这份记录逐屏执行。理解了这个结构后面所有排错都会有抓手录屏对你来说就不再是一个黑匣子。为什么强调先用 SHDB 录而不是直接在 LSMW 里点录屏因为 SHDB 是独立的录屏维护工具录完可以立刻 Test 重放一遍验证还能在多个 LSMW 对象之间复用同一个录屏 ID。LSMW 自带的录屏入口本质上也是调用 SHDB但少了中间验证这一步出了问题要返工的成本更高。我一般建议团队统一走「SHDB 录屏 → 验证 → LSMW 引用」这条路径尤其在多人协作时录屏 ID 可以像公共组件一样共享。2.1 录屏前必做的三件准备工作第一在开发或测试环境用一个权限完整的账号录屏。SAP 的权限不足会在屏幕上弹出授权警告这个弹窗会占据一个屏幕位置录进 BDC 记录里批量重放时如果用户权限不同屏幕序列就会错位直接中断。所以在录屏前先确认目标事务码比如物料主数据 MM01、采购信息记录 ME11、财务凭证 FB50在你当前账号下能完整走完。第二保证屏幕环境干净。初次登录改密码、密码过期提醒、系统消息弹窗这些都会打断录制。更隐蔽的是某些事务在特定工厂或公司代码下有自定义校验会在保存前多弹一个确认框。录屏时如果没碰到批量执行时遇到对应数据就会卡住。通常做法是先用一条标准数据手工完整跑一遍确认没有额外弹窗再开始录。第三想清楚录哪些字段。录屏是「所见即所得」——你在屏幕上输过的每个字段都会被记录没碰过的字段不会被包含在 BDC 记录里。这意味着你得有意识地把该业务对象的关键字段、必填字段都点一遍并输入值而不是只填最基础的几个。漏了字段后续映射阶段就找不到这个屏幕字段只能重录。2.2 SHDB 录屏步骤与 LSMW 对象引用SHDB 录屏的完整操作路径如下事务代码 SHDB 进入录屏管理界面点屏幕左上角的「New recordings」按钮。系统会弹出对话框要求输入录屏名称和目标事务代码。录屏名称建议用 Z 开头比如 ZMM01_001后面追加日期或版本号ZMM01_202502_001因为录屏 ID 在系统里是全局的起名太随意很容易跟别人的冲突尤其是多人协作换环境时目标系统里可能已经存在同名录屏。输入完录屏名和事务码后点「Start recording」开始录制系统会跳转到目标事务的初始屏幕。从这一刻起你每一次回车、填值、点按钮都在被记录。把业务操作完整走完直到保存成功——注意保存动作本身也要录进去很多新手录到数据填完就退出了结果 BDC 记录里没有保存功能码批量执行时全是只填不存的废会话。保存成功后录屏结束返回 SHDB 列表。此时可以双击刚才的录屏名选择 Display显示查看 BDC 记录内容或者选择 Test 模式直接重放一次。Test 重放非常关键——它在当前系统里把录屏再执行一遍如果这一步就报错说明录屏本身有问题不要带着问题进 LSMW。验证通过后进入 LSMW 事务代码创建 Project项目、Subproject子项目、Object对象对象类型选 Batch Input Recording在对象属性里填上录屏 ID 和事务码这个 LSMW 对象就和录屏绑定上了。下面是一段典型的 BDC 记录内容理解它比记住界面按钮更有用BDC: Transaction code: MM01 Screen: SAPLMGMM 0060 BDC_OKCODE: /00 RMMG1-MBRSH: M RMMG1-MTART: ROH RMMG1-MATNR: ZTEST-001 Screen: SAPLMGMM 0070 BDC_OKCODE: /00 MAKT-MAKTX: 测试物料 Screen: SAPLMGMM 0070 BDC_OKCODE: /11每个 Screen 块代表一次屏幕交互BDC_OKCODE 是这次交互触发的事件/00 表示回车继续/11 表示保存/12 表示返回或取消。字段名是屏幕字段的技术名称比如 RMMG1-MATNR 是物料号输入框。排错时如果发现 OKCODE 停在某个位置不动就能直接定位是哪一步断在了哪个屏幕上。字段技术名在 F1 帮助里可以看到SHDB 的 Display 界面也会原样展示。2.3 录屏重放的条件与时序敏感点录屏重放依赖两个条件一是目标屏幕在当前系统里仍然存在且字段名未变二是屏幕出现的顺序必须完全一致。SAP 版本升级、增强实施都可能导致屏幕顺序变化最典型的是在原有屏幕上插入了一个新的子屏幕录屏重放时系统期待下一屏是 A实际出现的却是 Bsession 直接报「屏幕不存在」之类的错误。实际项目里常见两种录屏思路。一种是把整个事务的完整流程录下来字段全部填满好处是适用性强坏处是录屏长、重放慢、容易被弹窗打断。另一种是只录最短路径——只填必填字段和关键字段屏幕能跳过就跳过好处是快且稳坏处是后续想补录字段必须重新录屏。两种做法我都试过目前更偏向短路径。LSMW 的固定值功能可以补很多录屏里没录的字段无需重录。具体怎么补下一章展开。3. 字段映射与转换规则把 Excel 列变成屏幕字段录屏解决的是「屏幕怎么走」映射解决的是「数据怎么填」。LSMW 在这个阶段的界面分为左侧步骤树和右侧操作区需要依次完成维护源字段Source Fields、维护结构关系Structure Relations、维护字段映射与转换规则Field Mapping and Conversion Rules、维护固定值与转换规则Fixed Values, Translations, User-Defined Rules。这些步骤大多数人只用到其中两三个但理解它们之间的关系能省很多返工。所谓源字段是你给数据文件里的每一列起的代号它不是 SAP 屏幕字段只是 Excel 列和 BDC 记录之间的中间层。源字段的顺序必须与数据文件列的顺序严格一致这是整个 LSMW 配置里最容易出错的地方。3.1 源字段定义文件列和录屏字段的对应关系进入「Maintain Source Fields」界面上会列出当前对象的所有源字段。默认可能什么都没有需要手动添加。字段名建议用和业务含义一致的名字比如材料号字段叫 MATERIAL工厂叫 PLANT数量叫 QTY。不建议直接用 MARD-WERKS 这类技术名做源字段因为源字段会出现在日志和排错界面里业务化的名字一眼能看懂。字段顺序必须与文件列顺序一致。常见的翻车场景Excel 里列顺序是物料号、工厂、物料类型、行业领域但源字段定义成了物料号、物料类型、工厂、行业领域。LSMW 读文件时按位置取数不会智能匹配列头于是物料类型列读进了工厂字段执行时工厂全部非法。排错时从第一个字段开始向右核对往往能发现错位从中间某一列开始通常是新增列时插在了中间位置。源字段的数据类型也值得关注。LSMW 的源字段默认跟着录屏字段类型走但如果你手动维护源字段类型可以选 CHAR、NUM、DATS 等。一般来说让 LSMW 自动带出即可不需要手工指定只有在跑固定长度文件时才需要精确控制长度。3.2 转换规则选型固定值、XKOMB、NUM、DATUM 怎么配源字段定义完成后进入「Maintain Field Mapping and Conversion Rules」。这个界面左侧列出源字段右侧列出录屏里的屏幕字段需要逐个建立映射。映射后文件里的值会直接赋给对应屏幕字段。但真实项目里经常需要做二次处理这时就要用到转换规则。常用的有四种。第一种是 KONST固定值把某个屏幕字段固定为常数比如行业领域字段直接固定为 M营销行业不管文件里有没有值都以此为准。第二种是 XKOMB组合把多个源字段拼成一个屏幕字段值比如把物料类型和工厂拼接成评估类或用物料号加下划线加版本号生成内部编号。第三种是 NUM处理数字格式问题比如德国格式的 1.234,56 转成 SAP 可识别的 1234.56。第四种是 DATUM把各种日期写法转成 SAP 内部格式 YYYYMMDD。下面这张表是我常用的选型参考抄作业时直接对照就可以转换类型作用典型场景注意事项直接映射文件值原样填入屏幕字段物料号、文本描述、数量格式必须已在文件层处理干净KONST固定为常数行业领域、物料类型、公司代码优先级高于文件值注意别覆盖XKOMB多个源字段拼接组合编号、评估类派生拼接顺序决定输出分隔符用下划线或斜杠NUM数字格式转换带千分位或德语小数点的金额源字段类型选 NUM转换规则选 NUMDATUM日期格式转换把 2024-02-15 转成 20240215源文件里日期不要带时分秒XKOMB 有一个容易忽略的参数拼接时的填充字符和长度。比如把物料类型4 位和工厂4 位拼接如果中间不加分隔符生成的串是 ROH1000可读性差加了下划线变成 ROH_1000后续排错肉眼可见地省力。在转换规则界面XKOMB 的配置行里可以指定连接符留空就是直接拼接。NUM 转换有个适用范围的问题它处理的是字符串里的数字格式如果文件里已经出现字母或特殊字符转换会报错。所以 NUM 规则只适用于确认内容是纯数字的字段像物料号这种字符型编号不要用 NUM否则前导零会被吃掉主数据匹配直接失败这个坑在第五章会细说。3.3 固定值维护与映射对检查映射关系建好后进入「Maintain Fixed Values, Translations, User-Defined Rules」。这个界面负责三件事给屏幕字段设固定值、做翻译比如代码转文本、写用户自定义规则。固定值的优先级要清楚固定值 文件值 录屏默认值。如果你在录屏时填过某个字段又在 LSMW 里设了固定值实际执行时以固定值为准。所以录屏时填过的字段如果在批量导入时想用文件值覆盖不需要改录屏直接在映射里建立对应关系即可如果想让所有行都统一用某个值则在固定值界面维护。录屏里出现过、但映射里没建关系、也没设固定值的字段会使用录屏当时的默认值。这一层覆盖关系务必核实一遍否则会出现「为什么我文件里没填这个字段生成的数据却有值」的困惑。映射完成后的检查手段有三个。第一个是在映射界面逐行扫一遍源字段和屏幕字段的对应关系确认没有错配第二个是「Display」映射概览把映射对导出成列表核对第三个是进入后续「Read Data」后用真实数据逐条对照。前面两个检查是静态的第三个才是动态验证。我习惯在映射阶段先在映射界面右侧的格式列确认每个屏幕字段的数据类型和文件里的实际值做个目测匹配。4. 文件读取与数据格式核验数据翻车的集中营映射配置做得再漂亮文件读进来时列对不上一切白搭。LSMW 的文件处理分为指定文件Specify Files、分配文件Assign Files、读取数据Read Data、显示数据Display Read Data四步。前两步很多人不重视后两步才是真正暴露问题的地方。这一章把文件读取的完整链路和那些反复出现的格式问题讲透。4.1 文件类型与读取参数变量格式优先于固定格式在「Specify Files」界面LSMW 要求选择文件类型。两个选项Variable Format变量格式和 Fixed Format固定长度。变量格式用分隔符区分列典型代表就是 CSV固定长度格式按字符位置切分列每列的起始位置和长度严格定义。变量格式维护简单文件可读性强是绝大多数场景的首选。固定长度一般用于对接旧系统的导出文件且需要精确到每一列的位置维护成本高只在对方系统只能输出这种格式时才用。选完文件类型后进入「Assign Files」这里指定文件路径。LSMW 支持两种路径文件在应用服务器上路径以 /usr/sap 开头或在前端 PC 上通过 SAP GUI 的打开对话框选择。两者的差异直接影响性能前端路径适合小文件几千行以内应用服务器路径适合较大文件因为读取过程不经过网络传输。常见做法是数据量不大时直接前端选文件操作直接数据量超过十万行时让 Basis 把文件放到应用服务器临时目录用服务器路径读。变量格式的读取参数里有几个关键设置字段顺序Field Order是否与源字段定义一致、第一个数据行是否需要跳过Skip First Data Row对应 Excel 里带标题行的场景、分隔符用的是逗号、分号还是制表符。分隔符的选择有个潜规则如果文件里某些字段内容本身含逗号比如文本描述CSV 解析会把字段拆断整行错位。这种情况下建议导出时改用分号分隔或者给文本字段加英文双引号包裹LSMW 的变量格式解析器能识别引号包裹。下面是一份典型的 CSV 数据文件样例对应前文定义的源字段MATERIAL,PLANT,MBRSH,MTART,MAKTX 000123,1000,M,ROH,工业润滑油 001024,1000,M,ROH,液压油 002087,1000,M,ROH,齿轮油注意物料号列带前导零这是 SAP 主数据管理的硬性要求。如果这个文件是用 Excel 编辑后再另存的000123 大概率已经变成 123需要提前发现。这种问题在文件读取阶段看不出来——LSMW 忠实地读入了 123执行阶段匹配不到物料号才会报错。所以文件准备阶段的核验比执行阶段更重要。4.2 CSV 文件的格式陷阱前导零、日期、分隔符与编码第一个陷阱就是前导零。Excel 默认把纯数字列当数值处理打开 CSV 文件保存时会把 000123 变成 123。解决方式有两个层面文件层面在 Excel 里把物料号列预先设置为文本格式再粘贴数据重新另存为 CSV或者干脆不用 Excel 编辑 CSV用 VS Code、Notepad 这类文本编辑器做字段增删避免任何隐式类型转换。LSMW 层面如果文件里确实丢了前导零可以尝试用字符串处理函数补零但前提是编号长度固定——比如物料号最长 18 位从右往左补到 18 位。实现方式是映射规则里选 XKOMB 拼接固定长度填充实际操作起来不如直接在文件层解决省心。第二个陷阱是日期格式。SAP 内部日期是 CCYYMMDD比如 2025 年 2 月 15 日写作 20250215。Excel 里常见的写法是 2025-02-15 或 15.02.2025这些在 LSMW 里都不能直接用。如果文件里是 YYYY-MM-DD不要指望 DATUM 转换规则能识别所有格式——DATUM 支持的核心场景是带点和斜杠的欧洲格式、美国格式最稳妥的做法是在 Excel 里把日期列设成文本用文本函数拼成 YYYYMMDD或者导出后再用文本编辑器替换。日期字段一旦解析错误批导数据会在后台表里留下一堆 00000000 或报错信息。第三个陷阱是分隔符与区域设置。欧洲用户的 Excel 逗号和高位默认是千分位分隔符另存 CSV 时生成的分隔符是分号而非逗号。如果 LSMW 里选的是逗号文件里却是分号读出来整列串到一起。判断办法是拿文本编辑器打开文件看一行内容数一下分隔符数量是否等于字段数减一。第四是编码问题中文描述在 UTF-8 编码下 SAP GUI 读取时可能乱码尤其当操作用户的操作系统区域设置是中文时UTF-8 文件读进来会出现「锟斤拷」这类经典乱码。解决办法是把 CSV 另存为 ANSI 编码注意 Excel 中文环境的 ANSI 即 GBKSAP GUI 的代码页设置为中文即可正常显示。如果公司内部既有中文又有欧洲用户这类问题尤其烦建议把编码检查列入交付前的检查清单。4.3 Read Data 之后必查的两个屏幕点「Read Data」读取文件后LSMW 只是把数据读进了内存此时要立刻进「Display Read Data」做验证。这个界面按源字段定义列出每一列的取值情况逐行翻看重点确认三件事列是否对位、关键字段是否有值、日期和数字是否已转成期望格式。第一屏出现错位意味着源字段顺序和文件列顺序不一致回到「Maintain Source Fields」调整顺序即可不需要改录屏也不需要碰映射关系。第二个必查的屏幕是「Display Field Mapping」这里展示的是映射后的效果——源字段的值经过转换规则处理后即将填入屏幕字段的最终值。比如源字段里是 2025-02-15经过 DATUM 转换后这里应该显示 20250215如果是直接映射这里应该和源字段值一致。这个界面的价值在于动态验证转换规则配置是否正确而不只是静态检查语法。我每次配完新规则都会在读取数据后翻一翻这个界面看到的不是预期格式就直接改规则重读不带到批导会话里。Read Data 阶段还有一个常见问题读取时提示字段数不匹配。现象是读取过程没有报错但 Display Read Data 里看到最后一列全部为空或者第一列包含了文件中的前两列内容。原因是源字段定义的数量和文件实际列数不一致。排查思路是用文本编辑器打开文件数一下表头里的字段数量再和源字段列表数量对比缺列或多余列一目了然。最让人头疼的是文件里有可见行的尾部逗号或多余分隔符会造成「看起来有 N1 列但实际内容是 N 列」的假象这种情况直接改文件比改 LSMW 配置更快。5. LSMW 录屏批量上载常见问题5 个高频踩坑与排查路径这一章写的是录屏批导里反复出现的五类问题每条按「现象 → 原因 → 解决」来拆。这些内容来自我做过的真实项目也吸收了不少社区里公认的经验属于交了学费才能换来的血泪笔记。5.1 录屏重放报「字段必须输入」却不知道漏了哪个现象在 LSMW 的「Create Batch Input Session」之后到 SM35 执行会话系统提示「字段 XXX 必须输入」但录屏时明明输入过这个字段。原因录屏阶段你可能是通过 F4 帮助或者默认值带出这个字段的而 SHDB 只记录你显式输入的字段F4 选择的内容如果最后落到了屏幕字段上通常会被记录但默认值不会。还有一种情况是录屏时屏幕上有残留值——上一个页面的值带到了下一个屏幕字段里SHDB 只记录改变的部分批量执行时新数据没有这个残留值字段就空了。解决回到 SHDB 里查看录屏的 BDC 记录确认该字段是否在记录中。如果没有重新录屏时务必在目标字段上显式输入一个值哪怕随便输个占位值后续 LSMW 映射里用文件值或固定值覆盖。如果录屏记录里有字段但没值字段名后面跟着空值说明录屏时该字段实际是空的同样需要重录或补录。这个问题的排查路径就是从报错字段反查 BDC 记录看它是否存在、是否有值。5.2 前导零消失物料号、客户号对不上主数据现象批导执行成功但生成的物料主数据在 MM03 里查不到或者 ME11 创建采购信息记录时提示物料号不存在。用 SE16N 查表发现物料号存的是 123 而不是 000123。原因Excel 打开 CSV 文件时把物料号列当数值处理丢掉了前导零。LSMW 读取文件时忠实读取了 123录屏里的物料号字段虽然是字符型但录入的值本身就没有前导零SAP 主数据编号规则要求 18 位字符不足部分左侧补零但 LSMW 不会自动补。解决文件层解决最直接——在 Excel 里把编号列设为文本重新录入或粘贴然后另存为 CSV。如果文件已经生成且丢失前导零可以回到 LSMW 映射规则里用自定义规则补零比如映射物料号时用 XKOMB 把常量「000000000000000000」和源字段拼接后取右侧 18 位这样 123 会变成 18 位补零后的物料号。还有更省心的方案直接把物料号改成从 SAP 系统导出时不丢零的格式比如前导加单引号在文本编辑器里批量处理。我个人的习惯是每批数据执行后必查一次目标表的 MATNR 字段确认前导零补齐。5.3 SM35 会话执行到一半停在某个屏幕日志看不懂现象SM35 里跑批导会话进度停在某一条数据上双击查看时屏幕停在事务的中间页面没有明显的错误消息数据既没保存也没报错。原因录屏时屏幕序列和当前数据触发的屏幕序列不一致。通常是因为录屏时用的是标准路径但文件里某条数据触发了额外校验比如物料类型和行业的组合非法SAP 弹出了一个录屏中不存在的提示屏幕。此时 LSMW 重放找不到匹配的屏幕就停住了。解决先看停在哪个屏幕、提示什么。如果是数据值违法业务规则修正数据文件后从 SM35 里重置该 session 或重新生成 session如果是弹窗未被录屏覆盖在 SHDB 里重录录屏故意用边界数据触发这个弹窗把「处理弹窗」的动作也录进去。用边界值重录的技巧是录屏时故意输错一次或选到非法组合让系统弹窗然后处理掉再回到正常流程这样一个录屏里就包含弹窗处理的片段后续遇到类似情况就能自动继续了。5.4 中文乱码物料描述录进去成了「锟斤拷」现象批导执行成功但物料的描述字段在 MM03 里显示为乱码或者文本字段被截断。原因CSV 文件编码与 SAP 系统的代码页不匹配。最常见的是文件为 UTF-8 编码但 SAP GUI 的代码页是中文 GBKLSMW 读取时按 GBK 解析 UTF-8 字节序列产生乱码。反过来GBK 文件在 UTF-8 代码页的系统里也会乱。解决在「Assign Files」界面查看读取文件的字符集设置LSMW 通常在读取文件时跟随当前 GUI 的代码页。如果文件是 UTF-8可以在文本编辑器里另存为 ANSI/GBK 编码再读。这个问题在混合语言环境的项目里特别常见比如国内团队配了英文系统语言或欧洲代码页处理中文文件就会出现。预防手段是统一约定文件编码为 ANSI 中文并且在 Read Data 后第一屏就检查中文字段发现乱码立刻停止后续步骤改编码重读。5.5 批导数据量过大导致会话超时或卡顿现象LSMW 创建 Batch Input Session 时提示会话条数超过限制或者在 SM35 里处理大量数据时前端卡死、后台报内存不足。原因单个会话包含的事务数据太多。SAP 对 Batch Input Session 有容量限制具体值取决于系统参数且一条录屏重放涉及的屏幕数越多内存和更新进程开销越大。几万条数据塞进一个 session前端执行时会长时间无响应后台执行也可能因为更新进程满载而排队。解决在创建 session 前把源文件按批次拆分常见做法是每 500 到 1000 条数据生成一个 session文件名带批次号。LSMW 的「Create Batch Input Session」界面虽然没有直接的「按批次」选项但你可以通过分批读取文件来实现——把 Excel 文件拆成多个 CSV分别读入 LSMW或者利用 LSMW 的「数据包」功能如果版本支持。更稳妥的方案是每批数据跑完一个 session 后去 SM35 查看结果确认无误再跑下一批。拆批是录屏批导的日常操作不要嫌麻烦一次失败要重跑的代价远大于多建几个 session。6. 进阶技巧LSMW 对象跨环境迁移与会话执行控制6.1 LSMW 导入导出操作跨环境迁移时录屏 ID 才是关键把 LSMW 对象从开发环境搬到测试或生产环境是项目上线前最常做的事。LSMW 主界面菜单里有现成的导入导出功能可以把整个对象包含源字段、映射、固定值、文件参数导出为一个本地文件到目标环境再导入。实际操作中绝大多数配置都能原样带过去唯一需要处理后的是录屏本身。LSMW 对象里存放的是录屏 ID而不是录屏内容。录屏内容存在 SHDB 里随系统传输或手工复制才能迁移。目标环境里如果不存在同名录屏LSMW 导入后执行时会直接报「录屏不存在」或找不到事务码。解决方式是在目标环境先用 SHDB 复制录屏或者干脆在目标环境重新录一遍同名录屏注意录屏名必须和 LSMW 对象里引用的一致。我的习惯是导出 LSMW 对象的同时在 SHDB 里把录屏也用传输请求带走这样目标系统只做一次导入和验证不会出现两边录屏版本不一致的问题。跨环境迁移后还有一个隐含风险录屏的目标屏幕可能因为系统版本不同而变化。开发环境录的屏测试环境还能跑生产环境升级过就未必。所以迁移后必须拿一条真实数据走一遍 Test 模式确认录屏在当前版本下有效再执行正式批导。6.2 会话执行控制与事后验证SM35 参数和目标表检查SM35 里执行 Batch Input Session有三种处理方式前台执行Process / Foreground逐屏显示整个操作过程前台显示错误Display errors only只在发生错误时弹出屏幕后台执行Process / Background不显示任何屏幕。首次批导建议选「Display errors only」——它比全前台快得多又能及时看到报错屏幕是效率和排查的平衡点。确认数据稳定后再用后台执行处理剩余批次。会话的更新模式也要区分Synchronous同步更新在每条数据提交后立即写库并返回结果适合小批量精确控制Asynchronous异步更新会有一个更新延迟适合大批量。如果系统在批导过程中因更新进程繁忙导致 DB 锁等待改用同步模式往往能更早暴露锁冲突问题。事后验证是批导的最后一环也是最容易被省略的一环。跑完 session 后我至少做三件事去 SM35 确认 session 状态为已完成且无错误记录用 SE16N 查目标表的数据行数是否等于文件行数比如物料主数据查 MARA物料描述查 MAKT财务凭证查 BKPF/BSEG随机抽三到五条数据在事务里查看关键字段是否完整。这三件事做完才算真正收工。我早年有过批导后不看数据就发交付邮件第二天用户反馈物料描述缺了一半从此养成「SM35 绿了不算完表里数对了才算完」的习惯。这套流程跑顺之后LSMW 录屏批导会更省心希望帮到你。本文还有配套的精品资源点击获取