1. 先拆业务多角交易里到底有几条流1.1 从一条真实的业务链说起客户找我的时候描述的是很典型的集团业务场景集团下有贸易公司、生产公司和销售公司海外的原材料先进贸易公司贸易公司卖给生产公司生产公司加工后卖给销售公司销售公司再卖给终端客户。采购负责人补了一句很多情况下货从生产公司直接发到销售公司的客户那里中间不经过销售公司仓库。财务总监问得很直接SAP里这么多公司代码公司间多角交易到底怎么做才不乱这个场景几乎每个做集团ERP的人都会碰到。所谓多角交易不是SAP里的一个标准功能按钮而是集团内部多个法人公司之间发生的、首尾相接的采购销售链条。常见形态是“三家以上公司代码参与同一个最终客户订单的交付”但实际物流可能只有一次发货。我一般不会马上打开SAP写配置而是先画业务环。因为这个方案不像一个销售订单类型那样有标准答案它考验的是把业务翻译成“货物流、发票流、资金流、税流”的能力。四条流拆清楚方案就已经成型一半。1.2 四条流分开看事情马上变简单拿刚才的例子继续。货物流海外供应商发货到贸易公司CC卖给生产公司BB卖给销售公司AA卖给终端客户。也可以从C直接发货到B甚至从B直发给A的客户。发票流C开票给BB开票给AA开票给客户。这是完整的逐级开票链。不少集团想减少开票层数于是就可能拆成“A开票给客户B开票给AC不开票给B”或“C直接开票给A”但这样又带来货权转移和增值税问题。资金流客户付钱给AA付钱给BB付钱给C。很多集团会设置资金结算中心内部往来不真正逐笔打款而是通过对冲或净额结算这部分在SAP里需要用公司间往来科目和内部清账来处理。税流每一张内部发票都涉及增值税税率、开票时间点、红蓝冲规则。如果涉及出口贸易还要考虑退税主体是谁如果不同公司代码使用不同本位币还会叠加汇兑损益。这四个流不搭任何配置方案都会成为“把错误流程自动化”。所以方案讨论第一步永远是跟业务确认在真实物理世界中货在哪一个节点转移所有权发票必须由谁开给谁资金是否逐笔清算。这三个问题定下来再谈SAP单据怎么落地。1.3 为什么SAP标准功能是“两角”结构SAP内部交易的标准玩法不管是公司间销售订单Intercompany Sales Order还是跨公司库存转移订单STO本质上都是两两配对一个公司对另一个公司。系统不会因为你建了一个销售订单就自动在三家公司之间连续传递所有权和账务。比如销售公司A和工厂公司B之间标准流程是A向B下跨公司采购订单B收到后创建一张公司间销售订单然后B发货、开公司间发票A收货、发票校验。这是一对一的闭环。多角交易等于要把这些一对一的闭环串起来C对B一套B对A一套A对客户一套。每两段之间的价格、发票、往来科目都可能不同。很多客户第一次做方案时希望“一张销售订单贯穿三家公司”这个预期要纠正。SAP能保证的是每段闭环内的凭证高度可追溯但不是用一个单据号完成全部。想清楚了这一点方案讨论就不会一边想着设计完美蓝图一边被系统边界卡死。提示多角交易方案讨论的核心是把法务上的每一段合同关系还原成SAP里两两配对的公司间单据再用交货单、IDOC、条件价格把几段串成一条可追踪的链。2. 三种落地方案背靠背、调拨链、代理结算2.1 方案A背靠背的跨公司销售订单链这是用得最多的方案。外部客户订单签约在AA向B下跨公司采购订单B在SD里生成公司间销售订单同时向C下跨公司POC同样生成公司间销售订单。每一层都是“采购订单销售订单”背靠背配对物理交货可以指定由最终生产公司直发终端客户。优点是业务逻辑最贴近合同关系。每个公司代码都有自己的采购成本、销售收入、库存成本和毛利财务凭证完整外部审计容易解释。发票链和货物流天然对应税票主体不会乱。缺点是单据量很大。三家公司之间如果每天有上千行订单系统里销售订单、采购订单、交货单、发票单数量会成倍增长业务操作和月结对账压力都大。另外价格条件必须逐级维护公司间价格如果长期不动还好一旦要按季度调价维护条件记录的工作量就很可观。这个方案适合贸易型销售公司或者各公司都有独立经营考核的集团。每一家公司需要看到自己“买进卖出赚了多少”的时候背靠背是最合适的。2.2 方案B跨公司STO逐级调拨如果链条重点是内部产能调配而不是每个环节都要做销售可以考虑STO。比如C把原材料调拨给BB把成品调拨给A然后A对外销售。每一步用一张跨公司库存转移订单接送货物料所有权的转移通过发货过账和收货过账实现不需要在SD里做一堆公司间销售订单。这个方案的优点是库存归属清晰。每个工厂各自的库存、在途库存都能追踪适合生产公司负责库存管理的集团。不过它的缺点是STO本质上偏重于“物”对“业务合同关系”的表达弱。如果每一层都希望体现B“向C采购再卖给C”的毛利STO就不如背靠背直观。实际项目里最常见的组合是内部工厂之间用STO到了面向外部客户的一环再用销售订单。也就是说链条拆成两段STO负责把物权调到最终销售公司销售订单负责对外成交。这样既控制了中间单据量也让销售公司保留完整的客户合同。2.3 方案C代理/寄售结算压缩发票层有些公司存在“过票公司”。明明货从C直发A的客户但合同关系要经过B做中间商B额外承担了信用风险和资金占用账面却只有过路收入。对这种场景用寄售Consignment和代销会明显减少凭证层。C把货放在B的寄售库存B实际领用消耗时才确认采购负债和成本或者B把货给A做代销A卖出去给最终客户之后才和B结算。这样做的好处是中间公司不需要在系统中模拟“先买后卖”的重复物流库存、发票、往来都压缩在真实消耗节点。缺点是寄售消耗的确认、后续结算和税票处理比普通采购销售繁琐需要业务和财务都理解“消耗点结算”的逻辑。如果集团已经习惯每单都要对清楚这种方案容易在月末对账时争论。2.4 怎么选把税、法、资金全部放到一张表里我通常建议客户用一张表对比而不是凭感觉选。维度背靠背订单链STO调拨链代理/寄售合同关系还原度高低中单据量高中低库存归属清晰度中高中内部毛利体现每层都能体现弱弱税务/发票复杂度常规但票多常规消耗点结算复杂资金清算复杂度高逐层应收应付中低可集中结算合并抵消工作较多中较少实施风险低低中高选型时先问业务一个问题中间公司到底是不是“需要承担货权和收入的主体”如果答案是要挣差价的独立经营主体老老实实选方案A如果只是内部调拨中转方案B更省事如果中间公司只做信用背书或资金通道方案C能显著降低运营成本。3. 关键配置路径从组织架构到财务入账3.1 组织与主数据逻辑系统、业务伙伴、内部客户/供应商方案定了以后配置才真正开始。首先检查组织架构定义。公司代码、销售组织、工厂之间的分配关系要明确销售公司下的销售组织能否看到生产公司的工厂能不能把其他公司代码的工厂设为发货工厂。这一步决定了公司间销售订单能不能建立。如果是多套系统通过IDOC集成还要先配置逻辑系统事务码SALE为每个系统分配逻辑系统名称再在通信参数里维护发送/接收关系。很多项目里“逻辑系统配置”往往被当成IT杂活其实是多角交易跨系统联动的地基。主数据方面S/4 HANA里客户和供应商统一为业务伙伴BP。一个内部伙伴往往既是供应商又是客户要在同一个BP上同时维护FI供应商、FI客户和SD客户视图。常见的坑是只维护了客户视图结果跨公司PO创建时找不到供应商或者公司间发票开不出。内部客户/供应商的编号最好用独立号段避免和外部客户混在一起。这样报表里一看到某个号段就知道是关联公司公司间往来对账和审计抽凭都会方便很多。3.2 SD侧订单类型、项目类别、开票类型和定价创建跨公司销售订单时销售订单类型建议复制标准订单类型但行项目类别、开票计划、交货类型都要单独维护。项目类别决定该行是正常销售、免费样品、寄售还是公司间库存转移。一旦选错后面所有交货、开票都会走错方向。公司间开票类型需要单独定义。标准外向交货过账之后系统根据开票类型生成公司间发票发票接收方是内部客户。价格方面主要靠条件类型PI01和PI02PI01用于公司间销售收入PI02用于公司间采购成本。两个条件类型在定价过程中缺一不可而且它们的取值必须和财务核算逻辑一致。很多配置团队在这里忽略“输出确定”。公司间发票的打印、PDF发送、通过IDOC发送给下游全靠在输出类型里设置输出条件。没有配输出发票只存在于系统里对方公司可能什么都收不到。3.3 MM侧跨公司采购订单、STO移动类型与收货跨公司采购订单和普通PO的区别在于采购组织可以属于销售公司但工厂属于另一个公司代码。系统通过“公司代码不同”这个条件自动触发公司间开票逻辑。配置时要确保采购凭证类型支持“跨公司代码”标识否则PO建不到别的工厂头上。STO方案里移动类型和收货逻辑是核心。发货过账用STO发货移动类型收货过账用101系列系统会自动产生公司在途库存和在途负债。跨公司STO追求的是“发货方有收入、收货方有成本”的效果内部收入通过公司间发票实现并不是把存货白送。多角交易中经常有直发场景B的工厂发完货不是运给A的仓库而是直接发到A的客户。为了减少中间库存SD交货单可以直接从B工厂过账同时MM里A做虚拟收货。这个“虚拟收货”要在交货类型和工厂参数里配很多实施项目在UAT阶段才发现问题。3.4 FI/CO侧往来科目、利润中心、外币评估公司间交易的往来科目建议单独使用内部结算科目不要跟普通应收应付混在一个统驭科目里。比如“内部应收—关联公司”“内部应付—关联公司”这样月末用FBL3N/FBL1N导出内部往来对账和抵消都有抓手。如果集团要按利润中心考核收入、成本、库存都要落到正确的利润中心最好在单据层用“利润中心派生规则”自动填充不要依赖用户手工填写。多角交易链条很长手工填很容易填错最后CO报表口径到处都是洞。外币评估配置在跨币种公司代码之间尤其重要。A公司本位币是人民币B公司本位币是美元A对B的应收美元到月末会形成未清外币项。必须用外币评估程序FAGL_FC_VALECC里是F.05按期末汇率评估汇兑损益并且在配置里指定汇率差异科目。否则内部往来余额永远对不上合并报表时差异全堆在未分配利润。涉及成本核算时公司间转账也要注意成本构成分解。内部结算金额进入存货或成本时要作为初级成本要素处理否则容易出现“成本要素没有分配给成本构成”这类报错物料分类账一激活就满地是雷。3.5 集成侧IDOC关联交易凭证与接口多角交易如果走系统间集成公司间采购订单和公司间发票通常通过IDOC传输。ORDERS消息类型传递销售订单/采购订单INVOIC消息类型传递发票。配置点集中在WE20伙伴参数文件、WE21端口、WE30消息类型和基本类型分配以及NACE销售凭证输出控制。“关联交易IDOC凭证”是我见过搜索量很高的词说明实际项目里IDOC出问题的概率不低。最常见的是发送方已经生成了IDOC但接收方因为主数据不完整或凭证类型不匹配无法自动过账。排查时用WE02看IDOC状态重点检查接收方的客户/供应商主数据是否包含公司代码视图、是否有对应的销售订单或采购订单。如果外围系统要接收各家公司的会计凭证就要提前写接口功能说明书。多角交易的凭证往往不是单一凭证而是几张凭证通过关联号绑定。设计接口时最好把“公司间参考号”作为主键否则外围系统追不到来龙去脉。4. 多角交易最容易踩的坑现场排查实录4.1 收入成本错位毛利润出现在错误的公司多角交易里最让人头疼的是毛利润失真。A公司给客户开票十几万成本却等于B公司按标准价结转的几万中间差额被当成A的毛利实际上里面混合了B的生产成本和集团内部利润。这个问题通常出在公司间价格设置上。PI01和PI02如果没有按“成本加成”或“转移价格”逻辑维护A的收入就会包含B应体现的利润。更合理的做法是公司间结算价采用标准成本加成比例让生产和销售两家公司各吃一段毛利。如果集团不要求内部利润就统一用标准成本作为公司间结算价事后在合并报表层面抵消。4.2 关联交易IDOC凭证报错逻辑系统与伙伴参数有一个项目公司间PO已经在A系统创建了B系统却一直收不到采购员只能手工补建一张PO。查下来发现A系统的逻辑系统名称和B系统伙伴参数里的对端逻辑系统不一致IDOC在发送时队列一直重试失败。这类问题要按三层排查第一逻辑系统配置是否全局一致第二WE20伙伴参数文件里消息类型和基本类型是否配对第三接收方主数据是否完整。三样都对IDOC才会自动过账。4.3 物料分类账连接缺失跨公司实际成本下传当公司代码启用了物料分类账多角交易会把多级差异从上游带下来。C的标准价是10元实际采购价是12元发给B的物料如果按10元结算B的生产成本就少计2元B再发给A的成品价格又基于10元差异层层滚雪球。所以在方案阶段就要设计好实际成本是否可以跨公司代码流转。如果系统报“物料至物料分类帐的连接缺失”一般是因为相关工厂或公司代码未统一激活物料分类账或者跨公司转移时移动类型的差异分配逻辑没维护。这不是一个事务码能解决的要回到配置整体视图。4.4 外币未清项清账与评估还有一家公司审计时发现内部应收应付两边余额差了一大截。原因是两边的本位币不同A记账时按汇率折算成本位币B记账时也按记账当天汇率折算到月末汇率一变未清项的价值就出现偏差。解法是月末统一做外币评估同时在内部往来对账时不要按“本位币余额”逐笔对而按“原币金额汇率”对。如果内部结算币种能统一建议所有关联交易都用同一种币种外币评估只在公司报表层面做这个坑能少一半。4.5 权限、审批与期初数据切换用户打不开公司间销售订单界面第一反应通常是没有权限。查了PFCG角色事务代码在但用户主数据里的默认销售组织是空白的导致界面根本带不出公司间订单类型。PFCG配的是“能用的权力”默认参数配的是“进去以后看到什么”两个都要对。审批流也一样。销售订单审批过程中系统生成跨公司PO的动作是等审批结果的如果审批流停住下游什么都等不到。SAP Workflow配置要跟MD07缺料检查、可用性检查串起来否则只能靠业务追单。期初数据切换要区分年末上线和年中上线。1月1日切换主要导入期初库存和往来余额采购订单/销售订单可以重建7月1日切换必须导入未清PO、未清销售订单、在途库存和未清内部往来否则业务链会断在“历史单据”上。多角交易尤其要注意内部往来未清项两边公司要同步导入导入后原币和本位币余额都要核对。5. 我最后的选型建议5.1 一个优先推荐组合如果业务上没有特别的税务和法务要求我一般优先推荐“外部销售订单跨公司采购订单公司间销售订单”的组合也就是方案A作为主链内部库存调拨用STO。理由很简单它是SAP最成熟、最可预期的路径后续月结、审计、合并报表的阻力最小。但如果链条里有超过三家法人中间那几家只是过票我会强烈建议适当引入寄售/代销把多层发票压到两层。这需要财务总监和税务顾问点头但一旦达成共识系统运行成本能明显下降。5.2 上线前必须跑通的测试闭环上线前别急着铺数据先把闭环跑通创建最终客户订单看系统是否自动生成跨公司PO供应商一方生成公司间销售订单做交货和发货过账生成公司间发票内部客户收货和发票校验最终客户开票最后做收款清账和内部往来对冲。每一步用FBL3N/FBL1N/FBL5N查凭证重点看公司间往来科目是否平衡。我还会额外跑一遍“多角链的冲销场景”。退货、价格重开、红蓝票在单边公司发生的情况三家公司是否都能联动冲销。很多项目正流程通了冲销流程全乱套上线后客退单变成灾难现场。5.3 一点个人体会做这种方案讨论我最深的体会是三句话先别谈配置先谈货权每次只增加一个公司代码不要指望一步到位内部交易的价格条件必须当作财务制度来管。多角交易本质上不是IT问题是利益分配问题。系统能帮你把每一段的账记得清清楚楚但前提是业务愿意把“谁赚哪一段”这件事摆在桌面上说清楚。