聚水潭销售出库到金蝶云星空销售订单的同步策略实战

这个策略解决什么问题

电商前端在聚水潭完成发货审核、生成销售出库单后,财务与供应链要在金蝶云星空里看到对应的销售订单,才能继续走应收、库存、成本核算。问题在于:两边单据模型不同,编码体系不同,触发时机也不同。这一条策略专门解决"聚水潭销售出库 → 金蝶销售订单"的落地,差量触发,只把新增的出库单推过去,不在金蝶侧重复创建。

数据流向与字段映射

整体链路是 聚水潭(源) → 轻易云集成平台(中间层) → 金蝶云星空(目标)。聚水潭一侧的出库单是电商语义,带平台单号、收件人、仓库编码;金蝶一侧的订单是 ERP 语义,带单据类型、客户、币种、收付款组织。两边不能字段对字段直推,要在中间层做一次语义翻译。

关键字段对照(仅列实战必看项):

轻易云做中间层时,我们习惯把编码映射集中管理在轻易云的资料映射表里——客户、物料、仓库各自一张表,聚水潭编码作 key,金蝶内码作 value。新接入门店或新上 SKU 时,只改映射表,不改动主流程。

在轻易云上如何配置

在轻易云集成平台里,这条策略对应一个「聚水潭 → 金蝶云星空」的数据集成任务,典型配置分四块:

• 数据源:选择聚水潭的 sales.out 接口(销售出库查询),按修改时间增量拉取,增量起点为策略启用时刻往前推 30 天做冷启动补偿。
• 目标端:金蝶云星空 salebill/save 接口,标准销售订单保存。单据类型走映射常量,不写死在脚本里。
• 字段映射:用轻易云的「可视化字段映射」配置,关键转换(单位、币种、含税/不含税)走内置函数,客户/物料/仓库走查表映射,失败时落入异常队列。
• 写入控制:启用「单据编号幂等」——同一 io_id 不论重跑几次,只在金蝶生成一张订单;启用「失败重试」,金蝶侧校验失败回退到轻易云待处理列表,人工复核后可手工重推。

实施步骤

我们通常把上线拆成三段,先收口再放量。

第一阶段:增量起点与冷启动。 在轻易云里把策略先置为「手动触发」,用脚本跑一次过去 30 天的全量数据,目的是把金蝶里缺失但已发货的历史订单补齐。补齐完成后,把增量起点锚定在「本次冷启动结束时间」。这一步做错,后续会重复补单或漏单。

第二阶段:差量触发上线。 把策略改为定时调度,典型做法是 每 15 分钟一次,窗口只取「上次成功结束时间 ~ 当前时间」的新增与变更。聚水潭出库单发货审核后才推,所以前端审核越快,金蝶落单越及时。轻易云的「增量 + 全量双轨」模式在这里很合适:定时差量保时效,凌晨一次小全量做对账兜底。

第三阶段:调度频率与监控。 稳定后可以把差量频率提到 5–10 分钟一次;同时在轻易云监控面板上盯三类指标:聚水潭侧拉取失败率、金蝶侧保存失败率、单据编号冲突次数。任一指标超过阈值,告警进企业微信群。

踩坑复盘

1. 客户/物料编码没集中映射,直接写在转换脚本里。新开一个门店或新增一个 SKU,就要改脚本、上线,改动面太大。稳妥做法是全部下沉到轻易云的资料映射表。

2. 表头表体一次性推送。聚水潭出库单是单头多条明细,金蝶保存接口要求表头先建、内码回填、再推表体。一次推全容易因明细超长或某个 SKU 映射失败导致整张单回滚。我们通常改为表头表体分阶段:先写表头拿到 FID,再批量写表体,失败只重试表体。

3. 忽略发货后的改单。电商场景下,聚水潭发货后还会改地址、改备注、甚至换 SKU。金蝶订单一旦保存并走过应收,后续修改要走变更单而不是再次 save。我们额外加了一个「变更标记」字段,识别哪些是修改单、哪些是新增单,走不同的下游路径。

4. 金额字段直接搬运。聚水潭的金额是前端含税价,金蝶要求根据价目表与税率反算不含税金额。直接搬运会在月末成本结账时出现金额不一致。稳妥的做法是在轻易云转换层按物料+客户的价目表重算,不做字段直推。

5. 没有幂等保护。轻易云重试或人工重推,没有幂等就会在金蝶生成重复订单。一定要在策略层启用「单据编号幂等」与「源单据号去重」。

适用场景与不适用场景

适用:电商前端在聚水潭完成发货,后端 ERP 是金蝶云星空,需要把销售出库实时或准实时落成销售订单,做应收与库存核算。

不适用:聚水潭和金蝶同处一个组织、需要走线下对账;或者前端不是聚水潭、目标不是金蝶云星空,本条策略不直接套用,需要重做映射与接口适配。