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

.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. It should be something like Require approval from <group name> u) Press the Finish button. 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. 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. The Action should be something like Require approvals up to the first superior.· 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.

name as "Next Pos Name" from fnd_user cur_user.position_id = str.name as "Cur Pos Name".employee_id order by next_user. 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 .date_to . sysdate) and pos.date_from and nvl( psv.pos_structure_version_id and trunc(sysdate) between psv. per_all_positions next_pos.position_id = str. per_assignments_x next_assign where str.person_id = cur_user. per_pos_structure_elements str.position_id = pos.user_name.pos_structure_version_id = psv.person_id = next_user. str. next_user.user_name as "Cur Username". select. per_all_positions pos.subordinate_position_id as "Cur Pos ID".parent_position_id as "Next Pos ID". next_pos. per_pos_structure_versions psv. str. cur_user.user_name as "Next Username".position_structure_id.subordinate_position_id and next_pos.position_id and next_assign.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. per_assignments_x cur_assign.parent_position_id and cur_assign. fnd_user next_user.position_id and cur_assign.employee_id and next_assign.position_id = next_pos. 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. pos.

If a different approval style is required for some or all of the SSHR functions. a supervisor level approval style which requires approval up to the first 3 levels. Does SSHR use AME? SSHR provides a seeded AME Transaction Type called 'Oracle Self Service Human Resources' which includes one rule. AME allows users to create conditions and approval types.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. a. For example. The condition is WORKFLOW_PROCESS_NAME in (<list of all seeded SSHR functions>) and the approval style is supervisor level. or Absence_Duration > 10 Attributes to be used in conditions can be defined if they do not already exist like 'Absence_Duration'.B (MetaLink Note 336901. These can then be linked by rules. This note does not show how to modify and create approval lists. The Action should be something like Require approval up to first position up v) Press the Next then Finish button 5. the seeded rule can be modified or new rules can be created.access to all areas of AME that do not require technical knowledge. Overview There are two AME responsibilities: Approvals Management Administrator .AME.full access to AME Approvals Management Business Analyst . To understand those please see Implementation Guide . Each self service transaction requiring approval would have to meet the condition in one of the rules that have been defined. You would then define a rule to link the condition with the approval eg If WORKFLOW_PROCESS_NAME = 'MY_CUSTOM_LOA' then use a supervisor hierarchy approval style which requires approval up to the first 3 levels.1). There are several approval types eg supervisor level which goes up the supervisor chain. 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. and an approval specification will define how many approvers are required. . For example a condition could say WORKFLOW_PROCESS_NAME = 'MY_CUSTOM_LOA'.

Then the presence of the pAME parameters in the function definition will determine whether AME should be used to generate the list of approvers. 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. b... SSHR functions generally require a WF attribute to be set to indicate whether approval is required or not.. Other applications have their own methods of using AME.. AME is only responsible for compiling a list of approvers.Does other application use AME? As mentioned earlier in this note.. Invoices In AP navigate to Setup -> Options -> Payables. the calling application is responsible for getting AME to find an approver and for notifying approvers. Architecture . to Yes at the Application level for Oracle Payables and all expenses will be approved via AME. Requisitions To enable AME approval for requisitions go to Setup -> Purchasing -> Document Type Form in a Purchasing responsibility and enter the required approval details. In the Invoice tab tick the 'Use Invoice Approval Workflow' checkbox to specify that AME approval is to be used.

the application uses rules to generate a list of approvers for the SSHR transaction. thereby increasing the efficiency of our procure-to-pay process  Increased visibility of spending traits upfront to management chain d.0 are the default behavior for modules in SSHR 4. 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. hence reducing the cost of ownership Helps you leverage common expenditure policies across modules.c. thus consolidating your approval policy requirements Any transaction is assured to be approved under the latest conditions. Approvals Process Approvals with Correction V4.0 and above. 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. The way in which the list is generated depends on the approvals mechanism . Within the approvals process.

