SAP数据迁移实战：Direct Input与BDC批输入选型与避坑指南

开头

做 SAP 实施和运维这么多年，数据迁移、批量导入、历史数据补录基本是每个项目躲不掉的环节。不管是上线切换时把旧系统数据搬进新系统，还是日常运维里财务凭证、物料主数据、生产订单批量维护，SAP 给的标准批输入方案其实就两条主线：一条是 Direct Input，另一条是 BDC。很多顾问一听到批量导数据就想到 SHDB 录屏、LSMW，但真正遇到性能瓶颈、校验失败、大数据量处理时，还是得把这两套方案的底细摸清楚。

这篇文章不打算讲那些躺在帮助文档里的理论，而是按我实际项目里的使用经验，把 SAP 标准 Direct Input 和 BDC 批输入程序完整梳理一遍，包括标准程序清单、选型逻辑、调用套路和踩坑记录。适合正在做数据迁移的顾问、写批导程序的 ABAP 开发，以及刚接手运维要维护存量数据的业务同事。看完不说让你成为专家，但至少遇到批量导入需求时，能快速判断该走哪条路、该用哪个事务码、出了问题去哪查。

1. Direct Input 与 BDC 的本质区别与选型思路

1.1 快速理解两者差异

先说 Direct Input。SAP 提供了一批专门的报表程序，它们不走用户界面，而是直接通过内部调用把数据写入数据库。这些程序的入口通常是一个事务码或者一个报表，数据来源是外部文件，比如文本文件、Excel 转换后的 CSV。程序会读取文件、解析字段、执行校验、直接创建凭证或主数据。

BDC 的全称是 Batch Data Communication，它的逻辑完全不同。BDC 是模拟用户在 SAP 界面上的操作，通过程序自动向屏幕上的字段填入值、模拟点击按钮、触发后续事件和校验。BDC 有两种经典实现方式：一种是 Batch Input Session，也就是通常说的“会话批输入”，程序把操作记录下来生成会话，之后用 SM35 处理会话，本质是“回放用户操作”；另一种是 Call Transaction，程序通过 CALL TRANSACTION 语句直接模拟事务执行，每笔数据即时处理、即时返回结果。

两者的根本差异可以这样理解：Direct Input 是“走后门直接进数据库”，绕过界面，速度快、批量大，但一旦遇到校验失败的记录，定位问题要靠报表日志；BDC 是“走前门模拟人工操作”，完全复现用户路径，所有增强、校验、屏幕逻辑照常触发，但性能天然受限，因为每笔数据都要过一遍屏幕逻辑和数据库写操作。

这个区别直接决定了二者的应用场景：Direct Input 适合大规模、可控的数据初始化，比如 FI 凭证、资产、成本中心这些有专用导入程序的数据；BDC 适合那些没有专用 Direct Input 程序、但必须完整走业务逻辑的场景，比如修改采购订单、批量创建销售订单、维护复杂主数据。

1.2 选型决策：什么时候用哪个

我见过不少项目组在选型上翻车，最常见的错误是看到 BDC 录屏方便，就用 BDC 导几十万条财务凭证，结果跑了一晚上没跑完，第二天还要处理一堆报错记录。反过来，也有人硬要用 Direct Input 导销售订单，发现根本没有标准程序，最后只能自己写 BAPI 或 BDC，白白浪费时间。

我的经验判断顺序是这样的：

第一优先级，查有没有标准的 Direct Input 程序。财务类、资产类、HR 类通常有；销售、采购、生产类的极少，不要硬找。有就用，因为 Direct Input 是 SAP 官方针对该数据设计的，校验逻辑权威、性能经过优化，还支持文件断点续传。

第二优先级，查有没有 BAPI 或者类方法能实现。比如销售订单的 BAPI_SALESORDER_CREATEFROMDAT2、采购订单的 BAPI_PO_CREATE1、物料凭证的 BAPI_GOODSMVT_CREATE。BAPI 对业务逻辑的封装比 BDC 更可靠，参数清晰、返回消息结构化，而且不会因为屏幕变式或者字段顺序变化而失效。

