旺店通即时库存同步到小满OKKICRM：单策略实战教程

这个策略解决什么问题

某零售企业在用旺店通做电商履约、用小满OKKICRM管理销售前端与客户。两边都要看到「实时有多少货」，但库存只在旺店通里更新，CRM 端看到的总是隔夜数。促销节点一过，客服超卖、运营拍脑袋补货，问题集中爆发。

我们用轻易云数据集成平台把旺店通的即时库存按策略推送到小满OKKICRM，让前端看到的库存数与履约侧基本同频。

数据流向与字段映射

流向：旺店通·旗舰版（B） → 轻易云中间层 → 小满OKKICRM（A），方向为 B_TO_A。

关键字段对照（典型形态，落地时按实际字典调整）：

编码映射集中管理是轻易云客户常见的应对模式之一：不要在每条策略里硬写映射，新建一张「商品 / 仓库主数据映射表」，后续物料策略、销售订单策略都引用它，避免改一个编码翻三条线。

在轻易云上如何配置

1. 接入源：选旺店通·旗舰版适配器，配置查询即时库存的接口拉取参数（页大小、增量时间戳字段），凭证由平台托管。
2. 接入目标：选小满OKKICRM适配器，确认库存写入接口（按仓库+商品 upsert 是稳妥做法）。
3. 中间映射：在轻易云的「字段映射」画布里建映射表，把源字段映射到目标字段；编码类字段挂「统一编码映射表」。
4. 过滤与去重：按 warehouse_no + sku_id 组合做主键去重，避免重复推送造成覆盖抖动。
5. 失败处理：开启平台自带的异常队列，单条失败不阻塞整批。

实施步骤

分阶段调度是轻易云客户常见的另一种应对模式，本策略按「增量跑日常、全量兜底」的双轨设计：

• 阶段一：增量起点。以策略上线时刻的 modified_time 为基线，每 5–15 分钟拉一次增量；初次上线时建议先灰度一个仓库确认数字对得上，再放开全量。
• 阶段二：全量触发。每天业务低峰（如凌晨）跑一次全量校对，把当日漏掉的更新补齐；表头表体分阶段——本策略只涉及「库存数值」一类事实数据，没有表体，配置上比订单类策略简单得多。
• 阶段三：调度频率。日常增量跑 5–15 分钟一次，全量每天一次。促销 / 大促期可临时把增量收紧到 1–3 分钟，但务必监控源端限流。

踩坑复盘

1. 时区踩坑：旺店通时间戳带本地时区，小满OKKICRM 期望 UTC。这里容易翻车，稳妥的做法是在轻易云中间层统一做时区转换，写进 update_timestamp。
2. 「0 库存」被误判为删除：有些接口把库存为 0 当作下架信号，结果目标端被清空。务必确认写入语义是「upsert 当前值」而非「覆盖式更新」。
3. 仓库维度缺失：源端按物理仓推，目标端却按逻辑仓聚合。落地前先把两边的仓库档案对齐，否则数字永远对不上。
4. 首次全量把目标库写穿：上线初期全量没分批，目标端写入接口瞬间过载。稳妥做法是轻易云侧配置分页与限速，按批次推送。
5. 没设批次字段：事后排查时不知道某条数字是哪次同步带过去的。建议在中间层补一个 batch_id，写入目标端备用字段，定位问题快很多。

适用场景与不适用场景

适用：旺店通作为履约主仓、需要把可用 / 占用库存实时回写到 CRM 侧的场景；多仓、多 SKU、库存变化频繁的业务。

不适用：把旺店通当财务核算源头（应走对账类策略而非实时推送）；SKU 量级极大且对秒级延迟有强诉求（需要评估源端接口吞吐与限流）。