简介：《SAP两种批处理工具使用方法详解（BDC&LSMW）》是一份面向SAP顾问、数据迁移及运维人员的实操型文档，重点解决批处理操作与历史数据导入中的效率问题。文档以SHDB录屏为线索，完整演示从创建记录、录制MMPV开账期脚本、修改屏幕字段，到借助Office邮件合并生成20条批量执行脚本并通过后台模式运行的全过程，并对前台、后台两种处理模式及适用场景做了对比；同时系统梳理LSMW在旧系统向SAP迁移时的14个标准步骤，涵盖创建对象、定义数据文件、源/目标结构映射、转换规则设定以及预转换和正式数据传输，兼顾静态主数据、动态库存与业务数据等典型对象。资源为单个docx文档，压缩包约2.49MB，已有1749人学习浏览。读者可据此掌握两种工具的适用边界，既能快速处理轻量级、一次性的批量任务，也能应对大规模数据迁移的复杂场景，是一份步骤清晰、可直接对照练习的实战资料。

1. 一次开 21 个月物料账期：SAP 批处理工具不是玄学

做 SAP 的多少都碰过这种需求：月底结账前，运维或财务同事丢过来一句「把公司代码 0001 的物料账期从 1998 年 4 月开到 1999 年 12 月」，然后你打开事务码 MMPV，改个月份、回车、退出，再改下个月——如果只开一两个月还行，碰上二十多个月，重复劳动不说，手一抖写错月份就得返工。SAP 批处理工具就是干这个的，BDC（Batch Data Conversion，事务码 SHDB）和 LSMW（Legacy System Migration Workbench）是两条最常见的路线：BDC 轻、快，适合系统内批量重放业务操作；LSMW 重、全，适合旧系统数据往 SAP 里迁。这篇就是把两种工具逐段拆开，从录屏到批量脚本再到数据迁移，讲清楚操作步骤和最容易翻车的地方。适合正在做月结、主数据维护、上线数据准备的人，按着步骤能直接复现。

2. SHDB 录屏：把手工业务操作变成可改写的脚本

2.1 录屏前准备：事务码、提交后继续、手别乱点

BDC 的核心思路很朴素：系统把你手工操作事务码的过程录下来，存成脚本，之后脚本可以改字段值再重放。用 SHDB 之前，先明确三件事。第一，确定要录像的事务码，本例是 MMPV，用来设定物料凭证结算期间；第二，像 MMPV 这种多屏操作的事务码，创建记录对话框里的「提交后继续」选项必须勾上，否则录完第一屏系统就停了；第三，录屏期间手要管住，不要有多余的鼠标点击或键盘按键，真需要滚动屏幕时用 PageUp、PageDown 翻页，别拿鼠标拖滚动条。

进入 SHDB 后，初始界面会列出已有的记录（Recording），点「新建记录」按钮，弹出对话框，填两样东西：记录名称（自己起的名字，比如 ZMMPV）和事务代码（MMPV）。这里有个容易忽略的细节，「提交后继续」如果没勾，像 MMPV 这种回显多个屏幕的事务码会在第一屏结束后直接中断录像，脚本不完整。勾选后点「开始记录」，系统会弹出一个录屏窗口，之后你的每一步操作都会被记下来。

录屏操作本身不复杂：在 MMPV 初始界面填公司代码 0001 和期间 1998 年 4 月，点运行；系统给一条警告，别去编辑，直接按回车继续；运行成功后连点退出键回到 SHDB。这三次屏幕交互会被记录成三个屏幕的脚本。录完之后返回 SHDB，能看到脚本里记录了三个屏幕的信息，关键字段是 I_LFMON（月份，2 字节）、I_LFGJA（年份，4 字节）和 I_VBUKR（公司代码）。到这一步，第一个实用的场景就出现了：如果只是改一两次字段重跑，可以不用导出脚本，直接在 SHDB 界面里改字段值点「处理」就行。

提示：录屏时手抖多点了下拉框、多按了一次回车，脚本里就会多出多余的字段赋值，虽然很多时候不影响最终结果，但排查字段错位时会非常干扰。

2.2 看懂录屏脚本：屏幕字段、字段宽度与一次修改重放

录屏完成后回到 SHDB 维护界面，双击记录可以看到类似下面的脚本结构。这里展示的是导出后的文本文件内容，字段名和值一般按行交替存放，用制表符或换行分隔，这是 BDC 脚本的基本组织方式。

