Explore topic-wise InterviewSolutions in .

• I heard people saying this..But it all depends on what customizations.
• You can move only the customizations around identifying the APPROVER and sending notifications.
• Assume you are using normal routing approval method (WITHOUT AME) and there is a customization for the Requisition to be APPROVED by the department head in case the amount more than 10000$ we can’t move only this customization to AME.
• If the requisition system is moved to AME then only we can HANDLE this requirement with a AME rule and avoid customization.

AME doesn't have any feature to send NOTIFICATIONS. It is responsibility of CALLING application of SENDING notification, CAPTURING the RESPONSE and updating AME with response.

AME doesn't have any feature to send notifications. It is responsibility of calling application of sending notification, capturing the response and updating AME with response.

• Terminations (of the INITIATORS) are not handled efficiently though AME would rebuild the chain of approval after each approval.
• Not possible to create CUSTOM AME responsibilities because of RBAC LIMITATIONS other than the 2 seeded responsibilities – ‘APPROVALS Management Administrator', 'Approvals Management Business Analyst'.
• It is not possible to have ‘NOTIFICATION Timeouts with Reminders’ within AME.

• It is an optional setup. REQUIRED only when additional APPROVERS are required for PARTICULAR conditions.
• The rules defined for the transaction can be based on Approver Groups, JOBS defined in HR setup, or Positions defined in HR setup Additional approvers are added here.

• An action type is a COLLECTION of actions having SIMILAR functionality.
• Every action belongs to an action type. Action TYPES are enabled or DISABLED for a particular transaction type.
• Voting method (or regime) decides how the RESPONSES to the action types are treated.

• Attributes are the BASE element for an AME Rule. ATTRIBUTE values are retrieved from the EBS Applications database.
• AME is seeded with attributes relevant to the transaction type and the user can CREATE new attributes in AME for use in AME rule.

The APPROVAL process for the NEWLY created transaction type can be setup USING ‘Approvals Management BUSINESS Analyst’ RESPONSIBILITY.

The approval process for the newly created transaction type can be setup using ‘Approvals Management Business Analyst’ responsibility.

A new transaction TYPE can be created using ‘Approvals MANAGEMENT Administrator’ RESPONSIBILITY.

A new transaction type can be created using ‘Approvals Management Administrator’ responsibility.

• AME RESTRICTS access to transaction types using Data Security. GRANT users access to the transaction types using the Grants page.
• Login as ‘Functional Administrator’ responsibility & click on ‘CREATE Grant’.

Login as ‘System ADMINISTRATOR’ (not a responsibility) & navigate to ‘User MANAGEMENT > Users > Query the user and CLICK Update > Search & Add the AM Admin roles as shown below.

Login as ‘System Administrator’ (not a responsibility) & navigate to ‘User Management > Users > Query the user and click Update > Search & Add the AM Admin roles as shown below.

• APPROVE
• REJECT
• RETURN

• 11i8/9 11i10
• E-Records (ERES) User Management iSupplier
• Quoting ODM – BOM Sourcing
• Accounts Payable ODM – Engineering iProcurement
• Credit Management ODM – Inventory R12
• iExpenses ODM – Quality MGT E-Tax
• Lease Management ODM – Receiving Grants
• iRecruitment ODM – WIP Core Pay
• TRAINING Administration (SS) AR – Credit Memo Public Sector
• Self Service HR (4.1) Internal Controls Mgr Proposals
• OPM – Inventory OTA – Learner UI Distribution
• OPM - New Product Dev OTA – MANAGER UI GL-Journals
• OPM – Process EXECUTION iAssets (Transfer) Account Planning
• OPM – Quality Mgt. Deal Registration Service Contracts
• Oracle Partners Mgt REFERRAL Management Collections
• AR – Credit Mgt PO - Requisitions Incentive Comp

AME can be used to derive lists of approvers based on user DEFINED RULES and maintain a history of approver’s statuses when:-

1. Transferring employees from one division/cost CENTRE to another
2. Authorizing expenses
3. Paying invoices
4. Approval of Purchase Requisition
5. MUCH more – review EBS Module INTEGRATION List

AME can be used to derive lists of approvers based on user defined rules and maintain a history of approver’s statuses when:-

