金蝶收料通知单同步至旺店通采购入库单:中转仓模式的实战配置

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

某零售企业同时使用金蝶云星空做财务与供应链总账,使用旺店通做门店与电商履约。两边系统对「货到入库」的口径不一致:金蝶以收料通知单作为质检和应付的入口,旺店通则要求采购入库单直接驱动库存与上架。

如果两边人工重复录入,会产生三类问题:数量错位(收料数量与上架数量不一致)、单号断链(金蝶单据号与旺店通单据号无法互查)、跨天延迟(夜班收货无法当天入账)。我们用轻易云数据集成平台承接这条链路,目标是把金蝶的收料通知单按中转仓规则生成旺店通侧的采购入库单,实现一次录入、两端生效。

数据流向与字段映射

整体流向为:金蝶云星空(收料通知单) → 轻易云中间层 → 旺店通(采购入库单)。中转仓模式的关键,在于「仓库编码」需要在中间层做一次落地映射,而不是只把字段透传过去。

关键字段对照(简化版,实际项目以客户主数据为准):

值得强调的是,编码映射集中管理是轻易云上这类项目的常见做法:物料、供应商、仓库三类主数据,统一在一张映射表中维护,变更时只需改一处,不会扩散到多个策略。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略按「源 → 映射 → 目标」三段式编排:

1. 源端:选择金蝶云星空的收料通知单接口,采用按修改时间增量拉取,初始同步时建议回溯 N 天作为全量基线。
2. 中间层:在轻易云的转换器里完成字段映射、单位换算与中转仓落库;编码映射表放在轻易云的「数据中心」组件中统一维护。
3. 目标端:调用旺店通的采购入库单写入接口,表头与表体分阶段推送——表头先落,表体按行项目分批提交,降低单据失败时回滚成本。

典型配置要点:

• 增量起点:第一次运行前,人工确定一个「历史回溯截止日期」,避免把 3 年前的历史单据一起拉过来,造成目标端初始库存漂移。
• 中转仓标识:在映射脚本里增加 warehouse_type = TRANSIT 的判定,源端是中转仓的收料单才推,正式仓的收料单走另外的策略链路,避免混流。
• 失败重试:轻易云的运行日志里可以直接看到失败行,通常重试即可,但若连续 3 次失败,建议转入人工处理队列,不要无限重试把日志冲爆。

实施步骤

分阶段调度是这类采购单据同步的稳妥做法:

• 阶段一:增量起点。在轻易云里配置定时任务,首次运行回溯一个账期(例如近 90 天)作为初始基线,运行完成后立即切换为「按修改时间增量」模式,频率建议每 15 分钟一次,既及时又不会压垮源系统。
• 阶段二:全量触发。如果客户要求每天做一次全量核对,可以将全量任务放到凌晨低峰期,与增量任务互斥执行,避免锁表。
• 阶段三:调度频率。建议「增量 + 全量双轨」:增量保证实时性,全量保证一致性。轻易云客户里比较常见的应对模式是表头表体分阶段——表头失败阻断,表体失败只影响该行,便于运维排错。

具体到本策略:每天 06:00 触发一次全量,白天每 15 分钟跑一次增量;每次执行完成后,轻易云会记录成功条数、失败条数与耗时,便于周报里直接出图。

踩坑复盘

以下是我们在客户现场复盘过的高频问题:

1. 中转仓与正式仓混流。典型错误是图省事,把仓库映射脚本写成「源端仓库原样透传」,导致中转仓的收料单推到了正式仓,3 个月后两边库存对不上。稳妥的做法是在脚本里加显式分支,按仓库类型分流。
2. 单位换算藏在字段映射里。如果物料存在「箱/件」双单位,直接在字段映射里写换算,后期改起来要翻几十个策略。建议统一在数据中心维护换算系数,字段映射只引用,不写死。
3. 增量起点选错时间。把第一次同步的起点设成「系统上线当天」,结果上线前已经存在的收料单全部漏推,目标端库存偏小。稳妥做法是按客户的财务账期往前回溯一个完整周期。
4. 失败重试无上限。目标端接口偶发超时,自动重试一直循环,把运行日志写满,反而掩盖了真正的异常。建议在轻易云的策略配置里设置最大重试次数和告警阈值。
5. 批次字段非空校验缺失。若启用了批次管理,源端没有批号的目标单据直接推过去,会在目标端产生「无批次入库」的脏数据。校验最好放在中间层,而不是留给目标系统去报错。

适用场景与不适用场景

适用场景:金蝶做供应链总账、旺店通做门店履约,需要中转仓入库业务联动,且两端主数据已对齐的客户。

不适用场景:实时性要求低于 5 分钟的自动入库(建议改用消息队列直推);源端为正式仓直发的收料(应走「金蝶→旺店通正式仓」策略,不要混入本策略);两端主数据尚未统一的过渡期(先做主数据治理,再做单据同步)。