同一用户多店结算与同骑手配送方案草案

Branch: 当前 test-202609v2，不创建/切换分支。

Date: 2026-10-12 | Spec: spec.md

阶段: specify 与方案讨论；业务实现未开始。这是可持续修改的第一版方案，不是已批准的执行计划。

1 核心建议

保留“一次结算父单、每店独立子单、各店独立收款”。父单管本次确认参与集合的准入、生效、超时和取消；配送组管同骑手履约，不能把整份购物车等同于本次结算。用户已澄清：同骑手A/B父批次不包含圈外C，也不等待C付款；普通不合并结算不创建组。

付款后不改收款归属、不跨商家调拨。取消时按原支付交易使用对应商家凭证退款。OMG 正式退款已按用户最新要求纳入；环境限制是验证限制，不是砍掉功能的理由。

用户已确认首版纳入即时平台外送、预约平台外送、到付；夜市自配送、自取沿用原流程。预约支持在线付款或到付。同一用户、同一地址仍是合并前提；新多店批次不支持线下转账、原单店转账不变已确认（Q13）。堂食暂不纳入仍为方案建议。

2026-10-12用户最新决定：预约时间处理改造后续单独进行。不撤销预约多店支持；本輪仅按当前有效规则做兼容和批次准入，不重定义时间语义、不新增最迟接单或预约无人接单自动取消。Q12和FR-014移至后续独立事项，详见3.1；不能据此默认旧预约链路已闭环。

用户指出各商家可独立设置支付方式，撤回“同批统一付款方式/渠道”的建议。改为按每家店提供可用方式、用户逐店选择、子单独立保存payType；父批次只汇总，不覆盖子单。LINE/OMG/到付混用及统一生效已确认；新批次过滤转账，不改原单店流程（Q13）。预约时间改造延期见Q12。

2026-10-13最新确认：逐笔收银选择方式，所有新批次共用创建起15分钟支付发起/到付确认期限；期限内服务端已记录并实际发起的线上尝试允许在默认5分钟、平台可配置缓冲内完成付款和服务端确认。创建时快照缓冲及最终确认截止；第15分钟停止新发起/重试/方式切换/到付确认，既有渠道页面可继续完成，不再要求证明用户认证/扣款均发生在第15分钟前。最后成员合法就绪即生效，无需等满缓冲；最终确认截止仍未就绪超时取消。全到付仍须逐笔确认且不是实收，不创建即生效或免期限；旧非多店规则不变。

首店围栏与本次结算成员（用户已确认）

以用户选择的第一家店A为圆心，默认范围1公里、在平台合并配置中可调整；后续店分别与A按坐标直线距离比较，不按道路路线距离，不从B继续扩圈、不以收货地址为圆心。2026-10-13用户明确确认直线距离及范围可配置，不把1公里写死在代码。配置必须有效且大于0，缺失/非法时保守关闭合并；具体单位/精度在data-model/contracts明确，前后端一致。已确认A/B圈内、C圈外时，C不参与本次合并父批次/配送组，A/B的付款生效、金额和折扣不等待或包含C。撤回原Q2“C同批独立配送且ABC一起付款”建议；也不采用“购物车有C就禁止A/B合并”的上一条解释。

接入建议：预结算返回本次可合并参与店和圈外排除原因，用户确认本次A/B后提交；C保留购物车供另行结算，不自动建C单/收费、不静默丢弃商品。最终创建仅写A/B父子单、组和快照；若请求夹带C或成员与确认报价不同，应明确拒绝并重报，不在事务内偷偷过滤。圈内参与不足2店不形成合并组；删除首店/改变成员或地址需重算及确认。

已有C另行结算订单的状态、付款、取消或退款也不影响A/B父批次。统一生效检查只查询该父单真实成员，不扫描用户所有订单或购物车全部店。此边界与“用户是否选同骑手”分开；不选同骑手时各店按原运费计费的规则不因本次澄清改变。

每店不同支付方式的建议

复用StorePayMethodController和PaymentMethodGateService逐店查询平台/商家/凭证可用方式，不取跨店交集。统一创建仅校验参与店至少有一种本批次可用方式，不要求创建请求逐项携带已选方式，也不默认选到付；后续逐子单收银请求再传所选payType、重新校验并保存。旧OrderCreateInput全局paymentMethod及旧单店行为保留，不直接照搬其创建即设到付准入的逻辑。

三店均参与、A选LINE/B选OMG/C选到付：C须在15分钟期限内合法确认，A/B须在该期限内由服务端记录并实际发起支付尝试，可在默认5分钟可配置缓冲内完成真实付款和核实。最后成员就绪即生效，C仅创建不就绪，不提前推送或被抢；全到付最后一单须在15分钟内确认，缓冲不允许新选择/发起/重试/切换或到付确认。两个截止在创建时固定，不因逐店付款/重试延长。

取消/超时按每笔真实收款处理：A/B 已实收则原渠道退款，C 未实收只取消、不产生网关退款。支付进度分别展示线上已付/待付和到付约定，不能把到付计为已实收。骑手取餐、收款页面需逐子单显示付款方式，并单独合计到付待收金额，不能向用户再次收取线上已付餐费。线下收款路线仍沿用现行到付逻辑，不引入新资金池。

混用、逐笔选方式及统一15分钟发起/到付确认期限已确认。已就绪数与实际已付款数分别展示：到付确认参加就绪进度，不参与实收金额。支付失败/未知或未选方式仍不就绪；客户端回跳/已完成标志不能代替服务端事实。旧渠道尝试未决时不能直接切到到付并宣称就绪，须先核实/明确对账补偿，不直接复用旧切换接口或假定旧交易已经关闭。

线下转账范围（用户已确认）

新多店批次只允许当前真实可用的LINE Pay（payType=3）、OMG信用卡/Apple Pay（2/5）和到付（1），无论是否选择合并配送，均不允许转账（6）。本轮不新增待核款提醒、核款期限、转账人工退款或迟到转账补偿入口；此前候选兼容方案已撤下，不继续作为待实现内容。

每店可选集=该店现有闸门返回的就绪方式∩本批次支持方式；商家可不同渠道，不要求跨店交集，但每店都必须有至少一种本批次方式。过滤仅在新多店预结算/创建/换方式上下文，不关闭全局转账开关、不修改商家选择、不让现有StorePayMethodController的单店查询丢失转账。

仅支持转账或没有就绪支持方式的店，预结算时明确返回不能参加多店结算的原因；用户可以另走原单店流程，不能静默移除该店、自动拆成另一次结算或替商家改到付。统一提交重新校验所有店，防止配置变化或伪造请求；在创建任何可支付子单前拒绝非法方式，避免付前两家才发现第三家不能付。多店后续切换同样不得切到6。

现有单店payType=6、商家confirmTransferPayment及历史转账订单保持原流程；不因新的父批次闸门拦住非适用旧订单。回归覆盖单店转账下单、可用方式查询、商家核款和后续原履约。旧转账退款能力不足是已有单独议题，不能宣称本轮已经补齐，也不借此修改现有入口。

2 当前基础与需要改变的入口

