Multi-level BOM Open Order Quantity BAQ Logic

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?

1 Like

Melissa, it will be interesting what responses you get to this question.

I imagine some of the first responses will be something like, “what are you trying to do and why are you trying to do it this way?”

I am still learning every year I am at this and I can’t wait to learn more from this post.

Melissa,

Are there jobs created at the point you’re wanting to look at demand? There are two ways I would look at this:

  1. 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.
  2. 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.

3 Likes

@MDRussello this is what I was referring to. There are different ways to do what you are trying to do and to do it by leveraging Epicor’s power!

OR you could make a custom tool like Tyler documented in his second option.

What I was hoping to learn from this post is how the rest of the community does this…

@tsmith which of those options do you use or do you use them both?

1 Like

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.

2 Likes

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.

1 Like

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

THANK YOU :pray: this helps.

@MDRussello 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.

2 Likes