We are having the issue of Inventory On Hand Disappearing- I can not pin point exactly when or what caused it - we ran SMJC on 8/30, we run Rebuild weekly.  But I do know that $70,000 worth of pumps just disappeared from the IN-A on Hand
Funny thing is that there is still a book value, so the system must recognize that there is or was inventory.  Ran IN-F Inventory value for previous dates (PO receipt dates) and value is zero even for a year ago.
Is there a way to find other parts that might have "Disappeared"  
and what do you recommend that I do to properly add the "lost" inventory back in

Hi Lynn -  
Do you have any explanation why SMJC would just zero out inventory.  There are a total of 10 parts that the inventory just disappeared - but still shows an on hand book value $$.  Four of these parts we deleted from BKICLOC altogether and I had to re-enter them
We will run SMJC again and hope that it will reverse the transaction.
 
But I am being pressured for a reason...why would the system zero out Inventory and why did it delete the part from BKILCOC?
Why do we have to run SMJC?  It is a very LONG process and we have to run it from home.  We do it monthly - what is the suggest frequency to run this program?
Are there other weekly or monthly maintenance programs that we should be doing?
Thanks
Debra

Actually, Book Value is updated automatically with all transactions and should stay in synch with inventory on-hand extended value.  See #3 under Accounting at http://www.istechsupport.com/faq.php
 
There was a bug with PO-A (old Evo version, not the new GUI version) wiping out BKICLOC records under certain circumstances but it was fixed a while back.  You might have that going on with the Aug 08 version you are on.  What is the modified date of T6POA.RUN that you have?

Did you loose the inventory after a Master or Transaction Level Recon?    
We ran SMJC on the Transaction Level
 I run it here occasionally, and always in report only mode first.  
We run SMJC monthly as part of our system maintenance.  In the past the report was 30 pages, now that we do it monthly it is about 15 pages.  I am still trying to find out if there is a monthly maintenance routine that ISTech recommends.
We ave found that running IN-L-S (Rebuild Stock Status) before SM-J-C seems to reduce the number of things that come up.  
We run IN-L-S every Monday.  We run IN-D every Monday and say yes to Rebuild Stk Status.  We also say yes to rebuild summarized cost during finished production and still have 15 pages.SM-J-C allows you to correct this.  
SMJC is what Incorrectly deleted the inventory of 4 parts.  It also removed these parts completely in BKICLOCActually, Book Value is updated automatically with all transactions and should stay in synch with inventory on-hand extended value.  
Book value being out of synch is what alerted us that there was a problem.  One part had $70K of inv value and we have the parts in house but Inv on hand was wiped out.  What is the modified date of T6POA.RUN that you have?  
File was created on 6/10/03 - last modified on 10/10/08

Hi Lynn
My problem is that inventory is zero
You still have not told me how or why SMJC would wipe out our inventory on 4 parts
and what should I do about it.

We run the transaction level every month end and always run type B.  I have found that while transactions seem to always be recorded the location quantity is not always updated.  We have had nothing showing up on the transaction level reconciliation for a long time, until the update last month.  
Somehow a bunch of part number quantities were zeroed out in BKICLOC when I changed the blank location to "STOCK", so when we ran the reconciliation type B the location quantity was changed back to the correct  quantity per the transactions.  

When I run SM-J-C in report mode and check what it wants to do, it seems that quick counts more often align with BKICLOC than with what the transactions would indicate. At least they have in the past. We have been increasing training and tightening procedures, so I'm hoping to see a general improvement in the quality of our data.

But what would cause the BKICMSTR record to disappear?  That is what concerns me
 
We run SMJC monthly as part of our maintenance.
Our IT person first preforms a backup, then runs the Fix Binary zeros program before she runs SMJC - the process takes anywhere from 4-8 hours (after work hours) and there is no way we want to run it twice a month.  
Our reports are sometimes over 30 pages of data to review.  We have ~3,000 DAILY transactions between all the modules...Perhaps our company has an extraordinary amount of daily transactions?  
I would like to know - Thanks

You write " somehow the part number had been changed during some access of the record"  Somehow?  What would cause the BKICMSTR record to disappear?  That is what concerns me.
As far as running SMJC in report only, then reviewing it...I would like to think the the data transactions add up to actual on hand inventory and running SMJC is the check and balance of the system.
Like I stated, it takes 4-8 hours to complete the process and is not something I would want to run twice a month.
 
I would also be interested to know how many combined daily transactions other companies have.
 
Our reports are sometimes over 30 pages of data to review.  We have ~3,000 DAILY transactions between all the modules...Perhaps our company has an extraordinary amount of daily transactions?  
Thank you for your input

 
(I posted this under ITEMS and realized I should have put it here as it all seems to be related.... I have been having issues ever since the update and some seem to be related to creating a new named location and getting rid of the blank location.)
 
