Oracle A.I.M. Methodology – template list

Oracle A.I.M. Methodology encompasses a project management methodology with documentation templates that support the life cycle of an implementation. The life cycle methodology and documentation templates allows A.I.M. to be a very useful tool for managing implementation projects successfully. This is a depiction of the A.I.M. methodology life cycle:

Application Implementation Method is a proven approach for all the activities required to implement oracle applications. there are eleven processes of implementation.

1. Business Process Architecture [BP] – This phase outlines:

  • Existing Business Practices
  • Catalog change practices
  • Leading practices
  • Future practices
BP.010 Define Business and Process StrategyBP.020 Catalog and Analyze Potential Changes
BP.030 Determine Data Gathering Requirements
BP.040 Develop Current Process Model
BP.050 Review Leading Practices
BP.060 Develop High-Level Process Vision

BP.070 Develop High-Level Process Design

BP.080 Develop Future Process Model

BP.090 Document Business Procedure

2. Business Requirement Definition [RD] This phase explains about the initial baseline questionnaire and gathering of requirements.

RD.010 Identify Current Financial and Operating Structure RD.020 Conduct Current Business Baseline RD.030 Establish Process and Mapping Summary RD.040 Gather Business Volumes and Metrics RD.050 Gather Business Requirements RD.060 Determine Audit and Control Requirements RD.070 Identify Business Availability Requirements RD.080 Identify Reporting and Information Access Requirements

3. Business Requirement Mapping [BR]In this phase the requirements of business are matched with the standard functionality of the oracle applications.

BR.010 Analyze High-Level GapsBR.020 Prepare mapping environment
BR.030 Map Business requirements
BR.040 Map Business Data
BR.050 Conduct Integration Fit Analysis
BR.060 Create Information Model

BR.070 Create Reporting Fit Analysis

BR.080 Test Business Solutions

BR.090 Confirm Integrated Business Solutions

BR.100 Define Applications Setup

BR.110 Define security Profiles

4. Application and Technical Architecture [TA]This outlines the infrastructure requirements to implement oracle applications.

TA.010 Define Architecture Requirements and StrategyTA.020 Identify Current Technical Architecture
TA.030 Develop Preliminary Conceptual Architecture
TA.040 Define Application Architecture
TA.050 Define System Availability Strategy
TA.060 Define Reporting and Information Access Strategy

TA.070 Revise Conceptual Architecture

TA.080 Define Application Security Architecture

TA.090 Define Application and Database Server Architecture

TA.100 Define and Propose Architecture Subsystems

TA.110 Define System Capacity Plan

TA.120 Define Platform and Network Architecture

TA.130 Define Application Deployment Plan

TA.140 Assess Performance Risks

TA.150 Define System Management Procedures

5. Build and Module Design [MD]This phase emphasizes the development of new functionality (customization) required by the client. It mainly details how to design the required forms, database and reports.

MD.010 Define Application Extension StrategyMD.020 Define and estimate application extensions
MD.030 Define design standards
MD.040 Define Build Standards
MD.050 Create Application extensions functional design
MD.060 Design Database extensions

MD.070 Create Application extensions technical design

MD.080 Review functional and Technical designs

MD.090 Prepare Development environment

MD.100 Create Database extensions

MD.110 Create Application extension modules

MD.120 Create Installation routines

6. Data Conversion [CV]Data Conversion is the process of converting or transferring the data from legacy system to oracle applications. Ex. Transferring customer records from the legacy to the Customer Master.

CV.010 Define data conversion requirements and strategyCV.020 Define Conversion standards
CV.030 Prepare conversion environment
CV.040 Perform conversion data mapping
CV.050 Define manual conversion procedures
CV.060 Design conversion programs

CV.070 Prepare conversion test plans

CV.080 Develop conversion programs

CV.090 Perform conversion unit tests

CV.100 Perform conversion business objects

CV.110 Perform conversion validation tests

CV.120 Install conversion programs

CV.130 Convert and verify data

7. Documentation [DO]Documentation prepared per module that includes user guides and implementation manuals.