The dynamic approvals functionality works in two parts. 7. Inside each region is a list of current database and proposed transaction data. if you are modifying the approvals for the Process Personal Information V4. The Review page displays a corresponding region for each Web page section that you have updated as part of the preceding transaction. how many levels of approval are required.0 activity for your workflow process. The default approvals process also includes dynamic approvals as standard. meaning that the number of levels is unlimited. Review and Confirm Most functions display the Review and Confirm pages. the user can see the default approval chain and add further approvers and notifiers.0 activity for your process/subprocess and set the Approval required workflow attribute (HR_APPROVAL_REQ_FLAG) to YES. Configuring Approvals in the Workflow Builder If required. You can set up the approval properties for a process by changing the activity level attributes for the Review workflow functions. you can enter approvals comments in this page. One part is the self–service user interface which enables the initiating manager to add additional approvers and/or notification recipients. e. Note: You may have to drill down through several sub processes until you reach the correct Review Page V4. You set up the approvals process using workflow attributes. For example. When the user chooses the Submit button from the Review page. Open the workflow item type. Make a copy of the process and any affected sub processes.you are using (see Approvals Mechanisms in SSHR). 3.0 activity. A value of 1 for example will pass the approval one level up the supervisor chain. Add an approval level value to the Default Value field. The Confirm page is then displayed. 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. the transaction is committed to the Human Resources system or sent for approval. if the value is 1. The dynamic approval workflow process then sends notifications to approvers and/or notification recipients based on the approver list. You can also display the approvers and limit the number of approval levels. The second part is an application which generates the default approvers. Save your work. Navigate to the process you want to modify and double click to open the workflow diagram. 2. 5. 6. As part of the approvals process. The user can print a copy of the submitted transaction for their records if required. f. If you have configured approvals. Note: The default number of level is 0. in other words. This activates approval for your process/subprocess.0 process. and the related sub processes. To configure approvals in the Workflow Builder: 1. you would have to copy the Process Personal Information V4. This is either Oracle Approvals Management (AME) or a customizable PL/SQL package. The Confirm page contains a confirmation message describing the status of the transaction. For example. you can choose to enable dynamic approvals by configuring the Review activity for the workflow process in question. you can configure the predefined approvals processes in the Workflow Builder. Open the Review Page V4.0 process. Select the Review Page V4. Set the approval level using the Approval Level attribute (HR_DYNAMIC_APPROVAL_LEVEL). Decide how a process should pass through the entire approval chain. 4. the Process Basic Details sub process. If you have enabled the Dynamic Approvals function. for example. the transaction is .

Approvals Mechanisms in SSHR SSHR 4. it is committed to the HRMS application. the customizable PL/SQL package for approvals. for example. user ID. you can also link any existing custom functions that you may have based on earlier version 4 functions to AME. All delivered SSHR version 4 functions are now linked to AME. You can specify one for a scenario for which approval is required and one for a scenario for which no approval is required. this attribute reads the approval level from the APPROVAL_LEVEL (Approval Level) item level attribute. 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. 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. • Yes – Dynamic Approval: the process requires approval and the dynamic approval user interface will be shown in the review page. a salary amount. you can control the approval level for all the processes. • Attribute – this is a business variable. Apply for a Job. is still supported in this release as an alternative to AME. If you specify a value for the item level attribute. They are associated with a transaction type for a particular application. Note: If you are an existing SSHR customer. h. 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. even if they are modeled on SSHR version 4 functions. Note: You cannot link SSHR version 3 functions such as Appraisals. HR_APPROVAL_REQUIRED_FLAG: This attribute is used to specify whether the current transaction requires an approval.1 uses the Oracle Approvals Management (AME) application to define and manage approval logic. Confirm Instruction Application Short Name: In addition to the standard confirmation message shown in the confirmation page. g. With AME. see: Implementing Oracle Approvals Management (available on Metal ink). but not both. This text is only displayed when the process requires approval. which was the default approvals mechanism in previous releases of SSHR. you can define a message for Confirm Save Instruction Name and Confirm Send for Approval Instruction Name. it overrides the item level attribute for the process for which you have specified the value. Succession Planning. you can choose to continue to use the customizable PL/SQL package for new functions. You register this message under your custom application. or workflow . 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. you use the following components to define your approvals processes. to AME. This means that the initiator cannot add additional approvers or notifiers. using the HR_APPROVAL_REQUIRED_FLAG. By default. If required. The initiator can add additional approvers and notifiers. For example. you can also configure messages that are specific to the process.submitted for approval to one level higher than the initiating person. If you specify a value for the HR_DYNAMIC_APPROVAL_LEVEL attribute. When the transaction has been approved. or Suitability Matching. Processes can be set to either Approval Required or Approval Not Required. Alternatively. For more information on AME.

