|
|
@@ -4,7 +4,7 @@
|
|
|
|
|
|
**创建日期**:2026-08-31
|
|
|
|
|
|
-**状态**:既有功能已验证;2026-09-07 设计稿费用与物品信息对齐增量已确认,待实施
|
|
|
+**状态**:既有功能已验证;2026-09-07 设计稿费用与物品信息对齐增量已确认,待实施;2026-09-14 多取货点增量已确认,待实施
|
|
|
|
|
|
**输入**:基于蓝湖“闪送”分组 7 个设计页面、2026-08-24 用户端/骑手端补充原型及 2026-09-03 更新的 19 张用户端设计稿,实现帮送/帮取业务场景、普通/1 对 1 加急配送、共享地址簿、路线报价、完整物品信息、立即/预约配送、费用明细与报价校验、可选 PIN 交付、创建订单、寄件人/收件人订单查询、骑手主动抢单、急送独占、取件、送达、用户签收、平台配置与介入的非支付业务闭环。
|
|
|
|
|
|
@@ -295,3 +295,47 @@
|
|
|
- 本次只新增以上能力;沿用现有取消规则、非支付边界。复用现有字段与 version,无数据库迁移。
|
|
|
|
|
|
- FR-078(2026-09-09 入参调整):确认修改地址与追加小费使用 POST /orders/address 和 POST /orders/tip;订单 ID 通过 JSON 请求体 orderId 传入,必须是有效正整数,token 仍放请求头。
|
|
|
+## 2026-09-14:闪送多取货点(多取一送)
|
|
|
+
|
|
|
+本节按本轮审核及用户确认更新,替换此前多点增量规则;生产功能仍待实施。单笔订单包含 1 至 N 个取货点和 1 个收货点,每个取货点独立关联联系人和物品信息。用户填写顺序用于初始路线报价和展示,骑手自行决定实际取件顺序。按整条路线距离计价,不新增每取货点附加费;点间不设单独距离限制,整条报价路线仍不得超过 40 公里。
|
|
|
+
|
|
|
+### 用户故事 8:用户发布多取货点订单并由骑手逐点取件(优先级:P1)
|
|
|
+
|
|
|
+用户逐站填写联系人、地址和物品,填写唯一收货点后获取整条路线报价;骑手接单后自主选择未取货站点,逐站确认并上传凭证,全部取货点完成后订单进入已取件,送达流程不变。
|
|
|
+
|
|
|
+**优先级原因**:每站独立物品和凭证用于履约核对与纠纷定位。
|
|
|
+
|
|
|
+**独立测试**:验证每站物品独立、报价按用户顺序而取件顺序自由、单点可省略 stopId、多点必传 stopId、重试不推进其他站点、取件与用户取消互斥,以及全部取货点完成时仅推进一次主状态。
|
|
|
+
|
|
|
+**验收场景**:
|
|
|
+
|
|
|
+1. **假如** 多地点开关开启,**当** 用户报价或创建多点订单,**那么** 各站分别校验联系人和物品,按用户填写顺序计算整条路线距离、时长和费用。
|
|
|
+2. **假如** 数量超过字典有效上限,**当** 报价、创建或修改取货点,**那么** 返回国际化错误;字典缺失或非法时有效上限为 1。
|
|
|
+3. **假如** 多地点开关关闭,**当** 报价、创建或编辑提交多于一个取货点,**那么** 拒绝;既有订单履约及仅追加小费不受开关和上限调整影响。
|
|
|
+4. **假如** 订单只有一个取货点,**当** 骑手不传 stopId,**那么** 定位唯一取货点;多点订单未传 stopId 必须拒绝,不自动选择未取货站点。
|
|
|
+5. **假如** B 点在用户排序中位于 A 点之后,**当** 本单骑手先确认 B 点且凭证有效,**那么** 允许;主状态保持 ACCEPTED,全部取货点完成后才进入 PICKED_UP。
|
|
|
+6. **假如** 请求指定非本单站点、收货站点或他人订单站点,**当** 取件确认,**那么** 拒绝;同一骑手重试已确认站点只返回已确认结果,不重复写凭证、时间、日志或推进其他站点。
|
|
|
+7. **假如** 任意站点已经取货,**当** 用户自助取消,**那么** 拒绝并要求平台介入;与取件并发时,取件先成功则用户取消失败,取消先成功则取件失败。
|
|
|
+8. **假如** 用户选择加急和多个取货点,**当** 报价或创建,**那么** 允许并沿用整条路线计价及骑手独占规则。
|
|
|
+9. **假如** 待接单订单修改地址,**当** 报价或确认保存,**那么** 使用完整站点序列和原运价快照重算整线;仅追加小费时只增加小费和总金额,不请求路线或重算其他费用。
|
|
|
+10. **假如** 整线超过 40 公里或地图服务失败,**当** 报价、创建或地址编辑重报价,**那么** 按整线执行距离上限和逐段直线降级;点数超限在地图调用前拒绝。
|
|
|
+11. **假如** 旧单点请求提交 pickup 与订单级物品字段,**当** 报价或创建,**那么** 适配为一个含独立物品的取货点;pickup 与 pickups 同时提交时拒绝。
|
|
|
+12. **假如** 多点地址保存与抢单或其他编辑并发,**当** 保存,**那么** 站点、摘要、收件人绑定、路线和金额必须同一事务提交或回滚,不出现两套地址或报价。
|
|
|
+
|
|
|
+- FR-079:通用站点表 flash_delivery_order_stop 保存订单 ID、类型(PICKUP/DELIVERY)、用户填写顺序、快照和履约信息,作为新订单站点数据唯一真相;所有新订单(含单点)统一写入取货和收货站点。订单表 pickup_* 维护首取货点摘要,新增 pickup_stop_count。当前为测试阶段,不做历史订单迁移、无站点履约回退或历史详情适配,不自动清理测试数据。
|
|
|
+- FR-080:每个取货点独立保存联系人、电话、地址、详细地址、市/区、交接方式、经纬度和物品字段 packageType、quantity、weightRange、specification;逐站按既有物品规则校验并供骑手核对。唯一收货点保存收件信息,收件账号绑定和交付 PIN 维持订单级一套。既有订单级物品字段仅保留首取货点兼容摘要,不代表多点订单全部物品,不作为站点物品来源。
|
|
|
+- FR-081:数据字典 flash_pickup_stop_limit 配置取货点上限,不含收货点;仅接受 1 至 26 的整数,缺失、空值或非法配置时有效上限为 1。报价、创建、修改取货点均校验非空且不超过有效上限,超限返回国际化错误;首页下发有效 pickupStopLimit。26 个取货点对应 25 个中途点,超点数在地图调用前拒绝,不作为地图故障降级。
|
|
|
+- FR-082:flash_show_multi_pickup 控制多点能力;关闭时多于一个取货点的报价、创建和地址编辑均拒绝。开关或上限调整不影响已创建订单取件、送达及仅追加小费。
|
|
|
+- FR-083:flash_show_urgent_option 经首页配置下发,仅控制 App 加急选项展示;后端仍按 deliveryType 执行既有校验,不受该展示开关影响。
|
|
|
+- 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:骑手可选择本单任一未取货站点,每站至少一张取件图片。保留 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:客户端按骑手选择的未取货站点拼装 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 的权限、状态、版本及原运价快照,重算整线;订单原子条件更新成功后,在同一事务保存完整站点、首点摘要、数量、收件人绑定及费用,失败全部回滚。完整站点输入保留并校验逐站物品,不因编辑联系人或地址清空物品。
|
|
|
+
|
|
|
+地图约束依据:[Google Routes 中途点限制](https://developers.google.com/maps/documentation/routes/intermed_waypoints)、[Google Maps URL 参数及平台途经点限制](https://developers.google.com/maps/documentation/urls/get-started)。
|