Attributes

Attributes

Overview

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 following 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.

Attribute Properties

An attribute has the following properties:

Name

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. For example,

• If you want to create an attribute specific to the Web Expenses transaction type, then you might begin your attribute name with the prefix WEB_EXPENSES_.

• If you want to share the attribute name across several transaction types owned by a single integrating application, then give the name a prefix that refers to the integrating application such as HRMS_WEB_EXPENSES_.

• If you want to use the attribute name in all the transaction types, then avoid any references to integrating applications in the attribute name.

Item Classes

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.

Use

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 several applications. 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:

• Static

  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.

• Dynamic

  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.

  Note: Oracle strongly recommends that SQL queries used to retrieve information must use only base tables and not secure views. The SQL query must also not include any context-sensitive logic.

Attribute Types

An attribute type indicates the data type of the attribute's values. An attribute's type is always the same, regardless of the transaction type. You cannot change the attribute's type after you create the attribute name. AME distinguishes the following five attribute types:

• Boolean

• Number

• String

• Date

• Currency

Boolean Attributes

Boolean attributes have one of two allowed values at run time: 'true' and 'false'. These strings are case-sensitive. AME defines constants for them: ame_util.booleanAttributeTrue and ame_util.booleanAttributeFalse. Use the values as follows:

• constants in the dynamic attribute use or the source code generating them.

• use the actual values without quote marks in the static use.

Number Attributes

Number attributes can have any numeric value allowed in PL/SQL. Static use for number attributes should either be integers or decimal numbers using the decimal-point character required by the user's character set. For example, '1' and '-2' are acceptable integer values, and '-3.1415' is an acceptable decimal value.

Dynamic use for number attributes should convert a number column to canonical form using the function fnd_number.number_to_canonical. For example the following could be a dynamic use for the TRANSACTION_REQUESTOR_PERSON_ID attribute:

select
        fnd_number.number_to_canonical(requestor_person_id)
        from some_application_table
        where transaction_id = :transactionId

A number attribute can represent an approver. If you want this to be the case, then you must choose the attribute's approver type when you create the attribute.

Note: You cannot edit a number attribute's approver type after creating the attribute.

String Attributes

String attributes can have any text value up to 100 bytes long (100 characters). The text value can include spaces and ordinary punctuation, and is case-sensitive. You must not enter any return characters in the attribute use as AME removes the return characters from the attribute use. However, there is a difference in the way AME removes the return characters for static and dynamic use. This difference implies that:

• As AME removes the return characters during run time for a static use, a static use for a string attribute cannot contain any return characters.

• A string attribute's dynamic use can technically have a value that includes a return character as AME only removes return characters from the query, not from the query results.

Caution: We encourage you to avoid non-printable characters such as return characters in string attribute values because of the discrepancy between AME's behavior for static and dynamic use with respect to return characters, and as return characters do not display clearly.

Date Attributes

Date attributes can have any value represented as a date variable in PL/SQL as AME distinguishes dates down to the second. Date-attribute values must conform to the format model ame_util.versionDateFormatModel , which currently has the value 'YYYY:MON:DD:HH24:MI:SS' . This value is unlikely to change. For example, '2001:JAN:01:06:00:00' is an acceptable date value. AME's format model for dates differs slightly from the canonical format model. The canonical format model contains a space character, which creates certain technical difficulties.

Ensure your dynamic use for the attribute dates convert date columns to strings using ame_util.versionDateFormatModel, like this:

select
        to_char(sysdate, ame_util.versionDateFormatModel) from dual

Currency Attributes

Currency attributes represent monetary amounts. The reason AME defines a currency attribute type, rather than treating currency values as number attributes, is to allow for conversion between currency denominations when evaluating a condition defined on a currency attribute. This implies the following:

• The currency attributes have three components: amount, denomination, and conversion method

• Your Oracle Applications instance must use Oracle General Ledger's currency conversion functionality

For example, if TRANSACTION_AMOUNT is a currency attribute, then at run time, AME might need to evaluate the condition

TRANSACTION_AMOUNT < 500 USD

Upon fetching the attribute's value, AME finds that the amount is in British pounds (not U.S. dollars), and that the attribute requires the 'Daily' conversion method. AME would then use General Ledger's currency-conversion functionality to convert the attribute's value into U.S. dollars, using the 'Daily' conversion method. Later AME evaluates the condition using the converted dollar amount.

