1

Technical Architecture of Oracle Approvals Management

1. Abstract

This document provides technical overview of Oracle Approvals Management (AME) deals with architecture, key features and Workflow business rules to control approvals process.The process design of AME results in a more predictable, mature and defect-free performance leading to a reduction in the development cycle time.

This document also provides how AME can be utilized to create both simple and complex business cases involving the approval of Oracle Payables (AP) invoices. It also will discuss the basic components of the AME application (i.e. attributes, conditions and rules) that are required as part of AME setup for any integrating application. Finally, it will discuss how the invoice workflow in the Oracle Payables module has been integrated with AME to drive invoice approval routings. The current AME Implementation guide provides more in-depth information on the AME engine and other advanced features which is outside the scope of this document.

2. Introduction

An approval with Correction V4.0 is the default behavior for modules in SSHR 4.0 and above. Within the approvals process, the application uses rules to generate a list of approvers for the SSHR transaction. The way in which the list is generated depends on the approvals mechanism you are using (see Approvals Mechanisms in SSHR). The default approvals process also includes dynamic approvals as standard. The dynamic approvals functionality works in two parts. One part is the self–service user interface which enables the initiating manager to add additional approvers and/or notification recipients. You can also display the approvers and limit the number of approval levels. The second part is an application which generates the default approvers. This is either Oracle Approvals Management (AME) or a customizable PL/SQL package. The dynamic approval workflow process then sends notifications to approvers and/or notification recipients based on the approver list.

Oracle Approvals Management (AME) is a web–based application which is integrated with Oracle Workflow and which enables you to define business rules to control your approvals processes. With AME, you use the following components to define your approvals processes. They are associated with a transaction type for a particular application.

Attribute – this is a business variable, for example, a salary amount, user ID, or workflow process name.

Condition – a condition compares an attribute value with a set of allowed attribute values. For example, a condition could look at a salary amount. If the salary is greater than a specified value, a particular approver list is created.

Approval type and approval specifications – these components define the type of approver list that is generated. For example, to generate a supervisor–based approver list with 5 levels, you use the ’supervisory level’ approval type with the ’requires approval up to the first 5 approvers’ approval specification.

Rules – a rule links the other components together by associating one or more conditions with the approval type and approval rule.

3. Prerequisites

The prerequisites of AME are like:

Working knowledge of Workflow.

Working knowledge of PL/SQL.

Set up the approvals process using workflow attributes, to configure approvals in the Workflow Builder.

Need to know about Self-Service Human Resources (SSHR) functions.

4. Environment

1) Setup an AME Admin User     a) Login as sysadmin to the Oracle Application Home Page     b) Select User Management à Users from the Navigator     c) Search for a user from the User Maintenance page that you will want to make it the AME Admin.     d) Click on the Update Icon     e) Click on the Assign Roles button     f) Search and assign Approvals Management Administrator Role     g) Go back Home to the Navigator     h) Select Functional Administrator Responsibility     i) From the Grants page, press on the Create Grant button     j) Create a grant with the following information:              · Name              · Grantee Type = Specific User              · Grantee = <The user which you just created>              · Object = AME Transaction Types              · Data Context Type = All Rows              · Set = AME Calling Applications

2) Create a Transaction Type with Approval Group Transaction Type     a) Login as that AME Admin and go to the Navigator to select Approvals Management Administrator     b) Press the Create Transaction Type button     c) Enter the following information in Step 1 to create a transaction type:               · Application               · Transaction Type Key               · Transaction Type Name     d) Just Press Next to skip Step 2 and 3     e) Press Finish to create the transaction type Group     f) Go back Home to the Navigator.     g) Select Approvals Management Business Analyst     h) Select the transaction type that you just created     i) Click on the Approver Groups link and press the Create button     j) Create a Group by entering the following information:                · Name                · Description                · Order Number = 1                · Voting Regime = serial                · Usage Type = static                · Query = <blank> 

     k) Press the Add Another Row to create an approver      l) Search an approver from the LOV and press the Apply button Action Type      m) Once the Group is created, click on the Action Types sub-tab      n) Click on the Use Existing Action Type button      o) Select the action named approval-group chain of authority and press on the Continue button then the          Finish button      Rule      p) Click on the Rules tab      q) Press the Create button       r) Create a rule with the following information:                 · Name                 · Rule Type = List Creation                 · Start Date = <today date>                 · End Date = 12/31/4712      s) Press Next to skip step 2      t) Search for the action which you created. It should be something like Require approval from <group         name>      u) Press the Finish button.

3) Create Transaction type with Supervisor Level Transaction Type     a) Repeat steps 2a – 2h     Attributes     b) Click on Attributes link and press the Use Existing Attribute button     c) Use an existing attribute named SUPERVISORY_NON_DEFAULT_ST        ARTING_POINT_PERSON_ID by select it and press the Continue button    d) Select Static for Usage Type and do not enter anything in the Value field    e) Press the Finish button    f) Repeat 3c – 3e for TOP_SUPERVISOR_PERSON_ID    g) Repeat 3c for TRANSACTION_REQUESTOR_PERSON_ID    h) Select Dynamic for Usage Type and insert the following query into the Value field:        select employee_id        from fnd_user        where user_id = umx_pub.get_attribute_value(:transactionId, 'REQUESTED_FOR_USER_ID')     i) Press the Finish button     Action Type     j) Click on the Action Types sub-tab     k) Press the User Existing Action Type button     l) Select the supervisory level action type and press the Continue then Finish button     Rule     m) Click on the Rules tab     n) Press on the Create button     o) Create a rule by entering the following information and click on the Next button:                · Name                · Rule Type = List Creation                · Start Date = <today date>                · End Date = 12/31/4712      p) Press the Next button to skip the Add Conditions      q) Search the Action for the Action Type of supervisory level. The Action should be something like          Require approvals up to the first superior.       r) Press the Next then Finish button

