订单全生命周期

本文档面向购买并使用 VortMall 电商平台的客户（平台运营方），系统梳理订单从创建到完结的各类业务流程，便于培训、实施与运营对照。每个流程均配有 Mermaid 图示与分步说明，不涉及代码实现细节。

订单状态枚举说明

枚举值	状态码	中文含义
PENDING	0	待支付
CONFIRMED	1	待发货
PROCESSING	2	待收货
CANCELLED	3	已取消
INVALID	4	无效（部分发货场景下的原单）
COMPLETED	5	已完成
DELETED	-2	已删除

1. 普通订单完整生命周期

说明：描述标准实物订单在系统中的主路径与常见分支，覆盖从待支付到已完成的全链路，以及取消与逻辑删除分支。

参与角色：终端用户（买家）、平台运营（后台）、支付渠道（异步）、系统调度（超时任务）。

stateDiagram-v2
    direction LR
    [*] --> pending: 创建订单
    pending --> confirmed: 支付成功
    pending --> cancelled: 用户取消或超时未付
    pending --> deleted: 逻辑删除
    confirmed --> processing: 全量发货
    confirmed --> invalidState: 触发部分发货拆单
    processing --> completed: 确认收货
    cancelled --> [*]
    deleted --> [*]
    completed --> [*]
    invalidState --> [*]: 原单标记无效
    note right of pending: 待支付 PENDING
    note right of confirmed: 待发货 CONFIRMED
    note right of processing: 待收货 PROCESSING
    note right of completed: 已完成 COMPLETED

步骤说明

用户提交订单成功后，订单进入「待支付」状态，等待用户完成在线支付或运营代付标记。
支付成功并收到有效回调后，订单转为「待发货」，进入履约准备阶段。
商家或仓库完成全量发货并录入物流信息后，订单进入「待收货」。
用户确认收货或达到系统自动确认条件后，订单进入「已完成」，后续可触发结算、成长值与通知等业务。
若在待支付阶段用户主动取消，或系统按策略取消未支付订单，订单进入「已取消」，库存与营销资源按规则回滚。
若业务需要隐藏或清理展示数据，可对订单执行逻辑删除，进入「已删除」状态（具体可见性与审计以平台配置为准）。
若发生部分发货拆单，原单可能标记为「无效」，由子单继续后续生命周期（详见第 8 节）。

特别说明

「已删除」通常为逻辑删除，财务与合规场景下仍可能保留底层记录；运营侧应区分前台隐藏与物理清除。
「已取消」与「无效」语义不同：前者多为用户或系统主动终止；后者多用于拆单后原单占位，不参与正常履约展示。

2. 下单创建订单流程

说明：从购物车或立即购买进入结算页，经服务端校验后生成正式订单，并同步占用库存、营销资源及后续支付与分销准备。

参与角色：终端用户、商品与库存服务、优惠券与积分服务、支付服务、分销服务、订单中心。

flowchart TD
    startNode([用户发起结算])
    validateAddr[校验地址与配送方式]
    checkStock[校验商品可售与库存]
    lockStock[扣减库存并增加销量占用]
    applyPromo[计算优惠并占用优惠券]
    usePoints[扣减积分或使用余额]
    buildOrder[生成订单主单与明细]
    createPay[创建待支付支付单]
    createDist[按需生成分销关联单]
    resultOk([返回下单成功待支付])
    resultFail([返回失败原因])
    startNode --> validateAddr
    validateAddr --> checkStock
    checkStock --> lockStock
    lockStock --> applyPromo
    applyPromo --> usePoints
    usePoints --> buildOrder
    buildOrder --> createPay
    createPay --> createDist
    createDist --> resultOk
    checkStock --> resultFail
    lockStock --> resultFail
    applyPromo --> resultFail
    usePoints --> resultFail

步骤说明

用户在结算页确认商品、数量、收货信息或自提点，提交订单请求。
系统校验地址有效性、区域配送限制及运费规则（含包邮条件）。
按 SKU 校验可售状态、限购与实时库存，不满足则终止并提示。
通过校验后执行库存扣减与销量占用，防止超卖。
按活动规则匹配优惠券、满减等，并锁定优惠券占用关系。
若用户选择积分抵扣或余额支付部分金额，执行对应扣减与流水记录。
持久化订单主表、明细、金额分摊与扩展属性。
生成与订单关联的待支付支付单，供用户拉起收银台。
若商品或订单参与分销体系，创建或挂接分销单，供后续佣金计算。

