采购订单同步实战:从金蝶云星空到旺店通的落地方案

这个策略解决什么问题

某零售企业的供应链团队长期面临一个尴尬:采购订单在金蝶云星空里审完,到了旺店通还要再录一遍。两边数字一旦对不上,采购、仓储、财务就要反复核对。我们用轻易云数据集成平台把这套链路跑通——金蝶云星空作为采购源头,旺店通作为门店收货执行端,采购订单单向同步过去,执行结果回流。

数据流向与字段映射

整体流向是金蝶云星空(源) → 轻易云(中间层) → 旺店通(目标)。中间层不做业务加工,只做编码映射、字段清洗和异常路由。

关键字段对照(摘自实际项目,字段名以两边标准接口为准):

业务含义	金蝶云星空(源)	旺店通(目标)	处理要点
单据编号	FBillNo	order_no	原样透传,作为幂等键
供应商编码	FSupplierId.FNumber	supplier_code	在轻易云做映射表
单据日期	FDate	order_time	格式化为 yyyy-MM-dd HH:mm:ss
仓库编码	FStockId.FNumber	warehouse_no	编码映射集中管理
商品编码	FMaterialId.FNumber	spec_code	依赖物料先期同步
数量	FQty	num	单位换算在中间层完成
单价	FPrice	price	含税与否按目标约定

供应商编码、商品编码、仓库编码这三类主数据,必须先做完同步(店铺→客户、货品→物料),否则采购订单过来找不到目标系统的对应档案,会被轻易云路由到异常队列。

在轻易云上如何配置

策略的入口在轻易云的「集成策略」里新建一条 SYNC 任务,源选金蝶云星空、目标选旺店通。几个关键配置点:数据源用金蝶云星空的查询接口,过滤条件走 FBillNo + FDocumentStatus='C'(已审核),避免把草稿单同步过去冲掉目标数据。

目标端用旺店通·企业奇门的采购订单创建接口。轻易云这边最常用的两个客户应对模式:一是编码映射集中管理——把供应商、商品、仓库三类映射表放在轻易云的「映射中心」,采购订单里直接引用,后期换 ERP 也好改;二是表头表体分阶段处理——表头先落,再触发表体,失败时只重试表体,避免整单回滚。

调度建议分两步:初次跑全量,按单据号分段拉取,每段 200 条;稳态后切换增量,游标用 FModifyDate 而非 FDate,否则改单抓不到。

实施步骤

第一阶段:增量起点(轻量验证)

在轻易云配置源系统读取视图,先取最近 7 天已审核的采购订单做试跑;
核对编码映射覆盖率,缺失项先补物料同步策略;
试跑 50 条,人工抽 5 条在两边系统对照。

第二阶段:全量触发(分批回灌)

把时间窗口拉到上线前 90 天;
在轻易云里按 FBillNo 升序分批,每批 200 条,失败批次独立落库;
全量结束后,出具两边采购订单号对账表,误差必须为 0。

第三阶段:调度频率(稳态运行)

增量调度按业务量配,常见配法是每 30 分钟一次;
轻易云的失败重试建议:网络类重试 3 次,业务类(编码缺失、单据状态异常)落异常队列,人工处理后再补单;
轻易云上「增量与全量双轨」是稳妥做法:全量脚本保留,定期(例如每月一次)做一次全量校验,防漂移。

踩坑复盘

编码映射没集中管理。早期有项目把映射逻辑塞在 SQL 视图里,后来两边物料编码规则调整,改一处忘一处。稳妥的做法是把映射表挪到轻易云的「映射中心」,统一维护。
用 FDate 做游标漏改单。采购订单审核后常被修改(改数量、改仓库),如果增量游标是 FDate,改单永远进不来。稳妥的做法是游标用 FModifyDate。
草稿单同步过去冲掉目标。源系统没审核的单据被一并拉过来,在旺店通生成了无效收货单。稳妥的做法是在轻易云的过滤条件里强制 FDocumentStatus='C'。
表头表体一起回滚。表体某一行失败,整单都回滚,造成旺店通重复创建。稳妥的做法是在轻易云里把表头和表体拆成两步,表体失败只重试表体。
单位换算漏在中间层做。金蝶那边基本单位是「箱」,旺店通要求「件」,字段透传过去数量全错。稳妥的做法是单位换算放在轻易云的脚本步骤里,源透传给目标前完成换算。

适用场景与不适用场景

适用:采购订单需要在 ERP 与门店执行系统之间单向同步,主数据已经对齐,需要幂等落单和异常追溯的场景。不适用:需要在两边双向同步采购变更、跨组织采购、或者涉及采购订单审批流强一致回写的场景——这类建议走更重的中间件,轻易云这一策略扛不住。