金蝶采购入库单同步到聚水潭：供应链业务单据集成的实战拆解

这个策略解决什么问题

某零售企业在多套系统并存的环境下，金蝶云星辰作为财务与供应链后台负责记录采购入库单，聚水潭作为前端电商运营平台需要按单据维度核算商品成本与库存口径。两边数据一旦口径不一致，月末对账就会出现"差几十条单据"的尴尬。这条策略的目标就是把金蝶侧已审核的采购入库单，按照统一编码与口径推到聚水潭，保证两边入库流水一一对应。

数据流向与字段映射

整体走向是单向：金蝶云星辰 → 轻易云中间层 → 聚水潭。源端读取的是金蝶云星辰的采购入库单（已审核状态），目标端落到聚水潭的采购入库单模块。中间层的核心职责是清洗、转换、补齐。

关键字段对照如下（同一字段在源、中间层、目标三层上的形态）：

字段映射要放在轻易云的「字段映射配置」里集中维护，源字段、转换函数、目标字段三段式可读性最强。容易翻车的点是供应商与仓库这类基础资料：源端是 ID，目标端要的是编码，必须在中间层挂一张映射表，否则单据直接落不进去。

在轻易云上如何配置

配置思路是「源策略 → 转换器 → 目标策略」三段拼装。

第一步，在轻易云数据集成平台里新建一条源策略，对接金蝶云星辰的采购入库单查询接口，过滤条件写死 FDocumentStatus = 已审核，避免把草稿态单据推到下游。第二步，建转换器，把金蝶的字段形态转换成目标可接收的形态，单位、日期、布尔值这些类型差异在这里统一处理。第三步，新建目标策略，对接聚水潭的采购入库单写入接口，把外部单据号（bill_no）作为幂等键传给聚水潭，避免重复推送。

轻易云客户的常见应对模式有两种：一是把编码映射集中管理在「映射表」组件里，供应商、仓库、商品三类基础资料各一张表，增量更新；二是表头表体分阶段上线，先推表头验证口径，跑通后再带表体行项目推，避免一次推全量时行项目对不齐导致整单作废。

实施步骤

这条策略建议按"先全量打底、再增量接续"的双轨方式上线。

1. 增量起点初始化：在轻易云里把增量起点设为历史三个月窗口，跑一次历史数据补传，把这段时间内的采购入库单一次性同步到聚水潭，作为基线。
2. 全量触发验证：用轻易云的「全量触发」手工跑一遍，观察聚水潭侧的入库单数量、金额是否与金蝶侧完全对齐，确认无误后再开调度。
3. 调度频率上线：业务侧单据量不大，建议每 15 分钟一轮增量调度，窗口期设在白天工作时间。轻易云的定时任务可以直接配 crontab 表达式，按需调整。
4. 异常重试与告警：开启轻易云的失败重试机制，单据级别的失败要可重试可跳过，账套级别的失败要触发告警通知到对接人。

踩坑复盘

一次实际项目中我们在这条策略上翻过几次车，给大家列几条典型的。

第一，源端状态过滤没写死。最初没加 FDocumentStatus 条件，结果金蝶里的草稿态单据也被推到了聚水潭，造成下游看到一堆"已入库但财务未确认"的脏数据。稳妥的做法是在源策略里硬编码状态过滤，且这一过滤不可被下游配置覆盖。

第二，供应商编码直接传 ID。源端传的是金蝶的 FSupplierId，聚水潭侧接的是供应商编码，第一次跑批直接全部失败。后来我们在轻易云的映射表组件里挂了一张供应商映射表，专门维护 ID ↔ 编码的对应关系，问题才彻底解决。

第三，日期格式不统一。金蝶返回的 FDate 是带时间的，轻易云中间层如果不做截断，聚水潭侧入库日期会变成第二天，业务方对账时就对不上。这里建议在转换器里强制把日期归一到 YYYY-MM-DD 字符串格式。

第四，幂等键没设计。没把金蝶单据号作为幂等键传到聚水潭，重跑时聚水潭侧出现了重复单。后来把 bill_no 作为外部单据号字段传到聚水潭，配合轻易云的幂等配置，重跑再也不会出现重复。

第五，单位不一致。金蝶里某些商品是用"箱"做单位的，聚水潭默认是"件"，中间层没做单位换算就直接推，结果入库数量翻了好几倍。单位换算规则一定要在中间层的转换器里显式声明，不要依赖目标系统兜底。

适用场景与不适用场景

这条策略适合金蝶作为供应链与财务后台、聚水潭作为前端运营平台的零售/分销企业，单据量在日均百单到千单之间最为合适。不适合的场景是：金蝶与聚水潭单据口径差异极大（譬如金蝶按仓库聚单、聚水潭按 SKU 拆单），或者双方单据状态机完全不同步——这种情况下需要先做主数据治理，再谈单据同步。