🚀 第12天：用多维表格“手搓”一个简易ERP（MRP全阶运算篇）
✨ 系列第12篇｜从零开始搭建标准ERP架构
👣 延续上一篇第1层MRP设计，今天我们进入 MRP的另一种核心模式：全阶展开计算
🔔 关注【信胜优】，看懂如何让数据“动起来”
🔧 模块升级：古哥ERP_V1.4 支持双模式MRP
在昨天我们完成了 MRP第一层需求 的设计后，今天我们将引入 全阶MRP运算 —— 一种更适合工艺稳定、批量生产场景的高效计算方式。
💡 为什么需要两种模式？
逐层运算：适用于复杂制造，可灵活调整每层参数（如损耗率、库存扣减）
全阶运算：适用于标准化产品，一次性拆解到最底层，快速生成毛需求
这就像“慢工出细活”与“一锤定音”的区别。我们的系统现在支持两种模式并存，适配更多企业场景。
🎯 全阶MRP的核心逻辑
全阶MRP的思路非常直接：
从销售订单出发 → 直接在树形BOM中查找该物料的所有子件（无论几级）→ 按用量乘以订单数量 → 一次性算出全部毛需求
不需要分层、不需要中间表、不需人工干预，一次完成所有层级的拆解。
📌 举个例子：
销售订单要生产100台A产品
A由B、C组成，B又由D、E组成……
那么全阶MRP会自动计算出：需要多少B、C、D、E……直到原材料
✅ 这种方式特别适合：
工艺成熟、BOM稳定的工厂
多品种小批量但结构固定的订单
快速响应客户需求的场景
📌 扩展「计划需求单」：新增“跑全阶需求”控制字段
为了实现“按需运行”，我们在「计划需求单」表中新增一个复选框字段：
字段名：跑全阶需求
类型：复选项
💡 用途：当PMC人员勾选此选项时，表示该订单需要进行全阶MRP运算。
📂 创建新表：全阶需求
接下来，我们新建一张数据表，命名为：
全阶需求
这张表将用于存储全阶MRP运算的结果。
字段设计如下：
销售订单号-项次（文本）
记录来源订单，确保可追溯
物料代码（文本）
存储最终拆解出的每一个子件编码
✅ 这两个字段是后续所有查找与计算的基础。
⚙️ 自动化流程：从计划需求单 → 全阶需求
现在，我们配置自动化流程，实现：
当用户在「计划需求单」中勾选“跑全阶需求”时 → 自动将该订单对应的所有层级子件全部提取出来，并生成对应的需求记录
流程命名：跑全阶需求
步骤一：触发条件
当「计划需求单」中的某条记录被修改，且“跑全阶需求”被勾选时
步骤二：查找触发记录
在「计划需求单」中查找当前触发的那条记录（即刚刚勾选的那条）
步骤三：查找树形BOM中所有匹配项
在「树形BOM」表中查找所有满足以下条件的数据：
- 父件 = 当前订单的“物料代码”
- 项次 = 对应项次（确保结构一致）
📌 注意：这里不是只找第一层，而是递归查找所有层级的子件！
步骤四：新增记录
在「全阶需求」表中新增一条记录
填写字段：
销售订单号-项次= 来自计划需求单物料代码= 来自树形BOM中的“子件”
✅ 这样一来，系统就能自动将一个父件拆解为所有下级子件，并生成完整的需求清单。
🔗 回到「全阶需求」表：补充关键信息
目前「全阶需求」表只有两个文本字段，我们需要把原始订单信息引用回来，以便后续分析与联动。
1. 引用父件信息（来自计划需求单）
新建查找引用字段：
字段名：物料名称
引用数据表：计划需求单
查找条件：销售订单号-项次 = 当前记录的“销售订单号-项次”
✅ 这样就能自动带出父件的名称，便于识别。
2. 引用子件信息（来自树形BOM）
新建另一个查找引用字段：
字段名：子件名称
引用数据表：树形BOM
查找条件：
产品= 当前记录的“物料代码”产品项次= 当前记录的“项次”
✅ 这样就能获取每个子件的详细信息，包括其属性（自制/采购）、层级等。
🧮 计算全阶子件毛需求
最后一步，也是最关键的一步：计算实际需求量。
在「全阶需求」表中，新增一个公式字段：
字段名：子件需求
类型：公式
公式内容：[@数量]*[@子件用量]
其中：
@数量：指当前订单项的物料数量（如400台）
@子件用量：来自树形BOM中的“子件用量”字段（如每台需2个A1）
📌 示例：
订单数量：400台
每台需A1：2个
则A1的总需求 = 400 × 2 = 800个
这个公式会自动计算每一行的毛需求，无需人工干预。
🔄 整体流程梳理：从订单到全阶需求
我们来回顾一下整个链路：
销售订单 → 生成销售订单明细
勾选“跑计划单” → 自动生成「计划需求单」
勾选“跑全阶需求” → 触发自动化流程
查找树形BOM → 获取该物料的所有子件（含多级）
自动新增到「全阶需求」表
公式自动计算毛需求量
✅ 一个完整的“订单 → 全阶需求”的闭环就此形成。
🌐 总结：为什么这种设计更强大？
| 传统做法 | 我们的设计 |
| MRP全自动运行，无法干预 | 保留人工选择权，灵活可控 |
| 结果一次性输出，过程不可见 | 分步执行，每一步都可审计 |
| 数据来源模糊 | 每条需求都有明确出处 |
| 不支持临时调整 | 可随时修改参数、重新运算 |
💡 核心价值在于：
把复杂的MRP运算，变成了可理解、可控制、可追溯的数字化流程。
🔮 下一篇预告：第13篇来了！
如果跑错了，如何取消已经跑出的需求？
如何实现“反向操作”？
是否支持批量撤销？
如何保证数据一致性？
我们将深入探讨“错误处理机制”，让你真正掌握系统的容错能力与可维护性。