Every time I lead a session for one of the many AXUG conferences or a class for the AXUG Academy, I always hear the following question:
“Why do I get cancel action messages on planned orders. If I’m supposed to cancel the planned order, why generate it in the first place!”
To understand the mechanism behind this, two little tidbits about master planning logic are important: the sequence that master planning executes certain tasks and assumptions about the users’ behavior.
First, master planning does 4 distinct processes when master scheduling is run. These can be seen by examining the session log for a given plan by navigating to “Master planning”–>”Setup”–>”Plans”–>”Master plans” and clicking the “Session log” button.
In the first step, “Update”, master planning prepares to get ready to calculate coverage. This step is the step when AX clears out the InventSumLogTTS records in the event of a regeneration. This is also the step that AX deletes the entire existing requirement profile, except for approved planned orders. In addition to a couple of other things, AX also generates the new, uncovered requirement profile for the item. The on-hand records, receipts, safety stock, and issues that need to be covered are all inserted into ReqTrans.
The second step, “Coverage”, is when the planned orders are created. During this step, AX looks at the requirement profile calculated in the last step and creates planned orders to represent the orders that must be created in order to satisfy all the demand. These orders are AX’s best guess based solely on the existing requirement profile. It’s necessary to understand that, at this point, AX is looking at the requirement profile and NOT the planned orders it’s creating. Since the planned orders could be created in batch, it’s not possible for AX to accurately use them as input in this step.
After the coverage is calculated, we come to the action and future messages steps. As explained in the previous paragraph, up until this point, AX only used the pre- coverage calculated requirement profile to generate planned orders. Without action messages enabled, this rudimentary coverage is left alone and no messages are calculated. If action messages are enabled, though, AX takes a pass through the newly created planned orders and gives suggestions on how to improve them. After the actions are calculated, futures are then calculated using the newly created action messages (if certain parameters are enabled) as input to get the best possible suggestions.
With this knowledge, it’s quite clear to see why AX will calculate cancel action messages for planned orders. As the action messages are calculated in sequence after the planned orders are generated, it’s possible that, based on the baseline requirement profile, AX calculated some planned orders that weren’t optimized. It’s not until the action messages look at the whole requirement profile – planned orders included – that AX can see that it might make sense to cancel one planned order and change another one.
This brings us to the second important fact about master planning when it comes to understanding canceled planned orders. Action messages are displayed with the understanding that you will act on all the other action messages associated with the item. For example, look at the screenshot included below.
This screenshot shows a situation where two action messages must both be acted on in order to get the most optimized requirement profile. It doesn’t make any sense to cancel the planned purchase order shown unless the planner is able to also postpone and increase the already existing planned order.
Hopefully, this post helps people understand a little behind what AX is trying to do when master planning runs. Although it seems inefficient and annoying to generate planned orders just to turn around and tell you to cancel them, it’s a necessary evil in the way master planning runs.