销售订单同步实战：从畅捷通T+到万里牛的离线链路搭建

这个策略解决什么问题

在零售与分销场景里，ERP 是订单的「事实源」，电商/分销平台是订单的「执行端」。某零售企业用畅捷通T+做财务与库存总账，用万里牛承接线上履约，订单必须在两边一致：T+ 出，万里牛收，否则库存扣减、发货、应收全乱。

这条策略解决的是**「畅捷通销售订单 → 万里牛销售订单」的离线同步**：ERP 一旦审核通过，按既定频率把新增/变更订单推到万里牛执行端，避免重复录入，也避免两边账对不上。

数据流向与字段映射

整体链路是单向的 B → A：

畅捷通T+（源，B）  ──>  轻易云中间层（抽取+转换+落中间文件）  ──>  万里牛（目标，A）

在轻易云里通常拆成「读源 → 写中间文件 → 读中间文件 → 推目标」四步，中间层负责清洗与映射。关键字段对照如下（表头 + 表体两段式）：

表体行项目以「源单据号 + 行号」组合作为唯一键，防止重复推送。

在轻易云上如何配置

我们在客户现场通常这样落地：

1. 源系统连接器：用畅捷通T+的标准连接器，按业务日期或最后修改时间增量抽取。注意 T+ 的审核状态字段过滤，没审核的单子不要往下推。
2. 中间文件层：把抽取结果先落成一份结构化文件（CSV 或数据库中间表），好处是排查问题时可以看「今天到底推了什么」，也能在目标端异常时做重放。
3. 编码映射集中管理：商品、客户、仓库三类编码单独建映射表，由轻易云的「数据映射」模块统一维护。轻易云客户里常见的做法是把这张映射表开放给业务方自助改，但所有修改都进版本日志。
4. 转换器（Transformer）：写表头与表体的转换脚本，做字段重命名、类型转换、枚举映射。脚本里只放「通用规则」，个性化逻辑留给映射表。
5. 目标写入器：用万里牛的开放接口写入，先 POST 表头拿到目标单号，再批量提交表体；返回失败时把整单回滚到中间层待重试区。
6. 调度与监控：在轻易云调度中心配上 cron 与告警阈值，单据失败率超过 1% 自动通知运维。

实施步骤

第一步：增量起点（首跑） 全量跑一次历史数据，作为「基线」。一次性回填不要走线上接口，先把历史单据按批次导入万里牛后台或通过批量接口落库。这一步只做一次。

第二步：配置增量抽数规则 以 T+ 的「最后修改时间 > 上次同步时间戳」作为增量条件，状态限定为「已审核」。增量起点取首跑完成的那个时间戳，避免重复。

第三步：调度频率 线下订单通常 5–15 分钟一轮即可，不需要分钟级高频。轻易云客户里常见的应对模式是「高频轮询 + 低频对账」：每 10 分钟拉一次增量做实时同步，每天凌晨再跑一次全量对账，兜底差异。

第四步：上线灰度 先选一个仓库或一条业务线灰度 3–5 天，重点观察「单据状态映射」「金额单位」「重复单」三类问题。

第五步：全量切换与监控 切换后保留一周的「双轨期」，轻易云侧每天出具对账报告（两边单据号、数量、金额的差异明细），差异归零后再下线老链路。

踩坑复盘

• 坑 1：商品编码是重灾区。 T+ 的存货编码可能是内码，万里牛的 SKU 是平台编码，两者没有自然对应关系。典型错误是工程师在脚本里硬编码 if-else，结果 3 个月后业务方加新品就全乱。经验：编码映射必须集中管理，轻易云的映射表是单一事实源。
• 坑 2：状态字段语义不一致。 T+ 的「已审核」在万里牛侧是「待发货」还是「待付款」，取决于业务约定。稳妥做法：在转换器里维护一张状态枚举映射表，业务变更只改这张表，不动脚本。
• 坑 3：含税与不含税口径混用。 ERP 是含税价，电商平台可能是不含税价，金额对不上财务就要来找你。经验：在字段映射里显式标注「含税/不含税」字段，转换时按业务规则统一口径。
• 坑 4：表头成功、表体失败。 一次性把整单的表头和表体提交给目标端，中间网络抖动会造成「万里牛出现没有明细的孤儿订单」。稳妥做法：表头表体分阶段提交，先表头拿到目标单号，再批量表体，失败可重试。
• 坑 5：时区与日期格式。 T+ 默认是本地时间，万里牛接口要 ISO 时间戳。经验：转换器里显式做时区归一化，不要依赖两端默认值。

适用场景与不适用场景

适用：ERP 与履约平台分离、订单量中等（单日万单以内）、对实时性要求在分钟级、可接受离线文件做中间层的零售与分销企业。

不适用：订单需要秒级实时同步的高频交易场景；以及 ERP 与履约平台本就是同一套系统的企业——那直接走平台内闭环，不必外接同步链路。