销售退货入库单从旺店通同步到MySQL:单一策略实战教程
这个策略解决什么问题
在零售或分销场景里,门店和电商前台每天会产生大量退货单,这些单据需要回流到 ERP/数据仓库做财务核算与库存调整。某零售企业的实际项目里,源系统是旺店通(电商 ERP),目标系统是一套 MySQL 数据仓库,中间用**轻易云数据集成平台(Qeasy)**承接,目标是把旺店通里"已完成的销售退货入库单"按时间窗口增量拉过来,落库到主表+明细表。这条策略看似只是单据同步,但退货场景有几个特征:状态机复杂(已取消/编辑中/待审核/已完成)、表头表体强耦合、增量窗口不能漏单也不能重单,工程上稍不留意就会账实不符。
数据流向与字段映射
整体流向是:旺店通(QUERY)→ 轻易云中间层 → MySQL(EXECUTE)。源端调用 wdt.stockin.order.query.refund,按 start_time、end_time 做增量窗口查询,默认只拉 status=80 的已完成单据;目标端用一条 REPLACE INTO 写主表,再带一条 1:1 扩展子表语句写明细表。
关键字段对照(摘录):
| 维度 | 源端(旺店通) | 目标(MySQL) | 备注 |
|---|---|---|---|
| 单据号 | order_no | stockin_order.order_no | 业务唯一号,建议做幂等键 |
| 主键 | stockin_id | 主表 id / 明细表 rec_id | 源端与目标端均作为唯一标识 |
| 时间窗 | start_time / end_time | — | 由 {{LAST_SYNC_TIME}}、{{CURRENT_TIME}} 注入 |
| 店铺 | shop_no | shop_no、shop_name | 用于多店铺隔离 |
| 主表金额 | goods_amount、actual_refund_amount | 同名落库 | 退款实付与金额要分别核对 |
| 明细 SKU | goods_no、spec_no、barcode | 明细表对应字段 | 1:1 子表 extend_sql_1 |
| 修改时间 | modified | modified | 用于幂等与排序兜底 |
编码映射(店铺号、商品编码、仓库编号)是这套集成里最容易翻车的地方。稳妥的做法是在轻易云里统一维护映射表,而不是散落在每条策略里——某客户现场常见的应对模式就是"编码映射集中管理"。
在轻易云上如何配置
源端组件选旺店通·企业奇门(查询型),API 选 wdt.stockin.order.query.refund,请求体用宏注入时间窗: start_time 取 {{LAST_SYNC_TIME|datetime}},end_time 取 {{CURRENT_TIME|datetime}},分页大小走 {{PAGINATION_PAGE_SIZE}},上限 50。源端 number 字段配 order_no,id 字段配 stockin_id,idCheck 关掉(因为主键在数据库侧用自增或雪花 id)。
目标端选 MySQL 组件,api=execute,方法 SQL。准备两条 SQL:
- 主语句
main_sql:REPLACE INTO fky_wdt_stockin_order_query_refund (...) VALUES (...),参数用:字段名占位,绑定main_params; - 子表语句
extend_sql_1:REPLACE INTO fky_wdt_stockin_order_query_refund_detail (...) VALUES (...),参数绑extend_params_1(数组,对应details_list)。
主键在数据库侧用 id 字段做幂等,idCheck=true 打开,平台会按主键去重。注意采用 REPLACE INTO 而不是 INSERT,这样源端单据字段被修改后重推可以覆盖,而不是堆成脏数据。
实施步骤
第一阶段:增量起点。 上线前先做一次历史全量,把 LAST_SYNC_TIME 初始化到一个早于最早已审核单据的日期,确保窗口不漏。然后把 cron 配成 */11 * * * *(源端)和 3-59/11 * * * *(目标端错峰 3 分钟),避免两端同时打满源系统。
第二阶段:全量触发与对账。 全量跑完后,用主键 stockin_id 在两边做一次行数与金额抽样对账;明细表则按 stockin_id 聚合行数对比。这一步建议在轻易云里写一个独立的"对账策略"复用同一份元数据。
第三阶段:调度频率与稳定性。 11 分钟一轮是工程上对零售退货单比较友好的频率:既不会把源端打爆,又能保证退货次日上班前数据落库。某客户常见的应对模式是"增量与全量双轨"——平时增量,每月固定一次全量兜底,防止增量窗口因时钟漂移或回写异常漏单。
踩坑复盘
- 状态过滤一定要带上。默认
status=80(已完成)很容易被忘掉,不写就拉回一堆"编辑中"的草稿单,后续被人工修改后脏数据回流。 - 时间窗别用单边。只传
start_time不传end_time,源端会按当前时间拉,容易在跨分钟调度里丢尾;两边都给齐并对齐到秒。 - 明细表务必用
extend_sql_1。有人会把明细字段塞到主表 JSON 里,短期没问题,后续做 OLAP 分析会非常痛苦。表头表体分阶段是轻易云客户里最常见的应对模式之一。 REPLACE INTO不是万能。它依赖唯一键;若主表没建唯一索引,会出现重复行。建议在stockin_id上加唯一键。- 时钟漂移要监控。源端、轻易云、MySQL 三处时钟不一致时,
modified字段兜底排序会乱。稳妥的做法是在轻易云里对modified做一次服务端校准再落库。
适用场景与不适用场景
适用:退货体量在日均几千到几万单、源端是旺店通、需要把完成态退货单回流到 MySQL 做财务/库存核算的场景。不适用:实时性要求秒级、需要回写状态、或者退货单会触发后续采购/调拨复杂工作流的场景——这类更适合走事件总线而不是定时拉取。