0% found this document useful (0 votes)
238 views24 pages

Approvals Management Engine (AME) Integration With Advanced Global Intercompany Systems

Uploaded by

Siva Naga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
238 views24 pages

Approvals Management Engine (AME) Integration With Advanced Global Intercompany Systems

Uploaded by

Siva Naga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 24

Approvals Management Engine (AME) Integration with Advanced Global Intercompany

Systems
An Oracle White Paper

Page 1
EXECUTIVE OVERVIEW............................................................................................................................. 3
INTRODUCTION.......................................................................................................................................... 3
SCOPE........................................................................................................................................................ 3
Static Method:.............................................................................................................................................. 4
Step 1: Define Employee Hierarchy Setups..............................................................................................5
Step 2: Define Action Types for FUN Recipient Intercompany Transaction..............................................5
Step 3: Define Rules for FUN Recipient Intercompany Transaction..........................................................7
Step 4: Define Attributes for FUN Recipient Intercompany Transaction....................................................8
Step 5: Define Conditions for FUN Recipient Intercompany Transaction................................................12
Step 6: Define Approver Groups for FUN Recipient Intercompany Transaction......................................12
Step 7: Transaction Process................................................................................................................... 12
Dynamic Method:....................................................................................................................................... 16
Step 1: Define employee hierarchy setups.............................................................................................17
Step 2: Define Action Types for FUN Recipient Intercompany Transaction............................................18
Step 3: Define Rules for FUN Recipient Intercompany Transaction........................................................19
Step 4: Define Attributes for FUN Recipient Intercompany Transaction..................................................20
Step 5: Define Conditions for FUN Recipient Intercompany Transaction................................................22
Step 6: Define Approver Groups for FUN Recipient Intercompany Transaction......................................22
Step 7: Transaction Process................................................................................................................... 22

EXECUTIVE OVERVIEW

The purpose of this document is to familiarize the users of Oracle Advanced Global
Intercompany Systems (R12) with the Approvals Management (Hierarchical Approval) feature.
This document provides details on the Usage and Setup of Approvals Management
(Hierarchical Approval) for Intercompany Transaction Approval.

Page 2
INTRODUCTION

In release 12, Intercompany Transactions can be processed using Advanced Global


Intercompany System (AGIS). Advanced Global Intercompany System (AGIS) enables
integration with Approval Management to send Hierarchical Approval Notifications for
intercompany transactions. If Approval Management is not used, then system will send single
Approval Notification based on Security setups in Advanced Global Intercompany. Using
Approvals Management, system can send multiple Approval Notifications for approvals based
on Approvals Management Supervisor Hierarchy.

Note: - This functionality was introduced through the Patch 6995183

SCOPE
The scope of this Document is to understand the Integration of Approval Management with
Advanced Global Intercompany System. The document provides details on the usage and setup
of AME for intercompany transaction approvals. Please refer to Oracle Advanced Global
Intercompany System User's Guide and Oracle Approvals Management Implementation Guide
for more information.

While defining AME there are various options available for setting the approvals. However in this
whitepaper, we would be discussing the steps to define AME based on the Supervisor Level
approvals using the following usage attribute types:

1. Static Attribute Method


2. Dynamic Attribute Method

Static Method:
Processing Advanced Global Intercompany Recipient Transaction with Supervisor Hierarchical
Approval Notifications Static Method: -

A static use specifies a fixed value for the attribute, for all items and transactions. It is a common
practice to give static use to most or all of the mandatory attributes. A static use requires less
runtime overhead than a dynamic use. Also, static use expresses uniform business policies for
all transactions in a given transaction type.

Static Method involves the following steps

1: Define Employee Hierarchy Setups (Mandatory)

2: Define Action Types for FUN Recipient Intercompany Transaction (Mandatory)

Page 3
3: Define Rules for FUN Recipient Intercompany Transaction (Mandatory)

4: Define Attributes for FUN Recipient Intercompany Transaction (Mandatory)

5: Define Conditions for FUN Recipient Intercompany Transaction (Optional)

6: Define Approver Groups for FUN Recipient Intercompany Transaction (Optional)

7: Transaction process

Note: - Steps 5 and 6 are optional and hence not covered in this session. For more details
please refer Approval Management Engine (AME) Implementation guide

Step 1: Define Employee Hierarchy Setups


Navigation: HRMS Responsibility ->People ->Enter and Maintain

1. Define Supervisor Employee


2. Define Subordinate Employee

Employee: Employee id 31418 Supervisor: Employee id 31638

Step 2: Define Action Types for FUN Recipient Intercompany Transaction


Note: Add Approval Management Business Analyst Responsibility to the user

Navigation: Approval Management Business Analyst Responsibility -> Business Analyst


Dashboard

Page 4
Business Analyst Dashboard ->Select FUN Recipient Intercompany Transaction Setup button

Setup->Action Types->Select ‘Use Existing Action Type

From the Existing Action Type ->Select Supervisory Level

Page 5
Choose Apply button.

Step 3: Define Rules for FUN Recipient Intercompany Transaction


