P2P cycle in Purchasing and O2C cycle in Order Management

http://oracleapplicationsfunctional.blogspot.in/2011/08/procure-to-pay-p2p-cycle-in-purchasing.html

http://oracleapplicationsfunctional.blogspot.in/2011/08/order-to-cash-cycle-in-order-management_28.html

AIM -- Oracle Application Implementation Methodology

The Oracle Application Implementation Methodology (AIM) is a proven approach for implementation of Oracle Applications across business domains. This approach has been developed by oracle in constant collaboration within its partner network.

According to Oracle "AIM provides the tools needed to effectively and efficiently plan, conduct, and control project steps to successfully implement new business systems."

The AIM is delivered in the form of a software bundle that packages the various document templates, which have been identified as deliverables under the AIM approach. These are in the form of easily editable Microsoft documents like word, excel and map documents.

The Software is currently available only to Oracle Partners through the Oracle Partner Network (OPN). The software installation itself is quite simple and gets running within a few clicks.

The A.I.M. methodology can actually be used for any type IT software implementations however the value of A.I.M is within the documentation template. The software includes the documentation templates, manuals and an html website to manage these templates.

Deliverables of AIM are as follows:

Business Process Architecture (BP)

BP.010 Define Business and Process Strategy

BP.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

Business Requirements Definition (RD)

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

Business Requirements Mapping (BR)

BR.010 Analyze High-Level Gaps

BR.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

Application and Technical Architecture (TA)

TA.010 Define Architecture Requirements and Strategy

TA.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

Module Design and Build (MD)

MD.010 Define Application Extension Strategy

MD.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

Data Conversion (CV)

CV.010 Define data conversion requirements and strategy

CV.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

Documentation (DO)

DO.010 Define documentation requirements and strategy

DO.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

Business System Testing (TE)

TE.010 Define testing requirements and strategy

TE.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

Performance Testing (PT)

PT.010 – Define Performance Testing Strategy

PT.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 Transaction Programs

PT.090 – Create Test Database Load Programs

PT.100 – Construct Performance Test Database

PT.110 – Prepare Performance Test Environment

PT.120 – Execute Performance Test

Adoption and Learning (AP) or User Training

AP.010 – Define Executive Project Strategy

AP.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 Communication Campaign

AP.090 – Develop Managers’ Readiness Plan

AP.100 – Identify Business Process Impact on Organization

AP.110 – Align Human Performance Support Systems

AP.120 – Align Information Technology Groups

AP.130 – Conduct User Learning Needs Analysis

AP.140 – Develop User Learning Plan

AP.150 – Develop User Learning ware

AP.160 – Prepare User Learning Environment

AP.170 – Conduct User Learning Events

AP.180 – Conduct Effectiveness Assessment

Production Migration (PM)

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

BR100 Application setup document

The BR100 documents the setup for each application, which is arrived at by completing some or all of the other BR (Business Requirements Mapping) and BD (Business Requirements Definition) documents in the Definition, Operational Analysis and Solution Design phases of the implementation project.

The first version of the BR100 will probably be used to build the TEST environment. Any changes required as a result of problems encountered will be incorporated into the next version of the BR100, which will then be used to build (say) the UAT environment. In parallel with these environments, there will probably be a DEVELOPMENT environment and it may be that there will be changes required to the BR100 because of issues encountered there. The "Final" version of the BR100 will probably then be used to build both the PRODUCTION and TRAINING environments.

In other words, it will probably evolve over a period of time.

To find out what other documents are available, look at AIM itself. Not all of the documents are required. If you are not doing any bespoke programing, you will not need to do any of the MD documents. Even the ones you do use, you may not use all of, or use in their original form. AIM is a set of guidelines not a straitjacket.


Or simply we can say,

BR.100 is Application setup document, where we are configuring the system which would go live, i.e. the instance is obviously production.So it is a production setup document primafacie.

So it goes without saying that values which are there in production should reflect in br.100.By this logic it is not mandatory to prepare a setup document for CRP, UAT.But if you want to document what you have setup in these instances then do so by all means.

Project Directory Structure

Most projects – even the smallest ones – need a project directory structure for storing important documents.
You may think this is a straight forward thing to create however after you may have tried working on several projects where the project structure didn’t work very well you realise it is not that easy anyway.
Things that may indicate a bad directory structure:

• You gat asked all the time where to find files
• You cannot always find your own files
• You are tempted to or already have copied files to your local drive for accessibility
• You have several copies of the same file but in different places
• You have to remember current project phase to find files
• You or somebody else keep moving files or directories around
• You find the structure over engineered and too deep

This above list could be very long but golden rule is a good directory structure works for you rather than you have to work for the structure…
So what do we want to achieve with our better directory structure?
Negating some of the problems above and adding some of my experience we get this:

• A lean and mean structure
• Documents remain in same place throughout the whole project
• Intuitive structure
• Structure focused on deliverables rather than phases and departments

There is no single solution to the above and any solution will depend of the type and size of project.
For one of my recent projects I would have liked the following top-level structure :

• Management
  • Scope
  • Planning
  • Resourcing
  • Quality Management
  • Status Reporting
  • Change Requests
  • Issues
• Deliverables
  • Process
    • Requirements
    • To-Be Processes
  • Data Conversion
    • Data Conversion Plan
    • Data Conversion Strategy
  • Interfaces
    • Interface Plan
    • Interface Strategy
  • Configuration
    • BR100 – Application Setup
    • MD50 – Functional Design
  • Development
    • MD40 – Build Standards
    • MD70 – Technical Design
  • Database
    • Environment Plan
    • Patch Management
  • Test
    • Test Plan
    • Test Strategy
    • Test Scripts

