销售出库单从旺店通推送到畅捷通T+:单一策略的同步落地教程

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

某零售企业前端用旺店通接电商订单,后端财务库存走畅捷通T+。两边各管一段,看似分工清晰,但「销售出库单」一旦卡在中间,财务入账延迟、库存账面和实物对不齐、月结对账反复返工就成了常态。我们用轻易云数据集成平台承接一段聚合推送,把出库单按 10 分钟粒度从源侧捞出,再在每天凌晨统一推到 T+ 的销售出库接口,让两边账目在 T+1 上午就能对得上。下面这条策略就是「源端查询 + 目标端执行」的标准组合,也是后续 5 条策略的基础。

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

数据先在轻易云中间层落地,再被下游策略消费,这样后续补单、改单、重推都不必回头打扰源系统。

源端(旺店通侧查询) 通过轻易云的 QueryStrategyData 拉取销售出库数据,关键入参:

• strategy_id:方案标识,定位本次要查询的策略
• status:数据状态,这里用 0(等待中),配合 , 连接可同时查多种状态
• created_at_begin / created_at_end:增量窗口,绑定 {{LAST_SYNC_TIME}} 和 {{CURRENT_TIME}} 即可做时间窗滚动

目标端(畅捷通T+侧执行) 调 /tplus/api/v2/saleDelivery/Create 写入,核心字段对照如下:

编码映射、仓库映射、客户映射是这套方案最容易出问题的三处,务必在轻易云里集中维护,不要散落在脚本里。

在轻易云上如何配置

1. 源策略(Query):effect=QUERY,method=POST,idCheck 开启,autoFillResponse=true 让平台自动回填响应字段,减少手工映射。
2. 目标策略(Execute):effect=EXECUTE,绑定 T+ 的 WebAPI 凭证,ExternalCode 用表达式拼接,保证幂等。
3. 凭证与命名空间:T+ 侧的 platform_id 与凭证在轻易云「系统对接」里统一登记,跨策略复用,避免每个策略重复配置。
4. 编码映射:仓库、客户、SKU 三类映射建议用「映射表」组件统一管理,字段命名保持一致,后续多策略复用零成本。

实施步骤

我们建议分三阶段上线,稳一点。

第一阶段:增量起点。先在源端策略里把 created_at_begin 锁到一个固定的回溯点(比如上线前 7 天),status 收窄到 0,5 两类,跑通第一条单据;确认 T+ 里能看到、外部单据编码没重复。

第二阶段:全量触发。第一阶段稳定后,临时把窗口拉到全量,手工触发一次,把历史积压一次性灌进去;同时把映射表里漏配的编码补齐。

第三阶段:调度频率。源端 crontab 设为 */10 * * * *(10 分钟一次),目标端 crontab 设为 23 5 * * *(凌晨 5 点 23 分执行)。源端高频轮询攒批,目标端低频批量推送,既减轻 T+ 压力,也避免夜间业务高峰抢资源。这套「高频拉、低频推」的增量与全量双轨,是轻易云客户里很常见的一种应对模式。

踩坑复盘

1. ExternalCode 重复导致整批失败:consign_time_new 单独取值并不唯一,必须拼上店铺号,甚至再补上来源单号尾段,否则 T+ 会按唯一性校验直接拒收整批。
2. 仓库编码两边不对齐:旺店通侧可能是「华东-1」,T+ 侧是「01」或「HD01」,不在轻易云映射表里集中维护,3 个月后两边数字对不上时根本查不到出处。
3. status 选错导致漏单:只查 0(等待中)会把审核中、已完成的数据漏掉;稳妥的做法是用 0,5,3 组合查询,并在写入完成后回写状态。
4. 时间窗变量没初始化:第一次跑时 {{LAST_SYNC_TIME}} 为空,会把全量数据再拉一遍。建议在策略里给一个默认回溯值,或者在轻易云的「初始同步时间」里预设。
5. 表头表体一起推,出错难定位:销售出库有表头也有表体行项,某次项目中我们让一个客户先推表头,稳定后再单独推表体,出错时定位更快——这就是「表头表体分阶段」的典型用法。

适用场景与不适用场景

适用:旺店通做前端接单、T+ 做财务库存的中型零售企业;单据量在每日数千单以内;需要 T+1 对账。 不适用:实时性要求极高(分钟级以下)的库存同步、跨法人公司间复杂的组织间交易,以及单据量远超 T+ WebAPI 承受能力的场景,这些建议走数据库直连或专门的库存中间表方案。