企业官网建设流程全解析

简介：SAP系统批处理与数据迁移的操作指南，面向SAP顾问、数据运维及实施人员，聚焦BDC与LSMW两款常用工具，系统梳理各自适用场景。资源为单份docx文档，大小约2.49MB，内容从实际录屏案例入手，以物料账期打开为示例，完整演示SHDB录屏、脚本检查、前台/后台执行、模板导出及Office邮件合并生成批量脚本；随后详细拆解LSMW的14个标准步骤，包括对象创建、数据文件定义、源结构与目标结构映射、转换规则设置及最终数据传输。已有1748人学习下载，适合需要处理大批量主数据、或面临旧系统向SAP迁移任务的读者。文中配有界面截图，明确区分BDC轻量批处理与LSMW复杂迁移的边界，并结合公司代码维护、物料凭证结算期间等业务场景，帮助读者减少手工操作、提升数据维护效率，也可作为团队内部培训的参考。

1. 为什么这两个批处理工具值得写一整篇

在 SAP 实施和运维现场，最磨人的不是写增强、不是调接口，而是那种“同样的操作一天重复 200 遍”的批量维护。建物料主数据、批量过账财务凭证、改供应商银行信息，随便拉出来一项，都能让顾问在 SAP GUI 上点一整天，眼睛盯着屏幕生怕点错行。SAP 为此准备了两样东西：BDC 和 LSMW。BDC 是批处理技术的底层实现，把你在界面上做过的一套操作录下来、回放出去；LSMW 是在批处理之上做出来的数据迁移平台，支持 Excel 和文本文件直接映射到 SAP 屏幕操作，不用写代码。下面逐个拆开讲，从录屏、代码生成、字段映射一路讲到执行和排错，适合刚进项目的 ABAP 开发、FICO/MM 顾问，也适合长期被数据迁移折腾的运维工程师照着做。

2. BDC 批处理：从录屏、写代码到三种执行方式

2.1 BDC 的原理：屏幕、字段与功能码的数据结构

BDC 全称 Batch Data Communication，是 SAP 最老牌、也最底层的批处理接口。它的思路一句话能说清：把你在 SAP GUI 上做一次业务操作的全过程，拆成“程序名 + 屏幕号 + 字段名 + 字段值 + 功能码”的序列，然后在系统内部按同样顺序重新触发一遍。

底层表结构是BDCDATA，每行承载一种动作：

• PROGRAM字段记录该屏幕所属的 ABAP 程序；
• DYNPRO记录屏幕编号；
• DYNBEGIN = 'X'表示这一行是新屏幕的开始；
• FNAM / FVAL记录屏幕字段名和字段值；
• 特殊的FNAM = 'BDC_OKCODE'行记录按键功能码，模拟“回车”“保存”这类操作。

下面是一个手写 BDC 数据的常见骨架：

DATA: lt_bdc TYPE TABLE OF bdcdata, ls_bdc TYPE bdcdata. FORM dynpro USING p_prog p_dyn. CLEAR ls_bdc. ls_bdc-program = p_prog. ls_bdc-dynpro = p_dyn. ls_bdc-dynbegin = 'X'. APPEND ls_bdc TO lt_bdc. ENDFORM. FORM field USING p_fnam p_fval. CLEAR ls_bdc. ls_bdc-fnam = p_fnam. ls_bdc-fval = p_fval. APPEND ls_bdc TO lt_bdc. ENDFORM. FORM okcode USING p_code. CLEAR ls_bdc. ls_bdc-fnam = 'BDC_OKCODE'. ls_bdc-fval = p_code. APPEND ls_bdc TO lt_bdc. ENDFORM.

三个 FORM 是 BDC 程序的基本骨架：dynpro在每步开始时打上屏幕标记，field给屏幕字段传值，okcode模拟用户按键。用它们拼一段 FB50（财务凭证过账）的数据就是这个效果：

PERFORM dynpro USING 'SAPMF05A' '0100'. PERFORM field USING 'BKPF-BUKRS' '1000'. PERFORM field USING 'BKPF-BLDAT' '20250115'. PERFORM field USING 'BKPF-BUDAT' '20250115'. PERFORM okcode USING '/00'.

逻辑说明：第一屏输入公司代码 1000、凭证日期 20250115、过账日期 20250115，然后回车。/00是回车这个功能码，SAP 随后会跳到 0101 屏幕（行项目编辑）。如果代码漏了PERFORM okcode，数据就停在这个屏幕，字段永远不会提交。

