企业官网建设流程全解析

去年接手一个集团内SAP整合项目，财务月结卡在公司间发票校验上，连续两个月的结账都因为这个环节被拖了两三天。发货公司开了公司间发票，收货公司的财务得照着纸质或邮件里的信息，去MIRO里手工录入发票校验，几十张凭证来回核对，稍不留神单价、数量就对不上。后来我们基于IDOC把这条链路彻底改成了自动发票校验，问题从根上解决了。这篇文章就把这个方案的落地过程完整写出来，包括业务链路、配置步骤、报错排查和增强思路，适合做MM/FICO的顾问、负责公司间流程的ITBP，以及想搞懂IDOC从发出到自动过账整个闭环的ABAP开发。

1. 公司间调拨为什么要做发票自动化，先看这条业务链

1.1 STO两步法和公司间发票的位置

公司间库存调拨，SAP里标准术语是STO（Stock Transport Order）。同一个集团下两个公司代码之间调货，最常见的方式是两步法：发货公司用移动类型303把库存转出，收货公司用移动类型305把库存收进来。这两步做完，存货和成本其实都还挂在发货公司账上，真正要让两个公司法人口径清账，必须靠一张公司间发票。

这张发票在业务上叫Intercompany Invoice，触发点在发货方。财务在VF01/VF02里基于发货过账做公司间开票，系统自动产生应收应付，发货公司挂应收（对关联客户），收货公司挂应付（对关联供应商）。注意这里有个很多人忽略的关键点：公司间开票和普通的销售开票不同，它没有销售订单，是基于内向交货单或装运单开的，税额计算方式也通常被设成无税或特定税码。

问题出在“开票”这个动作完成之后。发货方的账是清楚了，但收货方还没有入账。按SAP标准逻辑，收货方财务需要手工做一笔发票校验（MIRO），把这笔应付挂到供应商头上，同时对应到采购订单。公司间调拨的供应商发票和普通采购发票还有个区别：它的数量、金额都必须和发货方的发票严格一致，否则关联交易对账就会出现差异。

这条链路如果全靠财务两端人工同步，就会陷入一种持续救火的状态。

1.2 手工发票校验的四大痛点

我在多个项目里见过手工处理公司间发票的场面，问题基本集中在四个方面。

第一是数量差异难追。发货方按发货数量开票，收货方的采购订单收货数量可能因为收发货时间差、损耗、溢装短装而对不上。财务在MIRO里看到数量差异时，需要去查STO的整条链路，电话来回打，邮件来回发，一张票卡半天很正常。

第二是单价和金额不同步。公司间转移定价如果带汇率波动，发货方记账用的汇率和收货方记账汇率不同，手工录入时很容易按错汇率，导致应付金额对不上。更麻烦的是，公司间发票上的金额和采购订单金额有差异时，MIRO默认会有容差报错，收货方财务如果不清楚容差设置，就会被拦在保存这一步。

第三是重复录入和高错误率。给几十个关联供应商维护发票校验凭证，本身是纯粹的体力活。把发货方发票上的字段一条条抄进MIRO，日期、金额、税码、数量，任何一个字段错了，后续关联往来对账都做不平。

第四是月结效率被拖累。月结期间财务本来就在做应收应付重分类、外币评估、往来对账，公司间发票如果是月底集中开出来，收货方财务要在极短时间内完成校验入账，否则内部往来的未清项在集团合并层面就会产生差异。

这套手工流程跑久了，所有问题最后都会变成同一个诉求：发货方发票开出来之后，能不能让收货方系统自动把发票校验凭证做了？这就是标题里说的“IDOC完成自动发票校验”要解决的问题。

2. IDOC自动发票校验的方案选型与数据流设计

2.1 为什么选INVOIC IDOC而不是自开发接口或ERS

公司间发票自动化的技术路线其实有好几条，项目里评估下来最合适的还是标准INVOIC IDOC。

先说为什么不用自开发接口。自开发方案自由度最高，建一张自建表存发票数据，写RFC接口把数据推给收货方，再调用BAPI_INCOMINGINVOICE_CREATE生成发票校验凭证。但自开发接口要处理的东西很碎：报文格式、失败重传、幂等控制、日志监控，全得自己写。而且一旦集团里有其他SAP系统也要接入，每个系统都得定制一套，维护成本成倍上涨。

