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.

Intro

There are three main tools you can use to plan with SyteLine:

• MRP
• APS, finite
• APS, infinite (APSI)

These key factors will help you decide which planning tool best fits your needs:

1. Constraint behavior
2. Accurate times
3. Motivation

There are also a few secondary factors that may affect your choice. We’ll explain each below

Constraint behavior

Do you want constraints to push out plans or do you want a fixed target?

Here are the constraints that may move plans out:

• Material availability
• Capacity
• Time on-shift
• Today

APS backwards plans. If any of the first three constraints is not available between today and the due date, and it lies on the critical path, the system will push the plans out and backwards plan from the new date. If the plan is moved out, then ALL plans for that order are moved out.

For example, a user receives a customer order. If the user constrains on a material and its lead time is such that it affects the critical path, then APS will move all plans (all purchase orders, manufacturing orders for subassemblies, etc.) for the meeting the customer order out. You can turn off this constraint at the item level, but if a constraining material is not available and on the critical path, APS will move ALL plans for the end order out.

Another example. If you do not have capacity, APS will search for earlier time when you do. If you have none, it will push out the plan to find available capacity. And because the plan for manufacturing is pushed out, so are all the need dates for purchased materials. (Time on-shift works like capacity in that APS applies your times to a working calendar, if you choose, instead of a 24×7 calendar.)

The whole concept of pushing out plans is tied to the just-in-time philosophy. So if you have capacity constraints, the APS approach will minimize the inventory by synchronizing its arrival with its use. APS provides tools to see plans that are late. You can then work to resolve those issues and meet your due date. If you want any of these constraints to move your plan dates, you’re probably a candidate for APS or APSI.

However, some users do not want constraints to move out target dates. They want a fixed target for a plan. They want to see what they need to do to ship at a certain date. They want to clearly see when something is supposed to happen and will expedite and increase capacity to make it happen. These users do NOT want to see moving release dates and non-critical item pushing out the critical path; they simply want to freeze the plan until they’ve exhausted all expedite and capacity solutions.

If you want a fixed target, you are a candidate for APSI or MRP. Generally, such users have the following characteristics

To-order environment with revenue targets and cyclical order bookings

Most of their products are engineer-to-order, assemble-to-order, or make-to-order. They often sell configured products so they can’t make them ahead of time and level their production. The best they can do is plan for common sub-assemblies and purchased parts using planning BOMs and forecasts or dummy MPS lines with a kit of these common items.

These users have quarterly revenue targets and most of the order bookings come later in the quarter. There’s a rush to sell and ship product to meet the revenue targets at the end of the quarter, then a slow period at the beginning of the next quarter.

These users don’t want their plans to move. They want a fixed target and will do whatever it takes to get it out the door.

Material, not capacity, is the critical constraint

Backlogged orders or late shipments are most often caused by material shortages. Such users would rather get material in, even if months early, than experience a shortage. Variability in lead time only adds to this issue. A lean, JIT environment poses too much risk of material shortages for these users.

Capacity is not an issue for these users. They only need to know WHEN they need the capacity and HOW MUCH. Then they’ll make sure it happens.

No negotiation power with customers

Users who have little negotiation power with their customers usually have the following characteristics:

• Often a majority of their business comes from a handful of customers.
• The customers require them to feed their production schedule, and if they’re late they’re heavily fined.
• It’s cheaper to expedite than miss the customer deadlines.
• A highly competitive environment and meeting due dates is critical.

In these situations, the user wants a fixed target for production. They want to know when they need materials in and when they need to increase capacity. They will do whatever it takes to make the date.

Accurate times

Do you have accurate operation times for mfg items and lead times for purchased parts? If not, are you willing to spend time to update them?

APS will push plans forward using mfg times and lead times. If users can identify the critical materials and operations and have accurate times for these, they will find APS results reasonable. In complex manufacturing or assembly environments, balancing/synchronizing material and capacity is more important, and APS can help if a user has accurate data.

Note: in such situations a user does NOT need accurate data on all operations and materials–they only need it for the critical materials and the bottleneck resources.

