We have multi-level BOMs that we need to review demand quantities for based on lower level parts.
Example:
PartA (top level which sales orders are created against) contains a sub-assembly called PartB. PartB might contain another assembly PartC.
We may also have another part of a different number containing some of the same lower level parts.
PartZ (top level which sales orders are created against) contains a sub-assembly we’ll call PartY. PartY might contain another assembly PartC.
When I look at the demand for PartC in Epicor it shows 0 or whatever value is in WIP because there are no orders against PartC but there are orders for PartA and PartZ which both contain PartC.
What’s the best way to handle this BAQ logic to determine how many open order quantities are out there for PartC?
Are there jobs created at the point you’re wanting to look at demand? There are two ways I would look at this:
Use MRP to create unfirm jobs so that demand for each subassembly and raw material is generated. This lets Epicor do all the hard work and all you have to do is review demand for each part.
Build a recursive BAQ that iterates through each level of each part’s BOM to explode out the full multi-level BOM for the parent part you’re looking at. From there, you can multiply the order quantity by the total qty/parent for each subassembly and raw material to see total demand at each level.
If you mean that you do have jobs created but can’t see demand for parts that are subassemblies on these jobs, you should be able to use the JobAsmbl table to view each assembly level on jobs to see total quantity of parts needed at each level as well as total parts already made.
We let MRP create all of the unfirm jobs and use those to see demand volume. We don’t have our scheduling parameters nailed down 100% so there is some movement in time for which components go to which jobs/orders, but overall the quantities are accurate and we can use them to drive planning.
As others have already mentioned… using MRP can help.
Also, if your component parts built to stock (instead of Non-Stock)
then in addition to MRP I might look at the “Pegging” process too.
PartA and PartZ are being updated with new products PartA2.0 and PartZ2.0 launching soon. PartC is NOT in PartA2.0 and PartZ2.0, but is expensive and needs to deplete before we implement PartA2.0 and PartZ2.0. So we need to know when we will run out PartC to prompt the launch of PartA2.0 and PartZ2.0
@MRomeo If there are jobs made that are using Part C the timephase should show when you go negative and should move to the 2.0s.
If there are jobs all of the data for all demands and supply are in PartDtl. This thread has a query using partition over that should also show you where the running sum goes negative.