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.