旺店通委外出入库单同步到 MySQL:单一策略实战教程

这个策略解决什么问题

某零售/制造企业用旺店通管理仓库,委外出入库单据(把货发给委外供应商加工,或者加工完收回)分散在 WMS 里。财务、ERP、对账系统都在同一个 MySQL 落地分析,需要把单据按仓库维度持续推到 MySQL。我们用轻易云数据集成平台承接,源系统按订单状态增量拉取,目标系统通过 SQL 把表头和 1:N 表体分两次落库。

数据流向与字段映射

流向:旺店通·企业奇门 → 轻易云集成平台 → MySQL。

源侧(旺店通)关键入参:warehouse_no(仓库编号)、status(单据状态:10 取消 / 30 待审核 / 50 推送失败 / 70 部分出库 / 80 已完成)、order_type(1 出库 2 入库)、outer_no(外部单号)、order_no(单据编号)。

目标侧(MySQL)关键输出:tp_wdt_stock_outside_wms 表头(以 order_id 为主键)与 tp_wdt_stock_outside_wms_details_list 子表(1:N 扩展,通过 details_list 注入)。

关键映射对照表:

在轻易云上如何配置

在轻易云数据集成平台里,这条策略配置为"查询 + SQL 执行"两段式:源平台注册为旺店通·企业奇门,API 选 wdt.vip.stock.outside.wms.query,id 用 order_id,idCheck 关闭以避免拉取时强校验导致漏单;目标平台注册为 MySQL,API 选 execute SQL,主语句用 REPLACE INTO 写表头,extend_sql_2 写子表,extend_params_2 绑定 details_list。autoFillResponse=true 让源侧自动填充返回结构,减少脚本量。

编码映射集中管理:仓库编号、单据状态、出入类别统一在轻易云的「数据字典」维护,源侧值变化时只改一处,避免散落在策略脚本里后期失控。

实施步骤

第一步——确定增量起点。第一次接入,先不传 warehouse_no,调用一次全量,把历史单据同步进 MySQL;后续按订单状态过滤,只拉 status >= 60 的有效单据,避免重复写入已取消单据。

第二步——配置分阶段调度。源侧旺店通的 crontab 设为 */11 * * * *,每 11 分钟拉一次;目标侧 MySQL 写入 crontab 设为 3-59/11 * * * *,延迟 3 分钟,确保源侧已提交完整单据后再写库,避免空表头先于明细。表头与子表通过 1:N 扩展分两条语句写入,先写表头拿到 lastInsertId,再绑定 details_list 写子表。

第三步——日常运维。在轻易云监控台看每轮写入条数、SQL 执行耗时、异常告警;若源侧某仓库推量异常,可临时在入参填 warehouse_no 单独补拉。

踩坑复盘

1. 典型错误是表头表体用一条 SQL 写。委外出入库明细行很多,混写易出现主键冲突或漏写。稳妥做法是用轻易云的 1:N 扩展,主语句写表头,extend_sql_2 写子表,两边用 order_id 关联。
2. 增量与全量没分开。直接用增量模式上线,会漏掉历史数据;直接用全量模式上线,会反复覆盖拉高负载。稳妥做法是上线第一天跑全量,之后切增量,两者通过不同策略 ID 分开,互不影响。
3. 状态字段值含义记错。status=80 不是"已审核",而是"已完成";order_type 才是区分出库和入库的字段。常见翻车是把 status 当出入类别。建议把状态语义整理成数据字典,配置时勾选对应值。
4. 入库出库混在一起丢数。同一 order_no 下可能有出库也有入库,如果按 order_no 去重会丢一半。稳妥做法是按 order_id(单据唯一标识)去重,而不是 order_no。
5. REPLACE INTO 的副作用。源端改了字段,目标端用 REPLACE INTO 会先删后插,触发自增主键变化和关联外键失效。若有外键依赖,可改 INSERT ... ON DUPLICATE KEY UPDATE,只更新不重建。

适用场景与不适用场景

适用:旺店通作为仓库执行系统,需要把委外出入库明细落到 MySQL 给 ERP、对账或 BI 系统使用;明细条数稳定,单据状态可枚举。

不适用:需要实时秒级同步(本方案是分钟级);单据明细极多、跨仓库批量推送的场景;以及需要保留变更历史做审计的场景(本策略用 REPLACE,不留历史)。