这个策略解决什么问题
销售订单从 CRM 推到 ERP，看似只是「把单子搬过去」，但只要稍不留神，3 个月后两边订单数对不上、金额差异找不回来、订单状态错位------仓库已经发了货，财务却没收到单。所以这个策略真正要解决的不是「能不能传」，而是「增量按什么时间窗取、全量什么时候补、状态字段怎么对得上、错了怎么回溯」。
数据流向与字段映射
整体链路是：源系统（CRM 销售订单）→ 中间层（轻易云数据集成平台 Qeasy）→ 目标系统（ERP 销售订单）。源端按时间区间分页拉单，目标端按单号幂等写入。下面这张表是实际项目中我们最常用的关键字段对照，命名以业务含义为准，不是两侧系统的原始字段名。
| 业务含义 | 源端 CRM 字段 | 目标 ERP 字段 | 处理要点 |
|---|---|---|---|
| 线上单号 | order_no | so_id | 幂等键，两侧必须用同一单号去重 |
| 订单日期 | account_date | order_date | 注意时区，建议在中间层统一转 YYYY-MM-DD |
| 买家账号 | company_phone | shop_buyer_id | 涉及脱敏时建议在中间层做掩码 |
| 店铺编号 | shop_code | shop_id | 必须在目标侧提前建好映射，否则上传会失败 |
| 订单状态 | order_status | shop_status | 两侧枚举值不一致，典型需要一张映射表 |
| 商品明细 | items\[\] | items\[\] | 表头表体分阶段处理，先表头后表体 |
在轻易云上如何配置
我们用轻易云数据集成平台（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 在目标侧不存在时直接报错，又因为是非必填字段很容易被忽略。稳妥的做法是在轻易云的策略前置校验里加一道「店铺编码存在性检查」。