再说为什么不用ERS（Evaluated Receipt Settlement）。ERS是SAP里自动结算的经典功能，基于收货自动生成发票校验凭证，但它解决的是“按收货结算”的场景，金额逻辑是收货数量乘以采购订单价格。公司间调拨的发票金额由发货方决定，里面可能包含运费附加、价格重估、汇率差异，这些是ERS无法覆盖的。ERS用在这里，语义上就不对。

标准INVOIC IDOC正好卡在两者中间。它是SAP的通用电子发票报文，定义了完整的发票头、发票项、伙伴、税、货币等字段，发货方开票时通过输出控制自动生成IDOC，收货方收到后通过标准入站处理程序自动创建发票校验凭证。整个链路用的都是SAP标准机制，有状态管理，有错误处理，有BD87可以重新处理，没有自定义接口那种“看不到跑到哪儿了”的痛苦。

有一点必须说清楚：INVOIC IDOC方案能不能走通，很大程度取决于两端系统的版本和主数据规范程度。如果关联供应商、客户的主数据在某些系统里维护得乱七八糟，那么标准IDOC处理程序跑起来就会到处报错，项目里经常出现这种情况。

2.2 IDOC报文里到底装了什么

我们用的基本类型是INVOIC02，消息类型INVOIC。每次传过去的IDOC从业务角度看就是一张电子发票，关键数据段包括：

• E1EDK01：发票头数据，包含凭证类型、记账日期、过账日期，其中凭证类型和记账日期直接决定收货方生成的FI凭证长得什么样
• E1EDK02：参考数据，存放采购订单号、收货单号、发票号，收货方可以用这个段里的信息自动匹配到对应的采购订单
• E1EDK03：日期段，包含发票日期、基础日期、付款基准日期
• E1EDK05：货币段，包含币种和汇率，跨币种公司间交易靠它传递汇率信息
• E1EDKA1：伙伴段，包含收件人、发票方、供应商编号等
• E1EDP01：发票行项目，包含行项目号、物料编号、数量、单位、金额、税码
• E1EDP02：行项目参考，通常是采购订单行项目号

理解IDOC内容的关键在于：收货方入站程序不是“看”这些数据的，而是把E1EDK01、E1EDP01这些段的内容映射到发票校验凭证的字段上。所以哪一段数据缺失、哪个字段格式不对，都会直接导致IDOC处理失败或凭证生成错误。比如伙伴段里没有传供应商编号，入站程序就不知道这张发票该挂在哪个供应商头上，直接报错给拦下来是好事，最怕的是系统用了默认供应商，那账就悄悄错了。

2.3 全链路数据流转：从发货过账到收货方FI凭证

整个自动化的流程可以拆成七个节点：

1. 发货方对STO做发货过账（移动类型303）
2. 财务在VF01创建公司间发票，保存时系统运行输出确定
3. 输出确定找到EDI输出类型，调用IDOC出站处理程序，把发票数据打包成INVOIC02
4. IDOC通过端口（tRFC或文件方式）发送给收货方的SAP系统
5. 收货方端口接收到IDOC，写入入站IDOC表
6. 入站伙伴参数配置的处理程序被触发，解析INVOIC02各数据段
7. 处理程序调用标准逻辑或BAPI生成发票校验凭证，过账后产生供应商应付

其中第六步到第七步，就是标题里“自动发票校验”的动作发生点。系统不是简单地在后台记一条日志，而是真正执行了一笔MIRO，生成了凭证，供应商未清项、物料账、总账行项目全部更新。

实际项目里，发货方和收货方最常见的是同一个SAP环境里的两个公司代码，这样IDOC不经过外部中间件，走的还是系统内传递，但仍然完整保留IDOC的生命周期状态，便于监控。如果是跨SAP系统，只要配置了RFC目的地或者中间件发布订阅，同样能走通。

3. 发货方侧配置：让VF01开票后自动产生INVOIC IDOC

3.1 消息控制（NACE）与输出类型的坑

发货方侧的配置起点在NACE。用事务码NACE，选择应用“V3 出具发票”，把输出类型里跟公司间发票相关的那个找出来。标准系统里RD04通常对应公司间发票，但也有些项目用的是自定义输出类型。我们项目里直接用RD04，因为走EDI的时候标准类型支持得最好。

