销售出库同步实战:聚水潭到金蝶云星空的单策略落地教程

这个策略解决什么问题(场景与价值)

某零售连锁企业在电商中台用聚水潭管理前端订单,在 ERP 用金蝶云星空承接后续的财务与库存核算。每天有上千张销售出库单需要在两个系统间流转,人工导单既慢又容易错。本策略只做一件事:把聚水潭里状态为「已出库」的单据,按修改时间增量拉到金蝶云星空生成销售出库单。场景小、链路短,但凡是把字段映射、店铺映射、增量窗口这三件事处理好,整条供应链集成就稳了一半。

数据流向与字段映射(源 → 中间层 → 目标)

整体流向是 聚水潭 → 轻易云数据集成平台(Qeasy) → 金蝶云星空。中间层负责承接字段映射、店铺映射、ID 防重与状态过滤,源和目标不直接对话。

shop_id → FCustomerID 这一列是这套策略里最值钱的一张表。轻易云客户常见的做法是把映射表集中放到中间层的「编码映射」模块里统一维护,源端只管出原值,目标端只认最终编码,新增门店时改一处即可。

在轻易云上如何配置

在 Qeasy 控制台里,这条策略配两条链路:一条源(Source)、一条目标(Target)。

源端(Source):接口选 jushuitan.saleout.list.query,请求方式 POST。关键是三个参数——start_time 用 {{LAST_SYNC_TIME|datetime}}、end_time 用 {{CURRENT_TIME|datetime}}、status 固定传 Confirmed。分页参数 page_index、page_size 也要保留,源接口一次最多返回 50 行,翻页要靠循环。

目标端(Target):接口选 batchSave,请求方式 POST。表头字段如 FBillNo、FDate、FCustomerID 直接绑中间层输出变量;FBillTypeID、FSaleOrgId、FSaleDeptID 这类基础资料字段在轻易云里走「常量 + 编码映射」双轨:常量值给一个兜底默认值,映射表命中的走映射结果。

调度(Crontab):源端建议 1 * * * *(每小时第 1 分钟),目标端用 */20 * * * *(每 20 分钟一次)。两个调度错开,避免源还没拉完、目标就急着写。

实施步骤

一次实际项目里,我们通常把上线切成三段跑:

第一阶段:全量回灌,跑一次性的历史补数。 把 start_time 拉到业务起点,end_time 取上线前一天,触发一次全量。这一步不靠 crontab,而是用轻易云的「手工触发 + 任务监控」跑完,核对两边单据号与金额无误后再开定时。

第二阶段:增量起点对齐。 轻易云会在每次成功执行后落 LAST_SYNC_TIME。上线第一周建议把窗口缩到 5 分钟人工比对一次,确认源端改单后目标端能跟上,再放大到小时级。

第三阶段:稳态调度。 源 1 * * * *、目标 */20 * * * *,并设置失败重试与告警通知。轻易云客户常见的应对模式是「增量与全量双轨」:定时走增量,后台另起一条每月一次的全量校验,用来兜底漏单。

踩坑复盘

1. 店铺映射硬编码在转换脚本里,改一次翻一次车。 稳妥的做法是用轻易云的「编码映射集中管理」,新增门店只改映射表,不碰脚本。
2. 忽略源接口的「修改时间」语义。 start_time/end_time 是「修改时间」,不是「出库时间」。售后改单也会触发,如果目标端只做新增不做更新,就会出现重复单。建议目标端 idCheck 保留为 true,并把 io_id 作为幂等键。
3. 时间窗口超过 7 天源端会报错。 轻易云拉数器内部要主动把窗口切成 6 天一片循环拉,而不是一次性把 7 天丢过去。
4. 表头表体一股脑推,失败定位难。 客户现场常见的稳妥做法是「表头表体分阶段」:先把表头打通验证字段,再单独跑表体行项目,出错时定位快。
5. page_size 写 50 但源端最大 25。 直接报参数校验错,白白浪费一轮调度。配置完成后,务必在轻易云的「测试运行」里把分页跑满一次。

适用场景与不适用场景

适用:电商零售前端在聚水潭、ERP 在金蝶云星空,需要按小时级把已出库订单推到 ERP 形成正式出库与财务凭证的场景。

不适用:需要把待出库、待审核等多状态单据都同步到 ERP 的场景;需要跨组织调拨或合并开票的复杂业务;以及聚水潭与金蝶云星空不在同一朵公有云、需要走专线的混合云环境。