The default behavior is to use a supervisor–based approvals hierarchy which is now delivered using AME rules. To define a different approval level for all SSHR workflow processes: • For example. you could create a new rule. 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. a particular approver list is created. To define a new approval level (if the delivered approvals do not meet your requirements): • you create a new approval (for example. or you can define a custom transaction type. . 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. a manager. conditions. It is relatively easy to make minor changes to the delivered AME configuration and some examples are provided below. To define a particular user as the final approver. • Then you create a new rule. • Rules – a rule links the other components together by associating one or more conditions with the approval type and approval rule. 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’ j. you may add additional rules. You would add this list modification condition to your rules so that the approval chain would stop at this specified approver. • Approval type and approval specifications – these components define the type of approver list that is generated. 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. 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’. as the final approver. For example. For example. ’requires approval up to the first 15 superiors at most’) in the ’supervisory level’ approval type. If the salary is greater than a specified value.process name. to specify two approval levels: The approval level is currently defined in the rule ’SSHR Rule for at most 10 approvers in Supervisor chain’. to generate a supervisor–based approver list with 5 levels. a condition could look at a salary amount. ’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. for example. Configuring SSHR Approval Levels in AME To meet your business needs. 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. i. attach your new condition to the rule. Alternatively. for example. • Condition – a condition compares an attribute value with a set of allowed attribute values. or attributes within the delivered SSHRMS transaction type. you use the ’supervisory level’ approval type with the ’requires approval up to the first 5 approvers’ approval specification.

To set the Approvals Required attribute in the Workflow Builder: 1. Add the following parameter information to the Parameters field for your function: • pAMETranType=SSHRMS • pAMEAppId=800 4. Navigate to the Form tabbed region. Choose the Add Text Value button and enter the name of your new workflow process as an attribute value. However. 3. Display your function in the Workflow Builder. Configuring SSHR Functions to Use Oracle Approvals Management (AME) Any custom functions you created prior to release 4. 2. the attribute settings for the Review activity.1 will use the customizable PL/SQL package as the default approvals mechanism. Set the Approvals Required attribute to Yes or Yes – Dynamic Approvals. Save your work. it is important to understand the different components within AME. You should also check the workflow attributes for your workflow process using the Workflow Builder. 3. 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. As a general set–up recommendation. Note: You need to use one of the following AME responsibilities: – AME Application Administrator – AME General Business User – AME Limited Business User 2. you can modify any custom SSHR 4. 2. AME components In order for a business user to develop business scenarios in AME that determine approval routings. Transaction Types A transaction type describes the type of transaction for which business cases (rules) and approval routings will be based. 5. You define the additional parameters in the Form Functions window. This can include Oracle Application transactions such as . Select the SSHRMS transaction type. Save your work. Display the attributes for the Review function. you can simply use a different AME condition.k. l. The AME rules and conditions always override any other workflow attribute settings that apply to approvals. 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.0 functions to point to AME by adding two new function parameters. Select the Conditions tab and click on the WORKFLOW_PROCESS_NAME condition. for example. 3. the process completes without requiring approval. These components are often required to be modified or created as part of the development of business cases. Query your function. If the Approvals Required workflow attribute is set to Yes for a workflow process but AME does not return any approvers. 4. Log on to Oracle Approvals Management. A brief description of these components will be discussed in the following paragraphs. To link your function to AME in the Form Functions window (required): 1.

