How to Configure AME in R12 –  Assign Roles & Create Grants for User
Oracle Approvals Management (AME) functionality is a self-service web application that allows users to
define rules for administering approvals of various types of transactions. Learn how easy it is to use this
powerful functionality to create complex approval scenarios that meet your unique business requirements.
Case studies of recent successful implementations will be presented for PO, AP and HR. Learn how to
accommodate individual employee signing limits, how to integrate workflow timeout functionality with AME.

Oracle Approvals Management (AME) is a self-service Web application that enables users to define business rules governing the process for approving transactions in Oracle Applications .This enables development of custom rules to manage transaction approvals that is integrated with multiple Oracle EBS applications such as HR, PO, AP and UMX.

If you want to migrate the AME setup like rules,conditions,approval groups etc. from one instance to another instance, you can use some of them by mean of FNDLOAD utility. The process is similar to what we are regularly using for other AOL Objects.

FNDLOAD will have such ldt file through which you can use.

Here are the details steps for each setup’s.

1. Condition:

The script that downloads AME conditions allows you to download all conditions for a given transaction type or only those associated with a particular attribute or group of attributes.

Download
FND_TOP apps/<apps password> 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesconk.lct <ldt filename> AME_CONDITIONS CONDITION_KEY=<condition key> TRANSACTION_TYPE_ID=<trans typs id> APPLICATION_SHORT_NAME=<application short name>

Upload
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesconk.lct <ldt filename>

Example:
FNDLOAD apps/<passwd>@sourcedb 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesconk.lct amecondition.ldt AME_CONDITIONS APPLICATION_SHORT_NAME=’PER’ TRANSACTION_TYPE_ID=’HRSSA’ ATTRIBUTE_NAME=’PROCESS_NAME’ CONDITION_KEY=’317772662:44552′;
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesconk.lct amecondition.ldt

2. Dynamic Approval group /Approver Groups:

An approver group can either be an ordered set of one or more approvers (persons and/or user accounts) or it can be a list, which is dynamically generated at rule evaluation time.

Download
FND_TOP apps/<apps password> 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesappg.lct <ldt filename> AME_APPROVAL_GROUPS APPROVAL_GROUP_NAME=<name of approval group> TRANSACTION_TYPE_ID=<trans typs id> APPLICATION_SHORT_NAME=<application short name>

Upload
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesappg.lct <ldt filename>

Example:
FNDLOAD apps/<passwd>@sourcedb 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesappg.lct ameapprovalgroup.ldt AME_APPROVAL_GROUPS APPROVAL_GROUP_NAME=’Dyn Apprv Hub Approval Group’ TRANSACTION_TYPE_ID=’HRSSA’ APPLICATION_SHORT_NAME=’PER’
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesappg.lct ameapprovalgroup.ldt

3. Dynamic Approval group config:

Download
FNDLOAD apps/<passwd>@sourcedb 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesaagc.lct ameapprovalgroupusage.ldt AME_APPROVAL_GROUP_CONFIG APPROVAL_GROUP_NAME=’Dyn. Post HROPs Approval Group’ TRANSACTION_TYPE_ID=’HRSSA’ APPLICATION_SHORT_NAME=’PER’

Upload
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesaagc.lct ameapprovalgroupusage.ldt

4. AME Rule:

An approval rule is a business rule that helps determine a transactions approval process. Rules are constructed from conditions and actions.

The AME rules can be downloaded for information about the rule (e.g. name, description, etc) along with associated conditions and rule type.

Download
$FND_TOP/bin/FNDLOAD apps/<apps password> 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesrulk.lct <ldt filename> AME_RULES RULE_KEY=<Rule Key > TRANSACTION_TYPE_ID=<trans typs id> APPLICATION_SHORT_NAME=<application short name>

#You can find Rule Key in AME_RULES table
Upload
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesrulk.lct amerule.ldt

Example:
FNDLOAD apps/<passwd>@sourcedb 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesrulk.lct amerule.ldt AME_RULES RULE_KEY=’317772662:54567′ TRANSACTION_TYPE_ID=’HRSSA’ APPLICATION_SHORT_NAME=’PER’
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesrulk.lct amerule.ldt

5. AME Rule Action Type Usage:

Download
FNDLOAD apps/<apps pw> 0 Y DOWNLOAD amesactu.lct <download file name>.ldt AME_ACTION_USAGES APPLICATION_SHORT_NAME=<FND application short name> TRANSACTION_TYPE_ID=<AME transaction type short name> [RULE_KEY=<Rule Key>]

