旺店通物流单号回写金蝶云星空销售出库：单策略同步实战教程

这个策略解决什么问题

某零售企业的订单履约链路是这样的：前端在旺店通里审单、打单、发货，物流公司回传单号落在旺店通一侧；而财务与仓储口径以金蝶云星空的销售出库单为准。问题在于，物流单号经常滞后于发货动作，客服和仓库需要在金蝶里看到真实承运单号才能对账、推送下一步。这个策略只做一件事：把旺店通已发货的销售出库增量数据，按单据维度把物流单号回写到金蝶云星空的 SAL_OUTSTOCK。它不是全量镜像，而是一个"窄而准"的回写通道。

数据流向与字段映射

数据流向是单向回写：旺店通（源）→ 轻易云数据集成平台（中间层，Qeasy 承接编排与转换）→ 金蝶云星空（目标）。

关键字段对照（源 → 目标）：

目标端调用的是金蝶的 batchSave 接口，业务对象表单 ID 固定为 SAL_OUTSTOCK，操作类型 BatchSave，是否网控 IsUserModelInit=true，由 Qeasy 把源端明细折叠进 FEntity 数组后整批提交。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略拆成源读、转换、写目标三段，配置要点如下：

1. 源端读取器：选用 QUERY 动作，API 选 wdt.stockout.order.query.trade，主键 stockout_id，幂等开关 idCheck=true。把增量起点写成函数表达式，避免每次手动改时间。
2. 增量起点与时间窗：start_time 用 _function from_unixtime((CURRENT_TIME-259200),'%Y-%m-%d %H:%i:%s')（当前时刻往前 3 天），end_time 用 CURRENT_TIME-172800（往前 2 天）。这是一个 24 小时滑动窗，确保即使某次调度漏单，下一轮也能补回来。
3. 状态过滤：status 留空交给上游按需传值，但生产里建议固定传 95（已发货），避免把已取消或异常发货混进来。
4. 编码映射集中管理：在轻易云的"映射中心"里把旺店通的店铺编码 shop_no、仓库编码、物流公司编码统一映射到金蝶侧的档案 ID。这类映射一定要集中维护，散落在每个策略里 3 个月后必乱。
5. 目标端写入器：EXCUTE 动作，API batchSave，FormId=SAL_OUTSTOCK，Operation=BatchSave，IsUserModelInit=true。FID 用 _function substring_index('{{src_tids}}','_',-1) 从合并后的原始单号串里截取真正的金蝶单据号。
6. 表头表体分阶段：本策略只回写物流单号，不重传整张单据的金额、税额。因此 FEntity 里只放与物流相关的字段，其余字段保持原值，避免把已审核的单据"打回"待审核。

实施步骤

我们建议把上线拆成三段：

1. 全量触发（一次性）：先用更宽的时间窗（比如过去 30 天）跑一次全量，把历史已发货单据的物流单号全部回写一遍。生产环境的全量最好放在业务低峰期，并且关闭金蝶的网控或安排专人放行。
2. 增量起点切换：全量完成后，把 start_time 的偏移值切回正常的 3 天滑动窗，让调度进入日常节奏。源端调度 crontab 建议 13 */3 * * *（每 3 小时的第 13 分钟），目标端调度 22 */3 * * *，源比目标早 9 分钟，留出转换与缓冲时间。
3. 调度频率与监控：每 3 小时一轮已足够覆盖绝大多数物流回传延迟。如果企业是次日 12 点对账，把一轮调度对齐到对账前 1 小时即可。增量与全量双轨运行期间，必须在 Qeasy 里挂上"单据数对账"告警，一旦某小时回写条数环比下跌超过阈值，立刻人工介入。

踩坑复盘

1. 滑动窗的边界不要设太短。最早我们图省事把 start_time 设成 1 小时前，结果一旦调度器抽风漏跑，那一小时内的发货就再也补不回来——除非重跑全量。3 天 vs 2 天的窗口是踩过几次坑之后才定的稳妥值。
2. 物流公司编码不一致。旺店通用的是自家物流商编码，金蝶要的是承运商档案 ID。第一版没做映射，写进去的金蝶记录全部报错或变成"未知承运商"。后面所有这类跨系统档案，都先在轻易云映射中心建表，不允许在策略里硬编码。
3. IsUserModelInit=true 一定要保留。金蝶的批量保存如果关掉网控，并发场景下会出现"单据正在被他人编辑"的冲突。保留网控、由金蝶内部排队，是最稳的做法。
4. 不要把整张出库单重写一遍。这个策略如果图省事用整单覆盖，会把金蝶侧已审核、已生成凭证的单据"复活"成待审核状态，财务那边一定会炸。回写物流单号就只动物流字段，其余字段保持原值。
5. src_tids 截尾函数依赖拼接顺序。substring_index('_',-1) 取末段，前提是源端原始单号串确实把金蝶单据号放在末尾。曾经遇到过一个仓库系统把店铺编号拼在末尾，结果截出来全错。后来统一约定拼接顺序，才彻底解决。

适用场景与不适用场景

适用：旺店通做履约中枢、金蝶做财务/仓储中枢，需要把已发货状态的物流单号回传到金蝶供对账与下游使用的零售与分销场景。不适用：需要同步出库单全量字段（含金额、税额、价目表）的场景，此时应走另一条整单同步策略；也不适用于跨主体、跨账套的复杂组织间结算，那需要走专门的应收单策略。