企业官网建设流程全解析

简介：这份PPT资料聚焦SAP系统中的公司间采购与内部交易，面向SAP MM顾问、集团企业财务与供应链实施人员，以及需要系统梳理公司间业务的学习者，帮助理清不同交易模式的适用边界与配置差异。内容覆盖公司间采购STO、工厂间UB转储（带交货单与不带交货单、一步法与两步法）、跨公司销售、集中采购、公司间计划协议，并延伸到K寄售、O委外、Q项目等特殊库存下的公司间操作与账务处理逻辑，附有移动类型与STO、交货单、配置项的对照总结，便于按场景检索对照。资源为1个pptx文件，压缩包约26.85MB，以图文流程与系统演示截图呈现业务链条。目前已有319人学习。读者可从中获得各场景的操作脉络、借贷与清算科目关系及配置思路，用于项目实施前的方案梳理与日常问题排查参考。

1. 公司间采购是什么：一张单子为什么同时是采购单和销售单

公司间采购这个词，第一次听到的人多半会愣一下：集团下面两家公司，左手倒右手，为什么还要正儿八经地走一套采购销售流程？打个比方，一个家里两个房间搬东西，你抱过去就完了；可如果这两个房间分属两个独立记账的租户，那搬一箱纸都得写张条子，否则月底对账谁也说不清。集团里的公司就是这两个租户，各自有报表、有成本、有利润。所以在 SAP 里发生这种内部交易时，系统必须留下一张凭证：对买方公司它是采购订单，对卖方公司它就是销售订单——同一张单子，两副面孔。这就是公司间采购，也叫公司间交易、STO 转储订单。搞懂它，等于搞懂了集团型企业在系统里做内部结算的底层逻辑。

2. 为什么集团内部交易要设计得这么绕：从工厂间转储到公司间 STO

库存数字在系统里从来不是一个孤零零的阿拉伯数字，它背后挂着法人、工厂、成本中心、存货科目。货物从一个地方挪到另一个地方，如果只是把 A 的库存减掉、B 的库存加上，中间不留任何痕迹，那月底的存货金额、成本归集、责任划分就全断了线。系统设计的出发点，就是让每一次"东西挪窝"都留下可追溯的凭证。所以才会有一堆听起来很像的名词：工厂间转储、UB 转储订单、带交货单、不带交货单、一步法、两步法。它们解决的是同一个问题的不同侧面——货动了，账要跟着动，而且动得要让人看得懂。

2.1 为什么不能直接改库存：工厂间调拨的两种做法

最朴素的调拨发生在同一个公司下的两个工厂之间。这两家工厂共用一个法人，不存在开票、不存在内部往来，纯粹是库存搬家。这种场景系统给了两种做法。

一步法用移动类型 301，发和收在同一张物料凭证里完成：发出工厂库存减少，接收工厂库存同时增加。好处是干净利落，一张凭证闭环，系统里根本不存在"在途"这回事。缺点是接收方没有确认动作，发多少就是收多少，等于完全信任发货方的点数。

两步法用 303 加 305。303 是发货到在途，此时发出工厂的库存减掉了，但这批货没有直接落到接收工厂，而是挂在在途库存上，可以用事务码 MB5T 查得到。等实物真正运到，接收工厂再用 305 做接收。两步法的价值就在这段"在途"：货已经离开发货方，但还没进接收方，物权其实已经转移，只是实物还在路上。月末盘点的时候，这段在途必须有地方挂账，否则就会变成账实不符的玄学问题。

这张表不需要背，但值得存下来。后面所有让人头晕的组合，本质上都是这几个移动类型在换排列顺序。

2.2 UB 转储订单：不带交货单的 351 和 101

UB 转储订单是 STO 里最轻的一种形态。说它轻，是因为它不牵扯物流单据：行项目里没有"装运"页签，不需要建外向交货单，也没有拣配、打包、打印运单这些动作。整条链路只有三步：需求工厂用 ME21N 建一张 UB 转储订单，发货工厂用 MIGO 参照这张订单做 351 发货，需求工厂再用 MIGO 做 101 收货。351 一旦过账，库存就离开发货工厂，进入在途，直到 101 把它接住。

