50 KiB
美国预约管理统一总览与优化方案
日期：2026-10-09
文档性质：需求梳理与设计建议。统一展示美国段各类预约是原方案整体方向；本轮用户进一步提出开船后提前安排提柜、到仓、FBA送仓与车次余位拼车的目标。下述页面、状态、字段与实施方式供产品评审，不代表已确认全部细则、已实现或已发布。现行预约、到仓与拼车规则仍以各自维护入口为准；需要调整的合同在本文明确列为设计缺口。部署与验收状态仍以测试环境单机部署与配置契约为准。
本文维护在途筹划、对外预约与变化跟进；拼车数据入口与操作简化评估草案维护销售接货及共用车次操作简化。两份文档保留独立业务范围，跨方案职责与交接顺序仅在本文第九节维护；不另建重复总方案。用户后续已安排A/B实施，原“仅整理文档、不启动开发”的阶段限制已被该授权替代；本方案仍是目标定义，实际部署与验收只以环境主契约为准。
一 页面定位与核心结论
“预约管理—预约列表”应成为美国段提前筹划和预约跟进的统一入口。从真实开船及在途货物清单出发，让运营知道：哪些柜快到了、各目的仓有多少待送货、何时有望备妥、现在该联系谁、哪些已经约成、哪些车还有可发布的余位。
范围包括提柜、海外仓接仓、用车、FBA及其他送货等美国段事项。建议保留现有菜单名称，页面标题使用“美国预约总览”；日常工作以待办、货柜和送货批次列表为主，日历辅助查看已排日期。尚未约到时间的工作必须能被看到。
统一的是查看入口、关联信息和操作入口。提柜、车次、派送、收货仍由各自业务模块保存权威事实；总览读取和联查这些记录，修改时回到对应业务命令，避免运营在多个页面重复维护同一事实。
需要区分三种事情：
| 事项 | 例子 | 总览如何表达 |
|---|---|---|
| 对外预约 | 码头提柜时段、FBA收货时段、客户现场收货约定 | 显示预约状态、当地时间、地点、对方确认信息 |
| 内部作业计划 | 安排车辆司机、预计装车、计划发车 | 显示执行准备和资源安排，不冒充对外预约成功 |
| 参考节点与提醒 | 预计到港、实际到港、还柜截止 | 单独图层或待办提示，不计入预约成功数量 |
“约车送FBA”通常同时涉及运输安排和FBA收货预约。 车已安排不代表仓库已确认收货；仓库约好也不代表货齐、车到、可以发车。页面应把两者关联展示，分别保留状态。
1.1 从开船开始并行筹划
| 阶段 | 系统应提供的信息与建议动作 | 人工负责的决定 |
|---|---|---|
| 已开船、货在海上 | 读取真实柜内货物、接柜海外仓、目的FBA仓、最新ETA及来源；形成提柜联系待办和送仓货量预览 | 核对接仓地点、货量和预计时间，指定负责人 |
| 预计到港前 | 展示目标提柜/到仓窗口，按目的仓和货物可备妥窗口汇总；准备联系资料和约车需求 | 联系拖车公司、接仓方、送货承运商；允许先记录意向和对方反馈 |
| 对方开放预约且资料满足 | 提示可申请、缺资料、等待开放或等待对方回复；保留申请时的货物范围 | 人工提交预约，取得对方结果后登记确认时段、确认号及凭据 |
| 货到仓前后 | 核对实际提柜、到仓、卸柜/理货与预计货量差异；把已选在途货关联到后续真实作业单据 | 确认送货批次、承运车次和时间；处理少货、换标未完或延期 |
| 车次具备发布条件 | 带入有效的自有货计划占用和逐目的站剩余容量，链接现有拼车需求池 | 调度确认发布；销售登记意向，调度确认承运才占位 |
提柜沟通、收货仓排班、FBA预约准备和承运商询车可以并行。正式提柜、实收入库、拣货和发车仍按实际作业条件执行，不因提前安排而推进完成状态。
1.2 时间按用途分开，预约按对方规则办理
建议展示一条可追溯的时间链：预计到港 → 预计可提柜 → 预计到海外仓 → 预计货物可备妥 → 目标送达 → 对方确认时段。前三项也不能相互替代。
- ETA来自当前权威船节点，保留来源、更新时间和变更前后值。未查到ETA时进入“待补到港预报”，不直接用开船日加固定航程伪造。
- 预计可提柜需考虑卸船、清关/放行及码头可提信息；预计到仓还涉及拖车与接仓安排；货物可备妥还涉及卸柜、理货、打托或换标。可以由运营维护预计区间和依据，不要求首版建设复杂预测引擎。
- 目标送达需在预计备妥后留出装车、行驶和业务缓冲。先做可解释的区间预排；按港口、仓库、线路维护经验参数时，应允许人工核对，不能全美国统一写死“到港后两天送FBA”。
- 将“希望约的时间”“已申请的时间”“对方确认的时间”分开；可以提前联系，但正式可申请时间取决于具体码头、仓库和承运商。
- 每个预约地点按需维护预约方式、联系人、当地时区、开放条件、所需材料、改期/取消要求和规则核对日期。外部账号凭据不放在预约备注里。
外部规则核对（2026-10-09）：APM Terminals洛杉矶预约说明要求进口柜卸船后才能设置提柜预约，说明“提前安排拖车”和“码头正式约号”可能发生在不同时间；不能将这一家码头的条件推广为所有港口。Amazon美国Carrier Central手册区分申请日期与授予时段，要求承运商有把握按约送达，并禁止使用货件资料建立占坑或重复预约。本文据此建议先做好内部预排，再按对应机构条件确认，不预设“开船当天即可拿到所有正式预约”。
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个预约”，不能把单个字符串覆盖成最后一次预约。
当前排车预约字段独立维护的问题必须在实施前收敛，否则页面会同时出现“预约成功”和“排车待预约”。此项是建议的修正方向，尚未代替现有业务合同。
车次余位与现有拼车池衔接
沿用内部拼车需求池首版开发契约：一车次一发布，外接货统一在我仓上车；询价不占位，调度确认承运才占位。预约页只增加发布资格摘要及进入原发布操作的入口，销售继续在原需求池工作。
建议允许提前做用车需求和送货批次，但保持正式余位发布条件。 尚无车辆/司机、真实起运仓/卸货站或有效容量计划时，显示“预排中，暂不可发布”及具体缺项。承运商仅口头表示“预计有车”不能当作可发布运力；如以后要销售尚未落实车辆的远期运力，应另行评审，而不是本轮放松现有门禁。
车次准备、容量核对、发布窗口及部分成功续办统一由拼车优化草案第七、八节细化；预约页读取车次服务返回的逐目的站余位、资格与缺项，不实现第二套计算或发布表单。船期/货物变化由预约侧提供影响依据，车次侧重新核对运输承诺；不自动扩大余位或静默取消已确认外接订单。实际规则继续以拼车正式契约为准。
拼车新增货物后，预约侧按稳定来源核对目的仓、货件材料及预约覆盖，车次侧展示同一结果并引导处理。确认承运保位不能推定收货方已经接受新增货物；需要补充货件或改约时交预约负责人，不自动再建一张同义预约。两类货源的可预约阶段与检查时点须在第九节的首次交接中明确。
五 页面和交互优化
总览布局
建议在同一菜单内使用三个工作视图，避免把所有业务字段塞进一个通用大表：
| 工作视图 | 一行/事件的组织单位 | 首屏信息与主要动作 |
|---|---|---|
| 提柜与到仓 | 一个来源货柜 | 操作、柜次/柜号、港口→接仓点、ETA及更新标识、目标提柜/到仓窗口、拖车联系/码头约号结果、当前缺项、负责人/下次跟进；进入原货柜业务维护 |
| 送仓与排车 | 尚未安排的同仓同窗口候选组，或已建立的送货批次；二者明确标识 | 操作、起运仓→目的仓、预计备妥窗口、货量/可用状态、收货预约、承运安排、余位发布资格、负责人；选货保存安排、登记预约结果，带入共用车次入口，不另建建车/发布表单 |
| 预约日历 | 去重后的预约事件；内部作业及预报可选显示 | 按日/周查看对方确认时段及待确认安排，可切换列表；按类型、地点或车次查看，不用一条综合状态覆盖所有事项 |
日常进入列表工作视图，顶部用紧凑待办计数定位“待联系、等对方回复、已约未配车、船期变更待处理”，点击后作用于对应视图。每条待办展示负责人、下一步和下次跟进日期；同一柜或批次的多个问题合并提示，展开后逐项处理，避免提醒数量淹没实际货量。
“送仓与排车”增加目的仓货量汇总，默认按实际起运仓及未来可备妥窗口查询，可按需要切换7/14/30天。每个目的仓分别展示在途、在仓未备妥、已备妥货量及待安排量；未确定备妥日期的货物单列“日期待定”。已安排货物不再次进入未安排候选，跨窗口统计不能重复累计同一批货。
顶部保留日期、类型、地点/仓库、状态和关键词搜索。日期条件需注明当前筛选的是“预计到港”“预计备妥”还是“预约时段”；不能切换视图后无提示地把同一个日期变成另一种含义。关键词支持预约号、柜号、入仓码、车次号及客户业务名称；车牌、司机、负责人等放入更多筛选。
前两个视图使用工作列表；第三个统一承载月/周/日历及对应时间安排列表，不为每个工作视图再建一套日历。月视图负责概览，周/日视图负责排班，列表负责搜索、批量核对和导出。统一日历与其列表切换时保留筛选；跨业务视图保留通用条件并清楚显示各自日期口径。操作列按Admin规范放在第一列；大量货物明细只在展开或详情按需读取。
日历每格最多显示3条，标明剩余数，悬停显示总数。右侧当天安排按时间排序，未定时事项进入“待安排”区域，不伪造09:00或00:00占位。
到港、预计到仓、还柜提醒通过独立开关显示；预约数量只统计真实预约。历史已取消事项可以筛选查看，保留原取消信息。
以上为信息结构建议，尚不是已冻结视觉原型。实施时逐操作核对现有新增、详情、编辑的承载方式；未定义操作形成评审矩阵，人工按1920×1080、100%缩放确认，不以本方案代替视觉验收。
卡片内容
首屏只展示类型、地点、时段与时区、预约状态、运输安排摘要、货物统计和需要处理的问题。联系人、附件、操作历史、客户与货物明细按需展开。
入仓码独占一行区域，默认3条并显示总数，展开后独立滚动；大量货物使用可搜索、可分页的关联明细，不能一次拼接数百个编号到卡片中。备注缺失不占一整格；长备注默认摘要。
卡片提供“查看来源单据”“查看关联车次”等操作。编辑、改期、取消是否可用由来源业务权限和当前状态决定，不因用户能看总览就允许修改所有类型。
新增流程
- 优先从货柜或目的仓货量发起，自动带入业务对象与货物；通用“新增”入口再选择提柜、接仓、FBA或普通送货等类型。
- 先保存“预约安排”：目标日期/窗口、负责人与下一步；允许对方约号、车辆和司机暂缺。原有待办应直接补充，不另建一份重复事项。这与拼车侧的“客户货物登记”分别命名、分别维护，不能共用一个含义不明的“意向状态”。
- 人工通过电话、邮件或外部预约平台沟通，记录联系对象、方式、结果及下次跟进；系统可整理/导出既有货柜与货件资料，不能把资料导出当作已发送或已申请。
- 申请后登记申请时间及反馈；对方确认后再记录确认时段、外部号或适用的确认凭据。回到关联批次核对承运和货物是否就绪。
新增入口可以预先带入当前选中的日期，但时间应由用户确认；地点改变后重新核对时区、可选货物及资源，清空不再匹配的选择。继续保留并发版本校验和稳定幂等，避免重复点击创建重复预约。
六 减少填写项的具体规则
| 信息 | 建议 | 约束 |
|---|---|---|
| 仓库/码头 | 主档搜索选择，显示编码与名称；码头可由货柜带入 | 不接受自由文本冒充已存在地点；地点未维护时给出维护入口 |
| 客户/入仓码/柜号 | 选业务对象或货物后带入 | 不能让运营在预约表单再手填一遍；保留真实归属 |
| 箱数/托数 | 从所选货物汇总，计划值和实收值分别标识 | 不允许为了少填而拿预计值冒充实际值 |
| 车辆/司机/电话 | 关联车次后读取，外包运输复用承运车队信息 | 不在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。
已选定的预约与拼车交接文件
实施交接的来源、权限与跟进规则维护在业务主入口的预约跟进合同，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并将编译产物竞争误判为源码故障。
开工前先确定六项交接
- **货物来源与数量：**已有头程在途货、拼车外接货分别如何关联来源明细、来货、入仓计划和实收；避免入库前后重复计货，首版不默认拆分同一明细。
- **时间与状态：**预测、计划快照、对方确认时间分别归谁；预约安排、拼车登记、确认保位、实收后排入各自允许什么操作，不互相推进状态。
- **预约资格与覆盖：**两类货源分别在哪个阶段可以准备/正式申请FBA预约，需要哪些资料；新增拼车货如何进入候选、核对原预约货件及检查时点。预约服务给出结果，车次侧消费，不在最终联调才补来源支持。
- **车次接入：**A传真实来源及计划关系，B返回可用候选/阻断原因、关联车次和版本；无正式排车资格时只保留筹划，不生成假托盘或实际装载。
- **余位与变更：**B提供各目的站可接量、发布资格、缺项和版本；A传递预测/货物变化依据，双方明确哪些变化触发人工复核，不自动重约或替换已确认承诺。
- **权限、失败与重试：**查看和写入分开，变更使用版本与幂等；明确部分保存成功、结果未知和重试行为，同一次动作不生成重复业务。
以“两柜已有货合送同FBA，再接一票外部货”为共同样例，给出上述输入/返回示例、来源关联、可用动作及失败情形。选定规则在实现前同步到对应唯一正式契约与接口定义；本节只规定交接项，不提前宣称新接口或状态已经存在。
工作包与先后依赖
| 顺序 | A：预约与集成 | B：拼车与共用车次 | 进入下一步的条件 |
|---|---|---|---|
| 0 先确定共同边界 | 明确在途及外接货预约来源、预测/确认时间和关联结果 | 明确三类占用阶段、车次资格、容量和发布结果 | 六项交接有样例；正式契约、具体文件归属和受影响检查已明确 |
| 1 两侧独立工作并行 | 在途货量、提柜/接仓列表、负责人、联系记录、无约号的预约安排 | 销售简明列表、分阶段字段、单站带入、同一登记记录、角色待办和已有排车候选 | 各自定向验证通过；不编造约号、数量或资源；独立改动不等待对方全部完成 |
| 2 共用能力只做一次 | 实现对外预约/改期及货物关联，按已确定接口接入车次和资格展示 | 完成共用安排车次、排车关联、容量核对与连续发布，提供实际消费者可用的接口和操作入口 | A/B复用同一车次能力；源码、类型、OpenAPI、权限及必要SQL一起收敛，不能靠临时兼容接口拼接 |
| 3 接通变化与外接履约 | 完成统一日历、船期影响、外接货预约覆盖和待补/改约提示 | 完成安排来货、实收核量、排入原车次及预留替换；消费预约结果 | 从原登记可跟踪整链；延期可定位影响；不重复占位、建单或收费 |
| 4 统一验收本轮闭环 | A组织整链核对和问题归属，各侧修复自己负责的部分 | B复验共享车次及外接履约，保留原审核/拣货/发车门禁 | 必要自动检查完成；真实环境和人工截图按授权执行，代码、部署与验收分别报告 |
第1—3步共同交付首个完整闭环，不以一个更大的日历或仅改表单文案替代。B的内部操作细节及局部分批见拼车草案第八节，不另排一条互相冲突的整链发布顺序。可以按可独立验证的工作包推进；本表不是工期、上线或环境写入授权。
共同回归至少覆盖：已有货在途预约；合格车次发布后接外部货并补齐预约覆盖；外接实收后预留替换只算一次；一个柜延期时关联预约/车次/已接货均可追踪；三维容量不足、重复提交、版本冲突与权限拒绝。自提、还空、转运/退货提送的扩展仍保留总体范围，排在主链后，不占用第一轮共同接口建设。
交给预约实施对话的任务说明
- **目标：**完成从已有在途货开始的提柜/接仓跟进、按目的仓筹划、对外预约、日历及船期变化影响，并接入拼车侧提供的共用车次能力。
- **先交付：**具体文件写入清单，已有头程货和拼车外接货的稳定关联、可预约阶段、时间语义、预约覆盖与失败情形；与B共同确定六项交接，不等到最后才处理外接货来源。
- **独占业务：**在途/备妥预测展示、人工联系、预约安排与确认/改期、预约货物关联和覆盖结果。车次创建、排车命令、容量及发布由B提供，本侧只接入。
- **依赖：**B提供真实货源进入车次的资格、车次/排车关联、各目的站余位、发布资格和对应操作入口；本侧不得为提前完成页面而自建同义接口或虚假资源。
- **交付物：**选定正式契约改动、受影响接口/类型/权限/SQL清单、实现与定向验证结果、公共文件串行集成记录和整链核对结果；部署与人工验收分别列出，不由源码测试推定完成。
- **完成条件：**货在海上且未建入库计划时可真实筹划，未取得约号仍能跟进；两类货源的预约覆盖可追踪，预测变化能定位下游影响，预约和车次结果一致，未重复占货、建车或发布。
拼车实施职责的交接说明见拼车草案第八节。上述工作包供用户分派给其他对话；本轮只交付文档，不创建对话、发送开发任务或修改业务代码。
十 验收场景
- 同一美国日期包含提柜、用车、FBA和客户送货，列表/日历均可找到且类型明确；国内拖车不混入。
- 五客户二十票同仓同批预约只计一张，客户统计正确，入仓码默认三条；每个客户只读到自己的货物。
- 一车两站两个收货预约，在车次视图可以关联查看；车次计划不会被重复算成两个用车安排。
- 预约成功后，排车和派送显示同一来源事实；多预约排车不会丢掉其中一站，不能再出现无依据的独立“待预约”。
- 选仓自动加载货物；换仓清空旧选择；不可预约货物有原因；仓库接口失败不允许自由输入假仓库绕过。
- 新建待确认事项无需编造外部确认号、装车时间、司机或费用；转为已确认时按业务类型核验必要资料。
- 提柜时间、预计到仓、实际到仓互不覆盖；实际作业只由原业务事实推进。
- 改期更新原记录而不新增重复事件；取消保留历史；已执行业务不被日历操作回滚。
- 跨时区、跨日、只有日期、无时间及夏令时边界正确显示；地点时区缺失明确待补。
- 日格三条预览、大量当天安排和大量关联货物保持有限高度，展开可用键盘操作；关键业务号可查看完整内容。
- 来源接口部分失败、无权限、版本冲突和重复提交均有明确行为，统计不把缺失来源当零。
- 车次调度/理货、PDA拣货发车、库存和客户费用隔离继续有效，预约页面不能跳过这些门禁。
- 柜已开船但尚未生成入库计划时，真实货物出现在在途货量及预约准备中；无需假约号、假实收或假司机即可分派跟进。
- 同起运仓、同FBA、相容备妥窗口的两柜货可人工组织批次；起运仓不同、日期不相容或已占用的货不得被无提示合入。同一来源建计划/入库后不重复累计。
- 码头尚未开放正式申请时，保留拖车沟通与待开放事项；车队答应不自动标记码头已确认，接仓方和FBA确认也不互相替代。
- ETA延后时展示旧/新预测及来源，准确指出受影响批次与预约；已确认外部时间和已冻结计划不被覆盖，待办有负责人及处理结果。
- 海上预排货量不能直接发布可成交余位；达到现有车次、资源、有效计划容量条件后复用原发布。托位有余但重量/体积不足时，不发布虚假可接量。
- 在同一路段30托位车辆、自有18、有效外接预留8的示例中，剩余为4；外接货转为已关联货物后不再额外扣8。计划失效则显示待核对，不继续承诺旧余位。
- 联系资料可由已有货物生成；缺少FBA所需资料显示缺项。记录、导出资料、申请和取得确认是不同动作，不能相互推定完成。
十一 评审需要确定的事项
本轮用户明确目标：开船后依据预计到港提前人工联系提柜，同时掌握预计到海外仓的货物和各FBA仓货量，准备送货车辆，并把符合条件的车次余位接入现有拼车需求池。原方案已有方向：美国段预约统一入口、同仓跨客户合并、减少重复填写和控制卡片高度。
本次建议作为产品评审基线，尚未生效为代码合同的规则：
- 保留“预约列表”菜单和“美国预约总览”标题；以提柜与到仓、送仓与排车、预约日历三个工作视图组织，不另开一套拼车市场。
- 从真实在途货开始筹划，先保存目标窗口和人工联系结果，后补外部确认；预计装车时间由车次维护，预约按关联读取。
- 首版同起运仓、同目的地、相容窗口内人工组批，整来源明细选择；不同站点同车沿现有调度，一行货自由拆批不随页面优化默认开放。
- 最新预测与已确认入库计划时间分开；船期变化提醒人工处理受影响承诺。修订已确认计划日期的命令与权限需另在当前合同中明确。
- 正式拼车发布继续要求现有车次、车辆/司机及有效容量计划；无资源的远期运力先保留内部预排。
实施前还需结合运营习惯确定：
- 常用港口、接仓点与FBA线路的预计卸柜/备货/行车时间及缓冲；首版可由人工维护，不能给所有线路统一默认天数。
- 提柜、接仓、FBA/客户送货分别由哪些岗位联系，对方是否由承运商代约，以及超时未回复时由谁接手。
- 总览默认使用哪个业务时区，以及跨时区团队是否保存个人显示偏好。
- 尚未满足现有拼车发布条件时，仅预排是否满足经营需要；如必须提前成交远期运力，需明确范围和承诺方式，不能省略这项能力差异。
十二 现有实现入口
| 用途 | 入口 |
|---|---|
| 当前预约页面与字段 | AppointmentCalendarView.vue、日历读取API |
| FBA预约现行边界 | 海外仓业务预约送仓、预约服务 |
| FBA必填字段 | 创建请求、Lastleg初始化基线 |
| FBA预约货源与柜级到仓锁定 | 预约查询Mapper、尾程订单服务 |
| 码头提柜与还空 | terminalDrayages.ts |
| 柜级预计及实际到仓 | containerArrivalTimes.ts |
| 车次及运输资源 | tripTypes.ts、trips.ts |
| 外接承运预订 | tripBookings.ts |
| 车次计划容量及拼车发布 | 车次执行服务、余位发布服务、拼车主契约 |
| 排车独立预约字段 | dispatches.ts、DispatchService.java |
| 派送计划与实际签收 | deliveryOrders.ts |
| 本土运输需求日期 | 海外业务类型 |
| 全流程维护入口 | 头程到尾程README |