In part 1 of this article, we examined the basics of marking functionality Microsoft Dynamics AX, which dates back to the early releases of the product and remains much the same today. Here in part 2, we will explore more complex ways in which marking impacts firming planned orders, pegged supply, the production order cost sheet. We conclude with some thoughts on manual marking (and un-marking).
Firming planned production orders in MTO/ETO scenarios
As we have seen in part 1 in the paragraph about production orders, the release and start status with the use of the checkbox “referenced orders” makes a lot of sense in a Make-to-Order or Engineer-to-Order scenario. But we should take a step back and start in Master Planning.
In an MTO or ETO scenario, the BOM is order-specific and has to be created especially for a customer. MRP can not wait for that BOM to be finished, so MRP will typically have run many times already before the customer-BOM is finally completed. This means that MRP will be exploding an active but still changing BOM.Also, the growing BOM does not always grow in a linear fashion. Corrections are often made where part numbers are removed and replaced by others.
When we are not using ‘pegged supply’, we will have planned production orders on many BOM levels, some planned prod orders will not change, others will come and go, before the BOM is completed.
In Standard AX, the decision to firm a planned order is mostly a manual one, (although the option of automatic firming exists in the coverage group)
If I am a planner/buyer and I face a firming decision for items on lower BOM levels, I check my net requirements screen for the item to understand what is going on with this item in the broader sense, let’s assume I would agree with MRP’s suggestion. The next thing I do is look at the order date of the planned order. Is it time to firm this order yet? We don’t want to firm too early.
A well-known and rather obvious piece of advice is to firm planned orders as late as possible, in order to maintain the re-planning capability of Master Planning.
For Make-to-Stock scenarios, the approach above, just looking at the planned order start date, is sufficient. I can confidently firm planned production orders that way.
But for MTO/ETO scenarios, this approach is not sufficient. I need to somehow know that the BOM has stopped changing. I need a signal. And if that signal comes, I am not firming bottom-up, using order dates, but I want to firm the entire “job”, which could be hundreds of planned production orders, which are all part of a sales line explosion. (For those items in the BOM that are firm, I have seen engineers “approve” the planned orders for those, leading planners/buyers to only firm approved planned orders. Having an item status field that indicates the engineering status of an item would address this issue in a more fundamental way)
The signal from Engineering “BOM Complete” could theoretically be the “Approved” status, for MRP it would make more sense to use the “Active” status. But this is not practical. When certain parts of the BOM are known, we need to start planning orders. That is why we have this active BOM that is still changing.
After engineering has signaled that the BOM is complete, we can only go to one place to firm all planned orders related to a sales order line.
In the sales line, we find “Explosion” in the Product and Supply pull-down menu.
Then we click “Planned orders.”
This is our list of orders that we want to firm together. This is how we firm in an MTO/ETO scenario.
In that case we get a fully marked set of production orders that together represent one “job”.
There is no other way we can find this planned order list in the system, and this creates a security dilemma for companies because planners are typically not allowed in the sales order module. But this can be solved by giving the planner role only access to the relevant choices in the “Product and Supply” menu of the sales line.
An enhancement has been suggested on the Microsoft Connect site to add a special menu choice in the Master Planning module for planned orders that are the result of a sales order line explosion. Only in Make-to-Order scenarios would the planner go there to firm planned orders that are all part of one sales line explosion, part of one job.
What about Pegged Supply?
Pegged Supply is a line type in the BOM that does nothing else then create marking relationships between production orders, just at a much later time then when using Master Planning. The exact same end result can be reached by firming planned production orders with marking set to ‘standard’ or ‘extended’. The big difference is early visibility. With “Pegged Supply” I have no visibility of my lower level Production orders until I estimate my top level production order, because the orders simply don’t exist yet.
This could be a reason to choose regular planned production orders that are firmed using marking. Customers often worry that Pegged Supply prevents the MRP run from generating planned purchase orders below that “Pegged Supply” item. This is not a problem. MRP will do the BOM explosion as always, it will just not create regular planned production orders when it sees “Pegged Supply” but planned production orders that are “directly derived” and display as “Dynamic.”
These “directly derived” planned production orders cannot be firmed. They just serve as vehicles for the explosion. (similar to planned production orders for phantoms)
The Production order costing sheet “single”/”multi” level
In order to see estimated and actual cost of a production order, we have the very nice screens that are hiding under the icon “price calculation” in the VIEW tab of the action bar.
This cost sheet has the remarkable feature of being able to switch from a “Single level” to a “Multilevel” view. For Make-To-Order companies we have a key requirement of being able see the Total Actual Cost of Material, Labor and Overhead for a group of production orders that are part of the manufacture of some piece of equipment. By going to the top level production order and switching the level to ‘multi’, would I be able to see that here? At fist glance, it seems the answer is “yes”.
Now it is time to fasten our seat belt because we are going on a little Lewis and Clark discovery tour!
Question 1: When testing this “Single”/”Multi” level field, I don’t always see an effect. What is causing that?
Answer 1: First of all, to see any effect when switching the level from “Single” to “Multi”, two things have to be true:
- The item has to be on standard cost
- The inventory management parameter shown below has to be set.
Question 2: does marking have any effect on this cost view functionality? I can imagine when production orders are all marked against each other in a hierarchy of orders, the system could find the actual labor cost on a lower BOM level and show it to me on a higher level, when I switch to the “Multi” level view.
Answer 2: I can imagine this also, but this is not in the design. Because we are now talking costing, the marking functionality suddenly shows its true colors, being a costing feature that can gives us actual cost with more precision than FIFO costing would do. But if our items are on standard cost, marking is meaningless from a costing perspective and the system will not show us any “true actual cost” on lower levels, it will just show the standard cost on those lower levels. Be careful, it appears to work, until you check the dollar amounts precisely!
In the “costing” mode, this view does show actual cost for items on standard cost, but only for the production order I am currently on. We have to realize that marking has its limitations when we talk costing. It does not and cannot have any effect when we are using standard cost items.
What about FIFO or LIFO costing? Would I see lower level labor cost when I am on a production order of the end item? This would be very logical, it would be great, but no, the “single”/ “multi” level feature does not work, by design.
It is important to realize that standard AX is simply not able to show me an aggregated total of material, labor, and overhead cost for a group of production orders that are all referencing each other and make up one “job” for a customer. To satisfy this important requirement, we need to create a custom report that scans all the marked production orders, gathers their actual costs, and calculates a grand total, avoiding any double counting. (it would be summarizing costs by cost group or cost category when the project module is involved).
While there is no standard tool for this, Sikich (my employer) has created a cost analysis tool that fills this gap in standard AX, it is called Cost Connect.
Manual un-marking and marking
At the end of this second article, we will discuss the manual un-marking and marking functionality. Although it would probably (and hopefully) not be used much, I want to show the reader how to un-mark and re-mark as it will increase understanding of this functionality.
In this example, I see a 1-1 marking relation between a sales order line and a production order. To unmark this link, always start checking the box in ‘Set mark now’.
Then hit the “Apply” button and the marking will be gone.
To create manual marking, click that same ‘Set mark now’ checkbox.
The system will take the quantity of the line, but the user can change the quantity, if applicable to do a partial marking. Hitting “Apply” will set the marking again.
Because one of the roles of marking is to support actual costing, it is not possible to use manual marking when the item is on standard cost. This is understandable from a costing perspective – we are not gaining anything by marking standard cost items. But on the other hand, it is a little strange that we cannot use the logistic capability of marking once the item is on standard cost. At least we cannot set marking manually. The system uses its automatic marking for standard cost items just as abundantly as always. All the functionality that needs marking functions exactly the same for standard cost items, but only system-driven! For example: I still have my marking links between subcontracted PO’s and Prod BOM lines, between direct delivery PO lines and Sales order lines, etc. But when my item is on standard cost, I have to watch out. If I ever manually remove marking on any transaction, I will not be able to get it back manually. With any other cost type, this is no problem.
We at Sikich think this limitation is not necessary and it turned out to be a small code change (!) to allow manual marking for standard cost items also.
One warning: when I am manually marking, I have to know exactly what I am doing. I should have the two or more order numbers involved in the marking, position myself on one order, and find the one(s) I want to mark against in the list of candidates for marking. If I start on a sales order line, I could get a long list of potential supply candidates. And that is for two reasons:
- Anything that is a supply will show up in the marking screen.
- Posted transactions will also show up. From the costing perspective, marking is applied when I do a month end closing for items on FIFO or LIFO, and marking is very relevant for posted transactions. Inventory journals, posted or un-posted, will show up also. For the system this is logical. Journals represent inventory transactions. For logistical reasons, it makes no sense to mark against a journal. But it is possible.
When in the marking screen, it is also possible to let the system create marking automatically by clicking the “Auto” button.
IMPORTANT NOTE: Marking remains with the transaction permanently. Posted journals, ended production orders, shipped sales orders, will continue to show up in the list of candidates in the marking screen. This can get a little busy. If we use marking for logistical reasons, and that is what this article is about: we should reduce the manual marking to an absolute minimum.
Conclusion
Marking has a critical logistic function that MTO and ETO companies should use. It mimics “project manufacturing” without a project number. When using standard costing, system generated marking works the same but the user cannot manually mark anything. A small code change overcomes this hurdle.
I am wishing all Dynamics AX users great success!