# Rule Key is found in AME_RULES table
Upload
FNDLOAD apps/apps 0 Y UPLOAD amesactu.lct usage<download file name>.ldt

Ex:
FNDLOAD apps/<passwd>@sourcedb 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesactu.lct ameactionusage.ldt AME_ACTION_USAGES RULE_KEY=’317772662:54567′ TRANSACTION_TYPE_ID=’HRSSA’ APPLICATION_SHORT_NAME=’PER’
FNDLOAD apps/<passwd>@destinationdb 0 Y UPLOAD $PER_TOP/patch/115/import/amesactu.lct ameactionusage.ldt

6. Transaction Types

An application that uses AME to govern its transactions’ approval processes is termed an integrating application. An integrating application may divide its transactions into several categories where each category requires a distinct set of approval rules. Each set of rules is called a transaction type. Different transaction types can use the same attribute name to represent values that are calculated in different ways or fetched from different places.

Download
FNDLOAD apps/<apps pwd> 0 Y DOWNLOAD amescvar.lct <download file name>.ldt AME_CALLING_APPS APPLICATION_SHORT_NAME=<FND application short name> TRANSACTION_TYPE_ID=<AME transaction type short name>

Upload
FNDLOAD apps/<apps pwd> 0 Y UPLOAD amescvar.lct <download file name>.ldt

Eg:
FNDLOAD apps/apps 0 Y DOWNLOAD amescvar.lct hubtrantype.ldt AME_CALLING_APPS APPLICATION_SHORT_NAME=SQLAP TRANSACTION_TYPE_ID=SBTRANSTYPE
FNDLOAD apps/apps 0 Y UPLOAD amescvar.lct hubtrantype.ldt

7. Attribute

Attributes are business variables with a single value for a particular transaction. 
Download

FNDLOAD apps/<apps password> 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesmatt.lct <ldt filename> AME_ATTRIBUTES ATTRIBUTE_NAME=<attribute name> TRANSACTION_TYPE_ID=<trans typs id> APPLICATION_SHORT_NAME=<application short name>

Upload
FNDLOAD apps/<apps pwd> 0 Y UPLOAD amesmatt.lct <ldt download file name>

Example:
FNDLOAD apps/apps 0 Y DOWNLOAD amesmatt.lct hubattributes.ldt AME_ATTRIBUTES APPLICATION_SHORT_NAME=SQLAP
TRANSACTION_TYPE_ID= SBTRANSTYPE ATTRIBUTE_NAME=SB_CUST_ATTRIBUTE
FNDLOAD apps/apps 0 Y UPLOAD amesmatr.lct hubattributeusages.ldt

8. Attribute Usage

Download
FNDLOAD apps/<apps password> 0 Y DOWNLOAD $PER_TOP/patch/115/import/amesmatr.lct <ldt filename> AME_ATTRIBUTE_USAGES ATTRIBUTE_NAME=<attribute name> TRANSACTION_TYPE_ID=<trans typs id> APPLICATION_SHORT_NAME=<application short name>

Upload 
FNDLOAD apps/<apps pwd> 0 Y UPLOAD amesmatr.lct <download file name>.ldt

Example:
FNDLOAD apps/apps 0 Y DOWNLOAD amesmatr.lct hubattributeusage.ldt AME_ATTRIBUTE_USAGES aPPLICATION_SHORT_NAME=SQLAP
FNDLOAD apps/apps 0 Y UPLOAD amesmatr.lct hubattributeusages.ldt

How often do you create a XML publisher definition with a wrong Codes (Template or Data Definition)? Or you want to change the Code so that it is more meaningful?
Due to some typo error or to give some more meaningful name as per the standards, you can’t change those fields later. Also you can’t delete them too. Oracle recommends to disable them by giving an end date. But many developers don’t like to leave the wrong stuff in the system. They better like to delete them and freshly recreate them.

Why Oracle has restricted to Update or Delete?
The reason is concurrent program with XML output matches the Short Name with the template Code to find out which XML Publisher template to use for post processing. If you delete this template, the Post Processor cannot find the template, and then give errors. So it is always better not to give an option to update or delete.

But we have this workaround to update or delete the template or data definitions using scripts. It is highly recommend to run first in development instances.

Before the workaround, let’s look at the main tables that store the information of the Data Definitions and Templates.

