Let’s use a simple version of the Cronus bike as an example, where the bike is 1 frame and 2 wheels, and the wheel is an item with a Production BOM of 1 rim and 10 spokes, and the wheel component in the bike production BOM is defined as the production BOM for the wheel, not the item, so basically a phantom BOM. When a production order for the bike is refreshed, standard NAV will put all needed components (including the components of the wheel) on the production order component list.
Now here’s where it gets tricky. Wheels are also in the system as an Item, and are also sometimes made to stock. So now there’s this requirement that the refresh needs to take existing stock into consideration. So let’s say we have a production order for 5 bikes, and we have 4 wheels in stock. Instead of having all components for the 10 wheels on the component list, the customer wants to take those completed wheels out of inventory and consume them on the production order, and only produce the remaining 6 wheels. The consultant on the case then said “that is an easy fix, we will simply put the 4 wheel items on the production order component list, and the parts for the other 6, and that will be it”. I am starting to think it is not that easy at all.
First of all, the refresh is not a straight process down the levels of the BOM, it just puts all the components in there and then refreshes the quantities from the order line, and applies the order quantity to the quantity per on the components to come up with expected quantities. I can’t seem to find the moment where I can keep track of the components in stock and the components to produce, so I can bypass the “explosion” down the BOM levels. The whole thing is very illogical to me anyway, in standard NAV it sets the expected quantity when it validates the Scrap % field!!
Then later on in the process, when the production is posted it seems that NAV always applies all components to all produced items, so for each 1 of our 10 produced items, it will always use 1/10th of each component when consuming the components. In other words, it doesn’t allocate the 4 wheel items to the first 2 bikes, and produces 6 for the remaining items. Every component is spread evenly across the output quantity on the order line, there doesn’t seem to be any proportional allocation of components. So with automatic consumption posting you’re going to have the problem that it will just run down the component list and apply the quantity per times the output quantity. With consumption calculation, you’re going to see the same thing. So either way, I just don’t see an easy way out of this, and I could use some help. NAV just doesn’t seem to work like that, and I don’t really want to completely redesign the system.
My question is if anyone here has done something like that. A good challenge for the manufacturing experts here I hope, so please let me know your ideas, I’m all out of them.