特别说明

任一步骤失败应明确失败原因；已发生的占用（库存、券、积分等）须按事务或补偿策略回滚，避免脏数据。
分销单的创建时机与是否拆单，以平台启用的分销模式与商品配置为准。

3. 订单支付流程

说明：用户在待支付订单上选择支付方式，经支付渠道完成扣款，系统以异步回调为准将订单从待支付推进为待发货。

参与角色：终端用户、收银台前端、支付网关、支付渠道、订单与支付服务、回调验签服务。

sequenceDiagram
    participant user as 用户
    participant client as 客户端
    participant orderSvc as 订单服务
    participant paySvc as 支付服务
    participant channel as 支付渠道
    user->>client: 选择支付方式并确认支付
    client->>orderSvc: 查询待支付订单
    orderSvc-->>client: 返回金额与状态
    client->>paySvc: 发起支付请求
    paySvc->>channel: 创建预支付或跳转参数
    channel-->>user: 拉起密码或跳转
    user->>channel: 完成支付授权
    channel->>paySvc: 异步支付结果回调
    paySvc->>paySvc: 验签与幂等处理
    paySvc->>orderSvc: 通知支付成功
    orderSvc->>orderSvc: 订单 PENDING 转 CONFIRMED
    orderSvc-->>user: 消息或页面提示支付成功

步骤说明

用户在订单详情或待支付列表进入支付，选择微信、支付宝、余额等可用方式。
客户端向服务端确认订单仍为待支付且金额未变。
支付服务向渠道申请预支付参数或收银台会话，并记录本地支付单状态。
用户在渠道侧完成密码、指纹或跳转授权。
渠道异步通知平台支付结果；平台验签、防重放、比对金额与商户单号。
校验通过后更新支付单为成功，并将订单状态从「待支付」更新为「待发货」。
触发后续业务（如消息通知、发票预填、分销状态刷新等）。

特别说明

以异步回调为最终成功依据；前端同步返回仅作体验提示，不得单独作为记账依据。
必须做好幂等：同一支付回调多次到达时，订单与支付单只能向成功态迁移一次。

4. 用户取消订单流程

说明：在订单仍处于待支付时，用户可主动取消，释放已占用的库存与营销资源，订单进入已取消。

参与角色：终端用户、订单服务、库存服务、优惠券服务、积分与余额服务。

flowchart TD
    userReq([用户点击取消订单])
    checkState{订单是否为待支付}
    releaseStock[释放库存与销量占用]
    releaseCoupon[释放优惠券占用]
    refundPoints[返还已扣积分或余额]
    setCancelled[订单状态置为已取消]
    rejectOp([提示不可取消])
    doneNode([结束])
    userReq --> checkState
    checkState --> releaseStock: 是
    checkState --> rejectOp: 否
    releaseStock --> releaseCoupon
    releaseCoupon --> refundPoints
    refundPoints --> setCancelled
    setCancelled --> doneNode
    rejectOp --> doneNode

步骤说明

用户在订单详情发起「取消订单」操作。
系统校验当前状态必须为「待支付」；已付款订单不可走本流程，应走售后或管理端取消流程。
回滚库存扣减与销量占用，使商品可再次被购买。
释放已锁定的优惠券，恢复为可用（在券规则允许的前提下）。
若下单时使用了积分抵扣或余额预扣，按规则返还至对应账户并记账。
将订单状态更新为「已取消」，并记录操作者与原因（若采集）。
向用户展示取消成功，列表与详情同步刷新。

特别说明

若与超时自动取消并发，需依赖分布式锁或乐观版本号，避免重复回滚或状态错乱。
拼团、秒杀等活动订单可能有额外限制，以活动规则配置为准。

5. 管理端取消订单流程

说明：运营或客服在后台对订单执行取消；若订单已付款，需完整执行资金与资产回退链路，保证账务与库存一致。

参与角色：平台运营、权限系统、订单服务、支付与退款服务、积分与余额、优惠券、库存、分销服务。

