I am having some mysterious changes being made to our standard costs on several component items.  Since (as far as I know) only the owner and I know how to use the 'Run Program' feature to access the Standard Costs update program, I do not believe that anyone is deliberately changing our standard costs.  Several of the changes were made when we were solely using Classic, and one has been since installing Evo.  However, I am the only user currently using Evo.  As such, I cannot pinpoint it as being either a Classic-only or Evo-only problem.  Worse, 2 happened when receiving a PO and 1 when making an adjustment so I don't know which program cause it or if there is a common subroutine between PO Receipts and Invty Adjustments that could be the culprit.
 
Look below at what I am seeing and see if anyone else is having these problems.  I would appreciate any advice anyone has to offer on what could possibly be causing these changes to our Standard Costs.
 
This first image is from March when we were only using Classic.  The Std Cost is mysteriously rounded to 2 decimal places on this Purchase Receipt and for all transactions going forward.  Don't know why--we generally only reset our Std Costs after year-end.  The BOM was not updated/re-rolled with this change which we normally do whenever a change to Std Cost occurs.

 
Below is an adjustment from March where the Std Cost was once again rounded to 2 decimal places for all transactions going forward.  Again, BOM was not updated so don't know how this could have happened.  Using Classic at the time

 
Below is another Purchase Receipt.  This time I was using Evo.  The Std Cost mysteriously went to zero.  By luck I found it, reversed the PO, fixed the Std Cost, and re-received the PO.  

 
Like most companies, I have hundreds of items.  While I used Inventory Listing to quickly scan thru and look for any more zero's (that's how I found the one above), I have no easy way of finding the rounding issues above. Too, with no warning of when this happens, my costs get screwed up and I don't find it until I begin looking for month-end discrepancies.  Some of the discrepancies are just pennies or fractions of pennies per finished item so they're easily ignored.  My bulk items may contain hundreds of components per finished item so the discrepancy ends up being several dollars per unit.  Multiply that by hundreds of units per month and my discrepancy can easily end up being thousands of dollars.  This makes me  !
 
Has anyone else out there experienced any mysterious changes to their standard costs like the one's I'm seeing above?
 
Chris

RCOST[13]  is where the Std Costs are stored, but in my examples above, I am showing the Std Costs that were actually used from the Inventory Transaction files at the time the transaction was posted so that you can see that the Std Cost was changed.
 
If I had not corrected the Std Costs, whenever I run my Closed Work Orders Costing report, the Std Costs being pulled (from RCOST[13] would be wrong compared to my Actual/Avg Costs.  This is where my discrepancy comes in.  My actual costs are showing higher than what I am earning against my Standards.  It makes it look like I am having increases in my actual costs when in fact I am not--my Standards are changing.

I can see how the standard cost would matter if you are finishing production at standard cost and not actual.  Your variance might seem high when it really wasn't.
 
The file you are looking at, Chris, is the INVTXN file?  When I look at my INVTXN file I notice a this:
Transaction types I and A for Lot controlled items -- The field MTIT.STDCST is always the STD COST * QTY.
 
Transaction types I and A for all other R, N, and A types (this is all I looked at) are MOSTLY STD COST.  Occasionally I see an I type with the STD COST* QTY in that field.  Not sure why.  
 
When the transaction type is "C" (cancelled??) the field is always 0.
 
Basically what I think is this field has little to do with what is in my standard cost field for a part.
 
Are you actually seeing the change in the standard cost for the part when you go to IN-A and look at the standard cost field?  I am not.

Bottom line is, you shouldn't be using that Standard Cost field in the INVTXN field for anything because it is clearly not consistently saved to by the program (and nothing I am aware of in the program uses it) and the true standard cost in MTICMSTR RCOST[13] should never change unless you do a rollup.