IT Audit - Governance, Risk, and Compliance Topic for Oracle Applications - page 252

Create model
The first step in setting up a new Transaction control is to create a model . A TCG
model returns temporary results—a snapshot of risk that is replaced each time the
model is evaluated. Once a model design is reviewed and approved, you can convert
it into a control. A control returns permanent results—records of violations that
remain available to be resolved no matter how often the control is run.
You cannot create a control directly in TCG. A model and the control into which it
is converted are structurally alike (the principal difference between them being the
temporary or permanent nature of the results each generates). Although the creation
of a model is a preliminary step in the creation of a control, models may be created
to run on their own, so that users, such as auditors can assess the risk inherent in a
system at a given moment.
A TCG model or control specifies circumstances under which transactions entail risk
and so require a review. A model or a control into which the model is converted,
consists of one or more elements such as filter, function, or pattern. Each, in a distinct
way, defines an aspect of the risk a transaction may present and captures records of
transactions that meet its definition.
Each of these elements cites a business object and an attribute of that object,
which supply transaction data for analysis. They identify tables and columns in
the business management application database. At the same time, they represent
components of the user interface for that application:
• A business object corresponds to one or more database tables, but is given a
business language name that evokes the user screen those tables support
• An attribute corresponds to a database column in a business object's tables,
but is given a business language name that evokes the UI field that
column supports
There are two types of TCG controls or models:
• A Defined control or model contains filters or functions. These elements
enable the user creating a model to define circumstances under which
transactions are considered to pose a risk. A model or control can incorporate
any number of filters or functions (and so any number of business objects
and attributes from which they are derived).
For example, the following screenshot shows a model, which includes two
filters, both based on a Payables Standard Invoice business object. One filter
would select transactions for which an Invoice Canceled Date attribute is
not blank.