现有入口/结构	当前事实	本功能拟调整
UserOrderController.createOrder	一个 OrderParent + 多个 PosOrder；每子单 parentDdId 相同	新批次标识、全量预检、服务端算价、幂等创建与支付期限
OrderParent.orderStatus	0待支付、1已支付、2已取消；当前下单写0，尚无本批聚合机制	纳入到付后建议新增独立批次生效状态，不把“已支付”改成“到付已收款”
PosOrder.isDisplay/displayTime	有预约显示用途，骑手列表使用 isDisplay	保持展示职责；不单独承担付款与操作授权
LINE Pay request	明确拒绝多门店父单下子单支付	放行经过新批次校验的子单，继续取该店金额与凭证；不简单删除全部限制
OMG create	ddId != parentDdId 的多店子单被拒绝	同上；保留所有订单归属、状态、金额和凭证校验
单店付款成功/到付创建通知	当前按子单成功直接进入新单通知，无批次就绪检查	本次已确认付款事实先保存，全部合法就绪才持久记录幂等开放事件；预约等旧开放时点，提交后发送并支持重试，部分付款不得提前履约通知
骑手 acceptOrder(id)	一次只分配一个子单，容量按 pos_order 计数	新配送组原子分配；单笔入口拒绝拆抢；现有任务字典按组计1单/普通单计1单，统一外卖与跨类型总量，不新增子单总量上限
用户 cancelOrder(id)	UserOrderController.cancelOrder仅校验state=0，骑手接单更新deliveryStatus/qsId而不更新state，可能放行已承接单；LINE退款意图按单处理	新批次未生效只允许整批取消；已生效须校验组分配及子单qsId/deliveryStatus，已承接拒绝，未承接条件参加事务/CAS保护；不能绕过旧单笔入口。当前记录方案，不提前改普通订单
当前 OMG refund	测试阶段拒绝所有退款，未提供正式退款执行链	新增正式退款编排、事实记录、查询/重试/人工处理与环境硬边界
LINE Pay refundFull	仅全额；每付款记录目前对应一条退款记录	已确认用户取消只发生在未接并全退，优先复用全额机制；异常售后如需部分退款另确认，不默认新增多次/部分退款扩展

3 一次下单的流程

预结算：前端传地址、按选择顺序的候选店商品、是否同骑手。服务端按首店围栏返回本次参与集合和圈外排除原因，验证参与店/商品/支付方式等，计算运费和实付；不把购物车圈外C混入A/B批次金额或付款进度。
统一提交：以token确定用户，以真实门店确定商品/归属；校验用户确认的参与集合及资格，用报价版本/幂等号防重。本地事务只写本次成员父子单、收费规则快照和配送组，不另建圈外店单；夹带C或成员不一致明确拒绝，不静默删店，不留下部分可支付单。
逐单收银确认：用户按子单进入各店收银台选择方式。线上独立凭证/交易且可信付款成功才就绪；到付由服务端校验用户确认、无渠道扣款且不记实收。未选/失败/未知仍待确认，进度可恢复，不由前端决定就绪。
批次生效：各线上子单须在15分钟内由服务端记录并实际发起支付，且在最终确认截止前取得可信付款成功事实；到付须在15分钟内合法确认。全部真实成员合法就绪、未取消且未过最终确认截止时原子生效一次。不等满缓冲，不按创建或默认到付状态开放；即时提交后开放、预约沿原规则。
整批取消：未生效用户主动取消立即关闭；用户截止停止新操作，但合法在途支付按缓冲核实，不立即取消未知结果。最终确认截止仍未就绪原子关闭，已实收逐笔落全额退款意图，未实收到付/未选只取消，未知/迟到付款继续对账。确认已无法满足全部就绪时可提前关闭；已生效不再按结算超时取消，预约无人接单另属延期规则。
配送履约：合并组只出现一次待抢任务；骑手接组后子单共享骑手，其后各店接单/出餐、骑手取餐/送达、账单及通知沿普通子单流程独立处理。取餐顺序由骑手自行决定，不按用户选店顺序强制，不要求组内全部取齐后才能送达某一已取子单，不新增整组送达/结算入口。非合并子单各自进入原抢单流程。

沿用当前普通外送要求：批次生效且到达预约开放时间后开放抢单，骑手接组成功后商家才接单/出餐，不是先等各店出餐再让骑手看到，否则会与现有骑手先接单规则互相等待。即时单无预约时间等待；独立取餐/送达与组汇总按已确认Q11处理。用户明确多店目的为配送费优惠，除已确认批次支付/接组/收费规则外，不额外设计新的履约流程；本次独立履约不撤回已有批次就绪/超时取消决定。

预约批次共用15分钟发起/到付确认及快照缓冲，线上既有尝试可在缓冲完成和核实，不等预约当天付款；全部就绪后沿旧时点开放。本轮已批准普通平台配送和新多店预约后续扫描、重启补扫、幂等开放和通知重试，不新增预约语义/最迟接单/自动取消。创建先设置type/delryTime再判旧显示条件，普通预约不套多店期限，夜市自配送/自取不纳入扫描。

2026-10-13已确认合并资格：即时单与预约单不能同组；预约单的日期、开始和结束时间必须完全一致才能同组，仅时段重叠、不同日期同钟点均不允许。预结算明确方式/时段不兼容，创建按服务端规范化的真实配送方式/日期/起止时间重验并拒绝不一致成员，不静默改时间、转即时或自动拆组。由于同组由同一骑手承接，不仅凭“都是预约”或时段交集放行。此决定不取消同一时段预约多店支持，也不提前启动下方预约时间改造。

3.1 预约时间处理：后续独立事项

记录日期：2026-10-12；2026-10-13更新范围。新预约语义/最迟接单及无人接单自动取消：未开始，仍延期；旧时点基本开放扫描、重启恢复、幂等及通知重试已经批准纳入本轮。以下新算法建议不代表已批准或实现，基本扫描见7.1。

用户选择的18:00–18:30拟定义为期望送达时段，不是18:00才开始配送；需要统一前后端文案、时间字段及旧数据兼容，不能直接把历史delryTime重新解释。
本轮基本扫描复用原有效时间判断及sys_appointorder_handletime，不改变原时点语义；源码无配置默认60分钟，部署值未核实。18:00开始且提前60分钟时17:00开放仅为示例；新多店另须批次生效，普通预约不要求批次状态。新的开放算法后续评估。
最迟接单拟由预约结束减履约预留时长倒推，预留包含备餐、多店取餐、配送及缓冲，不只用地图行驶时间。首版是否使用保守配置、如何随门店数调整，后续确认。
到达最迟接单仍未承接的配送组/独立订单拟停止抢单并取消，线上已收原路退款、未实收到付不产生退款。生效后不连带取消已接/已取餐任务；已接超时转异常跟进，不直接自动取消。新多店不支持转账，原单店转账若涉及预约取消需在后续专项另评估，不增加到本轮。
下单时校验可履约时间和各店备餐/取餐营业时段、预约太近不开放选择等时间算法留待后续；本轮同组预约日期/起止必须完全一致已确认，不再作为延期待确认项。不同独立订单/批次的预约时间与付款衔接后续按范围另评，不擅自要求所有购物车候选统一时段；原单店转账核款与预约衔接如有需要后续另定。
用户本次已批准旧时点下持久开放扫描、重启补扫、通知幂等/重试及开放与取消/接单竞争，移入7.1及本轮验收，不再延期；新最迟接单/自动取消扫描仍后续。列表与直接接口校验时间资格，不靠App倒计时、不复用TestTask。
UserOrderController在setDelryTime前调用handleIsDisplay，可能把预约当立即单；实施本轮扫描时保证平台配送预约先设置type/delryTime再判旧开放条件，不以错误显示状态掩盖扫描缺失。不重解释历史时段或批量回写历史已开放单；超过预约结束的最迟接单/自动截止改造继续延期。

后续仍从本节确认新预约语义、最迟接单及自动取消；旧时点基本扫描按本次已确认范围在7.1落实。当前只更新方案，不写业务代码、执行SQL、创建或切换分支，不声称扫描或新预约功能已完成。

4 开放履约字段和并发控制

原草案建议复用父单 orderStatus；用户纳入到付后，改为建议新增独立 checkoutStatus（最终枚举在 data-model 确认），不改变原支付状态含义，不用“到付”冒充渠道付款成功：

新批次状态	子单真实付款事实	新批次履约资格
待生效	前15分钟可选方式/发起/确认到付；截止后仅既有线上尝试可继续完成付款和核实，未全部合法就绪仍待确认	全部禁止
已生效	所有真实成员均已线上可信付款成功或明确合法确认到付；确认到付不是实收	满足预约开放/售后/配送归属等规则后才可以
已取消	可以尚未付款、已付款待退款或已退款	全部禁止；后续成功付款不得重新生效

