领星拆分单到金蝶拆卸单：单策略同步方案实战

这个策略解决什么问题

某零售企业的供应链中台跑在领星ERP上，财务与库存核算沉淀在金蝶云星空。仓库每天会基于一站式加工单产出大量拆分单：把一个组合 SKU 拆成若干基础件，账面上既要扣减母件，又要新增子件。这类单据如果只在领星侧记账，金蝶侧的库存账和成本核算就会逐渐漂移。

这个策略要回答的问题只有一个：把领星侧已经"已完成"的拆分单，按完成时间增量拉取，转换成金蝶云星空的拆卸单（事务类型 Dassembly）写入，保证两边账目一致。它本质上是一笔库存事务的镜像，不是主数据同步。

数据流向与字段映射

整体流向是 领星ERP → 轻易云中间层 → 金蝶云星空。

源端（领星）调用的是加工单查询接口 /erp/sc/routing/inventoryReceipt/StorageProcess/getOrderLists，单据类型固定为 2（拆分单），加工状态过滤为 2（已完成），时间维度用 finish_time，按 start_date 到 end_date 区间增量拉取。

目标端（金蝶）调用 batchSave 进行批量写入，单据类型 ZZCX01_SYS（标准组装拆卸），事务类型写死为 Dassembly。

关键字段对照表（精简后）：

编码映射建议集中管理在轻易云的映射表里，不要散落在每条策略里——后续同类策略复制时直接复用。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略拆成两个集成流：源端 QUERY 流 + 目标端 EXECUTE 流，二者用同一份中间表/消息主题串起来。

配置要点：

1. 源流：HTTP POST 调用领星查询接口，请求体里的 start_date 用 {{LAST_SYNC_TIME|date}}，end_date 用 {{CURRENT_TIME|date}}，由平台自动替换。分页参数（offset/length）保留默认，靠轻易云内置分页器循环。
2. 中间层：在轻易云的数据转换节点里，把领星的母件行、子件行展平成金蝶拆卸单的分录结构。这里最容易翻车的是单位与数量正负号——拆分子件为正、母件为负，建议用表达式节点集中处理。
3. 目标流：调用 batchSave，把转换后的 JSON 整批塞进 Model 数组。轻易云的执行节点支持"部分成功"语义——单据级失败不影响整批重试，但要打开单据号幂等开关，避免重跑产生重复拆卸单。
4. 调度：源流 30 10 * * *（每天 10:30），目标流 30 12 * * *（每天 12:30），人为留 2 小时缓冲消化跨天数据与重试窗口。

实施步骤

我们把上线节奏切成三段：

• 阶段一：增量起点。第一次只跑近 7 天数据，确认两边单据号能一一对上。轻易云支持手动填入 LAST_SYNC_TIME，不用改代码。
• 阶段二：全量触发。在源流配置里临时把 start_date 改成业务上线日，做一次历史全量；全量结束后立刻把 LAST_SYNC_TIME 切回增量模式，避免下次又全量拉一遍。
• 阶段三：调度频率稳定化。观察一周，确认无延迟、无重复后，把 crontab 固定为源 10:30 / 目标 12:30。若后期单量大，可改成两小时一次的微批次，把"增量与全量双轨"常态化。

踩坑复盘

1. 时间字段选错，丢数据。典型错误是用 create_time 过滤，结果补单或改单永远追不上。稳妥的做法是按业务完成时间 finish_time 取，并用完成时间做幂等键。
2. 拆分单的正负号搞反。领星接口里母件和子件都是正数，必须在中间层显式把母件数量改成负数，否则金蝶拆卸单过账时库存会越加越多。
3. 重跑导致重复单。源端接口不支持天然幂等，必须靠轻易云的单据号映射表 + 目标端 idCheck 双保险。我们见过现场忘开 idCheck，三周对账才发现多了上百张重复拆卸单。
4. 组织编码不一致。领星侧的仓库 ID 和金蝶侧的 FStockOrgId 不是同一套字典，必须做映射，且映射表要随组织变更同步更新，否则单据会卡在组织校验环节。
5. 表头表体分阶段写入。如果一次塞整张单（含表体）失败，重试成本很高。轻易云支持的"表头先写、明细后补"模式很适合这种场景，建议表头表体分阶段落地。

适用场景与不适用场景

适用：拆分子件固定、母件单据量稳定（每天几十到几百张）、库存组织单一的零售/分销场景；以及已经跑通领星到金蝶基础资料同步、需要补齐业务单据链路的项目。

不适用：母件拆解规则频繁变动、需要按 BOM 动态生成的制造场景；金蝶侧有强审批流、需要人工干预后才能过账的场景；以及源端接口本身不稳定的灰度期——这种时候应该先做单据落地暂存表，再异步驱动下游。