金蝶、用友、SAP 都要数据：先接哪一套、怎么少返工

摘要：三套 ERP 都要数据，先接哪一套往往不是按判据定下来的。第一套接完才发现第二套的单据模型根本不一样，返工量比第一次接还大。这篇讲集成中心三台引擎各管什么、目标系统为什么只是取值而不是代码结构、接第二套的四处返工点、幂等为什么下推型天然免疫而新增型全靠人工反查，以及三个判据和一张返工成本两栏表怎么用。 关键词：ERP 集成、集成中心、金蝶云星空、用友、SAP、幂等、返工成本

一、三套都要接，第一套接完才发现第二套不一样

一个集团，三个账套：电商结算记在金蝶云星空，内贸批发记在用友，海外主体记在 SAP。财务总监的要求很直白——三套都要。

真开始接，问题才浮出来。金蝶这一套从五月接到八月，脚本、规则、任务模型都跑顺了。八月动手接用友，才发现"应收单"这三个字在两边的意思并不一样；十月翻 SAP 的接口文档，发现对方连"下推"这个动作都不存在，幂等得完全自己兜。

问题不在"ERP 难接"，而在"顺序没有判据"。 顺序定错，返工掉的不是接第二套的工时，是把已经跑顺的第一套再翻一遍。

有一件事必须先说清楚：截至目前，真正落地并且跑通的是金蝶云星空这一条线。侧边登记的对接动作一共 8 个——2 个负责拉（接口体检、暂估应收拉取），6 个负责推（暂估应收下推财务应收、费用应收、费用应付、其他应付、销售收款、银行转账）。

用友与 SAP 的位置是留好的：凭据按产品前缀预留了命名位，字典里预置了目标系统取值。架构上随时能接上，但动作本身还没写、还没跑。位置留好和跑通是两件事，估工期时不能把前者当后者算。

这列是亚马逊美国站收入对账的转换单据，每一行都是"对账结果翻译成对方单据"之后的产物。接管的终点不是把数算对，是把算对的结果变成对方系统里的一张张单。 那 8 个动作里，2 个把数取回来，6 个把单送出去，中间那步翻译就是下一节的集成转换。

二、三台引擎：拉回来、推出去、翻译成对方语言

集成中心不是一个接口，是一个把对账结果送进 ERP 的容器。里面三台引擎各管一段：

拉取和推送的落库差异值得单拎出来：拉回来落"集成任务表 + 自己的业务表"，推出去落"集成任务表 + 对方的业务表"。中间那张任务表是两边共用的账本，谁提的、走没走通、卡在哪一步，都记在它上面。

完整动作链是五步：上传 → 解析 → 对账 → 集成转换 → 对账确认。 少一环，单据就送不出去；或者送出去的不是确认过的数——这更麻烦，因为账上看着是对的。

每个对接动作都是一个统一接口，5 个方法：编码、方向（拉还是推）、入参校验、真正执行、可选的手工补偿。最后那个口子留在这儿，是因为有些失败只有人能处理。

这张流程图画的是从转换到审核这段路。推送不是一次调用就完事，是一串有次序的步骤：单据备好、推过去、对方审核、再回读确认。中间任何一步停下来，任务都挂在队列里等下一步。

三、目标系统只是取值，不是代码结构

换一家 ERP，真正要改的只有两样：脚本本身，和规则里取值的那些配置。通用层、队列、任务模型都不用动。换目标系统，是换取值，不是换框架。

目录按产品切，不按厂家切——金蝶云星空、金蝶云星辰、用友 YonBIP 是三个并列目录。同一家换产品，单据模型可能差很远，按厂家归类会把这个差别藏起来。

领域数据走标准化主表，不为某一家 ERP 建特例表。横切关注点（比如推送日志）用一张统一表，加一个"属于哪个产品"的字段，不按产品拆日志表。拆表最容易把架构做死：日志一旦按产品分成六张，跨产品查一次状态就要写六段代码。

轻易云的集成中心按目标系统取值，换一家 ERP 是新增一个产品目录，不是重写框架。语义不同的部分下沉到脚本与规则取值，框架层保持稳定。

但"架构上可插拔"不等于"接第二套零成本"。返工点不在框架，在四个地方：

第三条最容易出事。转换规则表里没有"平台"这个字段维度，规则靠键名分列：速卖通 66 条、亚马逊 35 条、支付宝 29 条、京东 16 到 17 条、小红书 10 条、视频号 6 条。一条通用规则如果用了一个别的脚本也在消费同一个键，铺下去会同时改掉所有 ERP 和平台的表现。 所以接第二套的第一件事不是写新脚本，是先查这个键有没有人消费。

