售后单到调拨单的 RPA 同步:次品仓查询售后单方案实战

这个策略解决什么问题

售后单据散落在外部系统,客服处理完一笔次品退换后,需要把售后单回流到 ERP 的次品仓调拨单上,仓库才知道这批货要去哪里、扣减哪个仓位。人工录单不仅慢,而且口径容易乱。我们这次就用 RPA 把售后单抓回来,落到 ERP 的调拨单(次品仓),让仓库、财务、客服三方对得上一套数据。

整体流向是:外部售后单源 → RPA 抓取层 → 中间转换层 → ERP 调拨单(次品仓)。

关键字段对照如下:

语义	源端(售后单)	中间层	目标端(调拨单-次品仓)
单据编号	售后单号	aftersales_no	调拨单号(前缀+原单号)
客户编码	客户ID	customer_code	调出客户/部门编码
商品编码	SKU	sku	物料编码(集中映射)
数量	售后数量	qty	调拨数量(正数)
次品原因	原因分类	defect_reason	备注/行项目说明
仓库	售后仓	wh_code	调入仓库=次品仓编码
时间	售后完成时间	done_at	单据日期

中间层是真正干活的地方:RPA 只负责「拿到结构化数据」,字段口径、单位、编码规则全部在中间层统一,这就是「编码映射集中管理」的典型做法。

在轻易云数据集成平台里,我们通常这样搭这个策略:

数据源节点:配置 RPA 抓取任务,登录外部系统、拉取售后单列表、轮询「已完成」状态的售后单,把单据头和单据体写到中间表。这里关键是「状态过滤」,不要把处理中的单子抓进来。
转换节点:写中间层映射脚本。商品编码、单位、次品原因字典、客户编码全部走映射表,不在脚本里硬写死。轻易云的「映射表」组件可以直接挂 Excel/数据库,后续维护只改一处。
目标节点:调拨单接口,单据头走一张 API,单据体走另一张,轻易云的「表头表体分阶段」就是为这种场景设计的——先提交表头拿到单据号,再批量提交表体行,出错能精确定位到哪一行。
异常处理:配置「重试+告警」,连续 3 次失败直接转人工工单,而不是无限重试把 ERP 推库撑爆。

我们一般分三步走,稳一点:

第一步:增量起点核对。上线当天拿一批历史售后单做「全量回灌」,目的不是生产用,而是把映射表、字典、单位先跑通,验证两边数字能对得上。
第二步:全量触发一次。回灌成功后,以「完成时间 ≥ 上线日 0 点」作为增量起点,正式启用 RPA 抓取。
第三步:调度频率。售后单不像订单那么高频,我们一般设每 15 分钟一轮,夜间低峰可以拉长到 30 分钟。注意:RPA 抓取和目标写入要串行,不要并发,否则目标系统的单据号会撞。

典型错误一:RPA 抓到「已审核」就推,但售后单还会被撤回。稳妥做法是只取「已完成且超过 30 分钟未变更」的售后单,给业务一个撤回窗口。
典型错误二:商品编码在源端是字符,在 ERP 是数字。两边字段类型不一致,直接传会丢前导零。映射表里要明确「源字符型 → 目标定长字符」,不要在脚本里隐式转换。
典型错误三:次品仓只有一个编码,但调拨单支持多仓位。如果次品仓下还有「待检」「报废」两个仓位,中间层要根据 defect_reason 二次判断,不能默认全部进次品仓主仓位。
典型错误四:调拨单提交后没回写状态。ERP 那边审核失败,源端售后单还停在「已同步」,业务以为成功了。这里要加「回写状态」,失败就回退源端标记。
典型错误五:全量回灌时把「处理中」的售后单也抓进来了。上线第一天就脏数据。务必在 RPA 阶段把状态过滤做死,不要指望下游兜底。

适用:售后单量中等(每天几十到几百单)、外部系统没有开放 API、必须走 RPA 抓取、且下游是 ERP 标准调拨单的场景。不适用:售后单量极大(上万/天)需要实时回流,或下游是定制化 MES、需要复杂工艺流转的场景——那种情况应该走事件驱动,而不是轮询 RPA。