送货车扎堆，是排期问题不是人手问题
早上八点半，三辆送货车同时进厂。冷库那边只有两个卸货口、一台叉车。采购说"我明明跟供应商讲好九点"，供应商说"路上顺，早到了我也没办法"。接下来通常是这样几幕：卸货口排队，司机把车停在厂区主路上，安全员一天来提三次意见；收货员被电话追着问"我的货什么时候能卸"，而手上这张单还没核完；短少几件、外箱破损当场说不清，谁在几点交的货、卸了多久，全靠事后回忆；采购订单里"已到货"三个字靠人手工去改，账和货三五天对不上一次。
这些现象背后缺的不是人手，而是把"到货"从一件随机发生的事，变成一张有承诺、有容量上限、有留痕的排期表。要落地的事情就三件：把一天切成有上限的时段格子，让供应商自己来占格子，让门口的人只做核销和登记。
这套模块适合谁：有固定收货口（月台、卸货位、冷库门）的仓库、工厂、连锁配送中心；供应商数量在几十家以上，或者一天到货车次超过五趟；已经在用采购订单，但"到货"这一步还靠电话、微信群和纸单衔接。
第一层：数据怎么建
不要一上手就画页面，先把四张底表和一本字典定下来。表定错了，后面所有报表都是错的。
一、月台档案表。 一行一个收货口。字段：月台编号、所属仓库或厂区、可卸货物类型（常温、冷藏、危化等，取值走数据字典）、同时可作业车位数、是否在用。这张表是后面所有排队的前提，先把"我们到底有几个口"数清楚。
二、时段容量表。 一行 = 某仓库 × 某日期 × 某小时段。字段：该时段最大可接车次、最大可卸托盘数（或重量上限）、备注（例如"该时段只有一名收货员"）。这张表不给人看排班用，它是系统判断"这个时段还能不能接单"的唯一依据。
三、预约单（主表）。 一行 = 一次送货承诺。字段：预约号（唯一）、供应商（引用供应商档案）、采购订单号或送货单号、货品大类、预计到达时段、预计件数 / 重量 / 托盘数、指定月台、承运司机与车牌（可空）、状态。预约号建议加唯一约束，并用"供应商 + 采购订单 + 时段"做重复提交拦截，否则会出现同一车货被占两个格子。
四、到货核销记录（子表）。 一行 = 一次实际到货动作。字段：实际到达时间、开始卸货时间、结束时间、实际件数与重量、差异类型与差异件数、现场照片（附件）、核销人、核销时间。
三条关键设计决定，值得在动手前想清楚：
主表和子表必须分开。 预约是承诺，核销是事实。一次预约完全可能分批到货——先卸一半，剩下明天补。所以"实际到达时间""实际件数"这类字段只能放在核销子表上，一预约对多条核销。若把它们塞进主表，第二批货一到就没有地方写了，报表的准时率也会失真。
状态先定字典，不要写成固定选项。 建议的起步状态：待供应商确认 → 已确认（占容量）→ 部分核销 / 已核销 → 超时未到 → 已取消 → 已完成。状态集中在数据字典里维护，之后要加"待检验""待退货"这类状态，改字典不动表结构，历史单据也不会乱。字典怎么建，可以参考 数据字典：管好下拉选项的统一口径。
容量必须能被系统算出来。 预约提交的那一刻，系统按"仓库 + 日期 + 时段"去查容量表剩余数，占满就转候补或要求改时段。人工判断"差不多还能再来一车"，是排队问题的起点，不是解决办法。
第二层：按角色分页面
同一个模块，四类人看到的应该是四个样子。谁也不该在一张万能表格里找自己那一行。
收货主管（PC）。 主页面是月台日历：横轴日期、纵轴月台，格子里显示该时段已占车次与占用率，一眼看出下周哪几个小时是红的。旁边两个列表常驻——「超载时段」（占用率超过容量的时段）和「待确认预约」，用来提前一周调节，而不是当天救火。
采购 / 计划（PC）。 主页面是「未预约到货清单」：已下采购订单但供应商还没预约的单子。这张清单是这套模块真正的杠杆，催供应商的动作从这里发出去，比事后追着问"货到哪了"有效得多。同屏给出供应商维度视图：谁按时预约、谁老是临时插单。
供应商（手机端）。 只有两件事：选时段提交预约、改期。历史记录里能看到自己过往的到货准时情况——把数据摆给他看，比采购打电话说"你又迟到了"有分量。
门岗 / 收货员（手机端）。 打开就是今日到货清单，按时间排序。核销按钮做到最大，一次点击完成"到了"；随后登记实际开始与结束卸货时间、实际件数、差异类型，需要时拍照上传。不需要他做判断题，只需要他做记录题。
报表。 四张固定的：供应商准时到货率（按预约时段与实际到达比）、平均等待时长（到达 → 开始卸）、平均装卸时长、月台占用率；再配一张差异件数趋势，用来判断问题是集中在某家供应商，还是集中在某个货品大类。这些指标只记录系统内发生的事实，具体达标线请按企业自有标准设定，不写进系统当承诺。## 第三层：四类自动化，把重复动作接走
系统的价值不在于多一张表单，而在于把每天重复的判断和通知交给规则跑。这四类在 Inkwell AI 构建器里都是配置项，不是开发任务：
定时任务——按点跑的事。 每天早上把当日到货清单推给门岗和收货主管；每半小时扫一遍"已过预约时段仍未核销"的记录，标记超时并通知供应商对接人；每周一汇总上周准时率发给采购负责人。定时任务用 Cron 表达周期，执行记录可查，跑失败能看出是哪一次，做法见 工作流与定时任务：让重复性工作自动跑。
数据流规则——条件满足了就动数据。 核销完成时，按预约单上挂的采购订单号回写采购侧的到货状态与到货数量，人不用再手工改第二个系统；差异件数超过阈值时自动生成一条待处理记录，转让步接收或退货评审；预约量触到时段容量上限时，把新提交的单子自动置为候补状态。规则是"当满足条件 → 执行动作"的结构，改规则不需要改表。
审批流——需要人点头的节点。 三类走审批：当天新增的临时插单（占用已排好的容量，得主管批）、月台临时关闭（维修、消杀），以及月度容量表调整。月台关闭审批通过时同步触发受影响预约的改期通知，否则关闭一天、十张预约单要靠人逐个打电话。
通知——消息找对人。 同类事件对三种角色走三种通道：收货员看站内信，供应商对接人收邮件，超时未到货这种要立刻处理的走短信。通知模板单独维护，改文案不动流程。
第四层：手机端怎么配合
这类模块有个特点——预约的动作在厂外（供应商手上），核销的动作在门口（门岗手上），两头都离不开手机。PC 上把模块搭好，手机工作台会同步出现对应页面，但预约表单的字段排布要在移动端单独调一次，这一步别省。移动端的整体机制见 移动端使用指南：工作台、模块页与手机上的 AI 构建，产品面见 移动端。
三个实用细节：
- 供应商侧表单只留四项：日期时段、货品大类、件数 / 托盘数、车牌。其余从供应商档案和采购订单带出，屏幕窄，字段多一个流失率就高一截。
- 门岗侧流程要"扫一眼就能点"：今日清单按时间排序，超时的行标红，核销动作一屏完成；拍照直接调起相机上传成附件，不让收货员先存相册再翻文件。
- 现场网络通常不好：登记页要先能填、再能交，提交失败留在本地不要清空。这条在真实收货口一定要实地测一次，办公室 Wi-Fi 下测不出来。
另外建议保留一块"落纸"能力：当日月台排班表可打印贴在门岗窗口，门口的司机不看系统，看纸上那张。数字化先把调度室的判断接过来，不必强求所有人在第一时间换成屏。
上线前要查的七件事
- 容量先实地核一遍。 每个时段最多接几车、每车最多卸多少托盘，仓库主管带着表到收货口走一遍再填。容量表填得虚，限流就是假的。
- 供应商名单先清洗。 一家供应商一条档案。同一个供货方在三张预约单上写成三个名字，准时率就永远算不准，供应商考核也没法谈。
- 状态字典定稿。 起步六个状态、允许的流转路径写清楚，先跑两周，再讨论加"待检验""待退货"。
- 唯一约束与重复拦截。 预约号唯一，以及供应商 + 采购订单 + 时段的重复提交拦截，防刷单占容量。
- 权限按角色配。 供应商只能看自己的预约；收货员能核销但不能改容量表；容量调整和插单审批只给主管。这块用平台的权限体系配置即可，参考 角色与权限配置：从内置角色到自定义授权。
- 期初数据一次性导入。 在途和已确认的送货计划用 Excel 导进来，不要手录——导入方法见 用 Excel 一步建模块：从表格到可用的业务系统。
- 先一条线试跑，再全厂推。 选一个收货口、两三家配合度高的供应商跑两周，把准时率和差异登记跑顺，再扩。跑之前记得走一遍模块测试与发布预检，见 模块的测试与发布：预检、挂载菜单与移动端同步。## 之后怎么延伸：从排队问题长成收货台账
到货预约跑顺之后，它天然连着上下游，可以按需一段段接：
- 接库位与出入库。 核销完的到货单可以直接生成收货单，进入上架、拣货流程，收货数据不用在两处各录一遍，见 仓储库位与出入库：收货、上架、拣货、出库一本账。
- 接采购链路。 请购、下单、预约、到货、对账连成一条线，采购订单的到货状态由核销动作自动推动，见 采购管理：请购、订单、入库、对账一条线。
- 接运输侧。 如果承运商自己已经在排车次，预约时段可以由运输方直接发起，你只做容量分配和核销，见 运输管理：调度、在途与运费结算。
- 接供应商考核。 准时率、差异率沉淀下来，进供应商评级，采购谈判时是硬材料，见 供应商管理：档案、评级与供货记录。
每条延伸都是独立模块，不需要一次全上。建议顺序：先把预约与核销跑稳一个月，再决定下一步接采购侧还是接仓储侧——哪一头现在最痛，就接哪一头。
这套方案不做什么
边界说清楚，比能力说满更有用：
- 不做车辆在途定位与轨迹回放。 那是运输调度的事。这里只回答三个问题：到没到、几点开始卸、卸了多久。
- 不做道闸、地磅的硬件直连。 地磅读数先由人录入。硬件对接涉及现场设备与协议，需要单独评估，不在这套模块的范围内。
- 不做最优车位分配的求解算法。 时段容量是人按经验和人力配置设定的规则，是"限额 + 先到先得 + 主管调额"，不是一个自动排优引擎。
- 不做多仓库的跨仓统一调度策略。 多个仓库可以各建各的容量表、各跑各的排班，但"哪个仓应该接这车货"这类决策，仍然由人做。
- 不建议一上来就精细化到 15 分钟粒度。 起步按小时切格子就够用，粒度太细会让供应商填不动，反而回到电话预约。
三个常见误解
「供应商不配合怎么办？」 这是推行问题，不是系统问题。两个抓手：把预约入口做成不用装 App、点开就能填；以及把"已预约"作为收货的前置条件——没预约的单子排在候补队尾。规则一视同仁，配合度两周内会自己上来。
「预约了但没来，格子白占着。」 所以状态里必须有「超时未到」，并且超时后容量要能被释放。定时任务扫出来标记超时，格子按企业自定规则释放或降为候补，不要让人手工去删。
「这不是又多了一个系统要供应商学？」 对供应商来说只是多了一次填四格的操作，省下的是他司机在厂门口干等的时间。等他能看到自己的准时率数据，这套东西对他是有利的——这是唯一的说服逻辑。
一句话记法
到货预约与月台排班 = 一张有容量上限的时段表 + 一张供应商自己填的预约单 + 一张门口核销的事实记录。三张表对齐，门口的队伍就从口舌变成了排期。
要搭的话，先把月台档案和时段容量这两张底表定下来，其余页面用 AI 构建器一句话一句话生出来，改起来也快——不必先写需求文档再等排期。