【实战教程】金蝶云星空销售出库单 → 旺店通原始订单同步:基于轻易云的单一策略落地

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

在一次零售企业的多渠道订单项目中,我们遇到一个很典型的痛点:门店、电商平台接单后,出库动作发生在金蝶云星空里(销售出库单),但平台侧的旺店通需要拿到一份「原始订单」用来走后续的发货、售后、结算流程。手工二次录入显然扛不住单量。于是我们用轻易云数据集成平台(Qeasy)做了一条单一策略:把金蝶云星空已审核的销售出库单,定时增量推送到旺店通·企业奇门,生成平台原始订单。整个链路只关心「单据如何过去」一件事,不掺其他业务,后续的回写、状态更新走独立策略,边界清晰。

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

源端是金蝶云星空的 SAL_OUTSTOCK(销售出库单),目标端是旺店通的 wdt.trade.push(原始订单推送)。在轻易云上,数据从源系统拉到中间层,经过字段映射与脚本加工,再写入目标接口。

关键字段对照(主表):

关键字段对照(明细行):

源端过滤器(在 Qeasy 的源端查询里直接配置):

FCreateDate>='{{LAST_SYNC_TIME|datetime}}'
AND FDocumentStatus='A'
AND F_VTRK_Assistant <> ''
AND F_VTRK_Text11 <> ''
AND F_VTRK_Text12 <> ''
AND F_VTRK_Text13 <> ''
AND F_VTRK_Text10 =''

这里容易翻车的点已经提前堵住:只推已审核的、店铺不为空的、省市区完整的、且上一次没推过的单据。

在轻易云上如何配置

在 Qeasy 的策略画布里,这条策略被拆成「源端查询 → 脚本加工 → 目标写入」三段:

1. 源端配置:业务对象选 SAL_OUTSTOCK,API 选 executeBillQuery,分页参数 Limit 用 {{PAGINATION_PAGE_SIZE}}、StartRow 用 {{PAGINATION_START_ROW}},主键 FBillNo,明细行 ID FEntity_FENTRYID。
2. AfterSourceInvoke 脚本:用 PHP 脚本处理空调类商品的内外机拆分。逻辑是:如果 F_VTRK_Text9(外机物料编码)存在,就把外机作为主物料;如果 F_VTRK_Text6(旺店通名称)或 F_VTRK_Text9 不为空,就追加为第二条、第三条明细行,数量都取 FRealQty。这一段是这套策略的「灵魂」,落地时建议先在测试环境跑几单空调出库单验证拆分结果。
3. 目标写入:API 选 wdt.trade.push,请求体按上面那张主表映射填,常量直接在 Qeasy 的字段配置里写死,shop_no 通过 otherRequest 透传。switch=0 表示非严格模式,避免一个字段就整单失败。

轻易云客户常见的几种应对模式,在这个场景里基本都用上了:编码映射集中管理(把店铺、物料这类易变映射放到一个统一的映射表,后续换店铺不用改策略)、表头表体分阶段(主表字段先映射过,明细行再走脚本拆分,失败也只影响行级)、增量与全量双轨(日常 5 分钟增量,出错时按 FCreateDate 区间补跑全量)。

实施步骤

1. 首次上线:全量起点。先把 LAST_SYNC_TIME 设到一个过去的时间点(比如项目启动当天 0 点),手动触发一次,把存量已审核的销售出库单全部推一遍。推完后立刻把 F_VTRK_Text10 回写为「已同步」,避免下一次重复推。
2. 日常调度:5 分钟增量。在 Qeasy 里把调度配成 */5 6-23 * * *(6:00–23:00 每 5 分钟一次),过滤条件里的 FCreateDate>=LAST_SYNC_TIME 会自动只取增量。每次成功后,Qeasy 内部把 LAST_SYNC_TIME 推进到本次最大时间戳。
3. 失败重试与告警。轻易云默认带重试,但建议把旺店通侧返回的「店铺不存在」「商品编码不存在」这类业务错误单独捞出来,人工介入修正映射表后再补推,不要无限重试。
4. 回写策略另起一条。本策略只负责「出库单 → 原始订单」单向推送,旺店通后续的物流单号、签收状态回写金蝶云星空,放到另一条策略里做,避免单条策略既要出又要进、逻辑耦合。

踩坑复盘

• tid 唯一性。旺店通要求同一个 sid 下 tid 唯一。一开始我们只用了 FBillNo,结果同一店铺两单合同号撞了,平台直接拒收。稳妥的做法是按素材里的 合同号-明细行ID_FID 三段拼接,既不重复,也能从 tid 反查到源单。
• 省市区为空。源端没强制校验地址完整时,推过去旺店通直接报错。我们把 F_VTRK_Text11/12/13 三个字段写进过滤器,凡是空的就不推,业务侧补全后再走下一轮。
• 空调内外机被当两条订单。第一次没加 AfterSourceInvoke 脚本,内机和外机各生成一个原始订单,客户投诉订单对不上账。加了脚本之后,一条销售出库单明细会按规则拆成主物料+外机物料+旺店通名称物料的多行明细,统一在同一个 tid 下。
• 金额字段固定为 0。不少工程师会习惯性地把单价、优惠这些也映射过去,结果旺店通把它当成「指定价」反而报错。稳妥做法是按素材说明,金额类一律置 0,由旺店通按 spec_no 反查商品档案自己算。
• F_VTRK_Text10 没回写。如果同步成功的标志位不回写,下一次增量还会重复推这条单。务必在策略末尾加一个回写动作(可以放另一条策略里,也可以在主流程里加一步),否则 3 个月后两边账肯定对不上。

适用场景与不适用场景

适用:单量适中、对实时性要求在 5 分钟级别、源端是金蝶云星空销售出库、目标端是旺店通原始订单,且地址、店铺、商品编码映射关系相对稳定的多渠道零售/制造企业。不适用:需要秒级实时同步的场景(应改走消息队列或事件触发)、跨多个目标平台(应拆分多条策略而不是堆字段)、源端数据需要复杂业务校验后再推送(本策略只做搬运,业务校验应放在前置环节)。