Bogus Location Transactions (was Erroneous Balances in ILI/IWI)

from Al Macintyre BPCS 405 CD Rel 2 OS/400 V4R3

Dick

You stated that IWI gets reset during EOM to agree with ILI records, even 
when there is bogus information in ILI.  Is this because the reorgs are part 
of your EOM steps, or is it a natural consequence of INV900 or some other EOM 
step, if you know?

Could you share the SSA fix identification # they working on & scenario if 
you have identified what causes this, because we discovered something weird 
happening on some transactions May 31 & probably will want to ask SSA for the 
same fix when they get it done.

Some individuals in facility 40 discovered that one batch of JIT600 
transactions for final assembly for what was to be shipped May 31 from 
warehouse-location 41-ES01 each got accompanying it a pair of bogus 
transactions (production & reject) for a shop order in facility 50 using 
combination of valid location 52 & invalid location ES01 (for that facility & 
warehouse).

Our warehouse number system is 1st character facility, 2nd character item 
type 1 in warehouse *1, work in process in warehouse *2, etc.  Our shipping 
location is *S01 where the * is a letter representing that facility.  We 
operate on a facility basis - inventory routings BOM costs MRP are all by 
facility.

52-ES01 is NOT in ILM file, but it is now in ILI.

We tried in our test environment to post to an invalid location & it would 
not let us, however our test environment does not have all the Y2K BMRs 
because I ran out of time to get both live & test get them both, so I plan to 
give my testers instructions what all to add to library list to be closer to 
our live version & I plan to look at JIT620 source to see if a Y2K fix did 
this.

This has also meant the creation of erroneous CIC cost records & we've done 
cost roll-up since it dawned on us this happened, so now we also have bogus 
CMF records. 

We do our final assembly pack transactions differently than other operations, 
because we want the inventory as accurate as it can be to serve shipping.  
For other operations we take the labor reporting as gospel & report labor & 
inventory at one time, but with final assembly final operation, we just enter 
the labor side, waiting on the packing for shipping to get confirmation of 
quantity that passed inspection, then report quantity no labor, using same 
employee # as was on labor transactions via SFC300 labor history to get the 
number.

The lady who showed me this told me that this phenomena only happened with 
facility 40 pack transactions - that other facilities had done random checks 
on their pack transactions (final work being inspected before shipment) & not 
found this.

But when I ran a query to identify what was in ILI for warehouse 52 that was 
not in ILM, I also found where one 21-LS01 pack transaction for facility 20 
got doubled into facility 50 in the same way.  So now facility 30 has been 
asked to check every one of their pack transactions for May 31 to see if they 
had some doubling.

We also plan to see if ILI has locations not in ILM irrespective of warehouse 
52.
We also plan to see if we got your scenario of ILI on-hand not adding up to 
IWI.

Facility 20 did 16 pack transactions June 1 morning & 10 of them got the same 
phenomena of 2 extraneous doubled transactions in facility 50 & 1 was tripled.

Does this sound anything like any of your scenarios?

Fortunately we still had our labor audit trails for the day (they usually get 
deleted without printing) so we were able to determine that people keyed 
transactions correctly, but for each of the problem transactions that we have 
identified so far, BPCS acted as if those were under lot control, so we have 
been digging into various files to see if we can find a field that says lot 
control & if the flag is in the wrong setting, so far without success.  We do 
not use lot control.

Needless to say, we are casting our net wider to see if there are any other 
bogus transactions & to alert other folks of the risk of bogus info in 
purchase planning & actual costs ... our end-month will be June-2 & I had 
been lobbying to have INV970 run, which we have not run in over a year, 
because there's a physical due end of fiscal June & we are drowning in zero 
ILI records.

Is there some ceiling on how many ILI records we can have that work right?

We do our annual physical a different month in each facility, with a special 
crew of experts on the process who travel to each facility to handle it & 
facility 50 got this service last month, so now I will be asking if there is 
a correlation between the items we have now found to be messed up & where we 
had heavy variances, although for most of the bogus transactions I have seen, 
those items would never be in that facility anyway, since they are end 
customer specific.

I ran SYS120 last nite because we had lucky 13 Meg of deleted records, but it 
has been a week since I did any other kind of reorg.

> Dick_Bailey@MCFA.COM writes:

> Why do we keep talking about doing re-orgs
>  to get the files in synch instead of fixing the causes? The one cause we
>  found this week generated at least 40% of the out-of-balance conditions I
>  found Monday night (by query), and with lots of help OGS has been searched
>  and an Incident Number has been established and we're looking for a fix 
from
>  SSA shortly.
>  
>   Our re-orgs over the past 6 months have locked in place incorrect
>  balances for at least 200 item numbers (found so far) and we have fixed 25
>  more that got generated during May.  Correcting those is going to take a 
lot
>  of work.

>   Problem Three is: The total of ILI on hand quantities 
>   does not equal the on hand in the IWI file. 

>   It is definitely true that the original Kit problem one generates 
>  some of these imbalances - during the month in which they occur. 

>  Then at the end of the month, IWI gets synchronized with ILI 
>   (to the incorrect ILI balance).  

>   However, this is only one source of this problem. 
>   I have seen many references here to having to run a 
>   synchronization program - and we have run it too, 
>   but, as the Kit situation proves, the result is wrong.  

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| 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
+---