THE PHANTOM in Dynamics AX
Phantoms are a very common phenomenon. Maybe we should use the word ‘Phantom BOM’s' as this is more precise. The more complex equipment is, the higher the chance there will be phantoms. How to explain the need for phantom- BOM’s?
This is not hard. In the design process, there is a need to define certain sections of the equipment as it represents a function but we would never assemble them as such, because it is too deeply integrated with other pieces of the finished product or unit, for example a hydraulic system. The hydraulic system certainly represents a distinct functional segment in the design of equipment but will never be assembled in isolation. This is a perfect example of a phantom. The BOM that contains all the pieces required for the hydraulic system is a phantom-BOM. Now we have the ability to copy this phantom BOM to other finished products, which is one of the essential reasons to have phantom-BOM’s in the first place. APICS says the following
Phantom bills. Phantom bills are a coding and structuring technique used primarily for transient subassemblies. The phantom bill represents an item that may not exist physically but is treated as an accounting unit.
One can also say that the phantom-BOM represent “work in process”.
Phantoms are also often used to represent options for configurable products.
This phantom assembly can certainly be a multi-level BOM that contains phantoms on lower levels.
I have seen many of those, the record holder for now being a 6 level phantom assembly for some type of involved packaging.
Every ERP system has phantom functionality, or better formulated: functionality to support phantoms which is really the support of phantom BOMs’ .The decision that something should be a phantom is often an obvious decision by a design engineer but sometimes it is a later decision made by the manufacturing engineer.
All ERP systems handle phantoms the same. The two areas at play are MRP and costing. MRP is simply not creating any planned production orders for phantoms but explodes through them taking only lead time and quantity into account. Costing similarly blows through the phantom, taking only quantity into account.
In the overview below I want to point out a few details that are specific to Dynamics AX and how it handles phantoms.
Let’s first find the checkbox “phantom” in Dynamics AX:
- The visibility of planned orders for a phantom is an interesting topic. Before 2012, planned orders for phantoms simply did not exist. They showed up in the MRP explosion tree as (dynamic), indicating it is not really an order, just showing itself for the complete explosion picture.
In 2009 and earlier versions, the user cannot get access to this phantom planned production order, there is in fact no order. Yet in AX 2012, there is planned order with a checkbox “directly derived” checked but no obvious other signs that this is not a planned order one should be concerned with.
Upon trying to firm, an error message shows, see below.
I would call this a slight regression in functionality and hope we will return to the invisibility of these phantom planned orders in the future.
2. Building a phantom to inventory is no problem in DAX. Although there is a checkbox “Phantom” on the item, this only serves to trigger the default phantom line type when the item ends up in a BOM line. I can create inventory for phantoms and I have seen companies doing just that. It could be this assembly is a phantom in certain types of equipment but an exchangeable unit in others. Or it is a spare part. However unlikely this seems, I have seen more then one case of this. Dynamics AX will allow it all, but we had better know how we would consume any phantom inventory we created because MRP will never see it. We would consume the phantom if we change the line type in our Prod-BOM before we do “estimate”, as a special case. Mostly the consumption would take place through sales orders, service orders or journals where we simply put the phantom part number in the transaction and the system will consume it without a problem.
3. Phantoms and routings. If I use phantoms, I really should put the labor associated with this assembly in the routing of the higher level item. But If I build this phantom separately sometimes, I may have to put a routing on it. What happens then? Let’s discuss costing first. The routing on the phantom is included in costing. If I estimate a production order, the phantom - routing is copied to the parent item routing and added as the first operations. This is exactly correct. The Production order suddenly has a bigger routing so the scheduling will result in different scheduled dates then this order had during the MRP-run. In the big picture this should not make a difference.
4. Linking BOM lines to operations when the phantom has no routing. Here we venture into a problematic area where I have seen customization necessary. If I have linked items below a phantom to the routing of the higher level assembly, these links are not preserved when the phantom disappears. They all get operation 10.
If I don’t have a routing for my phantom and I would like to link the items below the phantom to different operations of the higher level routing, I can’t really do that in the Phantom-BOM itself. I have to wait until the phantom is gone, and I could do it in the Prod-BOM when I am past ‘estimate’, but this is not very practical. When typing in operation numbers on BOM-lines, the system does not check whether these operation numbers actually exist. This is actually good news. It makes a customization possible. It turned out to be an easy customization to preserve the operation numbers on the BOM lines below the phantom, so after the estimate status I end up with the parts below the phantom nicely lined up with the operation they belong to.
5.Linking BOM lines to operations when the phantom has a routing . If I have linked items in the Phantom-BOM to these operations of the phantom-routing, the standard system has no problem. Because the operation numbers of the phantom routing do not change during the “merge” with the higher level routing, the links of the items with the operations will remain intact.
6. Work center consumption and phantoms. There is one other thing that was a problem in 2009. Since “Work center consumption” was introduced as an option in the BOM-line, planned orders for items below the phantom could not find their warehouse when the phantom had no routing. The logic was looking for a routing on the phantom. If that routing was missing, which is often the case, no warehouse on the production unit (2009) was found. A hot fix was needed for this.
The same fix was later applied to the “Max report as finished” where the same problem occurred when we exploded all the BOM levels; the system could not find the warehouses for the BOM lines below a phantom. In 2012 this problem has not occurred.
7. Purchased phantoms. A few times I have been asked if Dynamics could handle a “purchasing phantom”. To this day I honestly do not know what that possibly could be. It is not a question that can be asked and we attributed this slip-of-tongue to a Monday morning sickness of the person asking.
8. Phantoms and Lean manufacturing. Is there any relation between the two? We can say two things. Lean Manufacturing favors flat BOM’s but when it comes down to actual transactions, just like in traditional discrete manufacturing, introducing phantoms reduces the number of production orders we have to deal with. We have to do a lot less transactions. One could call the phantom an excellent concept to support lean manufacturing. Now we get to a tougher truth. In DAX 2009, a manufacturing Kanban was simply a quickly processed production order that went from create to report a finished in one click. If the PROD-BOM contained phantoms, they were removed during estimate and everything worked fine. In 2012 Lean manufacturing however, the manufacturing Kanban is not a fast version of a production order anymore. There is no status of the manufacturing Kanban where phantoms would be removed! So we are facing a challenge and are forced to remove phantoms out of the BOM of the product we are going to manufacturing using ‘Process Kanbans’. I believe we should not have a problem with phantoms in the Process Kanbans.