为什么要有这种形态？因为很多内部调拨根本不需要那么隆重的物流管理。两个工厂之间一辆卡车拉过去，司机带张纸单，货到了对方点数签字，这就够了。硬要套一套交货单流程，反而增加无效操作。UB 转储订单在这里的作用，是给"我发了多少、你收了多少"留一个系统凭据，让两边数量对不上时能查到差异出在哪一步。

适用范围有两条，值得留意：同一集团同一公司下不同工厂之间的调拨可以用；同一集团不同公司下两个工厂之间的调拨也能用。后者听起来有点意外——明明是跨公司，怎么还能走这种轻量流程？答案是账务处理不同。如果两家工厂分属不同公司，这个动作在系统眼里就从"库存搬家"变成了"内部买卖"，必须额外配置跨公司的清账科目。分录会变成：供方公司借公司间清算科目、贷库存商品；采购公司借库存商品加差异、贷公司间清算科目。科目不配，这一步必然报错，这是很多人第一次做跨公司调拨时踩的坑。

2.3 带交货单的转储：641 和 647 差在哪

一旦在后台给这类转储订单配上了交货单类型，行项目里就会冒出"装运"页签，整个流程立刻变得正式起来：供货工厂要先用 VL10B 或 VL10D 批量生成外向交货单，再用 VL02N 做拣配和发货过账。这时候发货的移动类型不再是 351，而是 641 或 647，两者的区别只有一处，但影响很大。

641 是老老实实的发货过账：库存进入在途，等着需求方来做 101 手工收货。这就是带交货单的两步法，系统里始终有一段在途挂着，MB5T 能看到。

647 则是在发货过账的同一瞬间，系统自动把 101 也做掉：发货和收货合并成同一张物料凭证和同一张会计凭证，在途根本不出现。这就是带交货单的一步法。

这里有一个特别容易翻车的细节：一步法只在有交货单的情形下才能生效。也就是说，你得先有交货单这个载体，才有资格选"发即收"；如果压根没配交货单类型，那 647 这条路走不通，只能用 351 加 101 的两步方式。这个约束在配置层面是硬性的，不是操作习惯问题。

为什么明明是同一次物理搬运，要分出这么多形态？因为物流管理的颗粒度不一样。走第三方运输、需要拣配打包、需要打印单据给司机的时候，交货单是绕不开的载体；而交货单一出现，"什么时候确认收货"就变成了一个独立的业务决策，641 和 647 就是把这个决策摆到台面上让你选。

2.4 计划协议：把高频调拨变成排程

如果两个工厂之间每个月要调几十次货，每次都 ME21N 建一张单，光录单就能把人耗干。计划协议解决的就是这种重复劳动：用 ME31L 建一份长期协议，用 ME38 维护交货计划，把未来一段时间每次要发多少、什么时候发，一次性排进去。执行的时候发货工厂照计划做 351 发货，需求工厂照计划做 101 收货。

它和普通 STO 的本质差别在于"合同"与"执行"被拆开了。普通 STO 一张单子就是一次交易，计划协议是一份框架加若干次执行，每次执行只产生一条计划行。这种结构特别适合那些用量稳定、节奏规律、双方早有默契的内部供应关系。反过来说，如果调拨是偶发的、数量每次都不一样，那上计划协议就是给自己找麻烦。

3. 一张 STO 单据背后的四步流转：采购订单、交货单、发票、收货

把视角从工厂挪到公司，事情会变得正式一档。工厂之间调拨，最多是内部记账；公司之间交易，那是两个法人在买卖，该有的单据一样不能少，只不过流程被压缩得更紧凑。

3.1 采购方与销售方：同一张单子的两副面孔

假设某集团下有 A、B 两家公司，A 向 B 采购一批物料。A 在系统里下了一张采购订单，这张单子对 A 来说是采购订单：A 关心的是什么时候到货、数量对不对、发票金额和订单是否一致，所以 A 会做收货、做发票校验。可同一张单子到了 B 那边，B 看到的是销售订单：B 关心的是要发多少、什么时候发、开多少票，所以 B 会建交货单、做发货过账、开销售发票。

一份数据，两边各用自己那半边功能，这就是所谓"复合体"的含义。这么设计的好处很实在：如果采购和销售各建一张单子，两边数量一改就容易对不上，改了一边忘了另一边，最后收货数量和开票数量打架，查起来能耗掉一整天。合并成一张，数量、金额、交期只有一个源头，谁也改不出分歧。

