Executing MRP

MRP reports and inquiries can optionally display item requirements summarized by week. The beginning day of the week is specified in the Summary Default field of MRP Control. Calculations are based on this weekly period.

MRP calculates net requirements for items using three variables:

• Gross item requirements are the sum of an item’s requirements from forecasts, higher level products, customer orders, service items, and intersite orders. They do not take into account inventory on hand or scheduled receipts.

• Scheduled receipts for that item, including open purchase orders, open work orders with a quantity open and a status of R, and intersite requests for DRP items.

MRP uses these three variables in the following calculation:

Net Requirements = Gross Requirements – Quantity on Hand for the previous period – Scheduled Receipts

MRP schedules planned purchase orders and work orders to fill these net requirements. Planned work orders generated by MRP are exploded into gross requirements for their components. This process continues until there are no more planned work orders to explode.

Note: MRP does not explode product structures for purchased and distribution items or components with structure code Document.

When MRP plans orders for a parent item, it also determines if orders are required for any of the parent’s component items.

MRP generates component requirements using the standard product structure or formula effective for that item-site or site on the date of the requirement. Alternate structures and substitute items are not considered by planning.

Yield is also considered by MRP when it calculates component requirements. These calculations are based either on the parent item yield percentage or the yield associated with each operation in the parent’s routing. Operation-based yield is used when both of the following are true:

• Op Based Yield is Yes for the parent item in Item Master Maintenance or Item-Site Planning Maintenance.

If the parent item qualifies for operation-based yield calculation, each component could potentially have a different yield percentage.

If a component item is a global phantom, MRP may need to blow through the phantom and plan another order for any required components of the phantom.

The system automatically applies the yield percentage of a global phantom to each of its components. This is true even if the parent item’s planned order includes components of local phantoms.

See Phantoms for more information on global phantoms.

MRP plans co-products and base processes differently than other items. Net requirements for co-products are passed down to their respective base process items. MRP then generates planned orders for base process items to meet these requirements. These planned orders are imploded, creating planned orders for each of the co-products and by-products.

See Co‑products and By‑products for more details.

For routable assemblies, MRP generates a separate routable work order when an order for the parent item is released. Usually, you should not approve these orders or change their status to firm planned.

Because of the number of calculations required in an MRP or DRP run, it can be a time-consuming, resource-intensive process. MRP/DRP is typically executed as a batch process; for example, at night, when the load on the system is usually much lower.

To enhance MRP/DRP performance in an environment that includes Symmetric Multiple Processor (SMP) computers, your system can be configured in two optional ways, which are described in more detail in the DRP discussion:

• Running synchronized, simultaneous MRP/DRP calculations by defining synchronization codes. See the DRP chapter in User Guide: QAD Supply Chain Planning for information.

• Using a Progress application server (AppServer) to perform multi-threaded processing, which allows MRP/DRP tasks to be spread out among more computing resources. See User Guide: QAD System Administration for information on AppServers.

These methods can result in a significant improvement in the time required to run MRP—particularly with scenarios such as running regenerative MRP for a large database that includes multiple sites.