SAP ECC 集成 传统 ERP 对账 迁移

摘要：SAP ECC（SAP ERP Central Component）是 SAP 在 R/3 之后推出的「上一代核心 ERP」——自 2004 年首发、随版本演进至 ECC 6.0 EHP8，至今仍在全球 30,000+ 大中型集团的核心生产环境里跑着。SAP 已官宣 ECC 标准维护到 2027 年彻底停止、延伸维护按订阅制付费到 2030 年。这意味着每一个还在 ECC 上的 SAP 客户，未来 12-36 个月里都要做一次「是否迁移到 S/4HANA」的决策。SAP ECC 与 SAP S/4HANA 的关键差异不是「升级」，而是「重做」：① 数据模型从「行存储透明表」迁到「CDS View + 列存储」，② API 体系从 BAPI/RFC/IDoc 迁到 OData V4 + RAP，③ 集成中间件从 SAP PI/PO 迁到 SAP BTP Integration Suite。本文给 CTO / ERP 实施一份完整的 ECC 对账接入路径——SAP JCo / SAP NCo 客户端、RFC / BAPI / IDoc 三大接口体系、SNC 认证体系、集成中心的 SAP ECC handler 清单、集成转换脚本骨架，以及 ECC → S/4HANA 的 4 种迁移路径 + 5 步验收清单。

关键词：SAP ECC、传统 ERP、对账接入、SAP RFC、BAPI、IDoc、SAP JCo、SAP NCo、SNC、ECC → S/4HANA 迁移、集成中心、集成转换

月底 23:50 的那一通紧急电话：ECC 客户的「另一类」难题

「我们公司还在 SAP ECC 上跑着，业务顾问说 ECC 标准维护 2027 年就要停了，让我们做 S/4HANA 迁移。我们现在的对账集成是 2018 年用 SAP JCo + BAPI 写的，能直接迁到 S/4HANA 上吗？」

2025 年以来，SAP 用户群在集成中心做对账接入时遇到的难题，与电商业务完全不同。电商客户关心的是「京东/抖店/亚马逊的账怎么跟金蝶对」，ECC 客户关心的是「SAP RFC / BAPI / IDoc 三大接口体系还能用多久？我们已经在 ECC 上跑 8 年的 SAP JCo 代码，能不能撑到迁移完成？」答案先放在前面：SAP JCo + BAPI 在 ECC 上还能跑几年没问题，但 S/4HANA 上不能直接用——这一点决定了 ECC 客户的迁移策略必须分两步走。

SAP ECC 的「传统」不是贬义词——它是 SAP 在 1992 年 R/3 之后推出的核心 ERP 继任者，整套产品理念都在 ECC 时代定型，全球前 500 强里有相当一部分企业的核心系统至今还在 ECC 6.0 EHP7/EHP8 上跑。SAP 自己在 ECC 时代建立的三大接口体系（RFC / BAPI / IDoc）已成为 SAP 集成的事实标准——任何做过 SAP 接口的工程师，开口就是「这是 BAPI 还是 IDoc？」。下面把这件事讲透。

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

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

三个最关键的对账集成差异：

差异一：BAPI/RFC/IDoc vs OData V4 + RAP。SAP ECC 的 API 主线是 BAPI（Business Application Programming Interface，业务应用编程接口）+ RFC（Remote Function Call，远程函数调用）+ IDoc（Intermediate Document，中间文档）——三套并列的接口体系，BAPI 用于「调用业务对象方法」、RFC 是底层传输协议、IDoc 用于「批量异步 EDI」。这套体系从 1990 年代 R/3 时代开始跑，到 ECC 时代已经被无数集成商「焊」在生产环境里。S/4HANA 的 API 主线就一条「OData V4 + RAP」——BAPI 在 S/4HANA 中保留为「兼容性包装层」，但调用方式、字段语义、性能特性都已变化。

差异二：SAP JCo / SAP NCo vs HTTP/OAuth 客户端。SAP ECC 的客户端是 SAP JCo（SAP Java Connector）或 SAP NCo（SAP .NET Connector）——SAP 官方维护的 RFC 协议客户端库，必须装在调用方应用服务器上，通过 jcoRFC 库发起 RFC 调用。S/4HANA 的客户端是任意 HTTP 客户端（curl / axios / fetch）——OData V4 是 HTTP/JSON 协议，不需要装任何 SAP 客户端库。

差异三：SAP PI/PO vs SAP BTP Integration Suite。ECC 时代的集成中间件是 SAP PI/PO（Process Integration / Process Orchestration）——SAP 自家的重型中间件，把 BAPI/IDoc 包装成 WebService，挂到 SOAP/HTTP 上。S/4HANA 时代 SAP 主推 SAP BTP（Business Technology Platform）+ Integration Suite——云原生的 iPaaS，OData V4 原生支持，OAuth 2.0 + X.509 双认证。

二、SAP ECC 三大接口体系：BAPI × RFC × IDoc

SAP ECC 的集成接口体系从 1990 年代 R/3 时代定型，是 SAP 集成工程师的「必修课」。三套接口各管一摊：

BAPI 是对账场景的核心接口。下面给出 SAP ECC 财务凭证（BAPI_ACC_DOCUMENT_POST）的一段 RFC 调用伪代码：

// === SAP ECC 财务凭证推送（SAP JCo Java 客户端） ===
// 入口：BAPI_ACC_DOCUMENT_POST 接收 documentheader + accountgl/accountpayable/accountreceivable 行表
// 出口：返回凭证号 OBJ_TYPE + OBJ_KEY + OBJ_SYS

JCoDestination dest = JCoDestinationManager.getDestination("ECC_PROD");
JCoFunction fn = dest.getRepository().getFunction("BAPI_ACC_DOCUMENT_POST");
if (fn == null) throw new RuntimeException("BAPI_ACC_DOCUMENT_POST 未在 SAP 端发布");

// 1. documentheader：凭证头
JCoStructure header = fn.getImportParameterList().getStructure("DOCUMENTHEADER");
header.setValue("USERNAME", "JCO_SYNC_USER");
header.setValue("COMP_CODE", "1010");        // 公司代码
header.setValue("DOC_TYPE", "KZ");           // 凭证类型 KZ=供应商发票 / DG=客户发票 / DA=客户贷项
header.setValue("PSTNG_DATE", "20260925");   // 过账日期
header.setValue("DOC_DATE", "20260925");     // 凭证日期
header.setValue("FISC_PERIOD", "9");         // 会计期间
header.setValue("FISC_YEAR", "2026");        // 会计年度
header.setValue("REF_DOC_NO", "RECON-202609-0042"); // 外部参考号（对账系统单号）

// 2. accountgl：总账行
JCoTable gl = fn.getTableParameterList().getTable("ACCOUNTGL");
gl.appendRow();
gl.setValue("ITEMNO_ACC", "1");
gl.setValue("GL_ACCOUNT", "6001010");        // 总账科目（管理费用）
gl.setValue("DEBIT_CREDIT_CODE", "S");      // S=借 / H=贷
gl.setValue("AMOUNT_DOC", new BigDecimal("12345.67"));
gl.setValue("COSTCENTER", "CC-1010-001");
gl.setValue("PROFIT_CTR", "PC-1010-001");

// 3. accountreceivable：应收行（客户）
JCoTable ar = fn.getTableParameterList().getTable("ACCOUNTRECEIVABLE");
ar.appendRow();
ar.setValue("ITEMNO_ACC", "2");
ar.setValue("CUSTOMER", "CUST-2024-001");
ar.setValue("DEBIT_CREDIT_CODE", "S");
ar.setValue("AMOUNT_DOC", new BigDecimal("12345.67"));

// 4. 执行 BAPI
fn.execute(dest);

// 5. 检查返回
JCoStructure returnStruct = fn.getExportParameterList().getStructure("RETURN");
if (!"S".equals(returnStruct.getString("TYPE"))) {
    throw new RuntimeException("BAPI 失败：" + returnStruct.getString("MESSAGE"));
}
String objType = fn.getExportParameterList().getString("OBJ_TYPE");
String objKey = fn.getExportParameterList().getString("OBJ_KEY");
String objSys = fn.getExportParameterList().getString("OBJ_SYS");
// objKey 即 SAP 凭证号，作为幂等键回写到对账系统

