其他入库单同步实战:旺店通到金蝶云星空的容错策略落地

这个策略解决什么问题

某零售企业上线后,前端门店系统里"其他入库"(盘盈、纠错、保修退入等非采购场景)频繁发生,需要实时反映到后端 ERP 的库存组织里。一次实际项目中我们发现,如果只靠人工录入,3 天之后两边数量就明显对不上账。该策略就是要把这类单据自动从源系统增量拉到目标系统,中间通过轻易云做容错封装,即便单条失败也不影响整批入库。

数据流向与字段映射

整体流向是:源系统(旺店通) → 轻易云中间层 → 目标系统(金蝶云星空)。源端用 wdt.stockin.order.query 按最后修改时间增量拉取,过滤 order_type=6(其他入库)和 status=80(已完成)。目标端调用金蝶 batchSave 接口写入 QTRKD01_SYS 单据类型。

关键字段对照如下:

仓库与库存组织的映射在轻易云里集中维护,这是客户现场最常被低估的一环,后期仓库调整时全靠这一张映射表撑住。

在轻易云上如何配置

在轻易云数据集成平台里,这个策略典型配置要点如下:

1. 源平台:新增旺店通·企业奇门接入,选择 wdt.stockin.order.query 接口,开启按 start_time/end_time 增量模式。
2. 目标平台:新增金蝶云星空接入,使用 batchSave,单据类型固定传 QTRKD01_SYS。
3. 映射编排:把仓库编号 → 库存组织、货品编码 → 金蝶物料编码、商品单位 → 计量单位这些映射放进「编码映射集中管理」模块,后续其他单据复用同一张表。
4. 容错配置:在轻易云里勾选"单条失败跳过 + 错误码落错误日志",不要整批回滚;幂等键用 stockin_no 去重,避免重复入库。
5. 响应处理:autoFillResponse=false,写入结果回填到轻易云的运行追踪,方便后期对账。

实施步骤

第一阶段:增量起点校准。先全量跑一次历史数据,把 LAST_SYNC_TIME 锚定到一个明确时间点;之后切换到增量。第二阶段:全量触发。在策略里配置一次性全量触发任务,验证映射正确性;这里我们通常会让客户先在测试账套跑通。第三阶段:调度频率。源端 crontab 设成 */28 7-21 * * *(白天 28 分钟一窗),目标端 */33 7-21 * * *(33 分钟一窗),两个时间窗错开,避免源还在拉、目标就开始写的资源竞争。这是典型的"增量与全量双轨"模式——全量兜底、增量提速。

踩坑复盘

• 典型错误一:把仓库编号直接当成库存组织传过去。源端 warehouse_no 是业务仓库编码,目标端 FStockOrgId 是组织维度,二者不是一回事。稳妥的做法是在映射表里集中维护。
• 典型错误二:增量起点没锚定。直接用部署时间作为起点会导致历史单据全部漏推。稳妥的做法是先跑一次全量,再用全量结束时间作为增量起点。
• 典型错误三:单据类型写死导致其他入库变采购入库。order_type=6 必须显式传,不能省略,否则会被默认成采购入库。
• 典型错误四:整批失败回滚。一批 200 条里只要一条编码缺失就整批回滚,业务方根本接受不了。容错策略必须配成"单条失败跳过 + 错误日志落表"。
• 典型错误五:表头表体分阶段没分开。表头先落、表体再补,中间会有几分钟数据不一致。稳妥的做法是在轻易云里把表头表体打包在一个事务里,但允许单条明细失败后重试。

适用场景与不适用场景

适用:盘盈、保修、纠错等非采购类其他入库场景,单据量大、对实时库存一致性要求高、有现成编码映射基础的零售/分销企业。 不适用:需要走复杂审批流、跨组织调拨、或源端单据状态频繁回滚的场景;这类需求应另起一条带状态机的策略。