The innovation in AX 2012 to add forecast consumption by "any transaction" was very important. It closed the gap for the Assembly to Order business scenarios.
These scenarios require forecasting on a level below a configured end product. The forecast is maintained on major subassemblies that represent product options.
The item allocation key is the other piece of the solution, It represents the product line and we can indicate , with percentages, our expected breakdown in the configuration options we are hoping to sell. This mechanism creates forecasts on the option level using a total forecast on a product line level. In summary:
- we can forecast on second level
- we can consume forecast on second level.
But one detail creates a problem in this scenario. These major assemblies that are being forecasted with a percentage (the base unit gets 100%) are often a phantom BOM. Companies do that to keep engineering revision control out of the configurator model as much as possible. If the configurations themselves do not change from the customer perspective, but engineering improvements take place leading to BOM changes and routing changes, we can handle that below the phantom level. The configurator model calls up the phantom item, which is not changing. This is a common choice for ATO companies.
In AX the part numbers in the item allocation key with their percentages would be phantoms. All works fine as long as my planned production order for my configured end product is still planned. The dependent demand created by this planned prod order consumes the forecast on these major assemblies , represented by phantom part numbers. The forecast is consumed as expected. But as soon as I firm my planned prod order for my configured end item, the phantom part numbers disappear from the resulting Prod-BOM and my forecast consumption is instantly reversed.
We need to find a way to have this forecast consumption NOT be reversed but stay in place. We want the logic to be a little different. In order to determine the forecast consumption quantity, the code should always look up one level in the BOM structure and determine how many sales orders were booked for the parent of the phantom item. It should not count on always getting dependent demand for itself because it will have that only temporarily, being a phantom.
This is our suggestion to accommodate a common scenario for Assembly to Order companies.
Comments
I do understand the need for a better forecasting for configurable products, Ideally on option/attribute levels.
As it is today, Item allocation keys should typically be used to define a set of representative configurations and use the distribution factor to define the forecast distribution between these typical configurations. Writing off the resulting forecast on component level is of course a requirement, as these "Typical configurations" are not the ones that will occur in reality.
Not sure if the forecasting on Phantom levels it the right solution and with the current architecture, it is basically impossible to implement this. Basically I fail to see how a write off of a phantom can be implemented, if that phantom is basically never "delivered". As Evert correctly observes, the phantoms disappear when estimating the production order, so I have nothing to write of in the first place. Also consider, if the second level may not be a static phantom but also a configurable component, the approach of forecasting on that gets us back to square one.
In my mind, this would also require a much stricter and more narrow definition of phantoms that we have it today (where a phantom can be merged and distributed over multiple operations.... ), that would allow to assign a phantom to a specific operation and with that trigger some kind of consumption/write off message.
I really would prefer having a backlog item, that describes the problem, not a possible solution, so maybe we can agree on using this product idea to represent the need to improve forecasting for configuration models, no matter if it will use the phantom approach or not - how does that sound?
Category: Planning
Agreed.There are scenarios in the first-level sub-assemblies that need to be assembled together - parts from sub-assembly option A need to be mated to parts from sub-assembly option B. These cases only make sense if phantoming the parts together onto an upper-level BOM. Forcing these to be transacted into inventory to make forecasting work does not reflect how the parts are actually handled in manufacturing.
Category: Planning
This is very important for the high tech industry and any company that has highly configured products. This fix will allow forecasting of a product family with option percentages, and then manage that forecast by allowing incoming sales orders to consume the forecast (i.e. replace the forecast with actual demand). The use of phantoms allows for a better way to manage bills of materials placing components needed for the configured assembly to be grouped by product options and then allowing bom explosion to derive the final set of components needed on a production order.
Category: Planning
Administrator on 5/28/2019 12:19:05 PM
Thank you for your feedback.
Currently this is not in our roadmap; however, we are tracking it and if we get more feedback and votes, we may consider it in the future.
Sincerely,
Christian Rytt
PM,
Microsoft.