领星退货入库单到金蝶其他入库单：库存同步单策略实战教程

这个策略解决什么问题

退货入库单据的链路打通是供应链集成里最容易被忽视、却最容易出问题的一段。在一次实际客户项目里，电商运营团队在领星ERP中录入退货入库单，财务和供应链分析却依赖金蝶云星空出具库存账面数据。如果两边不及时对齐，退货成本、库存数量、批次台账就会逐日漂移。本策略的目标，就是把领星中"退货类型"的入库单，每天定时拉取并写入金蝶云星空的"其他入库单"，确保退货侧库存动作在两端可追溯。

数据流向与字段映射

整条链路可以抽象为三段：领星ERP（源）→ 轻易云数据集成平台（中间层，负责抓取、转换、对账、重试）→ 金蝶云星空（目标）。

关键字段对照如下表所示：

编码映射建议在轻易云中集中管理，便于后期出现组织变更时一次性更新，避免在每条策略里硬编码。

在轻易云上如何配置

源端配置使用领星ERP的开放接口 /erp/sc/routing/storage/inbound/getOrders，method 为 POST，effect 为 QUERY，请求体里通过 start_date 与 end_date 限定时间窗（注意不允许跨月），并通过 type 参数筛选退货入库。offset 与 length 控制分页，默认每页 200 条。

目标端调用金蝶云星空的 batchSave 接口，method 为 POST，effect 为 EXECUTE。请求体里需要把领星的单据头与单据体字段映射到金蝶的 FBillNo、FBillTypeID、FStockOrgId、FStockDirect、FDate 等关键字段上。FBillTypeID 在退货场景下固定为 QTRKD01_SYS，与销售出库、其他出库等单据类型严格区分。

中间层在轻易云里需要做四件事：行项目拆分、字段类型转换、空值与异常过滤、以及幂等控制（按 order_sn 去重，避免重复入库）。

实施步骤

我们建议按三个阶段推进：

第一阶段是建立增量起点。先在轻易云里初始化一个全量历史窗口，把过去若干天的退货入库单补齐到金蝶，作为后续增量的基准线。初始时间戳记下来，作为后续调度窗口的起点。

第二阶段是配置调度与全量触发。源端 crontab 建议 45 10 * * *（上午 10:45），目标端建议 45 12 * * *（中午 12:45）。两个时间点错开的目的，是给源端留足抓取与转换时间，也避免和金蝶侧的库存结账窗口撞车。第一次上线时，建议手动触发一次全量，验证无误后再切换到增量。

第三阶段是日常调度与监控。每天源端按窗口拉取，目标端按计划写入。轻易云的运行日志、失败重试、异常告警都需要在第一周内重点盯，确认无重复单据、无丢单、无字段缺失后，再降低巡视频率。

踩坑复盘

第一，领星端按"不允许跨月"约束查询。如果窗口不小心跨月，接口会直接报错或返回空集，看似调度失败实则是参数设置问题。建议在轻易云里把窗口计算逻辑封装好，月底前后自动按月切分。

第二，金蝶单据类型写错。FBillTypeID 写成了销售出库或其他出库的类型值，单据表面上能落库，但库存方向、科目、流程节点全都错位。退货场景下必须严格写 QTRKD01_SYS。

第三，重复入库。源端接口偶发返回历史数据，目标端没有按 order_sn 做幂等，就会出现同一张退货单重复落账。稳妥的做法是在轻易云里基于 order_sn 做唯一键约束，重复即丢弃并打日志。

第四，行项目被合并。领星一张单据可能多行 SKU，中间层如果只取了首行或合并了数量，金蝶侧的库存明细就和实物对不上。建议在中间层显式按行拆分，逐行写入。

第五，时区与日期格式不一致。源端 opt_time 是带时区的时间戳，目标端 FDate 通常只取到日期。建议在轻易云里统一格式化为 Y-m-d，避免出现"差一天"导致退货日期错位到次日。

适用场景与不适用场景

适用：电商或零售企业的退货流程以领星ERP为业务前台、金蝶云星空为财务库存后台，且需要按天对齐退货入库数据。不适用：跨法人公司间调拨退货、批次追溯要求极高的医药/食品行业、或是源系统不是领星ERP的场景。