If your organization only uses one currency denomination, then you can use number attributes rather than currency attributes to represent monetary values.

Currency-attribute values must have the form:

amount,code,type

where code is a valid currency code and type is a valid currency-conversion type. Ensure there are no space characters other than those in the code and type values. For example,

'5000.00,USD,Corporate' might be a valid static currency value.

The amount component of a currency value must be in canonical form. Dynamic currency use must use the function fnd_number.number_to_canonical to return a number value in canonical form. For example, the following SQL statement could be a dynamic use for a TRANSACTION_TOTAL attribute:

select
        fnd_number.number_to_canonical(transaction_amount),
        currency_code,
        currency_conversion_type
        from some_application_table
        where transaction_id = :transactionId

Using Attributes

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. To create a null static use, see: Creating an Attribute and Editing an Attribute

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.

Syntax Rules for Static Use

1. A static use must not use single or double quote marks to demarcate strings.

2. A static use for boolean attributes must be one of the strings 'true' and 'false'.

3. A static use for number attributes must be either an integer or a decimal number in decimal (not scientific) notation. For example, '1' and '-2' are acceptable integer values, and '-3.1415' is an acceptable decimal value.

4. A static use for date attributes must use the format model ame_util.versionDateFormatModel, whose value is: YYYY:MON:DD:HH24:MI:SS

   For example, '2001:JAN:01:06:00:00' is an acceptable date value.

   Note: This format model differs slightly from the ”canonical” format model, which contains a space character. Space characters are problematic for variable values passed to a Web server via the HTTP GET method.

