SAP公司间STO详解：复合凭证、一步法与两步法配置及避坑

简介：面向SAP MM顾问、集团财务与供应链实施人员的一份公司间交易专题PPT，聚焦同一集团下不同公司、不同工厂之间采购与调拨的业务设计与系统配置。内容从公司间交易概念切入，梳理工厂间UB转储（带交货单与不带交货单、一步法与两步法）、无参考库存调拨301/303+305、公司间采购STO、计划协议、跨公司销售与集中采购，并延伸到K-寄售、O-委外、Q-项目及服务类特殊采购场景，配合清算科目与借贷关系说明，便于建立从业务场景到操作配置的整体框架。压缩包共1个PPTX文件，约26.85MB，以图文幻灯片呈现流程、移动类型和配置要点，适合按主题查阅与内部培训。已有319人学习，可作为SAP公司间交易方案梳理、项目实施参考与知识查漏的辅助材料。

1. 公司间交易：为什么一张采购订单在供货方眼里是销售订单

做 SAP 公司间采购的人，几乎都被同一个现象绊过：采购员在 ME21N 里建的明明是一张采购订单，供货方的销售同事却能在 VL10B 里把它拣配发货，财务还能 VF01 开票。不是两张单，也不是接口同步，而是同一张凭证被同时赋予了两种业务身份。这正是公司间交易（Inter-company STO）最核心的设计——系统把集团内两个公司之间的物料转移，建模成“既买又卖”的复合凭证。搞懂这个复合体怎么拆单据流、怎么拆会计账，后面的一步法、两步法、647 还是 641、要不要建交货单，就全都不是玄学，而是一串可以推导出来的结论。

2. STO 的复合凭证结构：采购视角与销售视角怎么共存于一条行项目

一张跨公司 STO，抬头挂在采购方的采购组织上，落到的却是两个公司代码。采购方看到的是“我要买”，供货方看到的是“我要卖”，两种视角共享同一个 EBELN，却各自往下延伸出完全不同的凭证链。理解这一点，是理解后面所有分支的前提。

2.1 单据流：一张 STO 从创建到发票校验要跨几道门槛

把跨公司采购（带开票的那种）摊开，单据流大致是这样一条链条：

第 3 步和第 5 步的先后关系取决于后台配置：一种是供货方 DN 过账后，系统自动触发采购方工厂收货，走一步；另一种不触发，采购方需要自己拿采购订单或交货单做 MIGO 收货，走两步。这个分支在第 3 章会拆开讲。

关键在于“为什么非得有第 4 步”。集团内部往来必须两边同时入账：供货公司要确认收入与销项，采购公司要确认存货与进项，任何一边缺凭证，月末内部往来对冲就平不了。常见的实现思路是：在供应商主数据上挂一个对应的内部客户号，开票时自动带出这个内部客户，让应收应付在集团层面自然对冲。这也是为什么公司间 STO 的“供应商”往往不是真正的第三方，而是指向供货工厂的内部往来对象。

2.2 装运页签的开关：DlTp 决定这张单走不走交货

打开一张 STO 的行项目，有没有“装运”（Shipping）页签，是第一个分水岭。有它，就能建交货单、能拣配、能走 PGI；没它，只能靠 MIGO 手工做 351 发货。这个页签不是靠权限控制的，而是靠后台“按工厂配置交货类型和可用性检查过程”里那一条配置撑起来的。

机制是这样的：系统在保存或修改行项目时，拿“供货工厂 + 收货工厂”这个组合去后台表里找对应的交货单类型（DlTp）和可用性检查规则。找到 DlTp（比如 NL），行项目就长出装运页签，调度行、交货日期、装运点这些字段才有地方落；找不到，行项目就是一个纯粹的库存移动指令，装运相关字段全部不可用。

注意：即便 DlTp 配了，如果供货工厂没有被分配给对应的销售组织，VL10B 依然选不出单据。工厂到销售组织的分配属于 SD 侧组织结构，和 MMPV/采购侧的配置是两套东西，这是新手最常混淆的地方。

为什么这么设计？因为“要不要走运输”是一个业务决策，不是一个技术决策。同一集团里，两个厂区隔一条马路的调拨和跨省运输的调拨，管理颗粒度完全不同。前者不需要拣配、包装、装运点、运输方式，后者需要。SAP 用 DlTp 这个开关把两类场景收进同一个凭证类型里，代价就是配置必须成对维护，少配一条就退化。

