售后服务

本文档面向购买并使用 VortMall 电商平台的客户（平台运营方），系统梳理售后（退货退款、换货、维修、仅退款等）从申请到完结的业务流程，便于培训、实施与运营对照。每个流程均配有 Mermaid 图示与分步说明，枚举与状态以平台约定为准。

售后类型与状态枚举说明

售后类型（afterSalesType）

枚举值	编码	中文	needReturn	needRefund
RETURN_REFUND	1	退货退款	YES	YES
EXCHANGE	2	换货	YES	NO
REPAIR	3	维修	NO	NO
OTHER	4	其它	NO	NO
REFUND_ONLY	5	仅退款	NO	YES

售后状态（afterSalesStatus）

枚举值	编码	中文含义
IN_REVIEW	1	审核中
APPROVED	2	已通过（中间态，视类型进入后续节点）
REFUSED	3	已拒绝
SEND_BACK	4	待用户回寄
RETURNED	5	商家已收货
COMPLETE	6	已完成
CANCELLED	7	已取消
WAIT_SUPPLIER_AUDIT	21	待供应商审核
WAIT_SUPPLIER_RECEIPT	22	待供应商收货（若业务启用）

1. 售后服务总览

说明：以统一状态机视角展示各售后类型在系统中的主干流转与关键分支，帮助运营理解「审核—供应商—回寄—收货—完结」全链路差异。

参与角色：终端用户（买家）、平台运营、供应商（代销/供货场景）、商家/仓储、支付与退款服务、订单中心。

stateDiagram-v2
    direction LR
    [*] --> inReview
    state "IN_REVIEW 审核中" as inReview
    state "APPROVED 已通过" as approved
    state "WAIT_SUPPLIER_AUDIT 待供应商审" as waitSupplierAudit
    state "SEND_BACK 待回寄" as sendBack
    state "WAIT_SUPPLIER_RECEIPT 待供应商收货" as waitSupplierReceipt
    state "RETURNED 已收货" as returned
    state "COMPLETE 已完成" as completeState
    state "REFUSED 已拒绝" as refused
    state "CANCELLED 已取消" as cancelled
    inReview --> approved: "平台审核通过"
    inReview --> refused: "平台拒绝"
    inReview --> cancelled: "用户撤销等"
    approved --> waitSupplierAudit: "退货退款换货需供应商"
    approved --> sendBack: "退货退款换货不需供应商"
    approved --> completeState: "仅退款或维修其它轻量完结"
    waitSupplierAudit --> sendBack: "供应商通过"
    waitSupplierAudit --> refused: "供应商拒绝"
    sendBack --> returned: "用户回寄商家确认"
    sendBack --> waitSupplierReceipt: "启用供销时可选"
    waitSupplierReceipt --> returned: "供应商确认收货后流转"
    returned --> completeState: "退款或换货闭环"
    completeState --> [*]
    refused --> [*]
    cancelled --> [*]

步骤说明

用户发起售后后，单据进入「审核中（IN_REVIEW）」，系统校验准入规则（订单状态、支付状态、商品类型、行级并发等）。
平台端完成审核：拒绝则进入「已拒绝（REFUSED）」；用户主动撤销等则进入「已取消（CANCELLED）」。
审核通过则进入「已通过（APPROVED）」，再按售后类型分流：退货退款、换货若需供应商参与，进入「待供应商审核（WAIT_SUPPLIER_AUDIT）」；若无需供应商则进入「待回寄（SEND_BACK）」；仅退款或维修、其它轻量场景可直接推进至「已完成（COMPLETE）」。
供应商审核通过则与用户回寄路径汇合为「待回寄」；供应商拒绝则与平台拒绝一致，进入「已拒绝」。
用户在「待回寄」状态填写物流公司、运单号，物流节点确认后进入「已收货（RETURNED）」，商家确认后推进退款/换货履约并进入「已完成（COMPLETE）」。
「仅退款」在平台审核通过并完成退款闭环后，可直接进入「已完成」；「维修」「其它」为不回寄、不退款或按配置的轻量路径，审核通过后进入「已完成」。
各终态（拒绝、取消、完成）后不再向前流转，仅允许查询与审计。

