|
|
@@ -299,15 +299,15 @@
|
|
|
- FR-078（2026-09-09 入参调整）：确认修改地址与追加小费使用 POST /orders/address 和 POST /orders/tip；订单 ID 通过 JSON 请求体 orderId 传入，必须是有效正整数，token 仍放请求头。
|
|
|
## 2026-09-14：闪送多取货点（多取一送，2026-09-15 修订）
|
|
|
|
|
|
-本节按 2026-09-15 用户确认的方式 2 更新：默认按用户顺序引导，取得下单人同意后允许调整实际取件顺序；替换此前无条件自由取件的规则。2026-09-15 已落实后端接口与平台 PC；用户/骑手 App 接入和真实数据库联调仍待执行，验证范围见 validation.md。单笔订单包含 1 至 N 个取货点和 1 个收货点，每个取货点独立关联联系人和物品信息。用户填写顺序用于初始路线报价、展示和默认取件引导；调整实际取件顺序须遵守 FR-094 至 FR-098。按整条路线距离计价，不新增每取货点附加费；点间不设单独距离限制，整条报价路线仍不得超过 40 公里。
|
|
|
+本节历史规则于 2026-10-15 修订：新旧订单均由骑手自主决定实际取送顺序，按站 ID 直接确认，无须先选择目标或取得同意。单笔旧契约订单包含 1 至 N 个取货点和 1 个收货点，每个取货点独立关联联系人和物品信息。用户填写顺序用于初始路线报价、展示和默认导航提示，不限制履约顺序。按整条路线距离计价，不新增每取货点附加费；点间不设单独距离限制，整条报价路线仍不得超过 40 公里。
|
|
|
|
|
|
### 用户故事 8：用户发布多取货点订单并由骑手逐点取件（优先级：P1）
|
|
|
|
|
|
-用户逐站填写联系人、地址和物品，填写唯一收货点后获取整条路线报价；骑手接单后默认按用户顺序前往未取货站点，需要调整时先与下单人沟通、取得同意并保存调整记录，再逐站确认取件并上传凭证，全部取货点完成后订单进入已取件，送达流程不变。
|
|
|
+用户逐站填写联系人、地址和物品，填写唯一收货点后获取整条路线报价；骑手接单后可自主选择未完成取货站，直接按站 ID 确认并上传凭证，全部取货点完成后订单进入已取件，送达流程不变。
|
|
|
|
|
|
**优先级原因**：每站独立物品和凭证用于履约核对与纠纷定位。
|
|
|
|
|
|
-**独立测试**：验证每站物品独立、按用户顺序报价和默认引导、沟通同意后调整并记录骑手声明、前往与取件分离、单点可省略 stopId、多点必传 stopId、重试不推进其他站点、取件与用户取消互斥，以及全部取货点完成时仅推进一次主状态。
|
|
|
+**独立测试**：验证每站物品独立、按用户顺序报价、非默认站直接确认、单点可省略 stopId、多点必传 stopId、重试不推进其他站点、取件与用户取消互斥，以及全部取货点完成时仅推进一次主状态。
|
|
|
|
|
|
**验收场景**：
|
|
|
|
|
|
@@ -315,7 +315,7 @@
|
|
|
2. **假如** 数量超过字典有效上限，**当** 报价、创建或修改取货点，**那么** 返回国际化错误；字典缺失或非法时有效上限为 1。
|
|
|
3. **假如** 取货点数量上限为 1，**当** 报价、创建或编辑提交多于一个取货点，**那么** 拒绝；既有订单履约及仅追加小费不受上限调整影响。
|
|
|
4. **假如** 订单只有一个取货点，**当** 骑手不传 stopId，**那么** 定位唯一取货点；多点订单未传 stopId 必须拒绝，不自动选择未取货站点。
|
|
|
-5. **假如** 用户顺序为 A → B → C 且均未取件，**当** 骑手查看订单，**那么** 默认突出显示前往 A；骑手取得下单人同意、填写原因并声明已取得同意，保存先前往 B 的调整记录后，可以实际到 B 取货并上传凭证确认；主状态保持 ACCEPTED，全部取货点完成后才进入 PICKED_UP。
|
|
|
+5. **假如** 用户顺序为 A → B → C 且均未取件，**当** 骑手先到 B，**那么** 可直接提交 B 的站点 ID 和取件凭证；主状态保持 ACCEPTED，全部取货点完成后才进入 PICKED_UP。
|
|
|
6. **假如** 请求指定非本单站点、收货站点或他人订单站点，**当** 取件确认，**那么** 拒绝；同一骑手重试已确认站点只返回已确认结果，不重复写凭证、时间、日志或推进其他站点。
|
|
|
7. **假如** 任意站点已经取货，**当** 用户自助取消，**那么** 拒绝并要求平台介入；与取件并发时，取件先成功则用户取消失败，取消先成功则取件失败。
|
|
|
8. **假如** 用户选择加急和多个取货点，**当** 报价或创建，**那么** 允许并沿用整条路线计价及骑手独占规则。
|
|
|
@@ -324,12 +324,12 @@
|
|
|
11. **假如** 旧单点请求提交 pickup 与订单级物品字段，**当** 报价或创建，**那么** 适配为一个含独立物品的取货点；pickup 与 pickups 同时提交时拒绝。
|
|
|
12. **假如** 多点地址保存与抢单或其他编辑并发，**当** 保存，**那么** 站点、摘要、收件人绑定、路线和金额必须同一事务提交或回滚，不出现两套地址或报价。
|
|
|
|
|
|
-13. **假如** 用户下单前调整站点顺序，**当** 确认报价，**那么** 按最终顺序计算并展示路线和费用，提示默认按此顺序取件、骑手如需调整将先沟通。
|
|
|
-14. **假如** 骑手选择非默认未取站，**当** 缺少调整原因或未声明已取得下单人同意，**那么** 不保存调整，也不能通过直接调用取件确认绕过所需记录；首期不要求用户在 App 内点击批准。
|
|
|
+13. **假如** 用户下单前调整站点顺序，**当** 确认报价，**那么** 按最终顺序计算并展示路线和费用；该顺序不约束骑手实际取件顺序。
|
|
|
+14. **假如** 骑手选择非默认未取站，**当** 未调用目标接口且未提交调整原因或同意声明，**那么** 仍可直接确认该站取件；目标接口仅兼容旧客户端导航。
|
|
|
15. **假如** 已保存先前往 B 的调整，**当** 打开或退出导航，**那么** B 仍为待取件，不生成取件凭证、不增加已取数量、不推进主状态；实际交接并提交有效图片后才可确认已取。
|
|
|
16. **假如** 用户顺序为 A → B → C，**当** B 已取且 A/C 待取，**那么** 保留原始顺序和报价，展示已取 1/3 站及各站状态，默认下一站回到 A，用户自助取消不可用。
|
|
|
17. **假如** 平台核对调整，**当** 查看记录，**那么** 展示调整前后目标站、原因、骑手、操作时间和骑手声明，不显示为用户已在 App 审批；订单聊天可作为沟通依据。
|
|
|
-18. **假如** 某站暂未备好，**当** 沟通同意后先去其他站，**那么** 原站继续待取；最终无法取货时联系平台处理，不能删除站点、虚假取件或直接完成整单。平台记录已取物品去向和交接凭证后再关闭异常订单。
|
|
|
+18. **假如** 某站暂未备好，**当** 骑手先去其他站，**那么** 原站继续待取；最终无法取货时联系平台处理，不能删除站点、虚假取件或直接完成整单。平台记录已取物品去向和交接凭证后再关闭异常订单。
|
|
|
19. **假如** 调整请求重试或与取件、取消并发，**当** 保存，**那么** 不重复追加同一次记录，不以过期状态覆盖目标；取消后禁止新调整，已取站不能作为新目标。
|
|
|
|
|
|
- FR-079：通用站点表 flash_delivery_order_stop 保存订单 ID、类型（PICKUP/DELIVERY）、用户填写顺序、快照和履约信息，作为新订单站点数据唯一真相；所有新订单（含单点）统一写入取货和收货站点。订单表 pickup_* 维护首取货点摘要，新增 pickup_stop_count。当前为测试阶段，不做历史订单迁移、无站点履约回退或历史详情适配，不自动清理测试数据。
|
|
|
@@ -337,20 +337,20 @@
|
|
|
- FR-081：数据字典 `flash_pickup_stop_limit` 配置取货点上限，不含收货点；仅接受 1 至 10 的整数，缺失、空值或非法配置时有效上限为 1。报价、创建、修改取货点均校验非空且不超过有效上限，超限返回国际化错误；首页下发有效 `pickupStopLimit`。超点数在地图调用前拒绝，不作为地图故障降级。
|
|
|
- FR-082：多取货点没有独立开关；报价、创建和地址编辑按 `flash_pickup_stop_limit` 校验数量。上限调整不影响已创建订单取件、送达及仅追加小费。首页兼容字段 `showMultiPickup` 由有效上限是否大于 1 派生。
|
|
|
- FR-083：加急功能始终可用，不设展示字典开关；首页兼容字段 `showUrgentOption` 固定返回 true。后端继续按 `deliveryType` 执行既有加急校验与计费。
|
|
|
-- FR-084：初始及地址编辑报价按用户填写顺序计算：首取货点为起点，其余取货点为中途点，收货点为终点，不自动优化顺序；地图失败逐段直线距离求和，40 公里上限按整线执行。stop_order 用于报价、展示及默认取件引导；骑手按 FR-095 改变实际取件顺序不重排用户站点、不重算订单金额。
|
|
|
+- FR-084：初始及地址编辑报价按用户填写顺序计算：首取货点为起点，其余取货点为中途点，收货点为终点，不自动优化顺序；地图失败逐段直线距离求和，40 公里上限按整线执行。stop_order 用于报价、展示及默认取件引导；骑手改变实际取件顺序不重排用户站点、不重算订单金额。
|
|
|
- FR-085：沿用 FR-004 至 FR-006、FR-070 至 FR-072 的运价、报价回传校验和整数 TWD 取整，以整线距离替代原单段距离，不新增站点附加费或按物品计价项；保留 FR-076 小费只增加小费及总金额，不重算路线、基础配送费或加急费。
|
|
|
- FR-086：deliveryType=URGENT 允许多个取货点，FR-065、FR-066 骑手独占规则不变。
|
|
|
-- FR-087：骑手默认按用户顺序取件，按 FR-095 保存沟通同意后的调整记录后可以先取其他未取站；每站实际取到货后至少上传一张取件图片。保留 POST /system/flashDelivery/rider/orders/{id}/pickup，请求 DTO 增加可选 stopId；单点可省略，多点必传。另提供 POST /system/flashDelivery/rider/orders/{id}/stops/{stopId}/pickup，路径 ID 为操作目标，同时传请求体 stopId 时必须一致。缺失必需 ID、站点不属本单或不是 PICKUP、骑手不是接单人时拒绝；同一骑手重试已确认站点幂等返回，不重复写凭证、日志或确认时间。新取件按 FR-096 校验当前目标及必要的调整记录；保存每站状态、时间和凭证；全部取货点完成才进入 PICKED_UP，pickedUpAt 记录最后一个实际完成取件的站点时间，不按 stop_order 判断末站。
|
|
|
+- FR-087：骑手可直接确认任意未取货站，每站实际取到货后至少上传一张取件图片。保留 POST /system/flashDelivery/rider/orders/{id}/pickup，请求 DTO 增加可选 stopId；单点可省略，多点必传。另提供 POST /system/flashDelivery/rider/orders/{id}/stops/{stopId}/pickup，路径 ID 为操作目标，同时传请求体 stopId 时必须一致。缺失必需 ID、站点不属本单或不是 PICKUP、骑手不是接单人时拒绝；同一骑手重试已确认站点幂等返回，不重复写凭证、日志或确认时间。确认取件不校验当前目标或调整记录；保存每站状态、时间和凭证；全部取货点完成才进入 PICKED_UP，pickedUpAt 记录最后一个实际完成取件的站点时间，不按 stop_order 判断末站。
|
|
|
- FR-088：任意取货点已确认即禁止用户自助取消，不限定用户排序第一站；全部未取时维持现有取消规则，平台保留介入能力。取件与用户/平台取消共用订单行级并发保护：同一事务先锁订单行，再读取最新订单及站点状态并校验、更新。站点状态、凭证、主状态、版本和日志一并提交或回滚，不能只在取消前单独查询一次。取消成功后禁止新增取件；任一站取件成功后用户取消必须失败。
|
|
|
- FR-089：列表保留现有字段和首取货点地址/物品摘要，新增 pickupStopCount；用户、骑手及平台详情新增 stops，包含站点 ID、类型、用户顺序、联系人、电话、地址、交接方式、坐标、独立物品、状态、确认时间及凭证。凭证按站关联，既有 pickupImageUrls 可聚合展示，不能用聚合列表覆盖各站凭证。骑手接单前逐站隐藏联系人、电话、精确坐标、PIN 及凭证图片，保留文字地址及履约判断所需物品信息。
|
|
|
-- FR-090：客户端按 FR-094 至 FR-096 确定的当前目标站拼装 Google Maps URL，默认指向用户顺序中最早的未取站，保存沟通同意后的调整后指向选定站，全部取完后导航到唯一收货点。选择前往、打开导航与确认已取货是独立操作。使用 api=1、travelmode=two-wheeler、dir_action=navigate，正确编码参数，起点默认设备当前位置；不依赖携带全部途经点的 URL 履约。后端按 FR-029 权限返回坐标，不生成导航 URL，不新增用于生成导航 URL 的接口；调整记录保存属于履约操作，不能仅保存在客户端。
|
|
|
+- FR-090：客户端可按骑手选择的待完成站拼装 Google Maps URL，默认提示用户顺序中最早的未完成站；导航选择仅是客户端行为，不作为确认取送的前置条件。使用 api=1、travelmode=two-wheeler、dir_action=navigate，正确编码参数，起点默认设备当前位置；不依赖携带全部途经点的 URL 履约。后端按 FR-029 权限返回坐标，不生成导航 URL。
|
|
|
- FR-091：站点表、订单表加列、站点凭证关联所需变更及三个字典项 SQL 只记录在 updatesql/sql.md，不直接执行数据库操作。
|
|
|
- FR-092：报价和创建新增 pickups 数组，每项含完整取货地址及 FR-080 物品字段；保留旧 pickup 与订单级物品作为单点输入，统一适配后校验。pickup 与 pickups 不得同时提交；使用 pickups 时不允许同时提交旧订单级物品字段，冲突返回国际化错误。AddressChange/Confirm DTO 同步支持完整 pickups 与唯一 delivery；旧 pickup 编辑仅适用于单点并保留该站物品，多点编辑缺少完整 pickups 必须拒绝，不能丢弃其余站点。
|
|
|
- FR-093：地址编辑沿用 FR-073 至 FR-075、FR-077 的权限、状态、版本及原运价快照，重算整线；订单原子条件更新成功后，在同一事务保存完整站点、首点摘要、数量、收件人绑定及费用，失败全部回滚。完整站点输入保留并校验逐站物品，不因编辑联系人或地址清空物品。
|
|
|
|
|
|
-- FR-094：下单前用户可调整取货点顺序，按最终顺序报价并确认；待接单订单调整顺序沿用 FR-093 重报价及确认流程。下单页提示“默认按此顺序取件，骑手如需调整将先与您沟通”，用户可见文案按现有国际化要求实现。骑手接单后可以查看全部站点，默认突出显示用户顺序中最早的未取站为下一站。
|
|
|
-- FR-095：骑手需要先去其他未取站时，须先联系下单人并取得同意，再选择“先前往该站”，填写调整原因并声明“已取得下单人同意”。服务端保存订单、调整前目标站、调整后目标站、原因、骑手身份、操作时间及同意声明。首期不要求用户在 App 内点击批准；骑手勾选只证明其作出了声明，不证明下单人实际同意，平台不得标记为用户审批通过。订单聊天可作为沟通依据；未取得同意不能自行调整，无法联系下单人时联系平台处理。
|
|
|
-- FR-096：选择前往与确认已取货分开：前者只确定目标并记录必要的调整，不能修改站点取件状态、取件时间、凭证或主状态；后者必须实际交接并提交有效取件图片。新取件确认以当前目标为准；选择非默认站须先保存 FR-095 记录，不能通过直接提交 stopId 绕过。已确认站点的重试仍按 FR-087 幂等处理，不受目标已变化影响。选定目标在取件前保持；再次改变目标时记录调整。目标站取件后回到用户顺序中最早的未取站，全部取完后转为收货点。调整操作校验接单骑手、订单状态和本单未取站，保存须防重复并与取件、取消使用一致的订单并发保护。
|
|
|
+- FR-094：下单前用户可调整取货点顺序，按最终顺序报价并确认；待接单订单调整顺序沿用 FR-093 重报价及确认流程。骑手接单后可以查看全部站点，客户顺序仅用于展示和默认导航提示，不限制实际取货先后。
|
|
|
+- FR-095：`POST /system/flashDelivery/rider/orders/{id}/stops/{stopId}/target` 标记过期，仅兼容旧客户端的可选导航目标保存。调用时仍校验接单骑手、订单状态、本单待完成站、订单版本与请求幂等；原因可选（最多 500 字），同意声明可省略，记录骑手提供的值但不作为客户审批。新客户端无需调用，直接按站 ID 确认取送。
|
|
|
+- FR-096：导航与实际取送分开：选择目标不能修改站点状态、时间、凭证或主状态；确认取送须实际交接并提交本站有效凭证。确认任意待完成站不要求当前目标一致，也不要求先保存 FR-095 记录。已确认站点的重试仍按 FR-087 幂等处理。服务端 `currentTargetStopId` 仅作为兼容旧客户端的导航提示；订单原站序和金额不变。
|
|
|
- FR-097：保留用户原始站点顺序及报价，按每站实际确认时间和状态展示履约进度；用户、骑手及平台显示已取数量/总数量（如“已取 1/3 站”）。部分取件主状态仍为 ACCEPTED，取消入口按是否任意站已取判断，不能仅依据主状态显示可取消。平台详情可查看 FR-095 调整记录；调整声明和取件凭证分别展示，不相互替代。
|
|
|
- FR-098：骑手仅能调整本单未取货地点的访问先后，不能新增或删除地点、修改地址或物品，也不能漏取。某站暂时无法取货可以沟通后先去其他站，该站继续保留待取件；最终无法取货、缺件或拒收须联系平台处理，不能虚假确认取件、擅自部分履约或直接完成整单。平台介入时记录问题站、处理结果及已取物品去向和交接凭证，再关闭异常订单；沿用既有介入权限，本次不新增支付退款功能。
|
|
|
|
|
|
@@ -443,8 +443,8 @@
|
|
|
|
|
|
## 2026-10-15：客户顺序交错取送与骑手双进度（用户确认）
|
|
|
|
|
|
-本节修订 v2 的 FR-116、FR-120、FR-128 以及此前“先取完再送”和“改变顺序须客户同意”的限制；旧契约订单继续沿用原履约规则。
|
|
|
+本节修订 v2 的 FR-116、FR-120、FR-128 以及此前“先取完再送”和“改变顺序须客户同意”的限制；2026-10-15 再修订为新旧订单均不限制目标站顺序，旧契约唯一收货站仍须先完成全部取货站，防止漏取而提前完单。
|
|
|
|
|
|
- FR-129：v2 客户提交的 `stops[]` 顺序用于报价、保存及默认导航，不自动按类型重排。首站为取货、末站为收货，中间允许取送交错，例如取1→取2→送1→取3→送2；下单与待接单改址共用校验。客户通过每站备注说明物品，骑手负责核对实际取送，不新增取货站与收货站强制关联字段。
|
|
|
-- FR-130：v2 骑手可自主选择其他未完成取货/收货站作为当前目标，包括先取完所有货再送；沿用目标接口、版本与请求幂等，原因可选，同意声明不再作为必需条件，保留实际调整审计。尚未取过货不能送达；存在未取货站时不能确认最后一个未完成收货站，以防漏取提前结束。每站取送仍需对应类型、所属骑手、当前目标、凭证及按站 PIN 校验；完成目标后回到客户原顺序最早的未完成站，不修改原站点顺序和运费。
|
|
|
+- FR-130：v2 骑手可自主确认任意未完成取货/收货站，不必先设为当前目标；旧订单亦不限制取货站顺序。目标接口过期，仅兼容旧客户端的可选导航提示，原因和同意声明均非必需。尚未取过货不能送达；存在未取货站时不能确认最后一个未完成收货站，以防漏取提前结束。每站取送仍需对应类型、所属骑手、凭证及按站 PIN 校验；不修改原站点顺序和运费。
|
|
|
- FR-131：现有五个 Tab、名称、参数和订单计数保持：`newTask` 新任务、`toPickup` 待取件、`delivering` 配送中、`completed` 已送达、`cancelled` 已取消。取货未全部完成时主状态保持 ACCEPTED，即使部分收货站已送达；全部取完后为 PICKED_UP；全部取送站完成后才为 DELIVERED，后续确认收货/自动完成和记账沿用原流程。卡片与详情同时显示已取件 `pickedUpStopCount/pickupStopCount`、已送达 `deliveredStopCount/deliveryStopCount`，如“已取件 2/3 · 已送达 1/2”；Tab 角标计订单而非站点，一单仅属于一个 Tab。App 由前端人员实现，本仓库提供接入文档，不修改 App 源码。
|
qmj