How to Define Segment Values in Accounting Flex field in Release 12.2

How to Define Segment Values in Accounting Flex field in Release 12.2 

Not able to Search Value sets in R12.2

In Release 12.2 Value set Insert/Update depends on Security access. To Insert/Update the Accounting Flex filed segment values for a specific user, User need to follow below steps

By Default in R12.2 a user will not be able to see any values in the value set / Key Flexfield values Form and will receive an error

FRM-40212: Invalid value for field FLEX_VALUE_SET-NAME

To Insert/Update the Accounting Flex filed segment values for a specific user, User need to be provided with appropriate Grants.

Please follow below steps toad Grants for User to Insert and update Value Sets.

Responsibility : Functional Administrator

Go to Navigation : Security à Grants à  Create Grant

1.Name            :Give Name as Required

2.Grantee Type :Select as Specific User

3.Grantee         :Select the Required User Name from List of Values

4.Object           :Select Object as ''Flexfield Value Set Security Object(1)'' from List of Values

5.Set               :Select the Set as ''Flexfield Value Set Security Insert/Update Set'' from List of values .

6. Click on ''Apply'' Button

Add the Object Data Context : All Rows

Select the Set as ''Flexfield Value Set Security Insert/Update Set'' from List of values

After creating the grants from functional administrator, we will be able to perform the following in Value set and Key Flex field Values form:

i) Access the values in Name field LOV, when we Find Values By Value Set.
ii) Access the values in Application,Title,Structure & Segment field LOV's, when we Find Values By Key 
Flexfield
iii) Access the values in Application,Title,Structure & Segment field LOV's, when we Find Values By 
Descriptive Flexfield
iv) Access the values in Application, Name & Parameter LOV's, when we Find Values By Concurrent Program.

Accounts Receivables Auto Accounting

Accounts Receivables Auto Accounting:

Define Auto Accounting to specify how you want Receivables to determine the general ledger accounts for transactions that you enter manually or import using Auto Invoice. Receivables create default accounts for revenue, receivable, freight, tax, unearned revenue, unbilled receivable, finance charges, bills receivables accounts, and Auto Invoice clearing (suspense) accounts using this information. When you enter transactions in Receivables, you can override the default general ledger accounts that Auto Accounting creates. You can control the value that Auto Accounting assigns to each segment of your Accounting Flex field, such as Company, Division, or Account. You must define Auto Accounting before you can enter transactions in Receivables.

To define Auto Accounting:

1. Navigate to the Automatic Accounting window.

2. Enter the Type of account to define. you may Choose from the following to configure the type of Account you wish to setup the rule for

Auto Invoice Clearing: The clearing account for your imported transactions. Receivables use the clearing account to hold any difference between the specified revenue amount and the selling price times the quantity for imported invoice lines. Receivables only use the clearing account if you have enabled this feature for the invoice batch source of your imported transactions.

Bills Receivable: The bills receivable account for your transaction. Receivables use this account when you exchange transactions for bills receivable.

Factored Bills Receivable: The factored bills receivable account for your bills receivable transactions.

Freight: The freight account for your transaction.

Receivable: The receivable account for your transaction.

Remitted Bills Receivable: The remitted bills receivable account for your bills receivable transactions.

Revenue: The revenue and finance charges account for your transaction.

Tax: The tax account for your transaction.

Unbilled Receivable: The unbilled receivable account for your transaction. Receivables use this account when you use the Bill In Arrears invoicing rule. If your accounting rule recognizes revenue before your invoicing rule bills it, Receivables uses this account.

Unearned Revenue: The unearned revenue account for your transaction. Receivables use this account when you use the Bill In Advance invoicing rule. If your accounting rule recognizes revenue after your invoicing rule bills it, Receivables uses this account.

Unpaid Bills Receivable: The unpaid bills receivable account for your bills receivable transactions.

For each segment, enter either the table name or constant value that you want Receivables to use to get information. When you enter an account Type, Receivables displays all of the segment names in your Accounting Flexfield Structure. Segments include such information as Company, Product, Department, Account, and Sub–Account. Receivables let you use different table names for different accounts. Choose one of the following table names:

Bill To Site: Use the bill–to site of the transaction to determine this segment of your revenue, freight, receivable, Auto Invoice clearing, tax, unbilled receivable, and unearned revenue account.

Drawee Site: Use the site table to determine this segment of your bills receivable, factored bills receivable, and remitted bills receivable and unpaid bills receivable account.

Sub-ledger Accounting Configuration - Part 1

Sub Ledger Accounting method (SLAM):

SLA is a rule based accounting Engine that introduced the ability to define how transactions originating in Sub Ledgers can be Accounted. Hence in order achieve this high level of flexibility SLA is accommodated with lot of configurable and predefined components.

This article will talk about different Predefined and configurable components of SubLedger Accounting which are used to setup accounting rules in order to achieve various accounting requirement.

Below mentioned are Predefined Components of SLA. We will talk about their specific Examples as we move on.

Predefined Components of SLA:

Entities:

Entities in SLA represent a Specific Document category in the Application. For example an Invoice or Payment in Account Payables. 

Event Class:

Event Class in SLA represents a specific type of the entity for which the Corresponding accounting entry will be generated. For Example a Standard Invoice is a Type Of invoice there by Standard Invoice will be an Event class for the Entity AP Invoice.

Event Type:

Event type is an Action or an event which should be defined as trigger for the creation of accounting entries.

For example: in reference to a Standard accounting requirement an Standard Invoice should get accounted once it is validated. Hence the Event which will initiate the accounting for the invoice is Validation. So Standard invoice validation is the Event Type for Event Class Standard Invoice

In Order to explain the complete concept let’s take one more example.

There should be accounting entries generated for Cancellation of a credit memo. And hence Credit Memo is a Type of Account Payables invoice.

Entities à AP invoice

Event Class à Credit Memo

Event à Cancellation.

Sub-Ledger Accounting

Sub-Ledger Accounting

Sub ledger accounting traditionally had accounting rules spread across multiple Products and Sub ledger applications hence it was Difficult to keep the rules up to date and manage.

And if there used to be any requirement which requires a different Accounting treatment as per different geographies, Regulations  or entity it was extremely difficult to implement and many times the ultimate solution was to implement a customization or pass manual Adjustment entries.

The New Sub Ledger accounting feature of oracle E-business Suite R12 popularly known as SLA addresses such issues through a central accounting rule engine allowing among other things, Superior controller ship of definition of accounting rules.

SLA is a rule based accounting Engine that introduced the ability to define how transactions originating in Sub Ledgers can be Accounted. One of the significant benefits of SLA is the ability to generate multiple accounting representations (IFRS and local GAAP) for a single sub ledger transaction.

Hence in Simple words, Different from 11i where accounting Entries used to get created in respective Sub ledgers and then get transferred to GL, In R12 the Entries get created using SLA for all the Sub ledger applications and then gets transferred to GL. Hence it would be appropriate to say SLA is placed between different Sub ledgers such as AP, AR, CE, PA and General Ledger as mentioned in below. 

Sub Ledger Accounting Gives capability to Massage/ Change the accounting entries which gets generated as part of the Standard Sub Ledger application specific account so as to have the accounting entries posted to the desired accounts to address various geographies or entity specific accounting requirement

Above Example shows how the accounting String (A.B.C.D) generated by SubLedger Applications (Eg: AP, AR, CE) can be altered to A1.B1.C1.D1 to achieve specific Accounting requirement and then can be transferred to general Ledger.

Application Implementation methodology (AIM) Template list

Application Implementation methodology (AIM) Template list

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

Different Documents Used at Different Levels in Application Implementation Methodology ::

Different Documents Used at Different Levels in Application Implementation Methodology ::

1. Business Process Architecture [BP] –

This Document Addresses ::

• Existing Business Practices
• Catalog change practices
• Leading practices
• Future practices

2. Business Requirement Definition [RD]

            This phase explains about the initial baseline questionnaire and gathering of requirements

3. Business Requirement Mapping [BR]

In this phase the requirements of business are matched with the standard functionality of the oracle applications.

4. Application and Technical Architecture [TA]

 This outlines the infrastructure requirements to implement oracle applications.

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.

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.

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

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

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

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


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

Application Implementation Methodology

Application Implementation Methodology::

