Re: BOM's not showing any value after roll-up -- BPCS-L

Check list
---------------
BOM900 was run & had no errors.

Cost Buckets are coded to roll up to where you are looking for results (which
bucket puts its cost into next higher level ... e.g. labor & machine at one
level becomes material cost at a higher level).

Effectivity Dates are current (if the sub-components are not CURRENTLY
included in the higher level items, then their costs also should not be
included).

Facilities agree

Method Codes

Only one person at a time is doing cost roll-ups & that person waits until a
roll-up is completed before doing another (if you have multiple concurrent
runs, you can end up clearing fields you want rolled).

Previous discussion in the BPCS-L archives discussed risk of changing a part
that used to be one way to the other ... purchased vs. manufactured.

I just created a query/400
link CMF & IIM

from CMF list buckets that are material & we also have a secondary kind of
material, with this level cost, whose IIM is coded manufactured item types

also

from CMF list buckets that are machine or human labor costs, whose IIM is
coded purchased item type such as P & 7

Both queries got hits, thankfully not many.

The trick is to dream up what should not be, then create a report listing any
such thing in need of correction.

Query totals only - how many records by facility - showed us records on an
invalid facility.
Query totalled buckets other than cost bucket zero to a work file with what
cost bucket zero should be, then match that with cost bucket zero to list any
that do not add up right.
List any CMF with negative costs.

When we run CST600 it creates a report showing what costs changed.
In most cases the costs are the same, next most common scenario is a new item
with its first cost.
5-view spool F14 decimal point 120 120 enter F16 F16 F16 search for hits of
cost changed other than the standard scenarios & check out those items.
Some may be new items & engineering changes in the works, but we found some
errors & unexpected scenarios, like a dramatic increase in some raw material
pricing.

We cloned CST270 report to have a variant using a logical that ignores lines
of additional description, which has made this report much more readable.
We run this & leave on spool hold, for all shop orders coded closed, before
we do CST900.
Immediately before CST900, we run a query that creates a query work file with
a report on all shop orders coded for purge & what the actual & standard cost
is on those items.  After CST900, we have a query to compare costs on items
purged, using the work file, to see which costs have changed by a more
dramatic amount than seems normally expected.  We then spool-search our
modified CST270 to see the details on those shop orders.  Usually the cost
variance is in labor rates.  This way we check out only the most dramatic
cost change activity.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)