程序。每种改进的威力与潜在的困难将在第二册中更充分地讨论;这里只要指出只
有当真正有需要并且使用者充分理解它们时才应该去使用它们。不必要的复杂化增
加的是成本而非价值。
随着一层一层的计算顺着物料清单自上而下地进行与一次一次地为已计划订单
补偿其提前期,数据发生在其中的视界会变得越来越短。有多种视界──填充计算
(horizon-filler calculations)可用来扩展数据通过全部计划视界的各个层次。
其中典型的是每期间的平均需求与重复前4(或多或少)周。由于该项计算所提出
的任意数据会影响低层的已发放订单的时机与数量,选择数据时应加小心。
为提供例外报告,可使用多种行动通知(action notices)去提醒用户注意具
体情况而不要求他们去研究每一组件显示。选用它们的应注意事项与使用这类通知
作为系统健康状况的诊断工具包括在第二册中。虽然在现代MRP软件包中还有别
的许多行动通知,但常用的有:
Release Order 发放订单 Order Past Due 订单过期
Data missing in this field 此栏遗漏数据
Expedite Order 赶制订单 No Requirements 无需求
Delay Order 延迟订单 Cancel order 取消订单
Future order covers this requirement 未来订单包括此需求
溯源(Pegging)是识别生成着一种组件需求的父物品的技法。来自几种父物
品的对一种组件的需求在一单独期间表现为其总计数。MRP程序中的屏幕当打印
时并不表示父件──组件关系但分别说明每物品的数据。用户往往需知道哪一种父
件引起了多大需求。特别是当没有足够的组件存货可用之时。当然一份BOM反查
表将显示所有的父件但在关键期间中可能只涉及一种或两种。溯源在组件屏幕上提
供信息,如图6-14所示,它直接引导用户到正确的父件。
这种溯源叫完全单层溯源(full single-level pegging),它为一种组件识
别时间期间、父物品与所需数量。当多种物品通用于许多父件而且这些父件被频繁
地订货时,这要求大的数据存储容量与长的打印时间。注意一种父件将多次出现于
每一组件的屏幕上。 由于父件的屏幕也可供用户使用, 采用部份单层溯源
(partial single-level pegging)可以节省文档空间与打印时间,部份单层溯源
只给出引起需求的父件的零件号。还可以进一步限制屏幕只显示一个短视界中涉及
的父件。第二册包括其它用途与溯源时的注意事项。
┏━━━━━━━━┓ ┏━━━━━━━━┓
┃ 周 ┃ ┃ 周 ┃
MPS ┣━━┳━━┳━━┫ MPS ┣━━┳━━┳━━┫
#7W ┃14┃15┃16┃ #7D ┃14┃15┃16┃
┣━━╋━━╋━━┫ ┣━━╋━━╋━━┫
代码#276┃50┃ ┃ ┃ 代码#281┃ ┃75┃ ┃
━━━━━━┻━━┻━━┻━━┛ ━━━━━━┻━━┻━━┻━━┛
┏━━━━━━━━━┓ ┏━━━━━━━━┓
┃ 周 ┃ ┃ 周 ┃
MPS ┣━━━┳━━┳━━┫ MPS ┣━━┳━━┳━━┫
#9W ┃ 14 ┃15┃16┃ #9D ┃14┃15┃16┃
┣━━━╋━━╋━━┫ ┣━━╋━━╋━━┫
代码#243┃100┃ ┃ ┃ 代码#262┃ ┃60┃ ┃
━━━━━━┻━━━┻━━┻━━┛ ━━━━━━┻━━┻━━┻━━┛
┏━━━━━━━━━┓ ┏━━━━━━━━━┓
┃ 周 ┃ ┃ 周 ┃
MPS ┣━━━┳━━┳━━┫ MPS ┣━━┳━━━┳━━┫
#11D ┃ 14 ┃15┃16┃ #11P ┃14┃ 15 ┃16┃
┣━━━╋━━╋━━┫ ┣━━╋━━━╋━━┫
代码#384┃250┃ ┃ ┃ 代码#385┃ ┃165┃ ┃
━━━━━━┻━━━┻━━┻━━┛ ━━━━━━┻━━┻━━━┻━━┛
自制插头┏━━┳━━┳━━┳━━┓
装配件 ┃ 过 ┃ ┃ ┃ ┃
#418┃ 期 ┃14┃15┃16┃
┏━━━━╋━━╋━━╋━━╋━━┫
┃ 需求 ┃ ┃ 400┃ 300┃ 500┃
┣━━━━╋━━╋━━╋━━╋━━┫
┃ 将收 ┃ ┃ ┃ ┃ ┃
┣━━━━╋━━╋━━╋━━╋━━┫
┃ 将有 ┃700 ┃ 300┃ -- ┃ 700┃
┣━━━━╋━━╋━━╋━━╋━━┫
┃ 要补 ┃ ┃ ┃ ┃ ┃
┣━━━━╋━━╋━━╋━━╋━━┫
┃ 开始 ┃ ┃ ┃ ┃ ┃
┗━━━━┻━━┻━━┻━━┻━━┛
被溯源的:
14周 15周 16周
#276-50 #281-75 #314-500
#243-100 #262-60
#384-250 #385-165
图6-14 溯源需求 ──插头装配件#418
在某些情况下,希望使MRP程序正常地处理已计划订单的方法归于无效。例
如,完全成套的组件数可能少于要完成下一批某一父件的正常订货量所需的数量,
或某一物品的下一批要求在短于计划提前期的时间内去完成。由于若干原因可能不
希望在现行时间去发放不变订单。不变已计划订单(firm planned order)强迫计
算机对任何这样称呼的订单要接收特殊的提前期或订货量。图6-15比较MRP
程序处理已计划订单、已发放订单与不变计划订单的方法。由于这种特殊订单搞混
了该系统的正常逻辑,它们应该有节制地被使用而且只应由合格的用户来使用。第
二册中包括有关于各种特殊订单以及其它改进的进一步评论。
┏━━━━━━━┳━━━━━━┳━━━━━┳━━━━━━━━━━━━┓
┃ 是否展开到 ┃是否自动重新┃是否生成例┃用户对数量、开始与需用日┃
┃ 较低层? ┃安排日程? ┃外信息? ┃期有无控制? ┃
┏━━━━━━╋━━━━━━━╋━━━━━━╋━━━━━╋━━━━━━━━━━━━┫
┃ 已计划订单┃ 是 ┃ 是 ┃ 否 ┃必须使用MRP程序中的规则 ┃
┣━━━━━━╋━━━━━━━╋━━━━━━╋━━━━━╋━━━━━━━━━━━━┫
┃ 已发放订单┃仅当首次发放时┃ 否 ┃ 是 ┃ 是 ┃
┣━━━━━━╋━━━━━━━╋━━━━━━╋━━━━━╋━━━━━━━━━━━━┫
┃不变计划订单┃ 是 ┃ 否 ┃ 否 ┃ 是 ┃
┗━━━━━━┻━━━━━━━┻━━━━━━┻━━━━━┻━━━━━━━━━━━━┛
图6-15 MRP的订单处理