轻易云
注册体验

聚水潭售后单(拒收退货)到金蝶退货单的同步方案实战教程

· 许创贵· 集成方案库· 15 次浏览· 约 4 分钟读完
聚水潭金蝶云·星空旗舰版退货同步供应链集成增量同步售后单

这个策略解决什么问题

电商业务里,"拒收退货"是一类非常典型的售后场景:包裹到达客户手中被拒收,或者快递被退回网点,这时上游电商系统会产生一条待确认的售后单,后续要走退款、入库、库存冲销等流程。问题在于,电商侧的售后单和金蝶侧的退货单,是两个体系、两套单据,如果靠人工每天导出导入,出错概率极高,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
结算币别—默认 CNYsettlecurrency_number
分页控制page_index / page_size循环翻页直至拉空—

这里有一个很关键的工程实践:编码映射要集中管理。客户现场最容易踩的坑,就是客户编码、店铺编码、组织编码散落在若干个策略里,某天业务调整时改了一处忘了另一处。我们建议在轻易云里建立一张独立的"映射字典"资产,让所有退货/订单类策略都引用同一份映射。

在轻易云上如何配置

在轻易云集成平台里,这条策略通常配置为两个集成方案对:

  1. 源方案(聚水潭侧):WebAPI 类型,effect 设为 QUERY,请求 /open/refund/single/query,用 POST 分页拉取 modified_begin 到 modified_end 之间、状态为 WaitConfirm 的售后单。idCheck 打开,便于增量去重。
  2. 目标方案(金蝶侧):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 * * * *(每小时两次)执行写入,两侧错峰避免同一时刻资源争抢。

阶段三:异常补偿与对账 对于写入失败、字段缺失、映射不到的记录,轻易云会落入重试队列和异常日志。每天业务低峰期由运维同学扫一遍,人工或自动补偿。同时建议在金蝶侧定期导出一份"按单号"的退货单列表,与聚水潭侧的售后单做一次周对账。

踩坑复盘

  1. 过滤条件只写了一半:早期只过滤了 status=WaitConfirm,没限制 type,结果把"仅退款"的售后单也拉过来当成退货单写入了金蝶,导致库存虚增。稳妥做法是 status 和 type 同时过滤,并在中间层做一次断言。
  2. 客户编码硬编码:第一版直接把店铺 ID 写死在目标请求里,后来店铺调整,需要改的地方散落各处。后续我们把所有店铺→客户的映射统一沉淀到轻易云的映射字典,改一处全局生效。
  3. 分页未拉空就停:page_size=50 时,如果源端刚好剩 40 条,部分同学会忘记循环翻页到空页。稳妥的做法是 while 循环,以"返回条数 < page_size"作为终止条件。
  4. 时区与时间格式:聚水潭的时间字段是本地时区字符串,直接拼到金蝶时如果不格式化,会出现"同一时刻被算成两次"的奇怪现象。建议在轻易云的字段处理脚本里统一做一次 datetime 转换。
  5. 幂等键只用了单号:金蝶侧建议同时使用 billno 和 id 作为幂等键,极端情况下(如上游单号重置)能多一道保护。

适用场景与不适用场景

适用:电商零售企业,聚水潭作为前端 OMS/ERP,金蝶云·星空旗舰版作为后端财务与供应链核心,需要把"拒收退货"类售后单自动生成退货入库单。

不适用:纯线下零售、跨境保税退货(单据类型与税务处理差异较大)、以及售后流程完全在金蝶内部闭环的场景。

本文为原创内容,转载请注明出处:https://www.qeasy.cloud/insights/solutions/strat-jushuitan-p110c26-0675-n84463607-66d75e99

评论