TCODE MMPV 屏幕 100 I_LFMON 04 I_LFGJA 1998 I_VBUKR 0001 屏幕 200 BDFLAG X 屏幕 300 BDOK X

这段脚本的含义是：先调用事务码 MMPV，在屏幕 100 里填了月份 04、年份 1998、公司代码 0001，然后依次经过屏幕 200、屏幕 300 完成后续确认。字段宽度决定了值的格式：I_LFMON 只有 2 个字符，所以月份要写 04 而不是 4；I_LFGJA 有 4 位，年份必须写成 1998 或 2000 这种完整四位。公司代码 0001 也是按 4 位补零存储的。

在这个界面，可以手工修改字段值再点「处理」，系统会按照修改后的字段重新执行一次 MMPV。这种方式的适用边界很清楚：只适合少量重复，比如补开一两个月账期、临时换个公司代码验证。改成大批量就暴露问题了——你不可能手工去改 20 段相同结构的脚本，所以下一步是把录屏脚本导出成模板，用外部工具生成批量脚本，再加载回 SHDB 统一执行。导出的文件可以存成任意名字，本例导出为 ZMMPV.txt，这个文件就是后续批量加工的基础原料。

2.3 前台与后台两种重放方式：什么时候用哪个

脚本重放时有明显的模式差异。点「处理」按钮后会弹出处理模式选择，前台（A）模式下，系统会一个屏幕一个屏幕地把执行过程完整展示出来，像有人在你面前又操作了一遍事务码。这种模式最大的好处是直观，脚本里哪一步出错，当场就能看到界面停在哪里、报什么错，是第一次执行脚本时的首选调试方式。代价是慢，每一条数据都要人工确认式地走过所有屏幕，批量回放时基本不采用。

后台（N）模式则完全相反，执行过程不显示任何屏幕，脚本放进去后系统默默跑完，最后给一个执行结果记录列表。速度快，能连续处理大批量脚本，但坏处是执行过程中看不到画面，出错只能事后从结果记录里翻。实际项目里的常见组合拳是：先用前台模式跑一条数据确认脚本没问题，再用后台模式放量执行剩余数据，最后翻执行结果记录核对每条脚本的完成状态。

还有个中间态值得提：处理模式对话框里不止前台和后台两项，还会有前台带日志之类的选项，但日常用得最多就是前台和后台。如果脚本本身有问题，直接上后台执行二十条，系统不会给你任何提示，跑完结果列表里一片「成功」，实际数据却没进去，这种假阳性很坑。所以后台执行前，至少用前台跑通一条。

3. BDC 批量执行链路：模板导出、批量脚本生成、回放校验

3.1 一份录屏只能覆盖一次执行：批量脚本拼接的最小单位

为什么不能直接在 SHDB 里录完 20 个月份的账期？因为录屏记录的是操作序列，不是数据表，你录了一个月再录下个月，生成的是两条独立的脚本记录。SHDB 里可以重复创建记录，但录 20 次就等于把重复劳动做 20 遍，这偏离了批处理的初衷。正确思路是：录一份最小脚本，把它当作模板，用数据源驱动的办法生成多份脚本内容，再一次性导入执行。

这里要建立一对核心的映射关系：一份录屏脚本只对应一次事务码执行。打开 1998 年 4 月账期这段录屏，本质上就是「TCODE = MMPV、期间 = 1998/04」的一次执行；要打开 5 月，就要把期间字段改成 1998/05。批量脚本文件就是一个包含多条独立执行段的纯文本文件，每条执行段的结构完全相同，只有月份、年份字段值在变。理解了这一点，就不难明白为什么后续用邮件合并或脚本拼接能生成批量文件——本质上是把模板里的字段值替换成多组数据。

从 SHDB 导出生成的 ZMMPV.txt，就是这样的模板文件。你可以先把它在文本编辑器里打开，确认有几行字段、几行值，结构是怎样的。打开之后会发现录屏时「提交后继续」勾选产生的结果：脚本里包含三个屏幕的处理块，而不是只有第一个屏幕就结束。这个结构是后续生成批量脚本时要保持不变的骨架。

3.2 用邮件合并或脚本驱动生成批量脚本：字段对齐是命门