• AME is a simple to use Rules ENGINE for Defining Approval Policy.
• AME is generic engine can be used where no integration currently exist, EVEN with non EBS modules.
• Standardizing on one engine reduces costs for customer as well as consulting since only one set of skills required.
• None or only minimal CODING required to setup rules.

The following features cannot be used with AME based Requisition Approval Workflow:

• Notification Timeouts with REMINDERS.
• The Forward Documents FORM cannot be used with Notifications pending approval that were SENT via Requisition Approval Workflow with AME.
• The Notifications that are sent only have Approve and Reject response actions. Forward and Approve and Forward are not available at this TIME.

The following features cannot be used with AME based Requisition Approval Workflow:

No. Approval Rules setup in AME will be used across all Operating Units.

If it is necessary to not have rules work in a particular Operating UNIT, there are two ways to do this:

• Turn off AME in that particular Operating Unit.
• Create a rule that excludes that particular Operating Unit from the rule.

1. Based on a ATTRIBUTE for operating unit and having different rule with CONDITIONS such that different rule will be applicable for different operating unit.
2. USING a DYNAMIC group in rules: The group used returns appropriate user based on operating unit.

No. Approval Rules setup in AME will be used across all Operating Units.

If it is necessary to not have rules work in a particular Operating Unit, there are two ways to do this:

List of Rules Types are listed below with EXPLANATION:

List-Creation Exception Standard creation of approval list, EXCLUDING a specified condition

Example: Have requisitions between $0 and $1000 approved by up to at most 3 levels except in the Deliver to Location V1 New York).

List MODIFICATION creates a standard list-creation rule with some TYPE of modification to that rule.

Example: If two rules are required such as:

INVOICE amount > $10K go up to VP lst

Post List Approval Group – This approval group will be appended to the end of the chain of authority approval list.

List of Rules Types are listed below with Explanation:

List-Creation Exception Standard creation of approval list, excluding a specified condition

Example: Have requisitions between $0 and $1000 approved by up to at most 3 levels except in the Deliver to Location V1 New York).

List Modification creates a standard list-creation rule with some type of modification to that rule.

Example: If two rules are required such as:

Invoice amount > $10K go up to VP lst

Post List Approval Group – This approval group will be appended to the end of the chain of authority approval list.

Voting REGIME is region that can be SETUP in AME when creating an Approval Group. There are four CHOICES available in the Voting Regime region.

They are:

• Series
• Consensus
• First Responder Wins
• Order NUMBER

Voting Regime is region that can be setup in AME when creating an Approval Group. There are four choices available in the Voting Regime region.

They are:

This is done in the Setup Document Type FORM in Core Purchasing.

The following Approval Transaction Types are seeded and SUPPORTED:

• PURCHASE_REQ = Purchase REQUISITION
• INTERNAL_REQ = Internal Requisition
• RCO = Requestor CHANGE ORDER

This is done in the Setup Document Type Form in Core Purchasing.

The following Approval Transaction Types are seeded and supported:

Yes, approval rules can be defined once and be‚ leveraged across multiple products, requiring less maintenance WORK. ADDITIONALLY approval rules can be easily extended without having to CUSTOMIZE the application or the WORKFLOW.

Yes, approval rules can be defined once and be‚ leveraged across multiple products, requiring less maintenance work. Additionally approval rules can be easily extended without having to customize the application or the workflow.

In 11.5.10 only SERIAL APPROVAL is SUPPORTED. PARALLEL approval is supported in R12.

In 11.5.10 only serial approval is supported. Parallel approval is supported in R12.

First, customers using any of the financials products but not ORACLE HR also install “SHARED HR,” which is a “lite” version of the HR product that includes the common entities that are needed by all applications. These include ORGANIZATIONS, locations, jobs, positions, and PEOPLE. AME will work with Shared HR. Customers do not need to apply the HR Family Pack if they do not install any of the HRMS applications. They will need to set up the people, jobs, or positions that they want to include in their approval rules.

First, customers using any of the financials products but not Oracle HR also install “Shared HR,” which is a “lite” version of the HR product that includes the common entities that are needed by all applications. These include organizations, locations, jobs, positions, and people. AME will work with Shared HR. Customers do not need to apply the HR Family Pack if they do not install any of the HRMS applications. They will need to set up the people, jobs, or positions that they want to include in their approval rules.