DO.010 Define documentation requirements and strategyDO.020 Define Documentation standards and procedures
DO.030 Prepare glossary
DO.040 Prepare documentation environment
DO.050 Produce documentation prototypes and templates
DO.060 Publish user reference manual

DO.070 Publish user guide

DO.080 Publish technical reference manual

DO.090 Publish system management guide

8. Business System Testing [TE]A process of validating the setup’s and functionality by QA(functional consultant) to certify status.

TE.010 Define testing requirements and strategyTE.020 Develop unit test script
TE.030 Develop link test script
TE.040 Develop system test script
TE.050 Develop systems integration test script
TE.060 Prepare testing environments

TE.070 Perform unit test

TE.080 Perform link test

TE.090 perform installation test

TE.100 Prepare key users for testing

TE.110 Perform system test

TE.120 Perform systems integration test

TE.130 Perform Acceptance test

9. Performance Testing [PT] Performance testing is the evaluation of transactions saving time, transaction retrieval times, workflow background process, database performance, etc

PT.010 – Define Performance Testing StrategyPT.020 – Identify Performance Test Scenarios
PT.030 – Identify Performance Test Transaction
PT.040 – Create Performance Test Scripts
PT.050 – Design Performance Test Transaction Programs
PT.060 – Design Performance Test Data

PT.070 – Design Test Database Load Programs

PT.080 – Create Performance Test TransactionPrograms

PT.090 – Create Test Database Load Programs

PT.100 – Construct Performance Test Database

PT.110 – Prepare Performance Test Environment

PT.120 – Execute Performance Test

10. Adoption and Learning [AP]This phase explains the removal of the legacy system and oracle application roll out enterprise wide.

AP.010 – Define Executive Project StrategyAP.020 – Conduct Initial Project Team Orientation
AP.030 – Develop Project Team Learning Plan
AP.040 – Prepare Project Team Learning Environment
AP.050 – Conduct Project Team Learning Events
AP.060 – Develop Business Unit Managers’Readiness Plan

AP.070 – Develop Project Readiness Roadmap

AP.080 – Develop and Execute CommunicationCampaign

AP.090 – Develop Managers’ Readiness Plan

AP.100 – Identify Business Process Impact onOrganization

AP.110 – Align Human Performance SupportSystems

AP.120 – Align Information Technology Groups

AP.130 – Conduct User Learning Needs Analysis

AP.140 – Develop User Learning Plan

AP.150 – Develop User Learningware

AP.160 – Prepare User Learning Environment

AP.170 – Conduct User Learning Events

AP.180 – Conduct Effectiveness Assessment

11. Production Migration [PM]The process of “decommissioning” of legacy system and the usage(adoption) of oracle application system.

PM.010 – Define Transition Strategy

PM.020 – Design Production Support Infrastructure

PM.030 – Develop Transition and Contingency Plan

PM.040 – Prepare Production Environment

PM.050 – Set Up Applications

PM.060 – Implement Production Support Infrastructure

PM.070 – Verify Production Readiness

PM.080 – Begin Production

PM.090 – Measure System Performance

PM.100 – Maintain System

PM.110 – Refine Production System

PM.120 – Decommission Former Systems

PM.130 – Propose Future Business Direction

PM.140 – Propose Future Technical Direction

thanks – Shivmohan Purohit

Oracle Projects 11i & R12 – AutoAccounting – Concept & Overview

How does AutoAccounting work?

For each accounting transaction, you define rules to determine the appropriate account to charge. Each accounting transaction is identified by an AutoAccounting function. AutoAccounting functions are components of programs that you submit to generate accounting entries.

How do you implement AutoAccounting?