必须有新批次适用标识（例如 checkoutBatchVersion=1，或新状态为空表示旧流程，最终在 data-model 确认），避免影响非适用的历史/单店/旧到付订单。新多店到付属于适用范围；状态字段及兼容标识方案尚待确认。现有到付子单 payStatus=1 是旧履约准入约定，不是渠道实收证据，退款及收款展示必须结合付款方式和真实交易。

2026-10-13用户明确兼容底线：不影响现有非多店订单。新标识必须由服务端新批次创建流程写入，不能由客户端自由指定；不能仅靠parentDdId非空、子单挂父单或数量判断适用。标识缺失的现有普通/历史订单、自取、夜市自配送沿原流程，不被新增15分钟期限、整批就绪、价格/营业策略、转账过滤或通知延迟影响。共享入口允许加合法新批次分支，但不得全局移除LINE/OMG原多店限制或更改原创建/取消规则。

isDisplay 不改变预约时间含义。骑手/商家待办列表同时过滤父批次生效条件，直接操作和推送再独立检查；不是“列表看不到就无法调用接口”。
用户端待付款、支付进度、退款进度仍可见，不把 isDisplay 用在用户待付款查询。
同一父单的付款核销、激活、取消、超时扫描按固定锁顺序串行；数据库父行锁/CAS是最后保护，不只依赖 Redis 锁。所有路径先取得父批次锁再锁支付/子单，避免现有先锁单笔支付再锁父单与取消反向锁造成死锁。
同一配送组接单顺序建议：现有骑手锁 → 组行锁 → 按 ID 顺序锁子单；全部资格、现有任务容量和组门店数校验在锁内，全部分配或全部失败，骑手锁保持到事务结束。不再检查额外子单容量；接组/取消等跨父批次与组的完整锁顺序将在 data-model/执行计划统一，不能各入口自行反向加锁。
支付发起/到付确认截止=本地创建成功时间＋15分钟；支付完成与确认缓冲默认5分钟、平台全局可配置；最终确认截止=前者＋创建快照缓冲。配置修改只影响新批次，重试/逐店结算不续时。选择/发起/重试/换方式/到付确认检查第一个截止；既有线上尝试完成/核销/补单、生效/扫描检查发起资格、真实收款证据及最终截止。第15分钟禁止新操作但保留合法在途交易继续完成，最终截止未就绪关闭后仅记实收/退款，不复活。
2026-10-13用户接受明确放宽：15分钟内发起线上支付，合法既有尝试允许在缓冲内完成用户认证、付款与服务端确认；不再严格要求第15分钟前认证/扣款完成，也不只允许后台响应延迟。服务端实际发起证据与渠道实收事实分别保存，核实原订单/交易、金额、币种、商家及签名/查询结果，不能信前端点击/回跳或事后补写发起时间。全部合法事实核实后立即生效；主动取消已关闭的批次不再使用缓冲重开。

付款确认缓冲及渠道时间适配

平台合并配置页维护支付完成与服务端确认缓冲（分钟），默认5，保存只接受正整数；缺失/非法/读取异常回退5而非无限。创建固定时长/两个截止，修改配置不追改旧批次。默认14:00创建→14:15支付发起/到付确认截止→14:20最终确认截止；第15分钟后禁止新发起/重试/切换/到付确认，既有合法渠道页面仍可继续完成付款。接口/前端文档须明确这项经用户确认的口径放宽，不宣称全部用户付款操作必须在15分钟内结束。
缓冲仅允许第15分钟前服务端已持久记录并实际发起的真实支付尝试继续完成，包含用户渠道认证/付款、回调、查询/补单及服务端确认；前端仅点击、未实际发起、失败后新重试均不因此获得缓冲资格。未知结果不能直接认定未付；未全部核实期间不给商家/骑手履约。全部合法成员就绪立即生效，不必等20分钟；最终截止仍未就绪取消，继续追踪未知交易及迟到实收退款，不能无限等待或在取消后复活。
OMG官方查询订单提供PaymentDate；LINE官方付款明细提供transactionDate。渠道交易时间、服务端发起时间和本地收款核实时刻分开保存，统一时区；第15分钟截止核对实际发起资格，而不是要求渠道付款时间早于该截止。OMG现有事实对象已有paymentDate，当前LINE补单多以本地new Date记payTime，不能直接拿它冒充真实渠道付款时间。真实收款、最终确认截止和取消终态仍须核实，只在合法新批次适配，不全局改变非多店行为。
LINE官方付款请求状态区分认证完成0110与付款完成0123，confirm仍是服务端步骤。采用已确认的发起截止口径，不依赖官方未提供的认证完成时间来证明用户在第15分钟前完成认证；在途合法尝试可在缓冲完成认证/确认/扣款，但认证或仅有请求号不算实收。data-model/contracts须明确实际发起时间/原尝试及渠道交易关联、证据未知时核查、真实收款核实和最终截止并发；当前业务确认不等于接口已实现或验证。
不以长事务锁等待外部HTTP：渠道核查和父批次状态落库分开设计，但最终生效/取消须在同一并发保护下重验状态及截止。重启扫描、回调/查询重复或乱序都不能在第15分钟提前取消应缓冲交易、重复开放或绕过最终截止。
生效事务记录幂等开放通知，预约记录旧规则可执行时点，提交后且满足开放条件才发送；合并组按组、独立单按子单去重，失败可重试，取消后不开放。逐单回调/到付确认仅记事实并聚合，不直接推履约新单；用户真实支付结果通知及后续逐子单取餐/送达通知保持原职责。

创建校验、付款快照与旧流程隔离（用户已确认）

新批次创建前完整校验各参与店、商品、配送资格、支付可用集合及服务端金额，成功后固化商品/价格/折后运费等快照；不能将此规则写成放松创建校验。
创建后普通菜单改价、上下架、停止接新单或营业时间变化不触发重新报价/自动整批取消；用户仍可在创建起15分钟内发起支付/确认到付，既有线上尝试可在缓冲内完成。付款只基于已创建订单金额，继续验证用户归属、订单/批次未取消未过期、支付方式及凭证可用；旧尝试结果未知仍先对账，不能凭快照绕过支付保护。
真实回调/查询核销仍使用对应支付尝试的原交易及凭证快照验真，不用商家后续菜单/凭证变化抹掉已收款事实。实际不能出餐按既定子单规则，不设计结算未完成时新增商家供餐审核或菜品变化监听；快照不是库存保证，本轮不新增库存预占系统。
新批次规则只用于服务端明确标识的新多店；普通创建/支付/价格/优惠/取消等不全局改写，未标识不误判未就绪或进入整批取消。唯一相关补齐是本次批准普通平台配送预约按旧时点后续扫描，不套新批次期限；单店转账、自取、自配送不改。
单笔取餐/送达及结算/通知仍沿普通流程，组只汇总/去重任务。优惠、促销和发票逐单沿原有效规则；本次已确认补充新批次取消优惠券释放/返还、保留原有效期及幂等，见7.1，不全局重写普通券规则，不把返券或取消状态当作渠道退款成功。
回归必须覆盖新批次创建后改价/上下架/普通停业仍按快照结算、非法付款继续拒绝、旧流程无新期限/就绪拦截、普通LINE/OMG/到付/转账、自取/自配送、促销优惠券发票、取消退款及消息时机；没有实际运行回归前不宣称兼容已验证。

5 配送组与金额快照

建议新增一个轻量 order_delivery_group 表表示配送组，PosOrder 增加可空 deliveryGroupId；不新增收款账户表或跨商家资金池。不合并时不创建组。

建议数据职责：

父单：新功能标识、生效状态、幂等号、创建起15分钟用户操作截止、确认缓冲时长快照/最终确认截止、已就绪/已实收及待核实进度、预约信息、合并/锚点和收费快照；不设唯一渠道或全到付无截止例外，状态不代表退款到账。
配送组：父批次、用户/固定地址、待抢/已接/履约/结束汇总状态、骑手、版本；成员关系由子单关联表达。组内可同时有待取、配送中、已送达、合法取消等子单，不用单一组状态覆盖各单事实；汇总只用于展示及任务释放，不新增整组取餐/送达/结算行为。
子单：待选/逐单所选payType、线上已付/到付已确认的就绪事实、选择顺序、运费/优惠/实付快照与原履约状态。不能用创建时默认payType=1或payStatus=1判断到付已经由用户确认；字段/派生规则在data-model统一。
退款：对应子单/原支付尝试/渠道交易、凭证快照、退款原因与金额、退款业务号、处理中/结果未知/重试/成功/失败/人工处理。新功能退款记录不能与“付款成功”或“父批次取消”混为一列。