特别说明

审核通过后先进入「已通过（APPROVED）」，再按类型分流至「待供应商审核」「待回寄」或直达「已完成」；若系统合并展示，可与下一状态合并为同一界面步骤。
「待供应商收货（WAIT_SUPPLIER_RECEIPT）」在部分业态或对接模式下启用，可与「待回寄」衔接，经供应商确认后再进入「已收货（RETURNED）」。
类型与 needReturn / needRefund 对应关系见本文档表「售后类型」：退货退款与换货需回寄；仅退款需退款但不回寄；维修与其它默认不回寄不退款（除非运营扩展策略）。

2. 退货退款申请流程（消费端）

说明：用户选择需退货退款的订单行，补充原因与凭证，系统按规则预估可退金额后提交，生成处于审核中的售后单。

参与角色：终端用户、订单与售后前端、商品与价格服务、上传服务（图片）、退款试算服务。

flowchart TD
    startNode([进入订单详情或售后入口])
    pickOrder[选择订单与售后类型RETURN_REFUND]
    pickLines[勾选需退货的商品行与数量]
    fillReason[填写退货原因与说明]
    uploadImg[上传凭证图片]
    calcRefund[系统计算建议退款额与上限]
    confirmSubmit[用户确认并提交]
    successNode([生成售后单状态IN_REVIEW])
    failNode([提示错误不生成])
    startNode --> pickOrder
    pickOrder --> pickLines
    pickLines --> fillReason
    fillReason --> uploadImg
    uploadImg --> calcRefund
    calcRefund --> confirmSubmit
    confirmSubmit --> successNode
    pickLines --> failNode
    calcRefund --> failNode

步骤说明

用户在「我的订单」或售后入口进入，选择目标订单，售后类型选择「退货退款（RETURN_REFUND）」。
在可售后范围内勾选订单行及退货数量（部分退时数量小于等于可退数量）。
选择或填写退货原因、补充说明，满足平台必填项校验。
按提示上传凭证图片（如外包装、质量问题照片），完成格式与大小校验。
系统根据行级实付、已退金额、活动分摊等计算建议退款额与可退上限，并展示给用户。
用户确认信息无误后提交；服务端通过准入校验后创建售后单，状态为「审核中（IN_REVIEW）」。
若行不可选、金额异常或并发冲突，前端或接口返回明确错误，不生成有效售后单。

特别说明

退货退款同时需要退货与退款：needReturn=YES，needRefund=YES。
预估金额可能与最终退款存在差异，以审核通过后实际退款单为准。

3. 仅退款申请流程（消费端）

说明：用户在不回寄实物的前提下申请退款，适用于未发货取消、虚拟商品、服务类或其它平台允许的场景，提交后进入审核。

参与角色：终端用户、订单与售后前端、退款试算服务、商品类型与履约策略服务。

flowchart TD
    entryNode([进入售后申请])
    selectRefundOnly[选择售后类型REFUND_ONLY]
    chooseScope[选择订单行与退款范围]
    inputReason[填写仅退款原因]
    optionalImg[按需上传凭证]
    previewMoney[展示可退金额与上限]
    submitOnly[提交申请]
    createdNode([售后单IN_REVIEW])
    rejectNode([不符合规则被拦截])
    entryNode --> selectRefundOnly
    selectRefundOnly --> chooseScope
    chooseScope --> inputReason
    inputReason --> optionalImg
    optionalImg --> previewMoney
    previewMoney --> submitOnly
    submitOnly --> createdNode
    chooseScope --> rejectNode
    submitOnly --> rejectNode

步骤说明