Boolean attributes have only two allowable values. There are several different attribute types that exist within AME. Most attributes in a transaction type are dynamic. Oracle provides many seeded transaction types to satisfy many of the common transactions that occur within a particular application. such as invoice date. AME requires that any numeric attribute that is dynamically generated to be converted to a canonical form.number_to_canonical function as part of the dynamic SQL query. String attributes are alphanumeric in nature and can have a total length of 100 characters. Currency attributes are used whenever the transactions of an organization involve multiple currency values. However. AME requires that date attributes be returned in the format ‘YYYY: MON: DD: HH24: MI: SS’. sales orders or accounting journals. a typical attribute would be invoice amount or supplier name. 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. Attributes Attributes within AME are business variables that represent the value of a data element of a given Transaction . The syntax format is in the form of either me_util. the transaction type that is provided with AME is the Payables Invoice Approval transaction type. One caveat to mention regarding currency attributes.booleanAttributeFalse. Dynamic attributes use a SQL query to retrieve the value of an attribute at runtime whenever a transaction is created. true and false. An example dynamic SQL query for a numerical attribute would be in the following syntax: SELECT fnd_number. The format string ame_util. currency and conversion method.booleanAttributeTrue or ame_util. This includes numbers containing decimal or sign operators (+/-). Numeric attributes are considered to be any numeric value that is acceptable in PL/SQL.purchase orders. Static attributes have a constant value that remains the same for each and every transaction associated with the attributes transaction type. This can be done by using the syntax fnd_number. 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). Attributes can be thought of the as the ‘building blocks’ of business case development. This allows for Oracle to use currency conversion between denominations when retrieving the value of an attribute. Date attributes are commonly used on transaction data that contains a date value.number_to_canonical(:requester_id) FROM ap_invoices_all WHERE invoice_id =: transactionId. AME provides a format string that can be used in the SQL query of a dynamic Boolean attribute. versionDateFormatModel can be used to return the proper date format at runtime. For the sake of this discussion. Any dynamic attribute defined as a Boolean must return one of these two allowable results. Oracle does not encourage the development of new transaction types because of the significant programming effort involved to integrate with the AME application.In the case of an AP invoice transaction. AME provides a format string that can be used in the SQL query of a dynamic date 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. The following mandatory attributes are defined in AME for all transaction types: ALLOW_DELETING_RULE_GENERATE_APPROVERS ALLOW_REQUEST_APPROVAL AT_LEAST_ONE_RULE_MUST_APPLY REJECTION_RESPONSE USE_RESTRICTIVE_ITEM_EVALUATION . any AME conditions that are developed using a currency attribute must include a condition for each currency this particular transaction attribute value might have. 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. The creation of new transaction type in AME is available for those business users that want to integrate custom applications with AME. Attributes in AME can be created as being static or they can be dynamic in nature.