3.2 两种收货时序：自动触发还是手工确认

具体跑起来，公司间采购的步骤会根据后台配置分成两种走法。

第一种，供方交货单过账之后自动触发客户工厂收货。整条链路是：客户公司用 ME21N 创建公司间 STO，供方公司用 VL10B 或 VL10D 参照 STO 创建交货单，供方用 VL02N 做发货过账，供方用 VF01 或 VF04 开票，最后客户公司用 MIRO 做收货发票校验。注意这里没有独立的收货动作，收货是跟着发货过账一起完成的。

第二种，不自动触发，收货得客户方自己做。链路变成六步：ME21N 建 STO，VL10B 或 VL10D 建交货单，VL02N 发货过账，VF01 或 VF04 开票，客户公司用 MIGO 参照交货单收货，最后 MIRO 做发票校验。

两种走法的差别，说到底还是那个老问题：系统里要不要留一段在途，收货这个动作由谁来签字。第一种快，但对收货方的数量确认是缺位的；第二种慢一步，可收货方实打实点过数才入库，账实更稳。

3.3 钱怎么走：跨公司清账科目这只黑匣子

公司间交易绕不开一件事：两家是独立法人，货搬过去了，钱不能当没发生。系统里承担这个角色的，是跨公司清账科目，也叫公司间清算科目。它像一个中转站：供方公司发货时，借公司间清算科目、贷库存商品；采购公司收货时，借库存商品加差异、贷公司间清算科目。等两边定期对账结算，这个中转站的余额再被清掉。

很多人第一次做跨公司业务时，会想当然地拿同公司调拨那套 301 或 303 加 305 直接套上去，结果一跑就报错。原因就在这里：同公司调拨不需要科目中转，跨公司调拨必须有，否则系统不知道这笔钱该挂在哪。反过来说，只要把跨公司清账科目配好，公司间交易其实也能用类似工厂间转储的方式跑，301 或者 303 加 305 都行。这一点常被忽略，但它在实务里非常有用——不是所有内部交易都值得走完整的采购销售流程。

4. 一步法与两步法：在途库存到底要不要出现在系统里

一步法和两步法这两个词，几乎贯穿了公司间交易的所有讨论。它们听起来像是两套技术方案，实际上只是一个业务判断的两种表达：这批货在路上的这段时间，系统要不要知道。

4.1 在途库存：物权在哪一刻转移

一步法的逻辑是"发货即收货"。301 是一张凭证搞定，647 是发货过账时系统顺手把 101 也做了，两种情况下库存都是瞬间从发出方跳到接收方，中间没有停顿。系统里查不到任何在途，因为业务上压根不承认有这段路。

两步法的逻辑是"货走了，人还没到"。303 或者 641 或者 351 过账之后，库存离开发出方，但不进接收方，而是挂在在途库存上。这段在途是有金额的，会出现在存货相关报表里，能用 MB5T 查出来。等接收方做了 305 或者 101，在途才被冲掉，库存正式落到接收工厂。

为什么这件事值得较真？因为在途库存代表的是一段悬空的责任。月末结账时，如果这批货已经发出但还没到，它到底算谁的存货、算哪个公司的存货，直接影响报表数字。一步法把这段悬空抹掉了，账面上干净，可一旦货物在路上丢了、损了、数量短了，系统里根本找不到这段痕迹，只能靠线下扯皮。两步法把这段悬空显式记录，麻烦是真麻烦，但出问题时至少有据可查。

4.2 三个问题决定一步还是两步

选哪种走法，不用记规则，问自己三个问题就够了。

第一个问题：接收方认不认发货方报的数量？如果发货方说发了十个，接收方连点数都不点直接入账，那就是一步法的场景。如果接收方必须自己点过、确认是八个还是十个，那就得留出货到之后再做一次收货动作，只能走两步法。

第二个问题：在途要不要体现在系统里？有些集团管理颗粒度粗，货在路上几天无所谓，账面干净更重要，那就一步法。有些集团要求存货责任清清楚楚，在途必须能查、必须挂账，那就两步法。

