SytelineMaster

Proper order for running MRP and MPS ProcessorThe order in which the MPS Processor and MRP Generation utilities are run depends upon the way you are using the MPS functionality. Which should be run first depends on whether or not you have MPS items which are not top level items and whether or not you are using the MPS Planning Fence feature. The primary function of the MPS processor is to examine the receipts and requirements which exist for each MPS item and generate the appropriate exception messages. Beginning with version 4.0, it also generates MPS receipts for requirements outside the MPS Planning Fence. It does not do any multi-level BOM processing (e.g. passing of requirements). The following is an overview of the MPS Processor algorithm.

– Reads each item master which is an MPS item.
– Deletes all exception messages which exist for the item.
– Generates requirements from COs for the item and consumes forecasts.
– Reviews all other requirements and receipts which exist for the item.
– Generates the appropriate exception messages.
– Generates MPS receipts if any unsatisfied requirements exist outside of the planning fence.

The key points to consider are the following:

1)  The MPS processor generates exception messages after reviewing all receipts and requirements for the item. Since the MRP Generation does all passing of requirements, this means that the MPS processor needs to be run after  MRP if you have MPS items which are not top-level items. In that case, if you ran the MPS Processor first it may not  generate exception messages properly since the item has not yet been passed requirements from its parent items (or had the dates of existing requirements adjusted).

2)  You can use the MPS Planning Fence field to have the system generate MPS receipts for uncovered requirements which exist for MPS items outside of the number of days specified. The MPS Processor is what generates these receipts but, like manually entered MPS records, these are exploded to the MPS item’s BOM by the MRP Generation. So, if you are using the fence and run the MPS Processor after MRP, it may generate MPS receipts which will then not be passed to the MPS item’s BOM until the next night’s MRP run.

Therefore, to have clean MRP data and exception messages after each night’s run, you should:

1. If you are using the MPS Planning Fence, run the MPS Processor and then MRP.

2. If  you have MPS items that are not top-level items, run MRP and then the MPS Processor.

3. If you are not using the planning fence and all of your MPS items are top-level items, the order in which you run them does not matter.

4. If you have top-level MPS items for which you use the planning fence and non-top-level MPS items for which you do not use the planning fence, running the MPS Processor, then MRP, and then the MPS Processor again would result in clean information.

The situation you may want to avoid is having non-top-level MPS items for which the planning fence is being used. In that scenario, you may not have completely clean data and exception messages after one night’s processing even if you run the MPS Processor twice since an MPS receipt may not be generated for an MPS item until the second time the MPS Processor is run.

For example, if a new requirement which is outside the planning fence needs to be passed from a parent item to a level-2 MPS item, it wouldn’t exist when the first MPS Processor is run so no MPS receipt would be generated to cover it. MRP would then pass the requirement to the level-2 MPS item. The second running of the MPS Processor would then generate an MPS receipt to cover the requirement and generate correct exception messages, but that MPS receipt would not be passed to the level-2 item’s BOM until the next MRP run.