Both mandatory and required attributes come seeded with default values. Ordinary-Regular conditions associate an attribute with a defined value or range of values (e. a List-Modifier condition could be defined as follows: If Approver B is final approver. 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.EFFECTIVE_RULE_DATE EVALUATE_PRIORITIES_PER_ITEM USE_WORKFLOW WORKFLOW_ITEM_KEY WORKFLOW_ITEM_TYPE REPEAT_SUBSTITUION The AME Implementation guide provides additional detail on each of these mandatory attributes and how they are interpreted by AME. but differ in that they are limited to the types of rules with which they can be associated. If invoice supplier is Vendor a. For example. Ordinary-Exception conditions are similar to Ordinary-Regular conditions in how they are defined. The result of a condition can either be true or false. invoice_amount > 100). Conditions are used to evaluate the value of attributes in a particular transaction. AME would retrieve and evaluate the value of the attribute invoice_supplier to determine if the value was equal to Vendor A. Ordinary-Exception and List Modifier.g. For example. It is the actions that dictate the approver list that is generated by AME for the given transaction. then require approvals from Approver a. require approver up 1 level This condition would evaluate to true if Approver B was the last approver in an approver list built by AME at runtime. Required Attributes are similar to mandatory attributes in that they determine runtime behavior of AME. In the case of the Payables Invoice Approval transaction types. This will be discussed later in the document. They can be modified to meet the needs of a specific transaction type. Approver B In this example. ALLOW_EMPTY_APPROVAL_GROUPS FIRST_STARTING_POINT_PERSON_ID and SECOND_STARTING_POINT_PERSON_ID INCLUDE_ALL_JOB_LEVEL_APPROVERS JOB_LEVEL_NON_DEFAULT_STARTING_PERSON_POINT_ID NON_DEFAULT_POSITION_STRUCTURE_ID SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID TOP_POSITION_ID TOP_SUPERVISOR_ID TRANSACTION_REQUESTER_PERSON_ID The AME Implementation guide provides details of each of these mandatory attributes and how they are interpreted by AME. The only difference being that required attributes are defined specific to a transaction type. The . 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. There are three different types of conditions that exist in the AME application: Ordinary-Regular. Conditions The next major component of AME setup is conditions. but how many approvers are requires for a given transaction and in what order should they be notified. Actions not only provide instruction as to who the approvers are. Finally. 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. Action Types and Actions Actions 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. the following require attributes are defined.

Defining a test case is simple as it involves supplying a name for the test case and description (optional). choose the Run Test Case button to execute and evaluate the rules and action defined for the transaction. choose the Save for Later button to save the test case definition. Additionally. The first approver is the individual included in the Tax Approver group defined earlier in the test case. The first step in using the Test Workbench involves defining a new test case in AME. navigate to the testing workbench. Having the ability to evaluate and see the results of your AME . The SB Sales Tax Approval Rule was applied to this transaction because the invoice had a sales tax distribution line. This allows you to preview the results of your AME definitions to verify certain aspects such as:  • Are attribute values. From the workbench. Now that an invoice has beencreated. Choose the Run Real Transaction Test button. the Testing Workbench can be a very useful during the process of implementing and developing AME rules for invoice approval routing. Based on the results of the test. you must choose the Go button which retrieves information about your transaction. choose a test case against which the testing will be conducted. This transaction id as mentioned previously is the invoice_id from AP_INVOICES_ALL It is important to note that upon entering a transaction id. the approval list has been built correctly. it retrieves the values of all attributes that have been defined for the current transaction type. The next approver in the approval chain is the supervisor of the requester of the invoice. The AME Dashboard can be found under the Approvals Management Business Analyst role discussed earlier in the document. 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. it appears that the business test case was defined properly. 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.multiple actions for this action type would all pertain to traversal of the supervisor hierarchy. it is best to save the definition to the database first and then execute a test case after receiving the confirmation page below. AME Testing Workbench One of the very powerful features of the AME application is the Testing Workbench. m. Although a Run Test Case button is available at this point. The next screen prompts the user for the transaction id which AME uses to evaluate previously defined rules and generates an approver list. As previously stated. The invoice will be created to test the second business case rule defined earlier in the document. After entering a name for the test case and description. These values are consistent with the data entered for your invoice transaction. we can execute a test from the workbench to see if our AME components have been defined correctly and produce the results we expect. All of the defined actions would be grouped into an action type based on their relationship to the hierarchy being used. 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. The values of the header attributes are shown on the next page to demonstrate how AME retrieves and displays the values of the attributes. To execute a test against this invoice. each action that describes how many levels of a hierarchy to move up would be defined separate unto itself. After reviewing the values retrieved for the various attributes of the transaction. but would express in terms of how many levels to traverse. Typically. 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. In particular.

