销售订单同步实战:从金蝶云·星空发货通知单到旺店通原始订单

这个策略解决什么问题

某零售企业的 ERP 用金蝶云·星空旗舰版管理发货,门店履约和线上订单中心却在旺店通里。发货通知单在 ERP 一旦审核完成,就需要尽快落到旺店通作为"原始订单"以便后续打单、拣货、物流跟踪。这条策略的本质是:把金蝶侧的发货通知单(表头 + 表体明细)按店铺维度组装成旺店通 rawTrade + rawTradeOrder 数组,定时增量回写到旺店通侧。

数据流向与字段映射

整体链路是单向的:金蝶云·星空旗舰版(源)→ 轻易云中间层 → 旺店通·旗舰版(目标)。

源端接口是 RESTful 的 batchQuery,分页拉取发货通知单;目标端是 WebAPI 的 sales.RawTrade.pushSelf2,把订单与明细作为数组整体提交。关键字段对照大致是这样:

注意 rawTradeOrderList 在金蝶源端对应的是 billentry 这个表体集合,要在中间层做"表头 + 表体"的拼装,而不是分别提交,否则旺店通会拒绝。

在轻易云上如何配置

我们用轻易云数据集成平台(Qeasy)承接这条链路,典型配置分四块:

1. 源端数据源:注册金蝶云·星空旗舰版的 API 账号,填入 /kapi/v2/dtog/sm/sm_delivernotice/batchQuery,开启 autoFillResponse,这样返回字段会自动展开,不用每次手动解析。
2. 目标端数据源:注册旺店通·旗舰版的 WebAPI,接口选 sales.RawTrade.pushSelf2,shop_no 用变量 {{customer_number}} 引用,便于按店铺拆分路由。
3. 字段映射 + 编码映射:发货通知单上的店铺编码通常是 ERP 内部编码,需要在轻易云的「编码映射」模块集中维护一份「ERP 店铺编码 ↔ 旺店通店铺编号」对照表。这样后续新增店铺,只改一处。
4. 表头表体分阶段写入:在轻易云的「数据处理」节点里,先用 JSONPath 把 billentry 提取出来,再通过「数组构造器」拼成旺店通期望的 rawTradeList + rawTradeOrderList 双层结构。这是客户现场用得最多的模式——表头表体分阶段,避免一次性塞进一个对象。

实施步骤

在客户现场我们一般按三步走:

• 第一步:增量起点锚定。先用 idCheck=true 的方式跑一次,确认从某个时间点之后只拉增量,避免历史上几万张发货通知单一次性重放,触发目标端限流。
• 第二步:全量触发做一次基线。在金蝶侧按业务日期筛选,把当天发货通知单以小批次(每批 50 单)方式全量回写一次,作为基线。轻易云的「批量执行」节点可以并发跑,通常一批几十秒。
• 第三步:进入调度循环。源端 crontab 是 0-59/3 7-22 * * *(每 3 分钟,在业务时段),目标端错峰一档 1-59/3 7-22 * * *,避免两端在同一秒打满带宽。这种「增量 + 全量双轨」的应对模式,在轻易云客户中很常见。

踩坑复盘

1. 表体被拍平成对象数组。直接把 billentry 当对象数组提交,旺店通会返回"订单明细不能为空"。稳妥的做法是用「数组构造器」先拼成 rawTradeList[].rawTradeOrderList,再整体提交。
2. 店铺编码映射遗漏。金蝶侧一个发货通知单可能挂多个店铺,如果只做主店铺映射,会让部分单据直接漏掉。建议在编码映射里维护全量,并加一道「未匹配店铺」拦截日志。
3. 幂等键 trade_no 重复。重跑同一批数据时,如果 trade_no 不唯一,旺店通会认为是新单。建议在轻易云的「数据处理」里把 billno + 行号 拼成 trade_no,保证幂等。
4. 跨日调度窗口。crontab 只配了 7-22,夜间发货的急单会被压到早 7 点才推,业务方感知"延迟"。如果业务允许,可以再加一个夜间兜底任务,把 22 点到 7 点的单单独补跑。
5. 限流被静默吞掉。旺店通限流时返回的报错是中文提示,而不是 HTTP 429,容易让人误以为是数据问题。轻易云可以在「异常处理」节点里按关键字识别限流,自动重试 + 退避。

适用场景与不适用场景

适用:ERP 侧有现成的发货通知单、需要把发货事实同步到电商履约/ERP 一体化平台做统一打单与物流跟踪的企业。不适用:实时性要求极高(秒级)的场景,或者订单结构差异巨大、需要二次开发的客户;那种情况更适合走事件驱动的中台方案,而不是定时拉取。