|
|
@@ -416,7 +416,9 @@ GET /system/multiStoreCheckout/rider/tasks?page=1&size=10&tab=newTask&longitude=
|
|
|
响应 `data` 为分页结构，`records[]` 中 `GROUP` 卡一张 = 一组（角标与列表同口径，组只计一次）。
|
|
|
普通单卡与组卡 `members[]` 均附带与旧骑手列表逐单一致的信息：`legacyOrder`（订单全量快照）、
|
|
|
`store`（门店对象）、`user`（用户对象）、`juli`（骑手定位到订单坐标的直线距离，公里两位小数；
|
|
|
-未传定位时为 null，组卡另有服务端口径的 `anchorDistanceMeters`）。待抢组只在批次已生效且达到原预约开放时点、组 `openedAt` 已写入后可见；新任务有有效坐标时按首店距离升序，其余按创建时间方向。最后成员就绪并提交后，服务端立即尝试开放即时/已到点批次；若失败，由原分钟任务重试，预约未到也由该任务到点开放。App 不依赖固定一分钟延迟，付款后可刷新列表，未出现时以服务端状态为准；对外 URL 保持不变。
|
|
|
+未传定位时为 null，组卡另有服务端口径的 `anchorDistanceMeters`）；
|
|
|
+`goodsCount`（food 快照件数合计，口径同统一列表：普通单卡为本单件数，批次/组卡为有效成员合计，
|
|
|
+food 缺失或非法为 null）。待抢组只在批次已生效且达到原预约开放时点、组 `openedAt` 已写入后可见；新任务有有效坐标时按首店距离升序，其余按创建时间方向。最后成员就绪并提交后，服务端立即尝试开放即时/已到点批次；若失败，由原分钟任务重试，预约未到也由该任务到点开放。App 不依赖固定一分钟延迟，付款后可刷新列表，未出现时以服务端状态为准；对外 URL 保持不变。
|
|
|
|
|
|
### 6.2 各页签任务数（角标）
|
|
|
|
|
|
@@ -444,7 +446,7 @@ GET /system/multiStoreCheckout/groups/{groupId}
|
|
|
- `allowedActions`：待抢时 `ACCEPT_GROUP`；本人已接组后 `members[]` 内出现 `PICKUP_MEMBER` / `DELIVER_MEMBER`。
|
|
|
- `codToCollectAmount`：有效到付子单的待收总额。
|
|
|
|
|
|
-成员摘要（含待抢阶段）附带 `legacyOrder`/`store`/`user`/`juli`/`jvli`，
|
|
|
+成员摘要（含待抢阶段）附带 `legacyOrder`/`store`/`user`/`juli`/`jvli`/`goodsCount`，
|
|
|
其中 `juli` 与旧普通订单详情一致：此详情接口未传骑手定位时为 `null`；`jvli` 是该店到收货地址的道路距离（公里），与 `legacyOrder.jvli` 一致。组内每店距离不同，组卡顶层不提供单一 `jvli`。历史子单若建单时未保存距离则保持 `null`，不把直线距离伪装成原道路距离。
|
|
|
其他订单字段与旧骑手列表逐单口径一致，
|
|
|
可直接复用旧列表项渲染；已接单后逐店履约仍按子单详情读取（见 6.5）。如产品后续要求待抢阶段
|
qmj