the workflow determines if the invoice transaction is fully matched to a purchase order. then the workflow tries to identify the first or next individual responsible for review and approval of the invoice. then the workflow ends and the approval status of the invoice is updated to Not Required. all invoices (manual and imported) are subject to invoice approval. If it is. The approval logic can best be explained by reviewing the Invoice Approval workflow. AME attempts to build an approver list based on the applied rule and the associated action type and actions that define the appropriate . the invoice falls into the workflow cycle. The workflow node Identify Approver is where AP and AME are integrated. Whenever AP is configured to use workflow. However. This is done by initially setting the approval status of the invoice to require. For any AME rule satisfied by the invoice transaction.setups using real transaction prior to implementation in a production environment is quite valuable. 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. Approval Logic When an invoice transaction falls into the approval workflow. if the invoice is not matched to a purchase order. n. 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. Once the invoice is validated and approval is initiated for the invoice either online or via the Invoice Approval Workflow concurrent program.

You can find the most recent patch for AME at site by using the Simple Search function under the Patches & Updates tab on Metal ink. The workflow itself remains active and continues to call AME as long as: There are more approvers left on the approver chain The workflow has not been rejected by any approver The workflow has not expired due to non-responses by an approver As you can see. the components that are defined in AME. there are some setup steps that must be completed in both the AME application as well as within the Payables applications. When the workflow begins. So for any invoices that fall into the category of not satisfying any approval rules. By default. AME.B is the latest RUP (Roll-Up Patch) available). the workflow ends and the status of the invoice remains ‘Initiated’. It is important to mention this because whenever an organization decides to require approvals of invoices.5. 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 invoices transactions. 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. then the workflow sends a notification to the first approver in the list. this could potentially prevent these invoices from ever being paid. . Modification to the workflow is beyond the scope of this document. Implementing AME for AP Invoice Approval In order to use AME to facilitate AP invoice approval routings. As of release 11. 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.approvers. In this case. This is the behavior of the AP Invoice workflow delivered with Oracle. the invoices cannot be paid until the invoice is approved. There are a couple of alternatives an organization could choose to resolve this issue. 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. the approval status of the invoice changes to ‘Initiated’. One the invoice is sent for approval either manually by the user online or via the Invoice Approval Workflow program. The setups that are described in this document are for the latest version of the AME applications. if the invoice transaction does not initially satisfy any approval rules in AME. AME Setup The first step in implementing AME is to install the AME application. If a successful approver list is built. One thing that is important to note is the behavior of AME and workflow for invoices that do not satisfy any predefined rule. especially the business rules have a direct impact on the approval routings within AP invoice workflow. AME comes seeded and is installed as part of the overall applications install. the approval status of any new invoices is set to ‘Required’. (As of this writing.9. o. The second alternative has to do with the setting of the mandatory attribute AT_LEAST_ONE_RULE_MUST_APPLY.

to access functions within the role in order to ‘activate’ access to the functions. This profile option change can be made under the System Administrator responsibility in the applications. The following roles are predefined in AME. rules and the testing workbench. then a specific access to this transaction type can be granted. if a business user is responsible only for the setup of the Payables Invoice Approval transaction type. conditions. 1 This role comes inherit will access to all of the components needed to develop AME rules. . the profile option AME: Installed must be set at the application level for Payables. thus allowing the user to only access and modify components of this one transaction type. In terms of AME. Approvals Management Administrator Approvals Management Analyst Approvals Management System Viewer Approvals Management System Administrator Approvals Management Process Owner Approvals Management Business Analyst1 Granting a role to a user does not automatically provide access to the setup components within AME. once a role has been granted to a user. For example.B. This includes attributes.The next step in setting up the application is to set up AME security. this means granting access to either all or a specific transaction type. 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. After the roles are granted and access is established. specific access must be granted. As part of the RBAC model. An AME role must be attached to the user account of any person utilizing AME to develop application business rules.

the Payables Options form. all of these setups are done from one form within the application module. Fortunately. 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 . there are some additional steps that must be done in the Payables application to enable AP invoice approval routing. There are three options on this form that dictate how Invoice Approval is facilitated in the Payables applications.AP Setup In addition to the setup steps that must be followed in the AME application. The Payable Options form is typically located under the Payables manager or equivalent responsibility in the applications.

including attributes.e. More importantly. The last option. Along with displaying an overview of the various transaction types that are currently defined. updated or deleted along with any rules that are slated to become active at a future date. Defining Business Case Scenarios In the current version of the AME application (AME. all invoices are set to require and must initially fall into the workflow cycle. the dashboard provides links to all of the setup components required when defining new business case rules in AME. 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. 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. Application specific guides. Whenever a business user begins the process of defining rules that represent organization business cases. 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 .) to discover what value in a particular transaction is used to represent the transaction id.approval workflow. Require Validation Before Approval requires that an invoice be fully validated before it can be placed in the workflow approval cycle. Metalink. the invoice_id in AP_INVOICES_ALL is used as the transaction type. As mentioned previously. when this option is enabled. which allows an invoice to be automatically approved without having go through the workflow cycle. the dashboard also displays any rules that have recently been defined. it is important to have an understanding of the transaction type of which business rules will be based.B). As part of this understanding. The next option is Allow Force Approval. conditions. etc. approver groups and rules. In the case of the Payables Invoice Approval transaction type. This allows a user to automatically set the approval status of an invoice to Approved. p.