4) Create Transaction Type with Job Position Transaction Type     a) Repeat steps 2a – 2h     b) Click on the Configuration Variables link in the Quick Links section of Business Analyst Dashboard        page     c) Select transaction-type administration and Press the Continue button     d) Enter the transaction type which you created in step a in the Transaction Type input field and press             Go button     e) Set Yes for allowAllApproverTypes of the Transaction Type and press the Apply button     Attributes     f) Select the transaction type in the Approval Process Setup section     g) Click on Attributes link and press the Use Existing Attribute button     h) Use an existing attribute named TOP_POSITION_ID by search, select, and press the Use Selected        Name button     i) Select Static for Usage Type and do not enter anything in the Value field     j) Press the Finish button     k) Repeat 4g – 4j for NON_DEFAULT_STARTING_POINT_POSITION_ID     l) Run the following query: select psv.position_structure_id, cur_user.user_name as "Cur Username", str.subordinate_position_id as "Cur Pos ID", pos.name as "Cur Pos Name", next_user.user_name as "Next Username", str.parent_position_id as "Next Pos ID", next_pos.name as "Next Pos Name" from fnd_user cur_user, per_pos_structure_elements str, per_pos_structure_versions psv, per_all_positions pos, per_all_positions next_pos, per_assignments_x cur_assign, fnd_user next_user, per_assignments_x next_assign where str.pos_structure_version_id = psv.pos_structure_version_id and trunc(sysdate) between psv.date_from and nvl( psv.date_to , sysdate) and pos.position_id = str.subordinate_position_id and next_pos.position_id = str.parent_position_id and cur_assign.position_id = pos.position_id and cur_assign.person_id = cur_user.employee_id and next_assign.position_id = next_pos.position_id and next_assign.person_id = next_user.employee_id order by next_user.user_name;      m) Repeat steps 4g – 4h for NON_DEFAULT_POSITION_STRUCTURE_ID      n) Enter the value of position_structure_id from the query result into the Value field as a Static attribute      o) Repeat steps 4k – 4l for TRANSACTION_REQUESTOR_POSITION_ID and with value of Cur          Pos ID from the query result      Action Type      p) Click on the Action Types sub-tab and press the Use Existing Action Type      q) Select hr position level action type and press the Continue then Finish button      Rule      r) Click on the Rules tab and press Create button      s) Create a rule by entering the following information and click on the Next button:

             · Name              · Rule Type = List Creation              · Start Date = <Today Date>              · End Date = 12/31/4712      t) Skip the Add Conditions by pressing the Next button      u) Search the Action for the Action Type of hr position level. The Action should be something like          Require approval up to first position up      v) Press the Next then Finish button

5. Oracle Approvals Management (AME)AME is a self-service web application (it’s not part of SSHR) which lets users define business rules governing who should approve transactions that originate in other Oracle applications eg in SSHR. 

5.1 Overview

There are two AME responsibilities:Approvals Management Administrator - full access to AME Approvals Management Business Analyst - access to all areas of AME that do not require technical knowledge;

AME allows users to create conditions and approval types.  These can then be linked by rules.

For example a condition could say WORKFLOW_PROCESS_NAME = 'MY_CUSTOM_LOA', orAbsence_Duration > 10Attributes to be used in conditions can be defined if they do not already exist like 'Absence_Duration'.

There are several approval types eg supervisor level which goes up the supervisor chain, and an approval specification will define how many approvers are required.For example, a supervisor level approval style which requires approval up to the first 3 levels.

You would then define a rule to link the condition with the approvaleg If WORKFLOW_PROCESS_NAME = 'MY_CUSTOM_LOA' then use a supervisor hierarchy approval style which requires approval up to the first 3 levels.

Each self service transaction requiring approval would have to meet the condition in one of the rules that have been defined.

This note does not show how to modify and create approval lists. To understand those please see Implementation Guide - AME.B (MetaLink Note 336901.1).

Does SSHR use AME?

SSHR provides a seeded AME Transaction Type called 'Oracle Self Service Human Resources' which includes one rule.The condition is WORKFLOW_PROCESS_NAME in (<list of all seeded SSHR functions>)and the approval style is supervisor level.

If a different approval style is required for some or all of the SSHR functions, the seeded rule can be modified or new rules can be created.

Does other application use AME?

As mentioned earlier in this note, the calling application is responsible for getting AME to find an approver and for notifying approvers.  AME is only responsible for compiling a list of approvers.

SSHR functions generally require a WF attribute to be set to indicate whether approval is required or not.  Then the presence of the pAME parameters in the function definition will determine whether AME should be used to generate the list of approvers.

Other applications have their own methods of using AME......

RequisitionsTo enable AME approval for requisitions go to Setup -> Purchasing -> Document Type Form in a Purchasing responsibility and enter the required approval details.

InvoicesIn AP navigate to Setup -> Options -> Payables.  In the Invoice tab tick the 'Use Invoice Approval Workflow' checkbox to specify that AME approval is to be used.Individual invoices will require approval  if the Approval Status field in the Invoices screen is set to 'Required'

Expenses Set the Profile Option AME:Installed, to Yes at the Application level for Oracle Payables and all expenses will be approved via AME.

5.2 Architecture

5.3 Key Features

AME helps you maintain your business logic associated with approval transactions globally from single window

Lets you cut down approval related workflow customizations, hence reducing the cost of ownership

Helps you leverage common expenditure policies across modules, thus consolidating your approval policy requirements

Any transaction is assured to be approved under the latest conditions, regardless of organizational changes, currency fluctuations or transaction data

Built-in testing utility to check the correctness of setup performed for both real-time and test transactions, hence reduces the need for elaborate testing cycles

Intangible benefits derived from solution design Reduced requisition approval turnaround times, thereby increasing the efficiency

of our procure-to-pay process Increased visibility of spending traits upfront to management chain

5.4 Approvals Process

