系统对接，解决的从来不是技术问题
先说结论：多系统对接难，难的通常不是接口调不通，而是同一件事在好几套系统里各记一遍，再靠人对账。ERP 里开了销售单，电商后台要再录一次发货；OA 批完的采购申请，采购员再抄进 ERP；CRM 里客户地址改了，开单时用的还是旧地址。系统越多，重复录入越多，对不上的账也就越多。
对接要做的，是把这些"第二次录入"消掉：数据从产生它的那套系统出发，自动流到需要它的系统里，人只负责审核和例外处理。
月底对账差几千块，翻单据翻三天
库存同步慢半拍，同一批货卖超了才发现
订单漏单，等到客户打电话来问才知道
人工导表错一行，整批数据返工重来
这些问题看着是技术故障，根子都是"两套系统各算各的账"。所以判断要不要做对接，只需要问一句：同一笔业务，是不是有人在两套系统里各录了一遍？如果是，就有对接的价值。
有接口或者有数据库，就真能打通吗
结论：满足三个条件就能——对方能提供取数通道、双方字段能一一对上、同步的触发时机可控。三个条件缺任何一个，该改的是方案，不是硬做。
取数通道通常有两种。一种是对方开放 API，按文档取数，REST、SOAP、GraphQL 都能接；另一种是对方给一个只读数据库账号，直接读视图取数。前者规范，后者直接，实际项目里往往是混着用的：商品、客户这类主数据走 API，几十万条历史单据走数据库直读，速度差一个量级。
需要提醒的是，对接走的是对方开放的通道，不是绕过对方系统。所以前提是这套系统本身留了接口，或者允许数据库直连。这也是为什么选型阶段就该问一句：这套系统对外提供接口吗？支持哪几种协议？很多企业是上线两年后才发现答案是否定的，那时候要么加钱定制，要么只能继续人工导表。
对速达系列产品来说，这一点是明确的：ERP 与生产管理、进销存与财务两条线都提供 RESTful、SOAP、GraphQL 三种接口，可以按对方系统的能力挑一种对接方式。
对接前要准备的五样东西
结论：接口文档不是全部，真正决定工期的是字段对照表。准备齐这五样，对接能省掉一半的来回扯皮。
接口文档或数据库表结构：字段含义、字段长度、是否可空、有没有枚举值。文档过期比没有文档更麻烦，所以要拿到能实际调通的版本。
账号与权限：API 的 appkey、token 怎么发、有效期多久；数据库账号的库表权限范围。权限给大了是安全隐患，给小了跑到一半报错。
字段对照表：这是工作量的大头。对方的"客户名称"跟自己的"客户全称"是不是一个字段，"规格型号"要不要拆成三列，计量单位怎么换算，都要在这一步定死。主数据没统一，对接后会出现一物多码，这类问题的处理方式可以参考商品编码规则怎么定。
测试环境：不要拿生产库试。没有测试环境就要求对方开一个演示账套，测完再切。
双方责任人：每边指定一个人，出问题能直接找到能改代码或改配置的人，比走工单快得多。
这五样里，字段对照表通常占掉整个对接一半以上的时间。原因不复杂：接口是技术问题，字段是业务问题，而业务口径往往在两边的部门之间就没谈拢过。
定时同步还是增量触发，怎么选
结论：按数据的"变化频率"分，不要一刀切。主数据定时全量，业务单据增量触发，两边各取所长。
| 维度 | 定时全量同步 | 增量触发同步 | 适用数据 |
|---|---|---|---|
| 实时性 | 按周期，分钟到小时级 | 准实时，按单据产生即推 | — |
| 对源系统压力 | 集中在同步时刻，量大时要错峰 | 分散，单次只传变化量 | — |
| 出错后的补救 | 重跑一次即可覆盖 | 要按单号补推，需要日志和重试 | — |
| 典型对象 | 商品档案、客户档案、价格表 | 销售订单、出入库单、收付款单 | 按单据类型分 |
两种方式都要留一条"补数"通道：定时同步要能手动触发一次全量，增量同步要能按单号重推。没有补数通道的对接，出一次异常就得人工填一次表，等于白做。
电商订单和库存同步，为什么容易超卖、漏单
结论：超卖多半不是同步慢，而是同步过去的数字本身就不是"可用库存"；漏单多半是接口重复调用没有幂等，订单被建了两遍或被判为重复丢了一遍。
可用库存要减掉已被订单占用但还没出库的部分。如果对接只传"账面库存"，电商前台看到的数字就是虚高的，卖超只是时间问题。这个口径怎么算，可用库存怎么算里有完整拆解。
幂等这件事更隐蔽。接口超时是常事，超时后自动重试也是常事，如果对方按订单号判重、这边没有传稳定的单号，同一笔单就会被建两次。反过来，如果去重规则写得太狠，正常的两笔相似订单又被吞掉一笔。比较稳妥的做法是：以源系统的单号作为幂等键，重试只补推不新建，每次同步留一份推送日志可查。
私有化部署时，数据怎么不出内网
结论：把对接服务部署在企业自己的服务器上，只开放指定的出口地址，数据全程在内网和双方的接口之间流转，不经过第三方平台中转。
这也是不少企业卡在对接这一步的真实原因：方案本身可行，但数据要先上传到某个公有云平台才能转，安全和合规过不了关。私有化部署下，同步程序、日志、临时文件都留在内网，出了问题可以自己查日志，不用等平台方排期。
配套的还有两件事：一是访问控制，接口地址和账号按白名单管；二是审计，每一次数据推拉都留记录，谁在什么时候改了什么能追溯。这两件事在私有化环境里做起来反而更简单，因为日志就在自己手上。
一套对接大概要多久
结论：取决于对方接口的质量，不取决于这边的工作量。接口规范、文档齐全的项目，几天能跑通；接口要现开发的项目，周期按周算。
| 对接类型 | 主要工作量 | 大致周期 |
|---|---|---|
| 单类单据单向同步 | 字段对照、接口联调、异常重试 | 3～5 个工作日 |
| 主数据 + 单据双向同步 | 口径统一、幂等设计、冲突处理 | 1～2 周 |
| 多系统编排（ERP+OMS+OA） | 流程串联、状态机、监控告警 | 2～4 周 |
| 含历史数据迁移 | 数据清洗、试跑核对、分批切 | 再加 2～4 周 |
工期里容易被忽略的是"数据清洗"。历史单据里的空客户、错计量单位、重复商品，同步过去会变成对方的脏数据，所以首轮对接通常要先跑一轮清洗。这块工作不做，后面查账的时候还是要回头补。
已经对接过哪些系统
结论：主流 ERP、电商后台、OA、CRM 基本都有现成经验，没列到的系统，只要有接口或者能给数据库，同样能接。
ERP：用友全系列、速达全系列、鼎捷、富勒、时空、浪潮、SAP、英克、管家婆、百胜
电商后台（OMS）：聚水潭、管易云、吉客云、旺店通、万里牛、网店管家、奇门
协同办公（OA）：泛微、钉钉、企业微信、飞书、云之家、蓝凌、致远
客户管理（CRM）：纷享销客、销帮帮、销售易、爱客
其他：微盟、有赞、支付宝、抖店、小红书，以及企业自研的个性化系统
对接方式上，企业只需要提供两样中的任意一样：对方系统的 API 接口，或者一个可读的数据库账号。剩下的字段映射、同步程序、异常重试、日志监控由我们来落地，交付时附一份可查的推送记录，后期运维也有据可依。
厦门速达软件有限公司成立于 2004 年，累计服务一万多家企业客户、覆盖 50 多个细分行业。公司在工序管理、序列号管理等方面有自主开发的模块，并提供 RESTful、SOAP、GraphQL 三种接口开发与系统对接服务，可按企业内部环境做私有化部署。
有正在跑的系统想打通，可以先说说两边分别是什么系统、要同步哪几类数据。联系我们做一次免费的可行性评估，通常一天内能给出结论：能不能接、走 API 还是数据库、大概多久。