For each of the following business case demonstrations. In the Payables Invoice Approval transaction type. In the case of invoice transaction. then require approvals up to the first supervisor Since this is an amount field. using the invoice_id will ensure that a single value will be retrieved. there is a required dynamic attribute defined for most if not all transaction types that contains the logic to retrieve this value. For this demonstration. there is the assumption that only one currency (USD) is used. The required attribute is TRANSACTION_REQUESTOR_PERSON_ID. Additionally. the paper assumes the HR supervisor hierarchy is used as the basis for building approval lists. the SQL statement must return the number using the . Remember. As far as determining the requester initiating a transaction. Business Case # 1: Require Approvals up 1 level from invoice requester for any invoice $100 or greater. q. Any approver lists that are built from an invoice transaction will begin using the requester id as the basis. an attribute must return a single value. the following components need to be defined: Attributes: Total Invoice Amount Condition: Total Invoice Amount >= $100 Rule: If Total Invoice Amount >= $100. the value of this attribute is retrieved by the following SELECT statement: Select requester_id From ap_invoices_all Where 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.the WHERE clause of the SQL statement used to retrieve the their value.

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. Rule: Total Invoice Amount >= $100. .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. we are only concerned with invoices that are $100 or more. In the business case.

then it is assumed the invoice has no sales tax lines. If the count returned is zero. 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’. then require pre-approval from the sales tax approver group. Condition: Sales Tax Present on Invoice > 0 ( SB_SALES_TAX_PRESENT is greater than 0) . along with the normal chain-ofauthority for any invoices greater than $100 with Sales Tax distribution Lines. Business Case # 2: Require approvals from the Tax Approver group. For this demonstration.r. the following components need to be defined: Attributes: Sales Tax Present on Invoice Total Invoice Amount (Already defined) Conditions: Sales Tax Present on Invoice > 0 Total Invoice Amount >= $100 (Already defined) Approver Group: Sales Tax Group Rule: If Sales Tax Present on Invoice > 0. Any value greater than zero is assuming the invoice has at least one or more sales tax lines.

any condition that is associated with a numeric attribute must define a lower and/or upper limit. then require pre-approval from the sales tax approver group. Additional people can be added or removed as needed. 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.As mentioned in the previous example. This approver group has been defined to include one employee in the approver group to represent the sales tax group. 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. Rule: If Sales Tax Present on Invoice > 0. 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.sqc' #include 'stdapi.sqc' #include 'hrctlnld.sqc' #include 'prcsapi. We need to include the SQC in the SQR program using #include function. 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. The first of which is the rule type associated with the rule which is a combination rule type.sqc' . For this rule. For this rule. There are a couple of items worth noting regarding this setup. notice that we are using both the most recently defined condition that counts the number of sales tax distributions lines.sqc' #include 'datwtime.sqc' #include 'curdttim. 6. Reusable Components SQCs are like functional library files which we can include in our SQR programs. Few important SQCs that need to be attached are: #include 'setenv. 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.sqc' #include 'prcsdefn. but also uses the previously defined condition that verifies whether the invoice amount is greater than $100. 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.

