销售订单从 CRM 推到 ERP：一条策略的完整同步实战

这个策略解决什么问题

销售订单从 CRM 推到 ERP，看似只是「把单子搬过去」，但只要稍不留神，3 个月后两边订单数对不上、金额差异找不回来、订单状态错位——仓库已经发了货，财务却没收到单。所以这个策略真正要解决的不是「能不能传」，而是「增量按什么时间窗取、全量什么时候补、状态字段怎么对得上、错了怎么回溯」。

数据流向与字段映射

整体链路是：源系统（CRM 销售订单）→ 中间层（轻易云数据集成平台 Qeasy）→ 目标系统（ERP 销售订单）。源端按时间区间分页拉单，目标端按单号幂等写入。下面这张表是实际项目中我们最常用的关键字段对照，命名以业务含义为准，不是两侧系统的原始字段名。

在轻易云上如何配置

我们用轻易云数据集成平台（Qeasy）承接这条策略时，配置上有几个典型动作。

第一步是源端接入：把 CRM 的订单查询接口登记成一个数据源，请求参数里 start_time 用 {{LAST_SYNC_TIME|datetime}}、end_time 用 {{CURRENT_TIME|datetime}}，配合 start_index 与 count 做分页，一次拉一页，循环到空页为止。

第二步是目标端写入：把 ERP 的订单上传接口登记成执行动作，shop_id 在轻易云里集中维护一张「店铺编码映射表」，避免散落在每条策略里——这是轻易云客户最常见的应对模式之一：编码映射集中管理。幂等键 so_id 直接绑源端 order_no，开启 idCheck，避免重复推送。

第三步是字段映射与转换：在映射画布里把上面那张表里的字段一一对应，订单状态、店铺编码这类枚举值通过「查找表」组件统一处理，而不是在每条字段上写脚本。

第四步是模型构建：目标端标记 buildModel=true 时，让轻易云按接口返回结构自动建模型，省去手工建模的工夫。

实施步骤

这条策略我们建议分三阶段上线。

阶段一：增量起点。 先用历史最大单号或最近一次成功时间作为 LAST_SYNC_TIME 初始值，跑一次手动全量补齐，把目标侧店铺、会员、商品编码等基础资料铺好。这一步通常依赖商品、会员等前置策略先完成。

阶段二：全量触发。 全量不是每次都跑，而是作为兜底——比如每月一次，或在增量跑挂、怀疑丢单时手动触发一次。这是轻易云客户的另一个常见模式：增量与全量双轨。

阶段三：调度频率。 源端 crontab 建议 0-59/10 7-22 * * *，即每天 7 点到 22 点，每 10 分钟一轮；目标端错峰 3-59/10 7-22 * * *，避免源端还在请求中、目标端就开始写。夜间不调度，留给库存、报表类任务。

踩坑复盘

坑一：分页参数 count 写死。 典型错误是把 count 固定成 10 或 50，碰到大客户一天几千单就漏。稳妥的做法是先用默认 10 验证逻辑，跑通后再调到一个安全上限（比如 100），并在循环里显式判空。

坑二：订单状态枚举直接透传。 两侧「已付款」「待发货」命名几乎不会一样，直接透传必然踩坑。我们后来所有客户项目都做了一张状态映射表，集中在轻易云的「查找表」里维护，业务方改一处即可。

坑三：removed 参数忽略。 源端删除/作废的单如果不带 removed=1 单独拉，被删单就永远丢不了。稳妥的做法是：增量拉正常单 + 定时单独拉一次删除单，在目标侧走作废逻辑。

坑四：表头表体一起发。 ERP 接口常常要求先建表头再传表体，或表头里要带合计金额。一次性把整张订单塞过去，失败时定位不到是头还是体。我们后来统一改为表头表体分阶段——先推表头，成功后再推明细，失败可重试。

坑五：店铺编码没提前建。 shop_id 在目标侧不存在时直接报错，又因为是非必填字段很容易被忽略。稳妥的做法是在轻易云的策略前置校验里加一道「店铺编码存在性检查」。

适用场景与不适用场景

适用： CRM 作为订单入口、ERP 作为后履约中枢的零售或分销企业；订单量在日均几百到几千单、增量为主；需要把订单状态、店铺、买家三套编码在两侧打通。

不适用： 两侧都要求实时秒级同步（轻易云默认 10 分钟级调度）；订单结构差异巨大、需要复杂二次开发；或源端根本不是订单「权威源」、仍有大量手工补单场景——这时应先治理源头。