5. A static use for string attributes can be any text value that fits in a varchar2 of length ame_util. attributeValueTypeLength, which is currently 100. (You may wish to check your AME installation's source code to verify that this constant still has the same value.). The text value may include spaces and ordinary punctuation. It is case-sensitive.

6. A static use for currency attributes must have the form:

   amount,code,type

   where code is a valid currency code and type is a valid currency-conversion type. There should be no space characters other than those in the code and type values. The amount should use a period, not a comma, as a decimal point (if any). For example, '5000.00,USD,Corporate' is a valid currency value.

7. A static use may be null. To create a null static use, leave the Usage field empty on the Create an Attribute, Edit an Attribute, or Mandatory Attribute Query Entry page.

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

might be a dynamic use for a line-item-level attribute named ITEM_QUANTITY.

Syntax Rules for Dynamic-use Queries

1. The query must fit in the column ame_attribute_usages.query_string, which is a varchar2(2000). If your query is long, you may wish to compare its length with the current table definition in your applications instance.

   Note: You can avoid the length constraint by encapsulating your query in a function that you compile on the database, and then selecting the function's value from dual in your query.

2. The queries for all data types other than currency must select one column; queries for the currency data type must select three columns.

3. Each selected column must convert to a value that fits in a varchar2 of length ame_util. attributeValueTypeLength, which is currently 100. (You may wish to check your AME installation's source code to verify that this constant still has the same value.)

4. Queries for boolean attributes must select one of two possible values, ame_util.booleanAttributeTrue and ame_util.booleanAttributeFalse.

5. Queries for date attributes must convert a date value into a varchar2 using the ame_util.versionDateToString function, to guarantee that AME stores the date value using the ame_util.versionDateFormatModel. AME can only evaluate conditions defined on a date attribute correctly when that attribute's dynamic use converts the attribute's date value using this format model, because AME stores the date as a varchar2, and attempts to convert the stored value back to a date using the same format model. For example the following is a correct dynamic use for a date attribute:

   Select ame_util.versionDateToString(sysdate) from dual

6. Queries for number and currency attributes must select the number or currency amount converted to a varchar2 by:

   fnd_number.number_to_canonical

7. Queries for header-level attributes may (but are not required to) contain the transaction-ID placeholder ame_util.transactionIdPlaceholder, which is ':transactionId'. The transaction-ID placeholder is a true dynamic PL/SQL bind variable. That is, at run time, AME binds a transaction-ID value to this variable before dynamically executing the query. A condition of a where clause referencing this bind variable must have the form:

   transaction ID = :transactionId

   where transaction ID is a column that contains the transaction ID passed to AME at run time by the application whose transaction type uses the query.

8. Queries for attributes belonging to subordinate-level item classes must return one row for each item in the item class, for a given transaction. For example for OIE Expenses the Item Class line item ID query string is as follows:

   select
                   distribution_line_number from ap_expense_report_lines_all
                   where report_header_id = :transactionId
                   order by distribution_line_number

   Therefore a corresponding line level attribute must match this query string, in respect of the number and the ordering of the line item Ids. So for example for the attribute LINE_COST_CENTRE the SQL is as follows:

   select
                   flex_concatenated from ap_expense_report_lines_all
                   where report_header_id = :transactionId
                   and distribution_line_number in
                   (select distribution_line_number
                   from ap_expense_report_lines_all
                   where report_header_id = :transactionId )
                   order by distribution_line_number

9. Queries for the dynamic required attributes can generate different starting approvers for each subordinate item in a transaction. See the required attributes in Attribute Classifications

   To enable this feature, the dynamic queries must include the item class and item ID bind variables in addition to the transaction ID. For example, the query can be as follows:

   select
                   person_id from invoice_table
                   where transaction_id = :transactionId
                   and item_class = :itemClass
                   and item_id = :itemId
   

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 reasons:

1. It is not practical for AME to guarantee that a transaction type's active attributes (those attributes whose values the engine and/or rules require to determine which rules apply to a transaction of that type) will always be fetched in a fixed order. As a result, AME may not have fetched the value of Attribute1 before it tries to fetch the value of attribute2. Even if AME were to guarantee an attribute-fetching order, that would not solve the general problem. It would only solve the problem for attributes that come after the ones they depend on, in the order.

2. Were AME to allow this sort of dependency among attributes, cycles could occur. Attribute1 could depend on Attribute2, and Attribute2 could depend on Attribute3, which in turn could depend on Attribute1. There would be no way in logic to resolve these attributes' values.

Attribute Classifications

An attribute classification indicates whether an attribute is mandatory, required, active or represents business variables.

Mandatory Attributes

Mandatory attributes determine various facets of AME runtime behavior. A mandatory attribute must have a use in all transaction types. AME displays the mandatory attributes at the top of the attributes list that appears when you select the Attributes tab in the application. AME predefines the following mandatory attributes:

• ALLOW_DELETING_RULE_GENERATED_APPROVERS

  This is a boolean attribute. It determines whether AME enables the integrating application to suppress from a transaction's approver list the approvers required by the transaction type's rules.

• ALLOW_REQUESTOR_APPROVAL

  This is a boolean attribute. It determines whether AME enables a requestor to approve their own transaction, if they have sufficient signing authority. When this attribute is true, and a requestor has sufficient authority, the relevant action type makes the requestor the only approver in their chain of authority, and assigns the requestor the initial approval status ame_util.approvedStatus (approved). When the attribute is false, the relevant action type does not include the requestor in the chain of authority. Instead, the action type includes in the chain of authority at least one of the requestor's superiors.

  In the previous versions of AME, the AME engine evaluated the attribute ALLOW_REQUESTOR_APPROVAL, so that it was appropriate for the attribute to be mandatory. In the current version of AME, the following action types require the action type instead:

  • Absolute job level

  • Final approver only

  • Manager then final approver

  • HR position

  • HR position level

  • Supervisory level

  It is likely that ALLOW_REQUESTOR_APPROVAL will be removed from the set of mandatory attributes, and treated instead as a required attribute for the above action types (and any others that require the attribute).

• AT_LEAST_ONE_RULE_MUST_APPLY

  This is a boolean attribute determining whether AME raises an exception when no rules apply to a transaction at run time.

• REJECTION_RESPONSE

  This is a string attribute. It determines how AME responds when an approver rejects an item. The attribute has three allowed values:

  • ame_util.continueAllOtherItems currently has the value 'CONTINUE_ALL_OTHER_ITEMS'. When REJECTION_RESPONSE has this value, AME continues the approval processes of all items other than the item(s) that were rejected.

  • ame_util.continueOtherSubItems currently has the value 'CONTINUE_OTHER_SUBORDINATE_ITEMS'. When REJECTION_RESPONSE has this value, AME continues the approval processes of all subordinate-level items other than the item(s) that were rejected, but stops the approval process of the header and the rejected item(s).

  • ame_util.stopAllItems currently has the value 'STOP_ALL_ITEMS'. When REJECTION_RESPONSE has this value, AME stops the approval processes of all of the transaction's items, including the header.

  Note: Ensure you use the actual value in a static use, and the ame_util constant in the code executed by a dynamic use.

• USE_RESTRICTIVE_ITEM_EVALUATION

  This is a boolean attribute. It indicates whether AME requires a single subordinate-level item to satisfy all conditions on attributes belonging to the subordinate item class, in a given rule, for the rule to apply. If the attribute is true, then a rule containing conditions on a subordinate-level item class' attributes only applies if one of the transaction's items in that class satisfies all of the rule's conditions on attributes of that item class. If the attribute is false, then different items may satisfy different conditions on the subordinate item class' attributes.

  For example, consider the rule:

  If 
  LINE_ITEM_CATEGORY in {office furniture, office supplies}
  and LINE_ITEM_TOTAL < 1,000 USD
          then
                  require approvals up to the first three superiors,at most
  

  Suppose a transaction has two line items with the attribute values shown in the following table:

  Line-Item ID	Attribute	Attribute Value
  1	LINE_ITEM_CATEGORY	office furniture
  1	LINE_ITEM_TOTAL	1,100 USD
  2	LINE_ITEM_CATEGORY	travel
  2	LINE_ITEM_TOTAL	900 USD

  If USE_RESTRICTIVE_ITEM_EVALUATION is false, then the rule applies as line-item one satisfies the first condition and line-item two satisfies the second. If the attribute is true, then the rule does not apply as, neither line item satisfies both the conditions.

• EFFECTIVE_RULE_DATE

  When AME begins to process a transaction, this date determines which rules are active for a given transaction. AME then evaluates each active rule's conditions to see whether the rule actually applies to the transaction.

  For most transaction types, the system date (sysdate) is the appropriate EFFECTIVE_RULE_DATE value. To use this value, provide EFFECTIVE_RULE_DATE a static use with no value. This is more efficient at run time than giving it a dynamic use that selects the system date from dual.

• EVALUATE_PRIORITIES_PER_ITEM

  This is a boolean attribute. It determines whether AME evaluates the applicable rules' use priorities per item. Per-item evaluation is relevant for relative rule-priority modes. When the attribute is true, AME evaluates the rules' use priorities that apply to each item as a group. When the attribute is false, it evaluates the use priorities of all the rules applying to the transaction together.

• USE_WORKFLOW

  This is a boolean attribute. It indicates whether AME should log the transaction type's exceptions to the Workflow exception stack. Ordinarily this attribute must have a static use.

• WORKFLOW_ITEM_KEY

  This is a string attribute. It is a transaction's item key in the integrating application's workflow. The item key is typically also the AME transaction ID, and in this case, the attribute's dynamic use can select :transactionId from dual. AME uses this attribute's value when it logs exceptions in Workflow's exception stack. If the integrating application does not use Oracle Workflow (if USE_WORKFLOW is false), then ensure this attribute has a static use with no value.

• WORKFLOW_ITEM_TYPE

  This is the item type of the integrating application's workflow. AME uses this attribute's value when it logs exceptions to Workflow's exception stack. If the integrating application does not use Oracle Workflow, then ensure this attribute has a static use with no value.

• REPEAT_SUBSTITUTION

  This is a boolean attribute with a default value of false, in order to make it backward compatible. AME uses this attribute to process the substitution rules a second time at the end of the processing cycle. This is done to apply the Substitution rules on adhoc insertions and surrogate approvers. The attribute's value can be set or reset dynamically for any transaction. For example, if you would like the substitution rules to run again only for a certain set of transactions, this attribute value can be set dynamically to true or false.

Required Attributes

An action type may rely on the values of one or more attributes to govern various aspects of the action type's runtime behavior. Such attributes are the action type's required attributes. The required attributes must have a use in a given transaction type, for the action type to be available in the transaction type.

Important: Only required attributes (attributes in the required category) can use item class and item ID (:itemId and :itemClass) along with transaction ID (:transactionId), no other attribute can.

AME predefines the following required attributes whose use is more generally explained in Required Attributes For Action Types and Rules:

• ALLOW_EMPTY_APPROVAL_GROUPS

  When this attribute is false, AME raises an exception if an approver group has no members at run time. This typically occurs if the approver group is dynamically generated and the SQL that populates the group, fetches no members. For further information, see Approver Groups.

• FIRST_STARTING_POINT_PERSON_ID

  and SECOND_STARTING_POINT_PERSON_ID

  These attributes' values identify the first approver in each chain of authority generated by the action type Dual Chains of Authority.

• INCLUDE_ALL_JOB_LEVEL_APPROVERS

  This attribute determines if all approvers with the same job level should be included when building the chain of authority for the action types that depend on Job Level. For further information, see Required Attributes For Action Types.

• JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID

  If this attribute is not null, the approver it identifies will be used as the starting point for action types that depend on Job Level. Its value will override the setting for TRANSACTION_REQUESTOR_PERSON_ID.

• NON_DEFAULT_POSITION_STRUCTURE_ID

  The position level action type handler uses this attribute to walk up the hierarchy. If the value of this attribute is null, then AME uses the primary position structure of the current business group for finding the parent position, otherwise AME uses the specified position structure.

• NON_DEFAULT_STARTING_POINT_POSITION_ID

  If this attribute is not null, then the position it identifies will be used as the starting point for position level action types. Its value will override the setting for TRANSACTION_REQUESTOR_POSITION_ID.

• SUPERVISORY _NON_DEFAULT_STARTING_POINT_PERSON_ID

  If this attribute is not null, then the approver it identifies will be used as the starting point for action types that depend on Supervisory Level. Its value will override the setting for TRANSACTION_REQUESTOR_PERSON_ID.

• TOP_POSITION_ID

  Similar to the explanation below for TOP_SUPERVISOR_PERSON_ID, it represents the top of the position hierarchy.

• TOP_SUPERVISOR_PERSON_ID

  This attribute should be assigned to the person ID of the employee at the top of the hierarchy (typically the CEO of a corporation). This is used in Action Types that climb the supervisor hierarchy and is needed to determine if AME has reached the top of the hierarchy as opposed to reaching a gap in the hierarchy setup.

• TRANSACTION_REQUESTOR_PERSON_ID

  This attribute should be assigned to the ID of person requesting the transaction. Several of the defined Action Types will use this as the starting point for traversing the hierarchy.

• TRANSACTION_REQUESTOR_POSITION_ID

  This attribute specifies the requestor's position ID for a transaction

Additionally, the following required attributes' values can identify a different first approver for each subordinate item in a transaction:

• FIRST_STARTING_POINT_PERSON_ID

• SECOND_STARTING_POINT_PERSON_ID

• JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID

• NON_DEFAULT_POSITION_STRUCTURE_ID

• NON_DEFAULT_STARTING_POINT_POSITION_ID

• SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID

Note: To enable this feature, you must ensure the dynamic query for these attributes includes the item class and item ID bind variables in addition to the transaction ID. See the syntax rules for dynamic use queries in Using Attributes.

Business-Variable Attributes

Non-mandatory attributes that are not required attributes represent business variables used in approval rules. In AME, these are the attributes that appear in conditions. (You can also use required attributes in conditions, though doing so is uncommon. You cannot use mandatory attributes in conditions.)

Active Attributes

An attribute is active for a rule if one or more of the rule's conditions is defined on the attribute, or if one of the action types of the rule's actions requires the attribute. An attribute is active for a transaction type (or simply active) if the attribute is either mandatory or active for at least one of the transaction type's rules. AME only fetches the values of active attributes at run time. It lists all attributes on the Test Workbench tab, even if they are not active.

How does AME use Attributes?

When AME starts to calculate a transaction's approver list at run time, it does the following:

1. It fetches the values of each attribute that is active for the transaction type.

   To do this, AME either fetches the constant value assigned to the attribute, or fetches the attribute's query and then executes it. If an attribute having a dynamic use is a header-level attribute, AME executes the query once for the entire transaction. If the attribute is a line-item-level attribute, AME executes the query once for each of the transaction's line items.

2. After fetching all of the active attributes' values, AME checks whether each of a transaction type's rules applies to the transaction.

   It does this by determining whether each of the rule's conditions is true. For conditions defined on header-level attributes, the condition is true if the attribute's value lies within the list or range of values that the condition defines. For conditions defined on line-item-level attributes, the condition is true if the value of the attribute for any one line item lies within the list or range of values that the condition defines.

Deciding Whether to Create or Edit Attributes

Ideally, a transaction type delivered with AME predefines the attribute names and attribute use that your organization requires. However, to meet your business requirements you may want to add attributes and their use, or change the predefined use.

Note: Even if you do not need to change the predefined attributes or their use, you still must verify that the predefined attributes and their use meet your business requirements.

The following steps explain the general procedure for deciding which attributes and attribute use you need to create or edit, how to add or edit them as needed, and test the results:

1. Consult the integrating application's documentation to determine the purpose and meaning of each predefined attribute.

2. Compare the predefined attributes' use with those your transaction type's implementation document specifies. See the Mandatory Attributes subsection of the Representation of Business Cases in AME.

3. Edit any attribute use that does not match your requirements.

4. Create any attribute names and attribute use that your implementation requires, and which are not predefined.

5. Use the Test Workbench tab to compare the attribute values of your test cases defined with their expected values.

6. Using your Application account, execute the dynamic attribute use from the SQL*Plus command line for your test cases to verify that the attributes have the same values in SQL*Plus as on the Test Workbench tab.

Viewing Attributes

You can view attributes using the Attributes tab.

The Attributes page enables you to view attributes present in your transaction type, create new, and reuse existing attributes to define how Oracle Approvals Management fetches business facts from a transaction.

To display the list of attributes for a transaction type

Use the Business Dashboard and Attributes pages.

1. Select the required transaction type in the Approval Process Setup available in the Business Dashboard.

2. Click the Attributes link.

   The Attributes page opens displaying the attributes list.

Creating Attributes

To create an attribute

Use the Create Attributes page.

1. Click Create on the Attributes page to open the Create Attributes page.

2. Enter the attribute's name.

   If you plan to create one or more rules referencing the attribute, and to share the rule(s) across several transaction types, you just need to create the attribute's name for the first transaction type, and then select it from the list of shareable attribute names for all remaining transaction types. You must enter a distinct use for the attribute name, for each transaction type.

   All attribute names, including those you create, are shareable; so make sure that your attribute name's degree of generality reflects your intentions. For example, if you want to create an attribute specific to the Web Expenses transaction type, you might begin your attribute name with the prefix 'WEB_EXPENSES_'.

   Note: If you enter an attribute name in lower or mixed case, AME changes it to all upper case when it saves your work.

3. Select the attribute's level (header or line-item) if the transaction type has enabled line-item attributes.

4. Select an attribute type. Ensure to use the currency type for attributes reflecting monetary values.

5. Optionally, select the approver type for Number data type.

6. Select a value set.

   Note: A value set contains business specific data. The application enables Value Set when you select Number, String, or Currency data type.

7. Select the attribute use. If you select Dynamic, then enter an SQL query and click validate to ensure the query is correct.

8. Click Create Another to create another attribute, if required.

9. Click Apply to add the attribute to your transaction type.

   Your new attribute appears in the appropriate section of the attributes list.

Editing Attributes

To edit an attribute

Use the Update Attribute page.

1. In the Attributes page, display the list of attributes.

2. Click the Update icon for the attribute that you want to edit.

3. Make your changes on the Update Attribute page.

4. Click Apply to update the attribute.

When you change an attribute's description, your changes apply for all transaction types. Changes to the attribute use only apply to the transaction type for which you make the change.

You cannot change the name, type, or description of predefined attributes. You must instead create a new attribute with the name, type, and description that you want. In some cases, you can create or edit a predefined attribute's use. You can change the use and value set of an attribute. If you change a use type from static to dynamic, then you must change the use value accordingly.

Note: Queries for the dynamic required attributes can generate different starting approvers for each subordinate item in a transaction if the query includes the item class and item ID bind variables in addition to the transaction ID. See the required attributes in Attribute Classifications

Deleting Attributes

To delete an attribute

Use the Attributes page.

1. Display the list of attributes.

2. Click the Delete icon for the attribute that you want to delete.

3. Confirm the deletion when prompted.

   Note: You cannot delete predefined attributes. You cannot delete an attribute if it has a condition based on it, which a current or future rule uses. Additionally, when you delete an attribute that is not shared with any other transaction type, AME deletes all the conditions associated with this attribute.

Copying Attributes

To copy an existing attribute into your transaction type

Use the Use Existing Attribute page.

1. Click Use Existing Attribute on the Attributes page to open the Use Existing Attribute page.

2. Select an attribute and click Continue to copy the existing attribute into your transaction type.

3. Modify the attribute's use.

   Note: Queries for the dynamic required attributes can generate different starting approvers for each subordinate item in a transaction if the query includes the item class and item ID bind variables in addition to the transaction ID. See the required attributes in Attribute Classifications

4. Click Finish to use the selected existing attribute in your transaction type.