简介：这份资源围绕IEEE 802.1Q标准框架下的MRP（Multiple Registration Protocol，多注册协议）展开，面向网络工程师、嵌入式开发者及工业网络方向的学习者，帮助理解环形网络中数据流控制、冗余链路管理与环保护机制的底层实现。压缩包共2个文件，包含1个c源文件与1个h头文件，整体约6KB，其中源文件承载协议函数定义、状态机与事件处理逻辑，头文件则提供数据结构、接口声明与常量定义，便于对照阅读与二次开发。资源重点覆盖环形拓扑支持、动态注册、环保护、流量控制以及与VLAN优先级兼容等核心特性，读者可借此梳理MRP在工业自动化、电力传输、轨道交通等实时性要求较高场景中的工作流程，并掌握协议定制与扩展的切入点。目前已有119人学习，适合希望深入协议源码细节的开发者参考。

1. 从一份 mrp.rar 说起：MRP 运算到底在算什么

如果你手上正躺着一个叫mrp.rar的压缩包，解压后是一套 MRP（Material Requirements Planning，物料需求计划）相关的源码或工具，那你大概率不是来听物料管理发展史的。你真正想知道的是：这套东西能不能跑、跑出来对不对、能不能塞进我现在的生产或进销存流程里。MRP 的核心任务其实很朴素——根据主生产计划、BOM 结构和库存现状，倒推出每个物料在什么时间需要采购或生产多少。听起来简单，但真正落地时，批量策略、提前期、损耗率、安全库存这几项参数一叠加，运算结果就会变得非常“玄学”。这份资源适合做生产计划、ERP 二次开发、进销存系统维护的工程师，也适合想自己搭一套轻量物料运算逻辑的开发者。下面我按“先看懂它在算什么，再动手跑通，最后把坑填上”的顺序拆一遍。

2. MRP 运算骨架：BOM 展开、净需求与提前期倒排

2.1 先分清独立需求与相关需求

MRP 运算最容易翻车的地方，不是代码写错，而是需求类型没分清楚。独立需求来自市场预测或客户订单，比如“下个月要卖 500 台整机”；相关需求是由 BOM 派生出来的，比如“500 台整机需要 2000 个螺丝”。很多 MRP 源码包会把这两类需求混在一张表里处理，结果就是螺丝也被当成独立需求去预测，库存直接爆掉。

常见做法是建两张表：一张demand_independent存成品或备件的独立需求，一张demand_dependent存 BOM 展开后的相关需求。运算时先跑独立需求，再逐层展开 BOM，把子件需求写入相关需求表。判断依据很简单：有父项物料的需求就是相关需求，没有父项的就是独立需求。

-- 独立需求表：只存成品或对外备件 CREATE TABLE demand_independent ( item_code VARCHAR(32) PRIMARY KEY, demand_qty DECIMAL(12,2), due_date DATE ); -- 相关需求表：BOM 展开后写入 CREATE TABLE demand_dependent ( item_code VARCHAR(32), parent_code VARCHAR(32), demand_qty DECIMAL(12,2), due_date DATE );

item_code是物料编码，parent_code记录它是由哪个父项展开出来的，due_date是需求日期。相关需求表不设主键，因为同一个子件可能被多个父项在同一时间需要，后面汇总净需求时再按物料和日期分组。

2.2 BOM 逐层展开与低层码

BOM 展开不是简单递归，因为同一个物料可能出现在不同层级。比如一个通用支架既用在第一层，也用在第三层。如果按深度优先展开，这个支架会被计算两次，库存扣减就乱了。标准做法是给每个物料分配低层码（Low Level Code），也就是它在所有 BOM 路径中出现的最深层次。展开时按低层码从 0 到 N 逐层处理，同一物料只在它最低的那一层被汇总一次。

