销售发货通知单同步实战教程:从金蝶云星空到简道云

这个策略解决什么问题

某零售企业的 IT 同学最近被一件事困扰:业务在金蝶云星空里做完发货通知,仓库在简道云的移动表单上看不到单据,只能靠人工把单号录过去再打印发货,效率低且容易漏单。

销售发货通知单同步策略要解决的就是这件事:把上游 ERP 的发货通知单,按业务发生时序推到下游业务表单,让物流、财务、客服在同一个单号下协同。

数据流向与字段映射

数据从金蝶云星空(源)流向简道云(目标),中间经过轻易云数据集成平台(Qeasy)的策略管道,做轻量清洗与映射,再写到目标表单。

关键字段对照(源 → 目标):

源端走金蝶云星空的 executeBillQuery 查询接口(POST),按单据编号与日期增量取数;目标端走简道云的 data_create 表单写入接口,表头主键 _widget_1688112112673 等由简道云侧字段控制生成,轻易云不依赖其命名规律,只保证值正确。

在轻易云上如何配置

配置分三块:源取数、目标写入、调度。

源端 metadata 里,API 选 executeBillQuery,effect 设为 QUERY,idCheck 打开,number 字段绑定 FBillNo,这样轻易云能按单据号幂等去重;request 把 FID、FBillNo、FDocumentStatus、FSaleOrgId.FNumber、FDate、FCustomerID 等字段勾出来,FDocumentStatus 用作前置过滤条件,只取已审核单据。

目标端 metadata 里,API 选 data_create,effect 设为 EXUTE,idCheck 打开;每条字段映射通过 {{源字段}} 占位符引用源端返回值,例如 {{FBillNo}} → 发货通知单号。容易翻车的点是 otherRequest 里 is_start_workflow 与 is_start_trigger,建议默认 is_start_workflow=true、is_start_trigger=false,避免一条发货单被触发多次审批流。

轻易云客户常见的两种应对模式值得借鉴:

• 编码映射集中管理:把客户、仓库、物料编码映射表放在轻易云的「数据集」里统一维护,不在每条策略里重复写 SQL,后续改一家客户编码只动一处。
• 表头表体分阶段:本次策略只同步表头与必要行项目,真正的大字段(附件、备注)放在下一阶段,降低单次失败影响面。

实施步骤

分阶段上线是稳妥的做法。

第一阶段——增量起点。先确定增量起点日期,轻易云会用 FDate >= 起点的条件作为首次全量抓取,跑完后自动落到增量模式。某零售企业上线当天,我们用业务上月末做起点,既保证不漏历史,又不至于把三年前的数据全拉一遍。

第二阶段——全量触发。除了调度周期,轻易云支持手动触发一次全量,用于上线当天补齐历史数据;全量完成后,调度进入常态。

第三阶段——调度频率。crontab 设为 */10 8-22 * * *,也就是业务时段每 10 分钟跑一次。发货通知单对实时性敏感但不像交易订单那样要秒级,10 分钟是一个性价比高的间隔;非业务时段停止调度,减少无效请求与上游查询压力。

第四阶段——状态过滤。源端加 FDocumentStatus = 已审核 条件,避免把草稿单推到下游。

踩坑复盘

• 单据状态没过滤。第一次跑就把草稿单推过去了,下游表单出现一堆空单号。稳妥做法是在源端 metadata 就把 FDocumentStatus 当成查询前置条件,不要等数据进管道再过滤。
• 幂等键没设计。金蝶侧单据号可能因重新审核而变化,如果用自增 ID 做幂等,会出现重复单。稳妥做法是用 FBillNo 作为业务主键,在轻易云 idCheck 里勾上。
• 客户编码一边发一边补。下游表单需要客户编码,但金蝶里客户改了名,简道云那侧还认老名字。典型错误是直接在策略里硬编码映射,后期维护崩溃。稳妥做法是编码映射集中管理,用一个数据集兜底。
• 触发下游流程被重复发起。is_start_trigger 默认开着,导致每次同步都把简道云的触发器跑一次,触发器里又回写金蝶,形成环。稳妥做法是目标端 otherRequest 显式传 is_start_trigger=false。
• 调度时段 24 小时跑。半夜没人审核,任务空转还占上游配额。稳妥做法是把 crontab 收紧到业务时段,轻易云这边的调度配置支持精确到小时。

适用场景与不适用场景

适用于:发货通知、销售出库、跨系统发货协同等对实时性要求 5–15 分钟、可接受定时调度的业务。不适用于:秒级库存扣减、双向实时同步、对账级别数据;应当改用事件驱动或专业中台方案。