2.3 跨公司清账科目：谁借谁贷，为什么不用应收应付

不带开票的公司间转储（UB 转储订单），账是最容易看晕的。原文给出的借贷关系很清晰：

• 供货公司：借 公司间清算科目，贷 库存商品
• 采购公司：借 库存商品 + 差异科目，贷 公司间清算科目

为什么中间要插一个“公司间清算科目”，而不是直接走应收应付？因为 UB 转储整条链路里根本没有开票动作。没有发票，就没有应收、没有应付，也就没有正常的客户/供应商往来科目可以挂。但两家公司又各自是独立的公司代码，必须各自借贷平衡，于是系统用一个中间科目把两条腿接上：供货方把存货转出、记一笔对采购方的债权；采购方把存货转入、记一笔对供货方的债务。集团合并报表时，这笔内部往来直接对冲清零。

这也是为什么“是否需要配置跨公司清账科目”会成为 UB 转储能不能跨公司跑的前置条件——不配，凭证出不来。配置上通常落在 OBYC 的库存记账相关事务键下，再配合账户修改码把“跨公司”这个场景单独摘出来，避免和普通工厂间转储混用同一个科目。

提示：跨公司的工厂间转储，系统会按两个工厂各自所属的公司代码分别生成会计凭证，两边在自己的公司代码里独立平衡。所以看到的不是一张凭证两个分录，而是两张凭证各自成对，这一点在做凭证追溯时特别容易搞错。

3. 一步法与两步法：库存所有权在哪个瞬间转移

一步法和两步法的差别，表面看是“做几次 MIGO”，实质是“系统承认物权在什么时刻转移”。这个差别决定了在途库存存不存在、MRP 会不会把货算进去、收货方还有没有数量确认权。三种转储方式在这三点上给出的答案完全不同。

3.1 无参考调拨：301 与 303+305 的语义差别

不走 STO、不建单据，直接用 MIGO 做库存转移，是最轻的一种方式：

• 一步法：MIGO 301，发货与收货在同一张物料凭证里完成，没有在途库存。
• 两步法：MIGO 303 发货，货物进入在途；实物到达后，接收工厂用 MIGO 305 做接收，在途转库存。

303 和 305 分开的意义在于“时间差被系统记录下来了”。303 过账的那一刻，货物已经离开供货工厂的非限制库存，但还没进入接收工厂，这段空窗期就是“在途”。如果这期间发生盘点、月末结账、成本核算，系统必须知道这批货在哪一方账上，303/305 给了它这个答案；301 则直接跳过这个问题，前提是发货和收货在业务上被视为同时发生。

用哪种，本质是问：这批货在路上的时候，需不需要有人为它负责？同厂区两个车间之间挪一批料，不需要；跨城调拨走第三方物流，需要。

3.2 带交货单的两种收尾：647+101 与 641+101

UB 转储订单配上交货单之后，分支变成两条：

• 两步法：VL02N 做 641 发货过账，货物进在途；实物到了之后，接收工厂用 MIGO 做 101 收货。两张物料凭证，一段在途。
• 一步法：VL02N 做 647 发货过账，系统在同一张物料凭证、同一张会计凭证里同时完成供货方发出与采购方 101 接收。一张物料凭证，零在途。

641 和 647 的差别不在“发不发货”，而在“系统是否替收货方认账”。647 的隐含假设是：供货方发出的数量就是收货方认可的数量，收货方放弃数量确认权。这个假设在管理上的代价很实在——一旦运输途中短少、破损、批次错发，系统里两边账已经平了，只能在事后用差异处理去补，而补的过程往往要跨两个公司代码调账。

所以原文那句“优先推两步法，库存数据有保障”，不是保守，是血泪经验。一步法省下的那一次操作，换来的是异常场景下没有后悔药。

3.3 在途库存：MB5T 里的数字到底算谁的

641 发货之后，用 MB5T 能看到在途数量。这个数字常被误解成“已经到收货工厂了，只是还没入库”。不是。它表示的是“已经离开供货方，尚未进入接收方”的中间态，在库存归属上既不算供货方的可用库存，也不算接收方的可用库存。

