Hello All,
 
We are finding that even by running this utility every week, we are having 5 or 6 pages of changes (we've been running Master and Transaction level NOT in report only mode).
 
Is it common to have this many changes over that short a period?
 
Thanks,
 
George

We also get many changes whenever we run SM-J-C (We run once or twice a month).  I am wondering why there are so many changes also.  What would cause so much to go wrong in inventory?

I checked one day's worth of transactions. On a relatively light day we had 204 inventory transactions of various types.  This triggered 22 lines on the SM-J-C master level reconciliation.
 
We run the report daily so that our Crystal reports are correct (or close to it).  This has been something we have just lived with and I always assumed it was the same for everyone who uses custom reports.
 
As an example, a P.O. is entered for 1.00 of Part #9900.  The data field BKICMSTR_PROD_UOO is not updated when this entry is made so any reports pulling this data are incorrect.  If an inquiry is made on this part in IN-A, the field will update before your eyes and be correct until another transaction is made.  Other actions that appear to update the stock status include running certain reports in DBA.
 
BKICMSTR, MTICMSTR and BKICLOC are three of the files most often affected.  Quantities for Units on WO, in WIP, on SO, on PO, Alloctd, etc... are affected on a daily basis.
 
I scan the report for anything that might affect GL Value or actually change OH quantity.  In four years this only happened once, when we blew it and someone did a transaction while the reconciliation was running.
 
If the stock status could update everytime an entry is made, we would be very happy.  Is this a possibility?
 

Thanks for the suggestion, David.

Quote from Lynn Pantic   on 02/25/04 at 07:59:07:

 
I need to know what to fix before I can fix it.  I know there has recently been a problem with PO-A setting the On PO Quantity.

Lynn,
 
In looking through the report from running SM-J-C last week (5 pages of changes after 1 week), there are a bunch of different Actions taken. The most common ones are:
 
BKICMSTR Units on PO changed to match open orders
MTICMSTR Units Allocted chgd to match open orders
MTICMSTR Units in WIP this locat chgd to match open orders
MTICMSTR Units in WIP chgd to match BKICLOC total
Units on PO this loca changed to match open orders
Units on this WO loca chgd to match open orders.
 
There are a handful of others, but these are the most common.
 
Thanks for any insight!
George

Hi all . . .
 
This thread is disturbing to us at FHC as we are starting to demand more accuracy from our inventory.  The answer may be to make a habit of checking reorder levels regularly -- e.g. for the purchasing manager to do IN-D every morning.
 
Elsewhere on this forum Lorne Rogers said that loss of synchronization may occur because of the "basic structure of how DBA was created. That is why there are so many utilities to try to sync data from one table(s) to another."  DBA may be designed so the tables that represent transactions directly (WORKORD, WOBOM, BKARINVL, INVTXN etc, etc.) are updated during those transactions and tables representing state (MTICMSTR, BKICMSTR BKICLOC) are synced later, in batch processes that occur when you are about to use a feature that requires synchronization.
 
Early PC database systems had limitations in the number of files that could remain open during a transaction because each open file is buffered using a chunk of scarce RAM.  There are also concurrency issues involved -- in systems that are unable to roll back a transaction in which one of the table updates has failed, it is safer to reduce the number of tables that are updated during a transaction.
 
A closer look at this thread tells us that IN-D can do the most frequently needed updates that George describes in a less involved way than SM-J-C (IN-D does not require a user lockout).  So anyone who keeps a close watch on reorder levels may well run IN-D several times a week and as a result would experience little of the confusion described above.
 
Lynn . . .  in your understanding of DBA does this make sense?

Help...was this issue ever resolved/fixed?  I ran UT-K-E (consolidate inventory locations) this past weekend and now NONE of our 'on purchase order' or 'in QC inspection' qty's appear on our inventory inquiry screen.  I have tried the IM-D function to recalculate stock status, and UT-K-I to fix binary zeros, but neither corrected our problem.  All of our open S/O, W/O, allocated & WIP qty's appear on the inquiry screen...it's just the qty's on order/in qc that seem to be missing.  But, when we click on the P.O.'s button below, the items DO show on order & in qc, they just don't appear on the opening item inquiry screen.
 
Also, our existing RFQ's still have the old inventory locations noted in the corresponding field, so when we convert to PO's they also show this old location.  Is there any way to globally change this info on all existing RFQ's?
 
HELP!
 
Lisa
Sr. Buyer/Planner & involuntary DBA maintenance tech (lol)