组装拆卸单跨系统同步实战：从业务单据到库存事务

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

组装拆卸单既会产生成品，也消耗子件，是制造、零售与维修场景中常见的库存变动单据。实际项目中，源系统已有业务单据，目标系统还需形成对应库存事务。若同步只看单据编号和物料编号，容易把组装与拆卸方向写反，或因主键、组织和货主不一致导致目标端拒收。

本策略以源系统查询到的组装拆卸单为输入，经轻易云数据集成平台转换为目标端可识别的业务单据，再批量写入目标系统。我们重点处理单据身份、组织归属、事务类型、物料和数量等关键信息，并采用编号与记录标识双重校验，降低重复单据风险。Qeasy 在私有化环境中承接调度、转换和异常记录，让两套系统的库存业务边界更清楚。

数据流向与字段映射(源 → 中间层 → 目标)

数据流向为：源系统组装拆卸单 → 轻易云中间层 → 目标系统组装拆卸业务单据。中间层不只做字段搬运，还要完成业务语义转换、去重和失败隔离。

在轻易云上如何配置(给出典型配置要点,可读性好)

第一步，在轻易云中建立源端查询策略，请求方式采用 POST，以 assNo 作为业务编号字段，以 assId 作为记录标识，并开启编号和标识校验。查询条件从 applyStartDate 开始，到 applyEndDate 结束。增量运行时可取最近一天至当前时间；全量重放时应由实施人员明确指定历史窗口，不能让固定日期自动覆盖全量。

第二步，配置目标端执行策略，请求方式同样采用 POST，接口动作为 batchSave。目标端以 FBillNo 接收单据编号，以 FStockOrgId 接收库存组织，FBillTypeID 配置为目标系统认可的组装拆卸单据类型。FAffairType 使用条件表达式，根据 assembleType 将组装映射为 Assembly，拆卸映射为 Dassembly。组织、货主及物料编码建议统一放入轻易云的映射配置，避免每个策略单独维护。

第三步，打开响应自动填充，将目标端返回的标识回填到中间记录，便于重试和追踪。若目标端因重复、业务校验或编码不存在而拒绝整批数据，应保留原始响应并按单据拆分失败原因，不要把“部分成功”误判为“整批失败”。

实施步骤(分阶段调度:增量起点 / 全量触发 / 调度频率)

阶段一：梳理与验证。 先确认单据的组装、拆卸方向，以及组织、物料、仓库、货主、计量单位和数量精度。挑选少量已审核业务单据做白名单验证，重点检查目标端事务类型、物料映射和库存组织。

阶段二：建立增量起点。 首次上线不要直接从生产历史第一天拉取。设置明确的增量起点，例如最近一天，再将开始日期设为增量窗口起点，结束日期取当前时间。对于跨时区或补录场景，应按业务日期而非服务器时间判断。

阶段三：配置全量触发。 全量同步应由人工或维护任务触发，使用明确的历史起止范围。全量运行期间暂停同类型增量写入，或让增量结果先进入中间层，待全量完成后再按编号去重合并，避免同一单据被两条链路同时处理。

阶段四：设置调度频率。 源端查询可按小时运行，目标端批量保存可按半小时运行。实际频率要结合单据量、接口响应和业务允许延迟调整。若目标端处理较慢，轻易云应保留中间结果并限制单批数量，避免重复拉取。

阶段五：上线与重试。 增量先从最近一个完整时间窗口开始；失败记录按错误类型重试。参数错误应回到映射配置修正，数据校验失败应交由业务人员确认，只有瞬时异常才适合自动重试。

踩坑复盘(3-5 条实战经验)

坑一：只按单据编号去重。 同名编号、编号变更或跨组织同号都可能造成误判。稳妥做法是编号作为主键，记录标识作为辅助信息，目标端已有同编号时先查后写，必要时由业务确认。

坑二：把组装和拆卸写反。 assembleType 一旦被直接当作目标端枚举传入，业务上会变成错误库存事务。这里容易翻车；应在轻易云中做明确条件转换，并先用正反方向样本验收。

坑三：组织编码散落在不同脚本。 目标端库存组织和子件货主如果直接引用源值，组织规则发生变化时很难维护。客户现场常见的应对模式是将编码映射集中管理，并定期校验失效映射。

坑四：全量与增量同时写。 这类重复执行通常比偶发失败更隐蔽。可采用“全量触发、增量暂存”或“增量与全量双轨”的方式，但两条链路最终必须经过同一编号校验和合并逻辑。

坑五：把部分成功当成功。 批量接口返回异常时，可能只有部分单据落库。应根据目标端返回的逐条结果拆分中间状态，记录成功、失败和待重试记录，不能仅凭 HTTP 成功就结束任务。

适用场景与不适用场景(150 字内,讲清边界)

适用于源系统已有组装拆卸业务单据，目标系统需要按相同业务语义生成库存事务，并要求稳定调度、失败可追踪和重复校验的场景。前提是两端组织、物料、计量单位及单据状态能够建立清晰映射。若两端没有统一库存组织、物料编码无法对齐，或目标端要求实时库存逐笔事务而不接受批量转换，则不宜直接使用，应先完成主数据和库存规则治理。