Approvals with Correction V4.0 are the default behavior for modules in SSHR 4.0 and above. Within the approvals process, the application uses rules to generate a list of approvers for the SSHR transaction. The way in which the list is generated depends on the approvals mechanism you are using (see Approvals Mechanisms in SSHR). The default approvals process also includes dynamic approvals as standard. The dynamic approvals functionality works in two parts. One part is the self–service user interface which enables the initiating manager to add additional approvers and/or notification recipients. You can also display the approvers and limit the number of approval levels.

The second part is an application which generates the default approvers. This is either Oracle Approvals Management (AME) or a customizable PL/SQL package. The dynamic approval workflow process then sends notifications to approvers and/or notification recipients based on the approver list.  

5.5 Configuring Approvals in the Workflow Builder

If required, you can configure the predefined approvals processes in the Workflow Builder. You set up the approvals process using workflow attributes. To configure approvals in the Workflow Builder: 1. Open the workflow item type. 2. Navigate to the process you want to modify and double click to open the workflow diagram. 3. Open the Review Page V4.0 activity for your workflow process.

Note: You may have to drill down through several sub processes until you reach the correct Review Page V4.0 activity.

4. Make a copy of the process and any affected sub processes. For example, if you are modifying the approvals for the Process Personal Information V4.0 process, you would have to copy the Process Personal Information V4.0 process, and the related sub processes, for example, the Process Basic Details sub process. 5. Select the Review Page V4.0 activity for your process/subprocess and set the Approval required workflow attribute (HR_APPROVAL_REQ_FLAG) to YES. This activates approval for your process/subprocess. 6. Decide how a process should pass through the entire approval chain, in other words, how many levels of approval are required. Set the approval level using the Approval Level attribute

(HR_DYNAMIC_APPROVAL_LEVEL). Add an approval level value to the Default Value field. A value of 1 for example will pass the approval one level up the supervisor chain.

Note: The default number of level is 0, meaning that the number of levels is unlimited.7. Save your work.

As part of the approvals process, you can choose to enable dynamic approvals by configuring the Review activity for the workflow process in question.  

5.6 Review and Confirm

Most functions display the Review and Confirm pages. The Review page displays a corresponding region for each Web page section that you have updated as part of the preceding transaction. Inside each region is a list of current database and proposed transaction data. If you have configured approvals, you can enter approvals comments in this page. If you have enabled the Dynamic Approvals function, the user can see the default approval chain and add further approvers and notifiers. When the user chooses the Submit button from the Review page, the transaction is committed to the Human Resources system or sent for approval. The Confirm page is then displayed. The Confirm page contains a confirmation message describing the status of the transaction. The user can print a copy of the submitted transaction for their records if required. You can set up the approval properties for a process by changing the activity level attributes for the Review workflow functions.

HR_DYNAMIC_APPROVAL_LEVEL: This attribute is used to specify the number of levels to which this transaction needs to be forwarded for approval in the approval hierarchy. For example, if the value is 1, the transaction is submitted for approval to one level higher than the initiating person. When the transaction has been approved, it is committed to the HRMS application. By default, this attribute reads the approval level from the APPROVAL_LEVEL (Approval Level) item level attribute. If you specify a value for the item level attribute, you can control the approval level for all the processes. If you specify a value for the HR_DYNAMIC_APPROVAL_LEVEL attribute, it overrides the item level attribute for the process for which you have specified the value.

HR_APPROVAL_REQUIRED_FLAG: This attribute is used to specify whether the current transaction requires an approval. The valid values are: • No: the process does not require approval • Yes: the process requires approval but the dynamic approval user interface will not be shown in the review page. This means that the initiator cannot add additional approvers or notifiers. • Yes – Dynamic Approval: the process requires approval and the dynamic approval user interface will be shown in the review page. The initiator can add additional approvers and notifiers.

Confirm Instruction Application Short Name: In addition to the standard confirmation message shown in the confirmation page, you can also configure messages that are specific to the process. You can specify one for a scenario for which approval is required and one for a scenario for which no approval is required. Processes can be set to either Approval Required or Approval Not Required, but not both, using the HR_APPROVAL_REQUIRED_FLAG. For example, you can define a message for Confirm Save Instruction Name and Confirm Send for Approval Instruction Name. You register this message under your custom application. Confirm Send for Approval Instruction Name: The text associated with this message name is displayed in the confirmation page immediately after the standard confirmation message. This text is only displayed when the process does not require approval. The text associated with this message name is displayed in the confirmation page immediately after the standard confirmation message. This text is only displayed when the process requires approval.  

5.7 Approvals Mechanisms in SSHR

SSHR 4.1 uses the Oracle Approvals Management (AME) application to define and manage approval logic. For more information on AME, see: Implementing Oracle Approvals Management (available on Metal ink).

Note: If you are an existing SSHR customer, the customizable PL/SQL package for approvals, which was the default approvals mechanism in previous releases of SSHR, is

still supported in this release as an alternative to AME.All delivered SSHR version 4 functions are now linked to AME. If required, you can also link any existing custom functions that you may have based on earlier version 4 functions to AME.

Note: You cannot link SSHR version 3 functions such as Appraisals, Apply for a Job, Succession Planning, or Suitability Matching, to AME.

Alternatively, you can choose to continue to use the customizable PL/SQL package for new functions, even if they are modeled on SSHR version 4 functions.  

5.8 Oracle Approvals Management (AME)

Oracle Approvals Management (AME) is a web–based application which is integrated with Oracle Workflow and which enables you to define business rules to control your approvals processes. With AME, you use the following components to define your approvals processes. They are associated with a transaction type for a particular application.

• Attribute – this is a business variable, for example, a salary amount, user ID, or workflow process name. • Condition – a condition compares an attribute value with a set of allowed attribute values. For example, a condition could look at a salary amount. If the salary is greater than a specified value, a particular approver list is created. • Approval type and approval specifications – these components define the type of approver list that is generated. For example, to generate a supervisor–based approver list with 5 levels, you use the ’supervisory level’ approval type with the ’requires approval up to the first 5 approvers’ approval specification. • Rules – a rule links the other components together by associating one or more conditions with the approval type and approval rule.  