If a user does not have accurate time information for the critical resources and materials and does not want to do what is required to update those times, then that user is a good candidate for MRP or APSI. In these situations, the user is comfortable with MRP or APSI backwards planning without constraint and working with a rough idea of how much expediting is needed for a given item.

Motivation

Are you actively looking for a solution to improve your planning or are you satisfied with MRP?

APS approaches planning different from MRP. Here are some of the key differences:

• Constraints pushing out plans
• Using projected late instead of past due to flag problems
• Consolidation
• Load (APS provides)
• BOM data needed (can run MRP on lead times, good routing times not  required), good lead times defined
• New parameters

Moving from MRP to APS or APSI requires a significant change. It requires commitment and energy to revise appropriate business processes, obtain accurate date for critical resources and materials, and train the users. Many APS and APSI users have realized significant benefits in reduced lead times, reduced inventory, and increased on-time deliveries. However, if a user is simply trying to move from SL6 to SL7 to take advantage of the Microsoft platform or is happy with the results of MRP, then they are not a candidate for APS or APSI.

Secondary factors

There are a few other factors that differ between MRP and APS. Consider these when making a decision.

Load views

APS and APSI will show you capacity. MRP will not. If you want a view of the load, even if you want an MRP-like plan, and are not using scheduler, then you’ll want to use APS or APSI.

What-if analysis

Only APS and APSI provide what-if analysis with the Analyzer.

Consolidation

Will the difference in consolidation hurt your process? Can you set consolidation times to be equal at all levels of a BOM or use order mins and multiples to manage inventory?

Decision Table

The 3 key questions you need to answer:

Notice that in many instances a user can run APSI like MRP, yet take advantage of some of the tools in APS. To do this you need to make some specific settings.

How to set up APSI to run like MRP

If you want the load data, Analyzer what-if capability, and order visibility provided by APSI, but want it to run like MRP, you’ll need to set a few fields. The table below describes what you should do.

Why MRP Failed with Low Level error?

At the end of the MRP Generation, you receive the following error:

[WARNING – Low level codes are improperly set. MRP Generation is not complete – re-run Net Change. MRP PROCESSOR] was not successful.

If you receive this error at the end of running the MRP Generation, it may or may not mean that the low level codes in the item master are improperly set. When the MRP Generation completes, it scans the item master file for any item where the “Net Change” flag is yes. All flags should be no if MRP runs successfully.

If any items are found with the net change flag set to yes, MRP displays the above error. Although it is not always the case, MRP is making the assumption that items found were not processed due to a low level code problem. The following are all of the known reasons for why this error may occur:

1) Low Level Codes are incorrect.

This is the most common reason for this message. To ensure that low level codes are accurate you should first run the “Current BOM Processor” and then the “Job BOM Processor” before running the MRP Generation. If your low level codes are not correct, your MRP data will not be accurate for the problem items and all items below them in your BOM structure.

Because of the nature of these algorithms, running them both and doing so in the proper sequence is crucial. Not running the job processor or running it before the current BOM processor may result in incorrect codes. There is a utility attached to this entry that can be used to display any items that have an incorrect low level code after the two processors have been run.

An alternative to running both processors before each MRP run is to have the inventory parameter “Low Level On-line” enabled which causes the system to adjust low level codes on-line as BOMs are copied and maintained. If both processors have been run at some point without errors and this flag is enabled, your low level codes should not be the problem. If you are relying on this parameter to maintain your codes, it may be worthwhile to run both processors before the next run to see if they fix the problem.

2) People are using the system while MRP is running.

Although it is not always feasible, the MRP Generation is designed to be run when no users are in the database. If there are users working in the manufacturing modules while MRP is running, there is a strong chance you will receive this error. If MRP plans an item (changing its flag to no) and then a transaction is processed or an order entered for that item while MRP is still running, the item’s flag will be flipped to yes which will result in the error at the end of the generation. In this situation, there really is no problem which needs addressed other than perhaps a procedural change to assure no one is using the system while MRP is running.

3) Invalid cross references.

