销售订单售后退货同步实战:吉客云到金蝶云星空的对接方案
吉客云金蝶云星空销售订单同步售后退货轻易云供应链集成
这个策略解决什么问题
售后退货场景下,前端在吉客云生成退货单,财务与库存结转需要落到金蝶云星空。看似只是「一张单据推过去」,但退货单与原销售单强关联,编码映射、状态机、库存方向三者任一错位,就会导致两边数字长期对不上。我们用轻易云数据集成平台(Qeasy)做中间承接,把售后退货单作为独立策略拆出来单独跑,既不污染正常出库链路,也方便按月核对增量。
数据流向与字段映射
整体流向是:吉客云(源)→ 轻易云集成平台(中间层,负责清洗、转换、补字段)→ 金蝶云星空(目标,写入售后退货单)。
关键字段对照,源 → 中间层 → 目标:
| 业务含义 | 吉客云(源) | 轻易云中间层 | 金蝶云星空(目标) |
|---|---|---|---|
| 单据编号 | return_no | 原样透传 | FBillNo |
| 关联原销售单 | src_order_no | 解析后回填 | FSourceBillNo |
| 商品编码 | sku_code | 经编码映射表转换 | FMaterialId.FNumber |
| 退货数量 | qty | 数值校验,负数拦截 | FQty(取正) |
| 仓库 | warehouse | 直接透传 | FStockId.FNumber |
| 客户编码 | customer | 经映射表转换 | FCustomer.FNumber |
| 单据状态 | status | 状态机归一化为目标态 | FDocumentStatus |
| 同步时间 | — | 由轻易云生成 | FSyncTime(自定义) |
编码映射我们坚持放在轻易云的「映射中心」统一维护,而不是散落在每条策略里。客户现场常见的应对模式是:SKU 主数据先在金蝶侧建立字典,吉客云侧只保留原始编码,中间层做一次转换,这样后续扩展到多家门店时,改一处映射即可,不用改每条策略。
在轻易云上如何配置
- 数据源注册:在轻易云「数据源」分别登记吉客云和金蝶云星空的接口账号(注:token 与密钥仅在平台内可见,不在策略里硬编码)。
- 源端事件:订阅吉客云的「售后退货单创建/更新」事件,设置单据类型的过滤条件,只取状态为「已审核」的单据。
- 目标端动作:在金蝶云星空侧配置「保存并审核」动作,失败时回退到「仅保存」并落异常单。
- 映射脚本:在轻易云的转换器里写字段映射,编码映射走映射中心,数值类字段加校验。
- 异常处理:开启轻易云的告警通道,推送失败明细到运维群,每条异常记录附带源单号与目标回执。
实施步骤
售后退货单建议采用「增量起步 + 全量兜底 + 调度常态化」三步走:
- 增量起点:首次上线时,以一个自然日零点为断点,只拉取断点之后的「已审核」退货单,确认无误后再放开历史数据。
- 全量触发:补数阶段手动触发一次全量回扫,配合金蝶侧的事务码逐单核对,避免历史脏数据带过来。
- 调度频率:稳态后按 5 分钟一次轮询 + 事件触发双轨运行,轻易云的「增量与全量双轨」是大多数客户的标配——轮询兜底,事件加速。
另外建议把表头与表体分阶段上线:先跑表头,核对单据编号、客户、仓库没问题,再放开表体行,减少一次性出错面积。
踩坑复盘
- 状态机不对齐:吉客云的「已退款」并不等于金蝶的「已审核」,必须在中间层做一次状态归一化,否则会出现「钱已经退了但金蝶没立账」的情况。
- 数量符号混乱:退货数量在源端是负数,目标端金蝶要求正数,这里容易翻车;稳妥的做法是在中间层显式取绝对值并加日志。
- 编码映射分散:每条策略各自维护一份 SKU 映射,3 个月后两边数字对不上;统一收口到映射中心是必修课。
- 关联交易丢失:退货单不挂原销售单号,会导致金蝶无法做红字冲销;这里典型错误是只同步了单据头没同步关联字段,务必在源端就把 src_order_no 抓出来。
- 重复推送:幂等键没设好,网络抖动时会重推,金蝶侧出现重复单;建议用「源单号 + 修改时间」作为幂等键,目标端开启去重。
适用场景与不适用场景
适用:多门店零售、电商零售的售后退货单统一入账,需要按单据类型拆策略独立对账。不适用:跨组织调拨退货、需部分换货的复杂售后场景,以及源端单据状态机尚未稳定的过渡期。
本文为原创内容,转载请注明出处:https://www.qeasy.cloud/insights/solutions/strat-p2ea595-kingdee-cloud-9948-8-copy-78bf0417