销售出库单代发货同步实战：从吉客云到金蝶云星空的一条策略讲透

这个策略解决什么问题

代发货场景下，电商交易在吉客云完成，但财务与库存要在金蝶云星空落地。销售出库单不传过去，金蝶里就没有发货依据，库存和应收账款都对不齐。我们用轻易云数据集成平台承接这条策略，目的就是让代发出库单按 15 分钟节奏稳定落入金蝶，做到两边账实一致。

数据流向与字段映射

整体链路是：吉客云（源）→ 轻易云（中间层）→ 金蝶云星空（目标）。

源端通过 jackyun.tradenotsensitiveinfos.list.get 拉取代发货单，时间窗用 modified_begin / modified_end 控制，单号 tradeNo 用于精确拉取，pageSize 控制分页。

目标端是金蝶云星空的 batchSave，落销售出库单。

关键字段对照：

shopCode 是这个策略里最关键的桥梁字段，组织和客户都靠它去基础资料表里查。

在轻易云上如何配置

在轻易云集成平台里配置这条策略时，几个要点要把握住：

1. 源端拉取接口。选吉客云的 tradenotsensitiveinfos.list.get，分页参数 pageSize 建议给到接口允许的上限，减少请求次数；时间窗用增量游标（startModified / endModified）驱动。

2. 编码映射集中管理。shopCode 到金蝶 FSaleOrgID 和 FCustomerID 的查表动作（_findCollection）放在轻易云的「数据映射」模块统一维护。客户现场常见做法是把所有门店-组织-客户的对应关系沉淀到一张映射表，门店新增或变更时只改这一张表，而不是散落在每条策略里。

3. 目标端写入。金蝶侧用 batchSave，单据类型 FBillTypeID 写死 XSCKD07_SYS；单据编号 FBillNo 用模板变量 {{tradeNo}}；日期 FDate 用 {{consignTime}}；组织与客户走查表。

4. 幂等与校验。源端开 idCheck，目标端也开 idCheck，用 tradeId / id 作为幂等键，避免重跑时出现重复单。

实施步骤

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

阶段一：增量起点确定。先在吉客云里圈定一个「启动时间点」（比如当天 00:00），把启动点之前的代发出库单用「全量补数」走一次性脚本灌入金蝶，从启动点之后切换为增量。增量时间窗就用 startModified / endModified 滚动。

阶段二：全量触发。全量补数用时间区间触发，间隔不超过七天（接口本身的限制）；全量跑完后核对两边单据数量与金额，确认无丢失后再切换调度。

阶段三：调度频率。源端 crontab 设为 */15 * * * *，目标端 */16 * * * *，错开一分钟避免上下游同秒抢占连接。轻易云客户常见的「增量与全量双轨」做法：平时增量跑，每周日 02:00 再触发一次当日范围的全量校验，作为兜底。

踩坑复盘

1. 时间窗超过七天接口直接报错。源端接口明确要求 modified_begin 与 modified_end 间隔不超过 7 天，全量补数时务必分片。

2. shopCode 在金蝶侧查不到组织。门店在金蝶基础资料里没建，或者编码不一致，会整张单被退回。稳妥的做法是上线前用一份门店清单做一遍预校验。

3. 单据编号重复。代发货场景下吉客云单号可能被复用或重传，目标端必须用幂等键拦一道，否则金蝶会报「单据编号已存在」。

4. 表头过了但表体丢了。典型错误是只处理了表头字段，忽略了商品明细行的映射。表头表体分阶段校验是轻易云客户的常见应对模式：先只校验表头，跑通后再加表体。

5. 时区与日期格式。吉客云默认时区与金蝶侧 FDate 期望格式不一致，没转就写，日期会被金蝶拒收。

适用场景与不适用场景

适用：电商代发货、门店发货、订单履约在异构系统间的出库单同步。

不适用：需要实时秒级同步的核心交易链路（应走消息队列直推）、以及涉及复杂审批流的多级销售出库（建议走金蝶单据状态机而非批量同步）。