Customer Submitted Case Studies Case Study: A Case Study on Migration from MAC to SLA

Author: Ramesh Kammula - Chartered Accountant from the Institute of Chartered Accountants of India Contributors: Krishna Mohan Achutuni, MSO Upgrade Team, Satyam Computer Services Ltd Skill Level Rating for this Case Study: Intermediate

About Oracle Customer Submitted Case Studies

Oracle Customer Submitted Case Studies are intended as learning tools and for sharing information or knowledge related to a complex event, process, procedure, or to a series of related events. Each case study is written based upon the experience that the writer/s encountered. Customers should not interpret or use information in these case studies as solutions or recommendations without first contacting Oracle Support. Each Case Study contains a skill level rating. The rating provides an indication of what skill level the reader should have as it relates to the information in the case study. Ratings are:

Expert: significant experience with the subject matter Intermediate: some experience with the subject matter Beginner: little experience with the subject matter

Case Study Abstract

Manufacturing Accounting Controller has been replaced with Sub Ledger Accounting for the various OPM applications in R12. Following is a case study of how we successfully implemented SLA for OPM applications while migrating from 11.5.10.2 to R12. The process, followed here, has been discovered by using different sources like Release notes and in-house functional and database administration expertise. The process, explained in this case study, enabled us to successfully and seamlessly integrate the new SLA functionality with OPM applications in R12.
This case study is intended for an audience having a basic awareness of OPM Modules and SLA in Release 12 and seeking to know the experiences of others in migrating MAC in 11.5.10.2 into R12 as Sub Ledger Accounting (SLA).

Case History
The OPM Manufacturing Accounting Controller (MAC) application is where we define the data needed to derive the financial implications of several OPM applications in 11i like Purchasing (PO), Order Management (OM), Production Management (PM), Inventory Control (IC), and Cost Management (CM). Once this financial information is reviewed and approved in subledger process, it will be passed to the Oracle General Ledger. MAC has been replaced with Sub Ledger Accounting (SLA) in R12. While migrating from 11i to R12 we have observed the following points. When we migrated from 11i to R12 the application has taken Standard Accrual Method as SLA method automatically. Apart from the 3Cs in 11i, a new 4th C has been added in R12 i.e., Accounting Setup Manager under which we have to attach subledger Accounting.Sub-ledger Accounting (SLA) is an intermediate step between all Oracle sub-ledger products and Oracle General Ledger.

Subledger accounting options define how journal entries are generated from subledger transactions at the subledger application level and transferred to General Ledger. When we migrated from 11i to R12 the application has taken Standard Accrual Method as SLA method automatically. We found that this Standard Accrual Method is not useful for OPM Financials.

Why it is not useful? We will explain it with an example by taking one Non-OPM module and OPM module. In Accounts Payables (Non OPM modules) When we saw the Account Derivation Rule of invoice in payables under Standard Accrual Method, the source is defaulting as Invoice Distribution Account as shown in Fig: 1.1

Page 2

Account Derivation Rule of Invoice in Payables:

Fig: 1.1 From this we inferred that whenever we enter an invoice the application will pick up the account code combination form the invoice distribution lines as shown in Fig: 1.2, which is similar to 11i process.

Fig: 1.2
Page 3

So we can use the Same Standard Accrual Subledger Accounting Method. If we want to use additional features of R12, then only we need to create a new Subledger Accounting Method. But, when we saw Account derivation rules for Oracle Process Manufacturing Financials under Standard Accrual Method, the source is defaulting as Transaction Account as shown in Fig:1.3. Account Derivation Rule of Inventory in OPM Financials:

Fig: 1.3 From this we inferred that the application would pick up the Accounting Code Combination that we enter while entering the Transaction. But in OPM, most of the transactions are not associated with accounting code combination. For example, we will not have any option for entering account in OPM batch processing, as shown in Fig:1.4.1 and Fig:1.4.2.

Page 4

Fig: 1.4.1

Fig: 1.4.2 Further, Account will be associated to transactions only when we run subledger accounting process. So we cant enter the account code combination while entering the transactions. Hence we inferred that Standard Accrual Subledger Accounting Method is not useful for OPM and we need to create a separate Subledger Accounting Method.
Page 5

Analysis
From the Oracle Subledger Accounting Implementation Guide, we found out that MAC migration to SLA will be done by running concurrent programs Import Application Accounting Definitions & Export Application Accounting Definitions as mentioned below in Fig: 1.5.1 and 1.5.2 Import Application Accounting Definitions

Fig:1.5.1

Page 6

Export Application Accounting Definitions:

Fig: 1.5.2 With these steps, we were just able to import the Account Mappings into Account Derivation Rules. Other setups like Journal line types, Journal line Descriptions, Application Accounting Definitions are not imported. So we created all other setups just like as a fresh implementation. For migrating MAC into SLA we have done the following further setups; 1. 2. 3. 4. 5. 6. Create Journal Line Types Create Journal Lines Definition Create Application Accounting Definitions Validate Application Accounting Definitions Create Subledger Accounting Methods Attach the new Subledger Accounting method in the Accounting method setups

Page 7

