Attributes are business variables with a single value for a particular transaction.
Examples of attributes are:
- Transaction's total amount
- Percentage of discount
- An item's category
- A person's salary
Approval rules use the attributes to determine the outcome such as a value for the transaction's total amount or a value for the percentage of discount. Attributes have an item class such as Header, Line Item, Cost Center, and Project Code. The above graphic uses the example of a purchase order to illustrate attributes and their values.
Creating attribute names and defining attribute use are two important steps in the implementation process for a transaction type. Often a transaction type predefines the attribute names and attribute use that your organization requires. You can use the predefined attributes or create attributes to meet your business requirements.
An attribute has the following properties:
An attribute name is a string that represents a decision variable. An attribute name can be at the most 50 bytes long (50 characters long) when you have configured your Oracle Applications to use a single-byte character set. In AME, attribute names always appear in upper case, for example, TRANSACTION_AMOUNT.
Note: If you enter an attribute name in lower or mixed case, AME converts it to upper case before storing it.
All attribute names are shareable. After you create an attribute name, it is available for use in all transaction types. When you create an attribute name, ensure its level of generality reflects your intentions.
An attribute item class determines what class of items have a value for the attribute. For a given transaction, each of the items in an attribute's item class has its own value for the attribute. An attribute always has the same item class, regardless of the transaction type. Attributes belonging to the header item class are sometimes termed header-level attributes. Attributes belonging to subordinate item classes are sometimes termed line-item-level attributes or cost-center-level attributes.
An attribute use tells AME how to get the attribute's value for a given item and transaction, in a given transaction type. Every transaction type can define its own use for a given attribute. This means several transaction types can share conditions and rules, so that an organization can define a single set of rules that applies to several transaction types, thereby implementing a uniform approvals policy across severalapplications. It also means that an attribute name can exist without a given transaction type having access to it, or to conditions defined on it, because the transaction type has not yet defined a use for it.
Attribute use can be of two types:
A static use specifies a fixed value for the attribute, for all items and transactions. It is a common practice to give static use to most or all of the mandatory attributes. One reason is that a static use requires less runtime overhead than a dynamic use. Another is that a static use expresses uniform business policies for all transactions
in a given transaction type.
A dynamic use specifies an SQL query that AME executes at run time to fetch the attribute's value for each item in the attribute's item class, for a given transaction. The execution of dynamic attribute use constitutes the majority of AME's run time overhead. Therefore, optimizing your dynamic use can have a big impact on AME's
performance. Ensure you optimize these queries thoroughly, especially if the transaction type that owns them processes a high volume of transactions.