售后、退货、质检（仓存）架构设计

1. 文档目标

本文用于统一 订单、退货、售后、质检（仓存） 四个模块的业务边界与流转关系，解决当前“归还处理”和“退货处理”概念交叉、都直接连接质检的问题。

本文输出的目标口径如下：

• 将原“归还处理”上收抽象为“售后处理”
• 退货不是售卖订单专属能力，而是订单在 待收货 阶段的回收能力
• 租赁订单在 租用中 或 到期后 不再走“退货”，只能走“售后”
• 售卖订单当前仅在 待收货 阶段支持退货，确认收货后 暂不支持退货，后续可扩展
• 售后单 / 退货单 只表达业务意图，不直接修改仓存
• 仓存变化继续由 入库单 + 质检任务 + 资产 / 仓存SKU迁移 驱动
• 当前售后类型先支持 到期归还、提前归还 两种，后续可扩展 维修、换货

2. 背景与问题

现状中存在以下问题：

• 归还管理 面向租赁订单设备回收
• 退货处理 也承接了设备回收与质检入库
• 两个模块都直接串到仓库质检，概念重叠
• “租用中退货”与租赁订单主流程冲突
• 违约处理里又需要感知“归还进度”，但缺少统一的售后载体

因此需要把订单回收动作拆成两条主线：

• 退货处理：承接订单在 待收货 阶段的退货回收，当前适用于租赁订单和售卖订单
• 售后处理：承接租赁订单在签收后的服务动作，当前为 提前归还、到期归还

两类业务统一接入仓储质检架构。

3. 设计范围

本文覆盖以下范围：

• 租赁订单的售后处理
• 订单待收货阶段的退货处理
• 售后单、退货单、质检任务、入库单之间的关系
• 质检完成后的资产、仓存SKU、库存投影联动
• 与违约、财务结算、订单详情的只读联动口径

本文不展开以下内容：

• 退款通道实现细节
• 支付链路实现细节
• WMS 接口字段细节
• 维修、换货的完整业务规则

4. 核心原则

4.1 单据分层原则

订单负责主交易，售后单/退货单负责服务意图，入库单负责库存凭证，质检任务负责仓库执行，资产与仓存SKU负责库存事实。

4.2 模块职责原则

• 订单模块：负责订单主状态、履约状态、可发起动作判断
• 售后模块：负责租赁订单设备回收类服务流程
• 退货模块：负责订单待收货阶段的退货退款流程
• 质检模块：负责收货、质检、定损、成色判定、处置方式
• 仓存模块：负责资产入库、仓存SKU归属、库存投影更新
• 财务模块：负责退款、押金退还、赔偿应付、售后补差

4.3 库存事实唯一入口原则

无论来源是 售后单 还是 退货单，都不得直接修改库存。库存变化必须通过以下链路完成：

业务单据（售后单/退货单） -> 入库单 -> 质检任务 -> 资产/仓存SKU -> 库存投影

5. 目标架构

5.1 模块总览

flowchart LR
    A[订单模块 Order] --> B{是否发起服务单}
    B -->|租赁订单| C[售后单 After-sales Order]
    B -->|售卖订单| D[退货单 Return Order]

    C --> E[入库单 Inbound Order]
    D --> E

    E --> F[质检任务 QC Task]
    F --> G[资产 Asset]
    F --> H[仓存SKU Warehouse SKU]
    H --> I[库存投影 Inventory Projection]

    F --> J[财务结算]
    C --> K[通知与客服跟进]
    D --> K

5.2 业务分工

6. 业务边界重构

6.1 售后处理

售后处理 专门面向 租赁订单，用于承接设备回收相关动作。

当前支持的售后类型：

• MATURITY_RETURN：到期归还
• EARLY_RETURN：提前归还

后续预留类型：

• REPAIR：维修
• EXCHANGE：换货

6.2 退货处理

退货处理 面向订单 待收货 阶段，承接“未签收前后、需退回仓库并退款/撤销履约”的回收动作。

当前支持范围：

• 租赁订单：仅 待收货 阶段可发起退货
• 售卖订单：仅 待收货 阶段可发起退货

当前不支持范围：

• 租赁订单 在 租用中 或 已到期 / 待归还 阶段发起退货
• 售卖订单 在 确认收货后 发起退货

说明：

• 对租赁订单来说，退货 解决的是“发货后但尚未正式进入租用期”的回收场景
• 对租赁订单签收后的设备回收，应统一走 售后处理
• 对售卖订单确认收货后的退货，当前暂不支持，后续可扩展

退货的核心是：

• 退款
• 回收设备
• 质检入库
• 更新库存

6.3 关键边界结论