用户在符合条件的订单上发起售后，类型选择「仅退款（REFUND_ONLY）」。
选择需退款的订单行及金额范围（全额或部分，以系统支持为准）。
填写仅退款原因；部分场景需说明未发货、错拍、服务未履约等。
按需上传凭证图片（如客服沟通截图）。
系统展示可退金额及「已付减已退」约束下的上限。
提交后生成售后单，状态为「审核中（IN_REVIEW）」。
若订单状态、商品类型（如禁止仅退款的品类）不满足，则在提交前或提交时被拦截并提示原因。

特别说明

needReturn=NO，needRefund=YES；通常无「待回寄」物理环节，审核通过后可走退款直达「已完成」路径。
虚拟商品、卡密、付费内容等可能限制为仅退款或禁止售后，见第 12 节准入规则。

4. 换货申请流程（消费端）

说明：用户因规格、型号不符等原因申请换货，需退回原商品但不走现金退款链路，提交后进入审核。

参与角色：终端用户、订单与售后前端、SKU 与库存展示、上传服务。

flowchart TD
    beginNode([发起换货])
    typeExchange[选择EXCHANGE换货]
    selectItem[选择需换货的行与数量]
    targetSku[选择目标规格或换货说明]
    reasonEx[填写换货原因]
    photosEx[上传凭证]
    submitEx[提交换货申请]
    okEx([IN_REVIEW])
    errEx([校验失败])
    beginNode --> typeExchange
    typeExchange --> selectItem
    selectItem --> targetSku
    targetSku --> reasonEx
    reasonEx --> photosEx
    photosEx --> submitEx
    submitEx --> okEx
    selectItem --> errEx
    targetSku --> errEx

步骤说明

用户进入售后入口，选择「换货（EXCHANGE）」。
选择需换货的订单商品行及数量。
选择目标规格 SKU 或按页面要求填写期望换货说明（以产品实现为准）。
填写换货原因并上传必要图片凭证。
提交申请；系统校验库存、换货规则与准入条件。
成功后售后单进入「审核中（IN_REVIEW）」。
校验失败时提示不可换货原因，不生成或回滚草稿。

特别说明

needReturn=YES，needRefund=NO；后续审核通过后进入「待回寄」，商家收货后执行换出发货而非退款单（与退货退款分流一致）。

5. 维修申请流程（消费端）

说明：用户申请维修类售后，无需回寄与退款时作为轻量单据处理，适用于质保内维修指引、线下维修登记等场景。

参与角色：终端用户、订单与售后前端、质保与类目策略（若配置）。

flowchart TD
    s0([进入维修申请])
    s1[选择REPAIR维修]
    s2[选择商品行]
    s3[描述故障与期望处理方式]
    s4[可选上传照片或视频]
    s5[提交维修单]
    s6([IN_REVIEW])
    s7([校验不通过])
    s0 --> s1
    s1 --> s2
    s2 --> s3
    s3 --> s4
    s4 --> s5
    s5 --> s6
    s2 --> s7
    s5 --> s7

步骤说明

用户选择订单与「维修（REPAIR）」类型。
选择需维修的商品行（若多行可选）。
填写故障描述与联系方式、期望处理方式（上门、寄修指引等以平台配置为准）。
可选上传照片或视频作为凭证。
提交后生成售后单，状态为「审核中（IN_REVIEW）」。
平台或商家后续在后台处理维修指引；无回寄、无退款时不经过「待回寄」主路径。
不满足准入条件时提示错误，不进入审核队列。

特别说明

needReturn=NO，needRefund=NO；与「其它」类型在规则上接近，具体 SLA 以运营配置为准。

6. 售后审核流程（平台端）

说明：平台运营对待审核售后单进行通过或拒绝决策；仅退款审核通过可直接完成并触发退款；退货退款需判断是否经供应商，决定进入「待供应商审核」或「待回寄」。

参与角色：平台运营（后台）、订单与售后服务、供应商关系服务、策略引擎。

