"Build Estimates" calculations discrepancies

I’m trying to use this page (…/part/176/what_if?) to determine how long it will take (based on current inventory and order lead times) before I can finish building/stocking parts. Using this page, it shows that i have enough Quantity on hand to build 12 units. If my goal is to build 200, I’d have to order some parts, in this case, speciifcally RAW000006. The lead time states that its 28 days to receive the parts, so I’m wondering why the QTY 200 work finish date would be 10-05-2020. Why is this?

Also, In the build labor plan, I mention the amount of time to build 1 piece. Shouldn’t this value be put into the “Build time” column?

Hi Regis!

The Build Time Column is to calculate how long it would take to build that component (if that component is a subassembly).
If I had a subassembly that took days to build (and, it’s build default was set to build), then it would show the days needed to build the number of subassemblies needed to build the top level component there.
That column shows nothing for components.

I’m not sure if this is a bug, or configuration quite yet.
I’ll ask Engineering to look at the case regarding the Start Date not accounting for the Lead Time of 28 for RAW000006.

@regisphilbin

The parts (components) that you have pictured here are actually BOMs themselves with no components.
Because of this, the first Note down at the bottom applies:

If a BOM has a build default of Skip Build (and honor build defaults is checked), Lead Time will be used instead of Build Time for that Part to calculate Start Date.

The way to fix this is to go into each of those parts.
Then on the left side menu:
Go to build defaults
image

Change the build default to be Skip Build:

image

You’ll need to do that for all of the components that you wish to be BOMs, but have no components of their own.
General operation would be to have components of a BOM that aren’t BOMs themselves, OR, to put components within those BOMs & use the buildtime/leadtime of the sub-subcomponents.

Thanks!

1 Like

That worked! Just FYI, we like Parts/Items to be BOM’s (even if they really aren’t) because then you can manage part revisions in ECO’s if needed.

Excellent!
BOMs historically have had better feature connections. We are making connections to regular parts in some cases, but I think ECO’s will remain exclusively a BOM function for a little while still (so keep using the above method).