目的仓退货处理
目的仓因为是尾程发货方，会涉及到很多退货的操作，从大方向来说，目的仓也好，中转仓也好，都是一个货物收集的一个物理地点，如图所示，这些物理地点都会遇到 一个场景
今天有个卡车，到仓库码头，卸下了一堆货，放在 码头门口
开卡车的不会跟你说，这个是你们在中国的客户，客户编号是xxxx，里面还有客户编号是 yyyyy的，你们点收下
他只会说，我送来了 一麻袋，一箱子，几麻袋，几箱子 货，你们数一数看一看，没事我就走了
送货的人不会告诉仓库的人，这些货 哪些是 正常 入库上架的，哪些是 退货的
所以 仓库的人要识别，识别的依据是 之前定义的sop
上图的描述如下
1.货物上面会贴有 单据
a.运营方自己的 装箱单
b.第三方物流面单
标准入库单处理
2.仓库人员根据这两个单据类型 ，将 有装箱单的默认为 是 入库单 ，进入【入库处理区】
进入正常的入库上架流程，不在这里描述
正常退货单处理
3.第三方物流单 默认为疑似 退货单，进入【待确认退货处理区】
4.仓库工作人员将当天收到的所有 待确认退货处理区的 所有 货物 放到 【退货工位台】
将 【第三方物流单号】 作为关键信息 扫描入系统进行识别
5.系统先到 退货单 数据池中寻找 输入的 【第三方物流单号】匹配的退货单，如果找到，确认sku和数量，货物进入 【退货上架区】
拒收退货单处理
6.如果退货单据池中找不到，再到正常出库单池子中寻找是否存在（这个点有点小争议，如果出库数据体量够大 比如几个亿的数据，为了找到这个疑似的退货单，要遍历几个亿的数据，这个有点不合理，不过如果是 只有几十万单，可以考虑这个逻辑）
匹配到 出库单，说明 是 拒收退货，货物是否完整未知 ，因此需要仓库人员输入 sku个数 和数量，还有照片，系统将自动生成 一个 【待确认退件单】
7.客户确认 【待确认退件单】 需要明确 ，sku 编号，数量，凭据是 照片等信息
8.【待确认退件单】确认后，仓库人员可以看到状态变化，进行入库上架操作
无主货物处理
9.无主货物，这个 【主】 应该理解为 这个没有任何【主数据】的货物，有可能是以下类型
A.正常退货的，客户还没有来得及建立 退货单
B.之前不是由所在目的仓出库的货物
10.仓库人员可以根据 系统提示后 ，输入 sku个数，数量，照片，系统根据【第三方物流单号】 生成【认领单】到订单中心，客户根据信息先做预判，后与客户绑定，推送到 客户的 OMS系统 ，推送到客户的单据自动转为 【退货单】+【认领单单号】
11.客户根据推送的 【退货单 】 +【认领单】照片信息，补充完成 sku编号，数量信息，提交后数据到仓库进行上架
目的仓退货处理
上图也是比较详细描述上面流程的信息