msf667 and msf620 appear to not be linkable/joinable.  Apparently this holds true for any tables that are not inclusive of any modules.  For example module 3620 is where table msf620 resides.  Module 3660 is where table msf667 resides.  The virtual table constructs via the system administrator you mentioned are what I initially thought would be required but was hoping to avoid that per the potential upgrade conflicts with Knowledge Library modifications/customizations.

We have pursued msf668 but also require to report the associated committments msf666 or msf665.  Just tried to use both msf668 and msf665 or msf666 and that join also failed even though the tables are withing the same module 3660.  Do you have join problems like this?

Also I am attempting to collect detail costs so need to get the account code which I cannot find in the 3660 tables but do find it in the 3620.  Looks like some major trade offs as to what end users will be able to do versus what the MIS folks (our system administrator(s)) will have to maintain.

Thanks    

1. we do most of our report development in RDL and use Corvu mostly as an ad-hoc querying tool, due to our perceived problems with CorVu's knowledge library.  
2. I believe you will need to add msf620 into the KL database for 3660 in order to attempt to link to it.
3. Joins are based on primary key structure and you need to have a clear understanding of those to realise what can and waht cannot be joined. We use the Mincom data dictionary, entitity relationship diagrams and reference manuals for this purpose. The Corvu KL is insuficient and it is risky to do Corvu development without a clear undestanding of MIMS.

In this instance it is obvious by looking at the record keys that MSF668 will not link to MSF665 or MSF666.

The fact that tables reside in the same module database does not mean that CorVu will link them. Corvu joins implicitely based on field names and the risk is there that tables are incorrectly joined. Use SQL preview in order to check on the correctness of joins.

We prefer RDL where we explicitly code the joins, also Access or SQL. Corvu's idea was to simplify the process, but this becomes more of a pain in some cases.   

What you can do when tables do not join, is  to write separate queries on each table, then JOIN or APPEND the resulting dynamarts, but you need a clear understanding of the tables design and what data is there, so that what you join makes sense. You may summarise or filter records from one of the tables before joining to records from another table. The process may go on on many levels so that you build a composite query out of many blocks (individual queries)

4.detailed costs: It would be inappropriate to use the msf620 account code as the reference for an aggregate cost from msf668. The msf620 account could be where all or most of the costs for a work order are collected, however it is common practice that some costs from the same work order are re-allocated against several accounts (there is a cost re-allocation action code from w/o screens).

What wou need to do in a drill-down scenario is to go to the msf900 transaction level. My advice is to try follow on the logic of MIMS screens where by using action codes you drill down from a period cost to individual transactions; you can read the CBL code behind the screens and follow that logic.

5. Another useful table is msf972 work order costing by period and cost category,  and through to msf976 (if you're using costing categorisations). This may be under Financials. This is the equivalent of MSF668, but for work orders.