def explode_bom(parent_code, parent_qty, level, demand_rows, bom_map, llc): """按低层码逐层展开 BOM""" if parent_code not in bom_map: return for child in bom_map[parent_code]: child_code = child["child_code"] qty_per = child["qty_per"] scrap_rate = child.get("scrap_rate", 0.0) # 考虑损耗率的实际需求量 gross_qty = parent_qty * qty_per * (1 + scrap_rate) # 只有当前层级等于该物料的低层码时才写入需求 if level == llc.get(child_code, level): demand_rows.append({ "item_code": child_code, "parent_code": parent_code, "demand_qty": gross_qty, "level": level }) explode_bom(child_code, gross_qty, level + 1, demand_rows, bom_map, llc)

bom_map是父项到子件列表的映射，qty_per是单位用量，scrap_rate是损耗率。关键判断是level == llc.get(child_code, level)，只有到达该物料的最低层时才记录需求，避免重复计算。llc需要提前用一次遍历算好，不能边展开边算。

2.3 净需求计算：库存、在途与安全库存

毛需求汇总完之后，净需求 = 毛需求 - 可用库存 - 在途量 + 安全库存。这里有个容易忽略的点：可用库存要扣掉已分配量。很多简易 MRP 只拿现存量去减，结果已经发给生产线的物料又被算进可用库存，净需求偏小，最后缺料停线。

def calc_net_requirement(gross_qty, on_hand, allocated, in_transit, safety_stock): available = on_hand - allocated net = gross_qty - available - in_transit + safety_stock return max(net, 0)

on_hand是现存量，allocated是已分配量，in_transit是采购在途或生产在制，safety_stock是安全库存。max(net, 0)保证净需求不为负，负值代表有富余库存，不需要补充。这个函数看着简单，但参数来源必须和库存系统对齐，否则算出来的净需求就是黑匣子。

2.4 提前期倒排与计划订单

净需求算出数量还不够，还得知道什么时候下单。MRP 用提前期倒排：计划订单下达日期 = 需求日期 - 提前期。采购件用采购提前期，自制件用生产提前期。如果提前期是变动的，比如供应商交期随批量变化，那就得按批量分段取提前期，不能一刀切。

from datetime import timedelta def backward_schedule(require_date, lead_time_days): """按提前期倒排计划订单下达日期""" return require_date - timedelta(days=lead_time_days)

require_date是净需求对应的需求日期，lead_time_days是提前期天数。倒排之后还要做能力校验，如果下达日期已经早于今天，说明交期不满足，需要标记例外信息，而不是硬算一个过去的日期。

3. 把 mrp.rar 跑起来：环境、数据与第一次运算

3.1 解压后先看目录结构再动手

拿到mrp.rar之后别急着双击运行。先解压到一个纯英文路径下，中文路径在某些老式数据库连接组件里会直接报错。解压后重点看三个地方：有没有sql或db目录存放建表脚本，有没有config或settings文件存放数据库连接信息，有没有readme或doc说明运行入口。如果压缩包里只有源码没有建表脚本，那大概率需要你自己根据实体类反推表结构，这种情况先找model或entity目录。

常见做法是先把数据库建好，再改配置文件，最后跑主运算类。顺序反了会出现表不存在、字段不匹配、编码乱码一连串问题。我一般会先备份一份原始压缩包，解压后的目录单独放，改坏了直接重来。

3.2 数据库准备与基础数据导入

MRP 运算依赖几张核心表：物料主数据、BOM 结构、库存现存量、独立需求、提前期参数。如果资源包里带了示例数据，先用示例数据跑通，再换自己的数据。换数据时注意物料编码长度和类型要和 BOM 表里的子件编码一致，一个是VARCHAR(20)一个是VARCHAR(32)，关联时可能因为尾部空格匹配不上。

# 以 MySQL 为例，先建库再导入脚本 mysql -u root -p -e "CREATE DATABASE mrp_demo DEFAULT CHARSET utf8mb4;" mysql -u root -p mrp_demo < sql/schema.sql mysql -u root -p mrp_demo < sql/sample_data.sql

