Analyses of Transaction Model or Control Results

You can create analyses that present results returned by transaction models or controls. But results returned by any transaction model or control are incompatible with results returned by any other. That's because:

A transaction model cites business objects and attributes of those objects, which supply data for analysis. Each business object is a set of related data fields from a business application; an attribute is one field within the set.
While creating a model, a user selects result attributes. For each risky transaction it finds, the model returns a value for each of these attributes.
Controls are developed from models, and each control inherits the result attributes selected for its model. For each incident it generates, a control returns a value for each of these attributes.

Because the selection of result attributes is unique for each model or control, you must limit the scope of result analyses.

First Option

One option is appropriate for a control analysis: It may report on amount values returned by multiple controls. For this to happen, though, some result attributes must be the same for all the controls included in the analysis. They must also occupy the same position among the result attributes in each control. Finally, the analysis must include only the columns that provide values for these attributes.

The recommendation is that as you create models from which these controls are deployed, you place the amount value second among result attributes and a date related to the amount third. Examples of such attributes are Amount and Date in the Payables business object. But it's up to your organization to enforce this convention while creating models.

Second Option

Another, more typical option is to focus an analysis on a single model or control. This approach is always the right one for model-result analyses, and you can apply it to control-result analyses as well.

Here's why this approach is right for model-result analyses. Model development is an iterative process. You define a model's risk logic and select its result attributes, then review results to see if they're as you expect. If not, you modify the model and repeat. The purpose of a model analysis is to review results of a single model during its development, as those results change with each iteration.

As is true for an access model, the analysis of a transaction model would include data that's also available in the model's Result page. But the analysis would enable you to focus on result attributes that are important to you, presented in your preferred view.

Here's an example of how to create such an analysis:

Open the BI catalog: Select Tools > Reports and Analytics, then click Browse Catalog.
Click New > Analysis.
For a control-result analysis, select the Risk Management Cloud - Advanced Financial Controls Real Time subject area. Or for a model-result analysis, select the Risk Management Cloud - Advanced Financial Models Real Time subject area.
In the Subject Areas list of the Criteria tab, expand a details folder and drag a name dimension from it to the Selected Columns region. For a control, the folder and dimension would be Advanced Control Details > Name. For a model, they'd be Model Details > Model Name.
Expand another subject-area folder, titled Transaction Incident Result Headers for a control, or Transaction Result Headers for a model. In each, number values indicate the order in which result attributes are arranged in a control or model. For example Result Header 1 in the Transaction Incident Result Headers folder is the first result attribute selected for a control. Drag those you want to the Selected Columns region. This example uses headers 1 through 3.

Click the Results tab. In the Compound Layout region, a grid displays records for all the models or controls you can access. (From here on, the term "item" may mean either model or control.) In the grid, each of the dimensions you've selected is a column header, and each row identifies the attributes selected for one item.

In this example, suppose you can access two items. The Compound Layout grid might look like this:

Name	Result Header 1	Result Header 2	Result Header 3
Duplicate Invoices	Supplier.Supplier Name	Payables Invoice.Amount	Payables Invoice.Date
Expenses Over Meal Limits	Person.Full Name	Expense Report Details.Original Receipt Amount	Expense Report Information.Date

Note that:

The standard way to identify an attribute is to concatenate its name with the name of its business object, with a period as the delimiter. For example, "Supplier.Supplier Name" indicates the Supplier Name attribute of the Supplier business object.
The order in which result attributes are selected for an item is the same as the order in which they're made available for an analysis. For Duplicate Invoices, for example, Supplier.Supplier Name is Result Header 1 because it was the first result attribute selected for the model, and inherited by the control developed from the model.

After viewing return values, decide which item you want to select for an analysis. Make a note of its result headers. Later, you may rename result-value columns. The result headers will serve as reminders of what the new names should be.
Click the Criteria tab. Create a filter that selects the one item you want. For example:
- In the Name dimension (for a control analysis) or Model Name dimension (for a model analysis), click the menu icon (it looks like a gear) and select Filter.
- In a Filter dialog, a Column value defaults to the dimension from which you opened the dialog, either "Name" or "Model Name." Specify an operator and a value to complete the filter, for example "Is equal to" and "Duplicate Invoices."
- Click OK to close the dialog.
Remove the result-header dimensions. Open the menu for each and select Delete.
If you're using the Advanced Financial Controls Real Time subject area, expand its Transaction Incident Result Values folder. If you're using the Advanced Financial Models Real Time subject area, expand its Transaction Result Values folder. Identify result-value columns whose numbers match those of the result-header columns you just deleted, and drag them to the Selected Columns region. In this example, they'd be Result Value 1, Result Value 2, and Result Value 3.
If you're creating a control-result analysis, give the result-value column headers meaningful names. For each result value in your analysis:
- Click the menu icon and select Column Properties.
- In a Column Properties dialog, select the Column Format tab.
- Select the Custom Headings check box.
- Enter a new name in the Column Heading field. For example, as you rename Result Value 1, you might enter "Supplier Name."
- Click OK to close the dialog.
You can do this for a model-result analysis as well, but you may not want to. That's because as you develop a model, you may add or remove result attributes. If so, you also modify the values displayed in the analysis. If, for example, you add an attribute at position 2, the original Result Value 2 becomes Result Value 3, the original 3 becomes 4, and so on. So column names you created for the analysis would no longer be valid.
Click the Results tab. The grid in the Compound Layout region now displays results only for the item you selected. These results consist of result-attribute values for each incident generated by the item, rather than result-attribute names.

Also, remember that your analysis displays information that's only as current as the most recent data synchronization. For a control analysis, that synchronization is performed by a Report Synchronization job; it's typically scheduled, and if so you don't need to do anything. (See Synchronize Analytics Data.) But for a model-result analysis, you must manually run a separate synchronization job from the Models page of the Advanced Controls work area. Run this job after each run of the model about which your analysis displays data. (See Synchronize Model Result Data for OTBI Reporting.)