做SAP集成的朋友十有八九会遇到这个需求集团下面两个公司代码A公司向B公司下采购订单订单一保存B公司的销售订单还得手工再敲一遍。物料、数量、价格、交期一项一项输进去量少还好一旦每天几十张单子靠手工不仅慢还容易敲错。SAP里解决这类问题的标准姿势就是IDOC EDI。采购订单这边通过输出控制生成ORDERS类型的IDOC接收方拿到后自动创建销售订单整个过程不需要任何手工干预。这篇文章我会从业务场景讲起把出站、入站、主数据准备、常见报错排查全部过一遍。内容偏实战适合正在做EDI集成、SAP MM/SD顾问或者想了解IDOC原理的入门朋友。如果你只想看配置步骤可以直接跳到第二章但我建议先把第一章看完不然你不知道每一步配置到底在配给谁看的。1. 这个需求到底在解决什么问题1.1 一个典型的跨公司采购转销售场景先说业务场景。很多集团企业的组织架构是“销售公司 工厂公司”分离甚至还有贸易公司、物流公司夹在中间。销售公司跟最终客户签合同工厂公司负责生产和发货但两个主体在公司代码层面是独立核算的。于是销售公司得先向工厂公司下一张采购订单工厂公司再对着这张采购订单创建一张公司间销售订单后续的出入库、发票校验、往来对账全部围绕这两张单据展开。在没有集成接口的时候流程是销售公司在SAP里创建采购订单然后电话、邮件通知工厂公司“单子我下了单号多少”工厂公司财务或销售内勤再去ME21N或者VA01里手工开一张销售订单。一天几单还能忍受月底冲量的时候一压就是几十上百单漏单、错号、价格不一致的问题全冒出来了。我见过最夸张的一次销售公司一天下了47张采购订单工厂那边手敲销售订单敲到晚上十一点第二天对账发现库存转储单对不上返工了两天。所以这块集成的核心价值就一句话把采购订单的数据不经过人工转录直接变成销售订单。IDOC是SAP的数据载体EDI是传输和报文标准的名头两者合在一起就是这个“自动转录”动作的幕后引擎。1.2 为什么标准方案是IDOC而不是直接调BAPI有人会问SAP里面创建销售订单可以直接调BAPI_SALESORDER_CREATEFROMDAT2在采购订单保存的增强点里写一段代码直接调用不就行了为什么非要绕一圈用IDOC这里有几个现实原因。第一解耦。采购订单和销售订单往往不在同一个系统里。销售公司在系统A工厂公司在系统B两个系统之间不能直接通过RFC互相调用BAPI的场景非常常见。就算在同一个SAP系统里两个公司代码之间用IDOC也更干净因为发出去的是一份标准报文接收端可以是一个系统也可以是中间件再转给第三方。第二可追踪、可重试。IDOC天然带状态管理从创建、发出、到达、处理成功、处理失败每一步都有状态记录。业务跑了三天你说订单没到我打开WE02一查就知道IDOC停在哪一步、报什么错。BAPI直调没这套机制失败了只能翻应用日志处理起来非常被动。第三标准化的报文格式。采购订单转销售订单这件事在SAP标准里已经有成熟的消息类型ORDERS字段映射关系也都是现成的不需要从零开发数据结构。只要按照标准配置走后续维护成本很低。当然IDOC也不是万能药。它的处理是异步的采购订单保存成功后IDOC可能要过几秒甚至几分钟才跑到销售端。业务如果要求实时同步、销售订单必须马上可查那就要评估IDOC是否满足时效要求或者考虑在增强中触发同步处理。但从我接触的项目来看公司间采购转销售这个场景对几秒钟的延迟基本无感IDOC完全够用。1.3 整条链路往返一次数据怎么走把整条数据流先理一遍后面配起参数来才不会迷糊。以同一套SAP系统中两个公司代码为例整条链路是这样的销售公司登录系统创建采购订单ME21N保存时系统的输出控制Output Determination根据条件记录判断需要发送EDI消息于是生成一条输出记录。后台程序RSNASTED定期扫描输出记录把采购订单的数据整理成ORDERS报文写入IDOC的数据库表同时生成一个出站IDOC号码。接着IDOC通过端口合作伙伴配置找到接收方逻辑系统如果是同一套系统IDOC相当于“内部投递”直接进入入站处理队列如果对接外部中间件则通过tRFC或文件方式传输出去。接收方收到IDOC后根据合作伙伴参数里配置的入站功能模块调用BAPI_IDOC_INPUT1解析报文中的订单头、行项目、合作伙伴、数量、价格、日期等信息自动调用创建销售订单的BAPI最终生成一张销售订单VA03可查。这个过程中任何一步出错IDOC状态都会停在某个值不会静默消失。这就是我为什么一直强调做IDOC集成一定要把状态监控做起来。2. 动手配置前必须打好的四个地基2.1 逻辑系统给系统起个唯一ID逻辑系统是整个IDOC链路里的“发件人地址”和“收件人地址”。SAP靠逻辑系统来区分消息从哪来、要到哪去所以每个参与集成的系统或者客户端都要有一个逻辑系统名称。配置路径是事务代码BD54创建逻辑系统命名规范一般建议用三位系统ID加CLNT比如SAPCLNT100、SANCLNT200这种。我这里强调一下逻辑系统名称一旦被IDOC使用之后最好不要随便改改了之后所有已发送的历史IDOC控制记录里的逻辑系统名就和新配置对不上了排查问题时会非常绕。创建完逻辑系统后还要用事务代码SCC4把客户端和逻辑系统关联起来这样系统才知道“我当前这个客户端叫哪个逻辑系统”。很多项目在这步容易漏客户端没分配逻辑系统后面配置伙伴参数时保存就会报错或者IDOC发不出去。2.2 RFC端口IDOC进出的“收发室”端口决定了IDOC通过什么方式进出系统。事务代码WE21在“端口”下面定义类型。日常项目里最常见的是“Transactional RFC”端口也就是tRFC端口适合SAP系统之间或者SAP与中间件平台SAP PI/PO、MuleSoft、DataHub等之间直连传输。创建tRFC端口时RFC目标必须是已经用SM59定义好的目标里面填接收方系统的主机、实例号、登录凭据。如果对方不是SAP系统不会直接认RFC那么更常见的做法是使用“File”端口让IDOC以文件形式落地由中间件扫走再转换发送给外部系统。文件端口需要维护文件名模板和路径这个根据中间件的要求来没有统一的强制标准。端口不是随便建一个就行它必须和合作伙伴参数里引用的端口保持一致。实际项目里经常出现两个团队各建各的端口名字差一个字母结果IDOC卡了半天的乌龙局。建议端口命名也和系统名挂钩比如端口名SAPLS001一眼能看出是发给哪个逻辑系统的。2.3 合作伙伴参数对方到底是谁这是IDOC配置最核心的地方。事务代码WE20维护“合作伙伴参数”。对逻辑系统伙伴伙伴类型选LS伙伴号填接收方的逻辑系统名称。比如销售公司逻辑系统是SAPCLNT100工厂公司是SAPCLNT200那么在销售公司一侧配置出站参数给SAPCLNT200。出站参数里要维护三样东西消息类型Message Type为ORDERSIDOC基本类型通常选ORDERS05端口选刚才建好的RFC或文件端口。这套参数的意思是当销售公司有一条ORDERS消息要发给SAPCLNT200时系统用ORDERS05这种报文格式通过指定端口发出去。入站参数同样在WE20里维护但侧重点不同。入站参数要给每个消息类型指定处理方式。对工厂公司来说收到ORDERS消息后要能创建销售订单所以入站参数里过程代码Process Code通常是ORDERS处理功能模块Processing Function Module分配为BAPI_IDOC_INPUT1或BAPI_IDOC_INPUT2具体选哪个我在第四章细说。这里有一个细节容易被忽略合作伙伴参数既可以配逻辑系统也可以配客户。如果对接的是外部EDI平台平台侧没有SAP逻辑系统那么可以在销售公司一侧用客户类型伙伴把外部EDI平台当成一个“客户”来配置出站参数这在SAP EDI场景里非常常见。但公司间采购转销售通常双方都是SAP系统逻辑系统方案更通用、更好维护。2.4 输出控制采购订单凭什么触发出站很多人配完WE20之后兴奋地去ME21N创建采购订单结果发现IDOC根本没生成问题多半出在输出控制上。SAP不会因为WE20配了发送方参数就自动发IDOC还必须让采购订单在保存时“想”起来要发一条EDI消息。输出控制用事务代码NACE配置。在NACE的“采购”应用里找到输出类型NEUNEU是采购订单的标准输出类型。双击进入后在“处理例程”或“处理程序”区域把EDI过程的程序设置为RSNASTED并把EDI过程标志激活。RSNASTED是SAP标准程序负责把NAST输出记录转成IDOC这一步是整个出站链路从“输出记录”到“IDOC”的转折点。此外输出类型的触发条件也很重要。采购订单创建后系统会根据访问顺序和条件记录判断是否生成消息记录。条件记录可以基于供应商、采购组织、采购组、订单类型等维度组合。项目上最省事的做法是给关键供应商/采购组织建好条件记录保证相关采购订单保存时自动生成NEU输出。如果条件记录没维护采购订单的消息页签下就是空的更谈不上发送EDI了。3. 出站实操采购订单到IDOC这一步怎么落地3.1 用ME21N创建采购订单并检查输出配置全部做完先在测试系统跑一遍全流程。事务代码ME21N输入供应商、采购组织、工厂、物料、数量、交期保存。保存后进入菜单“采购订单 - 消息”查看输出列表。正常情况下能看到一条NEU消息状态是“正在处理”或者“已发送”取决于处理是同步还是后台异步。如果消息状态的“输出时间”和“EDI发送状态”是空的说明后台程序还没跑。可以在WE20里检查出站参数有没有激活然后到SE38运行程序RSNASTED或者直接在当前客户端执行事务代码BD20EDI控制相关操作来触发。生产环境一般会设置后台作业定时运行RSNASTED比如每1到5分钟跑一次。项目初期调试时建议手动运行方便看实时效果。等到输出状态变成已发送就可以去WE02查IDOC了。如果采购订单保存后连消息记录都没有先回NACE看NEU的条件记录是否覆盖了这单采购再检查供应商主数据的采购视图里有没有设置“采购订单消息”的相关字段。记住出站是输出控制先触发IDOC是输出控制的下游产物。3.2 用WE02看一张完整的IDOC长什么样WE02是IDOC查询和监控最常用的事务代码。输入IDOC号码或者按照创建日期、消息类型、状态查询双击就能进入一张IDOC的完整结构。界面上半部分是控制记录对应表EDIDC里面最关键的几个字段IDOC编号DOCNUM、IDOC类型IDOCTYP、消息类型MESTYP、发送方逻辑系统SNDPRN、接收方逻辑系统RCVPRN、当前状态STATUS。调IDOC时第一步永远是看这几个字段确认报文类型和收发方对不对再往下看具体数据段。下半部分是数据记录对应表EDID4。标准ORDERS05的IDOC数据段由多个E1开头的段组成比如E1EDK01、E1EDK02、E1EDK03、E1EDKA1、E1EDP01、E1EDP19、E1EDP20等。展开后能看到采购订单号、订单类型、合作伙伴编号、物料号、数量、单位、日期、价格等所有关键业务字段。在这个界面里我强烈建议养成一个习惯任何一张IDOC打开之后先把控制记录收发方、消息类型、基本类型、状态这四要素截图再看数据段。发给别人排查问题时这四要素是第一条信息可以减少大量来回沟通。3.3 IDOC核心段位与采购订单字段映射把常用段的映射关系捋一下方便你遇到字段对不上的时候知道去哪找。ORDERS05的段很多但公司间采购转销售最常用的是这几个E1EDK01是订单头段记录订单类型、公司代码、采购组织等信息。E1EDK02是参考数据段很多项目把采购订单号放在这里。E1EDK03是日期段包含订单日期、交期等信息用限定符QUALF区分不同的日期类型。E1EDKA1是合作伙伴段伙伴功能、伙伴编号都在这里入站创建销售订单时主要靠它确定售达方、送达方、付款方等。行项目层面E1EDP01是项目头数据物料号、物料描述等基础信息在这里。E1EDP20是数量与单位订单数量、基本单位、销售单位都在这个段里。E1EDP02是价格和条件数据订单行价格条件就放在这里。E1EDP03是项目日期交期、发货日期等。字段映射不需要死记硬背业务上最重要的是三个点谁是售达方E1EDKA1里伙伴功能AG、什么物料E1EDP01里MATNR、多少数量什么价E1EDP20和E1EDP02。入站创建销售订单出问题时九成以上是这三个点对应的数据在主数据里“对不上号”。如果标准IDOC段不能满足字段传输需求比如想传一个自定义的参考号、备注字段标准做法是增强IDOC段或者在E1EDK02/E1EDP02这种可以扩容的段里加字段。这需要写ABAP增强我后面在入站增强部分一起说。4. 入站实操IDOC到销售订单这一步怎么落地4.1 入站处理程序BAPI_IDOC_INPUT1做了什么当工厂公司这边收到ORDERS类型的IDOC后WE20里配置的入站功能模块就开始工作了。BAPI_IDOC_INPUT1是处理ORDERS创建销售订单的标准函数模块它是“消费者”内部把IDOC的数据段读取出来转换成销售订单BAPI需要的数据结构再调用BAPI_SALESORDER_CREATEFROMDAT2来创建销售订单。这个FM有个特点它要求IDOC里的业务数据必须完整尤其是合作伙伴功能、物料、数量、价格这些关键信息一个都不能少。否则IDOC会直接报错停在68或51状态而不会创建一个残缺的销售订单。BAPI_IDOC_INPUT2和BAPI_IDOC_INPUT1功能类似但处理逻辑上有些差异。有些项目里对于ORDERS消息类型会使用BAPI_IDOC_INPUT2来兼容更复杂的IDOC结构或自定义处理逻辑。选择哪个取决于系统版本和项目增强情况。若系统标准建议是BAPI_IDOC_INPUT1那优先用它因为它的逻辑被验证最多出问题你还能在SAP社区找到大量案例。BAPI_IDOC_INPUT2也不是不能用但它不属于标准ORDERS入站的默认配置遇到问题排查资料少一些。4.2 创建销售订单必须满足的数据前提入站FM不会魔法般地凭空创建销售订单它依赖一堆SAP主数据和定制配置。最基本的几条售达方客户必须存在并且有对应的销售范围数据销售组织、分销渠道、部门。在跨公司内部订单场景这个客户通常是内部客户客户编号在IDOC的合作伙伴段里已经写好。客户主数据没有扩展销售视图或者按照IDOC里传来的销售范围找不到数据系统就会报“账户确定错误”之类的问题。物料主数据必须维护销售视图以及对应的销售组织数据。如果物料在工厂公司下没有销售视图或者物料状态不允许销售行项目创建就会失败。销售订单类型、行项目类别、计划行类别要能由IDOC里的数据推导出来。公司间订单一般会使用专用的订单类型比如OR它的行项目类别和计划行类别直接影响交货和开票逻辑。定价方面公司间销售订单往往有独立的一套定价过程比如使用公司间价格条件。采购订单上的价格如果想原样带到销售订单需要在IDOC映射上处理好价格条件类型。这里我想强调主数据的就绪度直接决定入站IDOC的成功率。项目上线前务必做一个主数据检查清单把涉及内部客户的销售视图、物料销售视图、定价条件全部扫一遍别等IDOC压进来再一个一个补。4.3 项目中真正要做的几个增强点标准功能虽然能跑通但真实项目基本都要做增强。最常见的几个点销售范围的确定。IDOC的合作伙伴段里通常只有客户编号但客户在多个销售组织下都存在系统怎么知道在哪创建销售订单一种做法是让IDOC在传输前就带上销售组织/分销渠道另一种做法是增强通过公司代码、工厂等字段反查对应的销售范围。后者更常见因为工厂公司往往只有一个主销售组织映射逻辑固定。销售订单类型的确定。同理IDOC里的订单类型比如标准采购订单NB和销售订单类型OR不是一一对应关系。很多项目直接在IDOC段的映射逻辑里写死收到采购订单类型就创建公司间销售订单类型OR。没有写死的话系统可能取默认值或者报错说订单类型无效这一点要看IDOC入站配置里的流程代码和数据段传递情况。价格和日期的修正。采购订单上的单价可能包含采购价到了销售订单这边要不要原样保留、要不要做价格条件类型转换都需要在入站FM前后做数据处理。日期方面采购订单上的交期和销售订单的请求交货日期并不总是同一个日期有偏移比如提前两天发货需求时也要在增强里调整。标准增强点一般是复制BAPI_IDOC_INPUT1到自定义FM或者在IDOC入站处理过程中写增强隐式增强、BADI根据项目习惯来。我个人更推荐保留标准入站FM不动用隐式增强或者后处理程序来做二次修正这样可持续升级性更好。4.4 入站失败重处理RBDMANIN和WE19IDOC入站失败是常态关键是失败后怎么快速恢复。如果只是主数据临时缺失比如物料销售视图没来得及扩展等主数据补好了之后通常用SE38运行程序RBDMANINIDOC入站处理重新处理失败IDOC。RBDMANIN是标准重处理程序按IDOC号码或状态批量重新触发入站处理。它会把IDOC再次交给入站功能模块执行一遍。运行前千万要注意一定要先看清失败的阶段。如果IDOC已经成功创建了销售订单只是回执或后续处理失败贸然重跑会创建出重复销售订单。WE19也有类似功能但它更偏向于单张IDOC的测试和维护可以修改数据段再重新入站。WE19在调试阶段特别好用比如采购订单传过来的物料号在工厂公司这边不一致可以在WE19里手动改掉IDOC段的物料号再重跑验证是否正确。重处理的正确姿势是先复制IDOC或者把原始IDOC号码记录下来再修改数据段再重处理最后核对销售订单是否重复。我见过不止一次因为重处理没看状态一张销售订单被创建了两遍后续交发货和开票全部串掉。5. 日常运维最常踩的坑与排查实录5.1 出站没生成IDOC十有八九是这三处出站IDOC不生成项目上线后生产群里问得最多的就是这个问题。归纳下来十有八九出在这三处。第一WE20出站参数没配或者没激活。伙伴类型、伙伴号、消息类型、端口、基本类型五样东西缺一不可。如果某个字段为空系统可能在保存采购订单时静默跳过EDI处理。第二NACE输出控制的条件记录没有覆盖当前采购订单。常见于新供应商上线采购订单消息页签里完全没有记录自然没有IDOC。这种问题去查供应商主数据采购视图和消息条件记录一般十分钟能定位。第三后台作业RSNASTED没跑。这个更隐蔽因为消息记录状态看起来是“等待处理”或者根本没刷新。生产环境的RSNASTED作业最好固定成高频运行并设置失败告警否则一旦作业挂了IDOC全部积压业务侧毫无感知直到对方打电话来催单。5.2 入站报错先看物料和客户主数据入站IDOC报错九成的根因都在主数据而不是程序。收到状态68的IDOC先在数据的项目段看物料号去MM03查这个物料在公司代码下有没有销售视图、有没有扩展销售组织的数据。很多集团公司各公司代码沿用同一个物料编码体系但数据分发不完整工厂公司那边物料销售视图根本没建IDOC一到就挂。客户主数据同理。XA03看售达方确认销售范围是否存在。内部客户的公司间销售还有一个坑就是客户的“销售伙伴功能”可能要求设承运商、联系人等缺了伙伴功能账户确定失败销售订单也创建不出来。这类问题没有捷径只能逐张IDOC去对主数据。所以我很建议项目上线前做一个自动巡检报表定期扫物料和客户主数据的销售视图完整性把问题消灭在IDOC进来之前。5.3 单位、价格、数量对不上怎么办IDOC里传过来的数量和销售订单里的数量经常因为单位体系不一致而出现差异。比如采购订单里用的单位是“托”缩写PAL而工厂公司销售单位是“件”PC如果物料主数据里没有维护这两个单位的转换关系IDOC入站时数量换算就会报“单位换算失败”。解决办法不在IDOC上而在物料主数据上。MM02进入物料主数据的附加数据/单位页签维护好基本单位与销售单位、采购单位之间的换算因子。IDOC只负责传原始数量真正的单位换算由SAP主数据执行。价格不一致是另一个高频问题。采购订单的价格传到销售订单后如果销售订单有独立的定价过程可能覆盖掉IDOC里的价格最后变成“系统算出来的公司间价格”。遇到这种情况要么在IDOC的E1EDP02段上传条件价格并确保入站BAPI使用要么在增强里限制销售订单定价过程不重算公司间价格。5.4 用WE19重处理之前请先想清楚这几件事WE19改IDOC重处理是万能的兜底手段但也是最容易出生产事故的手段。重处理前我建议先问自己三个问题。第一这张IDOC之前有没有部分成功过比如IDOC头创建了销售订单只是行项目失败那么重处理时哪怕只改了数据段一个空格也可能导致整单重复创建。正确的做法是先到VA03查有没有已经存在的销售订单有的话不要重处理而是手工修复缺的行项目。第二你要修改的字段在哪个段改完之后会不会影响其他逻辑IDOC数据段之间有勾稽关系改了数量不改单位改了物料不改描述很可能重处理后新的错误又出现。第三重处理时是否影响后续回执很多项目在IDOC入站成功后会逆向发送一个ORDRSP回执IDOC给对方系统。如果你们在调重处理对方那边可能连续收到多条确认回执对账时又会乱一阵。所以重处理前最好和对方负责人提前打招呼。5.5 IDOC状态速查表下面这张表是我项目里常备的状态速查表遇到IDOC卡住先对照它判断下一步动作。状态阶段含义处理建议30出站IDOC已成功传递给端口发送完成等待对方系统处理若长时间无回执需查中间传输链路38出站EDI子系统已确认收到出站侧OK重点查对方入站64入站IDOC已传递给应用程序说明入站FM已经开始处理继续看下一步状态65入站应用程序处理成功销售订单已创建到VA03核对销售订单并确认回执是否发出68入站应用程序处理出错处理中/待重试查看IDOC数据段报错文本修复主数据后可考虑重处理51/53入站应用程序处理出错最终失败修复后用RBDMANIN或WE19重处理需防重复创建69入站应用程序处理未确认/出错先看是否重复创建单证再决定是否重处理状态值在不同SAP版本里略有差异但大方向是一致的。判断IDOC成不成功不能只看出站状态是30就认为对方收到了必须以对方系统回传的结果或者销售订单实际是否存在为准。最后再分享一个小技巧做了几年EDI项目我的体会是IDOC配置本身其实不难难点在运维习惯。生产环境一定要把IDOC监控纳入日常巡检每天定时看一遍有没有异常状态的IDOC尤其是51、68、69这三种。很多问题当天发现就是改一条主数据的事拖到月底对账才发现就是大工程。再分享一个我一直沿用的排查习惯每一张IDOC在处理之前先把控制记录里的收发方、消息类型、基本类型、状态四要素截图贴到问题记录里。等到后续排查时光凭这四个字段就能过滤掉一半以上的干扰信息。如果你正准备在公司内部试点这个方案建议先在测试系统完整跑通一个业务场景再逐步扩大范围。配置和主数据准备最好由同一个人或同一个团队统一管理避免两边各配一套参数最后连IDOC都互认不了。等技术链条稳定之后这套方案完全可以复用到你负责的其他集团客户上你甚至会开始嫌弃手工敲销售订单的日子回不去了。