第三优先级，才轮到 BDC。有些业务对象没有 BAPI，比如某些旧事务的批量修单、界面逻辑极其复杂的功能，或者后台配置导入。这时候 BDC 是没办法的办法，但也要尽量用 Call Transaction 而非 Session，因为 Call Transaction 可以直接和业务逻辑交互、及时捕获错误，Session 只能事后看日志，排错效率低。

简单总结成一句话：Direct Input 是大批量主力，BAPI 是业务对象导入主力，BDC 是兜底方案。如果哪个顾问和你说“所有报表都用 BDC 统一搞”，你可以直接质疑他的方案设计能力。

2. SAP 标准 Direct Input 程序盘点与使用要点

2.1 FI/CO 财务常用 Direct Input

财务数据是所有模块里 Direct Input 程序最完整的，基本上常见的财务导入需求都有标准程序对应。我列几个项目里最常用的：

• 总账科目余额导入：程序 RFBIBL00，对应事务码还没固定，一般是通过 SE38 运行。它能处理总账科目期初余额和余额结转，字段格式在文档里有明确定义，支持每个字段的最大长度和校验规则。
• 未清项导入：程序 RFBISA00，这个专门用于客户未清项、供应商未清项的期初导入，是财务上线切换的核心程序，很多项目在资产和未清项导入上都靠它。
• 业务数据导入：程序 RFBIBU00，处理会计凭证抬头和行项目，本质上可以归为通用的 FI 凭证导入工具。
• 资产导入：资产主数据导入是 OAAS 系列，资产余额导入用 OAMS 系列，早期项目常用 RAALTD01 等老程序。资产模块的 Direct Input 程序比较多，读取格式各有不同，用错了格式字段错位是常事。
• CO 内部订单/成本中心导入：RKCOBL00、RKCOBL01 用于成本中心、内部订单主数据批量建立，配合成本中心标准层次导入 RKCOHIE00，CO 模块上线基本就是这几个程序打天下。

这些程序的共同特点是：需要把数据按标准格式组织成文件，文件的第一行通常是字段名或者字段描述，程序读文件的时候按固定位置取数。实际项目里，我建议优先在系统里跑一次标准的示例数据，确认字段顺序没问题再放大数据量，避免几十万条导完发现字段错位。

2.2 HR/PP/MM 常用 Direct Input

财务之外，HR 模块老版本有 RPU50B00 系列（比如导入人员主数据、考勤数据），但 HR 模块这十几年转向 HCM 后，标准 Direct Input 程序有的已经废弃，新的 HCM 导入主要靠 ILM 或中间件，这块不太建议新项目再依赖老的 Direct Input 程序。

PP 模块典型的 Direct Input 是工艺路线导入、物料 BOM 导入，程序 CC_BOM_* 相关。物料 BOM 也可以用 CSAP 函数组，但 Direct Input 程序能处理大批量文件，依然有存在价值。生产版本、工艺路线主数据在 ECC 里有一些旧的批导程序，不过使用频率远低于财务。

MM 模块比较特殊，物料主数据批量维护通常会优先用 LSMW 或者 BAPI BAPI_MATERIAL_SAVEDATA，标准的 Direct Input 程序比较少。MM 的采购信息记录、货源清单，官方文档里存在一些老的导入程序，但说实话，我这么多年很少在项目里见人用，大家更习惯用 LSMW 录 BDC 或者直接写 BAPI 来跑。

那怎么找到自己模块有没有 Direct Input 程序呢？最快的路径是去 SAP 的 Online Documentation 里搜 “Direct Input” + 模块名，或者进系统用 SE38 查以 RF*、R* 开头的报表，再结合事务码 SM30 查看视图里的导入定义。如果文档路径不熟悉，还有一个野路子：找项目的 ITS 或者实施模板，里面往往保留了历史项目的 Direct Input 程序清单，比官方文档更贴合实战。

2.3 Direct Input 数据格式与调用套路

Direct Input 程序虽然多，但调用套路基本一致。核心是三个要素：文件路径、批大小、会话队列。

文件路径。程序通常要求提供应用服务器上的物理路径，也就是 UNIX 或者 Windows 服务器上 SAP 实例能访问的目录，不是前端 PC 的文件路径。这坑很多人踩过：本地传了一个 Excel 到前端，然后程序报找不到文件，因为 SAP 程序读的是服务器路径。正确做法是先通过 CG3Z 传文件到服务器，再填服务器路径。当然，现在很多项目用 SFTP 或者云存储，那更省心，但读取逻辑是一样的。