Navigation: Approval Management Business Analyst -> Business Analyst Dashboard ->Rules

Choose Add Action and then select Action type as ‘Supervisor level’ and select correct levels of hierarchy.

As per the setup shown in this white paper if ‘Require approvals up to the first two superiors’ is
selected then, first SAMMER will approve the AGIS transaction, after that notification will go to
supervisor SIVA. Once supervisor approves AGIS Batch then AGIS Batch status will change to
‘Approved’.

Page 6
Step 4: Define Attributes for FUN Recipient Intercompany Transaction
While defining AME with Static Method following two attributes are mandatory

1. SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID

2. TOP_SUPERVISOR_PERSON_ID

Navigation: Approval Management Business Analyst ->Business Analyst Dashboard->Setup>Attributes

Here select the options as follows:


Attribute Category : All

Item Class : All

Data Type : All

Name : SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID
Select GO Button and then Choose Update button for the attribute
SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID

Page 7
Here pass the following information

Description : Enter required description

Data Type : Number

Approver Type : HR People

Value Set : Blank

Usage Type : Select Static from drop down list

Value : Subordinate employee id

Here user needs to give starting point as Subordinate employee id. Based on the subordinate employee id
AGIS will get the Supervisor employee hierarchy setup details.

Page 8
2. TOP_SUPERVISOR_PERSON_ID

Navigation: Approval Management Business Analyst ->Business Analyst Dashboard-


>Setup>Attributes

Here select the options as follows


Attribute Category : All

Item Class : All

Data Type : All

Name : TOP_SUPERVISOR_PERSON_ID
Choose GO Button and then Select Update button for the attribute
TOP_SUPERVISOR_PERSON_ID

Here pass the following information

Page 9
Description : Enter required description

Data Type : Number

Approver Type : HR People

Value Set : Blank

Usage Type : Select Static from drop down list

Value : Supervisor employee id

And choose apply button.

Here user needs to give ending point as Supervisor employee id to close the approval
notifications.

Step 5: Define Conditions for FUN Recipient Intercompany Transaction

This Setup is not mandatory and hence not covered in this white paper. For more details please
refer Approval Management Engine (AME) Implementation guide.

Step 6: Define Approver Groups for FUN Recipient Intercompany


Transaction
This Setup is not mandatory and hence not covered in this white paper. For more details please
refer Approval Management Engine (AME) Implementation guide.

Step 7: Transaction Process


Navigation: Intercompany Super user Responsibility->Transactions->Inbound: Query the batch
number ‘70’

Page 10
Initiator Organization : SOracle Hyderabad

Recipient Organization : SOracle Bangalore

SOracle Bangalore AGIS Organization access given to Employee .Once Employee approves
recipient notification then final approval notification will goes to Supervisor.

In the above example batch number 70 was received by SOracle Bangalore for approval
Navigation: Intercompany Super user Responsibility->Transactions->Inbound

Transaction: 70 Approved by Employee and forwarded to subsequent approvals.

When the transaction submitted for further approval, you can see the following message
in the inbound page

Page 11
‘Your approval action for transaction 70 and recipient SOracle Bangalore has been
recorded. The transaction may be forwarded for subsequent approvals’.

As transaction is forwarded for further approval, the transaction status remains as


‘Received’.

Log in into applications as Supervisor User

Page 12
Navigation: General Ledger Super Responsibility->Others-> Notifications -> Open Notifications
>Select Go

Here Supervisor received notification for final approval from Subordinate General Ledger Super
->Others-> Notifications -> Open Notifications ->Select Update

Supervisor can now select the Approve button and complete the approval process.
Navigation: Intercompany Super user->Transaction->Inbound ->Query the Batch number 70

Page 13
Here Transaction status changed as ‘Approved’ because batch approved by the final
approver that is SIVA (Supervisor).

Dynamic Method:

Processing Advanced Global Intercompany Recipient Transaction with supervisor


Hierarchical approval notifications with Dynamic Method:

A dynamic use specifies an SQL query that AME executes at run time .This query fetches the
attribute's value for each item in the attribute's item class, for a given transaction. The execution
of dynamic attribute use constitutes the majority of AME's run time overhead. Therefore,
optimizing your dynamic use can have a big impact on AME's performance. Ensure you optimize
these queries thoroughly, especially if the Transaction type that owns them processes a high
volume of transactions.

Multiple users would be having the same initiator and recipient organization access. System
picks the approval hierarchy on the basis of the employee id of the user who would be creating
the transaction.

SOracle Hyderabad (Initiator) and SOracle Bangalore (Recipient) organization access was given
to INIT_USER, INIT_MGR, REPT_USER and REPT_MGR

• For INIT_USER, Supervisor is INIT_MGR

• For REPT_USER, Supervisor is REPT_MGR

If AGIS Transaction is created by INIT_USER then approval goes to INIT_MGR. Similarly if AGIS
Transaction is created by REPT_USER then approval goes to REPT_MGR.

Page 14
Dynamic Method involves the following steps:

1: Define employee hierarchy setups (Mandatory)