这段语义带来的直接后果是 MRP：在途库存通常不参与接收工厂的可用量计算。物料需求计划在跑净需求时，看到的是接收工厂当前的非限制库存加上已确认的收货元素，在途那部分如果没被建模成采购订单的未清收货行，就不会被扣减。于是就出现了那个经典现象——货已经在路上，系统还在喊缺料，采购员又下了一单。

常见的处理思路有两条：一是让收货方对 STO 做确认（确认控制键），把在途变成“已确认的未清收货”，MRP 才会认；二是在计划参数上给这段运输时间留出提前期，用时间换准确度。两条都不完美，第一条依赖收货方愿意及时确认，第二条依赖提前期估得准。

3.4 一步法为什么必须挂在交货单上

原文专门强调了一句：一步法只在有交货单的情形下生效。这句话背后是一条很硬的机制约束。

不带交货单的 UB STO，走的是 351 发货 + 101 收货，351 是纯粹的库存移动，没有装运、没有拣配、没有 PGI 这个概念。系统在这一层根本没有“发货过账”这样一个可以挂自动收货的触发点，自然也就没有 647 的容身之处。只有走 SD 的交货单，才有 PGI 这个动作，647 才有地方落，系统才能在 PGI 成功的那一刻顺带把 101 一起做掉。

所以后台那张“分配凭证类型、一步过程”的表，勾了“一步”只是必要条件，不是充分条件。DlTp 没配，行项目没有装运页签，建不出交货单，勾了也白勾，单据照样走 351+101。这个坑在第 5 章会展开。

4. 后台配置链路：一步过程、交货类型和可用性检查怎么咬合

配置不好，业务怎么操作都别扭；配置对了，业务只需要点几下。公司间转储的所有分支，其实都由两张后台表决定：一张决定“一步还是两步”，一张决定“有没有交货单”。这两张表的匹配维度不同，必须成对理解。

4.1 分配凭证类型、一步过程与交货不足限度

路径是：物料管理 → 采购 → 采购订单 → 设置库存调拨订单 → 分配凭证类型、一步过程、交货不足限度。

这张表的主键是“发送工厂 + 接收工厂 + 凭证类型”这样一个三元组。系统在保存 STO 行项目时，拿这三个值去精确匹配：匹配到并且一步过程被勾选，就走 647+101；匹配到但没勾选，就走 641+101（有交货单）或 351+101（无交货单）；压根匹配不到，通常按两步处理。

这里的设计取舍值得说一句：为什么用“工厂对”而不是“公司对”？因为转储的粒度本来就是工厂，公司只是工厂背后的会计主体。同一个公司下两个工厂的调拨和跨公司两个工厂的调拨，在业务操作上没有区别，区别只在记账。用工厂对做维度，一条配置能同时覆盖同公司调拨和跨公司调拨，代价是配置条目会随工厂数量呈平方增长，大集团动辄几百上千条，维护本身就是个体力活。

“交货不足限度”解决的是另一个问题：STO 允许收货数量少于订单数量多少还自动收货。一步法下这个参数尤其敏感，因为收货是自动触发的，限度设宽了，少发的货也会被系统认账。

4.2 按工厂配置交货类型与可用性检查过程

路径是：物料管理 → 采购 → 采购订单 → 设置库存调拨订单 → 按工厂配置交货类型和可用性检查过程。

这张表才是“装运页签”的开关。给“供货工厂 + 收货工厂”配上交货单类型（如 NL）和可用性检查规则，STO 行项目就长出装运页签，VL10B 能选出单据；不配，行项目就是一个纯库存移动指令，走 351。

两张表的关系可以这么理解：第一张表决定“这一步要不要系统替收货方认账”，第二张表决定“这一步走不走 SD 的交货流程”。前者是业务授权，后者是流程形态。组合起来就是原文那张矩阵里的五种形态：

注意：这张表里“有没有交货单”和“一步还是两步”是两个独立维度，不要混为一谈。带交货单也能走两步（641+101），不带交货单永远走不了真正的一步（只有 301 那种同凭证才算）。

4.3 用 ABAP 判定跨公司：不要看抬头看工厂

判断一张 STO 是工厂间转储还是公司间转储，最靠不住的做法是看采购订单抬头的公司代码。抬头只反映采购方，供货方在行项目的 RESWK 里。真正决定“会不会生成两张会计凭证、要不要公司间清算科目”的，是两个工厂背后的公司代码是否相同。

