采购配方展开订货小工具——门店要货汇总一键拆成原料采购单，多级配方扣库存扣在途，尾差单列让你看见积压

你是一个编码代理。请为我做一个单文件 HTML 的「配方展开
订货」工具，给中央厨房采购用：输入门店要货汇总，按配方
自动拆成原料采购单，浏览器本地运行，不联网、不装依赖、
不引任何外部资源。

一、输入（三个可粘贴的表格）
1. 要货汇总：门店 / 成品品项 / 数量 / 需求日期
2. 配方表（BOM）：父项 / 子项 / 单耗——允许多级：
   成品用到半成品，半成品再用到原料（如 卤肉包 →
   卤水 → 香料），单耗按父项一份计
3. 库存与在途：子项 / 现有库存 / 在途数量 / 可用
   日期

二、计算（展开逻辑固定）
- 多级展开：从成品逐层拆到最底层，同一子项在多条
  路径出现的，毛需求合并
- 净需求 = 毛需求 − 可用日期不晚于需求日期的库存
  与在途，结果不为负
- 半成品自制优先：某子项标了「自制」的，先扣半成品
  库存，缺口再展开到它的下层原料
- 供应商规格换算：每个采购件填规格（如 25kg/件），
  订量 = 净需求向上取整到规格的整数倍
- 尾差单独一列：取整后多订的量。同一原料的尾差
  周周累积是常见的隐性积压，工具不替你判断，只让
  你看见

三、输出
- 表一：采购单——原料 / 净需求 / 规格 / 建议订量 /
  尾差 / 涉及的成品（哪几张要货拉出来的）
- 表二：半成品排产提示——各自制件的净需求缺口，
  复制给厨师长排产用
- 合计行 + 一键复制为制表符分隔文本（粘进微信和
  Excel 都不乱）+ 导出 CSV

四、防错
- BOM 存在环（A 的下层用到 A）：展开前检测，检测到
  就列出环路径并拒绝计算，不许死循环
- 单耗为空或为 0 的行：标红列出，不参与计算
- 某原料没有库存数据：按净需求等于毛需求处理并
  在结果里标注
- 可用日期晚于需求日期的在途，不许抵扣当期需求

五、数据
- 配方表与规格表存 localStorage，可导出 JSON 备份、
  导入恢复；要货汇总每次粘贴即用，不保存
- 不做价格计算——价格是采购谈判的变量，进了工具
  反而会被人当固定成本看

界面：桌面优先，三块输入一屏排开，结果表可直接框选
复制。交付一个完整 HTML 文件，内联全部 CSS 与 JS，附
两百字以内的中文使用说明。

为什么这样写

多级展开加环检测，是这个工具真正的门槛，也是 Excel 手工做不动的部分：采购在表里拆三层配方，任何一张要货单改动都意味着整表重算，而配方改版（卤水配方换了）意味着逐行核对。这些机械劳动里最容易错的恰恰是「同一原料在多条路径出现要合并」——香料既在卤水又在腌料里，手工分列加总，漏一列就少订一批。工具把合并、扣减、取整的规则一次写死，人只维护配方和规格两份主数据。

半成品先扣自制库存再展开，是中央厨房和普通餐饮订货的分水岭：同样是「要 2000 个卤肉包」，纯贸易逻辑直接拆到香料，但厨房里还剩 80 公斤卤水——这 80 公斤不扣掉，采购就会多订一批香料的钱。把自制件当一层有库存的中间品处理，排产提示（表二）顺手就有了，厨师长拿到的缺口数和采购看到的原料数出自同一次展开，两个部门不用对账。

在途的「可用日期」校验是踩坑之后才会有的规则：在途数量看着能抵扣需求，但船期排在下周一、生产排在周日，数字上抵掉了、实物上断料。让在途按可用日期和需求日期比对后才允许抵扣，是把这个坑一次性焊死。

尾差单列但不给建议，是工具的边界感：取整多订的部分本周看着无害，周周累积就是冷库里慢慢长出来的积压。工具的职责是让「每次多订 7 公斤」从不可见变成可见，动不动加安全库存、要不要谈小规格，是采购拿这个数字去做的人的决策——数据工具替人看见，不替人决定。

变量