子公司使用 SAP Cloud ERP（公有云），总部使用 SAP S/4HANA
双层 ERP 在 PPT 上听起来很简单：总部保留大型 S/4HANA，子公司用更轻量的 Cloud ERP，中间由集成层保持同步。 但真正的工作量，全在"保持同步"这几个字里。
本文用一个完整、可运行的例子——公司间采购到付款 / 订单到收款流程——讲解如何只用 SAP 标准 API，借助 SAP BTP Integration Suite 和 SAP Event Mesh 把它搭起来。
1. 什么是双层 ERP？什么时候适用？
| 单层 ERP | 双层 ERP | |
|---|---|---|
| 架构 | 总部和所有子公司共用一套 ERP | 总部一套核心 ERP + 子公司一套轻量、标准化的 ERP |
| 优点 | 数据唯一来源，管理简单 | 新实体上线快，更贴合本地需求 |
| 缺点 | 新实体接入慢；小公司被迫使用"重"系统 | 需要集成层，以及跨系统的主数据治理 |
典型的触发场景：需要快速上线 ERP 的并购或分拆、未来可能出售的合资公司、区域扩张、各地子公司系统分散，以及监管 / 数据驻留要求。
典型架构：
- 第一层——总部： SAP S/4HANA（私有云或本地部署），负责合并报表、全球科目表、主数据权威。
- 集成层——SAP BTP： 基于 API 和事件驱动的集成。
- 第二层——子公司： SAP S/4HANA Cloud 公有云版，标准流程、本地合规、快速上线。
2. 示例场景：子公司向总部采购
子公司向总部采购物料。六张单据，三次自动传递：
子公司（Cloud ERP） BTP 总部（S/4HANA）
1 采购订单 ──────────────► 映射 ──────────► 2 销售订单
4 收货 ◄────────────── 映射 ◄────────── 3 交货 + 发货过账
6 供应商发票 ◄────────────── 映射 ◄────────── 5 开票凭证
| 传递 | 触发 | 模式 |
|---|---|---|
| 采购订单 → 销售订单 | 子公司保存 PO，PO 输出被发送 | 消息触发：PO 消息推送到 BTP，映射后调用总部的销售订单 API |
| 发货过账 → 收货 | 总部完成发货过账 | 事件驱动：状态变化触发事件，BTP 通过 API 读取明细，在子公司过账收货 |
| 开票 → 供应商发票 | 总部创建开票凭证 | 事件驱动：同样模式，BTP 在子公司创建供应商发票 |
部分交货也能自然处理：总部 100 件只发 70 件，子公司就收货 70 件，发票也按实际开票数量过账。
3. 使用的标准 API
都可以在 SAP Business Accelerator Hub（api.sap.com）上找到，包括 Schema：
| 步骤 | API | 方向 |
|---|---|---|
| 发送采购订单 | Purchase Order – Send（异步出站） | 子公司 → BTP |
| 创建销售订单 | API_SALES_ORDER_SRV（Sales Order A2X） |
BTP → 总部 |
| 读取交货单 | API_OUTBOUND_DELIVERY_SRV |
BTP ← 总部 |
| 读取开票凭证 | API_BILLING_DOCUMENT_SRV |
BTP ← 总部 |
| 创建收货 | API_MATERIAL_DOCUMENT_SRV |
BTP → 子公司 |
| 创建供应商发票 | API_SUPPLIERINVOICE_PROCESS_SRV |
BTP → 子公司 |
在公有云一侧，入站 API 通过**通信安排（Communication Arrangement）**开放。每个 API 在 Business Accelerator Hub 上的页面都会说明它属于哪个通信场景。
4. 搭建步骤
第 1 步——先把业务设计定下来
集成只能自动化一个已经设计好的流程。在做任何 iFlow 之前：
- 公司间关系： 总部在子公司系统里是供应商；子公司在总部系统里是客户。
- 单据类型： 子公司使用专用的采购订单类型、总部使用专用的销售订单类型，便于监控。
- 价格： 以谁为准——PO 价格还是总部定价？先定规则，再做映射。
- 字段映射表： 客户 ↔ 供应商编号、物料号、工厂、库存地点、计量单位、销售范围。把它当作业务文档来维护，而不是只藏在代码里。
第 2 步——准备 BTP
- 一个开通了 Integration Suite（Cloud Integration 能力）和 Event Mesh 的 BTP 子账户。
- 两个系统的凭证和证书（OAuth 或基本认证；信任证书）。
- 如果总部是本地部署，需要 Cloud Connector 做安全连接。
第 3 步——准备子公司（Cloud ERP）
- 创建通信用户、通信系统（代表 BTP），以及入站 API 的通信安排：收货（物料凭证）和供应商发票。
- 采购订单输出管理： 配置 PO 输出，使发给总部供应商的订单以电子方式发送到 BTP，而不是打印或发邮件。
第 4 步——准备总部（S/4HANA）
- 开放所需 API（创建销售订单；读取交货单和开票凭证）。
- 事件启用： 当交货单完成发货过账、开票凭证创建时，从 S/4HANA 向 Event Mesh 发布业务事件。
- 另一种做法： 不用事件，而是在交货单上配置输出类型（例如发货通知 ASN），通过 SOAP Proxy 推送消息。如果只需要一个触发信号、明细本来就要通过 API 读取，事件方式更简洁。
第 5 步——开发集成流（iFlow）
四个 Artifact 覆盖整个场景：
a. PO → SO 接收 PO 报文 → Message Mapping（PO Schema → 销售订单 Schema，都从 API Hub 导入）→ 调用销售订单 API。
- 用 HTTP 发送 JSON 时，需要先获取 CSRF Token；用 OData Adapter 则由适配器处理。两种都可行，是设计选择。
b. Event Router（事件路由） 一个 iFlow 通过 AMQP Adapter 订阅 Event Mesh 队列，读取事件的 type 和 status，然后分流：
- 发货过账完成的交货事件 → 收货流程；
- 开票事件 → 供应商发票流程；
- 其他 → 忽略。 把路由逻辑集中在一处，业务流程就不必各自理解事件。
c. 发货过账 → 收货 事件只是触发信号，不包含所需的全部数据。所以：
- 通过交货单 API 读取交货单。
- **拆分（Split）*行项目；每一行读取总部销售订单，找到客户参考号*，也就是子公司的 PO 号。
- **汇总（Gather）**各行，映射为物料凭证结构，在子公司针对原 PO 过账收货。
d. 开票 → 供应商发票 同样的模式：读取开票凭证，找到 PO 参考，映射，参照 PO 创建供应商发票（这样三单匹配才能生效）。
流程 (c) 和 (d) 由路由器通过 ProcessDirect 调用（同一租户内 iFlow 之间的快速内部调用）。
第 6 步——端到端测试
- 全部交货、部分交货、多行项目，以及取消场景。
- 检查会计凭证：收货借记库存、贷记 GR/IR 清算科目；供应商发票再清掉 GR/IR。
- 检查可追溯性：总部销售订单的客户参考号 = 子公司 PO 号；PO 历史中能看到收货和发票。
第 7 步——监控与异常处理
- 在 Integration Suite 的 Monitor → Integrations and APIs 中，可以看到每条消息的源报文、过账报文和结果。
- 明确由谁监控失败消息、如何重处理——这是运维流程，而不只是一个技术设置。
5. 实际搭建中的经验
- 不要硬编码组织数据。 演示时很容易把工厂、库存地点、移动类型写死。正式项目应使用 Value Mapping 或外部参数表，新增工厂时不用改 iFlow。
- 计量单位映射很容易出错。 经典错误：单位代码（"PC"）被映射进数值字段。数量和单位分开映射，并用所有实际用到的单位测试。
- 业务错误看起来像技术错误。 收货失败，可能是因为 PO 已全部收货或会计期间已关闭。监控要能显示业务报错信息，而不只是"HTTP 400"。
- 防止重复过账。 同一个事件如果被投递两次，绝不能生成两张收货。过账前先检查单据是否已存在。
- 集成是长期流程，不是一次性项目。 两个系统按各自的节奏升级，要为接口保留回归测试。
- 主数据治理决定成败。 一旦物料号或合作伙伴编号不一致，所有接口都会出错。要明确谁负责哪类主数据、如何分发（规模较大的架构可以了解 SAP Master Data Integration）。
6. 延伸阅读（官方）
- SAP Business Accelerator Hub——API 规格和预置集成内容。
- SAP Help Portal——SAP Integration Suite（Cloud Integration）与 SAP Event Mesh 文档。
- SAP 官方关于 S/4HANA Cloud 公有云版双层 ERP 的资料。