spec.md 10 KB
功能规格：線下轉賬支付（payType=6）
功能标识：027-offline-transfer-payment
创建日期：2026-09-03
状态：设计已与需求方确认（对话定稿），进入 plan
输入：任务206「支付方式加上转账支付」。用户下单时可选「線下支付」，选中后展开商家的收款账户信息（帳戶名稱/銀行名稱/銀行帳戶）；用户线下银行转账后联系商家，商家线下核对后确认收款，订单进入配送流程。资金流：订单金额含运费全部线下转给商家，骑手正常接单不垫付任何费用，骑手到店后向商家收取运费再配送（运费交接纯线下，系统不处理）。支付方式编号使用 6。
用户场景与测试
用户故事 1 - 用户选择線下支付并完成下单（Priority: P1）
用户在收银台看到支付方式列表，其中「線下支付」选项仅在该商家收款账户三项信息（帳戶名稱/銀行名稱/銀行帳戶）齐全时出现；选中后展开提示语（转账后请联系客服确认）与商家收款账户卡片；用户提交订单，订单以转账支付方式创建，进入待商家接单，全程不触发任何线上支付。
为什么这个优先级：这是功能的入口与前提，没有它后续环节都无从谈起；单独成立即可验证展示与下单链路。
独立测试：商家 A 银行三项齐全、商家 B 缺银行账号；A 店收银台出现「線下支付」并显示三项账户信息，B 店不出现该选项；A 店提交转账单成功创建。
验收场景：
- 假如 商家银行三项齐全，当 用户打开收银台，那么 「線下支付」可选，选中后展开三项收款信息与转账提示。
- 假如 商家任一银行字段为空，当 用户打开收银台，那么 不显示「線下支付」选项（不出现空账户卡片）。
- 假如 用户以線下支付提交订单，当 订单创建，那么 订单支付方式=6、待商家接单、未支付，且不发起任何线上支付。
- 假如 同一商家旗下多家门店（连锁），当 任一门店收银台查询收款账户，那么 返回同一份账户信息（收款账户为商家级）。
用户故事 2 - 商家确认收款解锁配送（Priority: P1）
用户线下转账后联系商家；商家核对到账后，在商家端对该转账单点击「确认收款」，订单标记为已收款；此后该订单才对骑手可见、可接单。商家接单、出餐、骑手取餐送达走现有流程不变。
为什么这个优先级：确认收款是转账单唯一的资金闸门——未确认的单可能永远收不到钱（用户放弃/谎称已转），必须挡在骑手环节之外；同时骑手到店要向商家收运费，商家没确认收款前运费无从谈起。
独立测试：创建转账单后，骑手列表看不到该单、直接调接单被拒；商家确认收款后，骑手列表出现该单，接单成功，后续接单/出餐/取餐/送达全部正常。
验收场景：
- 假如 转账单未确认收款，当 骑手查询订单列表，那么 该单不出现；当 骑手以订单号强行接单，那么 系统拒绝并提示「商家确认收款后才能接单」。
- 假如 商家已确认收款，当 骑手接单，那么 接单成功，订单进入正常配送流。
- 假如 商家对已确认收款的转账单再次确认，当 调用确认收款，那么 系统拒绝并提示已收款。
- 假如 订单已取消，当 商家尝试确认收款，那么 系统拒绝。
- 假如 商家确认收款操作发生，当 查看订单操作日志，那么 记录「商家XX确认转账收款」。
用户故事 3 - 商家端正确识别转账单（Priority: P2）
商家 Web 端订单列表与订单详情中，转账单的支付方式显示「线下转账」标签（简中/繁中/英文/越南语四语言），商家能一眼区分转账单、到付单与线上支付单。
为什么这个优先级：商家需凭支付方式决定核账动作（转账单要查银行流水再确认收款），标签不准则整个线下核对流程都会混乱。
独立测试：分别创建到付单、线上单、转账单，商家订单列表三者的支付方式标签各不相同且正确。
验收场景：
- 假如 订单支付方式=6，当 商家在 Web 订单列表或详情查看，那么 显示「线下转账」（随界面语言切换为对应译文）。
- 假如 界面语言依次切换简中/繁中/英文/越南文，当 查看同一转账单，那么 标签四种语言均正确显示，无缺失文案。
用户故事 4 - 资金与运费规则（Priority: P2）
转账单的订单金额（含运费）全部由用户线下转给商家；骑手接单、配送不垫付任何费用；骑手到店取餐时向商家线下收取运费。系统不对运费交接做任何记录或结算处理。
为什么这个优先级：这是转账模式与到付模式的本质差异（到付骑手向顾客收全款），必须明确写成规则避免实现时套错模式。
独立测试：转账单全流程走完后，系统中不产生任何骑手代收、运费结算相关记录，订单金额与运费数值与用户下单时一致。
验收场景：
- 假如 转账单完成配送，当 查看订单，那么 金额与运费保持下单原值，系统内无骑手收款/运费代扣数据。
边界场景
- 商家银行信息不全（含审核通过后才补全/被清空）：收银台选项随查询结果实时显隐，已下单的转账单不受影响，仍可确认收款。
- 未确认收款期间用户取消订单：走现有取消流程，无资金争议（用户未付款成功即取消，商家未确认）。
- 未确认收款期间商家取消订单：走现有取消流程（待接单/已接单可取消）。
- 转账单长期无人确认：不做超时自动取消（商家自行管理），商家可手动取消。
- 自取/堂食订单选择線下支付：允许；商家确认收款同样可用，且订单完成时系统按现状自动置为已支付。
- 骑手在商家确认收款前后刷新列表：列表口径与接单口径一致，不出现「看得见接不了」的单。
- 已有线上支付方式（信用卡/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 端按钮可后续按需补）。