AME Profile Option For Integration Application

AME:Installed Is the Profile Option Used to Integrate the AME and Integrating Application.

This user profile is predefined by AME and is available for integrating applications

It is set at the application level and can be used by that application to determine if AME is installed and if so what action to take.

Setting Up AME Security for Role Bases access Control User Access

Access Model has Five Predefined Roles.

• Approvals Management Administrator

• Approvals Management Analyst

• Approvals Management System Viewer

• Approvals Management System Administrator

• Approvals Management Process Owner

            Each of the five predefined roles has a specific set of functional grants. The grants provide users access to AME. 

                To enable functional grants, you must assign roles to users using the User Management page.

Assigning Roles to Users.

 Select the User Management responsibility

Select the Users page

Search for the user to whom you wish to grant AME roles

Click on Assign Roles and Select Appropriate Required Roles  .

Provide Justification and Click on Apply and Save.

Grant User Data Access

Choose Functional Administrator Responsibility.

Select the Grants tab.

Select Create Grants.

Enters a Grant Name  . Choose Grantee type as Specific User and Grantee As USER Name for Which the Grants to be Given.

  Click Next 

Select Appropriate Data Context Type.

Click Next 

Select Permission Set That Defines grantee's Access.

Click Next Review and Finish.

Approvals Management Engine - An Overview

          The purpose of Oracle Approvals Management (AME) is to define approval rules that determine the approval processes for Oracle applications.

Approval Rules

An approval rule is a business rule that helps determine a transaction's approval

process. Rules are constructed from conditions and actions.

For example an approval rule can be as follows:

Ifthe transaction's total cost is less than 1,000 INR, and the transaction is for travel expenses,

then get approvals from the immediate supervisor of the person submitting the transaction.

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

This allows several transaction types to share approval rules.

  

How To Solve "There is no valid navigations for this responsibility" In User Management Responsibility

Issue :

   When Navigating to User Management Following Error Occurs.

Solution:

Log into the applications as 'SYSADMIN' User

Choose User Management responsibility and navigate to Users Web Page.

Search and find the user you want to inherit the Security Administrator and Customer Administrator Roles.

Click on Update Icon

Click on Assign Roles button

Find and choose 'Security Administrator' Role.

Repeat the Steps  for 'Customer Administrator' Role.

Enter A Justification for Role Inheritance and Apply and Save.

Login With the User Name For Which the Roles Has been Assigned and Check.

Return To Vendor With Automatic Debit Memo (India Localization)

This Blog Will Be Setup and Transaction Guide for Return to Vendor With Automatic Debit Memo (India Localization)

Pre Requisites

Create supplier with Additional info.

In Purchasing tab of supplier “Create debit memo on RTS transaction” to be enabled for automatic debit memo creation.






Always provide “Return To” as Supplier in return form even tough routing shows inspection required.



Invoice with taxes should be available for creating debit memo for the same purchase order.

Profile Option

PO:Enable automatic debit memo to be set as yes.

Concurrent:

India to insert Taxes in pay on receipt invoice to be run after debit memo creation.

Steps

1. Complete receipt , VAT /Excise Claim and Pay on Receipt Invoice Generation With Taxes.

2. If Returns to be Done, Go to I/L→ Receipt→ Return to Vendor New.

3.Provide PO and Release and Find the Returns .

4.Select Return to as “Supplier” and Check Whether “Create Debit Memo” is Enabled.

5. Save the Transaction .This Will Trigger the Concurrents

  I.Receiving Transaction Processor

  II.India - Receiving Transaction Processor for Return To Receiving (India - Receiving Transaction Processor)

6.Again Open the Returns Form and Now Find the Receipt No.

Process Action : Generate and Default the Line and save. A batch No Will be Generated.

A Debit Memo Would Be Created Without Taxes .

Now Run Concurrent : India - To insert taxes for Pay On Receipt.

Taxes Will Be Created in Debit Memo.

An Introduction About Procure To Pay Cycle

             Purchase-to-pay, often abbreviated to P2P and also called req to cheque, refers to the business processes that cover activities of requesting (requisitioning), purchasing, receiving, paying for and accounting for goods and services.

          Purchase-to-pay systems automate the full purchase-to-payment process, connecting procurement and invoicing operations through an intertwined business flow that automates the process from identification of a need, planning and budgeting, through to procurement and payment.

              Procure-to-pay is a term used in the software industry to designate a specific subdivision of the Procurement process.

              Procure-to-pay systems are designed to provide organizations with control and visibility over the entire life-cycle of a transaction – from the way an item is ordered to the way that the final invoice is processed – providing full insight into cash-flow and financial commitments. 

          Most of the companies using these systems look for a Centralization of their procurement department, or to set up a Shared Services organization for the same purpose.

Procure To Pay Cycle

Oracle Procure To Pay Process

Processing Constraint

Processing constraints are rules that control

1.who can change

2.What Can be Changed

3.when they can change

              Processing constraints can prevent certain changes, but can also be set up to perform actions based on those changes.

               They can define actions that can result from these changes, such as requiring a reason for the change, triggering an action in Audit Trail or Versioning, or raising an Integration Event.

Who can make changes

               Based on responsibility. A constraint (rule) may apply to all responsibilities, to only a list of constrained responsibilities or to all except a list of authorized responsibilities. 

What Can be Changed

• Order Header
• Order Line
• Order Sales Credit
• Line Sales Credit
• Order Price Adjustment
• Line Price Adjustment
• Order Payment
• Line Payment
• Sales Agreement Header
• Sales Agreement Line.

When they can change 

             The conditions must be collectively true for the constraint to Allow or prevent the changes. The conditions may be based on either the state of a workflow activity (where the entity is in the flow) or a value in a table.

             A condition may also be based on a custom API, which means that you can call your own PL/SQL code to evaluate the condition.

             

             Multiple conditions can be combined using either AND logic (all the conditions must be true) or OR logic (at least one of the conditions must be true.)

Usage of Processing Constraint:

      Any Action Such as Update , Split , Cancel ,Delete or Create Will be Evaluated by Order Management against the Entity for Constraint