用户已确认首版全局规则、不做城市/区域差异配置，最大合并门店数默认5且可配置。开关、范围、最大店数、动态折扣阶梯及支付完成/确认缓冲统一在配置页面管理；支付发起/到付确认期限固定15分钟，缓冲默认5分钟可配置，创建时固定两个截止。城市/区域覆盖留后续，本轮不加归属字段。最大店数在预结算/创建/接组重验，接单须满足原任务字典，不自动拆组，不新增子单总量上限或要求最大店数小于任务上限。

动态配送费折扣阶梯（用户已确认）

平台维护可增删改的“最少店数＋折扣”列表，无需为后续4店七折等档位改代码或重新部署，不使用固定两档字段。具体配置存储形式在data-model阶段沿现有配置能力确定，本轮不预先创建新表或DDL。

报价按实际参与同骑手配送组的去重门店数N匹配，圈外店不计；选择所有门槛不超过N的档位中门槛最大的档位，不按配置行顺序或直接选最低折扣。
首版初始折扣已确认，只配置两个档位：最少2家九折（系数0.9）、最少3家八折（系数0.8）；没有更高档时3/4/5家均八折。4家七折不默认启用。后续平台若新增4家七折，则新报价中4/5家七折；再增5家六折，则5家命中六折。新增示例不代表上线默认值，不取消最大合并店数/骑手容量约束。
同组各店原配送费分别乘该档位折扣，按HALF_UP四舍五入到整数新台币后固化，批次总运费为各店结果相加，不做跨店尾差分摊；商家给骑手折后毛运费及到付公式使用同一金额，详见下方已确认舍入口径。
门槛必须为不小于2的整数且不可重复；折扣系数大于0且不大于1。保存拒绝非法配置；读取缺失/非法或无法形成合法报价时沿规格保守关闭合并报价，不影响原单店流程。
创建时固化规则版本/命中门槛/折扣及每店金额；修改配置只影响新报价，不重算已创建待结算或已生效批次，允许阶段部分取消也不重算档位、不补差。预结算与提交间配置变化按现有报价重验约定明确重报价，不静默混用新旧金额。
验收覆盖动态增删改、最高门槛匹配、参与店去重、圈外店排除、非法配置拒绝、旧订单快照、提交配置竞争和取消不补差。

5.1 骑手接单容量：沿用字典、合并组算1单（用户最新确认）

2026-10-13用户确认撤回此前双层容量方案：不新增骑手实际子单总量上限、新字典或页面管理项，只沿用现有接单字典，并调整计数为合并组整体算1单。组内最大门店数由本功能配置独立控制，默认5家；这是单组规模，不是骑手所有子单合计限制。

外卖任务数 = 进行中的配送组数（按deliveryGroupId去重）+ 未分组进行中独立外卖订单数。只有真实组才去重，不按parentDdId去重；A/B组与另行结算的独立C计2任务，C不属于A/B合并父批次。
跨类型总任务数 = 外卖任务数 + 进行中闪送任务数。闪送任务和加急独占规则保持不变；外卖接单、闪送接单使用统一统计，不能其中一个入口仍按组内订单行计总任务。
接一个有N条有效待承接子单的组，只需要外卖任务+1、跨类型总任务+1不超过原字典上限，且N不超过合并门店上限；普通独立外卖为+1任务。不按骑手全部子单数量另设接单上限，组内订单仍分别保留履约/支付状态。
全部资格、任务和门店数校验在同一个骑手锁与分配事务内完成。不把未接单预约组预占到某个骑手，不把到付当作不占任务。

配置职责：

配置	口径	本轮处理
sys_rider_food_active_order_limit	同时承接外卖任务数；单独订单和配送组各计1	沿用现有配置，不自动改值
sys_rider_flash_active_order_limit	同时承接闪送任务数，保持原义	沿用现有配置
sys_rider_total_active_order_limit	外卖任务+闪送任务总数	沿用现有配置，不自动改值
合并组最大门店数（复用本功能全局配置）	一次合并最多多少店，可配置	默认5（已确认）

例：外卖/总任务上限均为1、组门店上限为5，空闲骑手可以接一个三店或五店组，均占1任务，不能再接另一普通单或闪送。若外卖/总任务均允许2且其他条件满足，两个五店组可以接，按2任务计，不因子单合计10而额外拒绝。以上是计数示例，不是修改现有字典值的授权。

现有任务字典缺失、非法或读取异常均保守回退为1，即最多1个任务而不是组内最多1家店；合法五店组仍整体算1任务。合并门店数等配置缺失/非法时保守关闭合并报价，不回退为不限门店。接单按实时任务容量和门店上限再校验，不保证某位空闲骑手存在或接单；若组门店上限下调导致已创建待接组无法接，明确原因并交平台跟进，不追改收费快照，也不强制取消已接任务。不再校验每组最大店数与已撤回子单上限的大小关系。

容量释放：组完成或合法取消部分子单后，只要剩余有效成员仍在履约/处置，组就继续占1任务；最后一个有效成员结束才释放整个组任务，不存在逐子单释放名额。各单独立送达不等于整组结束，某单结算/通知不等待其他单。已取餐进入售后或异常不等于货物已交付，确认实际履约结束或交接处理前仍占组任务。实现不能沿用“afterSaleStatus不为0就不计容量”的简化过滤；异常处置终态按Q5后续范围确认，不因Q11独立履约而新增特殊业务状态。

验收至少覆盖：三店/五店组都算1任务、组与独立单分别计数、总任务和加急独占、普通单/闪送/接组并发。任务上限1时两组最多成功一个，任务上限2且其他条件满足时两个五店组可接；部分完成/取消不提前释放组任务、已取售后保持占用、字典异常回退1任务、组门店上限变更与历史非分组兼容。不得残留已撤回的子单数量拒绝条件。

配送费舍入（用户已确认）：每店折后运费=该店原运费×命中折扣，在新台币元口径用十进制精确计算、HALF_UP到整数后固化；批次总运费=各店已舍入运费相加。不先对整批原运费总额打折舍入，不按比例分摊，不向任何店补齐尾差；撤下原比例分摊/稳定顺序补尾差建议。没有合并的单店仍沿原计费规则。

例如41元八折32.8元按33元；45元九折40.5元按41元。三店原运费各41元、八折后各33元，总运费99元，而不是总额123元八折98.4元再舍入为98元。即使各店原运费不同，也逐店按同一规则处理。仅配送费折扣按本条舍入，不额外修改商品价/优惠券等原有金额规则。

用户支付、真实原交易退款、商家给骑手的毛运费、到付总额减运费以及骑手账单计算基数统一使用已固化结果；佣金/税沿既有规则另算。允许阶段部分取消不重算剩余成员、不补差。实现前核对持久化/DTO与LINE/OMG的实际金额单位并明确转换（实体“分”的注释不能直接当成渠道单位），避免元/分错算；统一使用十进制运算，不能各端或支付渠道各自舍入造成不一致。

示例：A/B/C 原运费各40，三店八折后运费96，每店实付32，各店餐费加32分别向该店支付。这不是从某店账户抽钱转给另外一店。

5.2 折后运费与到付交付（用户已确认）

各店配送毛收入按折后实付运费计算：上述每店32就是商家给骑手的运费，不仍给40，不新增平台或商家补足24的机制。配送折扣同步降低该单骑手毛配送收入；既有佣金/税另依原规则计算，不把32说成扣除佣金后的净收入。

设每子单应付总额为A、折后运费为F：

