SAP S/4HANA 集成 新一代 ERP 对账

摘要：SAP S/4HANA 是 SAP 在 ECC 之后主推的新一代 ERP，2015 年首发、2023 年把 ECC 推入「延伸维护」、2027 年 ECC 标准维护彻底停止——任何还有 ECC 的大中型企业，未来 18 个月内必须做一次 SAP S/4HANA 的选型与对接。但 SAP S/4HANA 不是「升级」，是「重做」：① 数据模型从行存储改为列式 CDS View + RAP 编程模型，② API 体系从 BAPI/IDoc/RFC 升级为 OData V2/V4 + SAP Business Technology Platform（BTP），③ 集成从 SAP PI/PO 双堆栈迁到 SAP Integration Suite。本文用 SAP S/4HANA 与 SAP ECC 的 6 维对比表，给 CTO / ERP 实施一份完整的对账接入路径，结尾给出 4 步对接 + 5 步验收清单。

关键词：SAP S/4HANA、新一代 ERP、对账接入、OData V4、SAP BTP、CDS View、RAP、Fiori、Integration Suite

月底 23:50 的那一通紧急电话

「SAP 那边说 ECC 标准维护到 2027 年就停了，我们公司还在 ECC 上跑着，能不能帮我们直接对接到 S/4HANA 上？原来的 BAPI 还能用吗？」

2026 年以来，SAP 用户群在集成中心做对账接入时遇到的问题和电商业务完全不同。电商客户关心的是「京东/抖店/亚马逊的账怎么跟金蝶对」，SAP 客户关心的是「S/4HANA 这套全新的内存数据库 + 列式存储 + CDS View，我们原来的 SAP ERP 接口知识是不是全部作废了」。答案先放在前面：不是全部作废，但绝大部分要重做。

SAP S/4HANA 不是一个「新版本」，而是一套新的产品线：底层数据库从「AnyDB（Oracle/DB2/SQL Server/MaxDB）」迁到专有的 SAP HANA 内存数据库；数据模型从「行存储 + 透明表」迁到 CDS View（Core Data Services）+ 列存储；业务对象建模从 BAPI + IDoc 迁到 RAP（RESTful ABAP Programming Model）+ OData V4；集成层从 SAP PI/PO（Process Integration/Orchestration） 迁到 SAP BTP（Business Technology Platform）+ Integration Suite。

任何一个 SAP 客户如果今天还在用 ECC + SAP PI/PO + BAPI 跑对账，那么切换到 S/4HANA 时，所有 handler、字段映射、签名逻辑、ETL 脚本都要按新的数据模型 + API 体系重写一遍。下面把这件事讲透。

一、SAP S/4HANA 是什么：与 ECC、Cloud、B1 的关系

「我们公司用的是 SAP 还是 SAP S/4HANA？两者能通用一套对接吗？」这是 SAP 客户在集成中心做对账接入时被问到最多的问题。答案和上节一样：不能通用。SAP S/4HANA 与 SAP ECC、SAP S/4HANA Cloud、SAP Business One 是四条并列的产品线，定位完全不同：

「SAP S/4HANA（On-Premise）」与「SAP S/4HANA Cloud」的区别关键在于部署模式：前者部署在客户自己的数据中心或私有云（IaaS），后者部署在 SAP 自己的公有云（SaaS）。On-Premise 版本允许深度定制（Customer-Specific CDS View / 自定义 RAP BO），Cloud 版本受 SAP 管控（不允许底层修改，扩展走 SAP BTP 的 Side-by-Side 模式）。对账场景下，On-Premise 版的集成自由度远高于 Cloud 版，因为后者不能直接往 S/4HANA 数据库写自定义表，所有扩展必须通过 SAP BTP 走。

ECC 用户最常问的一个问题是：「能不能把 ECC 的 BAPI 直接迁到 S/4HANA 上？」——不能。BAPI 函数层在 S/4HANA 中已经被 RAP BO 取代，原有 BAPI 大部分保留为「兼容性包装层」（compatibility layer），但调用方式、字段语义、性能特性都已变化。经验数据：从 ECC BAPI 迁到 S/4HANA OData V4，平均需要重写 60-70% 的字段映射代码（来源：2026-Q2 三家 ECC → S/4HANA 迁移实测）。

