入库单(组装)同步到其他入库单:一条策略讲透跨系统库存单据落地

这个策略解决什么问题

某零售企业的跨境仓配系统每天会产生大量组装入库单,这些单据需要落到财务 ERP 形成"其他入库单",驱动库存账面、核算与报表。看似只是"一张单据换个地方写",但编码不统一、组织映射缺失、库存方向混用,任何一处翻车都会让月底对账直接卡死。这条策略的目标,就是把组装场景下的入库单,稳定、可追溯地送进 ERP。

数据流向与字段映射

整体流向是:跨境仓配(源)→ 轻易云数据集成平台(中间层)→ 财务 ERP(目标)。中间层负责清洗、映射、ID 关联和重放,源和目标都不直接对话。

关键字段对照如下(只列最容易出错的核心项):

业务含义	源端字段	目标端字段	备注
入库单号	receiving_code	FBillNo	建议保留源端单号,便于对账
单据类型	(派生)	FBillTypeID	固定值 `QTRKD06_SYS`,组装场景专用
库存组织	warehouse_id	FStockOrgId	必须通过仓库档案做映射,不能直接塞 ID
库存方向	(派生)	FStockDirect	组装入库一般取 `0`,由策略统一下发
入库日期	complete_time	FDate	强烈建议以"完成时间"为准,而不是创建时间

注意:目标端 FStockOrgId 字段写的是 _findCollection find warehouseCode from <档案ID> where warehouseId={{warehouse_id}},这是轻易云里典型的"跨策略档案查找"用法。

在轻易云上如何配置

配置分三块:源取数、转换、目标写入。

源端:接口 getReceiving,POST 查询,主键 receiving_id,业务单号 receiving_code。开启 idCheck,由平台按主键去重。常见可传入的过滤条件包括入库单号、客户参考号、跟踪号、采购单号、仓库 ID 等,初次接入建议先用 receiving_code 锁单验证。

中间转换:这是最容易忽略、也最值钱的一段。建议把以下规则集中管理:

编码映射:仓库、客户、SKU、物料统一进档案策略维护,业务策略只做"取值",不做"写值"。这就是轻易云客户里常见的「编码映射集中管理」模式——一处变更,全链路生效。
表头表体分阶段:先稳跑表头(单据编号、类型、组织、日期、供应商),再补表体明细(行项目、批号、数量)。这样上线当天出问题,至少不会把脏数据写进 ERP。
幂等与回写:用 receiving_code 做幂等键,目标保存成功后回写状态,避免重跑产生重复单。

目标端:接口 batchSave,POST 执行,单据类型用 QTRKD06_SYS 锁死组装场景;库存方向、库存组织、入库日期按上面的映射表填入。

实施步骤

按"先稳后快"的节奏分三段上线:

历史数据全量回灌。停掉定时,手工触发一次全量,只同步过去 N 天已完成的组装入库单。观察目标端单据是否齐整、库存组织是否准确。这一步用轻易云的"手工触发"按钮即可,不必另写脚本。
增量起点确定。以全量跑完那一刻为时间锚点,记录最大的 complete_time,作为增量起点。后续调度都从这一点往后推。
调度频率上线。源端 crontab 是 49 3 * * *(凌晨拉数),目标端是 23 2 * * *(凌晨执行),两边错峰,互不挤压。这套「增量 + 全量双轨」的节奏,在轻易云的客户现场几乎成了标准动作:日常增量跑,出问题一键回到全量。

踩坑复盘

仓库 ID 直接当组织 ID 写进 ERP。典型错误:省掉了档案映射,结果库存方向对、组织错,整批单据都得冲销。稳妥做法是走 _findCollection 查档案,别图省事。
入库日期用创建时间。仓配端的创建时间和完成时间可能差好几天,做库存账直接偏掉。坚持用 complete_time。
表头表体一起上线。单据头和明细一起推,出错时定位成本极高。先表头后表体,分两步走,这是轻易云项目里反复验证过的「表头表体分阶段」打法。
忽略幂等。入库单量大,网络抖动一轮就可能重发,batchSave 不带幂等键很容易落重复单。receiving_code 一定要落到唯一键上。
跨时区时间字符串。源端给的时间字符串如果带时区或截断,ERP 端会拒收或错位。建议在中间层显式格式化,不要把脏数据直接透传。

适用场景与不适用场景

适用:跨境仓配 → 财务 ERP 的组装入库、调整入库、初始化入库等"其他入库"类单据,数据量稳定、对账要求高的场景。不适用:强实时库存查询(秒级)、多组织频繁切换的复杂分销网络,以及需要反向冲销高频交互的场景——这些更适合走事件流或专门的库存服务。