第一条命令建库并指定字符集，第二条导入表结构，第三条导入示例数据。如果你的 MySQL 版本是 8.0 以上，注意utf8mb4和旧版utf8的区别，物料名称里有生僻字时用utf8mb4才不会乱码。导入完成后用SHOW TABLES;确认表数量，再用SELECT COUNT(*) FROM bom;看 BOM 行数是否和预期一致。

3.3 配置参数与第一次运算

配置文件里通常有几项关键参数：数据库连接、运算日期范围、是否考虑安全库存、是否考虑损耗率、批量策略。第一次跑建议先把安全库存和损耗率关掉，只跑最基础的毛需求展开和净需求计算，确认 BOM 展开层数和数量对得上，再逐项打开高级参数。

# mrp.properties 示例 db.url=jdbc:mysql://127.0.0.1:3306/mrp_demo?useUnicode=true&characterEncoding=utf8mb4 db.user=root db.password=your_password mrp.plan.start=2025-01-01 mrp.plan.end=2025-03-31 mrp.use.safety.stock=false mrp.use.scrap.rate=false mrp.lot.policy=fixed mrp.lot.size=100

mrp.plan.start和mrp.plan.end是运算覆盖的日期范围，超出范围的需求不参与运算。mrp.use.safety.stock和mrp.use.scrap.rate先设为false，减少变量。mrp.lot.policy是批量策略，fixed表示固定批量，mrp.lot.size是批量大小。第一次跑完重点核对三件事：成品需求数量是否等于独立需求表汇总，第一层子件数量是否等于成品数量乘以单位用量，计划订单下达日期是否等于需求日期减去提前期。

3.4 运算结果核对与日志排查

跑完之后不要只看程序有没有报错，要看结果表里的数据是否符合业务常识。常见核对方法是从成品往下抽一条 BOM 路径，手工算一遍毛需求和净需求，再和结果表对比。如果数量对不上，先查 BOM 表里有没有循环引用，再查低层码是否算错，最后查库存可用量是否扣除了已分配量。

-- 核对某成品的第一层子件毛需求 SELECT d.item_code, d.demand_qty, b.qty_per, d.demand_qty * b.qty_per AS expected_qty FROM demand_dependent d JOIN bom b ON d.item_code = b.child_code WHERE d.parent_code = 'FG-001';

这条 SQL 把相关需求表和 BOM 表关联，算出理论毛需求，再和结果表里的计划订单数量对比。如果expected_qty和结果不一致，优先检查损耗率是否被意外启用，或者批量策略是否把数量向上取整了。日志里重点看WARN和ERROR级别，尤其是“物料编码不存在”“BOM 循环引用”“提前期为负”这几类信息，它们往往指向基础数据问题而不是程序 bug。

4. 避坑与排查：MRP 运算里最容易翻车的五件事

4.1 现象：BOM 展开数量翻倍；原因：低层码未提前计算；解决：先算 LLC 再展开

这是血泪经验里排第一的坑。程序跑完发现某个通用件的需求是手工计算的两倍，查来查去发现它在 BOM 里出现在两个层级，展开时被加了两次。根因是低层码没有提前算好，或者算的时候只遍历了一条路径。解决方法是单独写一个calc_llc函数，遍历所有 BOM 路径取最大深度，展开时严格按低层码逐层处理，同一物料只在最低层写入需求。

4.2 现象：净需求偏小导致缺料；原因：可用库存没扣已分配量；解决：库存口径对齐

库存表里有一个on_hand字段，但仓库已经把一部分物料分配给生产线了，这部分在allocated字段里。如果净需求只减on_hand，算出来的可用库存虚高，净需求偏小，采购计划下少了，上线就缺料。解决方法是净需求计算统一用on_hand - allocated，并且确认allocated字段的更新时机和仓库发料动作同步。

4.3 现象：计划订单下达日期跑到过去；原因：提前期大于需求日期减今天；解决：标记例外而不是硬算