二、SAP BTP：取代 SAP PI/PO 的新一代集成中台

SAP ECC 时代的对账集成主要靠 SAP PI/PO（Process Integration / Process Orchestration）做中间件：把 SAP 内部 BAPI/IDoc 包装成 WebService，挂到 SOAP/HTTP 上，再让外部系统通过 SOAP 调用。这种集成在 ECC 时代是行业标配，但放到云原生时代有三个根本问题：

1. 每请求都要 PI/PO 路由：一次 PULL 1000 张会计凭证要走「外部 → PI 适配器 → ECC BAPI → PI 路由 → 外部」五跳，平均延迟 800-1500ms；
2. 协议单一：PI/PO 强项是 SOAP/XML，到云原生 REST/OData 场景需要额外做适配；
3. 不能与现代 DevOps 协同：PI/PO 是基于 SAP NW 的一整套重型中间件，不能用 GitHub Actions / GitLab CI 做部署。

SAP 在 2018 年把 PI/PO 路线正式弃用，主推 SAP Business Technology Platform（BTP） 作为新一代集成中台。BTP 是一组云服务的集合，集成相关的核心组件是 SAP Integration Suite（包含 Cloud Integration / API Management / Open Connectors / Integration Advisor 四个子模块）：

对账场景下，BTP 提供了两个 SAP 官方维护的标准集成包：

• SAP S/4HANA Cloud 的 Standard Integration：SAP 官方维护的预制集成流（iFlow），覆盖财务（FI）、供应链（MM/SD）、主数据（BP）等核心场景，可一键部署；
• SAP API Business Hub：所有 SAP 标准 API 的目录（OData V2/V4、SOAP、SOAP-on-JMS 等），可在线试用并生成 SDK 代码。

实际接入路径有两种：

• 路径 A：直连 S/4HANA On-Premise——绕开 BTP，直接在 SAP Gateway 上把 CDS View 暴露为 OData 服务，集成中心用 OAuth 2.0 Client Credentials 调用。优点是链路短、延迟低；缺点是每个 CDS View 都要在 SAP Gateway 里手动注册成 OData 服务，且客户要自己维护 OAuth Client。
• 路径 B：经 SAP BTP Integration Suite——所有 SAP 内部 API 经 Cloud Integration 流出来，挂到 API Management 网关，集成中心调网关。优点是有 SAP 标准集成包、协议适配全；缺点是多一跳、QPS 高时成本上升。

对账场景下（高频 PULL + 中频 PUSH），推荐路径 A（直连 On-Premise），路径 B 用在 Cloud 版或异构系统多跳场景。

集成中心的整体架构与金蝶/用友/SAP 都同源——「PULL 拉取 + 集成转换 + PUSH 推送」三段式：

三、S/4HANA API 选型：OData V4 vs BAPI vs IDoc

「S/4HANA 上有 BAPI 吗？我们要不要继续用 BAPI？」——SAP ECC 时代的老兵最常问的第二个问题。答案是：S/4HANA 上 BAPI 仍然存在（作为兼容层），但 SAP 官方明确建议「所有新的集成走 OData V4 + RAP」。

实操推荐：对账集成一律走 OData V4。下面是 S/4HANA 财务凭证（AccountingDocument）的标准 OData V4 请求示例：

// SAP S/4HANA Cloud Public Edition - Accounting Documents
GET https://myXXXXXX.sapbydesign.com/sap/byd/odata/v4/accountingdocumentservice/AccountingDocument
  ?$filter=CompanyCode eq '1010' and PostingDate ge datetime'2026-09-01' and PostingDate le datetime'2026-09-30'
  &$select=AccountingDocument,CompanyCode,PostingDate,Supplier,Customer,AmountInCompanyCodeCurrency
  &$expand=AccountingDocumentItem($select=AccountingDocumentItem,GLAccount,AmountInCompanyCodeCurrency,DebitCreditCode)
  &$top=500
Headers:
  Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
  Accept: application/json
  OData-Version: 4.0
  OData-MaxVersion: 4.0