5.9 Default Use of AME Configuration in SSHR

Oracle SSHR delivers AME configuration which has been designed to emulate functionality delivered in the PL/SQL package. The default behavior is to use a supervisor–based approvals hierarchy which is now delivered using AME rules. The default AME configuration consists of: • a single AME transaction type ’SSHRMS’ with • a single condition WORKFLOW_PROCESS_NAME • a single rule which requires approvals to the top of the approval hierarchy or to 10 levels above the initiator, whichever comes first.     – this is based on the standard AME approval type ’chains of authority based on number of supervisory levels’  

5.10 Configuring SSHR Approval Levels in AME

To meet your business needs, you may add additional rules, conditions, or attributes within the delivered SSHRMS transaction type, or you can define a custom transaction type.  It is relatively easy to make minor changes to the delivered AME configuration and some examples are provided below. To define a different approval level for all SSHR workflow processes: • For example, to specify two approval levels: The approval level is currently defined in the rule ’SSHR Rule for at most 10 approvers in Supervisor chain’. You would edit this default rule and change the approval level for the supervisory level approval type to ’requires approval up to the first two superiors at most’. To define a different approval level for a specific workflow process: • first you create a new condition with the attribute WORKFLOW_PROCESS_NAME and enter the workflow processes which will have the different approval level as the attribute values. • Then you create a new rule, for example, ’2 approvers in supervisor chain’.     – Use the ’supervisory level’ approval type with the ’requires approval up to the first two superiors at most’ approval     – Finally, attach your new condition to the rule. To define a new approval level (if the delivered approvals do not meet your requirements): • you create a new approval (for example, ’requires approval up to the first 15 superiors at most’) in the ’supervisory level’ approval type. To define a particular user as the final approver, or final authority (even if they are not the last person in the approval chain): • you create a List Modification Condition and specify a user, for example, a manager, as the final approver. You would add this list modification condition to your rules so that the approval chain would stop at this specified approver. Alternatively, you could create a new rule, add the approval type for final approver and add the WORKFLOW_PROCESS_NAME condition so that this final approver rule would apply to selected processes.  

5.11 Configuring SSHR Functions to Use Oracle Approvals Management (AME)

Any custom functions you created prior to release 4.1 will use the customizable PL/SQL package as the default approvals mechanism. However, you can modify any custom SSHR 4.0 functions to point to AME by adding two new function parameters. You define the additional parameters in the Form Functions window.

You should also check the workflow attributes for your workflow process using the Workflow Builder. The AME rules and conditions always override any other workflow attribute settings that apply to approvals, for example, the attribute settings for the Review activity. If the Approvals Required workflow attribute is set to Yes for a workflow process but AME does not return any approvers, the process completes without requiring approval. As a general set–up recommendation, you should set up processes that currently do not require approval as follows: • Set the Approvals Required workflow attribute to Yes • Configure AME so that no approvers are returned

Note: If you subsequently need to add approvals to your process, you can simply use a different AME condition.

To link your function to AME in the Form Functions window (required): 1. Query your function. 2. Navigate to the Form tabbed region. 3. Add the following parameter information to the Parameters field for your function:     • pAMETranType=SSHRMS     • pAMEAppId=800 4. Save your work.

To add your custom workflow process to the list of values for the condition attribute for the SSHRMS AME transaction type (required if using the delivered SSHR transaction type):

1. Log on to Oracle Approvals Management.

Note: You need to use one of the following AME responsibilities:    – AME Application Administrator     – AME General Business User     – AME Limited Business User 2. Select the SSHRMS transaction type. 3. Select the Conditions tab and click on the WORKFLOW_PROCESS_NAME condition. 4. Choose the Add Text Value button and enter the name of your new workflow process as an attribute value. 5. Save your work.

To set the Approvals Required attribute in the Workflow Builder: 1. Display your function in the Workflow Builder. 2. Display the attributes for the Review function. 3. Set the Approvals Required attribute to Yes or Yes – Dynamic Approvals.

5.12 AME components

In order for a business user to develop business scenarios in AME that determine approval routings, it is important to understand the different components within AME. These components are often required to be modified or created as part of the development of business cases. A brief description of these components will be discussed in the following paragraphs.

Transaction TypesA transaction type describes the type of transaction for which business cases (rules) and approval routings will be based. This can include Oracle Application transactions such as purchase orders, sales orders or accounting journals. For the sake of this discussion, the transaction type that is provided with AME is the Payables Invoice Approval transaction type. Oracle provides many seeded transaction types to satisfy many of the common transactions that occur within a particular application. The creation of new transaction type in AME is available for those business users that want to integrate custom applications with AME. However, Oracle does not encourage the development of new transaction types because of the significant programming effort involved to integrate with the AME application.

AttributesAttributes within AME are business variables that represent the value of a data element of a given Transaction .In the case of an AP invoice transaction, a typical attribute would be invoice amount or supplier name. Attributes can be thought of the as the ‘building blocks’ of business case development. The reason being is that the value of an attribute(s) for a transaction can ultimately determine whether a business case (approval rule) has been met because approval rules use conditions which in turn use attributes.

Attributes in AME can be created as being static or they can be dynamic in nature. Static attributes have a constant value that remains the same for each and every transaction associated with the attributes transaction type. Dynamic attributes use a SQL query to retrieve the value of an attribute at runtime whenever a transaction is created. Most attributes in a transaction type are dynamic. There are several different attribute types that exist within AME. String attributes are alphanumeric in nature and can have a total length of 100 characters. Numeric attributes are considered to be any numeric value that is acceptable in PL/SQL. This includes numbers containing decimal or sign operators (+/-). AME requires that any numeric attribute that is dynamically generated to be converted to a canonical form. This can be done by using the syntax fnd_number.number_to_canonical function as part of the dynamic SQL query. An example dynamic SQL query for a numerical attribute would be in the following syntax:SELECT fnd_number.number_to_canonical(:requester_id) FROM ap_invoices_all