正文中提到了用 Office 邮件合并的方式加工脚本，这是最传统的做法：建一个 Excel 或 CSV 数据源，两列分别是月份和年份，邮件合并模板里放一段录屏脚本，每合并一行数据就生成一段执行脚本，最终把所有段拼成一个文本文件。但邮件合并有个烦人的地方，列顺序和模板字段顺序必须严格对齐，一旦数据源里月份列和年份列位置换了，生成的脚本里I_LFMON拿到年份、I_LFGJA拿到月份，后果很严重——系统会认为你在 1998 年开 12 月账期，或者年份字段校验直接报错。

我一般在没有 Office 环境的机器上会用一段简短的 Python 脚本做同样的事情。原理和邮件合并完全一致，只是把模板占位符替换成了程序的字符串格式化。下面这段代码示例演示了如何生成 1998 年 5 月至 1999 年 12 月共 20 段 MMPV 执行脚本，保存为 MMPV_BATH.txt。

import datetime template = """TCODE MMPV 屏幕 100 I_LFMON {month:02d} I_LFGJA {year:04d} I_VBUKR 0001 屏幕 200 BDFLAG X 屏幕 300 BDOK X """ lines = [] year, month = 1998, 5 for _ in range(20): lines.append(template.format(year=year, month=month)) if month == 12: year += 1 month = 1 else: month += 1 with open("MMPV_BATH.txt", "w", encoding="utf-8") as f: f.write("".join(lines)) print("生成完成，共 {} 段脚本".format(len(lines.split(""))) )

逻辑说明：模板字符串里{month:02d}和{year:04d}是占位符，前者保证月份按两位补零输出（4 月生成 04、12 月生成 12），后者保证年份四位输出；循环体内每生成一段脚本就推进一次月份，遇到 12 月时年份加一、月份回到 1 月，正好覆盖 1998/05 到 1999/12 这 20 个月。参数说明：range(20)是脚本段数，要和需要执行的月份数一致；月份推进逻辑要特别关注，这是跨年时最容易出错的地方，如果漏了month == 12的判断，年份会永远停在 1998，后面连续生成 12 段错误的 1998 年 12 月账期。

生成的文件里每段结构都和录屏模板完全一致，这就是批量执行的基础。用邮件合并的话，本质替代品是 Word 的「邮件」功能，数据源里放 MONTH 和 YEAR 两列，模板正文放上面的脚本片段并插入合并域，每行数据生成一段，最后合并到新文档另存为纯文本。两种方式生成的文本内容应当完全一致，你可以在文本编辑器里直接打开检查开头几段，确认 TCODE 后面跟的是 MMPV，年份、月份、公司代码顺序正确。

3.3 重新导入与后台执行：结果清单和行数翻倍怎么看

批量脚本文件生成后，回到 SHDB，点导入按钮加载 MMPV_BATH.txt，系统会用这个文件的内容替换掉原有脚本。加载后界面会显示第一段执行脚本的字段值已经变成月 5、年份 1998。这里有一个可验证的细节：原录屏脚本大约是 13 行组成一段执行块，20 段就会显示成 260 多行，如果导入后发现行数不对，先检查生成脚本时是不是多加了空行。

导入之后点「处理」，弹出处理模式对话框，选后台（N）确认执行。因为后台模式看不到实际屏幕，跑完以后会给出一个执行结果记录列表，每条记录对应一段脚本的执行结果。这个列表要怎么看？每段脚本最终都有个状态码，成功会显示正常完成的标志，出错会显示对应的错误信息。但注意，这里的信息粒度是「脚本是否跑完」，不是「业务是否成功」——脚本跑完不代表物料账期真的开了。

之前有个案例，同事用后台模式跑了一批物料主数据扩展的 BDC 脚本，结果列表全部成功，但后来发现录屏里有个必填字段没有赋值，系统压根没保存任何数据。所以后台执行结束后，建议至少抽查一条实际业务结果，用 MMPV 或者物料凭证相关的事务码去查一下对应月份的账期状态。这一步可以放在后面统筹讲，但请先记住结论：批处理搞定的是操作过程，不是业务正确性。

4. LSMW 的标准 14 步：从数据准备到实际转换

4.1 管理界面里的三层对象树：Project、Subproject、Object