If you have what MRP determines to be an invalid cross reference, it will generate and error and skip the next item before changing the item’s net change flag to no. Therefore, the item with the invalid cross reference will generate the low level code error. If MRP is being run in the background queue, the error will be written to the MRP error file (mrp.err). If being run in the foreground, the error will appear on screen. This problem cross references must be manually cleaned up in order to prevent this error.

Cross references can be created between CO line items and jobs, job materials and subjobs, or job materials and PO line items and must be a one-to-one relationship. If one record points to another which is not linked back or if multiple records point to the same record the system considers that an invalid cross reference. Examples would be if a CO line item is referenced to a job which is not referenced to the CO line or multiple job materials all referenced to the same PO line item.

4) An item is missing the inventory default warehouse.

Every item in the item master file should have and item warehouse record (itemwhse) for the warehouse that is defined as your default warehouse in the inventory parameters (typically MAIN). SYMIX always expects that record to be there. If the “Whse Considered For” MRP parameter is set to “Single” and an item is missing this record, MRP will skip the item without resetting its net change flag. To check for this condition, you can run the following program from the Progress query editor:

find symix.parms 0.
for each symix.item no-lock where item.item <> “”:
find itemwhse where itemwhse.item = item.item
and itemwhse.whse = parms.def-whse no-lock no-error.
if not available itemwhse then
display item.item item.change-date.
end.

If any items are missing this record, it can be created by running the “Item Stockroom Loc Mass Create” utility on the inventory Warehouse Transfer Utilities menu.

5) The BOM processor(s) failed without error due to incorrectly imported data.

Like item 1 above, this may result in incorrect low level codes but it is really a different problem. If you have imported data such as item master records, current routing and BOMS, jobs, job routings and job BOMs and all of the files and fields have not been populated appropriately, both processors may complete with no error messages but your low level codes may still be inaccurate.

One past example of this was imported actual jobs that did not have the “Finish Job” field populated. The Job BOM processor gave no errors but did not work since it counts on that field being set for identifying top level jobs.

6) Low level code are incorrect due to bugs 19385 or 19387

These are two bugs that ONLY EXIST IN VERSION SL3b00. The problem defined by bug 19387 is that the low level codes are not set properly when you add materials to a current or job BOM if the “Low Level On-Line” inventory parameter is enabled. The workaround is to run the Current BOM Processor and Job BOM Processor before each MRP run.

The problem described in bug 19385 is that the Job BOM Processor may not adjust your low level codes correctly if there are manufactured items used in job BOMs at lower levels than they are used in any current BOMs. The true cause of the problem is that the inventory module is leaving the status field blank in the current job it creates when you create a current routing for an item. It should be (F)irm. The workaround is to run the following program to populate that field and then run both processors.

for each symix.job where job.type = “S”:
job.stat = “F”.
end.
If none of these prove to be the source of the problem, the first step should be check the background queue log file, MRP error file, and the database log file. If there was a Progress error generated due to missing or corrupt data, it will appear in one of these files.

If no errors are found, the next step would be to run the “Items with Net Change Flag” report immediately after MRP finishes. Any items for which the net change flag is yes will appear on the report. You should then examine the data structures in the system for those items. For example, run a “Single Level Where Used” report for the item and verify its low level code is higher than all its parent items’ codes.

It is imperative that the report is run after MRP finishes but before any users begin using the system since there activities will likely turn on the net change flag for items making it impossible to know which items generated the low level code error. If running MRP in the background, you can set up this report to also run in the background after MRP.

The MRP Generation algorithm
– SL6 and lower (Progress versions)Regenerates the m-day calendar if it requires regeneration
If full regeneration being run:
Delete all requirement records for all items (mrp table)
Delete all transfer order receipts for all items (rcpts table, ref-type “T”)
If lasttran counter for PLNs is > 9000000:
Reset it to 1
Delete all planned orders for all items (rcpts table, ref-type “N”)
End
End

Reads through item master by low level code, by item:
If type is Other and net change is on, turn it off and skip to next item
Turn on the I/M net change flag for all current materials of the item
Get the following from item’s product code (if not ?) or planning parms:
Forecast look ahead and behind
Job reschedule tolerance factors
PO reschedule tolerance factors