参数说明：

• 'SAPMF05A'和'0100'是 FB50 事务背后前台的程序名与屏幕号，这两个值必须与录屏得到的完全一致，写错一个就报“屏幕不存在”。
• BKPF-BUKRS是公司代码的屏幕字段名，格式是“表名-字段名”，不是直接照抄数据库表字段。
• OKCODE 常见取值有'/00'（回车）、'=SAVE'（保存）、'=BK'（返回），具体值以录制结果为准，不同事务、不同 SAP 版本可能有差异。

这里最容易让人绕晕的一个点是：屏幕布局不是固定死的。同一张屏幕，前面字段的取值会影响后面字段是否出现。比如物料主数据里，物料类型选了“成品”和选了“原材料”，后续屏幕上的“行业领域”“单位”字段布局完全不同。所以录制一条路径只能覆盖一种业务形态，这一点在后文踩坑部分会展开。

2.2 用 SHDB 录屏并生成可复用 ABAP 代码

SHDB 是标准的批处理录屏事务码。进入后点工具栏的“新建录制”，给录制起个名字（比如 ZREC_FB50_01），填要录制的事务代码（比如 FB50），系统直接打开 FB50 初始界面。此时你把一笔凭证从头做到尾，做完保存、点返回，SHDB 就把全过程记录在案，回到 SHDB 主界面就能看到这条录制。

选中录制条目，菜单栏有个“程序”按钮，点击后 SAP 会生成一段 ABAP 程序。这段程序的内容是把录制到的 BDC 数据逐屏、逐字段填充到BDCDATA内表，然后调用 CALL TRANSACTION 或提交为会话。生成的代码跟 2.1 里手写的结构几乎一样，只是没有参数化，数据全部写死在代码里。

实际项目中几乎没人直接用生成的“死代码”。更常见的做法是把录制当“字段字典”：展开 SHDB 中这条录制的“字段清单”，能看到所有经过的屏幕、字段名和值。手写 BDC 时照这个清单去填，能避免字段名写错。拿到字段清单后，把逻辑封装成可复用的子程序，以 FB50 为例：

FORM build_bdc_fb50 USING p_bukrs TYPE bkpf-bukrs p_bldat TYPE bkpf-bldat p_newbs TYPE rf05a-newbs p_newko TYPE rf05a-newko p_newum TYPE rf05a-newum. PERFORM dynpro USING 'SAPMF05A' '0100'. PERFORM field USING 'BKPF-BUKRS' p_bukrs. PERFORM field USING 'BKPF-BLDAT' p_bldat. PERFORM field USING 'BKPF-BUDAT' p_bldat. PERFORM okcode USING '/00'. PERFORM dynpro USING 'SAPMF05A' '0101'. PERFORM field USING 'RF05A-NEWBS' p_newbs. PERFORM field USING 'RF05A-NEWKO' p_newko. PERFORM field USING 'RF05A-NEWUM' p_newum. PERFORM okcode USING '=SAVE'. ENDFORM.

逻辑说明：这里把录制里写死的值换成了参数。RF05A-NEWBS是行项目过账码的屏幕字段名，RF05A-NEWKO是科目，RF05A-NEWUM是金额。参数声明成数据字典里对应的类型（TYPE bkpf-bukrs），可以借用 SAP 的字段帮助和长度校验，调用时传错类型也能提前发现，不必等到执行时翻车。

字段名坑：FB50 在初始屏幕上的抬头字段是BKPF-*，但在行项目屏幕上的字段却变成RF05A-*，不是BSEG-*。屏幕字段名和数据库表字段名不总是对得上，尤其行项目中间字段。所以还是那句老话：别背字段名，每次以 SHDB 录制结果为准。

2.3 CALL TRANSACTION 与 Session：两种执行方式的差异与选型

BDC 数据拼好之后，怎么送进去执行，常见是两条路。

第一，CALL TRANSACTION 直接调用，在 ABAP 程序里同步执行：

CALL TRANSACTION 'FB50' USING lt_bdc MODE 'N' UPDATE 'S' MESSAGES INTO lt_msg.

参数说明：

• MODE：屏幕模式。'N'静默执行不弹界面；'A'逐步全屏显示；'E'只在出错时显示。开发环境调试用'E'，生产环境大量跑用'N'。
• UPDATE：更新方式。'S'同步更新，程序等数据库写完后才返回；'A'异步更新；'L'本地更新。
• MESSAGES INTO lt_msg：把所有屏幕消息收进内表，循环检查lt_msg-msgty就能判断每条数据是成功还是失败。

