销售订单同步实战:从畅捷通T+拉取订单写入万里牛的单一策略深度拆解

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

在某零售企业的供应链集成中,ERP 一侧的订单是结算与库存扣减的源头,电商一侧的订单是履约与发货的依据。同一张销售订单,如果两边状态不一致,仓库就不知道该按哪边发货、客服就不知道该按哪边回款。

这条策略要解决的,就是「以畅捷通T+为权威源,把销售订单按业务口径抽取出来,落到轻易云集成平台做中间层处理,再写入万里牛」。本质上是用一次同步,把订单的归属、编码和状态对齐。我们在实际项目里看到,不做这件事,3 个月后两边订单数对不上、退换货链路就乱成一团。

数据流向与字段映射(源 → 中间层 → 目标)

数据流分三段:畅捷通T+(源) → 轻易云数据集成平台(中间层) → 万里牛(目标)。源端是查询,中间层做映射与清洗,目标端是写入。

关键字段对照如下(只列容易出错的字段):

注意:源端 request 里 selectFields 指定返回的字段集合,pageIndex / pageSize 控制翻页,paramDic_1 用来塞过滤条件(比如按日期、按客户)。目标端的「写入空操作」是中间层锚点,真正的写入在后续策略里完成——这是轻易云常见的「分阶段」打法。

在轻易云上如何配置

在轻易云数据集成平台(Qeasy)里,这条策略的源操作是一个 WebAPI 查询,目标操作是一个空写入锚点。配置要点有四个:

1. 源接口选择 WebAPI,method = POST,把 /tplus/api/v2/SaleOrderOpenApi/FindVoucherList 配进 API 路径;effect = QUERY 表示这是拉取动作。
2. 请求体三段式:selectFields 写明要返回的字段(常见是 VoucherCode、ID 等);pageIndex 从 0 开始;pageSize 按源系统限流能力给,通常 100 以内稳妥。
3. number 字段填 Code、id 字段填 ID、idCheck = true——告诉平台「用单据编号做幂等、用单据ID做唯一性校验」。
4. 目标端先挂「写入空操作」,把数据落到中间层;真正的写入万里牛放在下一条策略里做,这就是「表头表体分阶段」的典型打法——一次只解决一个层次,出问题时好定位。

编码映射一定要集中管理,不要散落在每条策略里。我们在客户现场见过最常见的翻车,就是客户编码在 A 策略硬编码、B 策略又写一遍,结果 ERP 改了客户档案,两边没同步,订单全错。

实施步骤

分三阶段走,稳一些:

阶段一:增量起点。先把 last_sync_time(上次同步时间)锚定一个明确时间点,比如当天 0 点。第一次跑全量,跑完后立刻把 last_sync_time 更新到本次最大值;之后的增量按这个值往后推。

阶段二:全量触发。沙箱环境里,把 pageSize 调到 5(就像素材里给的默认值),人工触发一次完整拉取,核对返回结构与字段;确认无误后,再把 pageSize 调到生产值。

阶段三:调度频率。crontab 设为 0 23 * * *,每天 23:00 跑一次。理由是:白天业务高峰 ERP 压力大,放夜里更稳妥;23:00 这个点,绝大多数订单已经审核完毕,落库完整。如果客户要求更实时,可以缩到 30 分钟一次,但要盯着源系统的限流阈值。

增量与全量双轨是轻易云客户常见的应对模式:平时增量,每周日凌晨做一次全量核对,防止漏单。

踩坑复盘

1. 典型错误:第一次跑就上全量。源系统一次性返回几十万条,中间层处理卡住,后续所有策略排队。稳妥的做法是先小 pageSize 验证结构,再逐步放大。

2. 典型错误:idCheck 不开。不开幂等校验,源端重发就会重复落库,目标端出现重复订单。一定要把 idCheck = true 配上。

3. 典型错误:目标端直接写最终系统。源数据没经过中间层沉淀,出问题想回查只能从头拉。中间层先落一次,排查效率高十倍。

4. 典型错误:编码映射散落各处。客户编码、商品编码、仓库编码,每条策略自己写一遍映射。客户 ERP 一调整,所有策略全要改。集中管理才省事。

5. 典型错误:忽略翻页。pageIndex 不递增,只拿到第一页数据,看着像同步成功,实际上后面全丢了。配置时务必确认分页逻辑生效。

适用场景与不适用场景

适用:ERP 与电商/OMS 之间需要订单对齐、双方均有开放 API、日终批量即可满足业务节奏的场景。

不适用:要求分钟级实时同步的高频订单;源系统不开放 WebAPI、只能走数据库直连的场景;订单结构差异巨大、需要在中间层做大量业务规则改写的场景——后者建议拆成多条策略,不要塞进一条里。