AIM consists of a project management methodology together with the underlying documentation templates that support the tasks you perform within this methodology. This combination of a methodology together with documentation templates makes AIM a powerful tool for assisting implementation participants in running and managing projects successfully.

There are 6 phases in AIM

1. Definition ::
1. Establish the business objectives and related Requirements,
2. Define the Project Plan

2. Operations Analysis :
1. Analyze the operations and identify the fit between Organizational requirements and Standard Applications Functionality

3. Design :
1. Develop detailed design for the optimal Solutions to meet the future business requirements

4. Build : (Implementation)
1. Physical Software system Build and testing

5. Transition:
1. Deploying the Finished solution in to Organization

6. Production Go live

** Each Phase has Number of tasks to be followed.

** There are more than 150 templates, which can be used through out the AIM Process.

There are two types of AIM Documentation template:

-        Project management related (Project plan, Change Orders, Quality control document. Etc.)

-        Oracle Applications Implementation related Docs (RD50, BR100, MD200 etc.)

Security Profiles in Oracle Application R12

Security Profiles

Oracle Applications 11i had a limitation where, the Business Personnel’s responsible for a particular business function who had access to multiple organizations had to navigate to individual Organization specific responsibilities for taking action on the transactions. For example: a buyer who can create Purchase orders for multiple organizations will have to Navigate to each operating Unit specific responsibility to create or manage purchasing Documents.

R12 comes as a blessing for such user of Oracle applications where Multi Organization Access control features enabled such users to take action on documents and transactions without navigating between various organizations specific responsibilities. This feature can be implemented using Security Profiles in R12.

Security profiles is a feature in R12 which can be used for grouping the organizations logically such that a set of users can access a Set of Organizations using the responsibility which are assigned with particular Security profile.

There are two types of Security Profiles.

• Security Profile: If it is required to group multiple operating units for the same business group.

• Global Security Profile: If it is required to group multiple operating units for the different business group.

After the security profiles are defined it is required to run the Security List Maintenance program, before assigning the Security profile to the Responsibilities

A Security profile can be assigned to a responsibility by using the MO: Security Profile option.

If you set the MO: Security Profile option, you can also set the MO: Default Operating Unit profile option to specify a default operating unit.

It is important to note that if the MO: Security Profile option is not set for the responsibility it will behave same as R11i.

The MO: Operating Unit profile option still exists in R12 but it should only be used if Multi organization access control is not desired.

HR: Security Profile

Oracle Applications also has HR: Security Profile feature. This profile option is used for defining association between a Business group and the Organizations hierarchy. HR: Security Profile options needs to be setup before defining any new organizations or organization hierarchies under a Business group.

Inventory Organization in Oracle Applications

Inventory Organization in Oracle Applications.

In this Article we will see the importance, setup steps, Prerequisites of Inventory organization in Oracle Applications R12.

An Inventory Organization represents a business entity which can Store and Transact Item. Setting up Inventory organization is a Preliminary step for defining and using Oracle Inventory module.

In real world an inventory organization represents a physical entity like a manufacturing facility, warehouse, distribution center or a branch office where inventory is stored and transacted or it can also represent a Logical Entity such as Master Inventory Organization which can be used for Defining Items..

Some of the applications which secure information by inventory organization are: Oracle Inventory, Bills of Material, WIP, MRP, and Purchasing receiving functions. Hence to use such applications for transactions, it is required to select an organization that has been classified as an inventory organization.

Below Mentioned is a Sample Structure which shows how Inventory Organization fits in th Oracle applications Multi-Organization Structure.

An Inventory Organization has one or more Sub-inventories which in turn can have one or more Locators.

Sub-Inventory:

Subinventory is a business Entity which represents a Physical or Logical Separation Of Inventory, For Eg. Finished Goods Inventory, Raw material Inventory. the Inventory Transactions can be Tracked or Restricted as per Subinventories. It is required to define at least one Subinventory for every Inventory Organization.

Locators:

Locators are physical places where an Inventory Item is stored with in a Subinventory or Inventory. Locator Control is an Optional feature in Oracle Inventory Module.

It is also required to define below mentioned Multi organization Entities before defining an Inventory organization.

• ·        Ledger
• ·        Location
• ·        Legal Entity
• ·        Operating Unit (Optional)

