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.