WHERE invoice_id =: transactionId.

Currency attributes are used whenever the transactions of an organization involve multiple currency values. This allows for Oracle to use currency conversion between denominations when retrieving the value of an attribute. AME requires that any dynamic attribute setup as a currency attribute must include the following columns as part of the SQL query: numeric column, currency and conversion method. One caveat to mention regarding currency attributes; any AME conditions that are developed using a currency attribute must include a condition for each currency this particular transaction attribute value might have. Boolean attributes have only two allowable values; true and false. Any dynamic attribute defined as a Boolean must return one of these two allowable results. AME provides a format string that can be used in the SQL query of a dynamic Boolean attribute. The syntax format is in the form of either me_util.booleanAttributeTrue or ame_util.booleanAttributeFalse.Date attributes are commonly used on transaction data that contains a date value, such as invoice date. AME requires that date attributes be returned in the format ‘YYYY: MON: DD: HH24: MI: SS’. AME provides a format string that can be used in the SQL query of a dynamic date attribute. The format string ame_util, versionDateFormatModel can be used to return the proper date format at runtime. All transaction types currently defined in AME use several mandatory attributes that can be thought of as runtime parameters because they often determine various facets of AME runtime behavior. These attributes can control AME behavior such as whether to allow an approver to appear multiple times on an approval hierarchy or whether to allow a requester to approver his/her own transactions (invoices). The following mandatory attributes are defined in AME for all transaction types:ALLOW_DELETING_RULE_GENERATE_APPROVERS ALLOW_REQUEST_APPROVALAT_LEAST_ONE_RULE_MUST_APPLY REJECTION_RESPONSE USE_RESTRICTIVE_ITEM_EVALUATIONEFFECTIVE_RULE_DATEEVALUATE_PRIORITIES_PER_ITEMUSE_WORKFLOWWORKFLOW_ITEM_KEYWORKFLOW_ITEM_TYPEREPEAT_SUBSTITUIONThe AME Implementation guide provides additional detail on each of these mandatory attributes and how they are interpreted by AME.Required Attributes are similar to mandatory attributes in that they determine runtime behavior of AME. The only difference being that required attributes are defined specific to a transaction type. In the case of the Payables Invoice Approval transaction types, the following require attributes are defined.ALLOW_EMPTY_APPROVAL_GROUPSFIRST_STARTING_POINT_PERSON_ID and SECOND_STARTING_POINT_PERSON_IDINCLUDE_ALL_JOB_LEVEL_APPROVERSJOB_LEVEL_NON_DEFAULT_STARTING_PERSON_POINT_IDNON_DEFAULT_POSITION_STRUCTURE_IDSUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_IDTOP_POSITION_IDTOP_SUPERVISOR_IDTRANSACTION_REQUESTER_PERSON_IDThe AME Implementation guide provides details of each of these mandatory attributes and how they are interpreted by AME.Both mandatory and required attributes come seeded with default values. They can be modified to meet the needs of a specific transaction type.

ConditionsThe next major component of AME setup is conditions. Conditions are used to evaluate the value of attributes in a particular transaction. The result of a condition can either be true or false.

Conditions are precursors to AME business rules. The result of a condition helps to determine whether a business case (rule) has been satisfied. The conditions within AME can be better thought of as the IF part of an approval rule. For example, If invoice supplier is Vendor a, then require approvals from Approver a, Approver BIn this example, AME would retrieve and evaluate the value of the attribute invoice_supplier to determine if the value was equal to Vendor A.

There are three different types of conditions that exist in the AME application: Ordinary-Regular, Ordinary-Exception and List Modifier. Ordinary-Regular conditions associate an attribute with a defined value or range of values (e.g. invoice_amount > 100). Ordinary-Exception conditions are similar to Ordinary-Regular conditions in how they are defined, but differ in that they are limited to the types of rules with which they can be associated. This will be discussed later in the document. Finally, List-Modifier conditions provide the ability to create conditions based on the existence of a specific approver in an approver list that is built by AME for a specific transaction. For example, a List-Modifier condition could be defined as follows:If Approver B is final approver, require approver up 1 levelThis condition would evaluate to true if Approver B was the last approver in an approver list built by AME at runtime.

Action Types and ActionsActions within the AME application describe the nature of what should be done in AME if a particular condition and rule is satisfied by a transaction. It is the actions that dictate the approver list that is generated by AME for the given transaction. Actions not only provide instruction as to who the approvers are, but how many approvers are requires for a given transaction and in what order should they be notified.Action types are groupings of actions that have a similar functionality such as the approval hierarchy that should be traversed when building an approver list. An example of this would be actions that pertain to building an approval based solely on the supervisor tree in HR. The multiple actions for this action type would all pertain to traversal of the supervisor hierarchy, but would express in terms of how many levels to traverse. Typically, each action that describes how many levels of a hierarchy to move up would be defined separate unto itself. All of the defined actions would be grouped into an action type based on their relationship to the hierarchy being used.

5.13 AME Testing Workbench

One of the very powerful features of the AME application is the Testing Workbench. The workbench provides the ability to test the business rules that have been defined in AME against test or real transactions in your Payables application database. This allows you to preview the results of your AME definitions to verify certain aspects such as:

Are attribute values, particularly custom attributes retrieving values correctly? Does the invoice satisfy the appropriate rule? Is the proper approver chain(s) being generated for the transaction based on the rule

chosen?The testing workbench can be accessed from the AME Dashboard. The AME Dashboard can be found under the Approvals Management Business Analyst role discussed earlier in the document.

The first step in using the Test Workbench involves defining a new test case in AME. Defining a test case is simple as it involves supplying a name for the test case and description (optional).After entering a name for the test case and description, choose the Save for Later button to save the test case definition. Although a Run Test Case button is available at this point, it is best to save the definition to the database first and then execute a test case after receiving the confirmation page below. The best approach to demonstrating the AME Test Workbench is by entering a new invoice in the Payables application and executing a test against this invoice. The

