|
|
@@ -0,0 +1,99 @@
|
|
|
+# Feature Specification: 夜市商家自配送订单闭环
|
|
|
+
|
|
|
+**Feature Branch**: `test-202609v2`（按现行惯例不开独立分支，共享工作区有并行会话）
|
|
|
+
|
|
|
+**Created**: 2026-10-16
|
|
|
+
|
|
|
+**Status**: Draft
|
|
|
+
|
|
|
+**Input**: User description: "夜市商家自配送订单闭环：商家只管出餐，自配送外卖单用户侧显示商家配送中且不显示骑手UI，未发起售后的单次日凌晨由定时任务自动完成并生成商家账单；统一订单列表补充selfDelivery字段；商家端PC订单列表标记自配送"
|
|
|
+
|
|
|
+## User Scenarios & Testing *(mandatory)*
|
|
|
+
|
|
|
+### User Story 1 - 自配送订单次日自动完成（核心闭环） (Priority: P1)
|
|
|
+
|
|
|
+夜市开启了自配送后，用户下的外送单由夜市自己的人配送。摊位主和夜市主都不掌握送达时刻，商家只做现有操作（接单、出餐）。系统在次日凌晨自动把前一天仍处于"配送中"的自配送订单置为完成，并按现有规则生成商家账单（运费归商家）。用户未发起售后的单才自动完成；已发起售后的单跳过，等售后流程了结后按同一规则再处理。
|
|
|
+
|
|
|
+**Why this priority**: 没有完成路径，自配送订单会永远停留在"进行中"，商家运费结算缺失，整个自配送功能不可用。这是闭环的最小可用切片，仅后端即可独立交付价值。
|
|
|
+
|
|
|
+**Independent Test**: 构造一笔已出餐、无售后的自配送订单，触发次日自动处理后，订单状态变为已完成且生成商家账单；构造一笔有售后的同状态订单，验证其不被处理。
|
|
|
+
|
|
|
+**Acceptance Scenarios**:
|
|
|
+
|
|
|
+1. **Given** 自配送外送单已出餐（配送中）且用户未发起售后，**When** 次日凌晨自动处理执行，**Then** 该订单变为已完成，商家账单按现有完成口径生成（含运费归商家）。
|
|
|
+2. **Given** 自配送外送单已出餐且用户已发起售后，**When** 次日凌晨自动处理执行，**Then** 该订单不被自动完成，保持原状态等待售后处理。
|
|
|
+3. **Given** 自配送单在自动处理执行前已被人工完成或取消，**When** 自动处理执行，**Then** 该订单不被重复处理（幂等）。
|
|
|
+4. **Given** 售后被驳回或撤销、订单回到配送中，**When** 之后的某次凌晨自动处理执行，**Then** 该订单按规则正常自动完成。
|
|
|
+
|
|
|
+### User Story 2 - 用户能识别商家自配送订单 (Priority: P2)
|
|
|
+
|
|
|
+用户查看自配送订单时，列表和详情明确显示"商家配送中"等商家配送语义的文案，不显示骑手姓名、电话、实时位置，也不提供"联系骑手"入口；订单完成后与普通订单展示一致。
|
|
|
+
|
|
|
+**Why this priority**: 现状用户会看到骑手式界面（配送状态、联系骑手按钮），既误导又在点击后无响应，属于必须消除的体验缺陷；依赖 P1 的字段约定但不依赖其完成逻辑。
|
|
|
+
|
|
|
+**Independent Test**: 用自配送订单分别打开用户订单列表与详情，可见"商家配送中"文案且无任何骑手信息或联系骑手入口。
|
|
|
+
|
|
|
+**Acceptance Scenarios**:
|
|
|
+
|
|
|
+1. **Given** 自配送外送单处于配送中，**When** 用户打开订单列表或详情，**Then** 显示商家配送语义文案，不显示骑手信息与联系骑手入口。
|
|
|
+2. **Given** 骑手配送的普通外送单，**When** 用户打开列表或详情，**Then** 展示与现状完全一致（骑手信息、联系骑手入口不变）。
|
|
|
+3. **Given** 统一订单列表接口返回自配送单条目，**When** 前端渲染，**Then** 条目携带可供区分的自配送标识。
|
|
|
+
|
|
|
+### User Story 3 - 商家端能识别自配送订单 (Priority: P3)
|
|
|
+
|
|
|
+商家 PC 订单列表对自配送单显示"自配送"标记，摊位主一眼可知该单不会进骑手池、无需等待骑手接单；商家端不新增任何履约操作按钮。
|
|
|
+
|
|
|
+**Why this priority**: 提升商家认知、减少"为什么没骑手接单"的困惑，但不阻塞闭环，价值独立且实现轻量。
|
|
|
+
|
|
|
+**Independent Test**: 在商家 PC 订单列表中，自配送单与骑手单可通过标记区分；自配送单无新增操作按钮。
|
|
|
+
|
|
|
+**Acceptance Scenarios**:
|
|
|
+
|
|
|
+1. **Given** 商家查看订单列表，**When** 存在自配送订单，**Then** 该单显示自配送标记，且不出现"开始配送/确认送达"类新按钮。
|
|
|
+
|
|
|
+### Edge Cases
|
|
|
+
|
|
|
+- 自动处理执行与用户发起售后的时序竞争：以处理时刻的售后状态为准，已发起售后的跳过；处理完成后用户再发起售走的按现有售后规则走，不回滚完成。
|
|
|
+- 出餐时刻临近凌晨边界：口径为"次日凌晨处理此前所有仍处配送中的自配送单"，不依赖出餐后满 N 小时。
|
|
|
+- 自动处理执行时订单恰好被商家通过既有自配送完成接口人工完成：人工结果优先，任务幂等跳过。
|
|
|
+- 任务当天失败/停机：下次执行时按同一条件补偿处理（条件天然覆盖更早的订单）。
|
|
|
+- 夜市当日关闭自配送开关：按订单上的自配送快照判定，不受开关事后变化影响。
|
|
|
+
|
|
|
+## Requirements *(mandatory)*
|
|
|
+
|
|
|
+### Functional Requirements
|
|
|
+
|
|
|
+- **FR-001**: 统一订单列表的每个外卖条目 MUST 携带该订单的自配送标识（依据下单时的自配送快照）。
|
|
|
+- **FR-002**: 用户侧对配送中的自配送外送单 MUST 展示商家配送语义文案，MUST NOT 展示骑手姓名/电话/位置或提供联系骑手入口；对骑手配送订单的展示 MUST 与现状完全一致。
|
|
|
+- **FR-003**: 系统 MUST 在每日凌晨（默认 04:30，可配置）自动完成满足以下全部条件的订单：外送类型、自配送快照=1、处于配送中、用户未发起售后。
|
|
|
+- **FR-004**: 已发起售后的订单 MUST 被自动完成处理跳过；售后驳回/撤销后订单回到配送中的，后续执行按同一规则处理。
|
|
|
+- **FR-005**: 自动完成 MUST 复用与商家人工完成相同的商家账单生成口径（含自配送运费归商家），确保结算一致。
|
|
|
+- **FR-006**: 自动完成 MUST NOT 向用户或商家发送任何推送通知，仅变更订单状态并落操作日志。
|
|
|
+- **FR-007**: 自动完成 MUST 幂等：已处于终态（已完成/已取消）或已有售后的订单不受影响；重复执行不产生重复账单。
|
|
|
+- **FR-008**: 商家 PC 订单列表 MUST 以标记区分自配送订单，且 MUST NOT 新增商家履约操作入口。
|
|
|
+- **FR-009**: 本功能 MUST 仅作用于自配送快照=1 的外送单；骑手配送单、自取/堂食单、闪送单的现有流转 MUST NOT 受任何影响。
|
|
|
+- **FR-010**: 用户 App（msd-user）展示改造的实施方为 [NEEDS CLARIFICATION: 本 feature 是否包含 msd-user 的界面实现，还是仅交付接口/状态约定由他人实施？]
|
|
|
+
|
|
|
+### Key Entities
|
|
|
+
|
|
|
+- **订单**: 新增依赖现有自配送快照字段；本功能涉及其状态（配送中→已完成）、售后状态与操作日志的联动。
|
|
|
+- **商家账单**: 复用现有完成时生成口径；自配送单运费归商家。
|
|
|
+
|
|
|
+## Success Criteria *(mandatory)*
|
|
|
+
|
|
|
+### Measurable Outcomes
|
|
|
+
|
|
|
+- **SC-001**: 开启自配送的夜市产生的无售后自配送订单，100% 在次日上午 10 点前离开"进行中"分类。
|
|
|
+- **SC-002**: 抽样对比自动完成与人工完成的商家账单金额与构成，差异为 0。
|
|
|
+- **SC-003**: 用户侧自配送订单不再出现骑手信息或联系骑手入口（回归用例 0 例出现）。
|
|
|
+- **SC-004**: 自动完成过程产生的用户/商家推送为 0 条。
|
|
|
+- **SC-005**: 骑手配送订单的列表归类、详情展示、状态流转与改造前完全一致（回归通过）。
|
|
|
+
|
|
|
+## Assumptions
|
|
|
+
|
|
|
+- 自配送配置能力维持现状：仅夜市主可配置（2026-09-10 收窄后的范围），本功能不改变配置入口与生效规则。
|
|
|
+- 自动完成时点默认凌晨 04:30（夜市已收摊、避开整点高峰），作为可配置参数而非硬编码口径。
|
|
|
+- 不提供用户"确认收货"入口（产品决策：完成由系统统一触发）。
|
|
|
+- 既有的商家端自配送开始/完成接口保留不删、无界面对接，作为兜底与运维手段。
|
|
|
+- 送达拍照凭据不纳入本功能（夜市主不掌握送达时刻，无意义）。
|
|
|
+- 037 无骑手自动取消已排除自配送单，无需调整；本功能不改动取消类任务。
|
qmj