Cost Bucket Zero -- BPCS-L

From Al Macintyre 405 CD

I just want to do a reality check that I correctly understand some 
implications, because I do believe we now have some items whose cost bucket 
zero does not add up correctly.

When we update buckets other than zero, via CST100 or any other standard BPCS 
program, that also updates bucket zero by the amount of the change to the 
other buckets - Am I correct about that?

There is no standard BPCS program that habitually recalculates cost bucket 
zero, as part of its normal operations, on the basis of the other buckets. - 
Am I correct about that?

If i wrote a reorg program to fix bucket zero, it would be reasonable to 
assume that the individual buckets have the correct information.  Am I right 
there?

Thanks to some other queries, I am also aware of
We have CMF & CIC records with facility missing (we function by facility) ... 
it is my intention to kill these records on the understanding that we should 
have no such animal;
We have some IIM items for which there is no CMF ... most of them have 
on-hand zero & no recent inventory activity;
We have a bunch of CIC item/facility combinations for which there is no 
corresponding CMF.

We run BOM900 regularly & in fact I ran it tonite after discovering this 
problme.  It always says we have no infinite loops & does not list any other 
problems.  If there was some problem with BOM low level codes, should BOM900 
audit trail tell us?  If not, how can we tell if we have such a problem?

I became suspicious that cost bucket zero might be corrupt thanks to a query 
listing any cost buckets with negative numbers ... it is my understanding 
that costs should never be negative ... inventory can be negative due to 
transaction float, but not costs ... so I went into CST100 to zero out the 
negative fields & discovered to my dismay that the individual buckets of 
several items whose cost bucket zero was negative - the individual buckets 
were all zero or positive numbers, so I speculated that if these few could 
get corrupted, how about costs on items with no negatives.

I determined the unpleasant truth about our costs via
a) query of all CMF records excluding bucket zero to work file totalled by 
item facility set
b) query of all CMF records cost bucket zero only matched with the work file 
& print list of mismatched level totals.
c) when I calculated the difference, they all were previous level costs on 
actual cost set one & look to me to be primarily sub-assemblies - I have not 
exhaustively analysed this yet since there are about 2,000 items involved

I have been reviewing some historical BPCS_L posts about potential problems 
with cost bucket zero
someone mentioned risk of duplicate records in CMF IIM ILI IWI
is there an easy way to check on that possibility & are there other files 
that should be checked?

Beyond the topic of fixing this mess is the topic of preventing it from 
happening again.
We run CST600 regularly but only on standard cost set 2
We run CST900 at least once a week on all shop orders.
The associated reports of both 600 & 900 are so monstrous (10s of thousands 
of pages) that we habitually delete them without trying to do any meaningful 
analysis)

I often review DSPLOG of system JOBQ summary to see what kinds of stuff had 
abnromal termination & how my peers coped, since there are sometines some bad 
choices.
I have observed from this review that several co-workers have run CST600 in 
middle of day & some of them multiple runs.
I asked them about this & got assurances that:
They all use the same JOBQ for this - no one does any of this on-line;
They know all the other people who are doing CST600 & they let each other 
know when they are doing so;
They fully understand that CST600 on a single item also updates costs on BOM 
components, so that if CST600 happened to be running on 2 different end items 
at the same time that shared some components, this would potentially corrupt 
all the costs involved in both runs;
Everyone knows to use BPCS programs exclusively to be updating BPCS files 
(not DFU or PC tools) except where MIS or tech support has specifically 
authorized some exception.

Have I missed any caution to give my co-workers?

I am also aware that BPCS uses field sizes that push IBM OS envelope
RPG/400 numeric field size ceiling is 30 digits with 9 decimal which BPCS 
habitually uses in clear violation of the rules for arithmetic operaitions 
near the beginning of Chapter 11 of RPG/400 Reference Manual, which I can 
quote if you are interested.

Basically, by multiplying fields without making the result field big enough, 
BPCS runs the risk of losing both high order & low order values.  I think 
that because most of our numbers do not populate the high order portions of 
BPCS fields we are generally losing the low order decimal places, which are 
critical to our costing & pricing.

I do not know if RPG/ILE has expanded the window & if SSA V8 has managed to 
stay inside the envelope or has the same systemic flaw.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---