退货预收模式（云仓/三方仓）

在树上唱歌 2023-08-09 14:46:52

一、退货预入库

退货预入库是什么？

是指货品退到仓库WMS先预收，再联系前端OMS售后进行下一步处理的动作。

由于前端货主推退换单的时间不及时，所以存在货先退回到仓库，此时一般由仓库收入后核对货品后联系前端货主进行推单。
涉及到客退件的货品可能存在数量、质量上的问题，需要仓库拆包核验后才能接收正式入库，所以需要仓库负责处理退货的人进行拍照、取证，特殊的甚至要进行质检。
涉及到运输过程中的破损索赔问题，包裹实际到库会区分客退、原退。原退即退回时为发出时的同一物流单号，未经过任何拆包，如存在破损情况，一般是由物流公司承担。预入库了可以直观的看到对应货品明细，区分正残。

目前大多数退货流程都是从上至下，从前往后的顺向流程。也就是由买家在平台发起退货退款申请，逐步将退换单推向下游软件。

涉及钱款流向的，平台根据买家信用等级，允许进行极速退款，钱款在支付时从买家暂存至平台，发起退款时，平台则将此钱款退回到了买家。

而在订单履约流程上，ERP仍需要从平台上自动抓取原始退换单，根据不同ERP的规则设置，可以自动创建退换单或手动创建退换单，但退货信息是会有部分缺失的。

比如买家单独退回平台是没有填入物流单号的或者买家偷偷退回后面才反馈给客服；又或者买家分了多个包裹依次退回而ERP的限制不允许自动建多张退换单，此时只能手工建单……

多种情况导致建立退换单时并非都有相应的单号进行对应。

如果是原退，即货还未到买家手里，买家发起退款，此时是由卖家发起物流拦截，退回到原发出点。

只要ERP创建后正常情况下会推送到WMS，存在2种情况导致推单不及时：

此种情况下，会导致存在许多的无头件流到仓库，仓库收了一脸懵逼，不收吧占用大片空间，越堆越乱。

且对于仓库来说无法知道前端什么时候推单过来，这是个持续性的事情，今天推的单可能包含昨天前天的，陆续的。

所以仓库就要对每个包裹逐个尝试入库，推的才能自动关联匹配；不推的如果直接进行入库会直接增加库存的变化。前端若是没有关联该类型，会使得前端ERP的库存增加后还莫名其妙，无法判断其来源。

对于财务方面来说，库存即是钱，盘亏盘盈都是钱的流动，更何况是涉及到退货，稍大一点的公司都会需要对退货方面的帐表进行核对，明确它的来源及变动原因。

即使我们系统对象是仓库，但是仓库的上游则是货主，仓库如果直接回传库存变化，快是快了，库存却乱了。

货主的单子白建了也不知道后面的整体流转情况，对于分析退货情况十分不利。

所以本次的预入库优化则是包含了半逆向流程，即货到仓库先收货，再联系货主推单。

经过上面分析及结合现有系统功能，我们划分了三种退货入库方式：

完全等前端货主推单后才能进行入库，完全限定顺向流程。
按现有模式的预入库，针对微型、小型客户来说，如果对货品客单价不高且不敏感的货主来说，比如纸巾、日常小百货等，可以直接入库，ERP都不需要推退换单而是直接进行入库操作，最后都能达到两个系统库存的一致，货主侧也节省了建单的工作量。
允许先进行预入库，后推退换单再进行自动关联预入库的货品。此功能最大的好处则是保证了退货流程的闭合性，货到仓库收入、登记，发给货主，货主根据明细再进行建单、推单。WMS关联后正常回传，以仓库收到货为主导，是真实有效的货品才最有说服力。

前端如果直接推单有个问题，如买家退回时货品影响了二次销售或退回数量不一样。仓库收到时进行核对后需要反复沟通才能明确到具体问题，继而返厂还是报废处理等，且过程中需要留用取证等，都需要较大的沟通成本。

对于退货占比较高的商家来说，有效减少退货成本和优化退货配置也是很重要的一部分。