invoice will be created to test the second business case rule defined earlier in the document. Our test case will allow us to verify whether our business case rule has been defined properly and if the approver list is built correctly by AME.

Now that an invoice has beencreated, we can execute a test from the workbench to see if our AME components have been defined correctly and produce the results we expect. To execute a test against this invoice, navigate to the testing workbench. From the workbench, choose a test case against which the testing will be conducted. Choose the Run Real Transaction Test button. The next screen prompts the user for the transaction id which AME uses to evaluate previously defined rules and generates an approver list. This transaction id as mentioned previously is the invoice_id from AP_INVOICES_ALLIt is important to note that upon entering a transaction id, you must choose the Go button which retrieves information about your transaction. In particular, it retrieves the values of all attributes that have been defined for the current transaction type. The values of the header attributes are shown on the next page to demonstrate how AME retrieves and displays the values of the attributes. These values are consistent with the data entered for your invoice transaction.

After reviewing the values retrieved for the various attributes of the transaction, choose the Run Test Case button to execute and evaluate the rules and action defined for the transaction.Based on the results of the test, it appears that the business test case was defined properly. The SB Sales Tax Approval Rule was applied to this transaction because the invoice had a sales tax distribution line. Additionally, the approval list has been built correctly. The first approver is the individual included in the Tax Approver group defined earlier in the test case. The next approver in the approval chain is the supervisor of the requester of the invoice. As previously stated, the Testing Workbench can be a very useful during the process of implementing and developing AME rules for invoice approval routing. Having the ability to evaluate and see the results of your AME setups using real transaction prior to implementation in a production environment is quite valuable.

5.14 Invoice Approval Workflow and AME

So how does Oracle Payables integrate with Oracle Approvals Management? The simplest answer is to mention that they integrate through use of the AP Invoice Approval workflow. Whenever AP is configured to use workflow, all invoices (manual and imported) are subject to invoice approval. This is done by initially setting the approval status of the invoice to require. Once the invoice is validated and approval is initiated for the invoice either online or via the Invoice Approval Workflow concurrent program, the invoice falls into the workflow cycle. The approval logic can best be explained by reviewing the Invoice Approval workflow.

Approval Logic

When an invoice transaction falls into the approval workflow, the workflow determines if the invoice transaction is fully matched to a purchase order. If it is, then the workflow ends and the approval status of the invoice is updated to Not Required. However, if the invoice is not matched to a purchase order, then the workflow tries to identify the first or next individual responsible for review and approval of the invoice. The workflow node Identify Approver is where AP and AME are integrated. It is at this point that the workflow calls AME to determine either a) does the invoice initially meets any of the currently defined rules in AME for invoice approvals or b) are there any additional approvers left on the approval chain hierarchy.

For any AME rule satisfied by the invoice transaction, AME attempts to build an approver list based on the applied rule and the associated action type and actions that define the appropriate approvers. If a successful approver list is built, then the workflow sends a notification to the first approver in the list. The workflow itself remains active and continues to call AME as long as:

There are more approvers left on the approver chainThe workflow has not been rejected by any approverThe workflow has not expired due to non-responses by an approver

As you can see, the components that are defined in AME, especially the business rules have a direct impact on the approval routings within AP invoice workflow. It is very important to plan and define your rules carefully to ensure that the organizational approval requirements are met and approval routings flow as intended.

One thing that is important to note is the behavior of AME and workflow for invoices that do not satisfy any predefined rule. By default, the approval status of any new invoices is set to ‘Required’. One the invoice is sent for approval either manually by the user online or via the Invoice Approval Workflow program, the approval status of the invoice changes to ‘Initiated’.

When the workflow begins, if the invoice transaction does not initially satisfy any approval rules in AME, the workflow ends and the status of the invoice remains ‘Initiated’. This is the behavior of the AP Invoice workflow delivered with Oracle. It is important to mention this because whenever an organization decides to require approvals of invoices, the invoices cannot be paid until the invoice is approved. So for any invoices that fall into the category of not satisfying any approval rules, this could potentially prevent these invoices from ever being paid.

There are a couple of alternatives an organization could choose to resolve this issue. The first of which is to modify the AP Invoice workflow to deal with any invoices that do not initially meet the conditions of an approval rule. Modification to the workflow is beyond the scope of this document. The second alternative has to do with the setting of the mandatory attribute AT_LEAST_ONE_RULE_MUST_APPLY. Setting the value of this attribute to True will cause the workflow to raise an exception for any invoice transactions that do not satisfy at least one defined rule. In this case, an organization could at least be aware that their rules defined in AME do not cover any all business cases that exist in regards to invoicestransactions.

5.15 Implementing AME for AP Invoice Approval

In order to use AME to facilitate AP invoice approval routings, there are some setup steps that must be completed in both the AME application as well as within the Payables applications.

AME Setup

The first step in implementing AME is to install the AME application. As of release 11.5.9, AME comes seeded and is installed as part of the overall applications install. The setups that are described in this document are for the latest version of the AME applications. (As of this writing, AME.B is the latest RUP (Roll-Up Patch) available).

You can find the most recent patch for AME at site by using the Simple Search function under thePatches & Updates tab on Metal ink.

The next step in setting up the application is to set up AME security. The current version of AME uses Oracle Role Based Access Model (RBAC) which is part of the new User Management model to provide access to the various AME component functions. An AME role must be attached to the user account of any person utilizing AME to develop application business rules. The following roles are predefined in AME.B.

Approvals Management AdministratorApprovals Management AnalystApprovals Management System ViewerApprovals Management System AdministratorApprovals Management Process OwnerApprovals Management Business Analyst1