• 租赁订单在 待收货 阶段允许发起 退货单
• 租赁订单在 租用中 不允许发起 退货
• 租赁订单签收后只能发起 售后单
• 售卖订单在 待收货 阶段允许发起 退货单
• 售卖订单当前在 确认收货后 暂不支持退货
• 售卖订单不发起 归还类售后单
• 违约处理，租金履约完成进行归还，创建 到期归还售后单，租金未履约完成进行归还创建 到期归还售后单

7. 订单动作矩阵

8. 核心对象设计

8.1 订单 Order

订单是主业务单据，负责：

• 表达交易主体
• 表达履约状态
• 表达当前可触发动作
• 记录关联的服务单据

8.2 统一服务单基座 Service Order

建议从技术上抽象统一服务单基座，前台产品上仍拆分为“售后单”和“退货单”。

8.3 售后单 After-sales Order

售后单是租赁订单的服务载体。

职责：

• 承接客服审核
• 生成归还地址
• 记录寄回物流
• 转仓库质检
• 回写订单售后进度

8.4 退货单 Return Order

退货单是订单在 待收货 阶段的服务载体，当前适用于租赁订单和售卖订单。

职责：

• 承接客服发起退货
• 记录退货物流
• 创建退货入库单
• 触发质检
• 触发退款或履约撤销

8.5 入库单 Inbound Order

入库单是库存凭证，不表达客服审核过程，只表达实物入库事实。

建议继续使用现有入库类型：

• RETURN_IN：归还入库
• RETURN_BACK_IN：退货入库
• MAINTENANCE_IN：维修返库入库

8.6 质检任务 QC Task

质检任务是仓库执行单据。

职责：

• 仓库确认收货
• 判断收货成功/失败
• 执行质检
• 输出质检结果
• 输出定损金额
• 决定入库仓库和质检后成色

8.7 资产与仓存SKU

质检通过后：

• 资产状态回到 IN_STOCK
• 如成色变化，资产迁移到新的 仓存SKU
• 更新库存投影

9. 单据关系

9.1 关系说明

• 一个订单可关联多张服务单，但同一时刻通常只允许一张进行中的主服务单
• 一张售后单或退货单可关联一张入库单
• 一张入库单可关联一张或多张质检任务
• 一张质检任务对应一台或一组待质检资产
• 一次质检完成后更新一条资产当前归属与库存结果

9.3 退款单关系

退款单（含线上退款记录与线下退款工单）是财务结算的凭证：

• 线上退款：支付通道退款成功时生成退款记录，直接关联售后单/退货单/订单。
• 线下退款工单：支付通道退款失败时自动生成，由客服/财务人工处理，处理完成后关联售后单/退货单/订单。
• 一个售后单/退货单可关联多张退款记录/工单（如同时触发押金退还和租金退款）。
• 退款单不直接修改业务单状态，仅作为财务结算凭证。

9.2 关系图

flowchart TD
    O[订单 Order] --> S1[售后单 After-sales]
    O --> S2[退货单 Return]
    S1 --> I1[RETURN_IN 入库单]
    S2 --> I2[RETURN_BACK_IN 入库单]
    I1 --> Q[质检任务 QC Task]
    I2 --> Q
    Q --> A[资产 Asset]
    A --> W[仓存SKU]
    W --> P[库存投影]

10. 状态模型设计

10.1 售后单状态

说明：

• 提前归还 与 到期归还 共用状态框架
• 待支付 用于承接提前归还或售后处理中需要支付的场景

10.2 退货单状态

10.3 质检任务状态

继续沿用现有质检状态：

• PENDING_RECEIPT
• PENDING_QC
• IN_PROGRESS
• QC_PASSED
• QC_FAILED

11. 核心流程

11.1 租赁订单发起售后流程

flowchart TD
    A[租赁订单<br/>租用中 / 已到期] --> B[客户或客服发起售后]
    B --> C{售后类型}
    C -->|提前归还| D[创建售后单 EARLY_RETURN]
    C -->|到期归还| E[创建售后单 MATURITY_RETURN]
    D --> F[用户寄回设备]
    E --> F
    F --> G[进入后续流程<br/>收货 / 质检 / 支付]

说明：

• 本阶段只表达售后发起与设备寄回，不展开客服审核等中间动作
• 售后单创建后，用户寄回设备，后续统一进入仓库收货、质检、结算流程
• 租用中 可发起 提前归还
• 已到期 / 待归还 可发起 到期归还

11.2 售后转仓、质检、结算流程

flowchart TD
    A[RETURN_IN 入库单] --> B[质检任务 待收货]
    B --> C[仓库确认收货]
    C --> D{收货成功?}
    D -->|否| E[终止流程并记录失败原因]
    D -->|是| F[进入待质检]
    F --> G[执行质检与成色判定]
    G --> H{质检通过?}
    H -->|否| I[输出不通过结论/进入后续处置]
    H -->|是| J[资产回库]
    J --> K{是否成色变化?}
    K -->|是| L[迁移到新仓存SKU]
    K -->|否| M[保持原仓存SKU]
    L --> N[更新库存投影]
    M --> N
    N --> O{是否产生定损/补差?}
    O -->|否| P[押金退还或售后完成]
    O -->|是| Q[生成售后应付]
    Q --> R[支付完成]
    R --> P

