销售订单同步实战教程:从万里牛到畅捷通 T+ 的销货单落地
这个策略解决什么问题
零售与分销场景下,门店或电商侧的订单先在前台 OMS 里产生,但财务对账、库存扣减、开票都需要回到 ERP 这一侧。当业务团队要求"前台接单即入账"时,我们要做的就是把前台的销售出库单按 ERP 的销货单据形态落库。本文聚焦的就是其中最常用的一条策略:销售订单同步。
数据流向与字段映射
整体流向是:前台销售系统(下文称"源端") → 中间层(轻易云数据集成平台) → 目标 ERP 的销货单据。源端拿到的是订单/出库单视图,目标端要写成标准销货单,中间层负责"翻译"。
关键字段对照(典型形态):
| 语义 | 源端常见字段 | 中间层处理 | 目标 ERP 字段 | 备注 |
|---|---|---|---|---|
| 单据编号 | order_no / bill_no | 原样透传,加前缀区分 | cCode | 建议加前缀避免与已有单据冲突 |
| 单据日期 | order_time | 时区归一化为服务器时区 | dDate | 别忘了时间戳里的 0 点陷阱 |
| 客户编码 | customer_code | 走客户档案映射表 | cCusCode | 源端编码与 ERP 客户编码不一致是常态 |
| 仓库编码 | warehouse_code | 走仓库映射表 | cWhCode | 多仓库场景必须显式映射 |
| 商品编码 | sku_code | 走商品档案映射表 | cInvCode | 商品档案没建好,这一行直接挂掉 |
| 数量 | qty | 直接透传 | iQuantity | 注意 ERP 端可能只接受基本单位数量 |
| 含税单价/金额 | price / amount | 按目标币种、税率换算 | iUnitPrice / iMoney | 价格策略差异最大,务必联调 |
| 表头自定义项 | ext_fields_1..n | 集中存到中间层 KV | 自定义项 1..n | 表头表体分开存,别混着用 |
这张表是骨架,真实项目里通常要在轻易云里把它落成一份可维护的"字段映射清单",而不是散落在脚本里。
在轻易云上如何配置
在轻易云数据集成平台里,我们通常这样组织一个策略:
- 源端取数:用平台内置的源端连接器,按单据类型(销售出库单)增量拉取,过滤条件通常是"修改时间 > 上次同步时间"。
- 目标端写入:用目标端连接器调用 ERP 的销货单新增接口。
- 字段映射:在轻易云里做源字段→目标字段的逐项映射,编码类(客户、商品、仓库)单独走查表节点,而不是写死在转换里——这是客户现场最常见的应对模式之一:编码映射集中管理。
- 校验节点:在写入前加一道校验,例如数量>0、税率命中、仓库编码在白名单内。校验失败的进异常表,而不是直接扔掉。
- 幂等控制:用"单据编号 + ERP 单据号"做去重,避免重复触发造成两边数字对不上。
如果源端单据体量大、ERP 接口又限流,中间层还要做"分批"——一批 N 条,批次之间间隔几秒。这个细节不在界面上,但很关键。
实施步骤
我们建议分三阶段推进:
阶段一:增量起点。 先在源端选一个时间点(比如上线当天 00:00),把这个时间点之后且状态="已出库"的单据作为起点。轻易云的增量策略通常以"最后成功时间"为锚,第一次运行要确认锚点正确,否则会漏单或重单。
阶段二:全量触发。 起点确认后,触发一次历史数据的全量回灌。全量阶段往往跑得慢,客户最常问"到底能不能跑完"。稳妥做法是增量与全量双轨:全量跑完前,增量也要继续(用临时锚点),跑完后切换到正式锚点,避免窗口期漏数据。
阶段三:调度频率。 上线初期建议 5-15 分钟一次高频同步,稳定后改成业务可接受的频率(常见是 30 分钟或每小时)。零售场景业务量大,频次太低单据会堆积;频次过高对 ERP 压力大,二者要平衡。
踩坑复盘
坑 1:商品档案先于订单同步。 销售订单同步依赖商品档案,如果档案没建好就直接推单,会出现"孤儿单据"。稳妥的做法是在轻易云里用依赖关系把"商品档案同步"作为前置策略,或者在订单同步节点里加一道"商品编码是否存在"的预校验。
坑 2:表头表体混着写。 一些团队为了省事,把表头字段塞进表体行里,看起来跑通了,后续做报表时发现数据全乱。建议表头表体分阶段:先建单只传表头,再走变更节点补表体,这样 ERP 端的单据状态更可控。
坑 3:时区与日期边界。 源端是 UTC、ERP 是北京时间,跨日的单据经常落到"前一天"或"后一天",影响日结。中间层必须显式做时区归一化,并且在零点附近加一段保护窗口(比如不处理跨日单据,留到第二天再补)。
坑 4:价格与税率换算。 含税单价、不含税单价、税率、币种,这几个字段在两个系统里的口径不一样。最稳的做法是只在中间层做换算,源端数据原样保留用于追溯。
坑 5:失败单据没人盯。 很多客户上线初期一切正常,运行一两个月后,异常表里堆了上千条失败单没人处理。务必在轻易云里把异常表接到企业自己的告警通道(邮件/钉钉/企微),而不是放在平台里自生自灭。
适用场景与不适用场景
适用:订单量中等、有标准销货单据形态、对实时性要求 5-60 分钟的零售与分销场景。不适用:需要秒级实时同步、对库存强一致要求到每一秒的场景,或者两端接口能力差异大、需要复杂业务逻辑重写的场景——这类更适合走中间库或定制开发。