优化
This commit is contained in:
@@ -14,11 +14,14 @@
|
||||
- [国内货柜履约](国内货柜履约/README.md)：分柜与同柜、智能排柜、订舱、拖车、PDA 拣货、装柜、报关和国内出仓。
|
||||
- [船期日历功能规划](国内货柜履约/船期日历功能规划.md)：渠道、周模板、单次船期、收货截止时间和按渠道货量统计的独立日历规划。
|
||||
- [海外仓业务](海外仓业务/README.md)：船节点、海外接柜、入仓、库存、托盘、换标、转运、废弃、退货、排车、PDA 出库、派送、异常退回、客户回访、一件代发及海外本土业务。
|
||||
- [采购订单样品履约流程变更需求](海外仓业务/采购订单样品履约流程变更需求.md)：采购样品购买、装箱、面单、交寄、国内核费与寄客户的变更入口。
|
||||
- [船节点标准化契约](海外仓业务/船节点标准化契约.md)：统一船司原始状态、标准节点、预计/实际时间、异常事实、还柜停止规则和新增船司接入门禁。
|
||||
- [美国预约管理统一总览与优化方案](海外仓业务/美国预约管理统一总览与优化方案.md)：美国段各类预约的范围、关联关系、表单精简及分步实施建议。
|
||||
- [预约送仓](海外仓业务/README.md#预约送仓)：预约日历与跨客户同仓预约入口。
|
||||
- [车辆管理原型梳理与任务规划](海外仓业务/车辆管理原型梳理与任务规划.md)：司机资质、车次、自有/外接承运、运维与报价的范围及契约入口。
|
||||
- [内部拼车需求池首版开发契约](海外仓业务/内部拼车需求池首版开发契约.md)：车次余位发布、销售意向、承运占位、本土订单关联及我仓上车流程。
|
||||
- [财务管理](财务管理/README.md)：应收、应付、费用池、账单、收款、成本、核销、凭证以及国内外业务费用来源。
|
||||
- [自营业务](自营业务/README.md)：平台自营经营总览图表、SKU 销量、分仓产品库存、库存周转视图与数据采集；Admin 入口 `apps/admin-web/src/modules/self-operated/AGENTS.md`，业务设计、采集页面与进度图、查询性能优化及领星 API 联调依据见该业务域入口。
|
||||
- [打印标签维护](打印标签维护/README.md)：箱唛、各类托盘标、HOLD、BOL 与其他单据的现状盘点、参考样张和逐项改版记录。
|
||||
|
||||
## 全流程公共契约
|
||||
|
||||
@@ -65,6 +65,10 @@
|
||||
|
||||
## 业务快速路由表
|
||||
|
||||
领星 WMS 自研系统（OMP）、经营总览图表、自营 SKU 日销量、热销与滞销排行、分仓产品库存与可售天数、库存周转、数据采集：`docs/自营业务/README.md` → `领星一件代发数据统计一期方案.md`（架构、表结构与验收）、`经营总览图表设计.md`（图形、聚合与下钻）、`库存周转视图设计.md`（三窗出库、SKU／货主汇总及周转资格）、`数据采集页面设计.md`（首页、详情、进度图与预计时间）、`领星统计查询性能优化方案.md`（查询优化与验证顺序）、`领星WMS接口联调手册.md`（签名、参数与实测）；Admin 从 `apps/admin-web/src/modules/self-operated/AGENTS.md` 进入，后端从 `integration-service/AGENTS.md` 与 `lastleg-service/AGENTS.md` 进入，区别于整箱库存和客户 WMS 作业库存。
|
||||
|
||||
美国各类预约统一总览、提柜/用车/送仓预约梳理：`docs/海外仓业务/美国预约管理统一总览与优化方案.md`（设计建议）；实际维护仍按下述来源模块进入。
|
||||
|
||||
预约管理、预约列表、跨客户同仓送仓：Admin `apps/admin-web/src/modules/appointment-calendar/`，规则见 `docs/海外仓业务/README.md` 的“预约送仓”；送仓记录沿 Lastleg `inboundplan/`，到港沿 Firstleg `portschedule/`，区别于订舱级拖车预约。
|
||||
|
||||
退货预报、签收、库存与合箱：Client `modules/overseas-warehouse/views/ReturnOrdersView.vue`、`ReturnInventoryView.vue`；Admin `modules/overseas-warehouse/pages/ReturnInventoryManagementView.vue`；海外 PDA `src/pages/return-receipt/return-receipt.vue`、`src/pages/return-packing/return-packing.vue`，API 与检查入口见 `apps/pda-overseas-uniapp/AGENTS.md`；Backend `lastleg-service/returnreceipt/`，执行规则先读 `baiyue-firstleg/lastleg-service/AGENTS.md`，详细接口与状态按需查 `baiyue-firstleg/lastleg-service/docs/business-index.md` 的退货入口，OpenAPI 为 `overseas-business-v1.yaml`。客户预报 → 平台审核 → PDA 签收 → 退货箱/SKU 库存 → 同客户合箱 → `delivery/` 退货出库；两个 PDA 页面均在 `src/pages.json` 注册，由 `src/data/overseas-workbench.js` 提供入口，真机验收另取证。派送异常退回仍归 `exceptionorder/`。
|
||||
@@ -106,6 +110,7 @@
|
||||
| 尾程订单控制与柜级入仓计划转换 | `docs/海外仓业务/README.md` | Admin `modules/overseas-warehouse/pages/LastMileOrdersView.vue`、`LastMileOrderDetailView.vue`、`api/lastMileOrders.ts`；Backend `lastleg-service/` 的 `LastlegOrderController`、`LastlegOrderCommandService`、`InboundPlanService`、`ContainerInboundPlanConversionCoordinator`，资源归 `warehouse-overseas-service/` 的 `WarehousePalletBatchService`。`orders/container-summaries` 按 `sourceContainerBookingId` 跨客户聚合并分页返回全部稳定来源柜，已完成计划转换的柜仍保留用于接柜仓查询与修改；生成动作只消费 `allPlansReady/pendingPlanCount/resourcePendingPlanCount`，详情不受列表分页截断。确认前从 `/inbound-plans/container-preview` 读取服务端分组、托数、阻断项与 `snapshotVersion/snapshotHash`；`convert-container` 锁柜重算后先批量预留真实托盘，再本地原子生成剩余独立计划并确认资源，失败仅补偿未确认资源，同柜重放不得产生第二批资源。单票手工计划保存后，全柜计划齐全且预览就绪时自动生成并绑定托盘资源，一票柜立即触发；`resourcePendingPlanCount` 表示自动生成异常后的重试入口，资源未齐不得进入 PDA 接柜。自动入口见 Lastleg `ContainerInboundPlanConversionCoordinator.convertManualAndAutoMaterialize`。单票可维护完整入库计划、暂扣/解除及八行人工节点快照；命令提交订单版本与幂等键，新增暂扣只允许完成入库后执行并仅阻断该票后续排车/出库，不阻断入库计划或入库作业；人工节点首次保存后固定 `MANUAL` 来源且不得回退柜级节点 |
|
||||
| 海外仓 PDA | `apps/pda-overseas-uniapp/AGENTS.md`；执行规则查 `baiyue-firstleg/lastleg-service/AGENTS.md`，跨模块流程才查海外仓 README | 入仓 `src/pages/operation/`、`src/api/inbound.js`；排车与出库 `src/pages/dispatch/`、`src/pages/outbound/`、`src/api/fulfillment.js`。Backend `lastleg-service/inboundplan/pda/`、`dispatch/pda/`、`delivery/`；统一经 `gateway/`。柜级收货与单票客户隔离按 Lastleg“PDA 入仓”规则核对 |
|
||||
| 海外采购、本土卡车与散板 | `docs/海外仓业务/README.md` | Admin `modules/overseas-business/`；Client `modules/cross-border/`；Backend `lastleg-service/` 的 `procurement/`、`trucking/`、`looseboard/`；统一经 `gateway/` |
|
||||
| 采购样品、货款、装箱清单、面单、预估快递费、国内收货寄客户 | `docs/海外仓业务/采购订单样品履约流程变更需求.md` | 采购流程变更入口；代码从上述采购模块进入 |
|
||||
| 海外仓库与通用资料 | `docs/海外仓业务/README.md` | 全部仓库主档进入 Admin `modules/warehouses/` 与国内 `warehouse/`；海外库位/托盘/锁进入 `warehouse-overseas-service/` 并引用国内 warehouseId；报价、汇率、车辆按海外服务实际契约 |
|
||||
| 车辆管理、司机证照、保养加油、车辆维修/故障/救援/异常、外接货与车次 | `apps/admin-web/src/modules/overseas-master-data/AGENTS.md`、`baiyue-firstleg/lastleg-service/AGENTS.md`；原型范围有疑问时查 `docs/海外仓业务/车辆管理原型梳理与任务规划.md` | Admin `modules/overseas-master-data/`；Backend `lastleg-service/fleet/`，接口 `lastleg-service/src/main/resources/openapi/fleet-drivers-v1.yaml`、`fleet-trips-v1.yaml`、`fleet-vehicle-records-v1.yaml`；证照与运维照片存储查 `file/AGENTS.md` |
|
||||
| 拼车需求池、车次余位、销售拼车意向 | `docs/海外仓业务/内部拼车需求池首版开发契约.md`、`apps/admin-web/src/modules/overseas-master-data/AGENTS.md` | 复用 Lastleg Fleet 与本土业务；区分车次余位发布和客户订单，不从需求池生成第二套库存或费用 |
|
||||
|
||||
@@ -13,6 +13,8 @@
|
||||
|
||||
## 货柜关键节点
|
||||
|
||||
货柜对外统一使用 `cabinetNo` 柜次号（`D0001` 起，全局连续、不按日期重置），创建时只生成一次；日历、提柜、智能装柜、货柜详情及出仓均读取该值。`containerBookingId` 仅用于技术关联，`containerNo` 为真实集装箱号。货柜不再维护独立的 CB 格式 `bookingNo`；海运订舱和外接货登记各自的 `bookingNo` 不属于货柜编号，保留各自业务语义。
|
||||
|
||||
```text
|
||||
分柜/订舱/拖车 → 拣货 → 装柜完成（LOADED）
|
||||
├─ 报关协同：资料 → 报关行回执 → 客户确认/打回重做
|
||||
|
||||
@@ -10,6 +10,18 @@
|
||||
|
||||
**当前实现快照（2026-09-29）**：两份文件链路已经落到平台、客户和 Firstleg 报关接口，客户端“报关资料”和“船期价格”也已经作为独立模块接入导航和路由。客户资料、报关行回执、客户整份回执确认/打回、平台发送报关行执行、真实报关完税文件分别保存并受版本门禁控制。回执发送给报关行后不可再替换；只有包含退税货物的柜才允许走发送执行接口；全买单柜仍走平台直接完成。`brokerSubmittedAt` 只表示发送执行时间，不表示报关完成。PDA 只负责产生 `LOADED` 前置事实，报关验收不创建或操作 PDA 任务；船期、甩柜和改配只修改原柜运输信息，不重置报关资料和确认结果。
|
||||
|
||||
## 客户报关资料菜单待办红标
|
||||
|
||||
- 侧栏“报关资料”在文字右侧显示红底白字数量，白色描边；无待办时隐藏，超过99显示“99+”。承载依据为客户提供的菜单截图，菜单入口和资料弹框保持原承载方式。
|
||||
- 数量按当前客户需要处理的**柜次去重**：最新实际装柜的退税货物尚缺本客户有效资料，或者报关中本客户冻结资料的当前回执待确认（PENDING）。同柜多个入仓码、多份回执合计1个红标待办；已确认、已打回等待平台重做、已完成及同柜其他客户的待办不计入。
|
||||
- `GET /api/merchant/v1/customs/pending-summary` 由Firstleg只读聚合返回`pendingCount`，客户范围来自认证上下文，读取权限`merchant:order:view`；复用现有网关customs路由，不在侧栏逐票加载报关详情或创建报关记录。计数与订单列表“上传资料”的订单数不是同一单位，不能相互替代。
|
||||
- 首次进入工作台、页面可见时每60秒、窗口重新获得焦点、报关资料刷新及资料操作后重新查询。刷新期间保留已确认数值；失败显示红色“!”并说明数量加载失败，不把失败显示成零。退出或失去菜单权限立即清空，旧会话响应不能写入新会话。
|
||||
|
||||
| 页面/操作 | 原型依据与承载 | 实现 |
|
||||
|---|---|---|
|
||||
| 报关资料菜单红标 | 用户提供菜单截图，文字右侧圆形红色数量 | 真实待办数、白描边、同柜去重；不添加新弹框 |
|
||||
| 资料处理后更新 | 原有上传、覆盖范围、删除及回执确认/打回操作 | 查询最新待办数，不在浏览器自行减1 |
|
||||
|
||||
## 当前差异与下一步
|
||||
|
||||
当前主流程和代码的关系已经收敛：F01-F24（国内头程、报关、待发区、送港、进港、甩柜和实际开航）有最新真实 HTTP 证据；F25-F40（目的港、海外入库、库存、出库、派送和最终回写）已有综合真实 HTTP 证据和页面实现。客户端两个独立模块、订单快捷入口、平台整柜报关工作台和船期价格查询均已接入，不需要再按“新增页面”拆任务。
|
||||
|
||||
+2
-1
@@ -16,7 +16,8 @@
|
||||
|
||||
### Admin 菜单结构与显示
|
||||
|
||||
- 一级、二级菜单的名称、分组和顺序以当前确认原型为准，唯一代码入口为 `apps/admin-web/src/core/navigation/adminNavigation.ts`。当前已实现的一级结构为首页数据看板、客户管理、国内头程、货柜管理、海外尾程、预约管理、车辆管理、海外业务、客户服务、财务管理、通用、系统管理；二级菜单统一在该入口维护，实际显示继续由权限过滤。
|
||||
- 一级、二级菜单的名称、分组和顺序以当前确认原型及当前对话确认为准，唯一代码入口为 `apps/admin-web/src/core/navigation/adminNavigation.ts`。一级结构为首页数据看板、客户管理、国内头程、货柜管理、海外尾程、预约管理、车辆管理、海外业务、客户服务、财务管理、自营业务、通用、系统管理；二级菜单统一在该入口维护，实际显示继续由权限过滤。
|
||||
- 自营业务的经营总览、销量分析、库存分析、数据采集四个页面统一使用 `platform:self-operated-analytics:list`，包括任务详情只读和运行辅助查询；重试独立使用 `platform:self-operated-analytics:sync`。IAM 菜单管理资源不替代上述实际读写授权，不能仅凭采集写权限打开只读页面。
|
||||
- 已实现菜单继续使用正式路由及服务端权限，不因改名、移动或仅调整菜单结构改变接口、状态和操作资格。当前原型未展示的既有入口通过 `hidden` 退出侧栏，正式路由和权限仍按现行合同管理；角色权限设置仍保留这些正式页面及操作的可分配权限。
|
||||
- 尚无正式页面的菜单不显示，不保留禁用占位或空分组，不接入原型假数据、虚构权限码或新增业务接口。后续功能实现时再核对正式页面、权限与服务端合同。
|
||||
|
||||
|
||||
@@ -1,5 +1,408 @@
|
||||
# 测试环境单机部署与配置契约
|
||||
|
||||
## 自营统计 TEST 发布与验收（2026-10-13，进行中）
|
||||
|
||||
20:04 按用户“先手动恢复采集，再改额度”执行：19:55已通过原人工BACKFILL接口提交10/07根 `LXCOL-20261013-6ECEF4366F694584`，20:04实查RUNNING、325请求、账号无暂停；原1.2秒间隔、Nacos、日计数和独占截止均未改。提交前只将本机必须容纳root10800秒加900秒的过保守预检改为90分钟余量，按2100预估核对剩余3180后提交，未重复已有日期。取消BUSINESS每日/根次数硬额度的代码 `c2bb769676c487c13eb6dee962c13febeeffe83e` 已推送，121项定向测试及5项Gateway检查通过；计数、1.2秒、期限、429/鉴权/未知结果保护和VALIDATION上限保留，每轮requestBudget仍是YIELDED批次边界。该版本尚未部署，当前仍由旧服务采集。已准备一次性有限接续脚本，在7日两仓发布且无活动请求后只部署Lastleg、验证镜像和运行API无次数上限，再接6日；不续22:36:59原许可，不执行SQL/清零或修改Integration。20:05接续进程已启动（PID17464），状态WAITING_CURRENT_COLLECTION，当前根354请求；启动状态以 `target/selfop-unlimited-cutover-r1.json` 为准，不将待发布代码记为运行生效。
|
||||
|
||||
19:46 用户反馈再次停采，实查10/08两仓已完整发布（本根1899请求），10/08—12连续5日完成；10/07尚未创建。有限队列r4于19:45:48停在BLOCKED_BUDGET_EXPECTED_5000：账号日限12000、累计8820预留/8818确认、剩余3180，低于本机队列固定5000请求预估门槛。账号pause=null、冷却已过去、无活动根、上一出口请求已完成；不是新限流或在途任务失败。原许可22:36:59截止，19:46剩余约2小时50分，也不足当前单根10800秒加900秒预检余量；仅下调5000预估仍会被时长预检拒绝。本次只读检查，未改预算/配置/许可或重新提交。证据：target/selfop-seven-day-queue-r4-seven-days-current.json、selfop-ten-day-observation-2026-10-13T11-46-19-498Z.json。
|
||||
|
||||
18:50 用户确认热销榜应沿页面所选时间、不固定30日后，已发布Lastleg `f151e74f5c0d`（Jenkins #294 SUCCESS）与Admin `698ca3452986`（#596 SUCCESS，SCM恢复release/test及原lightweight）。热销Top10/Top100按同一所选日期与固定版本的已采集有效量排序，部分覆盖明确提示，不用部分量推算日均；另两库存榜仍保留30日依赖。只提交本次查询/展示/直接测试及合同，未纳入并行ECharts、采集估算等未提交修改。前端全量2996通过，追加HOT提示35项及最终含类型检查构建通过；后端相关7类86项通过、网关5项和索引1122项通过。后端全量另有PDA反射、退货H2、Schema合同及缺失测试class失败，保留报告，不宣称全量通过。真实HTTP两仓各测完整3日、部分长范围、今日无数据共36断言通过；有数据范围均返回10条，Top100前10与卡片一致；镜像健康、路由及资源hash等80项核验通过，视觉仍待人工截图。证据：target/selfop-top10-http-r1.json、selfop-top10-runtime-r1.json及selfop-top10-release-*。
|
||||
|
||||
本轮构建/修改期间继续采集10/09，未关闭BUSINESS、修改Nacos或重启Integration。10/09两仓完整发布后在无活动根/未完成出口请求边界单独替换Lastleg，随后18:47:51提交10/08根 `LXCOL-20261013-5EB5F31A67CD4DF8`。有限队列由本机r3交接至r4-seven-days（PID55108），原10/06—12范围、1200ms间隔、12000日预算、单根5000/10800秒及22:36:59许可保持；不承诺更新仅数秒或全部7日必能在额度内完成。18:50实查10/09—12连续4日均两仓完整，10/08 RUNNING、83请求、账号无暂停，累计7006预留/7004确认，r4继续运行。证据：target/selfop-top10-queue-hold.json、selfop-thirty-day-config-proof-r17918884610121.json、selfop-seven-day-queue-r4-seven-days-current.json、selfop-ten-day-observation-2026-10-13T10-50-15-220Z.json。
|
||||
|
||||
18:13 用户提供sku-sales-summary THIS_WEEK的500（requestId 33533b64-89029）已定位为共享Lastleg发布重启窗口的网关连接拒绝，并非查询SQL异常：Lastleg #293 SUCCESS、镜像38958c891ae7（贴标申请/仓储转运；自营与Nacos路径无差异），容器18:10:38启动，18:10:55才监听9303；用户18:10:46请求落在启动窗口，Gateway记录Connection refused，sync-overview同期亦失败。18:12:36原参数真实HTTP复查200/code200、206ms，sync-overview亦200、111ms，会话已退出；容器healthy、非OOM，无本轮额外发布/重启。采集未因该排障停止：10/11已两仓完整发布，10/10—12均完整，队列已自动启动10/09根LXCOL-20261013-AE0BA5AEBA1741E2；18:12:48仍RUNNING、509请求、账号无暂停，队列r3持续观察。证据：target/selfop-query-500-recheck-r1.json、selfop-ten-day-observation-2026-10-13T10-12-51-238Z.json。
|
||||
|
||||
17:55 用户明确授权本次恢复并指定间隔1s→1.2s。两端Nacos仅调整间隔至1200ms并一次重启；发现运行Lastleg已由其他业务更新为c07131b26fc1，fetch比对确认自营及Integration/config路径无差异，保留该镜像。恢复SQL在同一事务核对冷却结束、原累计5118/5116及限流2次不变、12000日限不变后，仅清复核暂停、改持久间隔1200ms并将原11日根DEAD→READY；保留91已采详情、原预算与20:38:02期限。r1前检因JSON布尔类型判断失败已回滚无变更，r2按实际布尔类型校验后提交成功。17:54:35实查原根RUNNING、139/263详情、无错误，账号pause=null、限流累计仍2次，实际请求持续增加；尚未完成11日发布。有限队列改为r3-seven-days继续运行，并修复本地队列把正常分片让出RETRY_WAIT/YIELDED误判失败的问题（真实DEAD/FAILED、暂停、限流门禁仍保留）；未修改后端源码。运行中config-proof-r5因HTTP与DB采样期间计数增长拒绝，不将其当静态预算一致证明。证据：target/selfop-recover-1200-config-r2-result.json、selfop-recover-1200-database-r2-result.json、selfop-business-sales-observe-r28-oct-eleven-r7.json、selfop-seven-day-queue-r3-seven-days-current.json。
|
||||
|
||||
17:43 用户反馈采集停止，实查10/11根 `LXCOL-20261013-BECACFDF93394FF7` 已于17:41触发 `LINGXING_WMS_HTTP_RATE_LIMITED`，根DEAD、最新run FAILED；已取91/263详情，本根98请求确认，两仓仍WAITING_SOURCE，未发布。账号暂停原因为RATE_LIMIT_REQUIRES_REVIEW，冷却至17:46:09.662北京时间，日累计5118预留/5116确认，日限12000、间隔1000ms、累计限流失败2；不是日额度耗尽。有限队列第2轮已按故障门禁停止于BLOCKED_TASK_FAILURE_NO_RETRY，未提交10/09及更早日期。冷却到期不自动清除复核暂停；本次只读定位，未改代码/配置/预算、未重试。页面突出展示等待来源的仓任务，不能从“待机/等待数据准备”判断账号真实故障。证据：target/selfop-business-sales-observe-r28-oct-eleven-r3.json、selfop-takeover-rate-stop-r1.json、selfop-seven-day-queue-r1-seven-days-current.json。
|
||||
|
||||
17:41 最近7日有限连续队列已在当前本机后台启动（target/selfop-seven-day-queue-r1-seven-days-current.json及同名前缀history/stdout/pid）。每45秒核对当前日，两仓发布后自动按11→09→08→07→06接续，保留10/10、12已有结果；未预建排队业务根以免提前消耗冻结期限。仅复用现有公开采集命令，不改后端源码/SQL/预算；日限、限流、未知结果、任务失败或剩余许可不足时记录BLOCKED并停止，5000请求预估门禁保持。最多运行至本轮22:36:59许可结束，且新根须保留10800+900秒；因此未承诺7天必能在现有预算/窗口内完成。17:40:45当前11日已81/263详情、87请求确认、无错误。后续是否仍运行与推进到哪一天，以该本机current记录及实际任务为准，不以本记录替代实时状态。
|
||||
|
||||
17:39 用户进一步明确停止后端改动，优先采回最近7个完整北京时间自然日（10/06—10/12），覆盖此前先10天/30天的当前执行范围；10/10及10/12不重复采集。17:37配对恢复BUSINESS并一次重启成功，日限12000、1秒间隔、单根5000请求/10800秒，累计5020/5018保留，新许可到22:36:59北京时间。17:38通过真实配置/运行/预算核验后已提交10/11根 `LXCOL-20261013-BECACFDF93394FF7`；17:38:50实查RUNNING、两轮目录263单一致、18详情，25预留/24确认、无错误，两仓待来源。10/09、08、07、06尚未创建，正准备有限连续队列；不得称7天已全部提交或采完。证据：target/selfop-takeover-resume-r1-resume.json、selfop-thirty-day-config-proof-r4.json、selfop-ten-day-2026-10-11-accepted.json、selfop-business-sales-observe-r28-oct-eleven-r1.json。
|
||||
|
||||
17:34 采集页/进度版统一发布完成：Admin #592 SUCCESS、运行镜像 `133654327df9`，Lastleg #291 SUCCESS、运行镜像 `ec7e9b36ecd7`，两者健康；Admin SCM已恢复release/test及原lightweight配置。接管后的运行核验80项通过，包含Jenkins提交、镜像身份、四页入口与资源hash；不替代人工视觉。发布后OFF复读5020/5018未变且正常退出。用户随后明确要求继续并尽快恢复采集，下一日期为10/11，恢复前仍须实查预算、配置与有界期限；本条覆盖此前“保持暂停等待”的安排。恢复结果单独记录，不能把本次发布成功当作采集已启动。证据：target/selfop-collection-release-admin-web-test-deployment.json、selfop-collection-release-baiyue-firstleg-lastleg-service-deployment.json、selfop-takeover-runtime-r1.json、selfop-build-guard-takeover-postdeploy-r1.json。
|
||||
|
||||
17:32 当前总控接管并执行既定采集页/阶段进度发布：Admin `133654327df906775d68bd563321b552fa22de4f`（包含远端 `260409c`）已提交推送，Lastleg 固定 `ec7e9b36ecd7f7e2297e29bfdeaf62aec4e686d2`；Jenkins Admin #592、Lastleg #291 已派发，结果与运行验收待确认。前端专项最终全量2985项通过，接管后相关141项复测及合入远端后的含类型检查构建通过；后端既有167项及最后四类65项通过，Gateway5项与发布辅助离线121项通过。17:30刷新证据确认12日根2787详情完成、两仓已发布、无活动根/run/租约/在途请求，双配置OFF且出口关闭，账号5020/5018未变。独立完整日查询修复本轮暂停，不纳入本次发布；不续11日、不恢复采集，视觉仍待人工截图确认。证据：target/selfop-business-sales-observe-r26-oct-twelve-r17.json、selfop-collection-publication-audit-r3.json、selfop-build-guard-takeover-predeploy-r1.json、selfop-window-release-continuity-r3-oct12-closed.json、selfop-takeover-admin-build.log。
|
||||
|
||||
17:22 只读连续性复核 r2-oct12-closed 再次确认 Lastleg/Integration 配置 OFF、领星出口关闭、配置 hash 未变，两容器健康且仍为17:08关闭后启动实例。12日页面完整性根因已定位为查询仅认连续覆盖岛；采集专项获得查询链及直接测试独占写权，实施版本绑定的独立完整日判断，内部只读审查并行核对证明不可变性，禁止用11日缺口伪造连续范围。前端专项继续按用户最新要求统一白色卡片与蓝紫色强调，尚未冻结；本批尚未发布。
|
||||
|
||||
17:15 关闭后真实HTTP核验发现查询覆盖问题：12日两仓经营总览分别返回已采集474/2414件，与单日趋势合计一致，但正式量为空、日状态PARTIAL；当前版本连续completeDay区间仍为10/10至10/11不含，因11日缺口未涵盖12日。selfop-oct12-http-verify-r1的两项完整日覆盖断言失败，其他范围/分页/固定版本/日合计检查通过，已logout、零领星请求。不能把此前任务coverage COMPLETE等同12日页面完整日验收通过；已交采集专项只读定位版本内独立日覆盖证据及最小修复，禁止伪造连续范围或续采11日。双配置OFF/hash及容器健康连续性r1-oct12-closed通过，额度不重置，最新前端仍收口中，尚未部署。
|
||||
|
||||
17:09 10/12根及两仓处理已完成并按用户要求关闭采集。根2787/2787有效详情、2843请求确认，SUCCEEDED/ROUTED；两仓SUCCEEDED/APPLIED/PUBLISHED、coverage COMPLETE，当前版本日记录分别155/1479、版本总数量474/4665（未当作12日单日HTTP验收数）。独立publication-audit-r2通过：精确关联/当前发布指针/就绪与修订干净、无活动根/run/租约/在途请求；r1在执行中按ROOT_INCOMPLETE拒绝。17:07两份Nacos关闭r27-pause-after-oct12后回读hash一致；按实际镜像Lastleg55764497c810、Integration39f914b3b574重启，17:09真实sync-overview为OFF、四scope均关闭、当日5020预留/5018确认保持且logout成功。未创建11日或其他根。证据：target/selfop-business-sales-observe-r26-oct-twelve-r16.json、selfop-collection-publication-audit-r2.json、selfop-business-sales-config-r27-pause-after-oct12.json、selfop-test-collection-close-restart.json、selfop-build-guard-oct12-close-r1.json。新前端仍按用户最新原型重构中，候选未部署；30日/10日历史仍未齐，人工视觉待验。
|
||||
|
||||
16:57 根2652/2787详情、2708确认，无错误，两仓仍WAITING_SOURCE。前一冻结单账号候选前端2987全量及构建通过，后端167通过；已提交并纳入远端其他业务更新后推送Backend ec7e9b36e（含146d468ff）、Admin c7d9af0（含bda0743），均未部署。用户随后在指标专项再次明确按原型重构并移除配置/详情，前端唯一写者继续实现，现CollectionView已有新改动；该版未冻结，r4前端测试/build-r3期间输入变化，不能作为新候选证明。12日完成两仓发布后先停采，保持不续11日，再待新前端冻结统一验证追加提交发布。
|
||||
|
||||
16:43 前端全量r2为2983通过/1失败，随后定位到用户在指标专项新要求“单账号运行看板”，该窗口compact布局与内部frontend采集页改动交叉，不能以混合输入测试证明最终版本。内部frontend已确认停写停测；现由指标专项唯一集成最新布局、组件及测试，总控待冻结后复测。旧完整多任务主屏设计以用户最新要求收敛，保留服务端来源证据、阶段数量及不虚构队列/总ETA。当前发布尚未执行，12日结束后暂停采集再统一更新的安排不变。
|
||||
|
||||
用户最新指令：10/12当前采集完成并经两仓归并/发布核验后先暂停，统一更新当前候选版本；本条覆盖此前自动续窗和继续11日的安排。不提交11日或其他日期根，不为下一日延长授权；待当前根与两仓处理达到安全结束边界后关闭采集、核对预算和状态，再统一发布。暂停的是后续采集，不是当前代码验证和更新工作。
|
||||
|
||||
16:33 采集继续RUNNING，详情2218/2787、2274请求确认，无错误，两仓仍待来源。合入03601ab0a后的后端167测试复测通过（maven-r2）；前端全量2984项中2981通过、3失败，均位于CollectionView.layout.test：旧fixture缺少新活动/依赖DTO、旧列断言，并暴露全部仓库共享来源去重摘要缺失，已交前端同包补齐后复测，不能将本次全量记为通过。当前无Maven/前端测试进程运行，前端实现仍进行；候选未提交部署。当前根结束后再续窗推进11日，不中途重启。
|
||||
|
||||
16:29 采集页改版候选已由四窗口和内部前端协作完成，尚未提交/部署。活动优先与直接依赖查询、阶段ETA、单轮询首页/居中详情已落盘；独立审查发现库存同run暂停恢复沿用旧snapshot，已修并补最终冻结回归；零量计数齐不推阶段完成，8KiB冻结优先保业务检查点。第一轮后端9类167测试全通过，Gateway5项通过；前端79项定向后追加2项边界测试通过，含typecheck构建通过。两条终态SQL在真实TEST MySQL的EXPLAIN通过（未执行UPDATE；r1因READ ONLY事务拒绝EXPLAIN UPDATE为1792，r2仅EXPLAIN成功）。已fast-forward纳入远端03601ab0a其他业务提交且保留未提交变更，正在进行合入后定向后端复测与前端全量测试。16:23实际补采2012/2787详情、2068次请求确认、无错误、两仓待来源，12日尚未发布；当前根不重启，下一日期在完成边界续窗后再提交。测试证据位于target/selfop-collection-redesign-*及selfop-collection-terminal-sql-check-r2.json。
|
||||
|
||||
15:51 只读复核：10/12 根仍 RUNNING，目录两轮已完成并一致为2787单，详情1292/2787，1349次预留/1348确认，无错误，两仓仍WAITING_SOURCE，尚未发布。已接收《数据采集页面设计》及交互示意；用户随后再次要求复用四个长期窗口，已移交查询合同与阶段ETA实现，并分别安排接口请求审查和发布续采清单，精确文件权见协作登记。内部前端继续采集页改版，两个内部后端写者已停止并交接。改版尚未验证或部署，当前根运行期间不为改版重启Lastleg；Admin已有其他窗口默认仓库和统计说明入口变更保留。
|
||||
|
||||
15:01 补采已真实运行：14:59创建10/12根 `LXCOL-20261013-0D70D251A9C5488F`，当前RUNNING、目录2787单、第二轮目录核验中、54次预留/53确认、无错误，冻结5000请求/10800秒，期限17:59；共享授权至19:44:43，账号当日上限12000、最小间隔1秒、首429停。14:43预算事务已成功，仅提高日限，保留2177/2175累计、冷却和失败记录。启动脚本先后排除两条已证明不可运行的旧DEAD根WAITING_SOURCE子任务（不删除/修改它们），修MySQL1093同表子查询限制，并修API长整型字符串的数值比较；r1事务回滚、r2失败后的只读复核确认原值未变，r3提交成功。配置证据r25-campaign-enable、实际运行proof-r2、任务接受记录及 `target/selfop-business-sales-observe-r26-oct-twelve-r1.json`。期间测试Lastleg被其他发布更新至89a05a234812；已fetch核对该提交包含cebcdfb66且差异仅贴标/仓储业务，没有自营采集/数据库/配置变动，保留运行新版本。当前只建12日根，待发布边界再继续11日，10日不重复。30日目标未完成，不能把当前目录扫描当成已发布销量。
|
||||
|
||||
13:49 用户继续截图验收并重新授权补采。销量／总览的自定义日期已改为单一范围选择，草稿不污染已应用分页与趋势；Admin 1de73b5f1c95、#587 SUCCESS，2966测试及含类型检查构建通过，运行镜像健康、四页资源检查通过。总览历史日被全局STALE误降PARTIAL已修：Lastleg cebcdfb66ed4、#287 SUCCESS，19项定向及5项Gateway检查通过；真实15日查询两仓10/10分别为完整0/2251，其他14日未知，整体仍PARTIAL，证据 `target/selfop-dashboard-partial-http-verify-r2.json`。r1核验脚本把匿名仓别预期写反，已按既有发布证据纠正并离线反例验证，不改业务结果。官方OMP文档复核：WMS一件代发出库分页入参没有仓库筛选，库存分页支持whCode/whCodeList；继续账号共享发现并分仓，避免重复拉取。补采先12、11、9向前推进；启动预算核对被旧DEAD根的2个WAITING_SOURCE子任务误阻，r1预算事务已完整回滚、计数和2421原上限未变，正核对不可运行证据后修保护脚本，尚未声称12日已启动。日期视觉仍待用户截图确认。
|
||||
|
||||
13:24 发布后补验通过：四页相关8份懒加载JS/CSS均HTTP200、类型正确且与运行容器文件SHA一致，证据 `target/selfop-test-unified-chunks.json`；实际OFF复读r4仍2177/2175，无新增领星请求。后续补采遵守用户先暂停要求，等待其确认检查页面或恢复补采；没有以目标自动续执行代替恢复指令。
|
||||
|
||||
13:23 统一发布完成：Lastleg #286 SUCCESS、镜像496fc11b0af1；Admin #586 SUCCESS、镜像6bdaff3fdfac，两者健康。Admin XML发布脚本显式UTF-8后固定提交成功，SCM已恢复release/test及原lightweight=true并回读确认；此前500无配置落地、无重复构建。后台入口资源HTTP200、四页路由及产物存在检查通过，不替代人工页面操作/视觉验收。10/10两仓完整销量与总览HTTP、库存10/30窗口HTTP已通过；用户可在销量页选仓并设自定义2026-10-10至2026-10-10查看。当前采集保持OFF、未启动下一日期；完整10/30日预计可售天数仍待补齐历史日。部署证据 `target/selfop-window-release-baiyue-firstleg-lastleg-service-deployment.json`、`target/selfop-window-release-admin-web-test-deployment.json`、`target/selfop-test-window-admin-runtime.json`。本轮“10号拉完后统一发版”完成；人工验收、恢复补采及后置性能目标仍待后续推进。
|
||||
|
||||
13:21 实测：10/10完整日根 `LXCOL-20261013-1FBE16A284F54636` 已成功，2014/2014详情、2056次请求确认；两仓均于13:13:25发布COMPLETE/APPLIED且当前指针命中本次版本。第一仓完整日无出库，第二仓811条SKU/货主日记录、2251件。13:14配对Nacos关闭并重启，实际Lastleg OFF及账号累计2177预留/2175确认复核通过；没有续建12/11或其他日期根。Lastleg统一版本496fc11b0af1已由#286 SUCCESS部署，实际镜像健康；10/10两仓销量/总览真实HTTP通过，库存10/30天窗口真实HTTP r2通过。窗口仍缺历史日，预计可售天数保持未知；r1核验脚本误要求未知空字段必须存在，修正为仅显式UNKNOWN允许省略后通过，未放宽旧字段禁用。Admin统一版本尚未发布：config.xml POST返回500，回读仍原release/test、lightweight=true、#585未变；服务器SAX非法字符错误正在修正传输编码，未派发新构建。证据：`target/selfop-business-sales-observe-r15-full-day-r32.json`、`selfop-build-guard-unified-close-r2.json`、`selfop-full-day-http-verify-r1.json`、`selfop-inventory-window-http-verify-r2.json`及window-release部署记录。人工页面确认、后续补采及性能验收仍未关闭。
|
||||
|
||||
12:50 统一候选已集成并推送，尚未部署：Lastleg `496fc11b0af1213bd6c52ac97418ccec6195377d`；Admin `6bdaff3fdfac8c66040e992a9f6cb2934e99d482`（包含库存10/30窗口及采集展示修正）。指标对话最终报告2960项测试、typecheck、build通过，总控额外执行6文件54项交叉回归通过；后台工作区干净。共享来源进度按taskNo去重只展示一次，仓库行只显示本仓等待/执行；“自动采集”更名“采集开关”，不误称TEST会自动建根。12:49当前根1375/2014详情、无错误，两仓尚待来源；当前继续跟踪，发布必须在10/10两仓完整发布并关闭采集后进行，12/11不启动。正式预计完成区间13:10—13:20只是基于当前速率的估计，不是完成证据。
|
||||
|
||||
用户随后指定“平台销量｜指标与查询接口” `01a12f3f-ce73-75d2-8fe3-23d709c755d5` 的采集页面更新一并纳入统一版本。已读取并通知该对话：完成当前前端任务、提交验证结果后冻结，由本总控统一集成和发布；不自行部署或操作采集。其当前变更为区分当前采集状态/历史任务、等待说明、执行时间与心跳、阶段进度及数据准备任务的可读文案，仍在收口。共享 state.ts 的 WAITING_SOURCE 文案与活动态识别已随 Admin 9dcd991 纳入，其余变更待完整交接后验证。保留“10/10完成后暂停补采”的指令；不因统一版本安排提前打断当前根。
|
||||
|
||||
12:38 用户最新要求：只让当前 10/10 采集完成并发布，随后暂停，等待其他更新核对后再继续 10/12、10/11；本条覆盖下述立即续采计划。实查当前根仍 RUNNING，1038/2014 单详情，账号仅一个活跃根，两仓 WAITING_SOURCE，无账号暂停；尚未完整日发布。没有提交后续日期根，没有启动自动续采进程，TEST 定时规划仍关闭。停止本轮新的部署及配置/预算调整，保留当前根已有期限和预算。10/30 天库存窗口实现已提交并推送：Lastleg `496fc11b0`、Admin `9dcd991`，后端89项、Gateway5项、前端61项及typecheck通过，独立源码集成审查无阻断；均未部署，不能据此声称TEST页面已有新窗口。保留其他任务新增的 Admin CollectionView/TaskExecutionFacts 改动，未带入本次提交。后续串行采集及有界配置辅助脚本只在本机 target 准备并离线验证，未执行配置或预算变更；恢复前重新核对当前根实际发布、运行镜像和用户更新。
|
||||
|
||||
12:25 用户将本轮 TEST 真实销量采集目标扩展为最近 30 个完整北京时间自然日，即 2026-09-13 至 2026-10-12，由新向旧逐日补齐；先完成最近 10 天用于预计可售天数，再继续 30 天。当前实际运行仍是 10 月 10 日根，已核验 637/2014 单详情、679 次请求确认、无错误，两仓尚未发布；保留此根，完成后按 10/12、10/11、10/09 至 09/13 排序，不重复已完成日。每个日期完成账号发现与两仓完整发布后才提交下一日，不能预创建导致排队消耗冻结期限。现有账号预算及许可仅覆盖当前根，后续批次须在当前根完成的边界核对累计用量并配置有界预算/许可，不以本条记录冒充已启动 30 日补采。并行准备库存 10/30 天查询与指定截止日，公式为当前正品可售库存 ÷（完整窗口实际出库件数 ÷ 窗口天数）；缺日不补零、不伪装完整，零销量不除零。性能优化仍后置。
|
||||
|
||||
12:07 完整日新根 `LXCOL-20261013-1FBE16A284F54636` 已于12:04:28启动，范围北京时间10月10日00:00至11日00:00，两仓共享账号目录；冻结2300次/7200秒，许可至14:18左右，最小配置间隔1秒、首429复核、失败不自动重试。双扫描2014单一致，已进详情阶段，尚未发布，不能声称页面完整日已经可用。复核在12:03:47冷却结束后仅清除RATE_LIMIT_REQUIRES_REVIEW，保留rateLimitFailures=1、121/119累计及原冷却时间；账号日限提升2421、间隔1000ms，其余预算字段不变。复核脚本的JSON对字符串比较误报budgetUnchanged=false，独立只读同值实验确认未cast恒false、CAST AS JSON为true；该误报不当作已验证的原始预算全量hash，实际变更SQL仅写pause/updated_at，后续保护字段复读保持。证据 `target/selfop-rate-json-review-verify.json`、`target/selfop-rate-budget-r6.json`、`target/selfop-business-command-r15-full-day-result.json`，进度 `target/selfop-business-sales-observe-r15-full-day-*.json`。限流诊断DEBUG已关闭。
|
||||
|
||||
12:02 单AppKey阶梯实测结束，Integration #105已成功部署39f914b3b；3/2/1秒配置各20次均成功（各4目录、16详情），实际详情平均起始间隔分别3.770/2.789/1.863秒，平均调用耗时0.424/0.453/0.393秒。追加500ms档第6次请求（第二次详情）在实际735ms间隔触发HTTP429，立即停止，未重试；总计66次中65成功1限流，不能由单次429声称官方固定QPS。账号累计121 reserved/119 confirmed、rateLimitFailures=1、RATE_LIMIT_REQUIRES_REVIEW，持久冷却到12:03:09.018；两端Nacos已OFF并重启，完整日任务仍未提交。计划冷却后完成本次原因复核，保持计数、冷却记录及失败历史不变，以1秒配置新建全天根。证据 `target/selfop-rate-result-r1.json`（3秒）、`r3.json`（2秒）、`r4.json`（1秒）、`r5.json`（500ms）；r2混含前档日志不用于单档比较。Lastleg实际镜像仍c13bf96cb94b，未部署其他后端变更。
|
||||
|
||||
11:47 用户人工反馈销量缺失，当前验收未关闭，优先获取一个完整自然日。已选择北京时间10月10日全天（能衔接既有短窗），受控单请求探测确认账号目录2014单，双扫描加逐单详情基础2056次；首探测未发出供应商请求，重载适配器并自然冷却后第二探测成功，累计55 reserved/53 confirmed，原失败占用未退款。用户随后明确要求先实测单AppKey限流以加速，完整日任务尚未启动。现5秒为本地配置/构造器限制，不是供应商配额。Integration提交39f914b3b将BUSINESS/OFF间隔改为有界正毫秒、VALIDATION仍至少5秒，默认不变；新增仅DEBUG的脱敏实际请求起止日志，80项定向测试及5项Gateway合同通过，部署进行中。阶梯计划3/2/1秒、每档最多20次、总最多60次、单并发、首次限流/未知响应即停；只调整账号持久日限与间隔，保留累计计数和其他预算字段。任何小样本通过只证明本时段观测，不声称供应商绝对限额。
|
||||
|
||||
功能收口补充：MySQL事务补验r1未完成，0项provider查询通过，报告为MYSQL_EXIT_BEFORE_STATEMENT_COMPLETED；原OR式零残留查询独立执行也超时，不把此脚本失败解释为业务功能失败。随后按三个事实表PRIMARY id区间及仓日PRIMARY销量run定位，同一检查返回四表均0，exit0，确认本次合成数据无残留（`target/selfop-bucket-r1-indexed-zero-check.json`）。按用户加速要求停止该补验包，不再重跑或扩矩阵；MySQL该边界专项证据仍未取得。当前四页无已证实未实现功能，已部署版本可进入人工功能确认；既有H2边界、合成HTTP和权限证据分别保留，不混称全部验收完成。
|
||||
|
||||
11:24 用户要求加速功能收口，停止扩大验收范围。四页按已部署58df0ed与操作矩阵只读复核，未发现尚未实现的明确功能缺口，剩余人工操作/视觉确认单列；并发性能后置。只读入口权限已扩至全部12个GET×5类身份，60项全部通过、无缺样本，4个登录身份均退出；8个经营接口使用合成r5，4个采集入口仅读取已配置仓库运行元数据，未触发采集/恢复。证据 `reports/selfop-test-20261013/selfop-all-get-permissions-r1.json`。MySQL分桶事务验证为最后一个当前在执行补验包，不再追加新测试矩阵。
|
||||
|
||||
11:19 功能边界补验完成：现有客户身份三个自营查询均403/A0403；新增专项合成角色及平台账号，仅授一个sync权限，本人权限回读确认list=false/sync=true，三个自营查询均明确A0403拒绝。创建仅3次IAM公开API写入（角色/单权限授权/新用户），未修改其他身份，密码仅私密目录保存；全部会话正常退出，未发业务采集。七桶离线SQL测试已加强为每桶非空、30/60/90及±0.000001边界、同SKU不同货主、Dashboard真实classified身份与库存分页集合逐项一致，每页2条无重复遗漏并检查越界空页；11项DashboardSqlSemanticTest及Gateway5项通过，提交 `ed8c9b154` 仅测试，无需重部署。H2证据不替代MySQL/HTTP非空60—90/>90场景。真实出口仍OFF、预算53/52未变。报告 `reports/selfop-test-20261013/selfop-customer-denial-r1.json`、`selfop-sync-only-denial-r1.json`、`selfop-sync-only-account-r1.json`；测试日志 `target/selfop-bucket-identities-r1.log`。TEST真实采集继续按已确认有界样本，生产两个月首采不列作本轮自动执行项；并发性能后置、人工页面确认仍未关闭。
|
||||
|
||||
11:12 只读权限矩阵补验r2通过：现有专项readonly身份本人权限list=true/sync=false，dashboard、sku-sales-summary、inventory-coverage全部成功；denied身份list=false/sync=false，三个入口均明确A0403拒绝；匿名三个入口均401/A0401。两个已登录会话均正常退出。r1将业务授权拒绝误要求HTTP403而失败，核对现行GlobalExceptionHandler以HTTP200承载A0403后修正脚本，未放宽到参数错误或其他失败，r1报告保留。尚未覆盖客户身份和仅sync身份，不声称完整权限矩阵结束；没有创建账号、修改权限或业务POST。证据 `reports/selfop-test-20261013/selfop-functional-permissions-r2.json`。
|
||||
|
||||
11:10 Admin功能修复已发布：提交 `58df0ed9e3a5091fe8543692f32a73603076b343`，Jenkins `admin-web-test #585 SUCCESS`；固定提交发布后恢复SCM至release/test。运行核验r7的178项检查通过，包含实际镜像健康、Jenkins检出提交、四个SPA入口和资产hash、匿名API拒绝以及总览/采集页修复产物标记；这不替代人工页面操作和视觉验收。前端工作区干净；后端服务及真实采集开关未改变。证据 `reports/selfop-test-20261013/selfop-test-admin-runtime-r7.json`。
|
||||
|
||||
11:03 合成固定版功能HTTP补验r2完成：修正脚本无损十进制解析以支持指数及额外尾零后，26次串行Gateway请求成功并注销。两仓完整30日趋势守恒、切趋势范围不改变固定三榜/分桶、热销前10与Top100一致（候选10000/900，列表上限100）、最长消化时间榜前10一致；第二仓无出库榜48候选前10一致。非空分桶首3行分类及全部分桶总数守恒通过；60—90日/>90日两桶无非空样本，未验证全桶分页身份集合与完整权限矩阵，故报告仍标PARTIAL_COVERAGE。这是既有合成数据的真实HTTP功能证据，不是领星完整30日采集证据，不进行并发压测。报告 `reports/selfop-test-20261013/selfop-functional-fixed-r5-r2.json`。
|
||||
|
||||
11:02 功能修复本地验证完成：采集页跟随缓存返回后的仓库深链，离页停止轮询并取消在途请求；总览拒绝缺仓库的异常返回，不再自动改查首仓。新增KeepAlive切仓、隐藏120秒不轮询、迟到请求隔离及异常返回复现测试；Admin全量355文件/2948测试、类型检查和构建通过，当前修改尚未提交部署，人工视觉仍待确认。合成固定版HTTP功能补验r1已核对首仓完整30日趋势守恒，但在榜单对照脚本的十进制断言处失败并正常注销，不作为榜单通过证据；后续修正脚本后另留新报告。
|
||||
|
||||
10:56 用户调整执行顺序为先完成功能与数据正确性验收，再处理并发性能；原性能目标保留为最终未关闭项，不再阻挡当前功能联调。本轮工作区自营模块及导航定向测试96项、Admin类型检查通过，尚不代表未提交页面改动已部署或人工视觉通过。真实HTTP只读回查确认采集OFF、账号预算53预留/52确认未变并已退出会话。功能审查发现采集页KeepAlive后仓库深链未同步、总览异常返回可能被默认选仓清除两项缺口，进入修复；完整销量日/30日仍无真实采集证据，测试继续遵守有界采集范围，不自动扩为生产两个月首采。
|
||||
|
||||
10:46 分段定位完成：TEST默认关闭的局部诊断先部署4c9878c33/#284，Docker日志API只读读取连续超时且无输出，不能据此认为业务请求失败；随后部署响应头诊断c13bf96cb/#285。诊断仅显式TEST开关+三个GET入口生效，Mapper及Statement分别计数，固定方法名且无SQL/参数/业务身份。6项诊断测试、Gateway5项通过。r4诊断39请求全部成功且requestId逐条匹配（单用户每类3次、10并发每类10次，非P95验收）；各请求统计ReadMapper SQL固定6次。十并发样本平均Statement客户端耗时：总览report3028.44ms、daily1.89ms、context4.13ms；SKU清单page1166.45ms/count54.25ms/context3.98ms；默认库存page497.75ms/count48.14ms/context5.08ms。Statement时间包含JDBC往返和映射，不冒充纯服务器时间；BEFORE_BODY_WRITE未包含序列化。窗口digest存在其他请求且归一化摘要可能合并，不能替代逐请求证据；连接池等待未取得直接测量。定位支持集中处理report/SKU page，暂不重做认证或趋势。诊断开关已关闭并重启同镜像Lastleg，两服务健康；r5三接口回读确认诊断头均消失、数据版本一致、采集OFF、预算53预留/52确认未变且会话退出。证据 `reports/selfop-test-20261013/selfop-query-timing-r4-summary.json`。
|
||||
|
||||
10:30 库存优化完整复测inventory-seek-r2完成：用户暂停导致r1主动中断，无完整报告，不作为验收；恢复后确认无遗留压测进程、镜像d08ed2f2caa7及采集OFF，再以原r5/current三场景运行单用户60.21秒＋10并发301.41秒。并发1991请求零错误，库存663次P95=773.53ms（目标1秒，通过该场景），SKU销量664次P95=1382.06ms（未达1秒），总览664次P95=3106.58ms（未达1.5秒）。默认库存局部优化的HTTP收益已验证，不外推为全部库存筛选达标。轻量资源快照Lastleg CPU约单核21.92%、内存958.5MiB，没有应用CPU饱和证据；匿名Prometheus未取得连接池指标，不能推断无连接等待。文档规划已交接并修订；下一步为默认关闭的TEST局部逐请求SQL诊断，不重复窄投影/profile归并旧候选。证据 `reports/selfop-test-20261013/selfop-perf-read-r5-inventory-seek-r2-result.json`。
|
||||
|
||||
10:13 Lastleg #283 SUCCESS，运行镜像 `d08ed2f2caa7`、Lastleg及Integration均healthy。新版本真实Gateway60项检查全部通过，两仓分桶守恒、固定版本、非法范围拒绝及35件观测量保持；collectionMode=OFF、会话退出。正在执行同r5/current/三场景的inventory-seek-r1并发对照，完成前不更新性能达标结论。证据 `target/selfop-test-inventory-seek-ready.json`、`target/selfop-dashboard-http-r12.json`。
|
||||
|
||||
10:11 库存默认分页最后出库日优化已提交 `d08ed2f2c` 并启动Lastleg测试发布（queue7629，尚待完成）。仅ALL/AVAILABLE_DESC无分桶筛选路径，使用五维隔离及三列倒序LIMIT1；MySQL EXPLAIN证实密集样本索引反向每SKU1行，原路径366行并反复连接库存/销量。ABBA三场景结果逐字一致：A首页候选692/699ms对原799/789ms，A深分页712/717对811/784，B首页534/564对662/633。59项直接测试和Gateway5项通过；尚无新镜像HTTP/并发结论。另销量排序聚合状态简化候选在热态15日仅约1%收益，366日无收益，未采用；仍不能宣布整体性能达标。证据 `target/selfop-inventory-last-date-compare-r2-result.json`、`target/selfop-inventory-last-date-analyze-r2-result.json`、`target/selfop-summary-sort-state-compare-r1-result.json`。
|
||||
|
||||
10:04 汇总事务补验 r8 通过：1万 SKU/1日真实 MySQL 候选构建36.532秒，20次仓库日汇总写入全部位于真实 Spring 事务，行数与数量校验通过，原发布指针不变；未装配外部采集客户端。测试补强已提交 `2d7b6e438`，仅测试变化无需重新部署。运行回读仍 OFF，账号预算53预留/52确认，会话退出成功。10:05 追加只读查询候选：将总览 DISTINCT 物化屏障换为不截断 LIMIT，ABBA输出逐字一致，热态1497/1498ms对原1537ms收益有限；首次原查询2300ms不能作为稳定基准，暂不采用正式改动。证据 `selfop-candidate-build-r8.json`、`target/selfop-dashboard-materialize-limit-compare-r1-result.json`。
|
||||
|
||||
09:59 仓库每日汇总已部署并真实验证：Lastleg Jenkins #282 SUCCESS，运行镜像 `25db631ff772`。两仓基于既有事实 REBUILD 均已 PUBLISHED；第一仓该采集区间无销量，第二仓 23 条 SKU 日记录、观测 35 件，仍为北京时间10月10日01:00—01:09短窗口，不能当作完整日销量。关闭构建窗口后真实 Gateway 60 项检查通过，Integration 全程保持 OFF，领星预算仍为53预留/52确认。新 r5 稠密 fixture 的单用户60秒及10并发301秒均完整完成，并发1866请求（每类622）零错误；库存、SKU销量、经营总览 P95 分别1091.59/1412.22/3168.57ms，目标1000/1000/1500ms，仍未通过性能门禁。相较前一同场景对照总览3834.92ms有所降低，不能据此宣称全容量验收完成；后台构建并发、其他范围/榜单及人工视觉仍待验证。证据 `reports/selfop-test-20261013/selfop-perf-read-r5-warehouse-daily-r1-result.json`、`selfop-dashboard-http-r11.json`、`selfop-warehouse-daily-rebuild-observe-r2.json`。
|
||||
|
||||
09:46 用户已明确批准仓库每日汇总表，原设计决策阻断解除。后端 `25db631ff77227e0046bce988efb3f2b984349bf` 已推送：按统计版本/账号/仓库/日期同批原子构建六位小数汇总，发布前验证源行数并设置就绪标记，总览读取汇总，旧未就绪版本明确拒绝；版本清理保护同时覆盖新表。120项直接相关测试在修复后分轮通过，Gateway合同5项通过；MySQL临时表验证NULL、异常行、0.4+0.4及回滚重试，未改变真实业务数据。TEST已执行V22新表及就绪字段DDL，无旧版本回填。全新r5合成fixture11968200日行及2196仓日行生成成功；31日/366日新旧查询ABBA结果逐字一致，仓日读取约0.46—0.49秒（含连接），旧查询约0.72—1.16秒/3.27—5.94秒。尚未以此宣称HTTP性能达标；新镜像发布、真实版本REBUILD及并发验收正在继续。
|
||||
|
||||
09:15 趋势与SKU共享扫描候选验证：将31日窄字段事实物化为同语句CTE，供每日聚合和固定30日SKU聚合复用；输出全部日点及SKU聚合逐字一致。ABBA分开读取1401/1381ms，共享物化1481/1445ms，未取得收益。此为两个聚合的隔离对照，未实现完整dashboard改写，不外推为所有共享计划均无效；当前无足够证据支持继续这一改动。证据 `baiyue-firstleg/target/selfop-sales-shared-scan-compare-r1-result.json`。已向用户提出明确设计选择：是否允许新增按销量版本、仓库、业务日保存的每日汇总表；候选仅减少趋势/合计扫描，不能承诺解决库存与SKU榜单性能。回复前不建表、不改已发布口径；人工视觉证据仍待补齐。
|
||||
|
||||
09:13 销量聚合候选执行方式对照：相同30万日行、1万SKU输出按业务键排序后逐字一致。日期覆盖索引ABBA约1222/1106ms，强制SKU覆盖索引2451/2366ms；另一组默认聚合1246/1047ms，SQL_BIG_RESULT排序聚合1520/1353ms。两候选均更慢，未引入正式代码、索引DDL或部署。保留日期覆盖索引与默认聚合；不能据这些排除实验声称性能问题已修复。证据 `baiyue-firstleg/target/selfop-sales-index-compare-r1-result.json`、`baiyue-firstleg/target/selfop-sales-sort-compare-r1-result.json`。
|
||||
|
||||
09:11 正常完整数据查询诊断：在原稠密 fixture 上，将两版 profile 的 UNION＋回查替换为 UNION ALL＋条件聚合，ABBA 四次查询结果逐字一致；原 SQL 1604/1529ms，候选1520/1582ms，收益不稳定，未修改正式代码或部署。分别执行原 CTE 的 EXPLAIN ANALYZE，库存聚合服务器耗时约56ms（2万行），30日销量聚合约555ms（30万行，已使用日期覆盖索引，临时聚合输出1万SKU）；客户端连接等开销另计，不能以单查询计时代替并发验收。下一步优化重点是销量聚合成本，而非继续重写 profile。此次只读查询，未新增业务表、缓存或领星请求。证据 `baiyue-firstleg/target/selfop-dashboard-profile-union-compare-r1-result.json`、`baiyue-firstleg/target/selfop-dashboard-stage-analyze-r1-result.json`；性能门禁仍未关闭。
|
||||
|
||||
09:04 相邻真实销量补采已发布：09:02:30接受根任务 `LXCOL-20261013-13236515C8814E7A`，采集北京时间10月10日01:05—01:09；目录两轮一致7单、7份详情全部VALID，根请求9/9、冻结上限32次/300秒，09:03:17两仓均SUCCEEDED/APPLIED/PUBLISHED。连续销量覆盖扩展为01:00—01:09，第一仓该段无销量，第二仓累计23条SKU日记录、35件，较前版增加7件；仍非完整自然日。启用前首次配置请求因ISO时间精度解析失败被本地校验拒绝，writes为空，改用毫秒ISO后新操作成功，不重置账号预算。关闭两份Nacos配置并重启原镜像Lastleg/Integration后均healthy；真实运行回读OFF，日预算53预留/52确认、剩余预留额度28。关闭后Gateway60次总览/分桶/固定版本/范围检查通过，实际读到35件，正式全天量仍为空，会话已退出。证据 `reports/selfop-test-20261013/selfop-business-command-r4-next-sales-result.json`、`selfop-business-sales-observe-r4-next-sales-r2.json`、`selfop-business-sales-config-r5-next-enable.json`、`selfop-business-sales-config-r4-next-close.json`、`selfop-build-guard-next-sales-closed.json`、`selfop-dashboard-http-r10.json`。当前没有继续运行的采集任务；性能与人工视觉仍未关闭。
|
||||
|
||||
08:54 周期重载停用对照完成：用户于08:46:18停止site_total，实际systemd回读inactive/dead、MainPID=0；停止时Nginx工作进程更换为08:46:18这一批，08:53:57仍完全相同。沿用原稠密11,968,200日行fixture及current版本，对库存ALL／销量15日／总览15日执行单用户60.4秒＋十用户301.7秒；并发1,620次请求（每类540）、0错误、0拒绝worker，完整完成且跨过原08:49:32重载时点，未复现UND_ERR_SOCKET。支持site_total周期重载与此前断连相关，不把一次通过外推为所有场景永久稳定。容量仍失败：库存／销量／总览并发P95分别1160／1452／3835ms，目标1000／1000／1500ms；包装脚本LOAD_NOT_COMPLETED在本次表示延迟目标失败，实际phaseCompleteness=true、rawFailureSamples为空。采集前后OFF、日预算44/43未变、会话退出。site_total当前保持用户停止状态，未disable、卸载或恢复；notice日志仍由用户开启，后续可恢复crit但需记录人为重载窗口。证据 `reports/selfop-test-20261013/selfop-perf-read-r4-site-total-stopped-r1-result.json`、`selfop-perf-http-session-r4-site-total-stopped-r1-result.json`、`selfop-test-site-total-stopped-before.json`、`selfop-test-site-total-stopped.json`。剩余重点为正常容量优化与人工视觉验收。
|
||||
|
||||
08:45 宿主周期重载来源已定位：用户将主错误日志级别调整为notice后提供08:34/08:39的SIGHUP记录；总控只读进程观察于08:44:32捕获nginx进程2608869的父进程为site_total/PID1038，程序路径 `/www/server/site_total/site_total`。用户随后日志精确确认主进程295794于08:44:32收到来自2608869的SIGHUP，调用链闭合。08:35:26—08:41:30的360次已登录低频sync-overview请求全部成功，覆盖08:39:32重载，采集OFF、领星请求0、会话已退出；这只确认低频下未复现，不能认定并发断连已解决或重载必为其原因。下一步临时停止site_total做对照，未执行停用、卸载或再次修改宿主配置。证据 `reports/selfop-test-20261013/selfop-nginx-notice-probe-r1.json`、`selfop-test-nginx-process-window-at-0844.json`、`selfop-test-nginx-site-total-identify.json`；SIGHUP发送PID来源为本对话用户提供的原始日志。
|
||||
|
||||
本轮后续阻断核对：#281 已由 Jenkins 实时回读确认 SUCCESS，无该发布的在途构建；宿主 Nginx 错误日志再次读取仍被权限拒绝。入口断连原因缺少宿主日志／自动重载任务证据，正常数据容量仍未达标；每日仓库汇总表方案须先明确调整总览设计“不新增业务表”的边界，人工页面证据亦未补齐。当前自主修复转为等待这些外部输入，不标记整体验收完成；TEST 已发布短窗口样本符合受控测试范围，不将完整生产首采作为本次自动启用动作。
|
||||
|
||||
03:48 Lastleg #281 SUCCESS / `ca4e7086e91f` 已部署且 healthy。经营总览仅在完整30日不可用时省去不影响输出的SKU销量聚合、库存过期时省去库存聚合，仍保留两版profile候选、未知原因、独立daily已采集值和过期库存下可用的热销榜；普通库存/货主查询及完整新鲜总览的SQL保持不变，无新表或缓存。37项定向测试、Gateway合同5项通过；实际MySQL四种 complete30/stockFresh 组合与修改前编译SQL的结果逐字一致。单次诊断不完整销量分支1478→904ms、两项不可用1398→800ms，仅证明该次测量，不能替代正常数据的并发P95验收。初次H2全NULL类型推断失败仅在测试文字化适配中修正，未为H2改变生产SQL。发布后真实Gateway 60次检查通过，两仓库存、七桶下钻与28件销量样本保持一致；采集OFF、账号44/43不变、会话退出。宿主日志再次读取仍PermissionError；入口断连、完整日/30日销量、正式容量及人工视觉仍未关闭。证据 `reports/selfop-test-20261013/selfop-dashboard-unavailable-offline-result.json`、`selfop-dashboard-unavailable-compare-r1-result.json`、`selfop-test-dashboard-unavailable-ready.json`、`selfop-dashboard-http-r9.json`、`selfop-build-guard-dashboard-unavailable-postdeploy.json`、`selfop-test-ingress-nginx-access-recheck.json`。
|
||||
|
||||
03:35 #280 并发复测未通过：单用户60.2秒完成，十用户阶段104.5秒、548次启动请求后，销量请求在21.2ms内报 `UND_ERR_SOCKET`，随后脚本主动取消其余9个在途请求；538次成功样本的库存／销量15日／总览15日P95约1219／1491／4093ms，仅为中断段观测，未完成300秒且仍超目标。采集前后OFF、账号44/43不变、会话已退出。候选“总览缩窄DISTINCT物化字段”的实际SQL输出一致，但基线1595/1496ms、候选1532/1503ms的顺序测量无稳定收益，未修改生产代码。证据 `reports/selfop-test-20261013/selfop-perf-read-r4-current-common-pagefirst-r1-result.json`、`selfop-perf-http-session-r4-current-common-pagefirst-r1-result.json`、`selfop-dashboard-projection-compare-r1-result.json`。
|
||||
|
||||
入口断连新增定位证据：前两次首失败北京时间02:44:32.737与03:24:32.721，距各自测试开始约286秒／176秒，不符合相同脚本时长限制。宿主Nginx master未变，03:32与03:34的进程快照确认其工作进程分别于03:29:32、03:34:32启动，即连续两次精确间隔5分钟；与首失败时点吻合，仍须日志确认触发机制及因果。容器Admin/Gateway/Auth/Lastleg健康、0重启、无OOM，不能排除宿主入口换代；低频未登录连接复用/Connection close各150次均按预期401，仅覆盖鉴权前路径，不能替代并发业务验收。宿主配置可读，错误日志 `/www/wwwlogs/nginx_error.log` 当前Jenkins账号及非交互sudo读取均未成功；已向用户询问自动重载任务或只读运维入口，未停止未知宿主任务。证据 `selfop-test-perf-socket-diagnostic.json`、`selfop-perf-transport-probe-r1.json`、`selfop-test-ingress-workers-read.json`、`selfop-test-ingress-workers-recheck.json`、`selfop-test-ingress-nginx-read.json`。完整日销量、容量、人工视觉及每日汇总表决策仍未关闭；真实两仓库存和已发布5分钟销量样本可继续功能测试。
|
||||
|
||||
03:20 Lastleg #280 SUCCESS / `7ae91eb276bd` 已部署且 healthy，Integration 保持 `86e05a77e6b9` healthy。TEST BUSINESS 人工根任务已持久冻结请求上限和截止时间，派生、重试及跨 dispatch 共用，不再每批次重置；账号日预算独立保留。预算字段禁止旧实体整行回写，采集检查点锁后重读并拒绝终态，迟到响应不能恢复 DEAD/FAILED；完整本地构建可在不再出网的前提下收尾。既有任务表新增两字段、索引及约束，未新增业务表、未修改旧记录。423 项离线测试通过、5 项按原条件跳过，Gateway 5 项及实际 MySQL 18 个本地就绪判定场景通过。证据 `reports/selfop-test-20261013/selfop-business-session-offline-result.json`、`selfop-business-session-schema-r1-result.json`、`selfop-business-local-ready-mysql-r1-result.json`。
|
||||
|
||||
03:18 新增真实销量样本已完整采集并发布：北京时间 10 月 10 日 01:01—01:05 的账号目录两轮一致，23 单详情齐全，根任务 `LXCOL-20261013-464E3FB555C4459B` 跨多次 YIELDED 调度累计请求25/25，未重置冻结的40次／300秒预算；两仓子任务均 SUCCEEDED/APPLIED/PUBLISHED。与既有相邻样本合并后覆盖 01:00—01:05，第一仓无销量行，第二仓17条SKU日记录、已采集28件；这只是5分钟完整窗口，不是完整自然日。首次补采仅写配置、未重启 Integration，返回通用 `INTEGRATION_PROVIDER_FAILURE`，账号预留已扣但 authorize 未消费；原始细分错误未保存，不能据此断言供应商已请求。按不可热更新的出口配置重启两服务后，新会话经原有未知请求冷却正常完成。失败预留未删除，日累计44预留／43确认（剩余预留额度37），采集配置已关闭并重启生效，服务均healthy。证据 `selfop-business-command-r2-salesbounded-result.json`、`selfop-business-session-budget-r1.json`、`selfop-business-sales-observe-r3-salesbounded-r5.json`、`selfop-business-session-budget-r4.json`、`selfop-test-session-closed-ready.json`、`selfop-build-guard-business-session-closed.json`。
|
||||
|
||||
关闭后真实 Gateway 60 次统计回归及12次采集列表／详情／尝试查询通过，验证页面接口已读取第二仓28件样本、第一仓0件，并保持正式全天量为空；固定版本、七桶下钻、库存独立版本和范围拒绝均通过，会话已退出。证据 `selfop-dashboard-http-r8.json`、`selfop-business-session-http-r2.json`。当前可进行两仓真实库存、销量样本及经营总览功能测试；完整日／30日销量、正式并发容量及人工视觉仍未完成。每日仓库汇总表方案仍待用户决定，未擅自建表。
|
||||
|
||||
02:49 Lastleg #279 SUCCESS / `1fdd97808439` 已部署且 healthy，Integration 保持 `86e05a77e6b9` healthy。SUMMARY 先对完整候选按已采集量及原单位／未知资格排序分页，再仅为当前页计算日期完整性和订单数；总数、固定版本、并列排序与字段不变，不新增表。57 项定向测试及 Gateway 5 项通过。编译后的实际新旧 SQL 在两仓今日／15日／366日、主仓末页、辅仓零量／未知末页及主仓旧版本共8组输出逐字一致；主仓15日单次客户端 1123→905ms、366日 5109→3226ms，顺序测量不作因果百分比或 P95 结论。证据 `reports/selfop-test-20261013/selfop-summary-pagefirst-offline-tests-result.json`、`selfop-summary-pagefirst-compare-r1-result.json`。
|
||||
|
||||
发布后真实 Gateway 60 次回归及6项销量 HTTP 诊断通过：主仓今日／15日／366日约268／487／2751ms，辅仓105／131／386ms；诊断仍为15秒单次请求，不替代正式10秒并发容量验收。采集 OFF、账号预算18/18不变，独立会话已退出。真实两仓完整分页库存与经营总览可继续功能验收；完整销量日／30日仍未采集。证据 `selfop-dashboard-http-r6.json`、`selfop-summary-r4-http-probe-pagefirst-deploy-r1-result.json`、`selfop-test-pagefirst-shared-ready.json`。
|
||||
|
||||
本轮部署前对 #278 的正式三项复测失败：单用户60.6秒完成，十用户阶段运行209.0秒、1,011次启动请求后，一次库存请求在22ms内返回客户端 TypeError（未保存底层cause，不能确定网络根因），脚本主动中止其余9个在途请求；不将后续 AbortError 认作9次独立服务错误。该阶段1,001次成功样本的库存／销量15日／总览15日P95约1298／2088／3978ms，只是中断段观测，未完成300秒验收且仍超目标。本次未启动后台构建。随后容器检查确认Lastleg、Gateway、Auth均healthy、重启数0、OOM=false，不能仅据健康状态排除瞬时网络问题。证据 `selfop-perf-read-r4-current-common-nomerge-r1-result.json`、`selfop-perf-http-session-r4-current-common-nomerge-r1-result.json`、`selfop-test-postload-health.json`。#279尚未完成新一轮正式并发复测。
|
||||
|
||||
02:49 采集预算审计记录（该根预算缺口已于03:20修复，最新状态见上文）：当时账号81次／日是持久硬上限，已用18次；BUSINESS的40次／300秒仅是每dispatch内存预算，YIELDED后会续跑，并非整个测试采集根任务的持久硬结束。只有VALIDATION已有持久根预算，TEST BUSINESS扩大样本前须补齐明确的根会话截止与预算，保持缺页／详情不齐不发布。历史账号级一小时372单证据来自 `integration-service/target/lingxing-local/prerequisites-20261012T082631Z.json`，无仓筛选及当前账号指纹，不能宣称当前某仓仍有372单；若按该规模冷采，pageSize100双扫描加详情至少380请求，现有63次剩余额度无法保证完成。没有据此外推整日请求量或启动新采集。每日仓库汇总表仍待用户决定，人工视觉及全容量验收仍未关闭。
|
||||
|
||||
02:35 Lastleg #278 SUCCESS / `341b7635c785` 已部署且 healthy，Integration 仍为 `86e05a77e6b9` healthy。销量 SUMMARY 的 bounds 改为普通 SELECT，并在 counted 消费处以 `NO_MERGE(b)` 保持物化，消除无业务必要的全字段 DISTINCT 去重；不新增表、不改变字段或统计口径。54 项定向测试通过；两合成仓的今日／15日／366日及主仓旧版本366日共7组验证结果一致，所有计划保持 bounds 物化且无 Warning/Error；6组编译后实际 provider SQL 与先前验证候选精确一致（忽略空白）。单次15日客户端查询 1161→1073ms，年度顺序测量有缓存影响，不将全部差值归因于此改动。主方案原“源码尚未实现”过时段落已改为固定验收要求，部署进度仍仅维护本契约。
|
||||
|
||||
发布后真实 Gateway 60 次回归通过；密集合成数据的6项销量单次 HTTP 诊断均成功，主仓今日／15日／366日约361／724／4650ms，辅仓96／118／451ms，固定版本、记录唯一性、范围及未知／部分量规则通过。诊断请求期限15秒，不替代正式10秒负载或P95验收，全年主仓仍慢。首轮诊断因验证脚本误用内部字段 skuCode 而判记录重复；已依据公开DTO字段 sku 修复后重跑，旧失败证据保留，不认作产品接口故障。采集前后 OFF、预算18/18未变，会话退出。证据 `reports/selfop-test-20261013/selfop-summary-nomerge-ranges-r1-result.json`、`selfop-summary-nomerge-actual-r1-result.json`、`selfop-summary-nomerge-offline-tests-result.json`、`selfop-summary-r4-http-probe-nomerge-deploy-r2-result.json`、`selfop-dashboard-http-r5.json`。
|
||||
|
||||
资源只读核对：TEST MySQL仍为8.0.45、buffer pool 2GB；当前可访问Docker daemon未发现MySQL/MariaDB实例，不能据应用主机32GB推断数据库可用内存或调整其配置。实际数据库文件系统余量仍未知。销量15日一次ANALYZE约733ms，其中ranged物化435ms、bounds物化240ms，两个相关COUNT均未执行；无据将逐SKU补查或索引错误认作瓶颈。证据 `selfop-db-runtime-resource-r1-result.json`、`selfop-test-database-host-discovery.json`、`selfop-summary15-r4-analyze-r1-result.json`。全容量、完整销量窗口与人工视觉未关闭，每日汇总表方案仍待用户确认。
|
||||
|
||||
02:23 Lastleg #277 SUCCESS / `afd3bbaa3d7f` 已部署且 healthy，Integration 保持 `86e05a77e6b9` healthy；发布后真实 Gateway 60 次回归通过。相同 r4 主仓当前版本三项查询复测完整运行单用户 60.8 秒及十用户 301.7 秒，十用户 1,429 次零错误，每项 476—477 个样本。库存全部 P95 1,204.7ms（上一轮 3,213.8ms，下降约 62.5%），销量近15天 2,156.7ms，总览近15天 3,948.7ms；仍分别超过 1,000／1,000／1,500ms 目标，不能宣布容量达标。前后两次运行的后台构建结果不同，百分比是两次观测对比，不归因全部性能变化于单一改动。runner 退出 1 来自 P95 目标未达标；两阶段本身已完成，不把 wrapper 的 `LOAD_NOT_COMPLETED` 文案解释为测试中断。
|
||||
|
||||
本轮 r6 后台构建于 02:18:49—02:19:29 完整落在十用户阶段：10,000 日事实＋10,000 档案、40 个提交批次、40,221ms，176 次成功 HTTP 请求完整落在构建区间。独立只读审计确认 READY/COMPLETE、数量及订单数合计各 10,000、未发布、草稿 DEAD、租约释放；仅证明这一次本地 Java 构建器连接 TEST 数据库可与三类并发读重叠，不代表部署机构建 CPU、全年原单增长或全30case验收。采集前后 OFF，账号预算 18/18 未变，登录会话已退出。证据 `reports/selfop-test-20261013/selfop-build-r6-http-overlap.json`、`selfop-build-audit-r6-result.json`、`selfop-perf-read-r4-current-common-stockfirst-build-r1-result.json`、`selfop-dashboard-http-r4.json` 和 `selfop-test-stockfirst-shared-ready.json`。剩余读性能／全年容量、完整销量窗口、人工视觉与实际数据库磁盘容量仍未完成；每日汇总表方案仍待用户确认。
|
||||
|
||||
02:14 默认库存列表优化已提交 `afd3bbaa3`，Lastleg #277 发布中。仅 ALL＋AVAILABLE_DESC 且无分桶／有限正天数 selection 时，先用原库存资格与 NULL 末位排序选分页键，再为这些键聚合销量和历史日期；其他关注、排序、总览与计数保持原路径。初轮 H2 同名列歧义已通过显式日表别名及 JOIN ON 修复，最终 62 项查询／服务定向测试通过，没有跳过语义测试。实际编译 provider 的 A 首屏、A 末页、B 首屏各 100 行×21 字段与旧 SQL 全部一致（含 NULL 及排序），无 hint 警告；单次客户端 SELECT 基线/新路径分别 1425/876、1443/961、608/664ms，不代表 P95，小仓未见收益。对比销量近15天的索引提示则无收益：自然计划本已日期覆盖索引，1094/1141ms，不加无用提示。证据 `reports/selfop-test-20261013/selfop-stockfirst-actual-compare-r1.json`、`selfop-stockfirst-actual-plans-r1.json`、`selfop-stockfirst-offline-tests-result.json`、`selfop-summary15-r4-compare-r1-result.json`。发布后并发复测待执行，完整验收仍未关闭。
|
||||
|
||||
02:03 Lastleg #276 SUCCESS / `2c8c26490ac0` 已完成部署并核对镜像与 healthy；Integration 仍为 `86e05a77e6b9` 且 healthy。发布后真实 Gateway 60 次回归通过，两仓七桶全部下钻分页与计数一致、固定版本与库存独立版本核对通过，历史销量样本仍为第二仓已采集 4 件、正式全天量为空。采集 OFF、预算 18/18 未变，会话已退出。证据 `reports/selfop-test-20261013/selfop-dashboard-http-r3.json`、`selfop-test-profile-shared-ready.json`、`selfop-build-guard-after-deploy-profile.json`。真实库存及经营总览可继续 TEST 功能验收；十用户读性能、成功后台构建重叠验收、全年容量、完整销量窗口与人工视觉仍未关闭。每日汇总表方案待用户决定。
|
||||
|
||||
02:00 profileBatch 最小修复已提交 `2c8c26490`：内层查询指定订单→明细→采集记录→run→task 的连接顺序，并使用已存在的 stage observation 覆盖索引；过滤、游标、两个证据排名及 500 条批次边界不变。TEST 只读 EXPLAIN/SHOW WARNINGS 确认提示生效且无警告，7 项 Mapper 回归通过。r5 实际 10,000 日事实＋10,000 档案完整构建成功，用时 35,394ms；独立只读审计确认 READY/COMPLETE、数量与订单计数合计各 10,000、未发布、任务 DEAD、租约释放。采集 OFF、预算 18/18。本次为单构建复测，不替代失败的并发容量结论。证据 `reports/selfop-test-20261013/selfop-build-profile-plan-r4-result.json`、`selfop-candidate-build-r5.json`、`selfop-build-audit-r5-result.json`。Lastleg #276 已触发，部署结果待确认。
|
||||
|
||||
01:57 三项常用查询的当前版本并发验收完成：单用户 60 秒及十用户 301.8 秒均完整运行，十用户 1,109 次请求零错误，每项不少于 369 个样本；销量近15天、库存全部、总览近15天 P95 分别 2,245 / 3,214 / 4,189ms，仍超过 1,000 / 1,000 / 1,500ms 目标，容量验收不通过。同期 r4 合成构建提交 10,000 日事实和 500 档案后，profileBatch 优化器改用 task/run→stage→order 的连接顺序，观测执行 80 秒且反复扫描订单；已精确取消自身 SELECT，构建失败收尾，非自然超时、非成功构建。400 次成功 HTTP 请求完整落在构建尝试区间，不据此认定成功构建并发通过。独立只读审计确认任务 DEAD、租约释放、候选未发布，已有真实版本未更改。采集 OFF、领星预算 18/18 不变。证据 `reports/selfop-test-20261013/selfop-build-r4-http-overlap.json`、`selfop-build-audit-r4-result.json`、`selfop-build-explain-r4.json` 和 `selfop-perf-read-r4-current-common-build-r1-result.json`。正在修复 profileBatch 连接顺序；每日汇总新表方案仍待用户确认，不擅自变更现行设计约束。
|
||||
|
||||
01:48 构建增长 r3 已完成并独立回读核对：2 万合成订单生成 2 万日事实及 2 万档案，80 批提交，73,789ms，相比 r2 的一万档位约 2.06 倍；两档均只含一天事实，各执行一次，不外推一年密集数据或更大原单规模。r3 记录 842 次构建期 MyBatis 调用及分语句客户端耗时，非纯数据库服务器耗时；六次串行固定版本 HTTP 查询均完整落在构建区间且成功。候选为 READY/COMPLETE、未发布，任务 DEAD、租约和发布指针为空；日数量合计 20,000，档案 20,000。真实采集始终 OFF、请求预算 18/18 未变。索引基线、两个回归测试及显式启用的真实构建 harness 已提交 `bf693fab6`；本批无生产 Java 变化，运行镜像仍为 #275 / `d6891126560e`，测试库索引已直接应用并核对，无需为该索引重启服务。12 项本批测试（含真实增长构建）及 Gateway 5 项通过。证据 `reports/selfop-test-20261013/selfop-candidate-build-r3.json`、`selfop-build-audit-r3-result.json`、`selfop-build-growth-r3-summary.json`。十用户持续后台构建容量、物理磁盘增长及部署机构建资源仍未证明；不能将这两档通过解释为完整容量验收通过。
|
||||
|
||||
01:41 后台构建真实 MySQL 验收发现并修复另一个瓶颈：1 万合成订单的 `invalidFacts` 因 stage 缺少采集序号前缀索引，对每条订单重复按 object_type 扫描，01:37 观测该 SQL 已执行 128 秒；r1 最终连接失效（08003）且未提交构建批次，自身草稿已禁用。随后精确取消检查命中零条，未执行 KILL，不把该失败描述为人工取消成功。TEST 已在线增加 `idx_selfop_stage_fact_observation(observation_sequence,warehouse_code,object_type,validation_status,run_id,observed_at_utc)`，同一 SQL 实际计划变为每订单命中一条覆盖索引记录，总执行约 81.7ms；两份源码基线已同步。11 项 Mapper/Schema 定向测试通过，覆盖错仓、状态、对象类型和跨账号采集序号碰撞。
|
||||
|
||||
修复后 r2 完整候选构建于 01:40:46—01:41:22 成功：1 万日事实＋1 万档案，40 个提交批次，35,754ms；全部聚合写入在事务中，候选 READY/COMPLETE，发布指针未改变，独立草稿及租约已关闭。六次串行固定版本总览诊断请求完整落在构建区间并通过；仅证明该次本地 Java 构建器连接 TEST 数据库与单请求流可并行，不代表部署机 CPU 或十用户持续容量验收。前后真实采集 OFF、领星预算 18/18 不变。证据 `reports/selfop-test-20261013/selfop-candidate-build-r1.json`、`selfop-candidate-build-r2.json`、`selfop-build-index-analyze-result.json` 和 `selfop-build-r2-http-overlap.json`。增长档位及其指标继续验证。
|
||||
|
||||
01:33 Lastleg #275 SUCCESS / `d6891126560e` 已部署并核对镜像及 healthy。发布后真实 Gateway 60 次回归全部通过，两仓库存分桶及全部分页数量一致，第二仓历史短窗口仍显示已采集 4 件、正式全天量为空；采集 OFF。高密度 r4 单次 HTTP 探针六项全部返回并通过语义检查：主仓今日 1420ms、近15天 1351ms、366日 3978ms；辅仓依次 190/194/429ms。前后预算预留/确认保持 18/18，独立会话已退出。该诊断请求期限 15 秒，不改变正式容量的 10 秒请求期限，且每项仅一次，不代表 P95 或并发通过。证据 `reports/selfop-test-20261013/selfop-dashboard-http-r2.json`、`selfop-dashboard-r4-http-probe-deploy-r1-result.json`、`selfop-test-dashboard-shared-ready.json`。全年高密度容量仍未达标；后台候选构建并发与增长验收、完整销量窗口及人工视觉仍未关闭。已向用户提出是否允许按统计版本持久化仓库每日汇总，尚待确认，不擅自突破现行图表设计“不新增业务表”约定。
|
||||
|
||||
本批总览聚合优化：统计与三个榜单改为同一 SQL 共用一次物化结果；每日趋势固定使用日期覆盖索引，API 和统计口径不变。31 项定向测试及 Gateway 5 项通过；两个合成仓各三个历史版本、共 30 条只读 SQL 已执行，新旧全部统计字段、榜单和 366 日趋势逐项一致。主仓合并报告单次客户端约 1.50—1.57 秒，原两个查询合计约 4.37—5.75 秒；全年趋势单次客户端从约 11.47—14.70 秒降至约 5.13—6.09 秒，包含连接开销，仍不满足 HTTP 并发验收指标。证据 `reports/selfop-test-20261013/selfop-dashboard-r4-equivalence-all-six-r1.json`。不把 EXPLAIN 输出中的榜单子树 25ms 当作整条报告耗时，统计在预执行阶段物化的耗时未包含于该子树。
|
||||
|
||||
01:15 容量复测发现明确阻断：高密度 r4 主仓经营总览五个短范围首读约 3.70—3.84 秒（目标 1.5 秒），366 日查询在 10 秒客户端期限超时，运行已停止，尚未进入单用户持续及 10 并发阶段，不能据单次样本计算容量 P95 通过。前后真实采集均为 OFF，领星预算预留/确认保持 18/18，会话已退出。失败证据 `reports/selfop-test-20261013/selfop-perf-read-r4-current-all-r1-result.json` 和 `selfop-perf-http-session-r4-current-all-r1-result.json`；继续定位总览聚合查询，不调整样本规模或放宽时间门槛。
|
||||
|
||||
Lastleg #274 SUCCESS / `99d206eb0023` 已部署并核对容器健康。65 项定向测试及 Gateway 5 项通过；TEST 与两份 SQL 基线均使用销量日期范围及 SKU 顺序两个非唯一覆盖索引，线上原窄日期索引已移除，保留原业务唯一约束。原规模同参 SQL 对比中热销分页 341→292ms、统计 320→268ms，库存阈值分页 580→544ms、计数 381→340ms；366 天汇总使用 SKU 顺序覆盖提示约 921ms，原自然计划约 1426ms。四项范围查询及 366 天汇总结果摘要一致；这些旧规模单次计划不能证明新规模或并发 P95 达标。
|
||||
|
||||
新合成源 `selfop-perf-20261013-r4` 已于 01:08 提交 11,968,200 条日事实：主仓 10,000 SKU×366 日×3 版本，辅仓每版本 900 个有销量 SKU×366 日，另保留零销量与未知语义。r2 分版本审计确认六个版本行数、业务键数及每键 366 日覆盖一致；r1 全表聚合审计超时失败的证据保留，不作为成功依据。旧合成数据和真实领星数据均保留。主机只读证据为 8 CPU / 约32GB内存，MySQL 8.0.45 的实际 buffer pool 为 2GB；机器代理根文件系统可用空间不能推定数据库文件系统余量，后者仍未取得。生成和压测均不调用领星，采集保持 OFF。
|
||||
|
||||
00:52 经营总览真实 Gateway 验收通过：60 次只读请求，两个真实仓库固定版本重复查询一致；七桶全部分页核对且无重复业务键，桶计数与下钻记录数一致。第一仓 610 个候选＋282 个零实物排除＝892，第二仓 2,741＋2,661＝5,402。销量历史部分窗口仍只显示第二仓已采集 4 件，正式全天量及近30日日均保持未知；缺少完整30日销量的库存进入待核验范围，没有伪造可售天数或零出库资格。非法货主筛选、错误桶规则版本均被准确拒绝；采集 OFF，新增外部领星请求为 0，登录会话已退出。证据 `reports/selfop-test-20261013/selfop-dashboard-http-r1.json`。当前经营总览可在 TEST 功能试用；代表性并发容量及人工视觉仍待验收。
|
||||
|
||||
00:49 经营总览发布：Lastleg #273 SUCCESS / `a41c271a67d4`、Admin #583 SUCCESS / `b73dc0d410b75`；后端与 Integration 容器均 healthy，Admin 已恢复原 Jenkins 分支配置。后端 291 项定向测试、Gateway 5 项、Mapper 362 项注册及索引 1122 项检查通过；前端 100 项测试、类型检查及正式构建通过。Admin 运行验收 167 项通过，覆盖实际镜像与检出、四个自营路由、资源摘要、总览图表产物和匿名接口拒绝；不代替人工视觉验收。TEST IAM 已事务新增一个经营总览菜单及平台管理员关联，同事务推进 4 个关联主体权限版本；未替换原角色权限集合。总览真实数据与下钻验收及容量复测继续进行，不能据发布完成关闭整体验收。
|
||||
|
||||
00:41 已完成首次真实销量发布与关闭后 HTTP 验证。Lastleg #272 SUCCESS / `a84a9b730e6b` 修复人工短区间首个已证明覆盖的锚点，并排除未配置仓库派生任务。账号根任务 `LXCOL-20261013-4B44A835DA124894` 完成两次目录扫描及全部 3 个订单详情；两个真实仓库的子任务均 APPLIED / PUBLISHED / COMPLETE。覆盖仅为北京时间 2026-10-10 01:00—01:01：第一仓无本段销量事实，第二仓形成 1 条 SKU 日事实。真实 Gateway 自定义 2026-10-10 查询返回第二仓已采集出库量 4 件、PARTIAL，正式全天数量为空，日趋势与固定版本一致；其余未知 SKU 不显示虚构零值。该历史切片的销售状态为 STALE，不代表实时或整天销量。
|
||||
|
||||
00:40:30 两份 Nacos 已回读确认关闭；重启后 Lastleg / Integration 均 healthy，00:41:14 API 确认 TEST / OFF，00:41:40 关闭后销量仍可查询。当天预算预留/确认 18/18，无冷却或暂停，未重置预算。脱敏证据为 `reports/selfop-test-20261013/selfop-sales-http-r1.json`、`selfop-business-sales-observe-r1-sales-short-r2.json`、`selfop-sales-closed-check-r1.json` 和 `selfop-source-budget-after-sales-short.json`。经营总览前后端已实现但尚未发布；代表性容量、完整销量窗口和人工视觉验收仍未关闭。
|
||||
|
||||
2026-10-13 00:15 两仓真实库存均已发布且 Gateway 可查。Lastleg #271 SUCCESS / `ae1a80935775` 已实施用户确认的每仓一轮完整分页观测，保留缺页、重复键、范围和数量校验。第二仓新任务 `LXCOL-20261013-B512E9FD0CB04702` 在北京时间 00:14:28—00:15:00 完成 6 页、5,741 条唯一品质维度记录，全部 VALID，00:15:02 发布；实际库存列表返回 5,402 条货主＋SKU 记录。第一仓仍为 892 条货主＋SKU 记录（894 条品质明细）。17 项真实 HTTP 检查通过，包括两仓固定版本分页、采集起止时间、发布任务与概览一致及跨仓任务拒绝。当天预算预留/确认 13/13，本次新增 6 次，无冷却/暂停。00:15:29 两份 Nacos 已回读确认 OFF；00:16:27 重启后两容器 healthy，真实 API 确认 TEST/OFF，关闭后再次执行两仓 17 项 HTTP 检查全部通过，已发布数据继续可查。验收会话已退出，不重置账号预算。
|
||||
|
||||
Admin #582 SUCCESS / `cd3a32f37285` 已部署固定版本采集起止时间说明，18 项页面测试、类型检查及 145 项运行资源检查通过；后端 71 项定向测试和 Gateway 5 项通过。现在可以在 TEST 验证两个真实仓库的库存页；完整销量窗口、代表性容量与人工视觉仍未完成，不据库存通过关闭整体验收。脱敏报告位于后端 `reports/selfop-test-20261013/`。
|
||||
|
||||
23:54 第一仓真实库存已发布：Lastleg #270 / `51c0d77fd42b` 修复 BigDecimal 暂存前后指纹不一致；新任务 `LXCOL-20261012-2723D2B3AFB4436B` 发布 894 条品质维度库存，实际 Gateway 查询返回 892 个货主＋SKU 行，状态 VALID。第二仓后续完整双扫描因真实作业数量变化拒绝发布，另一次因重复键拒绝，均未拼接数据。两个完整第一轮均 5,741 个相同业务键，间隔约 5 分钟有 20 行数量摘要变化，支持采用采集区间观测语义。00:01 已关闭采集；跨日后只读预算为 2026-10-13 预留/确认 7/7，无暂停或冷却。完整销量窗口和人工视觉尚未验收。
|
||||
|
||||
查询优化后的容量 r3 已完成单用户约 60 秒、10 并发约 300 秒，无请求错误；仍有 15 个场景/阶段未达 P95 指标（10 并发 366 日汇总约 4.07 秒，目标 2 秒，部分库存/热销约 1.77—2.60 秒，目标 1 秒）。容量门禁仍未关闭，不能据库存发布宣布整体上线就绪。
|
||||
|
||||
23:35 真实完整库存首次执行存在发布阻断：两服务 `86e05a77e6b9` 已发布（Integration #104、Lastleg #269），容器 healthy；受控窗口启用并回读核对。第一仓人工库存任务 `LXCOL-20261012-1BEF85941FB14F9E` 完成 894 条双扫描，新增 2 次 HTTP，累计预留/确认 33；快照构建因 `SELFOP_INVENTORY_CONTENT_CHANGED` 失败，任务 DEAD、未发布，第二仓尚未启动。只读对 10 条暂存记录诊断发现 5 条重算指纹不一致，通过仅调整数值小数尺度（含负尺度/科学计数法）恢复全部 5 条原指纹，确认 JSON 持久化后的等值数量表示变化触发旧校验；修复进行中，不能据完整抓取声明库存页面可见。已先关闭 Integration 再关闭 Lastleg，配置回读通过并重启，两容器 healthy。证据 `target/selfop-business-observe-r1-warehouse-a-r1.json`、`selfop-stock-hash-diagnostic-r4.json`、`selfop-business-root-config-r1-close.json`。
|
||||
|
||||
23:25 完整库存采集准备：用户已取消每仓固定 5 分钟限制，允许按完整性选择时长。受控 TEST BUSINESS 改动 `86e05a77e6b909b8b501a4e994a5b5a7ebb49b90` 已提交推送，Integration 定向 74 项、Lastleg 定向 177 项和 Gateway 合同 5 项通过；Integration #104 SUCCESS，Lastleg #269 发布中。仅允许人工任务及可验证的派生任务，TEST 不自动计划两个月首采或定时复查；验证样本仍不能转为正式快照。配置尚未启用，完整真实库存尚未发布，不能据代码门禁声明页面已有数据。
|
||||
|
||||
23:16 容量 r3 已完整执行：Lastleg #268 SUCCESS，运行提交 `6e9f4b7932eaba630a0b62eab3bda2cc4b26b989`。原合成规模 1,656,408 日事实行，单用户 60.758 秒 / 198 请求，10 用户 301.401 秒 / 4340 请求，无请求错误或拒绝 worker；但 15 个阶段/用例延迟目标未通过，10 并发 366 日汇总 P95 4.070 秒（目标 2 秒），热销/滞销及部分库存查询约 1.77–2.60 秒（目标 1 秒）。因此完整压测阶段完成不等于容量验收通过；最大密度、并行候选构建等范围仍未验证。采集前后均 OFF，外部账号累计 31 次预留/确认未变化。证据 `target/selfop-perf-read-r3-result.json`、`selfop-perf-http-session-r3-result.json`、`selfop-perf-db-before-r3.json` 和 `selfop-perf-db-after-r3.json`；会话脚本通用错误 LOAD_NOT_COMPLETED 在本轮表示子进程因延迟目标返回非零，不能描述为压测中断。
|
||||
|
||||
23:02 验证任务可见性阻断已关闭：Lastleg `#267` SUCCESS，发布 `cbc316b34d3858577b80834df65268de272e5ed8`，运行镜像匹配且 healthy。普通 VALIDATION 根按冻结唯一仓码读取，无正式 scope 时可见；目录发现根仍不进入分仓视图。真实 HTTP r2 共 29 项通过，覆盖两仓出库／库存任务族的概览、列表、详情、尝试、20 条阶段计数、跨仓拒绝、目录根拒绝和 OFF 保持。r1 的六项计数失败为脚本将统一序列化的长整数字符串与数字严格比较，诊断确认实际值均为字符串20；按现行数字序列化修正断言后 r2 通过，没有修改产品数据或计数。关联本地定向测试 84 项、Gateway 合同 5 项通过；逐条 SKU 样本明细、正式统计发布、性能和人工视觉仍未完成。证据后端 `reports/selfop-test-20261012/selfop-source-visibility-http-r2.json` 和 `selfop-test-visibility-ready.json`。
|
||||
|
||||
22:40 后续只读复核发现未关闭项：按真实仓查询本次 VALIDATION 任务详情返回 B0001“任务不存在或不属于所选仓库”，因此暂不能将采样完成等同于采集页已可见；Collection 任务过滤与无正式 scope 的读取正在修复。原规模容量 r2 的首次读取中 366 日汇总约 7.03 秒，超过 2 秒目标；任务详情拒绝导致该轮在并发阶段前结束，不把未执行的 10 并发计为通过。证据 `target/selfop-source-task-detail-before-r1.json`、`target/selfop-perf-read-r2-result.json`。账号预算回查为 31 次预留、31 次确认，无冷却或暂停，采集保持 OFF。
|
||||
|
||||
22:36 最新真实领星小样本已完成并关闭窗口：仓库目录取得两个真实仓库（1 次 HTTP）；第一仓取得 20 条已校验订单详情、20 条库存样本（25 次 HTTP），第二仓取得 20 条库存样本、本次范围未取得订单详情（5 次 HTTP）。三个任务均为 SAMPLE_DONE，共 31 次已确认 HTTP；两仓均以 VALIDATION_SAMPLE_SUFFICIENT 提前结束，无后续重试，publishedAt 均为空。该结果仅证明有界请求、暂存与结构校验，不证明全仓完整、第二仓无订单或正式报表可见。测试模式按当前约定不发布真实销量／库存，正式报表仍不能据此宣布可用。
|
||||
|
||||
本批 Lastleg `#266` SUCCESS，发布 `b71380de3190e9be2ab55b5624b098ae201cd16d`，包含真实目录发现、单仓有界采样及查询优化；相关 163 项测试与 Gateway 5 项检查通过。采样后已先关闭 Integration 真实出口，再关闭 Lastleg 采集，Nacos 两份配置逐项回读一致；重启后两容器 healthy，真实 API 确认 TEST collectionMode=OFF，核验会话退出。额度与冷却记录未重置。脱敏证据位于后端 `reports/selfop-test-20261012/` 下的 `selfop-source-observe-r2-warehouse-a-r3.json`、`selfop-source-observe-r1-warehouse-b-r1.json`、`selfop-source-config-r1-close.json`、`selfop-source-closed-check-r1.json`。查询优化后的原规模容量复测和人工视觉验收仍未完成。
|
||||
|
||||
Admin 后续样式批次已于 `#581` 发布 `600fdcb4b4425443730c98ff2fd87e9628b4ae5c`：采集页统一工具栏、筛选与表格，销量／库存每日趋势及采集任务详情、历史、恢复确认按用户后续要求改为居中弹框。专项最终全量 2901 项、类型检查与构建通过；Jenkins SUCCESS，恢复原分支配置后 r4 对检出、容器、网页和资源等 145 项检查通过。仍待用户以 1920×1080、100% 截图确认视觉，不将资源校验当作弹框操作验收。证据 `target/selfop-test-admin-runtime-r4.json`。
|
||||
|
||||
Admin 前一批版本为 `#580` / `57c50e68768bdc04c9056dc57542ca1949ecc355`，已合并 SKU 优先展示、移除货主分页及远端其他业务更新。r3 核对真实 Admin 网页入口后，Jenkins 检出、镜像健康、三个自营页面、资源摘要、匿名 API 拒绝与库存模块货主分页移除共 143 项检查通过；不代表人工视觉验收。r2 因误用 API origin 检查网页而失败，报告保留，不能作为产品不可用结论。后续页面布局／弹框修改已包含在上文 #581。
|
||||
|
||||
本节最新配置补验：用户提供的统一环境文件原缺少 `REDIS_TOKEN_KEY_PREFIX`、`JWT_RSA_JWK_SET`、`JWT_CURRENT_KID`，导致 Integration `#102` 在环境预检处失败、未替换容器。已仅补齐这三项到用户文件及 Jenkins `firstleg-test-env`；RSA 密钥和编号与运行中 TEST Auth 逐值摘要比对一致，未轮换密钥，其他配置内容保留。预检缺项为 0，Integration `#103` 已 SUCCESS，发布 `e42d358e710f38ae612dea675568d0853b82e750`；实际镜像标签匹配、容器 healthy，`LINGXING_OMS_APP_KEY` / `LINGXING_OMS_APP_SECRET` 均已进入运行容器。采集仍为 OFF、WMS 适配 false，本次检查未调用外部接口；此结果只解除凭据注入阻断，不代表真实仓库采样或报表发布已完成。脱敏证据为后端 `target/selfop-env-reuse-proof.json`、`selfop-env-reuse-apply-result.json`、`selfop-jenkins-env-preflight-r3.json`、`selfop-test-source-loaded.json`。
|
||||
|
||||
经本轮用户明确授权部署 TEST、操作测试数据库及真实 HTTP，Integration `#101` 已发布 `3b137f8946602c553679c98ed7e02fba733e71b7`，Lastleg `#264` 已发布 `d782b2cd24d2e3854ff3f8ec61bc50838b84eaec`，Admin `#577` SUCCESS，固定源码 `533273769dad87bc694a82cdb88469f02d18c3b4`。两个后端容器实际镜像标签、健康及内部 HTTP 已核对；Admin 实际检出、运行镜像及健康一致，三个公网自营路由、静态资源与匿名 API 拒绝共 131 项独立检查通过，不代表页面视觉验收。Admin `#576` 在轻量检出提交号时失败，未进入部署；`#577` 改为完整检出成功后，任务已恢复 `release/test` 和原轻量检出设置。旧 `BAIYUE_RELEASE_ID` 环境值不作为镜像版本证据。
|
||||
|
||||
TEST 新建十张自营统计表，独立比对 221 字段、39 索引、9 CHECK 与当前基线一致；新增六项 IAM 权限及平台管理员六项关联。两个仅用于验收的最小只读/无权限账号已通过正式 IAM API 创建，密码仅存用户指定私有环境目录，验收会话逐次退出。配置仅在当前 TEST 命名空间的 `BAIYUE/lastleg-service.yml` 增加合成仓 `SELFOP-TEST-A/B`，原配置文本保留并核验保存前后哈希；Lastleg 重启后采集保持 `OFF`、预算 0，Integration 适配关闭，实际外部 HTTP 次数为 0。
|
||||
|
||||
合成查询样本共六表 71 行，来源标记 `SYNTHETIC-SELFOP-20261012`；使用当前来源账号键仅为验证现行界面和查询配置，不代表领星真实来源数据或采集成功。首轮 SQL 在前置检查处因无效列失败、未写数据，修正后 `r2` 成功。首轮真实 Gateway 验收 86 项中 80 项通过、6 项失败；归因为验收脚本误带货主概览分页参数、错误要求可选空值字段显式出现。按正式合同修正后 r2 完整 86/86 通过，保留未知不可当零的断言；未为通过验收修改产品或样本。全服务同步依赖合同补齐五类 Feign 和三类 HTTP 的实际访问、上下文与幂等登记，独立重跑 13/13 通过；Lastleg 内部门禁 12/12 通过。修复提交 d4dc4f875、HTTP 验收入口提交 b702ed9f4 均已推送，均为检查脚本变更，不需重复发布服务。现可开始合成查询、权限和采集关闭状态的功能测试，但不宣称整体验收完成。
|
||||
|
||||
真实 MySQL 发布事务补验已通过 4/4：实际 scope/run SQL 写入后故障注入完整回滚、已发布重放结果不变、同日后续发布保留首个代表及其数据、跨日发布不补记代表。测试直接调用生产发布服务的事务代理及真实 Mapper，使用独立合成账号与仓库，采集保持 OFF，外部 HTTP 为 0；不等同自然调度或真实领星采集验收。测试提交 `06de9b1c9`，与远端其他业务提交无冲突合并后推送 `e42d358e7`，未因测试源码变更重部署 Lastleg。
|
||||
|
||||
查询上下文自然过期补验通过：保存于 20:57 的原查询在服务端截止时间 21:27:10 后原样重放，返回 B0001 及明确刷新提示；新查询获得有效新上下文，登录/过期拒绝/刷新/退出 4 项通过，会话已关闭。未修改时钟、TTL、版本标识或原查询基准，证据为 `selfop-expiry-http-r1.json`。
|
||||
|
||||
代表性查询容量验收未通过：独立合成账号 `selfop-perf-20261012-r1` 的 A/B 仓共 11,000 个货主+SKU 候选、三个销量版本、1,656,408 条稀疏日事实、44,000 个版本维度行和22,000个库存行，六表计数与 manifest 一致。A仓单次366天查询约7.4秒，30日榜单约4秒，库存关注约2.5秒；10并发阶段首个366天查询超过10秒后自动停止，其余 AbortError 为联动取消，不能计作独立超时。单用户阶段实际63秒，10并发仅10秒，未完成计划的300秒，不宣称压测通过。专用会话已退出，采集保持OFF；原始失败、造数和前后数据库指标保存于 `target/selfop-perf-*`。当前只可做已覆盖的功能测试，容量门禁仍待SQL执行计划分析、优化及复测。
|
||||
|
||||
本轮原始证据位于 `baiyue-firstleg/target/selfop-*`，发布/查询证据稳定副本保存于 `baiyue-firstleg/reports/selfop-test-20261012/`。事务报告为 `lastleg-service/target/selfop-mysql-publication-*.json` 与 `target/selfop-publication-mysql-root.log`，四份报告均为 assertionsCompleted=true，亦已保存稳定副本。这些本地验收证据不提交源码。真实来源独占窗口验证、代表性容量/并发及人工页面视觉验收尚未完成；正式生产首采不属于本轮 TEST 环境操作。用户已确认无其他同时采集，TEST 真实小样本仍待安全凭据位置、真实仓库编码和当日预算交接核对，未开启真实出站。用户截图要求的 SKU 主视角调整正在本地验证，未将待发布页面计入上述 Admin #577 证据。
|
||||
|
||||
## 预约界面与柜次编号统一 TEST 发布（2026-10-12）
|
||||
|
||||
本轮按用户明确的 TEST 发布及独立 SQL 授权完成。Firstleg `#494` SUCCESS，提交 `c545a7719064c0dcd2f6cfc5d3e35844bf7cfee2`（包含柜次编号修复 `3cb4a5676`）；Admin `#572` SUCCESS，提交 `92bdd32f8679c64645a7e5f62bd58a505f2a1477`。运行容器镜像标签分别为 `c545a7719064`、`92bdd32f8679`，均 running/healthy；管理端首页与 `/healthz` 返回 200。本轮仅发布 Firstleg 和 Admin，未发布其他服务或修改 Nacos。
|
||||
|
||||
发布前核对实际结构及触发器后，停止 Firstleg，在停写窗口删除 `baiyue_firstleg.fl_container_booking.booking_no`、`uk_container_booking_no`，重建 `trg_container_booking_before_update`，仅移除旧编号比较并保留原有其他规则及定义者。执行前后均为 2220 条业务记录，`id + cabinet_no` 聚合校验一致；未删除业务行、未重编原有柜次号。实际结构核对确认没有依赖旧列的视图或外键。SQL 与回查证据为 `baiyue-firstleg/reports/cabinet-number-release-20261012.sql`、`reports/cabinet-release-cutover-result.json`；本次禁止回滚至依赖旧列的镜像。
|
||||
|
||||
Jenkins 首轮 `#492` 因三个船期复制测试使用固定日期而失败，数据库及服务当时未变更；仅修正测试日期为相对未来日期后，`#493` 完整 CI 通过 1769 项、跳过 9 项、0 失败，并构建镜像。相同提交的 `#494` 发布跳过重复测试执行，仍编译测试源码。此前本地受影响后端 116 项、部署合同 25 项，以及 Admin 测试、类型检查和构建已通过。
|
||||
|
||||
真实 HTTP 复核：2026 年 11 月到港日历返回 3 条记录，全部使用 D 开头的 `cabinetNo`、不再返回货柜 `bookingNo`，逐条与对应货柜详情一致；货柜列表按 `scope=ACTIVE` 查询 10 条记录，字段合同通过。首次列表探测遗漏必填 scope 返回 A0422，补齐后通过；未进行业务写入，专用登录会话已退出。提柜日历接口返回 200，但本次 10 月范围为 0 条，非空记录展示未在真实环境确认。证据为 `reports/cabinet-release-http-result.json`、`reports/cabinet-release-summary.json`、`reports/cabinet-release-runtime.json`。
|
||||
|
||||
本轮 UI 包含预约日历工具栏弹框入口、搜索区货物来源 tabs 及紧凑的计划开始/结束时段布局。上述运行与接口检查不替代视觉验收；1920×1080、100% 缩放的真实页面效果仍待人工截图确认。
|
||||
|
||||
## 采购样品履约 TEST 发布（2026-10-10，发布中）
|
||||
|
||||
采购版本已推送：Backend `a973be21033b46392e1d85af66e8b39bc836e44e`，Admin `302cc50a4bf6f619f0eaed2bfb0c6f823087437c`，Client 合并远端退货页面更新后的 `5751973c839ea73502db5db0dfe133200ab48bde`。后端聚合主/测试源码编译、网关 5 项和索引 1121 项检查通过；合并后的 Client 542 项测试及构建通过。本地通过不表示已完成环境验收。
|
||||
|
||||
按本轮 TEST 数据库授权执行采购 V14–V21 结构及 IAM V5 权限，全部退出码为 0，回查新增采购履约表 20 张、新动作权限及平台管理员授权各 13 条，资金来源引用和费用版本字段存在。原采购订单 105 条、费用 49 条数量未变；未删除、重置或回填购买、收货和资金事实，未重扣测试存量。旧订单废弃运输列尚未执行删除，当前代码和初始化基线已移除对应模型。证据为 `baiyue-firstleg/reports/procurement-schema-20261010-r1.json`，状态 VERIFIED。
|
||||
|
||||
Finance `#128` 与 File `#150` 已 SUCCESS，使用上述 Backend 提交，测试未跳过；Finance CI 报告 276 项中 1 项跳过、无失败，File 部署日志确认容器 running/healthy。Lastleg `#245` 已 SUCCESS（1670 项中 2 项跳过、无失败）；Admin `#542`、Client `#398` 已 SUCCESS，实际 Git 提交分别与上述两端版本一致。前端首次 `/build` 请求返回 400，确认没有产生构建后改用 Job 实际参数提交，原拒绝和正确队列均保留在报告。各任务原始队列及状态维护在 `reports/procurement-deployment-20261010-r1.json`，不得重复触发已运行任务。
|
||||
|
||||
只读真实 HTTP 预检确认新登录平台会话具备全部 13 项采购权限；洛杉矶收货仓具备联系人、电话和唯一 OPERATING 地址，可供本轮样本制单。`reports/procurement-http-preflight-20261010-r1.json` 误按 WAREHOUSE 地址类型筛选而失败；按服务端 OPERATING 契约更正后的 r2 通过，两次专用会话均已正常退出。未修改仓库主档；纽约仓缺少联系人、电话，不作为本轮样本前置。
|
||||
|
||||
正常路径真实验收 r1 在钱包前置处失败：脚本误将 Finance 的 data 数组作为分页 records 读取，未充值、未创建采购单；已修正脚本并补合同。r2 已创建独立客户、充值10元、下单审核及上传三类凭证，购买确认返回 S0500。TEST 日志证明 MySQL DATETIME 默认返回 LocalDateTime，被代码强转为 Timestamp；数据库回查订单仍 WAIT_PURCHASE/version=1、无购买事实/费用/资金请求，钱包 actual=10/frozen=0，事务完整回滚。证据为 `reports/procurement-sample-20261010-r1/report.json`、r2、`reports/procurement-purchase-error-20261010-r2.log` 和 `reports/procurement-purchase-rollback-20261010-r2.json`；两轮自身平台/客户会话均退出成功。
|
||||
|
||||
修复 `c0fbe2698b451b64473ccc065d653a0ee971bc94` 已推送，统一以 JDBC 4.2 读取采购日期，覆盖购买、收货、贴单、核费与进度查询，并补持久化类型断言；采购定向测试通过。Lastleg 修复版 `#246` 已 SUCCESS，测试仍启用。原失败购买请求按原键连续重放两次，返回同一费用和订单版本，最终只实扣1元且来源关联成功；钱包 actual=9/frozen=0。证据 `reports/procurement-purchase-replay-20261010-r2.json` 为 PASSED。
|
||||
|
||||
完整正常路径 r3 已在 TEST 通过：本轮新建并审核独立客户、充值10元，采购2件分2箱；货款1元实扣，海外分次实收与清单确认，预估2元只冻结，海外贴单交寄，逐箱国内收货，实际国际运费1.50元结算并释放差额，国内寄客户。关键命令原键重放无重复实收、发运或消费，客户终态与字段隔离检查通过，最终 actual=7.50/frozen=0；自身平台、客户会话均退出成功。证据 `reports/procurement-sample-20261010-r3/report.json` 为 PASSED_NORMAL_FLOW。该结果不覆盖尚未执行的异常、财务更正/退款、余额不足和完整权限矩阵。
|
||||
|
||||
已寄客户后的财务调整 r3 完成 51 项真实检查、35 次请求：国际运费目标由1.50调为2.00只补扣0.50，再调为1.00只退款1.00；超额原扣款退款被拒绝，旧更正请求重放保留原结果且不再次扣退。独立新增0.25元费用沿 FINANCIAL 入口结算。最终钱包 actual=7.75/frozen=0，原费用金额/汇率、核费确认时间、两段交寄及终态不变；自身会话退出。证据 `reports/procurement-financial-corrections-20261010-r3.json` 为 PASSED。
|
||||
|
||||
费用来源及客户边界 r3b 完成7项真实检查：4笔正额实扣来源在 Finance 均为 SETTLED 且未生成账单，Finance直接修改来源被拒绝；配置的另一客户账号不能读平台详情、执行采购财务更正或下载内部文件，merchant查询附加customerId不能改写认证范围。拒绝后费用/版本/交寄不变，两个会话退出。证据 `reports/procurement-isolation-sources-20261010-r3b.json` 为 PASSED；前一版 r3 在读取时将已结清预估误当有收费来源的实际费用而退出，未发送业务变更，r3b排除预估后重测。上述结果仍不覆盖余额不足、原冻结保留、USD汇率及全部平台动作权限矩阵。
|
||||
|
||||
余额不足及原冻结重试 r2 完成73项真实检查、60次请求：钱包实际9元、预估冻结2元时，实际国际运费11元返回SETTLE_ACTUAL_FAILED，原冻结引用/金额、钱包实际/冻结及账户版本均保持；寄客户被拒绝，未生成实际费用来源。为本轮客户补充5元后，按原实际费用版本重试并重放，只有一笔实际费用和一次国内交寄，最终actual=3/frozen=0。Finance只读流水补证原冻结仍为amount=2/status=SETTLED，只有FREEZE -2与CONSUMPTION -11，没有重复消费。证据 `reports/procurement-insufficient-20261010-r2.json` 为PASSED，以及 `reports/procurement-insufficient-ledger-20261010-r2.json`。
|
||||
|
||||
USD正常收费和目标更正 r3 完成34项真实检查、24次请求：使用已有业务月ACTIVE汇率创建0.10 USD独立费用，按原币×月度汇率舍入为CNY实扣；更正原币目标至0.15 USD仅补收舍入后目标与已扣的差额。原费用原币/业务日/汇率/月份保持不变，重放不重复收费，共享汇率版本未修改，已寄客户事实不变。证据 `reports/procurement-usd-20261010-r3.json` 为PASSED；最终该客户actual=6.55/frozen=0。上述验证会话均正常退出。全套平台细分权限、实物异常及UI仍待完成。
|
||||
|
||||
内置浏览器已准备 1920×1080 视口，但导航 TEST 管理端及随后读取 tab 均超时，尚未取得新版页面证据。完整真实资金链、权限/隔离、异常、两端视觉交互及请求量验收仍未完成。
|
||||
|
||||
采购平台细分权限 r2 完成345项真实检查、288次业务/API请求，240个权限矩阵单元全部通过：专用平台账号无国内/海外仓绑定，仅采购list可读取聚合详情及六类只读明细；分别仅增加13项新增动作及原有review/edit之一，其他写操作均返回A0403。有权原请求重放返回200，取消/撤回清单/过期版本编辑通过权限后由业务门禁返回A0409；完整订单投影与账户前后相同，无重复收货、交寄、扣款或退款。专用账号和角色已通过API停用，17次自身登录会话均退出。证据 `reports/procurement-rbac-20261010-r2.json` 为PASSED；r1只读预检误用权限字段code而非permissionCode，未创建角色/账号，退出成功。该矩阵每项权限选一个代表命令，不代替所有子接口、按费用来源判断的重试权限及各文件分类上传权限验收。
|
||||
|
||||
采购实物异常与全零费用补证：`reports/procurement-physical-20261010-r3.json` 在新建隔离客户上执行97次请求、106项检查通过，完成免费购买4件、实收合格2/破损1/多货1、短少1，逐项处置前收货完成被拒；超分配装箱拒绝，海外清单换版使旧面单失效，新面单须重新核对零元预估并贴单，国内分箱收货及一对一换包装后旧面单/核费资格失效，重新制单并引用原费用核定后整批寄出2件。末尾Python汇总把字符串件数直接求和而报错，未重跑写操作；`reports/procurement-physical-final-20261010-r3.json` 只读补验8项通过，确认终态、换箱测量、完整钱包不变与零元无资金引用；`reports/procurement-physical-zero-ledger-20261010-r3.json` 只读SQL确认5笔ZERO费用、0资金请求、两段各1次交寄。前两版r1/r2脚本误将无/api的客户Base直接拼认证路径而登录失败，r1未创建业务数据，r2仅创建独立客户；修正后统一使用已核实的/api入口。各自身成功登录会话均退出，不将脚本错误解释为产品账号或资金缺陷。
|
||||
|
||||
采购取消及异常关闭补证：`reports/procurement-closure-20261010-r1.json` 在另一新建隔离客户上验证购买前取消及客户查询、免费购买后接收合格/破损/多货和未到货来源；读取可空sourceId时脚本未处理JSON省略空字段而退出。按已有订单续验的 `reports/procurement-closure-final-20261010-r1.json` 验证缺少去向、数量不符及未解除阻断均拒绝，解除后关闭与原键重放成功；随后把含closed_at的完整流程快照误当不可变购买字段比较而报断言失败。`reports/procurement-closure-verified-20261010-r1.json` 按原购买请求和原实收逐字段补验15项通过：一份关闭、四份足额处置、购买与实收保留、无虚构交寄/退款、客户投影有关闭摘要、结束后继续收货/取消被拒，钱包仍全零。只读SQL `reports/procurement-closure-ledger-20261010-r1.json` 确认本客户两单分别CANCELLED/EXCEPTION_CLOSED、0资金请求、0交寄、1关闭及4处置。自身会话均退出。此证据覆盖零费用关闭，不代替存在正额扣款、冻结或未决退款时的关闭门禁验收。
|
||||
|
||||
采购分段实收更正：`reports/procurement-corrections-20261010-r1.json` 96项检查、87次请求全部通过。海外确认装箱后直接更正被拒，撤回清单后原实收停用但保留、更正及补齐后形成新清单；国际实际交寄后撤回和改写海外数量被拒。国内已核费/制单后将一箱合格件更正为破损，原国际交寄和费用不变，重新处置、完成国内收货、制单并引用原费用核定后只寄余下1件；原国际两箱记录与国内一箱结果同时保留，结束后更正被拒，客户实际详情和钱包不变检查通过。隔离客户准备及两端自身会话退出均成功。
|
||||
|
||||
采购预算及失败费用替代：`reports/procurement-budget-failure-20261010-r1.json` 验证零预算购买2元保存事实但不扣款，真实收货可登记、正式装箱被阻断；预算授权后货款核定、余额不足FREEZE_FAILED保留购买及钱包，未终止费用不能替代或异常关闭，终止后替代3元仍受2元预算上限阻断。该轮在测试充值时因脚本未带Idempotency-Key被A0400拒绝（未充值）；`reports/procurement-budget-failure-resume-20261010-r1.json` 对同一订单以独立幂等充值2元后继续35项检查、31次请求通过：终止的原2元费用不再可重试，财务替代1元使用新的费用/钱包身份，保留原币、业务日与汇率快照，原购买事实不覆盖，只实扣1元并完成来源关联，原键重放不重复，正式装箱可继续。自身会话全部退出。
|
||||
|
||||
采购缺汇率及错误购买：`reports/procurement-purchase-anomalies-20261010-r1.json` 53项检查、46次请求通过。独立客户两张测试单分别保存无有效业务月汇率的USD实付和买错商品的真实事实，均不核定货款、不生成费用；提高客户预算也不能使错误商品通过确认。两单均可记录真实收货并保存装箱草稿，但不能正式确认装箱，客户钱包始终零余额/零冻结。未修改共享汇率；样本保留待处理状态及来源证据，平台/客户自身会话退出。
|
||||
|
||||
采购预估变价和零实际运费：`reports/procurement-reprice-zero-20261010-r1.json` 101项检查、85次请求通过。原0.40元冻结在同金额重传面单后保留原身份，旧贴单不能继续交寄；变价0.60元第一步只释放旧占款，过程中不能交寄，旧变价请求重放不建立第二笔冻结。释放成功后新命令形成新0.60元冻结，国内实际运费核定零元只释放原冻结，不生成实际收费来源，最终两段各一次交寄，钱包实际余额始终1元。该样本继续使用前述失败货款替代订单，自身会话正常退出。
|
||||
|
||||
采购零预估及等额实际结算：`reports/procurement-estimate-cases-20261010-r1.json` 136项检查、122次请求通过。独立客户充值2元后两单完整履约：第一单零预估、实际国际0.50/关税0.10/国内0.20/其他0.10分别实扣及关联4个来源；第二单预估0.50、实际0.50在同一冻结身份结清。两单原键重放不重复交寄或扣款，合计实扣1.40，最终实际0.60/冻结0；自身平台/客户会话退出。
|
||||
|
||||
采购文件及按费用来源判断的重试权限：`reports/procurement-file-retry-rbac-20261010-r1.json` 168项检查、133次记录请求、110个权限矩阵单元通过。专用平台角色按list及9项独立写权限核对6种文件分类和5类资金重试（含FINANCIAL来源的替代货款）；只有对应权限可上传，6种分类共生成8份测试附件；已结算费用有权重试仍受业务状态拒绝，其他权限A0403。平台list可读取本单面单，错误订单下的文件读取A0404；除新测试附件外订单投影及钱包不变，另一替代订单完整投影不变。专用角色/账号停用、自身会话全部退出。
|
||||
|
||||
费用来源恢复的本地回归补强：提交 `373f1b2c1` 已推送，仅增强 `ProcurementFinancePersistenceTest` 的故障恢复断言。来源发布失败回滚后，恢复并重放原成功扣款回执只完成来源关联，保留原消费流水引用，资金请求仍只有原FREEZE/SETTLE两条；来源Outbox未发布时仍阻断发运，发布后解除。该H2持久化定向测试10项及Gateway路由合同5项通过，无业务源码、API或部署配置变化，本轮未主动触发服务重新部署；不把本地故障注入记为TEST运行故障注入。
|
||||
|
||||
测试库废弃字段清理已完成（2026-10-10，用户明确确认后执行）：精确执行 `reports/procurement-obsolete-columns-20261010.sql` 删除五个废弃列。`reports/procurement-obsolete-columns-execution-20261010-r1.json` 记录执行前后116条订单保留字段逐行摘要一致、五类子表数量不变、废弃列剩余0；未删除订单行。执行后的列表及三种订单详情真实HTTP四项通过，见 `reports/procurement-post-ddl-http-20261010-r1.json`。原只读预检报告保留其当时114条记录事实，不改写为执行结果。
|
||||
|
||||
采购两端UI验收进行中：用户确认后内置浏览器已恢复Admin登录、截图及控件操作；单次工具操作需约21秒，原15–20秒调用超时不能据此认定应用故障。1920×1080截图、DOM和脱敏网络证据保存于 `reports/procurement-ui-20261010-r1/`。采购列表业务请求2次（列表及客户选项）、详情聚合请求1次，均200且无逐行详情请求。发现本单文件操作列缺失下载按钮，已补slotName绑定与真实表格挂载回归测试；提交214b58b已由Admin #544成功发布（实际SHA为214b58b642dfd24f5b7d40752082ed7a4549d3ab）。部署后文件表三个下载按钮均出现，面单点击返回200/image/png；浏览器下载完成事件50秒超时，尚未证实文件落盘。整页重载网络缓冲截断，仅采用保留的目标文件请求证据，不统计该重载全部请求。采购页面34项、类型检查及构建、Gateway5项通过；全量2755项通过、2项失败，其中车队超时单独重跑通过，另一派送布局断言与未纳入提交的其他工作区改动冲突。其余Admin操作及Client页面验收未完成。Client已验证采购表单必填校验，并正常退出缓存的其他测试账号、以授权配置账号登录；尚未创建采购样本。Client监测初始化组合调用超过60秒，后续需拆成单次操作，不能据此推断页面故障。
|
||||
|
||||
采购收尾审计（2026-10-10）：`reports/procurement-acceptance-audit-20261010-r1.json` 已将需求第8节19项决定映射到第7节25项验收要求，逐项关联真实HTTP报告与本地行为/持久化测试，并记录证据层级限制。核对现存21份相关JUnit报告、136项测试无失败或错误；这不是本轮重新运行136项，也不把H2/外部边界Mock当作TEST故障注入或真实并发负载。`reports/procurement-deployment-recheck-20261010-r1.json` 只读复核五任务最后成功版本仍为Finance128、File150、Lastleg246、Admin542、Client398，均无运行中构建；Backend HEAD373f1b2c1与已部署Lastleg c0fbe2698仅有一份测试文件差异。审计结论仍为INCOMPLETE：五个废弃字段删除已按确认完成；浏览器已恢复并取得Admin列表/详情部分证据，当前继续处理下载入口和两端剩余页面验收。先前部署快照与浏览器超时记录保留为历史证据，最新状态见本节更新及后续部署报告。
|
||||
|
||||
采购客户端创建与审核页面补验（2026-10-10）：授权客户在真实客户端创建单商品、1件、USD零预算测试单 `ICSGS202610100001`（商品PROC-UI-20261010-r1，客户2097708157074210818），仅一次创建POST和一次详情GET；返回列表仅一次采购分页GET，全部200。公共报关待办另按约60秒固定轮询，不计作采购页面重复查询。详情展示完整节点、零扣款及冻结、结构化清单空态，无平台操作或内部附件入口；1920×1080截图和DOM、脱敏网络见 `reports/procurement-ui-20261010-r1/`。初次新标签截图不是目标视口，正式尺寸另存client-created-1920.png，不混算。
|
||||
|
||||
真实审核发现并修复：接口version与purchaseQuantity实际为数字字符串，旧适配器直接传递，导致本地pending校验报invalid pending payload，订单未变。提交 `fb062b5ec41dae1f6b5ed63be194b6f5d9b9c3d9` 在采购API边界核验并转为安全整数，覆盖订单/费用/装箱/面单版本、实收/来源/货物数量及文件大小，ID保持字符串；非法数值不默认为零。原始HTTP类型证据version-http.json和先红后绿API回归保留。模块139项、全量338文件2761项、类型检查/构建及Gateway5项通过。Admin #547已实际发布该提交，部署记录 `reports/procurement-admin-integer-deployment-20261010.json`。
|
||||
|
||||
部署后同一原订单真实审核通过，计划洛杉矶仓，进入待购买，审核按钮禁用且购买入口开放；Admin和Client详情显示同一审核时间，客户列表同步待购买。截图admin-approved-1920.png及client-approved-dom.txt为证。验证期间Client曾回到登录页，未查明原因；使用原授权配置正常重新登录后继续，没有重新创建订单。尚未完成本UI样本的购买、文件上传、收货、装箱、两段面单/交寄与费用表单验收，整体验收保持INCOMPLETE。
|
||||
|
||||
采购购买、海外实收与装箱UI补验（2026-10-10）：继续同单ICSGS202610100001，通过真实文件选择器上传TEST-ONLY-purchase.png并自动选中；明确登记USD 0、购买时间2026-10-10 08:56:00及预计到仓2026-10-11 09:00:00，成功进入待海外到仓。随后登记洛杉矶仓合格1/破损0/多货0，生成有效实收PR-473CB6B39EBB42F384A72007；单独确认全部到齐后进入待装箱。以UI-BOX-01关联原实收1件，保存20.25×15.50×10.75 cm、1.235 kg的第1版草稿。客户端刷新时草稿不可见；正式确认后进入待面单及预估处理，客户端刷新准确显示箱号、商品、规格、数量和相同精度箱规/重量。购买凭证未在客户详情开放下载。各节点DOM、草稿隐藏/确认公开对照及client-packing-confirmed-1920.png保存在reports/procurement-ui-20261010-r1/。仅合成TEST事实，无实际采购或寄送；本轮未修改源码或重新部署。仍待面单、预估、逐箱贴单、海外交寄、国内收货/费用及寄客户UI链路，不能据此宣布整体验收完成。
|
||||
|
||||
采购国际段UI补验（2026-10-10）：同单ICSGS202610100001真实上传LABEL分类测试图片，逐箱选择文件第1页，保存国际面单第1版及独立国内中转收件资料；UI-BOX-01对应TEST-EXPRESS / TEST-UI-INT-20261010-01。预估表单明确登记CNY0.01，首次返回冻结处理中，手动刷新后为已冻结、未扣款。独立只读账户快照wallet-before-estimate.json和wallet-after-estimate.json证明实际4.97不变、冻结0.02→0.03、可用4.95→4.94；快照自身HTTP会话退出成功。逐箱贴单初次工具check失败且未选中，点击可见箱号标签后正常勾选，保存09:40贴单时间后才开放海外交寄。确认整批1箱/1件于09:45模拟交承运方，生成PS-B45659A2591C4C78913B3408并进入国际运输中，国内收货入口开放。全部为合成TEST业务事实，没有真实采购/寄送；DOM、1920截图与账户快照见reports/procurement-ui-20261010-r1/。
|
||||
|
||||
客户端国际段补验暂未关闭：再次操作时已回到登录页，现存CDP缓冲截断且未包含导致跳转的认证请求，不能认定刷新故障或正常撤销；需要恢复监测并核对原因。当前Admin国际段完成、客户运输/冻结显示尚待补证，国内收货/实际费用/寄客户UI和文件落盘事件仍未完成。本轮无源码变更及新部署。
|
||||
|
||||
采购国内段UI会话中断定位（2026-10-10）：尝试国内实收时两次未保存表单被关闭并回到Admin登录页，明确提示“账号权限已变化…登记国内实收…相关页签将关闭”，国内实收POST未发生。重新登录后开启Network监测，未截断游标5→35记录登录200、权限200、详情200，289秒后同详情GET401/A0401（requestId bba47065-fdbc-4e15-b541-df72e1182ca2，traceId b325486e-6131-40af-ad6d-ad07c299031f）。成功请求带Authorization，失败请求无Authorization；仅解码原成功令牌的时间字段确认被拒时仍余1150秒，未保存令牌。区间没有refresh或logout请求，不能将此判为自然过期或服务端资金问题。证据admin-permission-change-dom.txt、admin-session-interruption-network.json、admin-session-401.json、admin-session-authorization-comparison.json位于reports/procurement-ui-20261010-r1/。源码确认Admin请求从localStorage读取令牌并同步跨标签页会话；已询问用户是否有其他任务/人员同时操作同一浏览器的登录退出或清理，尚待反馈，未自行修改认证/权限规则。本单仍为国际运输中，国内收货、费用、寄客户及Client后段验收均未关闭。
|
||||
|
||||
采购国内收货与费用UI补验（2026-10-10）：同单ICSGS202610100001真实页面成功保存国内实收PR-336065360AB247D78509DD2E，原箱UI-BOX-01合格1件、破损0、多货0，再单独确认国内收货完成进入待国内核费。上传VOUCHER分类测试图片；一次核定国际运费CNY0.01、关税零、国内运费零、其他不适用。提交前因正额项必填标签变化，自动定位把凭证选到关税项，核对表单后已补齐国际运费凭证才提交，未把此过程记为产品缺陷。首次返回结算中，刷新后原预估已结清、实际费用PF-F2AB3CBE08BF4EB2A3D6E456已扣款且来源关联已完成；wallet-after-actual-charges.json实际4.96、冻结0.02，对照原4.97/0.03证明本单结算0.01。国内面单保存第1版，最终客户资料从原单带入、寄件资料来自国内中转，TEST-DOMESTIC / TEST-UI-CUSTOMER-20261010-01对应原箱1件，国际段已禁改。国内段不要求独立贴单动作，面单和费用满足后寄客户按钮开放。当前待寄客户，最终交寄尚未提交。DOM、账户快照均在reports/procurement-ui-20261010-r1/。
|
||||
|
||||
采购UI验收阻塞已明确（2026-10-10）：重新登录的platform_admin身份，在随后同一浏览器进入原单时变为另一拼车测试账号pool_simple_1054a9e95fc4，仅车辆菜单可见，证据browser-identity-conflict.json及DOM/截图。此前多次非过期令牌消失和未保存表单关闭，现在已有跨验收会话覆盖的直接证据；不能通过反复登录继续互相覆盖，也不改应用正常跨标签页退出/权限机制。客户端原标签又被工具报告不属于当前浏览器会话，未继续操作。需协调独占验收浏览器或明确使用隔离浏览器环境后，继续最终交寄、Client终态/资金/附件显示和下载落盘补证。整体未完成；已通过的业务、资金和测试证据保留，不重跑造数。
|
||||
|
||||
采购管理员账号2恢复尝试（2026-10-10）：用户提供新管理员并明确要求写入测试验收环境变量。已在用户指定私有环境文件增加CHONGCHONG_ADMIN2_USERNAME/CHONGCHONG_ADMIN2_PASSWORD，保留原管理员键值；凭据未写入源码和报告。新账号admin1真实浏览器登录成功，可打开原单ICSGS202610100001且“确认寄客户”可用，但下一次操作前同一浏览器又切换为另一拼车测试身份pool_simple_656fa2915f04。最终交寄未提交，证据reports/procurement-ui-20261010-r1/admin2-identity-conflict.json及前后DOM/截图。新增账号不能隔离共享浏览器localStorage登录状态，需要独占当前验收浏览器或另行授权独立浏览器环境；未反复覆盖另一任务会话，整体验收继续保留未完成。
|
||||
|
||||
三个业务统一页面验收接管及采购终态（2026-10-10）：用户授权本采购对话向拼车需求、预约列表对话发送协调指令，复用既有三个对话，由采购对话独占内置浏览器。两边已表示停止浏览器操作，保留开发、测试及独立HTTP；预约明确无在途浏览器调用。职责边界见独立任务协作登记同日节，不创建额外对话。统一切换admin1后，登录、原单进入及最终交寄提交期间身份持续一致。采购ICSGS202610100001已通过真实页面确认寄客户，生成PS-570F68DB4CA545A284BDA72D；原国际PS-B45659A2591C4C78913B3408保留，两段各1箱1件，最终状态已寄客户、再次寄客户按钮禁用。仅TEST模拟事实，无真实寄送。admin-customer-shipped-dom.txt与admin-customer-shipped-1920.png保存在reports/procurement-ui-20261010-r1/。此前浏览器身份覆盖暂已消除；采购仍待Client终态/资金/附件展示及下载落盘补验，整体审计未完成。拼车、预约剩余页面清单继续由原对话交接，不以采购终态推定三业务全部验收完成。
|
||||
|
||||
采购客户端终态补验（2026-10-10）：以原单所属客户登录，ICSGS202610100001列表及详情均为已寄客户；11个履约节点、两段实际运单、1箱1件及20.25×15.50×10.75cm/1.235kg均一致。净实扣CNY0.01、预估国际运费占款CNY0.00，原预估已结清；客户页面未展示内部凭证入口。证据为reports/procurement-ui-20261010-r1/client-terminal-dom.txt与client-terminal-1920.png。下载完成事件虽超时，实际label.png与订单文件服务内容逐字节及SHA256一致，download-file-verification.json为VERIFIED。采购主流程两端页面与下载缺口已补齐，25项总审计仍待最终逐项核对；拼车及预约不据此宣称完成。
|
||||
|
||||
## 预约跟进与拼车简化 TEST 发布及验收（2026-10-09，持续验收中）
|
||||
|
||||
2026-10-10标题密度及错误耦合修正（未提交/未部署）：用户截图显示独占大标题区、空白工具栏、常驻业务解释以及A0404错误。Admin改为公共density-detail-title与三视图同行、compact间距，船期操作并入QueryToolbar actions；说明与requestId/traceId诊断默认折叠，错误仍保留重试。纠正上一批基础列表提前依赖未发布影响聚合接口的问题：基础列表固定读现有`/containers`，船期状态独立读`/impacts`，两个结果分别处理；后者失败不清空基础货柜、不显示假零待办、不开放船期写操作，不做失败后回退或模拟成功。预约10文件58项及类型检查/构建通过，证据`reports/appointment-compact-header-tests-r2.log`、`reports/appointment-compact-header-build-r2.log`。首轮构建发现测试Mock的回调类型缺失，补显式PlanningContainer后通过，失败日志保留。船期完整能力仍依赖匹配后端和新增表，尚未真实页面验收；本轮未部署、未SQL、未浏览器。
|
||||
|
||||
2026-10-10按用户文档审计修正入口偏移（未提交/未部署）：预约主入口收敛为“提柜与到仓／送仓与排车／预约日历”，保留预约列表菜单，业务标题美国预约总览；默认有权限的货柜列表，日历首次进入才加载，返回已加载日历不重复请求。取消独立船期变化主视图，将核对状态、负责人、行内处理和明确标识本页范围的待处理筛选并入原货柜列表，保留现有处理弹框。到港参考与用车计划默认隐藏、独立开关，预约数量只计提柜/送仓；资料不完整不再写成接口未加载，提柜超限和国家待核实分别提示。预约10文件56项及类型检查/生产构建通过（`reports/appointment-document-alignment-tests-r2.log`、`reports/appointment-document-alignment-build.log`）；首次测试因入口懒加载与文案断言未同步失败，原日志保留。未浏览器验收。货柜列表新聚合依赖当前尚未提交的船期影响后端和两表定义，不能只发Admin；本轮未执行SQL、发布或真实HTTP写入。送仓目的仓货量汇总、7/14/30天窗口、完整全局待办仍未完成，不以视图改名宣称完成。其他采购、拼车工作区改动未由A修改。
|
||||
|
||||
2026-10-10船期影响事务核心（未提交/未部署）：当前工作区新增`AppointmentForecastClient`、`AppointmentImpact/History/Mapper/Policy/Service`，一柜一个稳定业务事项；保留基准/最新观察、认领人及追加历史，同键按操作者精确重放，事项版本及最新来源双重校验，连续变化不覆盖待处理基准，结案后新变化重新打开。同一事项先锁定再读取观察，防止并发空预测覆盖新观察。两项H2/Spring真实事务测试覆盖重复观察、旧版本/新来源拒绝、竞争认领、历史失败整体回滚、结案后重开及来源失败保留状态；`reports/appointment-impact-persistence-tests-r2.log`通过，Mapper340扫描通过。`ll_appointment_impact`、`ll_appointment_impact_history`仅新增到模块和海外统一SQL定义，未执行测试环境SQL。尚缺下游预约/车次/外接承诺关系、公开权限接口、工作列表及Admin处理入口，不能声明船期闭环完成。A未部署/浏览器/真实HTTP写入，Maven已释放；本批不进入统一方正在发布的固定25aae449版本。
|
||||
|
||||
2026-10-10外接候选固定提交及船期依赖进展：外接候选后端精准提交`71111bf21bd3b36aed7ff7681bbee52074e2895c`（9文件、Lastleg、无SQL/配置变更），Admin提交`172cb05c78b928d658949eae413b38500a48d721`（5个预约模块文件）已在统一方释放推送窗口后推送。共享Admin全量340文件2786项及类型检查/构建通过，证据`reports/procurement-draft-admin-full-20261010.log`、`reports/procurement-draft-admin-build-20261010.log`，已核对日志。统一方报告Lastleg251已部署远端`12a5093b4`，本地后端分叉；A未推送后端、未merge/rebase/强推，须先由统一方集成已上线改动，不得发布旧候选回退。
|
||||
|
||||
船期影响新增Firstleg只读依赖提交`4b5b639adc7e79ffab5f9857e90c3127f7812876`（6文件，仍仅本地）：内部`POST /internal/firstleg/appointment-forecasts/batch`一次读取最多200个柜次最新两个到港船节点观察，未知ETA保持空、实际到港单列、来源时间明确时区未核实，不从订单快照或固定航程推算。3项定向测试、Gateway5项及Mapper339扫描通过，证据`reports/appointment-forecast-provider-tests.log`；无SQL/配置变化。此为依赖包，尚无预约侧调用，变化持久化、关联预约/车次/外接承诺及负责人处理结果尚待实施，不算船期影响闭环完成。A未部署、未操作浏览器，Maven已释放。
|
||||
|
||||
2026-10-10完整外接候选后续批次（未提交/未部署）：A在原确认范围新增`GET /appointment-planning/external-candidates`，通过Fleet只读适配器按原登记分页、美国目录及承运状态筛选；预约侧批量解析来源/覆盖，Admin在合批工作区切换头程/外接候选并保留选择，保存后刷新覆盖。本批无SQL/配置/权限码变化；后端12项含H2真实分页和方法安全拒绝通过（`reports/appointment-external-candidates-tests-r2.log`），前端50项通过（`reports/appointment-external-candidates-admin-tests-r3.log`），Gateway5项、Mapper338扫描通过。新增组件的DefaultRow类型问题已改用真实业务行类型；最终全局类型检查/构建留统一执行方窗口，尚不能声明通过。Maven窗口已释放。固定验收版本仍为后端721d92ac7/Admin0ca12de；不把工作区新代码并入该版本。船期影响正在核对权威Firstleg预测来源，尚未实现闭环；来货整链仍未完成真实验收。
|
||||
|
||||
2026-10-10跨日预约修复：核对总览方案第八节时发现FBA接口与页面均只按开始日期归入，跨午夜安排在次日查询漏失。后端改为当地时段区间相交，结束边界不包含，确认时间不借用计划结束；Admin在已加载日期内按覆盖日期展示同一业务记录并展示完整时段，切换日期不追加请求。后端候选更新为`721d92ac7be13ab5a0d9c4111ab95a7e9a0c71f9`，Admin为`0ca12de2f4d8156022d28b3274ddb9e0279e472c`，已推送未部署，无SQL。后端25项（含真实H2区间查询）、Admin49项、类型检查/构建和Gateway5项通过，证据`reports/appointment-overnight-tests.log`、`reports/appointment-overnight-admin-tests-r2.log`、`reports/appointment-overnight-admin-build-r2.log`。首次构建暴露新增测试使用get().exists()类型错误，改为find().exists()后通过，原失败日志保留。本次为FBA跨日修复，不将车次司机结束时间解释为收货预约时段；真实HTTP与1920×1080页面待统一窗口验证。
|
||||
|
||||
2026-10-10日历集成门禁收口：B车次日历交付已包含平台主体校验和SystemV时区拒绝，集成提交为`3a252dfc706c179f56d58d82bc2217f02d6d3fa1`。三服务集成回归中Firstleg、Warehouse通过，Lastleg发现原权限测试缺少新增CalendarService Mock和API合同数量未更新；补齐装配及真实方法安全代理的无权限拒绝/有权限放行测试后，后端最终候选`6e1d90aafe2061d0811e14ce0d382f8236d2c754`已推送。Lastleg全量1703项、零失败零错误、2项跳过，Gateway合同5项通过；证据`reports/appointment-calendar-integrated-services-tests.log`（保留首轮失败）和`reports/appointment-calendar-lastleg-regression-r2.log`（成功）。Admin候选仍为`e3038edd38279b3bc67d702b297021347ba60bd1`。统一窗口按Warehouse元数据提供端→Firstleg提柜/Lastleg车次→Admin发布，无SQL、无新增权限码和Gateway配置。本轮未触发发布；候选不能视为线上可用。
|
||||
|
||||
2026-10-10重新登录补记：用户关闭全部IAB并明确要求重新登录后，重新打开页面仍保留admin1会话；正常退出并使用用户提供的admin2登录，页面身份已确认，截图`reports/admin2-relogin-20261010.png`。此截图为登录证据，非1920×1080业务视觉验收；后续共享页面验收继续按统一窗口执行。待验项目包括新提柜/车次来源真实HTTP及权限、跨时区日期边界与缺资料展示、日格3条摘要、外接与头程合批保存及来货关联。船期变化影响和完整外接候选尚未闭环，不声明总体目标完成。
|
||||
|
||||
2026-10-10外接来源预约入口收口：Admin提交`e3038edd38279b3bc67d702b297021347ba60bd1`已推送未部署，包含前述提柜/车次日历前端。修复已确认承运BOOKING深链只能记录跟进、无法加入真实预约的问题，复用现有合批接口，不新增数据模型；同仓外接与头程混选、跨仓保留原选择、未知保存结果原键重试、已有预约不再提供新增均有测试。预约9文件48项及构建通过，证据`reports/appointment-external-arrangement-tests-r2.log`、`reports/appointment-external-arrangement-build.log`。仅关闭代码入口缺口，外接候选完整列表、浏览器完整保存及来货后关联仍待验收。未操作共享浏览器、未触发部署。
|
||||
|
||||
|
||||
2026-10-10车次日历前端已推送`b14d22b55ee6091026f219bffdf9d6d23bb8e349`，未部署；预约9文件45项测试及Admin构建通过（`reports/appointment-trip-calendar-admin-tests.log`、`reports/appointment-trip-calendar-admin-build.log`）。覆盖LA/NY跨日边界、DST重叠保留原UTC、无时区不落格、路线3站摘要、无权限不发请求；未知来源独立分页，不追加逐车详情请求。B的Fleet后端交付待补平台身份校验及SystemV拒绝，补齐后统一集成。配套发布单元为Warehouse元数据提供端、Lastleg车次端、Firstleg提柜端、Admin；尚未触发本批发布或页面验收，当前线上仍保持既有版本。
|
||||
|
||||
|
||||
2026-10-10车次日历依赖包：Warehouse内部历史元数据批量接口提交`83049ed9e5c93759f701b019cfc7c83c9ebcb41f`已推送、未部署；部署单元Warehouse，无SQL/公网路由/权限码变化。直接11项测试覆盖真实数据库公共归属、逻辑删除、停用仓、缺失/重复/上限及内部凭证；含空配置拒绝，Gateway门禁5项通过。B接入Fleet车次只读来源，A消费端未完成。待统一窗口配套发布，不能用源码通过推断线上可用。测试证据`reports/warehouse-metadata-batch-tests-r2.log`。
|
||||
|
||||
|
||||
2026-10-10提柜日历待发布包已固定：Firstleg提交`46ae8ab1c696d106d51e70e62298345a6af3b1af`、Admin提交`871c8c021b1489e8958b5e484d87c59905747f08`，已推送未部署。发布单元仅Firstleg与Admin，复用既有Gateway路径，不执行SQL或改权限码。提柜40项回归、另增方法安全/事实保持5项、Admin预约8文件39项、构建、路由5项及Mapper扫描通过。缺任一读权限、客户端主体拒绝；无权限不请求提柜来源并披露统计缺失；来源失败保留成功数据。后续需统一发布窗口、CI门禁和真实HTTP/页面验收，已部署版本仍见上文 #250/#132/#550，不以提交推定上线。A已释放Maven窗口，B继续车次只读日历合同。
|
||||
|
||||
|
||||
2026-10-10页面验收窗口交接：采购订单实施对话统筹唯一IAB操作，预约侧停止浏览器操作（无在途调用），保留用户指定新管理员登录，不登出/清存储。预约侧继续源码与独立HTTP，不修改采购验收账号、订单或客户；下一批Admin/Lastleg发布须先交付清单并等待统一发布窗口。当前未提交的提柜日历只读改动涉及Firstleg和Admin：原提柜时间按日期读取，实际提柜通过现有船节点服务批量获取；原跨域Mapper读取被静态合同拦截后已修正，`reports/appointment-pickup-terminal-regression-r2.log`40项通过，Admin日历18项与构建通过，尚未部署及页面验收。美国范围依据目的仓国家，港口国家/时区仍待核实，不声明全部美国预约总览完成。
|
||||
|
||||
|
||||
2026-10-10时区写入上线验收补记：使用用户新建管理员的独立HTTP会话，固定偏移被A0422/IANA原因拒绝，多时区州未显式选择被拒绝，单一时区州新建TEST目的仓自动保存America/Los_Angeles，正常接口回读一致，4项通过。首轮脚本误断言A0400，保留`reports/warehouse-iana-live-r1.json`；依据ResultCode.VALIDATION_FAILED=A0422及原错误原因复核后继续，`reports/warehouse-iana-live-r2.json`通过，未重新执行成功创建。此结果仅证明仓库时区写入规则，不是Admin页面验收；浏览器角色验收仍由B独占，A暂不切换其登录。
|
||||
|
||||
|
||||
2026-10-10时区修复已发布：Warehouse #132，提交47dc9e8bf6df9ea683e55263e45ca9841dea5fef，03:06:00Z健康；Admin #550，提交33e7e1e41baac1d82d13683bae3d5b419ec73f67，03:04:21Z Healthy，均核对实际提交。未执行仓库批量SQL。通过正常转运创建接口生成明确标记TEST的2箱验收货源（无实收/库存操作），资料完整的预约确认分支真实HTTP六项通过：保存、DST空缺时间拒绝、确认成功、纽约当地09点转换13点UTC、确认同键精确重放、旧版本拒绝。证据`reports/appointment-confirmation-fixture-r1.json`、`reports/appointment-confirmation-success-r1.json`。该测试未向真实外部仓库提交预约，不代表实收/排车/发车完成。
|
||||
|
||||
|
||||
2026-10-10正式确认补验：目的仓ABE3主档原为固定偏移UTC-5，现场只读核对US/PA/Breinigsville地址后，通过正常仓库编辑接口维护为America/New_York并回读验证（`reports/appointment-abe3-timezone-maintenance.json`），未批量改其他仓。当前9客户20票样本尝试确认返回A0400“正式确认前请核实货量并补齐真实FBA货件号或追踪号”，未推进SUCCESS，记录见`reports/appointment-confirmation-http-r1.json`；不把此负向结果算作确认成功。Warehouse新增/编辑/导入时区校验及Admin选项已修为IANA，Warehouse全量232项、Admin仓库15项及构建通过，尚未部署。初始化资料中127条无法仅凭州确定地点时区的地址保留待核实；源码基线变化不代表运行库批量维护。
|
||||
|
||||
|
||||
2026-10-10统一预约模型发布：后端提交`c4c1bddeec14fe1bae7c849823f09e38a9fc8fe7`经Lastleg #249仅构建门禁成功，#250发布同提交镜像`c4c1bddeec14`，02:47:26Z健康检查通过。按用户已授权范围重建预约主表及明细表（原2张预约、22行明细），新增幂等命令表；未改订单、库存或车次。SQL结果见`reports/appointment-unified-schema-apply-c4c1bddee.json`。旧测试预约关系随重建失效，不作存量回填；后续采用正常API新建测试安排。
|
||||
|
||||
本地Lastleg 1693项零失败、2项跳过；Admin首轮2770项通过、1项5秒超时，单文件11项复测通过，限制并发重跑全339文件2771项通过。Admin #548（901431f）因货源勾选回调TS7006构建失败，未部署；修正显式类型提交`320c2e44711a90f12b1c21a7be6f2590b2114db6`经Admin #549发布SUCCESS，02:49:55Z容器Healthy，日志确认实际提交。B已收到恢复TEST角色及原来货链验收通知，A暂不占用共享IAB账号窗口。
|
||||
|
||||
新后端真实HTTP `reports/appointment-unified-http-r1.json`为18项通过、12次请求，会话退出成功：9客户20票未建计划货物保存为同一无日期待确认安排，未伪造确认号/时刻；错误接仓点拒绝、同键精确重放、不同键重复占货拒绝、未定日期列表、只填计划日期进入日历且仅一条、后续编辑不改变创建命令重放快照均通过。此结果尚不覆盖正式外部确认、来货物化、销售浏览器权限及整体多类型日历/船期影响闭环。
|
||||
|
||||
|
||||
2026-10-10后续开发核对：正式FBA预约当前仍依赖入仓计划明细、外部预约号与预计装车时间，未建计划提前保存安排尚未完成。工作区新增跨客户合批核对及批量来源解析，20项后端定向与34项预约前端测试、类型检查通过；本批未提交发布，不能将核对预览当作可持久保存的预约安排。继续实施时必须补齐保存、并发占用和正式确认，不能只隐藏旧接口必填字段。
|
||||
|
||||
B原样本补证已读：`reports/fleet-capacity-pool-ui-simple-20261009-ui1/new-incoming-name-and-customer.json`为PASSED，原登记FB-2108714742102147074沿同窗补资料并确认，关联LB-ACY2-20261010-651779及WT-2OLDI4ZED3XOOGQR5P82OYW1N，新来货客户名称与权威客户一致；报告包含客户侧关联单摘要。B交付的1920截图记录Admin #546登记四动作及更多可见、排车完整DS/TR可见；prepare/publish/incoming网络证据分别2/6/3次，较早登记确认整段记录有截断，不能作为完整计数。真实收货仍待后续。B另交付FleetPoolOrderQueries及LocalLooseboardService两处客户文案修正、14项定向通过，尚待与A后续完整批次集中发布。
|
||||
|
||||
2026-10-10整柜共享跟进补记：Lastleg `#248`发布`24f5ccf7ff517649f7e52da8ca39511f2e4f10ce`，实际镜像`24f5ccf7ff51`于00:46:44Z为running/healthy；Admin `#546`发布`84488adf12aa4742f49e8acd88701a88f56d6717`成功，包含B交付的拼车登记操作列宽修正。整柜提柜/码头联系共用柜次来源，接仓联系按柜次和实际仓库保存，货源跟进入口仅追加FBA联系。此次未执行SQL，已有跟进表结构可承载新来源键；初始化注释同步更新不表示运行库注释已改。
|
||||
|
||||
本地Admin全量338文件/2760测试、类型检查与构建通过；Lastleg本地及CI各1677测试零失败、2跳过，新增事项隔离/权限/汇总等12项定向检查通过；网关5项、Mapper注册及预约OpenAPI校验通过。真实HTTP18项通过：来源读取、接仓归属、保存、精确重放、异内容冲突、跨事项拒绝、无关仓拒绝、拒绝后无新增，退出登录业务码成功。初次验收脚本将省略的空warehouseId当必有字段而KeyError，未执行写入；改为核对缺省空值后通过，不是服务端修复。报告`reports/appointment-container-http-20261010-r1.json`，发布证据`appointment-container-release-*-20261010.json`。
|
||||
|
||||
新页面实测1920×1080、devicePixelRatio=1：整柜视图返回324柜，首行TSTU2472410将2票/1客户汇总为1行；点击提柜跟进读到接口保存记录，页面再保存一条明确TEST标识的记录后历史1→2。截图`reports/appointment-container-ui-20261010.png`、`appointment-container-followup-saved-20261010.png`。本批真实样本仅1客户，跨客户共享由自动测试覆盖，仍待真实多客户同柜补证；新工作视图的浏览器请求计数尚未取证。整柜接仓弹框真实提交、未建计划正式对外预约、三方货源合批、船期变化影响和统一多类型日历仍未完成，不以此局部发布推定A整体目标完成。
|
||||
|
||||
2026-10-10页面验收补记：实际浏览器发现货源列表操作列、事项列及跟进历史列使用了错误的`slot`配置，虽然数据存在，按钮与事项未渲染。已统一改为共享表格的`slotName`并补真实DataTable/RowActions渲染与点击回归；前端31项定向检查、类型检查与构建通过，Admin `#543`发布`df4d3dfd66cf3bc8f4dd5433fa45de820a3bb9ad`成功。跨客户候选另发现旧来货未保存客户名称；新来货在写入前读取权威客户目录、保存名称快照，原键重放不再取目录，不回填旧数据。Lastleg `#247`实际检出`2c970f252d73e65dd5af546d5f5146701d6ff005`并发布同标签镜像，00:10:25Z健康；本地44项转运/来货测试通过，CI仍执行测试。前端对缺失名称明确提示，不以内部客户ID代替。
|
||||
|
||||
排车编号可读性修正：Admin `#545`发布`b835e52bcb9c85e07489e8290cbe5033b7a5eb27`成功，保留已合入的采购下载按钮修复214b58b，仅调整排车列宽与换行，不重启后端。合并状态全量338文件/2757测试中，唯一失败为布局合同仍写死380px；同步为新的260px后6项布局合同单独复跑通过，构建通过。该分次结果不表述为一次全量零失败；发布后排车操作按钮和完整编号的1920截图仍待B复核。证据`reports/appointment-fleet-final-admin-tests-20261010.log`、`appointment-fleet-final-admin-build-20261010.log`及`appointment-dispatch-width-admin-20261010-r1.json`。
|
||||
|
||||
1920×1080浏览器已核实：20票/12客户预约默认仅3个入仓码，展开20条时区域216px高、内容468px且可键盘聚焦；选择已有日期没有新增API请求。新增预约打开/搜索ONT8/选定仓库共3次GET（仓库初始列表、带关键词搜索、分页货物），无逐行请求。跟进打开后带入真实入仓码、柜号和目的仓，明确提示未预约及FBA资料缺失；页面保存一条明确标识的测试记录后历史2→3。此操作实际7次请求：来源解析、历史、写入401、一次refresh、权限读取、相同载荷写入重试200、历史刷新，未重复写入，不能称为零认证重试。截图与脱敏请求元数据在`reports/appointment-ui-20261009-r1/inbound-codes-collapsed.png`及`reports/appointment-ui-20261010-r1/`（`form-network.json`、`followup-network.json`、`summary.json`、`followup-saved.png`）。旧客户名称缺失样本保留，新快照真实造数仍待复核。
|
||||
|
||||
Lastleg `#243`发布`0d75e311d01eb7b7c3ece302a7d1720e96ddc222`；真实HTTP发现跟进首次响应含纳秒、数据库重放只有毫秒，补真实持久化回归并修复后，`#244`发布`040f3bbd93cf32afdb7aaf3bbec51c9e6a9733c6`成功，两次均显式`SKIP_TESTS=false`。Admin合并远端已提交修复后，`admin-web-test #541`实际检出并发布`2f23e30e204c56d446ac4c27f84882dc68a6ff29`成功；本地合并版本331文件、2665测试及构建通过。采购、财务等并行未提交实现未纳入这批提交。
|
||||
|
||||
TEST只新增`ll_appointment_followup`及`platform:appointment:followup`权限5107282，授予既有平台管理员角色4000001，没有重置既有业务表。初次Windows字符编码导致权限写入1366，已核实新表存在但权限/授权均未写入；随后显式UTF-8修正新表注释并完成两条授权记录，核对表为空、授权唯一及注释UTF-8一致。证据为`baiyue-firstleg/reports/appointment-test-schema-20261009-r1.json`与`r2.json`。
|
||||
|
||||
新货源查询、来源核实、无假约号的跟进保存、同键同响应重放、异内容拒绝、旧版本拒绝、只追加一条和错误目的地深链拒绝共9项真实断言通过，独立验收会话按refreshToken正常退出。证据为`reports/appointment-test-followup-20261009-r2.json`；r1保留首次精度缺陷，不能当作通过证据。只读预检r1的退出仅记录HTTP200，后续HTTP报告已明确早期空请求体退出返回A0400，不能据HTTP状态推定会话已注销。
|
||||
|
||||
拼车侧报告`reports/fleet-cross-simple-20261009-r1`记录751项检查通过、388次独立请求，覆盖同窗确认、来货、核量、自动排入原车、发车签收及费用唯一。后续UI前置在14:37:20Z遇到候选查询500；`#244`日志证实容器14:37:19.698Z开始替换、14:37:21.056Z启动、14:37:53.166Z健康，原样本需只读复核后继续，不能把发布窗口失败当作业务用例通过。
|
||||
|
||||
首次发布时新版本1920×1080页面和请求预算尚待验收；10月10日搜索仓、跟进弹框、入仓码折叠和相关请求计数的补证范围见本节顶部。整柜统一跟进、未建计划时正式对外预约、精确船期变化影响及统一多类型日历仍是业务实现缺口；本次发布和局部测试不表示美国预约总览或整个系统已全部完成。
|
||||
|
||||
## 报关资料菜单待办红标 TEST 发布（2026-10-09）
|
||||
|
||||
沿本对话TEST发布授权更新Firstleg与Client。Firstleg `baiyue-firstleg-firstleg #490` SUCCESS，提交`1202cafadfc11660ed0aa4132f7a8f2c4c329391`，完整服务及依赖测试1759通过、0失败、9跳过；Client `client-web-test #397` SUCCESS，提交`c0b151bc1542e010e1a20098fdc651b21f7bcceb`。实际两容器镜像分别`1202cafadfc1`、`c0b151bc1542`，均running/healthy。未执行SQL、Nacos或Gateway修改，也未创建业务验收数据。
|
||||
|
||||
红标按本客户待上传资料或待确认回执的柜次去重；刷新保留数量，0隐藏，99以上显示99+，失败显示带说明的红色!。客户端254项直接受影响测试、类型检查及构建通过。全量客户端534项测试中531通过、3项既有海外仓页面源码合同失败（贴标提交回列表、贴标文件分组、转运换标文件布局），相关源码本次未修改，不把全量测试记为通过。
|
||||
|
||||
真实`GET /api/merchant/v1/customs/pending-summary`未登录返回401/A0401；验收客户登录后返回合法非负数量，伪造客户参数不改变结果，重复读取成功，独立会话已退出。当前验收客户待办为0，未通过写入造数制造非零红标；非零待办的真实页面展示、处理后消标和1920×1080人工截图仍待确认。正向计数、同柜去重、客户归属、最新装柜计划、回执确认/打回状态由本地真实Mapper测试覆盖。
|
||||
|
||||
证据：`baiyue-firstleg/reports/customs-menu-badge-test-20261009/http.json`、`deployment.json`。业务口径见[报关资料与船期价格接入梳理](国内货柜履约/报关资料与船期价格接入梳理.md)的“客户报关资料菜单待办红标”。
|
||||
|
||||
|
||||
## 客户头程订单履约分类 TEST 发布（2026-10-09）
|
||||
|
||||
分类数量刷新体验后续修复：Client `client-web-test #395` SUCCESS，提交 `639b1ae22cea984f417808df79f61d5acbff2ce1`，实际客户端镜像 `639b1ae22cea`、running/healthy。切换分类时保留已确认数量，新响应校验通过后统一更新；同一分类重复点击不再请求，失败仍可重试。14项定向测试、类型检查及构建通过；仅更新Client，三项后端保持下述版本。本次动态视觉效果仍待用户刷新后人工确认。证据：`baiyue-firstleg/reports/client-order-progress-test-20261009-1740/count-refresh-deployment.json`。
|
||||
|
||||
用户本轮明确授权部署测试环境。后端总控 `backend-java #665` SUCCESS，固定提交 `d11abb78ac44fac1fe57ec89bdf467f6103af15f`，只选择 Firstleg、Order、Lastleg；完整 Maven 门禁3677项通过、0失败、11跳过。下游 `baiyue-firstleg-firstleg #489`、`baiyue-firstleg-order #185`、`baiyue-firstleg-lastleg-service #241` 全部SUCCESS。客户端 `client-web-test #394` SUCCESS，提交 `33d86d2a64ae26fc769cff1aa85128e3649079ee`。
|
||||
|
||||
发布后独立核对三项后端镜像标签均为 `d11abb78ac44`，Client为 `33d86d2a64ae`，四个目标容器均running/healthy。客户端容器健康入口成功，实际静态资源包含已报关、已清关、已排车、派送中及履约进度。此次未执行SQL、Nacos修改、网关发布、业务造数或业务状态推进。
|
||||
|
||||
既有测试客户通过真实工作台HTTP完成53项只读检查：遍历5553条订单（5547条正式单）、核对十类数量、新履约分类成员与进度一致、超过200条分页、不同页长切片、渠道筛选及伪造客户参数不能扩大范围；独立验收会话已退出。样本中装柜完成87、已报关16、已清关115、派送完成5，已排车/派送中/待上传资料均为0，因此本轮只证明这些空分类的查询与计数，不宣称有数据的排车、派送或报关待办业务场景验收完成。第二客户负向权限及1920×1080人工页面截图仍待确认。
|
||||
|
||||
部署证据：`baiyue-firstleg/reports/client-order-progress-test-20261009-1740/`（发布记录、前后镜像及健康、客户端资源检查）；HTTP证据：`baiyue-firstleg/reports/client-workbench-order-progress-20261009-1748/report.json`。部署与只读HTTP通过不替代完整写入流程及视觉验收。
|
||||
|
||||
|
||||
## 尾程商业来源 TEST 发布与验收（2026-10-09）
|
||||
|
||||
本轮用户授权发布并测试。本次商业来源改动只发布 TEST Admin 与 Lastleg，未发布灰度。Admin `admin-web-test #539`，提交 `7a9e91b7ce9bcfec7636ae2b3a012b0ddff24703`；Lastleg 最终 `baiyue-firstleg-lastleg-service #240`，提交 `023b28e31f72569efffc023ab3b3b981e971b14d`，均 SUCCESS，实际镜像标签及容器 running/healthy 核对通过。其他任务未提交的地图、排车改动未纳入本次提交；当前分支合入了远端已发布的退货相关更新，没有回退既有版本。
|
||||
@@ -38,6 +441,18 @@ H5发现并在当前工作区修复：错误提示残留、目的仓码误当托
|
||||
|
||||
本批国内H5补验：增加显式`--prepare-domestic-pda-h5 true`准备边界，57项脚本合同通过；灰度准备301项通过但报告明确`fullAcceptance=false/PREPARED_NOT_VERIFIED`。新柜TSTU1599289在灰度国内PDA H5领取，错码拒绝、正确箱码即时拣1箱、重复扫描数量不增；五类标识QA用途的合成图片及封签号保存、刷新恢复成功，H5提交装柜完成后服务端taskStatus/workflowStatus均COMPLETED。原2箱准确形成1箱LOADED来源＋1箱REMAINDER，数量守恒。图片仅用于上传/证据接口验收，不证明真机相机或真实实物装柜；打印/设备广播仍按用户后续真机确认范围保留。证据同批`domestic-h5-preparation.json`、`domestic-before-complete-task.json`、`domestic-before-complete-evidence.json`、`domestic-after-complete-task.json`、`domestic-after-complete-tree.json`。
|
||||
|
||||
本批跨客户预约补验：新建QA-GRAY-20261009-MULTI-01，将两个客户各一票货合为XLX7同一预约时段；相同命令重放不重复创建，详情回读2票/2客户，灰度Admin日历实际显示通过。该新样本仍待拣货，不能与前述已签收样本拼接为同一批完整履约。证据`gray-shared-appointment.json/png`。
|
||||
|
||||
本批H5断网补验：仅对本地修正版标签页模拟断网，交接刷新失败时任务与1/1拣货数量保留；恢复网络后重新读取成功、显示已签收。发现的`request:fail`已改为中文网络恢复提示，保留network/code/requestId/traceId诊断；215项测试及H5构建通过。发布候选`a7388914cdd1ae654efa08867edb51fc4e0b6e5c`仅包含dispatch.vue、dispatch-error.js及fulfillment-workflows.test.mjs，替代旧两文件候选；尚未建发布分支、尚未部署，发布授权待答复。证据`h5-offline-recovery.json`、`h5-offline-fixed.png`。此次仅覆盖读取失败与恢复，不覆盖写请求响应丢失；真机扫码/拍照/打印按用户要求延后，H5通过后再确认。
|
||||
|
||||
本批同货物闭环补验：预约QA-GRAY-20261009-MULTI-01的两客户货物在本地修正版H5连接灰度完成各1箱拣货；仅A完成时整车发车被B未拣门禁阻止。实际装载确认/理货通过后H5一次发车，两张排车DEPARTED且同车TR-E88E24A9D5C144D8。合成QA签收资料提交后两票DELIVERED，各签收1/剩余0，同键资料重放版本稳定；车次结案COMPLETED后分别释放测试车、司机。各客户30 CNY测试应收生成REC-261009-0003/0004并出账，客户分别确认及同键重放通过，越权读取对方账单均FIN_404，实收0，未执行付款。证据同批`shared-dispatches-departed.json`、`shared-receipts.json`、`shared-closure.json`、`shared-customer-confirmations.json`、`shared-h5-delivered.png`。
|
||||
|
||||
同时发现明确联动缺口：该预约回读仍SUCCESS/2票，而先创建的两张排车均fbaAppointmentStatus=PENDING且无预约号；当前DispatchService的预约字段取创建/编辑请求，未自动读取预约主记录，已绑定车次的排车编辑又被禁止。因此只确认同一批货物执行和财务闭环，不确认预约至排车的信息联动通过。已询问用户是否统一从货物预约记录读取，待业务维护规则确认；不直接改写已发车样本来制造通过。
|
||||
|
||||
本批权限/版本补验：灰度9项真实身份边界通过，覆盖平台读取预约、客户和海外PDA读取平台预约被拒、客户/国内PDA访问海外PDA被拒、海外PDA访问国内任务被拒、两类PDA各自合法只读访问，以及客户POST确认另一客户账单返回FIN_404。拒绝既包含HTTP403，也包含HTTP200+业务A0403，按完整响应判断，不以HTTP200当成功。证据`live-role-boundary-matrix.json`；不据此宣称所有角色全部权限覆盖。运行复核`runtime-followup.json`确认20个运行容器较基线无镜像变化、无新增停止、无运行中不健康项；海外H5仍3133aac01953，不能视为修复已发布。
|
||||
|
||||
10月灰度到港日历真实GET返回13条（ESTIMATED 5、ACTUAL 8），其中9条TSTU测试柜号；证据`arrival-calendar-live.json`。ACTUAL代表系统记录的实际到港类型，不证明实物到港或真实船司来源，不能将本批合成样本当自动查询验收。五项完成审计仍保留三类关口：预约/排车信息维护规则确认及后续联动验收、海外H5候选发布授权与上线复验、真实船司查询样本及供应商返回证明；真机按用户要求延后。
|
||||
|
||||
## 预约管理灰度发布（2026-10-09，完成）
|
||||
|
||||
用户明确授权灰度发布、已列明的结构及权限SQL，以及两个固定版本临时发布分支。后端PR25、Admin PR18合并后，源码树分别与TEST验证过的`7fd7699f6`、`73c29f5`完全一致；未纳入随后新增业务改动，发布分支已删除。本地工作分支未切换。
|
||||
@@ -1243,3 +1658,192 @@ Client #382（`a0736239e4ee4cd58b620dab912ffc0641360d9f`）正式页面在1920×
|
||||
|
||||
|
||||
|
||||
|
||||
统一角色页面补验（2026-10-10）：第二销售“我的登记”仅见FB-2108748109833093121，共1条，未出现第一销售FB-2108748108671270914；最小调度账号默认本人范围为空，切换全部登记后两条均可见。两者均未显示整车/排车导航。本次仅只读页面范围核对，不代表写动作或未部署日历版本验收。证据reports/fleet-capacity-pool-ui-simple-20261009-ui1/unified-role-review.json及对应1920截图。采购草稿修复已在工作区，模块140项、后端晚回执12项及Admin全局类型检查通过，尚未发布和真实页面验证。
|
||||
|
||||
采购更正草稿补齐（2026-10-10）：Admin #552成功发布2bf561bafe0b396cc615da95864aa1709e22ad06，checkout一致且健康检查通过。原单ICSGS202610100001使用admin1保存未提交金额/说明，刷新后恢复完整；只存当前浏览器标签页草稿，没有提交资金更正。截图与DOM见reports/procurement-ui-20261010-r1/draft-restored-*。Admin全量2786项、类型检查及构建通过；Lastleg晚回执12项本地持久化测试通过，不等同真实环境故障注入。运行Lastleg #251为12a5093b4；本地与预约候选/预测及采购测试已无冲突合并成25aae449，尚未发布，该合并不执行SQL。
|
||||
|
||||
统一配套发布批次（2026-10-10）：固定后端25aae44918c053b4c258d2b42386ebdb0f0800e5，合并保留已部署12a5093b4；本地聚合Firstleg1634项（9跳过）、Warehouse237项、Lastleg1717项（2跳过）均0失败/错误，Gateway5及Mapper339通过。Warehouse #133已成功部署25aae44918c0，容器healthy；Firstleg #491已检出固定提交并运行，Lastleg与Admin候选172cb05尚未发。本批不执行SQL，也不包含尚未完成的船期影响持久化闭环。证据reports/unified-release-candidate-20261010.json及各服务release报告。
|
||||
|
||||
采购25项分层验收收口（2026-10-10）：最后Create多商品扩展字段拒绝修复331f7508715a8aba5c27acde9845bcab7ed3b6a4由Lastleg #253成功部署且healthy。真实客户提交含items非法扩展的完整请求返回A0400，前后订单列表相同，自身会话正常退出。采购25项已按真实两端主流程、HTTP边界/资金/权限及本地事务/并发断言完成对应核对，见reports/procurement-final-coverage-review-20261010.json、procurement-acceptance-audit-20261010-r1.json及procurement-create-boundary-http-20261010.json。本地Mock边界不表述为TEST故障注入；采购验收收口不代表拼车与预约整体完成。预约页本次服务切换503在健康后刷新消失，提柜范围不完整提示仍待分类核查。
|
||||
|
||||
|
||||
三对话变更统一发布完成（2026-10-10）：Lastleg #254 成功部署固定提交 `8e36bd90ef945c58026dce713f69d3045d743be8`，容器 healthy，CI 1727 项测试零失败/错误、2 项跳过；Admin #555 成功发布 `453549ece1c002bb24b57050caa18758ad6697ee`，实际 checkout 一致、健康检查通过。采购操作分组、拼车待办默认入口及询价简化、预约三工作视图与最新去标题样式均已纳入；合并保留远端同期改动。Admin 本地全量 2803 项通过，最后预约增量 58 项及类型检查/构建通过。按用户逐项授权仅创建 `ll_appointment_impact`、`ll_appointment_impact_history` 两表，无删除或改写既有数据。真实 admin1 独立 HTTP 会话验证船期事项、外接候选、采购列表均 HTTP 200/业务200，并退出自身会话；页面刷新确认默认提柜与到仓、三视图和去除美国预约总览标题。证据为 `reports/three-threads-lastleg-deployment-20261010.json`、`three-threads-admin-deployment-20261010.json`、`appointment-impact-db-execution-20261010.json`、`three-threads-release-http-20261010.json` 及 `three-threads-release-ui-20261010/`。本次发布完成不等于预约和拼车全部业务验收关闭；目的仓7/14/30天货量聚合、全局待办及范围/时区待核项仍按原范围保留。
|
||||
|
||||
|
||||
预约用户最新布局补发（2026-10-10）：Admin #556 成功检出并发布 `e404fe10496bce285bd84b87d5048c1a0b7e2f48`，健康检查通过；保留远端同期尾程详情变更。用户最新确认覆盖旧默认列表结论：预约日历第一并默认打开，资料提示收进工具栏，137条待核实车次从提示入口打开分页弹窗。合并后70项直接测试、类型检查和构建通过，未重复部署后端或执行SQL。1920×1080、visualViewport.scale=1已核实，admin1实际打开日历、勾选用车计划、展开数据提示和待核实车次弹框成功；当前弹框截图见 `reports/three-module-ui-1920-20261010/appointment-unresolved-dialog.png`，发布证据 `reports/appointment-resume-deployment-20261010.json`。用户已确认本轮验收范围是采购、拼车、预约全部相关页面和弹窗，尚未逐项完成，不以本弹框通过替代全部验收。
|
||||
|
||||
|
||||
三模块1920验收继续（2026-10-10）：固定1920×1080/scale=1，已检查预约20入仓码展开、计划编辑/正式确认表单布局、ABE3仓库搜索与候选、勾选后跨页保留，以及管理员拼车默认待我处理。发现AP-UI-001：新增预约候选表长入仓码及客户名称被截断，已交预约对话修复，尚未复验。选择框隐藏输入自动定位超时，经点击可见选择单元格正常，未归为业务缺陷。本轮未保存或取消共用预约、未执行资金动作。证据 `reports/three-module-ui-1920-20261010/`；其余页面、状态依赖弹框和销售角色仍待验，不表示全模块完成。
|
||||
|
||||
|
||||
1920验收缺陷闭环（2026-10-10）：AP-UI-001修复提交 `67bd3e6e53c75529b536457186b91ecf52eeaff7` 经Admin #559成功发布，精确检出且healthy；合并远端同期出库修改后81项直接测试及类型/构建通过。同一ABE3候选真实页面复验长入仓码、客户名完整换行，分页和底部按钮仍在1920×1080内，截图 `reports/three-module-ui-1920-20261010/appointment-candidates-fixed.png`。新发现FL-UI-001：拼车只读客户货物跟进的本车卸货站仍可展开，已交拼车对话修复；无保存入口，未表述为服务端越权。其他待验范围保持，验收未整体完成。
|
||||
|
||||
2026-10-10三模块页面验收增量：Admin #559 下已打开提柜与到仓列表（324条），核对 TSTU2472410 提柜跟进历史与拖车联系/码头约号选项，以及洛杉矶仓独立接仓跟进空态；两个弹窗在1920×1080下底部按钮完整可见。截图 `reports/three-module-ui-1920-20261010/appointment-pickup-followup.png`、`appointment-warehouse-followup.png`。空接仓表单点击保存后仍停留且记录0条，但未捕获校验提示，提示反馈尚待验证。FL-UI-001已有本地修复，专项报告24项定向测试及类型检查通过，尚未发布或页面复验；三模块整体验收仍未完成。
|
||||
|
||||
2026-10-10送仓与排车页面验收增量：头程列表620条，NYEXX2610080222单票跟进展示洛杉矶仓→ABE3、资料缺项及3条历史；加入合批后1票/1客户/3预报箱正确，合批安排弹窗布局正常。切换外接货物保留选择，7条候选可见，FB-2108714742102147074跟进正确打开已关联WT-2OLDI4ZED3XOOGQR5P82OYW1N及ACY2。截图为同一1920证据目录的appointment-cargo-followup.png、appointment-batch-plan.png、appointment-external-followup.png；未保存预约。ABE3合批目的仓时区待核实的来源已交专项只读核对，尚未认定缺陷；以上不证明预约前后入仓的完整业务闭环。
|
||||
|
||||
2026-10-10三模块验收发布增量：Admin `7f39adf` 经 #560 SUCCESS 发布，源码与healthy核对，24项定向测试、类型/构建及5项Gateway路由合同通过；原FB-2108564562648285185真实页面卸货站已disabled，FL-UI-001关闭，截图fleet-progress-readonly-fixed.png。预约本页执行核对船期生成20条待处理观察，TSTU2472410影响弹窗及1条观察历史展开通过布局检查（appointment-impact-dialog.png）；未认领/处理/完成事项，未保存预约。AP-UI-002确认合批预览遗漏目的仓时区传递，已交专项修复；来源MANUAL:1000001展示与ETA缺失触发待处理规则仍待核对。完整三模块页面验收未结束。
|
||||
|
||||
2026-10-10预约两项修复已提交：Admin ebff6f8、Lastleg 15ab355dc；前端59项直接测试与类型/构建通过，后端专项5项通过，Lastleg #257正在完整构建测试，尚未确认部署成功，Admin尚未发布。后端保留远端同期派送修改c6471d06f。拼车发布详情、草稿编辑及原已排入票收货详情新增页面证据；收货数据正确，但BOUND仍提示可安排排车（FL-UI-002）已交专项核对修复。登记默认收起、单站自动锁定、未知货量空值已检查。
|
||||
|
||||
2026-10-10预约修复发布完成：Lastleg #257 /15ab355dc（1731项测试、0失败/错误、2跳过）和Admin #561 /ebff6f8均SUCCESS，精确提交及healthy已核对；无SQL变化。合批时区与船期来源/原因文案已部署，真实页面复验尚待完成，不能标为缺陷闭环。
|
||||
|
||||
2026-10-10预约修复页面复验：#561/#257下，NYEXX2610080222合批显示America/New_York（appointment-batch-timezone-fixed.png）；TSTU2472410船期影响显示人工维护、不再暴露内部来源引用（appointment-impact-fixed.png），核对原因实际为“实际到港已更新”，不以ETA为空推定缺失触发。AP-UI-002/003关闭，未保存预约。FL-UI-002专项本地修复及10项测试通过，尚未发布复验。
|
||||
|
||||
2026-10-10三模块验收继续：Admin #562 精确发布 e124fbcf6858417ff27f70832409bf51ff10203d，SUCCESS且Healthy；原 FB-2108714742102147074 收货详情显示已确认实收、已排入本车，FL-UI-002真实页面复验关闭，证据 fleet-bound-receipt-detail-fixed.png。采购客户端列表/新建/详情首屏已检查；后台编辑仅内部备注可写，订单号/商品/数量readOnly。终态详情读取及费用目标更正、关联退款表单布局已检查，未提交资金操作。发现PROC-UI-001列表长订单号与描述截断，局部修复及35项直接测试/类型检查已完成，尚未提交发布或页面复验。以上截图在 reports/three-module-ui-1920-20261010/，三模块全部页面弹窗与状态分支验收仍未完成。
|
||||
|
||||
2026-10-10采购弹窗增量：ICSGS202610100001终态订单的费用更正/原扣款退款/独立新费用及事实更正默认差异处置四种表单已在1920×1080检查并截图，标题、字段、底部按钮完整可见；未提交任何资金或实物更正，不据此宣称分支操作通过。截图 procurement-finance-correction.png、procurement-finance-refund.png、procurement-finance-new-charge.png、procurement-fact-disposition.png。其他财务处理方式及实物更正类型仍待验。
|
||||
|
||||
2026-10-10采购页面两项修复闭环：Admin #563 精确发布 d7f2d09b88d677468233a03638076e3161730dfb，SUCCESS及Healthy；全量前端2821项、类型检查和构建通过。PROC-UI-001列表长业务号/描述完整展示，PROC-UI-002终态及分段交寄后不可执行的实物更正禁用并解释，保留追加说明和实际仓追加更正；原ICSGS202610100001真实复验默认追加说明、不可改写选项disabled，列表原长订单号完整。截图 procurement-management-gates-fixed.png、procurement-admin-list-fixed.png。后端仅测试提交d4b72594ab640ca011027a6dfb1a37ff8f1a3aa1，14项持久化测试通过，未部署后端。7类实物更正表单布局已看并截图，无实物/资金提交；合法状态操作、其他财务选项、拼车角色及预约写入仍待验，不能称三模块全验完成。
|
||||
|
||||
2026-10-10采购非终态及财务表单验收：Admin #563 下客户2108640601712988162的QLYSXDKH202610100002（wrong-goods待装箱样本）装箱草稿表单与未交寄实收更正打开正常；确认装箱/预估/交寄仍显示货款或来源关联阻断，未改样本。六类财务管理表单截图现已齐全，新增procurement-finance-terminate.png、procurement-finance-reassess.png、procurement-finance-release-hold.png，仅证明布局，未新提交资金操作。采购主流程已有audit.uiProgress真实UI提交记录，不再重复整条扣费交寄链。尚缺的页面证据为购买前分支、部分状态节点、国内换包装、异常关闭及费用重试；计划仓调整、说明/解除、撤销处置、实际仓更正、独立释放冻结缺本轮明确线上成功证据，仍待验。
|
||||
|
||||
2026-10-10采购说明与阻断闭环：Admin #563，ICSGS202610100001 在真实页面20:55:06追加测试阻断，21:02:34解除；PN-FED1A3D0E2FB42008C0E5028显示已解除阻断，原说明、解除依据和两条流水均保留。1920×1080截图及DOM记录：reports/three-module-ui-1920-20261010/procurement-control-resolved.png、procurement-control-resolved.json。异常凭证已通过上传接口登记，本次说明及解除均由UI提交。购买前测试订单ICSGS202610100002/0003已准备，0003计划仓调整仅HTTP验证通过，UI仍待验；异常关闭弹窗截图已完成但未提交。剩余状态节点、换包装、财务重试、撤销处置、实际仓更正、独立释放冻结及拼车/预约剩余验收仍未完成。
|
||||
|
||||
2026-10-10购买前页面验收增量：1920×1080下完成审核拒绝、预算核验、计划仓、购买登记及购买前取消5个表单截图；仅计划仓实际提交。ICSGS202610100003于21:14:08通过UI将纽约仓改回洛杉矶仓，页面概览和操作流水已核对，仍待购买且购买/实收事实为空。证据目录reports/three-module-ui-1920-20261010/，截图procurement-review-reject.png、procurement-budget-authorization.png、procurement-planned-warehouse-form.png、procurement-planned-warehouse-saved.png、procurement-purchase-form.png、procurement-prebuy-cancel.png。未提交审核拒绝、预算、购买或取消，不以布局证据推定提交通过。剩余采购状态节点、换包装/重试、其他异常分支和拼车/预约范围继续待验。
|
||||
|
||||
2026-10-10采购终态仓更正验收：ICSGS202610100001于21:32:50通过UI追加洛杉矶→纽约仓更正说明，21:39:12解除测试阻断；PN-32F9B3670824463797D62F92保留原说明、目标仓及解除依据，有效实际收货仓仍洛杉矶仓。证据procurement-warehouse-correction-resolved.png/.json及procurement-warehouse-correction-final-dom.txt（reports/three-module-ui-1920-20261010/）。这仅证明终态追加留痕路径，不证明装箱前有效仓修改路径。购买重新核定弹窗截图已补，未提交。只读核对9客户14张当日测试订单：剩余收货/装箱/面单/交寄/换包装无合法可执行样本，且无有效失败费用；证据reports/procurement-remaining-ui-state-inventory-20261010.json。已安排复用专用待购买单ICSGS202610100003准备零元测试购买，停在海外收货前，结果待回报；不以此宣布剩余节点通过。
|
||||
|
||||
同批测试样本准备回报：ICSGS202610100003已通过HTTP登记CNY0测试购买，WAIT_OVERSEAS_RECEIPT v4，费用ZERO、实收0、交寄0，RECEIVE_OVERSEAS及FINISH_OVERSEAS允许；证据reports/procurement-zero-purchase-ui-preparation-20261010.json。停于海外收货前，下一步真实页面逐节点验收，尚未完成。
|
||||
|
||||
2026-10-10采购海外收货及确认装箱UI验收：ICSGS202610100003登记合格1/破损0/多货0，实收PR-4FBA0F4A1FD04C5E86D09870有效；22:01:20通过页面确认海外收货完成。草稿由API仅准备TEST-UI-NODE-BOX-01（1件，20×15×10cm，1kg，关联该实收），22:09:45通过UI确认第1版清单，面单入口已开放，尚无交寄。1920证据reports/three-module-ui-1920-20261010/下procurement-overseas-receipt-form.png、procurement-overseas-finish-form.png、procurement-overseas-finished.png及dom、procurement-packing-confirm-form.png、procurement-packing-confirmed.png及dom。数量直接fill未保留，改用数字控件ArrowUp并截图确认1后提交；日期通过选择器确定后实际保存21:51:36。未将工具填值问题当作产品缺陷。后续面单、运费、交寄、国内收货换包装及其他模块继续待验。
|
||||
|
||||
2026-10-10采购国际面单UI验收：ICSGS202610100003于22:20:24通过页面保存第1版国际面单，TEST-UI-NODE-BOX-01关联测试PNG第1页、TEST-EXPRESS及TEST-NODE-INT-20261010-03；保存结果显示实际仓寄件资料与TEST国内中转收件资料。面单文件由API仅上传LABEL，表单由UI填写及提交。1920证据reports/three-module-ui-1920-20261010/procurement-international-label-form.png、procurement-international-label-saved.png及-dom.txt；核对预估运费、确认逐箱贴单入口已开放，尚未新增预估或交寄。寄客户段、后续节点及拼车预约剩余范围仍待验。
|
||||
|
||||
2026-10-11断点恢复及国际交寄UI验收：恢复后ICSGS202610100003无预估记录，昨晚表单未提交；今日UI提交CNY0.01预估PF-D0A2F0B4EE1B4A7F8267BDFB并刷新确认已冻结、未扣款。随后模拟08:58:02逐箱贴单、09:02:09国际交寄，生成PS-93DDDF5D821D4DD5B5AEFB18，箱号TEST-UI-NODE-BOX-01与第1版面单一致，交寄后资金仍冻结未扣。证据reports/three-module-ui-1920-20261010/下procurement-estimate-form-20261011.png、procurement-apply-label-form-20261011.png、procurement-international-ship-form-20261011.png、procurement-international-shipped-20261011.png。实际页面国际面单登记时间为2026-10-10 22:28:24，修正上次文字记为22:20:24。国内收货、换包装及三模块其余验收继续待完成。
|
||||
|
||||
2026-10-11国内收货UI验收：ICSGS202610100003经页面登记国内实收PR-6BE184A7BA504C4C8C26220B，来源国际原箱TEST-UI-NODE-BOX-01，合格1/破损0/多货0，实收时间09:10:45；09:15:12通过UI完成国内收货，换包装和国内核费入口开放。1920证据reports/three-module-ui-1920-20261010/procurement-domestic-receipt-form-20261011.png、procurement-domestic-finish-form-20261011.png、procurement-domestic-repack-form-20261011.png。换包装表单已检查限制与布局，尚未提交；已安排仅准备其要求的文件凭证，不据表单开放判定换包装完成。国内核费及寄客户段、其余采购分支与拼车预约剩余范围仍待验。
|
||||
|
||||
2026-10-11国内一对一换包装UI验收：ICSGS202610100003通过页面提交TEST-UI-NODE-BOX-01新箱规21×16×11cm、1.100kg，仍1件且关联国内实收PR-6BE184A7BA504C4C8C26220B；原国际清单20×15×10cm/1kg与国际交寄记录保留。凭证仅由API上传RECEIPT，换包装由UI提交。1920证据reports/three-module-ui-1920-20261010/procurement-domestic-repack-filled-20261011.png、procurement-domestic-repacked-20261011.png。本样本此前没有国内面单，不证明既有国内面单失效分支；国内核费、寄客户面单及交寄与其他模块剩余范围继续待验。
|
||||
|
||||
2026-10-11国内费用及寄客户面单UI增量：国内核费主表单及其他费用逐项新增分支1920截图已完成，内部滚动及固定底部按钮可见，未核费。ICSGS202610100003通过UI保存寄客户面单第1版，TEST-DOMESTIC/TEST-NODE-CUSTOMER-20261011-03，沿用原下单收件资料，使用换包装后21×16×11cm/1.1kg的原箱1件；国际面单和交寄另行保留。证据reports/three-module-ui-1920-20261010/procurement-domestic-charges-form-20261011.png、procurement-other-charge-form-20261011.png、procurement-customer-label-form-20261011.png、procurement-customer-label-saved-20261011.png。尚未核费或寄客户，预估0.01仍冻结；独立释放和后续费用/交寄及三模块其余验收待完成。
|
||||
|
||||
2026-10-11三模块断点收口增量：采购ICSGS202610100003通过UI执行独立释放预估，PF-D0A2F0B4EE1B4A7F8267BDFB的CNY0.01先显示释放处理中，刷新后为“预估已释放 / 预估不入池 / 历史版本”，未新增收费或退款。1920证据procurement-release-estimate-form-20261011.png、procurement-estimate-released-20261011.png。原0001已有完整主流程UI证据，不再因0003仍待核费而重复整链；本轮全部页面弹窗范围与所有状态命令成功提交分别核算，progress.json陈旧摘要已修正。
|
||||
|
||||
同轮预约补验月→周、下一周、10月15日选日、跨月及“今天”恢复10月11日成功；两条ABE3预约正确出现在当天安排。AP-20261010-7A779BFFEB56取消确认框展示20票释放影响及历史保留，已返回，未取消。TSTU2472410/洛杉矶仓接仓跟进通过UI新增一条TEST-UI-FOLLOWUP-20261011模拟记录，历史由0变1，未联系真实仓库、未正式确认预约或推进收货。空表单未新增记录，源码明确有短暂warning，但尚无真实页面提示截图，仍保留此证据限制。截图appointment-week-selected-20261011.png、appointment-cancel-confirm-20261011.png、appointment-warehouse-followup-saved-20261011.png，均在reports/three-module-ui-1920-20261010/。
|
||||
|
||||
同轮拼车取消意向弹窗及已排入货物实收详情复核：FB-2108748108671270914取消确认影响清晰，已返回未取消；FB-2108714742102147074显示已确认实收、已排入本车。原FO-2108713050417709058截止北京时间10月11日10:00已过且容量待核对，登记/确认被合法阻断；本轮另外两个已知发布同样过期或关闭，没有可确认样本（reports/fleet-known-sample-eligibility-20261011.json）。新有效发布正式前置包括测试车辆司机预留及已有实托自有货排车；尚未创建新样本或改旧日期（reports/fleet-minimal-ui-preparation-preflight-20261011.json）。截图fleet-cancel-inquiry-confirm-20261011.png。三模块仍有角色及合法状态弹窗缺口，未标整体验收完成；没有新增部署、SQL或源码修改。
|
||||
|
||||
2026-10-11拼车有效样本及销售角色续验：只读确认原车次车辆/司机/两票货物均为专用TEST后，经正式API将TR-0B35BCAC84604E27发车调整至10月14日18:00、FO-2108713050417709058截止17:00，重核既有两托盘2托/200kg/2m³计划，planValid/capacityKnown=true并恢复接单；车次v14→16、发布v1→3，未新建货物流转、未确认承运/发车/修改主档。报告reports/fleet-ui-timing-capacity-preparation-20261011.json保留变更前后。此前“无合法发布样本”阻断已解除，原询价仍需补资料。销售A真实登录后默认“可拼车次”，仅有“我的登记”及本人1条询价，无调度确认入口。10:31:27通过UI保存FB-2108748108671270914为1箱/1托位/1kg/1m³、1USD模拟报价、TEST联系人、预计10月13日00:00到仓，状态变为“待调度确认·尚未保位”；未确认承运。截图fleet-sales-a-landing-20261011.png、fleet-sales-a-saved-ready-20261011.png。下一步是销售B隔离、调度最新版确认及剩余合法状态弹窗，当前浏览器保留销售A会话；不能据销售保存推断调度确认已验。
|
||||
|
||||
2026-10-11拼车最小角色及确认UI验收：销售B登录后默认可拼车次，“我的登记”和FO-2108713050417709058详情均仅显示本人FB-2108748109833093121，不显示销售A记录；车次号只读，无整车详情入口。最小调度账号默认待我处理，可见跨销售待办并对FB-2108748108671270914打开“核对并确认”全字段表单。10:44:48点击“确认承运并保位”真实成功，生成本土订单LB-ACY2-20261011-578947，状态“尚未安排来货·已保留货位”，无来货/排车关联，预约仍待真实货件资料。现行CapacityInquiryDialog.confirmMode通过saveAndConfirmInquiry直接提交，不另弹二次确认；此前待办中的独立二次确认框是过时假设，不作为缺失页面。最小调度无额外仓库执行权限，成交后仅只读跟进/取消；未发车、未收货或扣款。截图reports/three-module-ui-1920-20261010/fleet-sales-b-isolation-20261011.png、fleet-sales-b-detail-isolation-20261011.png、fleet-manager-confirm-form-20261011.png、fleet-manager-confirmed-20261011.png。三模块整体验收仍未结束；后续管理员非BOUND来货/核量/排入表单、关联入口及预约剩余证据继续核对。
|
||||
|
||||
2026-10-11拼车来货与关联页面UI增量：Admin admin1可对FB-2108748108671270914打开“登记外接来货”（预计到仓/交货说明/生成来货单），1920截图fleet-incoming-create-form-20261011.png，已取消未生成。发布详情→TR-0B35BCAC84604E27→DS-WH-20261010-169793排车详情真实跳转成功，待发车及业务关联可见，截图fleet-linked-dispatch-detail-20261011.png。发布余位窗口数据显示3托/201kg/3m³占用、余27托，与新增已确认测试预订一致；截图fleet-publish-settings-20261011.png暴露FL-UI-003：托盘码截断、托位数字控件挤压，已交拼车原对话局部修复，未发布。
|
||||
|
||||
核量/排入中间态准备受权限前置阻断：三个已知FO的13条询价没有非BOUND已实收样本；专用FIXTURE_PDA记录为停用，备用TEST ADMIN_PDA登录后读取同仓测试来货返回A0403。未生成新来货、未修改账号权限或库存，报告fleet-existing-inquiry-fulfillment-inventory-20261011.json、fleet-new-a-receiving-preparation-20261011.json。已向用户请求可用专用PDA测试账号或将两项转人工验收，等待回复，其他页面继续。
|
||||
|
||||
2026-10-11预约船期事项UI增量：TSTU2472410的AI-D4D736964D9A4E3B9015由admin1认领成功，历史1→2；随后保存TEST-UI-IMPACT-20261011合成处理记录，历史2→3。原始船期观察、认领、处理记录同时保留，关联2票/0预约/0车次，原始时间与时区待核实提示未改。事项仍待处理，未完成核对、未联系外部、未改运输/预约时间。1920截图appointment-impact-recorded-20261011.png在reports/three-module-ui-1920-20261010/。仍不得称三模块全部验收通过。
|
||||
|
||||
2026-10-11 FL-UI-003闭环：Admin提交baa69e66a17488f913b61de475d3636b8aad248e，经#564 SUCCESS精确检出发布、容器Healthy；本地341文件/2821项全量测试、类型检查及构建、5项Gateway合同通过。仅TripLoadingPanel.vue和CapacityOfferSettingsDialog.test.ts，未改后端/SQL。原TR-0B35BCAC84604E27发布窗口1920×1080真实复验两个完整托盘码换行、托位/重量/体积控件无省略挤压、标题及底部按钮完整，FL-UI-003关闭。截图reports/three-module-ui-1920-20261010/fleet-publish-settings-fixed-20261011.png；发布证据reports/fleet-publish-layout-deployment-20261011.json。PDA账号请求仍待用户回复，核量/排入及采购费用重试等确切未验项保持，不以本修复通过宣布三模块整体验收完成。
|
||||
|
||||
2026-10-11预约来源跳转补验：1920×1080真实UI从用车计划图层→待核实车次137条→TR-615F463539F24405查看来源，成功打开同编号车次详情及关联DS-WH-20261003-652033，截图reports/three-module-ui-1920-20261010/appointment-unresolved-source-navigation-20261011.png。仅只读，未改时区资料。当前日历DOM无未定时安排区块；源码仅unscheduledTotal非零时渲染，尚无非零真实样本的页面证据，不与待核实车次弹窗混为一项。空跟进提示、采购失败费用重试及拼车核量/排入前置仍未关闭，整体验收保持进行中。
|
||||
|
||||
2026-10-11剩余样本补验：正式UI对NYEXX2610080222（洛杉矶→ABE3，1票预报3箱）保存无日期待确认安排AP-20261011-6E396F904F78，备注TEST-UI-UNDATED-20261011；未定时列表显示1条，查看/继续保留原码、America/New_York与空日期，1920截图appointment-unscheduled-list-20261011.png、appointment-unscheduled-edit-20261011.png。未取得外部确认，未改原两张有日期预约。采购经正式API给原TEST单ICSGS202610100002上传本单预算/购买TEST凭证、审核授权及模拟购买5元，v0→3，费用PF-76D65321181D4F0ABF13A6AD自然返回FREEZE_FAILED/FIN-WALLET-INSUFFICIENT；无充值、授信调整、重试或物流，报告reports/procurement-five-cny-failed-sample-20261011.json。根UI已打开重试弹窗、读到正确5元选项，但浏览器控制连续超时未获得截图，不能算视觉验收完成。后续只需恢复截图，不重复造失败样本；拼车两项PDA前置及空跟进提示证据仍待补。
|
||||
|
||||
2026-10-11采购重试弹窗视觉缺口关闭：恢复原浏览器后确认已选PF-76D65321181D4F0ABF13A6AD，1920×1080截图procurement-failed-fee-retry-20261011.png显示完整费用编号、CNY5、汇率1/2026-10、操作说明与底部按钮。随后关闭并确认无未保存修改，未提交重试，失败费用保留。三模块剩余实际证据缺口为拼车合法实收态核量/排入两项（PDA账号待用户回复）及预约空跟进警告提示；不得据此推断全部命令或全部验收通过。
|
||||
|
||||
2026-10-11拼车剩余弹窗补验：经用户指定整个配置目录后找到现有可用TEST PDA，正式读取洛杉矶仓200（fleet-explicit-test-pda-candidate-check-20261011.json），账号前置解除。正式API为FB-2108748108671270914创建并PDA实收WT-580KXCFH2UB6X39E84CLN9EN3、PLT-USLAX01-261011-G0VEORZINJEP，1箱1kg1m³，报告fleet-new-a-pda-received-for-ui-20261011.json。根UI于12:25:56按原1USD确认实收及运费，随后打开确认排入本车并取消，未排入/发车/结算。1920截图fleet-receipt-review-20261011.png、fleet-bind-confirm-20261011.png。核量托位控件末端省略号记FL-UI-004，已局部修复与定向测试通过，待全量检查/发布/视觉复验，不能提前关闭。
|
||||
|
||||
2026-10-11 FL-UI-004首次复验未通过：Admin1edb65df773da8e6246217fda0ba330860b05465通过2821项全量测试/构建并经#565 SUCCESS精确检出、Healthy。B测试草稿经正式流程准备为FB-2108748109833093121 / LB-ACY2-20261011-513730 / WT-86A93VMC25F8Z6016W112SN0A，1箱1托位1kg1m³/USD1待核量，未核量提交/排入/发车。报告fleet-b-pda-received-for-ui-20261011.json。截图fleet-receipt-review-fixed-20261011.png仍显示托位控件尾部省略号；实时DOM已移除单行class，但基础cell计算样式仍overflow:hidden、textOverflow:ellipsis。问题保留未关闭，已回报修复方；不能以发布成功当视觉通过。
|
||||
|
||||
2026-10-11设计与实现专项核对：按用户要求复用拼车、预约两个既有对话进行只读审计。拼车报告3项交互缺口：登记列表未按当前主要动作收敛、确认承运缺目的站余位摘要、核量缺预报与实收对照；旧契约中的页签及独立确认框描述须按最新确认整理，不恢复旧交互。预约报告4项代码偏差：快捷取消使用固定原因、未知结果关闭后丢失原请求重试上下文、只读用户仍见编辑保存入口、FBA跟进说明条件错误。以上为代码审计发现，尚未全部真实页面复现或修复；只读入口问题不代表已验证服务端越权。预约的实际就绪时间、全局待办、车次整合及非FBA等设计目标另列待明确范围，不自动扩大本轮修复。来源为两个对话2026-10-11审计交付，未据此宣布三模块全部完成。
|
||||
|
||||
同轮FL-UI-004第二次修复加入原生容器控制数字输入宽度，11项定向检查、类型检查及构建通过；总控全量测试2821通过、1失败，失败为TripBookingPanel.test.ts:47既有成交价控件测试超过5000ms。已交原实现方定向排查，未以局部通过覆盖全量失败，尚未提交或发布第二次修复。
|
||||
|
||||
2026-10-11设计偏差前端修复门禁：Admin d77abbef7c2790724faf141640c71e20990ec55e 已提交并推送release/test，13文件覆盖拼车主要动作/目的站余位/首次核量对照/FL-UI-004第二次修复，以及预约未知结果关闭和切页保护/只读保存阻断/来源说明。总控全量341文件2828测试、类型检查、构建与5项网关合同通过；此前5000ms超时已通过按需导入真实控件改善，未放宽超时或删断言。尚未部署或真实页面复验，不关闭这些项目。已核量记录缺原始预报快照，无法展示历史差异。预约实际取消原因及可查询取消历史仍由原专项补齐，拟与前端最后接入统一发布；不新增SQL或覆盖原备注。
|
||||
|
||||
2026-10-11取消原因闭环发布准备：Backend 43494cbfa36de1963fe38fd92ad5e65a0c1c8cd2 / Admin 240aa5d6d06a24aeb6701af595c7402d8692b75b 均已提交推送，Admin包含前批d77abbe。取消必填原因、原备注保留、按预约查询历史和默认折叠的取消记录持久入口已实现；37项后端定向、5项网关合同、最终343文件2836项前端全量、类型编译和构建通过。未新增SQL。Lastleg发布队列7469已提交，报告reports/design-alignment-lastleg-deployment-20261011.json；Admin待后端健康后发布，不能据排队宣称环境完成。待复验范围见reports/three-module-ui-1920-20261010/progress.json的designAlignmentRechecks。
|
||||
|
||||
2026-10-11本批发布与首项复验：Lastleg #258精确43494cbfa36de1963fe38fd92ad5e65a0c1c8cd2、Admin #566精确240aa5d6d06a24aeb6701af595c7402d8692b75b均SUCCESS且容器Healthy。发布脚本中文匹配编码导致一次记录误判，直接日志验证目标checkout及健康后已修正为ASCII校验，未重启或重复部署。1920×1080真实B核量弹窗托位数字框完整无省略号，预报/实收对照和底部按钮完整，FL-UI-004复验关闭；B未提交实收，仍保留原状态。截图fleet-receipt-review-r2-20261011.png；列表不同状态主要动作已展示，截图fleet-primary-actions-20261011.png。其余角色、确认余位与预约新取消历史等复验继续待完成。
|
||||
|
||||
2026-10-11验收记录增量核对：复核既存1920×1080截图fleet-confirm-capacity-20261011.png，拼车待补资料确认窗口已展示ACY2可接26托位/17798kg/86m³，说明三维同时满足且提交时重核，底部按钮完整；仅证明该样本展示，未确认承运，也未证明未知余位分支。progress.json中旧“待部署/开发中”状态已按Admin #566及Lastleg #258发布证据纠正。预约取消原因与持久历史、只读角色、来源说明及拼车只读角色仍缺本批人工页面证据；未知结果保护沿用已通过自动化测试，不宣称真实故障注入通过。两个既有专项已收到增量文档对照指令并处于执行中，不新增对话、环境写入或重复部署。
|
||||
|
||||
2026-10-11截图证据规格审计：仅核对progress.json引用的39份现存截图，其中31份为1920×1080、8份为1905×1072；实际编码均为JPEG，扩展名为.png，不影响既有读取，但不能仅凭扩展名解析格式。像素不符8份涉及未定时列表、BOUND实收详情前后、调度确认结果、采购列表前后、说明解除及预估释放结果。像素尺寸不直接证明浏览器CSS视口/缩放不符，也不证明产品布局缺陷；须补原始视口/裁切依据或人工截图，不缩放原图冒充1920证据。明细reports/three-module-ui-1920-20261010/evidence-dimensions-audit-20261011.json，原业务操作证据保留，严格规格待核实，三模块验收未完成。
|
||||
|
||||
2026-10-11二次文档审计确认：AP-DESIGN-005，共享预约表单与普通更新接口仍允许CANCELLED，可绕过专用取消原因、权限和历史；预约专项接管移除旁路并统一取消流程，尚未交付/发布。FL-DESIGN-004，核量后的当前cargo已更新实收，却仍以预计货量展示并混入预计实托；拼车专项只修正阶段标签及预计实托语义，尚未交付/发布。更正此前“缺原始预报快照”的笼统表述：现有车次历史已保存含外接预订的快照，问题在当前单票响应未提供独立预报投影；新建记录同样受当前字段更新影响，不仅限旧样本。首版明确要求首次核量对照，未明确要求核量后永久对照表，因此本轮不擅增该范围。前批已验收项不因这两项新发现全部重跑，三模块整体验收仍未完成。
|
||||
|
||||
2026-10-11 FL-DESIGN-004实现交付：拼车专项冻结capacityOfferTypes.ts、CapacityInquiryTable.vue、CapacityInquiryDialog.vue、CapacityOffersBehavior.test.ts四文件，核量前标预报、RECEIVED/BOUND标已核实、CANCELLED用中性记录货量，预计实托独立保留；3个定向测试文件31项通过。根已只读核对diff和执行记录，尚未集成提交、全量检查或发布。AP-DESIGN-005取消旁路及本轮未知结果保护遗漏仍在预约专项处理中，待同批收口。
|
||||
|
||||
2026-10-11二次偏移修复集成门禁通过：Admin ee174f8265d2c2586d6769c135125ecec36a5f66（13文件）和Lastleg 29b562ebf5a4ece6f2333a28463929cf628dfedb（4文件）已提交推送。包含取消旁路封堵、未定时详情专用取消入口、船期影响及入仓单预约未知结果离开保护，以及拼车阶段货量标注。344文件2843项Admin全量、类型检查和构建、32项后端定向、5项网关合同通过；取消后恢复沿正式规则重新核对占用且保留取消历史。无SQL。Lastleg队列7474已提交，报告reports/design-gaps-lastleg-deployment-20261011.json；Admin等待后端成功健康后再发，暂不称发布或人工页面验收完成。
|
||||
|
||||
2026-10-11二次偏移修复发布完成：Lastleg #259精确29b562ebf5a4ece6f2333a28463929cf628dfedb，Admin #567精确ee174f8265d2c2586d6769c135125ecec36a5f66，两项均SUCCESS且Healthy，耗时分别85.479秒和56.434秒；代码仓库工作区均干净。发布证据reports/design-gaps-lastleg-deployment-20261011.json及design-gaps-admin-deployment-20261011.json。专项已获派只对原合成预约AP-20261011-6E396F904F78验证普通PUT取消被拒绝及前后事实不变、只读历史端点；尚无现场结果，不提前记通过。本批页面按当前规则待人工1920×1080/100%截图确认，整体验收仍进行中。
|
||||
|
||||
### 本轮三模块剩余人工验收清单（Admin #567 / Lastleg #259）
|
||||
|
||||
以下清单只覆盖尚缺的证据，不要求重做已通过的采购扣费、交寄或PDA收货。统一1920×1080、浏览器100%；截图保留原始尺寸，不放大或补边。
|
||||
|
||||
| 页面/样本 | 操作与预期 | 尚缺证据 |
|
||||
| --- | --- | --- |
|
||||
| 预约列表，未定时TEST预约AP-20261011-6E396F904F78 | 打开详情及专用取消弹窗；无原因不能提交，原备注仍可见；先关闭、不实际取消 | 新取消弹窗布局及空原因校验截图 |
|
||||
| 预约列表，“取消记录”与详情“取消历史” | 默认折叠，展开按需加载；存在记录时能以业务号打开详情并只读查看原信息及原因 | 已取消TEST记录的列表与历史截图；当前样本没有取消事实，不可假报成功 |
|
||||
| 预约只读角色与来源跟进 | 只读详情字段不可编辑且没有保存；货柜提柜、仓库收货、FBA送仓说明分别符合来源 | 只读角色及三类来源说明截图 |
|
||||
| 拼车FO-2108713050417709058 | 列表/详情按阶段显示预报或已核实；预计实托数单独标注；取消记录不冒称预报/实收；只读角色只开放其权限内操作 | #567新标签与只读操作截图；不用重新核量、排车或收费 |
|
||||
| 收货跟进与既存截图规格 | 空跟进提交应显示提示且不新增历史；8张1905×1072截图核对原始视口/裁切依据或人工补拍 | 短暂提示截图及规格依据，详见evidence-dimensions-audit-20261011.json |
|
||||
|
||||
未知结果下关闭/切页/跳转保护已由自动化用例验证，本轮不为截图额外制造环境故障。接口现场结果另记，不替代页面截图；原业务数据与成功操作事实继续保留。
|
||||
|
||||
2026-10-11取消旁路TEST现场验收：专项以独立会话确认AP-20261011-6E396F904F78为专用合成样本后，按版本0普通PUT请求CANCELLED，返回HTTP200/业务A0400；根读取报告核对before==after，版本、PENDING状态、原备注、时间、1票关联及货物摘要均不变。取消历史及汇总分页读取HTTP200/业务200，当前均0条；未执行真实取消或恢复，故不证明非空历史展示。证据reports/appointment-cancel-bypass-live-20261011.json。代码、测试、提交和发布已完成，本批剩余人工页面与截图规格证据见上表；不得将接口验证等同整体验收完成。
|
||||
|
||||
2026-10-11用户再次明确执行顺序：先更新测试环境，再由拼车/预约两原对话HTTP联调，最后根使用内置浏览器1920×1080验收样式与操作。本次明确授权覆盖此前等待人工截图的执行方式；保留原剩余范围，不标整体验收完成。根已复核Admin #567及Lastleg #259最新提交成功且健康、两代码仓库无未提交改动，无需重复部署。两个原对话已收到独立HTTP会话派工，拼车保留原A已核量/B待核量样本；预约保留原未定时样本并补专用TEST非空取消历史。浏览器由根独占，待HTTP结果后续验。
|
||||
|
||||
2026-10-11按用户新顺序完成HTTP后进入UI：拼车报告reports/fleet-increment-readonly-20261011/证明A RECEIVED/B CONFIRMED状态保留、ACY2余26托/17798kg/86m³、销售互查与客户访问被拒绝；纯列表只读账号缺失未覆盖。预约reports/appointment-cancel-history-live-20261011.json证明原合成AP-20261011-6E396F904F78取消后恢复PENDING v2，原备注/日期/1票关联保留、取消历史1条，分页1条与空下一页成功；独立平台编辑但无取消权限账号缺失未覆盖。根刷新Admin #567后读取实际视口1920×1080/scale1，列表及A只读详情分别显示预报/已核实，预计实托独立且未知未伪填，固定底部可见；FL-DESIGN-004视觉关闭。原始1920截图fleet-cargo-labels-admin567-20261011.jpg、fleet-verified-detail-admin567-20261011.jpg，未提交核量/排车；预约及其余证据仍待UI核对。
|
||||
|
||||
2026-10-11根继续Admin #567页面验收：取消记录列表及展开历史已显示独立取消原因、原备注、原待定计划和时区，查看详情没有保存入口。专用取消表单在DOM视口1920×1080、scale1下字段、说明及底部按钮完整可见；空原因点击后仍留在表单，源码明确warning并return，但短暂warning未截图，不把该提示的页面证据标记通过。已关闭表单，未提交有效取消。证据为reports/three-module-ui-1920-20261010/appointment-cancel-{list,history,required}-admin567-20261011.jpg；表单另存viewport.json，原始截图未缩放或补边。两个原对话按用户新指令并行只读核对设计文档与实现，初步差异尚待条款核实，不计为已修复或整体完成。
|
||||
|
||||
2026-10-11设计复核新增待修项：预约已排期卡片及入仓单关联预约缺列表权限下完整只读入口，已交原预约对话修复；拼车按已采用操作简化方案确认车次摘要、返回原登记路径、权限内本土订单链接、分操作成功及下一步反馈共4项缺口，已交原拼车对话最小修复，均未部署。未冻结的改期原因、汇总筛选及核量后永久差异投影不自动纳入。根同时完成提柜及接仓跟进来源说明1920×1080/scale1视觉核对，两个弹窗分别明确提柜共用记录和接仓点共用记录，不自动确认预约/推进收货，未保存业务记录；证据reports/three-module-ui-1920-20261010/appointment-pickup-explanation-admin567.jpg、appointment-receipt-explanation-admin567.jpg及各自viewport.json；FBA来源说明仍待补验。
|
||||
|
||||
2026-10-11根完成FBA来源跟进说明视觉验收：NYEXX2610080222弹窗在1920×1080/scale1下明确说明仅用于此货源FBA收货跟进，保存联系不确认预约/推进收货，已关联预约及收货/货件资料缺口完整显示，未保存新记录。证据reports/three-module-ui-1920-20261010/appointment-fba-explanation-admin567.jpg及viewport.json；AP-DESIGN-004三类来源说明视觉项关闭。新发现的预约只读入口修复已在当前工作区交付6个前端文件，42项定向测试及类型检查通过；根复核diff与现有详情GET读取权限一致，写入/取消权限仍独立；尚未提交或部署，不能记为现场已修复。拼车4项修复继续进行。
|
||||
|
||||
2026-10-11预约只读入口及拼车4项引导偏移修复已统一提交推送Admin release/test：315cb8e663d9200ee993b54a16cdc27dbef313ad，共21文件。合并全量测试2855通过/1旧源码返回断言失败；同步受影响合同断言后合同及排车详情25项通过，未删除原业务断言。专项81项、预约42项、迟到响应28项通过，合并类型检查及构建通过。仅Admin发布已触发，queue7479，报告reports/navigation-readonly-admin-deployment-20261011.json；此时尚未核实部署成功，Lastleg继续已验证#259，无SQL或后端变更。发布后需只读HTTP及新入口页面回归，不能据提交宣布验收完成。
|
||||
|
||||
2026-10-11 Admin #568发布完成：SUCCESS，耗时55.097秒，实际checkout精确315cb8e663d9200ee993b54a16cdc27dbef313ad，admin-web-test容器Healthy；Lastleg仍#259。报告reports/navigation-readonly-admin-deployment-20261011.json。根已通知两个原对话以既有样本独立会话补只读HTTP，之后回归新增只读入口、关联本土订单及受限返回路径；未重做业务写入，整体验收仍未完成。
|
||||
|
||||
2026-10-11 Admin #568拼车增量页面验收：专项6次GET全部HTTP200/业务200，原A/B及BOUND状态保留。根刷新新版本后，从FB-2108714742102147074查看进度确认新增客户/目的地/车次/登记/负责人摘要；点击LB-ACY2-20261010-651779准确定位列表并自动打开只读承运安排，车次及排车关联一致；关闭后点击返回原拼车登记，成功自动重开原FB。1920×1080/scale1截图fleet-summary-admin568.jpg、fleet-order-link-admin568.jpg及各自viewport.json存于reports/three-module-ui-1920-20261010/。未写入业务；排车/车次返回及预约新增只读入口仍待UI补验，独立只读角色限制继续保留。
|
||||
|
||||
2026-10-11 Admin #568根完成原BOUND登记→排车/车次→返回原登记真实操作，两条均自动重开同一FB-2108714742102147074。车次返回文案和1920布局通过（fleet-trip-return-admin568.jpg）。排车虽返回行为正确，但真实可见文本仍为“返回列表”，aria为“返回原拼车登记”，已交原拼车对话修正直接组件可见文案，不计视觉通过；失败证据fleet-dispatch-return-admin568.jpg。所有证据位于reports/three-module-ui-1920-20261010/，未写入业务。
|
||||
|
||||
2026-10-11 Admin #569收尾增量：f97cdad3538d22e8eef8bf473f785f1e55d2f081已提交推送并发布SUCCESS，精确源码匹配且Healthy，54.324秒。3文件修正排车详情可见返回文字；全量345文件/2856测试、类型检查及构建通过。根刷新新版后在1920×1080验收可见“返回原拼车登记”，点击自动重开原FB-2108714742102147074，通过。预约日历只读入口与入库单IP-ABE3-20261008-210754查看预约均已真实页面核对，无保存入口、字段禁用；证据见reports/three-module-ui-1920-20261010/{fleet-dispatch-return-admin569.jpg,appointment-calendar-readonly-admin568.jpg,appointment-inbound-readonly-20261011.jpg}及预约配对JSON。未新增业务写入。用户新授权缺账号可创建，两个原专项补独立受限角色HTTP证据；新增请求量及关联PDA390×848检查仍在进行，整体验收未完成。
|
||||
|
||||
2026-10-11请求量及权限补验：预约两种专用受限角色实测list GET成功、PUT/DELETE A0403，edit-no-cancel DELETE A0403，AP完整详情前后不变；拼车专用list-only读取发布成功，他人登记/履约及写命令A0403，原FO/BOUND不变。脱敏证据reports/appointment-role-audit-live-20261011.json、fleet-readonly-role-audit-20261011.json；新增3个专用账号，凭据仅私有配置，未改现有身份。拼车inquiry参数返回后刷新重复GET通过组件测试复现：每次发布GET1+登记GET2，修复为登记GET1，保留所属发布校验和最新读取。43611ecc5501b528c933084460a63ba905467ec9经345文件/2857测试及构建通过，Admin #570精确发布SUCCESS/Healthy，54.701秒；真实新版UI复验仍待。浏览器CDP网络启用超时，未据此声称实时请求计数通过。
|
||||
海外PDA本机原5175/5176服务配置未明确TEST，未登录；另以同工作区进程环境明确TEST启动127.0.0.2:5176，代理日志证实目标TEST。390×848工作台、31条转运候选、开始确认弹窗及取消通过截图；登录POST1、仓资料GET1、候选首次GET1、刷新GET1均200，打开确认及取消零请求。证据reports/three-module-ui-1920-20261010/overseas-pda-{home,transfer-list,start-confirm}-20261011.jpg及home viewport.json；仅H5当前源码连接TEST证明，不外推部署产物、其他PDA作业或Android硬件。国内PDA及剩余页面/请求量证据继续验收。
|
||||
|
||||
2026-10-11收尾补验：Admin #570的重新核对同登记自动重开已有fleet-refresh-admin570.json/jpg通过，原待UI标记过期。根补拍未定时预约列表及采购预估费用释放结果，分别appointment-unscheduled-admin570、procurement-estimate-released-admin570，均配实际DOM1920×1080/scale1；原0.01元仍显示已释放、不入池、历史版本，无新业务写入。独立预约list-only账号已真实登录，未定时详情仓库readonly，其余五字段disabled，只有关闭/退出弹窗按钮，无保存或取消预约命令；证据appointment-list-role-readonly-admin570.json/jpg，保存登录身份和尺寸。国内PDA当前H5的home viewport为390×848/scale1，domestic-pda-network-20261011.jsonl记录登录、仓列表、首次任务、手动刷新各一次200；仍不外推全部作业。历史采购网络原文件已复核：reports/procurement-ui-20261010-r1/admin-list-network.json列表1+客户选项1，detail及refresh各1；Client列表1、创建POST1+详情GET1。Client公共待办轮询记录没有时间窗口，不能推断频率；当前源码为可见页60秒一次、focus/visibility触发、在途去重。用户指定新浏览器验收对话01a12ae6-c6d8-7331-8f26-4d4009f873bc，已下发Client页面及定时请求核对；根保留Admin，PDA视口窗口另行交接。剩余其他受限角色UI、关联PDA作业页、短暂提示与网络计数未全部收口，整体验收仍未完成。
|
||||
|
||||
2026-10-11预约edit-no-cancel独立账号真实UI补验通过：10月15日两张预约卡片均显示查看预约/编辑，无取消预约；打开AP-20261010-7A779BFFEB56编辑弹窗可编辑日期/备注并显示保存，未提交。1920×1080/scale1及账号身份保存于reports/three-module-ui-1920-20261010/appointment-edit-no-cancel-admin570.json/jpg与appointment-edit-no-cancel-form-admin570.json/jpg。结合既有DELETE A0403，预约两种受限角色接口与页面证据已补齐。
|
||||
|
||||
2026-10-11拼车list-only独立账号UI补验：可拼车次列表仅详情，FO-2108713050417709058详情仅返回/重新核对，无登记、发布修改或调度写入入口；我的登记0条，不显示其他人记录。1920×1080/scale1配对证据fleet-list-only-admin570.json/jpg、fleet-list-only-detail-admin570.json/jpg位于reports/three-module-ui-1920-20261010/。该账号无自有登记，正向自有登记详情仍未覆盖，不能以空列表代替。新Client验收对话首次使用包装器超时，已下发本机实测可用的直接tabs.get+单次DOM/截图60秒预算恢复步骤；根未切换其Client会话。
|
||||
|
||||
2026-10-11并行Client补验收口：新验收对话已恢复直接tabs.get/DOM/screenshot工具路径，完成同一客户列表、ICSGS202610100001终态详情首屏及费用区；根复核list/fees图片与metadata。实际窗口1920×1080/scale1/DPR1，列表scrollWidth=clientWidth=1920；详情有纵向滚动条，内容1905但窗口仍1920，不能据截图像素判错误。费用汇总净实扣CNY0.01、预估占款0，原预估结清与实际运费扣款分开显示。证据reports/client-parallel-acceptance-20261011/{client-list-1920,client-detail-top-1920,client-detail-fees-1920}.jpg及对应viewport JSON，新建页复用原配对证据。本轮实时60秒网络窗口未取得，历史实际轮询间隔59.99–60.01秒及源码可见页60秒轮询单独记录，不假报当前实测。已将PDA390×848视口窗口交新验收对话，根暂不操作浏览器；国内/海外根自启TEST代理进程均刚确认存活。剩余关联作业页、拼车只读自有样本及明确残余证据继续补验。
|
||||
|
||||
2026-10-11新增真实缺陷已修复发布：船期影响历史连续分页的迟到响应在定向测试中复现2失败/5通过，会覆盖新页并提前解除loading。AppointmentImpactDialog仅接收最新代次的详情/错误/loading，卸载失效旧请求，加载时禁用分页并阻止基于旧详情提交。修复后7项定向通过，Admin全量345文件/2860测试、类型检查及构建通过。提交20b4d1425b8057f91e5d9e23a9b3821cfb7f9913已推送release/test，Admin #571 SUCCESS/精确源码/Healthy，53.453秒；reports/impact-history-race-admin-deployment-20261011.json。只改组件及测试2文件，Lastleg仍#259，无SQL。普通打开/历史显示新版UI烟测仍待PDA视口窗口交回，不把自动化逆序响应测试说成现场网络故障注入。
|
||||
专用拼车只读正向样本已按正式IAM/业务API准备：新身份先最小销售权限创建FB-2109268527119646721草稿，再收敛为精确capacity-offer:list并重新登录；自有详情/fulfillment200，取消A0403，三个写资格false且拒绝前后详情一致，无占位/来货/排车，原A/B/BOUND各自状态版本保持。reports/fleet-readonly-own-inquiry-20261011/http-result.json，私有凭据仅env。该新样本UI待补，不能改用原空列表证据。
|
||||
|
||||
2026-10-11拼车自有登记只读补验完成：新增专用只读身份在1920×1080/scale1打开自身DRAFT登记FB-2109268527119646721，列表只有查看进度，客户货物跟进弹窗字段全部禁用，无保存、确认承运或取消预订命令，底部取消仅关闭弹窗。截图及DOM尺寸证据reports/three-module-ui-1920-20261010/fleet-own-readonly-admin571.{jpg,json}；未提交业务变更。PDA专用1箱样本FB-2109271606594420737/WT-5T4IC0WKK0HOR1GHURCUH9BVC经正式接口准备至WAIT_PDA_RECEIVING，约定运费0；旧专用账号登录A0403，候选查询未验证。已移交新浏览器验收对话使用现有有效会话核对精确WT并补作业页，根交出390×848视口窗口。原A/B/BOUND及只读草稿状态保持，未把样本准备当作收货验收完成。
|
||||
2026-10-11海外PDA新样本已进入测量并正式生成PLT-USLAX01-261011-G0WSEW7CUF41，仍待绑定，未完成打托。真实H5代理日志确认本票详情/照片各GET1，草稿/生成各POST1，均HTTP200；证据overseas-pda-synthetic-network-20261011.json，不能据无时间戳日志推断轮询频率。390×848截图发现打印标签按钮换行，根仅修warehouse-transfer.vue布局，24项直接检查及H5构建通过，等待同单视觉复验；尚未提交发布，不代表线上PDA已修复。
|
||||
2026-10-11 Admin571普通UI复核通过：管理员admin1打开原AI-D4D736964D9A4E3B9015并展开3条历史，详情/关联货物/预约正常，正文滚动和固定底部可见；保存appointment-impact-history-admin571.jpg及viewport/DOM证据，无新处理写入。异步逆序保护仍依据组件复现，不冒称真实网络注入。海外PDA打印按钮390×848同单复验通过，92×46单行，底部提交门禁完整；修复4f56d97合并远端两笔非本页更新后HEAD9c3855cec2195b49659606dfba8aef0a116336b0已推送release/test，237全量测试及H5构建通过，TEST发布尚待执行。
|
||||
2026-10-11拼车旧截图规格缺口已补：Admin571下原BOUND登记FB-2108714742102147074管理员详情与外接来货详情重新取证，配DOM1920×1080/scale1。确认已核实1箱/1托位/100kg/1m³、已排入本车且不冒称已发车，来货WT-2OLDI4ZED3XOOGQR5P82OYW1N及原托盘一致；截图fleet-manager-bound-admin571.jpg及viewport、fleet-bound-receipt-admin571.jpg/json经根视觉核对。未核量、排车或修改原数据，原1905像素截图不再作为唯一尺寸依据。PDA样本页面交付已收取，打印修复远端已推送但静态TEST发布仍待执行。
|
||||
2026-10-11海外PDA打印修复TEST发布成功：源码9c3855cec2195b49659606dfba8aef0a116336b0，镜像pda-overseas-h5-test:h5-20261011-42b5d73aecb1，healthy且firstleg-test-network正确，实际首页与全部83个静态文件SHA256逐项匹配本地产物。发布目录20261011-print-r1，仅海外PDA静态容器；国内未发布。证据reports/pda-print-release-20261011-r1/{dispatch,verified-files}.json。公网H5精确入口尚未定位，已向用户询问；当前390×848修复图仍是同源码本地H5连接TEST，不冒称公网发布后UI已验。
|
||||
|
||||
2026-10-11用户提供更新后的国内及海外PDA公网TEST入口，发布后H5补验完成：两端真实登录成功，分别进入义乌仓、洛杉矶仓。海外原专用WT-5T4IC0WKK0HOR1GHURCUH9BVC恢复同一待绑定托盘PLT-USLAX01-261011-G0WSEW7CUF41，1箱/1kg/1m³；打印按钮92×46、nowrap，实际390×848/scale1、scrollWidth390，已在公网截图确认修复。国内47项出库列表及既有TSTU4721636装柜取证页面正常，五类照片/封签/禁用提交完整，实际390×848/scale1、scrollWidth390；此国内样本仍只证明布局，不充作本轮关联链路完成。证据reports/three-module-ui-1920-20261010/overseas-public-viewport-20261011.{png,json}、domestic-public-20261011.png及domestic-public-viewport-20261011.json；fullPage海外截图为空白，仅用viewport截图作证。未生成新托盘、绑定、上传照片或最终收货。公网入口缺失阻塞已解除；短暂提示截图与本轮定时请求证据仍未齐，不宣称三模块全量验收完成。
|
||||
|
||||
2026-10-11剩余网络证据只读复核：当前内置浏览器Network.enable及readEvents均工具超时。通过既有TEST Jenkins agent只读检查容器，匹配到firstleg-test-gateway；最近15分钟日志限尾1000行实得31行，无/api/路径及HTTP方法，未发现独立nginx容器。报告reports/three-module-ui-1920-20261010/server-log-observer-20261011.json；不能将普通日志行数当页面请求数，也不据此声称零请求。仍需可用浏览器网络时间窗口证据；未修改服务器日志配置、重启或部署。
|
||||
|
||||
2026-10-12按用户确认以真实HTTP补验收尾：已有TEST预约AP-20261011-6E396F904F78取消原因空串/纯空格，以及当前有效货物来源跟进result空串/纯空格，共4请求均HTTP200+业务A0422（字段必填），不是权限拒绝。预约完整详情、取消历史和跟进历史请求前后哈希一致，未新增业务记录。证据reports/three-module-ui-1920-20261010/http-validation-recheck-20261012.json；接口负向校验通过，不代表短暂提示截图或浏览器请求频率已验证。
|
||||
|
||||
2026-10-12客户共享消息未读数并发请求修复已发布：布局与消息页同时调用的定向测试修复前实际2次（预期1次）失败；store合并并发只读请求，已读操作后等待旧请求结束再重新查询，失败后可重试。3项行为测试及相关10项检查通过，合并远端退货展示修改后Client全量547项测试及生产构建通过。本次修复3692f9d，合并发布db44d24eb403fd86d550e703cac5a5d3bf6b6076已推送release/test；client-web-test #400 SUCCESS，29.183秒，精确源码与Healthy核对通过，报告reports/client-notification-deploy-20261012.json。仅Client发布，无SQL。该证据证明本地并发行为和精确发布，不替代浏览器实时Network计数；发布后页面烟测仍待完成。
|
||||
|
||||
2026-10-12 Client400发布后页面复验：重新加载公网采购创建页后导航我的消息，1920×1080/scale1、scrollWidth1920，空列表、导航、操作列显示正常。Network.enable和首次事件读取恢复成功，消息列表GET1、未读数GET1，另有独立customs/pending-summary GET1；静置45秒后的事件读取工具超时，不能推算完整轮询频率。证据reports/three-module-ui-1920-20261010/client400-messages.png、client400-smoke-viewport.json、client400-network-20261012.json；无业务写入。
|
||||
|
||||
2026-10-12请求频率机制补核：ClientSidebarMenu中的customs/pending-summary独立于notifications/unread-count，为60秒计时且仅visibilityState=visible发起；focus/visibilitychange触发刷新，store对普通在途刷新去重、身份切换丢弃旧响应、业务写后强制刷新以新代次防覆盖。现有4项行为测试通过，报告reports/three-module-ui-1920-20261010/customs-polling-review-20261012.json。该结论是源码及行为测试，不能冒充当前线上持续时间窗口实测；已知消息列表/未读数单次导航实测另存client400-network-20261012.json。
|
||||
|
||||
|
||||
2026-10-12经用户本轮明确授权，将采购、拼车、预约及匹配端侧冻结TEST版本发布至既有临时灰度（prod命名Jobs/main；不改变唯一TEST架构目标）。四仓PR已合并，合并树与冻结源一致：Backend main 4dc3d1752e278600785486a1ed90c8d1960e887d（源29b562ebf5a4ece6f2333a28463929cf628dfedb）；Admin main 545205e28d436dbf798e0425cb46ce5c2377bc59（源20b4d142）；Client main 15b51b61396390b800e070cc50b20c06006c596d（源db44d24e）；海外PDA main 4246468179da278afb61ff5cc35af1228fb49001（源9c3855ce）。灰度单服务Warehouse #10、Firstleg #15、Finance #10、File #18、Lastleg #14、Order #10，以及Admin #27、Client #18全部SUCCESS并核对精确提交。上述6个后端及3个前端最终9个容器全部healthy、镜像tag匹配。国内PDA保持原版本。
|
||||
|
||||
本轮灰度SQL独立获授权并执行：新增24表、20字段及对应索引约束、空采购表5个废弃列移除；删除1条旧测试预约及2条明细并重建2表；新增13项采购权限与1项预约跟进权限，采购按现行管理员规则、跟进仅PLATFORM_ADMIN，关联主体权限版本同事务推进；302条公共仓timezone按现行仓库编码主数据更新为IANA并推进版本，16条待核实空值保持不动。没有清空其他业务表或重放整库种子。Lastleg在结构变更窗口停止，匹配版发布后恢复。执行与复核证据位于baiyue-firstleg/reports/three-module-gray-20261012/{sql-execution-result,schema-review,warehouse-timezone-plan}.json。
|
||||
|
||||
灰度发布后真实HTTP：管理员登录、新14权限、采购列表/仓库选项、拼车车次/需求池、预约货源/整柜/影响事项/日历，以及客户订单工作台和采购列表均HTTP200+业务200，独立会话均已退出。客户工作台10项queues和progress符合当前客户端解析合同；首轮脚本误要求long序列化值必须为JSON number，改按客户端Number转换核对后通过，未修改应用或追加部署。Admin/Client公网入口200，分别59/95个引用JS/CSS正常返回。海外PDA直接复用TEST已验83文件产物，容器文件与loopback HTTP全部SHA256一致、healthz200。最终证据：同目录release-state.json、final-runtime.json、http-smoke-result-r2.json、public-web-smoke-result.json、pda-overseas-release-complete.json。以上证明匹配发布及接口/静态资源烟测，不代表新一轮完整业务写流程或所有页面弹窗人工验收；此前短暂提示截图、持续网络窗口缺口未伪称补齐。
|
||||
|
||||
2026-10-12 单票头程到海外正常链 HTTP 验收完成：依用户授权，通过正式接口完善并审核既有灰度专用客户，复用既有仓、渠道、供应商、车辆与司机，以一票一箱 FBA 买单报关样本执行。订单 FL2109479189589245954、入仓码 ZBYHK2610120001、货柜 TSTU9837300，已完成下单审核、测量与费用确认、订舱分柜、国内 PDA 装柜、买单报关、人工船节点、目的港预约、海外 PDA 收货卸柜、还空柜、排车转派送、车次绑定与拣货装载审核、发车出库、签收及国内回传。派送单 DL-WH-20261012-398465 已签收，国内订单 COMPLETED、入仓单 DELIVERED，车次货物结案且车辆/司机资源释放；会话退出完成。报告为 baiyue-firstleg/reports/single-order-gray-20261012-v2/result.json，最终标记 SINGLE_ORDER_HTTP_COMPLETED，范围仅 ONE_ORDER_NORMAL_HTTP_PATH。初始草稿缺订单层 FBA 货件/参考编号，保留原拒绝证据并修正同一票后按新版本重新提交，未新造替代订单；脚本同步修正无当前收货会话 A0404 及卸柜正式状态 UNLOADED 的判断。所有材料均为合成验收证据，不代表真实货物、硬件、浏览器视觉、多客户/异常分支、故障注入、支付或第三方下单验收；本次无 SQL、删除、重置或部署。
|
||||
|
||||
上述脚本定向离线检查 8 文件/72 项通过；全范围离线检查分别为 scripts 根级 79 文件/709 项（696 通过、13 失败），Admin 模块 129 文件/1159 项（1154 通过、5 失败）。失败文件精确记录于同目录 result.json：agents-index-registry-contract.test.mjs、database-schema-alignment-migrations-contract.test.mjs、java-quality-summary.test.mjs、synchronous-dependency-contract.test.mjs，以及 admin-test-env-modules/initialization-baseline-contract.test.mjs、phase3-producer-chain-contract.test.mjs。AGENTS 索引门禁仍因登记表不符合固定三任务假设失败，未改动登记表或放宽断言。本次 HTTP 正常链通过不等于全仓质量门禁通过。
|
||||
|
||||
+45
-4
@@ -1,5 +1,4 @@
|
||||
# 海外仓业务范围与快速索引
|
||||
|
||||
## 已确认业务边界
|
||||
|
||||
- 当前开发环境按端到端全流程交付，不再用开发批次切断上下游。订单与客户、入库测量与计费、国内货柜履约、海外仓业务和财务共同组成一条连续业务链。
|
||||
@@ -13,14 +12,56 @@
|
||||
|
||||
## 功能快速路由
|
||||
|
||||
- [采购订单样品履约流程变更需求](采购订单样品履约流程变更需求.md)：采购样品购买、装箱、面单、交寄、国内核费与寄客户的变更入口。
|
||||
|
||||
- [美国预约管理统一总览与优化方案](美国预约管理统一总览与优化方案.md)：提柜、用车、FBA及普通送货等统一展示的需求梳理与设计建议。
|
||||
|
||||
### 预约送仓
|
||||
|
||||
- 预约以同一目的 FBA 仓组织，允许选择多个客户的入仓货物统一预约；同仓不同日期或时段可以分别建约。预约主单不归属单一客户，客户归属保留在每票货物明细，库存、订单、费用及派送的客户隔离不随合并预约改变。
|
||||
内部历史展示读取仓库元数据使用`POST /internal/warehouses/platform-metadata/batch`，由Warehouse权威提供，内部服务令牌鉴权且不经公网Gateway。每批1至2000个不重复正数ID，只读平台公共仓的编号、名称、类型、国家、原时区和状态，包含停用仓；不存在、非公共或已删除的ID统一列为缺失，不返回联系人及客户数据。调用方不得把原固定偏移或缺失时区猜成IANA地点时区；国家/时区不明时单列待定位，不放入美国当地日期格。接口合同见Warehouse `warehouse-v1.yaml`。
|
||||
|
||||
仓库主档时区使用IANA地点标识（如`America/New_York`），不以固定UTC偏移表示当地时间。国内默认`Asia/Shanghai`；明确单一时区的美国州可自动选择，多时区或存在地方例外的州须按实际地址确认。新增、编辑和导入在Warehouse共用校验。初始化地址资料无法确定地点时区时保留为空并阻止正式预约确认；不根据旧偏移批量猜测或迁移现有主档。参考[IANA时区数据说明](https://www.iana.org/time-zones)。
|
||||
|
||||
- 预约以同一美国起运仓和目的FBA仓组织，允许多个客户的真实货源统一安排。未建入仓计划也可保存；同仓不同日期/时段、不同货物可以分别建约。主单不归属单一客户，客户归属保留在每票货物明细，库存、订单、费用及派送的客户隔离不随合并改变。
|
||||
- 预约管理日历和入仓单中的预约操作共用 Lastleg 的 FBA 预约记录。平台可读取完整预约；客户只能经自己的订单/入仓单读取本客户货物，不开放跨客户预约详情。
|
||||
- 预约号全局唯一；同号同内容重放返回原记录，异内容拒绝。已有有效预约的货物不得重复加入另一张有效预约；取消后重新预约的货物，不得通过恢复旧预约重复占用。
|
||||
- 预约开始、结束时间与预计装车时间分别维护；结束时间未明确时留空，不自动推算。编辑使用版本校验，避免覆盖其他运营人员已保存的修改。
|
||||
- FBA日历按地点当地时段与查询范围相交读取，跨日安排在覆盖的每一天展示同一业务记录；午夜结束不占次日，仅日期安排只占当天。确认时段与计划时段成对选用，不用旧计划结束时间补齐未知确认结束时间。卡片保留完整起止日期，切换已加载日期不追加查询。
|
||||
- 系统生成全局唯一AP业务单号，外部确认号单独保存并按目的FBA仓唯一。创建和编辑携带持久化幂等键、操作者及请求摘要，同键同内容返回原命令快照，即使后来编辑也不改变原结果；异内容拒绝。主单、明细和命令记录同事务。活动货源键与已形成订单均有数据库唯一占用约束，取消后恢复原单也必须重新核对占用。
|
||||
- 计划日期、可选计划时段、对方确认时段分别保存；仅有日期不补09点/零点，未定日期进入未定时列表。PENDING允许外部约号及箱数暂缺，不伪造值；SUCCESS必须有真实货量、FBA货件号或追踪号、外部确认号以及目的仓权威IANA时区，校验夏令时并保存对应UTC时间点。结束时间未知保持空。预计装车归运输安排，不再作为FBA预约写入字段；没有权威装车事实的关联查询明确返回未知。
|
||||
- 入仓明细入口仅用lineIds选择业务货物，服务端批量转换成原ORDER/BOOKING整票来源；外接来货后仍保持BOOKING键，禁止同时以ORDER别名建约。主表和明细只有一套，不并行维护“提前预约”副本。仓储转运的目的地和货件资料读取实际转运主记录，不能把未填充的尾程展示投影误报为目的地变化。
|
||||
- 取消/未约成须记录原因并释放货源占用，保留原计划、确认事实和历史，不回退库存；已有有效排车时先核对并处理运输安排。编辑使用版本校验，已确认预约不能直接退回待确认。
|
||||
- 用车计划来源读取Fleet日期范围接口，一车一条，保留计划/实际出发及司机任务预计结束的UTC时间点，不表示收货预约已确认。前端最多显示42个起运仓当地日期，通过前后各14小时的UTC检索余量覆盖跨日，逐条按权威地点时区落格；缺仓库、国家或时区时独立展示待定位记录，不用浏览器时区猜测。服务端UTC保护窗口最多44天，超过2000条明确拒绝并要求缩小范围，不逐页扫描或静默截断。读取仍需车次列表权限，正常一个车次SQL和一次内部仓库元数据批量调用；目录失败不可当作空结果。
|
||||
- 提柜日历读取Firstleg原码头拖车记录，入口为`GET /api/platform/v1/terminal-drayages/calendar`，同时要求预约列表与码头拖车列表权限。按启用目的仓国家筛选美国业务范围，不推断港口国家；原预约日期无时区事实时显示待核实，不套用收货仓时区或转为UTC。日期范围最多42天、一次批量查询；超过1000条或目的仓无法分类时标记统计不完整，目录失败报错，不能假装无预约。详情回到原清关提柜业务，不由日历直接写原状态。
|
||||
- Admin 入口为 `../../apps/admin-web/src/modules/appointment-calendar/`，既有入仓单入口为 `modules/overseas-warehouse/`。日历读取权限为 `platform:appointment:list`，既有预约写权限独立；API 合同见 `../../baiyue-firstleg/lastleg-service/src/main/resources/openapi/fba-appointment-calendar-v1.yaml`。合并预约不表示已经排车或发车，运输执行继续按既有排车与共享车次流程处理。
|
||||
|
||||
#### 在途货源与拼车外接货的预约跟进合同
|
||||
|
||||
本节规定来源解析、人工跟进和已有预约覆盖的共同边界。美国全类型预约的总体目标见[优化方案](美国预约管理统一总览与优化方案.md)；本节接口不代表总体目标、环境发布或整链验收已经完成。
|
||||
|
||||
| 事实 | 唯一来源与规则 |
|
||||
|---|---|
|
||||
| 头程已开船货 | `ORDER:<尾程订单ID>`；依据真实船节点和美国接仓点/FBA目录读取，不要求先建入仓计划。建计划后仍是同一来源，不重复计票。内部ID仅用于关联，不作为业务编号展示。 |
|
||||
| 拼车外接货 | `BOOKING:<原登记号>`；Fleet提供客户、目的地、接仓点、承运阶段、版本及可空的实际订单关联。确认承运后尚未来货可记录联系；生成订单后保持BOOKING键，禁止同时以ORDER别名重复计货。未知箱数保持空值。 |
|
||||
| 时间 | 在途列表的预计到港/到仓是订单保存的快照；船节点观察时间不代表实时ETA。预约已确认时间只读，不被预计时间更新覆盖。原预约缺少时区时明确待核实，不按操作者浏览器时区猜测。 |
|
||||
| 人工跟进 | `ll_appointment_followup`保留追加历史，跟进人取登录主体；允许没有入仓计划、约号、车辆时保存。提柜联系与码头申请按稳定柜次共享，接仓联系按柜次及实际接仓点共享，FBA联系按ORDER/BOOKING货源及客户保存；各事项独立，不推进正式确认或作业状态。 |
|
||||
| 预约覆盖 | `AppointmentCoverageService.query`按稳定来源及客户批量读取FBA预约，数量核对未覆盖、部分覆盖、待确认、已确认和待复核。外接货尚无订单但已保存安排时返回待确认及资料缺项，不返回假确认。正式确认号、地点时区和已核实来源版本分别读取；来源版本变化仅提示复核，不声称已完成精确船期影响分析。仓储转运的目的地与货件资料以转运主记录为准，缺少资料与实际目的地变化分开表达。 |
|
||||
| 运输和容量 | 车次、正式排车关联、容量、余位及发布由Fleet维护。预约侧读取其真实结果，不以联系记录生成库存、托盘、车次或容量，也不在前端扣减余位。 |
|
||||
|
||||
HTTP入口为`/api/platform/v1/last-leg/appointment-planning`，包括`GET /cargo`、`GET /sources/resolve`及`GET/POST /sources/{sourceKey}/follow-ups`；请求和响应定义见[预约筹划OpenAPI](../../baiyue-firstleg/lastleg-service/src/main/resources/openapi/appointment-planning-v1.yaml)。深链进入预约页时须由后端重新核对客户、来源与目的仓，不能信任URL赋予资格。读取同时要求`platform:appointment:list`与`platform:overseas-warehouse:last-mile-order:list`，追加跟进另需`platform:appointment:followup`；仅平台主体可用，客户端不暴露跨客户货源。
|
||||
|
||||
整柜入口为`GET /containers`、`GET /containers/{containerId}`与`GET/POST /containers/{containerId}/follow-ups`，沿用上述权限。未传`warehouseId`记录整柜提柜或码头联系，传入时仅记录该柜实际接仓点的接仓联系。共享来源键由服务端生成`CONTAINER:<柜次>`或`CONTAINER:<柜次>:WAREHOUSE:<仓库>`，技术平台作用域不接收客户端客户参数，也不在界面展示内部键。原货源写入口仅接受FBA联系，不能逐客户重复登记整柜事项。
|
||||
|
||||
整柜列表读取实际已开船且仍有效的头程货物，覆盖美国接仓点的各种目的地类型；不要求先建入仓计划。关键词命中某票后仍统计同柜全部美国范围货物，接仓点一次批量分组加载。任一票箱数未知则汇总箱数显示待核实；同柜另有未知或非美国接仓点时明确标记范围不完整并禁止新联系记录。来源预计到港仍是订单快照，不能当作实时船期或预约确认。已有联系历史在来源离开活动列表后保留可读。
|
||||
|
||||
跟进写入携带事项版本和持久化幂等键。同键、同操作者、同内容重试返回原记录；异内容或不同版本冲突拒绝，未知结果重试保持原请求。跟进保存成功不代表预约申请或确认成功。仓库目录失败必须报错；日历某来源失败时保留其他来源结果并标注统计不完整。
|
||||
|
||||
跨客户合批核对入口为`POST /batches/preview`，读取权限与来源查询相同，单批最多100票。服务端批量核对ORDER/BOOKING来源、客户归属及真实订单，拒绝重复别名、不同起运仓/目的FBA仓、暂扣、多目的地及已有有效预约；未知箱数保留缺项。`POST /appointments`重新核对后保存同一FBA预约聚合，另需既有FBA预约写权限；`GET /appointments/unscheduled`按预约列表权限分页读取无日期安排。允许未建计划及已确认承运但尚未来货的真实来源，不能信任浏览器预览作为写入依据。两种创建入口均自动提交选择时的接仓点和目的FBA仓，服务端在锁定货源后与当前事实比对；任一变化返回冲突并要求重新核对，不静默改约至新仓，也不增加人工填写字段。备妥窗口无权威依据时明确待核实，不能用预计到港或到仓替代。部署与真实验收状态见环境主契约。
|
||||
|
||||
已确认承运的外接货从原登记深链或`GET /external-candidates`服务端分页列表进入，必须经服务端核对后才能加入既有预约合批工作区；使用同一预览/创建接口，与同起运仓、同目的FBA仓的头程货共同保存，保留原BOOKING键，不生成ORDER别名。来源已有有效预约时不再提供新增入口；未形成入仓码或箱数未知仍可保存待确认安排，正式确认继续核验资料。
|
||||
|
||||
外接候选由Fleet只读适配器按原登记分页发现，限已确认承运/已实收/已绑定、车次未取消或完成、权威启用美国接仓点和FBA目的仓范围；支持登记号、车次号、客户名称及来货号检索，每页最多100票。预约侧对当页来源和覆盖批量核实，保留客户归属、原登记、真实订单关联及未知箱数；目录失败显式报错。Admin仅打开外接货源列表时请求，切换头程/外接保留同一合批选择，保存后刷新覆盖。它不提供承运确认、车次容量或发布写入。
|
||||
|
||||
共同样例：两柜头程货送同一美国接仓点再送ONT8，提柜分别按两柜联系，FBA货源保留各票ORDER来源；同一车次接入外部登记B-1时保留BOOKING:B-1。B-1确认承运但尚未来货时可以跟进和保存安排，不伪造入仓码或对方确认；实际来货在原登记行锁和同一事务内，将已有有效预约明细关联到真实订单及入仓码，继续通过同一BOOKING键读取覆盖；关联失败则来货事务一起回滚。该关联不自动改写预约数量快照、确认时间或来源版本，也不扫描补填历史记录。预约保存按登记号和订单号的稳定顺序锁定货源，并在订单锁定后清除查询缓存、重新核对来源，防止使用锁定前的旧事实。客户不符、目的仓变化、重复别名或已取消承运均不能借用其他货物的预约结果。跨来源筹划、正式确认和变化处理遵循总体方案，读取或核对成功不能代替保存和正式确认成功。
|
||||
|
||||
| 业务域 | 能力范围 | 原型入口 |
|
||||
|---|---|---|
|
||||
| 海外仓 | 尾程订单、入库单、换标单、托盘管理、库存管理；箱号管理与产品库当前暂不进入海外仓业务正式入口；Admin 入口 `../../apps/admin-web/src/modules/overseas-warehouse/` | 原型 `../悦/货代SAAS平台后台/prototype-src/modules/03-overseas-warehouse.html`；Backend `../../baiyue-firstleg/lastleg-service/`、`../../baiyue-firstleg/warehouse-overseas-service/`，经统一 `gateway/` |
|
||||
|
||||
+36
-2
@@ -4,6 +4,20 @@
|
||||
|
||||
## 1. 目标与首版范围
|
||||
|
||||
### 2026年10月9日操作简化开发定稿与预约交接
|
||||
|
||||
本次已收到开始开发指令，采用《拼车数据入口与操作简化评估草案》第七、八节的完整范围：已有车次接货，分阶段登记、服务端缺项及角色提示、原登记连续履约、合格排车候选、共用车次准备与实收排入。保留直接外接预订来源，不新增独立待配货池、虚拟运力或跨车改配。本文记录规则，发布与实际验收继续归环境主契约。
|
||||
|
||||
文件归属：本侧维护 Admin `overseas-master-data/`、其公开出口和所需 `overseas-warehouse` 排车消费者；Backend `fleet/`、`dispatch/fleet/`、相关既有排车候选 Mapper 及 Fleet OpenAPI/测试。预约实施侧维护 `appointment-calendar/`、预约服务、预约投影及其 OpenAPI，并统一整合 `lastleg.sql`、公共导航和新增权限种子；本侧不重叠写这些共享文件。不改变已存在的财务修改。
|
||||
|
||||
预约交接的稳定身份：成交前为 `bookingNo`，成交后关联 `businessOrderNo`；安排来货后增加 `incomingNo`，实收依据为 `receiptHash + warehousePalletId + packages`；正式排车以 `dispatchNo` 及其完整来源组成核对。货物上车资格以同客户、同起运仓、同真实来货来源、完整实收托盘组成、未绑定其他车次为准。来源尚未形成合格排车或实际托盘时，预约侧只能保存筹划，不能通过本侧创建假托盘或实载。
|
||||
|
||||
现有共用 API 前缀为 `/api/platform/v1/last-leg/fleet`：`/trips` 维护真实车次；`/trips/{tripNo}/assignment` 分配资源；`/trips/{tripNo}/dispatches/bind` 关联合格排车；`/trips/{tripNo}/capacity-plan` 核对计划；`/capacity-offers` 及发布命令维护每车次唯一发布。当前 UI 以车次详情及 `CapacityOfferSettingsDialog.vue` 为入口；新增共用入口实现后通过模块 `index.ts` 导出，不允许预约侧直接引用内部组件。预约侧覆盖投影尚待交接，以正式来源查询结果为准，不在本侧新增预约状态。
|
||||
|
||||
共同样例：两柜真实货物的合格排车进入同一30托位车次，自有计划占18，确认外接登记8后同区间余4；外接实收排入后，8由预留转入真实计划，仍只计一次。来货绑定导致旧计划失效时，余位返回待核对，不能继续展示旧余4或自动恢复发布。托位、重量、体积逐段同时校验，三类阶段（预约筹划、外接保位、正式排入）不互相替代。
|
||||
|
||||
登记保存即对获准调度可见，不保位；后续必填与始终选填分区展示。`Inquiry.progress` 为只读派生的阶段、保位说明、负责角色、主要动作及缺项，不能被前端写成状态。承运资格同时检查本票资料与目的站余位，最终写命令仍锁定并复验。后续履约读取和操作以原登记身份进入，查看本人记录不授予整车其他客户或司机资料的读取权限。
|
||||
|
||||
用户场景：调度约定30托位车辆去目的仓A，自有货占18托位，将剩余12托位发布给内部销售；销售联系外部客户、登记意向，调度确认承运和占位，客户订单随后走真实到仓、装车、配送和签收。
|
||||
|
||||
本功能的“需求池”是**已发布车次的剩余运力目录**，不是客户待配货需求库。一条发布对应一个车次；销售从具体车次登记意向，不新建无车次撮合平台。
|
||||
@@ -111,11 +125,11 @@ DRAFT由本人或调度取消；池来源CONFIRMED仅在尚未登记来货时由
|
||||
|
||||
## 7. 页面、请求预算与错误处理
|
||||
|
||||
Admin「车辆管理」增加「拼车需求池」，含“可接运力”“我的意向”两个独立页签，仅加载激活页签；调度可选全部意向范围，服务端拒绝销售越权该范围。主列表一行一发布车次：操作、发布号/车次号、起运仓、目的站/路线、发车/交货截止、已关联货物计划占用、未关联外接预留、各目的地可接托位/重量/体积、接单状态和调度联系信息；多目的站在同一行分行展示，详情展开分段表。查询起运仓/目的地使用文本条件，日期和状态使用本地选项，不为筛选增加目录请求。“我的意向”跨发布状态可读历史，不依赖OPEN列表。可接运力默认使用 `scope=AVAILABLE`，在数据库分页前按 `OPEN + PLANNED + now < cutoff <= plannedDepartureAt` 筛选，管理员也遵循同一默认范围；满位或容量待核对但允许草稿登记的发布仍保留。管理员显式选择“全部发布（含历史）”时使用 `scope=ALL`，普通销售不得请求该范围。车次发布设置查找已有发布显式使用ALL，避免遗漏草稿或过期发布。详情页有登记权限时保留“登记意向”按钮，业务资格不足则置灰并展示服务端原因；无登记权限不显示按钮。
|
||||
Admin「车辆管理」的「拼车接货」包含“可拼车次”“我的登记”两个独立页签，仅加载激活页签；调度默认进入“待我处理”登记范围，销售默认进入“可拼车次”。调度可选全部登记范围，服务端拒绝销售越权该范围。主列表一行一发布车次：操作、发布号/车次号、起运仓、目的站/路线、发车/交货截止、已关联货物计划占用、未关联外接预留、各目的地可接托位/重量/体积、接单状态和调度联系信息；多目的站在同一行分行展示，详情展开分段表。查询起运仓/目的地使用文本条件，日期和状态使用本地选项，不为筛选增加目录请求。“我的登记”跨发布状态可读历史，不依赖OPEN列表。可拼车次默认使用 `scope=AVAILABLE`，在数据库分页前按 `OPEN + PLANNED + now < cutoff <= plannedDepartureAt` 筛选，管理员也遵循同一默认范围；满位或容量待核对但允许草稿登记的发布仍保留。管理员显式选择“全部发布（含历史）”时使用 `scope=ALL`，普通销售不得请求该范围。车次发布设置查找已有发布显式使用ALL，避免遗漏草稿或过期发布。详情页有登记权限时保留“登记意向”按钮，业务资格不足则置灰并展示服务端原因；无登记权限不显示按钮。
|
||||
|
||||
发布详情为独立页，首个响应带运输摘要、分段余位及获准意向首20条、total/page/size；意向翻页单独1次请求。池接口只返回专用offer/inquiry DTO，不复用含司机或客户联系信息的TripDetail/FleetCustomerOption。offer独立返回canCreateInquiry、canConfirm和blockReason，满位或待核对不错误禁用允许的草稿登记；未取得有效容量时显示“待调度核对”，已知满位才显示0。
|
||||
|
||||
操作承载矩阵：发布详情独立页；登记/编辑/查看意向为1080px居中；车次详情内“发布设置”采用居中表单；确认承运与取消采用现有确认框，明确对象和影响。当前新增操作没有外部原型，按用户授权、本文矩阵及已确认车次高密度样式实现，不能拿方便的抽屉替换。未保存提醒覆盖取消、X、Esc及路由离开；结果未知时保留原请求键和载荷。
|
||||
操作承载矩阵：发布详情独立页；登记/编辑/查看意向为1080px居中；车次详情内“发布设置”采用居中表单；确认承运复用1080px登记窗口，同窗补齐资料、核对并通过save-and-confirm一次保存确认，不追加独立确认框；取消采用现有确认框，明确对象和影响。当前新增操作没有外部原型，按用户授权、本文矩阵及已确认车次高密度样式实现，不能拿方便的抽屉替换。未保存提醒覆盖取消、X、Esc及路由离开；结果未知时保留原请求键和载荷。
|
||||
|
||||
Admin本土订单池来源行增加“承运安排”只读入口（1080px居中），原编辑深链也只能展示只读原因和安排；正常独立订单保持原操作。关联车次/来货/排车跳转逐项检查目标权限，无权限只显示业务号。Client沿原详情展示同一客户摘要，不新增公开池。两端同步散板新状态标签和筛选，不能显示裸内部状态码。
|
||||
|
||||
@@ -190,3 +204,23 @@ Admin路由：`/overseas-master-data/capacity-offers`及`/overseas-master-data/c
|
||||
| 3 | 本土订单唯一来源、实际履约、状态和费用 | 审核V2后修订V3：确认仅创建池来源商业单，散板不再建独立占位来源；新增唯一桥、来货反绑、实托/托位分离、真实状态回写、旧手工入口和来货取消防旁路、唯一运费来源及回传不反向锁车次；依据LocalLooseboardService、UsTruckOrderService、FleetIncomingAdapter、DeliveryTransfer及国内完成事件范围 |
|
||||
| 4 | Admin/Client交互、最小权限、请求预算与验收 | 审核V3后修订V4：补独立我的意向历史入口、Admin本土单只读承载、offer/inquiry/fleetArrangement专用投影、可空箱数直接消费者、两端状态标签/筛选、逐动作请求预算/分页上限、未知与满位区分、完整弹框关闭保护；按现Trips/Booking/TransportOrders及Client消费者核对 |
|
||||
| 5 | 全文一致性、接口/SQL/权限/测试/部署可执行性 | 总核对V4并冻结V5：去除“任意既有单关联”残留，明确关闭终态与显式恢复；补接口/字段/路由及数据库唯一约束、持久重放、实现归属；Admin/Client请求预算统一，测试覆盖两类商业单、权限及取消旁路；本轮只授权TEST，部署与浏览器证据不由文档通过替代 |
|
||||
|
||||
### 预约侧可直接使用的来源解析边界
|
||||
|
||||
`FleetPoolSourceResolver.resolve(List<SourceRef(customerId, bookingNo)>)` 在同一服务内批量只读，每次最多100条；返回 bookingNo、tripNo、bookingStatus、warehouseId、destinationKey/Label、incomingNo、lastlegOrderId、businessOrderNo、fulfillmentStage 和登记recordVersion。未成交也保留登记来源；没有对应别名时返回null，不能计作另一票货。不返回私人联系方式。调用侧先校验每个来源的权限；不匹配客户或不存在的来源不返回，调用侧须比较请求/返回集合并提示缺失。
|
||||
|
||||
本侧期望预约覆盖以 `customerId + bookingNo` 查询并返回同一键、覆盖状态、预约业务号/确认号列表、缺项、sourceVersion及changeReviewRequired；别名由上述解析入口提供，预约侧负责归一化及货量去重。实际生产者签名由预约侧确定后本侧接入，不使用假覆盖结果。
|
||||
|
||||
来源解析补充：`Source` 同时返回 nullable `packageCount`、`expectedPalletCount`（均为预报，不是实收）、`estimatedArrivalAt`（数据库UTC LocalDateTime，到我仓预计到仓，不是目的地预约）。货量未知保持null。
|
||||
|
||||
B接受由A在 `appointmentplanning` 公开包建立唯一预约覆盖生产者。建议Java入口 `AppointmentCoverageQuery.query(List<SourceRef>)`，SourceRef为customerId、sourceKey（BOOKING:业务号或ORDER:订单标识）、destinationKey；结果以相同键返回status、appointments（预约业务号/外部确认号/确认时间）、missingFields、sourceVersion、changeReviewRequired。必须按同客户正式别名归一化；无真实货件资料可返回待补，不可伪造已确认。B在生产者存在后消费其公开DTO/服务，不维护第二套覆盖判断；若A采用不同签名，以A公开实现和测试为准收口消费者。
|
||||
|
||||
### 共用准备和连续处理接口定稿
|
||||
|
||||
- `POST /fleet/trips/prepare`：新建（计划、车辆、司机、排车单）或加入已有车次（车次号、版本、排车单）两种输入互斥；一次事务全部完成，失败不留下半成品车次。持久幂等复用现有命令记录，重试不得重复建车。共用UI `TripPreparationDialog`参数为warehouseId、warehouseName、dispatchNos，通过模块index.ts导出，实际仓库/来源由服务端再校验。
|
||||
- `GET /fleet/trips/{tripNo}/dispatch-candidates`：本仓、未绑定、未开始执行且无其他车次外接承诺的候选，数据库分页；`TripDispatchSelector`替代手填编号。
|
||||
- `POST /capacity-offers/inquiries/{bookingNo}/save-and-confirm`：同窗核对后一次命令更新资料、创建商业关联并保位，全部回滚或全部成功，保持原MANAGE权限；不自动生成来货。
|
||||
- 原登记下`/fulfillment`按需只读本票；`/incoming`、`/receipt-confirmation`和`/arrange-dispatch`分别明确安排来货、确认实收、排入本车。池manage并不自动获得原车次booking-edit/booking-confirm/trip-edit或智能排车权限；服务端和前端同时校验对应权限。
|
||||
- 实收排入优先复用唯一的同客户同来源完整排车；没有时使用真实实收计划托盘调用原预排。多张、混入其他来源、实收不完整或被其他车次绑定时整体拒绝。不创建假库存，不自动改配，不重复扣减预留；关联后旧容量失效须核对，审核/装载/发车仍独立。
|
||||
- “待我处理”使用scope=TODO，仅调度可读；未完成候选超过100条要求按客户或登记号缩小范围，实时投影后返回准确total并分页，普通列表仍数据库分页。仓库尚未实收的记录由仓库负责，不混入调度核量待办；收货阶段以批量权威状态读取，不逐行请求详情。
|
||||
- 后续输入/返回和权限完整定义在`baiyue-firstleg/lastleg-service/src/main/resources/openapi/fleet-preparation-v1.yaml`；本次复用现有表，无新增SQL结构或权限码。
|
||||
|
||||
@@ -0,0 +1,313 @@
|
||||
# 拼车数据入口与操作简化评估草案
|
||||
|
||||
日期：2026-10-09；状态说明更新：2026-10-10。本文保留优化目标与评估依据，后续用户已授权按建议实施；已选定的开发规则以正式拼车契约为准，未选定建议不自动成为本批需求。
|
||||
|
||||
**已确认的业务起点：已有车次，销售为余位寻找客户货物。** 本批围绕“选车登记 → 调度确认 → 安排来货 → 实收后排入本车”简化，不建设独立的待配货需求池。
|
||||
|
||||
目标是让用户打开页面就能回答：**这票货保位了吗？现在轮到谁？下一步点哪里？** 同一份资料只录入一次，同一票货始终能从原登记记录跟进。
|
||||
|
||||
本草案供业务评估和交付对照，不替代[内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)。以下目标不表示均已实现；原文档整理阶段“仅修改草案、不启动开发”的限制已被后续实施授权替代。部署及验收结论以[测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)为准。
|
||||
|
||||
与预约优化并行时，本文负责拼车接货和共用车次操作简化；[美国预约管理统一总览与优化方案](美国预约管理统一总览与优化方案.md)负责在途筹划、对外预约与变化跟进。跨方案职责、交接及先后顺序统一见该文[第九节](美国预约管理统一总览与优化方案.md#九-建议实施顺序与协同分工)，本草案不再维护另一套整链排期。当前已进入实施；拼车常用路径与预约扩展分别核对，不能以预约日历全部完成代替拼车易用性验收。
|
||||
|
||||
## 评估先看这里
|
||||
|
||||
**建议把用户操作收敛成两条路径：调度准备车次并发布余位；销售选车登记客户货物，再由原记录持续跟进。** 系统负责带出资料和关联单据，人员只负责需要业务判断的确认。以下为目标方案，具体边界见后文，不代表测试或灰度环境已全部具备。
|
||||
|
||||
### 数据从哪里进来
|
||||
|
||||
| 业务起点 | 用户从哪里操作 | 系统应带入什么 | 人员仍需确认什么 |
|
||||
| --- | --- | --- | --- |
|
||||
| 已有待运货物，需要安排车辆 | 排车列表选择合格货物，点击“安排车次” | 起运仓、所选排车单、客户归属和目的地 | 使用已有车次还是新建；车辆、司机、时间及多站顺序 |
|
||||
| 已有车次，希望利用余位接货 | 车次详情点击“发布拼车余位” | 本车路线、计划发车、有效容量及已有货物占用 | 交货截止、缺失资料，以及是否正式对外接货 |
|
||||
| 销售已有客户，想搭这趟车 | 拼车接货列表直接点击“登记客户货物” | 所选车次、起运仓、路线、截止时间；单一目的地自动选中 | 客户；多目的地时选卸货站，已知货量可先填 |
|
||||
| 客户确认要送货 | 原登记记录继续处理 | 已登记的客户、货量、报价及交货资料 | 调度确认承运；明确安排来货 |
|
||||
| 客户货物已实际到仓 | 仓库按原收货流程操作，调度从原记录查看 | 真实收货结果、原车次和订单关联 | 实收差异、容量和费用；确认排入本车 |
|
||||
|
||||
**创建车次、绑定排车单，并不等于已经发布余位。** 在用户提供的车次截图中，路线仍显示“待确定卸货点1”，登记窗口也没有可选卸货站。这可以说明该操作位置缺少可选站点，但不能单凭截图判断是数据未补齐还是程序异常。目标交互应在车次准备时就列出缺项并提供“完善卸货站”，避免用户到登记窗口才遇到“无数据”。
|
||||
|
||||
### 哪些操作可以省掉
|
||||
|
||||
| 现有操作负担或需要避免的做法 | 建议处理 | 保留的业务边界 |
|
||||
| --- | --- | --- |
|
||||
| 为找入口先进入详情，再寻找登记按钮 | 在可拼车次每行直接放“登记客户货物” | 不符合登记条件时，原位置展示原因和下一步 |
|
||||
| 反复录入仓库、车次、目的地和已填货量 | 从来源带入，同一登记连续复用 | 来源变化后提示重新核对，不覆盖人工确认结果 |
|
||||
| 只有一个卸货站还要再选一次 | 自动选中并展示 | 多站时仍需用户选择 |
|
||||
| 初次接触客户就填写全部货量、价格和交货信息 | 先登记，确认承运前再补齐必要信息 | 未知数量留空；保存登记不保位 |
|
||||
| 再点一次“提交调度”才进入待办 | 建议省去；保存后调度可见，按缺项分配待办 | 页面明确告知保存后的可见范围 |
|
||||
| 确认承运后再手工创建关联本土订单 | 系统沿正式承运命令生成唯一关联 | 失败不能显示已保位，重试不能重复建单 |
|
||||
| 查找、复制、粘贴排车单号完成关联 | 使用合格候选；实收后按真实来源复用或生成并关联 | 来源冲突、部分已安排、候选不唯一时停止自动处理 |
|
||||
| 销售查看容量计算和全部专业单据 | 默认只看可接货量、当前进度、负责人和下一步 | 调度仍能查看容量依据和关联单据 |
|
||||
| 将承运、来货、排入、发车压成一次“完成” | 不建议省略这些事实节点，只简化各节点的录入 | 防止未到货就生成实收、未审核就发车 |
|
||||
|
||||
### 最少需要填写多少
|
||||
|
||||
这是建议目标，不是当前表单的实测字段数量。自动带入值也应可见，避免用户不知道系统选了什么。
|
||||
|
||||
- **首次登记：**单目的地车次，最低只选择客户；多目的地再选择卸货站。允许同时填写已知货量，不强制分两次录入。
|
||||
- **确认承运：**只补缺失的货量、价格和交货资料，已填有效内容无需重填。托位、重量、体积的容量核验不能仅用其中一项替代。
|
||||
- **安排来货：**复用已核实的预计到仓和交货说明，只补本阶段缺项。没有可靠来源的到仓时间不能自动猜测。
|
||||
- **实收后排入：**展示实收结果和差异，正常情况下不手输订单号、来货号、排车号；有异常由调度明确处理。
|
||||
|
||||
### 可行性及实施成本判断
|
||||
|
||||
| 优化类别 | 初步判断 | 需要核对的关键点 |
|
||||
| --- | --- | --- |
|
||||
| 文案、字段分组、单站自动选中、列表直接登记 | 相对容易，优先改善可发现性 | 隐藏字段不能隐藏必填缺项；不同角色可见范围正确 |
|
||||
| 数据复用、角色待办、同一记录跟进 | 可行，需要页面与服务端共同提供事实 | 谁负责、缺什么、能做什么不能仅由前端猜测 |
|
||||
| 一次完成建车关联、补齐资料并承运 | 可行，但涉及多项写入，不能只合并按钮 | 全部成功或明确续办；并发、版本和原请求重试正确 |
|
||||
| 实收后复用或生成排车并关联原车次 | 可行，业务校验较多 | 实收来源唯一、库存真实、外接预留只替换一次、审核继续有效 |
|
||||
| 自动报价、自动选多站路线、自动改车或拆分运输 | 本次不建议默认自动化 | 商业承诺、路线和货物拆分规则需单独确定 |
|
||||
|
||||
### 建议您重点评估的五个问题
|
||||
|
||||
1. **业务起点是否覆盖日常工作？** 当前以“有车找货”为主；如果大量客户先报货、暂时没有合适车次，应另评估“待配货登记”，不能让这类货物被迫绑定一趟不确定的车。
|
||||
2. **保存后直接让调度看见是否合适？** 建议省去单独提交步骤；资料不全交销售补，资料齐全才成为调度承运待办。
|
||||
3. **确认承运前的资料是否都必要？** 第四节逐项说明阶段。评估时可调整采集时点，但涉及容量、价格和真实交货的必要信息不能直接取消。
|
||||
4. **承运确认与安排来货是否保留两个动作？** 建议保留，因为“答应接货”与“确定何时到仓”可能不是同一时刻；信息齐备时可以在同一窗口连续完成。
|
||||
5. **异常流程的覆盖是否足够？** 首批先覆盖正常接货、缺资料、满位、实收差异和重试；拆运、来货后的取消与跨车改配，需要明确业务规则后再扩展。
|
||||
|
||||
建议先用第九节的新人操作任务验证常用路径，再决定是否扩展分支。不要仅按按钮减少数量评价效果，还要看用户是否知道“是否保位、轮到谁、下一步做什么”。
|
||||
|
||||
### 本批范围收口
|
||||
|
||||
先对照“选车登记 → 确认承运 → 安排来货 → 实收排入”验证少填写和连续处理。首次登记默认展开客户与卸货站；已知货量可展开填写，业务类型默认值明确可见并可在确认前调整。调度默认进入待我处理，销售默认进入可拼车次。原登记突出一个符合当前阶段和权限的主要动作，其余操作及关联单据放次要位置。
|
||||
|
||||
预约覆盖作为必要关联结果保留；统一日历、船期变化影响及其他预约来源按预约方案单独交付，不作为继续扩大本轮拼车界面的理由。本文不宣称代码、部署或1920×1080验收已完成。
|
||||
|
||||
## 一 简化方向
|
||||
|
||||
1. **一个直白入口。** 建议菜单使用“拼车接货”；销售看到“可拼车次”和“我的登记”，调度直接看到“待我处理”及发布入口。保留现有菜单位置，不额外增加并列菜单。
|
||||
2. **一票货持续跟进。** 登记后从同一记录查看资料、处理当前事项和跟踪进度；本土订单、来货、排车等放入“关联单据”。不要求销售理解单据关系，也不再重复下单。
|
||||
3. **每次只突出当前要做的事。** 页面显示当前进度、下一步负责人、具体缺项和一个主要动作；其他合法操作保留在次要位置。
|
||||
4. **资料已知就能填，未知不强填。** 区分“现在必填”“确认前待补”和“始终选填”，不把后续必填统称为选填，不用虚假默认数补齐。
|
||||
5. **简化录入和关联，保留真实作业。** 容量校验、实际收货、调度审核、拣货、实测装载、理货审核及PDA发车继续有效。
|
||||
|
||||
销售新增外部货源、等待匹配车辆的独立“先有货、后找车”登记、虚拟运力、自动撮合和实收后跨车改配不在本批。已有头程在途货的提前筹划属于预约方案，不受上述外部需求池边界排除；它仍须通过真实货源和排车资格进入共用车次能力。若以后业务改变，再单独评估，不让这些分支影响本次常用路径。
|
||||
|
||||
## 二 首页让人一眼看懂
|
||||
|
||||
### 销售看可拼车次
|
||||
|
||||
一行一趟已发布车次，操作列在左，主要按钮为“登记客户货物”。默认突出以下信息：
|
||||
|
||||
| 信息 | 展示要求 |
|
||||
| --- | --- |
|
||||
| 起运仓、目的地 | 使用业务名称；多目的地分别展示，不让销售猜哪一站能接货 |
|
||||
| 计划发车、最晚送仓 | 两个时间分别标注，不能只写含义不明的“截止”；最晚送仓对应现有交货截止，不另造一套时间 |
|
||||
| 可接货量 | 按目的地同时展示剩余托位、重量、体积，不用全车单一数字代表所有路段 |
|
||||
| 当前能做什么 | 可登记时显示登记入口；暂不能承诺但仍允许登记时，明确“可先登记，待调度核对，尚不保位” |
|
||||
|
||||
展示示例，仅说明文案，不代表真实容量：
|
||||
|
||||
> 目的仓 A：余 4 托位｜最多 2.5 吨｜18 m³；三项须同时满足。
|
||||
> 可登记客户货物，调度确认承运后保留货位。
|
||||
|
||||
未知容量显示“待调度核对”，已知满位才显示0。能否登记与能否确认承运分别由服务端判断，不能用“暂不可确认承运”代替销售的登记资格。暂停、关闭、截止等限制继续遵循正式契约。
|
||||
|
||||
销售默认列表不展开分段计划占用、外接预留和容量计算过程，这些放入调度详情。业务单号及调度公开联系信息仍可查看；不得展示司机私人信息或他人客户货物。
|
||||
|
||||
发布时调度核对交货截止，结合实际收货、理货和装载安排预留时间。当前截止默认与发车一致只是已有默认值，不代表来货可在发车时才开始收货；本批不凭空规定统一提前时长。
|
||||
|
||||
### 同一登记记录持续跟进
|
||||
|
||||
“我的登记”跨发布状态保留本人记录，车次关闭或已发车后仍能跟踪获准的历史。记录顶部突出“客户＋目的地”、车次业务号、当前阶段、是否保位及下一步负责人。
|
||||
|
||||
当前可执行的资料补充、承运确认和来货安排尽量在同一处理窗口完成；需进入仓库或排车专业页面时，直接定位对应业务，避免重新搜索和输入编号，并提供返回原记录的路径。仓库继续使用现有收货页面和PDA，不另建一套作业入口。
|
||||
|
||||
关联单据按权限提供链接，无目标权限时只显示业务号。底层仍复用同一意向、预订及正式业务关联，不新建另一张独立“拼车单”。
|
||||
|
||||
## 三 常用操作路径
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[调度发布本车余位] --> B[销售登记客户货物]
|
||||
B --> C[销售补齐待确认资料]
|
||||
C --> D[调度确认承运并保位]
|
||||
D --> E[调度明确安排来货]
|
||||
E --> F[仓库实际收货]
|
||||
F --> G[调度核对实收与费用]
|
||||
G --> H[确认排入本车]
|
||||
H --> I[审核 拣货 实测装载 理货 发车]
|
||||
```
|
||||
|
||||
资料已齐时无需再做一次补充操作。该图表示本票货的衔接，不要求整车所有货物齐备后才开始每张排车单的审核。
|
||||
|
||||
### 销售登记与补齐资料
|
||||
|
||||
销售直接从车次列表点击“登记客户货物”。先选客户；只有一个卸货站时自动选中并展示，多个站时明确选择。货量已知就填，未知允许先保存；多站不能替用户猜目的地。
|
||||
|
||||
本批建议只有“保存登记”，暂不新增“提交调度”命令。**保存后调度可见，不是仅自己可见的私人草稿；保存也不保位。** 使用现有DRAFT及资料完整性，区分以下处理提示：
|
||||
|
||||
- 资料未齐：显示“待补资料”，具体列出销售还需补充的内容。
|
||||
- 资料已齐：在调度待办中显示“待调度确认”；若容量、路线或资源存在阻断，则显示“待调度核对”及具体原因。
|
||||
- 已确认承运：才显示“已保留货位”。资料填齐不能替代承运成功。
|
||||
|
||||
资料完整性、缺项和动作资格由服务端提供或按正式合同补充，不能只靠前端判断。它们是处理提示，不新增可手改的业务状态。若以后确需销售明确提交后调度才可见，须另行定义交接命令、权限和撤回规则，不能只增加一个按钮。
|
||||
|
||||
销售负责补充客户货物预报、约定价格、交货联系人和交货资料；调度负责车辆、路线、容量及承运资格。有权限的调度可代补已核实资料，但不凭猜测代填。
|
||||
|
||||
### 调度确认承运与安排来货
|
||||
|
||||
调度从“待我处理”进入，在一个窗口核对客户、目的地、完整预报货量、约定价格与币种、交货安排及本车有效余位。已填内容直接复用；缺资料明确指向销售，缺容量或路线则由调度处理。
|
||||
|
||||
点击“确认承运”成功后，系统保留货位并生成唯一关联本土订单，提示“已保留货位，尚未安排来货”。保存资料与确认结果分别反馈，不能把保存成功当成承运成功。
|
||||
|
||||
“客户货物登记”和预约侧的“预约安排”是不同记录。确认承运只证明本车保位，不表示FBA/收货方已接受这票货；需预约的目的站应关联预约侧返回的覆盖结果，缺货件资料或需补充/改约时引导有权限人员处理。可预约阶段和核对时点在共同交接阶段确定，不能用现有登记DRAFT充当预约状态，也不能自行创建第二套收货预约。
|
||||
|
||||
确定客户来货安排后，由有权限的调度明确点击“安排来货”，沿用客户、目的地、预计到仓和交货说明，补齐本阶段必要资料。承运确认不自动生成仓库待办；“线下安排提货回仓”只是交货说明，不表示系统已生成独立提货任务。
|
||||
|
||||
### 实收后确认排入本车
|
||||
|
||||
仓库按现有流程实际收货，系统展示预报与实收差异。调度核对实际货量、占用托位及约定运费；有差异先处理，不能以预报覆盖实收。
|
||||
|
||||
核量完成后提供“确认排入本车”，整合合格排车单选择或生成及车次关联。成功提示“已排入本车”，并显示服务端返回的下一待办；通常仍需调度审核。**排入本车不等于已经装车或发车。** 后续审核、拣货、实测装载、理货和PDA发车继续按真实事实推进。
|
||||
|
||||
## 四 字段按阶段展示
|
||||
|
||||
| 阶段 | 默认展示和需要确认的内容 | 自动带入或延后 |
|
||||
| --- | --- | --- |
|
||||
| 首次登记 | 客户、目的地；已知的预报货量可直接填 | 本车仓库、路线、发车和交货截止带入；单站自动选中。单站时允许只选客户先保存 |
|
||||
| 确认承运前待补 | 箱数、托位、重量、体积、按业务类型要求的预计实托数、约定价格与币种、必要联系人和交货安排 | 已填内容复用；业务类型明确可见。收起时仍显示“确认前还差哪些项”，不得标成普通选填 |
|
||||
| 始终选填 | 货物备注及额外说明 | 收起展示，不挤占首屏；已知的后续资料仍允许提前填写 |
|
||||
| 安排来货 | 核对预计到仓、交货说明；私人地址补全必要收件资料 | 沿用客户、目的地、商业订单和车次关联，不重复建单 |
|
||||
| 核对实收 | 实收与预报差异、实际占用托位、实际约定运费及容量影响 | 箱数、实托、重量、体积来自真实收货；调度只补必要核对项 |
|
||||
| 确认排入本车 | 实际货物、目标车次及关联后的容量、审核影响 | 系统选择或生成排车并关联，无须手输编号 |
|
||||
|
||||
“确认前待补”与“始终选填”分区显示，已填字段不重复录入。必要项按业务类型及正式契约校验，例如本土卡车确认前要求正数预计实托数。
|
||||
|
||||
- 预计箱数、实际托盘数和占用托位分别表达，不能互相替代。托位可解释为“占用车上多少个标准托盘位置”。
|
||||
- 未知数量保持未知，不用0或1补齐；计费重量不能替代真实装载重量。
|
||||
- 仅从可靠来源带入默认值，允许查看来源；币种、计价方式、业务类型在确认摘要中可见。
|
||||
- 客户联系人不能取司机私人联系方式；客户候选目录也不应被假定包含联系人资料。
|
||||
- 来源变化时提示差异和影响范围；无效的路线、报价或容量须重新核对。
|
||||
|
||||
## 五 当前进度、负责人和主要动作
|
||||
|
||||
下表是目标展示示例，最终动作须同时满足实际阶段、服务端资格和当前用户权限；销售只处理本人获准记录。
|
||||
|
||||
| 当前情况 | 谁处理 | 提示示例 | 主要动作 |
|
||||
| --- | --- | --- | --- |
|
||||
| 预报或成交资料不全 | 销售 | 待你补充重量和约定运费，尚未保位 | 补充资料 |
|
||||
| 资料已齐，等待承运决定 | 调度 | 待你确认是否接货，尚未保位 | 核对并确认 |
|
||||
| 路线或容量需要复核 | 调度 | 本车货物已变化，需重新核对余位 | 核对容量或路线 |
|
||||
| 承运已确认，来货未安排 | 调度 | 已保留货位，尚未安排来货 | 安排来货 |
|
||||
| 已安排来货，货物未到仓 | 销售跟进客户；仓库等待来货 | 已安排来货，等待实际到仓 | 查看来货安排 |
|
||||
| 仓库收货进行中 | 仓库 | 仓库正在收货 | 销售、调度查看进度；仓库沿原作业继续收货 |
|
||||
| 实收与预报有差异 | 调度，必要时销售联系客户 | 实收比预报多1托，待核对容量和运费 | 核对差异 |
|
||||
| 实收已核对，满足关联资格 | 调度 | 本票已核对，可排入原车次 | 确认排入本车 |
|
||||
| 已排入本车，审核待办存在 | 对应审核人员 | 已排入本车，待调度审核或理货审核 | 打开对应审核事项 |
|
||||
| 实际已发车 | 原派送作业人员 | 已发车，按实际派送状态跟进 | 查看运输进度 |
|
||||
|
||||
同一事实对不同角色采用对应文案：销售看到“等待调度确认”，调度看到“待你确认”。无权操作时展示负责角色及进度，不以无权限按钮作为唯一下一步。
|
||||
|
||||
非本角色待办仍可跟踪，但不混入“待我处理”。暂停、截止或关闭后不能继续编辑的登记，只显示获准的查看、取消等实际可用动作，不能一直提示销售去补一个已无法保存的表单。
|
||||
|
||||
## 六 异常时也要知道怎么办
|
||||
|
||||
| 情况 | 当前处理边界 | 页面应给出的下一步 |
|
||||
| --- | --- | --- |
|
||||
| 资料不足 | 未确认、不占位 | 列出销售待补字段，回到对应输入处；容量问题单独交调度 |
|
||||
| 满位或容量待核对 | 仍可登记时允许保存，禁止越过容量门禁确认承运 | 明确“尚未保位”；已知满位等待调度决定，计划失效由调度重新核对并按资格恢复接单 |
|
||||
| 发布暂停、关闭、截止或车次事实变化 | 按服务端资格限制登记、编辑和承运；发布关闭不等于取消已确认业务 | 说明具体原因，保留已登记业务跟踪；已确认承诺由调度核查影响，不宣称自动改车或恢复接单 |
|
||||
| 已确认但尚未登记来货，需要取消 | 由调度按正式命令一体取消预订、商业关联并释放占位 | 显示取消对象和影响，确认成功后反馈；不要求分别取消多张单 |
|
||||
| 已登记来货后需要取消或跨车改配 | 登记来货后，池内取消及跨车改配按正式契约明确阻断；不得通过旧来货取消入口旁路 | 明确限制及负责调度，保留原单据和库存；仅链接实际存在且允许的作业，不展示虚假的“去改车”按钮 |
|
||||
| 部分货物未收齐 | 本批不自动把一条意向拆到多车，不将未到货算成实收 | 仓库继续收货，销售跟进缺货；若客户确认不再送齐，交调度核查现有可用处理方式，不能直接点完收货 |
|
||||
| 实收超量或价格变化 | 重新核量，检查托位、重量、体积及费用；不能自动扩大承诺 | 展示预报、实收和差异，调度核对；超出本车容量时阻断排入，明确当前不支持自动改配 |
|
||||
| 已排到其他车次、来源不一致或候选不唯一 | 不重复创建排车，不把任意已有库存接成本意向 | 显示冲突业务号及原因，交调度核查；不自动解绑或绕过改配限制 |
|
||||
| 保存部分成功、超时或他人已修改 | 保存不等于承运成功，结果未知不等于失败 | 说明已完成步骤；未知结果保留原请求续试，版本冲突保留填写内容并要求重新核对 |
|
||||
|
||||
不支持的动作要明确说明边界和负责角色，不能用笼统“查看待处理事项”掩盖没有处理能力的情况。
|
||||
|
||||
## 七 调度准备车次与发布余位
|
||||
|
||||
本批以已有车次为主，准备车次保留两种现有业务起点，不让销售参与车次资源配置。
|
||||
|
||||
本节是两份方案共用车次操作的唯一设计展开处，由拼车/车次实施职责负责。预约页带入已核对来源后，复用同一候选、资格、建车/关联和发布入口；不另建表单、容量算法或写命令。预约筹划关联、外接确认保位、实收后正式排入本车分别通过各自资格，不能因共用入口合并门槛。
|
||||
|
||||
- **已有待运货物：**在排车列表勾选合格排车单，点击“安排车次”，选择加入已有车次或新建车次。仓库、货物、目的地自动带入；车辆、司机、计划发车及预计任务结束由调度确认，多站顺序由调度确认。
|
||||
- **先有运输安排：**保留车次新建入口，再用候选列表添加本仓待运货物，替代查找和手输排车号。
|
||||
- **发布余位：**同窗展示自有货占用、有效容量和截止时间，只补缺失数据；明确“确认发布”，保留部分成功后的续办能力。
|
||||
|
||||
不同仓库、已绑定其他车次或状态不允许的排车单不能混选提交。允许跨客户共享车次，但货物归属和每单审核独立。自动补齐卸货站不等于自动优化路线。
|
||||
|
||||
无自有货、仅准备接外部货的完整发布能力仍需定向核对；不能用空货单假定已有有效的零占用计划。没有落实车辆、司机的虚拟运力不在本批。
|
||||
|
||||
## 八 实施顺序与必要边界
|
||||
|
||||
以下是拼车侧内部交付包，不是工期承诺或独立于预约方案的发布排期。第一批主要对应共同顺序的并行工作，第二批对应共用车次接入，第三批对应外接履约衔接；具体依赖以[共同工作包](美国预约管理统一总览与优化方案.md#工作包与先后依赖)为准。
|
||||
|
||||
| 顺序 | 建议交付内容 | 完成判断 |
|
||||
| --- | --- | --- |
|
||||
| 第一批：先让常用流程走得明白 | 入口文案、销售简明列表、直接登记、分阶段字段、单站自动选择、缺项及角色待办、同一记录进度、来货资料复用；把合格排车单候选选择前移，减少手输编号 | 从选车到后续履约，每阶段知道是否保位、谁处理、从哪里继续；已有排车单可选择关联。无排车单时可直达现有作业，尚不能宣称已实现一键生成并关联 |
|
||||
| 第二批：减少调度的跨页准备 | 勾选排车单安排车次、同窗补齐资料并确认承运、准备与发布的连续操作 | 新建、分配、绑定或保存部分成功时能继续，不重复建车、建单或宣称占位成功 |
|
||||
| 第三批：整合实收后排入本车 | 一次业务操作复用或生成合格排车并关联，协调库存、预留替换、容量及复审 | 正常实收排入无需手工组织中间单据；异常、超时、并发及复审均有明确结果 |
|
||||
|
||||
“确认排入本车”的已有排车复用必须同时满足：**同客户、同一真实来货来源、覆盖本次全部实收货物、未绑定其他车次，并通过现有库存及排车资格校验。** 没有合格排车时才按真实来源生成；候选不唯一或已有部分安排时先核查，不自动另建重复单。其他已有在仓货继续从正常待运货物入口处理，不导入任意独立订单或库存来拼接本意向。
|
||||
|
||||
- 客户商业订单、来货及真实尾程来源保持唯一关联；外接预留转为真实货物计划占用时只计一次，不重复占位或收费。
|
||||
- 一次用户操作涉及多个写入时，需要相应服务端编排或明确的部分成功续办机制；承运确认中的订单创建与占位必须保持正式契约的一次命令，不由前端拼接成功。
|
||||
- 资料完整性、负责人提示和候选列表若缺少服务端数据，需补相应合同；不把全部优化误判为纯前端改文案。
|
||||
- 列表不逐行请求详情，详情和候选按需读取；写命令继续复验权限、版本、来源及资格。重复点击和未知结果重试不重复创建、占位或收费。
|
||||
- 直接外接预订是否有不经销售发布的独立用途仍需核对；本批保留入口，对池来源标记“来自拼车登记”，不强行合并不同业务来源。
|
||||
|
||||
### 交给拼车与车次实施对话的任务说明
|
||||
|
||||
- **目标：**完成本文选车登记、确认保位、安排来货、实收后排入本车的连续操作，并提供预约侧可复用的车次准备、容量和发布能力。
|
||||
- **先交付：**具体文件写入清单、货源/排车资格、逐站余位与发布资格的交接示例；明确外接预留如何在实收关联后被替换，并与预约侧核对外接货进入FBA预约的阶段和来源。
|
||||
- **独占业务：**销售登记、外接预订、商业/来货关联、车次与排车关联、容量和发布。预约候选/覆盖/确认结果由预约侧提供，本侧维护消费与跳转。
|
||||
- **依赖：**读取预约侧的来源关联、时间/材料摘要、预约覆盖及变更结果；共同接口确定后可以先做不依赖对方实现的表单和流程简化。
|
||||
- **交付物：**选定正式契约改动、受影响接口/类型/权限/SQL清单、实现与定向验证结果、供预约侧接入的实际入口，以及尚未部署/人工验收的事项。公共文件按共同分工交单一写入者整合后，本侧复验其业务。
|
||||
- **完成条件：**既有货源可通过唯一车次能力组织运输；外接货从原登记跟进到实际履约，确认保位/安排来货/排入/发车含义清楚，预留替换不双扣，不重复建单或收费，来源、容量、权限和失败重试均可核对。
|
||||
|
||||
该工作包已由用户安排实施；环境操作仍按对应授权与统一执行窗口处理。
|
||||
|
||||
## 九 用新人实际操作验收
|
||||
|
||||
以下是建议验收目标，尚不是测得的效果。Admin按1920×1080、浏览器100%缩放，由人工操作并提供截图，AI核对证据；没有截图时标记“待人工截图确认”，自动检查结果单独报告。
|
||||
|
||||
找一名未参与开发的业务人员，不先讲解“意向、预订、预排、绑定”的区别，让其完成以下任务：
|
||||
|
||||
| 任务 | 应能独立完成的动作 | 应能准确说出的结果 |
|
||||
| --- | --- | --- |
|
||||
| 销售选车并登记 | 找到目的地、发车、最晚送仓及三维余位；单站自动带入，未知货量仍可保存 | 保存后尚未保位，调度可见；知道缺什么、由谁补 |
|
||||
| 调度确认接货 | 找到需要自己处理的登记，同窗核对已填资料和容量，再确认承运 | 已保位并关联本土订单；尚未安排来货时仓库没有因此收到新来货待办 |
|
||||
| 跟进实际收货 | 从原登记查看来货及收货进度，识别当前负责角色 | 知道是否需要自己操作；不把预报当实收 |
|
||||
| 实收有差异 | 看懂预报、实收和差异，找到核量及容量处理入口 | 知道超量为什么不能排入；不会误认为能自动改车或拆运 |
|
||||
| 确认排入本车 | 按当前实施批次选择已有合格排车，或使用已实现的生成并关联操作 | 已排入不等于已装车、已发车；知道下一审核或作业环节 |
|
||||
|
||||
每次操作前让试用者回答：**保位了吗？轮到谁？下一步点哪里？** 记录答错、停顿、求助、重复填写、跨页找单和复制编号的位置，再据此调整，不预先承诺节省比例或完成时间。
|
||||
|
||||
同时检查以下底线：
|
||||
|
||||
1. 主操作和下一步提示首屏可见；后续必填与选填能区分，缺项不藏在笼统的“补充资料”里。
|
||||
2. 单目的地不重复选择；多目的地不自动误选；所有数量未知与0分开，容量三项及各目的地口径正确。
|
||||
3. 已保存且有效的客户、目的地、到仓及交货信息沿链路复用；业务编号用于识别，不把内部ID显示给用户。
|
||||
4. 第一批已有排车选择无需复制编号；第三批正常实收排入无需另行查单建单。各批按实际交付范围验收，不提前声称全链已打通。
|
||||
5. 满位、暂停、过期、路线变化、实收超量、冲突和结果未知均给出具体原因及实际可用动作。
|
||||
6. 确认承运只生成一份关联商业订单；重复操作不重复创建、占位或收费；取消和改配不越过正式边界。
|
||||
7. 每单调度审核、真实收货、实测装载、整车理货审核和PDA发车门禁继续有效。
|
||||
|
||||
## 十 当前数据关系与实现依据
|
||||
|
||||
当前“拼车需求池”是已发布车次的余位目录；尚无独立待配需求池。本节用于开发定位，不要求销售学习这些对象。
|
||||
|
||||
| 当前对象 | 沿用关系 |
|
||||
| --- | --- |
|
||||
| 排车单与车次 | 多张客户排车单可关联共享车次，各客户归属及审核保留 |
|
||||
| 运力发布 | 每车次一条发布，余位依据有效计划和已确认外接占用计算 |
|
||||
| 客户意向与外接预订 | 复用同一预订，保存发布来源和销售负责人；未确认不占位 |
|
||||
| 本土订单 | 确认承运时自动生成唯一关联订单，不需独立再下单 |
|
||||
| 外接来货 | 由明确操作创建，关联真实收货来源及库存，不能以预报代替实收 |
|
||||
| 外接货排车 | 实收核量后关联原车次，由真实计划占用替代外接预留，不能重复扣减 |
|
||||
|
||||
当前已有单站匹配、容量与发布同窗、未知货量暂存和承运自动生成本土订单等能力。主要待优化的是同时展示过多字段、角色待办不清、跨页查找编号，以及实收后的连续处理；这些调整不能仅凭既有接口存在认定已完成。
|
||||
|
||||
- [内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)：当前范围、权限、容量、订单及取消规则。
|
||||
- [海外车辆模块指引](../../apps/admin-web/src/modules/overseas-master-data/AGENTS.md)：车次、预订及履约入口。
|
||||
- [拼车列表](../../apps/admin-web/src/modules/overseas-master-data/pages/CapacityOffersView.vue)：当前销售列表、字段与资格展示。
|
||||
- [车次计划表单](../../apps/admin-web/src/modules/overseas-master-data/components/TripPlanDialog.vue)：当前建车与路线输入。
|
||||
- [意向表单](../../apps/admin-web/src/modules/overseas-master-data/components/CapacityInquiryDialog.vue)：当前同时展示的字段及保存操作。
|
||||
- [外接履约窗口](../../apps/admin-web/src/modules/overseas-master-data/components/TripBookingFulfillmentDialog.vue)：当前来货、实收及手填排车号关联。
|
||||
|
||||
进入开发定稿时，将选定的交互、字段责任、资格投影及实施范围同步到唯一正式契约；本草案不作为已实现或已验收证明。
|
||||
@@ -0,0 +1,409 @@
|
||||
# 美国预约管理统一总览与优化方案
|
||||
|
||||
日期：2026-10-09
|
||||
文档性质：需求梳理与设计建议。统一展示美国段各类预约是原方案整体方向；本轮用户进一步提出开船后提前安排提柜、到仓、FBA送仓与车次余位拼车的目标。下述页面、状态、字段与实施方式供产品评审，不代表已确认全部细则、已实现或已发布。现行预约、到仓与拼车规则仍以各自维护入口为准；需要调整的合同在本文明确列为设计缺口。部署与验收状态仍以[测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)为准。
|
||||
|
||||
本文维护在途筹划、对外预约与变化跟进；[拼车数据入口与操作简化评估草案](拼车数据入口与操作简化评估草案.md)维护销售接货及共用车次操作简化。两份文档保留独立业务范围，跨方案职责与交接顺序仅在本文[第九节](#九-建议实施顺序与协同分工)维护；不另建重复总方案。用户后续已安排A/B实施，原“仅整理文档、不启动开发”的阶段限制已被该授权替代；本方案仍是目标定义，实际部署与验收只以环境主契约为准。
|
||||
|
||||
## 一 页面定位与核心结论
|
||||
|
||||
“预约管理—预约列表”应成为美国段提前筹划和预约跟进的统一入口。从真实开船及在途货物清单出发，让运营知道：哪些柜快到了、各目的仓有多少待送货、何时有望备妥、现在该联系谁、哪些已经约成、哪些车还有可发布的余位。
|
||||
|
||||
范围包括提柜、海外仓接仓、用车、FBA及其他送货等美国段事项。建议保留现有菜单名称，页面标题使用“美国预约总览”；日常工作以待办、货柜和送货批次列表为主，日历辅助查看已排日期。尚未约到时间的工作必须能被看到。
|
||||
|
||||
统一的是查看入口、关联信息和操作入口。提柜、车次、派送、收货仍由各自业务模块保存权威事实；总览读取和联查这些记录，修改时回到对应业务命令，避免运营在多个页面重复维护同一事实。
|
||||
|
||||
需要区分三种事情：
|
||||
|
||||
| 事项 | 例子 | 总览如何表达 |
|
||||
|---|---|---|
|
||||
| 对外预约 | 码头提柜时段、FBA收货时段、客户现场收货约定 | 显示预约状态、当地时间、地点、对方确认信息 |
|
||||
| 内部作业计划 | 安排车辆司机、预计装车、计划发车 | 显示执行准备和资源安排，不冒充对外预约成功 |
|
||||
| 参考节点与提醒 | 预计到港、实际到港、还柜截止 | 单独图层或待办提示，不计入预约成功数量 |
|
||||
|
||||
**“约车送FBA”通常同时涉及运输安排和FBA收货预约。** 车已安排不代表仓库已确认收货；仓库约好也不代表货齐、车到、可以发车。页面应把两者关联展示，分别保留状态。
|
||||
|
||||
### 1.1 从开船开始并行筹划
|
||||
|
||||
| 阶段 | 系统应提供的信息与建议动作 | 人工负责的决定 |
|
||||
|---|---|---|
|
||||
| 已开船、货在海上 | 读取真实柜内货物、接柜海外仓、目的FBA仓、最新ETA及来源；形成提柜联系待办和送仓货量预览 | 核对接仓地点、货量和预计时间，指定负责人 |
|
||||
| 预计到港前 | 展示目标提柜/到仓窗口，按目的仓和货物可备妥窗口汇总；准备联系资料和约车需求 | 联系拖车公司、接仓方、送货承运商；允许先记录意向和对方反馈 |
|
||||
| 对方开放预约且资料满足 | 提示可申请、缺资料、等待开放或等待对方回复；保留申请时的货物范围 | 人工提交预约，取得对方结果后登记确认时段、确认号及凭据 |
|
||||
| 货到仓前后 | 核对实际提柜、到仓、卸柜/理货与预计货量差异；把已选在途货关联到后续真实作业单据 | 确认送货批次、承运车次和时间；处理少货、换标未完或延期 |
|
||||
| 车次具备发布条件 | 带入有效的自有货计划占用和逐目的站剩余容量，链接现有拼车需求池 | 调度确认发布；销售登记意向，调度确认承运才占位 |
|
||||
|
||||
提柜沟通、收货仓排班、FBA预约准备和承运商询车可以并行。正式提柜、实收入库、拣货和发车仍按实际作业条件执行，不因提前安排而推进完成状态。
|
||||
|
||||
### 1.2 时间按用途分开，预约按对方规则办理
|
||||
|
||||
建议展示一条可追溯的时间链：**预计到港 → 预计可提柜 → 预计到海外仓 → 预计货物可备妥 → 目标送达 → 对方确认时段**。前三项也不能相互替代。
|
||||
|
||||
- ETA来自当前权威船节点，保留来源、更新时间和变更前后值。未查到ETA时进入“待补到港预报”，不直接用开船日加固定航程伪造。
|
||||
- 预计可提柜需考虑卸船、清关/放行及码头可提信息；预计到仓还涉及拖车与接仓安排；货物可备妥还涉及卸柜、理货、打托或换标。可以由运营维护预计区间和依据，不要求首版建设复杂预测引擎。
|
||||
- 目标送达需在预计备妥后留出装车、行驶和业务缓冲。先做可解释的区间预排；按港口、仓库、线路维护经验参数时，应允许人工核对，不能全美国统一写死“到港后两天送FBA”。
|
||||
- 将“希望约的时间”“已申请的时间”“对方确认的时间”分开；可以提前联系，但正式可申请时间取决于具体码头、仓库和承运商。
|
||||
- 每个预约地点按需维护预约方式、联系人、当地时区、开放条件、所需材料、改期/取消要求和规则核对日期。外部账号凭据不放在预约备注里。
|
||||
|
||||
外部规则核对（2026-10-09）：[APM Terminals洛杉矶预约说明](https://akamai.apmterminals.com/en/los-angeles/online-services/truck-appointment-system)要求进口柜卸船后才能设置提柜预约，说明“提前安排拖车”和“码头正式约号”可能发生在不同时间；不能将这一家码头的条件推广为所有港口。[Amazon美国Carrier Central手册](https://images-na.ssl-images-amazon.com/images/G/01/magicarp/common/Carrier_Central_Manual_USAmazon.pdf)区分申请日期与授予时段，要求承运商有把握按约送达，并禁止使用货件资料建立占坑或重复预约。本文据此建议先做好内部预排，再按对应机构条件确认，不预设“开船当天即可拿到所有正式预约”。
|
||||
|
||||
### 1.3 以送货批次连接货物、预约和车次
|
||||
|
||||
建议在现有业务内补齐“送货批次”的计划关系：按**实际接货海外仓 + 目的FBA仓/准确收货地址 + 可备妥时间窗口 + 运输与收货要求**组织候选，再由运营选择。它表示这批货打算一起送，不能代替客户订单、库存、车次或对方预约。优先复用现有预约、货物和排车关系承载，选货与保存安排意向一次完成，不要求运营额外手工建一张中间单；是否需要新增持久化实体在实现评审中确定。
|
||||
|
||||
- 同一柜按目的仓拆成不同候选组；不同柜可以在同一接货仓、相容时间窗口内合并。首版默认只合并同一目的站，跨站同车由调度沿既有路线能力明确安排。
|
||||
- 同时展示在途预报、已到仓未备妥、已备妥三类货量，以及已有安排与尚待安排量。箱数、预计实托、预计托位、重量、体积分别表达；未知保持未知，不以头程托数冒充海外最终托位。
|
||||
- 选货必须关联稳定来源货物明细及本次数量，并检查已有有效安排；建入库计划或收货后延续同一来源关系，不再把这批货计为新增需求。现行模型不能拆分同一明细行时，首版仍整行选择，不在页面虚构拆批能力。
|
||||
- 对FBA申请，系统准备已有货件号、目的仓、箱/托等清单；缺少该机构要求的资料时显示缺项，不能只凭“有多少托去ONT8”就标记可正式申请。
|
||||
- 内部预排允许货未到仓、司机未定、外部约号未取得；这些缺项应作为跟进事项。转成正式承诺和现场执行时，再核对对应阶段条件。
|
||||
|
||||
例如：两个在途柜分别有同一接仓点、相近备妥窗口的ONT8货物，预计占10和8托位，可人工合成一个18托位送货批次。选用实际容量为30托位的车后，还须校验重量、体积和已确认外接占位；若同一路段三维容量均允许，才可能发布12托位。一个柜延期时应明确指出受影响的这10托位、预约及车次，由调度决定等货、换货或改期，不能自动拆单或更改对方约定。数字只作业务示例，不是默认车型或固定容量。
|
||||
|
||||
## 二 当前能力与缺口
|
||||
|
||||
以下为当前源码入口盘点，属于实现结构判断，不代替环境验收。
|
||||
|
||||
| 业务 | 已有承载 | 当前信息基础 | 统一总览的缺口 |
|
||||
|---|---|---|---|
|
||||
| FBA送仓预约 | Lastleg入仓计划预约；Admin预约日历 | 预约号、目的仓、开始/结束时间、预计装车时间、状态、跨客户货物明细 | 当前总览主要覆盖这一类；排车的预约字段与预约主记录分开维护 |
|
||||
| 船舶到港 | Firstleg到港日历 | 预计/实际到港、柜号、船名航次 | 已显示，但属于参考节点，需要来源与类型标识 |
|
||||
| 码头拖车提柜 | Firstleg目的港码头拖车；海外清关提柜 | 车队、预约提柜时间、实际提柜、还空信息、允许操作 | 尚未接入预约日历；现有查询主要按柜次ID读取，不能直接当全美国按日期查询 |
|
||||
| 海外仓预计到仓 | Lastleg柜级到仓接口 | 预计到仓、PDA实际到仓、版本 | 预计到仓不等于收货仓确认的预约时段；不能直接标成“已预约” |
|
||||
| 车辆和司机安排 | Lastleg共享车次 | 计划发车、预计司机结束、车/司机、站点、审核、实际装载 | 尚未接入总览；车次是运输执行载体，不是单一收货预约 |
|
||||
| 普通送货及FBA派送 | Lastleg派送单 | 计划送达、目的仓/地址、关联排车、承运资源、签收 | 派送计划时间不能直接作为对方确认时间；需关联具体收货预约 |
|
||||
| 外接货承运预订 | 车次外接预订 | 客户、货量、既有卸货站、确认承运、来货实收 | 确认承运不等于目的地预约确认；不应重复生成一条同义送仓预约 |
|
||||
| 本土卡车、本土散板 | 海外业务订单 | 需求日期、目的地、联系信息、订单及车次关联 | 需求日期不是精确预约时段；缺少时段时应显示“待确认时间” |
|
||||
| 内部拼车需求池 | 共享车次余位发布、销售意向与外接预订 | 已有专门开发契约和实现入口 | 预约页缺少与车次发布资格、余位和销售跟进的衔接；应复用现有池，不能再建一套 |
|
||||
|
||||
当前页面主要从“已经有日期的预约”出发；用户需要从“还在海上的货及尚未约好的工作”出发。关键缺口是开船后的待办生成、按目的仓归集的在途货量、可备妥窗口、人工联系记录，以及船期变化对既有安排的影响。
|
||||
|
||||
本轮已读到的当前规则还提示两个实施边界：FBA预约以入仓计划明细为选择对象；柜级预计到仓在已有入库计划后锁定。提前规划不能靠提前伪造收货，也不能直接把持续变化的ETA写进已冻结的到仓字段。相关源码核对与建议见第八节。
|
||||
|
||||
## 三 统一展示的业务范围
|
||||
|
||||
### 核心范围
|
||||
|
||||
| 类型 | 一条记录代表什么 | 关联对象 | 创建或维护方式建议 |
|
||||
|---|---|---|---|
|
||||
| 码头提柜预约 | 某柜在某码头的一次提柜预约 | 柜次、集装箱、码头、承运车队，必要时关联运输任务 | 选择已有货柜，自动带入柜与港信息；填写时段及确认信息 |
|
||||
| 海外仓接仓预约 | 接仓方接受某柜/批来货的到仓卸货时段 | 接柜海外仓、柜次或来货单、运输安排 | 预计到仓作为参考；人工联系仓库，单独登记仓库确认的接收时段 |
|
||||
| 用车与装车安排 | 一个车次的装车/出发安排 | 车次、车/司机或外包车队、起点、站点、客户排车 | 选择或关联车次，复用资源分配、审核和容量校验 |
|
||||
| FBA收货预约 | 某FBA仓在某时段接收一批货 | 多客户入仓货物、预约主记录、承运车次/站点 | 搜索仓库，选择同仓货物，登记收货预约 |
|
||||
| 普通客户送货预约 | 某客户地址或非FBA仓的一次收货约定 | 派送单、地址、收货联系人、车次/站点 | 从派送目的地带入信息，补充收货时段与确认结果 |
|
||||
|
||||
### 同一总览应覆盖的扩展事项
|
||||
|
||||
以下应纳入分类设计；缺少正式预约模型的部分，需要补齐业务合同后接入，不能直接把现有日期换个标题就当作预约。
|
||||
|
||||
| 类型 | 建议处理 |
|
||||
|---|---|
|
||||
| 还空柜安排 | 还柜预约与还柜截止提醒分开，实际还空由原业务事实更新 |
|
||||
| 客户自提/承运商提货预约 | 按出库或派送来源建约，区分对方来我仓提货与我方送货 |
|
||||
| 仓间转运/退货提送 | 有实际运输和收货时间约定时纳入；库存移库、退货申请本身不生成运输预约 |
|
||||
| 临时其他预约 | 最后考虑受控兜底类型，至少有事项、地点、时间或待定标识、负责人；能归到正式业务类型的必须归类 |
|
||||
|
||||
“美国所有可预约数据”指系统经营范围内、业务地点属于美国的预约和计划，不是承诺接入全美国所有仓库或码头的外部预约平台。第三方代约、查号与自动确认需各自接口、账号和验收支持。
|
||||
|
||||
国内订舱拖车继续留在国内业务。美国范围应由业务地点的国家主档确定，不能把全部海外记录或所有FBA仓一律当成美国。
|
||||
|
||||
## 四 预约 货物 车次之间的关系
|
||||
|
||||
### 一次预约可以关联多个客户和入仓码
|
||||
|
||||
例如A、B、C、D、E五个客户送ONT8同一时段：建立一张收货预约，货物明细保留各客户归属，再关联承运车次。预约卡片展示“ONT8 · 09:00–11:00 · 20票 / 5客户”，不拆成五张重复预约。
|
||||
|
||||
同仓同时间并不自动等于同一预约。是否合并还应核对对方预约要求、货物资格及实际承运安排；操作员明确勾选后由服务端校验。
|
||||
|
||||
### 一辆车可以有多站 不同站分别预约
|
||||
|
||||
车次T先去ONT8，再去LAX9：用车安排只有一条；ONT8和LAX9分别保留收货预约，均关联车次T及对应站点。总览可以按车次分组展开，不能把两站合成一条没有明确地点的预约。
|
||||
|
||||
一个入仓单后续若允许拆批或多车配送，关联必须落实到本批货物/数量，防止整票重复占用。目前FBA预约按入仓明细行占用，不能未经模型调整就宣称支持同一行拆分预约。
|
||||
|
||||
### 多条业务单据不重复计算同一个预约
|
||||
|
||||
预约、排车、派送引用同一收货预约时，总览只显示一个收货预约事件；卡片内列出关联车次、排车和派送数量。用车计划作为不同类型的关联事件保留，不与收货预约混成一个状态。
|
||||
|
||||
建议明确：FBA预约号和预约状态由预约主记录维护；排车、派送展示按货物关系读取。一张排车覆盖多站、多预约时，展示预约列表或“2个预约”，不能把单个字符串覆盖成最后一次预约。
|
||||
|
||||
当前排车预约字段独立维护的问题必须在实施前收敛，否则页面会同时出现“预约成功”和“排车待预约”。此项是建议的修正方向，尚未代替现有业务合同。
|
||||
|
||||
### 车次余位与现有拼车池衔接
|
||||
|
||||
沿用[内部拼车需求池首版开发契约](内部拼车需求池首版开发契约.md)：一车次一发布，外接货统一在我仓上车；询价不占位，调度确认承运才占位。预约页只增加发布资格摘要及进入原发布操作的入口，销售继续在原需求池工作。
|
||||
|
||||
**建议允许提前做用车需求和送货批次，但保持正式余位发布条件。** 尚无车辆/司机、真实起运仓/卸货站或有效容量计划时，显示“预排中，暂不可发布”及具体缺项。承运商仅口头表示“预计有车”不能当作可发布运力；如以后要销售尚未落实车辆的远期运力，应另行评审，而不是本轮放松现有门禁。
|
||||
|
||||
车次准备、容量核对、发布窗口及部分成功续办统一由[拼车优化草案第七、八节](拼车数据入口与操作简化评估草案.md#七-调度准备车次与发布余位)细化；预约页读取车次服务返回的逐目的站余位、资格与缺项，不实现第二套计算或发布表单。船期/货物变化由预约侧提供影响依据，车次侧重新核对运输承诺；不自动扩大余位或静默取消已确认外接订单。实际规则继续以拼车正式契约为准。
|
||||
|
||||
拼车新增货物后，预约侧按稳定来源核对目的仓、货件材料及预约覆盖，车次侧展示同一结果并引导处理。确认承运保位不能推定收货方已经接受新增货物；需要补充货件或改约时交预约负责人，不自动再建一张同义预约。两类货源的可预约阶段与检查时点须在第九节的首次交接中明确。
|
||||
|
||||
## 五 页面和交互优化
|
||||
|
||||
### 总览布局
|
||||
|
||||
建议在同一菜单内使用三个工作视图，避免把所有业务字段塞进一个通用大表：
|
||||
|
||||
| 工作视图 | 一行/事件的组织单位 | 首屏信息与主要动作 |
|
||||
|---|---|---|
|
||||
| 提柜与到仓 | 一个来源货柜 | 操作、柜次/柜号、港口→接仓点、ETA及更新标识、目标提柜/到仓窗口、拖车联系/码头约号结果、当前缺项、负责人/下次跟进；进入原货柜业务维护 |
|
||||
| 送仓与排车 | 尚未安排的同仓同窗口候选组，或已建立的送货批次；二者明确标识 | 操作、起运仓→目的仓、预计备妥窗口、货量/可用状态、收货预约、承运安排、余位发布资格、负责人；选货保存安排、登记预约结果，带入共用车次入口，不另建建车/发布表单 |
|
||||
| 预约日历 | 去重后的预约事件；内部作业及预报可选显示 | 按日/周查看对方确认时段及待确认安排，可切换列表；按类型、地点或车次查看，不用一条综合状态覆盖所有事项 |
|
||||
|
||||
日常进入列表工作视图，顶部用紧凑待办计数定位“待联系、等对方回复、已约未配车、船期变更待处理”，点击后作用于对应视图。每条待办展示负责人、下一步和下次跟进日期；同一柜或批次的多个问题合并提示，展开后逐项处理，避免提醒数量淹没实际货量。
|
||||
|
||||
“送仓与排车”增加目的仓货量汇总，默认按实际起运仓及未来可备妥窗口查询，可按需要切换7/14/30天。每个目的仓分别展示在途、在仓未备妥、已备妥货量及待安排量；未确定备妥日期的货物单列“日期待定”。已安排货物不再次进入未安排候选，跨窗口统计不能重复累计同一批货。
|
||||
|
||||
顶部保留日期、类型、地点/仓库、状态和关键词搜索。日期条件需注明当前筛选的是“预计到港”“预计备妥”还是“预约时段”；不能切换视图后无提示地把同一个日期变成另一种含义。关键词支持预约号、柜号、入仓码、车次号及客户业务名称；车牌、司机、负责人等放入更多筛选。
|
||||
|
||||
前两个视图使用工作列表；第三个统一承载月/周/日历及对应时间安排列表，不为每个工作视图再建一套日历。月视图负责概览，周/日视图负责排班，列表负责搜索、批量核对和导出。统一日历与其列表切换时保留筛选；跨业务视图保留通用条件并清楚显示各自日期口径。操作列按Admin规范放在第一列；大量货物明细只在展开或详情按需读取。
|
||||
|
||||
日历每格最多显示3条，标明剩余数，悬停显示总数。右侧当天安排按时间排序，未定时事项进入“待安排”区域，不伪造09:00或00:00占位。
|
||||
|
||||
到港、预计到仓、还柜提醒通过独立开关显示；预约数量只统计真实预约。历史已取消事项可以筛选查看，保留原取消信息。
|
||||
|
||||
以上为信息结构建议，尚不是已冻结视觉原型。实施时逐操作核对现有新增、详情、编辑的承载方式；未定义操作形成评审矩阵，人工按1920×1080、100%缩放确认，不以本方案代替视觉验收。
|
||||
|
||||
### 卡片内容
|
||||
|
||||
首屏只展示类型、地点、时段与时区、预约状态、运输安排摘要、货物统计和需要处理的问题。联系人、附件、操作历史、客户与货物明细按需展开。
|
||||
|
||||
入仓码独占一行区域，默认3条并显示总数，展开后独立滚动；大量货物使用可搜索、可分页的关联明细，不能一次拼接数百个编号到卡片中。备注缺失不占一整格；长备注默认摘要。
|
||||
|
||||
卡片提供“查看来源单据”“查看关联车次”等操作。编辑、改期、取消是否可用由来源业务权限和当前状态决定，不因用户能看总览就允许修改所有类型。
|
||||
|
||||
### 新增流程
|
||||
|
||||
1. 优先从货柜或目的仓货量发起，自动带入业务对象与货物；通用“新增”入口再选择提柜、接仓、FBA或普通送货等类型。
|
||||
2. 先保存“预约安排”：目标日期/窗口、负责人与下一步；允许对方约号、车辆和司机暂缺。原有待办应直接补充，不另建一份重复事项。这与拼车侧的“客户货物登记”分别命名、分别维护，不能共用一个含义不明的“意向状态”。
|
||||
3. 人工通过电话、邮件或外部预约平台沟通，记录联系对象、方式、结果及下次跟进；系统可整理/导出既有货柜与货件资料，不能把资料导出当作已发送或已申请。
|
||||
4. 申请后登记申请时间及反馈；对方确认后再记录确认时段、外部号或适用的确认凭据。回到关联批次核对承运和货物是否就绪。
|
||||
|
||||
新增入口可以预先带入当前选中的日期，但时间应由用户确认；地点改变后重新核对时区、可选货物及资源，清空不再匹配的选择。继续保留并发版本校验和稳定幂等，避免重复点击创建重复预约。
|
||||
|
||||
## 六 减少填写项的具体规则
|
||||
|
||||
| 信息 | 建议 | 约束 |
|
||||
|---|---|---|
|
||||
| 仓库/码头 | 主档搜索选择，显示编码与名称；码头可由货柜带入 | 不接受自由文本冒充已存在地点；地点未维护时给出维护入口 |
|
||||
| 客户/入仓码/柜号 | 选业务对象或货物后带入 | 不能让运营在预约表单再手填一遍；保留真实归属 |
|
||||
| 箱数/托数 | 从所选货物汇总，计划值和实收值分别标识 | 不允许为了少填而拿预计值冒充实际值 |
|
||||
| 车辆/司机/电话 | 关联车次后读取，外包运输复用承运车队信息 | 不在FBA预约中重复编辑司机档案；允许预约先于派车 |
|
||||
| 预约日期与时段 | 核心操作信息；支持“时间待确认” | 待定事项不计入已确认时间表，确认预约时按类型校验 |
|
||||
| 预约结束时间 | 选填；对方给出时间窗时填写 | 不自动假定两小时，不用司机任务结束时间替代 |
|
||||
| 预计装车时间 | 移到车次/装车安排；在预约详情作为关联信息查看 | 当前FBA接口与表结构要求非空，实施要同步调整，不能仅隐藏字段或伪造默认值 |
|
||||
| 预约状态 | 根据确认操作更新，普通新建可默认待确认 | 保存表单不等于对方确认；执行完成以来源事实为准 |
|
||||
| 预约编号 | 区分系统业务号与外部确认号 | 建议系统生成内部业务号，外部号在取得时补录；现有appointmentNo语义与唯一约束需先明确，不能把随机号当码头/FBA确认号 |
|
||||
| 联系人/地址 | 从目的地或来源单据读取，缺失时按类型补充 | 美国客户地址不强制伪装成FBA仓；变更需要留痕 |
|
||||
| 负责人/联系记录/下次跟进 | 默认带入当前操作者，可按权限分派；一次联系只补结果和下一步 | 拖车承诺、码头确认、收货仓确认分别记录对应公司，不能用一个“对方已确认”混用 |
|
||||
| 货物预报与预约材料 | 从柜内货物、来源订单及后续入仓计划读取已有内容，只补实际缺项 | 内部入仓码不能代替对方要求的FBA货件号、BOL或其他预约资料 |
|
||||
| 备注/附件 | 默认收起，异常、改期等动作按需要求原因或凭据 | 不删除业务真正需要的例外说明；文件仍遵守原权限 |
|
||||
| 运费/成本/账单 | 留在报价、运输和财务流程，可关联查看 | 不放进通用预约新增表单要求运营重复填写 |
|
||||
|
||||
目标是“系统已有的不用再填，只填本次预约新增的信息”，而非简单删除所有字段。
|
||||
|
||||
## 七 时间 状态与提醒
|
||||
|
||||
### 美国当地时间
|
||||
|
||||
预约录入和确认以业务地点时区为准，使用主档中的IANA时区，界面显示时区标签。存储和聚合需要同时保留可比较的时间点及业务地点时区；仅有无时区日期字符串时，必须先确认来源时区，不能按操作者电脑时间自行解释。
|
||||
|
||||
单地点视图默认当地时间。跨时区总览明确展示所选总览时区，卡片同时保留地点当地时间；日历分组和查询范围使用同一明确时区，避免日期错一天。夏令时切换时重复或不存在的当地时刻要明确校验，不静默偏移。
|
||||
|
||||
仅有日期的本土运输需求显示“当日待定时段”；没有日期的事项显示在待安排列表，不凭空推算。预计、已约、实际时间分别保存和展示。
|
||||
|
||||
### 状态分开表达
|
||||
|
||||
建议预约确认状态归纳为待安排、已申请待回复、已确认、已取消、未约成；“待联系、未开放、缺资料”作为待办原因，不增加大量互斥状态。作业执行显示未执行、进行中、已完成及异常提示；货物准备与承运安排各自显示摘要。各来源已有状态需建立显式映射，不直接替换所有服务的状态机。拖车公司承诺可提、码头给出约号、接仓方接受到仓时间属于不同确认对象，不能互相代替。
|
||||
|
||||
改期是一项有前后时间和原因的操作，不应覆盖掉原确认历史；已发车或执行中的改期要检查影响的收货站、司机任务及派送计划。取消预约不能自动取消车次或回滚已发生的库存。
|
||||
|
||||
异常优先展示：缺时间/地点、预约未确认、已约未安排承运、货物未就绪、资源冲突、已过约定时间未完成。冲突有完整资源与时段依据时才判断；缺少行程耗时不能断言车辆一定赶不到。
|
||||
|
||||
还柜截止必须使用现有业务服务返回的规则结果。当前内部72小时预警口径不能等同所有船公司、码头的免箱期或费用规则，也不能拿预计还柜时间当实际还柜。
|
||||
|
||||
### 船期与货量变化后的处理闭环
|
||||
|
||||
上游变化后更新有来源依据的最新预测，重新比较下游安排，形成“变化原因 → 受影响对象 → 建议动作 → 负责人 → 处理结果”。建议至少覆盖：
|
||||
|
||||
| 变化 | 需要提示的影响 | 人工处理 |
|
||||
|---|---|---|
|
||||
| ETA或预计可提柜推迟 | 提柜意向、接仓窗口、受影响货物的预计备妥窗口 | 再联系车队/仓库；尚未形成正式约号时调整意向 |
|
||||
| 预计备妥晚于计划装车或目标送达 | 具体送货批次、收货预约、车次及关联外接承诺 | 判断等货、取消本批或按合法命令调整货物/申请改期；正式约定保留至取得新结果 |
|
||||
| 实收箱托/重量体积与预报不同 | 车次容量、剩余可接量和需要更新的预约资料 | 调度重核容量及对方资料；已确认外接货不能被静默挤出 |
|
||||
| 对方改期、拒约或取消 | 关联装车/车辆安排及货物等待情况 | 指定下一次联系、补资料或另申请；保留原结果和原因 |
|
||||
| 船期来源过期或关键资料缺失 | 当前计划判断依据不足 | 标为待核实，负责人补充；不能继续显示无条件“可送达” |
|
||||
|
||||
首版提醒先做有明确依据的日期先后、资料缺项、超时未回复与来源变更。缺少可靠装卸/行车耗时，只能提示“需要核对”，不能自动判定违约。若变化可能影响运输承诺且暂无完整重算依据，先要求调度复核再确认新的外接承运；不改写已确认订单或凭空计算新余位。
|
||||
|
||||
跟进事项以同一来源与事项保持稳定身份，更新后保留处理历史，不在每次船期刷新时新增重复待办。待办完成要对应实际反馈或已处理的安排，不能仅因运营打开过详情就消失。首版岗位建议：提柜负责人跟进车队/码头，仓库负责人核对接仓和备妥，送仓调度跟进FBA/收货方及车次，销售在原拼车池跟进外接意向；具体人员由组织分工确定。
|
||||
|
||||
## 八 数据与接口实现建议
|
||||
|
||||
### 提前筹划必须补齐的当前接口边界
|
||||
|
||||
以下为2026-10-09只读源码核对，不代表已部署验证：
|
||||
|
||||
| 当前事实 | 对本目标的影响 | 建议调整 |
|
||||
|---|---|---|
|
||||
| `InboundFbaAppointmentQueryMapper`从入仓计划及其明细查候选，预约创建未要求入库完成 | 已有计划的海上货可以提前约；尚无计划的在途订单不在该入口 | 在既有Lastleg业务内提供在途货量及预约准备关系，直接引用真实来源明细；后续关联计划行，不为凑候选而伪造收货或重复建货源 |
|
||||
| `BatchFbaAppointmentRequest`要求预约号、预约时间及预计装车时间；关联仅接收完整`lineIds` | 刚开始联系时无法真实填写；不支持同一明细自由拆量 | 支持先保存筹划信息，再补确认结果；首版按完整来源明细组织，拆批数量分配另行定义后才开放 |
|
||||
| `LastlegOrderService`在同柜任意入库计划生成后禁止修改柜级预计到仓 | 提前建计划后无法持续修订该字段，不能仅靠预约页面解决 | 先区分来源最新预测与入库计划确认时的时间快照；明确各自来源和显示，预测变化走影响提示。若要修订已确认计划日期，需同步修改当前到仓合同和实际消费者，不能直接移除锁定校验 |
|
||||
| `FleetTripExecutionService`从已关联客户排车读取计划货源，要求货物、托盘、车辆与目的地；`FleetCapacityOfferService`发布还校验司机及有效容量计划 | 已支持拣货前核对容量，但不能直接把海上FBA汇总当成可售余位 | 复用现有排车/车次关联；先验证计划货源可在哪个阶段合法形成这些事实，补齐在途批次到现有货源的关联闭环；尚未具备事实时仅预排，不许前端凭空发布 |
|
||||
|
||||
“开船后提前筹划”与“开船后立即发布远期可成交余位”是不同交付要求。前者是本轮明确目标；后者只有满足现有资源、容量及履约条件的车次才能开放。若业务要求更早发布，必须在本方案中明确新的可承诺条件，再调整拼车主契约。
|
||||
|
||||
### 聚合读取 原业务写入
|
||||
|
||||
总览提供按日期范围、类型、地点和权限过滤的聚合读取能力。Firstleg负责码头提柜/还空及船节点，Lastleg负责FBA、车次、派送和仓库收货相关业务，Warehouse提供地点主档。服务端通过明确接口聚合，不跨服务Schema查询。
|
||||
|
||||
先接已有事实，不为每种来源复制一套预约数据。不具备预约状态或确认时段的业务，补充自己的模型后再作为正式预约接入；仍可先以“待安排计划”展示。
|
||||
|
||||
建议统一返回：稳定事件标识、来源类型和业务号、预约类型、地点与时区、时间含义/开始/结束、确认状态、执行状态、货物统计、关联单据摘要、可执行动作、版本及来源更新时间。内部ID用于关联但不作为用户可见业务编号。
|
||||
|
||||
事件按来源及业务阶段建立稳定去重键，不能按客户复制，也不能用会随改期改变的日期作为唯一标识。改期更新同一业务事件，保留历史；跨日时段按与查询区间相交纳入，不能只查开始日期。
|
||||
|
||||
在途预报、已建计划和实收入库应按稳定货源关联去重。建议新增的筹划信息仅保存负责人、目标窗口、联系记录、批次关联等现有业务没有的事实，归Lastleg相关业务承载，不建设独立预约微服务或通用工作流引擎。提柜/船节点继续由Firstleg提供；筹划查询不跨服务Schema取数，不把来源快照复制成第二套可编辑货物清单。
|
||||
|
||||
### 性能与错误处理
|
||||
|
||||
按时间范围批量查询并分页读取当天明细，禁止先加载所有业务单据再在浏览器过滤，也禁止日历每个卡片再请求一次详情。现有FBA和到港接口可复用；提柜现有按柜次ID接口需要新增按范围的读取合同，不能假设它已支持。
|
||||
|
||||
某一来源失败时，明确显示该分类暂不可用及重试，不把整个页面清成“当天无预约”。所有分类的总数必须说明是否完整，避免部分结果冒充全部。筛选和切换日期时丢弃迟到响应。
|
||||
|
||||
### 权限与审计
|
||||
|
||||
统一入口按平台员工权限过滤各来源，后端同时执行数据范围和动作权限校验。仅有总览权限不自动取得提柜、排车或取消权限。聚合失败、无权查看和确实无数据应区分处理。
|
||||
|
||||
跨客户预约只在平台完整展示；客户仍只能看到自己的货物和获准公开的信息。改期、取消、关联/解除记录操作人、时间、原因和原新值。发送车队邮件属于显式业务操作，不因新增日历卡片自动发送。
|
||||
|
||||
## 九 建议实施顺序与协同分工
|
||||
|
||||
### 两份文档 两个实施职责
|
||||
|
||||
建议由用户安排两个实施对话：A负责预约并协调本次集成，B负责拼车接货及共用车次能力；可以复用已有对应对话，不额外创建第三个协调对话。A/B仅为待分派的职责代号，不是已登记或已创建的任务；本次文档整理对话不承担A或B开发职责。本文维护跨方案分工，拼车草案只链接本节并保留自己的操作细节。正式规则仍回到各自当前契约，评审稿不能代替开发定稿。
|
||||
|
||||
| 工作范围 | 唯一实现职责 | 另一侧如何使用 |
|
||||
|---|---|---|
|
||||
| 在途货量、ETA/备妥窗口、提柜与接仓联系、预约安排 | A | B读取获准的货物/时间摘要，不另建预测与联系记录 |
|
||||
| FBA/收货预约、货物关联、确认/改期、预约覆盖结果、日历 | A | B展示同一预约结果，缺项进入预约操作；不独立维护预约状态 |
|
||||
| 车次创建、车辆司机、路线、排车关联及正式排入本车 | B | A带入真实来源，使用同一候选、资格与业务命令；不另建运输单或排车命令 |
|
||||
| 计划容量、占位、余位、发布与恢复资格 | B | A只展示摘要和进入共用操作的入口，不在浏览器重算 |
|
||||
| 销售登记、确认承运、安排来货、实收后连续处理 | B | A按稳定来源联查货物及预约，不复制拼车登记或商业订单 |
|
||||
| 船期/货量变化影响 | A识别时间及预约影响；B维护车次容量/发布资格 | 各自维护自己的事实，通过明确关联衔接，不互相覆盖状态 |
|
||||
| 本次共用文件集成与整链核对 | A协调单一写入者，保留既有项目文件归属 | B提交精确改动并对其业务复验；不因此将B的业务责任移交A |
|
||||
|
||||
实施前按目标文件列出写入范围，不能只写“前端归A、后端归B”。A通常涉及`appointment-calendar`、预约服务及所需船节点/提柜读取，B通常涉及`overseas-master-data`、Fleet及排车关联；同在Lastleg不等于可同时修改同一服务文件。排车中的预约展示/关联由A定义预约事实，B修改其负责的排车消费者。
|
||||
|
||||
实际重叠的`lastleg.sql`、导航、根路由、权限种子、公共导出/类型、OpenAPI和相邻合同测试须逐文件指定唯一写入者；已有项目负责人持有的文件沿用其归属。B负责的公共变更由B提供精确变更清单或补丁，单一写入者在当前工作区串行整合，B复验业务行为。普通工作仍在当前工作区、当前分支，不复制项目或创建worktree。
|
||||
|
||||
#### 已选定的预约与拼车交接文件
|
||||
|
||||
实施交接的来源、权限与跟进规则维护在[业务主入口的预约跟进合同](README.md#在途货源与拼车外接货的预约跟进合同)，HTTP定义维护在预约筹划OpenAPI；本表只明确文件写入归属。
|
||||
|
||||
| 文件或精确目录 | 写入方 | 边界 |
|
||||
|---|---|---|
|
||||
| Admin `src/modules/appointment-calendar/` | A | 在途列表、来源深链、跟进、覆盖展示及预约日历 |
|
||||
| Lastleg `appointmentplanning/`及同包测试、`openapi/appointment-planning-v1.yaml` | A | `AppointmentExternalSourceGateway`由A定义；`AppointmentCoverageService.query`提供共同只读结果 |
|
||||
| Lastleg `fleet/business/FleetPoolSourceResolver.java`、`FleetAppointmentSourceAdapter.java` | B | B适配原登记真实来源到A的端口，A不直接依赖Fleet实现 |
|
||||
| Admin `overseas-master-data/`、Lastleg `fleet/`与排车消费者 | B | B消费覆盖投影，提供共享车次候选、安排和容量；不复制预约写命令 |
|
||||
| Admin `core/navigation/adminNavigation.ts`及对应测试、`overseas-master-data/routes.ts`菜单标题 | A串行整合 | 此次仅“拼车接货”标题调整由A写入；B保留其页面及路由功能改动 |
|
||||
| `lastleg-service/src/main/resources/db/lastleg.sql`、`deploy/sql/海外区域统一增量-MySQL8.sql` | 按新增表块串行 | A仅写`ll_appointment_followup`块；B维护Fleet块，其他业务负责人持有的块保持原归属 |
|
||||
| `iam/src/main/resources/db/lastleg-permissions.sql`、`deploy/sql/头程数据库统一增量-MySQL8.sql` | A整合预约权限行 | A维护`platform:appointment:followup`及平台管理员授权，保留其他任务的种子变化 |
|
||||
|
||||
深链为`/appointment-calendar?sourceKey=BOOKING:<登记号>&customerId=<客户ID>&destinationKey=FBA:<仓码>`，各参数须编码。它进入核实后的来源跟进与覆盖展示，不等价于外部预约确认。B的原登记入口必须满足读取权限，写入另受跟进权限约束。共用Lastleg编译目录串行使用，不能两侧同时运行Maven并将编译产物竞争误判为源码故障。
|
||||
|
||||
### 开工前先确定六项交接
|
||||
|
||||
1. **货物来源与数量：**已有头程在途货、拼车外接货分别如何关联来源明细、来货、入仓计划和实收；避免入库前后重复计货，首版不默认拆分同一明细。
|
||||
2. **时间与状态：**预测、计划快照、对方确认时间分别归谁；预约安排、拼车登记、确认保位、实收后排入各自允许什么操作，不互相推进状态。
|
||||
3. **预约资格与覆盖：**两类货源分别在哪个阶段可以准备/正式申请FBA预约，需要哪些资料；新增拼车货如何进入候选、核对原预约货件及检查时点。预约服务给出结果，车次侧消费，不在最终联调才补来源支持。
|
||||
4. **车次接入：**A传真实来源及计划关系，B返回可用候选/阻断原因、关联车次和版本；无正式排车资格时只保留筹划，不生成假托盘或实际装载。
|
||||
5. **余位与变更：**B提供各目的站可接量、发布资格、缺项和版本；A传递预测/货物变化依据，双方明确哪些变化触发人工复核，不自动重约或替换已确认承诺。
|
||||
6. **权限、失败与重试：**查看和写入分开，变更使用版本与幂等；明确部分保存成功、结果未知和重试行为，同一次动作不生成重复业务。
|
||||
|
||||
以“两柜已有货合送同FBA，再接一票外部货”为共同样例，给出上述输入/返回示例、来源关联、可用动作及失败情形。选定规则在实现前同步到对应唯一正式契约与接口定义；本节只规定交接项，不提前宣称新接口或状态已经存在。
|
||||
|
||||
### 工作包与先后依赖
|
||||
|
||||
| 顺序 | A：预约与集成 | B：拼车与共用车次 | 进入下一步的条件 |
|
||||
|---|---|---|---|
|
||||
| 0 先确定共同边界 | 明确在途及外接货预约来源、预测/确认时间和关联结果 | 明确三类占用阶段、车次资格、容量和发布结果 | 六项交接有样例；正式契约、具体文件归属和受影响检查已明确 |
|
||||
| 1 两侧独立工作并行 | 在途货量、提柜/接仓列表、负责人、联系记录、无约号的预约安排 | 销售简明列表、分阶段字段、单站带入、同一登记记录、角色待办和已有排车候选 | 各自定向验证通过；不编造约号、数量或资源；独立改动不等待对方全部完成 |
|
||||
| 2 共用能力只做一次 | 实现对外预约/改期及货物关联，按已确定接口接入车次和资格展示 | 完成共用安排车次、排车关联、容量核对与连续发布，提供实际消费者可用的接口和操作入口 | A/B复用同一车次能力；源码、类型、OpenAPI、权限及必要SQL一起收敛，不能靠临时兼容接口拼接 |
|
||||
| 3 接通变化与外接履约 | 完成统一日历、船期影响、外接货预约覆盖和待补/改约提示 | 完成安排来货、实收核量、排入原车次及预留替换；消费预约结果 | 从原登记可跟踪整链；延期可定位影响；不重复占位、建单或收费 |
|
||||
| 4 统一验收本轮闭环 | A组织整链核对和问题归属，各侧修复自己负责的部分 | B复验共享车次及外接履约，保留原审核/拣货/发车门禁 | 必要自动检查完成；真实环境和人工截图按授权执行，代码、部署与验收分别报告 |
|
||||
|
||||
第1—3步共同交付首个完整闭环，不以一个更大的日历或仅改表单文案替代。B的内部操作细节及局部分批见拼车草案第八节，不另排一条互相冲突的整链发布顺序。可以按可独立验证的工作包推进；本表不是工期、上线或环境写入授权。
|
||||
|
||||
共同回归至少覆盖：已有货在途预约；合格车次发布后接外部货并补齐预约覆盖；外接实收后预留替换只算一次；一个柜延期时关联预约/车次/已接货均可追踪；三维容量不足、重复提交、版本冲突与权限拒绝。自提、还空、转运/退货提送的扩展仍保留总体范围，排在主链后，不占用第一轮共同接口建设。
|
||||
|
||||
### 交给预约实施对话的任务说明
|
||||
|
||||
- **目标：**完成从已有在途货开始的提柜/接仓跟进、按目的仓筹划、对外预约、日历及船期变化影响，并接入拼车侧提供的共用车次能力。
|
||||
- **先交付：**具体文件写入清单，已有头程货和拼车外接货的稳定关联、可预约阶段、时间语义、预约覆盖与失败情形；与B共同确定六项交接，不等到最后才处理外接货来源。
|
||||
- **独占业务：**在途/备妥预测展示、人工联系、预约安排与确认/改期、预约货物关联和覆盖结果。车次创建、排车命令、容量及发布由B提供，本侧只接入。
|
||||
- **依赖：**B提供真实货源进入车次的资格、车次/排车关联、各目的站余位、发布资格和对应操作入口；本侧不得为提前完成页面而自建同义接口或虚假资源。
|
||||
- **交付物：**选定正式契约改动、受影响接口/类型/权限/SQL清单、实现与定向验证结果、公共文件串行集成记录和整链核对结果；部署与人工验收分别列出，不由源码测试推定完成。
|
||||
- **完成条件：**货在海上且未建入库计划时可真实筹划，未取得约号仍能跟进；两类货源的预约覆盖可追踪，预测变化能定位下游影响，预约和车次结果一致，未重复占货、建车或发布。
|
||||
|
||||
拼车实施职责的交接说明见[拼车草案第八节](拼车数据入口与操作简化评估草案.md#交给拼车与车次实施对话的任务说明)。上述工作包供用户分派给其他对话；本轮只交付文档，不创建对话、发送开发任务或修改业务代码。
|
||||
|
||||
## 十 验收场景
|
||||
|
||||
1. 同一美国日期包含提柜、用车、FBA和客户送货，列表/日历均可找到且类型明确；国内拖车不混入。
|
||||
2. 五客户二十票同仓同批预约只计一张，客户统计正确，入仓码默认三条；每个客户只读到自己的货物。
|
||||
3. 一车两站两个收货预约，在车次视图可以关联查看；车次计划不会被重复算成两个用车安排。
|
||||
4. 预约成功后，排车和派送显示同一来源事实；多预约排车不会丢掉其中一站，不能再出现无依据的独立“待预约”。
|
||||
5. 选仓自动加载货物；换仓清空旧选择；不可预约货物有原因；仓库接口失败不允许自由输入假仓库绕过。
|
||||
6. 新建待确认事项无需编造外部确认号、装车时间、司机或费用；转为已确认时按业务类型核验必要资料。
|
||||
7. 提柜时间、预计到仓、实际到仓互不覆盖；实际作业只由原业务事实推进。
|
||||
8. 改期更新原记录而不新增重复事件；取消保留历史；已执行业务不被日历操作回滚。
|
||||
9. 跨时区、跨日、只有日期、无时间及夏令时边界正确显示；地点时区缺失明确待补。
|
||||
10. 日格三条预览、大量当天安排和大量关联货物保持有限高度，展开可用键盘操作；关键业务号可查看完整内容。
|
||||
11. 来源接口部分失败、无权限、版本冲突和重复提交均有明确行为，统计不把缺失来源当零。
|
||||
12. 车次调度/理货、PDA拣货发车、库存和客户费用隔离继续有效，预约页面不能跳过这些门禁。
|
||||
13. 柜已开船但尚未生成入库计划时，真实货物出现在在途货量及预约准备中；无需假约号、假实收或假司机即可分派跟进。
|
||||
14. 同起运仓、同FBA、相容备妥窗口的两柜货可人工组织批次；起运仓不同、日期不相容或已占用的货不得被无提示合入。同一来源建计划/入库后不重复累计。
|
||||
15. 码头尚未开放正式申请时，保留拖车沟通与待开放事项；车队答应不自动标记码头已确认，接仓方和FBA确认也不互相替代。
|
||||
16. ETA延后时展示旧/新预测及来源，准确指出受影响批次与预约；已确认外部时间和已冻结计划不被覆盖，待办有负责人及处理结果。
|
||||
17. 海上预排货量不能直接发布可成交余位；达到现有车次、资源、有效计划容量条件后复用原发布。托位有余但重量/体积不足时，不发布虚假可接量。
|
||||
18. 在同一路段30托位车辆、自有18、有效外接预留8的示例中，剩余为4；外接货转为已关联货物后不再额外扣8。计划失效则显示待核对，不继续承诺旧余位。
|
||||
19. 联系资料可由已有货物生成；缺少FBA所需资料显示缺项。记录、导出资料、申请和取得确认是不同动作，不能相互推定完成。
|
||||
|
||||
## 十一 评审需要确定的事项
|
||||
|
||||
本轮用户明确目标：开船后依据预计到港提前人工联系提柜，同时掌握预计到海外仓的货物和各FBA仓货量，准备送货车辆，并把符合条件的车次余位接入现有拼车需求池。原方案已有方向：美国段预约统一入口、同仓跨客户合并、减少重复填写和控制卡片高度。
|
||||
|
||||
本次建议作为产品评审基线，尚未生效为代码合同的规则：
|
||||
|
||||
- 保留“预约列表”菜单和“美国预约总览”标题；以提柜与到仓、送仓与排车、预约日历三个工作视图组织，不另开一套拼车市场。
|
||||
- 从真实在途货开始筹划，先保存目标窗口和人工联系结果，后补外部确认；预计装车时间由车次维护，预约按关联读取。
|
||||
- 首版同起运仓、同目的地、相容窗口内人工组批，整来源明细选择；不同站点同车沿现有调度，一行货自由拆批不随页面优化默认开放。
|
||||
- 最新预测与已确认入库计划时间分开；船期变化提醒人工处理受影响承诺。修订已确认计划日期的命令与权限需另在当前合同中明确。
|
||||
- 正式拼车发布继续要求现有车次、车辆/司机及有效容量计划；无资源的远期运力先保留内部预排。
|
||||
|
||||
实施前还需结合运营习惯确定：
|
||||
|
||||
- 常用港口、接仓点与FBA线路的预计卸柜/备货/行车时间及缓冲；首版可由人工维护，不能给所有线路统一默认天数。
|
||||
- 提柜、接仓、FBA/客户送货分别由哪些岗位联系，对方是否由承运商代约，以及超时未回复时由谁接手。
|
||||
- 总览默认使用哪个业务时区，以及跨时区团队是否保存个人显示偏好。
|
||||
- 尚未满足现有拼车发布条件时，仅预排是否满足经营需要；如必须提前成交远期运力，需明确范围和承诺方式，不能省略这项能力差异。
|
||||
|
||||
## 十二 现有实现入口
|
||||
|
||||
| 用途 | 入口 |
|
||||
|---|---|
|
||||
| 当前预约页面与字段 | [AppointmentCalendarView.vue](../../apps/admin-web/src/modules/appointment-calendar/AppointmentCalendarView.vue)、[日历读取API](../../apps/admin-web/src/modules/appointment-calendar/api.ts) |
|
||||
| FBA预约现行边界 | [海外仓业务预约送仓](README.md#预约送仓)、[预约服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/service/InboundFbaAppointmentService.java) |
|
||||
| FBA必填字段 | [创建请求](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/dto/BatchFbaAppointmentRequest.java)、[Lastleg初始化基线](../../baiyue-firstleg/lastleg-service/src/main/resources/db/lastleg.sql) |
|
||||
| FBA预约货源与柜级到仓锁定 | [预约查询Mapper](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/inboundplan/mapper/InboundFbaAppointmentQueryMapper.java)、[尾程订单服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/service/LastlegOrderService.java) |
|
||||
| 码头提柜与还空 | [terminalDrayages.ts](../../apps/admin-web/src/modules/container-loading/api/terminalDrayages.ts) |
|
||||
| 柜级预计及实际到仓 | [containerArrivalTimes.ts](../../apps/admin-web/src/modules/container-loading/api/containerArrivalTimes.ts) |
|
||||
| 车次及运输资源 | [tripTypes.ts](../../apps/admin-web/src/modules/overseas-master-data/tripTypes.ts)、[trips.ts](../../apps/admin-web/src/modules/overseas-master-data/api/trips.ts) |
|
||||
| 外接承运预订 | [tripBookings.ts](../../apps/admin-web/src/modules/overseas-master-data/api/tripBookings.ts) |
|
||||
| 车次计划容量及拼车发布 | [车次执行服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetTripExecutionService.java)、[余位发布服务](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/fleet/trip/FleetCapacityOfferService.java)、[拼车主契约](内部拼车需求池首版开发契约.md) |
|
||||
| 排车独立预约字段 | [dispatches.ts](../../apps/admin-web/src/modules/overseas-warehouse/api/dispatches.ts)、[DispatchService.java](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/dispatch/service/DispatchService.java) |
|
||||
| 派送计划与实际签收 | [deliveryOrders.ts](../../apps/admin-web/src/modules/overseas-warehouse/api/deliveryOrders.ts) |
|
||||
| 本土运输需求日期 | [海外业务类型](../../apps/admin-web/src/modules/overseas-business/types.ts) |
|
||||
| 全流程维护入口 | [头程到尾程README](../头程到尾程/README.md) |
|
||||
@@ -0,0 +1,458 @@
|
||||
# 采购订单样品履约流程变更需求
|
||||
|
||||
日期：2026-10-09
|
||||
|
||||
采购订单需要从现有的下单、审核和数量记录，扩展为客户下单、海外购买、到仓装箱、国际快递交寄、国内收货核费及寄客户的完整流程。核心变更是将样品货款与快递费用分开控制：购买完成时扣样品货款，预估快递费先冻结，国内收货后再录入实际国际快递费、关税等费用。
|
||||
|
||||
本文是本次采购流程变更的需求维护入口。2026-10-09，用户授权按“首版简单、后续可扩展”的原则确定原第 8 节的 19 项业务规则；本版已将决定同步到操作、资金、权限和验收要求，开发按本版执行。第 2 节仅记录修改前的源码基线，第 3 至第 8 节定义目标行为；本文不表示目标功能已经实现、部署或通过环境验收。
|
||||
|
||||
## 1 已确认的目标流程
|
||||
|
||||
客户采购下单 → 国外客服购买完成，填写预计到货时间并扣样品货款 → 货物到仓核对，录入每箱箱规、重量及装货清单 → 国内客服根据清单打快递面单，冻结预估快递费 → 上传面单，国外贴单并送快递站点 → 国内收货，录入准确国际快递费、关税等费用 → 寄给客户。
|
||||
|
||||
| 节点 | 操作方 | 明确要求 | 需要区分的业务事实 |
|
||||
|---|---|---|---|
|
||||
| 客户下单 | 客户 | 创建采购订单 | 下单不代表已购买 |
|
||||
| 购买完成 | 国外客服 | 填写预计到货时间，执行样品货款扣费 | 购买完成与后台审核通过不是同一节点 |
|
||||
| 海外到仓及装箱 | 海外收货作业人员 | 收货核对，录入箱规、重量、每箱装货清单 | 入库总量不能替代逐箱清单 |
|
||||
| 制作面单及预估运费 | 国内客服 | 根据清单制作快递面单，锁定预估快递费 | 锁定是冻结，不直接扣款 |
|
||||
| 海外交寄 | 国外作业人员 | 获取面单，贴单，送快递站点 | 上传面单、贴单、交寄为不同事实 |
|
||||
| 国内收货及核费 | 国内收货人员、国内客服 | 国内收货后录入准确国际快递费、关税等费用 | 预估费用与实际费用必须区分 |
|
||||
| 寄客户 | 国内作业人员 | 将货物寄给客户 | 海外交寄与国内寄客户必须区分 |
|
||||
|
||||
## 2 当前实现与差距
|
||||
|
||||
以下为 2026-10-09 的源码核对基线，不作为测试环境部署或验收状态记录。部署与已验证场景仍以两份环境主契约为准。
|
||||
|
||||
| 范围 | 当前已有 | 本次需要变更 |
|
||||
|---|---|---|
|
||||
| 客户下单 | 正式创建、列表、详情入口；商品、规格、链接、数量、预算、地址和联系人；提交后待审核 | 在已有入口增加后续履约进度与业务明细 |
|
||||
| 购买 | 后台审核、预计到达时间维护 | 增加独立购买完成操作及实际样品货款扣费 |
|
||||
| 海外收货 | 采购仓库、手工入库数量、签收文件 | 增加收货核对、逐箱尺寸、重量和装货清单 |
|
||||
| 快递费用 | 后台登记费用及凭证，发送冻结请求 | 区分样品货款、预估快递费、实际国际快递费及关税；改变结算触发时点 |
|
||||
| 面单 | 只有签收文件、费用凭证分类 | 增加面单上传、受控读取、箱关联及贴单交寄事实 |
|
||||
| 国内收货 | 未见采购专用国内收货节点 | 增加国内收货事实及实际费用确认 |
|
||||
| 寄客户 | 国内外承运商、运单号；通用出库明细及时间 | 明确国内寄客户记录，与海外交寄分开 |
|
||||
| 客户详情 | 基础商品信息、数量、预计到达时间、国内外运单、审核备注 | 增加节点进度、逐箱明细及获准展示的费用和文件 |
|
||||
|
||||
现有采购展示状态为待审核、已通过、已拒绝、待出库、部分出库、全部出库，不能表达购买完成、装箱、面单、海外交寄、国内收货和寄客户。
|
||||
|
||||
当前下单为单商品模型，仅有一份选填收货地址，联系方式允许填写电话、微信或邮箱。已有字段不能直接视为国际段和寄客户段均已具备可用于快递制单的收件资料。
|
||||
|
||||
### 现有资金逻辑与目标冲突
|
||||
|
||||
采购费用登记后发起冻结。当采购入库量达到采购数量时，系统对已冻结的采购费用发起结算；如果在全部入库后才登记费用，冻结成功回执也会继续触发结算。触发条件是全部入库，不是采购出库。
|
||||
|
||||
因此，在货物到仓装箱后登记预估快递费，现有逻辑会继续结算，无法保证只冻结。必须移除采购费用依赖入库数量统一结算的行为，按不同费用用途和业务节点控制。不得仅修改页面文案而保留旧触发逻辑。
|
||||
|
||||
## 3 首版履约范围与操作规则
|
||||
|
||||
### 3.1 范围与扩展边界
|
||||
|
||||
- 一单一个商品及规格、一次购买、一个履约批次、一个海外实际收货仓和一个国内接收地点；数量使用正整数件。一单允许多箱，国际段和寄客户段各一次整批实际交寄，可有对应不同箱的主/子运单。
|
||||
- 海外、国内均允许对同一批次分次追加实收记录，例如两箱隔日到达。实收登记不自动完成收货；全部到齐或差异已处理后，由操作人员确认该段收货完成，再推进整批后续节点。
|
||||
- 首版不支持多商品、追加或分批购买、分批国际交寄、分批寄客户、跨订单合箱及跨订单共用面单。购买前需要更换商品或数量时，取消原单并重新下单、审核；购买后不修改原购买对象。
|
||||
- 海外收货、装箱、贴单和交寄均使用 Admin。采购数量只记履约台账，不接入 PDA，不形成或修改 WMS 可用库存，不绕过既有 PDA 入账边界。
|
||||
- 商品、实收明细、箱内明细、两段运送及费用分别保留稳定业务关联；首版在服务端限制商品和履约批次数量，不把可扩展性做成未启用的流程、通用审批引擎或新的资金账本。
|
||||
|
||||
### 3.2 节点操作与保存信息
|
||||
|
||||
| 操作 | 保存的信息 | 执行与完成条件 |
|
||||
|---|---|---|
|
||||
| 客户下单 | 单商品、规格、链接、数量、预算单价及币种、最终收件人、联系电话及完整国内地址 | 登录客户隔离；预算非负且必须明确填写，零预算表示仅授权免费样品；提交进入待审核 |
|
||||
| 平台审核 | 通过或拒绝、审核人、时间、备注、采购仓 | 保留现有单级审核；采购仓取国内仓库主档中的有效海外收货仓。拒绝结束原单，不新增退回修改流程；审核不是扣款 |
|
||||
| 确认购买完成 | 已审核商品与数量快照、实际购买时间、供应商实付金额及币种、凭证、预计到海外仓时间、操作人 | 按第 4.1 节预算上限校验；真实购买事实与资金状态分开保存，触发实际货款扣费。未购买不得点击完成，也不得以预算替代实付 |
|
||||
| 登记并确认海外收货 | 实收时间、实际仓库引用及编码/名称快照、逐次实收数量、合格数量、差异和处置 | 对照购买明细累计核对；已到货可先登记，未齐或异常未处理不能确认收货完成 |
|
||||
| 保存并确认装箱 | 箱号、外箱长宽高、封箱毛重；箱内商品、规格、数量、实收来源 | 仅使用本单已确认可发的实收明细；各箱数量合计必须等于本批全部可发数量，不能重复分配。草稿可随收货准备；正式确认须海外收货完成、样品货款成功或确认零元 |
|
||||
| 外部制单、上传与预估冻结 | 已确认清单版本、箱关联、承运商、运单号、面单文件、两端地址快照、预估国际运费 | 国内客服在外部制单后上传，填写 CNY 预估金额；系统只冻结该金额。制单与上传可先完成，冻结未成功不能交寄 |
|
||||
| 确认贴单与海外交寄 | 逐箱贴单确认、实际交寄时间、本批全部箱及货物来源、承运商与运单、操作人 | 贴单与交寄分开留事实；全部有效面单与当前清单一致，预估资金已冻结或明确为零，且无阻断异常，才允许整批交寄 |
|
||||
| 登记并确认国内收货 | 原国际交寄箱、逐次实收数量、合格/异常数量、实收时间、差异处理 | 不用总箱数代替逐箱来源；分次到达可以记录，全部收齐或差异已处置后确认该段完成 |
|
||||
| 核定实际费用 | 国际运费、关税、国内运费、其他费用的核定情况、实际金额、凭证、业务日期、确认版本 | 国内收货完成后由有核费权限的国内客服确认并发起第 4 节资金处理；不增加客户在线确认或第二级财务审批 |
|
||||
| 确认寄客户 | 国内实际交寄时间、全部可寄实收明细及数量、承运商与运单、最终收件快照、操作人 | 第 5 节资金及异常条件通过后整批交寄；生成面单、取得运单号或提交寄件信息不代表已寄出；实际交寄后进入“已寄客户” |
|
||||
|
||||
制单固定采用封箱毛重 kg（保留 3 位小数）和外箱长宽高 cm（各保留 2 位小数），数值必须为正。超出精度时提示按精度重新填写，不静默改变实测值；不新增净重、体积重或计费重试算。承运商计费与实测存在差异时，通过实际费用及凭证说明，不覆盖原测量值。
|
||||
|
||||
面单首版仅接受 PDF/JPG/PNG，沿用 File 的大小和安全限制；一个文件可覆盖本订单多个箱，但应明确每箱对应的面单页或文件。国际段同一批可有多个箱运单，国内段同样逐箱可追溯；不要求一箱一笔冻结，不新增快递商、轨迹或打印机集成。
|
||||
|
||||
### 3.3 修改、重制与历史保护
|
||||
|
||||
| 对象 | 首版规则 |
|
||||
|---|---|
|
||||
| 商品、规格、数量 | 审核后锁定，购买前需要变更则取消重下；购买后仅允许登记事实更正说明及异常处置，不直接改原商品或数量。预算上限调整单独按第 4.1 节处理 |
|
||||
| 计划采购仓与实际实收仓 | 首次实收前由采购审核/管理人员选择或修改计划仓；首次实收冻结实际仓。实际仓录错由采购管理人员凭说明、证据更正并保留原记录；已有后续实物操作时不得通过改字段重归属，仅补充更正记录并处理异常。首版不做转仓 |
|
||||
| 实收数量 | 按该实收记录本段的下游判断：海外实收已有装箱确认时，先撤回尚未交寄的海外清单再建立受控更正；国内实收在尚未寄客户时可建立受控更正，重核可寄数量、国内面单及费用依据，不回滚原国际交寄。已完成本段实际交寄时仅追加更正说明和异常处置，不改写原实物事实 |
|
||||
| 未交寄装箱清单 | 修改形成新版本；箱、数量、尺寸、重量变化立即使旧面单不能用于新版本，需国内客服重新核对清单、面单与预估。旧贴单确认失效，重新贴单后才可交寄 |
|
||||
| 未交寄预估金额 | 金额不变且币种为 CNY 时，核对后可由新清单版本引用原有效冻结，不新建占款；金额变化则先释放旧冻结，成功后再申请新金额冻结。释放或新冻结未完成时禁止交寄，失败显示待处理，不保留两笔重复有效占款 |
|
||||
| 面单重传 | 同清单同金额只替换文件版本并保留历史，不重复冻结；换承运商、运单或收件信息须重新核对报价和箱关联，并重新确认贴单 |
|
||||
| 已交寄记录 | 保留当次清单、货物、面单、运单、地址和时间快照；之后只能追加有权限的更正说明，不覆盖原事实，不以改版本重新增加可发数量 |
|
||||
| 已确认费用 | 金额、币种、汇率及资金请求不能原地覆盖；处理中禁止确认更正，已结算后的增减分别走第 4.5 节调整 |
|
||||
|
||||
海外交寄时，服务端须按本订单、当前清单、实际箱和货物来源原子校验并保存有效交寄事实。累计有效交寄不得超过本批可交寄装箱数量，本次必须覆盖全部可交寄箱；不同操作人、不同请求、刷新或更换清单版本不能重复发出同一货物。原请求重放返回原结果，其他请求遇到已交寄货物明确提示，不新增交寄数量或国内收货来源。合法更正只修订说明或建立关联更正，不产生第二份有效交寄。
|
||||
|
||||
### 3.4 国内货物承接与异常
|
||||
|
||||
- 国内实收逐箱关联国际交寄来源，同一收货事实不重复计数，分次实收按原箱累计核对；多到的货物单独记异常，不增加本单可寄数量。
|
||||
- 两端短少、破损、多货均先如实记录。未处理差异阻断收货完成及计划性发运，但不阻断继续登记真实到货。采购管理人员在本单记录“等待补齐、确认短少、破损拒收/处置、多货退回”的数量、原因、证据、操作人和时间。
|
||||
- 等待补齐不生成第二个购买或发运批次。供应商补发只用于海外整批交寄前补齐本单原采购缺口；国际交寄后，国内等待补齐仅限原交寄范围内的迟到货物。需要重新采购或再次国际发运的另行下单，不在原单追加交寄。客户接受短少、破损后剩余货物继续履约，或停止履约，均由客服留存客户书面/聊天凭证，采购管理人员确认。钱款由财务关联原费用调整，不按短少数量自动退款。
|
||||
- 只有已确认可寄的实收明细可继续装箱/寄出；已寄量加本次寄出量不得超过可寄实收量，且本次须覆盖本批全部剩余可寄货物。全损或无可寄货物进入异常关闭，不伪造零数量交寄。
|
||||
- 国内允许一原箱对应一新包装的破损换箱，记录原因与新箱规重量，保留原箱业务标识及其来源关系；换箱不改变已经核准可寄的商品、数量。不支持拆成多箱、合并不同箱或重新组合商品；损坏商品的剔除先走差异处置。
|
||||
- 购买前可由有取消权限的平台人员取消，客户通过客服提出取消；购买后不提供抹除履约的一键取消。全部实物去向明确、无需继续履约、已收费调整和冻结释放均完成且无未决资金时，采购管理人员可异常关闭。关闭保留原履约和资金事实，不自动退款，也不自动生成退货物流任务。
|
||||
- 本节只是采购履约记录及最小异常处置，不产生 WMS 库存流水，不新增通用异常工单、供应商应付或索赔系统。
|
||||
|
||||
### 3.5 两段地址、文件与客户展示
|
||||
|
||||
| 内容 | 首版处理 |
|
||||
|---|---|
|
||||
| 国际段收寄资料 | 寄件方取实际海外仓资料，国内接收地址由国内客服每单录入或从已有资料复制；国内收件人、联系电话及完整地址在制单前必填，不新增国内接收地点主档 |
|
||||
| 国内寄客户资料 | 客户下单提供最终收件人、电话和完整国内地址；国内客服寄出前核对。客户申请变更由客服凭确认记录修改；已制单须重制面单，实际交寄后不能覆盖原地址或在系统中假作改派 |
|
||||
| 资料快照 | 两段分别保存当次使用的收寄姓名、电话、地址及承运商要求的信息，后续主档变更不改历史快照；仅有微信或邮箱不能代替快递电话 |
|
||||
| 客户可见 | 本客户订单进度、预计到海外仓时间、装箱结构化明细、两段承运商/运单、预算上限、货款及各费用、冻结/扣款/退款结果、对客异常处理摘要 |
|
||||
| 客户不可见 | 面单、供应商采购凭证、费用凭证、预算沟通凭证、内部异常附件、内部备注及原始诊断报错；首版不开放这些文件下载，也不新增客户核费审批页面 |
|
||||
|
||||
文件读取、下载和关联均由服务端校验客户、订单、文件分类及操作者权限。平台人员可在其采购业务权限范围内处理不同客户的订单，不强加个人仓绑定；关联的文件必须属于当前订单，不能仅凭同客户或文件标识放行。一个订单多箱共用一份面单允许，跨订单共享首版不开放。文件本体继续由 File 持有。
|
||||
|
||||
## 4 费用与资金规则
|
||||
|
||||
### 4.1 币种、预算和实际货款
|
||||
|
||||
- 原币仅支持 CNY/USD，钱包、资金命令及本次采购实际费用入池统一 CNY。预算单价和原币费用保留 2 位小数；USD 折算复用 Lastleg 现有月度汇率及 OverseasFeeCurrencyConverter：取费用实际发生日所在月的有效正数汇率，汇率 6 位，CNY 金额 2 位，均使用 HALF_UP。CNY 汇率固定 1.000000。
|
||||
- 保存原币、原金额、实际业务日、汇率月份、汇率值和折后金额；确认后冻结快照。缺失有效汇率时不得确认资金金额，不能默认 1 或取回执/重试当天汇率；已经发生的购买仍可登记为待核定事实。
|
||||
- 预算总上限等于预算单价乘已审核数量，是样品货款上限，不包含运费、关税等服务费用。核对实付时，预算与实付均以本次购买相同汇率快照折算为 CNY 比较；实际货款按供应商实付 1:1 收取，首版不加价。
|
||||
- 无预算须先取得客户授权补齐；零预算只授权免费货款。超预算须在购买前取得客户书面/聊天确认，客服登记新的上限、币种与凭证，由现有采购审核人员核验后生效；保留前后上限，不新增客户在线审批或多级流程。
|
||||
- 已发生的未授权超预算须记录真实事实并暂停后续确认，取得客户授权后再核定扣费，或按异常终止/退款处理；不得静默超扣、伪造金额或丢失采购事实。买错商品或数量不通过补预算授权改写原购买对象，记录异常后处理退还/关闭，正确需求另单办理。
|
||||
|
||||
### 4.2 费用用途与核费范围
|
||||
|
||||
| 用途 | 时点与资金行为 |
|
||||
|---|---|
|
||||
| 样品货款 | 购买完成后按确认的实际 CNY 金额扣费；明确免费时只记核定事实，不发零元资金指令 |
|
||||
| 预估国际运费 | 制单阶段只冻结国际段预估 CNY 金额；零预估须记录依据，不发零元冻结。关税、国内运费及其他费用不混入该冻结，冻结不生成实际应收 |
|
||||
| 实际国际运费 | 国内收货完成后按实际金额结算唯一有效的国际运费冻结，规则见第 4.3 节 |
|
||||
| 关税 | 国内客服依据实际凭证核定，正额单独扣费，不适用或零元需明确确认 |
|
||||
| 国内运费 | 国内收货完成后可先外部制单确定价格，核定扣费成功后再交承运方；制单不代表发货，不引入“先发货才能知道金额”的依赖 |
|
||||
| 其他费用 | 默认不适用；发生时逐项填写名称、原因、凭证、业务日及金额，正额单独扣费。不得重复计入货款、国际运费、关税或国内运费 |
|
||||
|
||||
国内核费由有核费权限的国内客服一次确认本单费用清单，不再增加客户确认或第二级财务审核。国际运费、关税、国内运费和其他费用范围都应有明确核定结果；其他费用可标为“不适用”，不要求创建虚构收费行。
|
||||
|
||||
| 核定情况 | 处理 |
|
||||
|---|---|
|
||||
| 待核定 | 尚无明确结果，空值不视为零元；不能完成本单核费或寄客户 |
|
||||
| 确认零元 | 项目适用但无需收费，保存确认人、时间及依据，不发零元扣款、冻结或结算指令 |
|
||||
| 不适用 | 明确不适用于本单，保存确认说明，不伪造已付款 |
|
||||
| 确认正额 | 保存金额和确认版本，发起资金处理；核费已确认与扣费成功分别展示 |
|
||||
|
||||
已有冻结对应的实际费用确认零元时仍须真实释放冻结。费用清单中的多笔正额分别处理，部分扣款成功不回滚已成功扣款，也不能重扣；只跟进其余未完成项，全部完成后才允许国内实际交寄。
|
||||
|
||||
### 4.3 扣费、差额与冻结
|
||||
|
||||
样品货款、关税、国内运费及其他正额费用复用 Finance 的业务冻结后立即全额结算链路，同一费用号最多一次成功实扣。中间显示扣费处理中，不要求客服手动执行两步；冻结成功不等于扣费成功。该自动结算只用于明确的实际费用用途，预估国际运费不得沿此链路自动结算，更不得由采购入库数量触发。
|
||||
|
||||
设预估国际运费冻结额为 E，最终实际国际运费为 A，两者均为 CNY：
|
||||
|
||||
| 情况 | 首版资金行为 |
|
||||
|---|---|
|
||||
| A = E 且 A > 0 | 结清原冻结，实扣 A |
|
||||
| 0 < A < E | Finance 在同一事务内实扣 A、释放 E − A，原预估 E 与实际 A 分别保留 |
|
||||
| A > E | Finance 在同一事务内校验并补占差额后实扣 A；资金/有效授信不足时整笔失败，保留原冻结和原余额，不先释放原冻结 |
|
||||
| A = 0 或国际运费不适用 | 仅释放对应有效冻结；无冻结则只保留核定结果，不生成零元结算 |
|
||||
| E = 0、A > 0 | 无原冻结可结算，按一笔实际国际运费执行冻结后立即结算；费用来源仍只记录 A |
|
||||
|
||||
按实际金额结算冻结由 Finance 原子执行，Lastleg 不能用“释放旧冻结、再冻实际金额、再结算”的串行操作代替。此规则用于最终实际结算；交寄前重新报价使用第 3.3 节“先释放旧预估、再冻结新预估并阻断交寄”的流程，二者时点不同。
|
||||
|
||||
资金可用额、授信期限、扣用顺序和充值归还顺序全部沿用 Finance 当前规则；采购不额外开放透支、不建立授信副本，也不套用信用卡授权有效期。冻结不因到货、时间流逝或订单页面关闭而自动结算/释放，必须关联明确的重估、结算、取消或异常处理动作。
|
||||
|
||||
### 4.4 请求幂等、费用版本与入池
|
||||
|
||||
- 每个资金请求绑定客户、费用用途、费用确认版本、原币/汇率/CNY 快照和唯一请求标识。每个费用业务事实最多一次成功扣款，不能通过新请求标识绕过该约束。
|
||||
- 处理中或结果未知时，可保存更正草稿，但不能确认新版本、发起替代扣款、退款或释放同一待决资金；先查询/重放原请求直至结果明确。网络超时不能当成业务失败。
|
||||
- 只有 Finance 已明确失败且确认未发生目标资金动作时，才允许对同一费用版本登记新的重试尝试；保留原尝试结果。冻结已成功但结算失败时只重试结算，不能新冻一遍。
|
||||
- 旧版本晚回执只能更新原请求及其费用版本，不覆盖新金额结果，不丢弃真实扣款、冻结或释放事实。未决时尝试确认 V2 应被拒绝，V1 结果明确后才能按第 4.5 节更正。
|
||||
- 本次采购的正额费用收到成功扣款回执后，才通过同一费用版本的 Outbox 发布实际应收来源。预估冻结、零元和不适用不发布实际应收；发布失败只重试来源投递，不再次扣款。
|
||||
- Finance 以明确的原资金处理引用和实际 CNY 扣款金额核对来源；匹配后直接作为已结算应收入池，不能进入普通待对账候选。来源缺少资金引用、引用跨客户或金额不符时拒绝或待核对，不降级成可再次收费的 AVAILABLE 来源。
|
||||
- 延迟、乱序及重放仍须安全：已扣款等待来源入池时显示该关联进度；关联不影响已经发生的资金事实，但正常寄客户前须完成实际费用入池关联，异常关闭前同样须完成关联。
|
||||
|
||||
上述规则按[财务费用入池 P0 闭环](../财务管理/财务费用入池P0闭环.md)的防重复结算原则执行；本次采购采用“先实扣、后发布已结算来源”的确定路径，不增加采购赊账出账选项。
|
||||
|
||||
### 4.5 更正、追加与退款
|
||||
|
||||
- 未发出资金请求的费用草稿可修改；仅处于预估冻结阶段的金额变化按第 3.3 节重估。已发出请求且结果未决时锁定确认动作，不用新费用号避开未决状态。
|
||||
- 实际费用的资金请求已明确失败且尚未成功实扣时，先终止旧版本的后续重试；仍有有效冻结的须释放成功，才可更正确认新费用版本并发起关联的新请求。该情形不产生已实扣差额单或退款，旧版本不能因晚回执或人工重试重新生效。
|
||||
- 已结算费用增加金额，由具有财务调整权限的人员创建仅含正差额的新调整单、独立费用号，引用原费用和原因凭证；例如原已扣 100，正确总额 120，则新增 20，不重新扣 120，也不复用原冻结号。原实际费用和差额各自关联成功资金结果。
|
||||
- 已结算费用减少或应退，由财务人员创建关联原成功扣款的 CNY 退款调整，填写原因、凭证和金额。Finance 锁定原扣款，原子校验本次退款金额不超过“该原扣款金额 − 累计已成功退款”的可退余额；等价地，计入本次后的累计退款不得超过该原扣款。幂等回补客户钱包并保留不可变流水，回补遵循 Finance 现行资金归还顺序，不延长或恢复过期授信；仅冻结未扣款的款项执行释放，不做退款。
|
||||
- 退款只回客户资金账户，不走外部支付原路退款，不以普通充值伪装，不发布负数普通费用。原费用保持已结算，财务净额通过原款、正额调整及退款记录计算，不能重新进入待对账池。
|
||||
- 对同一原费用链的金额更正沿用原汇率快照，以“原扣款 + 已成功正额调整 − 已成功退款”计算当前净实扣，再与本次修正目标 CNY 总额求差。同一费用链有未决调整或退款时不得确认下一次更正；明确失败的旧调整须先完成，或终止其后续重试并释放仍占用的冻结后，才能按新目标更正，不能留下以后还可重试扣款的旧目标。独立新发生费用才使用新业务日汇率；退货、短少不自动推导退款金额，由财务依据已确认的客户处理方案执行。
|
||||
- 已成功退款、调整和原扣款均不得覆盖；同一调整单重放返回原结果，拒绝重复、超额及零元退款。需退多笔实扣时逐笔关联，不能跨客户冲抵。
|
||||
- 履约已完成后可以处理有凭证的追加或退款，资金进度单独展示，不把“已寄客户”回退成未发货；异常关闭时要求当时所有已知资金处理结束，后续新增有据调整保留关联记录。
|
||||
|
||||
## 5 权限、状态与节点准入
|
||||
|
||||
### 5.1 操作权限
|
||||
|
||||
沿用平台/客户两级及现有 IAM 角色；不新建国内/海外用户类型或岗位主档。采购列表权限包含详情只读，写操作独立，按下表动作赋予现有岗位，可由同一账号兼任多个动作，首版不强制双人分离。
|
||||
|
||||
| 动作范围 | 负责岗位及权限边界 |
|
||||
|---|---|
|
||||
| 客户下单和查询 | 仅本客户；不能执行后台审核、收货、发运或资金调整 |
|
||||
| 采购审核、取消、预算上限核验 | 现有采购审核/管理人员，保存审核或取消事实 |
|
||||
| 购买、海外收货装箱、贴单交寄 | 海外业务人员按各动作权限执行；服务端校验有效海外仓及订单冻结的实际仓，不把 Admin 用户绑定到某个 PDA 仓 |
|
||||
| 面单、预估、国内实收、核费、寄客户 | 国内业务人员按对应独立动作权限执行；面单上传不同时赋予核费或资金调整权限 |
|
||||
| 事实更正、差异确认、异常关闭 | 采购管理权限；资金结果不能通过此权限修改 |
|
||||
| 追加收费、退款 | Finance 财务调整权限；采购服务只发起受控业务请求，不直写账户或财务单据 |
|
||||
|
||||
权限码、Controller、接口合同、IAM 配置与前端按钮由开发按此动作边界同步落地，不能继续用一个通用编辑权限代替所有新节点权限。平台授权人员可以处理不同客户的采购单；客户隔离及文件范围始终由服务端保证。
|
||||
|
||||
### 5.2 状态与准入
|
||||
|
||||
履约进度按事实派生：待审核 → 待购买 → 待海外到仓 → 海外收货中 → 待装箱 → 待面单及预估处理 → 待海外交寄 → 国际运输中 → 国内收货中 → 待国内核费 → 待寄客户 → 已寄客户。已拒绝、已取消、异常关闭单独记录；异常处理中作为阻断标记，不抹去最后真实履约阶段。具体枚举命名由技术设计确定，含义不得改变。
|
||||
|
||||
| 动作 | 首版前置条件与资金失败处理 |
|
||||
|---|---|
|
||||
| 正常购买确认 | 已审核，商品及数量一致，预算授权和汇率可用；购买前可查询资金资格但不提前冻结货款。已真实发生的异常购买可登记，扣费失败不回滚购买事实 |
|
||||
| 登记收货事实 | 有对应购买/交寄来源即可记录实际到货，即使资金未成功；来源异常仍保留异常记录，不能伪造上游成功来放行正常链路 |
|
||||
| 正式装箱确认、预估冻结 | 海外收货完成、差异处理完毕、样品货款扣款成功并完成费用来源关联，或已明确免费；资金未决/不足时可准备草稿，不能完成上述确认 |
|
||||
| 海外实际交寄 | 清单、面单及逐箱贴单已确认；样品货款完成；预估国际运费冻结成功或确认零预估；所有可发货物整批一致，无阻断异常 |
|
||||
| 国内核费确认 | 国内收货完成，差异处置明确；四类费用均有核定结果，国内运费可以先制单取得确定金额。可以保存草稿，未核定不能确认整单费用 |
|
||||
| 国内实际交寄 | 全部可寄货物核平；全部正额货款/费用扣款及费用来源关联完成；零元/不适用已核定；多余冻结已释放；无未决退款/调整及阻断异常 |
|
||||
| 异常关闭 | 全部货物有明确去向且无需继续履约；所有已知费用、退款、来源关联和冻结释放完成；采购管理人员填写原因确认 |
|
||||
|
||||
首版不允许客服用“继续发货”跳过资金失败或未知结果，也不新增人工透支开关。余额不足通过充值或 Finance 已有授信机制解决后重试。国内实际交寄确认即正常履约终态，不新增客户签收、物流轨迹或自动签收功能。
|
||||
|
||||
## 6 代码入口、能力差距与实施边界
|
||||
|
||||
| 范围 | 当前入口 | 本次实现重点 |
|
||||
|---|---|---|
|
||||
| Client | apps/client-web/src/modules/cross-border/routes.ts、views/ProcurementView.vue、components/BusinessOrdersView.vue、api/businessOrders.ts | 单商品下单校验、预算及地址、进度与费用展示；不影响共用组件中的本土卡车、散板 |
|
||||
| Admin | apps/admin-web/src/modules/overseas-business/pages/PurchaseOrdersView.vue、PurchaseOrderEditView.vue、PurchaseOrderDetailView.vue；api/platformOverseasBusiness.ts | 节点动作、实收/箱明细、面单、预算凭证、核费及异常权限；通用编辑移除越过节点的写入 |
|
||||
| Lastleg | baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/procurement/ | 状态和业务明细、用途驱动资金指令、版本回执、原子数量校验及审计 |
|
||||
| 费用来源与汇率 | Lastleg financefee/，按采购实际引用进入；OverseasFeeCurrencyConverter | 复用月度 USD/CNY 汇率快照；成功扣款后发布实际来源，预估不入池 |
|
||||
| Finance 与 File | 沿采购资金、费用和文件调用进入 | Finance 资金及关联扩展；File 文件归属、分类与授权 |
|
||||
|
||||
现有钱包只有全额结算/释放，不能将“按实际金额结算冻结”或“关联原扣款退款”写成已经具备。首版必须补齐以下定向能力：
|
||||
1. Finance 在单事务内按实际金额结清预估冻结，并处理少收释放、超额补差、资金不足整笔不动。
|
||||
2. Finance 关联原扣款的幂等钱包退款、可退余额校验及财务调整留痕。
|
||||
3. Finance/Lastleg 按真实资金处理引用和实际结算金额绑定费用来源，防止预估金额与实际金额不同导致匹配失败或重复出账。
|
||||
|
||||
业务费用仍归 Lastleg，账户/冻结/流水/财务事实归 Finance，文件本体归 File。统一 Gateway/Auth 和业务 Outbox 直接投递不变，不新建账本或事件桥。上述定向扩展是满足本版需求的开发内容，不以新增技术平台或跨库写入实现。
|
||||
|
||||
开发前需完成本版对应的 DTO、状态/动作、资金命令与回执、表结构及权限合同设计。对外 API、OpenAPI、初始化 SQL、直接消费者、Mock/Fixture 和测试按仓库门禁同步；不为测试存量保留旧流程兼容分支。开发应移除“全部入库统一结算采购费用”的两处旧触发路径。
|
||||
|
||||
需求整理阶段仅维护文档；后续用户已授权按本文开发，并部署测试环境、操作测试数据库、执行真实 HTTP 及内置浏览器验收。该授权仅用于本次采购变更的测试环境操作，不扩展到生产环境或无关数据清理。
|
||||
|
||||
## 7 首版验收要求
|
||||
|
||||
| 场景 | 必须满足的结果 |
|
||||
|---|---|
|
||||
| 单商品与批次边界 | 多商品、追加购买、分批发运、跨订单合箱请求由服务端拒绝；一单多箱正常完成 |
|
||||
| 审核及预算 | 未审核不得购买；无预算不得正常确认；零预算不能扣正额；超预算凭证核验前不能正常扣费；实付不能被预算替代 |
|
||||
| 汇率与跨月重试 | CNY/USD 原币与 CNY 折算可还原；缺失月度汇率不伪造金额；跨月回执及重试保持原快照；金额与精度按现行转换器 |
|
||||
| 购买事实与货款 | 购买完成发起货款扣费，不等到全部入库；失败保留购买事实，免费不发零元命令；重复请求不重复扣费 |
|
||||
| 分次到货 | 同一批次多次实收累计正确；到货可记录，未齐或异常未处理不确认完成；海外交寄前可补原采购缺口，国内迟到只接原国际交寄货物，需要再次国际发运的另单处理 |
|
||||
| 分段实收更正 | 海外实收更正撤回本段未交寄清单；国内实收更正不回滚已完成国际交寄，重新核对国内可寄数量、面单及费用；已完成本段交寄只追加说明和异常 |
|
||||
| 实际收货仓 | 实收后通用编辑不得改历史仓；受控录错更正保留原记录，修改采购仓不代表实物转仓 |
|
||||
| 装箱与测量 | 实收来源与箱内件数核平，不能重复分配；全部可发数量被覆盖；cm/kg 精度和正值校验正确 |
|
||||
| 多人海外交寄 | 非本单/无效清单箱拒绝；两人不同请求并发或刷新重提同一箱仅一份有效交寄；换版或更正不重复增加国内来源 |
|
||||
| 面单及预估 | 外部面单可按箱读取打印；上传、贴单、交寄分开；冻结成功仅减少可用额；零预估有依据；全部入库及其后新增预估均不触发扣款 |
|
||||
| 交寄前重制 | 清单/面单变化后旧贴单失效；同金额重传不重复冻结；变价先释放成功再新冻结，过程及失败阻断交寄 |
|
||||
| 国内实收与换包装 | 逐箱来源可追溯，重复实收拒绝；允许一对一换包装但不增加货量；拆箱、合箱及重新组合拒绝 |
|
||||
| 收货差异 | 短少/破损/多货如实记录，未经处理不继续；客户接受减量有凭证；无可寄货物不能零数量交寄 |
|
||||
| 核费及国内制单 | 四类费用有明确结果；国内运费可先制单再核定扣费，实际交寄在后；未知金额不当零元 |
|
||||
| 零元/不适用 | 不发零元资金指令、不发布虚构应收；原冻结仍释放并跟踪实际结果 |
|
||||
| 国际运费差额 | 覆盖 E=100、A=100/80/120/0 及 E=0、A>0；少收余款释放，超额不足时原冻结和余额不变，不出现重复占款或扣费 |
|
||||
| 未决更正与晚回执 | V1 请求未决时 V2 只能存草稿，确认及替代请求被拒绝；晚回执归属 V1且真实资金事实保留；超时查询/重放不重复执行 |
|
||||
| 明确失败后重试 | 原结果已确定且无目标资金动作后才能新尝试；已冻结只重试结算，同费用最多一次实扣 |
|
||||
| 扣款与入池 | 扣款成功才发布实际来源；投递失败不再扣款；原资金引用、客户或实际金额不匹配时不进入普通待对账池；乱序重放仍不重复收费 |
|
||||
| 追加与退款 | 已扣100连续改120、130、110，依次补20、补10、退款20，净实扣110；单笔原扣100已退30再退50应成功，再退超过20应拒绝；并发退款不能超原实扣；不以充值或负数普通费用替代，原费用不重新可出账 |
|
||||
| 节点门禁 | 扣费失败仍可登记真实到货；不能确认装箱或计划发运；国内交寄前全部资金、来源关联、余款释放及异常处理满足要求 |
|
||||
| 地址与真实发运 | 两段快照独立，改地址不覆盖旧面单；仅填写运单不显示已寄；实际国内交寄后进入正常终态 |
|
||||
| 客户与文件权限 | 客户仅见自己的结构化资料及费用结果，不能下载内部文件；跨客户文件读取/错误订单挂载拒绝；平台已授权跨客户操作不误拦 |
|
||||
| 取消与异常关闭 | 购买前可取消；购买后不抹除原事实；实物和资金未收口不能异常关闭；关闭不自动退款 |
|
||||
| 权限与前端回归 | 节点动作由服务端独立授权，通用编辑不能越权；采购修改不破坏本土卡车、散板；客户响应无内部附件和诊断信息 |
|
||||
|
||||
代码和本地检查通过不代表整体验收完成。真实 HTTP 与环境写入、部署仍按仓库授权执行；Admin/Client 视觉验收按 1920×1080、100% 缩放，由人工操作并提供截图。部署与已验证场景仅维护在现有两份环境主契约。
|
||||
|
||||
## 8 原 19 项业务规则的首版决定
|
||||
|
||||
本表依据 2026-10-09 用户“按最简单可扩展方式先确认”的明确授权确定，替代原待确认清单。它是本次业务范围与行为选择，不表示实际人员已在业务单上完成审核或核费。开发按本版实施，后续改变范围需先回写本文。
|
||||
|
||||
| 编号 | 原决策主题 | 首版决定 |
|
||||
|---|---|---|
|
||||
| 01 | 多商品、购买与履约批次 | 单商品/规格、一次购买、一个批次；多箱、分次实收；两段各一次整批交寄，见第 3.1 节 |
|
||||
| 02 | 购买前审核 | 保留现有单级审核；通过后购买，拒绝结束原单；不新增通用审批 |
|
||||
| 03 | 预算与超预算 | 预算为货款上限；超预算先取得客户书面/聊天授权，由现有审核人员核验；不做客户在线审批，见第 4.1 节 |
|
||||
| 04 | 币种与汇率 | 原币 CNY/USD，钱包及入池 CNY；复用业务日所属月汇率，快照不重算 |
|
||||
| 05 | 面单方式 | 国内客服外部制单、上传 PDF/JPG/PNG；无快递商/轨迹/自动试算集成 |
|
||||
| 06 | 箱规重量 | 封箱毛重 kg 3 位、外箱 cm 2 位，正值；不新增计费重试算 |
|
||||
| 07 | 重制与冻结 | 同金额核对后沿用冻结；变价先释放旧冻结再新冻，期间禁止交寄；旧面单/贴单按第 3.3 节失效 |
|
||||
| 08 | 事实更正 | 购买对象锁定；按本段未发运的下游撤回并受控更正，国内更正不回滚国际交寄；已交寄事实只追加说明/异常，不覆盖或重发 |
|
||||
| 09 | 两段收寄资料 | 国际段国内接收资料由国内客服每单录入，最终客户资料由客户下单提供；确认及交寄保留两段快照 |
|
||||
| 10 | 作业终端与仓范围 | 海外用 Admin，不接 PDA/WMS；角色复用、动作独立授权；校验有效仓与订单实际仓，不新增 Admin 个人仓绑定 |
|
||||
| 11 | 国内部分实收及重装 | 同批允许分次实收，收口后才继续；仅支持一对一换包装，不拆箱/合箱/重组 |
|
||||
| 12 | 实际费用确认 | 国内客服按独立核费权限一次确认四类费用；无客户或二级财务审批；未知不当零 |
|
||||
| 13 | 预估冻结范围 | 仅国际快递费；关税、国内运费及其他费用实际核定后单独扣费 |
|
||||
| 14 | 实际差额结算 | Finance 原子按实际金额结清预估，少退多补，不足原状保留；零实际只释放，见第 4.3 节 |
|
||||
| 15 | 未决费用更正 | 只允许准备草稿，原结果明确前不确认新版本或发替代资金请求；已扣增额做正差额单、减额做关联退款 |
|
||||
| 16 | 失败与节点准入 | 真实到货可记；正式装箱及计划交寄须满足资金条件；未知/不足不放行，见第 5.2 节 |
|
||||
| 17 | 差异、取消与退款 | 单内最小异常处置；客户减量/停止有凭证；购买前取消，购买后收清实物和资金才能异常关闭；退款回钱包，见第 3.4、4.5 节 |
|
||||
| 18 | 正常完成条件 | 国内实际交寄确认即“已寄客户”；不新增签收或轨迹。之后财务调整不回退履约事实 |
|
||||
| 19 | 客户资料开放 | 展示结构化箱明细、运单和费用结果；内部面单、采购/费用/沟通凭证及异常附件不开放下载 |
|
||||
|
||||
### 开发交接结论
|
||||
|
||||
原 19 项已转为明确首版规则，正文与验收按同一范围执行，不再以待产品选择的条件场景交付。开发仍需完成 DTO、数据库、权限、资金事件和接口的技术设计，并实现第 6 节的 Finance 定向扩展；这些属于已确定业务规则下的实现工作，不是新的产品待确认项。
|
||||
|
||||
本版可交开发开展技术设计、任务拆分及实现。需求评审结论不替代编译、测试、环境或人工视觉验收，不表示当前代码已经满足目标。
|
||||
|
||||
## 9 依据与成熟软件参考
|
||||
|
||||
### 9.1 当前项目依据
|
||||
|
||||
- [海外仓业务入口](README.md)
|
||||
- [财务管理入口](../财务管理/README.md)
|
||||
- [财务费用入池 P0 闭环](../财务管理/财务费用入池P0闭环.md)
|
||||
- [统一认证与服务通信契约](../统一认证与服务通信契约.md)
|
||||
- [测试环境单机部署与配置契约](../测试环境单机部署与配置契约.md)
|
||||
- [平台客户层级与权限契约](../平台客户层级与权限契约.md)
|
||||
- [客户端采购详情实现](../../apps/client-web/src/modules/cross-border/components/BusinessOrdersView.vue)
|
||||
- [后台采购详情实现](../../apps/admin-web/src/modules/overseas-business/pages/PurchaseOrderDetailView.vue)
|
||||
- [采购服务与现有资金触发逻辑](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/procurement/service/OverseasProcurementService.java)
|
||||
- [现有海外费用汇率转换](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/financefee/service/OverseasFeeCurrencyConverter.java)
|
||||
|
||||
### 9.2 官方产品文档对照
|
||||
|
||||
参考查询日期：2026-10-09。以下用于验证设计模式可行性，具体 19 项是结合本项目现状作出的首版选择，不是声称这些产品采用完全相同的业务规则。
|
||||
|
||||
| 官方资料 | 本次采用的模式及边界 |
|
||||
|---|---|
|
||||
| [Odoo 19：收发货流程](https://www.odoo.com/documentation/19.0/applications/inventory_and_mrp/inventory/shipping_receiving/daily_operations.html) | 可从较少操作步骤开始，再按质量与仓储需要扩展；本次采用简化采购台账，不引入 Odoo 的库存体系 |
|
||||
| [ERPNext：Purchase Receipt](https://docs.frappe.io/erpnext/purchase-receipt) | 订单与实收分开，记录接收/拒收及短收关闭；本次允许同批多次实收和明确差异处置，不照搬其库存过账 |
|
||||
| [Shopify：Understanding shipping labels](https://help.shopify.com/en/manual/fulfillment/fulfilling-orders/shipping-labels/understanding-shipping-labels) | 支持在系统外购买面单后补充运单，贴单和交给承运方是不同动作；本次保留外部制单与人工交寄确认 |
|
||||
| [Stripe：授权与捕获分离](https://docs.stripe.com/payments/place-a-hold-on-a-payment-method) | 预留与实际扣款分开，部分扣款释放余款；本项目使用自有 Finance 钱包，原子补差是本项目扩展，不接入 Stripe，也不使用信用卡期限或超额捕获规则 |
|
||||
| [Stripe：幂等请求](https://docs.stripe.com/api/idempotent_requests) | 重试关联原请求，参数变化不能冒充原请求；本项目另加费用业务级防重复，不照搬外部平台的幂等记录保留期限 |
|
||||
|
||||
可行性结论：上述模式能够支持本版采购样品流程；实施重点是本项目的明细关系、权限、资金用途及 Finance 定向扩展，不需要先引入完整 ERP、WMS、第三方支付或通用流程平台。
|
||||
|
||||
## 10 技术实施合同
|
||||
|
||||
本节将前述业务规则映射到实现边界，不改变业务范围，也不表示对应功能已完成。开发直接在当前工作区及分支实施。
|
||||
|
||||
### 10.1 数据与事务边界
|
||||
|
||||
| 数据对象 | 归属与核心关系 | 约束 |
|
||||
|---|---|---|
|
||||
| 采购主单 | Lastleg，保留当前采购单号与客户归属 | 主单版本控制；商品、规格和购买数量审核后冻结；履约阶段与资金状态分开 |
|
||||
| 购买事实与预算授权 | 关联采购单、原商品快照、凭证及预算授权版本 | 每单一次实际购买；异常购买事实可以先保存，但未核定金额不能扣费 |
|
||||
| 两段实收记录 | 段别为海外/国内；海外关联购买，国内关联国际交寄箱 | 分次追加与更正留痕；不能重复消费实收来源；实收不直接增加 WMS 库存 |
|
||||
| 装箱清单与箱内来源 | 清单版本、业务箱号、尺寸重量、实收来源及数量 | 每单唯一当前确认版；数量守恒；失效版本不得交寄；历史版本不能恢复可发数量 |
|
||||
| 面单与贴单事实 | 文件归 File，关联关系归 Lastleg；绑定运输段、清单版本及箱号 | 每箱明确文件或页码；面单版本改变后旧贴单资格失效；只允许同订单文件关联 |
|
||||
| 国际与国内交寄 | 每单每段唯一有效整批交寄；保存箱/来源数量、地址、运单快照 | 订单行锁内复验全部货物、资金与异常条件；两段交寄各自幂等，跨请求也不能重复发运 |
|
||||
| 费用版本 | 费用用途、核定情况、原币/汇率/CNY、版本、原费用链 | 草稿可修改；确认后不可覆盖；预估、实扣及退款分别记录 |
|
||||
| 资金请求尝试 | 费用版本、操作、冻结身份、事件 ID、请求幂等键、请求金额、结果 | 结果按 commandEventId 精确落到原尝试；未决时禁止替代请求，明确失败才可受控重试 |
|
||||
| 费用来源关联 | 成功实扣对应的来源版本、资金引用、关联结果 | 预估不入池；资金成功与来源关联分别记录；来源投递重试不得重发扣款 |
|
||||
| 差异和更正记录 | 来源对象、原事实引用、数量、处置、证据、操作者 | 追加留痕；已交寄事实不覆盖；资金更正受 Finance 独立权限约束 |
|
||||
|
||||
数量、费用版本、资金请求和明细关联使用结构化列及唯一约束；JSON 只承载不可变快照、地址或审计补充，不承担全部数量关系。每个节点命令使用订单版本、幂等键和请求摘要；锁定订单后复验来源、可执行动作及最新资金状态，再原子提交事实、审计和业务 Outbox。
|
||||
|
||||
通用 `finance-fee-sources` 接口不允许人工创建、提交、审核、调整或作废采购费用来源；采购收费与更正必须从采购节点进入，实扣成功后才由内部已结算发布入口关联来源，防止绕过节点形成第二笔收费。
|
||||
|
||||
采购费用记录沿用 `ll_overseas_procurement_fee`，以 `purpose + fee_item_code + fee_version` 在订单内区分确认版本；原币、汇率、实际 CNY、核定情况和资金身份保存在同一不可变费用版本上。`ll_procurement_wallet_attempt` 按 `fee_id + attempt_no` 和唯一 `command_event_id` 保存每次请求。预估与实际国际运费是独立费用事实，实际费用可引用原预估的资金身份；退款用独立费用业务号引用原成功实扣，不能改写原费用。
|
||||
|
||||
独立新发生费用通过 `fees/additional` 由 `finance-adjust` 权限登记，必须关联已购买订单、本单费用凭证及真实业务日期，以新业务日汇率和独立费用号处理；不覆盖原费用。费用版本记录 `confirmation_origin`（BUSINESS / FINANCIAL），资金重试沿用该入口权限。普通核费首次成功确认后只能引用已有有效版本，新增费用与失败替代由财务入口处理；未交寄时重新确认完整费用清单，已交寄时不改写原履约终态。
|
||||
|
||||
金额在扣款前核对采购台账、钱包和两端费用来源的共同存储边界；费用来源为 DECIMAL(20,6)，单笔原币及 CNY 金额最多 14 位整数、业务输入保留 2 位小数。金额目标快照使用台账范围，正差额仍须满足单笔费用来源范围。购买金额不满足资金链容量时保留真实购买事实并显示待处理，不发起扣款。
|
||||
|
||||
|
||||
单批节点事实由 `ll_procurement_flow` 按采购订单唯一保存；`ll_procurement_command` 保存节点请求摘要、幂等键和内部依据；预算上限变化由 `ll_procurement_budget_authorization` 留存前后金额、币种和客户凭证。购买事实与货款核定标记分开，资金结果仍从费用版本读取。节点 API 见 Lastleg `src/main/resources/openapi/procurement-fulfillment-v1.yaml`，下单与审核基础 API 继续维护在 `overseas-business-v1.yaml`。
|
||||
|
||||
实物明细由 `ll_procurement_receipt`、`ll_procurement_disposition`、`ll_procurement_manifest`、`ll_procurement_carton` 和 `ll_procurement_carton_source` 保存；更正只停用原实收/处置并追加新记录，历史清单及来源不删除。`ll_procurement_shipment` 以订单及运输段建立唯一约束，`ll_procurement_shipment_item` 保存当次逐箱件数、货物来源、测量、面单和运单快照。
|
||||
|
||||
面单版本由 `ll_procurement_label_set` 和 `ll_procurement_label_item` 保存，预估核对通过 `ll_procurement_estimate_review` 显式关联面单版本与有效预估费用。制单不修改资金，贴单不产生发运。每次交寄在订单行锁内复验当前确认清单、全部可寄原箱、实收来源和包装摘要；新面单不继承旧贴单。国内 `ll_procurement_repack` 仅允许原箱的一对一包装新版本，件数仍取原箱有效国内实收；即使新箱尺寸相同，换包装记录也使旧国内面单失效，并清除整单核费确认标记，保留已发生扣款供重新核对。
|
||||
|
||||
国际寄件姓名、电话及地址通过 Warehouse 的既有公共海外收货仓和有效仓详情接口读取，须有唯一作业地址及完整联系人，不由浏览器覆盖。两段交寄各自冻结收寄快照；国内寄件资料承接原国际段国内收件资料，最终客户地址变更须关联本单客户确认凭证。面单文件按本单 LABEL 分类校验，图片仅对应第 1 页，PDF 明确逐箱页码。
|
||||
|
||||
运输动作权限独立采用 `estimate`、`apply-label`、`ship-overseas` 和 `ship-customer`；`label` 只维护面单，不能同时获得冻结或交寄权限。上述权限均在既有采购权限前缀下，沿用现有平台角色，不引入新岗位类型。
|
||||
|
||||
Finance 账户操作统一按“客户账户行 → 原冻结/原扣款行”顺序加锁。结算实际金额保留原冻结金额，实际扣款取关联的 CONSUMPTION 流水；退款用独立 REFUND 流水引用原扣款，不能篡改原结算状态或使用充值类型。退款回补复用现行现金/授信归还计算，不恢复过期授信。
|
||||
|
||||
### 10.2 资金指令和来源合同
|
||||
|
||||
- `FREEZE` 预留金额；`SETTLE` 结清明确实际费用的全额冻结；`RELEASE` 释放有效冻结。
|
||||
- `SETTLE_ACTUAL` 在原冻结业务身份上携带最终正额 CNY 金额，在 Finance 单事务中补差或释放余款。结果 amount 表示实际扣款，不能回传原预估。零实际费用使用 RELEASE。
|
||||
- 正额货款、关税、国内运费和其他费用，由采购按费用用途在 FREEZE 成功后自动发送 SETTLE；预估国际运费绝不走该自动分支。
|
||||
- 资金成功回执必须能定位原请求、客户、费用版本及实际流水；费用入池引用这笔已成功的资金事实，Finance 同客户校验实际金额后标为已结算。不得仅凭展示单号或预估金额认领资金。
|
||||
- 退款业务命令需包含原成功扣款引用、独立退款编号、金额、原因和授权证据。相同退款编号换请求键不得再次回补，累计退款按原扣款串行核验。
|
||||
- 已确认费用的资金请求状态与费用来源状态分开。节点准入同时检查资金终态和来源关联，不以 Outbox 已发送或 HTTP 已确认作为全部完成。
|
||||
|
||||
国内核费以整单节点命令确认：实际国际运费、关税、国内运费分别选择新核定值或本单已有有效费用版本；其他费用明确为不适用或逐项核定。不适用不创建虚构收费行，重新核对引用原版本不重新扣款，也不能通过省略有效费用隐藏原收费。确认时间与实际资金完成状态分别保存，寄客户仍逐笔校验资金及来源关联。
|
||||
|
||||
费用链更正使用 `ll_procurement_fee_correction` 保存正确原币总额、原汇率及月份、目标 CNY、确认前净实扣和差额，`ll_procurement_fee_correction_item` 关联本次产生的每笔追加或退款。输入必须是原实际费用链根；同链存在未决或尚可重试的旧调整时拒绝新目标。正差额建立独立 CNY 费用，差额费用自身汇率为 1，目标原币及原汇率完整保留在更正快照，避免由人民币分差反推原币造成误差；负差额按本链成功消费的可退余额逐笔关联，不把多次扣款合成一笔虚构原扣。退款仍由 Finance 原子校验累计上限。
|
||||
|
||||
未实扣费用的替代核定使用独立 `fees/{feeId}/replace-failed` 命令，要求财务调整权限。仅最新实际费用版本已明确失败、终止重试且有效冻结已释放时可替代；未决、已实扣或已有后续版本均拒绝。新费用沿用原币、业务日及汇率快照，以新的资金业务标识扣款，并由更正记录关联前后版本；原购买事实不覆盖，替代货款仍核验客户预算。普通核费不能绕过该入口重建历史费用，财务替代版本的失败重试也使用财务调整权限。
|
||||
|
||||
普通核费权限不能追加或退款。明确失败后的重试按原费用用途分别检查购买、预估、核费或财务调整权限；终止失败版本、目标更正及退款统一要求财务调整权限。所有命令明确携带订单版本及幂等键；缺失版本拒绝，原请求重放不能改变金额。履约已寄客户或异常关闭后，有据财务更正保留原终态，不改写历史发运。
|
||||
|
||||
### 10.3 服务和接口组织
|
||||
|
||||
Lastleg 在现有 `procurement/` 内按购买、实收装箱、运输、费用、文件及异常划分职责；统一订单查询组装详情和动作资格，不新建服务或通用流程引擎。Finance 只处理本服务账务与来源关联；采购不能直接写 Finance 数据表。
|
||||
|
||||
采购列表只返回订单基础信息、采购数量和履约状态，不返回旧 `inboundQuantity/outboundQuantity/inventoryQuantity` 库存式统计。删除旧 `outboundDetails` 及订单级两段承运商/运单字段；实际承运商、运单、交寄数量与时间从逐箱面单和不可变交寄记录查询，不由旧 JSON 或静态订单字段推导。初始化结构与模型同步移除这些废弃字段，实际环境结构清理由发布范围单独核对。
|
||||
|
||||
沿用现有平台和客户采购 API 根路径。新增操作使用明确节点命令，包含确认购买、登记/完成实收、保存/确认清单、面单维护、预估确认、贴单、两段交寄、核费、预算授权、更正及关闭。通用 PATCH 移除能绕过这些命令修改数量、运单、状态和资金的字段；不保留旧编辑行为回退。
|
||||
|
||||
平台详情返回服务端计算的 `actions` 与动作阻断原因，以及采购事实、箱明细、费用版本和历史。客户端使用单独的详情 DTO，仅返回第 3.5 节允许的字段，不透传平台附件、内部备注或原始资金错误。内部 ID 只用于程序关联，用户界面以采购单号、箱号、运单及费用业务编号展示。
|
||||
|
||||
Admin 采购保留当前独立列表/详情/编辑路由，具体操作承载按适用原型核对；Client 将采购专有详情和下单逻辑从三类业务共用组件中分离，本土卡车和散板不接受采购新增状态或字段。权限按第 5.1 节逐动作同步 Controller、IAM 种子、API 合同与前端。
|
||||
|
||||
异常控制保存在 `ll_procurement_control_note`：更正说明关联本单购买、实际仓、实收或交寄对象及 EXCEPTION 凭证，阻断与解除分别记录，不覆盖原说明。实际仓在已有箱明细前可受控更正当前有效仓，并保留原仓快照及原实收；已有后续实物或已结束时只追加说明和阻断，不能将货物重新归属。真实到货仍可记录，正式装箱、预估、核费和交寄校验未处理阻断。
|
||||
|
||||
异常关闭由 `ll_procurement_closure` 与 `ll_procurement_closure_item` 留存客户停止履约凭证、财务结论、对客摘要和每份剩余货物的去向。服务端按购买未达、原国际箱在途未达、有效实收合格/破损/多货计算待处理来源，扣除既有有效差异处置；已国际交寄的海外合格实收不再重复计为剩余货物。提交须逐来源足额覆盖且有证据，全部资金及来源关联处理结束后才能关闭。关闭不改变原购买、收货、交寄或资金事实，不新建退款、退货物流或零数量发运。
|
||||
|
||||
平台既有采购详情 GET 返回 `ProcurementQueryService.PlatformView`，聚合客户视图、内部购买事实、实收装箱、运输、费用/更正、异常、文件、操作记录及动作资格，页面无需逐块发起详情请求。交寄按钮的阻断原因复用实际交寄的状态校验；所有写入仍在订单锁内重新校验，详情上的可执行状态不能替代提交门禁。客户既有详情及创建响应使用独立 `CustomerView`，不再从平台详情动态删字段：只输出已确认箱明细、两段实际运单、预算/费用结果和专门填写的对客摘要，不返回内部附件、原始异常说明、审计内容和资金引用/诊断。
|
||||
|
||||
平台运输快照分别返回 `overseasCargo` 和 `domesticCargo`：前者为海外清单及原实收分配，后者按国内有效合格实收计算件数并使用最新一对一换包装的箱规、重量和包装记录引用。面单与交寄页面使用该权威结果；不能从海外旧箱规或采购总数推定国内可寄货物。客户 DTO 仍使用独立允许字段，不透传内部来源引用。
|
||||
|
||||
### 10.4 开发与验收顺序
|
||||
|
||||
1. Finance 原子实际结算、原扣款退款、费用来源资金关联及其事务测试。
|
||||
2. 采购数据结构和命令合同，下单、审核、预算授权、购买与货款闭环。
|
||||
3. 海外分次实收、差异、装箱版本、面单和预估冻结、贴单与整批交寄。
|
||||
4. 国内分次实收、换包装、费用核定、实际结算和寄客户。
|
||||
5. 受控更正、追加、退款、取消和异常关闭；客户端全节点和费用展示。
|
||||
6. 全链路定向回归、API/权限/Mapper/SQL 合同检查，匹配版本部署后执行真实 HTTP 和两端页面验收。
|
||||
|
||||
各节点同时交付服务端行为、Admin 操作、Client 展示及直接受影响测试，不以“接口存在”代替完整操作。资金基础测试应覆盖账户、冻结、流水、审计及幂等记录同事务回滚，以及不同请求并发处理同一冻结/原扣款。
|
||||
|
||||
页面验收使用 1920×1080、100% 缩放。列表和详情按实际 Network 记录请求数：检查重复加载、逐行附加请求、重复提交、无限重试和资金处理中无界轮询；以具体页面操作和请求证据判断，不臆定所有页面统一的请求上限。本轮用户已明确授权内置浏览器登录并自动检查样式与交互，适用于本次采购流程验收。
|
||||
|
||||
|
||||
### 10.5 客户端页面实施核对矩阵
|
||||
|
||||
本次页面依据为本需求第 3、5、10.3 节和现有正式路由。客户端栏目原型 `docs/悦/柏悦物流客户端/柏悦物流客户端-栏目架构图.html:977` 只定义“海外采购”业务入口，未定义新履约字段布局；不能据此宣称已有完整页面原型。按本轮“首版简单、后续可扩展”的开发授权，保留已确认独立页面承载及现有工作台视觉，扩展本次业务分区，不新增客户审批或内部文件入口。
|
||||
|
||||
| 页面 | 操作 | 原型/当前确认依据 | 当前实现与承载 | 本次结论 |
|
||||
|---|---|---|---|---|
|
||||
| 采购列表 | 查询、分页、进入详情 | 栏目原型行 977；`cross-border/routes.ts` 的采购列表及详情路由 | 共用 `BusinessOrdersView.vue` 的 QueryToolbar、DataTable，操作列在左 | 保留表格和查询布局；使用采购履约状态，去除采购库存含义的旧展示；详情通过正式路由打开 |
|
||||
| 采购新建 | 新增、提交、取消 | 需求第 3.2、3.5、10.3 节；`cross-border/routes.ts` 的 `cross-border/procurement/create` | 已有独立新建路由，旧共用列表又能切换内部新建模式 | 统一由既有独立新建路由承载；明确单商品、预算和最终收件资料，白底分组表单，桌面短字段三列；取消返回列表 |
|
||||
| 采购详情 | 查看、刷新、返回 | 需求第 3.5、5.2、10.3 节；既有 `cross-border/procurement/:orderNo/detail` | 独立页面、返回列表、状态及四列描述网格 | 沿用独立页面及四列资料区；增加节点时间、已确认箱清单、两段实际运单、费用及对客异常摘要；每次加载一个聚合详情请求，不自动轮询 |
|
||||
| 采购详情 | 编辑、审核、核费确认、取消订单、文件预览/下载 | 需求第 3.4、3.5、5.1 节 | 客户本次无对应平台操作权限 | 不新增；客户通过客服提出变更或取消，不开放内部面单、采购/费用/沟通凭证 |
|
||||
|
||||
新页面按 1920×1080、100% 缩放核对。该矩阵是实施依据，不代表已经完成运行环境视觉或交互验收。
|
||||
|
||||
|
||||
### 10.6 平台页面实施核对矩阵
|
||||
|
||||
按本轮用户“先修正偏移项”的要求，采购详情首屏只展示当前有权限且可执行的常规履约操作；预算/仓库更正、财务调整、取消及异常处理收纳在“更正、财务及异常处理”分组，费用更正草稿也在该组。其他不可执行的常规节点以可展开的节点及原因列表保留，不铺满首屏禁用按钮。原请求未决提示与原请求恢复入口仍直接显示，不因折叠分组隐藏；服务端资格、权限及业务门禁不变。
|
||||
|
||||
平台原型定向入口为 `docs/悦/货代SAAS平台后台/prototype-src/modules/07-overseas-business.html`，其中采购列表及独立编辑页承载保留；旧原型中的数量、运单和费用通用编辑方式按本需求第 3、4、5、10.3 节收敛。新增节点采用现有详情页内分区及独立操作弹框，沿用 Admin 高密度公共样式，不将原型旧字段当作新节点操作的授权。
|
||||
|
||||
| 页面 | 操作 | 承载与变更边界 |
|
||||
|---|---|---|
|
||||
| 采购列表 | 查询、分页、查看、编辑 | 保留列表及独立路由；操作列在左，使用实际履约状态；不将采购台账展示为 WMS 可用库存 |
|
||||
| 采购独立编辑 | 维护内部备注、保存、取消 | 保留独立编辑页、三列只读订单摘要及备注区；只提交订单版本和内部备注，保留未保存保护及版本冲突提示；不在此修改购买对象、仓库、数量、箱单或运单 |
|
||||
| 采购详情 | 查看、刷新、返回 | 单次聚合详情请求，分区显示订单、履约、费用、文件及内部历史；不自动无界轮询 |
|
||||
| 采购详情 | 审核、购买、预算授权、取消 | 各自独立操作弹框；审核通过必须选择有效海外收货仓，真实购买和资金确认分开呈现 |
|
||||
| 采购详情 | 分次收货、差异处置、完成收货、装箱、换包装 | 节点弹框配结构化明细表，显示原实收或原箱来源；不使用自由 JSON 输入，不将保存等同节点完成 |
|
||||
| 采购详情 | 面单、预估核对、贴单、两段交寄 | 面单逐箱关联；预估冻结、贴单、实际交寄独立提交，展示服务端阻断原因；文件使用受控上传和下载 |
|
||||
| 采购详情 | 国内核费、重试、费用更正、退款 | 普通核费和财务调整分别控制权限，逐项展示核定值、冻结、实扣及来源关联；待处理资金不能显示已结清 |
|
||||
| 采购详情 | 更正说明、解除阻断、异常关闭 | 保留原事实，以来源、凭证和去向形成结构化记录；关闭前明确实物与资金处理结果 |
|
||||
|
||||
以上为页面实施边界，不表示各操作已经开发、部署或通过浏览器验收；运行验收仍按第 10.4 节逐项核对。
|
||||
+80
@@ -1,5 +1,85 @@
|
||||
# 测试环境独立任务协作登记
|
||||
|
||||
## 2026-10-13 用户指定的数量对照临时验证
|
||||
|
||||
用户明确指定已自行创建的 `01a135d0-f5c7-7422-892f-037b0c9ea00e`（开启新对话）处理列表量／预报量／实际量验证，在不影响现有采集的前提下开发。保存项目 TEST `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host local、cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`；本次只登记既有对话的一次性范围，不创建长期专项或新对话。采集整体协调仍归当前总控 `01a13496-1713-7ac3-9981-1ae9ed551571`。
|
||||
|
||||
该对话唯一维护本次 Integration 有界数量对照组件、列表／详情白名单观察触点及直接测试；先核对现有未提交内容，不改其他专项冻结的 Egress/Gate、持续采集、共享 SQL、发布和运行脚本。若触点涉及仍在写入的文件或扩大 DTO/OpenAPI 合同，先列出精确冲突和最小范围，由用户／总控协调后再写，不覆盖他人修改。当前明确授权的是本次开发及只读状态核对，不解除其他对话的暂停，不自动恢复采集、部署或发起新的历史扫描。方案维护对话继续维护文档，详细保护条件和验收见 `自营业务/领星WMS接口联调手册.md` 的“数量对照验证的采集保护与开发交接”。
|
||||
|
||||
## 2026-10-13 持续自动采集批次（当前精确写权）
|
||||
|
||||
用户指定复用四个既有独立对话，唯一总控为 `01a13496-1713-7ac3-9981-1ae9ed551571`，仅负责调度、协调、验收收口与发布安排；禁止新增内部子代理。保存项目为 TEST `c64729ff-6710-43c6-8ef2-d84e9666cc1e`，cwd 为 `C:/Users/BY-OY/Desktop/code/chongchong-global`，保持当前分支。以下范围覆盖旧内部代理和历史临时写权，所有内部代理已停止；已有修改由对应独立专项接管，不创建新对话、分支或 worktree。
|
||||
|
||||
| 执行对话 | 本批唯一写入范围与交付 |
|
||||
| --- | --- |
|
||||
| 采集专项 `01a12f3f-c971-7b62-a0bb-dbdddb091990` | Lastleg 自营 `sync/`、Planner/TaskService/Execution/Discovery、CollectionPolicy/AnalyticsProperties、BusinessBudget、CoordinationMapper 及直接测试；持久完整日任务池、每日计划、断点续跑与去重 |
|
||||
| 接口专项 `01a12f3f-c57a-79e1-9efa-9401f594544c` | Lastleg Egress、Integration EgressProperties/Gate 及直接测试；配对持续 BUSINESS 开关、短 permit 与真实出口保护 |
|
||||
| 指标专项 `01a12f3f-ce73-75d2-8fe3-23d709c755d5` | Collection 查询/OpenAPI、StageEstimate/ProgressProjection、Admin 采集展示及直接测试；前端测试由该专项独占执行 |
|
||||
| 原总控 `01a12f38-d28c-75c0-bc1a-dfb27e7a4961` | 本批登记、一期方案自动化契约、两服务 application.yml 开关默认 false、target 下新 continuous 发布/配置/验收脚本与脱敏清单；三个专项差异只读审查，代码冻结且编译就绪经总控确认后串行执行共享 Maven |
|
||||
|
||||
### 已正式派工的下一批：库存周转
|
||||
|
||||
库存周转已派给指标专项 `01a12f3f-ce73-75d2-8fe3-23d709c755d5`，按 `docs/自营业务/库存周转视图设计.md` 在本批持续自动采集收口后实施，不再仅记录为收到方案。该专项唯一维护只读 `inventory-turnover` 接口及 Admin 库存分析默认 TURNOVER/SKU、OWNER 汇总、7/15/30 同屏和原 DETAIL 严格入口及直接测试。采集专项 c971 只读核对每日库存代表和 continuous 库存计划资格，不改写或补造历史样本；原总控维护独立验收清单并安排串行后端回归。库存周转未完成不阻断本批持续采集启用；两批文件输入和验证证据分别冻结，后续改动不覆盖已审持续采集输入。
|
||||
|
||||
当前精确阶段门禁：总控已确认本批 Admin 固定候选 `4c4a3db1ebc277b2462a2e93c3e597ea86df36ae`，ce73 获准接续库存周转仅前端实现；周转后端新源码/OpenAPI 暂不写入，待持续版后端集成收口后再解锁。本批 Admin 验证/发布必须绑定该固定提交，不能取已接续下一批的 workspace HEAD。c971 本批覆盖修复将通过 run.scope_snapshot_json 冻结完整区间集合并同步直接查询消费者；其扩大文件范围以总控下一次精确写权与冻结清单为准，原总控重审后再串行回归。
|
||||
|
||||
目标为北京时间最近两个月全部完整日（首次 2026-08-13 至 2026-10-12）进入服务端持久任务池，每日 00:05 补前一完整日并优先，历史近到远；跨夜运行不依赖本机队列。运行事实、已验证与未关闭项只维护正式部署契约。现有 cutover/queue/helper 只读，不修改运行脚本、不擅自停止进程；新 continuous 发布须先核对旧 cutover 状态和自然日完成边界。环境操作、SQL、Nacos、部署及提交等总控具体指令；真实只读核验先报范围。本批交付在各自对话回复，由总控读取，不自动跨对话回信。
|
||||
|
||||
2026-10-13 用户明确要求接管“平台销售总控”：当前唯一总控改为 `01a13496-1713-7ac3-9981-1ae9ed551571`，接替 `01a12feb-0474-77f1-afe0-a3b491733dca`。继续使用本 TEST 工作区、既有专项与原文件边界；本轮集成及发布由当前总控串行执行，既有专项已停止写入。独立完整日修复包暂不实施，待后续精确派工；不创建新长期对话。运行事实只记入正式部署契约。
|
||||
|
||||
2026-10-13 17:22 总控追加12日独立完整日修复包：采集专项c971独占 AnalyticsReadMapper/AnalyticsReadRows、AnalyticsQueryService/AnalyticsSqlRequest/AnalyticsReadSql、SalesBucketPolicy、DashboardSalesPolicy/DashboardQueryService及直接测试与最小共用覆盖值对象；此精确范围临时覆盖原指标查询长期归属。指标专项ce73仍独占本轮采集前端，不写上述后端文件。内部inventory_daily仅审查版本覆盖证明不可变性，owner_query仅维护target下既有发布helper与离线测试；环境、共享文档、Maven、集成提交和发布仍由总控执行。采集保持OFF，不续11日。
|
||||
|
||||
2026-10-13 16:43 用户在指标专项窗口补充“单领星账号运行看板”最新页面要求。发现该窗口与内部frontend在采集页面发生并行写入，内部frontend已停止全部写入/测试并交接；采集前端CollectionView、进度组件、相关types/tests和操作矩阵唯一写权转交指标专项ce73，取代下段内部frontend独占安排。总控停止基于混合输入发布，待唯一写者统一新需求、冻结后再测试构建。
|
||||
|
||||
2026-10-13 用户再次明确要求复用以下四个窗口推进采集页改版。本批精确写权覆盖旧临时包：指标专项唯一维护 CollectionResponses/CollectionReadRows/CollectionReadMapper/CollectionQueryService、自营 OpenAPI 与直接查询测试；采集专项接管内部代理已停止的 SelfopStageEstimate/SelfopProgressProjection/SelfopDiscoveryService、直接测试及 SelfopEgressMapper 终态摘要触点；接口专项只读核查官方仓库筛选和重复请求/额外等待；原总控只读准备发布及续采清单。内部 frontend 唯一维护采集页及其组件/API类型/测试/操作矩阵；内部 owner_query、inventory_daily 已停止写入并完成交接。共享合同由新总控协调，Maven、提交和发布仍由新总控串行收口，当前运行根不因页面开发被重启中断。
|
||||
|
||||
## 2026-10-12 平台销量统计长期开发分工
|
||||
|
||||
本轮用户授权复用四个既有对话并行收口 Lastleg 全服务依赖门禁，临时覆盖下文旧修复包：指标专项独占预约来源与入仓包循环涉及的 `appointmentplanning/`、`inboundplan/` 和根 `service/` 直接相关类（排除 `ReturnOrderReferenceResolver`）；采集专项独占 `fleet/` 包循环及车队反向依赖修复、必要的 `delivery/` 适配器；接口专项负责 `export/` 导出组合依赖审查与直接测试；原总控负责 `ReturnRelabelPackingService`、`WarehouseTransferReceiptCoordinator`、`ReturnOrderReferenceResolver` 三处边界及必要本域适配器，并只读核对发布清单。每包包含直接调用测试，跨写权先交新总控协调。新总控唯一维护依赖分析器、架构 JSON 基线、共享文档并串行执行 Maven。不得以通配许可或循环豁免消除失败；不新增长期任务，不授权环境操作。
|
||||
|
||||
2026-10-12 用户明确授权总控接管：本节唯一当前总控改为 `01a12feb-0474-77f1-afe0-a3b491733dca`（当前接管对话），原“平台销售总控” `01a12f38-d28c-75c0-bc1a-dfb27e7a4961` 仅保留历史交接记录。以下三个长期专项和方案维护者继续复用，已有文件归属与环境操作限制不变；共享文件集成和 Maven 窗口由新总控协调，不新增用户可见任务。
|
||||
|
||||
用户随后明确授权上述三个专项及原总控作为当前总控的下级任务继续派工。本次原总控负责发布清单与配置的只读复核，不再承担调度；指标专项复核查询上下文和隔离，采集专项复核调度/恢复前置，接口专项复核预算与出口安全。当前新增经营查询、日库存代表和前端实现分别由新总控的独占内部工作包维护，四个既有对话在收到精确写入权移交前只读，不沿旧派工并行改写。所有 Maven 和共享文件仍由新总控统一收口。
|
||||
|
||||
上述复核后的定向修复写权：接口专项独占 `client/RestLingxingAnalyticsClient.java`、`request/SelfopEgressService.java` 及直接测试；采集专项独占 `sync/SelfopValidationRunner.java`、`SelfopExecutionService.java`、`SelfopTaskService.java`、`SelfopSchedulePlanner.java` 及直接测试。经营查询由内部工作包统一实现，指标专项只读复核，不重复写入；日代表 `inventory/`、`model/SelfopSyncRun.java`、`mapper/SelfopSyncRunMapper.java` 由内部工作包维护。新总控保留 `query/Collection*`、`retention/`、共享 SQL、配置集成和最终门禁。
|
||||
|
||||
用户此前明确确认新增以下三个开发对话；创建时所属总控为“平台销售-开发” / `01a12f38-d28c-75c0-bc1a-dfb27e7a4961`，当前归属以上述接管记录为准。保存项目为测试环境 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`，host `local`，cwd `C:/Users/BY-OY/Desktop/code/chongchong-global`；不得跨到开发环境项目。创建阶段仅准备并等待明确开发派工，不因创建自动开始编码、构建、API 调用或环境操作；后续开发授权见下段。
|
||||
|
||||
已有文档规划对话“平台销量统计” / `01a12ec3-b0a3-7e81-ab61-fbf9d9a183da` 保留方案及联调依据维护职责。业务输入以 `自营业务/README.md`、`自营业务/领星一件代发数据统计一期方案.md`、`自营业务/领星WMS接口联调手册.md` 和适用项目/模块指引为准；本轮用户经方案对话明确移交开发，一期包含后端任务、事实、统计、平台查询与受控重试 API，以及 Admin 销量分析、库存分析、数据采集三个入口。业务告警与补货另行确认。
|
||||
|
||||
用户后续明确授权按最新两份主文档继续开发、集成与离线验收，完成源码、SQL 基线文件、接口和权限合同；这覆盖创建时的等待开发要求。主设计文档继续由原规划对话维护，不并行覆盖。源及业务时区已确认 `Asia/Shanghai`，数量为每个 SKU 的件数 `PCS`，唯一账号、全部授权货主、按仓独立采集；已观测货主数量不成为硬编码上限。正式首采固定两个滚动月，生产独占账号；本轮只实现 `OFF/VALIDATION/BUSINESS`、持久会话预算和隔离，真实出口与发布默认关闭。不执行 SQL、不部署、不触发 Jenkins、不启动真实采集或发布、不读取凭据、不调用真实 HTTP、不自行 Git 提交或创建分支/worktree。总控唯一维护共享 SQL、IAM、Gateway、Admin 导航/根路由和公共门禁；前端模块可交独占内部子代理，不创建额外用户对话。真实启用和人工视觉验收另按现行主方案及工程门禁处理。
|
||||
|
||||
| task_id | 对话 | 唯一长期职责及文件边界 |
|
||||
| --- | --- | --- |
|
||||
| `01a12f3f-c57a-79e1-9efa-9401f594544c` | 平台销量｜领星接口适配 | Integration 领星 WMS 单页/单单接口、DTO、签名和账号配额能力、内部鉴权、本服务 OpenAPI 及直接测试；补仓库目录、出库摘要/详情/按单定位、产品库存。多页采集与完成性判断归采集专项，Lastleg 调用方由采集专项维护。 |
|
||||
| `01a12f3f-c971-7b62-a0bb-dbdddb091990` | 平台销量｜采集与数据发布 | Lastleg 自营分析采集和发布写链，账号发现、分仓任务、共享持久化模型及写 Mapper、租约栅栏、暂存事实、修订、库存快照、覆盖证明、候选日事实/profile、版本发布、恢复、调度和人工任务命令及直接测试；SQL 结构需求交总控集成。 |
|
||||
| `01a12f3f-ce73-75d2-8fe3-23d709c755d5` | 平台销量｜指标与查询接口 | Lastleg 自营分析只读指标和查询，日销量、7/30 天、Top 100、可售天数、数据质量/时效、固定版本分页，查询 Controller/DTO/只读 Mapper、OpenAPI、权限校验及直接测试；只消费已发布版本，不修改共享持久化模型或写入/发布链。 |
|
||||
|
||||
开发前由总控明确包/文件归属和共享 DTO、版本及只读接口合同；两个 Lastleg 专项不得交叉修改共享模型和 Mapper。共享 SQL 基线、权限种子、Gateway、导航/根路由、主契约和集成提交由总控统一协调。文档规划对话的现有来源核验不因本次创建改变授权，开发专项不能自动复用其真实 API 授权。
|
||||
|
||||
本轮用户进一步明确要求拆分现有重包并发收口，复用上述三个对话，不新增用户可见任务。临时文件写入权覆盖下表原本轮边界：接口适配对话接管 Lastleg `selfoperated/analytics/request/` 及直接测试，完成出口许可、验证预算和冷却回调；指标查询对话接管 `outbound/OutboundCandidateBuilder.java`、`OutboundCandidateTransaction.java`、`OutboundAggregateMapper.java`、`retention/` 及对应直接测试，完成有界候选构建、覆盖聚合和版本引用保护；采集对话保留 `client/`、`sync/`、中立 `model/`、原持久模型/写 Mapper、`inventory/`，以及 `outbound/OutboundFactService.java`、`OutboundPolicy.java`、`OutboundLockMapper.java` 和直接测试。移交区域原写入者停止修改后才释放新写入者；跨包签名和模型变化交总控协调，Maven 由总控串行执行。该临时收口分工不放开环境操作或 Git 提交，不扩展长期职责和创建授权。
|
||||
|
||||
所有专项保持当前分支当前工作区，不创建分支/worktree、不覆盖他人改动、不使用共享 Git 索引自行提交；Maven/全量构建窗口由总控协调。此次创建不授权 SQL、数据库写入、部署、发布或真实 HTTP 验收；正式启用仍按一期方案逐仓核验。专项按精确派工交付，结果由总控只读收取，不自动跨对话回信或创建额外对话/持续目标。
|
||||
|
||||
## 2026-10-10 采购、拼车与预约的统一页面验收
|
||||
|
||||
2026-10-11用户新增并指定浏览器验收对话 `01a12ae6-c6d8-7331-8f26-4d4009f873bc` 加速本轮验收；已核对 cwd 为本测试工作区，归采购总控 `01a12033-95f3-7073-a74a-ef681e7ac470` 协调。新对话第一包仅采购 Client 页面与请求量，使用自己创建的 Client 标签，1920×1080；采购总控继续 Admin 预约/拼车。此次明确分工覆盖下面原“总控独占全部内置浏览器”的范围，仅放开新对话 Client 标签，不放开其 Admin 登录、共享标签、Cookie/storage 清理或全局视口变化。浏览器独立性须实际核对，未证明前按共享会话管理；PDA 390×848 待单独移交视口窗口。新对话只维护 `baiyue-firstleg/reports/client-parallel-acceptance-20261011/` 证据，不改共享进度、主契约、生产代码或触发发布。原拼车/预约开发对话仍不操作浏览器。
|
||||
|
||||
该新验收对话第二包获总控移交 PDA 390×848 视口操作窗口，限本轮关联的国内任务详情及海外转运收货/测量作业页；总控窗口期间不操作浏览器，完成后恢复1920×1080。复用根已确认连接TEST的两条本地H5服务，不接管原HBuilder服务、不新增发布；进入页面若必须推进任务，先交最小合成样本准备要求，不领取无关任务。证据仍写其专用目录下 `pda/`，业务代码和共享主契约保持总控协调。
|
||||
|
||||
用户明确授权复用以下三个既有对话，由“采购订单-开发”统一安排页面验收，并向另外两个对话发送协调指令。本节仅约束这三个业务的本轮协作，不创建新对话，不扩大环境授权，不改变其他专项的代码归属。
|
||||
|
||||
| task_id | 对话 | 本轮职责 |
|
||||
| --- | --- | --- |
|
||||
| `01a12033-95f3-7073-a74a-ef681e7ac470` | 采购订单-开发 | 统一页面验收协调；独占内置浏览器，负责三项业务的页面操作、身份切换、请求及截图取证，复核交付并协调发布窗口。 |
|
||||
| `01a11999-5e90-75c3-9004-9bda35b92ced` | 拼车需求-开发 | 保留拼车业务实现、定向测试和独立会话HTTP验收；交付剩余页面检查清单、样本和证据，修复统一页面验收发现的本业务问题。 |
|
||||
| `01a11b99-6f9e-7a72-9d91-bdbd5cea051f` | 预约列表-开发 | 保留预约业务实现、日历来源接入、定向测试和独立会话HTTP验收；交付页面检查清单、样本及就绪条件，修复本业务问题。 |
|
||||
|
||||
- 页面操作权移交时须确认无在途浏览器调用。拼车及预约对话不再开关标签页、登录、退出、切换账号或清理浏览器数据；交接时也不额外退出共享登录。
|
||||
- 其他两项可继续不干扰验收样本和账号权限的开发、测试及独立会话HTTP操作。共享文件、构建产物及同一应用/服务的部署仍须协调；部署需求先交统一验收方确认窗口，避免中途改变验收版本。
|
||||
- 凭据只引用私有环境变量键名，不在交接消息或证据中复制密码、Token。验收方默认使用新增管理员账号2的专用变量；其他对话不修改其权限或采购验收样本。
|
||||
- 交接清单在原对话回复，由统一验收方只读收取；不因收到跨对话消息自行向其他对话回发消息。仅复用已有成果并补齐缺口，运行版本、已验证场景和未关闭项维护在两份正式主契约中。
|
||||
|
||||
## 2026-10-04 用户确认的三个独立执行对话（当前派工）
|
||||
|
||||
用户明确选择“按这 3 个独立对话创建”。所属唯一总控仍为 `退税报关` / `01a0d0da-130f-7d43-97b5-9c76abc1b5f1`；本次三个对话不各自建立持续目标。已核对保存项目 `c64729ff-6710-43c6-8ef2-d84e9666cc1e`、host `local` 与 cwd `C:/Users/BY-OY/Desktop/code/chongchong-global` 一致。旧对话保持原状态，不恢复或唤醒。下表为本轮分阶段执行分工，不新增永久专项。
|
||||
|
||||
+1
-1
@@ -88,7 +88,7 @@
|
||||
- 客户订单首页使用 `GET /api/merchant/v1/orders/workbench`，客户范围只取认证上下文，权限为 `merchant:order:list`。接口一次返回当前页、筛选后总数、全部/待费用确认/装柜完成/已报关/已清关/已排车/派送中/派送完成/待上传报关资料/草稿十项数量及该客户完整渠道名称选项；不能先取前 200 条再在浏览器分页或统计。
|
||||
- Order 在数据库内应用入仓码或 SKU、收货仓、渠道、目的仓类型、快递单号、创建时间、当前状态及待办筛选。草稿排在前面，同组按创建时间和订单 ID 倒序稳定分页；默认每页 10 条，上限 200 条。`DRAFT/CANCELLED` 是订单交易状态在客户读模型中的直接展示，不新增履约推进节点；默认列表排除已取消单。
|
||||
- Firstleg 通过受内部服务令牌保护的 `/internal/firstleg/v1/inbounds/unified-orders/workbench-filters` 提供当前客户匹配的履约和待办订单范围。费用待确认只取最新费用版本的未确认 `SENT`；报关待上传取最新已完成装柜计划、有效货柜及尚未上传齐当前客户退税入仓码资料的范围，不受同柜其他客户未上传影响。查询不创建报关记录、不更改船或柜、不跨 Schema 读表。
|
||||
- 翻页、换每页数量和筛选均重新请求服务端；快速切换时旧响应不得覆盖新页。筛选数量随当前条件计算，资料或费用确认后重新读取。分页响应不完整或依赖服务失败时明确报错，不能回退旧查询或显示成功的空列表。
|
||||
- 切换分类和刷新期间保留上次已确认的分类数量，最新响应完整校验后统一替换，避免数量先归零再恢复；请求失败明确报错并清除失效数量。重复点击当前分类不重发请求或重置页码，错误态允许点击重试。翻页、换每页数量和筛选均重新请求服务端；快速切换时旧响应不得覆盖新页。筛选数量随当前条件计算，资料或费用确认后重新读取。分页响应不完整或依赖服务失败时明确报错，不能回退旧查询或显示成功的空列表。
|
||||
|
||||
### 客户头程订单履约分类
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# 统一认证与服务通信契约
|
||||
|
||||
2026-10-12 自营统计 TEST 身份验收进行中：六项权限及平台管理员关联已落库；独立最小只读平台身份可以查询、不能提交采集命令，无权限平台身份被 A0403 拒绝，客户身份不能进入平台统计域，匿名请求为 401/A0401。平台管理员在采集 OFF 时收到中文业务拒绝 B0001，未新增任务；内部调用无令牌被 A0401 拒绝，Lastleg 出口预算授权在 OFF 时被 `EGRESS_MODE_REJECTED` 拒绝。首轮业务查询验收脚本的六项错误已按正式合同修正，r2 完整 Gateway 矩阵 86/86 通过；这只证明合成查询和当前身份边界，不外推为真实来源、性能、发布恢复及人工页面验收。发布版本、合成数据边界及未关闭项统一见测试环境主契约“自营统计 TEST 发布与验收”节。
|
||||
|
||||
2026-10-08 TEST回归后灰度发布、10月9日恢复核对：灰度IAM #10更新至 `d4eb0ef0233c`，权限5107004与唯一关联主体授权版本按现行契约同事务同步，未改角色授权；新会话的废弃审批及八类导出所需权限均核对通过，正式HTTP验收后已退出。六部署目标与17容器健康、TEST故障恢复证据、灰度验收边界详见测试环境主契约“TEST 回归后灰度发布”节；不能将运行健康或接口冒烟外推为灰度全流程及真机均已验证。
|
||||
|
||||
2026-10-08 TEST 汇总发布补记：IAM #176部署 `6b6d217774be`。废弃审批权限5107004及精确两个关联主体授权版本已同事务按当前合同同步，未扩大角色授权；新登录权限集合已包含现行 `platform:overseas-warehouse:discard:approve`，验证会话正常退出，旧会话需重新登录。发布范围、版本和非全量验收边界以测试环境主契约“当前代码汇总 TEST 发布”节为准。
|
||||
@@ -109,6 +111,33 @@
|
||||
|
||||
特别约定：资金指令的投递成功不等于冻结/扣款成功。Finance 必须可靠保存 SUCCEEDED 或 FAILED 业务结果及结果 Outbox 后确认该指令已消费，Lastleg 以 `WalletCommandCompleted` 更新业务状态。余额不足等已形成 FAILED 结果的指令不进行无意义的传输重试；成功扣款后结果发送失败，只重试原结果事件，不能再次生成扣款指令。
|
||||
|
||||
采购资金合同扩展：`SETTLE_ACTUAL` 携带最终正额 CNY 金额，在原冻结身份上原子补差或释放余款，原冻结金额保持不变；实际零元使用 `RELEASE`。`REFUND` 必须携带 `originalLedgerId`，以独立退款业务号关联原成功消费，累计退款不超过该消费金额。成功结果携带 `walletHoldId`（退款可空）和 `walletLedgerId`，以及该动作实际金额；失败结果不伪造资金引用。Lastleg 以 `commandEventId` 定位原费用版本和请求尝试，不能用当前订单状态覆盖旧结果。
|
||||
|
||||
采购应收只在实扣成功后发布 `BusinessFeeSourceChangedV1.walletSettlement`，包含原 `commandEventId`、`holdId`、`ledgerId`；Finance 核对命令结果、客户、业务身份、消费流水与实际 CNY 金额，同事务关联为 `SETTLED`。缺失或错误引用拒绝入池，禁止降级为待收费 `AVAILABLE`。原冻结金额与实际消费金额可不同；同一消费不能认领成多笔费用来源。已确认汇率快照随来源发布，传输重试不重新折算。
|
||||
|
||||
采购资金 TEST 定向证据（2026-10-10）：`reports/procurement-purchase-replay-20261010-r2.json` 验证原购买请求重放只产生一笔1元实扣并完成来源关联；`reports/procurement-sample-20261010-r3/report.json` 验证2元预估只冻结、最终1.50元结算释放差额，货款及实际运费来源均关联成功，重复节点命令未新增消费。运行版本及已知缺口见单机部署主契约；此证据不替代原冻结不足、退款上限、并发或全部异常分支。
|
||||
|
||||
补充已寄客户财务证据：`reports/procurement-financial-corrections-20261010-r3.json` 验证只补扣0.50、按负差额退款1.00、超额退款拒绝、旧请求重放不重复扣退，以及独立0.25费用成功结算；原消费与汇率不覆盖。`reports/procurement-isolation-sources-20261010-r3b.json` 验证4笔正额来源在Finance均为SETTLED且禁止直接改写来源。余额不足及全部故障/权限分支仍待验收。
|
||||
|
||||
采购 SETTLE_ACTUAL 余额不足实证：`reports/procurement-insufficient-20261010-r2.json` 验证E=2、A=11、实际余额9时失败，原冻结和账户版本不变、交寄被阻断；充值5后原费用重试成功。`reports/procurement-insufficient-ledger-20261010-r2.json` 确认原hold.amount仍为2，只有一条-11的CONSUMPTION。`reports/procurement-usd-20261010-r3.json` 验证业务月USD换算、原币目标差额与原汇率快照保留，不修改共享汇率。不能据此推定所有权限及故障分支通过。
|
||||
|
||||
采购平台动作权限实证（2026-10-10）：`reports/procurement-rbac-20261010-r2.json` 的240格矩阵通过。统一Auth新会话按专用角色分别验证list及15个写权限（13项新增、review/edit）：list包含详情和只读明细，无仓绑定仍可处理平台范围；未授予相应权限时连原幂等请求重放也被A0403拒绝，授予后按原业务结果/状态门禁处理。订单完整投影和钱包前后不变；专用账号、角色已停用，所有专用会话退出。此结果只覆盖代表命令，费用用途/来源驱动的重试、文件分类上传及页面按钮边界继续单独验收。
|
||||
|
||||
采购零额与异常结束补证：`reports/procurement-physical-zero-ledger-20261010-r3.json` 确认免费样品、零预估及三项零实际费用共5笔ZERO核定、0资金请求，完整履约钱包不变；`reports/procurement-closure-ledger-20261010-r1.json` 确认新客户取消/异常关闭两单无资金请求和交寄，不以自动退款或虚构发运结束异常。HTTP原请求重放及只读补证、过程脚本失败原因和仍未覆盖的正额资金关闭边界见测试环境单机部署主契约。各成功登录的测试会话均已退出。
|
||||
|
||||
采购未实扣失败替代实证：`reports/procurement-budget-failure-20261010-r1.json` 及其resume报告验证货款FREEZE明确失败时不能绕过终止直接替代，失败费用仍阻断异常关闭；终止后替代按原汇率/业务日和预算校验，以FINANCIAL来源及新钱包身份只实扣1元，原版本无法再次重试，原键重放不重复消费。`reports/procurement-purchase-anomalies-20261010-r1.json` 验证缺汇率、错误购买即使提高预算仍不发资金请求。`reports/procurement-corrections-20261010-r1.json` 验证国内实收更正后重新引用已有零元费用不会新增资金动作。上述均为隔离TEST样本，成功登录会话全部退出；不外推为所有延迟回执或并发分支均已做真实故障注入。
|
||||
|
||||
预估资金及分类权限补证：`reports/procurement-reprice-zero-20261010-r1.json` 验证先释放0.40旧冻结再建立0.60新冻结、原键重放不重复占款、零实际只释放；`reports/procurement-estimate-cases-20261010-r1.json` 验证零预估后独立实际扣款、等额实际结清原冻结及四类正额费用分别关联来源。`reports/procurement-file-retry-rbac-20261010-r1.json` 验证文件按6种分类授权、错误订单文件拒绝，以及BUSINESS/FINANCIAL来源驱动的重试权限（财务替代货款不能用购买权限重试）。本地测试提交 `373f1b2c1` 补全来源故障恢复后原回执重放不重复资金命令的持久化断言，定向10项通过；与真实HTTP证据分层，不将其称为运行环境故障注入。
|
||||
|
||||
采购页面补验（2026-10-10）：Admin #544修复详情文件操作列未绑定插槽的问题；平台账号真实点击本单面单后，订单及客户范围内下载接口返回200/image/png。该项仅证明页面请求接线和服务响应，下载落盘事件未取证成功；list-only授权仍以此前HTTP矩阵及本轮挂载测试为证。采购列表2次业务请求、详情及手动刷新各1次，均200；尚未关闭两端完整UI验收，详见单机部署主契约。
|
||||
|
||||
采购数值与真实审核补验：Admin #547采购适配器将接口数字字符串明确转为安全整数，长ID不转Number。原审核在本地校验失败、未提交业务变更，修复后同单ICSGS202610100001审核通过，客户详情同步待购买与审核时间。API路径、权限和服务端合同未变；139项模块及2761项全量通过。客户端独立创建请求一次、详情一次、列表一次，公共报关待办每60秒轮询；证据和剩余节点以单机部署主契约为准。
|
||||
|
||||
采购国内核费UI补证：真实页面核定国际0.01、关税/国内零、其他不适用，原冻结结清、实际扣款及费用来源关联完成，账户实际4.97→4.96、冻结0.03→0.02；不重复冻结或二次扣款。后续界面验收因同一浏览器platform_admin被切换成另一拼车测试账号而中断，已记录会话覆盖证据，未改跨标签页认证策略。国内面单已保存，最终交寄及Client终态仍待恢复隔离验收环境后验证，具体证据见单机部署主契约。
|
||||
|
||||
|
||||
|
||||
|
||||
| 情况 | 生产端动作 | 消费端要求 |
|
||||
|---|---|---|
|
||||
| APPLIED / DUPLICATE | 标记完成 | 已提交、幂等记录可核验 |
|
||||
@@ -186,3 +215,6 @@ JWT 不携带角色或权限集合，只保留必要身份、客户/应用/仓
|
||||
- 签收本地时间使用服务执行时区转换为事件的 UTC `completedAt`，信封 `occurredAt` 与其为同一时刻；Firstleg 完成时间及状态历史按该事件 UTC 时刻保存。不得将本地 `LocalDateTime` 直接解释为 UTC。来源完成审计同时核对实际签收数量、事件标识与载荷摘要、目标投递 ACK、接收端 Inbox 和完成历史；Outbox 数量检查不能替代完整接收端核对。
|
||||
|
||||
|
||||
|
||||
|
||||
三对话发布后只读冒烟（2026-10-10）：Lastleg #254 与 Admin #555 的精确提交及健康证据见单机部署主契约。统一 Auth 的 admin1 独立会话经 Gateway 查询 `/platform/v1/last-leg/appointment-planning/impacts`、`/appointment-planning/external-candidates`（同属 Lastleg 前缀）及 `/platform/v1/last-leg/overseas-procurements` 均 HTTP 200、业务码200，随后退出自身会话成功。仅证明本轮读接口与新增表接线可用，不代替船期事项认领/记录/关闭的完整写入与权限验收；证据 `reports/three-threads-release-http-20261010.json`。
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
# 自营业务文档入口
|
||||
|
||||
本目录维护平台自营业务的设计与规则。自营外部系统数据与客户物流订单、仓储作业库存分开管理。
|
||||
|
||||
- [领星一件代发数据统计一期方案](领星一件代发数据统计一期方案.md)：Java 服务归属、分仓同步、表结构、自营菜单、货主经营概览与 SKU 库存关注、每日库存观测、销量图表、采集进度、查询性能及验收；后续库龄、内部评级与成本分摊边界。
|
||||
- [经营总览图表设计](经营总览图表设计.md)：新增经营总览页面、指标带、出库趋势、消化天数分布、三类 SKU 图形榜单、统一版本聚合及下钻验收；保持 SKU 为中心。
|
||||
- [库存周转视图设计](库存周转视图设计.md)：库存分析默认视图、7／15／30 天同屏、SKU 与货主汇总、可售天数与期间件数周转、数据资格、查询结构及验收。
|
||||
- [数据采集页面设计](数据采集页面设计.md)：采集首页与任务详情、来源依赖、阶段进度图、数量摘要、预计剩余时间、结果可用性及逐操作验收。
|
||||
- [领星统计查询性能优化方案](领星统计查询性能优化方案.md)：查询耗时定位、总览共享结果与复杂筛选优化顺序、正确性对照及性能验收；业务口径仍以一期方案和总览设计为准。
|
||||
- [领星 WMS 接口联调手册](领星WMS接口联调手册.md)：自研系统（OMP）的签名、仓库发现、一件代发出库、产品库存请求参数及只读实测依据，后续批次库龄接口核验入口。
|
||||
|
||||
后端实现先读 [Integration 指引](../../baiyue-firstleg/integration-service/AGENTS.md)与 [Lastleg 指引](../../baiyue-firstleg/lastleg-service/AGENTS.md)。统一部署、认证和服务通信继续遵循现行主契约。
|
||||
@@ -0,0 +1,211 @@
|
||||
# 库存周转视图设计
|
||||
|
||||
在 Admin「自营业务 → 库存分析」增加默认打开的“库存周转”视图，让运营在同一处比较各 SKU 的 7／15／30 天出库、当前库存和消化速度，并按货主汇总，筛选需要复核库存安排及内部仓储成本的对象。
|
||||
|
||||
本设计整理自 2026-10-13 [优化数据采集页面状态提示中的业务讨论](codex://threads/01a134a1-0ccd-7b61-add0-945d47eec5de)。用户已要求整理方案并交开发总控安排。本文件是新增视图、指标扩展、查询合同与验收的维护入口；基础数据、采集及权限沿用[一期方案](领星一件代发数据统计一期方案.md)，总览原有下钻沿用[经营总览图表设计](经营总览图表设计.md)。设计交付不表示功能已实现、部署或通过验收。
|
||||
|
||||
## 业务目标与本次边界
|
||||
|
||||
业务需要回答四个问题：哪些货现在存得多；哪些 SKU 近期不动或消化慢；哪些货主的库存需要优先复核；哪些商品持续流转，可以进一步评估仓储支持或成本优惠。
|
||||
|
||||
继续按仓库独立查看全部授权货主，当前仍是自营业务的内部评估与成本分摊准备。领星货主不是平台收费客户，不自动绑定财务账户。件数、出库速度与当前可售天数是经营依据，不直接给出“加价”“优惠”“优级客户”或费率结论。
|
||||
|
||||
| 本次交付 | 后续另行核验 |
|
||||
| --- | --- |
|
||||
| 默认进入即查；SKU 与货主两种视图；7／15／30 天出库同屏；按所选窗口的日均及可售天数；无出库、消化较慢／较快、冻结／次品及待评估筛选 | 真实批次库龄、占用体积、托盘／库位及占用时间、货主与内部成本中心映射 |
|
||||
| 有完整日库存样本时计算期间件数周转次数；不足时展示样本数与缺口，不阻断其他指标 | 正式内部评级、仓租加价／优惠规则、生效期、例外、审批及财务联动 |
|
||||
| 库存与销量时间分别展示；同版本分页、汇总、图表及趋势下钻 | 新外部接口、提高领星并发、补造历史库存、任意历史时点库存重建 |
|
||||
|
||||
本轮扩展了早前“期间周转留待后续”的范围：实现有资格才计算的查询与展示，但不放宽日样本标准。新品、战略备货、季节性、断货与促销尚未建模，所有关注标签都供人工复核。
|
||||
|
||||
## 菜单与首次进入
|
||||
|
||||
保持 `/self-operated/inventory` 和现有菜单，页内提供「库存周转」「库存明细」两个视图。普通菜单进入默认“库存周转”，其中默认“按 SKU”；“按货主”是可选切换，不要求先选择货主，不在经营总览和销量分析恢复货主面板。
|
||||
|
||||
原库存明细继续承接已确认的 10／30 天查询与经营总览严格下钻，不得被新默认页签吞掉或转换成相似的新筛选。它是现有查询能力的明确入口，不增加旧协议别名。
|
||||
|
||||
仓库优先级为合法深链仓库、当前页面保留的有权限仓库、服务端返回的首个有权限仓库；不硬编码仓库编码。确定仓库后自动加载，默认截止日为北京时间昨天，计算基准为 30 天，按实物件数降序、未知末尾。无可用仓库不发经营请求。非法深链或无权仓库明确报错，不静默改查其他仓。
|
||||
|
||||
新视图路由参数使用 `view=TURNOVER,groupBy=SKU|OWNER,endDate,baseWindowDays=7|15|30`，以及其合法筛选／排序和查询上下文。显式 `view=DETAIL` 或原总览严格下钻走原合同；相互冲突的参数拒绝，不混合两套筛选。重置保留仓库，恢复新视图默认条件并重新查询；刷新、查询都只读本地已发布数据，不创建采集任务。
|
||||
|
||||
页签判定按以下顺序执行：总览严格下钻（`from=overview`／`drilldownFrom=DASHBOARD`）进入 DETAIL；其次采用合法显式 view；未指定 view 但有明细专属 `salesWindowDays,attention,coverageSelection,coverageBucket,bucketRuleVersion` 时进入 DETAIL；其余默认 TURNOVER。`warehouseCode,sku,customerCode,endDate` 和公共版本字段本身不决定页签。优先级不吞掉冲突：显式 TURNOVER 同时携带总览来源或明细专属条件必须报错，所有参数再按选定视图校验。
|
||||
|
||||
## 页面示意与交互
|
||||
|
||||
以下是布局与承载设计，不是实际数据或已验收截图。沿用模块 ECharts、蓝紫主色及浅色指标卡，数量、异常和数据状态同时有文字，不只靠颜色。
|
||||
|
||||
```text
|
||||
库存分析 库存周转〔默认〕 库存明细 数据采集
|
||||
仓库 [当前仓] 截止日 [昨天] 日均及消化基准 [7 / 15 / 30天] 查询 刷新
|
||||
按 SKU / 按货主 SKU 搜索〔仅 SKU 视图〕 关注条件 / 阈值 / 排序
|
||||
销量：7日完整、15日缺2日、30日缺12日 当前库存采集：开始……完成……
|
||||
────────────────────────────────────────────────────────────────────
|
||||
实物件数 正品可售件数 近30日无出库 SKU 待评估 SKU
|
||||
────────────────────────────────────────────────────────────────────
|
||||
货主实物件数 Top10（横条） 7／15／30日日均出库对比（柱图）
|
||||
────────────────────────────────────────────────────────────────────
|
||||
全部 | 实物件数最多 | 近30日无出库 | 消化较慢 | 消化较快 | 待评估
|
||||
SKU／商品／货主 | 实物／可售 | 7日／15日／30日出库 | 日均 | 可售天数 | 状态
|
||||
……服务端分页，20条／页…… 扩展列／统计说明
|
||||
```
|
||||
|
||||
图表约 220～260px 高，可折叠且记住本页偏好，表格仍是比较明细的主区。四张指标卡和两图显示当前仓库及精确货主范围的整体情况，不随 SKU 关键字、关注筛选及翻页改变；区块标明“本仓概览”或“本货主概览”。列表上方单独显示筛选结果条数，不能让全仓卡片被误读为当前页合计。
|
||||
|
||||
货主 Top10 按有效全品质实物件数排序，未知货主不按零参与排名，图旁显示未能完整计算的货主数；标题必须是“实物件数”，不写“占仓面积／占仓最多”。相同件数按货主编码稳定排序。点击条目切入本仓该货主的 SKU 视图，显示可清除的货主条件，保留上下文；不足十个按实际数展示。
|
||||
|
||||
日均对比使用该范围内完整的 7／15／30 天总出库分别除以 7／15／30，各柱独立判覆盖，不比较不同天数的原始累计量；无完整口径的柱留空并显示原因，不画零柱。图表用于观察平均速度，不直接生成增长率或客户等级。
|
||||
|
||||
| 操作 | 承载与行为 |
|
||||
| --- | --- |
|
||||
| 切仓／截止日／计算基准／分组 | 同页 QueryToolbar；更新条件并回到第一页；切仓清旧数据，取消旧请求并校验请求世代 |
|
||||
| 关注与阈值 | 同页紧凑控件；选择消化较慢／较快时展开整数天阈值，输入有效后查询；不新增确认弹框 |
|
||||
| 按货主切换 | 同页服务端分页汇总；切换时清除 SKU 关键字及仅适用 SKU 的排序，提示条件已调整；保留仓库、截止日、基准及有效精确货主条件 |
|
||||
| 点击货主 | 同页切回 SKU 列表并添加精确货主 chip；返回货主汇总恢复原页码、筛选和上下文 |
|
||||
| 点击 SKU | 复用当前 1120px 居中 SKU 日趋势 AppDialog，带真实货主＋SKU与所选基准区间；不加抽屉或独立详情页 |
|
||||
| 样本与未知原因 | 行内短说明；详细覆盖／日样本证据用现有 1040px 居中证据 AppDialog，最多 30 日；关闭取消请求 |
|
||||
| 图表完整明细 | 沿用 1040px 居中图表明细框，支持键盘等价下钻；不默认重复展示第二张表 |
|
||||
| 统计说明 | 同页折叠文字，集中说明三种指标、时间及未知规则；主表不重复长段说明 |
|
||||
|
||||
SKU 列表是只读分析表，无须新增“操作”列。第一组身份列为 SKU、商品名称、所属货主；长名称可换行，不以内部 ID 回退。首屏保留三窗出库及主要库存／速度指标；冻结、次品、期间平均库存、周转次数、最近已观测出库日、样本证据放扩展列。允许表格内部横向滚动，不挤小全页字体。
|
||||
|
||||
本节是新视图的逐操作设计依据，总控实施时并入模块 `operation-matrix.md`；原明细和总览承载继续沿用既有矩阵。视觉验收为人工 1920×1080、100% 截图，缺证据记“待人工截图确认”。
|
||||
|
||||
## 统计时间与三种指标
|
||||
|
||||
所有窗口使用同一个北京时间截止日 D，默认昨天且不允许未来或未结束的今日。N 天范围为 `[D-N+1 00:00, D+1 00:00)`，N 固定取 7、15、30；不是自然周／自然月，也不复用包含今日的销量图表预设。例：截止 2026-10-12，三个起始日分别为 10-06、09-28、09-13。
|
||||
|
||||
三列出库量始终同屏；`baseWindowDays` 只决定日均、可售天数、快慢查询和期间周转的计算基准，默认 30，不会偷偷把未齐的 30 天换成 7 天。每窗独立返回完整量、已采集量、完整／部分／未知日数、实际日期及原因。部分窗口显示“已采集 X，覆盖不足”，所有日均与派生判断不采用该部分量。
|
||||
|
||||
| 指标 | 计算与命名 | 资格 |
|
||||
| --- | --- | --- |
|
||||
| N 日日均出库 | 同期完整实际出库件数 ÷ N，含真实零出库日 | 使用固定销量版日事实及完整日规则；不只除以有出库的天数 |
|
||||
| 预计可售天数 | 当前正品可售量 ÷ N 日日均出库 | 沿用库存有效性、窗口完整性和本仓 SKU 观察资格；描述正品可售库存，不代表全部实物消化时间 |
|
||||
| N 日件数周转次数 | 同期完整实际出库件数 ÷ 同期每日全品质实物观测均值 | N 个合格同口径日代表、范围／单位／商品身份可靠、同期销量完整；显示“次／N日”，不叫财务周转率 |
|
||||
|
||||
期间平均库存为 `N 个每日代表的实物量之和 ÷ N`，沿用主方案 `DAILY_SCHEDULED_FIRST_V1`：每天指定的首次合格计划采集，不改用每天最新快照，不使用期初／期末二点平均，不是日终或时间加权平均。每个日代表的商品库存先按品质聚合一次，冻结和次品是实物子集，在途不加入。出库分子为同商品同单位全部实际出库，不以某个库存品质过滤重复累加订单。
|
||||
|
||||
当前库存和历史期间独立：更改截止日只改变销量及平均库存的历史区间，预计可售天数仍使用查询时固定的当前库存，页面必须保留库存观测时间。历史周转有完整样本时，不因当前库存过期而抹去历史结果；当前可售天数仍须失效。不同 N 的周转次数不是同一期间，不能直接比较次数得出速度变快。
|
||||
|
||||
计算保留原六位小数精度；日均显示两位、天数一位、周转次数两位，筛选和排序使用未舍入值。很小的正数按显示精度显示“<0.01／<0.1”，不伪装为真实零；前端不重新推算业务指标。
|
||||
|
||||
### 零值与数据不足
|
||||
|
||||
| 条件 | 结果 |
|
||||
| --- | --- |
|
||||
| 窗口完整，当前正可售，但出库为零 | 日均 0，可售天数为空，显示“所选窗口无出库”；不填无限大 |
|
||||
| 当前库存有效且可售为 0 | 可售天数 0 并标“无可售库存”；不进入消化较快，不代表库存健康或货主优秀 |
|
||||
| 当前库存未知／异常／过期 | 可售天数为空并说明；可靠历史出库及历史周转独立展示 |
|
||||
| 7 天完整、15／30 天缺失 | 7 天可独立输出正式值，其他窗口显示已采集量／缺口；默认 30 日基准的日均及天数仍为空 |
|
||||
| N 日日代表齐全且平均实物大于零、出库为零 | 件数周转次数为 0；仍要满足商品观察与销量完整性 |
|
||||
| 平均实物为零 | 周转次数为空；有出库时说明“每日观测未捕获存量”，不输出无穷大或直接认定数据造假 |
|
||||
| 有 30 天出库，但库存只有 2 个合格日样本 | 显示 2／30、缺口和积累起点；周转次数为空，不缩小分母、不用当前库存倒推历史 |
|
||||
| 首采以前、人工 TEST 库存、日代表缺商品行或品质／单位异常 | 沿原规则保留未知／缺口；不补零，不把人工批次事后标成计划日代表 |
|
||||
|
||||
最近已观测出库日期取固定销量版的有效正出库最大日期，不以任意首采日充当。没有可靠日期显示“已采集历史内未见出库”；只有该日期至截止日连续覆盖且商品存在证据可靠时，才可显示“距最近出库 N 天”。不得将有限观察窗口内未见出库写成“从未售出”或真实库龄。
|
||||
|
||||
## 筛选与内部评估规则
|
||||
|
||||
新视图使用独立 `focus`，不改写原 `attention`、总览分桶或 30 日严格下钻含义。观察与异常证据沿用主方案。快慢阈值是本次查询输入，按仓库保存页面偏好但不是正式仓租政策；初始不预设未经确认的 90／180 天，不因未设阈值阻止默认列表。
|
||||
|
||||
| 快捷入口／focus | 规则与默认排序 |
|
||||
| --- | --- |
|
||||
| 全部 ALL | 固定版本候选全集，保留零值、售空及未知；默认实物件数降序 |
|
||||
| 实物件数最多 | ALL＋实物降序；不得称为占用空间最大 |
|
||||
| 近30日无出库 NO_OUTBOUND_30D | 有效正实物、同截止日完整 30 日出库为零及本仓观察资格；包含全冻结／次品；基准选 7 日也不改变该按钮的 30 日语义 |
|
||||
| 消化较慢 COVERAGE_GT | 有效正品可售量和 N 日日均均为正且正式可售天数 > 查询阈值；天数降序 |
|
||||
| 消化较快 COVERAGE_LE | 有效正品可售量和 N 日日均均为正且正式可售天数 ≤ 查询阈值；天数升序；只是消化估算，不代表持续销售或正式高周转等级 |
|
||||
| 冻结／次品 FROZEN／DEFECTIVE | 对应有效数量 >0，不依赖销量完整性；这些库存可能无法按日均正常售出 |
|
||||
| 待评估 UNASSESSABLE | 当前库存、所选 N 日窗口或 SKU 观察资格不足，无法完整评估流转表现；有效零可售仍按优先规则显示0天，窗口不足时可同时标“待评估：销量覆盖不足”；完整零出库不属于此类 |
|
||||
|
||||
可售天数判定固定为库存有效性 → 明确零可售 → 正可售的窗口／观察资格 → 分母是否为零；待评估标签不覆盖这一数值顺序，也不等同“可售天数必为空”。另提供“周转样本不足”状态／筛选 `turnoverStatus=INSUFFICIENT`，它与经营待评估独立：已有完整出库和可售天数的 SKU 可以仅缺历史库存样本。无出库与慢消化是不同集合，不将空天数伪装为超大数；冻结／次品与其他关注可重叠，不把标签命中数相加当总 SKU 数。
|
||||
|
||||
货主视图不把整个货主简单分为快／慢：使用“含此类 SKU 的货主”筛选，行内同时显示该类已确认 SKU 数、实物件数和待判断数；未输入阈值时快慢相关值为空并显示“未设查询阈值”。
|
||||
|
||||
## 货主汇总
|
||||
|
||||
货主汇总是一条服务端分页聚合查询，不先获取货主选项再逐个调用 `owner-overview`。身份键为来源账号＋仓库＋货主；SKU 继续以货主＋SKU 去重，不跨货主合并同名商品。
|
||||
|
||||
每行展示货主名称／编码、有实物 SKU 数、实物／正品可售／冻结／次品件数、7／15／30 日出库、所选 N 日日均、近30日无出库 SKU 数及实物件数、慢消化命中和待评估数量；期间周转放扩展列。不平均 SKU 可售天数，也不输出“总库存÷总日均”作为货主整体可售天数。
|
||||
|
||||
货主历史出库和平均实物候选必须涵盖期间曾有库存或出库而当前已售空的商品；不能先筛当前正库存再算周转。货主平均实物先按每个合格日代表汇总该货主全部同口径商品，再取 N 日均值；完整时用货主同期总出库除以该平均量。它仍是混合商品的件数指标，不作为跨货主奖惩排名，不能用高销量小件掩盖积压大件。
|
||||
|
||||
每项总量分别提供正式总量、已知小计和未知数量。销售窗口完整即可展示货主真实出库总量；单个 SKU 库存观察不足不抹掉已可靠的出库事实。无出库等正式命中件数占比，只有整个候选范围及判断均可靠才输出；否则仅给已确认小计与待判断数。比例为实物件数比例，不是空间占比；分母零时比例为空。
|
||||
|
||||
## 服务端合同与数据结构
|
||||
|
||||
新增 Lastleg 只读 `GET /api/platform/v1/last-leg/self-operated-analytics/inventory-turnover`，供新视图使用；原 `/inventory-coverage`、`owner-overview`、经营总览及其严格下钻合同保留各自用途，不把原单窗口接口改成三次调用。复用平台 list 权限、仓库范围检查和既有异常响应。最终 Controller、DTO、OpenAPI、前端类型必须一起收口，以下是开发目标，不宣称接口已经存在。
|
||||
|
||||
| 入参 | 约束 |
|
||||
| --- | --- |
|
||||
| sourceAccount、warehouseCode | 沿现有受控配置及服务端范围检查；只查单仓 |
|
||||
| endDate、baseWindowDays | 截止日含当天且必须为已结束日期；基准 7／15／30，默认昨天／30；三窗固定返回，不传任意窗口数组 |
|
||||
| groupBy、customerCode、sku | SKU／OWNER；customerCode 可选精确身份，用于下钻；sku 沿用现有合法搜索语义但只适用 SKU 分组，OWNER 携带则拒绝 |
|
||||
| focus、coverageDaysThreshold、turnoverStatus | 按上节枚举；GT／LE 必须有正整数阈值，其他关注可带阈值展示标签；拒绝原 attention／coverageBucket 等混入 |
|
||||
| sortBy、current、size | 按分组白名单排序；默认 PHYSICAL_DESC，1／20，size≤100；同值以 SKU＋货主或货主编码稳定排序，未知末尾 |
|
||||
| 查询上下文 | 复用固定版本、queryAsOf 和有效期；新增历史日代表集合的固定证据，不能由客户端任填 run ID 绕过检查 |
|
||||
|
||||
SKU 排序至少提供实物／可售降序、7／15／30 日出库降序、所选基准可售天数升降序、期间件数周转次数降序；正式值优先，部分出库只能以明确的“已采集量排序”独立模式参与，不伪装成完整销量排序。OWNER 不支持 SKU 天数排序；支持实物、完整窗口出库、已确认无出库实物小计等明确排序，未知状态随值返回。
|
||||
|
||||
一次响应返回 `context,summary,charts,rows,total`。首次／整体刷新返回概览与两图，普通列表翻页用同一上下文及 `includeOverview=false` 省去重复汇总；筛选 SKU 或关注不改变概览范围。切仓、截止日、基准、精确货主或分组变化时，重新请求对应概览；不得把新上下文的行与旧图拼屏。
|
||||
|
||||
`context` 固定账号、仓库、销量版、当前库存版、queryAsOf、有效期、三个真实窗口、当前库存观测起止、历史日样本规则与最多30个日期到代表批次的映射摘要。历史样本只纳入首次上下文时已经发布且合格的代表；后续样本补齐不能悄悄改变旧查询。实际代表映射须可由服务端验证／重建，缺失日期也冻结，不只是返回一个不可校验的哈希。受引用版本按现有保留策略保护，到期或无法重建时明确要求整体刷新。
|
||||
|
||||
每窗指标至少返回 `days,startDate,endDateExclusive,outboundQuantity,observedQuantity,averageDailyOutboundQuantity,completeDayCount,partialDayCount,unknownDayCount,dataStatus,reasonCodes`；行另外返回 `inventoryCoverageDays,averagePhysicalQuantity,quantityTurnoverCount,qualifiedSampleDays,requiredSampleDays,attentionReasons` 及各自状态。不能用一个行级 COMPLETE 掩盖部分指标未知。内部版本标识用于程序，不作为用户可见业务编号。
|
||||
|
||||
### 复用表与最小结构要求
|
||||
|
||||
| 数据 | 复用与约束 |
|
||||
| --- | --- |
|
||||
| 三窗实际出库 | `ll_selfop_sku_daily_sales`，按固定销量版、仓库及最长30日读取，一次条件聚合三窗；仓级概览优先复用 `ll_selfop_warehouse_daily_sales` 及原覆盖证据 |
|
||||
| 当前实物／可售库存 | `ll_selfop_inventory_snapshot`＋其固定 profile，同 SKU 全品质先聚合，避免与日销量多行连接后乘倍 |
|
||||
| 历史平均库存 | `ll_selfop_sync_run.inventory_daily_sample_date/inventory_sample_rule_version` 对应的 snapshot、profile、范围与发布证据；最多30个不可变代表批次 |
|
||||
| 商品观察与缺日 | 固定版本 profile＋销量覆盖证明＋各库存代表的资格；缺行不补零，不读取可变最新档案污染旧上下文 |
|
||||
| 查询上下文 | 沿现有版本上下文机制扩展日代表集合；可用服务端签名令牌或既有上下文存储，但冻结字段及权限行为一致，实施前总控确定唯一方式 |
|
||||
|
||||
本轮不新增 7／15／30 天销量表、不复制库存日明细、不存一张会被实时覆盖的“SKU 周转结果表”，也不新增采集调度。若实际执行计划证明需要索引或有界聚合缓存，由总控在唯一 SQL 基线中评审；不凭设计先引入缓存平台。没有历史代表时，周转值为空即可交付页面，不能为得到数值额外扫描领星或修改原样本标记。
|
||||
|
||||
## 查询性能与一致性
|
||||
|
||||
所有查询读取本地已发布数据，不查原始订单明细，不调用 Integration。禁止前端逐 SKU／逐货主请求、把第一页求和当全仓汇总、先取 Top100 后筛选、为三窗执行三套完整扫描。
|
||||
|
||||
候选身份是本次固定当前库存版 profile／snapshot、固定销量版所选最长30日事实及相关 profile、同期合格日代表 profile／snapshot 中货主＋SKU 的并集；不读取后续可变档案。仅历史存在而当前缺行的商品保留为当前库存未知，不能补零。rows、total、summary 和图表使用同一候选定义，再分别应用各自已声明的范围与列表筛选。
|
||||
|
||||
默认实物排序且无销量／天数／周转等依赖筛选时，可先对完整候选身份分页，再补该页三窗和历史样本，不能只从当前 snapshot 选页而丢失未知／售空商品。依赖销量、可售天数、周转次数的筛选／排序必须先在完整候选计算资格，再排序分页。货主聚合与图表独立按完整范围计算；复用现有性能方案中已验证的路径，不原样重复已无收益的优化实验。
|
||||
|
||||
验收采用单仓至少1万货主＋SKU、最多30日代表、多历史销量版、10并发只读用户及后台构建场景。新增目标：首屏含概览 HTTP P95≤1.5s；默认列表翻页 P95≤1s。复杂筛选、货主汇总和完整30日周转排序分别报告，不用缺样本快速返回证明达标；未达目标记录瓶颈交总控安排，不能伪报通过。保留 P50／P95／P99、SQL 数、扫描行、响应大小及结果对照，压测不请求领星。
|
||||
|
||||
相同条件刷新失败可以保留旧结果并明确时间；切仓清旧结果。当前库存过期时只失效依赖当前库存的判断，历史销量／历史周转仍按各自证据展示。页面刷新不会改变采集状态，开发与发布不得为本视图重置采集任务。
|
||||
|
||||
## 开发顺序与职责
|
||||
|
||||
1. 总控冻结新增接口、窗口／零值规则、历史样本上下文和文件写权；明确 SKU 默认与货主可选视图是本轮新增例外，同步最近模块指引及操作矩阵，不恢复其他页面货主控件。
|
||||
2. 指标查询工作包实现一次三窗聚合、库存资格、分页排序、全范围汇总与有资格的期间周转；样本不足作为正常业务状态，补定向公式／覆盖／版本测试。
|
||||
3. 前端工作包实现默认打开、表格两视图、紧凑图表、筛选与既有趋势／证据弹框；先按冻结 DTO 并行，随后联调。共享类型与导航由总控协调唯一写者。
|
||||
4. 采集工作包只核对已有日代表选择、保留及查询证据是否满足合同，不默认改采集或放大请求；必要缺口另交总控精确派工。
|
||||
5. 总控完成接口、SQL 基线、权限及受影响门禁，安排人工页面验收。实现、自动测试、部署、人工验收分别记录；运行状态仍只维护正式工程契约。
|
||||
|
||||
优先交付能立即使用的默认查询、三窗出库、日均／可售天数、关注筛选与货主汇总；期间周转的合成样本测试同期完成，真实数值等待合格日样本自然积累，不让积累期阻断功能开发。不得以“已有可售天数”宣称正式周转已完成。
|
||||
|
||||
## 验收清单
|
||||
|
||||
| 场景 | 必须结果 |
|
||||
| --- | --- |
|
||||
| 普通菜单进入／有效深链／无仓库 | 自动选合法仓并查询；深链优先；无仓不查；不要求先选货主 |
|
||||
| 截止2026-10-12 | 三窗起止分别为10-06／09-28／09-13至10-13不含，均不包含今日 |
|
||||
| 示例 SKU：7／15／30日出库70／150／300，当前可售600；选30日 | 三列各自真实显示；日均10，可售60.0天；切7日仍日均10，不改三窗累计 |
|
||||
| 同一SKU同期30个日代表实物均值500，30日出库300 | 30日件数周转0.60次；不能用当前可售600算成0.50次 |
|
||||
| 7日齐、15／30日未齐 | 7日正式值可用；其他显示已采集量与不足；30日基准天数空，不自动缩短窗口 |
|
||||
| 30日出库齐、仅2个日代表／只有人工TEST库存 | 显示真实样本缺口，正式周转空；销量和符合资格的可售天数继续展示 |
|
||||
| 全冻结／次品正实物且完整30日零出库 | 可命中无出库和库存品质关注；可售为零不判消化较快，不重复累加实物 |
|
||||
| 新品／来源缺行／负数／过期 | 对依赖指标逐项传播未知，不认定无出库、快消化或优秀；负数不取绝对值 |
|
||||
| 库存有效且可售0，但销量窗口不足 | 可售天数0并标无可售库存，同时保留销量覆盖不足及待评估；不因0天进入消化较快 |
|
||||
| 平均库存正且零出库／平均库存零且有出库 | 前者周转0；后者为空并说明单日观测局限，不显示无限大 |
|
||||
| 当前售空但期间有出库与历史库存 | 仍计入货主期间出库及平均库存；不因当前零库存丢失历史贡献 |
|
||||
| 同仓同名SKU不同货主、两仓同货主SKU | 分行、分仓、独立窗口资格，不混合库存或借另一仓历史 |
|
||||
| 货主有部分未知商品 | 出库、库存及关注分别传播；保留已知小计与未知数，不用合格样本比率冒充完整风险占比 |
|
||||
| 切货主／筛选／分页／图表下钻 | 统计范围标签准确；列表 total 与全量谓词一致；图表不由当前页拼出；身份与上下文不丢 |
|
||||
| 原经营总览无出库／最长天数／分桶跳入库存 | 进入原库存明细，保留原30日资格、严格版本及时效，不落入新近似筛选 |
|
||||
| 新版发布、日样本新增、旧上下文读取 | 旧上下文结果不漂移；整体刷新才切新；过期明确要求刷新 |
|
||||
| 页面与性能 | 1920×1080人工核对；三窗与主库存可读；未知有原因；性能按上述真实完整样本分别报告 |
|
||||
|
||||
本轮评审已明确：7／15／30是完整滚动窗口；原10／30明细继续有入口；货主汇总仅在新视图可选；件数不是空间；可售天数不是库龄或期间周转；历史样本不足不造数；新视图查询不增加领星请求。待后续业务确认的是正式仓租／优惠阈值、空间数据和成本主体，均不阻断本次只读功能开发。
|
||||
@@ -0,0 +1,200 @@
|
||||
# 数据采集页面设计
|
||||
|
||||
把采集首页和任务详情改成能直接看懂的进度界面：**正在做什么、总量多少、完成多少、还剩多少、预计还要多久、结果是否已经可用。** 历史尝试、配置和诊断按需展开，不再让用户从多段文字和两张宽表中寻找答案。
|
||||
|
||||
2026-10-13 用户已确认本文方案及配套交互示意，并明确交由开发总控 `01a12feb-0474-77f1-afe0-a3b491733dca` 安排开发。方案维护对话只维护文档，不修改业务代码；图形示意不是实时任务监控，方案确认也不等于正式页面视觉验收。采集范围、统计口径、发布条件和账号保护继续以[一期方案](领星一件代发数据统计一期方案.md)为准，查询性能按[优化方案](领星统计查询性能优化方案.md)验收。
|
||||
|
||||
## 从这条任务暴露的问题
|
||||
|
||||
用户关注任务为 `LXCOL-20261013-FC1699DFFB6E4EC7`，截图显示 US01、2026-10-12 的出库销量采集。本仓状态为“等待数据准备”，详情却显示来源任务 `LXCOL-20261013-0D70D251A9C5488F` 正在获取详情，已处理 339 / 2,787 单。两种状态可以同时成立：来源数据还在准备，本仓尚未开始归并。
|
||||
|
||||
上述数量只代表截图时刻的来源阶段，不能当成此刻实时进度、US01 单量、SKU 销量或整个同步的完成比例。按截图口径剩余 2,448 单，阶段百分比为 12.1%；展示沿用服务端统一舍入口径。
|
||||
|
||||
| 当前问题 | 用户需要看到的解释 | 设计处理 |
|
||||
| --- | --- | --- |
|
||||
| 首页只写等待，关键列被截断 | 后台到底有没有在干活 | 首屏聚焦当前关注任务，同时展示已确认关联的来源进度 |
|
||||
| 本仓执行 0 次，来源却正在执行 | 两段状态是什么关系 | 用“来源准备 → 本仓归并 → 统计计算 → 结果发布”阶段流串起来，范围分别标注 |
|
||||
| 详情重复任务号并铺满文字 | 总量、已完成、剩余在哪里 | 标题保留一次完整任务号；主体用数字摘要、阶段进度图和一句状态解释 |
|
||||
| “完成时间暂无法预计”长期不变 | 大概要等多久 | 增加基于可靠检查点的速度与当前阶段剩余时间；不具备条件时解释具体原因 |
|
||||
| 空执行历史占大块区域，仍展示恢复表单 | 是否有需要我处理的事 | 历史默认收起；无尝试显示一行摘要；不可恢复时不铺表单 |
|
||||
| 页面更新时间看起来很新，但数量未动 | 是页面在刷新，还是任务在推进 | 区分状态读取时间、进度推进时间和执行心跳 |
|
||||
|
||||
### 源码核对结论与边界
|
||||
|
||||
当前前端已有阶段计数、尝试信息、共享来源和结果状态，不需要另起一个监控系统。但后端 `currentTasks` 按最新创建任务选取，不保证它正在执行；详情上游依据直接关联，概览另有时间窗口关联。调度占位任务还可能没有自己的执行尝试。因此，改版必须补齐“当前实际执行”和“本任务等待对象”的语义，不能只改变文字或给现有最新记录套进度条。
|
||||
|
||||
源码入口为 [CollectionView](../../apps/admin-web/src/modules/self-operated/pages/CollectionView.vue)、[CollectionQueryService](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/query/CollectionQueryService.java)、[CollectionReadMapper](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/query/CollectionReadMapper.java) 和 [SelfopProgressProjection](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/model/SelfopProgressProjection.java)。这些是只读源码结论，不证明截图任务最新运行情况或部署状态。
|
||||
|
||||
## 首页：先看正在发生什么
|
||||
|
||||
### 2026-10-13 单账号首屏收敛（优先于下方原方案）
|
||||
|
||||
用户在最新截图中明确：只有一个领星账号，首页只关心账号正在做什么、完成／剩余多少、预计本阶段多久结束及后续处理。首屏改为账号运行看板，直接使用账号活动与各仓实际活动摘要，不受历史任务号或仓库筛选影响；不能把停止的历史记录作为主进度。布局按配套原型重构为运行看板，配色使用现有 Admin 白色卡片与蓝紫色强调，保留环形进度、三项数量、预计时间和阶段流程；待机时显示最近发布结果与各仓可用状态，不把待机画成100%完成。
|
||||
|
||||
按用户最新要求，采集页移除仓库筛选、任务定位、配置、历史详情、诊断与恢复表单，只读一个账号概览接口；旧链接中的仓库和任务号不改变账号首屏。后续阶段用流程说明展示，不宣称已确定执行顺序；待处理只列服务端已返回的活动摘要（每仓每类型有上限），不能将其数量冒充全账号剩余任务总数。没有完整队列与总任务ETA契约时如实说明，继续展示可靠的当前阶段剩余量和阶段ETA。
|
||||
|
||||
保留“自营业务 → 数据采集”和现有页面路由，按以下顺序组织。沿用 [Admin 高密度规范](../Admin高密度界面规范.md)，使用连续白底区域、轻分隔和紧凑间距，不为每个字段单独放一张大卡片。
|
||||
|
||||
1. **查询栏：** 仓库、采集内容、任务号定位、查询／刷新；北京时间作为统一辅助说明。任务号支持完整粘贴。选择仓库后定位该仓任务，错误仓库返回明确提示，不自动跨权限搜索。
|
||||
2. **当前关注任务：** 一行完整任务号、仓库、采集内容和数据日期；下面是阶段流、当前阶段数量、等待原因、预计剩余时间和最近推进时间。普通用户无需先打开详情就能理解进展。
|
||||
3. **各仓数据可用情况：** 紧凑表展示仓库＋采集内容、当前活动、最近可用数据、覆盖／新鲜度。出库与产品库存各自独立，库存已发布不代表销量已完成。
|
||||
4. **任务记录：** 保留分页、筛选和历史详情。初始展示较少行，把视觉重点留给当前任务；历史列表不能代替实时运行概览。
|
||||
|
||||
首屏焦点默认采用服务端明确的实际活动／阻塞任务，不将“最新创建”冒充“正在执行”。同仓有多个关联任务时给出数量和可切换入口，切换后持续关注所选任务，不被刷新自动换掉。手动选择历史记录时标明“查看历史任务”，保留返回当前活动入口。
|
||||
|
||||
任务号定位同步到现有路由查询参数 `warehouseCode,taskNo`，读取已有受权限约束的任务详情；不要求用户先翻到该任务所在页。轮询不重置历史分页，不丢弃手动选择。任务不存在、无权访问、首次读取失败、暂无任务分别呈现。
|
||||
|
||||
### 历史记录压缩为六列
|
||||
|
||||
| 顺序 | 列 | 呈现方式 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 操作 | “查看详情”；需要固定时固定左侧，不统一写“详情／恢复” |
|
||||
| 2 | 任务／范围 | 完整任务号允许两行；辅助行放仓库、出库／库存、正式／验证用途 |
|
||||
| 3 | 数据时间段 | 显示明确日期区间，精确起止时间进入详情；统一北京时间，结束边界不歧义 |
|
||||
| 4 | 当前阶段与进度 | 阶段标签＋简短计数；等待来源时标注来源范围，不塞完整解释段落 |
|
||||
| 5 | 最近进展 | 推进时间及多久前；没有执行尝试时显示未开始本仓执行，不能用读取时间填充 |
|
||||
| 6 | 执行／发布结果 | 如“等待来源 · 未发布”“已完成 · 已发布”“本次失败 · 旧数据可用” |
|
||||
|
||||
完整技术字段、重试资格、尝试历史和诊断从详情查看，不继续横向增加列。按 1920×1080、100% 缩放及展开侧栏验收：关键状态与进度不依赖横向滚动，任务号不只剩无法区分的前缀，长内容自然换行，不缩小字号硬塞。
|
||||
|
||||
## 详情：图形进度在上，诊断记录在下
|
||||
|
||||
继续使用已确认的 **1200px 居中 AppDialog**，保留全屏与关闭；不新增抽屉或独立详情页。弹框标题只出现一次完整业务任务号，内容分为三层。
|
||||
|
||||
### 第一层：数量、进度与时间
|
||||
|
||||
顶部显示“US01 · 出库销量 · 2026-10-12”和简短状态。当前正在等待来源时，主状态为“等待来源数据”，其下突出“关联来源正在获取出库详情”，避免一个大大的“未开始”盖过真实活动。
|
||||
|
||||
主体左侧为当前阶段的环形进度图，右侧为一组数字和时间摘要，共用一个区域：
|
||||
|
||||
| 位置 | 本次截图对应的呈现 | 规则 |
|
||||
| --- | --- | --- |
|
||||
| 图形标题 | 来源详情采集 · 账号共享 | 图形旁持续显示范围，不能只放在提示浮层中 |
|
||||
| 中心数字 | 12.1% · 当前阶段 | 只有可靠分母才能画确定比例；不叫“同步总进度” |
|
||||
| 数量摘要 | 总数 2,787 单／已完成 339 单／剩余 2,448 单 | 同一计数范围、阶段和基准；“单”不是 SKU 件数 |
|
||||
| 时间摘要 | 任务累计耗时（含排队与重试）；最近处理速度；预计本阶段还需多久 | 累计耗时使用 Task.elapsedSeconds，从 createdAt 起算，活动任务截止读取时间，终态截止任务最后更新时间；不受 attempt 或阶段切换影响，缺失显示 —；当前阶段 ETA 与任务累计耗时分别标注 |
|
||||
| 提示 | 本仓尚未归并；来源完成后继续计算与发布 | 一句话解释下一步，不复述整段技术规则 |
|
||||
|
||||
未知总量显示“已完成 N 单／总量待确认”（库存按实际单位），使用不表达百分比的阶段状态图，不画 0% 或假转动的确定进度。零量仅表示数量，状态继续取服务端证据：如“0 单，正在核验”或“0 单，结果已发布”；库存显示对应页／行单位，不由 `total=0` 推断正在校验或已经完成。异常计数或总量变化时撤去比例，说明正在复核。
|
||||
|
||||
进度图只表达当前阶段。按 2026-10-13 用户确认，与自营业务其他图表统一使用 ECharts＋vue-echarts 的 Canvas 配置，通过 `AnalyticsChart.vue` 复用；当前阶段环图使用无指针、无刻度的环形进度配置。未知、零分母及异常计数只显示空环，不填入虚假百分比。状态同时使用文字和图形，不只靠红绿颜色区分。
|
||||
|
||||
### 第二层：阶段流与结果可用性
|
||||
|
||||
出库流程画为五个节点：**来源目录 → 来源详情 → 更新本仓出库数据 → 统计计算 → 结果发布**。前两个节点标“账号共享”，后三个标“本仓”。完成节点用勾、当前节点用突出色、阻塞节点用原因、未开始节点用灰色；只有服务器确认适用时显示“复用完成／无需此步骤”。不能把完成两个节点直接换算为整体 40%。
|
||||
|
||||
节点完成必须有对应任务、尝试／轮次及切片的服务端完成证据，不能因当前进入后一个阶段就自动勾选之前全部节点。重复扫描、恢复或多切片时标明当前适用范围；缺少阶段历史证据显示“状态未确认”，不补造完成时间或完成结论。
|
||||
|
||||
产品库存采用自己的流程：**本仓库存分页 → 完整性校验 → 统计计算 → 结果发布**。展示页数、读取行数和去重业务键时分别标单位；库存行数不能冒充 SKU 数。
|
||||
|
||||
阶段流下方只保留两条业务说明：
|
||||
|
||||
- **本次结果：** 未发布／已发布／沿用已有结果／失败。来源完成或详情 100% 不等于本仓报表更新。
|
||||
- **当前报表：** 正在使用哪次已发布数据、销量连续覆盖到哪天、库存观测时间。首次没有结果时显示尚无可用数据；已有旧版则继续展示其真实时效。
|
||||
|
||||
多日首采另显示目标日期范围和已发布覆盖／缺口摘要，目标从服务端读取。当前 TEST 最近 30 个完整日和生产首次最近 2 个月不得写成同一个固定标签；单个 12 日任务完成也不代表近 10／30 天可售天数观察窗口已经齐全。
|
||||
|
||||
### 第三层：按需查看与处理
|
||||
|
||||
“执行记录（N 次）”“校验与诊断”按需展开。配置只保留必要摘要，完整配置继续从原页面入口使用只读 AppDialog 查看，不在详情里另造配置区或叠开弹框。没有本仓尝试时只占一行：“本仓尚未开始执行；来源准备进度见上方”，不显示空表、空分页器。来源任务号与其尝试信息独立展示，不混进本仓尝试次数。
|
||||
|
||||
失败、长时间无推进或账号保护生效时，将简短原因提到上方；完整错误码、历史检查点和请求用量留在诊断区。质量尚未计算时摘要写“待校验”，不在多个区块重复长解释。可恢复任务且具备独立写权限时，才展示原有原因填写、核对与恢复操作；等待来源、正常运行或会话终止时不展示不可使用的表单。
|
||||
|
||||
恢复仍沿已有 `POST /sync-tasks` 的 `RETRY`、原任务号和幂等键，受服务端 `allowedActions/actionBlockReason` 控制。受理后只提示已排队，不能提示同步成功；页面不增加绕过账号暂停、会话截止或预算的“强制继续”。
|
||||
|
||||
## 预计时间：先给可靠的阶段估算
|
||||
|
||||
用户需要大概同步时间，因此把速度与预计剩余时间纳入本次设计，不无限期留一句“无法预计”。先交付**当前可计量阶段的剩余时间**；整个任务还需归并、计算、发布时明确说明。完整同步 ETA 只有所有剩余阶段均有可信工作量或校准过的历史耗时模型后才开放，不能把当前阶段 ETA 改个标题当总 ETA。
|
||||
|
||||
计算由服务端产生，页面只显示，不按页面轮询次数、请求次数或截图里的“339 单／78 秒”推算。78 秒可能是尝试耗时，且已完成数量可能包含检查点复用，两者并非同一个测速口径。
|
||||
|
||||
### 计算条件与公式
|
||||
|
||||
- 采样来自已提交的进度检查点。使用同一来源任务、尝试、阶段、扫描轮次、范围、单位和计数基准；分母已确认且在采样窗口内稳定，执行健康正常。
|
||||
- 建议初始参数：最近不超过 3 分钟的有界样本，至少跨度 60 秒、至少 3 次真实推进。阈值集中配置，并用实际采集验证；这是实现建议，不是当前已测得的领星吞吐能力。
|
||||
- `处理速度 = 窗口内新增实际处理完成量 / 窗口实际经过秒数`；正常运行期间没有推进的间隔也计入耗时，不能只统计快的请求。完成总数允许包含复用对象，但测速增量独立排除复用；窗口内新识别的历史复用也不能抬高速度。实现可保留可靠的实际处理增量，无法区分时遇到复用跳变重新建立基线，暂不估算。
|
||||
- 同身份且完成数不变的保存不重置样本，也不计为有效推进；复用导致完成数增加仍重新采样。本次执行至少积累60秒、3次实际推进后估算，累计完成比例不能作为本次测速的样本量。有效期为最多30秒，为10秒轮询留出请求时间，仍受最近推进、执行健康及180秒采样窗口约束；选取在有效期内不会移出窗口的采样起点，避免窗口滚动造成短暂失效。
|
||||
- 估算使用同一份进度身份、完成数、分母和时点。采样窗口截止到本次估算时刻，最后一次检查点后正常等待的时间也计入分母，补充的只读端点不伪造新推进。不能将旧估算与新 completed／total 混合返回；页面按身份和有效期整体接收或丢弃。
|
||||
- `本阶段预计剩余秒数 = (可靠总量 - 已完成量) / 处理速度`。速度必须大于零、剩余量非负；以“约 N 分钟”向上取整展示，小于一分钟显示“约 1 分钟内”，不显示精确到秒的完成承诺。
|
||||
- 阶段切换、尝试重开、轮次变化、分母变化或冷却后恢复均重建测速窗口。建议样本按 10 秒桶合并、最多保留 20 个端点，ETA 持久采样数据不超过 1 KiB，并与已有阶段记录合计遵守进度 JSON 8 KiB 上限。优先保留业务检查点及审计摘要；接近上限时压缩／丢弃 ETA 样本并返回暂不可估算，不能让估算附加数据导致采集提交失败。不为 ETA 扫描全部订单或引入独立时序平台。
|
||||
|
||||
| 情况 | 预计时间区域 |
|
||||
| --- | --- |
|
||||
| 正常推进且样本充分 | “当前阶段预计还需约 N 分钟”，同时显示最近处理速度与估算更新时间 |
|
||||
| 刚启动／恢复后样本不足 | “正在测速”，照常显示已有完成量 |
|
||||
| 总量未确定／正在变化 | “总量待确认，暂不估算” |
|
||||
| 明确限流冷却 | “限流暂停；最早恢复时刻……；恢复后重新估算”，不把冷却结束当完成时刻 |
|
||||
| 预算耗尽／人工暂停／失败／健康待确认 | “已暂停估算”＋具体原因，不保留看似继续倒计时的旧 ETA |
|
||||
| 超过配置的无推进期限 | 保留最后真实计数，显示“近期无新增进度，暂不估算”；心跳正常不等于有处理速度 |
|
||||
| 页面读取失败／估算已过期 | 标记最后观测时间，撤去活动倒计时，显示更新失败或估算已过期 |
|
||||
| 本阶段结束但后续阶段未知 | “本阶段已完成；正在归并／计算／发布”，不显示整个同步还剩 0 分钟 |
|
||||
|
||||
服务端返回 ETA 适用阶段、有效期及不可估算原因。全任务 ETA 留作后续校准能力，不阻塞本轮数量、阶段图、测速和阶段预计时间交付；不以提高领星请求并发来让预计时间变短。
|
||||
|
||||
## 任务关联、等待与活动状态合同
|
||||
|
||||
继续扩展现有运行查询 DTO，不新增平行的监控 API，不改采集任务身份。以下为需补齐的语义；已有等价字段优先复用，开发总控确认最终 DTO 命名并同步 OpenAPI、直接调用方和契约测试。
|
||||
|
||||
| 数据组 | 已有基础 | 必须补齐或明确的语义 |
|
||||
| --- | --- | --- |
|
||||
| 关注任务与实际执行 | `currentTask,latestAttempt,taskNo` | 显式区分最新逻辑任务与活动执行；无本仓 run 是合法状态。不能依赖创建时间推断活动任务 |
|
||||
| 依赖与阻塞 | `sharedUpstream`、直接上游关联、概览窗口关联 | 建议返回 `dependencyState,blockingReason,progressSourceTaskNo`；服务端确认关联后才标“为本任务准备”。窗口相交只表示相关候选，不能证明直接依赖；多个实际依赖以有界摘要呈现 |
|
||||
| 阶段计数 | `progressScope,countBasis,attemptNo,phase,scanRound,completed,total,totalKnown,unit,sliceFrom,sliceUntil` | 数量保留范围、来源和分母依据；本仓无投影不能借账号总数填充。本仓页可展示共享进度，但标题必须标账号共享 |
|
||||
| 状态时钟 | `observedAt,progressUpdatedAt,heartbeatAt,executionHealth` | 读取时间、最后提交推进时间、执行心跳分别返回；终态尝试冻结可靠摘要时间。当前终态读取 `summaryAsOf` 而标准冻结路径未写此值，需补实际快照证据，不用查询时刻伪装 |
|
||||
| 等待与保护 | `nextRetryAt,accountCooldownUntil,accountPauseReason` 和预算摘要 | 等待原因与不能重试原因分开；区分来源未齐、排队、冷却、会话截止、预算耗尽。前端不靠本地时钟自行判失败或宣布已恢复 |
|
||||
| 速度与预计时间 | 现有可靠计数和阶段时间 | 建议有界 `stageEstimate`：状态、`progressIdentity`（来源任务、尝试、阶段、轮次、范围、单位、基准）、所依据的 completed／total，以及 `sampleFrom,sampleUntil,completedDelta,ratePerSecond,remainingSeconds,estimatedAt,validUntil,unavailableReason`；completedDelta 仅指实际处理增量。估算和进度依据一致才返回数值，有效期同时受状态观测及无推进期限约束 |
|
||||
| 结果与覆盖 | `resultPublicationState,lastPublishedAt,initialCoverageStatus` 等 | 本次结果和目前报表可用结果独立；来源 `ROUTED`、预算 `YIELDED`、目录完整不能当成本仓发布 |
|
||||
|
||||
依赖不明确时，展示“本任务等待来源；关联进度尚未确认”。如服务端确有其他账号活动，可以另外显示“账号正在执行其他采集”，不能挂在这条任务下面冒充它的完成量。`actionBlockReason` 是操作资格，不能直接当成执行等待原因。
|
||||
|
||||
共享采集可能服务两个仓库，在全部仓库视图按来源任务号去重展示一次；本仓任务不重复累加共享数量或尝试次数。数据范围与权限由服务端核验，不暴露来源密钥、内部数据库 ID 或原始订单载荷。
|
||||
|
||||
## 状态刷新与查询成本
|
||||
|
||||
页面可见且有本仓活动、来源活动、等待来源或待执行任务时，沿用每 10 秒刷新运行元数据；没有活动时每 60 秒刷新。来源仍在推进时，不因本仓执行次数为零降为闲置。切页或浏览器隐藏停止，恢复可见立即读取。
|
||||
|
||||
只保留一个轮询调度器：概览和所关注任务读取有界摘要；任务详情展开时复用同一任务数据，历史尝试分页按需获取，不为每一行各开请求，也不每 10 秒反复拉不变的历史页。仓库切换、任务切换、旧尝试迟到响应均进行取消／身份校验，不覆盖新选择。
|
||||
|
||||
轮询失败保留最后成功读到的数量和时间，提示“状态更新失败”，不把运行状态改成失败。无新推进且心跳正常显示“执行中，最近一次推进在……”，是否超时或失联由服务端判定。页面刷新成功不更新任务推进时间；只有下一次服务端健康与保护状态确认后，才撤销冷却／暂停提示。
|
||||
|
||||
运行查询只读 scope、task、run 与有界投影，不扫描订单、商品明细、统计全表或完整 manifest，不调用领星。阶段 ETA 也不增加外部请求。已有运行元数据 P95 ≤500 ms 的目标继续适用；后续与候选构建混合负载验证按性能方案安排，本轮不新增真实采集或压测。
|
||||
|
||||
## 逐操作设计与验收
|
||||
|
||||
视觉依据是本轮首页与任务详情两张用户截图及用户已确认的配套交互示意；现有承载以 [模块操作矩阵](../../apps/admin-web/src/modules/self-operated/operation-matrix.md)为准。下表为已确认的改版设计，由开发者实施时更新该矩阵；本轮不把设计图写成已实现／已验收。
|
||||
|
||||
| 操作 | 承载与关键验收 |
|
||||
| --- | --- |
|
||||
| 打开采集页 | 现有独立页面；首屏读到活动／等待对象、当前计数、最近推进和结果可用性 |
|
||||
| 输入任务号 | 现有查询栏；可直接定位，不依赖历史首屏；当前关注区保留完整任务号和仓库 |
|
||||
| 切换仓库／关注任务 | 原页更新；旧响应不串仓、不替换手动选择；共享数量不重复合计 |
|
||||
| 查看任务详情 | 原 1200px AppDialog；首屏为数量摘要、阶段图、阶段预计时间和结果提示；全屏／关闭保留 |
|
||||
| 查看历史／诊断 | 当前详情内折叠；空历史无表格和分页；失败原因在首层有短摘要 |
|
||||
| 查看配置 | 复用原只读 AppDialog，不把查看变成修改配置 |
|
||||
| 恢复任务 | 原详情内受权限与资格控制的确认流程；无资格不铺表单，不能绕过账号保护 |
|
||||
| 跳转销量／库存 | 复用已有页面与仓库上下文；目标展示已发布版本，不把运行计数当销量 |
|
||||
|
||||
### 必测状态
|
||||
|
||||
1. **本次截图场景：** 本仓未启动，已确认关联来源正处理 339 / 2,787 单。首页和详情均明确来源在工作，本仓等待；两个任务号、尝试次数和计数范围不混用。
|
||||
2. **关联缺失：** 账号有活动但无法证明属于该任务。明确待确认，不把无关进度贴过来；详情与概览采用同一关联语义。
|
||||
3. **计数边界：** 总量未知、零单、分母变化、分页轮次变化、对象复用、尝试重开。没有虚假百分比、剩余负数、重复完成数或从阶段序号算整体比例。
|
||||
4. **预计时间：** 样本未齐不估算，稳定采样可估算；窗口内外复用都不抬高速度；最后推进后的正常停顿计入窗口；阶段／尝试变化重置，旧估算不得配新数量，冷却和陈旧数据暂停估算，阶段 100% 不等于任务剩余 0。高频推进且历史阶段摘要接近 8 KiB 时，样本仍有界、可降级，采集提交不受 ETA 影响。
|
||||
5. **更新故障：** HTTP 失败、旧响应迟到、心跳过期、心跳正常但无推进。最后观测值保留，任务不被浏览器误判失败；来源活动下保持活动轮询。
|
||||
6. **发布与覆盖：** 来源完成但本仓计算中、本次失败但旧版可用、首次无版本、单日已发布但 10／30 日窗口不足、库存独立发布。所有结论均与实际覆盖一致。
|
||||
7. **权限与布局：** 只读账号可看详情但不可恢复；无资格任务无恢复表单；1920×1080／100% 截图核对首页、普通详情、全屏详情、长任务号和错误状态，关键内容不靠横向滚动或极小字号查看。
|
||||
|
||||
前端状态用受控样本和组件验证，后端关联、计数、ETA 和权限用合同测试；不为验收设计扩大真实领星采集。源码检查、接口验证和人工截图分别交付，缺少人工截图时保留“待人工视觉确认”。
|
||||
|
||||
## 交给开发总控的建议顺序
|
||||
|
||||
| 顺序 | 工作包 | 交付判断 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 统一活动任务、等待依赖与计数范围 | 服务端能解释这条任务在等谁；概览和详情一致；未确认关联如实显示 |
|
||||
| 2 | 首页与现有详情改版 | 先用已有可靠计数呈现阶段图、大数字和结果状态，收起历史及无效操作；不等待复杂总 ETA 才改善可读性 |
|
||||
| 3 | 阶段速度与预计时间 | 补有界采样和服务端估算合同；所有不可估算状态有具体解释，页面显示约数 |
|
||||
| 4 | 联合验收 | 跑上述状态矩阵、元数据查询检查和人工截图，核对两仓／出库／库存；已通过项目不无故重复 |
|
||||
|
||||
用户已授权开发总控将本设计纳入开发安排，由总控协调现有模块写入者、共享接口与执行顺序；方案维护对话不改业务代码，不另建监控服务、任务表、调度系统或用户可见对话。代码、部署和正式验收进度继续只维护在工程主契约；本次设计交接不扩大环境操作授权。
|
||||
|
||||
页面阶段名称 MERGE 显示“更新本仓出库数据”：将已校验的来源出库单按所属仓库写入或更新本地出库数据，再计算销量；不表示库存合并。库存流程独立为获取产品库存、完整性校验、统计计算、结果发布。
|
||||
@@ -0,0 +1,178 @@
|
||||
# 自营经营总览图表设计
|
||||
|
||||
新增 Admin「自营业务 → 经营总览」，用图表回答本仓近期出库是否变化、库存大约需要多久消化、哪些 SKU 出库多、哪些库存值得关注。页面以 SKU 为中心，所属货主只作识别；保持同仓同名 SKU 跨货主分开，不恢复已取消的货主独立筛选或经营面板。
|
||||
|
||||
本文件是经营总览页面、聚合接口、下钻和验收的维护入口；原始事实、同步、可售天数、观察资格、版本与权限沿用[一期方案](领星一件代发数据统计一期方案.md)。本次范围为设计与开发交接，不表示页面已经实现、上线或通过视觉验收。采集和环境操作继续按当前正式契约及用户授权执行，图表查询不调用领星。
|
||||
|
||||
## 菜单与页面布局
|
||||
|
||||
新增路由 `/self-operated/overview`，模块页建议为 `apps/admin-web/src/modules/self-operated/pages/OverviewView.vue`。菜单顺序为经营总览、销量分析、库存分析、数据采集；沿用 `platform:self-operated-analytics:list`，总控统一集成路由、导航及 IAM。保留原三个页面的查询与作业入口，不更改登录后的全局首页。
|
||||
|
||||
总览只选一个仓库，不合并两仓库存、规则或可售天数；不增加来源账号、货主或 SKU 输入框。仓库首次为空时提示选择，返回页面可恢复最近选择；无有效仓库不查询经营接口。来源账号由已有受控配置确定，不在业务页面显示技术键。
|
||||
|
||||
在 `1920×1080`、100% 缩放下采用以下设计布局，正常纵向滚动，不为挤进一屏压缩图形和字体：
|
||||
|
||||
```text
|
||||
经营总览 查看销量 查看库存 数据采集
|
||||
仓库 [选择] 出库趋势范围 [今日/近3天/本周/近15天/本月/自定义] 查询 刷新
|
||||
销量覆盖截至…… 库存采集于…… 有新数据可刷新 / 部分资料提示
|
||||
──────────────────────────────────────────────────────────────────────
|
||||
区间出库量 | 近30日日均出库 | 实物库存 | 正品可售 | 有库存SKU | 无出库SKU
|
||||
──────────────────────────────────────────────────────────────────────
|
||||
出库趋势（日折线，约 2/3 宽） 库存消化天数分布（横向条形，约 1/3 宽）
|
||||
所选日期范围；真实每日点 固定近30个完整日；分类数量与待核验范围
|
||||
──────────────────────────────────────────────────────────────────────
|
||||
所选时段热销Top10 预计消化时间最长Top10 近30日无出库库存Top10
|
||||
按出库件数的横向条形 按可售天数的横向条形 按实物件数的横向条形
|
||||
```
|
||||
|
||||
出库趋势范围默认近 15 天，支持主方案确认的五种自然周期和最多 366 天的自定义范围。该控件同时影响趋势、区间出库 KPI 与热销榜；热销按所选日期内已采集有效出库量排序，未采齐显示部分覆盖。日均、分布、最长消化及无出库库存榜仍标注近 30 个完整日范围。
|
||||
|
||||
KPI 采用紧凑的一行指标带；图表是主要内容，不再以整页描述表承载。复用 Admin 密度令牌，图表不套详情字段网格或普通表格行高。图表行建议趋势约 280～320px 高；榜单给 10 条保留可读高度，不强制全部首屏可见。长 SKU 可换行或省略并提供可聚焦的完整文字；名称与货主为辅助文本，不以内部 ID 回退。
|
||||
|
||||
## 指标带
|
||||
|
||||
数值来自服务端，保留版本、单位、覆盖和未知原因。这里的件数均为出库或库存数量，不是订单数、成交收入或净销售额。
|
||||
|
||||
| 指标 | 展示口径 |
|
||||
| --- | --- |
|
||||
| 区间出库量 | 与当前全仓趋势的日点合计守恒；全日均完整才显示正式总量，否则标为“区间已采集出库量”，全无可靠值为“—” |
|
||||
| 近 30 日日均出库 | 本仓最近 30 个完整自然日实际出库总量÷30；完整仓级覆盖即可计算，不因某个 SKU 库存观察不足抹去有效出库。不用当前图表天数做分母 |
|
||||
| 实物库存 | 当前固定库存版各货主／SKU／品质的有效实物量；冻结、次品已经包含在实物中，不重复相加；在途不加入 |
|
||||
| 正品可售 | 只汇总正品有效可用数量，不再减冻结、不加在途或次品 |
|
||||
| 有库存 SKU | 全品质实物量已核验大于零的货主＋SKU 去重数；品质行不是独立 SKU；存在库存未知时标记“已确认 N，另 M 待核验” |
|
||||
| 近 30 日无出库 SKU | 有实物且满足完整 30 日零出库及本仓观察资格的 SKU 数；观察不足和未知另外说明，不认定卖不掉 |
|
||||
|
||||
库存或风险总量存在依赖未知时，正式值为空，允许显示“已知小计”及未知 SKU 数；不把未知过滤后仍显示成全仓总数。单项完整性独立：库存失败不阻止完整销量图；销量不足不掩盖已核验库存。全仓可售天数、平均 SKU 可售天数、评分和“优级客户”不在指标带中。
|
||||
|
||||
## 五张图表
|
||||
|
||||
### 出库趋势
|
||||
|
||||
使用日折线图，横轴为北京时间业务日期，纵轴为件数，零基线；日期轴包含完整选择区间。后台按仓库及固定销量版直接汇总有效日事实，包含现在已无库存的出库商品，不从库存列表或 Top 榜单反推总量。仓级全日覆盖完整且无出库时可为零，不要求每个 SKU 均满足 30 日库存观察期。
|
||||
|
||||
每个日点返回正式量、已采集量、完整性和覆盖原因。缺日断线，部分日用明确的点形／虚线及“未完整”文字；不平滑跨越缺口。今日只有一个日累计点，不画小时趋势；自定义长区间减少坐标标签密度但保留全部日点和提示。整段已采集合计等于可靠日点已采集量之和；所有日点未知时合计为空。
|
||||
|
||||
仓级零值与部分值单独判断：全天覆盖完整时，正式量＝已采集量＝有效日行合计，无行可为 0；只有部分已证明覆盖且无日行时，正式量为空、已采集量为 0、状态 PARTIAL；没有覆盖证明但存在已确认日行时仍保留日行合计为已采集量、状态 PARTIAL；没有覆盖证明且没有日行时，两值均为空、状态 UNKNOWN。连续水位外的已确认日行不能被丢弃，整个仓级趋势不套单 SKU 存在时间或库存观察门槛。
|
||||
|
||||
点击已知日点进入销量分析当日自定义范围；未知日不可伪造零数据下钻，改显示该日覆盖不足原因。鼠标提示和键盘聚焦均显示日期、件数、状态；不能仅依赖颜色解释未知。
|
||||
|
||||
### 库存消化天数分布
|
||||
|
||||
使用横向条形图，单位为 SKU 个数，显示“有实物库存或库存待核验 SKU 的分布”。候选取固定两版 profile 的货主＋SKU 并集：明确有效且实物为零的 SKU 排除；有效正实物以及实物未知／过期的候选保留。整个库存版尚不可用时显示无库存资料，不将全部销售候选画成一个伪造的库存总量。
|
||||
|
||||
`bucketRuleVersion=COVERAGE_DISTRIBUTION_V1` 按以下先后顺序将每个候选只归入一个桶；上一步命中后不再落入后续桶。销量与观察资格沿用主方案，不直接将没有日行视为零出库：
|
||||
|
||||
| 桶 | 判定 |
|
||||
| --- | --- |
|
||||
| `UNKNOWN` 库存或销量待核验 | 先检查本 SKU 实物或用于可售天数的正品可售数据异常／未知／过期；命中即归此桶。后续因销量窗口或观察资格不足无法计算时也归此桶，分别统计原因 |
|
||||
| `NO_AVAILABLE` 无可售库存 | 库存有效、实物大于零且正品可售量明确为零；可包含冻结或次品，不宣称周转良好，不依赖销量资格 |
|
||||
| `NO_OUTBOUND_30D` 近 30 日无出库 | 有效正可售量、完整 30 日及观察资格且出库为零；天数为空，不转成无限大 |
|
||||
| `DAYS_0_30`、`DAYS_30_60`、`DAYS_60_90`、`DAYS_GT_90` | 正可售量、正日均且资格完整，按未舍入天数分别落 `(0,30]`、`(30,60]`、`(60,90]`、`(90,+∞)` |
|
||||
|
||||
在无可售库存判断之后、零出库或数值分桶之前检查销量／观察资格；不足回到 UNKNOWN。展示顺序为四个数值桶、无出库、无可售、待核验，不等于执行判定顺序。30／60／90 仅为本版图形分组边界，不是收费、补货或优劣政策。
|
||||
|
||||
各桶 `skuCount` 之和必须等于 `candidateSkuCount`，并同时返回已排除的确定零实物 SKU 数。图表不展示“风险率”百分比；待核验量无法被藏进已评估分母。可在提示中显示桶内已知实物小计及未知件数范围，不把件数与 SKU 个数混用。
|
||||
|
||||
此分布为互斥展示分组，主方案 attention 是可并存的关注条件，两者不等价。例：全冻结且近 30 日零出库 SKU 归 NO_AVAILABLE，但仍可出现在无出库库存榜。冻结、次品、可售、在途不能作为可相加的饼图组成部分。
|
||||
|
||||
### 三个 SKU 榜单
|
||||
|
||||
均为横向条形图，最多 10 个候选；热销使用页面所选日期，另两个库存榜固定至昨日的 30 个完整自然日；无合格候选显示原因，不造空条或补足 10 个。每条展示 SKU、可用名称、所属货主及主指标，提示补充库存／日均／日期依据。同名 SKU 不跨货主合并；坐标从零开始，条长按真实数值，不截成相同最大长度。数量过大可用统一刻度单位，提示保留原值。
|
||||
|
||||
| 图表 | 资格与排序 | 下钻 |
|
||||
| --- | --- | --- |
|
||||
| 所选时段热销 Top 10 | 按所选日期已采集有效正出库量降序、单数降序、SKU／货主编码升序；部分覆盖也展示，明确标记未完整，不将未采集当零。库存缺失或售罄不阻止进入 | 条目打开同窗口 SKU 趋势；“查看 Top 100”进入销量分析相同 CUSTOM 日期范围 |
|
||||
| 预计消化时间最长 Top 10 | 有效正可售、正日均、完整窗口及观察资格；按未舍入可售天数降序，SKU／货主编码升序。零销量单列，不冒充无限天数；不等同原 slow-skus 低销量榜 | 条目打开 SKU 趋势；“查看全部”进入库存分析相同有限天数候选及天数降序 |
|
||||
| 近 30 日无出库库存 Top 10 | 主方案 attention=NO_OUTBOUND_30D：全品质有效正实物、完整窗口和观察资格、出库零；包含全冻结／次品有实物者。按实物量降序，SKU／货主编码升序 | 条目打开 SKU 趋势；“查看全部”进入库存分析无出库关注及实物量降序 |
|
||||
|
||||
排名从全仓所有已授权货主的候选先算资格／排序后截取，不先截 SKU 清单或逐货主各取十个再汇总。观察不足时返回待评估数量；榜单明确是“符合条件的 SKU”，不以没有合格候选推断库存健康。可售天数很长仍是按历史速度的估算，不标成真实库龄或一定卖不掉。
|
||||
|
||||
## 图表交互与视觉依据
|
||||
|
||||
本文件作为新增页面的设计依据，布局由上面的页面示意和本矩阵约束；实现前总控将对应记录并入模块现有 `operation-matrix.md`。既有页面承载以该矩阵的用户截图纠正为准，不读取或恢复更早的货主面板。
|
||||
|
||||
| 页面操作 | 承载与行为 | 设计验收 |
|
||||
| --- | --- | --- |
|
||||
| 仓库／趋势范围查询 | 同页紧凑 QueryToolbar；查询先校验再更新，切仓清旧数据并取消旧请求 | 不增加独立货主控件，不在主区堆账号键、时区技术值、长规则 |
|
||||
| 刷新 | 明确按钮整体更新版本与 queryAsOf；新数据提示不自行替换某张图 | 过期上下文显示刷新提示，不混合版本 |
|
||||
| 柱／条与日点提示 | 图内提示，键盘可聚焦查看同等内容；未知日只展示缺口原因 | 不是新业务弹框，不仅靠颜色或悬浮识别数值 |
|
||||
| SKU 条目趋势 | 沿用当前 1120px 居中 AppDialog，支持已有全屏／关闭；传该行 customerCode＋sku 和上下文，热销使用所选范围，另两个榜固定 30 日范围 | 不改为列表下方详情、抽屉或新详情页；关闭取消请求 |
|
||||
| 分桶或查看全部 | 导航至既有销量／库存正式页面并带准确筛选、版本和返回来源 | 目标页显示可清除的“来自经营总览”条件摘要，不重新引入货主选择器 |
|
||||
| 查看采集状态 | 导航至所选仓的数据采集页 | 只查看当前状态，不触发采集／重试 |
|
||||
|
||||
保留屏幕阅读名称、键盘入口、焦点和足够对比度；趋势每日数值、SKU覆盖证据、库存分组说明、分布与排行榜按2026-10-13用户截图反馈统一使用居中弹框；分布与排行榜使用“查看完整明细”1040px居中弹框，提供完整名称、数值、证据及同资格的键盘下钻入口，长字段换行，正文滚动；悬浮提示只展示名称和数量并限制宽度，Top100／查看全部仍进入对应列表，不将全页默认变回表格。主图使用折线与条形，不使用 3D、雷达、仪表盘、双轴、装饰动画或无依据的“健康分”。按 2026-10-13 用户确认，自营业务图表统一使用 ECharts＋vue-echarts，通过模块内 `AnalyticsChart.vue` 按需注册并使用 Canvas 渲染；坐标轴、提示框、缩放、条形及环形进度用配置维护，删除手写 SVG／CSS 绘图。日趋势与 SKU 趋势共用有效数据连线配置，未完整日用虚线，未知或缺失日期仍断线。
|
||||
|
||||
功能／合同评审和人工视觉验收分别记录。本设计不代替真实页面的人工 `1920×1080`、100% 截图验收，未提供截图时保留待人工确认，不声称视觉通过。
|
||||
|
||||
## 服务端聚合接口
|
||||
|
||||
新增 `GET /api/platform/v1/last-leg/self-operated-analytics/dashboard`，前端使用独立 `analyticsApi.dashboard`。现有前端 `overview` 实际调用 `sync-overview`，是采集状态接口，不能用它冒充经营聚合或改掉原语义。
|
||||
|
||||
入参要求 `sourceAccount,warehouseCode`，趋势参数复用 `rangePreset` 和 CUSTOM 的 `startDate,endDate`；不接受 customerCode、SKU、跨仓合并或任意 Top N。首次查询固定主方案中的两版、范围摘要、queryAsOf 及到期时间；后续只切趋势范围复用上下文，显式刷新／切仓重新建立。榜单数量服务端固定 10，消化天数分组固定 V1。
|
||||
|
||||
在一次短只读一致快照中校验范围／版本并读取所需数据；整个响应共同使用同一上下文，不由前端并发获取多个“最新版本”后拼屏。某一数据族不可用时仅返回该族不可用，不妨碍另一族可用图形；鉴权失败、参数错误、版本无效或 SQL 失败是请求错误，不吞掉后转零或正常空图。
|
||||
|
||||
| 响应块 | 主要字段与要求 |
|
||||
| --- | --- |
|
||||
| `context` | 主方案现有完整版本上下文、实际趋势范围、固定 30 日窗口、salesCoveredFrom/Until、库存观测起止、inventoryFreshUntil、queryExpiresAt，另含 inventoryDrilldownExpiresAt（有效库存时取前两截止时间的较早值，否则不可用）；技术字段用于程序，不放主页面占位 |
|
||||
| `kpis` | 六项指标各有 value／knownSubtotal、单位、dataStatus、unknownSkuCount、reasonCodes；区间出库另有正式量／已采集量，日均使用独立完整日窗口 |
|
||||
| `salesTrend` | 每日 points 及区间汇总；每点 businessDate、outboundQuantity、observedQuantity、dataStatus、reasonCodes，最多 366 点，日轴不省略缺日 |
|
||||
| `coverageDistribution` | bucketRuleVersion、candidateSkuCount、excludedZeroPhysicalSkuCount、各 bucketCode／skuCount、可选已知实物小计／未知数、dataStatus／reasonCodes；分组未知原因有摘要 |
|
||||
| `hotSkus`／`longCoverageSkus`／`noOutboundSkus` | 各自实际窗口（windowStartDate/windowEndDateExclusive/calculationWindowDays）、eligibleCount、unassessableCount、items（最多 10）、dataStatus／reasonCodes；每项包含实际 customerCode＋sku、名称、主指标及其单位／必要辅助值，窗口出库字段为windowOutboundQuantity。热销部分覆盖返回PARTIAL与SALES_WINDOW_INCOMPLETE，不返回该部分量推算的日均和消化天数。单点弹框复用原 daily API，不因图形新增另一份销量公式 |
|
||||
|
||||
计数无法确定时用空值和原因，不能把未计算的 eligibleCount／unassessableCount 默认为零。冻结、次品、在途可作为必要辅助数量，不新增会被误加总的库存占比饼图。所有经营数量的已知小计／完整总量遵守主方案；日均销售不依赖 SKU 的库存观察期，风险分类则依赖。
|
||||
|
||||
### 精确下钻合同
|
||||
|
||||
现有销量／库存页仅解析并传递 warehouseCode、sku，不能只拼一个新 URL 就宣称下钻已完成。此次必须扩展目标页的参数解析、初始化、取消请求、校验与返回上下文；来源条件只作为查询条件，权限仍由服务端核验。
|
||||
|
||||
- 通用路由条件：`warehouseCode`、可选精确 `sku,customerCode`（仅行身份，不显示独立货主选择器）、原完整版本上下文、`from=overview`。使用固定本地路由，不接受任意 return URL；编码／日期／枚举非法显式提示，不能静默忽略成全仓查询。
|
||||
- 趋势日点：销量页 `analysis=SKU`、`rangePreset=CUSTOM` 且 startDate=endDate=该日。热销 Top 100：`analysis=HOT,rangePreset=CUSTOM,startDate,endDate`，日期来自榜单窗口（endDate 为 exclusive 截止前一日），不再携带 windowDays。这两个路由枚举是新增初始化合同，开发映射到现有页面状态，不能原样当作新的外部 API 字段。dashboard 的 eligibleCount 是当前已采集有效正出库候选数，热销明细沿用原 Top 100 上限，故 total=min(eligibleCount,100)，前 10 名及主值必须一致；不扩展成无限热销榜。
|
||||
- 无出库全部：库存页 `attention=NO_OUTBOUND_30D,sortBy=PHYSICAL_DESC`。最长可售全部：`/inventory-coverage` 和路由均新增 `coverageSelection=FINITE_POSITIVE`，在服务端 SQL 分页前过滤为正式有限正可售天数候选，`sortBy=COVERAGE_DAYS_DESC`；不能仅在浏览器当前页过滤，也不能把零库存、未知天数放进候选冒充同一榜单。该字段属于本地报表接口，不传领星。
|
||||
- 分布条形：库存页新增 `coverageBucket` 与 `bucketRuleVersion=COVERAGE_DISTRIBUTION_V1`。服务端 `/inventory-coverage` 同步接收并按上述唯一分组谓词过滤；不能把区间点击近似替换成 attention 或一个“大于”阈值。coverageBucket 与 coverageSelection、非 ALL attention 互斥，冲突拒绝；未带 bucket 时不接收单独 ruleVersion。FINITE_POSITIVE 与非 ALL attention 也互斥。
|
||||
- 日点、整榜、分桶或具体 SKU 下钻均携带同一版本上下文；条件 chip 可清除，清除后恢复目标页常规范围，但不更换仍有效的上下文。返回总览恢复原仓库、趋势范围、上下文及滚动位置；到期或版本不可用时提示整体刷新，不能悄悄换新后声称与原图一致。
|
||||
|
||||
库存严格下钻额外携带 `drilldownFrom=DASHBOARD` 给 `/inventory-coverage`，用于声明与原图一致的读取要求，不授予额外权限；from=overview 的目标页必须映射此参数。服务端从原上下文及库存 run 的真实时效重新计算 inventoryDrilldownExpiresAt，不信任客户端传入的截止时间。库存已超过有效期或上下文到期时返回明确的“原图库存已过期，请刷新总览”错误，不能按过期后的 UNKNOWN 重新分桶再冒充原图结果；前端同时禁用原库存图的分桶／榜单列表下钻。此时趋势与热销的有效读取仍可继续，普通库存页的历史／过期展示保持原规则；重新加载的过期总览仅提供普通库存诊断入口，不提供严格分桶下钻。单条 SKU 的出库趋势不受库存过期阻断。
|
||||
|
||||
## 数据模型与查询性能
|
||||
|
||||
本页不新增采集任务、调度、周月汇总、缓存平台或库龄表。2026-10-13 用户确认允许新增仓库每日汇总表 `ll_selfop_warehouse_daily_sales`，按销量版本、来源账号、仓库、业务日保存有效已采集量、异常日行数与源日行数，数量沿用六位小数。每批 SKU 日行与对应仓日汇总在同一事务写入并推进构建检查点；发布前核对汇总覆盖的源行数，成功后同事务设置销量版本 `warehouse_daily_ready`。空销量版也必须完成该验证，不能以汇总表无记录推断为零。缺少就绪证据的版本明确拒绝总览读取，重新构建发布，不回退到旧查询或补写旧版本。
|
||||
|
||||
趋势和仓库销量合计读取已发布仓日汇总，日期完整性、部分采集与异常口径仍由原版本覆盖证据判定；仓日汇总不证明完整自然日。SKU 明细、库存与榜单继续复用已发布 daily、snapshot、profile、run；SQL 按版本、仓库、日期限缩，库存先按货主＋SKU／品质聚合，再与销量连接，禁止原始订单 Join 或逐 SKU／逐货主 N+1。版本保留与受保护版本规则同时覆盖仓日汇总；不引入额外清理调度。
|
||||
|
||||
趋势在数据库按业务日期聚合；三个榜单分别在完整候选上计算并排序 LIMIT 10；分桶在 SQL 中 CASE 聚合，不能从第一页库存或 Top 100 拼出全仓分布。前端一次 dashboard 响应只接收最多 366 个日点、7 个桶和 30 条榜单记录及固定 KPI，不请求全部库存，不逐货主调用 owner-overview。下钻的库存计数及谓词必须与 dashboard 共享，避免边界漂移。
|
||||
|
||||
沿用主方案的代表性合成数据档位：单仓 1 万货主＋SKU、多个历史统计版、有后台构建及 10 个并发只读用户。新增目标为 dashboard HTTP P95≤1.5s；报告 P50/P95/P99、SQL 数、扫描行及响应大小，查询数量须为固定少量、不得随 SKU／货主数线性增长。目标未实测，不以 SVG 绘图流畅代替后端验收。首次与预热分别记录，任何测试不对领星发起压力请求。
|
||||
|
||||
首次加载用结构占位；无仓、无业务版本、可靠全零、观察不足、过期和失败分别呈现。主动切仓立即清旧仓图并隔离迟到响应；相同条件刷新失败可以保留旧图，但明确“刷新失败，展示上次查询”，不伪装新成功。到达库存有效期或上下文到期后，相应指标标为历史／待刷新，不继续作为当前可信结论；不靠后台轮询替换单张图。点击刷新只读本地接口，不意味着立即同步领星。
|
||||
|
||||
## 离线验收与评审
|
||||
|
||||
下表均为合成数据设计，不作为真实经营结果；开发需同步 OpenAPI、权限、目标页路由解析和直接测试，API 门禁沿后端根指引执行。原模块已有功能与人工截图结论保留，不因新增总览回退 SKU 中心布局。
|
||||
|
||||
| 用例 | 必须得到的结果 |
|
||||
| --- | --- |
|
||||
| 近 15 天含今日，另选今日／本周／本月／CUSTOM | 趋势轴、区间出库与热销榜随选择变化，另两榜／分布／日均仍固定 30 日；今日单点无小时数据 |
|
||||
| 日量 2、未知、5，今日部分 1 | 可靠值合计 8 标已采集，正式总量为空；缺日断线，今日部分；全未知合计为空，不为 0 |
|
||||
| 同仓 SKU X 属货主 A 出库 2、B 出库 5，均有效 | 全仓对应日为 7；榜单与点击身份保留两条，下钻分别为 2／5 |
|
||||
| 库存缺失但完整 30 日热销数据存在 | 日均、趋势、热销可用，依赖库存的图形显示未就绪，不让库存失败清空销售 |
|
||||
| A 正可售 3000、30 日出库 300；B 正可售 30、出库 30 | A 可售 300、B 30，分别归 >90 和 (0,30]，最长榜 A 在前；不按低销量将 B 当更积压 |
|
||||
| 候选 5 个：有效正可售零出库、全冻结且零出库、库存未知、有效天数 30、有效天数 30.04；再有明确零实物 1 个 | 分别落无出库／无可售／待核验／(0,30]／(30,60]；桶合计 5、排除数 1；冻结 SKU 仍能进入独立无出库库存榜 |
|
||||
| 正品实物 120 含冻结 20，可售 100；次品实物 8，在途 30 | 实物 128、可售 100，不相加为 278；图中不出现这几个重叠量的库存组成饼图 |
|
||||
| 整体存在未知库存或观察不足；热销和无出库候选不足 10 个 | 标已知小计和待评估，不补齐榜单、不宣称整体无风险；完全无可靠资料不显示健康零值 |
|
||||
| 90、90.04 天显示均可能接近 90；零出库的天数为空 | 比较与分桶按未舍入值，分别≤90／>90；零出库不进最长有限天数榜、不放成无限值 |
|
||||
| 每个分桶点击、榜单跳转、单条趋势，随后返回；另测 200 个热销候选 | 库存分桶／最长／无出库的 total 等于对应完整候选数；热销 total=min(eligibleCount,100)，200 个候选时为 100，前 10 一致。身份／版本不变，复用 1120px 趋势弹框，返回保留范围及滚动位置 |
|
||||
| 图表加载途中切仓、后台发布新版、跨午夜或上下文过期 | 旧仓响应不覆盖新仓；不单图切版或自动滚动今天；到期明确刷新，库存过期不继续显示当前有效 |
|
||||
| 同一版本和 30 分钟上下文仍有效，但库存先到 freshUntil，再点击原分桶／库存榜单 | 前端阻止旧图严格下钻，服务端同样拒绝，不返回改变分类的结果冒充一致；要求刷新总览，出库趋势／热销仍按其独立资格读取 |
|
||||
| dashboard 或路由参数缺仓、非法桶、互斥参数冲突、客户身份调用 | 明确拒绝，不能悄悄全仓查询；平台鉴权和来源范围校验不因汇总而弱化 |
|
||||
|
||||
设计评审收口项：SKU 中心与现有页面一致；两套窗口分开；分布互斥且守恒；零出库与有限天数分开；全品质实物不重叠相加；未知不隐藏；下钻需要真实参数接线和共用谓词；新增聚合接口与运行概览分开。评审不覆盖生产吞吐、真实数据对账或人工视觉验收。
|
||||
|
||||
本轮已分别完成数据口径、页面／接口两项独立评审，并复核修正后的合同：补齐仓级部分日零值规则、库存时效先于查询上下文到期的严格下钻门禁，以及热销完整候选数与原 Top 100 上限的区别。设计范围内无剩余阻塞，可交开发总控安排；不把该结论作为代码、性能或视觉验收通过。
|
||||
|
||||
后续可在真实库龄、空间占用和内部经营规则核验后增加库龄分布及成本分析，不在本页放无数据的库龄饼图、平均周转率、货主评分或费用预测。开发总控按本设计安排前后端工作，计划和测试状态由其当前对话及正式工程契约维护。
|
||||
|
||||
图表明细与说明弹框通过 append-to-body 挂到页面根部，避免图表卡片动画／transform限制遮罩与弹框；更换数据关闭旧弹框，日期下钻先关闭明细，长表只滚动弹框正文。库存分组说明宽760px，每日数值／覆盖证据和排行明细宽1040px，可全屏。
|
||||
|
||||
热销Top10完整明细按用户最新截图去重：使用1280px居中弹框，按排名、SKU、商品名称、货主、所选时段出库量、实物库存、可售库存、窗口日均、预计可售天数分列；不再拼接重复说明段落，窗口与覆盖状态只在表格上方展示。商品名称与SKU完全相同时显示—，以“SKU＋空格”起始时仅去掉该重复前缀；货主＋SKU身份及点击下钻保持不变，未知指标不补零。
|
||||
@@ -0,0 +1,350 @@
|
||||
# 领星 WMS 一件代发与产品库存接口联调手册
|
||||
|
||||
本手册是后续开发的外部 API 入口，说明请求方式、参数、字段映射、实测差异和验收方法。业务同步、表结构、统计口径和开发顺序以[一期方案](领星一件代发数据统计一期方案.md)为准。本期只使用 **WMS 一件代发出库单和 SKU 产品库存**，不接整箱中转出库单或整箱库存，不做箱数到件数的推算。
|
||||
|
||||
接口体系为领星 WMS 管理后台的“自研系统／服务商内部系统对接”，官方文档站为 OMP。不要换成 OMS 货主端或 WMS 智能设备的路径和签名。
|
||||
|
||||
**当前执行边界：首次正式历史采集改为最近 2 个月，放在生产执行；测试只做有硬上限的小样本。** 同一真实账号由一个环境独占，测试不能与生产并行请求；默认最多累计 10 次分页、20 次详情、40 次总 HTTP 及 5 分钟，任一上限即停止，预算含复核及失败请求。详细边界与用途隔离以[生产首采与测试请求边界](领星一件代发数据统计一期方案.md#生产首采与测试请求边界)为准。下文此前一个月样本、全库存扫描及重读均是历史联调证据，不是现在要求测试环境重复执行的步骤；本轮未发起新请求。
|
||||
|
||||
**时间口径已确认：2026-10-12 用户说明领星返回时间已转换为北京时间。** 本期两个仓库均按 `Asia/Shanghai` 解析出库时间和统计日期，直接使用有效返回日期；查询 `startTime/endTime` 同样按北京时间传参。不要再按洛杉矶、纽约或仓库资料中的 `timeZone` 二次转换。08:00／20:00 出库同步、建议的每日 08:00 库存同步及五种图表自然周期均采用北京时间；分仓任务、覆盖与时效继续独立。
|
||||
|
||||
原始时间字符串保持不变，业务日期直接取其日期；内部 UTC 字段按既有存储规范标准化，不使用 UTC 日期替代业务日。认证包络的 Unix 秒级 `timestamp` 仍按当前时间点生成，不能因业务时间为北京时间而手动加减 8 小时。完整实现与验收见一期方案的[同步时间和统计日期](领星一件代发数据统计一期方案.md#同步时间和统计日期)。
|
||||
|
||||
## 接口和当前实现
|
||||
|
||||
| 用途 | 方法与路径 | 返回主体 | 本地 Java 当前能力 |
|
||||
| --- | --- | --- | --- |
|
||||
| 发现正常仓库 | `POST /openapi/v2/warehouse/page` | `data.records[]` | 已有内部仓库目录接口源码；外部接口已直接 HTTP 联调 |
|
||||
| 一件代发已出库单目录 | `POST /openapi/v2/order/delivery/page` | `data.records[]` | 已有只读内部分页摘要接口 |
|
||||
| 一件代发单的实际 SKU 明细 | `POST /openapi/v2/order/delivery/detail` | `data` | 已有内部详情接口及 SKU 数量 DTO 源码；外部接口已直接 HTTP 联调 |
|
||||
| 产品库存 | `POST /openapi/v2/stock/stockSku/page` | `data.records[]` | 已有内部产品库存接口源码；外部接口已直接 HTTP 联调 |
|
||||
|
||||
当前 Java 已有五个内部 POST 入口，共用 `/internal/integrations/lingxing/wms` 前缀并要求内部服务令牌：`/warehouses/query`、`/outbound-orders/query`、`/outbound-orders/locate`、`/outbound-orders/detail`、`/product-inventory/query`。出库发现接口返回单据摘要，实际 SKU 数量须通过详情接口获取；不能把摘要当作完整明细。接口职责和字段见[一期方案的接口约定](领星一件代发数据统计一期方案.md#平台查询接口和权限建议)。本轮只核对源码，不把外部直接 HTTP 联调成功推定为这五个 Java 入口已全部运行验收。[本地启动说明](../../baiyue-firstleg/integration-service/README.md)
|
||||
|
||||
## 认证和请求格式
|
||||
|
||||
基础地址为 `https://api.xlwms.com`；所有请求使用 HTTPS POST，`Content-Type: application/json; charset=UTF-8`，响应按 JSON 解析。认证参数放在请求体中，不需要 OAuth 获取 Token 的前置调用。
|
||||
|
||||
| 包络字段 | 类型 | 约束 |
|
||||
| --- | --- | --- |
|
||||
| `appKey` | string | 自研系统的 App Key，官方长度 32 |
|
||||
| `timestamp` | string | 当前 Unix 秒时间戳，官方为 10 位数字；不是毫秒 |
|
||||
| `data` | object | 对应接口的业务参数 |
|
||||
| `sign` | string | HMAC-SHA256 小写十六进制，64 位 |
|
||||
|
||||
领星凭据按用户在开发总控对话中的确认配置为 `LINGXING_OMS_APP_KEY` 和 `LINGXING_OMS_APP_SECRET`，应用、示例及 Compose 已采用这两个名称；产品仍为 WMS OMP，真实出口开关仍为 `LINGXING_WMS_ENABLED`。真实值仅通过私有环境配置／Jenkins 凭据注入，不复制到文档。本地私有配置由 Git 忽略；Spring 不会自动加载 `.env.local`，运行前按上述 README 核对变量名和加载方式，不输出凭据值。内部服务令牌是本平台自身的调用保护，与领星凭据分开。
|
||||
|
||||
```json
|
||||
{
|
||||
"appKey": "<运行时注入>",
|
||||
"data": {"current": 1, "size": 2, "whCode": "WH-DEMO", "isHideInventory": 0},
|
||||
"timestamp": "<当前秒时间戳>",
|
||||
"sign": "<本次计算的签名>"
|
||||
}
|
||||
```
|
||||
|
||||
以上占位符不是可直接发送的凭据。先确定业务参数与路径，再为每次请求重新生成时间戳和签名，不能把分页接口的签名复用于详情或库存。[官方加签算法](https://apidoc-omp.xlwms.com/docs/%E5%BC%80%E5%8F%91%E9%AA%8C%E7%AD%BE%E5%B7%A5%E5%85%B7.md)的当前参数拼接为：
|
||||
|
||||
```text
|
||||
待签名串 = appSecret + path
|
||||
+ "appKey" + appKey
|
||||
+ "data" + data的Map/List字符串表示
|
||||
+ "timestamp" + timestamp
|
||||
+ appSecret
|
||||
sign = hexLower(HMAC_SHA256(key=appSecret, message=待签名串, UTF-8))
|
||||
|
||||
库存例子的 data 表示：{current=1, size=2, whCode=WH-DEMO, isHideInventory=0}
|
||||
不是 JSON：{"current":1,"size":2,"whCode":"WH-DEMO","isHideInventory":0}
|
||||
```
|
||||
|
||||
保留业务对象的插入顺序，使用同一数据对象参与签名和实际发送；对象以 `k=v`、逗号加空格连接，数组也按 Map/List 规则递归表示。`path` 包括 `/openapi/v2/...`，不包括域名和查询串。Java 已有 `LingxingWmsSigner`，后续优先复用它，避免新增第二份签名实现：
|
||||
|
||||
```java
|
||||
Map<String, Object> data = new LinkedHashMap<>();
|
||||
data.put("current", 1);
|
||||
data.put("size", 2);
|
||||
data.put("whCode", warehouseCode); // 来自已配置仓库，不能用文档占位值
|
||||
data.put("isHideInventory", 0);
|
||||
var signed = signer.sign(appKey, appSecret,
|
||||
"/openapi/v2/stock/stockSku/page", data, Instant.now());
|
||||
// POST signed.body()；不可打印请求体、签名、密钥或原始响应。
|
||||
```
|
||||
|
||||
客户端使用超时、HTTPS、禁止重定向及受控并发；认证错误不能盲目重试。现有本地适配器请求间隔为 1 秒，这只是保护配置，不表示领星承诺 1 QPS。正式初始化前确认账号配额和详情调用量，使用统一账号级限流。
|
||||
|
||||
## 一件代发出库分页
|
||||
|
||||
[官方 WMS 分页说明](https://apidoc-omp.xlwms.com/reference/post_openapi-v2-order-delivery-page-1.md)明确对应管理端的一件代发出库单列表。
|
||||
|
||||
一期使用的 `data` 参数如下；首采固定起止时刻，后续翻页不能移动窗口：
|
||||
|
||||
| 参数 | 类型 | 本期值与说明 |
|
||||
| --- | --- | --- |
|
||||
| `current` | integer | 从 1 开始 |
|
||||
| `size` | integer | 官方默认 10、最大 1000；联调先 1 |
|
||||
| `timeType` | string | 固定 `outboundTime`；不用创建时间代替出库时间 |
|
||||
| `startTime`、`endTime` | string | `yyyy-MM-dd HH:mm:ss`，按已确认的北京时间口径传入，与返回的出库时间保持一致。2026-10-12 已出库单样本观察到起点、终点均包含，见后文边界验证；不能外推为全部仓库／时间类型的保证 |
|
||||
| `status` | integer | `100` 已出库；`99` 已取消。已知单的修订复查走详情，不只查状态 100 |
|
||||
| `customerCodes` | string | 官方类型为字符串、描述为客户编码；不是已确认的数组，多货主拼接方式未验证。本期账号全集省略该参数；与库存单数 `customerCode` 名称不同 |
|
||||
| `deliveryNo` | string | 官方描述“发货单单号”；已验证正常单和取消单省略时间／状态可定位，本期默认新单发现不传。仍须校验单号完全一致与货主身份，不能假定所有输入均精确匹配 |
|
||||
|
||||
公开分页入参没有 `whCode` 或 `whCodeList`。因此出库目录按账号共享发现，再用返回的 `whCode` 路由至每仓独立任务和统计范围；不得发送未声明字段并假定已经按仓过滤，也不为每个仓重复抓取全账号目录。详情可使用仓库标识，已知单的复查按所属仓执行；跨仓修订必须同时处理旧、新仓贡献。
|
||||
|
||||
```json
|
||||
{
|
||||
"current": 1,
|
||||
"size": 1,
|
||||
"timeType": "outboundTime",
|
||||
"startTime": "2026-09-12 08:00:00",
|
||||
"endTime": "2026-10-12 08:00:00",
|
||||
"status": 100
|
||||
}
|
||||
```
|
||||
|
||||
正式任务按已确认账号全集读取，不传 `customerCodes`。用户已确认当前可见全部 70 个货主、2 个仓库均为自营统计范围，货主数量不作为硬编码上限。若后续加入货主子集筛选，应先实测该字符串参数，不能依据复数名称自行发送 JSON 数组。
|
||||
|
||||
目录保留 `deliveryNo`、`sourceNo`、`customerCode`、`whCode`、`status`、`createTime`、`outboundTime`。`productList[].qty` 不直接作为正式实际出库量；本期明细统一来自详情。
|
||||
|
||||
## 一件代发出库详情
|
||||
|
||||
[官方详情说明](https://apidoc-omp.xlwms.com/reference/post_openapi-v2-order-delivery-detail-1.md)的业务参数仅有以下三个字符串。Schema 未声明 `required`，但本平台合同要求三个值齐全，全部来自同一条已验证分页记录：
|
||||
|
||||
```json
|
||||
{
|
||||
"whCode": "WH-DEMO",
|
||||
"customerCode": "CUSTOMER-DEMO",
|
||||
"deliveryNo": "DO-DEMO-001"
|
||||
}
|
||||
```
|
||||
|
||||
不要用来源单号 `sourceNo` 代替出库单号 `deliveryNo`，也不要从单号格式推断货主或仓库。
|
||||
|
||||
| 响应路径 | 含义与处理 |
|
||||
| --- | --- |
|
||||
| `data.deliveryNo/customerCode/whCode` | 必须与查询主体相符；同单仓库变更进入修订核对 |
|
||||
| `data.status` | 当前状态；以当前事实决定是否计入 |
|
||||
| `data.orderCreateTime` | 详情的创建时间字段名；分页中对应 `createTime`，不能照搬 DTO 名称 |
|
||||
| `data.outboundTime` | 实际出库时间，已由领星转换为北京时间；保留源字符串，按 `Asia/Shanghai` 解析并直接使用其业务日期，不再转美国时间 |
|
||||
| `data.skuVOList[].productSku` | SKU；货主和仓库从详情主体继承 |
|
||||
| `data.skuVOList[].actualDeliveryQty` | 实际出库量；官方 integer，实测为 JSON number；Java 使用 BigDecimal 统一保留精度 |
|
||||
| `data.skuVOList[].deliveryQty` | 预报出库量，只作对照，不用于销量替代 |
|
||||
| `data.packageList[].skuList[]` | 包裹维度重复明细，不与 `skuVOList` 累加；其 `actualDeliveryQty` 官方类型是 string |
|
||||
|
||||
同单同 SKU 多行先归并。完整详情缺失、数量无法解析或身份不符时，不能把该单视为零销量后推进完整水位。原始响应可能含面单链接、物流信息等，日志和持久化只能保留本期白名单字段。
|
||||
|
||||
### 列表数量与实际数量对照的证据缺口
|
||||
|
||||
2026-10-13 按用户要求只读检查 TEST 已保存数据，目标是寻找预报量与实际量不同的一件代发出库单。检查在只读事务中执行，单条 SELECT 限时5秒；本次没有向领星发起请求，没有修改采集任务或统计数据。
|
||||
|
||||
- 当前查得12,823条有效出库暂存、12,740个不同订单业务键；预报量字段检查命中0。核对最新完整载荷及代码，商品行仅保留 `skuCode,productName,quantityUnit,actualQuantity`。Integration 的详情 DTO 虽有 `deliveryQty`，Lastleg 转为统计载荷时未保留它，订单事实也不保存预报量。
|
||||
- 同时查询已出库状态100、商品实际量为0的候选，结果为空；不能据此推断所有订单预报量等于实际量。
|
||||
- Integration 列表映射只保留订单头，不返回 `productList[].qty`。所以当前库不能直接筛选预报／实出差异，现有内部列表接口也不能完成三值对照。当前检索结果是“缺比较字段”，不是“已证明一致”。
|
||||
|
||||
下一步最小验证应优先附着正常采集已经收到的响应，采集少量白名单对照证据：同一账号、仓库、货主、出库单、SKU 的列表 `qty`、详情 `deliveryQty`、详情 `actualDeliveryQty`，订单状态／出库时间及列表、详情观测时间。按同 SKU 汇总后比较，同时核对 SKU 集合完整性。最多保留100个完整配对订单或首次出现差异即停止；不额外创建历史采集，不输出面单、收件信息、签名或凭据。该诊断需要开发总控协调列表字段与预报量的有限保留，当前尚未实施。
|
||||
|
||||
命中预报量不等于实际量时，优先使用同次配对的列表证据；若列表／详情时点相差或订单被修订，则仅针对该订单在现有账号预算和统一出口内最多补一次列表与一次详情核验，限流即停止。已保存匹配证据不重新请求。
|
||||
|
||||
验收判定：列表量等于预报且不等于实际量，可否定“列表直接替代实际量”；列表量等于实际量且不等于预报，只证明该差异样本支持替代方向，还需确认 SKU 完整性、修订与取消边界；三值相同不能区分语义。未取得差异样本时明确保留未验证，不停用详情链路。
|
||||
|
||||
### 数量对照验证的采集保护与开发交接
|
||||
|
||||
2026-10-13 用户指定已有对话 [开启新对话](codex://threads/01a135d0-f5c7-7422-892f-037b0c9ea00e) 实施本次有界验证，要求不影响采集。仅接管数量对照与所需只读状态判断，不恢复其他对话已暂停的开发、服务或采集。业务销量继续以详情实际量为准；验证通过前不切换统计来源。
|
||||
|
||||
开发先核对当前代码、运行版本及改动归属。只读状态使用实际生效配置、账号预算／冷却／暂停原因、未完成请求许可、任务／执行尝试／租约和真实进度观测时间联合判断，不凭聊天状态、“无活动任务”、页面等待文案或心跳正常推断可发请求。前后两次轻量只读观测可识别正常推进与证据变化，不轮询原始订单或 SKU 明细。
|
||||
|
||||
| 状态证据 | 对照行为 |
|
||||
| --- | --- |
|
||||
| 正常采集运行，有有效租约／在途请求或成功数量推进 | 只附着正在发生的正常响应保留白名单字段；不发独立扫描或插队详情，不调整并发 |
|
||||
| 等待间隔／自动冷却／预算耗尽／授权失效 | 按实际原因展示等待或不可验证；不缩短间隔、清零预算、延长期限或自动重试探测 |
|
||||
| 人工暂停、模式OFF、复核暂停、服务正在切换 | 保留暂停；允许准备代码和离线对照，运行取样等后续启用，不为验证开启采集或重启服务 |
|
||||
| 证据缺失／前后冲突／许可结果未知／版本不一致 | 返回“状态待确认”和缺失证据，禁止主动核验；不把未知解释为安全空闲 |
|
||||
| 已确认空闲且无在途／遗留未结许可，账号预算及授权均有效 | 如确需补验，只通过现有持久账号预算和统一出口领取一次性许可，最多一单的列表＋详情共2次；空闲检查不能代替发请求时的原子许可校验 |
|
||||
|
||||
旁路取样必须默认关闭，使用一次有上限的验证会话。会话冻结范围、开始／截止时间、最多100个完整配对订单、接收记录及字节上限；建议最长30分钟，到期或首次预报／实出差异即结束本次捕获，没有差异也按“未命中”结束。不能每次轮询、翻页、重试或重启重置额度。字段来自同一次来源采集代次，配对键至少包含账号／仓库／货主／单号／SKU与观测证据；同单同SKU多行以十进制数量汇总，缺值保留未知，不能按总件数相等掩盖SKU替换或缺行。
|
||||
|
||||
诊断字段与业务事实分离，不改变业务内容摘要、修订号、任务就绪条件、归并、发布或现有返回状态。捕获失败、配对超时、存储满时停止诊断并记录脱敏原因，不能让正常采集失败，也不能无限缓存或同步写大量日志。不得保存原始全响应、面单、地址或凭据；三值与必要业务身份仅留在受控诊断存储，文档和报告使用样本别名。
|
||||
|
||||
最小代码范围是 Integration 列表／详情响应映射旁的白名单观察、独立有界配对组件及直接测试。优先在 Integration 层完成三值观察，避免为了找样本修改 Lastleg 业务事实表；如必须新增字段传递或内部诊断合同，先声明精确 DTO／调用方／OpenAPI 影响，再由唯一写者同步。不改 Egress 的预算、许可、限流逻辑或已经冻结的持续采集候选，不新增公开绕过出口的接口。开发可以在当前工作区完成，发布需另按当前授权协调；不能把“新增代码不影响运行”扩大成“重启后无损”。
|
||||
|
||||
交付须分别给出：采集状态证据和是否具备取样条件；三值对照的有界实现与离线测试；真实差异样本是否命中；额外供应商请求数；是否可以替代及尚未覆盖的边界。至少测试预报10／实际8且列表分别为10和8、SKU集合不一致、重复行、部分字段缺失、跨代次拒配、取消单、会话到期／上限、诊断失败不影响业务返回、暂停／429／许可未知不发请求。没有真实差异样本时只能交付验证能力，不能宣称字段语义已证实。
|
||||
|
||||
已实测当前取消单可查详情，且正常单、取消单均可按单号重新定位；实际改仓后的旧三标识行为尚无样本。若旧仓三标识无法取得详情，使用出库分页的按单重新定位方式，以下为合成业务参数：
|
||||
|
||||
```json
|
||||
{"current": 1, "size": 10, "deliveryNo": "DO-DEMO-001"}
|
||||
```
|
||||
|
||||
官方业务 Schema 没有将时间参数和 `status` 列为必填。2026-10-12 的正常、取消两个样本均省略这些字段，分别返回唯一同货主、同单号记录；样本未受到默认已出库过滤。必须读完返回页、逐条校验单号完全一致及货主身份，再取当前仓库查详情；不能只按模糊单号命中就迁移事实。无结果、权限失败、多个身份冲突均进入待核对，不认定取消、不清零。
|
||||
|
||||
当前 Java 已有独立的 `/outbound-orders/locate` 入口和按单定位请求 DTO，不传时间／状态条件；默认摘要发现接口仍用于状态 100 的新单发现，不能用它替代取消定位。新单发现和已知单修订复核使用不同查询意图，仍共用账号限流和签名器。该源码能力仍须完成内部 HTTP 和编排验收。当前取消样本的详情仍有实际数量 `1`，但 `outboundTime` 为空；必须先按状态和有效出库时间判定，不因数量大于零计入销量，也不能据此证明该单过去已经出库。
|
||||
|
||||
## 仓库发现和分仓配置
|
||||
|
||||
用户已确认按仓库分别采集和管理时效。先调用 [正常仓库列表](https://apidoc-omp.xlwms.com/reference/post_openapi-v2-warehouse-page-1.md)：
|
||||
|
||||
```json
|
||||
{"current": 1, "size": 1000}
|
||||
```
|
||||
|
||||
请求路径为 `/openapi/v2/warehouse/page`，业务入参 `current` 默认 1、`size` 默认 10、最大 1000。可按 `whCode`、`whNameCn`、`countryCode` 筛选，但一期发现当前全部正常仓库时不传过滤。接口没有 `status` 请求参数，也不要因为业务是“自营”就添加 `warehouseType=0`，自营商品可能存放在代理仓。
|
||||
|
||||
响应分页字段是 **`data.page/pageSize/pages/total`**，不是产品库存的 `current/size`；2026-10-12 已实测这一差异。每行保留 `whCode`、`whNameCn`、`warehouseType`、`status`、`timeZone`；不用仓库地址、联系人或联系方式。`warehouseType` 为 0 自营仓、1 代理仓；`status` 为 0 正常、1 停用、2 冻结，但该接口只返回正常仓库，缺失仓不能解释为“库存归零”。
|
||||
|
||||
仓库编号是任务、快照、时效与未来预警规则的必需维度。每仓保存来源时区、报表时区、出库计划、库存计划及过期阈值；本期两个时区字段均已确认填写 `Asia/Shanghai`，每天北京时间 08:00／20:00 出库、建议每天北京时间 08:00 库存。返回的 `timeZone` 只是仓库所在地资料，不覆盖领星已转换好的北京时间。某仓失败不阻止另一仓发布完整库存，不能用成功仓的采集时间刷新失败仓。
|
||||
|
||||
## 产品库存分页
|
||||
|
||||
[官方产品库存说明](https://apidoc-omp.xlwms.com/reference/post_openapi-v2-stock-stocksku-page-1.md)与管理端「产品库存－库存信息」口径一致。库存接口没有日期筛选，也不使用出库的最近两个月窗口。
|
||||
|
||||
正式任务必须按仓发送 `whCode`，以下是单仓全量产品库存 `data` 模板：
|
||||
|
||||
```json
|
||||
{
|
||||
"current": 1,
|
||||
"size": 1000,
|
||||
"whCode": "WH-DEMO",
|
||||
"isHideInventory": 0
|
||||
}
|
||||
```
|
||||
|
||||
对每个已确认仓库独立从第 1 页读完，每页只增加 `current`，同仓其他参数保持一致。**不传 `productQuality`，采集正品和次品；不设置 SKU、数量、预警或品类过滤。** 该仓全部货主均纳入，正常全量不传 `customerCode`；它只用于定向核验。每仓独立记录执行状态、覆盖范围、采集起止和发布版本，统计只使用正品 `productQuality=0` 的可用库存。
|
||||
|
||||
| 参数 | 类型 | 官方规则与使用方式 |
|
||||
| --- | --- | --- |
|
||||
| `current`、`size` | integer | 默认 1、10；每页最大 1000 |
|
||||
| `customerCode`、`whCode` | string | 官方均未标必填，实测可省略；本平台分仓采集要求 `whCode` 必填，`customerCode` 可省略读取该仓全部货主 |
|
||||
| `whCodeList` | string[] | 仓库列表，最多 500；不要同时混用单仓与多仓参数，优先关系未核验 |
|
||||
| `productQuality` | integer | `0` 正品、`1` 次品；全量不传，专题查询可传 |
|
||||
| `isHideInventory` | integer | `0` 保留零库存，`1` 隐藏；正式全量必须为 0 |
|
||||
| `barcode`、`barcodeAccurate`、`barcodeList` | string、string、string[] | 模糊／精确检索；列表最多 500。官方名称 Barcode 与列表说明“SKU”不一致，未经单 SKU 实测不得用于生产过滤；全量不传 |
|
||||
| `productName`、`categoryIdList` | string、string[] | 商品名、品类过滤；品类最多 500；全量不传 |
|
||||
| `stockValueType`、`startValue`、`endValue` | string | 数量过滤；类型为 `stkQty/freezeQty/useStkQty`，边界开闭未说明；全量不传 |
|
||||
| `sortName`、`sortOrder` | string | 数量排序，方向 `asc/desc`；无稳定快照或唯一排序保证，不能靠排序解决翻页期间变动 |
|
||||
| `stockStatus` | integer | `0` 无预警、`1` 预警；全量不传 |
|
||||
|
||||
返回是 `data.records[]`，分页元数据是 `data.current/size/total/pages`。主体字段都在每条记录的第一层：
|
||||
|
||||
| 字段 | 类型与映射 |
|
||||
| --- | --- |
|
||||
| `customerCode`、`whCode`、`productSku` | string；与来源账号、品质一起构成候选业务键 |
|
||||
| `productName` | string；展示信息，不作为唯一键 |
|
||||
| `productQuality` | integer；分别保存正品、次品 |
|
||||
| `stkQty` | number；实物库存 |
|
||||
| `freezeQty` | number；冻结库存 |
|
||||
| `useStkQty` | number；可用库存，正品该值用作可售量，不再次扣冻结 |
|
||||
| `transitQty` | number；在途，单独保存，不计入当前可售量 |
|
||||
| `innerBatchNo`、`outBatchNo` | string；批次线索，空字符串保留为空；不能未经核验据其拆分库存粒度 |
|
||||
| `uniqueKey4tenant` | string；只作来源核对，不拆解它替代明确维度 |
|
||||
| `stockCompare` | object；代理仓对比信息，不与本行数量相加；其中 `refreshTime` 不是主体库存采集时间 |
|
||||
|
||||
数量使用 BigDecimal／数据库 DECIMAL；不能强转 int、截断小数或将 `""`、null、缺字段自动转换为 0。官方统一空值规则可能把数值 null 输出成空串或 0，API 数值 0 仅能证明“接口报告零”，首次正式验收仍须与领星页面核对。接口缺行不证明库存为零。
|
||||
|
||||
## 后续库龄数据入口
|
||||
|
||||
[官方批次库存分页](https://apidoc-omp.xlwms.com/reference/post_openapi-v2-stock-batch-page-1.md)公开 `POST /openapi/v2/stock/batch/page`，对应 SKU 批次库存，不是整箱库存。可作为后续真实库龄核验入口，已核对的公开字段如下：
|
||||
|
||||
| 字段 | 官方含义与类型 |
|
||||
| --- | --- |
|
||||
| `stockAge` | integer，库龄天数 |
|
||||
| `putawayDate` | string，上架日期 |
|
||||
| `stkQty` | number，在库数量 |
|
||||
| `customerCode`、`whCode`、`productSku`、`productQuality` | 货主、仓库、SKU 与品质；前三者为 string，品质为 integer |
|
||||
| `sysBatchNo`、`batchNo`、`innerBatchNo`、`outBatchNo`、`relateOrderNo` | string，系统批次、上架批次、内部／外部批次及关联入库单号 |
|
||||
|
||||
该接口尚未实测账号权限、字段非空覆盖和分页完整性；还需确认库龄起算、移仓／退货是否重置、不同视图及库位是否重复汇总，并按同一货主、仓库、SKU、品质与产品库存对账。现有产品库存样本的批次字段为空，不能代替此接口验证，也不能用首次同步日补造真实库龄。领星 `stockAgeStatus` 的规则尚未核准，不直接作为本平台的滞销判断或评级。
|
||||
|
||||
本节仅登记后续待核验能力，不是本轮一期必交代码，不默认接入生产；一期仍使用现有出库与产品库存链路，本次不新增真实请求。后续核验沿用账号独占、同一会话共享请求预算及遇限流即停规则，不另开预算或自动全量补采。用途仍为自营业务内部评估与仓储成本分摊，不用于对外客户收费。
|
||||
|
||||
## 成功、失败和契约差异
|
||||
|
||||
2026-10-12 出库分页、详情和产品库存已观察到成功包络为数值 `code=200`、`data` 和 `msg`，没有 `success`，与官方 BaseResponse 的 required 声明不同。解析规则为：
|
||||
|
||||
1. HTTP 200 只是传输成功；仍检查 JSON `code` 为数值 200。
|
||||
2. `success` 缺失时继续校验数据结构；存在时必须是布尔 true，false、null 或字符串均拒绝。
|
||||
3. 分页必须有有效 `records` 数组和可核验分页元数据；详情必须是对象并核验主体身份与 SKU 明细。当前 Java `mappedPage` 已要求 `total/current/size/pages` 并校验页数和本页行数；完整批次仍须由 Lastleg 跨页检查唯一业务键、页间总数变化及应有页数，不能由单页适配成功推定全量成功。
|
||||
4. 官方认证错误可使用字符串错误码；保留数值错误码和固定错误分类，原始 `msg` 不直接输出日志或用户界面。认证失败不当作空页。
|
||||
5. 测试验证遇 HTTP 429／明确限流码立即停止整轮会话，不自动重试；正式任务交回账号协调器统一冷却后有限退避，不由各接口独立重试。超时等失败也消耗原预算；权限与验签错误停止盲目重试。没有验证的配额与历史限制保留为待确认项。
|
||||
|
||||
**出库分页空结果的已验证例外**：请求 `current=1,size=100`、时间窗口明确不包含目标单时，成功响应为 `records=[]、total=0、pages=0、current=1、size=10`。它把空页条数恢复为默认 10。可仅在这组完整空结果条件同时成立、且本次请求为第一页时归一化内部 `size` 为请求值，保留源分页元数据作为诊断；不能因此判失败。非空页、总数缺失、后续页异常或其他结构错误仍严格拒绝；未经验证不能把例外推广到库存或仓库接口。首次探针因严格回显检查中止，针对空结果核验后完成后续测试，这不是供应商业务请求失败。
|
||||
|
||||
成功响应示例为合成数据，展示的不是实际业务记录：
|
||||
|
||||
```json
|
||||
{
|
||||
"code": 200,
|
||||
"msg": "操作成功",
|
||||
"data": {
|
||||
"current": 1, "size": 1000, "total": 1, "pages": 1,
|
||||
"records": [{
|
||||
"customerCode": "CUSTOMER-DEMO", "whCode": "WH-DEMO",
|
||||
"productSku": "SKU-DEMO", "productQuality": 0,
|
||||
"stkQty": 120.0, "freezeQty": 20.0,
|
||||
"useStkQty": 100.0, "transitQty": 30.0
|
||||
}]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
这里的 `total` 是供应商 JSON number；经过现有平台 Long 序列化后，本地内部 API 的 `total` 为字符串，这是平台响应格式，不能据此要求供应商返回字符串。
|
||||
|
||||
## 联调证据与复现验收
|
||||
|
||||
截至 2026-10-12，出库分页通过本地 Java 服务验证；详情、仓库发现和库存使用同一组凭据及 OMP 签名直接执行只读 HTTPS 请求。临时探针与脱敏报告放在被 Git 忽略的 `integration-service/target/lingxing-local/`，只保留字段类型、数量、分页计数和核验结论，不保存密钥、签名或完整原始响应。这些临时文件可被构建清理，开发依据以本手册记录为准。
|
||||
|
||||
| 项目 | 已验证内容 | 不能由此推定 |
|
||||
| --- | --- | --- |
|
||||
| 一件代发分页 | 本地 Java 已取得一条状态 100 的摘要；使用出库时间最近一个月窗口 | 整月已完成采集、时间区间完整 |
|
||||
| 一件代发详情 | 对同一单传齐仓库、货主、出库单号，HTTP 200、业务码 200；`skuVOList` 返回一行，实出和预报数量均为数值 1 | 所有单都单 SKU、预报永远等于实出；北京时间口径来自后续用户确认，不由 HTTP 成功推定 |
|
||||
| 产品库存样本 | 不传货主、仓库、品质，`current=1,size=2,isHideInventory=0` 返回两行；四种数量是 JSON number，零库存能返回 | 所有空值语义、同一时刻快照；自营范围由用户另外确认 |
|
||||
| 产品库存两轮全集核验 | 北京时间 15:30:32—15:32:24，每轮 7 页、6,635 条；两轮业务键与四种数量一致 | 永久稳定排序、跨页原子快照、已持久化业务库存 |
|
||||
| 正常仓库发现 | 返回 2 个仓库；分页元数据为 `page/pageSize`，仓库资料有 `timeZone` | 接口时间必定使用仓库时区、未来停用仓可直接清零 |
|
||||
| 定向库存筛选 | 用样本货主＋仓库查询，返回记录均属于所请求的货主与仓库 | 同仓全量只需该货主，或其他货主不属于自营 |
|
||||
| 按仓全分页 | 分别带两个实际 `whCode` 查询，每页 1000，合计 7 页、6,635 条；每行都属于所请求仓库，分别通过总数与业务键核验 | 跨仓为同一原子时刻、时区已完成业务对账 |
|
||||
|
||||
全集核验的 6,635 是“货主＋仓库＋SKU＋品质”库存记录数，不是商品件数，也不等于去重后的 SKU 数。两轮均为正品 6,293 行、次品 342 行；实物为零 3,278 行、实物大于零 3,357 行。未观察到重复业务键、缺失主体身份、四种数量类型异常或负数；样本全集的批次字段均为空，`stockCompare` 均为空对象，因此非空批次和代理仓对比仍待专项样本。用户随后确认全部 70 个货主、2 个仓库纳入自营，并要求正式采集按仓执行。
|
||||
|
||||
2026-10-12 北京时间 15:43:18—15:44:09 的按仓结果如下。仓库 A／B 是文档脱敏别名，不可作为请求中的 `whCode`；实际编码必须从仓库目录或受控配置读取。
|
||||
|
||||
| 仓库 | 仓库资料时区 | 页数 | 库存记录 | 正品／次品记录 | 零实物记录 | 涉及货主 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| A | `America/New_York` | 1 | 894 | 892／2 | 280 | 15 |
|
||||
| B | `America/Los_Angeles` | 6 | 5,741 | 5,401／340 | 2,998 | 69 |
|
||||
|
||||
表中美国时区为接口实际返回的仓库资料，保留原值作为证据；两仓的出库返回时间和本期统计口径仍统一为用户确认的北京时间，不按这两个资料值分别转换。
|
||||
|
||||
两仓合计与先前账号全集相符；货主可跨仓出现，15＋69 不能作为去重货主数。首次分仓尝试遇到临时网络错误，未视为成功；随后重跑完整分仓读取成功。正式同步必须同样区分失败尝试和已发布完整批次。以上核验只读入内存并保存脱敏统计，没有导入业务表，也没有新增 Java 库存 API。
|
||||
|
||||
### 2026-10-12 追加前置验证
|
||||
|
||||
用户要求继续验证后，本轮继续直接串行请求 OMP，最小请求起始间隔 1.1 秒，不制造业务变更、不做限流压测。以下 API 验证发生时尚未取得用户的时区确认，也未完成页面对账；用户随后确认领星返回值已是北京时间，当前按本手册开头的 `Asia/Shanghai` 口径执行。该用户确认与下列只读实测证据分别记录。
|
||||
|
||||
| 验证项 | 本次结果 | 保留的限制 |
|
||||
| --- | --- | --- |
|
||||
| 正常单按号定位 | 省略时间与状态，返回唯一同货主、同单号的状态 100 记录；三标识详情一致 | 不保证模糊输入或同号跨货主也唯一，仍须逐条核验 |
|
||||
| 出库不同页大小 | 源字符串窗口 `2026-10-10 01:00:00` 至 `02:00:00`，size=124／125 均 3 页、372 个唯一单据；两轮单号集合及仓库／状态／出库时间摘要相同 | 不是 UTC 区间证明，也不是原子快照或永久稳定分页承诺；没有页面导出对账 |
|
||||
| 秒级边界 | 一个已出库样本：宽窗前后复读均命中；以该时刻为起点、终点均命中；严格前一秒与后一秒窗口均不命中。六次结果均全量、唯一且单号准确 | 仅观察到该样本两端包含；尚未覆盖另一仓、其他时间类型或北京时间午夜边界 |
|
||||
| 空结果分页 | 两个不相交窗口都返回 `records=[]、total=0、pages=0、current=1、size=10`，请求 size=100 | 仅按前述严格条件归一化；不能放宽非空页、库存页或后续页 |
|
||||
| 多 SKU 详情 | 另取 5 条已出库单，分别有 4、4、3、3、2 个 SKU；身份、数量类型与列表出库时间一致，实际量均等于预报量 | 未观察到同 SKU 多行、实出少于预报或部分出库，不把缺少样本标为通过；单位仍需业务核对 |
|
||||
| 当前取消单 | 近月创建时间查询的取消目录报告 163 条；抽查列表的 20 行均状态99，读取其中1条详情也为99，按号无时间／状态定位仍唯一命中 | 该样本实际数量1、出库时间为空，不能证明过去已出库；改仓及“出库后再撤销”仍无前后证据 |
|
||||
| 详情耗时 | 7 次详情耗时约 1.09—2.63 秒，平均约 1.57 秒 | 只是小样本观测，不是配额、容量或首采完成时间承诺 |
|
||||
| 实际限流与退避 | 串行、最小起始间隔1.1秒下，仍观察到1次出库分页 HTTP429；有限退避后的第二次请求为 HTTP200、业务码200 | 未刻意压测；不能由一次429反推准确阈值，也不能将1.1秒间隔视为已确认的安全持续速率 |
|
||||
| A 仓库存分页 | size=298／299 各3页、各894个唯一业务键，集合和四种数量一致 | 仍为采集区间观测 |
|
||||
| B 仓库存反例 | size=999 时6页、5,741个唯一键；随后 size=1000 返回5,741行，但只有5,740个唯一键，发现1个重复键，两轮集合不同 | **该次尝试完整性失败，不能发布。** 原因尚不能区分业务变化与非稳定排序，不删除异常证据 |
|
||||
| B 仓完整重试 | 再从第一页以 size=1000 完整读取两轮，各6页、5,741个唯一键；无重复、集合和四种数量一致 | 证明本次可恢复，不证明供应商分页永久稳定；不是将前后数据拼起来凑齐 |
|
||||
|
||||
出库与详情验证于北京时间 16:25:37—16:26:31 完成；两仓不同页大小核验于 16:27:57—16:29:22 完成；B 仓完整重读于 16:32:40 完成。脱敏报告分别为忽略目录中的 `prerequisites-20261012T082631Z.json`、`prerequisites-20261012T082922Z.json`、`prerequisites-20261012T083240Z.json`；前一次空页严格校验中止记录另保留，不能混记为成功。
|
||||
|
||||
验收必须覆盖两个实际用例：出库合法空页不误报失败；库存总数与返回行数相同、但唯一键少 1 时仍整批拒绝并重试。当前 `LingxingWmsClient` 已包含限定的出库空页例外：请求首分页 `size=100`，来源 `current=1,size=10,total=0,pages=0,records=[]` 时允许通过，其余页大小不匹配仍拒绝。此处仅更新源码事实，未重新运行 Java 或批次验收；既有直接 HTTP 联调证据与当前适配器验证应分别记录。
|
||||
|
||||
公开官方资料专项核对未找到账号 QPS／每日配额、时间戳容许误差、源出库时区、历史保留或最大更正期限的明确值。官方 `requestDeliveryTime` 的北京时间说明不能单独外推给 `outboundTime`；本期出库北京时间口径采用用户的明确确认，不再列为待选时区。供应商仍需补充列表／详情保留期限、已出库后撤销与改仓是否允许及查询方式、账号请求配额，以及稳定分页能力。当前低频调用成功不能代替这些确认。
|
||||
|
||||
后续复验先检查账号独占和整轮预算；不直接开启当前会自动规划正式首采的执行开关：
|
||||
|
||||
1. 先完成离线签名、异常脱敏、预算耗尽及用途隔离测试，确认原采集环境已停止且在途请求排空。在独占验证窗口内只读读取配置、不回显值，用 `size=1` 的出库分页和 `size=2` 的产品库存开始，足够即停。保存业务参数模板、时间、HTTP/业务码、字段类型和已用预算。
|
||||
2. 用分页同一行的三个业务标识查详情，核对实际 SKU 数量和创建／出库时间字段；与领星页面同单对账。禁止把包裹数量重复累加。
|
||||
3. 以已确认的当前账号全部 70 个货主、2 个仓库建立范围版本；按仓库目录取得实际编码，核验带 `whCode` 返回的每行仓库一致。仓库目录或业务范围变化要重新验证覆盖，不将 70／2 固定在代码中。
|
||||
4. 测试只在原会话预算内翻少量页、读取有限详情，并记录 `total/pages`、实际行数、唯一键与停止原因；达到预算或遇到限流即停止，不为凑齐某种样本继续搜索。不完整库存不得发布、补零或触发缺行占位。
|
||||
5. 重复键、缺页、总量变化、断点恢复、事实归并和版本发布先用离线合成数据验证。2026-10-13 用户确认库存按每仓一轮完整分页观测，取消两轮数量完全一致的发布前提；正式受控任务保存每仓真实采集区间和完整性证据。所有页、唯一业务键、总量、范围及数量校验仍须通过，不拼接失败批次，不承诺跨页原子快照。历史两轮核验仅证明当次观测结果，出库目录规则不变。
|
||||
6. 对本次预算内已有的正品、零库存、次品、冻结、在途样本进行相同筛选的页面核对；未取到的场景留待合成用例或正式生产验收，不追加无上限查询。结束验证后关闭该环境真实出口，再交还账号给正式采集。
|
||||
|
||||
来源与统计时区已确认采用北京时间；实现仍需验证北京时间午夜边界与内部 UTC 存储不改变业务日期，订单历史修正期限、稳定分页和实际账号限流仍需供应商或人工对账确认。库存 API 没有历史时点参数，不能用当前查询补造昨日库存。开发可以从适配、暂存及分仓任务开始；正式启用标准统一见[一期方案的开发准入与正式启用门槛](领星一件代发数据统计一期方案.md#开发准入与正式启用门槛)，本手册的成功样本不替代这些门槛。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,278 @@
|
||||
# 领星统计查询性能优化方案
|
||||
|
||||
面向平台销售开发总控，当前先完成功能、真实数据正确性及人工页面确认，并发优化后置。本文维护后续性能专项规划，不触发代码修改、真实采集或压测，不把新增诊断任务变成功能联调的前置条件；页面不可用、请求超时或数据错误仍按功能问题处理。
|
||||
|
||||
性能专项恢复时，按“复用完整基线与诊断 → 验证有证据的新候选 → 全场景验收”推进。窄投影、profile 归并和延后商品名称均已试验，未显示稳定收益，移出默认实施顺序；只有新的执行计划证据表明问题或条件发生实质变化时才考虑重测。每次只验证一项主要改动，保留结果一致性与执行计划证据。
|
||||
|
||||
本文为 2026-10-13 的查询优化执行方案，只交付文档，不修改代码或操作环境。业务口径、版本保护及验收目标继续以[一期主方案](领星一件代发数据统计一期方案.md)和[经营总览图表设计](经营总览图表设计.md)为准；本文不另建部署状态或验收进度台账。开发安排由[平台销售总控](codex://threads/01a12feb-0474-77f1-afe0-a3b491733dca)统一收口。
|
||||
|
||||
用户本轮追加的领星获取速度、重复请求与等待开销只读梳理，统一维护在[采集速度优化顺序](#采集速度优化顺序)。它与前述经营查询 SQL 优化分开，不因本次梳理调整正在运行的采集任务或提高账号出口并发。
|
||||
|
||||
## 对照基线与问题判断
|
||||
|
||||
以[库存索引倒序优化后的完整压测](../../baiyue-firstleg/reports/selfop-test-20261013/selfop-perf-read-r5-inventory-seek-r2-result.json)为本次核对取得的较新基线。该轮于北京时间 2026-10-13 10:29 结束，合成数据共 11,968,200 条 SKU 日行，包含多个版本；不能把这个总量当作单仓单版本行数。10 个并发用户持续约 301 秒，总览和销量各完成 664 次、默认库存完成 663 次，共 1,991 次，无请求错误。
|
||||
|
||||
| 查询路径 | P50 | P95 | P99 | 现行 P95 目标 |
|
||||
| --- | ---: | ---: | ---: | ---: |
|
||||
| 经营总览近 15 天 | 2,732 ms | 3,107 ms | 3,275 ms | ≤1,500 ms，未达标 |
|
||||
| SKU 销量近 15 天 | 1,150 ms | 1,382 ms | 1,489 ms | ≤1,000 ms，未达标 |
|
||||
| 默认库存列表 | 613 ms | 774 ms | 849 ms | ≤1,000 ms，该场景达标 |
|
||||
|
||||
[此前仓库日汇总后的报告](../../baiyue-firstleg/reports/selfop-test-20261013/selfop-perf-read-r5-warehouse-daily-r1-result.json)中，三个路径的 P95 分别为 3,169、1,412、1,092 ms。保留它作为前后对照，不能继续将默认库存写成尚未达到 1 秒，也不能把默认列表通过扩大为所有关注筛选、排序和下钻均已通过。
|
||||
|
||||
常用路径稳定性通过不代表完整性能验收通过。该压测报告仍列有未验证项；后续[分段诊断摘要](../../baiyue-firstleg/reports/selfop-test-20261013/selfop-query-timing-r4-summary.json)补充了 SQL 次数与阶段耗时采样，不能再把这项写成完全未开始。后台候选构建并行、构建增长成本、复杂筛选及原单增长不影响查询等仍需专项证据。旧销量版本的 366 天 SKU 清单在较早报告中有约 7.30／7.39 秒的单次抽样，后续需复核；单次结果不能当作 P95。
|
||||
|
||||
已完成且输入条件一致的基线与诊断直接复用，中途停止的压测不算完整基线。恢复性能专项后，先核对期间功能修复是否改变查询 SQL、索引、数据集、版本和资源条件，再决定是否需要更新基线，不因本文更新原样重跑。以上为固定证据快照，后续实际部署和验收状态仍由现行主契约维护。
|
||||
|
||||
## 保留已有优化
|
||||
|
||||
当前代码已具备以下能力，不再作为待从零实现的任务：
|
||||
|
||||
| 已有能力 | 代码入口 | 本轮处理 |
|
||||
| --- | --- | --- |
|
||||
| 趋势读取已发布仓库日汇总，进入查询前验证就绪证据 | [DashboardReadMapper](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/query/DashboardReadMapper.java)、[DashboardQueryService](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/query/DashboardQueryService.java) | 保留，不再让趋势扫描所有 SKU 日行 |
|
||||
| 一次 report 返回统计和三个 Top 10，共享 SKU 计算结果 | [DashboardReadSql](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/query/DashboardReadSql.java) 的 `report` | 保留共享计算，不拆成每张图独立扫描；窄投影按下文已试验结论处理 |
|
||||
| 默认库存按库存量先选页，再补该页销量；普通 ALL 计数只读候选身份 | [AnalyticsInventorySql](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/query/AnalyticsInventorySql.java) 的 `stockFirst`、`inventoryCount` | 保留轻量路径，不能被复杂筛选的通用方案拖慢 |
|
||||
| 默认库存最后出库日按现有索引倒序取首条 | 同上 `inventoryPage` | 复用上文已完成的并发结果；仅默认 ALL＋AVAILABLE_DESC 且无分桶／selection 的路径已采用，复杂筛选不能视作同时完成 |
|
||||
| SKU 销量清单先选分页键，再计算本页完整／部分／未知日数 | [AnalyticsReadSql](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/query/AnalyticsReadSql.java) 的 SUMMARY 分支 | 保留，不重新引入所有 SKU × 所有日期的展开 |
|
||||
| 库存过期或 30 日不完整时，总览跳过相应无用事实聚合 | `AnalyticsInventorySql.dashboardCte` | 保留，不能以资格不足场景的快速结果代替完整场景验收 |
|
||||
|
||||
查询已经有日表覆盖索引，不能仅凭慢就继续叠加相近索引。最多 366 个趋势点、30 条榜单记录的 Java 处理暂不列为优化重点。
|
||||
|
||||
## 复用分段诊断并限定剩余测量
|
||||
|
||||
分段诊断共 39 个请求，包含三个接口各 3 个单用户样本和各 10 个并发样本；它明确标为诊断用途、非 P95 验收。并发组的已观测结果如下，均为平均值：
|
||||
|
||||
| 路径 | 主要 SQL 阶段耗时 | 其他阶段与结论 |
|
||||
| --- | ---: | --- |
|
||||
| 总览 | report 约 3,028 ms | context 约 4 ms、daily 约 2 ms；优先研究全仓 SKU 聚合、分桶及榜单成本 |
|
||||
| SKU 销量 | page 约 1,166 ms | count 约 54 ms、context 约 4 ms；优先研究区间聚合与分页排序 |
|
||||
| 默认库存 | page 约 498 ms | count 约 48 ms、context 约 5 ms；保留已达标路径，后续做回归 |
|
||||
|
||||
三个接口在这组样本中均固定为 6 条统计读 SQL。诊断范围为 `ONLY_ANALYTICS_READ_MAPPERS`，不能将 6 条说成包含 IAM／鉴权等全部应用 SQL，也不能由小样本推断全部场景都不存在额外调用。采样已指出主要 SQL 成本；连接池等待、数据库资源竞争、写入重叠等仍按需要补证据，不再从头重复同一诊断。
|
||||
|
||||
固定同一数据集、代码版本、仓库、双统计版本、业务日期、覆盖证据和库存时效，分别记录以下阶段。跨午夜、库存过期、版本切换或测试数据重建后，需要重建可比基线。
|
||||
|
||||
| 请求 | 需要分开的耗时 |
|
||||
| --- | --- |
|
||||
| 总览 | 权限与 context 校验、仓库 daily、report、DTO 组装、序列化与 HTTP 总耗时 |
|
||||
| SKU 销量 | context、候选 count、分页及日量聚合、DTO／HTTP |
|
||||
| 库存 | context 与下钻资格、count、分页与最后出库日、DTO／HTTP |
|
||||
|
||||
每个代表 SQL 保存绑定参数范围、执行计划、实际行数／循环数／耗时、排序和临时表证据。对比 profile、snapshot、daily 各访问节点，确认共享 CTE 是否确实只构建一次。同一请求关联各阶段耗时，不能用两个阶段各自的 P95 相减估算成本。数据库总耗时还应与连接池等待、CPU、磁盘及同机负载对照，不能把 HTTP 与数据库耗时之差全部归给 Java 计算。
|
||||
|
||||
只采集当前测试需要的只读诊断；`EXPLAIN ANALYZE` 会真正执行查询，沿总控既有环境窗口安排，不和另一轮压测或构建竞争。诊断参数采用合成账号和业务编码，不在文档、日志或证据中写凭据及真实客户载荷。
|
||||
|
||||
候选方案先做相同输入的响应对照，再做单请求 SQL 对照；有一致且可解释的收益，才进入整轮 HTTP 压测。首次应用请求、预热和业务结果缓存命中分别标注，不把“首次应用请求”称为数据库磁盘冷启动；不为制造冷启动清理共享数据库缓存。
|
||||
|
||||
## 已试验方案与重试条件
|
||||
|
||||
依据[开发总控 2026-10-13 的后续性能反馈](codex://threads/01a12feb-0474-77f1-afe0-a3b491733dca)，以下三项已经测试，均未显示稳定收益。此处记录试验结论与选题边界，不把“尚无稳定收益”扩大成所有数据规模下永久无收益，也不编造提升比例。
|
||||
|
||||
| 方案 | 已有结论 | 默认处理 | 重新验证的前提 |
|
||||
| --- | --- | --- | --- |
|
||||
| 总览共享结果窄投影 | 已试验，未显示稳定收益 | 不再列为首选任务，不重复原样 A/B | 新执行计划显示宽字段确实造成主要临时表／去重成本，且能说明新方案与已测方案的实质差异 |
|
||||
| 两版 profile 归并以减少重复访问 | 已试验，未显示稳定收益 | 不再安排同一归并方案 | 新执行计划显示 profile 访问成为主要成本，并能指出访问路径、规模或归并方法相对既有试验发生的变化 |
|
||||
| 榜单确定后延后读取商品名称 | 后续已试验，未显示稳定收益 | 从待试新候选中移除，不再单独派工 | 新证据表明名称访问或携带名称的中间结果成为主要成本，且处理方式与已测方案存在实质差异 |
|
||||
|
||||
重试前先复用总控保留的代码版本、输入及计划证据，写清旧结论、新证据和本次差异。重新发布文档、换一个试验名称或重新出现同一静态代码建议，都不构成重试理由；已有试验详细证据需要核对时先核对记录，不直接重跑。
|
||||
|
||||
若满足上述前提，正确性边界仍保留：窄投影不能删除身份、分类、资格或排序所需字段，观察证据即使不展示也须参与上游计算；profile 归并须保留来源存在标记，区分“无该版记录”和“该版字段无效”，不能因 MAX／MIN 忽略空值而将未知改成有效。单位资格、编码比较、名称优先级及有效观察依据均不变，库存过期也不意味着其 profile 身份可删除。
|
||||
|
||||
## 后续集中处理两条主要慢查询
|
||||
|
||||
### 总览聚合与销量分页
|
||||
|
||||
总览以 report、销量以 page 为下一阶段的主要优化对象。对照已有计划核实日行扫描、聚合、排序及物化的实际工作量，先说明新方案具体减少哪一部分，而不是继续围绕已无收益的字段／名称调整。默认库存保留回归覆盖，不继续作为主要提速目标。
|
||||
|
||||
总览固定 30 日的重复计算与销量清单任意日期区间是两种需求，不能用只覆盖固定 30 日的结果替代今日、近 3 天、本周、近 15 天、本月及历史自定义区间。若要评估把重复计算移到版本构建阶段，按后文条件分支测算读取收益和构建成本，另行形成具体设计，不直接追加统计表。
|
||||
|
||||
连接池或线程数只有在等待和资源证据支持时才评估，不以增加请求并行度代替减少数据库工作量。每项候选均保留固定版本、全候选资格、未知值及排序语义，不提前裁掉 SKU 获得表面速度。
|
||||
|
||||
### 按实际成本审视物化方式
|
||||
|
||||
`DashboardReadSql.report` 的 DISTINCT 有阻止四个消费者重复展开计算的用途，不能直接删除。如果新的分段与执行计划证据显示共享结果的去重仍是主要成本，再核对既有试验，决定是否有值得验证的物化替代方案；不把 `NO_MERGE` 等提示自动当作尚未尝试的新方向，也不要求先重做窄投影。
|
||||
|
||||
任何替代方案都要证明统计与三个榜单仍共用一次聚合，没有将 daily／snapshot／profile 展开四次。计划不稳定或未显示可重复收益时，保留当前实现；不能仅凭提示写进 SQL 就认定生效。已试验方案若无实质变化，直接沿用既有结论。
|
||||
|
||||
## 减少复杂库存筛选的重复聚合
|
||||
|
||||
`AnalyticsQueryService.inventoryCoverage` 先调用 `inventoryCount`，再读取 `inventoryPage`。当条件依赖销量资格，例如无销量、可售天数、分桶或无法评估时，两次查询都会执行相近的完整候选计算。
|
||||
|
||||
分段测量若证实这两次聚合是相关路径的主要成本，再尝试一次共享候选：先在全候选上计算、筛选和排序，再从同一结果取得计数与当前页。执行计划须证明公共聚合只执行一次，仅抽取相同 SQL 字符串再调用两次不算共享。统计行应独立产生，即使结果为空或 offset 超出末页也返回真实 total，并且不能把统计占位行映射成伪 SKU 记录；不能仅依赖附在页记录上的 `COUNT(*) OVER()`，否则空页会丢失总数。响应 DTO 继续使用现有分页合同，不对前端引入第二套格式。
|
||||
|
||||
必须保留普通 ALL 的身份计数、冻结／次品关注的库存专用计数，以及默认库存先分页方案。**本项主要优化图表下钻和复杂筛选，不承诺降低基线中的 inventory-ALL 耗时。**
|
||||
|
||||
复杂筛选最后出库日仍可单独评估同一 SQL 内的页内索引倒序探测；它只补充展示，不参与筛选资格。保持固定销量版本、账号／仓库／货主／SKU、`business_date<=anchor`、PCS 正出库量及无匹配返回空值。对无销量或大量无效日行的 SKU 仍可能扫描较多行，不能承诺每个 SKU 必定只读取一行。
|
||||
|
||||
热销／滞销计数与分页也有类似重复计算，但只有定向测量证实不达标时再扩展，避免把本轮收敛变成全查询重写。
|
||||
|
||||
## 实测后再启用的方案
|
||||
|
||||
### 不完整或过期状态的快速路径
|
||||
|
||||
总览已跳过部分无用事实扫描。若“30 日不完整且库存过期”的场景仍耗时，可进一步评估只从固定 profile 身份生成候选数和未知统计，跳过空榜单计算。四种 `complete30 × stockFresh` 组合分别对照，零候选、未发布版本、未知原因优先级和七桶计数均须一致。
|
||||
|
||||
该项改善诊断状态响应，不能代替“30 日完整且库存新鲜”的正常经营查询优化，也不优先于总览正常路径。
|
||||
|
||||
### 固定版本结果的有界缓存
|
||||
|
||||
如果前述查询调整后仍未达标，再依据测量结果评估进程内有界缓存及同键并发请求合并，不默认新增 Redis 或缓存平台。总览 report 固定计算 30 日，切换趋势范围时存在复用机会；首先评估该稳定数据块，不缓存整页响应。
|
||||
|
||||
缓存键必须覆盖账号、仓库、全部实际访问范围、销量与库存版本、范围／修订摘要、固定日期窗、完整性和时效资格、规则版本。容量受条目数及内存预算限制，失败结果不作为正常数据缓存；发布、跨午夜、库存过期、修订屏障及旧版本不可读均须使相关复用失效。
|
||||
|
||||
每次请求仍在受控只读快照中完成权限、范围、版本可读性、覆盖和时效校验，重算实时状态。携带固定上下文的请求保留原 `queryAsOf`、业务日期锚点和 `queryExpiresAt`；下钻截止时间依据实际库存时效重算，并受原上下文有效期上限约束，不因缓存命中或翻页续期。一个旧缓存命中不能绕过被删除版本、待重建状态或过期库存的处理；同键请求合并不能把一个请求的上下文直接发给另一请求。
|
||||
|
||||
主方案明确要求无业务结果缓存的性能验收，本方案不修改该标准。缓存关闭、首次未命中、同键首次并发和命中分别报告；缓存收益只能作为额外体验改善。若无缓存始终不能达标，总控应提交剩余成本与方案取舍，不能自行以命中数据宣布通过。
|
||||
|
||||
本轮不新增固定 30 日 SKU 表、周月表或搜索引擎。若执行计划证明正常请求的全仓 SKU 聚合已是主要且无法继续压缩的成本，再单独评估发布时预计算的读取收益、构建增量成本、跨日期重算和原子发布规则；不能仅为省一次查询把可变结果写回已发布版本。
|
||||
|
||||
## 分开规划采集速度与查询并发
|
||||
|
||||
| 链路 | 记录的时间与吞吐 | 与其他链路的边界 |
|
||||
| --- | --- | --- |
|
||||
| 领星目录与逐单详情采集 | 配置间隔、实际请求起始间隔、请求耗时、成功明细数／分钟、429／冷却、剩余目录与详情请求量 | 统一账号级限流及环境独占；不能因有两个仓库就给每仓单独一份额度 |
|
||||
| 本地归并与统计候选构建 | 输入行量、批次量、构建阶段耗时、写入量、发布耗时及磁盘增长 | 使用已落库的事实；统计发布完成与详情下载完成分开记录 |
|
||||
| 页面查询 | 请求并发数、请求组合、实际完成请求数／秒、P50／P95／P99、错误率及各 SQL 耗时 | 读取已发布本地版本，10 个并发用户不等于固定 10 QPS，也不对应领星请求并发 |
|
||||
|
||||
总控在 2026-10-13 报告的账号串行小样本中，3／2／1 秒配置档各完成 20 次成功请求，对应平均详情请求间隔约 3.77／2.79／1.86 秒；0.5 秒配置档在约 735 ms 的两次详情请求间隔处出现 429 并停止。这证明配置等待和实际吞吐要分开测量，不能据此推导领星固定配额，也不能由 20 次成功认定可长期稳定维持该速率。总控选择的 1 秒配置不作为本方案的永久安全速率或新默认配额。
|
||||
|
||||
这些实测仅用于容量推算与解释来源等待。后续仍遵循[主方案的生产首采与测试请求边界](领星一件代发数据统计一期方案.md#生产首采与测试请求边界)及[接口联调手册](领星WMS接口联调手册.md)的账号预算、冷却和终止规则；本方案不发起新的限流探测，不增加真实采集并发，也不放宽原有请求预算。页面性能验证使用本地合成事实与统计数据。
|
||||
|
||||
采集预计完成时间应分为“剩余目录／详情获取、归并、构建、发布”四段。获取阶段根据实际成功吞吐及剩余请求量滚动估算，冷却和失败另计；不能仅用配置间隔乘单数给出整轮完成承诺，也不能因目录页拉完就显示销量已可用。页面分别展示已获取详情、已归并数量、构建阶段、最近完整发布版本及停止原因，沿用既有采集进度合同。
|
||||
|
||||
### 采集速度优化顺序
|
||||
|
||||
依据[接口专项的只读反馈](codex://threads/01a12f3f-c57a-79e1-9efa-9401f594544c)，本轮复核了当前工作区的获取、路由、等待和预算链路。结论是：**先减少每条详情之后重复执行的本地工作，再减少短间隔等待造成的恢复开销；扩大目录分页作为后续新任务的次要节省项。** 已定位的是源码中的工作量放大，还没有整轮分段耗时证据，不能宣称它已占总耗时的某个比例或承诺若干倍提速。
|
||||
|
||||
接口调用单位也要分清：一个出库单详情请求可以带回多个 SKU，当前不是每个 SKU 都发一次详情请求。出库目录由账号共享获取，再分仓处理；产品库存独立按仓全量分页，两条链路不混用过滤能力。
|
||||
|
||||
| 顺序 | 已核对的情况 | 候选改进与预期影响 |
|
||||
| --- | --- | --- |
|
||||
| 先保留基线 | 1 秒配置不等于 1 秒实际请求间隔；短样本约 1.86 秒还没有完整分段 | 用现有观测与本地合成回放拆分耗时，不增加领星限流探测；记录生效配置、代码快照及阶段规模 |
|
||||
| 优先 1 | 每拿到一条新详情即执行全量 `route(false)`；按仓逐个检查整批目录 | 保留首次等待任务登记与最终完整路由，中间不再每单重建全量子任务；减少本地查询与子任务写回，不改变必要详情 HTTP 数量 |
|
||||
| 优先 2 | 每次间隔不足可能退出任务、释放租约，随后恢复重新扫描 | 若分段证据确认短间隔让出频繁，评估事务外有界等待或准确的到点调度；减少额外恢复成本，不降低账号最小间隔 |
|
||||
| 随后核对 | 父 manifest 每次整批序列化、重新统计完成量并写回；恢复检查也从开头进行 | 先测累计 JSON 字节、检查点和恢复扫描成本；用可靠的增量计数、变更集合／有界批量减少重复工作，保持可恢复证据。取消全量路由不代表这部分自动消失 |
|
||||
| 后续新窗口 | 官方目录上限 1000，本地出库 Query DTO 与校验上限为 100 | 统一 DTO、适配校验、配置和冻结参数后再验证较大分页；只节省目录请求，不能中途改变已运行任务的分页参数 |
|
||||
| 条件分支 | 批量实际出库明细、可靠修改游标或变更推送尚无已确认合同 | 向供应商核实能力及字段等价性后再设计；这是可能显著减少详情 HTTP 的方向，不能现在直接替换现有来源 |
|
||||
|
||||
#### 已确认的本地放大点
|
||||
|
||||
[SelfopDiscoveryService](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/sync/SelfopDiscoveryService.java) 在详情处理前、每条新详情提交后和全部完成后调用 `route`。其中按配置仓库遍历完整 manifest，对每个对象点查旧订单；相关对象有有效详情时，再读取和解析 stage，并重建子任务 manifest。中途 `detailsResolved=false`，子任务仍等待来源，不会因为这些完整重算提前进入 READY。
|
||||
|
||||
设目录对象数为 N、仓库数为 W、本轮实际新增抓取详情数为 K，在不计恢复和修订的基础路径上，旧订单查询方法调用量约为 `W × N × (K + 2)`。代入 N=K=2,787、W=2，约 1,554.6 万次调用。**这是代码循环的条件推算，不是已测 SQL 次数或数据库全表扫描次数**；MyBatis 缓存、事务边界、恢复和分支都会影响实际 SQL 与耗时。首采 K 接近 N 时，这部分工作量近似平方增长。
|
||||
|
||||
`saveManifest` 还会序列化父任务整批对象、遍历完成数并更新 task/run；检查点读取包含 manifest 的 task 行，路由又为各仓写回完整 manifest。该成本需要单列。优化不能简单把持久检查点全部改成内存缓存，也不能不落库直到最后；可复用的 VALID stage、对应关联及提交边界必须可靠保留，进程中断不能丢失已取得的详情或错误复用旧版本。
|
||||
|
||||
首个最小改动可先减少路由频次，不急于换表或调度平台。最终路由再评估有界批量读取旧归属和有效 stage、每对象解析一次后按仓分组。保留旧仓＋新仓联合归属、取消／跨日期修订、`belongsToSlice`、租约栅栏及半归并屏障；全部详情确认前不能让空仓提前发布零量，已经 APPLYING／APPLIED／BLOCKED 的子任务不能被覆盖。页面等待关联和进度继续使用轻量投影，不靠重复全量路由维持可见性。
|
||||
|
||||
#### 额外等待不等于供应商请求时间
|
||||
|
||||
[SelfopEgressService](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/request/SelfopEgressService.java) 的 `ACCOUNT_INTERVAL_WAIT` 在发出领星 HTTP 前产生；[SelfopExecutionService](../../baiyue-firstleg/lastleg-service/src/main/java/com/baiyue/lastleg/selfoperated/analytics/sync/SelfopExecutionService.java) 将执行让出并释放租约。调度器 `fixedDelay=1000` 表示当前 tick 的同步任务处理结束后再等 1 秒，不是保证每秒准时启动。出库任务恢复还包含重新获取租约、建立尝试和读取／扫描 manifest。
|
||||
|
||||
[LingxingEgressGate](../../baiyue-firstleg/integration-service/src/main/java/com/baiyue/integration/provider/lingxing/LingxingEgressGate.java) 在实际 HTTP 开始前另有账号保护，只等待尚未满足的剩余间隔。HTTP、落库和路由也消耗时间，不能把两处配置间隔简单相加。Lastleg 的持久 `minIntervalMs` 采用旧值与配置值的较大者，配置改成 1000 也不能直接证明实际已按 1000 生效；应只读核对实际许可和 HTTP 时间，不为本次梳理清空保护状态。
|
||||
|
||||
短间隔优化仅针对可恢复的普通间隔等待：事务外有界等待后重新校验租约、截止时间、账号保护及预约资格。等待超界、限流冷却、会话预算耗尽和结果不确定仍走原有让出／暂停路径；不能持有数据库事务或行锁睡眠，不能无限占用唯一调度线程，不能为了减少尝试数跳过重新授权。是否使用短等待还是到点调度，由实测等待分布和调度公平性决定。
|
||||
|
||||
| 事件 | 领星真实 HTTP 与预算 |
|
||||
| --- | --- |
|
||||
| 预约前因最小间隔／冷却／在途被拒绝 | 不发领星 HTTP、不增加持久 HTTP 预留；此前本轮内存工作额度可能已消耗，需与请求预算分开统计 |
|
||||
| 成功预留后、发送前失败 | 可能没有真实 HTTP，但预留与根会话额度不自动退还；不能据 reserved 数认定已调用领星 |
|
||||
| 已开始的超时、429 或业务失败 | 消耗一次真实请求；有回执时按实际调用数确认，未知结果保持保守预留 |
|
||||
| 重试／重新定位／再取详情 | 每次均重新授权计额；当前 Integration 没有隐藏的供应商 HTTP 重试循环 |
|
||||
|
||||
内部 reserve／authorize／complete 通信也有成本，但不是领星请求。下一轮性能证据分别记录内部调用数、真实 HTTP 数、预留额度和确认额度，不用 run 次数或重试次数代替外部调用次数。
|
||||
|
||||
#### 哪些请求可以减少，哪些还不能省
|
||||
|
||||
官方[出库分页](https://apidoc-omp.xlwms.com/reference/post_openapi-v2-order-delivery-page-1.md)目前公开的请求字段没有仓库过滤，最大页大小为 1000；返回仓库编码不代表请求支持按仓筛选。按两个仓库重复扫同一账号目录不节省请求，当前账号共享采集设计应保留。
|
||||
|
||||
以 2,787 单、两个稳定目录扫描轮次、所有订单均需一次详情、无异常重试为例：每页 100 需要 56 次目录请求，每页 1000 需要 6 次；加上 2,787 次详情，总量约从 2,843 降到 2,793，少 50 次，约 1.8%。这里只是基础请求量推算，不含重新定位、修订、库存等；真实收益还受响应大小和分页稳定性影响。已经完成目录的当前任务，不会因扩大未来分页而加快剩余详情。
|
||||
|
||||
列表虽然有 `productList[].qty`，官方未明确它在部分出库、差异出库及后续修订中等同实际出库量；[详情](https://apidoc-omp.xlwms.com/reference/post_openapi-v2-order-delivery-detail-1.md)明确区分 `deliveryQty` 与 `actualDeliveryQty`。当前统计需要后者，不能仅因列表包含 SKU 和数量就删掉详情请求。列表的批量单号筛选也不等于批量实际明细。
|
||||
|
||||
已有有效详情且没有更新观测时，当前代码会跳过 HTTP；这项应保留，不再作为从零开发的优化。新的观测代次、身份失配或修订要求重新核实时，仍需读取或重新定位。当前公开时间筛选未确认可靠的修改时间游标，不能永久以“列表字段没变”判断详情无需复查，也不能删除第二轮目录稳定性核验来制造提速。
|
||||
|
||||
需要供应商确认的高价值问题是：已出库列表 qty 的完整语义、批量实际明细能力、带稳定游标的修改时间增量／变更推送、历史修订与取消范围，以及账号级／接口级速率、突发和在途限制。当前未找到已确认能力不等于供应商没有这些能力；取得契约与针对性对账证据后，才能评估替换详情链路的收益。本轮不联系供应商、不增加试探调用。
|
||||
|
||||
#### 最小测量与验收
|
||||
|
||||
先复用已有日志和只读统计。缺少的分段埋点留给后续开发工作包，不为测量新增真实采集、加大并发或反复重跑已完成日期。每轮证据关联同一任务、尝试和出站许可，保留代码版本、N／W／K、复用比例、生效间隔、已发布覆盖、同机负载及预算边界。
|
||||
|
||||
| 测量组 | 必须区分的指标 |
|
||||
| --- | --- |
|
||||
| 外部调用 | 各接口 HTTP 数、实际起始间隔、HTTP 耗时、成功新增详情／分钟、429／超时；复用完成量不算新增下载速度 |
|
||||
| 调度与保护 | 最小间隔拒绝数、可再次尝试时刻、到点至实际恢复的延迟、租约获取／begin 耗时、内部授权／完成回执耗时 |
|
||||
| 本地处理 | 详情检查点、route、最终路由、归并／构建／发布分别计时；订单／stage 方法调用与实际 SQL 次数分别记录 |
|
||||
| 序列化与恢复 | manifest 大小、累计编码／解码字节、子任务写回次数、恢复重扫对象数、峰值内存和数据库连接等待 |
|
||||
|
||||
实际 HTTP 起始间隔、详情提交间隔和整阶段耗时分别报告；用同一请求链中不重叠的时间段解释墙钟耗时，不将互相覆盖的保护等待重复相加。先回答本地重复工作、外部等待各占多少，再决定线程数、连接池或并发调整；短样本不能证明长期限额。
|
||||
|
||||
离线对照建议固定 N=100／1,000／3,000、W=1／2，使用假领星 Client 和计数 Mapper，比较优化前后的必要 HTTP 数、route 次数、查询调用、JSON 字节、子任务写回和最终结果。覆盖部分恢复、全部复用、新观测强制复查、跨仓、取消、时间切片、零单、提交回滚、租约失效、等待超界及冷却。证明减少工作量且结果／恢复语义等价后，再按总控有效授权验证实际数据库耗时与整阶段吞吐；离线替身耗时不能冒充数据库提速。
|
||||
|
||||
本轮不承诺减少必需详情数量，不修改正在运行任务的分页、租约和会话预算，不为赶速度增加账号并发。采集页改版仍按已确认设计推进；这些采集性能候选由总控另行安排，不能把未经测量的优化变成当前页面交付的前置条件。
|
||||
|
||||
## 真实数据覆盖与容量样本用途
|
||||
|
||||
此前几分钟的真实销量样本只能验证局部链路。总控为功能验证补采的两仓单日 2,014 单，也必须完成目录核对、详情获取、归并与覆盖／发布校验后，才能用于判断对应日期的结果；目录数量相同或 HTTP 全部成功本身不证明业务日完整。
|
||||
|
||||
一个日期的数据完整不代表最近 30 日完整，也不自动补足每个 SKU 的观察期。相应平均销量、可售天数、无销量结论及榜单资格仍按主方案判定；不能为让页面出现数字把未覆盖日补零。真实功能样本与合成容量数据分别标注账号范围、仓库、统计版本、覆盖区间、观察依据及库存新鲜度。
|
||||
|
||||
功能核验可先使用真实单日结果，并用已有合成数据检查完整 30 日榜单、边界和下钻。容量验收必须包含“30 日完整且库存新鲜”的正常经营路径；观察不足或库存过期导致跳过聚合的快速响应仅代表该状态，不用于替代正常路径性能结果。
|
||||
|
||||
## 正确性与性能验收
|
||||
|
||||
所有 SQL 调整保留当前 API、权限、六位小数数量口径、统计版本、北京时间业务日及未知值规则。不会因为优化改变页面字段、图表范围、榜单资格或库存新鲜度。
|
||||
|
||||
| 对照组 | 必须验证的结果 |
|
||||
| --- | --- |
|
||||
| 两仓、同 SKU 不同货主、仅单版存在的 SKU | 身份不串仓／不串货主，候选并集不丢失；名称优先级不变 |
|
||||
| 完整／部分／未知销量、真实零量、单位冲突 | 正式量、已采集量、未知数量及原因一致，未知不能变成零 |
|
||||
| 新鲜／过期库存与完整／不足 30 日的四种组合 | KPI、榜单、七桶和下钻资格一致；正常完整场景单独计时 |
|
||||
| 边界 30／60／90 天、零可售、次品／冻结、短观察期 | 分桶用原精度比较；有限天数、无销量和未知不混算，库存品质不放大销量 |
|
||||
| 首末页、越界页、空结果及并列销量／天数 | total、顺序及业务键一致；不先取 Top 10 再算全仓分布 |
|
||||
| 发布切换、旧版、修订屏障、跨午夜、库存到期 | 同请求读一致快照；严格下钻拒绝规则及独立销量读取不变 |
|
||||
| 小数与最后出库日 | 小数汇总不提前取整；最近日期条件不放宽，无匹配仍为空 |
|
||||
|
||||
响应对照使用同一逻辑时钟与固定输入，逐字段比较；真实 HTTP 中必须变化的请求时间／诊断标识单独核对，不以整段忽略 context 的方式让对照通过。
|
||||
|
||||
每项候选先完成直接回归和 SQL 对照，再串行复测同档 HTTP，记录 P50／P95／P99、样本数、错误数、每请求 SQL 数、数据库耗时、扫描及临时结果、响应大小。相同资源下重复比较以排除波动；不能靠提高超时、减少候选、缩短统计范围或跳过资格校验获得收益。
|
||||
|
||||
最终验收沿用主方案：单仓 1 万货主＋SKU、单销量版最多 366 万条稀疏日行、当前及至少两个旧版，并验证两仓隔离。无业务结果缓存，10 并发稳定至少 5 分钟；各类用例需要分别有足够样本，低于 100 个成功样本的路径只作抽测，不用其 P95 宣布通过。缺失阶段或失败请求不能从汇总中静默排除。
|
||||
|
||||
| 性能场景 | P95 目标及边界 |
|
||||
| --- | --- |
|
||||
| 经营总览 | ≤1.5 秒 |
|
||||
| 五种常用范围的 SKU 清单、7／30 日榜单、库存各关注筛选／排序、货主概览 | ≤1 秒 |
|
||||
| 366 天自定义 SKU 清单 | ≤2 秒，覆盖当前及仍可读旧版 |
|
||||
| 单 SKU 日趋势、货主选项、采集运行元数据查询 | ≤500 ms |
|
||||
| 全部正常合法请求 | 无超时／错误；首次与预热、单用户与并发、深分页分别报告 |
|
||||
|
||||
同档后台候选构建期间也要满足查询目标，并验证只读完整旧版；构建耗时、扫描、写入及磁盘增长单独报告。增加原单和旧统计版本后，当前固定版本查询不能扩大成原单／全部版本扫描。查询不访问 order／item／stage，不调用领星；合成容量验证不能通过开启真实采集获得数据。
|
||||
|
||||
### 并发与后台构建的对照矩阵
|
||||
|
||||
| 场景 | 固定条件与增加的负载 | 应取得的证据 |
|
||||
| --- | --- | --- |
|
||||
| 查询单独运行 | 单用户与 10 并发分别记录；请求组合、分页深度、日期范围、双版本、资格状态及资源不变 | 每条路径分别统计样本量和时延；默认库存作为已达标回归项，总览与销量作为主要改善对象 |
|
||||
| 查询与候选构建重叠 | 相同查询读取原固定版本，同时启动规模明确的本地候选构建 | 记录真正重叠的起止时间、构建阶段、输入／输出行量、批次及进度，关联查询时延、连接等待、CPU／磁盘；不能仅以后台曾启动证明已覆盖竞争 |
|
||||
| 查询与采集落库重叠 | 如需验证，采用受控合成输入，并单列写入速率与持续时间 | 与前两组分别比较，保留归并／写入的干扰证据；不调用领星制造压力 |
|
||||
| 版本发布边界 | 新旧版切换前后的请求分别标记，固定上下文仍读取原版 | 版本一致、无半份数据、到期拒绝正确；不把发布后更换数据范围的请求混入同一 A/B 结果 |
|
||||
|
||||
请求组合先覆盖既有近 15 日总览、销量和默认库存，再增加常用范围、长窗口、复杂筛选及深分页；记录每类占比，不能改变组合后直接比较整体平均值。主读阶段仍要求稳定至少 5 分钟；短构建或短采样仅标明覆盖到的阶段，其余阶段保留未验证。是否单独追加容量档位由实际使用需求决定，不自行把 10 并发目标扩展为新的大规模压测要求。
|
||||
|
||||
## 交给开发总控的工作包
|
||||
|
||||
以下工作包在功能与人工页面验收安排后启动；当前仅更新规划和证据，不向总控追加立即执行的性能任务。
|
||||
|
||||
| 顺序 | 工作包 | 完成条件 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 复用完整基线与诊断 | 复用 1,991 次请求的完整基线及 39 次分段诊断，核对功能修复后的可比性；仅补缺失或已变化的证据 |
|
||||
| 2 | 对准总览 report 与销量 page | 现有采样已明确主要 SQL 成本；补查计划及资源竞争中的剩余问题，默认库存保持回归，不重做无收益实验 |
|
||||
| 3 | 验证有证据的新候选 | 用具体减少的扫描／聚合／排序工作量说明收益来源；复杂筛选共享聚合按其自身瓶颈选题，窄投影、profile 归并和延后名称无新证据不重做 |
|
||||
| 4 | 全场景验收 | 按主方案完成无缓存、长窗口／旧版、下钻及上述混合负载矩阵；无稳定收益候选不进入最终实现 |
|
||||
| 条件分支 | 退化状态快路／固定版有界缓存／发布时预计算评估 | 仅在前述证据支持时展开，不自动增加本轮表结构或平台依赖 |
|
||||
|
||||
总控指定查询实现的唯一写入者；只读评审、回归设计可以内部并行，Maven、部署和共享环境压测窗口继续串行协调。现有查询、Mapper、SQL 基线由其当前写入者维护，本次文档交接不另行移交文件写权，不创建独立对话。
|
||||
|
||||
每个候选交付“修改点与版本、固定输入、响应对照、前后执行计划、同档性能结果、是否保留及理由”。已试验未显示稳定收益的方案保留结论，新派工先查重；有实质差异才重新验证。测量完整后再决定下一项，不以预计收益百分比代替结果。本文不授权部署、SQL 执行、环境写入或真实领星调用；这些操作继续沿总控已有有效授权和工程约束安排。
|
||||
Reference in New Issue
Block a user