Granting a role to a user does not automatically provide access to the setup components within AME. As part of the RBAC model, once a role has been granted to a user, specific access must be granted, to access functions within the role in order to ‘activate’ access to the functions. In terms of AME, this means granting access to either all or a specific transaction type. For example, if a business user is responsible only for the setup of the Payables Invoice Approval transaction type, then a specific access to this transaction type can be granted, thus allowing the user to only access and modify components of this one transaction type.

1 This role comes inherit will access to all of the components needed to develop AME rules. This includes attributes, conditions, rules and the testing workbench.After the roles are granted and access is established, the profile option AME: Installed must be set at the application level for Payables. This profile option change can be made under the System Administrator responsibility in the applications.

AP Setup

In addition to the setup steps that must be followed in the AME application, there are some additional steps that must be done in the Payables application to enable AP invoice approval routing. Fortunately, all of these setups are done from one form within the application module, the Payables Options form.

The Payable Options form is typically located under the Payables manager or equivalent responsibility in the applications.

There are three options on this form that dictate how Invoice Approval is facilitated in the Payables applications. The first option Use Invoice Approval Workflow is the primary option because it informs the Payables application to force all invoices to go through the invoice

approval workflow. As mentioned previously, when this option is enabled, all invoices are set to require and must initially fall into the workflow cycle.

The next option is Allow Force Approval. This allows a user to automatically set the approval status of an invoice to Approved, which allows an invoice to be automatically approved without having go through the workflow cycle. The last option, Require Validation Before Approval requires that an invoice be fully validated before it can be placed in the workflow approval cycle.

5.16 Defining Business Case Scenarios

In the current version of the AME application (AME.B), the Approvals Management Business Analyst role provides access to the Business Analyst Dashboard

The dashboard can be thought of as a ‘birds eye view’ of the AME application.Along with displaying an overview of the various transaction types that are currently defined, the dashboard also displays any rules that have recently been defined, updated or deleted along with any rules that are slated to become active at a future date. More importantly, the dashboard provides links to all of the setup components required when defining new business case rules in AME, including attributes, conditions, approver groups and rules.

Whenever a business user begins the process of defining rules that represent organization business cases, it is important to have an understanding of the transaction type of which business rules will be based. As part of this understanding, a user should determine two important elements of the transaction type:

· What does the transaction type’s transaction id represent? · How does the transaction type determine the requester of a transaction?

The answer to the first question would require some research (i.e. Metalink, Application specific guides, etc.) to discover what value in a particular transaction is used to represent the transaction id. In the case of the Payables Invoice Approval transaction type, the invoice_id in AP_INVOICES_ALL is used as the transaction type. The importance of knowing the value of the transaction id lies in the fact that most of the dynamic attributes use the transaction id as part of the WHERE clause of the SQL statement used to retrieve the their value. Remember, an attribute

must return a single value. In the case of invoice transaction, using the invoice_id will ensure that a single value will be retrieved.

As far as determining the requester initiating a transaction, there is a required dynamic attribute defined for most if not all transaction types that contains the logic to retrieve this value. The required attribute is TRANSACTION_REQUESTOR_PERSON_ID. In the Payables Invoice Approval transaction type, the value of this attribute is retrieved by the following SELECT statement:

Select requester_idFrom ap_invoices_allWhere invoice_id =: transactionId

This means that the person populated in the requester field on the invoice header in Payables will be flagged as the initiator of a transaction. Any approver lists that are built from an invoice transaction will begin using the requester id as the basis.

For each of the following business case demonstrations, the paper assumes the HR supervisor hierarchy is used as the basis for building approval lists. Additionally, there is the assumption that only one currency (USD) is used.

5.17 Business Case # 1: Require Approvals up 1 level from invoice requester for any invoice $100 or greater.

For this demonstration, the following components need to be defined:

Attributes: Total Invoice AmountCondition: Total Invoice Amount >= $100Rule: If Total Invoice Amount >= $100, then require approvals up to the first supervisor

Since this is an amount field, the SQL statement must return the number using the

fnd_number_to_canonical function.

Condition: Total Invoice Amount >= $100 (SB_INVOICE_AMT is greater than or equal to 100)

Any condition that uses a numeric attribute as its basis must provide a lower and/or upper limit. In the business case, we are only concerned with invoices that are $100 or more.