flowchart TD
    p0([待办售后单IN_REVIEW])
    p1[运营查看详情与凭证]
    p2{审核结论}
    p3["REFUSED 拒绝"]
    p4{是否仅退款REFUND_ONLY}
    p5["触发退款并完成COMPLETE"]
    p6{是否退货类RETURN_REFUND或换货}
    p7{是否存在供应商审核}
    p8["WAIT_SUPPLIER_AUDIT"]
    p9["SEND_BACK 待回寄"]
    p10["维修或其它通过后的COMPLETE"]
    p0 --> p1
    p1 --> p2
    p2 -->|"拒绝"| p3
    p2 -->|"通过"| p4
    p4 -->|"是"| p5
    p4 -->|"否"| p6
    p6 -->|"是"| p7
    p6 -->|"否"| p10
    p7 -->|"是"| p8
    p7 -->|"否"| p9

步骤说明

运营从待办列表打开「审核中（IN_REVIEW）」的售后单，核对订单、商品、用户举证与规则。
作出「通过」或「拒绝」决策；拒绝则单据进入「已拒绝（REFUSED）」，并通知用户原因。
若通过且为「仅退款」，直接走退款执行，完成后单据进入「已完成（COMPLETE）」（中间可经历短暂已通过态，以系统为准）。
若通过且为「退货退款」或「换货」，判断是否需要供应商参与：需要则进入「待供应商审核（WAIT_SUPPLIER_AUDIT）」；不需要则直接进入「待回寄（SEND_BACK）」。
若为「维修」或「其它」且业务定义为轻量完结，审核通过后可直接进入「已完成（COMPLETE）」。
全程记录操作人、时间与备注，供审计与纠纷处理。

特别说明

「仅退款」无回寄环节，与需退货类型在审核后的下一状态严格区分。
供应商是否存在以订单行供货关系、代销配置或平台规则为准。

7. 售后审核流程（供应商端）

说明：当售后单处于「待供应商审核」时，由供应商在供应商端进行处理：通过则进入「待回寄」，拒绝则与平台拒绝一致进入「已拒绝」。

参与角色：供应商账号、供应商端售后模块、平台售后状态服务。

flowchart TD
    q0([售后单WAIT_SUPPLIER_AUDIT])
    q1[供应商查看申请与凭证]
    q2{供应商审核}
    q3["SEND_BACK 通过回寄"]
    q4["REFUSED 拒绝"]
    q0 --> q1
    q1 --> q2
    q2 -->|"通过"| q3
    q2 -->|"拒绝"| q4

步骤说明

供应商登录供应商端，在待办中看到「待供应商审核（WAIT_SUPPLIER_AUDIT）」的售后单。
查看商品、用户申请原因、图片及平台备注。
选择「通过」：售后单进入「待回寄（SEND_BACK）」，通知用户寄回地址与注意事项。
选择「拒绝」：售后单进入「已拒绝（REFUSED）」，同步原因给用户与平台。
超时未处理策略（自动通过、自动拒绝或转平台）以平台配置为准，文档不展开。

特别说明

供应商拒绝与平台拒绝对外均为「已拒绝」，但责任主体与申诉流程可能不同，需在运营手册中单列。

8. 用户回寄商品流程

说明：在「待回寄」状态下，用户填写寄回物流公司与运单号，经系统或物流校验后进入「已收货」或由商家确认收货后进入该状态。

参与角色：终端用户、物流服务查询（可选）、商家或仓储。

flowchart TD
    r0(["SEND_BACK 待回寄"])
    r1[展示寄回地址与注意事项]
    r2[用户填写物流公司]
    r3[用户填写运单号]
    r4[提交物流信息]
    r5{校验是否通过}
    r6[等待商家签收]
    r7["RETURNED 或保持待收货直至确认"]
    r8([异常提示])
    r0 --> r1
    r1 --> r2
    r2 --> r3
    r3 --> r4
    r4 --> r5
    r5 -->|"通过"| r6
    r5 -->|"不通过"| r8
    r6 --> r7