" 判定一张 STO 属于工厂间转储还是公司间转储 " 关键点：不看抬头公司，看行项目的 WERKS（收货工厂）与 RESWK（供货工厂） SELECT ebeln, ebelp, werks, reswk FROM ekpo INTO TABLE @DATA(lt_item) WHERE ebeln = @iv_ebeln AND loekz = @space. " 排除已删除行项目 LOOP AT lt_item INTO DATA(ls_item). " 工厂不直接等于公司：先经 T001W 取估价范围 BWKEY，再经 T001K 取公司代码 SELECT SINGLE bwkey FROM t001w INTO @DATA(lv_bwkey_recv) WHERE werks = @ls_item-werks. SELECT SINGLE bukrs FROM t001k INTO @DATA(lv_bukrs_recv) WHERE bwkey = @lv_bwkey_recv. SELECT SINGLE bwkey FROM t001w INTO @DATA(lv_bwkey_send) WHERE werks = @ls_item-reswk. SELECT SINGLE bukrs FROM t001k INTO @DATA(lv_bukrs_send) WHERE bwkey = @lv_bwkey_send. IF lv_bukrs_recv <> lv_bukrs_send. " 跨公司：会按两个公司代码分别生成会计凭证，必须有公司间清算科目 " 不配的话，凭证出不来或走错科目 ENDIF. ENDLOOP.

这段逻辑里有两个容易忽略的点。第一，工厂和公司代码不是直接关联的，中间的桥梁是估价范围（BWKEY），一个估价范围可以包含多个工厂，所以生产环境里更严谨的写法是先取 T001W-BWKEY 再取 T001K-BUKRS，中间这一层不能跳。第二，判定结果必须按行项目做，不能按抬头做——一张 STO 理论上可以有多行，落到不同收货工厂，虽然实务中很少这么建，但代码不能假设。

把这个判定做成通用的校验出口，挂在 STO 保存或收货过账前，就能在配置缺失的时候提前拦住，而不是等财务月末对账才发现科目走错了。

4.4 计划协议：ME31L 与 ME38 把重复建单变成长协

调拨频率高到一定程度，每笔都建一张 STO 就是浪费。计划协议（Scheduling Agreement）用 ME31L 建一份长期协议，用 ME38 逐期维护交货计划行，发货方按计划行做 351 发货，收货方按 STO 做 101 收货。凭证数量从“每次一张”降到“一份协议 + N 条计划行”。

机制上，计划协议把“订单数量”和“交货日期”解耦了：协议本身只约定大致总量和有效期，真正的执行量落在计划行上，每条计划行有自己的日期和数量。这样改计划不用改订单，直接调整计划行即可，历史计划行还能留痕。代价是收发双方都要维护计划行，一旦计划行和实际发货脱节，MB5T 上的在途就会越堆越多。

原文把计划协议放在“不带交货单”这一类里，走 351+101，逻辑是自洽的：计划协议的定位是长期、稳定、可预测的重复调拨，这类场景通常不需要逐笔走拣配和装运，用最轻的库存移动就够了。真要装运管理，那就该用带交货单的 STO，而不是计划协议。

5. 避坑与排查：STO 上线后最容易翻车的五个地方

配置和操作都能跑通，不代表数据是对的。下面这五件事，是我见过最频繁、也最容易被当成“系统 bug”的。

5.1 勾了一步过程，647 却始终不出现

现象：后台“分配凭证类型、一步过程”里明明勾了一步，业务做 VL02N 发货过账，出来的还是 641，MB5T 里照样有在途。

原因：一步过程只对有交货单的场景生效，而这张单之所以有交货单，是因为另一张表配了 DlTp。如果“按工厂配置交货类型”里这条组合没配，行项目没有装运页签，只能走 351+101，一步过程这个勾根本没有落点。

解决：先确认行项目有没有装运页签。没有，就去补 DlTp 和可用性检查规则；有装运页签但还是出 641，再回头核对“发送工厂+接收工厂+凭证类型”这三元组有没有精确匹配上，注意别把发送和接收写反。

5.2 641 发货后有在途，MRP 照样喊缺料

现象：供货方已经 641 发货，MB5T 里能看到在途数量，接收工厂跑 MRP 还是提示缺料，采购员于是重复下单。

原因：在途库存不参与接收工厂的可用量计算。MRP 只认接收方自己的库存和已确认的收货元素，在途那部分既不属于供货方的可用库存，也不属于接收方的可用库存，处在两边都不管的灰色地带。