flowchart TD
    adminStart([运营发起后台取消])
    permCheck{权限与风控校验}
    paidCheck{是否已付款}
    refundMoney[发起原路退款或登记线下退款]
    returnPoints[返还积分]
    returnBalance[退还余额]
    returnCoupon[退还优惠券可用性]
    restoreStock[恢复库存与冲减销量]
    cancelDist[取消或冲销分销单]
    setCancelState[订单置为已取消]
    onlyStock[未付款仅释放占用]
    finishNode([完成])
    adminStart --> permCheck
    permCheck --> paidCheck
    permCheck --> finishNode: 拒绝
    paidCheck --> refundMoney: 已付款
    paidCheck --> onlyStock: 未付款
    refundMoney --> returnPoints
    returnPoints --> returnBalance
    returnBalance --> returnCoupon
    returnCoupon --> restoreStock
    restoreStock --> cancelDist
    cancelDist --> setCancelState
    onlyStock --> setCancelState
    setCancelState --> finishNode

步骤说明

运营在后台检索订单并选择「取消订单」，填写原因（如用户拒收、风控拦截、错单等）。
校验操作者角色、数据范围与风控规则（如高额、敏感类目二次确认）。
判断订单是否已发生支付成功；未支付则等价于释放占用并置取消。
已付款时，按支付渠道能力发起原路退款，或记录线下退款凭证并标记异常跟踪。
若订单曾扣减积分，按规则返还积分并写入流水。
若使用余额支付部分或全部，将对应金额退回用户余额账户。
恢复优惠券为可用状态（或按券类型作废并补发，依运营策略）。
恢复商品库存并冲减已记销量，保持进销存一致。
取消或冲销关联的分销单，避免重复计佣或结算。
将订单状态更新为「已取消」，并保留审计日志。

特别说明

已发货或已收货订单的取消往往与售后退货联动，本流程侧重「未发货或允许直接取消」场景；已发货请走退货退款闭环。
跨境、分账、合单支付等复杂场景需在退款步骤增加拆分与对账规则。

6. 超时自动取消订单流程

说明：下单成功后写入延迟消息或调度任务，若在配置时间内未收到支付成功，则自动取消订单并释放资源，超时时间可由平台配置。

参与角色：订单服务、延迟队列或调度器、库存与营销服务、消息通知服务。

flowchart TD
    createOrder([订单创建成功])
    scheduleJob[写入延迟关闭任务]
    waitPay{超时前是否支付成功}
    autoCancel[自动取消订单]
    releaseAll[释放库存券积分等]
    notifyUser[通知用户订单已关闭]
    payOk([支付成功路径保留订单])
    createOrder --> scheduleJob
    scheduleJob --> waitPay
    waitPay --> payOk: 是
    waitPay --> autoCancel: 否
    autoCancel --> releaseAll
    releaseAll --> notifyUser

步骤说明

订单创建为「待支付」后，系统根据全局或店铺级配置计算关单时间点。
向延迟队列、定时任务或调度中心注册一次性任务，携带订单号与计划执行时间。
在宽限期内若收到支付成功回调，则取消该延迟任务或标记订单为已支付，不再执行关单。
若到达计划时间订单仍为待支付，触发自动取消流程。
与用户主动取消一致，释放库存、优惠券、积分与余额占用。
订单状态置为「已取消」，原因标记为超时关单。
可选向用户发送短信、站内信或 App 推送，提示订单已关闭。

特别说明

延迟任务必须幂等：重复触发关单时，状态应稳定为已取消且无重复回滚。
配置项应支持按店铺、活动、商品类型差异化，以适应大促拉长支付时限等场景。

7. 订单发货流程（全量发货）

说明：商家对「待发货」订单一次性维护物流公司与运单号，完成全量发货后，订单进入「待收货」。

参与角色：仓储或运营、物流信息录入、订单服务、消息通知（可选）。

flowchart TD
    shipStart([订单处于待发货])
    inputLogistics[填写物流公司与单号]
    validateOrder{校验订单与权限}
    fullShip[标记全量发货]
    toProcessing[状态 CONFIRMED 转 PROCESSING]
    notifyBuyer[通知买家已发货]
    shipDone([等待用户收货])
    shipStart --> inputLogistics
    inputLogistics --> validateOrder
    validateOrder --> fullShip
    validateOrder --> shipStart: 校验失败
    fullShip --> toProcessing
    toProcessing --> notifyBuyer
    notifyBuyer --> shipDone

步骤说明

