Re: Inventory Transactions - Correct On Hand Balances

[MacWheel99@xxxxxxx]

Dick_Bailey@MCFA.COM writes:

>   BPCS 6.1.01 -  Has anyone noticed that some Inventory transfer 
transactions 
> post to the receipts total in ILI and IWI and others post to adjustments?  
> Our Inventory Transaction effect files are set up to post to adjustments, 
but 
> sometimes receipts are posted instead. This might not matter, except that 
it 
> has a high correlation with errors in on-hand balances.  (My favorite 
subject)

BPCS 405 CD - We have noticed that after End Month, sometimes some 
transactions get posted with a date of the prior month & this updates the 
Opening Balance for the month AS IF the transaction had in fact been posted 
in the prior month.  Until we noticed this, we had always thought Opening 
Balance was a fixed amount, changed only be EOM & Physical Inventory.

JIT620 sometimes bounces off of someone else updating the same identical 
item# & sometimes by mistake someone responds with "R" Retry.
My speculation is that this is because people with PCs are so used to "R" 
retry meaning retry JUST the action that failed, like with a diskette for 
example.
But depending on where it bounced, the job stream could retry the whole 
thing, all the transactions in the batch, through all the programa.
Now when the labor is updated, there is some flag set to say "this software 
posted this labor" so do not do that again, but the inventory does not get 
that benefit, so we can have a large chunk of JIT620 inventory transactions 
double posted thanks to how easy it is to take "R" retry.

IBM error messages have a default response to be taken if the user just 
presses enter & that response is not always the best for the situation.  Some 
of use type-ahead but suppose there is an error we did not expect, that could 
now be populated by the type ahead?  I am just saying that it is incredibly 
easy to just press enter by mistake, not realizing these consequences, when 
there is an error message.

Fortunately responses to error messages in JOBQ are captured by DSPLOG, but 
interactive scenarios are lost when user takes ordinary sign off.

We have been looking at patterns of ITH to try to find unwanted transactions.
For example if it is the type of transaction that normally comes from JIT620 
but has no labor ticket #.  We have been assuming the request date means the 
date the shop order wanted it, and if that is blank/zero then that is a 
suspected unwanted transaction.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

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