返回的响应是嵌套 JSON，财务凭证头 + 分录行一次拉齐——这与金蝶的「应收单 + 分录 + 关联关系四元组」结构同构，但 SAP 的优势是 $expand 可一次拉多层、避免多次请求。

四、认证：OAuth 2.0 取代 SAP Logon Ticket

S/4HANA 的认证体系比金蝶云星空复杂一些，但比 SAP ECC 时代简化了——SAP 用 SAP Identity Authentication Service（IAS） 和 SAP Identity Provisioning Service（IPS） 把所有认证统一到 OAuth 2.0 / SAML 2.0 / X.509 三选一：

// Step 1 · 获取 access_token（用 Client Credentials）
POST https://<tenant>.authentication.sap.hana.ondemand.com/oauth/token
Headers:
  Content-Type: application/x-www-form-urlencoded
  Authorization: Basic <base64(clientId:clientSecret)>
Body:
  grant_type=client_credentials
  scope=API_BUSINESS_PARTNER_0001.read S4HANA_ODATA_0001.read

// Step 2 · 用 access_token 调用 S/4HANA API
GET /sap/opu/odata4/sap/api_accountingdocument/srvd_a2x/sap/accountingdocument/0001/AccountingDocument
Headers:
  Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
  OData-Version: 4.0

三件值得拎出来说的事：

第一件：IAS 是 SAP BTP 的「Identity Provider」，所有 SAP Cloud 产品统一认证。S/4HANA Cloud、SuccessFactors、Ariba、Concur 等都挂在同一个 IAS 下做 SSO。对账集成的 OAuth Client 必须在 IAS 上注册，而不是在 S/4HANA 内部。

第二件：scope 粒度细到「业务对象 + 操作 + 字段」。API_BUSINESS_PARTNER_0001.read 表示「业务伙伴主数据可读」，但 SAP 还允许进一步细到「只能读 company code 1010 的数据」——这种细粒度授权来自 IAS 的「Authorization Scope」配置。对账场景下的最佳实践是：PULL handler 拿 .read scope 的 token，PUSH handler 拿 .write scope 的 token，集成转换脚本拿 transform scope。

第三件：X.509 客户端证书仍可用——S/4HANA On-Premise 版的 RFC/BAPI 调用场景下，X.509 比 OAuth 2.0 更稳定，因为不需要 IAS 中转。SAP PO/PI 时代的老客户如果还在用 SNC 证书，可以平滑迁移到 mTLS（mutual TLS）。

五、集成中心的 SAP handler 设计

集成中心下挂 handler 的全貌——金蝶云星空已有 9 个 HMAC 版 handler；SAP S/4HANA 需要在 kingdee-cloud-galaxy 之外新增 9 个 OAuth 2.0 版 handler，命名空间隔离为 sap-s4hana：

下面给出 SAP S/4HANA handler 的 9 个推荐清单（按金蝶云星空 handler 镜像）：

每个 handler 的 execute() 方法都是「协议层（OAuth 2.0 + IAS 凭证 + IAS scope 申请）→ ETL（SAP CDS View 字段映射）→ 落库（标准化 transform_documents 头表 + 体行表）」三段式。

对账场景下，handler 的最大价值不在协议封装本身（OAuth 2.0 客户端每个云服务都能写），而在于把 SAP 那套重型业务对象模型（BO / CDS View / RAP）压平到对账系统能直接消费的轻量 schema 上——这是「集成中心」作为对账基础设施的核心价值，也是轻易云智能对账系统「多 ERP 同构」策略的落地：同一份对账结果能直接 PUSH 到 SAP S/4HANA，也能 PUSH 到金蝶云星空、用友 YonBIP，业务侧不需要为每个 ERP 重写对账脚本。

六、集成转换脚本：从 SAP CDS View 到 transform_documents

SAP CDS View 字段命名遵循「数据元素 + 业务对象」的强类型规范（如 AccountingDocument.CompanyCode、AccountingDocumentItem.AmountInCompanyCodeCurrency），与中文财务习惯不同。集成转换脚本要把这些字段映射到标准化的中文核算项目名称，让这个接口读得懂下游的核算项目体系：