运营或仓储在后台或商家端打开待发货订单列表。
录入或对接电子面单获取物流公司编码与运单号，支持多包裹时若仍属全量一次发完则走本流程。
校验订单状态为「待发货」、操作者对该订单有发货权限。
将发货信息写入订单发货记录，并标记为全量发货完成。
将订单状态从「待发货」更新为「待收货」。
向用户发送发货通知，可在通知中带物流查询链接或小程序跳转。
若对接物流订阅，可继续跟踪在途状态（非本图重点）。

特别说明

若实际需要拆成多个包裹且分批发，应使用「部分发货」流程以免状态语义错误。
虚拟商品、自提、O2O 等到店场景可能跳过传统快递发货，请以商品类型配置为准。

8. 订单发货流程（部分发货／拆包裹）

说明：当同一订单需分批发货时，原订单标记为无效，系统拆出已进入在途的子订单与仍待发货的子订单，金额按比例分摊。

参与角色：仓储、订单服务、拆分规则引擎、财务分摊（逻辑层）。

flowchart TD
    partialStart([待发货原单])
    splitLogic[执行拆单与金额分摊]
    markInvalid[原单状态置为 INVALID]
    childShip[子单A进入 PROCESSING]
    childRemain[子单B保持 CONFIRMED]
    recordLine[记录拆单与包裹明细]
    partialDone([分别履约])
    partialStart --> splitLogic
    splitLogic --> markInvalid
    markInvalid --> childShip
    markInvalid --> childRemain
    childShip --> recordLine
    childRemain --> recordLine
    recordLine --> partialDone

步骤说明

运营选择待发货订单，发起「部分发货」并勾选本次发出的 SKU 与数量。
系统按配置规则计算各子单应付金额、优惠分摊与运费分摊，保证总额一致。
将原单状态置为「无效」，表示该单不再作为独立履约单元展示给用户主路径。
生成已发货子单，状态为「待收货」，填写本包裹物流信息。
生成剩余未发子单，状态为「待发货」，等待后续发货操作。
持久化拆单关系、包裹序号与操作日志，便于客服查询与对账。
子单后续确认收货、完成与售后均独立流转，直至全部完结。

特别说明

优惠与积分分摊需在拆单时一次性算清，避免尾差导致客诉；尾差处理规则应在平台层明确（如按最后一单吸收分）。
用户端展示应对用户展示子单列表，避免仅展示「无效」原单造成困惑。

9. 用户确认收货流程

说明：订单在「待收货」状态下，由用户主动确认收货或超时自动确认，状态转为「已完成」，并触发结算、成长值与通知等增值流程。

参与角色：终端用户、订单服务、结算服务、会员成长体系、消息服务。

flowchart TD
    recvStart([订单待收货])
    userConfirm{用户主动确认或超时自动确认}
    toCompleted[状态 PROCESSING 转 COMPLETED]
    settle[触发商家或平台结算入账]
    growth[增加成长值与积分奖励]
    notifyDone[发送完成通知与评价提醒]
    recvEnd([流程结束])
    recvStart --> userConfirm
    userConfirm --> toCompleted
    toCompleted --> settle
    settle --> growth
    growth --> notifyDone
    notifyDone --> recvEnd

步骤说明

用户在小程端或 App 查看物流，订单处于「待收货」。
用户点击「确认收货」，或到达系统自动确认天数后由任务批处理确认。
校验订单状态与防重复提交，将状态更新为「已完成」。
按结算规则将可分账款项记入商家或平台待结算账户，并生成结算明细。
按会员体系规则增加成长值、消费积分或等级进度。
发送订单完成通知，并可邀请用户评价或申请开票。
若存在分销佣金，进入佣金解冻与可提现周期（依配置）。

特别说明

自动确认收货天数通常可配置，虚拟商品、自提、O2O 可能采用不同规则。
若订单仍有未完成售后，完成态与售后状态应并存展示，避免用户误解。

10. 自提核销流程

说明：用户下单时选择到店自提，系统生成自提码；用户到店出示凭证，门店或后台完成核销后订单完结。

参与角色：终端用户、门店店员或后台运营、订单服务、核销服务、消息通知。