As said – the above is an example only and will change based on project size and complexity.
Each directory above – especially MD50 can get out of hand on large projects so you may want to subdivide this by module or work stream.
Most operating systems arrange directories alphabetically however if you need to arrange directories within one level you can prefix the directory names with a number:

• 10 Test Plan
• 20 Test Strategy
• 30 Test Scripts

Be sure to number with gaps in case you need a new directory in the middle.

R12 – MOAC Security

Multiple Organizations Access Control (MOAC) security give the possibility of querying or seeing transactions of one or more Operating Units (OU) without changing responsibility.
In 11i we were securing transactions by Operating Unit (OU) only and we would have to choose a corresponding responsibility to see the transactions:

• OU1 – Receivables Manager
• OU2 – Receivables Manager
• OU3 – Receivables Manager

In R12 it is now possible to have a shared services responsibility like:

• ALL – Receivables Manager

This new kind of security is based on Security Profiles which is a hierarchy of operating units.
So best practice in R12 is now to secure all responsibilities by Security Profile rather than by Operating Unit.
11i non-MOAC setup:

	Site Level	Receivables (Vision)
MO: Default Operating Unit
MO: Operating Unit	Vision Operations	Vision Operations
MO: Security Profile
GL Set of Books Name		Vision Operations

So a global shared service responsibility was not possible in 11i so some companies had very long lists of responsibilities.
Also note in R11i site level setting takes precedence at lower levels so the responsibility level setting in this case is not needed – only if the OU had been different.
R12 MOAC setup:

	Site Level	Receivables (Vision)	Receivables (Global)
MO: Default Operating Unit		Vision Operations	Vision Services
MO: Operating Unit
MO: Security Profile	Vision Global	Vision Operations	Vision Global

Assuming we have a hierarchy like this where OU and security profiles have same names:
> Vision Global
>> Vision US
>>> Vision Operations (OU)
>>> Vision Services (OU)
>> Vision Europe (OU)
We do not need to have a security profile for all branches in the hierarchy above but it is best practice to do so.
So in R12 GL Set of Books Name is gone and you leave MO: Operating Unit empty and leave it to the Security Profile.
Note: MO: Default Operating Unit is not required and can be left empty however I have had several bugs in R12.1.1 and R12.1.2 related to missing default operating unit in IEX so try leaving it empty first and if you get problems put a default value in this and try again.
So Oracle has created MOAC but forgot a few details here and there.
Mixed R11i/R12 MOAC setup:
Some modules in R12 does not yet fully support MOAC so a mixed setup may be needed.
Luckily Oracle changed the MO profile settings inheritance so the site level setting does NOT override at responsibility level as in R11i – well at least this setup worked in R12.1.1.

	Site Level	Receivables (Vision)	Receivables (Global)
MO: Default Operating Unit			Vision Operations
MO: Operating Unit	Vision Operations
MO: Security Profile	Vision Global	Vision Operations	Vision Global

Using the setup above you will get a site level default OU of “Vision Operations” however at responsibility level the security profile takes precedence so Receivables (Global) will be able to see all OU’s within “Vision Global”. In 11i you would have been locked down to “Vision Operations”.

Technical

11i – View Based Security

11i used views to secure transactions in individual schemas:
APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL
With where clause using CLIENT_INFO set from the responsibility context.
In PL/SQL programs you would set:

• fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id);

and:

• dbms_application_info.set_client_info(var_organization_id);

R12 – VPD Based Security

R12 uses the Virtual Private Database (VPD) technology for MOAC security.
Synonym APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL
With a policy attached to synonym APPS.AR_PAYMENT_SCHEDULES.
In PL/SQL program you still need to set:

• fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id);

and for single OU access:

• mo_global.set_policy_context(‘S’,var_organization_id);

or for multi OU access:

• mo_global.set_policy_context(‘M’,null);

Accessible Organisation Units

In 11i it was easy to see what access you had:

• dbms_application_info.read_client_info(var_organization_id);

Which would return your current org_id however in R12 you need to do the following:

• select organization_id
  from HR_ORGANIZATION_UNITS
  where MO_GLOBAL.CHECK_ACCESS(organization_id)=’Y’
  ;

I usually use the following script:

declare

  l_user_id number;

  l_responsibility_id number;

  l_application_id number;

  l_organization_id number;

begin

--  dbms_output.enable;

  select application_id,responsibility_id

    into l_application_id,l_responsibility_id

    from fnd_responsibility_tl

    where responsibility_name = 'General Ledger Super User';

  select user_id

    into l_user_id

    from fnd_user where user_name='ORACLE';

  select organization_id

    into l_organization_id

    from hr_all_organization_units

    where name='Vision Operations';

  fnd_global.apps_initialize(l_user_id,l_responsibility_id,l_application_id);  

  --mo_global.set_policy_context('S',l_organization_id);

  mo_global.set_policy_context('M',l_organization_id);

--  dbms_output.put_line('Done...');

end;

Concurrent Requests

Concurrent request can now be setup to run as in 11i (default) or as MOAC compliant programs.
Use the “System Administrator” OAF screen “Concurrent Program” to set Operating Unit Mode to Single (OU) or Multi (MOAC compliant):