IDoc 是 ECC 上批量场景的「另一条路」。与 BAPI 的「函数式同步调用」不同，IDoc 是「中间文档」——ECC 把要传输的业务文档（订单、发票、付款凭证）序列化成 IDoc 格式，通过 ALE（Application Link Enabling）配置从 SAP 端发到合作伙伴端口。对账场景里，IDoc 常用于「SAP → 银行」的付款指令回执、「SAP → EDI 报关」等批量场景——但对账系统与 SAP 的实时 PUSH 通常用 BAPI 而非 IDoc。

RFC 是 BAPI/IDoc 的底层协议。SAP RFC（Remote Function Call）是 SAP 自研的远程函数调用协议，跑在 SAP 端口（sapni 3200-3299 + sapgw 3300-3399）上。RFC 有四种调用模式：

• 同步 RFC（sRFC）：调用方等被调方返回，最常用；
• 异步 RFC（aRFC）：调用方不等返回，被调方通过回调；
• 事务性 RFC（tRFC）：保证至少一次投递，失败可重放；
• 队列化 RFC（qRFC）：保证按顺序投递，序列化处理。

BAPI 基于 sRFC，IDoc 基于 tRFC/qRFC。对账场景里 90% 用 BAPI（同步），剩下 10% 用 IDoc（批量）。

三、SAP ECC 认证体系：SNC + SAP Logon Ticket + 用户名口令

SAP ECC 的认证体系比 S/4HANA 复杂——SAP 在 ECC 时代同时支持三种认证机制，企业可以选任意一种或多种组合：

// === SAP ECC 三种认证方式（SNC + Logon Ticket + 用户名口令）===

// 方式一：用户名口令（最简单，调试场景用）
JCoDestination dest = JCoDestinationManager.getDestination("ECC_PROD");
dest.getProperties().setProperty("jco.client.user", "JCO_SYNC_USER");
dest.getProperties().setProperty("jco.client.passwd", "****");
dest.getProperties().setProperty("jco.client.lang", "ZH");

// 方式二：SAP Logon Ticket（基于 SSO，跨系统）
// SAP Portal/ITS 颁发的 Cookie 形式的 SAML-like 票据，
// 调用方把 MYSAPSSO2 Cookie 透传到 SAP 即可登录，无需再次输入用户名口令
dest.getProperties().setProperty("jco.client.mysapsso2", "AjExMDAgABRzc3...base64...AAB");

// 方式三：SNC（Secure Network Communications，基于 X.509 证书）
// SAP 在 2010 年后主推的强认证，基于 PKI 体系
// 调用方持有 X.509 客户端证书，SAP 侧配置信任的 CA
dest.getProperties().setProperty("jco.client.snc_lib", "/usr/sap/lib/libsapcrypto.so");
dest.getProperties().setProperty("jco.client.snc_partnername", "p:CN=ECC, O=SAP, C=DE");
dest.getProperties().setProperty("jco.client.snc_myname", "p:CN=jco-sync-client, O=CompanyX, C=CN");
dest.getProperties().setProperty("jco.client.snc_qop", "8"); // 8 = 完整性保护 + 身份认证

三件值得拎出来说的事：

第一件：用户名口令是 ECC 上的「最弱但最常用」认证。SAP ECC 上 80% 的 BAPI 集成走用户名口令——SAP Basis 给集成商分配专用账号（如 JCO_SYNC_USER），密码放在 KeePass/Vault 里。这种方式在 SAP 内部叫做「Dialog User」，不适合做无人值守的批量对账场景——SAP 默认 Dialog User 会受 License + 并发限制，且密码策略到期后会强制修改。生产环境的对账集成必须用 Service User（服务用户）+ SNC 证书 模式。

第二件：SNC 是 ECC 上的「强认证事实标准」。SAP 在 ECC 5.0 之后主推 SNC（Secure Network Communications）——基于 X.509 客户端证书 + PKI 体系的强认证，调用方持有 p:CN=<subject> 格式的证书名，SAP 侧配置信任的 CA 根证书。对账场景下推荐所有 ECC handler 走 SNC 认证——避免密码泄露、且支持双向 TLS。

第三件：SAP Logon Ticket 是「跨系统 SSO」。SAP 在 ECC + SAP Portal 时代支持 SAP Logon Ticket（也叫 MYSAPSSO2 Cookie）——SAP Portal 颁发一个含用户身份 + 有效期的票据，调用方把 Cookie 透传到 SAP 即可登录。对账场景下 Logon Ticket 通常用于「SAP Portal → 对账系统」的单点登录，而不是「对账系统 → SAP」的对账调用——后者走 SNC 证书。