1. Create Journal Line Types We created new Journal Line Types by using the Copy functionality from existing pre-seeded Journal Line Types.

Fig: 1.6.1

Page 8

Fig: 1.6.2

Fig: 1.6.3
Page 9

Create Account Derivation Rule After Migration, process of Import and Export of Application Accounting Definitions as mentioned in Fig: 1.5.1 and Fig: 1.5.2, converted Account mappings into Account Derivation Rules.

Fig: 1.7

Page 10

2. Create Journal Lines Definition We created new Journal Lines Definitions by using the Copy functionality from existing preseeded Journal Lines Definitions

Fig: 1.8.1

Page 11

Fig: 1.8.2 In the new Journal Lines Definitions under Line Assignments we deleted the seeded Journal Line Types and selected the Journal Line Types that we have created and assigned the respective Account Derivation Rules, for each Journal Line Types, segment wise.

Fig: 1.8.3
Page 12

3. Create Application Accounting Definitions: We created new Application Accounting Definition by name KLM_AAD by using the Copy functionality from existing pre-seeded Application Accounting Definitions.

Fig: 1.9.1

Fig: 1.9.2
Page 13

In the new Application Accounting Definitions, for each Event class and Event types we deleted the seeded Journal Lines Definitions and assigned the new Journal Lines Definition that we have created

Fig: 1.9.3 4. Validate Application Accounting Definitions We found that at the time of creating the Application Accounting Definitions, the Validation status of Event classes is Not Validated, as shown in Fig: 1.9.3. Hence we ran the Validate Application Accounting Program to validate the Event classes.

Fig: 1.10.1
Page 14

Fig: 1.10.2 After running the Validate Application Accounting Program, validation status of event class and event type became valid as shown in Fig: 1.10.3

Fig: 1.10.3
Page 15

5. Create Subledger Accounting Methods We created a new Subledger Accounting Method by name KLM_ACCRUAL by using the Copy functionality from existing pre-seeded Subledger Accounting Methods and assigned KLL_AAD (new Application Accounting Definition that we have created earlier) to the respective Applications.

Fig: 1.11

Page 16

6. Attach the new Subledger Accounting method in the Accounting method setups We attached the new KLM_ACCRUAL Subledger Accounting Method in the Accounting setups under Subledger Accounting

Fig: 1.12.1 After that we got the following measge stating that Ledger has been updated and Subledger Accounting Options have been changed as shown in Fig: 1.12.2.

Fig: 1.12.2.

Page 17

After doing all these steps we have checked wether MAC has been successfully migrted or not by verifying the following screens.

Account Mappings for Inventory: At the time of setting up basic settings in OPM Financials in 11i, we defined Account mappings as shown in Fig: 1.13.1 when Company is KLM, Title is INV, Warehouse is RMW the account to be hit is 20031 which is encircled in red

Fig: 1.13.1

Page 18

After Migration: Account Derivation Rules for Inventory

Fig: 1.13.2 When we migrated to R12 we observed that Account mappings have been migrated as Account Derivation Rules, stating to hit account 20031, which is encircled in red in figure 1.13.2, when the following conditions are satisfied

Fig: 1.13.3
Page 19

After migration also the account to be hit is 20031 when Company is KLM, Title is INV, Warehouse is RMW as shown in Fig: 1.13.3. So we inferred that MAC has been successfully migrated as SLA.

Results, Conclusion and Learnings

From all the above steps we came to following conclusions: When we migrate from 11i to R12, the Application, by default, will take Standard Accrual Method as SLA method. This Standard Accrual Subledger Accounting method is not useful for OPM. We have to create a new Subledger Accounting method while migrating from 11.5.10.2 to R12 With concurrent programs, like Import Application Accounting Definitions & Export Application Accounting Definitions, we can just import the Account Mappings into Account Derivation Rules.

Further findings: 6 segments = 6 Account Derivation Rules

At the time of defining Accounting Flexfields in 11i we created 6 segments viz., Company, Location, Department, Product, Account and Buffer as shown in Fig: 1.14.1. After migrating Account mappings to Account Derivation rules, we observed that a separate rule has been created for each segment. The same can be observed from the following screen shots wherein each screen shot representing the corresponding Accounting Derivation Rule.

Fig: 1.14.1

Page 20

After Migration:

Account Derivation Rule for Company Segment

Fig: 1.14.2

Page 21

Account Derivation Rule for Location Segment

Fig: 1.14.3

Account Derivation Rule for Department Segment

Fig: 1.14.4
Page 22

Account Derivation Rule for Product Segment

Fig: 1.14.5

Account Derivation Rule for Account Segment

Fig: 1.14.6
Page 23

Account Derivation Rule for Buffer Segment

Fig: 1.14.7

References
1. Oracle Subledger Accounting Implementation Guide for release 12 2. Oracle Manufacturing Accounting Controller Users Guide

DISCLAIMER: The information in this document is the opinion of the author, not of Oracle Corporation. Any content, materials, information or software downloaded or otherwise obtained through the use of the site is done at your own discretion and risk. Oracle shall have no responsibility for any damage to your computer system or loss of data that results form the download of any content, materials, information or software.

Page 24