集成转换流程图展示 SAP 字段从 SAP CDS View 经过集成转换脚本（脚本沙箱内运行）变成 transform_documents 头表 + 体行表的全过程：

下面是 SAP S/4HANA 集成转换脚本（scriptKind = INCOME）的一段伪代码骨架：

// === transform_sap_s4hana_income.js ===
// scriptKind: INCOME（收入转换）
// 入口：transform(input) 接收 SAP CDS View 字段映射后的标准化数据
// 出口：返回 documents[] 数组，每个元素 = 一个 transform_documents 头表 + 体行

export default async function transform(input) {
  const { accountingDocuments, companyCode, fiscalPeriod } = input;
  
  // 1. 按 GLAccount + 公司代码聚合：SAP 的 AC_DOC_TYPE + AC_DOC_NO 是天然聚合键
  const groups = new Map();
  for (const doc of accountingDocuments) {
    const key = `${doc.CompanyCode}-${doc.AccountingDocumentType}-${doc.GLAccount}`;
    if (!groups.has(key)) {
      groups.set(key, {
        docType: 'AR_receivable',          // SAP 也复用 AR_receivable 命名
        head: {
          companyCode: doc.CompanyCode,
          accountingDocType: doc.AccountingDocumentType,  // KZ / KZ-BUKRS / DG / DA
          documentDate: doc.DocumentDate,
          postingDate: doc.PostingDate,
          fiscalPeriod: doc.FiscalPeriod,
          reference: doc.AccountingDocument,         // SAP 凭证号
          userName: doc.UserName,
          currency: doc.CompanyCodeCurrency,
          // ... 头表 10+ 字段
        },
        lines: [],
      });
    }
    const g = groups.get(key);
    g.lines.push({
      glAccount: doc.GLAccount,
      amount: doc.AmountInCompanyCodeCurrency,
      debitCreditCode: doc.DebitCreditCode,         // 'S' 借 / 'H' 贷
      assignment: doc.AssignmentReference,
      customer: doc.Customer,
      supplier: doc.Supplier,
      costCenter: doc.CostCenter,
      profitCenter: doc.ProfitCenter,
      material: doc.Material,
      // ... 体行字段
    });
  }
  
  // 2. SAP 配平不变式：每个凭证的借方合计 = 贷方合计（绝对值相等）
  //    转换脚本必须做此校验，违反则 throw 由 run-sync 报告 FAILED
  for (const g of groups.values()) {
    const debitSum = g.lines.filter(l => l.debitCreditCode === 'S')
                            .reduce((s, l) => s + Math.abs(l.amount), 0);
    const creditSum = g.lines.filter(l => l.debitCreditCode === 'H')
                             .reduce((s, l) => s + Math.abs(l.amount), 0);
    if (Math.abs(debitSum - creditSum) > 0.01) {
      throw new Error(`SAP 凭证 ${g.head.reference} 借贷不平：借 ${debitSum} vs 贷 ${creditSum}`);
    }
  }
  
  // 3. 返回 documents 数组（integrated transform 沙箱标准输出）
  return {
    documents: Array.from(groups.values()),
  };
}

三个值得拎出来说的设计选择：

选择一：按 (CompanyCode + AccountingDocumentType + GLAccount) 三元组聚合。SAP S/4HANA 的财务凭证以「AC_DOC_NO（凭证号）+ AC_DOC_TYPE（凭证类型）」为主键，但下推到对账系统时，收入应收按客户 + GLAccount 聚合才符合电商财务场景——一笔凭证里同一个客户的多个分录可以合并出单，下游对账只看「客户 × 期间」汇总。

选择二：借贷方向硬校验。SAP 的会计恒等式是「每张凭证借方合计 = 贷方合计」，这是 GAAP 强制约束。转换脚本必须做此校验，违反直接 FAILED 由 run-sync 报告——这与金蝶云星空的「配平不变式」一致，是任何严谨 ERP 对账集成都不能省的硬校验。

选择三：凭证号（AccountingDocument）作为 reference。SAP 凭证号是 10 位数字字符串（受 NUMC 类型约束），作为外部单号回写到对账系统，下游做 SAP 推送时可作为幂等键避免重复推送。

