Re: Costing Question (Confusion) -- BPCS-L

Because of many co-workers intermittent confusion looking at summary totals
of costs on CST300 and other BPCS info sources, especially questioning why
INV300 cost disagrees with some other place cost, we created a Query/400
... people key in Item # and they get a screen display listing ALL CMF
records on that item.  The header above buckets, sets, etc. annotated as to
most common meanings.  Query let's them select to exclude on facility etc.
for those people not confused.

Adjacent menu option does same thing for CIC.

This helps us find Hidden Costs.
Definition ... BPCS is doing what it supposed to do, but something has
fallen out of our brain as to where BPCS is getting this cost from.  We
have mass of data, but you gotta know right search question query to get at
the data you need.

The most common areas of confusion for our people include (you may be in
one of these boats):
Cost in some facility where a body did not expect in that facility for that
item.
If a human being makes a mistake, BPCS has a memory like an Elephant, and
will use that mistake in all calculations until some human being stumbles
over and fixes that mistake.
Actual costs do not work the same way as Standard costs.
You have to look at the roll-up pattern on the Costing Menu ... for example
a sub-component may be mainly a labor cost, but at a higher level it shows
up as a material cost.
It may pay to print one copy each cost report available on same item ...
many contain data not found on the others.

To err is human, but BPCS also makes mistakes.
There are some systemic bugs in how BPCS does its number crunching, which
includes CST600 and CST270 and CST900.  The worst one, in my opinion, is
that in RPG there is a maximum field size of 30 numerical, 9 decimal and
BPCS populates a bunch of fields defined at that size then multiplies and
divides them with work field of same size.  Now in RPG manual from IBM it
clearly spells out that this can lead to unpredictable results.

For example ... multiply zero times one and you could get any of the
following results
zero, 0.00001, 0.000001 minus, other possibilities
This is because when the math is going on, IBM needs an extra space larger
than the field sizes to handle some number crunching, and when values
thrown out there into non-existing limbo, something can get lost or found.

We first figured this out because of a rounding error in Billing, and
traced the problem to unit of measure conversion where it should have
multiplied 1 times 1 equals 1 but instead generated one of these 0.0001
additions.

I have a fix it program that totals up what bucket zero SHOULD BE and
compares to what bucket zero ACTUALLY IS then fixes those that are off (an
accumulation of those 0.00001 plus or minus rounding errors)

On rare occasion we have had this rounding error give us a cost value of
something like 9999999999999999999999999.99998 (could be positive or
negative) which I interpret as the 0.00001 plus minus errors wrapping round
from zero to largest possible number for the field

I run a regular query listing all items with negative costs.  We get
perhaps one a month.
They come from the systemic rounding problem in shop order closing.  I fix
them with DFU.

Hi,
     We found it. This item has a previous level labor cost. The labor cost
on the screen is the total of TL & PL, so didn't catch it until I looked at
CMF. Thanks for the help.

<===================================================>

Terri Harteau
****************
"There's no point in being grown up if you can't be childish sometimes."
- Dr. Who
****************

Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

-
Al Macintyre (macwheel99@sigecom.net via Eudora)
Al's diary http://radio.weblogs.com/0107846/
Cure cancer. http://members.ud.com/about/