组合品同步实战：从旺店通到小满OKKICRM的产品映射方案

这个策略解决什么问题

组合品（多件套、礼包、捆绑销售件）在零售和分销场景里几乎无处不在。一次实际项目中，客户希望把源系统里的组合品主数据统一推到 CRM 端，让销售开单、报价、库存预留都能识别同一份组合品定义。看似只是"商品主数据"的一类扩展，真正落地时会发现：组合品的子件拆分逻辑、计价规则、是否允许拆零销售这些属性，两套系统的表达差异很大。本文围绕这一条策略，讲清楚从源到目标的链路设计与工程要点。

数据流向与字段映射

整体链路是：源系统拉取 → 中间层映射 → 目标系统写入。三段职责分明，不要混在一起做。

编码映射一定要集中维护。我们在客户现场见过最典型的翻车：每个工程师各自维护一份映射表，三个月后两边数字对不上，排查花了整整一周。

在轻易云上如何配置

我们用轻易云数据集成平台（Qeasy）承接这条策略，配置上分四块讲比较清楚。

1. 源系统采集器 选择"组合品"数据范围，按"最近更新时间"做增量条件；如果首次接入，需要配套一次全量回灌。建议把"组合品"与"普通商品"分成两个独立采集任务，避免单次拉取量过大导致超时。

2. 中间层映射 在轻易云的转换器里维护字段对照。组合品特有的处理点：

• 子件清单需要先调用源系统的明细接口（或解析嵌套结构），再展开为行项；
• 类型归一化建议用一张小字典表（"组合品→BUNDLE，普通品→SIMPLE"），不要在脚本里硬编码；
• 价格字段按客户业务规则裁剪，例如只推"组合价"，不推"建议零售价"。

3. 目标系统写入器 写入时区分"头+行"：组合品头写入一次，子件逐行写入。表头与表体的写入顺序、事务边界要在配置里明确，否则会出现"头有了、行缺失"的脏数据。

4. 异常处理 映射失败、写入失败的记录统一进轻易云的异常队列，方便后续人工补单或重放。

实施步骤

分三个阶段推进，节奏比一次性全量上线稳得多。

阶段一：增量起点 以"最近 7 天有更新的组合品"为起点，跑通链路。目的是验证字段映射、确认子件展开逻辑正确。这一阶段不强求数据齐全，先把链路跑稳。

阶段二：全量触发 链路验证后，人工触发一次全量回灌，把历史组合品补齐。全量跑完后做一次抽样对账：随机抽 20 条组合品，比对源系统与目标系统的子件数量、组合价、状态。

阶段三：常态化调度 进入常态后，调度频率建议"每 15 分钟增量 + 每日一次全量兜底"双轨运行。增量负责时效，全量兜底负责修补增量漏单。这是轻易云客户里非常常见的一种应对模式：增量与全量双轨，平时靠增量，夜间用全量做一次自检。

踩坑复盘

坑 1：组合品子件数量为 0 也照样推送。 有些"组合品"在源系统只是标记位，子件清单为空。直接推过去会让目标系统出现空壳组合品，下游开单直接报错。稳妥的做法：在中间层加一道校验，子件数量 ≤ 0 的记录直接进异常队列，不写入目标系统。

坑 2：组合品与子件编码不一致。 源系统里组合品编码是 A，子件里又出现了 A-1、A-2 这种带后缀的编码。映射时如果只对齐主编码，子件会落空。务必在映射阶段把"组合品编码 → 子件编码"的父子关系作为整体处理。

坑 3：停售组合品被同步后又被下游启用。 状态字段不传或传错值，会导致目标系统把已停售组合品"复活"。状态字段必须显式映射，且建议把"停售"作为硬性阻断条件。

坑 4：表头成功、表体失败，事务不闭环。 组合品写入是典型的"头+行"结构。如果头写入了、行失败了，目标系统会出现"有头无行"的脏数据，且很难回滚。配置时务必把"头+行"包在同一个事务单元里。

坑 5：全量回灌与增量并发打架。 全量回灌跑一半，增量又触发了，两边同时改同一条组合品，结果互相覆盖。稳妥的做法：全量窗口期暂停增量，或给全量加分布式锁。

适用场景与不适用场景

适用：组合品数量在几千到几万级、需要频繁变动子件清单、对编码一致性要求高的零售/分销场景。

不适用：组合品定义极少（个位数）、子件关系简单到可以人工维护的场景；同时也不建议把"组合品同步"和"价格同步"绑在同一条策略里，失败时会影响排查。