其他出库单自动同步方案实战：从旺店通到金蝶云星辰
这个策略解决什么问题
电商仓里每天会冒出大量「非销售、非采购」的库存出库：样品出库、赠品发放、内部领用、盘亏出库……它们不走销售订单链路，却实实在在要扣减账面库存。
一次实际项目中，某零售企业把样品领用登在仓储系统，财务却要在 ERP 手工再录一遍，三天后账对不上，库存数量越偏越多。
这个策略要做的，是让其他出库单从仓储端按 order_type=7 自动推到财务 ERP，保存即审核，库存自动扣减，账实实时一致。
数据流向与字段映射
数据流非常简单、单向：仓储系统侧的其他出库单，通过轻易云数据集成平台推到财务 ERP 的其他出库单。中间不沉淀业务数据，只做格式转换与字段搬运。
| 维度 | 源端（仓储系统） | → | 目标端（财务 ERP） | 备注 |
|---|---|---|---|---|
| 主键 | stockout_id | → | id | 系统内部唯一标识 |
| 业务键 | order_no（出库单号） | → | bill_no（单据编码） | 业务单据编号 |
| 日期 | consign_time | → | bill_date | 单据日期 |
| 业务类型 | — | → | trans_type_id = "13" | 其他出库固定值 |
| 操作类型 | — | → | operation_key = "audit" | 保存后直接审核 |
| 明细数组 | details_list | → | material_entity | 一行源对应一行目标 |
| 物料编码 | details_list.goods_no | → | material_number | 直接传递 |
| 数量 | details_list.num | → | qty | 直接传递 |
| 单价 | details_list.price | → | price | 直接传递 |
| 金额 | details_list.total_amount | → | amount | 直接传递 |
| 批次 | details_list.batch_no | → | batch_no | 仅启用批次管理时 |
| 有效期 | details_list.expire_date | → | valid_date | 仅启用保质期时 |
注意 trans_type_id 与 operation_key 是常量，在源端并不存在，必须在平台里以固定值的方式补齐——这也是初次配置时最容易漏的两项。
在轻易云上如何配置
我们在客户现场一般按「源端建查询 → 目标端建写入 → 字段映射 → 调度」四步走。
源端（仓储系统·企业奇门）：API 选 wdt.stockout.order.query，类型 QUERY，方法 POST，主键 stockout_id，业务键 order_no。请求参数里把 order_type 写死为 7，这是过滤其他出库单的关键开关；start_time 取 {{LAST_SYNC_TIME}}、end_time 取 {{CURRENT_TIME}}，由平台按上次同步成功时间自动填。
目标端（财务 ERP V2）：API 走 /jdy/v2/scm/inv_other_out，WebAPI 类型，方法 POST，主键 id，开启 IDCheck 防重复推送。
字段映射：主表字段以 DIRECT 直接引用为主；trans_type_id、operation_key 用 CONSTANT 固定值；details_list → material_entity 直接数组整体引用，由目标端按物料编码自动匹配。明细行无需任何脚本，所有逻辑靠配置即可跑通。
这是轻易云客户典型的「轻脚本、重映射」模式——编码映射集中管理在平台，表头表体分阶段处理，物料主数据由其他链路保证一致即可，本策略不重复做联查。
实施步骤
阶段一｜增量起点。首次上线务必做一次全量回灌：在源端把 start_time 设为历史最早时间，end_time 取当前时间，跑一遍历史数据，把存量其他出库单补齐；之后平台会记录 LAST_SYNC_TIME，自然切换到增量。
阶段二｜全量触发。历史数据补齐后，将 start_time 改回 {{LAST_SYNC_TIME}}，从此刻起只推新增/变更。这是增量与全量双轨衔接的稳妥做法。
阶段三｜调度频率。源端 Cron 设为 3 2 * * *，即每天凌晨 02:03 跑一次——避开支付结算高峰，又能赶在财务日结之前。目标端备用 Cron 设为 23 2 * * *，作为兜底重试。
阶段四｜联调验证。按验证清单逐项核对：单据编号、日期、trans_type_id=13、明细数量/金额、是否自动审核通过、有无重复单据。
踩坑复盘
坑一｜业务类型漏配 trans_type_id。源端根本没有这个字段，新手以为「源端有什么就传什么」，结果 ERP 端拒绝或默认成销售出库。务必在映射里显式常量赋值为 "13"。
坑二｜物料编码不一致。本策略不做 _findCollection 联查，假设两边物料编码已一致。若仓和 ERP 的 goods_no 体系不同，会直接落空。稳妥做法是先打通物料主数据同步链路，再启用本策略。
坑三｜operation_key 没设 audit。漏配后单据停留在「已保存未审核」，库存不会扣减，账实再次脱节。
坑四｜增量时间窗太短。把窗口设成「过去 1 小时」很常见，但跨夜补单会漏推。建议窗口至少覆盖 24 小时，且 end_time 往前推几分钟做缓冲。
坑五｜明细数组整体引用被误解。details_list → material_entity 是整体数组映射，不是逐字段拼接。如果在源端做了字段删减，目标端会整段丢失，联调时要抽查空数组、空字段的场景。
适用场景与不适用场景
适用：电商零售、批发企业的样品/赠品/内部领用/盘亏等其他出库业务；仓与 ERP 的物料编码已对齐或由其他方案维护；希望保存即审核、库存自动扣减的场景。
不适用：需要按仓库、客户、批号做复杂主数据联查的业务；仓与 ERP 编码体系差异大、且无主数据同步方案托底；高实时秒级同步——本方案按天调度，秒级需求另选实时事件方案。