Material Resources Planning

From Opentaps Wiki
Revision as of 00:15, 13 January 2009 by Sichen (talk | contribs) (How MRP Works)
Jump to navigationJump to search

Material Resources Planning (MRP) is a time-series analysis tool which helps you plan purchasing and production to meet customer demand. It will combine information about your current inventory with outstanding sales, purchases, and production orders to determine both the quantity and timing of additional inventory required. It will then create Requirements to help you order or manufacture more products to meet demand.

Configuring MRP

To use MRP, you must first set up the following information:

  • Set up Bill Of Material for products which you sell. If you have imported products, you should run the initLowLevelCode service to set up your products and check the Product.billOfMaterialLevel to make sure it is set.
  • Set up Product Suppliers for products which you purchase. You should designate a "Main Supplier" for the primary vendor of your products.
  • Set up Inventory Stock Levels for all your products, by warehouse.
  • Your products must have a "low level code" configured for them. If they were created in opentaps, they should be created automatically. Otherwise, if you imported your products, your system administrator must run a service called "initLowLevelCode".

Then you can use the Run MRP Screen to run material resources planning for your warehouses. After running MRP, you can use the View MRP Screen to look at the results. You can also use the Open Requirements Screen to approve or cancel the requirements created by MRP and thus start the purchasing and production process.

How MRP Works

Imagine drawing a horizontal line across a piece of paper. Now imagine that it is a timeline, and as you move from left to right on the line, you are moving into the future. Pick a product. Now for each sales order you have, mark on the line the date when you must ship the order and the quantity you must ship to your customer. Repeat this for all upcoming receipts of inventory from your suppliers or from manufaturing operations at your company. Now you have a time line of all the "inventory events" for your product. You can then take the starting inventory of your product, move from left to right into the future, and calculate the inventory at different points in the future. Next, whenever the inventory dips below your minimum stock quantity, write down a "requirement" to obtain additional inventory. If this product is purchased from suppliers, then this means you need to purchase and receipt. If the product is manufactured, the requirement means you need to manufacture it.

You have just manually performed MRP for one of your products. A real MRP system is much more complicated and must consider delivery lead times and bills of materials for all of your products, but conceptually it is very similar to the process above.

The opentaps MRP system begins by creating the inventory events timeline for every product which has a minimum stock defined in the warehouse. It will create a negative inventory event when a product is required for a sales order or as the raw material of a production run and a positive inventory event when it is to be received from a purchase order or as the product as a production run. When there are pending production runs, it will also look through the Bill Of Material of a product to create inventory events for the dependent parts of a product.

It will then start from products which are at the top of the bill of material and run through all their inventory events. If a product has no inventory events, then MRP will compare its current quantity on hand inventory versus the minimum stock set for the warehouse. If at any time the inventory events cause BOM to fall below the minimum stock, and the product is NOT defined with a type of "WIP", the system will try to replenish the inventory stock by taking the following steps:

  1. It will look for Backup Warehouses for the current warehouse and see if it could request a transfer from these warehouses.
  2. If not, it will create a new requirement to purchase or manufacture the product. To determine whether a product will be manufactured or purchased, the system will consider whether it has a Bill Of Material of its own and whether it has any supplier products defined for purchasing. By default, a part is considered manufactured if it has child nodes AND if it also has no unexpired SupplierProducts defined. Products to be purchased will be associated with the "Main Supplier" of the product by default.
    • In opentaps version 1.4, the production routings for a product can have minimum and maximum quantities associated with it. In that case, if production routings have been found, but none of them have the required minimum or maximum, then MRP will not create a manufacturing requirement for the product. It will be skipped by MRP. Purchasing requirements for its bill of material components will also not be created.
  3. It will create a link between the requirement and any outstanding open sales orders which prompted the requirement to be created. The requirements will be allocated to the orders in the sequence that they were reserved.

If your product is defined of type "WIP", then no requirements will be created for it. The system, however, will go through it and create requirements for its components.

After completing all the products at one BOM level, it will go down to the next BOM level and repeat the process, until it has either traversed all the BOM levels or it has traversed three levels without finding any products which require any purchases or production. Products with type "WIP" would not have requirements created for them because the system will create requirements for the parts of such products.

If there are no inventory events for a product, MRP will essentially compare its current quantity on hand (QOH) inventory level with the minimum stock level and create new requirements if it is below stock.

If there are fractional quantities, MRP will by default round them to two decimal places.

