ITH Population from JIT620 -- BPCS-L

We on 405 CD
We typically have 4 people concurrently keying labor tickets via JIT600, and 
recently have been getting them to do their JIT620 via single threaded same 
JOBQ to cut down on the volume of collisions.

ITH has a Request Date.
We have been assuming that this date comes from shop order & is the date that 
the material was needed.
Some of our CI transactions have this field as being blank or zero.
We have been assuming that this means the shop order had no need whatsoever 
for the material, and the transaction was probably issued in error & need to 
be backed out.
Have we been asuming correctly?

ITH has a labor ticket number on CI PR RJ transactions from JIT620
FLT has a labor ticket number on labor ticket history
JIT6 audit trails show labor ticket number associated with input
We have been assuming that SFC600 assigns labor ticket number to the 
transactions generated from screen-1 of some input through any data on 
subsequent screens, so that a particular labor ticket number goes on all 
output to ITH & FLT for all the issues against production & rejects, the 
production, crew personnel, everything associated with that labor input until 
next screen-1 starts.

We have found some CI PR transactions in ITH with no labor ticket #
We have been assuming those transactions got there through INV500 instead of 
JIT620

We have found some ITH transactions in which the same labor ticket # shows up 
on several different shop order #s  These also are blank or zero in request 
date.

Latest example - labor ticket # 388617 has 24 ITH items involving 5 different 
shop order #s.  The warehouse involved is identical.  It looks like from the 
times of update close to 5 pm that it was all in one & the same JIT620 batch.

We have been assuming this is evidence of some kind of crash, like JIT620 
getting hung & someone responding with "Retry" which can retry a string of 
programs for all the transactions there.

There is one other circumstance that can "legitimately" cause something like 
this.
Suppose labor is reported against some shop order in which there is say 250 
quantity left to go until the order is finished, but the reported labot is 
2,000 production.  JIT620 will try to spread the quantities around to post 
against other shop orders on the same item, so you can end up with users 
posting data against one shop order & BPCS transferring the work to other 
shop orders, with no audit trail to let you know this is going on.

Are we missing any nuances in playing detective with these clues?

We have been having some incidents in which two people doing JIT620 at same 
time & they collide, like SFC735 needs to update some record & the error 
message does not identify where the lock conflict exactly is, then some 
helper takes "Retry" option instead of "Go On" & it Retries far too many 
transactions leading to duplicate bogus unwanted inventory transactions.  
When this happens, there is supposed to be various people notification so 
that corrections can be made, but sometimes notification falls through the 
cracks of interruptions & forgetting who needs to know,

This might not be the only mishap we are having that is causing problems.

We would like to figure out what is the normal population of ITH for CI PR 
etc. transactions, so that if we run a query listing CI PR etc. transactions 
that are an exception to the normal population, that identifies for us what 
needs repairs to our inventory accuracy.

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