sequenceDiagram
    participant buyer as 用户
    participant sys as 系统
    participant store as 门店端
    buyer->>sys: 下单并选自提点
    sys->>buyer: 生成待支付订单
    buyer->>sys: 完成支付
    sys->>buyer: 推送自提码或二维码
    buyer->>store: 到店出示凭证
    store->>sys: 扫码或录入核销
    sys->>sys: 校验订单与自提点
    sys->>sys: 状态转为已完成
    sys->>buyer: 通知提货完成

步骤说明

用户在结算页选择「到店自提」并选定自提点，提交订单。
用户完成支付后，订单进入「待发货」或业务约定的待提货状态（具体展示名称可配置为「待提货」）。
系统生成唯一自提码或动态二维码，并提示有效期限与自提点地址。
用户到店向店员出示手机凭证或报自提码。
店员在门店端或后台核销界面扫码或输入码，系统校验订单归属、自提点一致性与是否已核销。
核销成功后，订单状态转为「已完成」，可打印小票或电子凭证存档。
向用户发送核销成功通知，并可邀请评价。

特别说明

需防止截屏盗用与重复核销，可采用短时动态码或店员二次确认。
若支持部分自提商品，应与拆单或明细行状态联动。

11. 代客下单流程

说明：运营或门店人员在管理端代替用户录入订单，可标记为已收款而无需在线支付，并支持自提等履约方式。

参与角色：平台运营或门店账号、被代下单用户（会员）、订单服务、库存与支付标记、自提服务。

flowchart TD
    agentStart([代客人员登录后台])
    selectUser[选择或录入会员]
    buildCart[添加商品与优惠]
    chooseDelivery[选择快递或自提]
    markPaid{是否标记已收款}
    createPaidOrder[生成已付款订单 CONFIRMED]
    createPendingOrder[生成待支付订单]
    fulfill[后续发货或自提核销]
    agentStart --> selectUser
    selectUser --> buildCart
    buildCart --> chooseDelivery
    chooseDelivery --> markPaid
    markPaid --> createPaidOrder: 是
    markPaid --> createPendingOrder: 否
    createPaidOrder --> fulfill
    createPendingOrder --> fulfill

步骤说明

代客人员使用具备代下单权限的账号登录管理端或门店端。
检索并选定会员，或按规则新建临时会员再绑定手机。
添加商品、数量、价格改价（若权限允许）、优惠券与备注。
选择配送方式：快递地址或指定自提点。
若现场已收现金、刷卡或其他线下收款，可勾选「已收款」，系统直接生成「待发货」订单，跳过在线支付单。
若需用户稍后在线支付，则生成「待支付」订单并通知用户支付。
后续按普通订单发货，或来自提核销流程完成订单。

特别说明

必须严格权限控制与审计日志，防止内部舞弊；大额改价宜二次审批。
标记已收款应对接财务对账要求，区分「线下已收」与「平台代收」。

12. 全款预售订单流程

说明：预售商品采用全款模式（saleMode=1），用户一次性支付全部预售金额，后续发货与确认收货与普通订单一致。

参与角色：终端用户、商品配置（预售）、订单与支付服务、仓储按约定时间发货。

stateDiagram-v2
    direction LR
    [*] --> pendingFull: 提交全款预售单
    pendingFull --> confirmedFull: 一次付清全款
    pendingFull --> cancelledFull: 未支付关闭
    confirmedFull --> processingFull: 约定时间发货
    processingFull --> completedFull: 确认收货
    cancelledFull --> [*]
    completedFull --> [*]
    note right of pendingFull: saleMode等于1

步骤说明

用户选择标注为全款预售的商品，结算页展示全款金额与预计发货时间说明。
订单创建后为「待支付」，金额为预售全款。
用户完成一次性支付，订单进入「待发货」，等待到达约定发货窗口。
商家在可发货时点维护物流信息，订单进入「待收货」。
用户确认收货后，订单「已完成」，结算与会员逻辑与普通订单一致。
若在支付时限内未支付，按超时关单规则取消并释放资源。

特别说明

预售说明、延迟发货免责与客服话术应在商品页显著展示，降低纠纷率。
若存在补款或尾款场景，应使用「定金预售」模式而非本流程。

13. 定金预售订单流程

说明：预售商品采用定金模式（saleMode=2），用户先支付定金订单至「待发货」，在尾款支付期内支付尾款后，后续流转与普通订单一致。

参与角色：终端用户、订单服务（定金单与尾款单关联）、支付服务、商品预售配置。

