AX 2012 MRP Regeneration


We are finding the Static/Dynamic re-gen for our Serial items to be taking > 80 hours to process. When doing 2 of our linked items (as a sample) we are still finding it taking 52Hrs. EG: Item1 (Serial) has SubBom Item2 (Serial)

It seems all the processing is in the Futures calculations: The alarming one is the Quality tab in MasterPlans->SessionLog.

Statistics: Counting:

Number of productions = 2045, Number of production lines = 1293, Number of order lines = 1468


Number of order lines having futures messages = 4311516 in percent = 293700.00

Just wondering what this could be telling me if the percentage is ALLOT > 100 for the

Quality: " Number of order lines having futures messages = 4311516 in percent = 293700.00"?

Any suggestions would be greatly appreciated, as our non serial items are processing through in < 1Hr.

Consistency checks are not really identifying any issues.

Note: AX 2012, CU3 installed, with ProcessManufacturing.

I have attached the SessionLog details and the “ProcessTaskDuration”.


Could you show us the serial items setup and the coverage group along with the net requirements?

Hello Adam,

Thanks for the quick response.

“Thermo” - ProductDimension = “Config”, StorageDimension = “Site/Wh”, TrackingDimension=“Serial”, ItemModel=“FIFO”, CoverageGroup=“MTO CF REQ”

SubBomItem of Thermo:

“pieceThermo” - ProductDimension = “Config”, StorageDimension = “Site/Wh”, TrackingDimension=“Serial”, ItemModel=“FIFO”, CoverageGroup=“MTO CF REQ”

NOTE: We generate a new SubBom for each unique THERMO salesline, as we have a configuration attached to this.

We also generate a new SubBom for each pieceThermo, as we have a configuration attached to this.

Therefore we have thousands of subBom’s each with unique configurations (these items are uniquelly configured)

CoverageGroup “MTO CF REQ” specs (see attachment)

MasterSchedule Static (See attachment)

NetRequirements has Thousands of rows for all the demand. (See attachment for portion)

I will reply with SalesOrder → SubBom setup to let you visually see this in attachment.

Have you seen this Futures percentage ever be > 100%?


SalesOrderSetup attached.


Thermo (Serial “51”) SubBom (18458)

→ pieceThermo (Serial “52”) SubBom (18459)

->Raw Materials

With versions, serial numbers and sub-BOM;s all connected I would expect this to take some time.

Do you have serial number groups specified for the items?

What is your update marking set to in the MRP Parameters?

Why is the future date set to 200 days? What is your lead time and how far forward does it matter on the replan whether you receive this message or not?


We have a single serial number sequence catering for all our “Serially controlled” items. This is potentially 15 different Items all using the 1 sequence (Inv_29). Is there a benefit in having different number sequences per item, not even sure how to set this up? EG: Thermo 1~X and pieceThermo 1~X (it’s own number sequence). If so could you please explain the logic, we only use the out-of -the-box concept of NumberSequence (Inv_29 → Batch/Serial No.).

we have our UpdateMarking set to “Standard”, so we retain marking according to the pegging, also as we transfer in pack lots, we want to leave pack remainders unmarked, making them available for other orders.

We currently have monthly production cycles on some of our items, and also allot of raw material with 60+ day leadtimes. Although this number is inflated, changing this down for all timefences to say 2, has no impact on the MRP duration / statistics. We even tried bringing the coverage groups / MRP paramters back to it’s simplest / minimum settings and it still does not drop this duration.

We have even tried unticking the all the “Futures message” / “Action message” etc, though nothing seems to be bringing the processing duration down for our serial items.

Our serial items have their own CoverageGroup to control setup, so even if we were able to get them to MRP in a realistic-time frame, without futures messages that would give me something, as all the processing seems to be in the futures stuff. Just cannot seem to get it to stop doing it to see if the duration drops dramatically.

Do you have any explanation / thoughts why the Futures percentage is > 100%? It only seems to do it when we run it for our serial items.

Is there maybe some other diagnostics tools that could help us?

Is there any specifics we should check if we are using subboms?


Ultimately you need to get your partner to get hands on, it is the only way.

The processing time will reduce if you remove future messages., it must do, there is no alternative to this because it is a processing element of the plan that takes time to calculate. If you reduce the coverage time it must impact on the time, because it will not plan beyond the coverage time fence - however you are overwriting this on the plan, so changing it on the coverage group will have no impact, you have to reduce your overriding settings on the plan. Make sure you change the overall plan settings whilst testing the reduction, just doing it on the coverage group will have no impact at all.

There is no benefit of having different serial number sequences it is the setup of the sequence and whether it is one per - I presume it is but it does not have to be. By planning at a serial number level the marking has an impact, but yours is set to standard, it does mean it will mark through the BOM so this again comes down to volume and complexity of the BOM.

Have you routes? Are the resources finite? The futures is probably planning at every single level, why it is greater than 100% is difficult without being hands on.

I would suggest creating a test environment and trying with one setup. Ultimately the serial number, sub-BOM and production with routes will have a signifiicant impact on the plan time because of the processing time for each and every serial number. It is simply a matter of processing time. The non-serial is much quicker because it is aggregated into net requiremetns, serial processing cannot do this because the requirements are processed individually as requirements.

Not much help sorry, but get someone in who can actually look at it and offer advice on the entire setup.