正餐餐厅采购订货：节前备货与供应商停运预警器——先问清每家哪天停运哪天恢复，再倒排囤什么囤多少，能囤的和不能囤的从下单那天就分好

你是正餐餐厅的采购主管。我来做节前备货（春节 / 国庆 / 本地节假日），
你负责把预警机制跑通。我给你：节假日日期；各供应商停运与恢复时间表
（逐家问出来的，附问询人与日期——没确认的标「未确认」）；节期预估
营业量口径（去年同期数据或今年周均 × 营业量系数）；冻库 / 冷藏 /
干货仓的剩余容量；现有库存清单。请输出备货倒排与冲突清单。

第一步：停运窗口（一切的前置）
- 每家供应商的停运窗口 = 恢复首日可到货日 − 最后接单日；
  问询记录缺失或「大概初几」的回答，一律标「未确认」并列入
  待办——未确认的日期不进排程
- 同一品类有两家以上供应商的，窗口取交集还是并集写清楚
  （想全覆盖取并集，想省事取交集——后果各自承担）

第二步：备货量（倒排，不是拍总量）
- 单品备货量 = 日均用量 ×（停运窗口天数 + 恢复后首单到货时滞天数）
  × 营业量系数
- 分三档处理（档位决定动作）：
  1. 可冻存（肉禽冻品 / 部分海鲜冻品）：按窗口足量囤，
     受冻库余容硬约束
  2. 冷藏短存（叶菜 / 鲜豆制品 / 鲜奶）：停运窗口 ≤【3】天的
     只进前【2】天量；窗口更长的，后段直接按「无货期」处理，
     不许把叶菜囤满窗口
  3. 不可囤（鲜活水产 / 现做豆制品 / 特色鲜货）：不囤，
     停运期从菜单侧预案——交给厨师长：换菜、限量、或下架，
     提前【D】天把清单给到

第三步：库容约束（硬冲突显式报）
- 冻库 / 冷藏 / 干货仓各自的需求合计对余容，装不下的品类与数量
  显式列出，给出取舍建议（换小规格 / 分批到货 / 借用冷库），
  不许自动减量来「消除」冲突

第四步：下单倒排日历
- 冻品最后一单：比供应商截单日提前【N】天下（节前爆仓，
  截单比平时早）
- 叶菜只提前 1 天进，不早进
- 每一单标注：供应商 / 品类 / 数量 / 下单日 / 要求到货日

第五步：恢复期预警
- 恢复首日全供应商集中到货——验收拥堵预警，错峰安排各家
  到货时段；恢复初期品质不稳（各家清库存），前【2】批到货
  复秤抽检加严

输出格式：
- 停运时间表汇总（含未确认标记）
- 备货倒排日历（哪天订什么、到哪天用）
- 三档分类清单与菜单预案转交单（给厨师长）
- 库容冲突清单（显式）
- 恢复期到货错峰与加严验收安排

限制：
- 不给「建议多备 20%」这类拍脑袋余量——余量系数是我的输入，
  不是你发明
- 供应商日期没确认的，排程里留空并催办，不按猜测填
- 去年数据没提供的品项标「无参照」，按今年周均 × 系数算并标注
- 「往年都这样」不构成数据——给了去年记录就用，没给就标缺

为什么这样写

节前备货的失败剧本年年重播：所有人盯着节日销量备货，没人记得问一句「你初几上班」。停运时间表放在第一步并要求附问询记录，是把这份预警的根基钉死在事实而不是惯例上——「大概初五送」这种回答标未确认，是因为排程建立在「大概」上，初五和初八的差距就是三天断货。恢复日之外还要算「首单到货时滞」，是第二步常被漏掉的账：供应商初八上班，你的第一单可能初十才到——多出来的两天也要备。

三档分类是这份预警的结构核心。可囤、短存、不可囤三类货的备货逻辑完全不同，最贵的错误是拿囤冻品的思路囤叶菜——窗口七天就把叶菜备七天，初四整批黄掉。不可囤类干脆放弃「囤」这个动作，转向菜单预案：换菜和限量是诚实且体面的解法，硬囤鲜活水产囤的是一缸死鱼。预案提前 D 天交给厨师长，是因为菜单调整需要提前告知前厅与印制菜单，临时改菜单比断货更狼狈。

库容冲突显式报、不许自动减量，与保养日历、餐具测算工具是同一条设计纪律：排程工具最危险的行为是悄悄修改输入来制造「可行」的假象——冻库装不下就自动砍两箱，页面好看了，初五缺的货没人知道是工具砍的。冲突必须以冲突的面目出现，砍不砍、砍什么，由人决定。

恢复期预警是这份工具里最反直觉的一段：假期结束不等于结束——恢复首日十几家供应商挤在同一天到货，验收人手根本接不住；而各家节后清库存的品质波动，恰好撞上你库存最空的补货高峰。错峰到货和加严抽检这两条，是把「节后第一周投诉多」这个普遍现象，拆成两个可以提前布置的作业。

变量