The steps are as follows:
a). Design your AutoAccounting setup based on your implementation data.
b). Define lookup sets. Navigation – Setup/AutoAccounting/Lookup Sets.
To define a lookup set, you specify pairs of values. For each intermediate value, you specify a corresponding account segment value. One or more related pairs of intermediate values and segment values form a lookup set.
You may need several lookup sets to map organizations to cost centers, expenditure types to account codes, event types to account codes, or for other situations where the segment value depends upon a particular predefined parameter.
You can use a lookup set more than once; several AutoAccounting rules can use the same lookup set.
You define and modify lookup sets using the AutoAccounting Lookup Sets window.
c). Define rules. Navigation – Setup/AutoAccounting/Rules.
Each AutoAccounting rule you define supplies one Accounting Flexfield segment value at a time. Thus, you need to specify one AutoAccounting rule for each segment in your Accounting Flexfield for each AutoAccounting transaction you want to use.
Some of the AutoAccounting rules you define can be quite simple, such as always supplying a constant company code or natural account. Others can draw upon context information (parameters), such as the revenue category for a particular posting or the organization that owns a particular asset. You can even use multiple parameters to provide a segment value.
You can reuse the same AutoAccounting rules for many different functions and their transactions.
You define rules based on project information that you enter. You can use these AutoAccounting parameters as input values to your rules. Note: AutoAccounting does not use Flexfield security rules when determining a valid account combination. You must define your AutoAccounting rules to determine the appropriate account based on the rules required by your company.
d). Assign rules for each function. Navigation – Setup/AutoAccounting/ Assignments.
When you are assigning rules to an AutoAccounting function, you may want to assign different rules to different conditions. For example, you may want to account for indirect projects using one set of rules, and use two different sets of rules for billable items and nonbillable items on contract projects.
To make it easy to do this, Oracle Projects provides function transactions to each function, which identifies commonly used conditions in which you may want to assign different rules.
You can assign rules to function transactions for each AutoAccounting function.
You complete the following steps to assign AutoAccounting rules to AutoAccounting functions and transactions:
Enable each transaction you want to use
For each transaction you enable, you specify an AutoAccounting rule for each segment of your Accounting Flexfield

How does AutoAccounting compare to Workflow Account Generator?

Both the account generation processes in Oracle Workflow and AutoAccounting in Oracle Projects can create account numbers dynamically, based on transactions in Oracle Projects. This section compares the Account Generator to AutoAccounting, and provides directions for:
Assigning a constant or lookup value to a segment
Assigning an attribute parameter to a segment
Deriving a segment value
Learning more about SQL functions to generate account codes




Workflow or Item Type Function



Defining and assigning rules to segments



Assigning a constant to a segment

Assigning a constant AutoAccounting rule to a segment

Assigning an attribute parameter to a segment

Assigning an AutoAccounting rule that uses a parameter, which becomes the value (a lookupset is not used)

Assigning a lookup set value to a segment

Assigning an AutoAccounting rule that passes a parameter to a lookup set to determine the segment value

Deriving a segment value by using SQL statements or If conditions

Using an AutoAccounting rule that derives the intermediate value or segment value via a SQL statement.


I have an AutoAccounting Error – where do I start?

In most cases, when a user encounters an AutoAccounting error when processing Oracle Projects transactions, you will utilize the debug log file to find the source of the error. Most AutoAccounting errors are specific and will provide you with enough information for troubleshooting purposes.  Setting the Profile Option ‘PA: Debug Mode’ = Yes will provide more detail information in the log file.


How can I find out which parameters are valid for an AutoAccounting Function?

Run the IMP: AutoAccounting Functions report.

Can I create or edit existing AutoAccounting transactions?

Oracle Projects predefines AutoAccounting transactions; you cannot modify them, or define additional transactions.

Oracle Applications Documentation AIM Methodology

Oracle Applications – Documentations – Using AIM or Tailored AIM Methodology

here i am giving brief intro, in next article you can find much details information on AIM documents and reference


Not all companies are using the same AIM instead they are using their own giving different names but the formats of all the documents are more or less same. Each stage is having set of documents.

First Stage: Analysis
Second Stage: Designing
Third Stage: Build – DEMO / PROTO TYPE
Fourth Stage : Testing
Fifth Stage : Go Live
Six Stage : Post Production

Various documents for different scope and criterias such as


