领星ERP采购单同步到金蝶云星空:单策略实战教程

这个策略解决什么问题

某跨境零售企业的供应链里,采购员在领星ERP里下采购单,财务和成本核算却跑在金蝶云星空上。订单数据不互通,就会出现"这边下了单,那边看不见"的尴尬:在途物资、应付暂估都对不上。

我们要做的,是把领星ERP里的采购单按创建时间增量拉到金蝶云星空的采购订单模块,定时、自动、可重跑。这一条策略看着只是一个单据搬运,但它依赖物料和供应商两个基础资料先到位,所以上线顺序很重要。

数据流向与字段映射

整体流向是 领星ERP(源) → 轻易云中间层 → 金蝶云星空(目标)。中间层做时间窗口过滤、编码映射、字段补齐,以及调用金蝶 batchSave 之前的拼装。

源端关键字段(来自领星 /erp/sc/routing/data/local_inventory/purchaseOrderList):

目标端关键字段(写入金蝶 batchSave):

编码映射是这条策略最容易出问题的一环。领星的供应商是名称,金蝶要的是编码。我们用一个轻量的 Mongo 查询语句做集中维护:在 Mongo 里存一份 FName → FNumber 的映射表,写一个查询动作去取,而不是把映射逻辑散在每条策略里。这是轻易云客户常见的应对模式——编码映射集中管理,后续新增供应商只在 Mongo 加一行,不用改策略。

在轻易云上如何配置

进入轻易云数据集成平台(Qeasy)的策略编辑页,把源、目标两份元数据分别加载进源端读取器和目标端写入器,中间挂一个转换器。

配置要点:①源端读取器选 WebAPI/POST,粘入领星接口路径,请求体按上面的字段填好,注意 start_date 用 DAYS_AGO_s10 这种相对时间表达式,让窗口每次往前推;②目标端写入器选 batchSave,把每条采购单的明细行拼成金蝶期望的 JSON 结构;③在转换器里,供应商名称 → FSupplierId 这一段,直接用 Mongo 查询动作,避免在策略里硬编码。

另外,源端要勾上 idCheck=true 并用 order_sn 当唯一键,这样重复数据进入时可以幂等去重,避免下游单据号冲突。

实施步骤

阶段一:基础资料先行。 上线前先确认「领星-产品→金蝶-物料」和「领星-供应商→金蝶-供应商」两条策略已经稳定跑过至少一轮,否则采购单进来时找不到物料和供应商编码。

阶段二:增量起点。 第一次上线时,先用一个明确的历史起点(例如 start_date 取月初、end_date 取当前时刻)跑一次历史回灌,把存量订单补齐。之后切换到每日增量。

阶段三:调度频率。 源端 crontab 1 1 * * *(凌晨 1:01),目标端 crontab 1 2 * * *(凌晨 2:01),中间留一小时缓冲。增量窗口默认取「过去 10 天到当前」,留足冗余以覆盖漏数。

阶段四:异常重跑。 如果某天因为网络抖动写失败,先把增量窗口拉宽重跑,再恢复常规调度。不要在生产策略里手动改 start_date,轻易云支持参数化窗口,改一次配置就能复用。

踩坑复盘

坑 1:时间维度选错。 领星接口有 create_time / update_time / expect_arrive_time 三个维度,这里必须用 create_time,否则订单变更后会被反复拉取。

坑 2:分页边界漏单。 length 上限 500,我们用 100 是为了稳。每次翻页要判断 offset 累加后是否还有数据,典型错误是直接按固定页数拉,最后一页不满就停,造成尾部漏数。稳妥的做法是按"返回条数 < length 即停止"判断。

坑 3:供应商编码空指针。 Mongo 映射表里如果没维护某个新供应商,金蝶 batchSave 会因为 FSupplierId 为空直接报错。现场做法是在转换器里加一道空值校验,缺失时把订单抛到"待人工补录"队列,而不是让整批失败。

坑 4:幂等被绕过。 如果 idCheck 没开,重跑时金蝶会重复生成 FBillNo。源端 idCheck=true + order_sn 作为唯一键是必须的。

坑 5:表头表体一锅炖。 采购订单有表头也有明细行,如果一次性把表头和行项目塞进同一个 JSON,字段一多极难排错。轻易云客户的常见做法是表头表体分阶段:先单独写表头,确认无误再补明细行。

适用场景与不适用场景

适用:跨境电商、零售、贸易类企业,业务前端在领星ERP做采购执行,后端在金蝶云星空做财务和成本核算,需要按日把采购单同步到财务侧做应付和入库。

不适用:如果采购执行也在金蝶云星空里完成,或者需要双向实时回写(比如金蝶的修改要反推回领星),本策略的单向增量模式不够,需要单独设计反向同步。