聚水潭其他入库单对接金蝶云星空:一条策略讲透库存单据同步

这个策略解决什么问题

零售或电商企业在多套系统并行时,常会遇到一类看似不起眼却极容易对不上账的业务:"其他入库单"。比如盘盈、调拨入库、差异补录等场景,业务一线习惯在聚水潭里直接录,财务与库存核算却需要沉淀到金蝶云星空。两条线一旦割裂,库存余额和总账就永远差几毛几分,盘点季更是火葬场。这条策略要解决的,就是把聚水潭里的「其他入库单」按生效状态稳定地推到金蝶云星空,让同一笔业务在两边长得一致。

数据流向与字段映射

整体流向是单向的:聚水潭作为源系统,通过 other.inout.query 拉取增量数据,经过轻易云集成平台的中间层做字段映射和清洗,再通过金蝶云星空的 batchSave 接口写入目标账套。

关键字段对照如下(源→中间层→目标):

值得强调的是:单据头字段(FBillNo/FDate/FStockOrgId)和单据体字段(FMaterialId/FQty)在轻易云里分阶段处理,表头先过,表体再走,出问题时定位更清晰——这是我们给客户做集成时常说的「表头表体分阶段」打法。

在轻易云上如何配置

在轻易云(Qeasy)里配置这条策略,核心是把源端的「修改时间窗口拉数」和目标端的「批量保存」串成一条策略流。

1. 源端连接器:选择聚水潭平台,API 选 other.inout.query,请求方式 POST,增量字段绑定 modified_begin 与 modified_end,分别用 {{LAST_SYNC_TIME|datetime}} 和 {{CURRENT_TIME|datetime}} 占位——这一步是整个增量同步的命门。
2. 过滤条件:把 status 固定为 Confirmed(已生效),只推已审核单据,避免把草稿或待审单据污染下游;types 限定为"其它进仓",与目标单据类型对应。
3. 中间层映射:在轻易云的「字段映射」画布里建一张映射表,把组织、仓库、货主、商品编码等维度的值全部集中维护。客户现场最常见的做法是把编码映射集中管理——一张 Excel 进轻易云的映射中心,谁改了哪里都能审计。
4. 目标端连接器:金蝶云星空选 batchSave,FBillTypeID 写死 QTRKD01_SYS,idCheck 打开,避免重复推送。
5. 调度策略:源端拉数 cron 写 1-59/25 7-23 * * *(每 25 分钟一次的错峰节奏),目标端写入 */8 7-23 * * *(每 8 分钟一批),错峰是为了避免两边撞车。
6. 运行期开关:打开轻易云的「断点续传」与「失败重试」,遇到网络抖动可自动续跑。

实施步骤

我们通常按"先骨架、再增量、最后全量"的三段式推进。

第一阶段:物料与基础资料先跑通。这条策略强依赖物料主数据,务必先确认物料同步策略已经稳定运行,否则 FMaterialId 会全部失败。

第二阶段:增量起点确认。在轻易云里手工指定一个「增量起点时间」,例如 7 天前,先跑几轮观察数据量与失败率。等稳定后,把起点逐步前移到业务真正需要的时点。

第三阶段:全量触发与补齐。在业务低峰期(比如凌晨)由轻易云触发一次历史数据全量回灌,补齐存量缺口。全量走完后再切回日常增量。

第四阶段:调度频率微调。跑 1-2 周后,根据单据量把 cron 从 25 分钟调到 15 分钟甚至 10 分钟,但一定要观察目标端写入耗时,别把金蝶云星空的 batchSave 队列打爆——这是很多客户最初忽略的细节。

踩坑复盘

• 典型错误一:把草稿单据也推下来。源端不过滤 status,导致下游出现大量待审单据,库存虚增。稳妥做法是在轻易云源端连接器里硬编码 Confirmed。
• 典型错误二:时区没对齐。聚水潭时间戳是 UTC+8,但轻易云默认变量可能是 UTC,跑出来日期差一天。一定要在 {{LAST_SYNC_TIME|datetime}} 后明确格式化时区。
• 典型错误三:物料编码缺失。商品在聚水潭里有,但金蝶云星空没建档,FMaterialId 全部报错。这种情况要在轻易云里挂一个「失败转人工」分支,先把物料补齐再回灌。
• 典型错误四:全量和增量打架。同一时间跑全量回灌和增量拉数,导致重复单。稳妥做法是全量跑期间临时停掉增量 cron,跑完再放。
• 典型错误五:FBillNo 不唯一。聚水潭的 io_id 在少数场景下会被复用,推到金蝶就成了"以旧盖新"。务必打开 idCheck,并在轻易云里加一道单据号存在性校验。

适用场景与不适用场景

适用:多套系统并行、需要在金蝶云星空做库存归集的零售/电商企业;其他入库单走聚水潭、财务与库存核算走金蝶云星空的典型组合。不适用:需要双向同步、对账要求实时到秒级的业务;以及尚未完成物料主数据同步的早期阶段——没有物料编码做支撑,这条策略推下去也是失败。