![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
Previous | Next | Contents | Index | Navigation | Glossary | Library |
Project MRP planning logic differs from the regular MRP planning logic primarly in the way it determines what supply is available to satisfy demand. It also differs in the way it assigns any suggested planned orders that result from the planning process.
Instead of simply considering existing inventories and scheduled receipts when netting supply against demand, the project MRP planning logic goes through a process of pre-allocation: Before netting supply against demand, the planning process analyses the project/Seiban numbers (along with the item attributes, project parameters, and plan level options you have set), to determine what supply is available for meeting project/Seiban demand. Supply and demand that is not specific to any project/Seiban is defined as common supply. The project MRP planning logic treats common supply or demand as a "null" project/Seiban.
During the pre-allocation phase, the planning process first nets a project's demand with its supply. It then checks the reservation level to determine if excess can be shared. This only works for items that have their attributes set to soft or hard pegging.
The following table compares the logic in regular MRP and project MRP:
Regular MRP | Project MRP |
---|---|
explode bill of materials | explode bill of materials |
snapshot of inventory and supply/demand | snapshot of inventory and supply/demand |
pre-allocate supply to projects/Seibans | |
net supply against demand | net supply against demand; assign suggested planned orders to projects/Seibans |
Table 1 - 61. Planning logic in regular MRP compared to project MRP. |
During the pre-allocation phase of netting, the planning engine divides the supply for the item by project. In Period 1, the demand from project 2 (P2) is 100. Since there is an onhand quantity of 25 for P2 and no scheduled receipts, there is still demand for P2 of 75. The planning engine cannot apply excess from any other source to meet this demand, the planning engine looks for the available supply for P2 and finds it in Period 2. This supply is rescheduled in to Period 1. The remaining demand from Period 1 (75) plus the demand in Period 2 (500) equals 575. The scheduled receipts in this period leaves an excess of 25, which is then carried forward for 2 periods (see the Projected Available).
Once again, the planning engine can only apply the excess P2 supply to P2 demand. The last P2 demand is in Period 3 (for 300), consuming the excess of 25 from Period 2 and leaving a net requirement of 275, which the planning engine converts into planned orders.
Because the item is hard pegged, and the hard pegging level (from the plan options) is set to project, the P2 project reference is added to the suggested planned order.
During the pre-allocation phase of netting, the planning engine divides the supply for the item by project. In Period 1, the demand from project 2 (P2) is 100. Since there is an onhand quantity of 25 for P2 and no schedules receipts, there is still demand for P2 of 75. To distribute this excess, the planning engine looks for more P2 demand, which it finds in Period 2. This supply is rescheduled in to Period 1. It then reduces that demand to 425. P1 also has an excess of 75 in Period 1 (scheduled receipts plus the onhand quantity minus P1 demand), which is then used to reduce P1 demand in Period 2 to 75. The excess supply for P3 in Period 1 is 78, which eliminates the P3 demand in Period 2, but with an excess of 28. The final demand in Period 1 comes from the common (nonproject/Sieban specific) demand. To meet this demand, the planning engine reschedules the receipts in Period 3, leaving an excess of 100. This excess has no further "common" demand to meet. In Period 2 there is a scheduled receipt of 800 against P2, which is rescheduled to Period 3, leaving an excess of 500. Period 3 also has a demand from P4 of 120, which is reduced to 70 by P4 scheduled receipts. In Period 2, we are left with scheduled receipts of 100 (common) and 28 (P3); in Period 4, we have scheduled receipts of 500 (P2).
Unlike the hard pegging example, the planning process can use other excess supply in this period to meet this remaining demand.
Project-Task | Project | Hard Pegging | reserve supply at project-task level; create planned orders at project level |
Project-Task | Project-Task | Hard Pegging | reserve supply at project-task level; create planned orders at project-task level |
Project-Task | None | Hard Pegging | reserve supply at project-task level; create planned orders without project references |
Planning Group | Any Value | Soft Pegging | reserve supply at planning group level; create planned orders without project references |
Project | Any Value | Soft Pegging | reserve supply at project level; create planned orders without project references |
Project-Task | Any Value | Soft Pegging | reserve supply at project-task level; create planned orders without project references |
None | None | Hard Pegging | no reservations, full pegging |
Table 1 - 62. Project MRP Netting Behavior (Page 1 of 1) |
Item attribute | Allocation of excess supply |
---|---|
Hard Pegging or End Assembly/Hard Pegging | Planning logic ignores excess in common supplies and project/Seiban specific supplies during the netting routine. |
Soft Pegging or End Assembly/Soft Pegging | Planning logic considers excess in common supplies and project/Seiban specific supplies during the netting routine. |
Table 1 - 63. Effects of the pegging item attribute on the netting of excess supply. |
Previous | Next | Contents | Index | Navigation | Glossary | Library |