|
|
@@ -0,0 +1,124 @@
|
|
|
+# 功能规格：線下轉賬支付（payType=6）
|
|
|
+
|
|
|
+**功能标识**：`027-offline-transfer-payment`
|
|
|
+
|
|
|
+**创建日期**：2026-09-03
|
|
|
+
|
|
|
+**状态**：设计已与需求方确认（对话定稿），进入 plan
|
|
|
+
|
|
|
+**输入**：任务206「支付方式加上转账支付」。用户下单时可选「線下支付」，选中后展开商家的收款账户信息（帳戶名稱/銀行名稱/銀行帳戶）；用户线下银行转账后联系商家，商家线下核对后确认收款，订单进入配送流程。资金流：订单金额含运费全部线下转给商家，骑手正常接单不垫付任何费用，骑手到店后向商家收取运费再配送（运费交接纯线下，系统不处理）。支付方式编号使用 **6**。
|
|
|
+
|
|
|
+## 用户场景与测试
|
|
|
+
|
|
|
+### 用户故事 1 - 用户选择線下支付并完成下单（Priority: P1）
|
|
|
+
|
|
|
+用户在收银台看到支付方式列表，其中「線下支付」选项**仅在该商家收款账户三项信息（帳戶名稱/銀行名稱/銀行帳戶）齐全时**出现；选中后展开提示语（转账后请联系客服确认）与商家收款账户卡片；用户提交订单，订单以转账支付方式创建，进入待商家接单，全程不触发任何线上支付。
|
|
|
+
|
|
|
+**为什么这个优先级**：这是功能的入口与前提，没有它后续环节都无从谈起；单独成立即可验证展示与下单链路。
|
|
|
+
|
|
|
+**独立测试**：商家 A 银行三项齐全、商家 B 缺银行账号；A 店收银台出现「線下支付」并显示三项账户信息，B 店不出现该选项；A 店提交转账单成功创建。
|
|
|
+
|
|
|
+**验收场景**：
|
|
|
+
|
|
|
+1. **假如** 商家银行三项齐全，**当** 用户打开收银台，**那么** 「線下支付」可选，选中后展开三项收款信息与转账提示。
|
|
|
+2. **假如** 商家任一银行字段为空，**当** 用户打开收银台，**那么** 不显示「線下支付」选项（不出现空账户卡片）。
|
|
|
+3. **假如** 用户以線下支付提交订单，**当** 订单创建，**那么** 订单支付方式=6、待商家接单、未支付，且不发起任何线上支付。
|
|
|
+4. **假如** 同一商家旗下多家门店（连锁），**当** 任一门店收银台查询收款账户，**那么** 返回同一份账户信息（收款账户为商家级）。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 用户故事 2 - 商家确认收款解锁配送（Priority: P1）
|
|
|
+
|
|
|
+用户线下转账后联系商家；商家核对到账后，在商家端对该转账单点击「确认收款」，订单标记为已收款；**此后**该订单才对骑手可见、可接单。商家接单、出餐、骑手取餐送达走现有流程不变。
|
|
|
+
|
|
|
+**为什么这个优先级**：确认收款是转账单唯一的资金闸门——未确认的单可能永远收不到钱（用户放弃/谎称已转），必须挡在骑手环节之外；同时骑手到店要向商家收运费，商家没确认收款前运费无从谈起。
|
|
|
+
|
|
|
+**独立测试**：创建转账单后，骑手列表看不到该单、直接调接单被拒；商家确认收款后，骑手列表出现该单，接单成功，后续接单/出餐/取餐/送达全部正常。
|
|
|
+
|
|
|
+**验收场景**：
|
|
|
+
|
|
|
+1. **假如** 转账单未确认收款，**当** 骑手查询订单列表，**那么** 该单不出现；**当** 骑手以订单号强行接单，**那么** 系统拒绝并提示「商家确认收款后才能接单」。
|
|
|
+2. **假如** 商家已确认收款，**当** 骑手接单，**那么** 接单成功，订单进入正常配送流。
|
|
|
+3. **假如** 商家对已确认收款的转账单再次确认，**当** 调用确认收款，**那么** 系统拒绝并提示已收款。
|
|
|
+4. **假如** 订单已取消，**当** 商家尝试确认收款，**那么** 系统拒绝。
|
|
|
+5. **假如** 商家确认收款操作发生，**当** 查看订单操作日志，**那么** 记录「商家XX确认转账收款」。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 用户故事 3 - 商家端正确识别转账单（Priority: P2）
|
|
|
+
|
|
|
+商家 Web 端订单列表与订单详情中，转账单的支付方式显示「线下转账」标签（简中/繁中/英文/越南语四语言），商家能一眼区分转账单、到付单与线上支付单。
|
|
|
+
|
|
|
+**为什么这个优先级**：商家需凭支付方式决定核账动作（转账单要查银行流水再确认收款），标签不准则整个线下核对流程都会混乱。
|
|
|
+
|
|
|
+**独立测试**：分别创建到付单、线上单、转账单，商家订单列表三者的支付方式标签各不相同且正确。
|
|
|
+
|
|
|
+**验收场景**：
|
|
|
+
|
|
|
+1. **假如** 订单支付方式=6，**当** 商家在 Web 订单列表或详情查看，**那么** 显示「线下转账」（随界面语言切换为对应译文）。
|
|
|
+2. **假如** 界面语言依次切换简中/繁中/英文/越南文，**当** 查看同一转账单，**那么** 标签四种语言均正确显示，无缺失文案。
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 用户故事 4 - 资金与运费规则（Priority: P2）
|
|
|
+
|
|
|
+转账单的订单金额（含运费）全部由用户线下转给商家；骑手接单、配送不垫付任何费用；骑手到店取餐时向商家线下收取运费。系统不对运费交接做任何记录或结算处理。
|
|
|
+
|
|
|
+**为什么这个优先级**：这是转账模式与到付模式的本质差异（到付骑手向顾客收全款），必须明确写成规则避免实现时套错模式。
|
|
|
+
|
|
|
+**独立测试**：转账单全流程走完后，系统中不产生任何骑手代收、运费结算相关记录，订单金额与运费数值与用户下单时一致。
|
|
|
+
|
|
|
+**验收场景**：
|
|
|
+
|
|
|
+1. **假如** 转账单完成配送，**当** 查看订单，**那么** 金额与运费保持下单原值，系统内无骑手收款/运费代扣数据。
|
|
|
+
|
|
|
+### 边界场景
|
|
|
+
|
|
|
+- 商家银行信息不全（含审核通过后才补全/被清空）：收银台选项随查询结果实时显隐，已下单的转账单不受影响，仍可确认收款。
|
|
|
+- 未确认收款期间用户取消订单：走现有取消流程，无资金争议（用户未付款成功即取消，商家未确认）。
|
|
|
+- 未确认收款期间商家取消订单：走现有取消流程（待接单/已接单可取消）。
|
|
|
+- 转账单长期无人确认：不做超时自动取消（商家自行管理），商家可手动取消。
|
|
|
+- 自取/堂食订单选择線下支付：允许；商家确认收款同样可用，且订单完成时系统按现状自动置为已支付。
|
|
|
+- 骑手在商家确认收款前后刷新列表：列表口径与接单口径一致，不出现「看得见接不了」的单。
|
|
|
+- 已有线上支付方式（信用卡/LINE Pay/Apple Pay/到付/现金）不受任何影响：现金确认收款（payType=4）逻辑保持原样。
|
|
|
+
|
|
|
+## 需求
|
|
|
+
|
|
|
+### 功能需求
|
|
|
+
|
|
|
+- **FR-001**: 系统 MUST 提供按门店查询商家收款账户的能力（帳戶名稱、銀行名稱、銀行帳戶三项），账户信息为商家级（连锁门店共用同一份）；任一项缺失时 MUST 返回空，客户端据此隐藏「線下支付」选项。
|
|
|
+- **FR-002**: 用户以線下支付下单时，系统 MUST 以支付方式值 6 创建订单，订单进入待商家接单、未支付状态，MUST NOT 发起或等待任何线上支付。
|
|
|
+- **FR-003**: 系统 MUST 提供商家确认转账收款能力：将转账单标记为已收款并记录操作日志；对非转账单、已收款单、已取消单 MUST 拒绝并给出国际化提示；该能力 MUST NOT 影响现金单（支付方式=4）的现有确认收款逻辑。
|
|
|
+- **FR-004**: 商家确认收款前，骑手 MUST NOT 能接转账单：接单请求 MUST 被拒绝并提示「商家确认收款后才能接单」（国际化）。
|
|
|
+- **FR-005**: 未确认收款的转账单 MUST NOT 出现在骑手订单列表；如存在向骑手推送新单的链路，同样 MUST 排除。
|
|
|
+- **FR-006**: 确认收款后的转账单 MUST 回归现有状态机：商家接单/出餐仍要求骑手已接单（现状约束不变），取餐/送达流程不变。
|
|
|
+- **FR-007**: 商家 Web 端订单列表与详情 MUST 正确显示转账支付标签，文案覆盖简中/繁中/英文/越南语四种界面语言。
|
|
|
+- **FR-008**: 本功能 MUST NOT 引入数据库结构变更（复用订单现有支付方式与支付状态字段）。
|
|
|
+- **FR-009**: 系统 MUST NOT 为转账单生成骑手运费代收、代扣或结算数据（运费交接纯线下）。
|
|
|
+- **FR-010**: 客户 App 端与骑手 App 端界面不在本期实现范围；本期交付可用接口与交互说明，App 后续直接复用。
|
|
|
+
|
|
|
+### 关键实体
|
|
|
+
|
|
|
+- **订单支付方式（值域）**：1=外送到付、2=信用卡、3=LINE Pay、4=现金（到店/线下当面）、5=Apple Pay、**6=線下轉賬（本功能新增）**。
|
|
|
+- **订单支付状态**：0=未支付、1=已支付；转账单在商家确认收款时由 0 置 1。
|
|
|
+- **商家收款账户**：帳戶名稱/銀行名稱/銀行帳戶三项，来自商家审核资料，商家主账号级，连锁门店共享。
|
|
|
+- **订单状态机**：state（商家轴：0待接单→1已接单→2已出餐→…）与 deliveryStatus（骑手轴：1已接单→2已取餐→3已送达）；外送单商家接单/出餐要求骑手已接单（现状）。
|
|
|
+
|
|
|
+## 成功标准
|
|
|
+
|
|
|
+### 可度量结果
|
|
|
+
|
|
|
+- **SC-001**: 转账单从下单到商家确认收款，用户端除线下转账本身外零线上支付操作，商家确认后订单 100% 可被骑手正常接单并走完配送流。
|
|
|
+- **SC-002**: 未确认收款的转账单在骑手侧可见性与可接单性均为零（列表不可见 + 强行接单被拒，抽查 100% 成立）。
|
|
|
+- **SC-003**: 商家银行信息不全的门店，收银台「線下支付」选项出现率为 0，不出现空账户展示。
|
|
|
+- **SC-004**: 转账单、现金单、到付单在商家端的支付方式标签互不混淆，四语言显示全部正确。
|
|
|
+- **SC-005**: 零数据库结构变更；线上支付方式（信用卡/LINE Pay/Apple Pay）与现金确认收款行为与上线前完全一致。
|
|
|
+
|
|
|
+## 假设
|
|
|
+
|
|
|
+- 商家收款账户数据源为商家审核资料中的银行三字段（2026-09-03 已加），App 端展示文案与交互按参考原型（选项+副标题「轉賬後請聯繫客服確認」+展开卡片+红色提示语）实现，由 App 团队负责。
|
|
|
+- 转账凭证核对完全线下（即时通讯联系），系统不做凭证上传、自动对账。
|
|
|
+- 转账凭证无超时自动取消机制；长期未确认单由商家手动取消。
|
|
|
+- 骑手运费由骑手与商家线下交接，系统不记录、不结算。
|
|
|
+- 支付方式值 6 为全新值，无历史数据冲突（历史值域 1-5）。
|
|
|
+- 商家确认收款入口同时面向商家 App 与商家 Web 预留（本期实现接口，Web 端按钮可后续按需补）。
|
qmj