RD04的“处理程序”要维护成“EDI”或“EDI1”，这样保存发票时系统才会走IDOC生成逻辑而不是打印逻辑。这里有个特别容易踩的坑：输出确定跑不出来，最常见的原因是条件记录缺失。输出类型不是自动就带条件记录的，需要在NACE里维护输出确定条件，指定“销售组织 + 客户 + 输出类型”的组合。

有朋友会问，公司间开票没有销售订单，销售组织从哪来？答案是公司间开票参照的是交付单和装运单，销售组织、销售渠道、产品组这些信息从交付单里带过来。如果发货工厂对应的销售范围和客户主数据之间没有维护条件记录，那开票保存时会话静默，不报错，但就是没有IDOC产生。这种问题最难查，因为业务上发票开票成功了，但接收方什么都没收到。

我处理这种问题有一个固定的检查顺序：先看VF02输出日志（“抬头 -> 输出”），看RD04有没有命中；如果输出日志里根本看不到RD04，问题就在NACE条件记录；如果能看到RD04但IDOC没有生成，问题在WE20伙伴参数；如果IDOC生成了但状态错误，问题在出站处理程序或端口。这样一层层切分，定位很快。

3.2 端口和伙伴参数（WE21/WE20）到底怎么配

发货方出站配置涉及两个事务码：WE21定义端口，WE20定义伙伴参数。

端口用的是tRFC类型，事务码WE21里选择“事务性RFC”，创建端口，填入RFC目的地。这个RFC目的地可以是发货方系统自己的逻辑系统名，也可以是收货方系统的逻辑系统名，取决于IDOC是发给本系统还是远程系统。我们当时是同环境两个公司代码之间传，RFC目的地指向本系统逻辑系统名就行。

这里必须提醒一个细节：RFC目的地的“逻辑系统名”必须和SAP系统里分配的逻辑系统保持一致，否则IDOC发送时会报“合作伙伴没有维护”之类的错误。很多项目卡在IDOC发送不出去，查到最后都是逻辑系统名不匹配。

WE20的配置逻辑是这样的：伙伴类型选KU（客户），伙伴编号填收货方对应的关联客户编号。然后分配消息类型INVOIC，基本类型INVOIC02，出站处理程序填标准程序。保存后，这张客户在所有相关销售范围里的公司间开票，只要输出确定命中，就会自动打包发送IDOC。

出站这边容易出错的有两个地方。一是伙伴参数的客户编号和NACE条件记录里的客户编号不一致，导致条件命中了但伙伴参数找不到。二是消息类型和基本类型的组合没配对，比如配置里写的是INVOIC01但发货方系统只会产生INVOIC02，那么IDOC会以“缺少基本类型”报错。

3.3 实际触发验证：一张STO发票从VF02到IDOC命中的过程

配置做完之后一定要做一次端到端的验证，不要跳过。我们当时的测试方法是：

先用一张STO做发货过账，然后在VF02里开一张公司间发票，保存后马上用WE05查看IDOC列表。如果配置正确，这里会看到一条新的出站IDOC，消息类型INVOIC，基本类型INVOIC02，状态应该是30（已生成，等待发送）。

如果WE05里没有这条IDOC，回到VF02输出日志里看RD04是否命中，按上面说的顺序排查。如果IDOC状态是01或02开头，说明发送环节有问题，大部分是RFC端口配置不对。

这里有个实用的技巧：可以在VF02保存前，先在NACE里检查输出确定是否锁定。输出确定锁定会影响输出记录生成，但不会报错。项目里遇到过几次“开票一批、IDOC只出一半”的情况，最后全是输出确定锁定导致，解除锁定后重新保存就正常了。

4. 收货方侧配置：IDOC进来以后如何自动生成发票校验凭证

4.1 入站伙伴参数与处理程序

进入收货方侧（同一个系统里就是同一套环境，但配置对象不同），WE20里要新增一条入站伙伴参数。

这里的伙伴类型是LI（供应商），伙伴编号填发货方对应的关联供应商编号。分配消息类型INVOIC，基本类型INVOIC02，入站处理程序填标准程序。保存时系统会提示填写入站处理程序的函数模块，标准情况下用系统提供的IDOC_INVOIC即可。

入站处理程序的机制我想补充一句：它不是简单的“把IDOC变成凭证”，而是要经过数据校验、凭证类型映射、税额重算、差异容差判断这几个环节，任何一个环节失败，IDOC都会停在51/53状态而不是入账。这其实是个安全设计，宁可拦下来人工管，也不能让错误凭证悄悄过账。

