聚水潭售后单(拒收退货)到金蝶退货单的同步方案实战教程
这个策略解决什么问题
电商业务里,"拒收退货"是一类非常典型的售后场景:包裹到达客户手中被拒收,或者快递被退回网点,这时上游电商系统会产生一条待确认的售后单,后续要走退款、入库、库存冲销等流程。问题在于,电商侧的售后单和金蝶侧的退货单,是两个体系、两套单据,如果靠人工每天导出导入,出错概率极高,3 个月后库存和应收就对不上了。
我们要做的,就是把上游"待确认"状态的拒收退货售后单,按增量方式定时拉取,经中间层转换后,以销售退货单的形式写入金蝶云·星空旗舰版,实现售后业务的闭环。整套链路,我们用轻易云数据集成平台(Qeasy)来承接。
数据流向与字段映射
整体流向是:聚水潭(WebAPI 查询) → 轻易云中间层(转换/校验/编码映射) → 金蝶云·星空旗舰版(RESTful 写入)。
关键字段对照:
| 业务含义 | 聚水潭侧(源) | 中间层处理 | 金蝶侧(目标) |
|---|---|---|---|
| 单据唯一号 | as_id | 直接透传 | billno(单号) |
| 店铺/客户 | shop_id | 编码映射(集中维护) | customer_number |
| 修改时间窗 | modified_begin / modified_end | 用 LAST_SYNC_TIME 与 CURRENT_TIME 动态拼接 | — |
| 售后状态 | status = WaitConfirm | 过滤条件,只拉待确认 | — |
| 单据类型 | type(退款/退货) | 按 type 路由到对应单据类型 | billtype_number |
| 库存组织 | 来源于店铺映射 | 取默认组织或按店铺维度映射 | org_number |
| 结算币别 | — | 默认 CNY | settlecurrency_number |
| 分页控制 | page_index / page_size | 循环翻页直至拉空 | — |
这里有一个很关键的工程实践:编码映射要集中管理。客户现场最容易踩的坑,就是客户编码、店铺编码、组织编码散落在若干个策略里,某天业务调整时改了一处忘了另一处。我们建议在轻易云里建立一张独立的"映射字典"资产,让所有退货/订单类策略都引用同一份映射。
在轻易云上如何配置
在轻易云集成平台里,这条策略通常配置为两个集成方案对:
- 源方案(聚水潭侧):WebAPI 类型,effect 设为 QUERY,请求
/open/refund/single/query,用 POST 分页拉取modified_begin到modified_end之间、状态为WaitConfirm的售后单。idCheck打开,便于增量去重。 - 目标方案(金蝶侧):RESTful 类型,effect 设为 EXECUTE,调用
/kapi/v2/null/im/im_saloutbill/batchAddV2,以单据编号name与主键id做幂等控制,避免重复落单。
配置层面几个值得强调的点:
- 时间窗参数化:
modified_begin取{{LAST_SYNC_TIME|datetime}},modified_end取{{CURRENT_TIME|datetime}},由轻易云自动管理水位线,无需人工干预。 - 幂等与重放:金蝶侧启用
idCheck+ 单号billno,售后单一旦成功写入,即便重跑也不会重复生成退货单。 - 批量写入:金蝶
batchAddV2支持批量,中间层把聚水潭分页拉到的多条记录聚合成批,降低接口调用次数。 - 路由分支:通过聚水潭的
type字段,把"拒收退货"和"普通退货"路由到不同的金蝶单据类型上,避免混单。
实施步骤
我们在客户现场通常分三个阶段推进:
阶段一:全量初始化
首次上线时,把历史一段时间内的拒收退货单一次性补齐。触发方式可以是在轻易云里手动跑一次"全量模式",把 modified_begin 写死为一个足够早的时间点,跑完后记录当前时间作为水位线。这一步只跑一次。
阶段二:增量同步上线
切换到常规调度。聚水潭侧按 05,35 8-22 * * *(业务时段每 30 分钟一次)拉取待确认售后单;金蝶侧按 20,50 * * * *(每小时两次)执行写入,两侧错峰避免同一时刻资源争抢。
阶段三:异常补偿与对账 对于写入失败、字段缺失、映射不到的记录,轻易云会落入重试队列和异常日志。每天业务低峰期由运维同学扫一遍,人工或自动补偿。同时建议在金蝶侧定期导出一份"按单号"的退货单列表,与聚水潭侧的售后单做一次周对账。
踩坑复盘
- 过滤条件只写了一半:早期只过滤了
status=WaitConfirm,没限制type,结果把"仅退款"的售后单也拉过来当成退货单写入了金蝶,导致库存虚增。稳妥做法是status和type同时过滤,并在中间层做一次断言。 - 客户编码硬编码:第一版直接把店铺 ID 写死在目标请求里,后来店铺调整,需要改的地方散落各处。后续我们把所有店铺→客户的映射统一沉淀到轻易云的映射字典,改一处全局生效。
- 分页未拉空就停:page_size=50 时,如果源端刚好剩 40 条,部分同学会忘记循环翻页到空页。稳妥的做法是 while 循环,以"返回条数 < page_size"作为终止条件。
- 时区与时间格式:聚水潭的时间字段是本地时区字符串,直接拼到金蝶时如果不格式化,会出现"同一时刻被算成两次"的奇怪现象。建议在轻易云的字段处理脚本里统一做一次
datetime转换。 - 幂等键只用了单号:金蝶侧建议同时使用
billno和id作为幂等键,极端情况下(如上游单号重置)能多一道保护。
适用场景与不适用场景
适用:电商零售企业,聚水潭作为前端 OMS/ERP,金蝶云·星空旗舰版作为后端财务与供应链核心,需要把"拒收退货"类售后单自动生成退货入库单。
不适用:纯线下零售、跨境保税退货(单据类型与税务处理差异较大)、以及售后流程完全在金蝶内部闭环的场景。