Re: Inventory Record Inaccuracies

[MacWheel99@xxxxxxx]

from Al Macintyre 405 CD

as usual, a collection of clues & ideas that may or may not be helpful

so first we eliminate the obvious knee jerk thoughts

Yes, we know all about using reorg to "fix" some data & "hide" other problems.

Yes, we know that when some event drives inventory negative or zero, that 
causes the system to ask for a cycle count, and depending on how cycle count 
data is entered, it may or may not create an ITH record, and humans have been 
known to make data entry errors, and the rate of error correcting errors is 
greater than rate of error with just regular activity.

Yes, we know that when data is being viewed by a sign-on that has some 
security constraints, that sign-on might not neccessarily see the whole 
picture & be oblivious to what is missing.

Yes, we understand security risks in 405 CD of letting co-workers into 
command line to use DFU SQL PC-tools & other oops ... Central Industries may 
see no problem with that risk, but it is not a factor at MCFA.  Central is 
also a bit sloppy on security detail ... a lot of people are authorized to 
run 100% of INV or other category, without serious thinking about what EOM or 
reorg functions they should be blocked from, so sometimes in the middle of 
the month an ordinary clerk runs some EOY job by accident, and is too 
embarrased to own up to this oops.

Yes, we may have added some of our own logicals, but we are very careful to 
verify data base links & it just is not possible that there is a logical 
pointing at physical data in the test library that should be pointing at the 
live one or vica versa.

Yes, we understand that the ITH data is in there based on when the 
transactions were really keyed in, not when the activity was really done, and 
some users may report using a date other than the date when they really 
entered the data.  Now when INV900 gets rid of the oldest records, those that 
were entered with an artificially old date might get removed faster than 
those with a more contemporary or futuristic date.  Thus, depending on what 
BPCS or non-BPCS tool we use to look at history of transactions, we can see 
different stories.

So beyond knee jerk about how BPCS works or not works & the many 
opportunities to misuse security to some additional clues about interpreting 
the data.

At Central, we have had some strange things happen that we were unable to 
resolve until we recognized assumptions that we were making about the 
veracity of data on screens & how BPCS "works."

We had a location that someone deleted when it still had inventory in it.  
This inventory showed up in the IWI total, but not on any obvious BPCS 
screens listing what was in ILI.

We had a modification to add records to ITH that was not sufficiently 
thoroughly tested & my programmer perfection had a serious blemish ... bottom 
line the transactions were going into ITH but not showing up on the INV300 
history screen ... Ok that has been fixed.

We run various things off the reorg menu approx once a week & they have to be 
run in a particular sequence & we have not yet created a CL to enforce the 
sequence.  Do you have a similar policy & is it possible that steps went in 
the wrong sequence?

For example, I am very careful to run related tasks from the same session 
because I use different JOBQ & priorities from different sessions & if JOBQ 
got backed up and I was running related tasks from different sessions, I am 
well aware of the risks.  Many of my co-workers are not wise to this kind of 
nuance.

Al Macintyre  ©¿©

>  From:    Dick_Bailey@MCFA.COM (Bailey, Dick)
>  
>   Sometime between 8AM Wednesday and 8AM Friday, the IWI record for
>  one of our prime products miraculously acquired an Issue quantity of
>  negative one, so the on hand quantity went from zero to one. NO inventory
>  transactions took place. ILI records show nothing on hand.
>  
>   This is not the first time that prime product records have had this
>  happen.
>  
>   Anyone have a clue how this happens?
>  
>   Dick Bailey
>   MCFA


+---
| 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
+---