批大小。Direct Input 程序一般支持定义“每次读取 N 条记录提交一次”，这个参数我建议按几千条一批来设，不要一次性全提交。批太大容易造成 DB 锁、表空间压力、回滚段暴涨；批太小性能又差。实测下来批大小在 2000 到 5000 之间比较稳，如果数据量特别大，可以配合排队作业分批运行。

会话队列。这是 Direct Input 的杀手锏，程序支持把文件数据按批次拆成多个后台作业，每个作业处理一个片段，多作业并行也能通过配置实现。这样百万条数据可以拆成几十个作业，在 SAP 的作业调度里并行跑，整体耗时能压缩到一个可接受的范围。

我用 RFBIBU00 导过 40 万条会计凭证，就把文件拆成 10 个片段，每个片段 4 万条，批大小 2000，后台并行跑了大概 3 小时左右，导入日志里只有零星几笔因为科目未建导致的报错，处理效率远超 BDC。这也再次说明了 Direct Input 在大批量导入里的价值。

3. BDC 批输入程序方法论与标准工具清单

3.1 BDC 是什么、为什么还要用

很多开发说 BDC 是个老古董，现在有 BAPI 和 OData 了，不学 BDC 也没关系。这话只对了一半。BAPI 虽好，但不是每个业务对象都有 BAPI，也不是每个 BAPI 都实现了完整的业务校验。很多事务码至今没有对应的 BAPI，比如某些自定义的 Z 事务、某些老的 HR 界面、某些后勤模块的混合流程，以及很多依赖屏幕变式、需要触发特定用户出口的场景。业务不给你搭界面，数据又不是一条两条，几百上千条要批量处理，这时候能用的仍然是 BDC。

另外，BDC 还有一个隐性价值：当你要自动执行某些人工重复操作、并希望保留完整的应用日志时，BDC 可以触发所有屏幕相关的验证和用户出口，行为和真实用户完全一致，这在某些审计要求严格的行业（比如制药、汽车）反而更重要。

所以我的观点是：BDC 不应该是你的首选，但你必须掌握这套方法论，因为你永远不知道下一个需求会不会逼你走进 SHDB 的录屏老路。

3.2 标准程序、表和函数模块清单

BDC 相关的标准程序和对象，我常用到的整理如下：

• SHDB：BDC 录制器，可以在事务码里录制操作生成录制文件，用于分析屏幕字段结构。
• SM35：批输入会话处理界面，管理所有 Batch Input Session，支持处理、查看、删除会话。
• BDC* 系列程序：比如 BDCRECX1 用于处理错误文件，BDC_CHECK 等辅助程序。
• RSBDCSUB / RSBDCBTC_SUB：用于在后台批处理作业里处理批输入会话的标准程序。如果你生成了大量 Session，又想让它们在后台排对执行，就是通过这两个程序。
• BDC 相关的表：BDCDATA（屏幕字段数据结构）、BDCMSGCOLL（消息收集表）、BDC_OKCODE（功能码），这些在调试 BDC 程序时都绕不开。
• 函数模块组：BDC_OPEN_GROUP、BDC_INSERT、BDC_CLOSE_GROUP 是用来创建批输入会话的三件套函数模块；BAPI_BILLINGDOC_CREATEMULTIPLE 这种属于 BAPI 范畴，不算 BDC 核心，但实际工程里常常组合使用。

标准清单看起来不算长，但真正写 BDC 程序的开发基本也就用这些东西。这行当的核心能力不在于记住多少个函数模块，而是能读懂录屏生成的 BDC 数据、处理好屏幕字段变化、设计好错误的收集策略。这些套路下文展开说。

3.3 一个可复制的 BDC 代码骨架

直接给一段我在项目里反复用的 BDC 代码框架，用 Call Transaction 版本，能直接跑：

abap复制DATA: lt_bdcdata TYPE TABLE OF bdcdata,
      ls_bdcdata LIKE LINE OF lt_bdcdata,
      lt_msg     TYPE TABLE OF bdcmsgcoll,
      ls_msg     LIKE LINE OF lt_msg,
      lv_mode    TYPE c VALUE 'N'.

