spec.md 63 KB
同一用户多店结算与同骑手配送需求规格
Created: 2026-10-12
Feature Branch: 不创建新分支，沿用当前 test-202609v2；本轮不切换分支。
Status: Draft，供用户逐轮讨论；业务代码未开始。
Input: 用户提供《多店下单与骑手合并需求变更 (2).docx》，确认各店独立收款、在线批次全部子单付款完成后才开放履约，并要求纳入 OMG 正式退款、预约配送和到付；夜市自配送、自取沿用原流程。先给方案、确认细节后实现，可持续调整。
已确认与待确认的边界
已确认：
- 一次多店结算按店生成独立子订单，款项分别付给对应商家，不改为平台代收。
- 新批次创建时各子单待收银确认，不预先认定付款方式；线上须服务端确认支付成功，到付须用户选择并由服务端校验确认。全部成员就绪前，商家/骑手不能提前履约。
- 首版纳入即时配送、预约配送和到付；夜市自配送、自取沿用原流程，不加入本次多店批次规则。
- 新预约时间语义、最迟接单及无人接单自动取消仍留后续。2026-10-13用户确认本轮补充普通平台配送外卖和新多店外卖预约单的后续开放扫描，沿原有效开放时点，支持重启补扫、幂等开放与通知重试；新批次额外要求已生效，普通预约不套用多店期限。夜市自配送、自取不纳入。后续边界见plan.md「预约时间处理：后续独立事项」。
- 各商家可独立设置支付方式，多店不要求共同渠道；本功能仅开放各店已可用的LINE Pay、OMG和到付，不擅自改变商家设置。
- 同批可按店混用LINE Pay、OMG和到付，逐笔收银时选择；即使最终全部到付，也须逐单完成到付确认，不能创建即生效或因旧payStatus=1默认就绪。
- 全部新批次共用创建起15分钟支付发起/到付确认期限，支付下一店、重试/回页面不延长；支付完成与服务端确认缓冲默认5分钟、平台可配置，创建时固化时长和最终确认截止。第15分钟停止新的支付发起、重试、切换方式及到付确认；截止前服务端已记录并实际发起的线上支付尝试，允许在缓冲期继续完成用户认证、渠道付款和服务端确认。此口径经用户确认，取代严格要求第15分钟前完成付款的旧口径；并非第15分钟后仍可发起新交易。全部真实成员经服务端确认合法就绪立即生效，无需等满缓冲；最终确认截止仍未就绪整批取消，真实实收全退含运费、未收款到付只取消。已取消后迟到实收退款、不重开。
- 新多店批次不支持线下转账（payType=6），无论是否选择同骑手；原单店转账订单、入口和商家配置保持不变。本轮不新增转账核款/人工退款流程，不关闭全系统转账。
- 同骑手资格以用户选择的第一家店为圆心，按门店坐标计算首店到后续各店的直线距离，不按道路路线距离；范围默认1公里、在平台合并配置中可调整，不能在代码写死1公里。圈外店不进入本次合并结算父单/配送组，不创建其子单、不等待其支付、不计入合并折扣或本批次金额；A/B合并不受圈外C付款影响。
- 即时单与预约单不能进入同一合并配送组；预约单仅预约日期、开始时间和结束时间完全一致时才能同组，不因同用户/地址/围栏而放宽，仅时段重叠也不能合并。不同日期的同一钟点亦不合并；仍支持符合原有效规则的同一预约时段多店，预约时间处理改造仍按既定范围延期。
- 新多店批次创建时完整校验门店、商品、配送资格及金额，成功后固化商品/价格/折后运费快照；付款不因普通改价、上下架或停止接新单/营业时间变化重新算价、自动取消批次，仍可在15分钟内发起支付/确认到付，既有线上交易可在缓冲内完成。付款继续检查归属、订单/批次未取消未过期、方式及凭证可用；快照不是库存保证，实际不能出餐按此前确认的子单规则处理，不新增库存预占体系。
- 新批次准入/期限、权威算价快照及取消返券仅用于服务端明确标识的新多店批次，不全局改变普通单/历史单的付款、取消、优惠促销及发票规则。本次明确批准普通平台配送预约按原时点补充后续开放扫描，不引入新预约语义、批次15分钟限制或无人接单取消。夜市自配送、自取及其他旧流程不变，新标识缺失不能误判为未生效批次，共享入口不能全局移除原校验。
- 圈外店处理建议：预结算明确列出未纳入店及原因，用户确认本次参与集合后再提交；C保留购物车供另行结算，不自动另建订单、不静默丢掉购物车商品。购物车保留方案属于接入建议，App由前端人员实现。
- 骑手接单数量沿用现有外卖/闪送/总接单数字典：普通独立外卖单算1单，合并配送组整体算1单，不新增骑手实际子单总量上限、相关字典或配置项。同父单的独立配送订单不能合计为1单；闪送原计数与加急独占不变。此前双层容量/子单上限方案已撤回。
- 接组须在同一骑手锁内检查账号资格、现有任务上限和组内门店上限，再原子分配；部分完成/取消不按子单释放任务名额，组内全部有效子单履约结束才释放组任务。已取餐异常未处理结束时不得仅因进入售后而提前释放组任务。
- 多店下单目的为用户提供配送费优惠；除已确认的结算批次准入、同骑手整组接单/计数及收费规则外，其余履约沿用普通订单。各子单独立出餐、独立取餐、独立确认送达，取餐顺序由骑手自行决定，不强制选店顺序，不要求全部取齐才允许已取子单送达，不新增整组送达/结算流程。单笔履约仅作用于自身，不联动改变其他店订单；组状态只作汇总及任务释放，不能取代子单事实。
- 配送收入按每店折后实付运费计算：三店原运费各40、八折后每店32，商家不再另付原运费40、不另补折扣差额。到付子单给商家金额=子单应付总额−子单折后运费；向用户代收该子单总额，差额为该单配送费。佣金/税等既有规则仍按项目原流程，不把配送毛收入当作净收入。
- 配送费折扣采用平台可动态增删改的“最少店数＋折扣”阶梯，不写死固定档位；按实际参与合并的去重门店数，命中门槛不超过该店数的最高门槛档。首版初始配置已确认：最少2家九折（系数0.9）、最少3家八折（系数0.8），未配置更高档时3家及以上均八折。4家七折仅为以后可新增的示例，不在初始配置中启用。各店原配送费分别乘命中折扣；配置变更不改已创建订单，允许阶段的部分取消仍不补差。
- 首版最大合并门店数默认5家、可配置，使用全局规则，不按城市/区域设置差异配置。用户提交及骑手接组仍检查最大店数，接单同时受原任务字典控制；两者单位不同，不要求每组最大店数小于任务上限。城市/区域覆盖留待后续另行评估，不属于本轮实施。
- 各店原配送费独立乘命中折扣，按整数新台币四舍五入（HALF_UP）后固化；批次总运费为各店舍入后运费之和，不先把原运费总和打折舍入再分摊，不补齐尾差。示例41元八折为32.8元，实收配送费/商家给骑手毛运费均为33元；佣金/税仍按原规则另算。支付、退款、到付及账单统一使用该快照。
- 合并批次生效后，允许的部分取消不向剩余成员补差，即使仅剩一单也不恢复原价。用户主动取消仅允许骑手接单前，完整实收含运费全退；已接单后用户不能取消单店或整组，包括未取餐阶段，不新增商家取消审核。商家/平台异常另定；未生效仅整批取消，重下按新报价。
- 生效后骑手未接单的单店取消只作用于该子单，其他成员继续履约、不补差；未实收到付仅取消并移除待收目标，不生成网关退款。与整组接单并发时以事务内实际状态为准，取消成功的成员不能随后分配给骑手。
- 骑手已接、该店尚未取餐时，商家因缺货/无法供餐可取消本店子单，退该单全部实收含折后运费；其他店继续履约、不补差。到付现场能交餐才给商家钱，不能供餐不发生垫款：该取消只移除用户待收，不产生用户网关退款或骑手垫款返还流程；空跑是否补偿仍单独待定。
- 本业务不设计“无法供餐、尚未取餐但骑手已垫款”的常规场景，不新增取餐前垫款状态/返款入口。到付款项当面在交餐环节交付，已取餐不走未取餐无法供餐取消路径；用户已接禁取消规则不变。
- 可使用现有或新增字段控制开放；具体建议见 plan.md，尚未把字段选择当作用户已确认的决定。
- OMG 正式退款纳入本功能。2026-10-13用户再次确认按现有测试环境无法执行真实退款的边界处理：测试环境验证取消、退款意图及模拟流程，不要求完成真实渠道退款联调；不能据此省略正式退款实现，也不能在测试环境调用正式端点或把模拟结果标为真实退款成功。正式退款未联调的验证限制单独记录，不阻断方案确认和本地/测试环境流程验证。
- 本轮只编写规格和方案，不修改业务代码、不执行 SQL、不创建分支、不提交/推送。
- 不修改用户/骑手/商家 App 源码，提供前端接入文档；平台配置与必要 PC 页面属于后续拟议实现范围。
原需求文档提出、需要落实并讨论边界：
- 第一家店为围栏圆心，默认半径 1KM，可配置。
- 用户可选择同骑手；不合并或围栏外订单独立配送、独立计费。按用户最新澄清，圈外店不挂在本次合并结算批次内，另行结算，不等待其支付。
- 配送费按参与合并的各店原配送费之和打折；示例两单九折、三单以上八折，阶梯可配置。
- 原文合并数量建议值5～8、示例最多5单；2026-10-13用户确认首版默认最多5家且可配置，取代原未定默认值；使用全局规则，暂不做城市/区域覆盖。
- 分笔支付并显示进度，未生效时只能取消整批；最新规则为15分钟支付发起/到付确认期限，已有线上支付可在默认5分钟可配置缓冲内完成和核实。全到付不免期限；第15分钟后不能新发起支付，但已打开的合法渠道页面可继续完成付款。全部合法成员未就绪前不开放履约。
- 超时整批取消，已付款的逐笔原路退款；付清并生效后按正常售后处理。
- 原文提出单店售后取消不退配送费；最新确认覆盖用户主动取消规则：未接单实收全退含运费，已接单用户不得取消，不采用申请取消/商家审核，也不采用退餐款保留运费的用户取消路径。商家/平台异常仍待确认。
- 全部门店和商品提交前校验；订单详情显示关联订单。
User Scenarios & Testing
US1 同一用户多店预结算与创建（P1）
用户把不同门店商品加入同一次结算，服务端计算哪些店可合并、折扣和各子单金额，再统一提交。
Independent Test: 三家均符合资格的店一次提交，形成一个结算父单及三条子单；任一参与门店关闭、未审核、商品不可售或坐标无效时，不留下部分可支付订单。A/B圈内、C圈外时，本次确认提交仅A/B，C无子单/金额/付款等待。
Acceptance Scenarios:
- 第一家店 A 为锚点，其他店分别与 A 比较，而不是相邻店两两比较或不断延伸围栏。
- 重复门店不增加合并店数，也不能制造阶梯优惠；同店商品汇总为一条子单。
- 用户不选同骑手时，各店按原运费计费；选同骑手时，仅参与配送组的店铺享合并优惠。
- 服务端重新校验报价、商品/门店归属、地址归属和金额，不信任客户端传入的运费/折扣/合并资格。
- 相同用户、相同请求号的网络重试返回原批次，不重复建单或重复占用优惠券/库存。
- 创建前校验每个参与店至少有一种本批次支持且就绪的方式，不要求用户已选定。逐单收银选择时重验具体方式；到付只要求该店允许到付，不要求具备线上凭证；创建阶段不得默认选择到付。
- 预约配送校验所有参与门店在所选时段可营业、可配送；即时与预约不能同组，预约日期和起止时间不同也不能同组。预结算明确不兼容、创建拒绝混合，不静默改时间或自动拆组；同一日期/时段的合法预约多店仍支持。
- 按每店查询平台开关、商家选择和凭证就绪的可用方式，不取跨店交集；子单在逐笔收银确认时保存独立payType，创建时保留待确认语义，不能由父单唯一方式覆盖。
- 新批次可选方式为各店当前真实可用方式与本功能支持的LINE/OMG/到付的交集。仅支持转账或没有本功能就绪方式的店明确提示不能参加多店结算，用户可另走原单店流程；预结算和提交前均校验，不静默移除门店、不自动拆单、不擅自改成到付，不在已付部分后才发现无法支付。
- 预结算区分购物车候选集合、本次合并参与集合和不符合店铺清单。首店A/B圈内、C圈外时，仅A/B参与本批；创建接口若夹带C或成员与确认报价不一致，明确拒绝，不在提交事务里静默删C或自动另建C单。
- 删除首店或改变参与店、地址等会重算围栏资格和报价，重新确认成员；圈内可参与店不足2家时不形成多店同骑手组。
- A/B新批次创建后，A已付款而B普通改价/下架/停止接新单，B在期限内仍按已创建快照结算，不重新取当前菜单价格或自动取消A/B。已取消、过期、非本人或支付方式/凭证不可用的请求仍拒绝；商家真实不能供餐按既定子单操作处理。
US2 各店独立支付与批次统一生效（P1）
用户逐笔进入各店收银台，选择并完成线上支付或到付确认；就绪进度由服务端事实汇总，不需要创建时提前知道最终是否都是到付。
Independent Test: A/B为本次合并批次、C圈外未纳入：A付款后父批次仍未就绪；B也满足付款条件后仅生效一次，C未支付甚至未建单不阻断A/B。三家都参与的批次才等待三家条件全部满足。
Acceptance Scenarios:
- 支付单金额、门店凭证与该子单精确对应，不使用父单总额向任意一家商家收款。
- 已付款子单保留真实付款事实；父单未生效不等于所有子单未支付。
- App 关闭、用户跳过某笔或重复进入收银台不会丢失进度；前端回跳不能替代支付回调/查询验真。
- 父批次生效与取消互斥；重复回调、查询补单、服务重启不重复生效或重复通知。
- 支付发起截止后、最终确认截止前，仍未取消的批次允许截止前服务端已记录并实际发起的线上尝试继续完成和核实，全部合法成员就绪才生效；不得在该缓冲内新发起支付、重试、切换方式或确认到付。批次已关闭或最终确认截止后发现实收，只记录收款事实并退款，不重新开放履约。
- 未付齐时，用户仍可看到订单并继续支付，不能把订单从用户待付款列表隐藏。
- 每子单就绪条件为：已选择线上且可信付款成功，或已选择到付且服务端确认该选择合法；未选、支付失败/结果未知、仅客户端回跳均不就绪。到付确认不是实收，已付款数量和已就绪数量分别表达。
- 三单依次确认到付时，前两单就绪后仍不开放，第三单确认后才生效；用户离开而未确认最后一单，15分钟到期整批取消且无网关退款。创建时不自动生效。
US3 未付齐时整批取消与真实退款（P1）
未生效用户主动取消立即关闭整批；超时取消须区分15分钟支付发起/到付确认截止及最终确认截止。第15分钟停止用户新操作，既有线上尝试允许按默认5分钟可配置缓冲完成和核实；不能把结果未知当作未付款立即取消。最终确认截止仍未就绪关闭整批，已实收按对应商家原交易全额退款，到付只取消；确认交易已不可能满足全部就绪时可提前关闭，不把未收款全到付无限保留。
Independent Test: 三单中两单已付款，整批取消后两条退款分别进入各自渠道，一条未付款单取消；一个渠道退款失败不会影响另一笔退款完成，也不能把整批标为全部已退款。
Acceptance Scenarios:
- 未生效批次不支持单独删掉已提交子单后继续付其余单；修改购物车需先取消原批次。
- 取消与退款是两个事实：订单可以已取消而退款处理中；仅真实渠道证据允许标记已退款。
- 退款请求持久化，事务提交后由后台处理；退款超时、响应丢失先查询核实，不盲目重复退款。
- 持久扫描全部未生效批次的支付发起/到付确认截止及最终确认截止，包含尚未选择/待确认到付及支付待核实，重启/Redis事件丢失仍补处理。第15分钟只截止新操作，保留已记录并实际发起的线上尝试继续完成和核实；最终截止未就绪才取消并继续追踪迟到实收退款，不依赖App倒计时。
- 取消时逐子单对账；迟到付款、迟到回调、旧支付尝试仍有明确补偿，不把本地未支付当成绝不会扣款。
- LINE Pay 与 OMG 正式退款均纳入；OMG 测试环境明确返回不能执行，不伪造退款事实、不外呼正式 API。
US4 同一骑手一次承接配送组（P1）
批次生效且达到预约开放时间（即时单无时间等待）后，参与合并的子单形成一个不可拆抢的配送组，由同一骑手一次接下。
Independent Test: 两骑手并发抢组三单，只能一个骑手成功，三单全部归属该骑手；任一子单已变化则整体失败，不能只抢到一部分。
Acceptance Scenarios:
- 配送组必须属于同一用户、同一批次、同一收货地址；不能仅按 userId 拼接历史订单。
- 单笔接单接口不得绕过配送组规则，把组内单抢给另一个骑手。
- 服务端在现有骑手锁内检查账号、配送类型、急送独占、现有任务上限及合并门店数；接一个有N条有效待承接子单的配送组，仅增加1个外卖任务和1个跨类型总任务。N须满足组门店上限，不另外检查骑手子单总量上限；任一既有接单条件不满足则整组拒绝。
- 商家各自接单/出餐，骑手按自己的顺序逐单独立取餐、独立送达，沿用普通订单的对应阶段校验。A已取可送达，不因B仍未出餐/未取餐而阻断A；A未取不能因B已取而确认A送达。撤回“全部有效子单取齐后整组确认送达”建议。
- 各子单保留自己的履约、售后、账单及通知事实；A取餐或送达只更新A，不修改B/C，不把整组标为全部已取/已送达。重复单笔操作沿用现有幂等规则，不重复入账/收款/通知；组汇总随子单事实更新，不新增整组送达或结算操作。
- A/B合并组与另行结算的独立C是两个任务，C不在A/B父批次内；一般容量统计仍按组/独立单而非父号去重。未接单预约组不预占具体骑手容量，接组时才占用。
- 三单组完成或合法取消一条后，仍有有效成员需履约时组任务占1；最后一条有效成员履约结束才释放任务。已取餐异常在确认实际履约结束或交接处理前，组仍计入任务，不能因售后提前释放。
- 现有外卖/闪送/总任务字典缺失/非法均保守回退为1，指最多1个任务而非组内最多1家；每组门店上限由独立合并配置校验，合并配置缺失/非法时保守关闭合并，不增加子单上限兜底。
- 并发接组/普通外卖/闪送使用统一任务统计，避免闪送总容量仍按组内订单行数重复计数。外卖/总任务上限为1时并发抢两个三店组最多成功一个；均允许2任务且没有其他冲突时两个五店组可同时承接，不因子单合计10而另拒绝。
- 用户、商家和骑手读取同一份每店折后运费快照；到付给商家金额按该子单优惠后的应付总额减折后运费计算，不用商品原价或父批次总额代替。
US6 预约配送与到付批次（P1）
用户可以预约多店平台配送，也可以选择到付；到付不是在线付款成功，预约不是提交后立即抢单。
Independent Test: 预约批次在15分钟内发起各线上支付/确认到付，既有线上交易可在缓冲内完成和核实，全部就绪后仍等待原预约开放时间；即时全到付第三笔确认前不能被抢、全部确认后仅生效一次，缓冲不放宽到付确认期限，不造退款。
Acceptance Scenarios:
- 即时/预约、线上/到付均共用创建起15分钟支付发起/到付确认期限，不延长至预约日期；截止前已记录并实际发起的线上尝试可在默认5分钟可配置缓冲内完成及核实，缓冲不开放新的支付发起、重试、方式切换或到付确认。全部就绪生效后等待原预约开放，不再因结算倒计时取消。
- 到付子单须用户逐店选择且服务端合法确认，不在创建时默认就绪。所有到付确认完成才统一生效，不在第一条创建或首次确认时提前推送。
- 接单、商家处理、列表和通知共同检查批次生效及预约开放条件；仅改 isDisplay 不能防止直接接口提前接单。
- 本轮按用户本次确认补充旧时点下普通平台配送/新多店预约后续开放扫描、重启补扫、开放幂等及通知重试；新批次额外检查已生效，普通预约不套用新期限，通知不得提前或重复。基本扫描不再延期，不复用废弃TestTask；新预约语义、最迟接单及无人接单自动取消仍单独留后续。
- 到付取消不产生未实收款项的在线退款；实际线下收款、取餐和售后仍按现行到付流程处理，不把旧 payStatus=1 当作渠道实收证据。
- 已生效预约单无人接单的截止和自动取消延期单独处理；本轮不复用“未付齐付款超时”冒充预约到期处理，不声称已有此功能。
- 三店均参与、A选LINE/B选OMG/C选到付时，C须在15分钟内明确合法确认，A/B须在15分钟内由服务端记录并实际发起支付尝试，且在最终截止前完成真实付款核实；最后成员就绪才生效。C仅创建不算就绪，缓冲不放宽C确认期限；超时取消只退真实线上实收。
US5 平台规则与付清后售后（P2）
平台配置开关、范围、折扣阶梯、最大合并数量及支付完成/确认缓冲（分钟，默认5）；支付发起/到付确认期限仍为15分钟，能看到付款/待确认进度与退款状态。
Independent Test: 配置调整影响下一次报价，不追溯改已提交批次的收费快照；售后退款金额与实际退回商品款/配送费分项一致。
Acceptance Scenarios:
- 配置非法、缺失或不能形成合法报价时不得默认无限合并/随意优惠，合并功能保守关闭，单店正常下单不受影响。
- 已确认商家给骑手折后运费、到付给商家为子单总额减折后运费；首版全局配置、默认最多5家，超过上限明确拒绝，不静默拆组。各店运费独立打折并四舍五入到整数新台币，批次加总、不分摊尾差；城市/区域覆盖本轮不做。
- 付清后单店售后按确认的原因/阶段计算可退金额，不能把渠道全额退款作为保留运费的实现；退款取已固化的实际收款及运费，不重新用未舍入金额计算。
- 整组最终无法配送时不得无条件套用“单店取消不退运费”。
- 用户、骑手、商家只能查看自己有权访问的关联内容；商家不能看到其他店商品或支付凭证。
- 三家均参与合并、原运费各40、三单八折每家32；生效后C在允许的售后阶段取消，A/B仍各32，不转两单九折36、不各补4。线上不再拉起补款，到付剩余单待收金额及给商家金额不补差，账单运费基数不重算；取消C退多少另依Q5。
- 已生效组三单骑手未接时允许取消C，已线上实收132（示例餐费100、运费32）退132；未收款到付只取消。A/B继续待接且运费不变，组有效成员及任务展示同步更新；全部有效子单取消则结束组/父单汇总、停止抢单，不重复退款。
- 单店取消与整组接单并发只允许明确胜出的结果：取消先成功，接组不能包含被取消成员并须重验版本；接组先成功，用户取消请求拒绝，不修改订单、不建取消退款、不产生商家审核任务。
- 骑手接组后，无论商家尚未接单、已备餐或骑手未取/已取，用户均不能通过单笔、整组或普通取消申请入口绕过限制；商家不能供餐等异常和商品质量售后另定，不把用户禁止取消解释为平台不得处理任何异常。
- 已接组三单中C尚未被取餐且无法供餐，所属商家可按明确异常原因取消C，线上实收132退132含运费32，A/B继续由原骑手履约且各运费不变。同步通知骑手无需再去C取餐、更新有效站点/到付待收/容量；不重分配其他店、不默认整组取消。全部有效成员取消则组任务结束。
- 商家无法供餐取消与取餐并发重新检查该店取餐事实；取餐先成功不能继续按未取餐异常取消路径操作，转后续异常处置。重复取消不重复退款；商家仅能处理本店子单，不能修改其他店状态/付款。
- 平台无需改代码或重新部署即可增删改折扣阶梯；配置2家九折、3家八折后新增4家七折，2家命中九折、3家八折、4/5家七折（仍须满足最大合并店数）。重复店数门槛、非整数或小于2的门槛、非法折扣不能保存；圈外店不计数。配置修改只作用于新报价，已创建批次保持原快照，部分取消不重算档位。
Functional Requirements
- FR-001 使用现有父子订单表达一次结算；各子单各商家独立收款。
- FR-002 结算批次和配送组职责必须区分：普通不合并结算不创建组；同骑手结算父单仅含本次确认参与合并的店。购物车圈外店不挂入该父单，不允许“A/B组加C独立单”仍共用付款生效闸门。
- FR-003 同骑手资格、范围、参与店数、报价和总额均由服务端重新计算校验；首店到后续各店使用坐标直线距离，范围默认1公里、平台可配置，不按道路距离或写死1公里。范围须有效且大于0，缺失/非法沿合并配置保守关闭规则处理；提交重验规则/金额并固化快照。
- FR-004 所有本批成员共用创建起15分钟支付发起/到付确认期限；期限内服务端已记录并实际发起的线上尝试允许在已快照的缓冲内完成付款及核实，缓冲默认5分钟且平台可配置，不开放新的交易。全部合法成员就绪即生效，不预先区分全线上/全到付，不按创建或默认payStatus开放。认证或支付请求创建不等于实收，待核实阶段仍禁止履约，预约另满足原时间规则，列表/通知/操作共同校验。
- FR-005 保留子单付款事实；父批次是否生效不覆盖子单支付、退款事实。
- FR-006 父批次未生效时，主动取消/超时整批取消，已付款交易分别真实退款并独立跟踪。
- FR-007 付款完成、取消、到期、补单和迟到付款处理必须幂等，取消不得被后续付款重新激活。
- FR-008 同骑手组一次原子接单，不能拆抢；接单后商家各自接单/出餐，子单独立取餐和送达，取餐顺序骑手自行决定，其余履约沿用普通订单，不增加整组取齐/送达/结算流程。
- FR-009 支持 LINE Pay 与 OMG；OMG 正式退款必须实现且显式区分环境，未经批准不得用正式交易验证。
- FR-010 用户主动取消在未接单阶段按真实交易全额退款含运费，已接单不走用户取消退款；不以旧稿“商品款退、运费保留”默认要求部分退款扩展。异常售后如需部分退款须另确认，任何退款累计不得超实收、部分退款不得标成全额退款。
- FR-011 非适用单店/历史订单及夜市自配送、自取保持原流程；新多店到付和预约属于本功能，标识明确区分适用范围。唯一相关补齐为本次批准的普通平台配送预约按旧时点补扫，不套新批次期限。
- FR-012 按项目规范补注释、四语言、SQL 登记、测试和 App 接入文档；本轮仅讨论规格，不直接实现。
- FR-013 创建、选择方式、子单就绪、真实实收、批次生效和预约开放分别表达；到付确认参加结算期限但不算线上实收，未收款取消不产生虚构退款。旧单店到付创建约定不直接应用新批次。
- FR-014（后续独立事项） 新预约送达时段语义、重算开放/最迟接单及无人接单自动取消仍后续独立处理。本轮已确认补充旧开放时点下普通平台配送/新多店外卖预约的持久扫描、重启恢复、幂等开放与通知重试，见FR-037；不能继续将基本扫描列为延期，不复用废弃TestTask。
- FR-015 每店独立查询、选择、校验并保存支付方式；批次不要求共同渠道，允许LINE/OMG/到付按店混用，受当前平台/商家/凭证闸门共同约束。只在新批次上下文过滤转账，不改现有单店支付方式查询和商家设置。
- FR-016 新多店预结算、创建及后续换方式拒绝payType=6，原单店和历史转账仍走原流程；本轮不新增核款时限、待核款提醒、人工转账退款或补偿入口。仅转账门店提交前明确拒绝其参与本批，不擅自转到付/自动拆单/静默移除，也不关闭平台全局转账开关。
- FR-017 外卖任务按进行中的配送组去重加未分组独立订单计数，跨类型总任务为外卖任务加闪送任务；合并组整体算1单，不新增实际子单总量限制。不得按父批次去重或仅排除售后状态来释放已取餐、仍待履约/处置的组任务。
- FR-018 复用现有外卖/闪送/总任务字典及合并组最大门店配置。接组只检查外卖任务+1、总任务+1及组门店数；普通外卖增加1任务，闪送保持原计数和加急独占。撤下新子单上限字典、字段、页面管理及相关校验，不把门店上限当作骑手子单总量上限。
- FR-019 现有任务字典缺失/非法/读取异常回退1；合并配置缺失/非法时保守关闭合并报价。预结算/创建检查每组门店上限，接单在骑手锁内使用实时任务容量和门店上限再校验。配置降低不能强制取消骑手已接任务；待接组超出调整后的门店上限时须有明确不可接原因及平台跟进，不改收费快照。
- FR-020 每店折后实付运费同时作为商家给骑手的配送毛收入基数和现有骑手账单计算基数，不再按原运费向商家索取、不新增折扣补差。线上已收款子单由商家按现行方式给骑手折后运费；到付子单骑手给商家该单总额减折后运费，向用户代收该单总额。佣金和税沿用原规则，不能额外支付重复配送收入；原单店转账结算不在本功能中改写。
- FR-021 混合付款配送组分别列出各店给商家金额、商家给骑手运费、到付待收总额；只合计真实到付有效子单的待收金额，不将线上单加入代收。取消后的金额及已发生线下款项另跟踪，不仅靠组总额展示。
- FR-022 合并报价明确首店锚点、参与店及排除原因，提交校验用户已确认成员且各参与店位于首店圈内。付款进度、批次总额、折扣店数、生效和取消仅作用于该父单成员，圈外C另行结算，不自动创建或等待C付款。
- FR-023 生效后允许阶段的部分取消不追补剩余成员运费折扣，不重算阶梯、收费快照、剩余单商家给骑手运费或到付交付公式，不额外发起补款；仅更新有效履约/待收汇总和取消成员自身的退款/费用事实，不把取消单损失分摊给其他单。是否允许取消、取消单是否退运费与退款金额仍按另行确认的售后规则。
- FR-024 已生效批次骑手尚未接单时允许取消单个子单，完整实收金额含折后运费按原交易退款；未实收到付不虚构退款。剩余成员继续履约且不补差，取消同步组成员/版本、待抢可用性与待收汇总；全组取消结束任务。取消与接组串行/CAS校验实际分配状态，不能以过期列表当作未接单证据。
- FR-025 本功能用户取消按服务端骑手承接事实校验，已接组或其子单拒绝用户主动取消单店/整组，不因尚未取餐或商家尚未接单而放行，不新增申请取消或商家审核流程。现有UserOrderController.cancelOrder不能仅以state=0判定可取消；新批次须同时检查配送组分配事实、子单qsId和deliveryStatus，任一已有承接证据即拒绝。组/子单未承接条件必须参加事务内更新/CAS校验，不能只在读取后判断，避免检查后骑手接单仍被取消。拒绝请求无订单/组/容量/退款副作用；商家/平台异常处置不是此用户入口的绕过方式，其权限、原因和退款另行确认。当前仅确认和记录方案，不提前修改普通非多店订单行为。
- FR-026 骑手已接且该店未取餐时，有权限商家因无法供餐可取消本店子单，线上原交易全额退实收含运费；到付不能供餐时尚无当面垫款，仅移除待收，不新增返款分支。其他单继续不补差，取消同步组成员/站点、待收/容量及骑手通知；与取餐串行/CAS校验，已取不得走此路径。空跑是否补偿另定，不默认追加支付。
- FR-027 新批次创建只确认参与集合/报价和各店至少有一种就绪可用方式，不强制携带已选payType；逐单收银入口以用户、子单、所选方式及服务端闸门确认，不接受客户端已支付/已就绪标志。具体字段在data-model/contracts定义，保留旧单店接口兼容。
- FR-028 创建时固化支付发起/到付确认截止=创建起15分钟、缓冲时长及最终确认截止=前者+缓冲，配置改动/重试/逐店付款不延长既有批次。第15分钟停止新的支付发起/重试/换方式/到付确认，但允许合法既有线上尝试继续完成付款和核实，默认缓冲到第20分钟；最后合法成员就绪可立即生效。最终截止仍未就绪取消整批，未知支付继续对账/补偿，实收全退且取消后不可重开。核销、补单、生效和取消采用同一父批次并发规则。
- FR-029 平台动态维护最少店数与折扣阶梯，服务端按实际合并去重店数选择满足条件的最高门槛档，各店原配送费分别按该折扣计算，舍入按FR-031。门槛为不小于2的整数且不重复，折扣系数须大于0且不大于1；缺失/非法配置沿US5保守关闭合并报价。规则及命中档位随创建固化，配置修改或允许的部分取消不追溯重算。
- FR-030 首版规则使用全局配置，最大合并门店数默认5家且可配置，初始折扣档为最少2家0.9、最少3家0.8，不默认启用4家七折，不新增城市/区域覆盖规则。预结算、创建及接组检查有效店数上限，接单同时满足现有任务字典，不新增子单容量。不自动拆组或放宽缺失/非法配置；调整上限不直接取消已承接任务，待接组按FR-019处理。
- FR-031 折后配送费按每店原配送费乘折扣后HALF_UP到整数新台币，批次总运费直接相加各店已舍入运费，不做整批舍入/比例分摊/尾差转移。创建固化后支付、全额退款、到付交付、商家给骑手的毛运费及账单基数使用同一金额；佣金/税不改变此毛运费口径。本条只定义配送费折扣舍入，不额外改变商品/优惠金额或原单店规则；持久化/渠道金额单位在实现前明确转换，不盲按实体“分”注释换算。
- FR-032 多店履约以普通子单流程为准：独立出餐、取餐、送达、结算及通知，既有单笔入口仍逐单校验归属/状态/阶段/幂等；仅整组接单不得被单笔入口拆抢。骑手自行决定取餐顺序，不等待组内其他未取子单才允许已取子单送达；单笔操作不批量改变成员或重复结算。组/父单只汇总进度，不替代子单送达事实；全部有效履约结束才释放组任务。此前已确认的付款就绪/到期取消规则不因独立履约而撤回。
- FR-033 合并组不能混入即时单与预约单，预约成员的日期、开始时间和结束时间必须完全一致，不允许仅重叠或跨日期同钟点合并。预结算提示方式/时段不兼容，创建重新校验并拒绝不同成员时段，不静默改时间或拆组。比较服务端规范化的实际预约时间，不仅比显示文字；仍支持符合原有效规则的同一预约时段多店，不新增时间语义/最迟接单等延期功能。
- FR-034 新多店创建全量校验并固化商品/价格/运费等快照，后续付款不因普通菜单/营业变化重算或自动整批取消，仍校验所有必要付款条件、15分钟发起/到付确认截止及最终确认截止；不新增库存预占。必须以服务端新批次标识限定适用范围，现有非多店订单和其他非适用旧流程行为不变；共享支付/回调/查询/通知/取消扫描/履约入口只定向处理新批次，不全局放开多店支付或强加新期限/就绪条件。具体标识字段在data-model确定，未标识订单按原流程。
FR-035 平台合并配置页面维护支付完成与服务端确认缓冲时长，单位分钟，默认5，保存只接受正整数；缺失/非法/读取异常按5分钟安全回退，不能回退为无限等待。创建快照后不因改配置改变旧批次最终截止。发起资格以服务端持久记录的原支付尝试、实际发起事实及时间为准，不能用前端点击/回跳或事后补写时间证明期限内发起；收款须核实渠道真实交易、金额、币种、商家及签名/查询事实。LINE认证/确认/扣款按实际分阶段流程处理，认证成功不算实收；不再要求证明用户认证/扣款均在第15分钟前完成，不以本地记账时间冒充渠道付款时间。
FR-036 新批次付款事实先落库，逐单成功/到付确认不直接发履约新单通知；全部合法就绪后生效并持久记录开放事件。满足预约条件且提交后发送，合并组按组、独立单按子单幂等，失败可重试，取消终态不复活。用户支付结果通知保持真实事实，后续取餐/送达逐子单沿原流程。
FR-037 补充普通平台配送外卖及新多店预约的持久开放扫描，沿原时间判断/sys_appointorder_handletime，不新增最迟接单或自动取消。创建先设预约信息再判显示；扫描校验原开放时点、未取消未分配和原付款/履约资格，新批次额外已生效，普通单不检查批次期限。重启数据库补扫，开放状态与通知意图原子幂等并支持重试；直接接单不可绕过。自取/夜市自配送不纳入，不批量改写历史已开放单。
FR-038 用户原订单列表与统一列表识别新批次：未选、部分付款、全部未就绪或缓冲核实中保留可见进度/继续结算信息，不因payType空值漏单或payStatus=1误标可履约。真实已付与到付确认分开，生效后逐子单普通进度不被覆盖；覆盖本批LINE、OMG信用卡/Apple Pay及到付，旧非多店分类不全局改写，App只交付接入文档。
FR-039 新多店预结算/创建服务端读取真实门店商品/规格价格、数量与优惠规则，计算餐费、原/折后运费及实付并固化。拒绝跨店商品/规格、非法数量和报价/金额不一致，不能直接保存客户端amount/freight/foodAmount或仅警告放行。明确金额单位与渠道转换，逐店HALF_UP及支付/退款/到付/账单同快照不变，原普通算价不改。
FR-040 新批次整批或合法子单取消释放/返还对应取消成员占用/核销的券，不返仍履约成员的券。保留原有效期，仍有效恢复可用、过期不续期；原券/原子单绑定及状态参加并发幂等，重复取消/退款/扫描不重复返券，旧取消不得释放已由新单使用的券。创建同一券不能并发重复使用，返券不是渠道退款成功；普通非多店券规则不改。
FR-041 新批次详情、付款进度、关联订单、支付/取消按token确定用户并校验父/子/组归属及关联，不能仅凭传入ID返回信息或操作；现有getParentOrderDetail涉及新批次不得原样复用无用户过滤查询。商家仅访问授权子单，骑手沿现有待抢/本人承接权限，不放宽其他商家或用户敏感信息。未授权无款项/状态/退款/返券副作用。
Key Entities
- 结算批次：复用OrderParent；成员、创建起15分钟用户操作截止、确认缓冲时长快照/最终确认截止、逐单已就绪/实收及待核实进度、预约信息、收费快照及生效/取消状态。新批次均有用户截止，不设全到付例外；缓冲到期不是已生效预约任务取消时间。
- 门店子单：复用PosOrder；门店、待选/逐单所选payType、收银就绪事实、商品/运费快照、实际交易与独立履约状态。就绪的到付仍不是实收。
- 配送组：参与同骑手配送的子单集合；不是收款账户或跨商家支付交易。
- 骑手接单容量：任务按配送组/独立外卖单及闪送任务统计，沿用现有三个接单字典，异常回退1；合并门店数独立校验。不新增骑手子单上限字典、字段或容量实体。
- 支付与退款事实：各子单自己的门店凭证/交易/退款金额及状态；复用或扩展当前有效 LINE、OMG 机制，不启用废弃支付代码。
Edge Cases
- 第一家店被删除：重算锚点和全部资格，不保留旧折扣。
- 围栏内外混合：圈外店不参与本次合并结算，不自动创建独立单；每组默认最多5家且可配置，超额拒绝、不静默拆组。即时与预约不得同组，预约日期/起止不一致亦不得同组，不按时段交集放行。LINE/OMG/到付混用已确认，夜市自配送、自取不混入新批次。
- 最后一笔在第15分钟前由服务端记录并实际发起、缓冲期内完成付款/核实：全部成员合法就绪且批次未取消时统一生效，第15分钟不立即关闭合法在途批次；仅有请求/LINE认证不等于实收。第15分钟后新发起或重试拒绝。超过最终截止或已主动取消后发现成功款记事实并退款，不复活；缓冲配置后改不影响该批次。
- 新多店在部分结算后普通改价/下架/停止接新单：保留已创建快照，不按菜单/营业变化自动取消，付款仍核实合法状态/期限/方式/凭证。实际不能出餐按既定子单规则，不借快照保证不存在的库存或新建库存预占；非多店订单保留原行为。
- 一店拒单、取件前后单店取消、整组仅剩一店、整组无可配送单：费用、容量释放与骑手通知需闭环。
- 退款受渠道状态、商家余额、禁止调用时段或结果不明影响：持续显示真实处理中/人工处理，不承诺已到账。
Success Criteria
- SC-001 在并发线上回调/查询、到付确认、取消/扫描下，尚有子单未就绪、已取消或预约尚未开放的批次无一条子单提前履约，不把默认到付当作已确认。
- SC-002 重试同一提交、付款回调和接单请求不产生重复批次、重复支付核销或分裂骑手归属。
- SC-003 批次收费等于子单收费合计；总运费等于各店独立打折并舍入后的运费之和，不再按总额打折分摊尾差，所有退款累计不超过实收。
- SC-004 服务重启后到期取消和退款可以恢复，失败可追踪且不影响其他子单退款。
- SC-005 普通及非适用历史订单回归覆盖创建、原营业/价格/促销/优惠券/发票、LINE/OMG/到付/转账、取消及履约/通知；新标识为空不被新批次期限/就绪条件拦截或取消，自取/自配送不变。普通平台配送预约仅按SC-025补齐旧时点后续开放，不引入新时间语义或自动取消。
- SC-006 OMG 正式退款发布前完成批准的小额交易联调；模拟测试通过不能代替真实联调通过。
- SC-007 即时到付、预约到付及预约线上验证批次生效与旧预约开放时点兼容，未实收到付不造退款。本轮包括基本开放扫描/重启恢复，详见SC-025；新预约语义、最迟接单与无人接单自动取消仍留后续，不宣称本轮完成。
- SC-008 验证三店/五店合并组均只算1任务、独立单各算1任务、外卖闪送总任务及加急独占，普通单/组/闪送并发不超过原字典任务上限。上限1时两组仅一组成功，上限2且其他条件满足时两个五店组可接，不另按子单合计拒绝；部分完成/取消不提前释放组任务，已取售后继续占用，字典异常回退1任务而非1家店。
- SC-009 餐费100/折后运费32的到付子单应收用户132、给商家100、配送毛收入32；三单均到付合计396/300/96，混合付款只累计到付单待收。用户收费、现金交付、账单运费基数均取同一快照，不能重复收取线上已付款或重复支付配送收入。
- SC-010 新批次对仅转账门店明确提示，对伪造payType=6的创建/换方式请求拒绝；提交前全店检查，不留下部分已创建可支付子单。原单店转账下单、商家核款、现有查询及历史订单回归不受影响，不改变商家配置。
- SC-011 A/B圈内、C圈外时仅确认A/B创建父单和配送组；C无本批子单、金额、折扣计数、付款等待或退款。A/B条件满足即生效，夹带C提交拒绝，删除锚点后重算，不用相邻店链式扩圈。
- SC-012 三单均参与且已生效、每单折后运费32时，允许售后取消一单后剩余两单仍32，再只剩一单也仍32；线上无补款、到付剩余单不追加差额、账单基数不恢复原价。取消单自身退款独立，不以不补差冒充允许取消或免除该单应付费用。
- SC-013 生效后未接组三单取消C：线上实收132原交易退款132含32运费，到付未收无退款；A/B继续待接不补差，C不能被分配。并发接组先胜时拒绝未接单取消路径；取消全部成员时任务结束，退款幂等并保持真实进度。
- SC-014 已接组在未备餐、备餐、未取/已取阶段，用户单笔/整组及直接接口取消均拒绝，无状态更新、容量释放、退款或审核任务；特别覆盖state=0但deliveryStatus=1且qsId已分配的商家未接场景，以及组已承接但子单字段异常不一致时保守拒绝。接组与用户取消并发仍无“已承接却按未接全退”，校验后发生承接必须使取消CAS失败。旧非适用单据原流程保持不变。
- SC-015 已接组C无法供餐且未取，商家只取消C、真实线上132全退含32运费；A/B仍由原骑手履约不补差，待收/站点/容量及通知一致；到付未收不造网关退款。取餐先成功拒绝此取消路径，重复请求不重复退款、商家无越权，全组有效成员皆取消则任务结束。
- SC-016 全到付/全线上/混合/未选共用15分钟发起/到付确认截止；创建/部分到付确认不生效，缓冲不开放新支付发起/重试/换方式/到付确认。默认5分钟缓冲允许截止前已记录并实际发起的线上尝试完成和核实，最后合法成员就绪只激活一次；最终截止未就绪实收全退，无收款到付不造退款。主动取消后/最终截止后发现线上成功退款不重开；生效后不再按结算未完成取消。
- SC-017 验证动态增加/修改/删除档位、最高门槛匹配、不同原运费分别打折、去重/圈外店不计数、重复门槛及非法系数拒绝。新增4家七折仅影响新报价；已有4家八折订单不重算，部分取消不补差；提交重验报价防止混用配置版本。
- SC-018 首版不同城市使用同一套全局规则，初始2家九折、3/4/5家八折且无4家七折档；合法配置默认5家时5家可进入后续资格/任务容量校验、6家不能合并，不静默拆组。修改最大店数后预结算/创建/接组重验，上限调整不强制取消已接组；现有字典缺失回退1任务仍可承接一个合法五店组，不误计为5个任务，不新增子单容量配置。
- SC-019 验证每店舍入方向和单位：41元八折32.8元取33元，45元九折40.5元取41元；三店原运费均41元、八折时各33元，总运费99元，不能按总额123元八折98.4元另舍入为98元。支付/退款/到付/骑手毛运费及账单基数一致，配置变化或允许取消不重算剩余金额，不产生跨店尾差。
- SC-020 验证骑手不按选店顺序取餐、A送达时B仍待取餐、A已送/B配送中/C合法取消等混合进度；每次操作只影响对应子单，未取子单不能送达，不强制全部取齐/整组送达。A完成触发自己的普通账单/通知且重试不重复，其他单继续原流程；剩余有效成员未结束时组任务仍占1，最后有效成员结束才释放。普通非合并订单流程不被改变。
- SC-021 验证范围配置及距离口径：默认1公里时首店直线0.9公里可进入其他资格校验、1.1公里排除，不能因道路绕行超过1公里而排除直线圈内店；改为2公里后新报价按2公里，不写死1公里，已有收费快照不追改。预结算/创建均拒绝即时与预约混组、同日18:00–18:30与19:00–19:30、同日18:00–18:30与18:15–18:45、不同日期同一时段，不静默改时间/拆组；合法纯即时组及同一日期/起止时间的合法预约组不被误禁用。
- SC-022 验证新批次创建后改价/上下架/停止接新单/普通营业时间变化时，期限内支付仍取原商品及金额快照，已付其他店不被自动取消；归属不符、取消、超时、支付方式/凭证不可用仍拦截。旧非多店订单的价格、支付、取消等规则保持不变；普通平台配送预约仅按SC-025补齐旧时点开放扫描，不能因同样挂父单而套用新批次规则；旧支付限制不被统一删除，只有合法新批次成员可定向放行。
SC-023 14:00创建、默认发起/到付确认截止14:15及最终确认截止14:20；14:14由服务端记录并实际发起、14:17真实付款并核实且其余成员合法就绪可生效。14:16新发起/重试/切换方式/确认到付拒绝；仅前端声称14:14已发起、伪造时间、只有请求或认证成功均不能当作实收就绪。最终截止仍未知则取消并持续核查迟到实收退款。验证缓冲配置5改8只影响新批次、非法回退5、回调/查询/扫描竞争、重复核销、LINE分阶段及非多店无新增期限。
SC-024 A已付/B未付或未选不推履约新单且不可抢，全部合法就绪即时开放一次、预约未到不推。重复回调/查询/到付不重复事件，事务回滚不发送；失败可重试、取消后不复活，单笔送达通知不等其他单。
SC-025 旧配置提前60分钟、预约18:00–18:30时17:00前不开放、17:00后原普通合法平台配送预约可开放；新批次未生效仍不开放，随后生效才开放。停机跨时点后补扫，重复扫描不重复开放/生成通知，取消/接单竞争不复活；普通单不套批次15分钟条件，自取/自配送不纳入，新语义/最迟接单/自动取消不视为已实现。
SC-026 新批次未选、A已付/B未付、混合到付、Apple Pay未付及缓冲核实中可查进度并恢复合法结算；批次未就绪时已付子单不能误标可履约，到付不标实收，生效后逐单普通进度不被组覆盖；旧非多店分类回归不变。
SC-027 篡改amount/freight/foodAmount、跨店商品/规格、非法数量不能改变收费；提交报价差异拒绝/重报价而非仅警告。服务端快照与渠道/退款/到付/账单一致，创建后改价仍按旧快照，原单店算价不改。
SC-028 未生效整批取消返对应券、生效取消C只返C券；重复取消/退款/扫描只返一次，仍有效可用、过期不续期。并发创建同一券不能重复核销，旧取消回调不释放新单所用券；返券不伪造退款成功，普通单券规则不改。
SC-029 用户A传B父单号/子单ID/组ID或伪造关联/标识，不能看B详情/进度或支付/取消，失败无状态/款项/返券副作用；本人合法查询正常，商家/骑手仅现有授权范围，不因关联组暴露其他敏感数据。
待讨论事项
见 plan.md 的Q1～Q13确认表。范围、付款/15分钟支付发起及到付确认期限、既有线上交易可在默认5分钟可配置缓冲内完成和核实、直线围栏/可配置范围、费用、原字典按组计1单且不增子单上限、全局/初始折扣、逐店整数新台币舍入、不补差、取消/快照/非多店兼容均已确认；即时预约不混合、同组预约日期/起止一致、独立取餐/送达及骑手自行决定顺序亦已确认。其他普通优惠/履约/异常沿原有效流程，原能力缺口另反馈，不额外设计多店规则；预约时间算法延期，原任务字典不自动改写。支付尝试发起证据、真实收款核实、分阶段与并发适配仍须在data-model/contracts落实并验证，不能把业务参数确认描述成接口已实现；完整方案批准前不写执行tasks或业务代码。
2026-10-13最新补充：用户接受Q6口径放宽为15分钟内发起线上支付/确认到付，截止前已记录并实际发起的线上交易可在默认5分钟可配置缓冲内完成付款和服务端确认；取代严格要求第15分钟前完成付款/认证的旧建议。缓冲期禁止新发起、重试、方式切换及新的到付确认，既有渠道页面可能在第15分钟后完成付款，不再描述成仅后台响应缓冲。全部合法就绪立即生效，最终截止未就绪取消及实收退款；全到付不免期限，取消后不重开。已确认业务参数不重复询问，后续整理完整技术方案供审阅。
变更记录
- 2026-10-12：用户明确预约配送、到付纳入首版；夜市自配送、自取沿用原流程。补充到付生效与预约开放的独立规则，尚未实现。
- 2026-10-12：用户指出各商家支付方式可能不同；取消共同支付方式的前提，改为逐店选择/校验，补充线上渠道及到付混合的生效建议，混用细则待确认。
- 2026-10-12：用户确认 LINE/OMG/到付按店混用并询问转账兼容；记录已确认混用，补充待确认的转账核款、待办例外、人工退款及迟到收款方案，尚未实现。
- 2026-10-12（历史方案，已被2026-10-13简化规则取代）：用户当时确认双层骑手容量，替换原“合并三单占三个任务”建议；一组占1任务、组内子单独立计数。额外子单上限及其验收现已撤回，仅保留任务计数/释放等仍有效规则。
- 2026-10-12：用户确认三店原运费各40八折后每店32，商家给骑手折后运费；到付给商家为子单应付总额减运费。更新Q3及现金/账单一致验收，未改业务代码。
- 2026-10-12：用户要求预约时间调整后续单独处理；标记FR-014/Q12为后续事项，保留本轮预约兼容，不把送达语义、倒推时刻、开放补偿和预约无人接单自动取消列为本轮新增功能。仅记录，未改业务代码。
- 2026-10-12：用户确认Q13采用“新多店批次不支持线下转账，原单店转账保持不变”；撤下候选核款/人工转账退款扩展，补充上下文支付过滤、仅转账门店提示、提交前校验和旧流程回归。业务实现未开始。
- 2026-10-12：用户明确圈外C不参与本次合并结算，也不等待C付款；撤回“A/B合并+C同批独立配送”和“有C整批禁止合并”建议。记录首店围栏、明确参与集合及提交防夹带、付款/金额隔离验收；建议C保留购物车另结算，未改App或业务代码。
- 2026-10-12：用户确认生效后部分取消不补差价；固化剩余子单原运费/折扣，不向线上或到付单追加差额。取消单本身能否取消/退运费仍待Q5，Q8金额舍入仍待定；仅更新规格/方案。
- 2026-10-12：用户确认已生效批次骑手未接单时允许单店取消，完整实收含折后运费全退；未实收到付仅取消。补组成员收口和取消/接组竞争验收，已接单规则仍未确认；仅更新文档。
- 2026-10-12：用户明确骑手已接后不给用户取消、不做商家审核。新增已接拒绝及无副作用验收，撤下用户主动取消保留运费/部分退款的默认前提；异常售后范围仍待确认。未改业务代码。
- 2026-10-12：用户确认已接但该店未取、商家无法供餐可取消本店，完整实收含运费全退；其他单继续不补差。补商家归属、与取餐竞争、有效站点/待收/容量/通知及全组收口验收，骑手已发生款项和空跑费用另定。仅更新文档。
- 2026-10-12：用户明确到付当面能交餐才给商家钱，无法供餐不会先垫款；撤下“未取餐但已垫款”假设及返款分支，普通取餐流程不新增垫款状态/退款入口。保留线上全退、到付仅取消、其他成员继续及既有接单/取餐限制。仅更新文档。
- 2026-10-13：用户明确最后逐笔收银才知道方式组合，并确认全部新批次创建起15分钟内完成线上支付或到付确认才生效；超时未完成整批取消，实收全退，到付不造退款。撤回全到付创建生效/无期限假设，更新创建/确认职责、并发和验收；未改业务代码。
- 2026-10-13：用户确认动态“最少店数＋折扣”阶梯，按最高满足门槛匹配、各店分别打折，配置不追溯已创建订单且取消不补差。4店七折为扩展示例，不视为上线默认值；最大合并店数/城市覆盖仍待确认。仅更新规格/方案，业务实现未开始。
- 2026-10-13：用户进一步确认首版默认最多合并5家且可配置，规则全局生效、暂不按城市/区域区分；同步边界、上限与容量共同校验及验收，取代此前待确认项。未确认其他骑手容量默认数值及初始折扣，未改业务代码。
- 2026-10-13：用户确认初始折扣为2家九折、3家及以上八折；记录两个动态档位的门槛/系数，4家七折仅后续扩展示例、不默认启用。更新初始规则与验收，业务实现未开始。
- 2026-10-13：用户确认每家运费独立打折、HALF_UP到整数新台币后加总，不另分摊尾差；支付、退款、到付及商家给骑手毛运费取同一快照。撤下整批打折后比例分摊/补齐尾差建议，新增单位/舍入/对账验收；仅更新文档，未改业务代码。
- 2026-10-13：用户确认简化骑手容量：现有外卖/闪送/总任务字典继续控制接单数，合并组算1单、普通单算1单，每组最多5家由合并配置控制；撤回额外子单总量上限/新字典/页面及相关验收。部分完成仍不提前释放组任务，保留同锁并发/急送独占/异常回退。仅更新036文档，未改业务代码或数据库配置。
- 2026-10-13：用户明确独立取餐/独立送达、取餐顺序骑手自行决定，进一步明确多店下单目的为配送费优惠，其余沿普通订单流程。撤回全部取齐后整组送达建议，不新增整组送达/结算操作；保留此前确认的批次支付准入、超时取消、同骑手接组及组计1任务。同步独立履约/混合进度/单笔幂等验收，仅更新文档。
- 2026-10-13：用户确认合并范围使用直线距离、范围可配置（默认1公里），即时单与预约单不能合并；同步服务端校验、参数变更/道路绕行及混组拒绝验收。未把此答复扩展为取消预约多店或批准不同预约时段混合；其他未定事项保留。仅更新036文档，未改业务代码。
- 2026-10-13：用户确认新多店创建完整校验/创建后保留快照/付款不复查普通上下架及营业变化，要求不影响现有非多店订单。撤回按普通菜单/营业变化取消未生效整批的候选建议，保留必要支付校验及既定子单无法供餐处理；明确服务端适用标识、旧流程隔离和完整兼容回归，不新增库存体系。仅更新036文档，未改业务代码。
- 2026-10-13：用户明确不同预约时段不能合并，因订单交给同一骑手；收口为预约日期及起止时间完全一致才同组，仅重叠/跨日期同钟点不合并。同步FR-033及预结算/创建验收，当前时段资格已确认，不启动既定延期预约时间改造；仅更新036文档。
- 2026-10-13：用户要求15分钟内已付款应留服务端确认缓冲，并指定默认5分钟、平台可配置；拆分用户操作截止/缓冲/最终确认截止快照，缓冲只核实既有交易，全部就绪即生效、最终未就绪取消退款。替换第15分钟立即取消的旧建议，补渠道付款时间、LINE分阶段、配置变更与非多店隔离验收。仅更新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、未执行测试、未创建/切换分支或提交推送。