This chapter covers the following topics:
Project MRP is one of a series of features in Oracle Applications designed to support companies that manufacture products for projects or contracts.
Project MRP allows you to plan in a project environment by separating all sources of supply and demand by project. This allows the planning process to identify components as common or project specific, track existing inventories by project, and provide visibility to all supply and demand associated with a project.
Include project numbers and task references in forecast, MPS, and MDS entries
Load, copy, or merge forecast, MPS, and MDS entries with project numbers and task references
Recognize and allocate supply according to project numbers and task references
Combine project and related supply and demand with non-project related supply and demand in the same plan or schedule
Perform netting by planning groups, project, and tasks
Generate planned orders with project number and task references
Implement planning suggestions by planning group, project, or task
Link sales order lines, production orders, and purchase orders to projects and tasks, allocate onhand inventory to projects, and issue inventory to projects
Perform on-line net change simulation in a project environment
Selection of Project MRP plan options and choice of pegging attributes of an item together determine the output of a Project MRP plan. This section describes the Project MRP plan options and the item attributes that impact Project MRP planning logic.
See Also:
Establishing a Project MRP Environment, Oracle Master Scheduling/MRP & Oracle Supply Chain Planning User's Guide
Project MRP provides the following plan options to you in the Oracle Project Manufacturing environment. There are multiple options available for Reservation Level and Hard Pegging Level in the Pegging region of the Plan Options window. The Pegging check box must be checked in order to access these plan options.
The Reservation Level determines the method of pre-allocation of project supply to project demand. There are four options for reservation level.
Planning Group
Choosing this option for a Project MRP plan reserves project specific supply at the planning group level. Excess supply in one project can be reserved against demand for another project belonging to the same planning group. Excess common supply is also be allocated to project demand.
Project
A project level reservation, allows project specific supply to be used for demand specific to that project only. This option allows cross allocation across tasks within the same project.
Task
A task level reservation reserves supply for a project-task against demand for the same project-task only. No cross allocation of material belonging to the same project but different tasks is allowed.
None
Reservations for this option takes place like any non-project MRP planning process.
The Hard Pegging Level option determines if project and/or task references are added to planned orders of hard pegged items only. (The Pegging item attribute must be either Hard Pegging or End Assembly/Hard Pegging) No project references are associated with planned orders of soft pegged items. Project MRP suggested planned orders are assigned one of the following levels:
Project
The planned orders generated for hard pegged items carry project references only.
Project-Task
This option attaches project and task references to the planned orders of hard pegged items.
None
This option does not add any project/task reference to the Project MRP suggested planned orders.
Note: Hard Pegging Level options work independent of the Reservation Level options.
See Also:
Project MRP Planning Logic, Oracle Master Scheduling/MRP & Oracle Supply Chain Planning User's Guide
Item pegging attributes defined in Oracle Inventory determine the allocation of excess available supply for a project-task to the demand and the generation of Project MRP planned orders. Table 1 compares the available item pegging attributes.
Project MRP planning logic differs from the regular MRP planning logic primarily 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/task references (along with the item attributes, project parameters, and plan level options you have set), to determine what supply is available for meeting project demand. Supply and demand that is not specific to any project is defined as common supply. The project MRP planning logic treats common supply or demand as a Null project.
During the pre-allocation phase, the planning process first nets a project 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 Pegging, End Assembly/Soft Pegging, Hard Pegging or End Assembly/Hard Pegging.
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 |
Net supply against demand | Net supply against demand; assign suggested planned orders to projects |
By combining the item pegging attribute with the plan options reservation and hard pegging levels, you can exercise a high degree of control over how the planning process pre-allocates supply for an item. Table 3 summarizes the possible combinations and types of behavior you can enforce:
Reservation Level | Hard Pegging Level | Item Pegging Attribute | Netting Behavior |
---|---|---|---|
Planning Group | Project | Hard Pegging | Reserve supply at planning group level. Excess common supply is used for project demand; Create planned orders at project level |
Planning Group | Project-Task | Hard Pegging | Reserve supply at planning group level. Excess common supply is used for project demand; Create planned orders at project-task level |
Planning Group | None | Hard Pegging | Reserve supply at planning group level. Excess common supply is used for project demand; Create planned orders without project references |
Project | Project | Hard Pegging | Reserve supply at project level; Create planned orders at project level |
Project | Project-Task | Hard Pegging | Reserve supply at project level; Create Planned orders at project-task level |
Reservation Level | Hard Pegging Level | Item Pegging Attribute | Netting Behavior |
Project | None | Hard Pegging | Reserve supply at project level; Create planned orders without project references |
Reservation Level | Hard Pegging Level | Item Pegging Attribute | Netting Behavior |
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. Excess supply belonging to other projects and common is used for project demand; Create planned orders without project references |
Project | Any Value | Soft Pegging | Reserve supply at project level. Excess supply belonging to other projects and common is used for project demand; Create planned orders without project references |
Project Task | Any Value | Soft Pegging | Reserve supply at project-task level. Excess supply belonging to other projects and common is used for project demand; Create planned orders without project references |
None | None | Hard Pegging | No reservations, full pegging |
A7004 MRP Planned | Period 1 | Period 2 | Period 3 |
---|---|---|---|
Demand | 100 (P2) 200 (P1) 65 (P3) 400 (common) |
500 (P2) 150 (P1) 50 (P3) |
300 (P2) 120 (P4) |
Scheduled Receipt | 265 (P1) 5 (P4) |
800 (P2) | 50 (P4) 500 (common) |
Planned Orders | 62 | 145 | |
Projected Available | 725 (P2) 75 (P1) 63 (common) |
225 (P2) |
Item Pegging: soft pegging, Reservation Level: Project, Hard Pegging Level: Project
On Hand=5 (common), Onhand= 10 (P1), On Hand = 25 (P2), On Hand = 18, (P3)
A7004 MRP Planned | Period 1 | Period 2 | Period 3 |
---|---|---|---|
Demand | 100 (P2) 200 (P1) 65 (P3) 400 (common) |
500 (P2) 150 (P1) 50 (P3) |
300 (P2) 120 (P4) |
Scheduled Receipts | 265 (P1) 5 (P4) |
800 (P2) | 50 (P4) 500 (common) |
Planned Orders | 62 | 145 | |
Projected Available | 725 (P2) 75 (P1) 63 (common) |
225 (P2) |
Item Pegging: soft pegging, Reservation Level: Project, Hard Pegging Level: Project
On Hand=5 (common), Onhand= 10 (P1), On Hand = 25 (P2), On Hand = 18, (P3)
Table 4 shows an item that is an MRP-planned component used in four projects and as common.
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 P2 is 100. Since there is an on–hand quantity of 25 for P2 and no schedules receipts, there is still demand for P2 of 75. To meet this demand, the planning engine looks for more P2 supply, which it finds in Period 2. The supply is pegged to the demand in Period 1. Project P1 has an excess of 75 in Period 1 (scheduled receipts plus the on–hand quantity minus P1 demand), which is then used to partially satisfy the P1 demand in Period 2. Period 1 also has common demand. To meet this demand, the planning engine allocates the receipts in Period 3, leaving an excess of 105. This excess has no further common demand to meet. Period 3 has a demand from P4 of 120, which is reduced to 70 by P4 scheduled receipts. After satisfying all the project specific demand in the three periods we are left with an excess of 105 (common) in Period 1, and un-met demands of 42 P3 in Period 1, 75 P1 in Period 2, 75 P2 and 70 P4 in Period 3.
The planning process can use other excess common supply in Period 1to meet the remaining demand for P3 in the same period. So 42 common are used to meet the P3 demand in Period 1. The remaining 63 common partially satisfy the P1 and P3 demand in Period 2, leaving an un-met demand of 62 in Period 2. The demand for 145 units in Period 3 remains unsatisfied.
This results in the planned orders for 62 in Period 2 and 145 in Period 3 without project and task references. Since the item is soft pegged, the planned orders does not carry any project reference irrespective of the Hard Pegging Level for the plan.
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 P2 is 100. Since there is an on–hand quantity of 15 for P2 and no scheduled receipts, there is still demand for P2 of 85. 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 to the demand in Period 1. The remaining demand from Period 1 (85) plus the demand in Period 2 (500) equals 585. The scheduled receipts leaves an excess of 15, which is carried forward (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 15 from Period 2 and leaving a net requirement of 285, 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.
Similar logic applies to the supply and demand for projects P1, P3, P4, and common.
A7004 MRP Planned | Period 1 | Period 2 | Period 3 |
---|---|---|---|
Demand | 100 (P2) 200 (P1) 65 (P3) 400 (common) |
500 (P2) 150 (P1) 50 (P3) |
300 (P2) 120 (P4) |
Scheduled Receipts | 265 (P1) 20 (P4) 600 (common) |
600 (P2) | |
Planned Orders | 75 (P1) | 285 (P2) 100 (P4) |
|
Projected Available | 515 (P2) 75 (P1) 53 (P3) 205 (common) 20 (P4) |
15 (P2) 0 (P1) 3 (P3) 205 (common) |
0 (P2) 0 (P1) 3 (P3) 205 (common) 0 (P4) |
item pegging:hard pegging, Reservation level: Project, Hard pegging level: Project On Hand = 5 (common), On Hand = 10 (P1), On Hand = 15 (P2), On Hand = 18 (P3) |
The new netting logic for Project MRP now also takes into account excess common supply for project demand for hard pegged items. This netting logic is available only if the reservation level option for the plan is set to Planning Group.
In a given period, the planning engine looks for supply that belongs to the same project. If there is a shortage, excess supply within the same planning group is allocated. If unsatisfied demand still exists for the project, excess common supply is used to satisfy project requirements. Excess common supply available in a period takes precedence over future scheduled receipts for the same project or planning group.
The difference in netting logic is explained below with the help of the same numerical example as above. In this case, projects P1 and P2 belong to the same planning group.
Netting of common supply and demand in leaves us with an excess of 205 in common. Similarly, for project P1 there is an excess supply of 75 in period 1.
In Period 1, the demand from project P2 is 100. Since there is an on–hand quantity of 15 for P2 and no scheduled receipts, there is still demand for P2 of 85. The planning engine can now apply excess from any other project belonging to the same planning group as well as excess common supply to meet this demand. In Period 1, the excess 75 in P1is allocated to this demand. There is still an unsatisfied demand of 10 for project P2. As per the new netting logic, the excess in common is available for this project demand, thus satisfying all the requirements for project P2 in Period 1.
In Period 1, project P3 has an un-met demand of 47 (demand 65 - On hand 18). There is no other supply for P3. But there is excess common supply, which is used to meet this requirement Notice that project P3 does not belong to any planning group. Just by virtue of the reservation level for the plan, excess common supply has been allocated to project demand for P3.
This excess in common is also applied to unsatisfied demand for projects P1 and P3 in Period 2, and project P2 in Period 3. The unsatisfied demand for 252 (P2) and 100 (P4) in Period 3 results in planned orders.
Because the item is hard pegged, and the hard pegging level (from the plan options) is set to project, project reference is added to the suggested planned orders.
A7004 MRP Planned | Period 1 | Period 2 | Period 3 |
---|---|---|---|
Demand | 100 (P2) 200 (P1) 65 (P3) 400 (common) |
500 (P2) 150 (P1) 50 (P3) |
300 (P2) 120 (P4) |
Scheduled Receipts | 265 (P1) 20 (P4) 600 (common) |
600 (P2) | |
Planned Orders | 252 (P2) 100 (P4) |
||
Projected Available | 0 (P2) 0 (P1) 0 (P3) 148 (common) 20 (P4) |
0 (P2) 0 (P1) 0 (P3) 48 (common) 20 (P4) |
0 (P2) 0 (P1) 0 (P3) 0 (common) 0 (P4) |
Item pegging: hard pegging, Reservation level: Planning Group, Hard pegging level: Project
On Hand = 5 (common), On Hand = 10 (P1), On Hand = 15 (P2), On Hand = 18 (P3)
Generation of project and task references on planned orders is a function of the Hard Pegging Level plan option and the item attributes. Even though Project MRP does not display the project and task references on planned orders for soft pegged items, these references are maintained within the system. These are used if the children of this soft pegged item happen to be hard pegged items.
In Figure 10-1, A2003 is a soft pegged item which has A3002 as its child item. A3002 is a hard pegged item. The Project MRP plan for A1001 has the Hard Pegging Level set to Project.
Being a soft pegged item, planned orders for A2003 does not carry any project reference. However, A3002 carries a project reference on its planned orders even though the planned orders for its parent do not contain project references.
Project MRP uses the same Order Modifiers logic as standard MRP. The assignment of project references for hard pegged items (and Hard Pegging Level Project or Task) to planned orders occurs as per the logic shown in the following figure.
Any excess order quantity is assigned a project reference that belongs to a nearest future unsatisfied demand. In no demand exists, then the planned order carries a null project and task reference (for example, common supply).
Assigning Project References to Planned Orders after Applying Order Modifiers
This section discusses the Planner Workbench in Project MRP.
The MPS Workbench and MRP Planner Workbench in Project MRP have significant enhancements to enable the planner in a Project Manufacturing environment to conveniently view planning information by project and implement manufacturing plans in the workbench by project.
The planner can enter Planning Group, Project Number and/or Task Number as the search criteria in the Find Supply, Find Demand, or Find Supply/Demand window of the Planner Workbench. This enables the planner to find Supply, Demand, or Supply/ Demand information by planning group, project, or project-task.
The planner could also use customizable folders in the Supply, Demand, or Supply/Demand screens to query planning information for a particular project or project-task.
The Horizontal Plan and Enterprise View windows enable the planner to view supply and demand information by Planning Group, Project, and Project-Task. The planner can also choose to see the planning status of all the material or only common material in these windows.
See Also:
Overview of the Supply Chain Planning planner Workbench, Oracle Master Scheduling/MRP & Oracle Supply Chain Planning User's Guide
Along with the other MRP Exception Messages, Project MRP provides the following project related exception messages that can help monitor project material plans. Like other exception messages, these exception messages are also workflow enabled for better supply chain coordination. The Project Manager or Task Manager (if defined) is also notified of these plan exceptions.
Items with Excess inventory in a project This exception message enlists all the items that have a excess inventory in a project or project-task.
Items with Shortage in a project This exception message highlights the items whose demand exceeds supply for that project or project-task.
Items allocated across projects This exception message indicates items where supply for one project/task is used to satisfy demand for another project/task.
The Planner Workbench generates the following action messages for project supply. It follows the current Planning Time Fence and Acceptable Days Early logic to generate these messages.
Reschedule In
Reschedule Out
Cancel
See Also:
Workflow Enabled Exception Messages, Oracle Master Scheduling/MRP & Oracle Supply Chain Planning User's Guide
Using the features of the Project MRP Planner workbench, the planner can view and implement the planned orders by planning group, project or project-task. The planner can choose to override the suggested project and task references on planned orders. The Implement Property Sheet window allows the planner to view and change the Project or Project-Task of such planned orders. You can also simulate changes to dates, quantities, or project references in the Planner Workbench and generate net change simulation plans.
This section points out some implementation notes in Project MRP.
Project MRP does not support forecast consumption by project and task. An alternative would be to use demand classes to represent projects. Forecast consumption by demand classes is supported.
Although Project MRP considers excess supply of material for one project as available to another project within the same planning group (if the reservation level is Planning Group), the material cannot be used directly across projects if the projects belong to different cost groups. A subinventory transfer is required if those items must be issued to a WIP job belonging to another project.
However, material belonging to one project can be issued to a WIP job of a different project if:
Both the projects belong to the same planning group, and
Both the projects share the same cost group, and
PJM Org Parameter: Allow Cross Projects Issues is set to Yes.
Sales order shipment from inventory belonging to a different project but in the same planning group is not supported. Project inventory should be moved to the correct project locator before sales order shipments have to be done for that project.