I have some issues going on with my inventory transactions and the change of default location from blank to "STOCK".  I have been discussing some of them in another thread.  
This morning I decided to run a report only master and transaction level reconciliation.  
 
Master level has one "N" type part having 5 BKICLOC records. I checked the location file and sure enough there were 5 records, all with various UOH.  I went into IN-A to look at the part and then went back to BKICLOC, and now there is only one record.  Strange.
 
A number of parts have no BKICLOC record, it wants to create a record for location "STOCK        ".  Should all those spaces be at the end of the location?  Most of these are obsoleted parts, only one has some monthly consolidation transactions, the others do not have any transactions.  Can I just delete the ones with no transactions?
 
Transaction Level:  
  As expected the transaction level reconciliation wants to recreate new blank locations for parts I have that in most cases only have one J type transaction, STOCK is in every location field I can find.  Don't know what to do about these.  
  Another problem part was reconciled at the end of last month and is already off again.  The part says we are negative but we should have a bunch.  So far this month there has been one receipt and a few issues.  The last reconciliation done on 9-8-09 had BKICLOC at 24 but transaction total was 77- part was changed to 77. After that there was an issue of 2.  Now the BKICLOC UOH is -2.  Somewhere along the line the UOH was zeroed out.  The report mode verifies this and wants to change the UOH to 75.
 
But why is the UOH quantity being zeroed out?????

After I installed the latest update on 8/21, I created the new named location "STOCK" and merged (?) my old blank location with this new default location.  Then I copied my real company to a new test company.  Then I ran fix binary zeros, I assume on both companies' data.
So far my new test company looks great, has none of the problems that my real company has.  I have been running test transactions and can't get it to do anything but act normally.  
So between the 8/21 and 8/31 when we ran SMJ-C as part of our usual month end inventory, there was some transaction or record lock or something (!) that corrupted some records so that now we seem to have a permanent issue with some parts that zero out, or have phantom blank location transactions.  
If there is something I could check or try in my test company that might help figure out this mystery I would like to know about it.  

Your method is fine and THANKS for pointing us to PO-C as the culprit!!!!  We will get right on it!

update on this -- it was not a PO as I first suspectd.  That is I can't subsantiate that claim, and Lynn did not find anything either.  I can reproduce this zeroing out though when we are using WO-K-B.  If we change the BOM on one assembly and finish another related assembly (same prefix, lower suffix) a related part (same everything, same item number  except for the last digit) is zeroed out.  In some cases the BKICLOC record is deleted altogether.  
Now today I have a different case.  On the inventory exceptions report I have a part that is listed two times with the note: UOH total of locations is not the same as UOH total of inventory record.  Use reconcile inventory to correct.  The only transaction this part has had since September was to be on a BOM for an assembly that was converted from a sales order, and then the BOM was changed  with WO-K-B (this item was not changed, another was, there are only three items on this BOM).
 
I am convinced that there is something wrong with WO-K-B and would like to change back to the old version (current one is dated 6/22/09 and old one is dated 1/18/09).  Is there a problem with this?

Well that did not help.  
The first time I ran the sequence everything was fine.  The second time, and times thereafter, following this sequence the BKICLOC record was zeroed for the second part #:
 
For two assemblies with boxes, the first with box 2000005, the second with 2000001 (the order does not matter- the part that gets zeroed out is always in the first work order)
1) Convert SO to WO - SO-N, one of each eg 7013-14, 7013-15
2) Release work order- WO- B (rebuild stock status doesn't matter- this happens either way)
3) WO-K-B- for second work order- Delete the part number 2000001 from the bill.(Highlight the part number, <enter> advance to the item number field, and <delete component>, exit,exit.)
 
AT THIS POINT-- The BKICLOC record for 2000005 is missing!
 
WO-I - Finish production on the two work orders 7013-14 first.  Shortage report at the end says inventory is negative for 2000005.  When I look at BKICLOC again, the record has re-appeared and is -1.
 I have other items that are zeroing out but are not so easily traced.  This happens every time I run this sequence for assemblies containing these two item numbers except for the first time I run it after starting my computer and logging on Evo.
 
Good luck figuring this one out...
 
 
PS We use this sequence alot and that is how I noticed it.

Thank You Cathy!!!!!!!!!!!    
 
We have identified and fixed (patch to be released tomorrow Oct 23) this problem.  We are continuing to look to see if the same behavior exists elsewhere now that we know what to look for.  The problem we have fixed existed only for multiple line Sales Orders converted to Work Orders that had Type N (Non-Inventory) components on the BOM.  What made it extra tricky to find was that the inventory item that ultimately had the problem was a DIFFERENT component on the BOM.