Rule: Total Invoice Amount >= $100, then require approvals up to the first supervisor (SB Invoice Rule (>$100)

Several items on the figure above are highlighted to show that the rule is consistent with the original business case requirement to force an approval by the immediate supervisor of the requester for any invoice $100 or greater.

5.18 Business Case # 2: Require approvals from the Tax Approver group, along with the normal chain-of-authority for any invoices greater than $100 with Sales Tax distribution Lines.

For this demonstration, the following components need to be defined:

Attributes: Sales Tax Present on InvoiceTotal Invoice Amount (Already defined)

Conditions: Sales Tax Present on Invoice > 0Total Invoice Amount >= $100 (Already defined)

Approver Group: Sales Tax GroupRule: If Sales Tax Present on Invoice > 0, then require pre-approval from the sales tax approver group, then up to the first supervisor

Attribute: Sales Tax Present on Invoice (SB_SALES_TAX_PRESENT)

This attribute could have been defined as a Boolean attribute to return either True or False. For simplicity it has been defined as a numeric field that returns the # of invoice distribution lines that are line type ‘TAX’ with a tax code equal to ‘SALES TAX’. If the count returned is zero, then it is assumed the invoice has no sales tax lines. Any value greater than zero is assuming the invoice has at least one or more sales tax lines.

Condition: Sales Tax Present on Invoice > 0 ( SB_SALES_TAX_PRESENT is greater than 0)

As mentioned in the previous example, any condition that is associated with a numeric attribute must define a lower and/or upper limit. In this case, we define a lower limit that the value retrieved in the SB_SALES_TAX_PRESENT attribute must be greater than 0 for the condition to be considered true.

Approver Group: Sales Tax Group (SB Sales Tax Group)

Important to remember is that an approver group allows an organization to setup hierarchies that include specific individuals required to be included in an approval list. This approver group has been defined to include one employee in the approver group to represent the sales tax group. Additional people can be added or removed as needed.

Rule: If Sales Tax Present on Invoice > 0, then require pre-approval from the sales tax approver group, then up to the first supervisor

The definition of this rule really demonstrates the flexibility of the AME application when defining complex or unique approvals. There are a couple of items worth noting regarding this setup.The first of which is the rule type associated with the rule which is a combination rule type. This important to note because a combination rule type allows a rule to include different action types that may use different approval types as discussed earlier in the document. For this rule, a combination rule type was necessary to allow the pre-approval group to be notified (Sales Tax Group) prior to the notifying the immediate supervisor of the invoice requester.

The other item worth noting is that rule can use as many conditions as necessary to satisfy the most complex or unique approval requirements of an organization. For this rule, notice that we are using both the most recently defined condition that counts the number of sales tax distributions lines, but also uses the previously defined condition that verifies whether the invoice amount is greater than $100.

6. Reusable ComponentsSQCs are like functional library files which we can include in our SQR programs. We need to include the SQC in the SQR program using #include function.

Few important SQCs that need to be attached are:

#include 'setenv.sqc'

#include 'stdapi.sqc'

#include 'prcsdefn.sqc'

#include 'prcsapi.sqc'

#include 'curdttim.sqc'

#include 'hrctlnld.sqc'

#include 'datwtime.sqc'

7. POC and PrototypesNot Applicable

8. Additional Deliverables (Optional)

Not Applicable

9. Assumptions & Dependencies1. Access to all resources2. A clear idea of the SQR syntax while working on the requirements3. Thorough understanding of functionality or purpose4. SQR application is available and in place for use.5. Preparation of Requirements document6. Leave scope for modifications to accommodate future changes

10. Integration Management

SQR is not an integration tool.

11. Tips and TechniquesNot Applicable

12. Estimation RevisionsIn SQR estimation revisions take place whenever Client raises a Change Request. This change request can be analyzed with the following list of impact parameters:

o Volume and size of the transactions to a certain degreeo Business Requirement as well as Interface complexity

The above factors help in revising estimations.

Interface ComplexityN/A

Table 1 Interface ComplexityLight Medium Heavy Elaborate

Condition N/A

13. Skill SetPrimary Skills Acquaintance with SQR

Generic Business Skills Strong organizational and time management skills, Excellent problem and incident management skills, Typical candidate should be a self-starter, pro-active and detail

orientated, Prior experience working with PeopleSoft Technologies

14. Technical Review Criteria1. Thorough review of the documents and templates2. Statements supplemented with supportive documents3. Criteria check to be authorized with measured/measurable estimates 4. Version# and name of the document should be updated wherever required (check in

footer as well).5. Prepared by and reviewed by should be mentioned.6. Version history should be properly maintained.7. Provide Reference FDD document name in Functional Description section.8. Table of content should be updated and should be correct.9. Mention where these changes are going to be done.10. Review comments should be captured in review template and tracked. Review doc's

name should: Should be decided.

11.

15. ConclusionIt was the intent of this paper to provide the reader with enough high level understanding of AME Functionality and how organizations can use AME to control their approval requirements for invoice approval routing in Oracle Payables. As with any other Oracle application, mastery of the application comes through practice and experimentation. Hopefully, the paper has demonstrated how thorough planning of business case rules and further understanding of AME can allow business users to develop their most unique or complex approval requirements in this powerful application.

16. References

16.1 White Papers Table 2 White Papers Title White Paper Link

Oracle Approvals Management Implementation Guide Rel 11i Part No. B25324-01,

Metal ink Note 336901.1

Approvals Management Developers Guide Release AME.B

Metal ink Note 289927.1

MetaLink Note 336901.1

16.2 Web Sites

Table 3 Web SitesTitle URLGoogle, a popular search engine, is a tool for finding resources on the World Wide Web.

http://www.google.com

Official Website http :// www.oracle.com

16.3 Documents

Table 4 DocumentsTitle Document LinkUnderstanding SQR messages

www.peoplesoftcity.com/hr88books_eng/eng/psbooks/tsql/htm/tsql10.htm

Understanding Dates

www.peoplesoftcity.com/fin84books_eng/eng/psbooks/t sqr /htm/t sqr 22.htm

Meta SQL www.peoplesoftcity.com/fin84books_eng/eng/psbooks/tpcr/htm/tpcr05.htm

16.4 Customers

Table 5 CustomersCustomer Name Customer Type (PPP/P/G)RSMeans Corp. GOceaneering GIDEA RC G

16.5 Projects

Table 6 ProjectsProject Title Description1. RSMeans Project Integration Between CRM and FIN2. Oceaneering Finance Module3. IDEA RC Finance Module

17. Open Issues

Table 7 Open IssuesSno IssueID Description Status

(Open/Close)Owner’s Name

Comments Dt.Close

1 SFS_R188 Relieving Letter

1.Make Emplid Mandatory in the Run Control Page2.Active EE s are also coming in the EE Lookup page.It should show only Terminated EE s.3.The Paragraph is not properly aligned in the Report.

NA NA NA

2 SFS_R176 Weekly Report From Operations

1.This Report is not running.Its Showing Run Status as 'Processing' forever.

NA NA NA

3SFSPAYRL Payroll

RegisterNot able to run the Report.Im getting this SQL Error

(SQR 5528) ODBC SQL dbdesc: SQLNumResultCols error 208 in cursor 20: [Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name 'PS_SFS_ST_PAYROLL'.

Error on line 337:

NA NA NA

(SQR 3716) Error in SQL statement.

Errors were found in the program file.

SQR for PeopleSoft: Program Aborting.

18. Glossary

Table 8 Glossary Term DefinitionAME Oracle Approvals ManagementAP Oracle PayablesSSHR Self-Service Human Resources RUP Roll-Up PatchRBAC Oracle Role Based Access Model