LSMW 和 BDC 最大的区别在于，BDC 直接录屏重放，而 LSMW 是一套完整的数据迁移框架。进入事务码 LSMW，第一次运行会看到欢迎界面，把不再显示的选择框勾上就能进管理界面。管理界面里要先确定一个三层对象结构：Project（项目）、Subproject（子项目）、Object（对象）。比如做一个物料主数据迁移，Project 可以叫「上线数据导入」，Subproject 叫「物料主数据」，Object 叫「物料基本视图」，三个层级合起来唯一确定一套迁移定义。

为什么要分三层？因为一个上线项目里有大量数据对象要迁移：物料、客户、供应商、库存初始化、销售订单，如果全部平铺在一起，维护字段映射时很容易混。三层结构相当于给每类数据划了独立的工作区，互不干扰。第一次用 LSMW 的常见困惑是不知道这三个名称是自己随便起还是有讲究——它们只是名称标识，没有后台表逻辑关联，你可以完全按自己习惯命名，但建议遵循「项目-业务模块-具体对象」的分层规则，方便后续维护。

管理界面的作用除了维护对象树，还包括对象的新增、修改、删除、查找，以及导出、导入迁移定义。但日常操作的主战场不只是这里，真正干活的地方是「分步操作界面」——在管理界面选定 Project、Subproject、Object 后按运行键进入，这个界面列出迁移的所有步骤，才是 LSMW 的核心。

4.2 从 20 步裁剪到 14 步：用户菜单选择与主数据导入的差异

分步操作界面默认显示 20 个菜单步骤，但这 20 步是完整版，实际做常规主数据迁移用不了这么多。标准做法是点选择用户菜单的按钮，弹出一个对话框，把最后 6 个非必要步骤的勾选去掉，保留前 14 步。这 14 步几乎覆盖了所有常规数据迁移场景，在 ECC 6.0 里标准菜单就是 14 步，IDES 4.71 等老版本才需要手动裁剪。

这 14 步可以分成几个阶段，用表格可以看得更清楚些。

表里最后两行的顺序容易被搞混：读取数据并预转换只是把外部数据读入 LSMW 内部结构并按规则变换，还没写入 SAP；真正生效的是后面的数据转换步骤。如果预转换阶段发现映射错误，直接回头改映射重新读取就行，不会对系统产生任何影响。

4.3 核心字段映射与读取规则定义：预转换阶段能发现什么

LSMW 的实战操作重点在字段映射这一步。以物料主数据为例，源文件是 CSV，里面可能叫MATNR（物料号）、MAKTX（物料描述）、MEINS（基本单位）、MATKL（物料组），而目标结构 MM01 屏幕里对应的字段名可能是MATNR、MAKTX、MEINS、MATKL——有些能直接对上，有些对不上，就需要手工映射。LSMW 提供了可视化映射界面，左侧是源结构字段，右侧是目标结构字段，中间划线连接即可。

给一个源数据的样例，实际从旧系统导出的物料主数据 CSV，第一行是字段名，后续是数据行。

MATNR,MAKTX,MEINS,MATKL 100001,电子控制单元,ST,PC 100002,线束总成,ST,PC 100003,铝合金壳体,ST,PC

这个文件的字段顺序在目标结构里要怎么对应，是映射阶段要考虑清楚的业务逻辑。定义源结构时要把每一列的字段名和数据类型写清楚，LSMW 用这些元信息解析 CSV 内容；定义目标结构时列出 SAP 侧需要接收的字段。两者通过映射关系连接。映射做对之后，读取数据并预转换阶段会给出每条数据的转换结果及错误明细，常见错误包括物料号在 SAP 里已存在、单位字段值不符合自定义单位表、物料组不存在等。预转换的全部意义就是把这些错误暴露在写入 SAP 之前。

顺便提一句和 BDC 的典型分工：如果只是把现有 SAP 数据从一个状态改成另一个状态（比如批量改物料组），BDC 录屏重放完全够用；但要是从旧系统往 SAP 导几万条主数据，还涉及字段值转换和错误重跑机制，LSMW 更合适。这也回应了选型问题——不是哪个工具更好，而是场景决定了工具。

5. 避坑清单：录屏、生成脚本、回放三个环节的五个坑

5.1 录屏与脚本生成期的三个坑

第一个坑是录屏时多余操作污染脚本。现象：录完以后回到 SHDB，脚本里多了好几个不明字段，比如BDC_OKCODE后面多了一串没见过的功能码。原因：录屏过程中手误了点了一个不该点的按钮或按了多余的回车，系统把这次操作也记录进去了。解决：重新录一遍，录之前把手从鼠标上挪开，需要翻页时明确使用 PageUp、PageDown 键，录完先回看脚本确认字段数量符合预期再继续。

