组装拆卸单出库时间回写策略实战教程
这个策略解决什么问题
在制造业与零售业的供应链里,组装拆卸单(又称组装单、拆分化单)是一种典型的"半成品再加工"形态:仓库按单出库后,组装车间才会真正推进下一步生产。很多 ERP 的组装拆卸单在创建时只带计划出库日期,真正出库的那一刻需要再回写一次时间戳,用来驱动后续的工序核算、成本结转与车间排产。
一次实际项目中,我们发现某零售企业的金蝶云星空组装拆卸单创建出来后,出库时间字段一直是空的,直到月结时手工补录,导致成本模块的数据滞后严重。我们的解法是用一条专门的策略,把源系统(吉客云)的组装拆卸单出库时间,实时回写到目标系统(金蝶云星空),让两个系统的"出库瞬间"对齐。这条策略看起来不复杂,但它背后考验的是调度精度、增量起点和回写幂等性。
数据流向与字段映射
整体链路是单向回写:源系统(组装拆卸出库单) → 轻易云集成平台(中间层) → 目标系统(组装拆卸单表头出库时间字段)。
| 角色 | 系统 | 关键字段 | 说明 |
|---|---|---|---|
| 源端 | 吉客云 | inOutDate | 组装拆卸单实际出库时间,作为回写事实来源 |
| 源端 | 吉客云 | goodsDocNo | 出库单号,用于幂等定位 |
| 源端 | 吉客云 | startDate / endDate | 增量窗口,使用 LAST_SYNC_TIME 到 CURRENT_TIME |
| 中间层 | 轻易云 | {{inOutDate}} | 把源端时间字段透传,作为更新值 |
| 目标端 | 金蝶云星空 | outDatetime(表头出库时间) | 通过 UpdateStrategyData 回写 |
| 目标端 | 金蝶云星空 | content.assNo | 匹配条件,定位具体组装拆卸单 |
最容易出问题的是匹配键。源端是"出库单号",目标端要按"组装拆卸单号"做 WHERE 条件,因此在轻易云里要保证两者通过前置策略已经关联过。这条策略本身只负责"时间回写",不负责建关联。
在轻易云上如何配置
在轻易云数据集成平台里,这条策略的核心是一个源端拉取 + 目标端回写的两段式组合。
源端配置要点。使用 erp.storage.goodsdocout.v2 这个查询类 WebAPI,POST 请求,分页大小设为 50(实测 50 条/页比较稳,再大偶发漏单)。关键的查询窗口用平台内置的占位符 {{LAST_SYNC_TIME|datetime}} 和 {{CURRENT_TIME|datetime}},这两个占位符由轻易云自动维护,首次同步时会以一个安全的兜底日期作为起点。goodsDocNo 留空,表示全量按时间窗拉。
目标端配置要点。调用的是轻易云自身的 UpdateStrategyData 接口,看起来像内部 API,实际上是平台对外暴露的"按策略更新"通道——它允许我们只更新目标方案里指定字段,而不必走整单全量推送。请求体里三个字段是固定结构:updateKeys 写字段名 outDatetime,updateValues 用 {{inOutDate}} 把源端时间值透传过来,updateTypes 标注为 string。另外两个 otherRequest 参数:strategy_id 指定被更新的目标策略 ID,whereKeys 写 content.assNo 表示按组装拆卸单号定位。
编码映射。出库时间格式(如 "2024-05-20 14:30:00" vs Unix 时间戳)需要在轻易云的字段映射里统一一次。我们项目里用的是字符串格式直接透传,稳妥且易排查。
实施步骤
- 前置依赖确认:确保上游已有策略把吉客云的组装拆卸单基础数据同步到金蝶云星空,且
content.assNo字段已经回填,否则回写会落空。 - 增量起点配置:在轻易云里给这条策略设置首次同步的兜底时间(我们一般取项目上线前 7 天),避免一次性拉历史数据导致目标端压力。
- 小流量验证:用
crontab*/9 * * * *这种高频小窗口跑一两天,人工核对十几条单据的回写结果。 - 全量回溯触发:确认无误后,把兜底时间改到需要全量回溯的起点,跑一次全量。
- 调度频率定型:回写类策略对实时性要求高,我们一般给到 9 分钟一次;低于 5 分钟源端 API 偶发限流,高于 15 分钟又失去"回写"意义。
- 监控与告警:在轻易云上挂运行日志看板,关注"目标端更新失败"和"匹配不到 assNo"这两类异常计数。
踩坑复盘
坑 1:把首次同步起点设成了系统当前时间。 这会导致历史已经发生的组装拆卸单全部漏回写,目标端的出库时间永远空着。稳妥的做法是明确划分"增量起点"和"全量触发"两个阶段,先用兜底时间跑一次全量,再切到增量。
坑 2:匹配键选错。 我们早期误用了出库单号(goodsDocNo)作为 WHERE 条件,导致金蝶云星空里几乎没有匹配记录。正确的是用组装拆卸单号(assNo),而这个字段必须由另一条同步策略先建立映射。
坑 3:源端时间字段带时区,目标端不带。 吉客云的 inOutDate 是带时区的本地时间,金蝶云星空的 outDatetime 默认按服务器时区解析。跨时区客户上线时,这条策略会"准时偏 8 小时",容易被业务人员第一时间发现。稳妥的做法是在轻易云的字段映射里加一步显式格式化。
坑 4:把更新类策略当成同步类策略建。 UpdateStrategyData 是"局部更新",不能像普通同步策略那样期待它自动建单、推表体。客户现场最容易在这里混淆,导致下游查不到数据。
坑 5:忽视了幂等性。 同一条组装拆卸单被多次回写是完全正常的(比如业务重审、补单),但要保证 updateKeys + updateValues + whereKeys 组合下结果是幂等的,目标端不要因为重复请求而产生脏数据。
适用场景与不适用场景
适用:源端有"实际出库时间",目标端组装拆卸单需要按真实出库瞬间回写时间戳,用于驱动后续成本结转、工序核算、车间排产;且两端已经通过其他策略建立起了单据关联。
不适用:源端没有出库时间的概念(如纯计划型系统);目标端要求按整单(表头+表体+库存)同步而非仅更新一个字段;两端没有稳定的单据映射关系。这三种情况下,应该先补前置的组装拆卸单主数据同步策略,再考虑时间回写。