第三个问题：接收方有没有人在系统里做收货？这一条最现实。如果接收工厂连个会做 MIGO 的人都没有，你设计再严谨的两步法也跑不起来，最后还是会退化成让发货方代劳，那就失去意义了，不如直接一步法。

原文里给出的场景建议很接地气：同一个公司下两个工厂距离特别近、调拨非常频繁、发货和接收是同一批管理者的时候，优先用 301 一步法，因为自己发自己收，不需要数据确认。如果是两波人，发货的发十个、收货的必须点一遍，那就 303 发货产生在途，接收方用 305 按实际数量收货。如果是同一个公司下两个工厂距离远、还要走第三方运输公司，那一般得上 UB 转储订单加发运功能；至于一步还是两步，看接收工厂有没有人做系统收货，有人就两步法，实在没人就一步法——但在条件允许时优先推两步法，因为库存数据有保障。

这段话里藏着一条血泪经验：方案设计不能只看理论最优，要看对面站着的是谁。系统是给人用的，人不配合，再优雅的流程也会被绕过去。

4.3 配置里的两个开关

真到配置层面，决定一步法还是两步法、带不带交货单的，其实就是两个开关。它们的入口在同一片菜单下面。

# 公司间调拨与 STO 的关键配置入口（菜单层级，不是可执行命令） SPRO: 物料管理 -> 采购 -> 采购订单 -> 设置库存调拨订单 ├── 分配凭证类型、一步过程、交货不足限度 # 控制"一步法"是否生效 └── 按工厂配置交货类型和可用性检查过程 # 控制"要不要建交货单"

先说第一个开关，一步过程。它的取值直接对应移动类型组合：勾选一步，走的就是 647 加 101 自动收货，没有在途；不勾选，走 641 加 101 手工收货，有在途；而在没有交货单的情况下，不勾选对应的是 351 加 101 手工收货，同样有在途。

再说第二个开关，交货单类型。如果某个工厂的这一项空着没配，那这个转储订单就不需要创建交货单，行项目里也看不到装运页签。如果配上了具体的交货单类型并且设置了库存类型的检查规则，那这张转储订单就必须建交货单，行项目里会出现装运页签。

两个开关的组合关系值得单独强调一句：一步法只在有交货单的情形下生效。所以真正决定"能不能一步"的，是先有没有交货单；在有的前提下，才轮到一步过程这个开关说话。反过来，把顺序搞混，就会配出一个自己都解释不通的组合，然后在测试环境里反复翻车。

5. 易混概念辨析：五组最容易搞混的名称

这几个词放在一起，几乎每个刚接触公司间业务的人都会混淆一轮。它们的字面意思太接近，实际边界却差得很远。

5.1 易混点一：工厂间转储和公司间采购，差的不只是一个"公司"

这两个词最容易被当成同一件事的粗细两种说法。毕竟它们都叫"调拨"，都用转储订单，操作界面上看起来也差不多。

混淆的根源在于，从库存角度看，两者确实都是货从一处挪到另一处。同一个集团、同一批物料、同样的移动类型，视觉上几乎一模一样。可一旦跨过公司这条线，业务性质就变了：工厂间转储是同一法人内部的库存搬家，不产生买卖关系，不需要开票，不需要内部往来科目；公司间采购是两个法人之间的交易，要开票、要走发票校验、要挂跨公司清账科目，供方还要确认收入。

怎么区分？看三个地方就够了。看是不是跨法人——同一个公司代码下的两个工厂，那是转储；不同公司代码，那是采购。看要不要开票——需要 VF01 开销售发票、需要 MIRO 做发票校验的，一定是公司间采购。看要不要配清账科目——跨公司调拨即使走 301 这种极简方式，也必须先把跨公司清账科目配好，否则跑不通。

5.2 易混点二：公司间采购和跨公司销售，方向正好相反

这两个名字听起来像是同一件事的两种叫法，其实发起方完全不同。

混淆是因为它们的参与方都是同一个集团下的两家公司，单据链条也高度重合，都有采购订单、都有交货单、都有发票。从外面看，两条流程长得几乎一样。