第二，批处理会话（Batch Input Session）。先把 BDC 数据塞给 SAP 的会话表，再由 SM35 在后台按计划处理：

CALL FUNCTION 'BDC_OPEN_GROUP' EXPORTING client = sy-mandt group = 'ZBDC_FB50_01' user = sy-uname keep = 'X' holddate = sy-datum. CALL FUNCTION 'BDC_INSERT' EXPORTING tcode = 'FB50' dynprotab = lt_bdc. CALL FUNCTION 'BDC_CLOSE_GROUP'.

逻辑说明：第一步打开一个名为 ZBDC_FB50_01 的会话组，第二步把内表数据插入这个组，第三步关闭组。之后到 SM35 事务码里能看到这个会话，选择“处理”或“处理/后台”，由系统一条条执行。

两条路怎么选？我一般这样判断：

如果程序一次要导几千条主数据，用 Session 更稳：导到一半出错，可以到 SM35 里把剩余部分重跑，不必整个程序推倒重来。如果业务要求“实时导入、立刻校验”，比如某个批量录入工具要马上看到每条数据成败，那用 CALL TRANSACTION MODE 'E' 更合适。这个判断标准在 SAP 批处理里延续了很多年，没有绝对的优劣，只有场景适不适合。

3. LSMW 批处理：不写代码，把 Excel 变成 SAP 批导任务

3.1 LSMW 的导入方法，以及录屏法为什么最常被写进教程

LSMW 的全称是 Legacy System Migration Workbench，中文资料常把它叫“旧系统数据迁移平台”。它最初是为了帮企业升级或替换旧 ERP 时把历史数据搬到新 SAP 系统，后来被实施顾问发现更适合做日常批量导入，慢慢变成了“万能批导工具”。

LSMW 是事务代码。进去后先看到项目（Project）、子项目（Subproject）、对象（Object）三层结构。对象建好后，第一步定义对象属性时要选导入方法。常见选项有这四类：

“批输入录制”本质就是 BDC 录屏的界面化，而且 LSMW 能直接引用录屏得到的屏幕字段清单，把它作为字段映射目标。实际项目里这个方法最常用，因为它能处理那些“没有标准 BAPI、IDoc 也要配置半天”的麻烦事务。比如修改客户银行信息、调整销售订单项目类别，这类操作的 BAPI 参数很绕，录一遍屏、映射一遍字段是最快路径。SAP 系统里的 MM01、XD01、FK01 这类主数据维护事务，用录屏法做 LSMW 导入，是实施项目里出现频率最高的组合。

3.2 源结构、字段映射与转换规则：LSMW 的三个核心步骤

LSMW 整个流程分成配置和数据迁移两个阶段，核心步骤集中在三块：定义源结构、定义源字段、维护字段映射。下面以“把 CSV 里一批物料主数据导入 SAP”为例子，走一遍常见流程。

第一步：定义源结构。告诉 LSMW 你要导入的外部文件长什么样。常见做法是单层结构：整个文件是一层，字段就是文件的列。如果要同时导入物料主数据、物料描述、工厂库存，那就需要多层结构（文件里分段），每个段对应一个源结构。

第二步：定义源字段。逐列定义外部文件的字段。这一步最琐碎：第一是字段名，第二是数据类型（CHAR、数值、日期），第三是长度和格式。比如 CSV 文件里有三列：物料号、物料描述、工厂，源字段大致如下：

MATNR,CHAR,18 MAKTX,CHAR,40 WERKS,CHAR,4

第三步：维护字段映射。这是 LSMW 的核心，界面左右两栏，左边是源字段，右边是录屏到的 SAP 屏幕字段。操作上就是把左边的 MATNR 拖到右侧 RMMW1-MATNR，把 MAKTX 拖到右侧 MAKT-MAKTX。文件里没有、但 SAP 屏幕又必填的字段，则要维护固定值，比如物料类型 MATART 固定为 FERT。转换规则在映射完成后单独维护，用于处理日期格式、数值千分位、去前导零这类转换。

固定值和转换规则这两个功能是 LSMW 比纯 BDC 代码省心的核心原因。同样一个“物料类型”字段，如果它不来自文件，BDC 里你得在代码里硬写一个值，LSMW 里点几下配置就行；同样日期格式转换，BDC 要么在 Excel 里预处理，要么在 ABAP 里写 CONVERSION_EXIT，LSMW 里则有一条现成的转换规则可以勾选。