第二个坑是月份字段补零和字段宽度问题。现象：生成批量脚本后发现月份值从 1 到 9 是 1、2、3 这种形式，导入 SHDB 后执行报错。原因：I_LFMON字段宽度是 2 字节，但生成脚本时直接把数字格式化了，没有补零。解决：在生成脚本的数据加工环节强制左补零——Python 用format(month, '02d')，Excel 里用 TEXT 函数=TEXT(B2, "00")，确保所有月份都是两位数字，12 月变成 12 没问题，6 月必须是 06。

第三个坑是批量脚本文件里的空行。现象：生成 MMPV_BATH.txt 后行数是「13 的 20 倍」再多 20 行，导入 SHDB 后执行结果里出现了空记录。原因：生成脚本时每段之间多写了一个换行符或文件末尾多了一行空行，SHDB 把空行识别成了一段脚本。解决：生成时用strip去掉每段首尾空白，或者生成完毕后打开文件检查行数，多一个空行就从 260 行变化成 261 行，这个细节能提前暴露问题。

5.2 执行与结果核对期的两个坑

第四个坑是后台执行显示成功但数据没变化。现象：后台模式跑完 20 段脚本，结果列表全部成功，但打开 MMPV 查看物料账期发现只开了第一段脚本对应的月份。原因：脚本中某个字段在录屏里没录到，重放时系统因为字段缺失没真正保存，但 BDC 执行逻辑认为脚本跑通了，没有抛出硬错误。解决：后台执行前，先用前台模式跑一条同结构的脚本，逐屏确认关键字段值确实进入到了系统界面；批量跑完后，随机抽查实际业务数据，不要只看执行结果列表。

第五个坑是跨年时年份字段没有联动。现象：生成 1998 年 5 月至 1999 年 12 月的脚本，执行后发现 1999 年的月份全部没有记录，或者系统报错说期间不在有效范围内。原因：生成脚本时月份和年份是独立推进的，没有考虑 12 月之后年份加一，所有 1999 年月份实际写的是 1998/01 到 1998/12，重复覆盖了已有账期。解决：在生成逻辑里加入跨年判断，遇到 12 月就把年份加一、月份置为 1，这一步建议用单元测试或打印前几段脚本来验证，确认第四段和第十三段脚本的年份值正确。

6. 收尾技巧：最小集回放加三重验证，让批量脚本不返工

BDC 批量执行最怕的不是出错，而是出错时你根本不知道错在哪里。我现在的习惯是：任何批量脚本生成后，不直接导入执行，先走一遍最小集回放。所谓的「最小集」，就是只保留第一段脚本，把后面的 19 段都临时移出文件，用前台模式执行。前台模式下系统会把屏幕一步步展开，你可以核对I_LFMON和I_LFGJA字段实际显示的值是否和预期一致。如果这里没问题，基本可以确认脚本结构、字段映射和值格式化都对。

最小集通过后，把剩余脚本重新拼接完整，后台模式执行。执行结束不着急关结果列表，先做三重验证。第一重验证看执行结果记录，确认每一段脚本的状态码都是成功，没有卡在屏幕跳转或字段校验失败；第二重验证查业务数据，物料账期可以直接用 MMPV 查看当前期间，确认 1998 年 4 月到 1999 年 12 月每一段对应月份都已经开好，不要只看列表状态码；第三重验证看边界月份，重点查 1998 年 12 月和 1999 年 1 月这两个跨年节点，数据在，说明生成脚本时的年份联动逻辑是对的。

字段装配上，我习惯在公司代码不变的情况下，把月份和年份作为仅有的两个可变字段，其他字段值全部沿用录屏原值。这样做的目的是缩小出错面，任何回放异常都可以快速定位到月份或年份字段格式，而不是一大堆字段里逐个排查。补零规则、四位年份、字段顺序这三件事，每次生成脚本我都强制检查一遍，不管用邮件合并还是脚本批量生成，跑完顺手打开文件看前两段。

从那以后我每次跑批量脚本前都强制走一遍最小集回放加边界验证，哪怕只是几条数据也要确认字段看上去没问题，再用后台把剩余的执行放出去。这个习惯帮我省了不少返工，也希望帮你避掉那些查不出原因的假成功。希望帮到你。

本文还有配套的精品资源，点击获取