线上已付：用户给商家A，商家按现行取餐线下交付方式给骑手F；骑手不再向用户收该单A。原单店转账沿用原结算，不混入新批次。
到付：现场有餐可交付时，骑手当面在交餐环节给商家A−F，再向用户代收A，配送毛收入为F；不能供餐时不先付钱、不设计取餐前垫款。A是优惠后实际应付，不能用商品原价减运费或从父批次总额直接扣。
A包含哪些商品优惠/包装等费用继续遵循服务端子单算价；F固定在子单收费快照中，三方展示和现有账单的freight基数相同。

示例（不含其他优惠/附加项）：各店餐费100、原运费40、折后运费32，每单总额132。若三店都是到付，骑手分别给商家100，向用户合计收396，商品交付款合计300，配送毛收入合计96；若A/B线上、C到付，仅C的132计入用户待代收，给C商家100，A/B商家分别给骑手32，不能把整个批次396再次代收。

接口/前端接入文档逐店区分“给商家金额”“商家给骑手运费”“用户到付待收”，金额方向不能混成一个组运费字段。沿用现有到付资金路线，不新增资金池。已取消成员不继续作为待收目标；若现金已发生，按售后规则独立记录追回/退款事项，不能仅重算组总额掩盖事实。

现有OrderService.setQishouBilling按子单freight计算佣金/税及账单并调用钱包入账，接入时须保持上述折后基数和原结算职责一致。现金交付、账单记录及钱包余额不得被解释为平台额外再支付一次同笔运费；钱包原结算用途及取消后的冲正范围需在实现时核对，不能仅改报价便宣称现金/账单已闭环。

不在本轮方案中默认增加自动最优路线/TSP。围栏资格已确认用首店到其他店的直线距离、默认1公里可配置；配送距离/预计时长仍用道路路线，不把直线围栏判断改成道路导航/计费。取餐顺序由骑手自行决定，不强制按选店顺序执行。地图仓库现有按序多点算路可作为能力参考，尚未接通本业务，不能据此新增强制路线编排或宣称已联通；普通子单导航沿原流程。

6 取消与退款

生效前

整批取消。每个已付款子单退完整实付金额，包含该单实付配送费；未付款取消，结果未知先补查。退款实际调用使用该子单对应商家凭证/交易，不能只改 payStatus。

统一15分钟是支付发起/到付确认期限，不是催到付提前交现金；默认5分钟可配置缓冲仅允许合法既有线上尝试继续完成付款和核实，不给到付追加确认机会。全到付未确认不无限保留；在途未知不能按未付款抢先取消，最终截止未就绪关闭，真实线上实收原路退，未收款到付不因payStatus=1造退款。已全部合法就绪生效后不再按结算期限取消；预约无人接单截止仍属Q12延期事项。

支付请求在发起截止前由服务端记录并实际发起，仅代表既有交易可在缓冲继续完成，不代表已经付款或可以开放履约；须在最终确认截止前核实对应真实收款。第15分钟后禁止新的支付发起/重试/方式切换/到付确认，合法既有渠道页面可能在该时点后完成付款，这是用户已接受的口径放宽。最终截止仍不就绪或用户已主动取消则关闭；本地关闭不能保证渠道不再扣款，迟到实收持续对账退款，不重新激活。

生效后

按阶段处理，不能全阶段套用原文“单店取消不退配送费”：

已确认：骑手尚未接单。 生效后可取消单个店铺子单，退该单完整实收含折后运费；例如餐费100/运费32、实收132则退132，不保留运费。未实收到付仅取消、移除待收，不产生网关退款。其他子单继续履约、原运费不变。
取消与接组须事务内检查真实未分配状态并同步组成员/版本，不信前端待抢页面。取消先成功，旧接组请求须重验且不能分配已取消成员；接组先成功，用户取消拒绝，无退款或审核任务，不再走另一条“申请取消”路径。
取消单退出有效配送集合，剩余成员继续形成待接任务；仅剩一单仍沿用原运费，不重报原价。所有有效成员取消时组/父单按全取消汇总结束，不再推待抢；各退款仍独立跟踪，不把任务结束当作钱已到账。
已确认：骑手已接，用户不得取消。 包括尚未取餐及商家尚未接单阶段，既不能单店取消也不能整组取消；不新增用户申请取消/商家审核，避免增加商家负担。2026-10-13用户再次明确取消必须判断骑手已接事实：现有UserOrderController.cancelOrder只判state=0不足，OrderLifecycleService.acceptDeliveryByRider仅更新deliveryStatus=1和qsId，商家未接时state仍可能为0。新批次检查配送组承接、qsId及deliveryStatus，不因某一个字段异常为空或仍为0掩盖其他承接证据；未承接条件须在事务/CAS中与取消更新同步保护，避免读后接单竞态。隐藏按钮不能代替直接接口校验；当前仅更新方案，普通非多店入口不提前改写。
已确认：商家无法供餐、该店尚未取餐。 骑手已接后，所属商家可按无法供餐原因取消自己的子单，全部实收含折后运费全退；其他店继续由原骑手履约，不补差、不重分配、不默认整组取消。此为商家异常入口，不恢复用户已接取消权限，也不新增用户申请/商家审核任务。
商家取消须和该店取餐竞争校验：先取消则不能再取该单，先取餐则拒绝未取餐异常取消路径。取消同步有效成员/站点、用户到付待收及容量，通知骑手无需再到该店；全组无有效成员则结束组任务，退款仍独立跟踪。其他店已发生履约不被连带回滚。
用户已明确到付现金流程：有餐可当面交付才给商家钱，无法供餐不会先垫款。因此未取餐无法供餐取消时，线上原交易实收全退、到付仅取消和移除待收，不新增骑手垫款返还或取餐前垫款状态。此前“已垫款未取餐”假设撤下，不再作为待确认问题或实施分支。交餐后不走该未取异常取消；空跑补偿仍是另一个待定事项，不默认增加。
尚待确认：骑手无法配送、平台责任、取餐后的异常、商品质量等。 本条用户主动取消限制不等于所有异常均不得退款，其权限/阶段及相关现金/骑手收入处理另定，不用通用用户取消接口绕过。

用户已确认：生效后在允许单店售后的阶段部分取消，剩余子单不补差，保留原运费/折扣快照，不因三单变两单而换九折，也不因仅剩一单恢复原价；线上不再补款，到付剩余子单应收/给商家金额不追加差额，骑手账单仍按各单原折后运费基数。未生效仍仅整批取消；取消后重新下单按新的实际组合报价。

例：三家均合法参与、原运费各40、三单八折后每单32，生效后未接时用户取消C，A/B仍各32，C完整实收含运费全退；如果骑手已接，用户不能取消C。商家/平台异常若允许退出后的其他成员仍不补差，其退款事实独立记录，不转嫁。

用户取消的“已接申请取消、商家审核、退餐款保留运费”候选方案已撤下，不能列入执行任务。若后续异常售后确需部分退款，再明确金额/记录/渠道能力；未确认前不默认实现。容量释放遵守5.1，不能借异常退款立即释放已取餐仍待处置的容量。

退款按实际事实记录。已确认的普通用户取消为全额；如果异常售后最终纳入部分退款，不能直接沿用payStatus=2并宣称全退，金额/类型和展示须独立表达。此扩展仍待异常范围确认，不视为本轮已定需求。

LINE Pay

现有Online客户端使用v4；官方v4 Refund支持refundAmount，省略为全额。项目refundFull发空对象、每付款一条退款记录，可作为本次未接取消全退的基础，仍需接入批次取消、重复/迟到付款和未知结果对账。多次/部分退款不因旧稿默认保留运费而自动扩展；若异常售后确认需要，再追加金额、幂等业务号、累计对账和展示能力。

OMG 正式退款（用户已确认纳入）

官方退款/取消交易说明 DoAction 仅正式环境可用，按交易状态选择动作，且不能把“接受请求”与银行已退回混同：

