简介：本资源是一份系统讲解物料需求计划（MRP）核心原理与实务应用的PPT课件，面向制造业生产计划员、供应链管理初学者及高校工业工程/物流管理专业学生，旨在帮助读者突破传统库存管理的盲目性困境，掌握基于主生产计划（MPS）、物料清单（BOM）和库存记录三大输入驱动的精准需求计算逻辑。课件共1个PPT文件（458KB），内容覆盖MRP基本原理、BOM分层编码与用量展开、净需求计算公式（Nj(t)=Gj(t)−Hj(t−1)−Sj(t)）、计划订货量与投入量推导、逻辑流程图及典型企业案例演算，含多层BOM结构图、需求对比表、期量标准示意图等可视化解析。目前已有677人学习下载，内容紧扣生产厂长在计划排程、库存控制与采购决策中的实际痛点，提供可直接用于课堂讲授或自学复盘的结构化知识框架与计算范式。
1. 物料需求计划（MRP）不是库存Excel表，而是制造业的“时间-数量”翻译器
你手上有张主生产计划表：下月5号要交200台A产品，15号再交150台；BOM里写着每台A含2个B部件、3个C部件；仓库系统显示当前B还剩80件、C剩45件，另有60件B下周三到货、90件C下周五入库。现在问题来了——B该什么时候下单？下多少？C要不要今天就补单？如果B的采购周期是7天、C是10天，最晚哪天必须发出采购指令才不会耽误5号的交付？
传统做法是翻Excel算：200×2=400→400−80−60=260件缺额→再查供应商起订量……但漏掉了关键变量：B本身还要用在其他产品上，而C的90件入库时间比B晚5天，若只按静态数字下单，5号当天B可能刚到货、C却还在路上——生产线直接停摆。MRP干的就是这件事：它不把物料当孤立库存项，而是把主计划（What/When）、产品结构（How Much）、时间轴（When to Start）三者焊死在一条逻辑链上，输出带精确时点的“动作清单”。它解决的不是“有多少”，而是“在哪个时间点，为哪个工序，准备多少数量的哪类物料”。适合正在从手工排产转向系统化计划的中小制造企业、ERP实施顾问、工业工程专业学生，以及被销售临时加单和仓库报损反复暴击的计划员。这不是理论模型，是每天早上八点你打开系统后第一眼要看的那张动态作战图。
2. MRP三大输入不是数据堆砌，而是时间坐标系的三个锚点
MRP的计算引擎像一台精密钟表，主生产计划（MPS）、物料清单（BOM）、库存记录这三者就是它的发条、齿轮和游丝。少一个，整个系统要么停摆，要么乱走时。很多人以为只要把数据导入系统就自动出结果，实际落地时90%的错误源于这三个输入没对齐时间粒度、版本和逻辑边界。下面拆解每个输入的真实含义、常见陷阱，以及我现场调试时必做的三步校验法。
2.1 主生产计划（MPS）：不是销售预测的复制品，而是可执行的“时间切片承诺”
MPS本质是企业向生产系统签发的“军令状”，它必须满足三个硬约束：
- 时间颗粒度统一：所有计划行必须按相同周期（如“周”或“日”）切分，不能混用“第1周”“3月15日”“Q2”；
- 需求来源可追溯：每行计划必须标注来源（如“合同号ABC-2024-001”“预测模型V2.1”），禁止出现“预估”“大概”等模糊字段；
- 版本强锁定：MPS一旦发布，后续所有MRP运算必须基于该版本快照，不可动态覆盖——否则BOM变更后重跑MRP，历史计划会全盘错乱。
提示：某公司曾将销售部每月初更新的滚动预测直接当MPS导入，结果MRP每天生成新计划，采购员收到的订单号天天变，供应商拒收。正确做法是：销售预测进系统做“参考源”，MPS由计划部每周五17:00前冻结并发布正式版，版本号含日期（如MPS-20240322-V1）。
校验脚本（Python）验证MPS时间连续性：
import pandas as pd def validate_mps_time_continuity(mps_df, time_col='week_start', freq='W-MON'): """ 检查MPS时间列是否严格按指定频率连续（无跳周、无重复） freq示例：'W-MON'（周一为周起始）、'D'（日）、'MS'（月首日） """ # 转换为datetime并排序 mps_df[time_col] = pd.to_datetime(mps_df[time_col]) sorted_df = mps_df.sort_values(time_col).reset_index(drop=True) # 生成理论时间序列 expected_dates = pd.date_range( start=sorted_df[time_col].min(), end=sorted_df[time_col].max(), freq=freq ) # 比对实际与理论 actual_dates = set(sorted_df[time_col]) missing = set(expected_dates) - actual_dates duplicated = sorted_df[time_col].duplicated().sum() print(f"时间范围：{sorted_df[time_col].min()} 至 {sorted_df[time_col].max()}") print(f"理论周期数：{len(expected_dates)}，实际行数：{len(sorted_df)}") print(f"缺失周期：{sorted(missing)}") # 输出具体缺失日期 print(f"重复行数：{duplicated}") return len(missing) == 0 and duplicated == 0 # 使用示例：读取MPS表（CSV格式，含week_start, product_code, qty列） mps_data = pd.read_csv('mps_input.csv') is_valid = validate_mps_time_continuity(mps_data, time_col='week_start', freq='W-MON')参数说明：freq必须与企业实际计划周期严格一致。若用“自然周”（周一至周日），选'W-MON'；若按“厂历周”（如第1周=1月1日~1月7日），需先用pd.offsets.CustomBusinessDay定义厂历，再传入。脚本输出缺失日期（如[Timestamp('2024-04-01')]），直接定位到哪周没填计划——这是MRP跑出“某物料突然缺3000件”的首要排查点。
2.2 物料清单（BOM）：不是静态树形图，而是带时序权重的动态装配网络
BOM常被误认为只是“产品拆解图”，但在MRP中，它是需求放大的计算器+时间偏移的转换器。关键差异在于：
- 层级编码隐含提前期传递：BOM中B部件属于A的1层，C属于B的1层（即A的2层），则C的需求时间 = A的交付时间 − A的生产周期 − B的生产周期；
- 用量必须是净用量：若BOM写“B部件：2个”，但实际生产中因工艺损耗需多领5%，则BOM用量应为2.1（而非在MRP外另加损耗系数）；
- 替代料必须显式声明：同一位置允许A/B两种原材料，BOM中需标注“替代组ID=ALT-001”，且注明主用料（A）与备用料（B）的切换条件（如“A缺货超3天时启用B”）。
我处理过一个典型翻车案例：某电机BOM中，定子铁芯（代码IR-100）用量标为“1”，但实际每台电机需叠压320片硅钢片，BOM未展开到片级，导致MRP计算铁芯需求量时直接×1，而采购按“1个铁芯”下单——结果仓库堆满未叠压的硅钢片，产线却等着叠压好的铁芯。根源是BOM层级断裂：IR-100本应是2层（父件：电机；子件：硅钢片），却被错误设为1层。
BOM完整性检查表（现场必填）：
| 检查项 | 合格标准 | 验证方法 | 不合格后果 |
|---|---|---|---|
| 层级深度一致性 | 所有同级子件必须在同一BOM版本中定义 | 导出BOM全量表，按parent_id分组，检查各组内level值是否全相同 | MRP倒推时间时，部分子件提前期被忽略，导致采购过早 |
| 用量单位匹配 | 子件用量单位必须与库存单位一致（如BOM用“kg”，库存记录也必须是kg） | 对比BOM用量列与库存表unit字段 | 净需求计算时单位换算错误，如BOM写“2.5”，库存单位是“吨”，MRP当2.5吨算 |
| 替代料标识 | 替代关系必须有唯一substitute_group_id，且主用料priority=1 | SQL查：SELECT * FROM bom WHERE substitute_group_id IS NOT NULL GROUP BY substitute_group_id HAVING COUNT(*) > 1 | 系统无法自动切换，紧急缺料时人工干预延迟 |
| 生效日期控制 | 每条BOM记录必须有valid_from和valid_to | 检查是否存在valid_from > valid_to或valid_from为空 | 新旧BOM混用，MRP同时读取两套结构，需求量翻倍 |
2.3 库存记录：不是实时快照，而是带“时间窗”的可用量动态池
库存数据最易被轻视，但它是MRP计算净需求的“地基”。很多企业直接导出ERP库存余额表就当输入，结果MRP天天报“缺料”，盘点却发现仓库堆满——问题出在可用量（Available Inventory）≠ 账面库存（On-Hand）。可用量必须动态扣除三类“已承诺但未消耗”的量：
- 已分配量（Allocated）：已绑定到某工单/销售订单，但尚未发料；
- 预计入库量（Scheduled Receipts）：已下单且确认交期，但未到货（注意：仅包含已审核采购单，不含询价单）；
- 在途量（In-Transit）：货物已发出，但物流未签收（需对接TMS系统获取实时状态）。
某汽车配件厂曾因此停产：MRP显示某轴承库存为0，紧急下单加急采购，三天后新货到库，发现原订单的200件已在运输途中，只是物流系统未回传签收状态。根源是库存表未接入TMS，MRP把“在途量”全算作0。
构建可用库存计算逻辑（SQL模板，适配主流ERP）：
-- 假设表结构：inventory_master（主库存表）、sales_allocation（销售分配表）、po_receipts（采购入库表）、tms_tracking（物流跟踪表） SELECT i.item_code, i.on_hand_qty, COALESCE(sa.allocated_qty, 0) AS allocated_qty, COALESCE(pr.scheduled_qty, 0) AS scheduled_receipts, COALESCE(tt.in_transit_qty, 0) AS in_transit_qty, -- 核心公式：可用量 = 账面库存 - 已分配 + 预计入库 + 在途 i.on_hand_qty - COALESCE(sa.allocated_qty, 0) + COALESCE(pr.scheduled_qty, 0) + COALESCE(tt.in_transit_qty, 0) AS available_qty FROM inventory_master i LEFT JOIN ( SELECT item_code, SUM(qty) AS allocated_qty FROM sales_allocation WHERE status = 'CONFIRMED' AND delivery_date <= '2024-04-30' GROUP BY item_code ) sa ON i.item_code = sa.item_code LEFT JOIN ( SELECT item_code, SUM(qty) AS scheduled_qty FROM po_receipts WHERE receipt_date BETWEEN '2024-04-01' AND '2024-04-30' AND status = 'APPROVED' GROUP BY item_code ) pr ON i.item_code = pr.item_code LEFT JOIN ( SELECT item_code, SUM(qty) AS in_transit_qty FROM tms_tracking WHERE current_status IN ('SHIPPED', 'IN_TRANSIT') AND expected_arrival <= '2024-04-30' GROUP BY item_code ) tt ON i.item_code = tt.item_code WHERE i.warehouse = 'MAIN_WHS';关键参数说明：
delivery_date <= '2024-04-30'：只统计计划在MRP计算周期内交付的已分配量，避免远期订单占用当前可用量；receipt_date BETWEEN ...：预计入库量必须限定在MRP计划期（如未来8周），否则系统会把半年后的到货当“即时可用”；current_status IN ('SHIPPED', 'IN_TRANSIT')：在途量必须排除“已签收”状态，且需物流系统提供expected_arrival字段——若TMS无此字段，宁可不用在途量，也不能瞎猜。
3. MRP核心计算不是四则运算，而是带时序约束的净需求传导链
MRP的计算过程常被简化为“G−H−S=N”，但真实场景中，净需求（N）不是终点，而是触发下一层级需求的开关信号。它像多米诺骨牌，从顶层MPS开始，逐层向下“推倒”，每倒一块，都带着时间偏移和批量规则。理解这个传导链，才能看懂MRP报表里为什么“某螺丝今天就要下单，而它的母件下周才投产”。
3.1 粗需求量（Gj(t)）：独立需求与相关需求的混合体，必须分层剥离
粗需求量Gj(t)是MRP的起点，但它绝非简单相加。公式Gj(t) = Σ(上层计划投入量 × BOM用量) + 独立需求量中，独立需求量必须严格限定为“不通过BOM分解产生”的需求，如：
- 直接销售的备件（客户单独订购100个轴承，不关联任何整机）；
- 维修用消耗品（车间报修领用的润滑油）；
- 样机专用物料（研发部申请的定制电路板）。
常见错误是把“销售预测中的A产品需求”当独立需求填进Gj(t)，导致BOM分解后重复计算——A的预测量既驱动了自身MPS，又被当独立需求加到Gj(t)，结果B部件需求翻倍。
分层剥离独立需求的校验逻辑（伪代码）：
FOR each物料j in BOM所有层级： IF j是最终产品（BOM中无父件）： Gj(t) = MPS中j的计划量 + 备件销售订单量 + 维修领用量 ELSE： Gj(t) = Σ(所有父件i的计划投入量Ri(t') × BOM中i对j的用量) + （仅当j有独立销售时）j的备件订单量 END IF END FOR关键点：只有BOM末端的“最终产品”和明确标记为“备件”的物料才允许填独立需求；中间层物料（如B部件）的独立需求必须为0，否则破坏BOM传导逻辑。
3.2 净需求量（Nj(t)）：负数不是错误，而是系统在告诉你“库存冗余”
净需求量Nj(t) = Gj(t) − Hj(t−1) − Sj(t) 的计算结果为负时，MRP标准做法是置0，表示“无需补充”。但这个“0”背后藏着重要业务信号：
- 若Nj(t)连续多期为0，且Hj(t−1)持续高位，说明该物料存在结构性过剩，应启动呆滞料分析；
- 若Nj(t)在某期突变为0（此前为正），需检查Hj(t−1)是否异常增加（如盘点盈余、退货入库未及时处理）；
- 若Nj(t)为负但绝对值大（如−5000），而Hj(t−1)正常，大概率是Sj(t)（预计入库量）录入错误——把“下周到货5000”错录成“本周到货5000”。
某电子厂曾因此报废百万物料：MRP连续3周显示某芯片Nj(t)=0，计划员未深究，直到产线反馈芯片批次老化失效。追溯发现，该芯片的Sj(t)被误录为“已到货”，实际货物在海关滞留两周。教训是：Nj(t)=0时，必须反查Sj(t)的来源单据状态。
3.3 计划订货量（Pj(t)）与计划投入量（Rj(t′)）：批量规则是成本与响应的平衡器
计划订货量Pj(t)不是Nj(t)的直译，而是经批量规则（Lot Sizing Rule）调整后的结果。常见规则及适用场景：
| 批量规则 | 计算逻辑 | 适用物料 | 风险提示 |
|---|---|---|---|
| 固定批量（Fixed Order Quantity） | Pj(t) = round_up(Nj(t)/Q) × Q，Q为固定值（如Q=1000） | 标准件、大宗原材料（钢材、塑料粒子） | Q过大导致小需求期库存积压，Q过小增加采购频次成本 |
| 经济批量（EOQ） | Pj(t) = √(2×年需求×单次订货成本/单位年持有成本) | 价值高、需求稳定的核心部件 | 年需求波动大时，EOQ失效，需季度重算 |
| 期间批量（Period Order Quantity） | Pj(t) = ΣNj(t) for t to t+T，T为覆盖周期（如T=4周） | 需求呈波峰波谷的季节性物料 | T设置不当会导致跨周期缺料或过剩 |
| 逐批清零（Lot-for-Lot） | Pj(t) = Nj(t) | 高价值、易变质、定制化物料（如航空发动机叶片） | 采购/生产频次高，管理成本上升 |
计划投入量Rj(t′) = Pj(t)的时间平移，其中t′ = t − L（L为提前期）。这里的关键陷阱是：L必须是“可控提前期”，而非合同约定提前期。例如，某螺丝合同写“交货期30天”，但实际采购从下单到入库平均耗时22天（含供应商生产15天+物流7天），则L应取22，而非30。用30会导致计划投入时间过早，资金占用；用15则忽略物流风险，到货延误。
提前期校准方法（实操步骤）：
- 导出近6个月所有该物料的采购单，字段含：下单日期、供应商确认交期、实际到货日期；
- 计算每单实际提前期 = 实际到货日期 − 下单日期；
- 剔除异常值（如物流罢工导致延期60天），取剩余数据的P90分位数（覆盖90%场景）；
- 将P90值设为系统L参数，并每季度刷新。
某机械厂用此法将某铸件L从合同35天修正为28天，MRP采购指令准时率从76%升至94%。
4. 避坑：MRP落地最常见的5个血泪问题与根治方案
MRP上线后最常听到的抱怨是“系统算得不准”“天天改计划”“仓库说有货，系统说缺料”。这些问题90%源于基础数据或流程断点，而非算法缺陷。以下是我在12个制造业项目中踩过的坑，按现象、原因、根治方案结构化呈现，每条都附可立即执行的检查动作。
4.1 现象：MRP频繁生成“紧急采购单”，但仓库实物充足
原因：库存记录未同步“已分配量”（Allocated Quantity）。销售部已将1000件A产品绑定到客户订单，但ERP未将这1000件从可用库存中扣除，MRP计算时仍按账面库存算，发现“缺1000件”而触发紧急采购。
根治方案：
- 系统层：在ERP中启用“销售订单预留”功能，确保订单审核通过即自动扣减可用库存；
- 流程层：要求销售助理每日下班前运行
check_allocated_sync.sql（见下文），输出未同步的订单清单； - 检查脚本：
-- 检查销售订单是否已同步扣减库存 SELECT so.order_no, so.item_code, so.qty AS order_qty, COALESCE(al.allocated_qty, 0) AS allocated_in_inventory, so.qty - COALESCE(al.allocated_qty, 0) AS delta FROM sales_orders so LEFT JOIN ( SELECT item_code, SUM(qty) AS allocated_qty FROM inventory_allocation WHERE status = 'RESERVED' GROUP BY item_code ) al ON so.item_code = al.item_code WHERE so.status = 'CONFIRMED' AND so.qty != COALESCE(al.allocated_qty, 0);执行动作：每日运行此脚本，若delta > 0，立即在ERP中手动执行“订单预留”操作，并追查为何自动同步失效（通常是销售订单状态流转未触发库存接口）。
4.2 现象：BOM变更后，MRP仍按旧结构计算，导致子件需求量错误
原因：BOM版本未与MRP计算周期绑定。新BOM于3月10日生效，但MRP仍在用2月28日冻结的旧BOM快照运算，且未设置BOM生效日期校验。
根治方案：
- 数据层：BOM表必须含
valid_from和valid_to字段，MRP计算时强制读取valid_from ≤ 当前日期 ≤ valid_to的版本； - 系统层：在MRP运算前增加校验步骤，SQL如下：
-- 检查当前日期是否有有效BOM SELECT item_code, COUNT(*) AS active_bom_count FROM bom_master WHERE '2024-03-15' BETWEEN valid_from AND valid_to -- 当前MRP运行日期 GROUP BY item_code HAVING COUNT(*) != 1; -- 每个物料必须有且仅有1个生效BOM执行动作：若查询返回结果，说明该物料BOM存在断层（无生效版）或重叠（多版本生效），必须由BOM工程师立即修复，否则禁止运行MRP。
4.3 现象：同一物料在不同MRP运行时段，计划订货量差异巨大（如上午算需500件，下午算需2000件）
原因：预计入库量（Sj(t)）未锁定。上午MRP读取时，采购部刚新增一张到货日期为“3月20日”的PO，下午该PO被取消，但MRP未重新加载数据，导致两次计算基准不一致。
根治方案：
- 流程层：MRP运算必须基于“冻结数据集”，即运行前导出MPS、BOM、库存的快照CSV，运算全程读取快照，而非实时数据库；
- 技术层：在MRP调度脚本中加入快照生成步骤：
# Linux定时任务示例：每日凌晨2点生成快照 0 2 * * * /usr/bin/mysqldump -u user -p'pwd' erp_db mps_table > /data/mrp_snapshots/mps_$(date +\%Y\%m\%d).sql 0 2 * * * /usr/bin/mysqldump -u user -p'pwd' erp_db bom_table > /data/mrp_snapshots/bom_$(date +\%Y\%m\%d).sql 0 2 * * * /usr/bin/mysqldump -u user -p'pwd' erp_db inventory_table > /data/mrp_snapshots/inventory_$(date +\%Y\%m\%d).sql执行动作：MRP运算日志中必须记录所用快照文件名（如bom_20240315.sql），审计时可回溯数据源头。
4.4 现象：MRP输出采购单，但供应商反馈“你们要的规格和我们合同不一致”
原因：BOM中物料属性（如材质、精度等级）未与采购协议绑定。BOM写“轴承：NSK 6204ZZ”，但采购协议约定的是“SKF 6204-2RS”，MRP只认编码，不校验技术参数。
根治方案：
- 数据层：在BOM子件表中增加
specification_id字段，关联技术协议库； - 校验层：MRP运行前执行协议一致性检查：
-- 检查BOM物料是否在有效采购协议中 SELECT b.item_code, b.specification_id, p.agreement_no, p.effective_date, p.expiry_date FROM bom_detail b LEFT JOIN procurement_agreements p ON b.item_code = p.item_code AND b.specification_id = p.spec_id AND CURDATE() BETWEEN p.effective_date AND p.expiry_date WHERE p.item_code IS NULL;执行动作：若返回结果，说明该BOM子件无有效技术协议，MRP暂停运行，通知采购部签署协议。
4.5 现象：MRP计算显示某物料“不缺”，但产线领料时被告知“仓库无此批次”
原因：库存记录未管理“批次/序列号”维度。BOM要求使用批次号以“20240301”开头的芯片，但库存表只记总数量，未区分批次，MRP按总量判断“有货”，实际可用批次已用完。
根治方案：
- 系统层：启用批次管理模块，库存表增加
batch_no、expiry_date字段； - MRP层：净需求计算时，按批次可用量聚合，而非总量：
-- 按批次计算可用量（示例：芯片需特定批次） SELECT batch_no, SUM(qty) AS batch_qty, MIN(expiry_date) AS expiry FROM inventory_batch WHERE item_code = 'CHIP-001' AND batch_no LIKE '202403%' AND status = 'AVAILABLE' GROUP BY batch_no HAVING SUM(qty) >= 500; -- 需求量500执行动作：对高价值、有保质期、需追溯的物料（如医药、食品、航空件），MRP必须开启批次级运算，否则不许上线。
5. 进阶验证：用“时间窗压力测试”揪出MRP隐藏逻辑漏洞
MRP系统上线后，多数人只关注“算得对不对”，却忽略“在极限场景下是否扛得住”。我给所有客户做的最后一道验证，是时间窗压力测试（Time-Window Stress Test）：人为制造时间冲突、数据断点、极端需求，观察MRP是否按预期逻辑响应。这不是为了找BUG，而是验证系统是否真正理解“时间”这个核心变量。以下是我用过的三套实战测试用例，每套都附可执行的SQL和预期结果。
5.1 测试一：主生产计划“时间跳跃”验证——检验MRP能否识别计划断层
场景构造：在MPS中删除第3周计划，保留第1、2、4、5周计划，形成“1,2, ,4,5”的跳跃。MRP应识别第3周无计划，不生成任何需求，且第4周需求不因第3周缺失而提前。
验证SQL（检查MRP输出表mrp_output）：
-- 检查第3周是否生成任何计划订货量 SELECT item_code, week_start, planned_order_qty FROM mrp_output WHERE week_start = '2024-03-18' -- 第3周周一 AND planned_order_qty > 0; -- 检查第4周需求是否与第2周需求量一致（验证无提前） SELECT m1.item_code, m1.planned_order_qty AS week2_qty, m2.planned_order_qty AS week4_qty, CASE WHEN m1.planned_order_qty = m2.planned_order_qty THEN 'PASS' ELSE 'FAIL' END AS result FROM mrp_output m1 JOIN mrp_output m2 ON m1.item_code = m2.item_code WHERE m1.week_start = '2024-03-11' -- 第2周 AND m2.week_start = '2024-03-25'; -- 第4周预期结果：第一查返回0行；第二查result全为'PASS'。若失败，说明MRP在时间断层时自动“插值”或“平移”，违反MPS刚性约束。
5.2 测试二：BOM“多层替代”验证——检验MRP能否按优先级自动切换
场景构造：BOM中A产品需B部件，B有主用料B1（优先级1）和备用料B2（优先级2），当前B1库存为0，B2库存为1000。MRP应生成B2的采购计划，而非报缺。
验证SQL：
-- 检查MRP是否为B2生成计划（而非B1） SELECT item_code, planned_order_qty, source_type -- 'PRIMARY' or 'ALTERNATE' FROM mrp_output WHERE item_code IN ('B1', 'B2') AND week_start = '2024-03-18' AND planned_order_qty > 0; -- 检查B1的可用量是否为0（触发替代） SELECT item_code, available_qty FROM inventory_summary WHERE item_code = 'B1';预期结果：第一查返回B2的记录且source_type='ALTERNATE'；第二查available_qty=0。若MRP仍为B1下单，说明替代逻辑未启用或优先级配置错误。
5.3 测试三：库存“在途量时效”验证——检验MRP能否动态响应物流状态
场景构造：某物料采购单约定3月20日到货，MRP在3月18日运行时，物流系统回传“预计3月22日到货”。MRP应将该笔到货从“第3周预计入库”移至“第4周”，并重新计算第3周净需求。
验证SQL：
-- 检查3月18日MRP运行后，该物料第3周（3月18-24日）的预计入库量 SELECT item_code, week_start, scheduled_receipts FROM mrp_output WHERE item_code = 'MOTOR-001' AND week_start = '2024-03-18'; -- 检查物流系统最新状态 SELECT item_code, expected_arrival, current_status FROM tms_tracking WHERE item_code = 'MOTOR-001' AND expected_arrival BETWEEN '2024-03-18' AND '2024-03-24';预期结果：第一查scheduled_receipts=0（因物流更新，原3月20日到货已移出第3周）；第二查expected_arrival='2024-03-22'且current_status='IN_TRANSIT'。若第一查仍有数值，说明MRP未实时拉取TMS数据或缓存未刷新。
从那以后我每次上线新MRP，都强制走一遍这三套测试——不是因为信不过开发团队，而是因为制造业的“时间”太敏感，差一天可能就是停产。这些测试用例不追求覆盖所有分支，但直击MRP最脆弱的三个神经：时间连续性、替代决策力、外部系统协同性。它们像一把手术刀，能快速切开系统表象，看到底层逻辑是否真正健壮。希望帮到你。
本文还有配套的精品资源，点击获取