执行阶段：配置完后面的操作按顺序执行：读取数据，把文件内容读入 LSMW；转换数据，按映射和转换规则生成待传输记录；传输数据，把结果做成批导会话。三步在同一套配置上重复使用。下次换一个新数据文件，重新读取、转换、传输即可，配置不用改。

这里给一个文件读取的参数参考：分隔符通常用制表符或分号，文件开头有几行空行或标题行要跳过；日期列先在 Excel 里统一成文本 YYYYMMDD，避免 Excel 把日期变成序列数。后两个细节每个顾问都栽过跟头。

3.3 批导会话创建与处理：SM35 里的完整闭环

LSMW 的“传输数据”执行完，界面会提示生成批导会话。到 SM35 里能看到 ZMM_MAT_CREATE 之类的会话名。然后进入会话处理环节，有两种模式：

• 前台模式：SM35 选中会话、点“处理”，系统一条条执行并显示屏幕，适合第一次测试和少量数据。处理时能看到每一条数据的屏幕跳转，定位问题非常直观，但也慢。
• 后台模式：点“处理/后台”或“处理/自动”，系统按顺序静默执行。几千条以上用这个，执行时人可以离开界面去做其他事。

会话处理完，SM35 的日志里记录了每条数据的执行消息。如果第 10 条报“字段工厂不能为空”，日志会把这个屏幕消息原样记下来，对照源文件找问题行，修正后再创建一个小会话单独补导，完全不需要重新处理全部数据。

LSMW 用会话方式的另一个好处是审计友好：数据从文件到 LSMW 到会话，每一步都有持久化记录，事后能回溯“这批数据是哪个账号、什么时间、按什么配置导入的”。做数据迁移项目时，这份记录能省掉大量跟业务解释数据来源的时间。

4. BDC 和 LSMW 怎么选：五个真实场景的对比

4.1 “批量录入”和“接口同步”，是两回事

很多刚接触批处理的朋友，一听到“批量”就条件反射想到 BDC。但 BDC 本质是模拟 GUI 操作，不是数据接口。SAP 与外围系统做实时或准实时同步，标准做法是 RFC、BAPI、SOAP/REST 或 IDoc；LSMW 虽然也提供 BAPI 方法，但它本质仍是半手工批导，不适合做接口级实时调用。先把“批量录入”和“接口同步”这两个范畴分清，选型才不会一开始就跑偏。

4.2 从数据量、频率和错误成本做选型

每次在项目里被问到“BDC 和 LSMW 到底用哪个”，我都建议先回答三个问题：这活儿是一次性迁移还是定期月结？功能顾问自己能否动手，还是要 ABAP 开发介入？数据量大不大，出错后业务能否承受？

下面这五类典型场景是我在多个项目里验证过的选择方式：

4.3 什么情况下“不用批处理”才是对的

工具是现成的，但“什么时候别用”同样值得弄清楚。

第一种是重复量不够大。一个操作一周只发生三十次，和一天发生三百次，完全不是一回事。少量高频的操作用人工维护反而更稳，因为人会对数据临场判断，批处理只认规则。比如客户主数据里的地址字段偶尔包含“#”这类特殊字符，录屏回放时可能触发字段校验失败，手工输入时人眼能立刻发现并改掉，批处理做不到这种灵活应变。

第二种是错误成本极高。财务凭证一旦过账错误没及时发觉，月末对账会非常痛苦。如果有几十笔异常数据混在几千笔正常数据里，批导会把所有数据过一遍，错在哪一行只能靠 SM35 日志慢慢翻。这种场景值得在批处理之外多写一个“前置校验报表”，先把明显非法数据剔掉，再放批处理进场。

第三种是目标对象规则极其复杂。比如物料主数据里，同一种物料在不同行业、不同工厂有不同视图和字段组合，录屏一次根本覆盖不全。这种场景与其硬套 BDC/LSMW，不如让业务顾问先手工建一两条模板数据，再按模板的屏幕路径去拆分录屏字段集。录屏的覆盖面和容错率，比工具本身更影响导入成败。

4.4 性能与容错的权衡：为什么生产环境首选会话模式

工具定了之后，执行路径还有一个决策。LSMW 和 SHDB 会话都建立在 BDC 记录上，到了执行环节依旧有同步执行与 Session 两条路。这里有个容易让新手迷惑的点：LSMW 是不是只能走会话？答案是不一定。LSMW 传输数据时可以选择同步调用或生成会话，同步调用意味着在传输过程中逐条执行 CALL TRANSACTION，能当场上报错误，适合小批量验证；大批量数据建议统一走会话模式。

会话模式的容错逻辑是这样的：一条数据失败，会话不会中断，而是记录错误并继续处理后面的数据。最后根据日志单独修正失败行，重建一个小会话补导。真实迁移里这个能力几乎是刚需：一万条物料导入，总会有几十条因字段超长、日期不合法等原因失败，这批失败数据单独处理就行，不必重跑整个文件。另一个细节是会话数量控制：一个会话塞太多数据（比如几千条），SM35 处理时会话记录更新频繁，日志膨胀，界面变卡。经验阈值是每个会话控制在 1000 到 2000 条以内，量再大就按源文件数据范围拆几个会话，出错时定位也更方便。

5. 避坑指南：BDC 与 LSMW 的六个高频问题

5.1 录屏回放中途报错：一个字段值改变后续屏幕布局

现象：SHDB 录制时跑得好好的 BDC 数据，换了一条业务数据后，回放到某个屏幕突然报“字段 XX 当前不存在”，整条 BDC 中断。在 LSMW 的字段映射里也可能看到目标字段“消失”。

原因：SAP 事务有不少动态屏幕，屏幕字段布局由前面字段的值决定。比如物料主数据的行业领域、物料类型、视图选择，这些值一旦变了，后续屏幕就会出现或消失某些字段。BDC 录制记录的是一条固定屏幕序列，它无法应对屏幕结构变化。

解决：这是 BDC 和 LSMW 高频翻车的第一原因。录屏时用覆盖度最高的“典型样本数据”，一个录制只对应一种业务形态；业务形态差异大就拆成多个录制/LSMW 对象。更稳的做法是录屏前先固定前置字段，在 LSMW 里把这些字段设为固定值，不让它们随导入数据变化。如果数据形态实在太多，那就老老实实拆多个映射方案，不要指望一个录屏吃遍天下。

5.2 版本与补丁差异导致录屏失真

现象：同一套 LSMW 配置，在测试客户端（比如 ECC 6.0 EHP7）跑得好好的，切到另一个补丁版本不同的客户端，执行时报“屏幕字段不存在”或“屏幕号无效”。

原因：屏幕字段是字典对象，版本升级和补丁更新会改变屏幕布局，甚至给同一屏幕换掉字段名。常见的情况是从旧版本录屏文件拿来的 BDC 数据，放到高版本系统里跑，原来的字段名被替换或废弃。SAP GUI 版本从 80 到 810 的过程中，这类问题集中爆发过，很多项目的录制文件因此集体作废。

解决：录屏必须在目标环境的目标客户端做。准备在生产系统用的 LSMW/BDC 配置，应在生产系统（或与生产环境补丁版本一致的测试系统）里录制，不要拿旧系统录屏文件到处复制。同时注意语言：语言包会影响屏幕标签显示，一般不直接改字段名，真正影响字段名的是功能模块版本和补丁状态。多客户端项目里，这一点尤其要提前约束，否则上线前一天才发现录屏全是废的。

5.3 Excel 日期、前导零与文本编码问题

现象：Excel 里的日期列 20250115 读入 LSMW 后变成一串数字（45000 这种）；中文描述变成乱码；物料号 000010 变成 10。

原因：Excel 的自动处理机制。日期被当成序列数存储，数值开头的 0 被去掉，CSV 文件的编码（ANSI 与 UTF-8）不一致导致乱码。这跟 BDC/LSMW 本身关系不大，但杀伤力极大——数据在源头就已经坏了，后面映射再正确也白搭。

解决：三个常规操作：第一，日期列在 Excel 里先把单元格格式改成文本，录入 YYYYMMDD 字符串；第二，物料号、税号这类含前导零的列统一定义为文本列，不做公式处理；第三，CSV 保存时用 UTF-8 编码，SAP 端读取时也选 UTF-8。如果数字列确实需要从 Excel 数值转回来，用 LSMW 转换规则里的“补前导零”功能也能补救，但最稳的还是在源头控制。这个经验至少管用了十年，现在做数据迁移依旧适用。

5.4 批导会话卡在“正在处理”状态

现象：SM35 点“处理/后台”，会话状态停在“正在处理”十几分钟不动，再创建新会话，系统提示会话被锁。

原因：批处理会话需要后台作业运行。SM35 前台处理时如果操作员直接关掉 SAP GUI，会话会卡在半路；后台处理时则通常是业务对象被锁。比如你正在批量改客户主数据，另一个用户正开着同一客户的 XD01 界面，对象锁让批导无限等待，等待超时后会话停在“错误”状态。

解决：先到 SM50 查看当前后台进程，找到锁资源来源，让那个用户退出相关事务即可。SM35 会话的“错误”状态可以直接在事务里点“重新处理”，不必重建整个导入。处理大批量前，跟业务团队打好招呼，锁定期间别让其他人维护同一批业务对象。这个小协调动作能省掉大量排错时间。

5.5 会话执行权限跟谁走：创建者而非操作者

现象：LSMW 把会话创建出来了，SM35 处理时日志显示一堆“没有执行此操作的权限”。创建会话的用户有权限，但执行报错。

原因：Batch Input 会话的处理身份是“创建会话的用户”，不是 SM35 里点处理的那个用户。如果创建会话用的是临时账号或权限不完整的账号，执行时就会以那个账号身份跑，权限不足的报错随之而来。这在项目现场特别隐蔽：权限没问题的时候一切正常，换个创建人立刻露馅。

解决：导入账号要同时拥有 LSMW 配置权限和目标事务的执行权限。最好启用一个专用数据导入账号，配置 LSMW、创建会话、处理会话都用同一个账号。生产环境更严格的话，把批导会话的执行账号纳入 Basis 的定期权限审查，避免临时账号残留后患。

5.6 LSMW 字段映射后仍提示“目标字段不在屏幕”

现象：字段映射明明配好了，转换数据也生成了，传输时却提示“目标字段不在当前屏幕”。

原因：录屏时的屏幕路径与实际业务数据的屏幕路径不一致。这通常和 5.1 是同一个根因：动态屏幕。LSMW 录制的是固定屏幕序列，而实际业务数据可能因为前置字段值不同，跳过了或加入了某个屏幕，导致映射字段在那个屏幕上不存在。

解决：回到录屏，检查映射的字段是否真的出现在录制路径的屏幕上；如果字段确实存在但时有时无，说明这个字段本身是条件字段，需要把触发条件的前置字段设成固定值，确保屏幕路径稳定。排查时可以先在 LSMW 里重新看一遍录制屏幕清单，把字段映射逐一对照，不要凭空猜测。

6. 批处理上线的最后一关：验证方法与回归清单

批处理跑完不意味着结束，数据对不对才是业务真正关心的事。我的习惯是跑完一批导之后做三步验证。第一步是数量对账：把源文件行数与 SAP 侧产生的对象数匹配起来。物料主数据导入，用 MM03 查看，或者直接 SE16N 查表 MARA/MARC/MVKE 的记录数；财务凭证导入，按导入批次号查 BKPF 表。LSMW 的传输日志里有成功、失败、跳过统计，把统计表导出比对，差额数字会直接告诉你问题出在哪个环节。

第二步是抽样核对：按业务维度抽三到五条数据，回 SAP 界面逐屏核对关键字段：编码、描述、状态、组织层级数据、金额。这一步不能偷懒。项目中最怕的是“数量对上了但值错了”，比如物料号错位、日期错一个月，只有抽样能揪出来。第三步是回归验证：批导改的是数据，如果数据牵扯业务单据流程，比如创建了交货单、生成了会计凭证，要跟进下游单据是否正常。方法是把导入产生的凭证号按时间段拉出来，跑一下相关事务的报表，比如 FB03 查凭证。发现问题及时在后续批次里修正映射规则，而不是等业务来投诉。

一个必须养成的习惯是任何批处理上线前，先在测试系统彩排一遍。彩排不只是跑通 BDC 数据，要连业务校验一起走。测试系统的补丁版本、权限配置、主数据概况越接近生产，能预防的问题越多。等生产环境跑出问题再修，不光要处理数据错误，还得跟业务解释这段时间为什么数据是坏的，那就非常被动。

我自己还有一个土办法：在 LSMW/BDC 程序里做增量导出报告，导入完成后把系统里发生变化的记录按日期导出，再与源文件对一遍。这比纯靠 SM35 日志多一道保险——日志记的是屏幕消息，报表记的是数据状态。近十年的习惯是批导之后永远保留源文件、会话日志、对账报告三样东西，按项目编号归档。月结、审计时这套资料能少解释很多问题。希望帮到你。

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