转换后的 transform_documents 会在转换单据全局表里与金蝶/用友/SAP 等所有 ERP 的转换单据一起展示：

七、4 步对接路径 + 5 步验收清单

把上面的内容串起来，给一份可直接执行的 SAP S/4HANA 对账接入路径：

4 步对接路径：

1. SAP 侧准备（1-2 周）——SAP Basis 顾问在 S/4HANA 系统里启用 OData V4 服务，把需要对接的 CDS View（AccountingDocument / SupplierInvoice / BillingDocument 等）通过「服务绑定（Service Binding）」+「SAP Gateway」发布为 OData V4 URL；同时在 SAP IAS 上注册 OAuth 2.0 Client，分配对应 scope。
2. 集成中心 handler 落地（2-3 周）——按上面 9 个 handler 清单创建 SAP S/4HANA 集成方案的目录（命名空间 sap-s4hana），每个 handler 实现「OAuth 2.0 凭证申请 → OData V4 请求 → 标准化 ETL → 落 transform_documents」四步。client 层封装 IAS 凭证缓存（access_token 2 小时有效期内的复用）。
3. 集成转换脚本编写（1 周）——按「INCOME / EXPENSE」两类分别写转换脚本（scriptKind 严格分离），按 (CompanyCode + AccountingDocumentType + GLAccount) 聚合，校验借贷平衡，处理汇率/币种/会计期间等本地化口径。
4. 联调与上线（1-2 周）——用一个真实账期（如 2026-09）的数据 PULL 一次会计凭证到本地表；用一个虚拟凭证 PUSH 一次到 S/4HANA；记录 PULL/PUSH 成功率、P95 延迟、字段映射准确率三个核心指标。

5 步验收清单（上线前必跑）：

1. OAuth 2.0 凭证申请成功率 ≥ 99%——把 IAS 返回的 access_token 缓存到 Redis，2 小时过期自动续签；连续 3 次申请失败触发告警。
2. PULL 会计凭证字段映射准确率 ≥ 99.5%——选一个完整账期（如 2026-08）的数据，对比 S/4HANA 原始凭证 vs 落库的 transform_documents 头表，字段差异行数 < 0.5%。
3. PUSH 会计凭证幂等性验证——同一张凭证连续 PUSH 3 次，S/4HANA 侧只生成 1 张新凭证（凭证号 AccountingDocument 作为幂等键）。
4. 借贷平衡校验 100% 通过——转换脚本对所有 PUSH 的凭证做借贷平衡校验，违反直接 FAILED。
5. P95 性能达标——PULL 1000 张凭证耗时 < 5s；PUSH 100 张凭证耗时 < 8s。

八、写在最后

SAP S/4HANA 是 SAP 在 ECC 之后 10 年的新平台。从 ECC 到 S/4HANA 不是「升级」，而是「重做」——数据模型、API 体系、认证协议、集成中间件四个层面都换了一遍。对账场景下，最大的隐性成本不是协议切换本身，而是 ECC 时代积累的 BAPI/IDoc/RFC 经验在 S/4HANA 上要全部重新学习。

文中涉及的 SAP BTP / OData V4 / CDS View / RAP / OAuth 2.0 等专有名词都是 S/4HANA 的「官方教材」用语，与 ECC 时代完全不同。正确的接入顺序是「先用 SAP 标准 API 包（BTP Integration Suite）跑通最小可用链路 → 再按业务场景逐步自定义 OData 服务」，避免一开始就陷入 CDS View / RAP 的技术细节里。

整个对账接入链路最终会落到集成中心，轻易云智能对账系统的「PULL × PUSH × 集成转换」三段式架构对 SAP S/4HANA 与金蝶云星空、Oracle Fusion 等所有主流 ERP 都同构——同一套集成中心能管多套 ERP，多个 ERP 的转换单据在一张全局表里混排——这是「集成中心」作为对账基础设施的核心价值。

如果你正在做 SAP S/4HANA 的对账接入，建议先把上面 4 步路径的第一步（S/4HANA 侧准备）跑通——这是 ECC → S/4HANA 迁移中最容易低估的环节，OData 服务发布的细致程度直接决定后续 handler 的复杂度。