Generate independent requirements:
Delete forecasts older than (today – forecast look behind)
Consume forecasts with customer orders
Create requirements for:
Outstanding forecasts
All unreserved COs
Transfer orders where
If “Whse Considered For” = Single
From Whse = default warehouse
If “Whse Considered For” = All
From Site is the current site
Project resources
End – Generate independent requirements

Create receipt records for transfer orders where:
If “Whse Considered For” = Single
To Whse = default warehouse
If “Whse Considered For” = All
To Site is the current site

Delete all of the item’s exception messages
Calculate beginning projected on hand (nettable on hand – qty reserved)
Generate applicable exceptions regarding beginning on hand:
On Hand below Safety Stock
Initial Qty. On Hand negative

If beginning on hand below safety stock and there are no past due requirements:
Look for first receipt for the item (job, PO, PS, transfer order, PO req)
Generate exception if appropriate:
Reschedule Receipt
Sched. Rcpt. past due
If no receipts or not enough to cover quantity below safety stock:
Create planned order (PLN) in temporary table
End

Read through all requirements for the item:
If requirement source is x-reffed, find x-reffed receipt (po, job, etc.)
If x-ref is valid, skip to next requirement
Generate error (then continue on) if:
Receipt is not cross referenced back
Receipt has a status of complete
End.
Generate exception if appropriate: Date outside shop calendar

If not an MPS item:
Generate exception if appropriate: Requirement past due
If requirement source is x-reffed, find x-reffed receipt then
Generate appropriate exception:
X-ref Rcpt: Resched
X-ref Rcpt: Qty
Sched. Rcpt. past due

If requirement is a forecast and “Use CO, Fcst or Both” is Forecast
Deduct full forecast amount from POH
Else deduct outstanding (i.e. not consumed by CO) amount from POH
Look for next receipt for item
If found, generate exception if appropriate:
Reschedule Receipt (if outside PO and job reschedule tolerance factors)
Sched. Rcpt. past due
If no more receipts or not enough to cover quantity below safety stock:
Create planned order (PLN) in temporary table
End – not an MPS item
End – read through all requirements

Read through all existing planned orders for the item (from the last MRP run)
Match them with temp table PLNs created in this MRP run
If old PLN and new PLN match up, set date and quantity to new record’s values
If old PLN exists and new record does not, it is no longer needed so it is deleted
If old PLN does not exist for new PLN, create a new real planned order
End

Read through all non-PLN receipts (jobs, PO, etc.)
Generate exception if appropriate: Sched. Rcpt. not needed

Pass all requirements to children:
Pass PLNs to current BOM, creating PPLN requirements
Pass job receipts to job BOM if exists or current BOM if not, creating PJOB requirements
Pass PS receipts to PS BOM if exists or current BOM if not, creating PPS requirements
Turning on each child’s net change flag
End

Turn off the item’s net change flag
Set the item’s Last Generation date

If the item’s Source is Transferred, it’s not an MPS item and its Supply Site is not blank
Set the flag that indicates planned transfer orders need passed for the item

End – read through item master

Turn off the behind-the-scenes flag that indicates a full regeneration must be done

If an error occurred (invalid cross reference detected):
Display “MRP Processor was not successful”
Else
Look for item master records with their net change flag enabled
If there are any (none should be) display:
“WARNING – Low Level codes improperly set”
“MRP Generation is not complete – re-run net change”
If not being run in the background:
Ask if the Item With Net Change Flag report should be run.
End. else
Display “MRP Processor was successful”
End

If multi-site and “Post Planned TOs” = Auto:
If not being run in the background
Display “Put Planned TRN Requirements will be performed”
Read through all transferred items for which the pass planned transfers flag is enabled:
Pass all PLNs for the item to the item’s Supply Site as TPLN requirements
Set the net change flag for the item in the supply site
display success or failure message for “Put Planned TRN Requirements”
End

Delete all records from the material planner workbench that were created from PLNs