步骤说明

用户在 App 或小程序查看「待回寄（SEND_BACK）」售后单及寄回地址。
使用快递寄出商品后，在页面选择或填写物流公司名称。
填写运单号；若支持，可自动拉取路由信息。
提交后系统校验单号格式、重复性及黑名单规则等。
校验通过后等待物流妥投或商家签收；商家在后台确认收到货后，单据进入「已收货（RETURNED）」或等价状态（以产品文案为准）。
校验失败则提示修改，不推进状态。

特别说明

换货与退货退款在回寄环节共用「待回寄」状态，后续履约不同（退款单 vs 换出发货）。
若启用「待供应商收货（WAIT_SUPPLIER_RECEIPT）」，可能在平台确认前增加供应商节点。

9. 商家确认收货与退款执行流程

说明：商家确认收到退回商品后，系统创建退款单，处理优惠券退回，同步订单与售后状态，直至「已完成」。

参与角色：商家或仓储、平台售后与退款服务、营销券服务、订单中心、支付渠道。

sequenceDiagram
    participant merchant
    participant sys
    participant pay
    participant promo
    participant ord
    merchant->>sys: 确认收到退货
    sys->>sys: 校验RETURNED前置
    sys->>pay: 创建并执行退款单
    pay-->>sys: 退款结果回调
    sys->>promo: 退回已核销优惠券或补发
    promo-->>sys: 处理结果
    sys->>ord: 同步订单行售后与金额
    sys->>sys: 售后状态置为COMPLETE

步骤说明

商家在后台对处于「已收货（RETURNED）」或待确认收货的退货单执行「确认收货」。
系统校验当前状态、可退金额与重复退款防护。
创建退款单并调用支付渠道执行原路退回或约定路径退款。
根据规则处理优惠券：退回、补发或作废，并记录流水。
更新订单行退款累计、订单主状态（如部分退、关闭等）及售后单状态。
退款成功且业务闭环后，将售后单置为「已完成（COMPLETE）」，并通知用户。
若退款失败，进入异常队列重试或人工处理，不将单据误置为完成。

特别说明

序列图中参与者：merchant 商家或仓储；sys 售后系统；pay 支付退款通道；promo 优惠券服务；ord 订单中心。
换货场景此流程可能侧重「换出发货」而非退款单，若同一界面合并处理，需在 UI 区分。
优惠券退回规则以营销配置为准，可能与现金退款异步完成。

10. 退款金额计算流程

说明：系统按行级实付与退货数量计算应退金额，并以「已付金额减已退总额」为上限，避免超额退款。

参与角色：售后试算服务、订单行金额分摊、支付与已退款累计服务。

flowchart TD
    c0([输入订单行与退货数量])
    c1{是否全额退该行}
    c2["应退等于行级实付小计paySubtotal"]
    c3["应退等于单价pay乘退货数量"]
    c4["读取已付金额与已退总额"]
    c5["退款上限等于已付减已退"]
    c6{应退是否大于上限}
    c7["截断为上限或拒绝"]
    c8["输出最终应退金额"]
    c0 --> c1
    c1 -->|"是"| c2
    c1 -->|"否"| c3
    c2 --> c4
    c3 --> c4
    c4 --> c5
    c5 --> c6
    c6 -->|"是"| c7
    c6 -->|"否"| c8
    c7 --> c8

步骤说明

接收订单行标识、申请退货数量及是否该行全退标记。
若为该行全额退货，应退基础金额取行级实付小计 paySubtotal（含分摊后的实付）。
若为部分退货，应退基础金额等于 payPrice × 退货数量（单价以平台定义的实付单价为准）。
读取该行或订单维度「已付金额」与「历史已退总额」（含成功退款与处理中策略以配置为准）。
计算退款上限：上限 = 已付金额 - 已退总额，不得为负。
若基础应退大于上限，则截断为上限或拒绝并提示，以产品策略为准。
输出最终应退金额供审核单与退款单使用。

