退货在海外仓是一个独立的业务流程，很难当成订单流程的反向执行来做。包裹从买家手上出来，先经过平台售后、国际物流、到仓签收、开箱查验，最后才决定这批货是回到可售库存、进异常区，还是直接丢掉。这条链路上每一步都可能断：面单糊了查不到货主，签收的人和上架的人不是同一个，货在仓库里堆着但系统里还是缺货状态，异常件卡在聊天记录里没人认。系统要接的就是这些环节之间的衔接。退货系统真正要管的是三件事：这批货归谁、现在处在哪个环节、什么时候能重新算作可售。
一、货权：无主退件先解决归属
退货单的标准链路是卖家先建单、仓库后收货。卖家在出库前发现买家取消，可以在订单「已提交」状态下拦截；货已经出库的，就得走退货单，选订单退货或者新建手工退货单，填完信息可以先「仅保存」，落到「待提交」里等二次编辑再提交。
这条链路成立的前提是单子先到。实际到仓的包裹里，总有一部分没有对应的退货单：面单磨损、买家贴错、跨平台混发。仓库扫不到待签收的单，系统就得给一个兜底路径，而且要根据仓库能识别到什么程度分两种。
仓库扫了商品条码能确定货主的，直接建退货单，扫 SKU、核对数量，签收并上架，一步走完。仓库只能看到一箱货、不知道是谁的，就得先建认领单，把包裹挂出来，等货主自己来领。
认领这个动作要解决的是一个数据问题：怎么证明这箱货是你的。做法是让认领人填运单号末尾几位，跟仓库录入的面单信息比对。规则很轻，但把「谁都能领」变成了「只有知道面单的人能领」，误领的概率就压下去了。认领之后还有一步不能省：认领只确认了货权，货要重新入库还得由卖家再生成一张退货单，填退回类型和商品，提交给仓库。认领单和退货单是两张表，前者解决归属，后者解决入库，混成一张就会在货权未明的时候提前动了库存。
认领单一般有几个终态：已认领、已忽略，以及长时间无人认领后的过期处理。忽略这个动作也得让卖家能做，看到列表里明显不是自己的包裹，直接划掉，不然待认领列表会被别人的货堆满，真正要找的那一票反而翻不出来。
二、状态：签收、上架、异常是三件事
退货单最容易被设计错的地方，是把「货到了」和「货能卖了」压成一个状态。
真实的仓库作业里，签收和上架经常是两个人。签收的人在收货口核对面单和箱内数量，上架的人在货架上选仓位、贴标、入库。这两步之间有一段时间差，可能几小时，也可能压到第二天。系统如果只有一个「已入库」状态，这段时间的货就成了黑户：既不算在途，也不算可售，库存盘点时对不上，责任也说不清。
把签收和上架拆成两个动作，各自有独立的确认点，问题就解决了。签收只做核对，不改库存；上架才确定数量和仓位，库存这一步才动。两个人分开操作时，签收的人点确认签收，上架的人扫退货单号继续走入库上架；同一个人操作时，可以直接签收并上架，省掉一次扫单。
第三件事是异常。开箱发现破损、少件、货不对板，这单不能按正常流程走完，但也不能凭空消失。正常的处理是把退货单转成异常单，填异常原因，可以附图片，转完之后仓库在异常列表里能看到，卖家那边也同步可见。异常单停在那里等决策，库存不动，计费也不该按正常上架走。
把状态整理成枚举，大致是这样一个结构：
# 示意：把退货单的流转拆成可独立推进的节点
PENDING_SUBMIT = "待提交" # 卖家建单未提交，可二次编辑
SUBMITTED = "已提交" # 仓库待签收
SIGNED = "已签收" # 核对完成，货在仓，库存未变
ON_SHELF = "已上架" # 数量与仓位确定，库存回写
EXCEPTION = "异常" # 原因与图片留痕，等待决策
CLAIMING = "待认领" # 货主不明，等卖家举证
要紧的是 SIGNED 和 ON_SHELF 之间必须留一道边界，这两个状态的库存语义完全不同。
三、库存回写：上架那一刻才算可售
平台侧的超卖，追到根上经常落在退货回写的时机上。
货一到仓就把库存加回去，等于把还没验货的商品挂上了货架。买家下单，仓库去拣，拣到的是那箱还没开过的退货，短装、破损、型号不对，全部在这一刻暴露，退款和差评跟着来。反过来，等到盘点才回写，可售库存又长期偏低，旺季该卖的时候显示缺货。
回写点放在上架这一步，是有道理的：上架意味着数量已经核过、仓位已经定了、货已经在一个能被拣到的位置。这时候加库存，加的是真实可拣的量。
签收并上架的弹窗里除了上架数量，还有一个丢弃数。这个字段解决的是残值问题：开箱之后确实有一部分货回不去货架，纸质包装破损的、配件缺失的，让操作人当场把它记成丢弃，比事后在系统里做一笔盘亏干净。上架数量和丢弃数加起来跟签收数量对得上，这单才算走完。
库存回写之外还有一层：商家的可售视图和仓库的实物账要同步。仓库上架完成，商家的库存查询里应该立刻能看到这批货回来了，能接着排二次销售。两边各记一套账、靠人工对，是这类系统里最常见的返工来源。
四、责任与计费：谁的动作记谁的账
退货是要收钱的，收的钱挂在具体动作上。
签收这一步不产生费用，上架入库时才扣一次上架费。拆成两个人做和一个人一次做完，都是这一笔。这个设计看着是小事，落到仓库的成本核算上是另一回事：一个退货包裹从到仓到可售，中间经过了哪些动作、每个动作记在谁头上、这笔费用最终摊给哪个货主，都要能在系统里查到明细，不能只在月结的总额里体现。
把动作和费用绑在一起，还有一个附带的好处：异常单不会静默产生费用。货转成异常之后，正常的入库上架不成立，费用就该停在那里，等双方确认怎么处理后再说。仓库最怕的就是异常件占着仓位、耗着人工，账单上却算不出这笔亏损出在哪一票货上。
五、这套机制适合什么样的仓
判断标准是退货量占出库量的比例，以及无主件的绝对数量。
一天几十票退货、面单几乎都能扫出来的仓，标准退货单链路就够了，多出来的状态和兜底路径用不上，反而是额外的配置和维护成本。退货量上去、旺季一天几百票、无主件天天有、异常件需要跨时区跟货主来回确认的仓，才会碰到这几类问题：货权说不清、状态压成一个、库存回写早了、费用摊不明白。
顶妙WMS 的退货链路是按这个思路搭的：卖家端建单提交，仓库端签收上架，签收与上架可分可合，无主件走认领单，异常单两端可见。这条链路被拆成七篇操作说明，从卖家提交到仓库端 PDA 扫码各管一段，拆法本身就是把状态和动作分开的结果。
退货系统的价值在把三件事对齐：货权确定、状态可追、库存回写有时点。三件事对齐了，退货区才不会变成一个只有仓库自己知道里面有什么的黑箱。