1. XDO_DS_DEFINITIONS_B: table for storing data source definition represented by XML Schema Definition (XSD). Each data source has one or more elements, and this information are stored in XDO_DS_ELEMENTS_B.
2. XDO_DS_DEFINITIONS_TL: translation table for XDO_DS_DEFINITIONS_B.
XDO_LOBS: This table is used for storing locale (language and territory) sensitive binary and text files. It is mainly used for storing language layout templates.
3. XDO_CONFIG_VALUES: stores the values of XML Publisher configuration properties entered from the Oracle Applications interface.
4. XDO_TEMPLATES_B: table for template information. Each template has a corresponding data source definition stored in the XDO_DS_DEFINITIONS_B. Each translation of a certain template, not each template, has a corresponding physical template file. The physical template file information is stored in the XDO_LOBS.
5. XDO_TEMPLATES_TL: translation table for XDO_TEMPLATES_B.

–Code Tested in R12.1.3 Instance
SET SERVEROUTPUT ON;
DECLARE
— Change the following two parameters
var_templateCode    VARCHAR2 (100) := ‘ORACLEERPAPPSGUIDE’;     — Template Code
boo_deleteDataDef   BOOLEAN := TRUE;     — delete the associated Data Def.
BEGIN
FOR RS
IN (SELECT T1.APPLICATION_SHORT_NAME TEMPLATE_APP_NAME,
T1.DATA_SOURCE_CODE,
T2.APPLICATION_SHORT_NAME DEF_APP_NAME
FROM XDO_TEMPLATES_B T1, XDO_DS_DEFINITIONS_B T2
WHERE T1.TEMPLATE_CODE = var_templateCode
AND T1.DATA_SOURCE_CODE = T2.DATA_SOURCE_CODE)
LOOP
XDO_TEMPLATES_PKG.DELETE_ROW (RS.TEMPLATE_APP_NAME, var_templateCode);

DELETE FROM XDO_LOBS
WHERE     LOB_CODE = var_templateCode
AND APPLICATION_SHORT_NAME = RS.TEMPLATE_APP_NAME
AND LOB_TYPE IN (‘TEMPLATE_SOURCE’, ‘TEMPLATE’);

DELETE FROM XDO_CONFIG_VALUES
WHERE     APPLICATION_SHORT_NAME = RS.TEMPLATE_APP_NAME
AND TEMPLATE_CODE = var_templateCode
AND DATA_SOURCE_CODE = RS.DATA_SOURCE_CODE
AND CONFIG_LEVEL = 50;

DBMS_OUTPUT.PUT_LINE (‘Selected template has been ‘ || var_templateCode || ‘ deleted.’);

IF boo_deleteDataDef
THEN
XDO_DS_DEFINITIONS_PKG.DELETE_ROW (RS.DEF_APP_NAME,
RS.DATA_SOURCE_CODE);

DELETE FROM XDO_LOBS
WHERE LOB_CODE = RS.DATA_SOURCE_CODE
AND APPLICATION_SHORT_NAME = RS.DEF_APP_NAME
AND LOB_TYPE IN
(‘XML_SCHEMA’,
‘DATA_TEMPLATE’,
‘XML_SAMPLE’,
‘BURSTING_FILE’);

DELETE FROM XDO_CONFIG_VALUES
WHERE     APPLICATION_SHORT_NAME = RS.DEF_APP_NAME
AND DATA_SOURCE_CODE = RS.DATA_SOURCE_CODE
AND CONFIG_LEVEL = 30;

DBMS_OUTPUT.PUT_LINE (
‘Selected Data Defintion has been ‘ || RS.DATA_SOURCE_CODE || ‘ deleted.’);
END IF;
END LOOP;
COMMIT;
EXCEPTION
WHEN OTHERS
THEN
ROLLBACK;
DBMS_OUTPUT.PUT_LINE (
‘Unable to delete XML Publisher Template ‘ || var_templateCode);
DBMS_OUTPUT.PUT_LINE (SUBSTR (SQLERRM, 1, 200));
END;
/