关于凭证类型映射，收货方自动生成的发票校验凭证类型是由IDOC里的凭证类型加后台配置共同决定的。IDOC里传来的“凭证类型”字段只是参考，真正落到FI凭证的凭证类型则需要满足发票校验的配置。如果想控制自动生成的凭证类型，需要通过配置或增强指定，这个后面在增强部分细说。

4.2 自动过账的前置条件：科目、容差、供应商主数据

IDOC入站能走到最后一步自动过账，不是只要伙伴参数配好就够了，还有三个前置条件缺一不可。

第一个是供应商主数据。关联供应商在公司代码下层维护了统驭科目（通常是应付供应商），并且采购组织视图和公司代码视图都激活。很多项目里供应商主数据是从外围系统同步过来的，偶尔会出现公司代码视图缺失，IDOC处理时就会报“供应商不存在或已删除”。

第二个是自动记账规则。公司间发票过账涉及的科目，包括GR/IR、存货、差异科目、税科目，在OBYC和OKB9里都要有对应的配置。因为公司间调拨的发票可能会产生价格差异，如果差异科目没有配置，系统会报“科目确定错误”，IDOC同样会失败。

第三个是容差设置。事务码OMR6里配置发票校验的容差上限，包括金额差异、数量差异、比例差异。公司间交易和本地采购有个明显不同：两边系统记账有时间差，汇率变动会导致发票金额和采购订单金额之间存在差异。如果容差设置过严，IDOC入站就会在容差检查处失败。

针对这一点，建议在公司间交易这个特殊场景下，把“金额差异”的容差上限设得比本地采购略宽一些，同时开启“自动过账超过容差”的相关设置。设置不在所有项目都适用，但公司间调拨的关联交易对账通常靠长期未清项目管理，不需要在单笔凭证上卡得太死。

这里有一个配置顺序的问题：很多顾问习惯先配WE20，急着看IDOC能不能处理，结果忽略了容差和科目配置，导致IDOC连续失败。我更建议按“主数据 -> 科目配置 -> 容差 -> 伙伴参数”的顺序来做，这样每一项配置失误都能在它该出现的位置暴露出来。

4.3 验证自动发票校验成功的标准姿势

收方配置完成后，验证动作比发方更关键。用事务码WE02看IDOC状态，状态68表示已处理成功。这时候别急着关界面，要接着查财务凭证。

方法是用事务码FB03查看凭证。需要注意IDOC入站生成的凭证类型是发票校验凭证，在SAP里对应的事务是MIRO，但MIRO是处理界面，查看记录用FB03或者MIRO里的凭证列表都可以。关联IDOC和FI凭证的纽带是IDOC里的参考字段，在FI凭证的“原因代码”或“分配”字段里有体现，具体字段因系统配置而异，建议在测试阶段就确认清楚，方便以后对账。

验证要点包括：金额是否正确、税码是否正确、供应商未清项是否生成、采购订单历史是否有对应记录、行项目的物料数量是否正确。如果这些都通过了，这条自动化链路才算真正打通。

在正式上线前，我还习惯做一次“断链演练”：让发方开了一张大金额发票，收方先不处理IDOC，再手工在MIRO里录一笔相同的凭证，确认两边的供应商未清项不会冲突。这个在关联交易对账时非常有用，否则发票传了、财务又录了一遍，未清项就会翻倍。

5. 常见失败与排查链路：从WE02状态到BD87重处理

5.1 一眼读懂IDOC状态：53、64、68到底代表什么

写这一段之前我得先强调一件事：IDOC的监控状态是整个方案里最不能省的一环。负责公司间流程的顾问和ITBP，至少要能够一眼看懂WE02/WE05里那些数字号代表什么。

IDOC状态号含义对照表：

我们项目上线初期，70%以上的失败IDOC都停在53状态。BD87是可以重新处理的，但这里有个关键认知：重处理前必须搞清楚失败原因，否则就会陷入“重处理 -> 失败 -> 再重处理”的死循环。BD87只负责重新触发，它不改变逻辑，业务数据的问题没有修正前，重跑一万次也是失败一万次。

5.2 项目里真实踩过的错误清单与解决过程

这条自动发票校验链路在测试阶段暴露的问题非常多，挑几个有代表性的列出来，这些几乎每个项目都会遇到。

