5 Jun 01 22:08
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.