- 新应用如果不和会计系统、库存系统对接，员工就得把数据录入两次，两边的数字迟早会对不上。
- 对接之前，必须先商定每一类数据以哪个系统为准，以及传送失败时会怎样。
- 先把两个系统的对账报表做好，再开发对接程序。这样一天之内就能发现问题，不用等到结账那天。
大多数问题出在系统之间的接缝处
常见的情形是：销售人员在新应用里接单，会计部门再把同一张单子重新录入会计软件。于是公司有了两套本该相等的数字，却没有任何机制让两边保持一致。每多录一次，两套数字就可能再拉开一点距离。
症状往往过一段时间才显露出来：忙的那天漏掉一张订单；应用里的价格还是上个月的，因为有人只在 ERP 里改了；应用显示的库存比仓库实际情况晚了半天。到了月底，会计部门要花好几天追查差额出自哪一张单。
这部分工作，Vibe Coding（氛围编程）帮不上太多忙。只要 API 文档写得好，AI 写调用 API 的代码非常快，但系统对接需要的知识，大多从来没有写成文档。销售部门和仓库用的是两套商品编码；同一位客户有三个客户编码，因为曾在三家分店开过票；会计部门十年来一直用备注栏记录客户的采购订单号。这些事情存在员工的脑子里和旧数据里，得有人去当面问、去翻数据才知道。
开发对接程序之前，必须回答的四个问题
系统对接有点像让两个部门共用同一本账簿。开始之前要商量好：谁来写，谁只能看，什么时候写，写错了由谁改。这四个问题必须由业务部门来回答，技术团队没法代劳。
每一类数据以哪个系统为准？
每一类数据都应该只有一个系统说了算，这叫作唯一可信数据源（Source of Truth）。比如售价以 ERP 为准，库存数量以仓库系统为准，客户联系方式以应用为准。其他系统可以读取使用，但不能修改。如果两个地方都能改，就没人说得清哪个数字才对。
什么时候传，往哪个方向传？
有些数据需要几乎实时送达，比如畅销商品的库存；有些每天夜里批量传一次就够了，比如已经入账的销售额。传得越频繁，系统越复杂，成本也越高，所以应该根据数据晚到会造成多大损失来决定传送频率。
传送失败会怎样？
网络中途断开是常事，所以发送端必须能重发，而且重发不能生成第二张单据，这种特性叫作幂等性（Idempotency）。多次重发仍然失败的条目，必须停在有人看得到的地方，并指定一位负责人去处理。
谁来对账，什么时候对？
今天运行正常的对接程序，到了有人新增一种折扣类型的那天，就可能出错。所以每天核对两个系统的数字，也就是对账，本身就是系统的一部分，从上线第一天起就应该有。
| 对接方式 | 适用情况 | 注意事项 |
|---|---|---|
| 调用目标系统的 API | 系统有 API，供应商也支持使用 | 每天调用次数的配额，以及 API 模块的授权费用 |
| 定期导入、导出文件 | 旧系统没有 API，但可以导入文件 | 数据要等到下一批才更新，还要有办法处理导入失败的文件 |
| 直接读取旧系统的数据库 | 没有其他办法，且系统供应商同意 | 直接写入可能损坏数据，也可能违反服务条款，应该只限于读取 |
| 让程序代替人去点界面 | 系统所有途径都不开放，而且业务量小 | 旧系统的界面一改，程序就会停止工作 |
写给开发团队 · 技术细节
每张单据使用一个 Idempotency Key，通过 Outbox 和 Message Queue 发送，配合 Backoff 策略的 Retry，以及带人工处理界面的 Dead-letter Queue。商品编码和客户编码的映射表放在中间层。校验输入数据的 Schema，监控队列的延迟和错误率，并对供应商的 API 做 Contract Test，在变更进入 Production 之前发现问题。
模拟案例
建材经销商：同一单水泥送了两趟
一家建材经销商给下游门店做了一个自助下单的应用，应用通过 API 把订单传进 ERP。有一天下大雨，仓库的网络时断时续。应用发出订单后一直等不到回复，直到超时，于是按照预设的规则重发。ERP 收到了两次同一张订单，开出两张拣货单，运水泥的卡车就给同一家店送了两趟。公司直到店主打电话来拒收第二趟货，才知道出了问题。
团队改了两处。第一处是让应用每次重发都附上原来的参考编号，接收端在生成单据前先检查这个编号。第二处是每天早上运行的对账报表，比较应用和 ERP 前一天的订单数量和金额。第二周，这份报表又发现了另一类问题：在应用里已经取消、却仍然挂在 ERP 里的订单。以前从来没人知道有这种情况。
对接之前先对账
- 选一种要在系统之间流转的单据，比如销售订单
- 确定两边每天必须一致的数字，比如单据数量、总金额、每个商品编码的件数
- 做一份把两个系统的数字并排列出的报表，先用上个月手工录入的数据试运行
- 逐条查看报表发现的差额。每一条差额，都是对接程序必须处理的一条规则
- 对接程序上线后，让报表每天早上运行，并指定当天负责清理差额的人
应该留存的依据，是每天的差额数量和处理每一条所用的时间。如果两个系统对同一个词的定义不同，这个方法就会卡住，比如一边的销售额含税，另一边不含。这种情况下，要先由会计部门把定义统一下来。
最容易低估的，是旧数据迁移
新系统如果要从旧系统带过来客户、商品和未结余额，数据迁移花的时间会比所有人预想的都多。旧数据里有重复记录、空白字段，格式还随着不同时期录入的人而变化。
稳妥的做法分四步。第一步清理数据，合并重复记录，补齐必填字段。第二步写一张对照表，说明旧系统的哪个字段对应新系统的哪个字段，这叫作数据映射（Data Mapping）。第三步试迁移，请数据负责人抽查样本。最后，两个系统并行运行一段时间，再正式切换（Cutover）到新系统，同时准备好回退方案，以防切换当天出问题。
符合以下任何一条，先别投资做系统对接
- 单据量很少，每周手工录入一次比开发和维护对接程序还便宜
- 目标系统一年内就要更换
- 两个系统数据冲突时，还没有能拍板的数据负责人
- 旧系统的供应商不允许或不支持对接
衡量效果时，看会计部门和运营部门切身感受得到的数字：省下了多少重复录入的工时，每天有多少条差额，清理差额要多久，月末结账要几天。如果并行运行满两周，差额仍然没有减少，就先推迟切换日期，回头查一查还有哪条规则没处理好。
让新应用和旧系统报出同样的数字
会计科目表和记账规则归您的会计部门管，商品编码和盘点方法归仓库管，ERP 供应商了解自家系统的限制。DNA Maker 会和这三方一起，把一张单据从起点追到终点，然后画成一张对接图：哪个字段对应哪个字段，每类数据以哪个系统为准，每批传多少，传送失败时谁要做什么。
根据这张图，我们搭建系统对接层，包括队列、不会产生重复单据的重发机制、编码对照表和每日对账报表，并提供仪表盘，让会计部门看到挂起的条目。工作从一种单据开始，与手工录入并行运行，直到差额持续为零，才切换到新系统，再扩展到下一种单据。如果您的团队有哪种单据重复录入得最频繁，可以从两个系统里各调出这种单据的同一批十张样本，带来和我们聊聊。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
规划系统对接时，和开发团队以及旧系统供应商沟通会用到这些词。右栏的问题可以帮您看清每一步由谁负责。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Reconciliation | 核对两个系统的数字是否一致，并追查不一致条目的原因 | 每天早上，报表比较应用和 ERP 前一天的订单数量和金额 | 差额由谁处理？必须在几小时内处理完？ |
| Data Migration | 把数据从旧系统转到新系统，包括清理数据和迁移后的检查 | 合并重复的客户之后，把八千位客户的名单迁入新系统 | 迁移后，我们怎样检查数据是否完整、未结余额是否与旧系统一致？ |
| Data Mapping | 说明一个系统的哪个字段对应另一个系统哪个字段的对照表 | 把销售部门的商品编码与仓库的商品编码逐条对应起来 | 这张表由谁负责？有新商品时由谁添加？ |
| Middleware | 位于两个系统中间的软件，从一个系统接收数据，转换格式，再传给另一个系统 | 中间件接收应用的订单，转换商品编码，再传进 ERP | 如果中间件停止工作，积压的条目会去哪里？谁会收到通知？ |
| Message Queue | 两个系统之间暂存数据的地方，条目排队等待发送，即使目标系统暂时宕机也不会丢失 | ERP 停机维护一小时，订单在队列里等待，系统恢复后再陆续进入 | 队列积压到什么程度，业务就会受影响？我们靠什么知道？ |
| Parallel Run | 在一段时间内同时使用旧系统和新系统，比较结果后再停用旧系统 | 对接程序运行期间，会计部门继续手工录入两周，并每天对账 | 用什么标准判断可以停止并行运行？由谁决定？ |
| Cutover | 真正从旧系统切换到新系统的那段时间 | 周六晚上暂停接单两小时，迁移未结余额，周日早上启用新系统 | 如果切换当晚出问题，最晚几点之前还能回退？由谁下令？ |