特别说明

活动分摊、积分抵扣、运费承担会影响 paySubtotal 与 payPrice 的口径，需与订单模块一致。
跨境、多币种场景需额外锁定币种与汇率时点，本文默认本币单订单。

11. 库存回滚流程

说明：在退款审核通过或商家确认适合触发库存回补的时机，系统自动增加 SKU 可售库存、冲减销量并记录库存变动日志。

参与角色：库存服务、商品销量统计、售后与订单事件、审计日志。

flowchart TD
    i0([触发条件满足])
    i1[锁定售后单行与SKU]
    i2[SKU可售库存加回]
    i3[商品销量按规则减少]
    i4[写入库存变动日志]
    i5[幂等与重试处理]
    i6([完成])
    i0 --> i1
    i1 --> i2
    i2 --> i3
    i3 --> i4
    i4 --> i5
    i5 --> i6

步骤说明

在规则定义的时点触发（例如仅退款审核通过且未发货回补、或退货入库后回补，以平台策略为准）。
根据售后单行解析 SKU、仓库维度，加分布式锁防并发重复回补。
将可售库存按退回数量增加，并处理多仓、渠道库存视图。
按规则减少商品销量统计，避免虚高。
记录库存变动日志：单据号、SKU、数量、前后数量、操作来源、操作人或系统任务号。
若调用失败，按重试队列补偿；幂等键保证同一售后不重复加库存。

特别说明

换货若产生入库与换出，可能涉及两次库存动作，需与 WMS 对接约定。
虚拟商品无实物库存时，本流程可能仅更新销量或跳过库存表。

12. 售后准入规则说明

说明：从订单状态、订单与商品类型、支付状态、用户一致性及行级并发等维度约束是否允许发起售后，降低资损与纠纷风险。

参与角色：终端用户、订单服务、商品类型服务、支付状态服务、售后校验服务。

flowchart TD
    a0([用户点击申请售后])
    a1{订单支付状态是否PAID}
    a2{当前用户是否订单买家}
    a3{订单状态是否在允许范围}
    a4{商品类型是否允许该售后}
    a5{同一订单行是否有进行中售后}
    a6([允许进入申请页])
    a7([拒绝并提示原因])
    a0 --> a1
    a1 -->|"否"| a7
    a1 -->|"是"| a2
    a2 -->|"否"| a7
    a2 -->|"是"| a3
    a3 -->|"否"| a7
    a3 -->|"是"| a4
    a4 -->|"否"| a7
    a4 -->|"是"| a5
    a5 -->|"是"| a7
    a5 -->|"否"| a6

步骤说明

校验订单已支付：支付状态 = PAID，未支付或已关闭支付单不允许售后。
校验当前登录用户为订单买家，防止越权。
订单状态须在允许集合内：通常「待发货（CONFIRMED）」「待收货（PROCESSING）」「已完成（COMPLETED）」可申请，具体以平台配置为准；其它状态（如已取消）一般不可申请。
按订单与商品类型限制售后类型：卡密类、付费内容等可配置为「禁止售后」；虚拟商品常限制为「仅退款」或条件退款；实物支持全类型（仍受类目与策略约束）。
同一订单行不允许同时存在多条进行中的售后单（审核中、待回寄、待收货等未终态），避免重复退。
全部通过后进入申请页；否则返回明确拒绝原因。

特别说明

「进行中」售后状态建议包含：IN_REVIEW、APPROVED（若仍视为处理中）、SEND_BACK、RETURNED、WAIT_SUPPLIER_AUDIT、WAIT_SUPPLIER_RECEIPT；不包含 REFUSED、COMPLETE、CANCELLED。
未发货仅退款、已发货退货等业务可与订单状态组合成更细矩阵，实施时在后台策略中心配置。

文档结束。