Forecasting Independent and Dependant Demand

[Kristin Miller]

Our supply chain department is looking to see a sum of independent and dependent demand from forecasting. We have items that are both sold individually and used to make a finished good, sold under a different item number. Currently, the system generates a forecast for each item number, but does not explode the forecast to the components that make up the end items. So for the item with two functions, we see the forecasted demand for selling it individually, but do not see the total forecast. The current forecast is used correctly in MPS and MRP, so I think that our supply chain department wants something different than what the system was designed for. Can anyone please verify/correct my thoughts or offer any solutions? I am using JDE World version 7.3c10.

Thanks,
Kristin

 

[Krofire.com]

We need to claify something here: are you selling your Sub-Assemblies under a different Part Number from that used on the Bills of Material for other Finished Goods? Your description was ambiguous... If your used the same part number for the same Item universally then you can enter a Forecast for any item at any level of the BoM. Then run P3482/P3483 and it just calculates all of your requirements.

If you already use the same part number universaly then I am not sure what the problem is... It sounds as if you wish to aggregate Forecast throughout the BoM. The trouble is that Dependent Demand doesn't generate a forecast - it generates F3412 Pegging records. You can write a program to reinterpret those records into the F3460 table but I fail to se the point of that as you can't then enter the data back into MRP/DRP as it would double up your demand. All you can use it for is for reporting....

...and if all you need is reporting then the MRP/DRP can already do all the work for you... But it doesn't write the F3460 for your sub-assemblies. I guess I am missing the Business Requirement here. Your Supply Chain Department is asking for something that seems nonsensical at first. All the Data is in the system - the F3413, F3412, F3411 - is it a question of interpretation? I have had Clients who have written extracts from these Tables in order to write a Forecast.

There are also such things as Planning BoM's that 'explode' Forecasts of Pseudo-Parents to Child Items. This should (I believe) use the FTRP in F3002 (Feature Planned Percent) and is exploded by P3482 when all the Processing Options are set. However, you may need to use Planning Code 4 and 5 with this. This is all in the book.

 

[Kristin Miller]

Thank you for your response. You have verified my thoughts that the department expects something different than the normal business function of forecasting. I understand that we do not want to explode the forecast to lower level items in JDE, as it would overcalcuate needed quantities in MPS/MRP.

We are not selling sub-assemblies. We purchase and then sell valves, which are also used in washer boxes. One valve can be used in several different boxes, so we use different item numbers for the valve and each of its washer boxes. I don't know that we can change the item setup to use planning bills. We are currently trying to get manufacturing and distribution planning working correctly, but will face obstacles as other departments do not want us changing setups that affect their modules.

Thank you for your help.

 

[Krofire.com]

I apologise for being a little dim but I am still little the wiser about your part numbering system. You say "One valve can be used in several different boxes, so we use different item numbers for the valve and each of its washer boxes."

Does this mean that you, say, buy Valve under Part Number "123" then, depending upon which Washer Box it goes into (Part Numbers "a", "b", "c" for example), your BoM has a Component Part Number "123a", "123b"...etc?

So Part Number "123" is exactly the same as "123a", "123b", etc?

You could use "123" as a Parent in Planning BoM with "123a", "123b" etc as Child items.. But you would still need a Forecast for "123" which, I guess, is the problem.