四、集成中心的 SAP ECC handler 设计

集成中心下挂 handler 的全貌——金蝶云星空已有 9 个 HMAC 版 handler，SAP ECC 需要在 kingdee-cloud-galaxy 之外新增 9 个 SAP JCo 版 handler，命名空间隔离为 sap-ecc：

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

每个 handler 的 execute() 方法都是「协议层（SAP JCo + SNC 凭证 + 连接池）→ ETL（BAPI 字段映射）→ 落库（标准化 transform_documents 头表 + 体行表）」三段式。

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

对账场景下，handler 的最大价值不在协议封装本身（SAP JCo 客户端每个 Java 项目都能集成），而在于把 SAP ECC 那套重型业务对象模型（BAPI / 透明表 / RFC 函数）压平到对账系统能直接消费的轻量 schema 上——这是「集成中心」作为对账基础设施的核心价值，也是轻易云智能对账系统「多 ERP 同构」策略的落地：同一份对账结果能直接 PUSH 到 SAP ECC，也能 PUSH 到金蝶云星空、用友 YonBIP、Microsoft Dynamics 365，业务侧无需为每个 ERP 重写对账脚本。

五、集成转换脚本：从 SAP BAPI 字段到 transform_documents

SAP ECC 的 BAPI 字段命名遵循「业务对象 + 业务术语」的强命名规范（如 ACCOUNTGL.GL_ACCOUNT、ACCOUNTRECEIVABLE.CUSTOMER），与中文财务习惯不同。集成转换脚本要把这些字段映射到标准化的中文核算项目名称，让这个接口读得懂下游的核算项目体系：

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

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

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

