Just wanted to share with everyone what I had found about doing point-in-time inventory reports, accessing the data itself, rather than using EVO/DBA functionality.
 
Disclaimer:  the following seems to be true and consistent with what I have found for our data.  It is possible that there might be some subtle nuances that I might have missed, or just not encountered.
 
To arrive at quantities, as of a certain date, likely month-end, but not exclusively:
 
Simply sum up the quantities in the INVTXN table, for the item and location, first multiplying the quantities by the following multiplier, based on transaction type:
 
Transaction types:  A, P, T, W                    Multiplier:  1
Transaction types:  C, G, J, O, Q                Multiplier:  0
Transaction types:  I, S                             Multipler:  -1
 
This will cause the first values to be added at "face value", the second types to be ignored, and the third types to have their quantities summed with the sign flipped.
 
So, if you select INVTXN records from "the beginning of time", in your world, through any desired date, multiplying quantities by the above schedule, the sum of that will be the inventory quantity at that time.
 
You can then take that value and multiply by your current standard cost (or whatever you use) to roughly estimate the value of that inventory.  The caveat being that your current costs may not be, now, exactly the same as they were at the time.
 
The only other thing to do is to only include the following prod types:  A, F, and R.  I believe those are the only prod types that get their quantities written to BKICLOC, which holds your units on hand, by item, by location.  Prod type is looked up, by item, in BKICMSTR.
 
Hope this is helpful if you find yourself needing to roll back time to extract data or create reports.
 
Detlef Galbreath
Systems/Financial Analyst
Geophysical Research Company
 

One more...  Type "M" transaction reduces inventory so it needs to be treated the same as I & S

An "M" product type is a Make-From and should be included in on-hand counts.  The "M" transaction type is the consumption of a component of a Make-From during the PO Receiving process so it is something like a material issue.  If you don't have M product types, you won't have M transactions either.  They go together.