* 清空消息收集
REFRESH lt_msg.

* 填第一个屏幕
CLEAR ls_bdcdata.
ls_bdcdata-program  = 'SAPMF05A'.
ls_bdcdata-dynpro   = '0100'.
ls_bdcdata-dynbegin = 'X'.
APPEND ls_bdcdata TO lt_bdcdata.

* 填字段值
CLEAR ls_bdcdata.
ls_bdcdata-fnam = 'BKPF-BUKRS'.
ls_bdcdata-fval = '1000'.
APPEND ls_bdcdata TO lt_bdcdata.

CLEAR ls_bdcdata.
ls_bdcdata-fnam = 'BKPF-BLDAT'.
ls_bdcdata-fval = '20240101'.
APPEND ls_bdcdata TO lt_bdcdata.

CLEAR ls_bdcdata.
ls_bdcdata-fnam = 'BDC_OKCODE'.
ls_bdcdata-fval = '=GO'.
APPEND ls_bdcdata TO lt_bdcdata.

* 执行事务
CALL TRANSACTION 'FB50'
  USING lt_bdcdata
  MODE   lv_mode
  UPDATE 'S'
  MESSAGES INTO lt_msg.

* 解析消息
LOOP AT lt_msg INTO ls_msg.
  MESSAGE ID ls_msg-msgid TYPE ls_msg-msgtyp NUMBER ls_msg-msgnr
    WITH ls_msg-msgv1 ls_msg-msgv2 ls_msg-msgv3 ls_msg-msgv4
    INTO DATA(lv_text).
  WRITE: / ls_msg-msgtyp, lv_text.
ENDLOOP.

这个骨架有几个关键点说明一下：

MODE 'N' 表示不回显，批处理模式跑得快；如果你想看到某个问题，可以临时改成 'A' 回显模式。
UPDATE 'S' 表示同步更新，即事务逻辑立即写入数据库。这个模式对凭证类业务尤其重要，有些业务必须用 'S' 才能保证后续读取到最新数据。
MESSAGES INTO lt_msg 收集所有消息，但注意这里收集的并不一定是完整的屏幕报错，有些应用服务器端的消息在事务内部就被吞掉了，所以还要结合事务日志来看。
BDC_OKCODE 是功能码，通过它才能触发屏幕上的按钮动作，比如保存、退格、回车。这些功能码在录屏时就能抓到，也是 BDC 调试时最先排查的对象。

4. BDC 实战套路与性能优化

4.1 录屏方式的选择

BDC 开发第一步是知道屏幕上要填哪些字段、按哪些按钮，这就离不开录屏。录屏工具有两套思路：

事务码 SHDB 录制。这是最经典的方式，录制时会生成一个录制名，存下每一步的 program、dynpro、字段名和值。录制结果可以导出成一个 ABAP 程序骨架，开发基于这个骨架修改数据源、循环跑数据。优点是字段名绝对准确，不会因为手写 BDC 表而出错，缺点是录屏步骤里会把所有中间值也录进去，有时候录到一个下拉框字段，还会录出几个隐藏字段，生成的数据表会很长，需要人工精简。

事务码 SM35 的“创建会话”功能也能录屏，但它录的是完整会话的 BDC 数据，偏向于直接生成会话而不是生成 ABAP 代码，路径稍绕。我的习惯是优先用 SHDB 录屏，因为它能直接生成骨架代码，省去自己手写 bdcdata 表的时间。

还有一条路：不录屏，直接根据系统里已有的程序名称和屏幕号分析 dynpro 结构。这种方法适合熟悉 ABAP 的开发，可以通过 SE93 查事务码对应的程序、用 SM30 维护屏幕，直接往 bdcdata 表里填字段。实验风险高，不推荐新人用，但当你手里没有录制权限或者录屏环境有问题时，这可是救急方案。

4.2 会话模式和调用事务模式怎么选

BDC 有两种执行方式，Call Transaction 和 Batch Input Session。这两种方式不是等价的，选错场景就是给自己挖坑。

Call Transaction 是最常用的，因为它每笔数据独立执行事务、独立提交、独立返回消息，错误的数据不会影响正确的数据。这样做的好处是可以实时根据返回消息决定下一步动作，比如某笔数据报错，你可以立即把错误记录到日志表里，继续处理下一笔。适合数据量中等（几百到几万笔）、对实时反馈有需求、需要混合使用 BAPI 和 BDC 的场景。