已授权且全额取消：按可核验交易状态进行放弃授权。
要关账阶段全额取消：按官方流程取消关账再放弃；部分金额按可用的退刷流程处理。
已关账：按真实可退金额退刷。
分期仅支持全额退刷，一般授权可支持部分退刷；商家余额不足等会导致退刷失败；自动关账开启时官方指定时段不能调用。发布前核对门店实际开通的信用卡/Apple Pay 交易类型及状态，不假设所有支付类型都能部分退款。
当前 OmgPaymentRefundService 是测试环境拒绝边界。本功能新增独立的正式退款执行、交易状态查询/对账、持久记录、幂等重试/未知结果恢复/人工处理；不启用废弃蓝新代码，也不复制旧支付方案的未验证退款逻辑。
网关环境必须由服务端配置和凭证决定，不能由 App 参数切到正式环境。正式退款仅在明确启用的正式部署中允许；测试环境禁止调用正式 URL，取消/测试结果不能伪装为真实到账。
测试环境可验证组级取消与退款意图，但真实渠道调用标为不可执行，不无限重试。不建议在无真实退款能力的测试渠道上开放真实资金多店结算。
2026-10-13用户再次确认按现有测试环境不能执行真实退款的限制推进：本轮先做 mock/单测/状态转换与网络故障测试，测试环境验证取消及退款意图，不要求真实渠道退款联调作为本轮测试环境验收前提；该限制不阻断方案确认，但不能据此省略正式退款实现或把模拟结果作为真实退款成功。正式凭证/部署及可控小额交易经用户另行批准后联调。未真实联调前，不报告 OMG 正式退款已验证。

7 接口与实现落点（草案，非最终契约）

建议保留旧单店创建接口，新增多店预结算/批次创建/批次详情与取消入口，统一复用商家下单规则而非复制一套旧逻辑。具体路径在 contracts 阶段确定，不让前端现在据草案编码。

能力	输出/约束
多店预结算	首店锚点、同骑手本次参与店/圈外排除原因、即时/预约时段、参与店本批次可用方式（过滤转账）、原/折后运费、实付、报价版本；用户确认集合后提交
多店创建	批次/子单号、待收银状态、15分钟用户截止/缓冲快照/最终确认截止；不要求提前确定方式，不创建即开放，预约沿原规则
逐子单收银选择/到付确认	前15分钟选择本店可用方式，重验归属/批次/发起截止及凭证；线上真实收款核实才就绪，到付确认不扣款。缓冲禁止新的选择/发起/重试/换方式/到付确认，但允许合法既有线上尝试完成付款及确认；路径待contracts确定
批次详情/进度与用户列表	未选/部分付款/已付待整批生效/缓冲核实中均可见并恢复合法结算，展示真实付款与到付确认区别及截止；token校验归属，不能按payType空值漏单或将payStatus=1误标可履约。App只交付文档
子单支付	复用 LINE/OMG 真实支付入口，放行合法新批次成员，不接受客户端金额/商家凭证
未生效整批取消	原子关闭批次，返回各退款真实进度，不承诺调用完成即到账
合并配送接单	一次接组，返回所有子单；旧单笔接单不得拆组
子单取餐/送达	沿用普通单笔入口及状态/权限/幂等校验，独立操作、独立结算/通知；不强制取齐，不新增整组送达/结算入口；同步组汇总但不连带修改其他子单
平台配置	四语言合并配置、最大门店数、动态最少店数/折扣阶梯、服务端确认缓冲（分钟，默认5）及校验；说明原任务字典组计1单，不增加子单上限/另一套任务值，不追改已创建快照
平台跟进退款	各店退款状态与人工处理入口，只能查询/执行有权限的操作，不能手工假设渠道退款成功

业务编排和网关外呼继续放 ruoyi-admin；领域/Mapper/持久化放 ruoyi-system，依赖方向不反转。所有 DTO 明确声明，业务校验与错误国际化按 AGENTS；Java 加注释，平台与必要商家 PC 文案四语言。App 只交付接入文档，由前端人员实现。

数据库变更仅在后续实现时登记 updatesql/sql.md，本轮不编造已定 DDL、不运行迁移、不连接业务数据库。现有无关修改保持原状。

7.1 2026-10-13代码审查第4～9项：已确认接入

以下为已确认范围，不再列为待确认业务问题；字段/Mapper条件/接口签名在data-model/contracts统一，当前未写业务代码。

审查项	实施落点	约束与验收
4 通知	LinePayFactService、LinePayOrderNotificationService、OmgPaymentNotifyService、DeliveryOrderNotificationService及新批次到付确认	支付事实先保存，全部合法就绪后持久通知事件；预约等旧时点，提交后发送，组/独立单去重及失败重试。用户付款结果与履约通知分开，后续单笔通知仍独立；FR-036/SC-024
5 预约开放	UserOrderController预约初始化、DateUtil旧时间判断、PosOrder查询/更新及新增有效扫描入口	普通平台配送/新多店预约旧时点补扫、重启恢复、开放/通知幂等及并发；先设预约字段，新批次额外已生效，普通不套批次期限。禁复用TestTask，不新增最迟接单/自动取消，不回写历史已开放；FR-037/SC-025
6 用户列表	UserOrderController.orderList/applyTabFilter、UnifiedOrderQueryService、UnifiedOrderTab及批次详情	未选/部分付款/已付待生效/缓冲核实可见并恢复合法结算，真实已付与到付分开，不遗漏新批次Apple Pay；只改新批次分类，App只交文档；FR-038/SC-026
7 权威算价	新多店预结算/创建、OrderPromotionHelper及真实商品/规格/促销/原运费能力	不信客户端amount/freight/foodAmount及food价格，服务端查真实价格/归属/数量，计算优惠与折后实付；报价差异拒绝/重报不只警告，金额单位明确，支付/退款/到付/账单同快照；FR-039/SC-027
8 优惠券	新批次整批/合法子单取消、PromotionUserCouponServiceImpl及Coupon Mapper条件更新	只返取消成员券、原有效期不延长、过期不续期；原券/原子单绑定幂等及并发核销，迟到旧取消不释放新单券，返券不等于退款到账；FR-040/SC-028
9 归属	新批次/关联详情、进度、收银/取消及涉及新批次的getParentOrderDetail	token确定用户，校验父/子/组归属和关联，不能原样复用无userId过滤查询；商家/骑手限定现有授权，失败无款项/状态/返券副作用；FR-041/SC-029

兼容边界：明确批准普通平台配送预约补齐旧时点扫描，其他新期限/就绪/算价/返券只用于服务端标识的新批次；夜市自配送、自取不纳入扫描，普通价格/付款/取消等不全局改写。App只交接入文档，SQL后续只登记updatesql/sql.md供开发者手动执行。

8 必须讨论的业务确认表

以下区分已确认范围与剩余建议；OMG 正式退款以及即时/预约/到付范围已确认，不重复询问。

