Attribute Usage

 All  All transaction types in AME can share an attribute name, while defining their own method of determining the attribute's value at run time as an attribute use. The ability to share an attribute's name enables several transaction types to share conditions and rules. This further enables an organization to define a single set of rules that applies to several transaction types and have a uniform approvals policy.

It also means that you can define an attribute name while a given transaction type may not have yet defined a use for the attribute. A transaction type only has access to conditions defined on attributes for which the transaction type has defined a use. Only users with the System
Administrator responsibility can create and edit an attribute's use.

There are two kinds of attribute use: static and dynamic.


Static Attribute Use
A static attribute use assigns a constant value to an attribute, for a given transaction type. A static use always stores an attribute value as a string, regardless of the attribute's data type. It is not necessary to have a value for a static use.

A static use is common but not required for certain mandatory boolean attributes that affect how AME treats all transactions, for example, the AT_LEAST_ONE_RULE_MUST_APPLY attribute. They are similarly used for certain
required boolean attributes, for example INCLUDE_ALL_JOB_LEVEL_APPROVERS.

Dynamic Attribute Use
A dynamic attribute use assigns an SQL query to an attribute, for a given transaction type. The query must follow certain syntax rules. AME executes the query at run time to determine the attribute's value. A dynamic use is common for all attributes other than the two classes of boolean attributes described under Static Attribute Use.

A dynamic use can be up to 4000 bytes long and should not end with a semicolon. A dynamic use can reference a transaction's ID by using the bind variable ':transactionId'. A dynamic use for header-level attributes must return one row per transaction. A dynamic use for attributes belonging to subordinate-level item classes must return one
row for each item in the item class, for a given transaction. The rows must be ordered so that the ith row returned by the dynamic use is the value for the ith item ID returned by the transaction type's item-class use for the attribute's item class. Typically this means the dynamic use will include an order-by clause that references a column containing the item ID. For example, the query:

select item_quantity
from some_application_table
where transaction_id = :transaction_id
order by line_item_id

Can a dynamic attribute use reference the value of another attribute?
For example:
Attribute1: select column1 from table1
where column2 = :transactionId
Attribute2: select column3 from table2
where column4 = :Attribute1

A dynamic attribute use cannot reference other attributes' values. To implement the above example, the second attribute's dynamic use would be:
select column3 from table2 where column4 =
(select column1 from table1 where column2 = :transactionId)
AME does not allow references to attribute values within the dynamic use for two

Oracle Applications Fusion Cloud - Inventory

Oracle Cloud/Fusion Procurement training will help you develop the fundamental skills required to set up and use the Procurement module. This training covers all the tasks, setups, forms and reports used in Procurement and related modules