Batch Input Session 的机制是先把 BDC 数据收集进一个会话，再用 SM35 或者后台作业批处理这些会话。优点是同一批数据作为一个整体进行逻辑处理，系统会按照录屏时的会话边界自动处理提交，适合数据量巨大（几十万笔往上）、不需要实时反馈、可以异步处理的场景。缺点是错误定位难、Session 卡死时不好干预、大批量处理时会话表会膨胀，而且如果中间业务代码有修改，历史会话会比较敏感。

我的经验数据线是：单批超过 5 万笔、又不需要逐单反馈结果的，就用 Session；低于这个量，尤其是有实时业务判断需求时，一律 Call Transaction。针对 Session 模式，还可以用 BDC_OPEN_GROUP、BDC_INSERT、BDC_CLOSE_GROUP 创建会话后，用后台作业把会话批量提交，这里有一个小技巧：创建会话时建议按业务分组，比如日期 + 数据源，一个组一个会话，这样处理失败时定位更快。

4.3 大数据量性能调优实测

BDC 的性能瓶颈主要是数据库写操作、应用层校验、以及 BDC 数据表本身的存储空间。这里分享几个亲测有效的优化手段：

串行处理优化为并行。如果数据之间有天然的分区（比如按公司代码、按工厂、按业务类型），可以拆成多个作业并行跑，但要注意别把同一张表的锁争用弄太高。我做过一次物料主数据扩展，8 万条数据拆成 4 个后台作业并行，从 50 分钟压到 18 分钟，效果立竿见影。

减少不必要的 BDC 字段。录屏生成的 bdcdata 表里常有大量字段、甚至是隐藏字段，这些字段在真正执行时可能根本不影响结果。精简掉不传的字段，能减少屏幕字段同步的 CPU 开销，数据量大的时候差异很明显。我习惯在录屏后删掉所有没改过值的字段，只保留必填和关键业务字段。

合理设置批内模式。Call Transaction 的 MODE 'N' 是默认不回显，但 'E' 表示错误时才回显，如果你希望错误的时候看到现场，可以用 'E'，但性能会略降；如果你追求最大性能，优先 'N'，错误排查靠消息日志记录定位。Session 处理时则可以在 SM35 里选择“前台、仅错误、后台”，后台处理性能最高。

关注 commit 频率。Call Transaction 是隐含每笔提交的，Session 是默认按录屏会话边界提交。如果你用自己写循环调 BAPI + BDC 的混合模式，注意不要自己包一个大的 COMMIT，导致大量数据长时间占用数据库锁。

5. 高频报错与避坑指南

5.1 最容易踩的坑 Top 10

BDC 程序写多了，踩坑踩到麻木。我把高频问题整理成下面的速查表，每一条都是实际项目经验，值得收藏：

表格里第 3 条值得展开说说，因为很多人不理解为啥要“传空字段”。很多屏幕上有选择框、单选按钮，如果该字段在前置情况下是必填，但你没传任何值，界面逻辑可能会认为它是空的并触发校验；反过来，你传了一个空字符串，它会被当作一个有效默认值进入逻辑，反而能绕过某些参数检查。这属于细节磨出来的经验。

5.2 错误日志定位技巧

BDC 程序本身不会告诉你哪笔数据错在哪，需要靠消息日志来定位。标准做法是：

每次 Call Transaction 时把 bdcmsgcoll 的结果采集进来，解析消息 ID、类型、编号，拼出可读文本。然后把消息文本连同你要传输的业务主键（比如凭证号、物料号、订单号）一起写到自建日志表里。这里的关键点在于日志表要包含一个唯一的业务主键字段，方便事后按主键检索错误原因，很多团队的日志表只留了消息文本，结果报错几百条，根本分不清是哪笔数据。

对于 Batch Input Session，错误信息存放在会话的错误文件中，处理完会话后要到 SM35 的会话日志里查看。这里同样建议在建会话时把业务主键放在一个明文字段里，比如利用 BDC 数据中的某个备注字段（前提是业务字段里有个可传的文本字段），这样查日志时一眼就能定位。