2: Define Action Types for FUN Recipient Intercompany Transaction (Mandatory)

3: Define Rules for FUN Recipient Intercompany Transaction (Mandatory)

4: Define Attributes for FUN Recipient Intercompany Transaction (Mandatory)

5: Define Conditions for FUN Recipient Intercompany Transaction (Optional)

6: Define Approver Groups for FUN Recipient Intercompany Transaction (Optional)

7: Transaction process

Step 1: Define employee hierarchy setups


Navigation: HRMS Responsibility ->People ->Enter and Maintain

1. Define Supervisor Employee (REPT MGR)


2. Define Subordinate Employee (REPT User)

Page 15
Supervisor: REPT MGR (Employee id 31742)

Employee: REPT User (Employee id 31741)

Step 2: Define Action Types for FUN Recipient Intercompany Transaction


Note: Add Approval Management Business Analyst responsibility to your user

Navigation: Approval Management Business Analyst -> Business Analyst Dashboard

Business Analyst Dashboard ->Select FUN Recipient Intercompany Transaction Setup button

Setup->Action Types->Select ‘Use Existing Action Type

Page 16
Select ‘Supervisory Level’ Action Type and choose ‘Apply’ button.

Step 3: Define Rules for FUN Recipient Intercompany Transaction


Approval Management Business Analyst -> Business Analyst Dashboard ->Rules

Page 17
Select Add Action and choose Action type as ‘Supervisory level’ and select correct levels of
hierarchy.

REPT User is the subordinate and REPT MGR is the Supervisor as per the Hierarchy. If
‘Require an approval up to the first two levels’ is selected then first REPT User will approve the
AGIS transaction, after that notification will go to supervisor REPT MGR. Once supervisor REPT
MGR approves AGIS Batch then AGIS Batch status will change to ‘Approved’.

Step 4: Define Attributes for FUN Recipient Intercompany Transaction


While defining AME with Dynamic method following attribute is mandatory

1. SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID

Approval Management Business Analyst ->Business Analyst Dashboard->Setup->Attributes

Here select the options as follows

Page 18
Attribute Category : All

Item Class : All

Data Type : All

Name : SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID

Select Go and then choose Update button for the attribute


SUPERVISORY_NON_DEFAULT_STARTING_POINT_PERSON_ID

Here enter the following information


Description : Enter required description

Data Type : Number

Approver Type : HR People

Value Set : Blank

Usage Type : Select Dynamic from drop down list


Value
: select employee_id from fnd_user where user_id = (select
last_updated_by from fun_trx_headers where trx_id = :transactionId)
Select Apply button.

Page 19
Step 5: Define Conditions for FUN Recipient Intercompany Transaction

This Setup is not mandatory and hence not covered in this white paper. For more details please
refer Approval Management Engine (AME) Implementation guide.

Step 6: Define Approver Groups for FUN Recipient Intercompany


Transaction
This Setup is not mandatory and hence not covered in this white paper. For more details please
refer Approval Management Engine (AME) Implementation guide.

Step 7: Transaction Process


Navigation: Intercompany Super user Responsibility->Transactions->Inbound. Query batch
number ‘88’. Batch 88 is created by the user REPT_USER.

Initiator Organization : SOracle Hyderabad

Recipient Organization : SOracle Bangalore

SOracle Bangalore organization access was given to REPT_USER. Once REPT_USER


approves recipient notification then final approval notification will goes to REPT_USER
(Supervisor). This approval path is based on the hierarchy of REPT_USER.

In the above example batch number 88 was received by SOracle Bangalore for approval.

Page 20
Select Update Transaction for Batch Number ‘88’

Select Approve button.

Transaction: 88 Approved by REPT_USER and forwarded to subsequent approvals.

When the transaction submitted for further approval, you can see the following message
in the Inbound Page

‘Your approval action for transaction 88 and recipient SOracle Bangalore has been
recorded. The transaction may be forwarded for subsequent approvals’.

Page 21
As transaction is forwarded for further approval the transaction status remains as
‘Received’

Login into application with Supervisor login ‘REPT_MGR’

General Ledger Super Responsibility->Others-> Notifications -> Open Notifications Open

the Notification form

Here Supervisor REPT_MGR, received final approval notification from Subordinate that is
REPT_USER

Page 22
General Ledger Super ->Others-> Notifications -> Open Notifications ->Select Update-> Choose
Approve

Supervisor (REPT_MGR) can now select the Approve button and complete the approval
process
Navigation: Intercompany Super user->Transaction->Inbound->Query Batch number 88

Here Transaction status changed as ‘Approved’ as batch approved by the final approver, SIVA
(Supervisor).

Page 23
White Paper Title: Approvals Management Engine (AME) Integration with Advanced Global Intercompany Systems
[NOV] 2011
Author: Sivaranganath Chittapragada, ISC Contributing
Authors:
Oracle Corporation
World Headquarters
500 Oracle Parkway Redwood
Shores, CA 94065 U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright © 2001 Oracle Corporation All rights reserved.

Page 24

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy