简介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 事务码里能看到这个会话选择“处理”或“处理/后台”由系统一条条执行。两条路怎么选我一般这样判断维度CALL TRANSACTIONSessionSM35执行时机代码里立即执行稍后由 SM35 处理数据量适合几百条以内几千上万的大型导入错误处理逐条收集 MESSAGES当场决定中断与否按会话粒度处理出错自动记录并跳过界面干扰静默执行时用户无感后台运行用户可继续做别的事恢复中途失败难回滚会话级可重新处理/删除如果程序一次要导几千条主数据用 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兼容所有带屏幕事务的导入否但依赖录屏路径通过 BAPI 调用有标准 BAPI 的业务对象物料、客户等否但要对 BAPI 接口参数通过 IDoc 消息SAP 之间或 EDI 式数据交换否但要有消息类型与端口配置批输入录制录屏获得屏幕字段再做字段映射否屏幕路径可控“批输入录制”本质就是 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_EXITLSMW 里则有一条现成的转换规则可以勾选。执行阶段配置完后面的操作按顺序执行读取数据把文件内容读入 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 或 IDocLSMW 虽然也提供 BAPI 方法但它本质仍是半手工批导不适合做接口级实时调用。先把“批量录入”和“接口同步”这两个范畴分清选型才不会一开始就跑偏。4.2 从数据量、频率和错误成本做选型每次在项目里被问到“BDC 和 LSMW 到底用哪个”我都建议先回答三个问题这活儿是一次性迁移还是定期月结功能顾问自己能否动手还是要 ABAP 开发介入数据量大不大出错后业务能否承受下面这五类典型场景是我在多个项目里验证过的选择方式场景推荐工具理由一次性迁移几万条物料主数据LSMW录屏法最快成型会话可后台跑出错好定位每月定期批量过账财务凭证ABAP CALL TRANSACTION凭证逻辑适合程序化调试可见性好临时修改某个字段利润中心、成本中心LSMW不用开发介入半小时搞定外部系统对接、需要接口级集成RFC/BAPI不是 BDCBDC 是界面回放不是接口协议没有现成 BAPI、但有可录屏幕的旧事务LSMW 录屏法用屏幕字段绕开 BAPI 缺失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 日志多一道保险——日志记的是屏幕消息报表记的是数据状态。近十年的习惯是批导之后永远保留源文件、会话日志、对账报告三样东西按项目编号归档。月结、审计时这套资料能少解释很多问题。希望帮到你。本文还有配套的精品资源点击获取