11.3 待收货阶段退货流程

flowchart TD
    A[订单处于待收货阶段<br/>租赁订单 / 售卖订单] --> B[客服发起退货单]
    B --> C[录入退货原因/物流/退款信息]
    C --> D[创建 RETURN_BACK_IN 入库单]
    D --> E[创建质检任务]
    E --> F[仓库确认收货]
    F --> G[执行质检]
    G --> H[资产回库并更新仓存SKU]
    H --> I{订单类型}
    I -->|租赁订单| J[撤销后续租赁履约并处理退款]
    I -->|售卖订单| K[触发退款]
    J --> L[退货单完成]
    K --> L[退货单完成]

11.4 违约联动流程

flowchart TD
    A[到期违约处理中] --> B{用户选择后续动作}
    B -->|买断| C[进入买断流程]
    B -->|续租| D[进入续租流程]
    B -->|归还| E[创建提前退还/到期归还售后单]
    E --> F[售后流程]
    F --> G[质检完成]
    G --> H{违约金额与售后金额是否结清?}
    H -->|是| I[违约完结]
    H -->|否| J[继续催缴]

补充规则：

• 正常履约中：订单处于 租用中 时，可发起 提前归还
• 违约联动中：订单仍处于 租用中 时，也可发起 提前归还
• 到期违约中：当用户选择“归还”时，创建 到期归还售后单
• 因此，提前归还 的判断核心是订单是否处于 租用中，而不是是否进入违约模块

11.5 退款处理流程

退款是售后/退货流程的最终结算环节。当售后单或退货单完成质检后，根据质检结果和业务规则触发退款。

退款类型定义

退款通道与线下兜底

flowchart TD
    A[售后/退货流程触发退款] --> B{调用支付通道退款}
    B -->|退款成功| C[退款完成 流程结束]
    B -->|退款失败| D{失败原因}
    D -->|通道不支持/渠道关闭/限额| E[自动生成线下退款工单]
    D -->|可恢复错误| F[重试退款]
    F --> B
    E --> G[客服/财务线下处理]
    G --> H[上传凭证 确认退款]
    H --> I[退款完成]

核心规则：

• 业务不卡住：退款失败时，售后单/退货单的主流程状态继续正常流转，不因退款阻塞。
• 自动兜底：支付通道不支持退款时，系统自动生成"线下退款工单"，无需人工创建。
• 线下退款工单状态：待处理 → 已退款。
• 退款凭证：线下退款必须上传退款凭证（银行转账截图等）。
• 跟进记录：退款结果自动同步到关联业务单的跟进记录。

退款与各业务模块的关系

• 售后单：提前归还/到期归还取消售后，触发租金违约金退款。
• 退货单：退货完成后，触发租金退款。
• 订单：触发租金退款。

12. 仓存与质检联动口径

12.1 统一原则

• 售后单和退货单都不能直接加库存
• 客服确认“收到设备”不等于库存恢复
• 只有仓库确认收货且质检完成后，设备才恢复为可管理库存
• 质检后的成色判定决定资产归属的仓存SKU

12.2 售后/退货来源与仓储类型映射

12.3 质检结果对仓存的影响

说明：

• 所有退款操作优先通过支付通道原路退回。
• 若支付通道不支持退款（通道关闭/限额/不支持原路退回），则自动生成线下退款工单，由客服/财务线下处理退款，业务主流程不受影响。
• 退货单退款统一归类为租金退款（含首期款）。

13. 未来扩展口径

在统一服务单基座下，后续新增业务时可直接扩展：

• REPAIR：维修售后
• EXCHANGE：换货售后
• ACCESSORY_REISSUE：补发配件

扩展原则：

• 新类型优先落在 service_type
• 若涉及设备回库，仍必须映射到对应入库单与质检任务
• 若不涉及回库，可不创建入库单，但仍建议保留统一服务单模型

14. 架构结论

本次架构调整后的最终口径如下：

• 订单：负责主交易状态与动作入口
• 售后单：负责租赁订单签收后的到期归还、提前归还等服务流程
• 退货单：负责订单待收货阶段的退货回收流程
• 质检任务：负责仓库执行、定损、成色判定
• 入库单 + 资产 + 仓存SKU：负责库存事实落点

最终实现的核心目标是：

• 让订单在 待收货 阶段统一进入 退货处理
• 让租赁订单签收后的设备回收路径统一进入 售后处理
• 让仓储库存变化继续保持单一事实入口
• 让违约、售后、质检、财务之间有清晰稳定的衔接关系