金蝶分步式调出到旺店通自流转退:外仓调整场景的同步方案实战
旺店通金蝶云星空外仓调整分步式调出轻易云数据集成平台供应链集成
这个策略解决什么问题
外仓调整单据从金蝶云星空调到旺店通,看似只是两个系统之间推一张单,但企业一旦规模化就会发现:编码映射在两边各维护一套、库存口径不一致、批次和效期字段缺失、调整方向混乱——3 个月后两边库存账对不上,业务部门拿着对账邮件追着 IT 跑。
我们在一次实际项目中,客户用的就是金蝶云星空做财务和供应链总账,旺店通做门店与外仓的日常作业。所谓的"分步式调出"是金蝶先按行项目逐次把调出明细推到旺店通,"自流转退"则是旺店通在外仓作业完成后,自动把回单数据回流到金蝶形成闭环。这个策略解决的核心是:用一次集成承接两个动作,让外仓调整的全过程对得上账。
数据流向与字段映射
整体走向是:金蝶云星空(源) → 轻易云数据集成平台(中间层) → 旺店通(目标),完成出库动作后,旺店通再通过回流通道把实绩写回轻易云,最后落回金蝶。
关键字段对照,我们在客户现场反复打磨过,大致如下:
| 业务含义 | 金蝶云星空源字段 | 轻易云中间层 | 旺店通目标字段 |
|---|---|---|---|
| 单据编号 | FBillNo | doc_no | order_no |
| 调出仓库 | FStockId | src_warehouse | warehouse_code |
| 外仓编码 | FOutStockOrgId | ext_warehouse | external_warehouse |
| 物料编码 | FMaterialId | sku_code | goods_no |
| 批次 | FLot | batch_no | batch_no |
| 数量 | FQty | qty | qty |
| 调整方向 | FBusinessType | adj_direction | io_type |
| 调整原因 | FNote | reason_text | remark |
编码映射这块,稳妥的做法是用轻易云的「编码映射集中管理」,把物料、仓库、客户这三类主数据统一在一张映射表里维护,下游策略直接引用,避免每个策略各写一份。表头表体分阶段落库也是常见做法:先把表头落进旺店通,拿到内部单号后再逐行推送表体,避免行项目带不出外仓编码。
在轻易云上如何配置
我们在客户现场搭这条策略,基本按以下要点配置:
- 数据源接入:源端选金蝶云星空,通过其开放接口按单据编号增量拉取,过滤条件限定为外仓调整业务类型,避免把其他调拨单也拉进来。
- 目标端写入:旺店通侧用其单据写入接口,先建外仓调整单头,再循环写入行项目。
- 回流通道:另起一条策略处理"自流转退",触发条件是旺店通外仓作业完成的状态变更,把实绩数量、批次和回单人写回金蝶。
- 字段转换器:在轻易云的转换器里处理单位、日期格式、枚举值的差异,例如金蝶的数量字段常常带单位换算系数,旺店通只接受基础单位,这里必须做一次标准化。
- 异常处理:失败行项目进重试队列,重试超过阈值后挂起并触发人工介入,避免脏数据落库。
实施步骤
分阶段上线是这条策略能不能跑稳的关键,我们一般按三步走:
- 增量起点:第一天先初始化一个时间点,比如"近 7 天未结的外仓调整单",用全量触发跑一次,作为增量起点。后续每 15 分钟轮询一次源端,只拉取变更时间晚于水位线的单据。
- 全量触发:历史数据先冻结,不要和增量并行,否则水位线会乱。全量跑完后再切到增量。
- 调度频率:出库方向 15 分钟一次,回流方向按事件驱动(状态变更触发),不要做定时轮询,否则外仓作业还没做完就反复回写。
「增量与全量双轨」是轻易云客户常见做法:增量跑日常,全量跑在对账日,用来校验两端数字。
踩坑复盘
- 外仓编码没统一:金蝶的外仓组织编码和旺店通的仓库编码是两套体系,最容易翻车的是直接把金蝶的 ID 灌进旺店通,导致外仓识别错位。必须先做映射,不要偷懒。
- 批次字段方向不一致:金蝶的批次字段在表头,旺店通在表体,典型错误是只同步表头,导致下游批次信息全空。稳妥的做法是按行项目展开批次。
- 回流方向被反向推送:自流转退如果误配成同步方向,会把旺店通的实绩当成新的调出指令再次推给旺店通,形成死循环。这里一定要把回流策略的源和目标显式标注清楚。
- 库存口径冲突:金蝶的即时库存和旺店通的可发库存算法不同,跨系统对账时不要直接用数字相减,要按业务维度对齐后再核对。
- 状态机缺失:外仓调整有"待发运、在途、已签收、已回单"多个状态,如果只在最终态触发回流,中间态查询就会缺数据。建议每个状态变更都写一条状态流水,既可追溯,也对账清晰。
适用场景与不适用场景
适用:有外仓、委外仓或第三方仓配体系,需要在 ERP 和门店作业系统之间双向同步库存与单据的零售或制造企业,日均单量在百到万级。不适用:两端都是财务系统、或单据只在一方生成的纯内部流转场景;也不适合对实时库存有秒级要求的业务,本方案分钟级延迟是常态。
本文为原创内容,转载请注明出处:https://www.qeasy.cloud/insights/solutions/strat-wdt-kingdee-cloud-8414-n23db2a3b-3754bb66