Preparation of Requirements document Leave scope for modifications to accommodate future changes 10. 4. 5. 11. pro-active and detail . Integration Management SQR is not an integration tool. Interface Complexity N/A Condition Table 1 Interface Complexity Light Medium N/A Heavy Elaborate 13. Access to all resources A clear idea of the SQR syntax while working on the requirements Thorough understanding of functionality or purpose SQR application is available and in place for use. Skill Set Primary Skills Generic Business Skills Acquaintance with SQR Strong organizational and time management skills. Excellent problem and incident management skills.7. This change request can be analyzed with the following list of impact parameters: o Volume and size of the transactions to a certain degree o Business Requirement as well as Interface complexity The above factors help in revising estimations. Tips and Techniques Not Applicable 12. Assumptions & Dependencies 1. 2. POC and Prototypes Not Applicable 8. 6. Additional Deliverables (Optional) Not Applicable 9. 3. Estimation Revisions In SQR estimation revisions take place whenever Client raises a Change Request. Typical candidate should be a self-starter.

com . 11. Prepared by and reviewed by should be mentioned.1 ii. 16. Table of content should be updated and should be correct. Version history should be properly maintained. B25324-01. Thorough review of the documents and templates Statements supplemented with supportive documents Criteria check to be authorized with measured/measurable estimates Version# and name of the document should be updated wherever required (check in footer as well). 8. Review comments should be captured in review template and tracked.oracle. White Papers Table 2 White Papers Title Oracle Approvals Management Implementation Guide Rel 11i Part No. is a tool for finding resources on the World Wide Web. References i. a popular search engine. Provide Reference FDD document name in Functional Description section. 5.B White Paper Link Metal ink Note 336901. mastery of the application comes through practice and experimentation. 7. Prior experience PeopleSoft Technologies working with 14.com http://www.orientated.1 Metal ink Note 289927.1 MetaLink Note 336901. 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. 4. Mention where these changes are going to be done. Conclusion It 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. Technical Review Criteria 1. Approvals Management Developers Guide Release AME. As with any other Oracle application. Official Website URL http://www. 9. Web Sites Table 3 Web Sites Title Google. 10. Review doc's name should: Should be decided. 2. 3. Hopefully. 15.google. 6.

peoplesoftcity.htm www.com/hr88books_eng/eng/psbooks/tsql/htm/tsql10.com/fin84books_eng/eng/psbooks/tpcr/htm/tpcr05.peoplesoftcity.htm .iii. Documents Table 4 Documents Title Understanding SQR messages Understanding Dates Meta SQL Document Link www.com/fin84books_eng/eng/psbooks/tsqr/htm/tsqr22.peoplesoftcity.htm www.

Not able to run the Report. Customers Table 5 Customers Customer Name RSMeans Corp. Oceaneering 3. Error on line 337: Owner’s Name NA Comments NA Dt.The Paragraph is not properly aligned in the Report. RSMeans Project 2. 3. 1.Close NA 2 SFS_R176 Weekly Report From Operations NA NA NA SFSPAYRL 3 Payroll Register NA NA NA .Its Showing Run Status as 'Processing' forever. Projects Table 6 Projects Project Title 1.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'.iv. Open Issues Table 7 Open Issues Sno IssueID Description 1 SFS_R188 Relieving Letter Status (Open/Close) 1.This Report is not running. Oceaneering IDEA RC Customer Type (PPP/P/G) G G G v.It should show only Terminated EE s.Active EE s are also coming in the EE Lookup page.Make Emplid Mandatory in the Run Control Page 2. IDEA RC Description Integration Between CRM and FIN Finance Module Finance Module 17.

SQR for PeopleSoft: Program Aborting.(SQR 3716) Error in SQL statement. Glossary Table 8 Glossary Term AME AP SSHR RUP RBAC Definition Oracle Approvals Management Oracle Payables Self-Service Human Resources Roll-Up Patch Oracle Role Based Access Model . 18. Errors were found in the program file.