export default async function transform(input) {
  const { accountingDocuments, companyCode, fiscalPeriod } = input;
  
  // 1. 按 GLAccount + 公司代码聚合：SAP 的 AC_DOC_NO + AC_DOC_TYPE 是天然聚合键
  const groups = new Map();
  for (const doc of accountingDocuments) {
    const key = `${doc.COMP_CODE}-${doc.DOC_TYPE}-${doc.GL_ACCOUNT}`;
    if (!groups.has(key)) {
      groups.set(key, {
        docType: 'AR_receivable',          // SAP 也复用 AR_receivable 命名
        head: {
          companyCode: doc.COMP_CODE,
          accountingDocType: doc.DOC_TYPE,       // KZ / DG / DA / KZ-BUKRS
          documentDate: doc.DOC_DATE,
          postingDate: doc.PSTNG_DATE,
          fiscalPeriod: doc.FISC_PERIOD,
          reference: doc.OBJ_KEY,                // SAP 凭证号（10 位数字）
          userName: doc.USERNAME,
          currency: doc.CURRENCY,
          // ... 头表 10+ 字段
        },
        lines: [],
      });
    }
    const g = groups.get(key);
    g.lines.push({
      glAccount: doc.GL_ACCOUNT,
      amount: doc.AMOUNT_DOC,
      debitCreditCode: doc.DEBIT_CREDIT_CODE,    // 'S' 借 / 'H' 贷
      assignment: doc.ASSIGNMENT,
      customer: doc.CUSTOMER,
      supplier: doc.VENDOR,
      costCenter: doc.COSTCENTER,
      profitCenter: doc.PROFIT_CTR,
      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()),
  };
}

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

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

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

选择三：凭证号（OBJ_KEY）作为 reference。SAP ECC 凭证号是 10 位数字字符串（受 NUMC 类型约束），作为外部单号回写到对账系统，下游做 SAP 推送时可作为幂等键避免重复推送。SAP ECC 上还有一个容易被忽略的幂等键是 REF_DOC_NO（参考号字段）——把对账系统单号（如 RECON-202609-0042）塞到这个字段，SAP 端可通过「参考号查询」反查凭证。

上面这套「BAPI 字段 → transform_documents」的映射规则是轻易云智能对账系统集成转换脚本的通用骨架，SAP ECC / SAP S/4HANA / 金蝶云星空 / 用友 YonBIP 共用同一套 contract——这让迁移到 S/4HANA 时协议层换掉、业务逻辑 0 改动。

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

六、ECC → S/4HANA 迁移路径：4 种迁移方式 + 实测影响

SAP 官宣 ECC 标准维护 2027 年停止后，每一个还在 ECC 上的客户都面临一次「是否迁移到 S/4HANA」的决策。SAP 提供 4 种迁移路径，每种的工程量、对账集成影响完全不同（来源：SAP 2025 ECC 维护时间表 + SAP 官方迁移指南）：

四种迁移方式中，Brownfield 是对账集成的「最佳策略」——SAP 在 Brownfield 迁移后会保留 ECC 时代的 BAPI/RFC 接口作为「兼容层」，给集成商 2-3 年的过渡窗口；但 SAP 明确表示兼容层不会无限期保留，S/4HANA 2025 之后某些 BAPI 已被弃用。经验数据：从 ECC BAPI 迁到 S/4HANA OData V4，平均需要重写 60-70% 的字段映射代码（来源：2026-Q2 三家 ECC → S/4HANA 迁移实测）。

迁移对账集成的 4 个最常见雷区：

雷区一：Universal Journal 改写会计凭证表结构。S/4HANA 的财务核心是 ACDOCA（Universal Journal）——一张表记录所有财务凭证的明细维度，而 ECC 上这些维度分散在 BSEG（凭证行）+ BSAD/BSAK（应收/应付明细）+ COEP（成本要素行）等多张表。ECC BAPI_ACC_DOCUMENT_LIST 拉取的凭证行在 S/4HANA 上字段名变了——BSEG 的 KUNNR（客户号）在 S/4HANA 上仍是 KUNNR，但 LIFNR（供应商号）变成 LIFNR，且 PRCTR（利润中心）从成本表迁到 ACDOCA 主表。

雷区二：并行账簿（Parallel Ledger）的会计视图变化。SAP ECC 上的 New GL 允许多个平行账簿（Leading + Non-Leading），每个账簿独立记账。S/4HANA 上账簿模型大幅简化——Leading Ledger 强制 0L，Non-Leading Ledger 可以建但字段受限。ECC 集成的「按账簿分类」在 S/4HANA 上要做适配。

雷区三：BAPI 函数兼容性层会被 SAP 持续剥除。SAP 明确说明 S/4HANA 的 BAPI 兼容层是「过渡设施」，不会无限期保留。S/4HANA 2023 已弃用 50+ 个 BAPI，S/4HANA 2025 弃用清单还会扩大。生产环境的 SAP ECC handler 不能假设 S/4HANA 上能复用——必须有「BAPI 字段名 + OData V4 字段名」双映射。

雷区四：凭证号（OBJ_KEY）从 10 位 NUMC 变成 GUID 兼容。SAP ECC 的凭证号是 10 位 NUMC（如 5100001234），S/4HANA 上仍是 NUMC 但允许外部 GUID 主键并存。对账系统回写幂等键时，ECC 上用 OBJ_KEY，S/4HANA 上既可以用 OBJ_KEY 也可以用 External Reference——后者更稳定。

迁移策略推荐：

1. 短期（6-12 个月）：在 ECC 上继续用 BAPI/JCo，但要写好「BAPI 字段 → OData V4 字段」的兼容映射表，为 OData V4 重写做好准备；
2. 中期（12-24 个月）：上线 Brownfield 迁移，BAPI 兼容层保 2-3 年；同步开发 OData V4 handler，与 BAPI handler 并行；
3. 长期（24+ 个月）：逐步废弃 BAPI handler，全部切到 OData V4；SAP 标准 API 包（API Business Hub）的标准 OData 服务优先使用，自定义场景走 SAP BTP 自定义 OData。

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

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

4 步对接路径：

1. SAP 侧准备（1-2 周）——SAP Basis 顾问在 ECC 系统里启用 SAP Gateway（事务码 SICF），把需要对接的 BAPI（BAPI_ACC_DOCUMENT_POST 等）通过「RFC 函数发布」+「SAP Gateway」暴露为 SOAP/HTTPS；同时配置 SNC 证书，给对账系统分配 Service User（如 JCO_SYNC_USER）。
2. 集成中心 handler 落地（2-3 周）——按上面 9 个 handler 清单创建 SAP ECC 集成方案的目录（命名空间 sap-ecc），每个 handler 实现「SNC 凭证申请 → RFC/BAPI 调用 → 标准化 ETL → 落 transform_documents」四步。client 层封装 SAP JCo 连接池（每个 ECC 系统单独一组连接）。
3. 集成转换脚本编写（1 周）——按「INCOME / EXPENSE」两类分别写转换脚本，按 (COMP_CODE + DOC_TYPE + GL_ACCOUNT) 聚合，校验借贷平衡，处理汇率/币种/会计期间等本地化口径。
4. 联调与上线（1-2 周）——用一个真实账期（如 2026-09）的数据 PULL 一次会计凭证到本地表；用一个虚拟凭证 PUSH 一次到 ECC（POST + COMMIT 两步）；记录 PULL/PUSH 成功率、P95 延迟、字段映射准确率三个核心指标。

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

1. SAP JCo + SNC 连通成功率 ≥ 99%——把 SAP JCo Destination 缓存到 Redis 风格的连接池，连接空闲超过 5 分钟自动 RFC_PING 探活；连续 3 次 RFC 调用失败触发告警。
2. PULL 会计凭证字段映射准确率 ≥ 99.5%——选一个完整账期（如 2026-08）的数据，对比 ECC 原始凭证（事务码 FB03 可见）vs 落库的 transform_documents 头表，字段差异行数 < 0.5%。
3. PUSH 会计凭证幂等性验证——同一张凭证连续 PUSH 3 次，ECC 侧只生成 1 张新凭证（凭证号 OBJ_KEY 作为幂等键；同时把对账系统单号塞到 REF_DOC_NO 字段作为二级幂等键）。
4. 借贷平衡校验 100% 通过——转换脚本对所有 PUSH 的凭证做借贷平衡校验，违反直接 FAILED；ECC 端 BAPI_ACC_DOCUMENT_POST 后必须紧跟 BAPI_TRANSACTION_COMMIT，否则凭证只入队不入账。
5. P95 性能达标——PULL 1000 张凭证耗时 < 8s（RFC 函数调用 + 透明表 JOIN 比 OData V4 慢）；PUSH 100 张凭证耗时 < 10s（POST + COMMIT 两步串行）。

整套对接最终落到集成中心——同一套 handler + 集成转换骨架能管 SAP ECC + 金蝶云星空 + 用友 YonBIP 多套 ERP，多 ERP 的转换单据在一张全局表里混排，迁移到 S/4HANA 时只需切换 handler 协议层而不必改业务逻辑。这是「集成中心」作为对账基础设施的杠杆价值。

八、写在最后

SAP ECC 是 SAP 在 R/3 之后 13 年（1992-2005）积累下来的核心 ERP 平台，全球前 500 强里有相当一部分企业的核心生产系统至今仍跑在 ECC 6.0 EHP7/EHP8 上。但 2027 年标准维护停止 + 2030 年延伸维护按订阅付费的时间表已经官宣——所有还在 ECC 上的客户未来 12-36 个月都必须做一次「是否迁移到 S/4HANA」的决策。

对账场景下的最优策略是**「分两步走」**：先用 SAP JCo + BAPI 保住 ECC 期的对账通路（按本文 9 个 handler 落地 + 5 步验收），同时开发 OData V4 handler 作为并行方案。迁移真正发生时（Brownfield 还是 Greenfield 取决于业务），集成中心能根据目标系统自动切换 handler 协议层——这是「集成中心」的杠杆价值。

文中涉及的 SAP RFC / BAPI / IDoc / SAP JCo / SAP NCo / SNC / Universal Journal / Brownfield 等专有名词都是 ECC 时代的「官方教材」用语，与 S/4HANA 时代不完全通用。正确的接入顺序是「先用 BAPI 跑通最小可用链路 → 再按业务场景逐步扩展 IDoc 批量 → 同时准备 OData V4 双轨并行」，避免一开始就陷入 SAP PI/PO 重型中间件的复杂度里。

整个对账接入链路最终会落到集成中心，「PULL × PUSH × 集成转换」三段式架构对 SAP ECC 与金蝶云星空、SAP S/4HANA、Microsoft Dynamics 365 等所有主流 ERP 都同构——同一套集成中心能管多套 ERP，多 ERP 的转换单据在一张全局表里混排——SAP ECC 客户的 BAPI/JCo 资产不会被浪费，迁移到 S/4HANA 时只需切换 handler 协议层即可。

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