解决：要么在 STO 上启用确认，让收货方对交货行做确认，把在途转成 MRP 认的未清收货；要么在物料或工厂层面把运输天数折算进计划交货时间。前者准，依赖人的及时性；后者稳，依赖参数估得准。两条都别指望零维护。

5.3 跨公司调拨的凭证里没有公司间清算科目

现象：同一公司的两个工厂之间调拨一切正常，换成跨公司的两个工厂，凭证出来了，但借贷方是普通存货科目，没有公司间清算科目，两边公司代码挂不上。

原因：跨公司清账科目是单独配置的，通常落在自动记账的库存相关事务键下，配合账户修改码把跨公司场景摘出来。没配这一条，系统只能退回默认的存货科目，凭证能过，账是错的。

解决：先按第 4.3 节的逻辑确认这张单确实是跨公司（两个工厂的公司代码不同），再去检查自动记账配置里跨公司场景的科目有没有维护、科目是不是挂了公司代码层级的特别科目。这类错误不会报错，只会安静地把账做歪，月结时才爆。

5.4 特殊库存 K/O/Q 跨公司转不动

现象：寄售库存（K）、委外库存（O）、项目库存（Q）在跨公司 STO 里收货失败，或者收进来的库存类型不对，后续发料找不到。

原因：特殊库存的归属逻辑和普通库存不一样。寄售库存的所有权在供应商手上，不能直接当成自有库存转储；项目库存必须带 WBS 元素，收货时缺这个维度就落不了账；委外库存和采购订单绑定，脱离委外 PO 就没有承载对象。这些限制在跨公司场景下会被放大，因为多了一层公司代码的账务归属。

解决：不要在 STO 里直接对特殊库存做跨公司转储。常见做法是先做一次库存类型转换（比如寄售转自有），再走正常的公司间 STO；项目库存则要在 STO 行项目上带好对应的项目号/WBS，让收货能落到正确的项目维度。凡是涉及特殊库存的公司间调拨，建议先在一套测试环境把整条链跑完再动生产。

5.5 两边差异科目金额对不上

现象：供应方发货的金额和采购方收货的金额不一致，差异科目上挂着一笔解释不清的余额。

原因：STO 的结算价来自采购订单净价，而供货方发货是按自己工厂的估价（标准价或移动平均价）走的。两个价格体系不一样，差额自然进差异科目。如果采购订单价格维护不及时，或者供货工厂的物料价格刚做过重估，差异就会突然放大。

解决：把 STO 净价和供货方成本的关系当成一个必须定期核对的对账项，而不是一次性配好就不管。物料价格重估、标准价年度切换、采购订单价格变更，这三个动作之后都要抽查差异科目余额。差异本身不可怕，可怕的是没人知道它为什么在那儿。

6. 选型取舍：301、303/305 与 UB STO 的分界线在哪

同公司两个工厂距离很近、库存转移非常频繁、发货和收货是同一批管理者，用 MIGO 301 一步法最省事——自己发自己收，不需要任何数据确认，一张物料凭证结束。这是最少单据、最低管理成本的方案，代价是没有在途概念，路上出了事系统不知道。

同样的距离，但如果发货和收货是两波人，收货方需要对数量负责，那就用 303 发货 + 305 收货。在途被显式记录，收货方按实际数量接收，差异有地方落。多一次操作，换来的是责任边界清晰。

跨公司、距离远、还要走第三方运输，那基本只能选 UB STO 加发运。至于一步还是两步，判断标准只有两条：收货方有没有人在系统里做收货操作，以及收货方是否认同发货方的数量。有人做、且需要确认，就两步（641+101），库存数据有保障；实在没人做系统收货，才退到一步（647+101），用放弃确认权换取流程能跑完。

这张表真正想说的是：一步法和两步法不是技术选项，是管理授权选项。系统能做的只是把这个授权关系固化成配置，一旦选错，后面所有的差异处理、对账、追溯都要为它买单。

我踩过最深的一次坑，是在一个调拨频率极高的场景里默认勾了一步法，上线三个月后运输短少累积成一笔说不清的差异，两个公司代码来回调账调了很久。从那以后我每接一个公司间项目，都强制自己先把“工厂对 + 单据类型”那张矩阵完整画一遍，把每一条标上一步还是两步、有没有交货单、在途谁负责，画完再动手配。希望帮到你。

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