flowchart TD
    depositCreate([创建定金预售订单])
    payDeposit[支付定金]
    depositConfirmed[订单 CONFIRMED 等尾款]
    openBalance[开放尾款支付窗口]
    payBalance[用户支付尾款]
    normalFlow[进入普通发货与收货流程]
    timeoutDeposit[定金超时未付则关单]
    depositCreate --> payDeposit
    payDeposit --> depositConfirmed
    payDeposit --> timeoutDeposit: 失败或超时
    depositConfirmed --> openBalance
    openBalance --> payBalance
    payBalance --> normalFlow

步骤说明

用户下单时支付定金，订单在业务上可展示为「待付尾款」或仍用「待发货」承载（以产品定义为准），系统记录定金已付事实。
若在定金支付时限内未完成，订单关闭，定金处理规则（可退与不可退）按预售活动配置执行。
到达尾款开始时间，向用户开放尾款支付入口，金额已扣减定金。
用户支付尾款成功后，订单具备完整货款，与普通已付款订单一并进入发货队列。
后续发货、收货、完成与售后与普通订单一致。
若尾款超时未付，按规则关闭订单并处理定金（没收、原路退或转余额等，依配置）。

特别说明

定金与尾款应对应清晰子支付单或对账标识，便于财务核对与监管合规。
尾款阶段价格保护、优惠券是否可用需在活动规则中预先声明。

14. 虚拟商品订单流程

说明：虚拟商品在支付成功后无需物流发货；用户可申请「仅退款」类售后，平台按规则审核处理。

参与角色：终端用户、订单服务、虚拟权益发放（如账号充值）、售后服务。

flowchart TD
    virtualPay([支付成功])
    skipShip[跳过发货环节]
    virtualDeliver[在线发放权益或核销资格]
    showState[订单展示为待收货或已完成策略]
    allowRefund[允许发起仅退款售后]
    virtualEnd([持续服务或完结])
    virtualPay --> skipShip
    skipShip --> virtualDeliver
    virtualDeliver --> showState
    showState --> allowRefund
    allowRefund --> virtualEnd

步骤说明

用户购买虚拟商品并完成支付，订单进入履约处理。
系统不创建物流单，可自动或手动触发权益发放（如卡券、直充、课程开通）。
订单状态可根据产品策略直接置为「待收货」短时展示后自动完成，或直接进入「已完成」。
用户在售后期内可发起仅退款申请，无需退货物流。
客服审核通过后执行退款并冲销已发放权益（技术或人工协调）。
订单在合适节点进入「已完成」并参与结算。

特别说明

已使用的虚拟权益应与退款策略联动，防止恶意刷单。
部分品类可能受监管实名制或年龄限制，需在下单环节完成校验。

15. 卡密商品订单流程

说明：卡密类虚拟商品在支付成功后由系统自动发放兑换码，平台对售后通常完全关闭，以避免码密泄露后的恶意套利。

参与角色：终端用户、订单服务、卡密库存池、安全审计。

flowchart TD
    cardPay([支付成功])
    pickCode[从卡密池分配唯一码]
    maskShow[页面与消息脱敏展示]
    forbidAfter[禁止退款与换货入口]
    completeOrder[订单置为已完成]
    cardPay --> pickCode
    pickCode --> maskShow
    maskShow --> forbidAfter
    forbidAfter --> completeOrder

步骤说明

用户购买卡密商品并完成支付。
系统从预导入或对接供货的卡密池中锁定一条未使用记录并绑定订单。
在用户中心或订单详情展示卡密，敏感位脱敏；支持复制与再次查看权限控制。
订单完成后关闭售后申请入口，或提交即自动驳回并提示规则。
记录领取与查看日志，便于纠纷举证。
财务与结算按已完成订单处理。

特别说明

卡密池需防重入与并发超卖；泄露风险高的品类应缩短查看有效期或增加二次验证。
若法律或渠道强制要求可退，应在商品级单独放开并承担风控成本。

16. 礼品卡兑换订单流程

说明：用户使用礼品卡余额兑换商品时，运费强制为零，且不参与满减、优惠券等促销活动，按礼品卡规则扣减余额生成订单。

参与角色：持卡用户、礼品卡账户服务、订单服务、促销引擎（排除叠加）。