Below some brief on mostly used document types
BR Documents : Business Requirement Documents, which is primafaciely done by the Functional Persons of the Implementation Team like Funtional Project Leads / Managers. These documents are the Set up Documents, which is 100% based on the BR 120 – Business Requirement Gatherings as provided by the business. Now as a Funtional Consultant you need to always go for the BR – 100, that is set up document, so BR 100 is the To Be Process after you gather all sorts of info from the Biz and map in the Oracle systems
MD Documents : Modular Designing Documents, which are is primafaciely done by the Technical Persons of the Implementation Team like Technical Project Leads / Project Manager. These documents are the Design Documents, which is again based on the BR 120 – Business Requirement Gathering as provided by the business. These MD’s are of basically discussed any customization needs or any special behaviaour oracle system should work which is not the Standard Oracle Funtionality. These also discussed about the tables and the Interface Tables or forms which are going to be used in the particular modules. Thses also discussed about the High Level Designs like Flows of the Business and all. These MD’s are basically made after you all Functional Design and if there is no work around Oracle System provides for a particular Test Scenario and there is no other way other than to go for the Customization.

MD.70 is technical Document(Technical resource will design), which show all Technical Details like Coding, Maping and Logics.
MD.50 is Desgin Document(Functional resource will design), which explore all design methods like its road-map, which includes all design setups.

thanks – Shivmohan Purohit

Oracle Project Intercompany Invoices to Payables

Friends, here is Oracle Project billing insight on its integration with AR. How to Interface Oracle Project Intercompany Invoices to Payables


To explain how intercompany invoices are interfaced to Payables


When the provider operating unit runs the Tieback Invoices from Receivables process, the intercompany invoices are automatically copied into the interface table of the receiver operating unit’s Payables. Intercompany invoices interfaced to Payables are identified with the following attributes:


Source. All intercompany invoices have a source of Projects Intercompany Invoices.

• Supplier. The supplier is identified by the provider operating unit’s internal billing implementation options.

• Supplier Site. The supplier site is based on how the provider operating unit defines the receiver controls for the receiver operating unit.

• Invoice Amount. The Payables invoice amount is the amount of the related Receivables invoice, including taxes. The interface process populates the project–related attributes for intercompany Payables invoice distributions, as indicated below:

• Project Number. The number of the cross charged project indicated in the invoice line.

Task Number. The number of the task specified in the Intercompany Tax Receiving Task field on the cross charged project.

• Expenditure Item Date. The invoice date of the intercompany Receivables invoice.

• Expenditure Type. The expenditure type specified by the receiver operating unit in the Receiver Controls tab.

Expenditure Organization. The expenditure organization specified by the receiver operating unit in the Receiver Controls tab.


In addition, the interface process matches the tax code from each invoice line of the Receivables invoice to the appropriate Oracle Payables tax code. This process indicates that the Payables invoice distributions do not include tax amounts, so that the Payables Open Interface process creates the invoice distributions for the entire invoice by grouping the tax lines based on the following attributes:


Tax code

Project information (project, task, expenditure item date, expenditure type, expenditure organization)

thanks – shivmohan purohit

Overview – Oracle Projects

Last few days I have been involved with the Oracle Projects module. I’ll try and put forth some basic learning of this module.

Oracle Projects is meant primarily for organizations that are project-oriented. Using this module, it becomes easy to track costs, budget and track the project status.


Oracle Projects consists of the following products:

• Oracle Project Costing

• Oracle Project Billing

• Oracle Project Connect for Microsoft Project

• Oracle Activity Management Gateway

• Oracle Project Analysis Collection Pack


Prior to Oracle Projects Setup, one has to setup the Set of Books in GL, setup Organization and Organization hierarchy in Oracle HRMS, define employees and job in HRMS and create customer in Oracle Receivables. However if Oracle Projects is being installed as a standalone package then one needs to define all above in Oracle Projects itself. Some other mandatory setups include defining locations, defining implementation options, defining Project Accounting periods, defining expenditure types and categories, define revenue categories, etc. Also one has to create a burdening hierarchy in Oracle HRMS which may vary from the Project or Task Organization hierarchy.


Invariably a Project is broken into a hierarchy of tasks as per Work Breakdown Structure (WBS, a hierarchy of tasks that rollup into a project) to manage project and task related information. One can define as many levels of tasks in a hierarchy in Oracle Projects. However, proper naming conventions need to be followed while naming projects, tasks and sub-tasks. An organization has to be associated with a project and a Task, which may be same or different.