编号	问题	本版建议
Q1	每店独立选择与混用	已确认逐笔收银选择LINE/OMG/到付，线上成功或明确合法确认到付才就绪，最后成员就绪激活；不能创建时判全到付或默认生效。统一期限见Q6，转账见Q13
Q2	首店围栏及圈外店的结算边界	已确认首店A为圆心、默认1KM可配置；圈内A/B参与本次合并结算，圈外C不建本批子单、不计金额/折扣、不等待其付款。预结算明确排除原因、确认成员后提交；C保留购物车另结算为接入建议，不自动建单。撤回C同批及有C整批禁合并两种建议
Q3	折后运费及到付交付	已确认每店原40八折后32，商家给骑手32，不另补原价差额；到付给商家=该子单应付总额−该单折后运费，向用户代收该子单总额，配送毛收入为折后运费。佣金/税沿用原规则；逐店整数新台币舍入/不分尾差亦已确认见Q8，不重复询问
Q4	合并组与骑手容量	2026-10-13最新确认：撤回双层/子单总量限制，只沿用现有外卖/闪送/总任务字典，合并组算1单、普通单算1单，原字典值不自动改写；组门店上限默认5可配置。资格、任务上限及门店数同锁校验，部分完成仍计1任务，最后有效成员结束才释放；原任务字典异常回退1任务，不新增子单字典/字段/页面项
Q5	用户取消与异常处置	已确认未接可取消全退实收含运费、已接禁用户取消不审核；已接未取无法供餐由有权限商家取消本店，其他成员继续不补差。到付交餐才给钱不先垫，取消券按7.1返还；其余异常沿普通有效流程，不另建多店售后或默认空跑补偿
Q6	支付发起期限、完成/确认缓冲与迟到结果	最新已确认15分钟线上支付发起/到付确认期限＋默认5分钟平台可配置缓冲，创建固定两个截止/时长、重试不续时。截止前服务端已记录并实际发起的线上尝试可在缓冲完成用户认证、付款与确认，取代严格15分钟内完成付款的旧口径；缓冲禁新发起/重试/切换/到付确认。全部合法就绪立即生效，最终未就绪整批取消、真实实收全退含运费，取消后迟到实收退款不重开；不影响旧非多店，发起证据/真实收款/并发按4节适配验证
Q7	动态折扣阶梯、默认合并数量、城市区域配置、距离口径如何定？	已确认最少店数＋折扣动态增删改、最高满足门槛匹配、每店打折且不追溯旧单；默认最多5家可配置，首版全局规则、不分城市/区域。初始最少2家九折/最少3家八折已确认，4家七折仅后续扩展示例不默认启用；首店到后续店使用直线距离、范围默认1公里可配置亦已确认，城市/区域覆盖后续另行评估
Q8	部分取消是否补差？费用分摊/尾差如何舍入？	已确认每店原运费独立打折、HALF_UP到整数新台币，再相加得总运费，不做整批舍入/比例分摊/尾差转移；支付/退款/到付/毛配送收入取同一快照。生效后允许阶段部分取消不补差、不重算剩余成员；取消单本身退款见Q5。元/分与渠道单位在实现前核对，不改变原商品价/优惠规则
Q9	权威算价/快照与兼容	已确认创建服务端全量校验及真实商品/规格价格、优惠、原/折后运费和实付计算后固化快照；付款不复查普通菜单/营业变化，仍校验归属/状态/期限/方式/凭证。新批次取消券返还、原有效期和幂等已确认，不新增库存预占；普通单原规则不改，普通预约仅按Q12补扫
Q10	支付工具与最终退款规则是否匹配？	先沿用现有已支持LINE/OMG信用卡/Apple Pay工具，不新增分期等支付工具。用户普通取消现在只需未接全退，不再以“已接取消保留运费”强制要求部分退款或新增禁用；异常售后若确定部分退款再核对渠道能力。OMG正式退款仍已确认纳入
Q11	骑手什么时候看到配送组，取餐顺序与履约如何定？	已确认沿原外送：生效且达到预约开放时间后可抢单，接组后各店独立接单/出餐；独立取餐、独立送达，取餐顺序骑手自行决定。单笔结算/通知沿普通订单，不要求全组取齐，不新增整组送达/结算。组状态只汇总混合子单进度，最后有效成员结束才释放1任务；撤回全取齐后整组送达建议
Q12	延期新预约算法与本轮基本扫描	即时/预约不同组，预约日期/起止完全一致，合法同段多店保留。本轮已批准普通平台配送/新多店外卖预约旧时点持久扫描、重启补扫、开放幂等及通知重试；新批次额外须生效，普通单不套新期限。新语义/最迟接单/无人接单取消仍后续，不再把基本扫描延期
Q13	线下转账范围	已确认新多店批次不支持转账，原单店/历史订单及商家设置保持不变；各店按LINE/OMG/到付就绪集合选择。仅转账门店提交前明确提示不可参与，可另走原单店；不静默删店/自动拆单/擅自转到付，不新增核款/转账人工退款

原业务规则及本次第4～9项均已确认，不重复询问：全部合法就绪后幂等通知、普通平台配送/新多店预约按旧时点补扫、用户列表/继续结算、服务端权威算价、新批次取消券返还、详情/进度/操作归属。仅新预约语义/最迟接单/自动取消继续延期，普通其他异常沿原有效流程。下一步细化data-model/contracts及并发/测试映射供用户审阅，完整技术方案批准前不写执行tasks或业务代码，不把确认当作实现验证。

9 实现与验收顺序（范围确认后细化）

确认范围/分组/费用/容量/取消规则；补齐 data-model 和 contracts，由用户审阅。
完成首店围栏/参与集合报价及确认提交、支付方式过滤、参与店全量预检、权威算价、幂等父子单和服务端新批次标识/状态；验证圈外C不建单/不等待付款、夹带拒绝、转账边界、事务回滚、快照及越权。创建后菜单/普通营业变化不自动取消/重算；保留支付必要校验，回归现有非多店创建/付款/优惠促销/发票/通知等原行为。
完成收银/支付、15分钟发起/可配置缓冲/实际交易核实及生效；接入现有回调/查询/到付的批次通知闸门、持久幂等通知及普通平台配送/新批次预约旧时点扫描。验证部分付款无履约通知、14:14发起14:17完成合法、14:16新操作拒绝、预约按时开放/重启补扫/失败重试/取消竞争及普通兼容；新语义/最迟接单/自动取消不纳入。
完成未生效整批取消/超时、生效未接单店取消全退、已接用户拒绝及已接未取商家无法供餐取消，接入LINE/OMG退款并补新批次取消成员优惠券释放/返还。验证实收/未知/迟到事实、接组/取餐竞争、重复取消幂等返券、保留原有效期、已过期不续期、旧取消不释放新单用券、其他成员不受影响；测试环境真实退款限制按6节，不新增用户审核。
完成整组抢单、原字典任务统计按组去重及组任务释放、每组门店上限校验、沿普通订单独立出餐/取餐/送达/结算/通知、折后运费与混合付款现金/账单对齐、售后任务收口及关联信息权限；验证两骑手抢同组、拆抢、跨类型/组并发、任意取餐顺序、部分已送部分待取的混合进度、单笔幂等、组任务释放、到付交付及不重复收款。不实现已撤回子单上限或全组取齐/统一送达/整组结算流程。
完成用户原列表/统一列表中新批次分类和继续结算、批次/关联详情归属、平台配置、必要PC及App接入文档，再统一业务回归/模块构建。验证未选/已付待生效/缓冲核实/Apple Pay本批子单、其他用户父/子/组ID越权及商家/骑手授权边界，App不改源码；正式退款/真实支付联调另行批准。

OMG 实现按项目纪律将每个接口的代码、测试源码、规格与 SQL 作为完整批次；不反复确认已确定事项。此处并非启动新的 OMG 重做测试禁令；实际测试时机在执行任务阶段按用户要求确定。

Technical Context 与 Constitution Check

Java 21、Spring、MyBatis/MySQL、Redis/Redisson；前端 Vue/Element UI。
.specify 工作流有 specify/plan 审阅闸门。本轮按用户要求先输出规格与方案草稿；不运行会创建分支或自动提交的扩展脚本，不修改当前 .specify/feature.json（仍指向032，待进入本功能执行阶段再显式切换）。
constitution.md 仍为占位模板，不凭空填入项目治理规则；AGENTS 和用户最新确认优先。
无新技术栈/资金池/独立收款平台/自动派单优化；新表和字段只表达当前批次、配送组、规则快照与退款恢复所需状态。
tasks.md、data-model.md、contracts 和 App 接入文档将在确认后逐步产出；本轮未创建它们，避免把未定细节伪装为可直接执行的任务。

本轮记录

2026-10-12：现有代码与原文档已核对，新增036规格/方案草案；业务实现未开始。
2026-10-12：用户明确 OMG 正式退款纳入，保留测试环境不可真实退款的验证限制。
2026-10-12：完成一次只读可实施性检查，补充 Q9～Q11；其中“先骑手接组再商家接单/出餐”来自现有真实入口，保留不变，库存占用、工具限制和取餐次序仍待用户确认。
2026-10-12：用户确认预约配送、到付纳入，夜市自配送、自取沿用原流程。调整为独立批次生效状态建议，补充线上/到付准入与预约开放双条件，新增 Q12；业务实现仍未开始。
2026-10-12：用户指出商家支付方式独立配置；撤回统一渠道建议，补充逐店 payType 与混合付款生效、退款和到付待收金额建议；混用细则待确认，未改业务代码。
2026-10-12：用户确认 LINE/OMG/到付按店混用，新增 Q13 转账兼容建议；核对现有单店商家核款入口及管理端退款类型限制，补充生效前核款待办、人工退款和迟到转账补偿，待用户确认后进入实现。
2026-10-12（历史方案，已被2026-10-13简化规则取代）：用户当时确认双层容量方案；记录组占1任务/成员逐单计实际容量。额外子单总量上限/新字典及其验收已撤回，任务计数/同锁/组任务释放等仍有效；仅改文档，未写业务代码。
2026-10-12：用户确认Q3：各店给骑手折后运费32，到付给商家为子单总额减折后运费；补充金额方向、混合付款只代收到付单、账单运费基数和原钱包职责核对，更新规格及验收。业务实现未开始。
2026-10-12：用户要求预约时间调整后续单独处理；新增3.1后续记录，标记Q12/FR-014延期，调整本轮新增实施/验收范围，仍保留预约多店的原规则兼容。未写业务代码、未变更分支。
2026-10-12：用户确认Q13新多店批次不支持线下转账，原单店转账保持不变；撤下候选核款/人工退款扩展，更新支付上下文过滤、全店提交前校验、仅转账门店提示及旧流程回归。当前仅调整036规格和方案，业务实现未开始。
2026-10-12：用户确认Q2：圈外C不属于本次合并结算，不等待其支付。修正旧C同批及整批禁合并建议，补参与集合确认、创建防夹带、金额/折扣/付款隔离；C保留购物车另结算为接入建议。仅更新规格/方案，未改业务代码。
2026-10-12：用户确认生效后部分取消不补差，剩余子单保持原折后运费，线上/到付及账单不追加差额；Q5取消单自身退费及Q8分摊舍入仍待确认，不修改业务代码。
2026-10-12：用户确认Q5第一阶段：生效后骑手未接允许单店取消，完整实收含折后运费全退，到付未收仅取消；补取消与接组竞争、有效成员/组结束验收。已接/取餐后及责任例外仍待确认，未改业务代码。
2026-10-12：用户确认骑手已接不允许用户取消，不新增商家审核；同步Q5、入口拒绝及并发验收。撤下用户已接取消保留运费及由此默认必需的部分退款扩展，Q10改按最终异常范围评估；商家/平台异常仍待定，仅更新文档。
2026-10-12：用户确认商家无法供餐、该店未取时可取消本店并全退实收含运费，其他单继续不补差；补取餐竞争、有效站点/待收/容量/通知和全组收口，垫款/已付骑手运费/空跑费用另确认。仅更新规格/方案。
2026-10-12：用户澄清到付只有当面可交餐才给商家钱，无法供餐不先垫款；撤下此前资金异常假设及返款建议，不新增垫款状态/接口。更新现金流程及Q5，空跑补偿不因本次澄清视为已确定；未改业务代码。
2026-10-13：用户澄清逐笔收银才确定方式，确认所有新批次创建起15分钟内完成线上支付/到付确认才生效；撤回全到付创建开放/无截止前提。同步创建/收银职责、就绪与实收区分、统一期限/扫描、迟到补偿和接口/验收。仅更新036文档，未改代码/SQL/App、未建或切分支。
2026-10-13：用户确认动态折扣阶梯，新增最高满足门槛匹配、每店分别打折、配置校验、报价/订单快照和配置变更验收。未将4店七折示例或默认最多5店/城市覆盖视为已确认部署值；仅更新036规格/方案，未改业务代码。
2026-10-13：用户进一步确认首版默认最多合并5家、可配置，使用全局规则、暂不区分城市/区域；更新Q7及上限/容量验收，城市覆盖后续另评。骑手任务/实际子单容量部署值和初始折扣数值未随之批准；仅更新036文档，业务实现未开始。
2026-10-13：用户确认首版初始最少2家九折、最少3家八折两个动态档位；未增高档时3/4/5家八折，4家七折由平台后续自行新增、不默认启用。同步Q7及规格验收，仅更新文档，未改代码/SQL/App。
2026-10-13：用户确认每店原运费独立打折、四舍五入到整数新台币后加总，不另分摊尾差；确定HALF_UP，撤下先整批打折再比例分摊/补尾差建议，明确支付/退款/到付/骑手毛运费同一快照及实现前单位核对。新增规格验收，仅更新036文档，未改业务代码。
2026-10-13：用户确认简化容量，只用现有任务字典，合并组算1单、普通单算1单，每组默认最多5家；撤掉额外骑手子单总量上限/新字典/配置页面项及其大小关系校验。统一更新Q4、实现落点与验收，保留组任务释放、同锁并发、闪送加急独占和异常回退，不自动改字典值。仅改036规格/方案，未改业务代码/SQL/App。
2026-10-13：用户明确独立取餐、独立送达、取餐顺序骑手自行决定，进一步强调多店下单为配送费优惠，其余沿普通订单；撤回全部取齐后整组送达建议，Q11改为已确认。各单结算/通知不等待他单，组只汇总混合进度及任务释放；保留既定批次准入/超时取消/同骑手接组，不额外引入新履约/整组结算。仅更新036文档，未改业务代码。
2026-10-13：用户确认围栏按首店到各店直线距离、范围默认1公里可配置；即时与预约不能合并，新增预结算/创建的混组拒绝及配置变更验收。纯预约多店范围保留，不同预约时段同组及既定延期改造未因本次答复批准；仅更新036规格/方案，未改代码/SQL/App。
2026-10-13：用户确认创建时完整校验、创建后保留商品/价格/运费快照、付款不复查普通上下架和营业变化，明确要求不得影响现有非多店订单。Q9收口并撤回菜品/营业变化自动整批取消及库存预占候选，补服务端标识/旧流程分支隔离/必要支付保护/单店及历史兼容回归；实际无法供餐仍按既定子单规则。仅更新036文档，未改业务代码或SQL，兼容测试尚未执行。
2026-10-13：用户确认不同预约时段不得合并；同一骑手配送组的预约日期/开始/结束必须完全一致，不以时段重叠或同钟点跨日期判断可合并。更新Q12当前资格与拒绝验收，不变更既定延期的预约时间算法，也不改变非多店原流程；仅更新036规格/方案。
2026-10-13：用户明确15分钟内已付款需服务端响应缓冲，指定默认5分钟且可设置。统一更新用户截止/可配置缓冲/最终确认截止快照、待核实阶段、缓冲禁新操作、生效/取消/补偿及平台字段；撤回第15分钟立即关闭未知交易/按本地结果时间认定付款的建议。补官方时间字段及LINE分阶段证据/现有本地payTime差异，须后续定向适配，不影响旧非多店。仅更新036文档，未改代码/SQL/App、未执行支付测试。
2026-10-13：用户接受第2项建议，明确放宽为15分钟内发起线上支付/确认到付，服务端已记录并实际发起的线上尝试可在默认5分钟可配置缓冲内完成用户认证、付款及服务端确认；第15分钟后禁新发起/重试/切换/到付确认。同步正文、Q6和验收，撤回严格第15分钟前完成付款及仅后台响应缓冲口径；实收才就绪、最终未就绪取消退款、取消后不重开及非多店兼容不变。仅更新036文档，未改代码/SQL/App、未执行测试、未切换分支或提交推送。
2026-10-13：用户确认审查第4～9项，纳入全部就绪后幂等履约通知、普通平台配送/多店预约旧时点扫描与重启补扫、用户列表/继续结算、服务端权威算价、新批次取消券返还（原有效期/幂等）及详情/进度/操作归属。新增FR-036～041、SC-024～029及7.1映射，基本扫描不再延期；新预约语义/最迟接单/无人接单取消仍后续，其他普通规则不套新批次限制。仅更新036文档，未改代码/SQL/App、未执行测试、未创建/切换分支或提交推送。
未写业务代码、DDL，未运行 Maven、未修改 App，未创建/切换分支、未提交/推送。

plan.md 68 KB Riwayat Mentahan