第一个，供应商公司代码视图缺失。现象是IDOC状态53，双击错误信息，一般是“供应商VENDOR123在公司代码XXXX中没有维护”。原因是供应商主数据在MDM里没有同步公司代码层视图。解决方案是补齐公司代码视图，再回到BD87重新处理。

第二个，税码不一致。发货方开票时用了税码J0（无税）或特定税码，但收货方的相关配置没有对应税码，入站重算税额时报错。这里要注意公司间发票在很多国家是零税或免税，但SAP里“零税”和“无税”在配置上是两种不同的处理，如果两端配置没对齐，IDOC一定会失败。解决方式是把两端税码配置对齐，或者在输出确定阶段就把税码控制在配置范围内。

第三个，金额差异容差超限。这主要用于关联公司使用不同本位币的场景。发方记账本位币是人民币，收方记账本位币是美元，IDOC里传过来的是人民币金额和汇率，收方换算成本位币后会和采购订单金额产生差额。如果OMR6容差设置过小，系统直接拦下。解决方式前面说了，放宽公司间场景的容差上限，或者让发方在开票时用收方系统希望的币种和汇率。

第四个，重复创建问题。IDOC重传后，如果第一笔凭证其实已经创建成功但IDOC状态没有更新，那么BD87重新处理会再建一笔重复凭证。这个防范要点是：拿IDOC里的参考发票号去FB03里用“分配”字段搜索，确认没有已有凭证再重处理。真出现了重复凭证，只能冲销多出的那张，没有更好的办法。

第五个，消息类型或基本类型没有维护完整。特别是收方在WE20里配了消息类型但基本类型没有分配，IDOC到达后会提示“消息类型/基本类型不明确”。这种问题在测试环境的出现率很高，配置时一定要把“消息类型 -> 基本类型”都维护好。

5.3 标准入站不够用的时候，增强写在哪个位置

标准IDOC入站处理能满足大部分公司间自动发票校验场景，但总会遇到一些定制需求。我们项目就遇到一个：应收应付凭证需要根据调拨方向自动填入不同的文本信息，而标准INVOIC入站没有提供这种逻辑的配置项。

常用的增强位置有两个。

第一个是出站增强。发货方在打包IDOC时，通过用户出口或BADI往IDOC的附加段里填入自定义信息。入站端再做对应的映射。这种方式适合“信息传递”类需求，比如把成本中心、WBS元素带过去。需要注意，往标准IDOC里塞自定义字段，一定要用增强段或者未被占用的标准段，不要破坏标准段结构，否则收方标准处理程序解析时会出问题。

第二个是入站增强。在收货方处理IDOC时，通过增强点修改最终生成的凭证内容。比如有些项目要在自动发票校验凭证里写入自定义参考号，或者根据公司代码切换凭证类型。入站增强通常动的是IDOC_INVOIC相关的函数模块或BADI，开发时需要注意消息类型不能搞混，否则会影响所有INVOIC入站。

增强文件做完，强烈建议用SAP ATC（ABAP Test Cockpit）做一次代码质量检查。IDOC入站增强的代码运行在后台异步处理中，如果代码里有性能问题或者未处理的异常，IDOC会停在64状态，很难定位。ATC至少能抓出一批明显的语法和安全性问题，省去后面很多排错时间。

从我个人经验看，增强方案不要走太深。能用标准功能解决的就尽量用标准功能，增强越深，升级影响越大。我们在项目里对入站增强做了一条硬性要求：必须在代码注释里保留完整的业务逻辑说明和配置依赖关系，防止后续顾问接手时看不懂、不敢动。

补充一个小技巧，上线后财务经常在FAGLL03里核对关联公司往来，但行项目里收付款对方名称显示不正确，让财务很困惑。这个问题往往不是IDOC配置错了，而是IDOC的伙伴段E1EDKA1里伙伴名称没传全，导致FI凭证中的文本字段被覆盖。处理方式是调整出站端伙伴段的内容填充逻辑，确保买方和卖方名称按期望写入。

整套方案上线后，公司间发票校验从每月的两三天人工核对，压缩到了系统自动完成，财务只需要每天花几分钟处理状态51/53的异常IDOC，关联交易对账也从此有了一个可靠的数据来源。你可以照着这个链路在自己的测试环境里搭一遍，第一张自动过账的凭证生成时，那种“终于不用抄发票了”的感觉，值得体验一次。