区分的关键在谁先动手。公司间采购是买方发起：A 公司要货，A 先建 STO，B 公司再照单发货。整条链路由采购需求驱动。跨公司销售则是卖方发起：B 公司先接到外部客户的订单，发现自己这边没货或者不方便直接发，于是向关联的 A 公司发起内部采购，由 A 供货，B 再对外销售。整条链路由销售订单驱动。

一个是"我要买"，一个是"我要卖"，起点不同，后面所有的单据归属、开票对象、收入确认主体都会跟着不同。判断的时候只问一句：这张单子最早是谁因为什么原因建出来的。

5.3 易混点三：一步法不等于带交货单

这是配置层面最常见的误解。很多人以为"一步法"和"带交货单"是同一套方案的两个名字，于是配完一步过程就以为交货单会自动出现，或者在没配交货单的情况下硬要去找 647，结果怎么都跑不通。

混淆的原因是两个概念经常一起出现在同一段描述里，而且确实有交集：带交货单的场景下可以选一步法，也可以选两步法。但它们描述的是两个不同维度——交货单解决的是"物流环节有没有单据载体"，一步法解决的是"在途要不要留在系统里"。

区分的办法很直接：一步法的前提是有交货单，没交货单就没有一步法这回事，只能 351 加 101 两步走。而有交货单的时候，一步和两步都合法，取决于你要不要在途。所以正确的判断顺序是先定要不要交货单，再定一步还是两步，顺序颠倒必然配出跑不通的组合。

5.4 易混点四：特殊库存 K、O、Q 不是另一套公司间交易

寄售、委外、项目这些特殊库存类型，经常和公司间业务一起出现在需求里，于是有人以为它们属于另一套并行的公司间机制。

混淆是因为这些库存类型确实会改变物料的归属状态和账务逻辑：寄售库存的所有权还在供应商手上，委外库存要跟着加工过程走，项目库存绑定到具体的项目号。这些特性让流程看起来和普通库存完全不同。但它们在公司间交易里扮演的角色，只是"被搬运的对象"不一样，搬运本身的框架没变——该建 STO 还是建 STO，该建交货单还是建交货单，该 641 还是 641，收货之后库存落到哪个特殊库存类型，那是行项目层面的事。

区分的方法是把两层分开看：一层是交易机制，选的是转储订单、交货单、一步两步；另一层是库存归属，选的是普通库存还是寄售、委外、项目库存。两层是叠加关系，不是替代关系。搞混这两层，就会在配置时到处找"特殊库存专用的公司间流程"，而它其实并不存在。

5.5 易混点五：计划协议不是普通 STO 的简化版

听到"计划协议"这四个字，容易联想到某种更轻、更省事的转储订单。实际上它比普通 STO 更重，只是重复劳动更少。

混淆是因为执行层面看起来确实简单：不用每次建单，照计划发货收货就行。可这份简单是用前期投入换来的——要先用 ME31L 建协议，再用 ME38 维护交货计划，把未来一段时间的节奏排清楚。前期没排明白，后面每次执行都会卡住。

区分的判断标准是用量节奏。用量稳定、周期规律、双方长期配合的，适合计划协议，一次排程管一段。偶发的、每次数量都不确定的、临时起意的调拨，用普通 STO 更合适，为一次交易维护一份协议纯属自找麻烦。

6. 什么时候用哪种：把场景和方案对上号

到这里，各种形态都摆出来了，真正难的是面对一个具体场景时该挑哪个。可以按一张简单的对照表先筛一遍。

反过来看什么时候别用，也很清楚。接收方根本没有系统操作人员，就别设计两步法，最后一定是发货方代做，流程形同虚设。调拨是偶发的、数量每次都变，就别上计划协议。只是同公司内部搬库存，就别硬套完整的公司间采购链条，多出来的开票和发票校验环节只会增加对账工作量。

我印象最深的一次，是给一个跨公司场景设计流程时，方案做得特别完整：交货单、两步法、手工收货、发票校验，一层不缺。上线第一个月就出问题——接收方压根没人愿意每天登系统点收货，货到了直接进车间，系统里的在途越堆越多，月底对账全靠线下表格补。后来改成一步法自动收货，账面立刻干净了。从那以后我每次设计方案，都强制先问一句"对面那个人，愿不愿意每天做这个动作"，答案是否定的话，再漂亮的流程也得推倒重来。希望帮到你。

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