One can have three different Project Types for managing the cost of a project: Indirect, Capital and Contract. An Indirect Project Type is used to track the overhead costs and labor hours for overhead activities like Admin, Legal, etc. Capital Project Type is selected to track costs and labor hours related to asset development activities which ultimately results in an asset for the organization. A Contract Project Type is selected in case the costs are reimbursed by a client.


Oracle Costing is the used for processing of expenditures for finding out costs which can be attributed to projects and tasks which can then be posted to GL corresponding to different account lines. There are two cost amounts associated to each transaction: Raw and Burdened. The raw cost is the actual cost of the work performed, and the burden cost is the indirect cost or overhead of work performed, like administrative cost. The Burden cost is calculated by multiplying Raw Cost with the Burden Multiplier. The burdened cost is the total cost that is incurred, i.e., the sum of raw cost and burden cost.

Burden Cost = Raw Cost x Burden Multiplier

Burdened Cost = Raw Cost + Burden Cost

More on Oracle Projects, primarily I’ll try and provide inputs on Burdening Cost and Oracle Project Billing in subsequent days.

SQL script to assist in the identification of Projects revenue issues

Project Billing

To provide an SQL script to assist in the identification of Projects (PA) revenue issues.

This script could prove very useful for PA revenue problems.  It will sum up all the accrued and unearned revenue, thus providing a figure for the total revenue against a project.


select   dr.draft_revenue_Num, sum(dri.amount) amt

from     pa_draft_Revenues dr, pa_draft_revenue_items dr

where    dri.project_id = dr.project_Id

and      dri.draft_revenue_Num = dr.draft_revenue_Num

and      dr.project_Id = &project_Id

group by dr.draft_revenue_Num;


Thanks – do share ur feedback – shivmohan

Oracle Projects Billing Interface with Oracle Receivables

Oracle Projects Billing Interface with Oracle Receivables

Oracle Projects (PA) generates draft invoices and uses Oracle Receivables (AR) features to create invoices and interface the accounting transactions to Oracle General Ledger (GL).  When you interface invoices to Receivables, a Projects process is used to collect all eligible, released draft invoices in PA and interfaces them to the Receivables interface tables.  This process also maintains project balances of Unbilled Receivables and unearned revenue and creates accounting transactions for these amounts. 

Once in the AR interface tables, the draft invoices await further processing by the Oracle Receivables AutoInvoice process.  After the AutoInvoice program is run to create invoices in Oracle Receivables, you need to run the tieback process to ensure that your data successfully loaded into Receivables and that there are no transactions requiring correction.   If you have rejected invoices, you will need to correct and resubmit them.

Standard Oracle Projects reports can be used to track your invoices as you interface data between Projects and Receivables. You can also use AutoInvoice output reports to review imported transaction data and transaction data that fails when you run AutoInvoice. Modification Of Transaction Lines (PA/AR Out of Sync). It is possible to modify or delete invoice transactions transferred from Projects to Receivables using the Transaction Entry Workbench (ARXTWMAI). 


Refer to the scripts below to verify the information contained in the PA-AR invoice interface.  Both scripts should normally return the same lines and revenue amounts:

     SELECT l.interface_line_attribute2, l.interface_line_attribute6,   

     l.revenue_amount, l.interface_line_attribute1, h.reason_code,   


     FROM ra_customer_trx_all h, ra_customer_trx_lines_all l

     WHERE h.customer_trx_id = l.customer_trx_id

     AND h.interface_header_attribute2 = l.interface_line_attribute2

     AND h.trx_number = &Transaction_no.

     ORDER BY l.interface_line_attribute6;


     SELECT h.draft_invoice_num, l.line_num, amount, p.segment1,


     FROM pa_draft_invoices_all h, pa_draft_invoice_items l, pa_projects_all p

     WHERE h.ra_invoice_number = &Transaction_no.

     AND h.project_id = l.project_id

     AND h.draft_invoice_num = l.draft_invoice_num

     AND l.project_id = p.project_id(+)

     ORDER BY l.line_num;

  Thanks — Shivmohan Purohit