The project MRP processes the quantity on hand, demand, and availability of parts, starting at the lowest level of the parts. The calculation begins with the final products, and continues down the structures (level by level). The project MRP planning consists of a number of phases. For a complete explanation of each phase, follow the appropriate link from the list below:
At the beginning of the project MRP run, unreleased project MRP proposals generated during an earlier run are removed. Examples of unreleased proposals include unreleased purchase and shop requisitions. If you change the planning mechanism used for a part between project MRP runs, project MRP will remove the unreleased order proposals created by other planning systems. For example, if you change from planning method B, part planned by order proposal, to planning method A, part planned by project MRP, project MRP will remove the unreleased proposals created by the last order proposal run.
Project MRP calculates the lowest level at which a part exists in a structure, in which it is used. A parent part, a part that is not a component of another structure, exists at level 0 (zero). A parent's components exist at the next level, level 1. A sub component of a component exists at level 2. Usually, level 0 parts are sales parts.
These coding of levels are necessary for the correct performance of project MRP, the accurate derivation of cost estimates, and the proper calculation of product families and product codes. The calculation of the lowest level, updates the value in the Low Level field on the Manufacturing tab of the Inventory Part window.
Project MRP collects all necessary information for the parts to be planned, and stores it in a temporary location .This snapshot ensures project MRP's planning data remains consistent throughout the project MRP run, and is not affected by ongoing transactions. Snapshot information includes planning attributes for the part and inventory balances as well as all demand and supply information.
For each part, available supply is netted against requirements, each day, beginning with the earliest demands. Existing stocks of inventory are allocated to demands first, then anticipated receipts are allocated next.
The system calculates the current on-hand quantity by adding the balances at all project inventory locations. One exception is the on-hand balance of expense parts at shop inventory locations. This amount is too uncertain to use in the calculation. The on-hand balances maintained in inventory locations with waiver numbers are also not used in the calculation, since these items may not be profitable.
In the process of allocating existing anticipated receipts to demands, project MRP always suggests moving the dates of existing orders before recommending any new orders to cover the requirements. Action messages are generated to indicate these planned rescheduling events, moving the order date, if necessary to meet an earlier demand, a future demand. In the event the existing receipts exceed the demands for the part, project MRP suggests additional actions to cancel those unnecessary orders and/or order quantities.
After all the existing inventory and anticipated receipts are applied to meet the requirements, the project MRP plans new order quantities to cover the future demands. Project MRP planned receipts can take several forms: Make receipts for manufactured parts, and buy receipts for purchased parts. Though not typical, with manufactured/acquired split percentages defined for an inventory part, project MRP can generate several of these receipt types in response to a single requirement. These planned receipts are eventually converted into corresponding order proposals later in the process as described below.
Once the new project MRP planned receipt quantities are calculated, the corresponding planned demands for the structure components are generated. The calculated start date and the due date backed off by lead time , is the basis for breaking down the parts into their components and creating requirements for those components at the next level of the structure. The system multiplies the required quantity of the parent part by the quantity per assembly for the component, along with its scrapping factor. The result is the required quantity of the component. The entire structure of the part is processed in this way.
There are two types of blow-through parts. Typically, blow-through parts do not physically exist. The types of blow-through parts are as follows:
When project MRP is running, it can generate errors during the following processes:
Before running project MRP, you can select an option that tells the system to either complete or interrupt the project MRP if errors occur in one of the processes listed above. These errors appear in the Background Jobs window. Whether project MRP stops because of completion or interruption, be sure to check this log for errors. If it contains more than one error, you must fix the errors in the order in which they occurred. If you do not do so, incorrect results from one phase of project MRP can affect the results of a later phase. After you have fixed all the errors in the log, you can restart project MRP.
The final stage in the project MRP process is to generate order proposals according to the planning attributes set for the part. The values that determine the type of order proposal generated include the part type defined on the General tab on the Inventory Part window, the default supply type defined on the Planning Data tab, and the proposal release value defined on the Planning Data tab. The Proposal Release field indicates whether the project MRP should generate proposals for a part. The part type indicates whether a part is regarded as a manufactured part or a purchased part, and it indicates appropriate corresponding proposal types. Optionally, users can define a manufactured/acquired split and associated percentages on the Planning Data tab. If a split is defined, users override the default supply type with specific values for the manufactured supply type and purchase supply type.
Project MRP can generate proposals of different types including: