优化
This commit is contained in:
+38
-3
@@ -16,7 +16,9 @@
|
||||
8. 同时支持先选同一起运仓的可排货物/托盘再生成排车单，以及先创建空排车单再添加货物；空单不能伪造货物、拣货、装车或发车事实。
|
||||
9. 车辆和司机既可从已有档案选择，也允许临时填写外配车辆和司机；临时填写不伪造车辆或司机档案关联，不自行创建主档。
|
||||
10. 后台确认装车完成必须以PDA真实拣货核平为前提。后台不提供替代PDA的拣货数量补录来绕过此条件；PDA和后台均可确认装车完成及实际发车的既有确认保持。
|
||||
11. 用户随后澄清本次“新增预约”是预约日历的功能需求，先与本批排车改造分开整理。本批不新增日历预约创建或独立约车流程；排车已有FBA预约、车辆预约字段及权威关联继续保留。此前确认的先保存后关联意见保留为日历需求输入，不作为本批扩大实现范围的授权。
|
||||
11. 用户随后澄清本次“新增预约”是预约日历的功能需求，先与本批排车改造分开整理。本批不新增日历预约创建或独立约车流程；排车保留已有FBA预约关联；用户随后对车辆预约权威来源问题答复“那就不要”，因此排车取消车辆预约字段、关联操作及公开协议，不再等待或新建该权威提供者。此前确认的先保存后关联意见保留为日历需求输入，不作为本批扩大实现范围的授权。
|
||||
12. 用户进一步明确“本批支持整托同车”：两张换标单已合到同一实托时，整托进入同一排车主单，物理托盘及容量只计一次，各换标单的箱数、客户及扫码归属分别保留。不得只装第一来源、借第一客户承载其他来源，或把同一实托拆成两张排车绕过排他占用；此确认取代该场景的待决定状态及仅作前置拦截的候选方案。
|
||||
13. 用户进一步确认：换标已由客户确认完成、关联出库单尚未扫码时，只取消本次出库安排，保留已完成的换标成果，退回待安排。不得将已确认换标申请一并作废；取消须清除本次有效出库关联，保持真实客户、原换标成果及重新安排资格。此规则不放开已扫码取消或新增回库流程，整车取消仍遵循既有阶段、版本和零扫码门禁。
|
||||
|
||||
## 二 原型依据与详情四块
|
||||
|
||||
@@ -27,7 +29,7 @@
|
||||
| 分区 | 截图字段或列 | 布局 |
|
||||
| --- | --- | --- |
|
||||
| 车辆信息 | 车牌号、司机、联系电话、拖车公司名称、车辆状态 | 第一个彩色图标页签；紧凑字段布局 |
|
||||
| 排车信息 | 路线、发车时间、预计到达时间、FBA预约、车辆预约 | 第二个彩色图标页签；紧凑字段布局 |
|
||||
| 排车信息 | 路线、发车时间、预计到达时间、FBA预约 | 第二个彩色图标页签；紧凑字段布局 |
|
||||
| 单据信息 | 排车单号、关联派送单、创建时间、更新时间、备注 | 第三个彩色图标页签；多单号完整展示 |
|
||||
| 关联订单明细 | 订单号、重量kg、托数、目的FBA仓、体积m³、集装箱号 | 第四个彩色图标页签；通栏只读表格 |
|
||||
|
||||
@@ -105,6 +107,7 @@
|
||||
| 实际装载核对 | 在确认装车弹框接入既有实载核对，有依据的实际数据自动带出，缺项再确认；保持PDA真实拣货核平前置 | 实载来源/字段/弹框及双端核验；不新增第五个详情页签，不代填拣货箱数 |
|
||||
| 零扫码变更 | 保留原排车单号，显式退回装车前，修改后两级审核重提 | 新审核轮次、权限和历史；已经扫码的退装/回库不在本批新增 |
|
||||
| 客户直接创建派送 | 本批整车安排仅由平台执行，客户继续查看自己的派送单，移除旧客户直接创建这类派送入口 | 派送后端移除对应Merchant创建写入口；前端任务按第九节更新Client直接消费者，保留本客户读取及合法资料操作 |
|
||||
| 换标合托同车 | 同一实托可承载两张换标单的逻辑运输来源并整托同车；各来源真实箱数、客户及扫码归属保留，托盘和实际容量只计一次 | 同车内物理占用共享、跨车排他；候选、整托完整性、扫码归属、实际装载及派送/来源状态的直接契约须一致，不能只放开重复托盘校验 |
|
||||
|
||||
工程事项仍由总控负责：公开版本字段、请求摘要与业务摘要、真实库存扣减点、子单与来源锁序、签收持久提醒的写入和消费职责等不要求用户裁定技术细节。尚未核实的资源/预约提供者反向锁点必须在实现前补齐证据，不能用业务确认替代代码和并发验证。
|
||||
|
||||
@@ -140,6 +143,30 @@
|
||||
- 主后端继续唯一维护上述草稿移交包以外的`dispatch/`、`fleet/trip/`和共享端口，补审核/装发、实际来源、PDA、Fleet一对一收敛及真实读写合同；不新增页面或业务规则。主后端保留唯一Maven执行权，按稳定输入覆盖File和派送用例。前端冻结后的只读差异核对已发现Long数量/附件大小字符串造成的真实阻断，总控仅解除其原有独占范围冻结以修正响应边界、直接消费者和真实wire回归；ID/版本继续无损，不改共享解析器、DataTable、导航或新增预约。
|
||||
- 总控直接承担共享数据库基线、OpenAPI、权限及根入口收口，其他任务不写这些文件；File上述独占契约除外。索引/AGENTS最终统一维护，避免另建重复状态文档。
|
||||
|
||||
### 换标同实托多来源的实施冻结
|
||||
|
||||
用户已确认本批支持整托同车。本次按真实物理托盘与逻辑运输来源分层：同一车内共享物理占用，来源分别保留客户、换标业务号、原货源与可拣贡献；跨车及跨草稿容器继续物理排他。只移除一条来源不得提前释放仍有其余来源的实托，取消、草稿失效/转换及零扫码重审沿同一完整集合执行，不通过第一条来源或FIFO推断其他来源。
|
||||
|
||||
候选由服务端返回完整选择组及组成版本，使用未被页面筛选截断的事实闭包，兼顾既有整申请规则；前端不按当前可见相同托盘码自行拼组。正式Create/AddCargo保留显式逐来源选择并在服务端复核全组；草稿单来源动作须服务端一次命令原子处理完整组，不能用前端循环多个写请求代替整组一致性。PDA保留逐明细精确扫码，展示明确换标业务号及该来源可拣位置/额度，全部逻辑来源核平后才允许装车；不新增整托一键多次扫码或自动补拣数量。
|
||||
|
||||
LoadingPreview及实际容量按每实托一行，逻辑箱数、来源状态与费用分别按真实归属保留。整托实测重量/体积不复制到每逻辑来源；业务份额只使用实际来源证据，缺少证据保持未知，不按箱数推件数或平均分摊重量。主流程先产出字段级公共骨架及唯一接口设计，前端以实际Java记录对齐；来源贡献的仓库生产者/移动触点及精确DDL由主流程提出，总控核对现有写者后逐文件分配。共享SQL/OpenAPI仍由总控集成，Maven仍由主流程唯一执行；此前普通流程通过结果不覆盖本次新增模型。
|
||||
|
||||
来源贡献的直接验证按主流程明确释放的有限边界并行：派送专项唯一新增`lastleg-service/src/test/java/com/baiyue/lastleg/dispatch/service/DispatchItemSourcePersistenceTest.java`，验证冻结贡献、逐明细/客户/位置消费、已消费额度、HOLD合计及事务回滚；该文件移交前主流程确认未创建、未写入。`DispatchItemSourceService`、Repository、Mapper、Entity及公共port仍由主流程唯一维护，派送专项不并修生产；提供者受控输入的组件测试不能代替真实provider与主流程的组合回归，Maven仍只由主流程执行。
|
||||
|
||||
### 实托组成冻结的共同串行点
|
||||
|
||||
当前运输组成须排除已由既有换标作废事务结束的申请历史，不沿其旧明细指针扩展实托闭包；真实库存位置仍完整保留，残余HOLD没有当前来源贡献解释时继续阻断。活跃、尚未取得排车资格的申请仍参加完整性核对。普通纯SKU的既有履约资格和库存生命周期保持原规则。
|
||||
|
||||
草稿纯释放和续租入口（UNSELECT、RELEASE、CREATE_CONTAINER、REMOVE_CONTAINER）须先按原草稿冻结实托集合取得共同Serial，再读取逻辑和物理占用，并在等待后复核原租约；不重新要求当前来源业务资格。SELECT、SNAPSHOT及CONVERT继续遵循既有资源、申请、订单到Serial的完整锁序，不把Serial提前到来源锁之前。到期接管与原草稿动作共享该串行点，不能分别采用逻辑成员到物理占用、物理占用到逻辑成员的相反锁序。
|
||||
|
||||
主流程已提出且总控冻结窄协议：`inventory/port/PhysicalPalletSerialPort.java`仅提供`void lock(List<Long> warehousePalletIds)`。永久表`ll_physical_pallet_guard`仅有真实全局`warehouse_pallet_id`主键与首次`created_at DATETIME(3)`，没有客户、状态、TTL或运输owner。调用方事务内对去重升序实托执行保留原时间的主键upsert及逐行FOR UPDATE，空目标也取得同一串行点；未关联实托的计划不伪造ID。
|
||||
|
||||
原有资源/主单父锁之后，预读完整源目标组成，稳定取得全部申请、真实订单，再取得全部实托串行行，重读组成，最后库存及运输claim。新增申请、订单或实托必须整笔冲突，不能持锁后追加无序集合。仓内移动、原托保留、return/unbound都覆盖普通库存、原生退货及空目标；不得给仓内作业新增暂扣资格限制。退货远端physical.apply须置于门禁之后，原业务失败补偿在共同串行锁仍持有时完成。
|
||||
|
||||
本有限包文件分配：既有B专项唯一新增inventory下上述port、`service/PhysicalPalletSerialService.java`、`repository/PhysicalPalletSerialRepository.java`、`mapper/PhysicalPalletSerialMapper.java`和对应真实Mapper/H2持久化测试，不修改排车/草稿消费者。主流程A唯一接入正式排车与草稿，并仍唯一维护公共排车模型及执行Maven。既有内部`native_fleet_script`唯一修改`palletops/service/PdaPalletOperationService.java`、其原直接测试，按必要最小范围修改本域Repository/Mapper及新增`PdaPalletDispatchFreezePersistenceTest.java`，不写inventory共同实现或dispatch/relabel提供者。SQL两基线与初始化合同总控唯一维护。各包先读取最近指引，交付准确SHA与未验证项；不得增加HTTP、状态协议或迁移。
|
||||
|
||||
草稿后续接线按主流程明确交接再次细分：B唯一维护`DispatchDraftService.java`、`DispatchDraftRepository.java`、`DispatchDraftClaimMapper.java`、`DispatchDraftPersistenceTest.java`四文件，A确认当前未写且暂停这四文件；A保留完整来源解析、正式主流程、PDA及公共模型。B以`selectionGroup(warehouse, selection)`读取完整组，以`lockDraftSources(warehouse, 全部组成员)`锁定并复核，选择、解除、布局、释放、到期与转换不得拆开同一完整组；按物理实托共享claim并只计一次容量，按逻辑来源保留真实客户及箱数。源版本与组成必须服务端核验，不增加前端循环写或公开协议别名。永久串行点的草稿接入由该B四文件包消费A来源锁方法，覆盖上段原先由A统一接draft的安排，其他边界不变。`DispatchItemSourcePersistenceTest.java`仍B唯一维护，按A明确新增`relabel_round_key VARCHAR(128) NOT NULL`同步手写建表并保持原16场景；SQL仍根维护。
|
||||
|
||||
### 既有预约接线的本轮授权
|
||||
|
||||
2026-10-19用户明确批准按《排车列表派送费用接口设计》第13节接线，新增预约不动。本段覆盖下列既有消费者的此前只读限制，不接管日历新增预约或建立车辆预约权威表。
|
||||
@@ -148,10 +175,18 @@
|
||||
- 主后端继续唯一维护`dispatch/port/`和主流程，给既有批次候选引用、分配补权威`recordVersion`（0合法、缺失及同批混版本拒绝），提供版本化的窄内部原预约变更命令；负责创建、加货以及草稿全批转换在来源锁之前预锁完整批次集合。另取得`ExceptionOrderService`及其直接测试的最小适配权，仅修正新共享PDA任务接口消费并保留明细/扫码/订单按真实客户隔离，不新增异常功能。
|
||||
- 前端只在原排车模型/API/wire/弹框、三个已授权既有Work排车表单及直接测试内，按实际Java合同透传批次版本；原冻结候选仅对此接线解除冻结，其他部分保持。不得猜版本、补0或改日历新增预约、面板、planningApi及公共密度文件。
|
||||
- 批次分配采用本次触及明细的增量替换，保留其他客户与未变明细的原分配，并以整车有效总量复核。统一锁序为全部父trip/资源/dispatch及必要的全部客户outbound、delivery，再全部既有批次、来源及实物/库存占用，协调guard在业务锁与变更之后；不能形成来源→批次反序。原命令身份、两级审核失效、主版本、零真实扫码、完整实物及整事务回滚规则不变，不补回退役Fleet绑定/移货别名。
|
||||
- 车辆预约仍须明确原权威记录、版本和归属提供者。当前未定位到该提供者时保持显式门禁，不能用FBA批次、外接预订或旧手填状态替代；此授权不包含新的车辆预约表、创建API或日历业务。
|
||||
- 用户最新明确取消排车的车辆预约：删除页面展示/输入、Update引用字段、详情字段、对应公开类型和拒绝占位分支，FBA预约不变；不保留旧字段别名或空字段，也不新增车辆预约表、创建API或日历业务。此前“保留权威关联、未定位时拒绝”的安排被本次裁定替代。
|
||||
|
||||
共享SQL、OpenAPI、权限仍由总控集成，Maven仍由主后端唯一执行；不增加任务、不部署、不执行环境SQL或真实业务写入。
|
||||
|
||||
本轮收口为减少串行等待，总控独占适配四个实际旧查询消费者：`exceptionorder/mapper/ReturnCartonStockReceiptMapper`、`inventory/mapper/ReturnStockReceiptMapper`、`delivery/mapper/DeliverySourceEvidenceMapper`、根`mapper/CustomerOrderProgressMapper`，并补齐同一旧任务客户头引用的`delivery/mapper/DeliveryOperationMapper.returnReceipts`，及直接查询测试`CustomerOrderProgressMapperTest`、`DeliverySourceEvidenceMapperTest`、`SharedDispatchReturnQueryTest`。仅消除已退出的主单/任务客户头、旧状态及发车列依赖，保留真实明细/扫码/订单/派送客户隔离与原数量规则；派送任务不并写移交的查询Mapper。原前端写者同步`CapacityInquiryTable`、`CapacityInquiryDialog`两处同一外接入车API的当前新建权限，保留其他三项独立权限。派送任务另独占`ReturnCartonReturnPersistenceTest`及主后端随后明确释放的`DispatchRepairWorkflowTest`的新模型夹具和构造器适配，主后端不并写该文件；现有归箱、逐SKU恢复、幂等、客户隔离、回滚和真实结案断言保留。总控另精确接手已交付19文件包内`FbaAppointmentPersistenceTest`、`FbaReceivingPersistenceTest`的transport.apply父命令键测试签名收敛，派送任务不并写这两个测试；其他17文件保持冻结。总控另唯一维护`DeliveryTransferService`及其直接测试：PDA解析改用真实整车Repository并保留绑定仓，取消出库不再被整车自动创建的唯一Fleet关系误阻断；ACTIVE/装车前/零真实扫码发运、子单未执行与费用门禁保留。本轮总控还收敛实际旧模型的直接查询消费者：`DispatchFeeCargoMapper`及`DispatchFeeCargoMapperTest`、`PlatformDispatchOutboundContractTest`；无生产调用的`DispatchCargoSourceQuery`删除，原真实来源断言转到现行FleetAdapter。另由总控唯一修改`LastlegOrderMapper.findDispatchStatuses`、`InventoryCommandMapper.shipmentSources`、`InboundPlanQueryMapper.SCHEDULED_DISPATCH`、`AppointmentImpactRelationMapper.dispatches`及四份直接查询测试；仅调整共享头身份/阶段，明细客户、真实库存命令、仓库及取消边界继续核验，不改预约创建。`FleetAppointmentImpactMapper`由主后端单写同一模型的绑定查询，双方不并写。没有新增异常、库存、外接或预约业务。
|
||||
|
||||
### 本轮测试环境实施授权补充
|
||||
|
||||
用户随后明确授权总控部署测试环境、操作测试数据库、调用真实HTTP，并使用内置浏览器登录验收样式、交互及请求量；Admin/Client按1920×1080，国内/海外PDA按390×848。此前仅离线检查、默认不部署和由用户截图的限制在此精确范围内由新授权取代。目标仍为本契约所属TEST项目及当前排车改造，不接管日历新增预约，不操作开发或生产环境。总控统一协调发布、SQL及环境写入，先核对匹配源码、结构、权限和现有运行版本，执行后按实际证据维护环境主契约；部署成功、HTTP通过和浏览器验收分别记录。
|
||||
|
||||
本轮换标出库取消修正的唯一实现者为总控内部`native_capacity_consumers`，只写`DeliveryTransferService.java`、`DeliveryCancellationRepository.java`及`ReturnOutboundClosureTest.java`；覆盖原生箱及普通仓托，保留原配送方式、已确认成果及库存事实，TRUCK退回待排车，其他方式退回待独立安排。不把非TRUCK来源改成TRUCK、不重跑换标完工确认或新增旧独立出库安排API。非TRUCK再次独立安排入口的接线尚不属于本次取消修正，不以取消持久化成功推定再次安排已完成。后端其他写者冻结这三文件，Maven仍由主后端统一执行。
|
||||
|
||||
## 十 日历新增预约的范围分离
|
||||
|
||||
用户澄清“新增预约”应放在预约日历，并指定由对话 `01a15231-2507-7802-8015-34b01f5eb2c4` 处理，明确本总控不用接管。三个排车任务不修改预约日历的新增预约表单、权威预约模型或预约新建API，也不承担其设计和矩阵；本批只处理整车改造确实影响的既有预约读取/关联消费者，有限接线写权见第九节，不自行接管新增预约或跨对话派工。
|
||||
|
||||
Reference in New Issue
Block a user