采购申请单同步实战:从旺店通到 SQL Server 中间表的字段级透传方案

这个策略解决什么问题(场景与价值)

采购申请单是供应链的源头单据之一。一次实际项目中,某零售企业把旺店通作为采购入口,内部 BI、ERP 二次开发都依赖 SQL Server 里的中间表做联查和汇总。最直接的问题是:API 调用零散、字段命名不一致、明细行经常对不上主单号。我们用轻易云数据集成平台承接这条链路,把旺店通的采购申请单按 5 分钟增量推送到 SQL Server 主从两张表,让下游按表消费即可,不必各自再去调 API。

数据流向与字段映射

数据流向是单向的:旺店通·旗舰版 → SQL Server。源端是 QUERY 类型的 purchase.PurchaseApply.search 接口,目标端是 EXECUTE 类型的 insert,主表与明细表 1:1 写入。

主表关键字段对照(t_mid_purchase_apply):

源字段	目标字段	映射类型	说明
purchase_apply_no	purchase_apply_no	直接透传	主键,单据唯一标识
warehouse_name / warehouse_no	warehouse_name / warehouse_no	直接透传	仓库名/编号
created / modified	created / modified	直接透传	创建/修改时间
remark	remark	直接透传	备注
expected_time	expected_time	直接透传	期望到货时间
apply_name	apply_name	直接透传	申请人
status	status	直接透传	状态枚举:5 已取消/10 编辑中/20 待确认/23 待引用/25 部分引用/30 已引用

明细表关键字段对照(t_mid_purchase_applyEntry):

源字段	目标字段	映射类型	说明
detail_list.rec_id	rec_id	直接透传	行唯一标识
detail_list.spec_no / goods_no / goods_name	spec_no / goods_no / goods_name	直接透传	SKU/货品维度
detail_list.spec_name / brand_name	spec_name / brand_name	直接透传	规格/品牌
detail_list.remark	remark2	直接透传	仅字段名差异,业务含义一致
detail_list.num / ref_num / stockin_num	num / ref_num / stockin_num	直接透传	申请量/引用量/入库量

主表的 purchase_apply_no 会下传到明细表,作为主从外键。源端主表上的 num、ref_num、provider_no 等汇总字段本策略未写入目标主表,这是设计上故意保留的边界。

在轻易云上如何配置

在轻易云数据集成平台里,这条策略的配置非常"轻":

源平台:接入旺店通·旗舰版,选择 purchase.PurchaseApply.search 接口,请求体用 {{DAYS_AGO_3|datetime}} 作为 start_time,end_time 默认到 2025-12-31 23:59:59,page_size=100,page_no 由分页器驱动。
目标平台:接入 SQL Server,主语句 insert into t_mid_purchase_apply(...),1:1 扩展语句 insert into t_mid_purchase_applyEntry(...),extend_params_1 填 detail_list。
字段映射:全部 DIRECT,逐字段拖拽对应即可,remark → remark2 是唯一需要留意的命名差异。
调度:源 */5 * * * *,目标 2-59/5 * * * *,错开 2 分钟避免读写争抢,这是轻易云客户常见的「错峰调度」应对模式。
不做编码映射:本策略无需店铺/客户/物料对照,因为是落到中间表而不是直接落业务系统。
不写脚本:没有 _findCollection、没有 _mongoQuery、没有自定义函数,所有逻辑都靠字段透传+主从关联完成。

实施步骤

我们一般把上线拆成四段:

建表与权限:在 SQL Server 端先建好 t_mid_purchase_apply 与 t_mid_purchase_applyEntry,主表主键 purchase_apply_no,明细表主键 (purchase_apply_no, rec_id) 组合,索引按 purchase_apply_no + created 建。
增量起点配置:start_time 用 DAYS_AGO_3 而不是某个固定历史日期,避免一次性回拉历史数据。end_time 指向一个远期未来时间,让平台按当前时间自动收敛。
全量触发一次:首次上线时,把 end_time 临时调成上线前一天,主动跑一次全量回灌,确认主从行数比例、明细行数与源端 detail_list 长度一致,然后切回日常调度。
调度频率与监控:源端每 5 分钟拉一次、目标端错开 2 分钟写一次。在轻易云里挂上「源端拉取条数」「目标写入条数」「明细行数/主单数」三个指标的告警,任何一项异常就立刻介入。

踩坑复盘

明细行容易丢:extend_params_1 必须填 detail_list,且 1:1 扩展语句里的 :purchase_apply_no 要从主表下传。如果只把明细当数组写入而忘了外键,会出现「明细孤儿行」。
remark 同名字段撞车:源端主表 remark 与明细 remark 都叫这个名字,目标端为了区分把明细命名为 remark2。映射时一定要看清是「主表 remark」还是「明细 remark」,典型错误是漏配或重复配。
状态码别在中间表里翻译:status 在源端是整型枚举(5/10/20/23/25/30),这里稳妥的做法是原样落库,留给消费层用 CASE 转中文。提前翻译会丢失语义,以后对接别的下游很被动。
时间窗别写死:把 end_time 写成 2025-12-31 看似无害,但到了 2026 年会突然拉不到数据。用变量或远期时间能让平台按当前时间自然收敛,这是增量与全量双轨策略里很关键的一笔。
错峰调度不是装饰:源、目标都用 */5 * * * * 时,会出现「刚写完主表,马上又来一轮新的主表」的争抢。目标端改成 2-59/5 * * * *,给源端留出处理窗口,链路稳定性会明显提升。

适用场景与不适用场景

适合:旺店通作为采购入口,下游 BI/报表/自研系统需要稳定、易追溯的采购申请数据,字段语义无需二次加工。不适合:需要把旺店通采购申请直接转成 ERP 采购订单(状态机、审批流、单据转换规则都要另起策略);也不适合需要做 SKU/供应商跨系统编码映射的场景——中间表不背这口锅。