Since MRP is based on a time line of a product's inventory events, it is extremely sensitive to assumptions about the timing of inventory events. For example, imagine that a sales order must be shipped out at 12 PM (noon) today, and you have a purchase order coming in at 12:01 PM. Should the MRP assume that you can wait until 12:01 to ship out the order, or does it actually need to order additional inventory so that it is in stock in time for the 12 PM order? The "common sense" answer to that question is something which the MRP system needs to simulate. The opentaps MRP makes the following assumptions about the timing of events:

  • It will use the stated shipment or production time for inventory events. If those are not available, it will assume the current time, except for the following:
    • For sales order shipments, if there is now specified ship time, it will use the "default years offset" parameter to move the sales order shipment X years into the future. By default, this parameter is set to 1 year, so MRP assumes that any sales order which does not have a shipment date set will need to be shipped 1 year in the future.
    • It will then use ProductFacility.daysToShip to set the time when a sales order shipment is needed. For example, if a sales order is scheduled to ship on Oct 15, 2007 and the product's daysToShip is 10 days, it will assume that the products on the order must be available in the warehouse on Oct 5, 2007.
  • No event will be set into the past: if any inventory event is before the current date/time, MRP will adjust it to the current date/time and mark it as "late."

Note also that at this time, the opentaps MRP is completely deterministic: it does not use any probabilities in calculating inventory events or potential requirements.

After MRP is completed, you can either view mrp results or go to the Open Requirements Screen to see the requirements which are created.

Sales Forecasts

In opentaps 1.4 and later, MRP will consider sales forecasts as well as actual sales. MRP will create production of purchasing requirements based on a percentage of item level sales forecasts. For example, you can have MRP create requirements at 50% of the forecasted sales level. To incorporate sales forecasts into MRP:

  1. Load your sales forecasts into the SalesForecastItem entity, using a CSV loading tool for your database. You need to fill in the fields facility ID, product ID, forecast data and time, and forecast quantity. The other fields are currently not used.
  2. When running MRP, set the percentage of sales forecast parameter to the percentage you want to use.

MRP will then find all the sales forecasts in the future, i.e. after when the MRP is being run, and adjust the inventory down by the forecast quantity multiplied by the percentage of sales forecast to create the appropriate requirements. For example, if you are forecasting a sale of 10 units a month from today, and your percentage of sales forecast parameter is set to 50, MRP will create a requirement for 5 additional units one month from today. Sales forecasts with forecasts date in the past will be considered expired and ignored.

Transferring Inventory

Starting with version 1.4, there are two new features for transferring inventory between your warehouses:

  1. You can use the FacilityTransferPlan entity to set up future dates when inventory transfers between your facilities will take place. If there are records in this entity, then MRP will only transfer inventory on those dates, and inventory transfers needed before the dates in the FacilityTransferPlan will be grouped on those dates.
  2. You can specify whether MRP will create inventory transfer requests directly, or whether it will create inventory transfer requirements on the dates when the inventory transfers should take place. The inventory transfer requirements function like other open requirements: once approved, they will cause inventory transfers to be created and inventory to be reserved for transfer.

There is one important difference between using inventory transfers directly versus creating transfer requirements: if your backup warehouse does not have sufficient inventory to meet the needs of the primary warehouse, then an inventory transfer will be be created for the quantity actually in the backup warehouse. In contrast, a transfer requirement will be created for the full quantity needed by the primary warehouse, whether the backup warehouse has sufficient inventory are not. The reason for this is so that you can aggregate all your inventory requirements into the backup warehouse, thus consolidating your purchasing or manufacturing there, rather than creating purchasing or manufacturing requirements in a lot of warehouses supplied by the backup warehouse. Once you approve the inventory transfer requirements and then run MRP for your backup warehouse, it will create purchasing or production requirements in the backup warehouse.

Customizing and Extending MRP

The opentaps MRP system offers additional possibilities for developers beyond those in the Run MRP Screen:

  • It is possible to configure your MRP to round to a different number of decimal places and to configure the interim and final rounding, so that you can have MRP "accrue" fractions, carry them forward in time, and do the normal rounding in the final period by using 0 decimal places, RoudningMode.DOWN for interim requirement, and RoundingMode.HALF_UP for final requirement.
  • You can run the opentaps MRP as a "black box" for other ERP or inventory management systems, without using the opentaps sales, inventory, and purchasing models, by turning off the reInitializeInventoryEvents field and importing InventoryEventPlanned records.
  • There is also now an MrpConfiguration abstract class which you can implement and pass into opentaps.runMrpForFacility. It is new and not fully developed yet, but the concept is to allow you to custom-configure the various results of MRP, such as turnaround time for manufacturing or purchasing.