仓库主数据从吉客云同步到金蝶云星空:单一策略实战教程

这个策略解决什么问题

仓库主数据看似基础,真正跑起来却最容易出乱。某零售企业的 ERP 顾问曾吐槽:上线 3 个月,财务和仓储对账时发现两边仓库编码对不上,有人改名字没人改编码,最后库存全乱。这个策略(代号 I0103)只做一件事——把源系统的仓库档案按修改时间增量推到目标系统,并保证编码、名称、属性在两端一致。

数据流向与字段映射

整体链路是单向的 A → B:源端按页拉取变更区间内的仓库记录,中间层做编码与属性的翻译,再调用目标端的批量保存接口写入。

关键字段对照(从源到目标):

我们用轻易云数据集成平台(Qeasy)承接这条链路,编码映射和属性字典放在平台的「映射中心」集中维护,后续调整不必动每个策略。

在轻易云上如何配置

进入策略编辑,源端选 WebAPI 类型,接口为仓库档案查询,请求体里带三个时间窗参数:pageIndex 固定 0、pageSize 固定 50,gmtModifiedStart 取 {{LAST_SYNC_TIME|datetime}},gmtModifiedEnd 取 {{CURRENT_TIME|datetime}}。这种时间窗写法是轻易云客户最常见的增量模式,平台会自动把上一次调度的时间戳作为起点。

目标端同样选 WebAPI,接口为 batchSave,把上述字段绑到目标系统的入参。这里有两个配置要点:一是 FCreateOrgId 和 FUseOrgId 写常量,避免被空值覆盖;二是把仓库属性、是否允许负库存这种枚举,放到映射中心统一查表。轻易云客户常见的应对模式之一,正是「编码映射集中管理」——所有策略共用一张字典,改一处生效全局。

实施步骤

实际项目里我们习惯把一次仓库主数据同步拆成三个阶段:

• 增量起点:首次上线前,在源端导出一份全量仓库档案作为种子数据,在目标端手工或脚本初始化;后续所有变更都走增量,起点就是种子数据落库的那个时间戳。
• 全量触发:种子数据写完后,把 LAST_SYNC_TIME 重置到一个很早的时间点,跑一次全量校验,把首日漏掉的脏数据补齐。这一步在轻易云上就是把调度时间往前挪、强制触发一次。
• 调度频率:源端 cron 设 3,23,43 * * * *,每 20 分钟拉一次;目标端写库 cron 设 10,30,50 * * * *,每 20 分钟推一次。两个时间点错开 7 到 10 分钟,避免读写抢同一批数据。

增量与全量双轨是轻易云客户里第二种高频应对模式:平时走增量保证时效,每月固定一次走全量兜底校验。

踩坑复盘

• 典型错误:第一次跑就拿当前时间作为起点。结果空跑一轮什么都查不到,种子数据丢了。稳妥的做法是先把种子数据落到目标端,再把 LAST_SYNC_TIME 设到种子完成时刻。
• 页大小写太大:有人贪快把 pageSize 调到 500,目标端批量接口一次性塞太多导致部分失败。把页大小压在 50 到 100 之间,失败重试成本最低。
• 组织字段被空值覆盖:源端如果某条记录没带组织信息,直接映射会写空。务必在中间层加默认值兜底,I0103 这种单组织场景就写常量。
• 编码改了名字没改:源端允许仓库改名称,业务部门习惯「改个名字就好」。这里容易翻车的点是下游报表按名称匹配,改了名就对不上账。稳妥的做法是把编码作为唯一键,名称变更通过单独通道通知下游。
• 没开 ID 校验:目标端 idCheck 关闭后,同名记录会重复创建。开 ID 校验后,重复请求会被目标系统识别为更新,数据才一致。

适用场景与不适用场景

这套方案适合:多组织隔离、单向同步、仓库档案变更频率不高、按编码做主键对齐的场景。不适合:需要双向同步、需要带库存余额一起推、或者源端没有修改时间戳(只能全量轮询)的场景,后者建议改成定时全量+版本号对比。