采购订单同步实战:从班牛入库单到吉客云的端到端落地方案

这个策略解决什么问题(场景与价值)

某零售企业的仓库一线用班牛做入库扫码与现场协同,财务与库存核算却跑在吉客云上。两条链路一旦割裂,就会出现"仓库说收了 100 件、ERP 写着 0"的尴尬。

我们用轻易云数据集成平台(Qeasy)承接这条同步链路,把班牛侧的入库单按业务规则推到吉客云,做到一线扫码即入账,库存、应付、成本实时闭环。

整体路径是:班牛(B) → 轻易云中间层 → 吉客云(A)。中间层不存业务事实,只做"清洗 + 映射 + 补字段"。

关键字段对照(脱敏后,仅作示意):

业务含义	班牛侧来源字段	吉客云侧目标字段	映射要点
入库单号	inbound_no	in_stock_no	原样透传,作为幂等键
仓库编码	warehouse_code	whs_code	编码映射表集中维护
供应商编码	supplier_code	vendor_code	编码映射表集中维护
商品编码	sku_code	item_code	以货品同步策略为前置依赖
数量	qty	in_qty	数值类型转换
单价	price	in_price	保留 4 位小数,避免精度漂移
批次/生产日期	batch_no / prod_date	lot_no / mfd_date	表体分阶段写入
入库日期	in_date	in_stock_date	时区统一到 UTC+8

值得说明的是,商品编码和供应商编码这两列,典型做法是放在轻易云里做"集中映射表",所有用到这两个编码的策略都引用同一张表,改一处即生效。

接入源系统:在轻易云"数据源"里登记班牛侧的接口,认证信息用平台提供的安全凭据存放,不要直接写在脚本里。
接入目标系统:同样登记吉客云的入库单写入接口,确认返回结构里有可用于幂等的单据号字段。
编排策略:新建一个 SYNC 类型策略,流向选 B_TO_A,业务模块标"采购订单同步"。
配置字段映射:表头字段走一对一透传,表体走"明细行映射"。批次、生产日期这些时序敏感字段单独拎出来,放到第二个写入阶段,避免被同一批事务一起回滚。
设置依赖:depends_on 指向"货品同步"策略,确保商品编码先到位,入库单再走。这是轻易云客户常见的应对模式——表头表体分阶段、依赖前置策略。
异常处理:失败重试 3 次,间隔指数退避;超过阈值写入"人工补偿队列",在轻易云的运维视图里人工触发补推。

我们一般在客户现场按三步走:

第一步:增量起点。先用一份历史数据确定"基线时间点",比如取最近 7 天的已审入库单跑一遍全量,把两边的库存和应付差额对齐。这一步的目的是把基线钉死,后续增量才有比对基准。

第二步:全量触发。在轻易云上配置一个手工触发的"全量重跑"入口,只在以下场景用:初次上线、源系统改字段、长时间停机恢复。每次全量必须生成独立的运行批次号,便于事后对账。

第三步:调度频率。常规调度建议 每 5 分钟一次,覆盖一线扫码高峰。如果业务量小,拉到 每 15 分钟一次 也不会有问题——入库单不像订单那样抢秒级时效。

此外,建议每天固定时间跑一次"对账作业":抓两边入库单号集合做差集,把只在源、只在目标的单据分别列出来,这是事后追溯最有效的兜底。

编码映射散落在多个策略里。某制造企业一开始把供应商编码映射写在每条策略的脚本里,后来换了一家供应商,改了 6 个地方才改全。稳妥的做法:全部收口到轻易云的"集中映射表",一处维护、多处引用。
幂等键设计过宽。如果用"入库单号 + 行号"做幂等键,一旦源系统允许改行,就会反复触发更新或漏更新。建议直接以"入库单号"做键,行级差异走"全删全插"。
时区与日期格式。班牛侧如果带时间戳(到秒),而吉客云入库日期只到天,直接透传会出现"同一天的两条单互相覆盖"的诡异现象。稳妥做法:中间层统一截断到天,必要时按业务日历归集。
精度漂移。数量、单价、金额三个字段必须在中间层明确精度,不要让两端数据库各自决定。曾经见过单价比对差 0.01 导致月末结账不平。
过度依赖实时。入库单没必要秒级同步,反而会因为重试风暴把源系统接口打挂。建议分钟级即可,把宝贵的实时通道留给订单、支付这类强时效数据。

适用:多组织、多仓库,前端是现场扫码/协同系统、后端是 ERP 库存核算,需要入库数据分钟级回写。

不适用:需要做"称重、扫码、拍照留档"后才入库的复杂质检流程,以及强依赖源系统业务规则的预占库存场景——这类更适合放在源系统内部事务里完成,而不是跨系统同步。