倒排日期时如果提前期是 30 天，而需求日期是 10 天后，算出来的下达日期就是 20 天前。程序如果直接写入这个日期，采购模块会生成一张过期订单。正确做法是判断plan_start_date < today时标记为例外信息，提示计划员要么催料要么调整需求日期，而不是硬算一个没有意义的过去日期。

4.4 现象：批量策略导致库存积压；原因：固定批量远大于净需求；解决：按需调整批量或改用动态批量

固定批量 100，净需求 12，计划订单就下 100，多出来的 88 变成库存。短期看是库存积压，长期看是资金占用。解决方法是根据物料 ABC 分类设置批量策略：A 类高价值物料用按需批量，B 类用固定批量但批量值调小，C 类低价值物料才用较大的固定批量。批量策略没有万能公式，得结合采购周期和仓储成本调。

4.5 现象：运算结果每次跑都不一样；原因：运算日期范围或数据快照不一致；解决：固定快照再运算

同一个计划日期，上午跑和下午跑结果不同，往往是因为运算期间有人改了库存或 BOM。MRP 运算应该基于一个数据快照，而不是实时表。常见做法是运算前把相关表数据复制到临时快照表，运算全程读快照，跑完再对比差异。这样至少保证同一次运算内部数据一致，排查问题时也有据可查。

5. 进阶技巧：用差异对比验证 MRP 结果是否可信

5.1 建立基线运算与差异表

MRP 结果对不对，单看一次运算很难判断。我一般会先跑一次基线运算，把结果存到mrp_result_baseline表，然后改动一个参数再跑一次，把新结果存到mrp_result_current，用差异对比看哪些物料的需求变了、变了多少。这个方法比逐条手工核对快得多，也更容易发现参数之间的相互影响。

-- 差异对比：找出两次运算结果不一致的物料 SELECT COALESCE(b.item_code, c.item_code) AS item_code, b.plan_qty AS baseline_qty, c.plan_qty AS current_qty, c.plan_qty - b.plan_qty AS diff_qty FROM mrp_result_baseline b LEFT JOIN mrp_result_current c ON b.item_code = c.item_code WHERE b.plan_qty <> c.plan_qty OR c.item_code IS NULL;

COALESCE处理一边有一边没有的情况，diff_qty是差异数量。如果只改了一个参数，差异却扩散到几十个物料，说明这个参数影响面很大，需要重点确认。比如打开损耗率之后，所有含损耗子件的父项需求都会变，这是正常的；但如果某个不相关物料也变了，那就要查 BOM 关联是不是写错了。

5.2 用关键路径抽查代替全量核对

全量核对几千行 MRP 结果不现实，我习惯抽三条关键路径：一条最长 BOM 路径、一条通用件出现次数最多的路径、一条提前期最长的采购件路径。最长路径验证展开层数，通用件路径验证低层码，长提前期路径验证倒排日期。三条路径手工算一遍，和结果表对上，基本就能判断运算逻辑有没有大问题。

这张表可以照着建一个检查清单，每次改完参数跑完运算都过一遍。三条路径都对了，再去看全量结果，心里才有底。

5.3 把例外信息当成入口而不是噪音

MRP 跑完会生成一堆例外信息：提前期不足、物料编码不存在、BOM 循环引用、库存为负。很多人嫌烦直接忽略，但这些例外信息恰恰是基础数据质量的入口。我一般会按例外类型分组统计，数量最多的那类优先处理。比如“物料编码不存在”排第一，说明 BOM 表里有废弃编码没清理；“提前期不足”排第一，说明主计划排得太紧或者供应商交期没维护准确。

从那以后我每次跑 MRP 都强制走一遍“基线运算 → 差异对比 → 三条路径抽查 → 例外信息分组”这个流程，不再只看程序有没有报错。这套习惯帮我省掉了大量上线后缺料停线的后悔药。希望帮到你。

本文还有配套的精品资源，点击获取