还有一个我个人的操作习惯：批量数据导入前，先取 5 到 10 条样本数据跑一遍 Call Transaction，检查消息类型。不是看有没有报错，而是看有没有 E 类型错误、W 类型警告。有些数据虽然成功了，但警告可能说明字段值不规范，后续会造成潜在的问题。这一步只要几分钟，却能省掉后面大量清数据的时间。

5.3 双界双码、日期格式等细节禁忌

细节决定成败，BDC 这一类最考细节。以下几个点我认为必须强调：

第一，双界问题。跨公司代码导凭证时，公司代码本身有国家字段，不同国家的日期格式、编号范围可能不同。如果你用一套 BDC 数据导所有公司代码，很可能一个公司跑得通，另一个公司却在日期或编号范围上报错。这时候要按公司代码分组执行，不能一把梭。

第二，双码问题：不少事务的屏幕上有两个功能码按钮，比如“保存并继续”和“保存并退出”。录屏时务必确认录到的正确功能码。我见过因为按错按钮，导致数据循环到保存后没有退场，卡在下一屏的情况，这种问题在 Call Transaction 里不会报错，但会话会越积越大。

第三，日期格式。很多项目在中国区使用 YYYYMMDD，但系统的用户参数里可能设置成 YYYY.MM.DD 或 DD.MM.YYYY，如果 BDC 里直接传 20240101，在一些屏幕上会被解析成 2024 年 01 月 01 日，但在另一些屏幕可能识别不了。稳妥做法是直接用系统内部格式转好，或者在传输前通过函数 CONVERT_DATE_TO_INTERNAL 统一转换。

第四，业务场景中的 SAP 请求编号。如果你每次修改后台配置后要传输请求号（TR），注意 BDC 本身不涉及传输管理，但如果你的 BDC 程序是新建的表或程序，需要在开发系统建好后把请求号传入测试系统，否则内容不完整，导致报错。这块常被开发忽略，却能被 Basis 团队吐槽很久。

第五，涉及采购订单发邮件这种跨系统场景，BDC 触发后台协议时日志不完整，容易让人误以为没执行成功。遇到这种最好通过增强点写日志，不能只看 BDC 返回消息。

6. 决策速查与建议

6.1 一张表带你做技术选型

说到这，我直接把选型逻辑总结成一张决策速查表，大家在项目里可以直接对号入座：

这张表不能覆盖所有场景，但思路是对的：优先标准 Direct Input，其次 BAPI，再回到 BDC。生产、物料、销售模块的扩展需求多，用 BAPI 时注意：BAPI 不一定包含所有增强点，有些业务字段在 BAPI 的参数里没有，就需要附加一个 BDC 补充屏幕，这个组合打法在复杂业务里很常见。

6.2 后续扩展方向

如果你看完这篇文章，觉得 BDC 这个领域想再深入，我建议按这几个方向继续往下走：

第一，掌握 BDC 与 BAPI 的混合调用框架。比如销售订单用 BAPI 创建主体，再用 BDC 调用自定义增强屏幕，这种组合能力在大型项目里特别吃香。

第二，研究 LSMW 的录屏转 BDC。LSMW 本质也是基于 BDC 录屏，但 LSMW 有更友好的字段映射界面。学会把 LSMW 的录屏映射逻辑反向导成 ABAP BDC 代码，等于多了一套快速出活的工具。

第三，注意新一代数据迁移工具的冲击。SAP 的 Migration Cockpit（迁移驾驶舱）和 S/4HANA 里的数据迁移方案已经能覆盖很多标准场景，但定制化需求仍然回到 BDC 老路。所以新工具可以学，底层的数据传输原理还不就是那些。

最后，凡是大批量导数据，请务必把所有操作写成可重复执行的程序，并设计好断点续跑。真实项目里第一次导入几乎不可能一次成功，出错、修复、重跑是常态。程序里带一个“部分成功跳过”的逻辑，比任何优化都省时间。

这篇文章是我在多个项目里跟 Direct Input、BDC、BAPI 反复打交道后总结出来的一套打法。没有炫技，全是实战逻辑。下次再遇到批输入需求，不要急着录屏，先翻一下这篇文章的决策清单，想想自己的数据量、业务复杂度和错误容忍度，再动工。磨刀不误砍柴工。