ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> System Manager >> SM-J-C Reconcile Inventory On Hand
http://www.istechforum.com/YaBB.pl?num=1077665159

Message started by geo@jps on 02/24/04 at 15:25:59

Title: SM-J-C Reconcile Inventory On Hand
Post by geo@jps on 02/24/04 at 15:25:59

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

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by aricon on 02/24/04 at 23:24:33

Depends on the volume of transactions.

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Karen Mason on 02/25/04 at 06:33:20

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?

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Lynn Pantic on 02/25/04 at 07:59:07

In theory, all the posting and order entry programs should correctly update the stock status and SM-J-C should never be necessary. Obviously, this is not the case.

If those of you that run it frequently and get long reports can identify which types of activity are not updating the inventory files fully, please let me know and we can fix them. What kinds of things dominate the reports?

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Tim Keating on 02/26/04 at 12:08:01

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?

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by David Waldmann on 02/27/04 at 05:58:52

Tim Keating wrote:

We run the report daily so that our Crystal reports are correct (or close to it).

You can also run IN-D to refresh stock status (don't need to actually print the report, just answer Yes at the begining when it asks to update stock status, then make your selection criteria and press <F10>).

Tim Keating wrote:

If the stock status could update everytime an entry is made, we would be very happy. Is this a possibility?

Ditto!!!

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Tim Keating on 02/27/04 at 09:02:57

Thanks for the suggestion, David.

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Bill Lee on 03/01/04 at 10:54:05

Lynn,

Thia is a real problem for us. Any thoughts on a fix?

Bill

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Lynn Pantic on 03/01/04 at 15:37:35

Lynn Pantic wrote:

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.

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by geo@jps on 03/02/04 at 08:46:51

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

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by geo@jps on 03/02/04 at 08:47:11

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Tim Keating on 03/02/04 at 09:24:16

Tim Keating wrote:

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.

If the stock status could update everytime an entry is made, we would be very happy. Is this a possibility?

I can't explain it any better than this.

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Steve_Carpenter on 08/11/04 at 13:09:27

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?

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by Lynn Pantic on 08/11/04 at 14:01:18

I would LIKE to see all the programs that affect the stock status of items update all the affected files but if it was working flawlessly, there would be no need for this thread. IN-D is a good fall-back solution but depending on the size of your files can take a few hours to rebuild all the status fields. As I mentioned earlier, any specific programs that can be identified that aren't properly updating the stock status can be fixed.

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by lgrover on 08/29/05 at 06:42:18

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)

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by callclay on 08/31/05 at 09:52:03

It appears that SO invoicing is NOT posting properly. We can see Qty on SO change in a flash as we click on the item screen. If we run export reports with the data in inventory, the numbers in On SO will be wrong unless the data is refreshed in DBA.

Title: Re: SM-J-C Reconcile Inventory On Hand
Post by timgolds on 12/15/05 at 14:08:02

We are also having the same problem! We have never woried about it before as we where not using they system fully. We were manually doing adjustments to inv because we were not suing WOs and we didn't have all our assem parts in. How that we do have everything in the system (at least 90%) we are really starting to watch our cost accounting.

As you can guess, This problem is causing us some major headaches! I just printed 15 pages from SM-J-C! Some of the stuff it want's to do isn't correct as we have parts that show the right amount in IN-A, but the transactions are off and the Serial for that part doesn't exist.

Please let us know anything you find out on this problem!

Right now I'm trying the IN-D with rebuild to see if it makes any difference.

FYI,

We get issues on BKICMSTR, MTICMSTR, BKICLOC and INVTRX the issues are with POs, SO's, WIP, Location, WO's, Allocations. Unfortunatly it says non of them will effect the GL. However, adding items to BKICMSTR Is going to throw my WIP and Raw material number off!