Setting Up Organization in Oracle Applications R12

Setting Up Organization in Oracle Applications:

An Organization represents a business unit in an Enterprise which has a business need to secure transaction data, Setups and Seed data. It can be a major division, sales office, a department, or a separate company within an enterprise. Since the transaction Information is secured at organization level for the various modules within Oracle applications, A single application responsibility can access, process, and report on data for one or more operating units that is assigned to its Security profile.

An Operating unit can be associated to a Single Legal Entity and Ledger. But multiple operating units can be Associated to a Single Legal entity and Ledger.

Organization can be classified in to a set of system-defined attributes that categorize an organization. Examples

• ·        Business group
• ·        operating unit
• ·        project expenditure organization
• ·        inventory organization
• ·        Human resources organization

Organization in Oracle Applications is an autonomous Business Entity having business activities corresponding either of the below Modules like Receivables, Order Management, Payables, Purchasing, Projects, Inventory.

Navigation to define Organization:

HR Responsibility à Work Structure à Organizations

Organization can also be defined and viewed from the accounting Setup manager as well.

Whenever a New Organization is defined in oracle application it needs to be added appropriately in the Security profile if the Security Profile is a List of Organizations based Security profile and The Security List Maintenance programs needs to be run.

Defining an Operating Unit:

In order to use an Organization for transactions in the Oracle Applications in the Modules like Receivables, Order Management, Payables, Purchasing. It is required to define the Organization as an Operating Unit.

It is Mandatory to decide and Setup the below mentioned Oracle application multi organization entities before we setup an Operating unit.

• ·        Business group
• ·        Ledger
• ·        Legal Entity

Operating unit is an Organization classification and once an organization is defined as an operating Unit the Organization Attributes need to be defined. Before setting UP operating unit below Profile options should be defined so that the Organization gets created under appropriate business group

HR: Business Group at Responsibility Level

HR: Security Profile at Responsibility Level

As mentioned above The Ledger and Legal Entity needs to defined in the organization Information. And this is how the Legal Entity and Ledger are assigned to the Operating Unit.

Also It is important to note that in Oracle Applications R12 the Legal Entity which is Attached in the Organization information screen is the Default legal Context. Transnational

Legal Entities Defined at the ledger level can be used on the basis of the Mapping Defined between the Balancing Segment and Legal Entity as per the Ledger Definition.

Ledger Configuration in Oracle R12 Part -3

In this Article we will look in to the Steps and necessary configurations involved in defining Ledger in Oracle R12

Setting Up Ledger:

Create Legal Entity: If it is required to assign a legal entity, It can be crated and assigned to a Ledger from accounting setup manager.

Assign the Legal Entity to Ledger

Setting Up Ledger Options:,

Before setting up Ledger options Decide up on the values that are required to be entered in the corresponding fields in the Ledger options.

Define Ledger:

While defining the ledger you may use the calendar, Chart of Accounts, Currency and Sub-Ledger Accounting method defined earlier. As part of ledger setup it is mandatory to finalize these values before defining Ledger.

Define Ledger options.

As part of the Ledger options Definition Below mentioned are the Values which needs to be defined which will control how journals and transactions are processed for that ledger hence it is very important to have the values for all the below mentioned Options Decided before setting up the Ledger on the basis of business Functional requirement:

• First Ever Opened Period

• Number of Future Enterable Periods

• Retained Earnings Account

• Sub-ledger accounting method,

• Option to track balances using a secondary segment

• Suspense Account

• Rounding Differences Tracking Account

• Intercompany Balancing option

• Journal Approval

• Journal Entry Tax

• Journal Reversal Criteria Set

• Default Period End Rate Type

• Default Period Average Rate Type

• Cumulative Translation Adjustment Account

• Journal Reconciliation

• Budgetary Control

• Reserve for Encumbrance Account

• Average Balance Processing

• Average Balance Consolidation

• Net Income Account

• Transaction Calendar

If there are legal entities that require any one of the above ledger processing options to be different, then define a separate primary ledger for each legal entity and therefore, a new accounting setup

You will not be able to use the Ledger Unless the Ledger options setup Shows as Complete in the ledger setup Screen.