这张图讲的是边界。集成、转换、对账各自成一块，边界之内不认具体是哪家 ERP。 换一家要动的是边界内某个模块的取值与脚本。判断一套架构能不能接第二家，看这张图比看产品文档准——模块互相咬住的地方，就是将来要重写的地方。

四、幂等这道坎：下推型天然免疫，新增型全靠人

对接里最贵的两个字是幂等——同一条数据推两次，第二次要能被认出来。

反直觉的地方在这里：下推型天然免疫，新增型完全裸奔。

财务应收是下推型的，必须从暂估应收下推。暂估已经全部下推完了，再推一次，账套自己会拒绝，报"应收单已经下推完毕"。这是业务错误，不是接口层的错误——请求本身是通的，是对方判定你重复了。

费用应收、费用应付、销售收款、银行转账是新增型的。对方 ERP 里没有"这单我已经有了"的判断，重推一次就是多一张单。这类单据推之前必须人工到 ERP 侧反查：按日期加客商加金额，或者按系统单据编号。没人反查，重复单就是重复入账。

防重办法是：单据编号不由 ERP 自动生成，改成表头必传一个自定义字段"系统单据编号"，值是平台枚举码加推送时刻的 17 位时间戳，比如 JD_POP20260918103142123。

还有一条要单独讲：本地状态机防重不等于 ERP 侧防重。 已经推送过的单据，在本地可以被重开回到"已确认"状态，系统不拦。本地那层"我只推一次"是给人看的，重复入账的后果最后由操作人自负。

轻易云在推送前强制回读校验，容差 0.005，行数与金额一起对。

失败处理有三道防线，参数都能在系统配置里运行时覆盖：

但重试有边界：重试三次救不了状态不对。 状态不对、缺主数据、日期不对这类业务性错误，重试一万次结果一样，系统不重试，直接判失败。把业务性错误塞进重试队列，是把一个明确的失败变成一段模糊的等待。

五、先接哪一套：三个判据，和一张两栏表

判据一：哪套 ERP 的数据是上游。 如果某套 ERP 出的业务订单就是账单匹配的对象——供应链订单、出库单——它必须先接。接晚了，对账没有对手方可匹配，账单行挂不上东西，后面的差异率全是假的。

判据二：哪套的单据模型最接近。 先接"应收 + 应付 + 收款"这类标准单据，模型特殊的那套放到第二阶段。

判据三：哪套先接能复用最多。 第一套 ERP 的成果里，核算项目、转换规则骨架、推送日志结构、任务模型都是复用的；脚本与规则取值要重写。

这三条合起来的结论是：先接金蝶云星空不一定是保守。 反过来看，它把坑都踩完了——行级拉取、下推与新增两类幂等差异、回读校验、组织隔离、模拟模式与真实模式切换。换第二家的时候这些坑不用重踩。顺序选对了，省下的不是第一套的工时，是第二套的调试期。

返工成本怎么估？列两栏，只算右边。

左栏是"搬一次就一直能用"的，右栏是"每接一家重写一遍"的。算返工成本只算右栏，左栏不进预算。 很多项目估工期时把两栏都算了一遍，估出一个吓人的数字，干脆不接第二家——这是把最便宜的那部分也算成了最贵的。

这张路径图是财务成本随对接成熟度下降的曲线。曲线什么时候开始往下掉，取决于第一套接的时候有没有把坑踩完。 第一套接得糙，后面每接一套都要重走一遍调试期，曲线就是平的；第一套接得干净，第二套的边际成本明显下降。给 CIO 讲投入产出时最该用的一张图：成绩不是"接了几套"，是"第二套比第一套少花多少时间"。

六、第一套 ERP 必须踩完的六个坑

这六条没有一条是金蝶特有的，它们是"接 ERP"这件事本身的坑。轻易云在金蝶这条线上把这些坑都踩过一遍——第一套接的时候踩完，第二套就只是换一批取值。

还有一条要单独记：翻页任务编号不含过滤条件。 同一时间窗口换过滤条件重拉，会跟历史链撞车。

七、今天就能做的三条动作

架构上可插拔和当前已落地，是两件必须分开说的事。位置留好不等于跑通，接第二套要花的时间，答案在那张两栏表里：左栏不用算，右栏一条一条数。

第一，按三个判据把三套 ERP 的接入顺序排成一页纸，标出哪一套是上游数据源，交给 CIO 和财务总监签字。

第二，列出所有靠新增推送的单据类型（费用应收、费用应付、销售收款、银行转账这一类），挑一张在 ERP 侧做一次人工反查：按日期加客商加金额查一遍，看看重复单能不能被挡住。

第三，给转换规则做一次键的排查：列出所有通用规则的键，确认每个键是不是只有一段脚本在消费。排查不出来的键先打标记不要动。

接第二套 ERP 的成本，不在于框架要重写，而在于第一套有没有把坑踩完。