采购入库单从旺店通到金蝶云星空的下推同步实战

这个策略解决什么问题

某零售企业的业务是这样跑的:门店端在旺店通里收采购到货,录采购入库单;财务和供应链的台账则在金蝶云星空里。两条线一旦对不上,月底结账对账就是一场灾难。这条策略的核心目标,是把旺店通的采购入库单,以下推方式同步到金蝶云星空,做到两边单据一一对应、库存与应付口径一致。我们用轻易云数据集成平台(Qeasy)承接这件事,关键不是"能传过去",而是"传过去之后两边都认账"。

数据流向与字段映射

整体流向是单向的:旺店通 → 轻易云中间层 → 金蝶云星空。轻易云不做业务加工,但负责字段重映射、编码转换和异常分流。

关键字段对照如下(从源到目标,只列容易出问题的部分):

编码映射(供应商、仓库、商品)是这条策略的命门。我们在轻易云里把它做成集中映射表,任何新增项都只改一处,绝不写死在脚本里。

在轻易云上如何配置

第一,数据源接入。源端走旺店通开放平台接口,目标端走金蝶云星空的保存/审核接口。轻易云内置的连接器可以直接配,凭据走平台的凭证管理,不落到脚本里。

第二,字段映射。在轻易云的映射画布里,把上表里的字段一一对应,映射表外挂在「编码管理」模块里。客户常见做法是把供应商、仓库、商品三张映射表独立出来,谁负责哪个域就改自己那张表。

第三,下推模式。金蝶采购入库单通常有表头和表体,这里要选「整单下推」,不要逐分录推送——逐分录推会丢失单据关联,后续核销直接乱套。

第四,异常处理。轻易云把每一条失败记录落到异常队列,带原始 payload 和目标系统的报错信息,值班同事按错误码分类处理:编码缺失、必填项为空、单价异常,三类问题处理路径完全不同。

第五,表头表体分阶段。上线初期建议先推表头+少量字段跑通链路,确认两边单据能对上,再补齐表体所有明细字段。一次性把全部字段铺开,是这条策略最常见的翻车姿势。

实施步骤

我们建议分三步走,而不是一上来就跑全量。

第一步:全量打底。取源系统近 30 天的历史单据做一次性全量同步,只用于验证链路。轻易云的「全量触发」可以在后台手动跑,跑完后两边数据比对,差异清零再往下走。

第二步:增量起点。确认一个清晰的时间分界点(如某日凌晨),从那一刻起只推新增和变更。轻易云用时间戳+单据状态做增量游标,避免重复推送和漏推。

第三步:调度频率。采购入库单对实时性要求不高,但也不能等到月底。建议每 15 分钟调度一次,业务低峰期可放宽到 30 分钟。轻易云的调度器支持按 cron 表达式配置,失败重试 3 次,3 次仍失败自动入异常队列。

另外提醒一句:源端的「已审」状态是增量游标的硬条件,草稿状态的单据不参与同步,避免目标系统出现孤儿单。

踩坑复盘

坑 1:编码映射写死在脚本里。 上线 3 个月,两边数字对不上,一查是新开了一家门店,仓库编码没同步过来,又因为写在多个脚本里,改了三处漏了一处。稳妥的做法:所有编码映射一律外置到轻易云的「编码管理」,只改一处。

坑 2:含税/不含税口径没对齐。 旺店通默认含税单价,金蝶可能取不含税。两种处理路径:要么源端转换后再推,要么目标端按含税入库单配置。一定要在 PoC 阶段就确定,不要等财务月结时才发现。

坑 3:时区问题。 源端按本地时区存时间戳,目标端按 UTC 解析,跨日单据会丢到下一天。建议在轻易云的字段映射里统一做时区转换,而不是依赖两边的默认行为。

坑 4:一次铺开全部字段。 表头表体 30 多个字段一次上线,出问题排查成本极高。我们推行「表头表体分阶段」:先打通主链路,再加明细字段,再加自定义项。

坑 5:增量起点没定死。 全量跑完后没有明确分界点,导致全量和增量重叠推,目标系统出现大量重复单。稳妥的做法是:全量完成后打一个「断点标记」,增量只推标记之后的数据。

适用场景与不适用场景

适用:旺店通作为业务前台、金蝶云星空作为供应链/财务中台,采购入库单需要单向汇聚;组织稳定、编码体系已建立。不适用:需要双向同步、频繁冲销或红字单据、对账要求实时到秒级的场景,这类需求要在策略设计阶段就另作讨论。