We are very pleased to announce that Oracle E-Business Suite Release 12.2 is generally available for download now:
  • EBS 12.2 represents our most-groundbreaking release in years (Press Release).  It includes new product functionality, new Fusion Middleware and database components, and introduces new tools for installing, configuring, and maintaining E-Business Suite environments:

    Hundreds of new features

    Includes significant enhancements across the integrated suite of business applications spanning enterprise resource planning, human capital management, and supply chain management.  You can find the complete list here:
    Online Patching
    Apply EBS patches while users are still entering transactions and using the E-Business Suite.  Online Patching uses the Oracle Database’s Edition-Based Redefinition feature and other new technologies to allow the E-Business Suite to be updated while the system is still running. You can learn more about Online Patching via our official documentation and this technical webcast.
    WebLogic Server
    Uses Oracle WebLogic Server, which replaces the Oracle Containers for Java (OC4J) application server used in EBS 12.0 and 12.1.  You can learn more about how this improves the system administration experience via our official documentation and this technical webcast.

    Streamlined installation

    • Option for installing EBS 12.2 on to existing database servers.
    • Capability of installation into existing Real Application Clusters environments.
    • Database deployment on Automatic Storage Management (ASM) and other file systems.
    Upgrading to EBS 12.2
    Is there a direct upgrade path from EBS 11i to 12.2?

    Yes, there is a direct upgrade path from EBS 11.5.10.2 to EBS 12.2.  EBS 11.5.10.2 customers do not have to install an intermediary EBS 12 release (such as 12.1.3) before upgrading to EBS 12.2.  EBS 11.5.10.2 customers must have applied the minimum baseline patch requirements for Extended Support as described in Patch Requirements for Extended Support of Oracle E-Business Suite Release 11.5.10 (Document 883202.1). Customers on earlier EBS 11i releases (such as 11.5.7) need to be at the 11.5.10.2 level plus the minimum baseline patch requirements for Extended Support before they can upgrade to EBS 12.2.
    Is there a direct upgrade path from EBS 12.0 to 12.2?

    Yes, there is a direct upgrade path from EBS 12.0.4 and 12.0.6 to EBS 12.2.  EBS 12.0.4 or 12.0.6 customers do not have to install an intermediary EBS 12 release (such as 12.1.3) before upgrading to EBS 12.2.  Customers on earlier EBS 12.0 releases (such as 12.0.3) will need to be at the 12.0.4 or 12.0.6 level before they can upgrade to EBS 12.2.
    Is there a direct upgrade path from EBS 12.1 to 12.2?

    Yes, there is a direct upgrade path from EBS 12.1.1, 12.1.2, and 12.1.3 to EBS 12.2.
    How can I prepare for EBS 12.2?
      More technical references
    (MLS) is a feature in Oracle E-Business (EBS) Suite of applications that enables users to run their applications in many different languages. MLS has opened the doors for global rollout of Oracle EBS with users in different countries able to use the application in their own language at the same time.
    MLS patch application
    Multi Language patches can be applied in Oracle as per the metalink note, R11i / R12 : Requesting Translation Synchronization Patches (Doc ID 252422.1). This metalink note has got references to other notes for applying NLS patches.
    Difference between NLS and MLS
    National Language Support (NLS) refers to the ability of Oracle EBS to run in any one of the supported languages other than American English. However, MLS refers to the ability in which the instance can be run in as many as languages as are supported at the same time.
    Once MLS patches have been applied in Oracle by the DBAs the developers have to keep a few more points in mind while developing custom components.
    • FND_LANGUAGES table shows which languages are installed, and which is the base language and which are non-base languages (Installed Languages)
      Query to identify which language(s) have been installed
    SELECT LANGUAGE_CODE, INSTALLED_FLAG FROM FND_LANGUAGES
    If the value of INSTALLED_FLAG is I then that language has been installed. If the value of INSTALLED_FLAG is B then it is the base language. By default, language_code is US is the base language.
    Example
    Execute the following query,
    SELECT * FROM FND_LANGUAGES where installed_flag IN (‘I’, ‘B’)
    • The Translated tables (*_TL) contain one record for each language i.e the translated string for each language.
    • Translated views (*_VL) have been introduced for the “_TL” tables, which allow concurrent programs to select data based on the session language without running the risk of returning more rows than expected using a condition within the view query like,t.LANGUAGE= USERENV(‘LANG’)
    Hence the view FND_CONCURRENT_PROGRAMS_VL will return rows as per the session language settings.
    Note:
    If queries are executed from SQL*Plus on the _VL views without setting the session language then no rows will be returned. This is explained in this article.
    Example
    If we query for concurrent_program_id, 20125, i.e. the program named Trial Balance, from the table FND_CONCURRENT_PROGRAMS_TLwe get the program name in all installed languages.
    Querying the same concurrent_program_id from the corresponding _VL view, FND_CONCURRENT_PROGRAMS_VL gives us only 1 record.

    MLS development guidelines

    A list of general guidelines has been drawn up for developing technical components which will be display more than 1 language.

    User messages

    • All user message (labels/pop ups) are to be derived from translation tables or from fnd message.
    User message from the following,
    • Form item labels
    • Report item labels
    • Pop up messages
    • Concurrent program output
    • Workflow notifications
    • Form personalizations
    Example
    After the MLS patches have been applied open the Messages form.
    Responsibility: Application Developer
    Navigation: Application > Messages
    Query for the seeded message named, ABORT.
    Notice that the same message has been ported into as many messages as there are installed languages. The value has also been translated. Thus if a piece of code picks up the message text from a message it will only have pick up the message text based on the language and the code need not be changed at all.

    SQL Queries

    • SQL queries should access data from _TL tables or _VL tables and have the following WHERE clause
      t.LANGUAGE= USERENV(‘LANG’)
    An example of this incorrect usage is demonstrated here.


    XML Publisher reports

    • There are 2 ways to develop XML Publisher report templates
    1. Each report will have as many templates as the number of languages it is expected to run on.
    2. Single template across all languages where the labels will also be derived from fnd messages or translation tables
      Single template Multiple template
      Advantage
      • 1 single file to be maintained
      • Modification/Addition of business logic or layout is simple
      • No business logic required to display template associate with language. It is configured in Oracle.
      Disadvantage
      • Modification/Addition of business logic or layout in the template is difficult
      • Business logic required to display the template associated with the language
      • Multiple files to be maintained
    Example
    Single template example
    The developer is allowed to upload as many translatable files as there are installed languages in Oracle.
    In this example there are 6 different language translations for a single template.
    Multiple template example
    You can also have multiple templates for a single report based on a language
    In this case there is no need to have a separate translation file.


    SQL Loader

    Application File System

    • Once the MLS patches have been applied to Oracle a set of directories are created in Unix under reports, forms, etc directories with the 2 character language code.
      • For instance, if patch for Spanish has been applied in Oracle a new set of folders will be created, like $GL_TOP/reports/ES, $AP_TOP/forms/ES
      • The point to keep in mind here is that any custom component created with specific changes for a language must be dropped to the language specific directory.
      • All translatable files reside in a subdirectory which has the language code incorporated in the name (e.g. $AP_TOP/reports/EL, $GL_TOP/forms/F etc.) .
      – Forms, Reports, Messages & Seeded data are translated
    Example
    If you check $AU_TOP/forms directory in Unix you will find several directories
    Now there is 1 directory to keep the same form in a different language. It is the same in all the seeded top directories, e.g. GL_TOP, AP_TOP, etc.

    NLS parameters in functions

    Many Oracle functions have MLS versions. The versions are listed below.
    • TO_DATE
      • NLS_DATE_LANGUAGE
      • NLS_CALENDAR
    • TO_NUMBER
      • NLS_NUMERIC_CHARACTERS
      • NLS_CURRENCY
      • NLS_DUAL_CURRENCY
      • NLS_ISO_CURRENCY
    • TO_CHAR
      • NLS_DATE_LANGUAGE
      • NLS_NUMERIC_CHARACTERS
      • NLS_CURRENCY
      • NLS_ISO_CURRENCY
      • NLS_DUAL_CURRENCY
      • NLS_CALENDAR
    • TO_NCHAR
      • NLS_DATE_LANGUAGE
      • NLS_NUMERIC_CHARACTERS
      • NLS_CURRENCY
      • NLS_ISO_CURRENCY
      • NLS_DUAL_CURRENCY
      • NLS_CALENDAR
    • NLS_UPPER
      • NLS_SORT
    • NLS_LOWER
      • NLS_SORT
    • NLS_INITCAP
      • NLS_SORT
    • NLSSORT
      • NLS_SORT

    Example of usage

    TO_NUMBER (’13.000,00′, ’99G999D99″,’nls_numeric_characters = ”,.”’)
    Where:
    ’99G999D99″ –The format mask for the number
    ‘nls_numeric_characters = ”,.”” –The thousands and decimal separator to be used
    The query
    select TO_NUMBER (’13.000,00′, ’99G999D99′,’nls_numeric_characters = ”,.”’) Num from dual
    will return
    13000

    Example of error message after applying MLS patches

    Once the MLS patches were applied on a particular Oracle instance a DFF value started throwing errors. The error is displayed below.
    The error message is the following,
    The value ROW for value set ****** OE Shipment Priority occurs in more than one row in column LOOKUP_CODE of table FND_LOOKUP_VALUES and duplicate values are not allowed. Please choose a different value or contact your system administrator.
    The reason for this error is,
    • The LOV associated with the DFF segment has not been correctly coded with regards to translations.
    If we look into the value set definition for the DFF segment we find that the LOV is based on the table, FND_LOOKUP_VALUES.
    As the Oracle instance now has MLS patches the table FND_LOOKUP_VALUES now can contain the same values across languages. We have 2 options to overcome the error faced by the user.
    1. We can add LANGUAGE= USERENV(‘LANG’) in the Where/Order By region to pick up the value based on the user’s language
    2. We can change the table name to FND_LOOKUP_VALUES_VL instead of FND_LOOKUP_VALUES