销售出库单从聚水潭同步到金蝶云星空：基于轻易云的增量调度实战

这个策略解决什么问题

零售企业的电商出库单从聚水潭流向金蝶云星空做财务和库存核算，看似只是「单据搬运」，但如果增量窗口、状态过滤、店铺/客户映射没设计好，3 个月后两边数字对不上，财务对账就会成为事故。

本策略要解决的就是一个具体场景：每天把聚水潭中已确认（Confirmed）状态的销售出库单，按修改时间增量拉取，写入金蝶云星空的标准销售出库单（XSCKD01_SYS），组织固定到销售组织 101，客户随店铺映射。

数据流向与字段映射

数据流向：聚水潭（源） → 轻易云数据集成平台（中间层，含转换与映射） → 金蝶云星空（目标）。

关键字段对照表（基于素材脱敏后整理）：

在轻易云上如何配置

在轻易云数据集成平台（Qeasy）上，这条策略通常按「源 → 目标」两个节点配：

1. 源节点（聚水潭·奇门）：API 选择 jushuitan.saleout.list.query，POST 请求。分页参数 page_index、page_size（最大 50）；增量窗口用 start_time / end_time，起始用 {{LAST_SYNC_TIME}}，结束用 {{CURRENT_TIME}}，时间间隔不超过 7 天；状态过滤写死 Confirmed。
2. 目标节点（金蝶云星空）：API 选择 batchSave，单据类型 XSCKD01_SYS，销售组织 101。开启 idCheck，以 io_id 作为幂等编号，避免重复推送。
3. 中间映射层：店铺 → 客户的编码映射建议集中维护一张映射表，不要在每条策略里硬编码；表头先过，表体再批量提交，是轻易云客户常见的应对模式之一。

实施步骤

我们习惯把一条增量策略切成三个阶段推进：

阶段一：增量起点确认。 第一次上线前，需要人工给定一个 start_time（例如上线当天 0 点），把 LAST_SYNC_TIME 初始化到这个值，避免漏单。

阶段二：全量触发（仅上线当天一次）。 用一个临时任务，把过去 N 天的 Confirmed 单据全量补齐。窗口必须 ≤7 天，因此要按 7 天切片循环拉。全量完成后，立刻把游标切到「当前时间」。

阶段三：稳态增量调度。 源端调度设 0 22 * * *（每天 22 点跑昨天全天），目标端设 0 1 * * *（次日 1 点写入）。两个时间点错开，既给源端留抓取余量，也避开金蝶云星空业务高峰。轻易云客户的常见做法是增量与全量双轨：全量脚本保留但默认关闭，只在断点恢复时手动启用。

踩坑复盘

1. 窗口超过 7 天静默失败。 聚水潭接口在 start_time 与 end_time 间隔 >7 天时会直接报错，但错误信息不显眼。稳妥做法是在轻易云的调度脚本里加上「窗口自动切片」逻辑。
2. 店铺 ID 与客户档案对不上。 客户现场常见的问题是聚水潭新开店铺后，金蝶侧没建客户档案，batchSave 就报错。建议在映射层前加一道「档案预校验」，缺失则写入待办队列而不是直接抛错。
3. WaitConfirm 单据被同步进来。 源端状态过滤一定要写死 Confirmed，否则会有「未真正出库」的单据进了财务系统，月底盘点对不上。
4. 幂等键只用 FBillNo 不够。 同单据号 + 不同修改时间会重复写入，建议幂等键组合 = io_id + io_modified_time。
5. 时区漂移。聚水潭时间戳是东八区，金蝶侧按本地时区解析时，跨日数据会丢。中间层统一强制按 +08:00 处理。

适用场景与不适用场景

适用：电商零售、有出库即入账诉求、聚水潭为前端 OMS、金蝶云星空为后端 ERP 的中小型商家。 不适用：B2B 大宗出库、需要审批流的多级销售订单、以及金蝶侧启用自定义单据类型（非 XSCKD01_SYS）的场景——后者需要重新做单据类型与字段映射。