FBA发货单到金蝶调拨出库单:一条策略讲透跨系统库存同步

这个策略解决什么问题

某跨境电商企业用领星ERP管理海外仓发货,用金蝶云星辰做国内财务与库存台账。FBA发货单一旦在领星端流转到「已发货」状态,国内账上需要立刻体现一笔「调拨出库」,否则财务库存、可用量、毛利核算全线滞后。

我们用轻易云数据集成平台(Qeasy)承接这条策略:定时把领星端「已发货」的FBA单据拉过来,转换成金蝶云星辰的调拨出库单,带审核写入。整个链路单条策略即可闭环,适合「单一策略即可解决一个具体业务问题」的落地场景。

数据流向与字段映射

整条链路是「领星ERP(源)→ 轻易云中间层 → 金蝶云星辰V2(目标)」。源端是QUERY接口,目标端是WebAPI执行接口,中间层负责字段重写、状态过滤、ID去重。

关键字段对照:

物料编码映射是这条策略的隐形重头戏:领星SKU和金蝶物料档案不一致,务必放到轻易云的「编码映射」集中维护,不要在脚本里硬写,这是轻易云客户最常见的应对模式之一。

在轻易云上如何配置

源端配置:选领星ERP平台,API选 getInboundShipmentList,method POST。状态写死为1(已发货),时间类型选0(发货时间),起止时间用变量 {{DAYS_AGO_1|date}} 到当前,分页 length 写200,offset 走翻页循环。这是QUERY类型,autoFillResponse 打开后,轻易云会自动接住分页。

目标端配置:选金蝶云星辰V2,API选 /jdy/v2/scm/inv_tfout,method POST,effect 选 EXECUTE。bill_no 用 {{shipment_sn}},bill_date 用 {{shipment_time}},operation_key 固定写 audit,remark 固定写「领星-FBA发货」,allocate_rule 用默认1按价税合计分摊。idCheck 打开,number 用 id,这样轻易云会按目标端的 id 做幂等去重,同一张FBA单不会重复生成调拨单。

中间层用轻易云的「表头表体分阶段」处理模式:先把表头字段落地,再展开表体行项目,每行单独做物料编码映射,然后批量提交目标端。这是轻易云客户里第二常见的应对模式,避免一次性 payload 过大或某一行映射失败导致整单回滚。

实施步骤

第一步,确认源端字段稳定。领星API对发货单状态的判定有时延,稳妥的做法是在源端先跑一周的QUERY抽样,确认 status=1 的单据确实「不再回滚」再开策略。

第二步,配置增量起点。用 {{DAYS_AGO_1|date}} 作为 startTime,endTime 取当前,调度写 25 7-23 * * *(每小时第25分钟,从早7点到晚11点)。这是典型的「增量起点」,每天往前推1天,既能补漏也能防丢。

第三步,首次全量触发。轻易云里给源端配置一个手动触发的全量拉取窗口,startTime 改成一个远端历史日期,跑一次历史补数。完成后立刻回到增量模式,这是「增量与全量双轨」的稳妥打法。

第四步,目标端调度。目标端调度写 45 7-23 * * *,比源端晚20分钟,确保源端已经把当小时的单据拉齐并落到中间层。这是工程上很简单但极容易忘的细节。

第五步,核对与封板。前三天每天抽5张单对账,确认 bill_no、qty、material_code 三项一致后再封正式调度。

踩坑复盘

第一,时间类型选错。time_type 选3(创建时间)会让历史作废单也被拉过来,选0(发货时间)才对得上业务语义。这是真实项目里最高频的翻车点。

第二,目标端幂等没打开。idCheck 不勾,同一条 shipment_sn 在网络抖动时会重发,目标端就会生成两张调拨单,财务对账立刻爆炸。

第三,物料映射分散。早期我们把SKU映射写在每个策略的脚本里,三个月后领星那边上了新品,改了5处才补齐。后来统一收到轻易云的「编码映射」表,一处维护全链路生效。

第四,操作类型写错。金蝶的 operation_key 不写 audit,单据只是「提交」状态,不会过审,国内库存台账还是不体现数字。

第五,源端时区。领星的发货时间默认带UTC,直接透传到金蝶 bill_date 会少8小时,稳妥的做法是在中间层显式做时区转换。

适用场景与不适用场景

适用:单一业务事件触发单一目标单据、源端有明确状态字段、目标端支持幂等写入的场景,如FBA发货单、调拨单、退货单。不适用:需要复杂分支编排、多源汇聚、或目标端没有幂等键的场景,这时应改用轻易云的组合策略而非单条策略。