Report Values Framework

DISCLAIMER: This framework is described in much better detail in the Financial Model Framework paper though some details are left here though they might have changed.

The general model of the dupont model framework is as follows. The DuPont model is driven by a set of EditorValues which are held in a collection by another object of CatState. Each EditorValues corresponds to a set of values based on a distinct set of queries, usually from a single table or a group of database tables. DuPontModel is the DuPont look of the collection of the EditorValues objects based on the definition of the DuPont model. The DuPont model only carries the total values of each EditorValues.

But there are other ways to look at the data stored in each EditorValues. The DuPontModel allows the user to click on the buttons that open up a window that displays more detailed information in a table/report form. The values are obtained from other queries of the specific EditorValues object. (It is possible, however, to get data from other EditorValues objects by accessing the CatState object.)

On the third level are even more specific data. The way to get to these specific data from the second level window is either by putting the action in the menus or in the table's double-clicking ability.

One is Detailed Information, which actually shows each row of the query. A variant of this is the Formula Information, which allows the user to define a formula to obtain only the relevant rows of the database.
Another is the Summary Report. This shows a more detailed information of the summaries. The summary report queries must be created.
The third one is Graph Information. The table information of the EditorValues window are always graph-viewable. But other graphs can be created based on the ElementSpecs. ElementSpecs are objects that are dependent on the queries of the EditorValues object to return a sum based on certain constraints.

It is also possible to group the EditorValue windows into one window in a reporting fashion. This ability displays the second-level detailed information of a set of EditorValue details in one window.

In order to make the framework as general as possible, the specifications of the EditorValues have been moved to the database. The names of the classes that correspond to the database tables are as follows.

Handling the types of EditorValues: ???.
Queries: ReportQuerySpecs.
ElementSpecs: ReportElementSpecs.
Window information: ReportWindowSpecs.
Detailed information: ReportDetailedTableSpecs.
Summary information: ReportSummarySpecs.
Graph information: ReportGraphSpecs.
Report grouping window information: ReportCompositeWindowSpecs.

Since EditorValues is the class that unites all the information together, it has several instance variables that hold the relevant information of each, queries, element specs, graphs, detailed, summary, and graphs. DuPontModel, which deals on a higher level by combining the EditorValues objects, holds the composite report information, as well as some graphs.

To get more specific information about each section, click on the relevant title below.

The report values hold the values that are obtained from database queries, directly or indirectly. They hold the queries and determine how the displayed value should look. The displayed values are determined by manipulating the result of the queries.

High level class descriptions:
There are basically two different types of "Report Values": FormulaReportValues and Query Report Values. The top level dupont model consists of both of these.

The FormulaReportValues are calculated values based upon other ReportValues while all of the Query Report Values are dependent on a selection criteria from Cat State. The selection criteria is primarily date and model number. Only the high level values of the report values are calculated in it (i.e. the actual and budget summations that are displayed in the DuPont Model).
Query ReportValues get their values from some relational database. All of them share the common characteristic of being able to open up an editor that displays the detailed information. For this reason, they are actually called EditorValues. But there are two types, those that are dependent only on database queries (ReportValues, except the subclasses FormulaReportValues and NullValues) and those that are dependent on these report values CompositeEditorValues. There is also another class, TotalCompositeValues, which is a special case in that it works with CompositeReportModel.
- ReportValues is special in that it holds a collection of queries through a special class, QueriesHolder, which holds the budget and actual queries and their corresponding values (stored as ListQueryValue so that the values are requeried if the queries change). It is also responsible for additional functionalities that are directly dependent on the queries, such as the summary report and the detailed table queries.
- CompositeEditorValues is the abstract superclass that holds a set of EditorValues objects that it depends on in order to get the detailed information for its editor. Because it does not hold any queries, all the detailed values must come from other report values.
- TotalCompositeValues has one editor, which has a single table, a total table. This class resembles CompositeEditorValues in that it is dependent on other editor values. But it is special in that it gets the information on the evaluation of the total value from CompositeReportModel, which has the specifications for obtaining the total value. In case of CompositeEditorValues, a special subclass must be created for every different detailed editor, but this class by itself can handle every type of detailed editor, as long as the editor has one total row.

The inner mechanisms of EditorValues:

Obtaining information from the database.
Since all values must come from database queries ultimately, the subclasses of ReportValues provide the queries. Direct dependence on the queries, however, is undesirable because a single query must be created for each unique value desired from the query. If there are many queries, then it can take a long time to get all the values from these queries. In fact, there are many redundancies, where several queries may be accessing the same database table to obtain only slightly different values.
For this reason, the queries have been separated out from the selections on the query. The queries just return all the specified information. But another class, ElementSpecs, holds the specifications for selecting on the results of the queries to obtain the desired sums. As a result, the number of queries is drastically reduced, and it is quicker to open up the detailed information.
It is up to the user to divide up the work optimally between the queries and the element specs so that the query time can be minimized.
The element specs select on either a query or another element spec. When selecting on a query, the name of the query as stored in QueriesHolder, the name of the field to sum on, and the selections, called constraint, are determined. Without a nil constraint, the summation of all the results of the query is returned. It is also possible to select on element specs by performing arithmetic operations on them. It is also possible to perform arithmetic operations on them with a ValueHolder that holds a single number. The element specs must also have an element spec called 'total' which is the value returned when the total of the editor value is desired. This value is used in the methods actual and budget, for filling in the values in DuPontModel.
Click here for learning how.
Specifying the look of the editor.
EditorValues also holds a dictionary of editor specifications. The editor that it opens is always an instance of ReportModel. This class asks the corresponding EditorValues for the editor specifications. With the specifications, it creates a set of tables with the appropriate values in each cell.
The editor specifications are designed to specify how the tables should look and what the values in each cell of the tables should be. Because BlockValue objects that are dependent on a query are put into each cell, they automatically reflect the most up-to-date value of the query.
Moreover, these editor specifications are used to perform arithmetic operations. For example, net sales is equal to gross sales minus warranty. In the specification terms, the total of the editor is equivalent to the total of the gross sales table minus the total of the warranty table. Similarly within a table, one row can be dependent on other rows, and across editors, one editor can be the result of two other editors, as is the case with TotalCompositeValues.
On the editor level, the number of tables as well as the name of the editor should be specified. If necessary, the formula for obtaining the total value of the editor should also be specified. By default, it is the sum of all the tables. Also the number of columns and the formula for calculating the values of the columns should be specified. The first two columns are reserved for budget and actual values. But the other columns are determined through arithmetic operations on the previous rows. It is possible to specify as many columns as wanted. The column specification should be done at the editor level and not at the table level because all tables should have the same column behaviors.
On the table level, the specifications of each row is essential. Moreover, its total value should be specified if needed.
On the row level, nothing needs to be done. The cells are filled using the actual and budget queries and the column specifications.
Specifying the menus.
The editor has three menus that are dependent on the queries:
1. Summary report information.
2. Detailed table information. The most detailed information possible from the database, showing each row, is possible.
3. Graph information. Graphs that are the resultant collection of queries can be specified.

Relevant classes and categories for ReportValues and ReportModel:

If you have any questions or changes, please contact:

Joseph W. Yoder at:(217) 244-4695 or by email: yoder@ncsa.uiuc.edu

Return to Financial Model Documentation Page