flowchart TD
    gcStart([选择礼品卡支付])
    checkBalance{余额是否充足}
    zeroFee[运费强制记为 0]
    skipPromo[排除促销与优惠券叠加]
    deductCard[扣减礼品卡余额]
    placeOrder[生成订单并履约]
    rejectGc([提示余额不足])
    gcStart --> checkBalance
    checkBalance --> zeroFee: 充足
    checkBalance --> rejectGc: 不足
    zeroFee --> skipPromo
    skipPromo --> deductCard
    deductCard --> placeOrder

步骤说明

用户在结算页选择使用礼品卡余额作为支付方式（或专用兑换入口）。
系统校验卡状态、有效期与可用余额。
结算页自动将运费置零，不展示其他付费配送选项（除非业务允许混合支付且规则另有定义）。
促销引擎在计算时排除与普通优惠券、满减的叠加，仅按礼品卡适用商品范围计价。
确认下单时扣减礼品卡余额并生成订单，记录卡流水号与订单关联。
后续发货与收货按商品类型走对应流程。

特别说明

混合支付（礼品卡+现金）时，应明确各部分的促销资格与发票开具规则。
礼品卡若分平台卡与店铺卡，适用范围需在下单前强校验。

17. 预约到店订单流程（O2O）

说明：【O2O 版】用户购买预约到店服务，支付成功后订单直接进入「待收货」（在业务展示上可称为「待到店」），跳过传统「待发货」；到店核销后进入「已完成」。

参与角色：终端用户、门店、预约与核销服务、订单服务。

flowchart TD
    o2oBook([用户选择到店服务并支付])
    skipConfirmed[支付成功跳过 CONFIRMED]
    toProcessing[直接进入 PROCESSING]
    showBook[展示预约时段与门店]
    storeVerify[到店核销]
    o2oDone[状态 COMPLETED]
    o2oBook --> skipConfirmed
    skipConfirmed --> toProcessing
    toProcessing --> showBook
    showBook --> storeVerify
    storeVerify --> o2oDone

步骤说明

用户在 O2O 场景选择服务商品、门店与可预约时段，提交并支付。
支付成功后，订单不经过「待发货」状态，直接进入「待收货」语义下的履约中状态（界面可映射为「待到店」）。
系统生成预约凭证或排队号，并提醒用户时间与地址导航。
用户到店后，店员在门店端完成核销，校验预约时间与订单有效性。
核销完成后订单「已完成」，可触发服务评价与结算。
若用户未到店，按规则处理过期与退款（依门店政策）。

特别说明

展示层应对用户隐藏易混淆的「待发货」文案，统一用预约语义。
与排班、技师、房间资源冲突时，应有锁号与改约流程。

18. 预约上门订单流程（O2O）

说明：【O2O 版】用户购买预约上门服务，支付成功后直接进入「待收货」（展示为服务进行中），服务完成由用户确认收货后订单完结。

参与角色：终端用户、服务人员或调度、订单服务、消息通知。

sequenceDiagram
    participant user as 用户
    participant order as 订单系统
    participant dispatch as 调度
    participant staff as 服务人员
    user->>order: 提交上门预约并支付
    order->>order: 支付成功直接进入 PROCESSING
    order->>dispatch: 生成服务任务
    dispatch->>staff: 分配上门时间与人员
    staff->>user: 按预约上门提供服务
    user->>order: 确认服务完成收货
    order->>order: 状态 COMPLETED

步骤说明

用户填写上门地址、预约时间段与服务项目，完成支付。
支付成功后订单直接进入「待收货」状态，表示服务待履约或进行中。
调度系统生成服务单并分配工程师或护理人员，可推送预计上门时间。
服务人员上门完成服务，可在端上标记服务完成（若启用）。
用户在客户端点击「确认收货」或「确认服务完成」，订单转为「已完成」。
若服务失败或用户拒收，进入协商、改约或售后流程。

特别说明

上门服务涉及安全与责任界定，建议在预约页展示服务条款与免责提示。
自动确认逻辑若启用，应显著长于快递场景，以覆盖服务窗口。

文档小结

以上十八个流程覆盖 VortMall 订单域的主干能力与典型变体。实施时应结合贵司启用的版本业态、支付渠道与风控策略，在后台完成参数化配置后再对运营与客服进行培训，以保证线上行为与文档描述一致。