r 12 Delta Students White Paper

GreenChain Software Solutions Pvt. Ltd. Page 1 of 52

Oracle Applications Release12.1.1

R12 Features Update

White Paper

GreenChain Software Solutions Pvt Ltd

www.greenchain.biz


Table of Contents

1.Introduction ..................................................................................................................................3 2.Subledger Accounting ................................................................................................................8

2.1 Introduction .............................................................................................................................8 2.1 Accounting Methods Builder ................................................................................................. 10

3.Accounts Receivables .............................................................................................................. 13 4.Accounts Payables ................................................................................................................... 26

4.1 Suppliers ............................................................................................................................... 26 4.2 Supplier Invoices ................................................................................................................... 27 4.3 Retainage .............................................................................................................................. 29

5.E-Business Tax ......................................................................................................................... 35 6.Multi Org Access Control ......................................................................................................... 38 7.AP/ AR Netting .......................................................................................................................... 39 8.Centralized Banks ..................................................................................................................... 47 9.Funds Disbursement (Payments) ............................................................................................ 50 10.Fixed Assets ............................................................................................................................ 51 11.Frequently Asked Questions .................................................................................................. 52


1. Introduction Major Oracle E-Business Suite R12 Architectural changes in the Financials are

Legal Entity Ledger Sets Accounting Engine (SLA) Transaction Based Taxes(E-Tax) Inter-company Accounting (AGIS) Multi-Organization Access Control (MOAC)

Accounting Setup Manager

The ledger replaces the 11i concept of a set of books. It represents an accounting representation for one or more legal entities or for a business need such as consolidation or management reporting. Companies can now clearly and efficiently model its legal entities and their accounting representations in Release 12. This seems to be a major area in getting success of the shared service center and single instance initiatives where many or all legal entities of an enterprise are accounted for in a single instance, and data, setup, and processing must be effectively secured but also possibly shared.

Legal Entities can be mapped to entire Ledgers or if you account for more than one legal entity within a ledger, you can map a legal entity to balancing segments within a ledger.

In 11i, Set of books is defined by 3 Cs, chart of accounts, functional currency, accounting calendar, and in R12, ledger is defined by a 4th C: accounting method. This 4th C allows you to assign and manage a specific accounting method for each ledger. Therefore, when a legal entity is subject to multiple reporting requirements, separate ledgers can be used to record the accounting information.

Accounting Setup Manager can perform and maintain following common setup components from a central location:

Legal Entities Ledgers, primary and secondary Operating Units, which are assigned to primary ledgers Reporting Currencies, which is an enhanced feature Subledger Accounting Options. This is where you define the accounting methods for each legal entity

subledger transaction and associate them to the ledger where the accounting will be stored. Intercompany Accounts and Balancing Rules Accounting and Reporting Sequencing Both Intercompany and Sequencing

Subledger Accounting (SLA)

GL is integrated with SLA to enable a unified process to account for subledger transactions and post data to GL, and to provide a consistent view when drilling down from GL to subledger transactions.


Enhanced Foreign Currency Processing by Reporting

GL has enhanced existing features to support foreign currency processing:

MRC feature is enhanced with Reporting Currencies. It will support multiple currency representations of data from any source, including external systems, Oracle or non-Oracle subledgers, and Oracle General Ledger journals and balances.

Reporting to view balances view balances that were entered in your ledger currency separate from those balances that were entered and converted to the ledger currency. Balances entered in ledger currency are maintained separately from balances converted to ledger currency for use in Reporting and Analysis.

Assume we have a ledger and currency is USD. I enter and post two journals; one in 1,000 US Dollars, and another in 500 British Pounds that gets converted to 1200 US Dollars.

In Release 11i, I can review the 500 GBP and the 1200 USD that results from converting the 500 GBP, and the total 2200 USD which is the USD balance in the Cash Account. The $2200 is the sum of the $1000 entered in USD and the $1200 converted from the 500 British Pounds. However, I view that a 1000 USD were entered directly in USD.

In Release 12, I can view the 1000 USD by performing an account inquiry on the Cash account for balances entered only in the ledger currency. The amounts entered in foreign currencies that were converted to the ledger currency will not be included in the balance. Of course, if I want to retrieve all balances in USD, both the entered as well and the converted, I can still do that in Release 12.

Creating foreign currency recurring journals

In Release 11i, you could define recurring journals using the functional currency or STAT currency.

Release 12, you can create recurring journals using foreign currencies. This is particularly useful if you need to create foreign currency journals that are recurring in nature. For example, assume a subsidiary that uses a different currency from its parent borrows money from the parent. The subsidiary can now generate a recurring entry to record monthly interest payable to the parent company in the parent currency.

Data Access to Multiple Legal Entities and Ledgers

You no longer have to constantly switch responsibilities in order to access the data in a different ledger. You can access multiple ledgers from a single responsibility as long as all ledgers share the same chart of accounts and calendar.


Simultaneous Opening and Closing of Periods for Multiple Ledgers

You no longer have to open and close periods for each ledger separately. You can now open and close periods across multiple ledgers simultaneously by submitting Open and Close Periods programs from the Submit Request form.

Simultaneous Currency Translation of Multiple Ledgers

You can run the Translation program for multiple ledgers simultaneously, if you are managing multiple ledgers.

Financial Reporting for Multiple Ledgers

Now with this feature you can run Financial Statement Generator (FSG) reports for multiple ledgers simultaneously. This is useful if you manage multiple ledgers and want to run a balance sheet or income statement report for all of your ledgers at the same time.

Cross-Ledger and Foreign Currency Allocations

You are able to allocate financial data from one or more ledgers to a different target ledger. This enables you to perform cross-ledger allocations, which is useful for purposes such as allocating corporate or regional expenses to local subsidiaries when each entity has its own ledger

Streamlined Automatic Posting

You can now share AutoPost Criteria sets across multiple ledgers that share the same chart of accounts and calendar and use the AutoPost Criteria sets to post journals across multiple ledgers simultaneously.

Streamlined AutoReversal Criteria Setup Integrated Web-based

AutoReversal Criteria Sets can also be shared across ledgers to reverse journals across multiple ledgers. This is enhanced by integrated Web-based Spreadsheet Interface.

Journal Copy

Now we can now copy entire journal batches. You can copy journal batches with any status. The system will create a new journal batch containing the same journal entries. You may also change the batch name, period, and/or effective date while copying the journal batch. After copying the journal batch, you may modify the unposted journals in the same manner as any manually created journals.

Streamlined Consolidation Mappings

You are able to define Chart of Accounts Mappings (formerly known as Consolidation Mappings) between two charts of accounts. Therefore, if you have multiple Consolidation Definitions for parent and subsidiary ledgers that share the same chart of accounts pair, and their mapping rules are the same, you only have to define a single Chart of Accounts Mapping.

The enhancement in R12 allows you to define mappings between charts of accounts instead of between sets of books, so that they can be shared across multiple Consolidation Definitions.

Therefore, if you have multiple Consolidation Definitions for parent and subsidiary ledgers that share the same chart of accounts pair, and their mapping rules are the same, you only have to define a single Chart of Accounts Mapping.

You can also secure access to chart of accounts mappings using definition access set security. This allows you to secure which users can view, modify, and/or use chart of account mappings in consolidation definitions.

Replacement for Disabled Accounts


Normally when an account is disabled, you can prevent transactions that include the account from erroring during journal import by defining a replacement account for the disabled account. Journal import replaces the disabled account with the replacement account and continue the journal import process if the replacement account is valid. This improves processing efficiency by preventing the journal import process from erroring and enabling the successful creation of the journal with minimal user intervention when an account has been disabled.

Data Access Security for Legal Entities and Ledgers

In R12, since you can access multiple legal entities and ledgers when you log into General Ledger using a single responsibility, General Ledger provides flexible ways to secure data by legal entity, ledger, or even balancing segment values or management segment values. You are able to control whether a user can only view data, or whether they can also enter and modify data for a legal entity, ledger, balancing segment value or management segment value.

Management Reporting and Security

You can designate any segment (except the natural account segment) of your chart of accounts to be your management segment and use Oracle GL security model to secure the management segment for reporting and entry of management adjustments.

Prevent Reversal of Journals with Frozen Sources

You can no longer reverse journals from frozen sources defined in the journal sources form.

If the journal is created from a frozen source, the journal cannot be modified even if the source is subsequently unfrozen in the future. This provides streamlined data reconciliation with subsystems. Not being able to reverse journals that originated in subledgers will ensure that the account balances will always tie out with General Ledger. If you need to reverse a subledger journal, then you should do so in Subledger Accounting or the subledger application.

Prevent Reversal of Unposted Journals

You also can no longer reverse unposted journals. This ensures data integrity and better auditability. In the past when we allowed you to reverse unposted journals, there was a risk that the original journal could be deleted so you could end up reversing something that didnt exist. Now, all reversals can be tied back to the original posted journal.

Integrated Web-based Spreadsheet Interface

Through the integration with Web ADI, users can now leverage spreadsheet functionality in Oracle General Ledger via a web-based interface. The spreadsheet interface can be conveniently launched from a GL responsibility.

Using the Journal Wizard, we can leverage spreadsheet functionality to create actual, budget, or encumbrance journals. You can take advantage of spreadsheet data entry shortcuts such as copying and pasting or dragging and dropping ranges of cells, or even using formulas to calculate journal line amounts. You can then upload your journals to Oracle General Ledger. Before uploading, you can save and distribute your journal worksheets for approval.

We can also import data from text files into spreadsheets, where it can be further modified before uploading to Oracle. This is useful to migrate data from legacy systems, or from any source that can produce delimited files.

Using Budget Wizard, download budget amounts to a spreadsheet, modify amounts, and then upload them back. You can also choose to download the actual amounts to compare it with the budget amount. Budget Wizard also allows you to plot graphs and do a graphical comparison on the amounts. Budget Wizard also provides budget notes. You can add descriptions to accounts and amounts in your budget and explain your budget within the budget worksheet, avoiding the clutter of external documentation.

Control Accounts


You are able to control data entry to an account by ensuring it only contains data from a specified journal source and to prevent users from entering data for the account either in other journal sources or manually within general ledger.

Security for Definitions

You can secure your setup and definitions by granting specific privileges to users to view, modify, and/or execute a definition. This enables you to control which of your users can view a definition, but not modify or execute it, or execute a definition without modifying it, or vice versa.

Following is a list of definitions that have this security available for:

MassAllocation and MassBudget Formulas FSG Reports and Components Accounting Calendars Transaction Calendars AutoPost Criteria Sets AuoReversal Criteria Sets Budget Organizations Chart of Accounts Mappings Consolidation Definitions Consolidation Sets Elimination Sets Ledger Sets Recurring Journals and Budget Formulas Rate Types Revaluations

Sequence for Reporting

Two sequences have been introduced, accounting and reporting sequencing. These are used to generate sequence numbers for journals that are coming from subledgers. The numbers are generated when accounting periods are closed. This is useful for statutory reporting in some countries.

Journal Line Reconciliation

Journal Line Reconciliation enables you to reconcile journal lines that should net to zero, such as suspense accounts, or payroll and tax payable accounts for countries, such as Norway, Germany, or France.

Enhanced Intercompany

11i Global Intercompany System (GIS) has been replaced with Advanced Global Intercompany System (AGIS) for actual and encumbrance journals. A separate responsibility can be used for this process.

Some of the GL Standard Reports converted into XML Publisher

Oracle General Ledgers Account Analysis, General Journals and Trial Balance standard reports are now integrated with XML Publisher.


2. Subledger Accounting 2.1 Introduction

Subledger Accounting (SLA) is a Rule-based accounting engine, toolset & repository. This allows multiple accounting representations for a single business event, resolving conflicts between corporate and local fiscal accounting requirements. The Functionality is similar to Global accounting engine used in Europe earlier.

SLA is an intermediate step between subledger products and GL. Journal entries are created in Subledger Accounting and then transferred to GL. Each subledger transaction that requires accounting is represented by a complete and balanced subledger journal entry stored in a common data model.

The high points of SLA would be:

There are no SLA responsibilities Users do not login to SLA SLA is a service provided to Oracle Applications SLA forms and programs are embedded within standard Oracle Application responsibilities

SLA provides the following services to Oracle Applications

Generation and storage of detailed accounting entries Storage of subledger balances (e.g. third party control account balances) Subledger accounting entries Subledger reporting (e.g. Subledger journal reports, open account balances listing)

Functionality of SLA is as follows:

Journal Entry Setup and sequencing Date Effective Application accounting Definitions Multiple Accounting Representation Multi-period Accounting Summarization Options Draft and online accounting Replacement for disabled accounts Process category Accounting Transaction account Builder Accrual Reversal Accounting Accounted and Gain/Loss Amount calculations Application Accounting Definition Loader Enhanced Reporting Currency Functionality A new transactional application that generates accounting impact Used to store detailed information not needed for a general ledger Sub ledgers post summarized activity to a general ledger periodically to maintain centralized account

balances for the company

SLA can be used by the following applications: Projects, Cash Management, Payables, Receivables, Assets, and Purchasing.


GL Flow with Subledger-Level Secondary Ledger

This is the typical flow within one product with SLA can be best described as:


2.1 Accounting Methods Builder

Accounting Methods Builder is a toolset to define journal entry rules for the transactions and events of a subledger application. This allows us defining multiple sets of rules to be used concurrently for different requirements.

Normally journals are split into three main components:

Descriptions Line Types Account Derivation rules

Description: Description can be on the entry or its individual lines. You set up descriptions, as many as you want, by using pieces of data from the transaction and constant values. It will identify journal line types, descriptions, and account derivation rules that will be used to create a journal entry for a particular event type


Type: The Line Type is another component, actually one of two main components of entry. The line type defines whether this is a debit or a credit, what accounting class is, where amount should come from etc. You can have a single invoice line or distribution to create as many debits or credits as needed.

Under type you can identify natural side of entry like Debit, Credit, Gain/ Loss This will determine accounting class You can set under which conditions the rule will create a line This can be tightened by defining the values needed for entry line generation, such as amount,

currency, conversion rate information

Account derivation rule: This determines to which GL account a line should be booked. You can have lot of flexibility around the account derivation rules. You can also set up a rule for each flexfield to be used, or you can make it more complex and build each flexfield segment by segment by combining multiple rules.

Normally these rules can be setup to derive the accounts or segment values from transactional data, including conditions of when to use a particular rule versus another.

Determine which rule will be generic or specific for a given chart of accounts This will identify what will be derived like Accounting flexfield or there respective segment or qualifier

value or Value from a value set This will also have a provision to define how the value will be derived for defaulting some Constant

values or any Source value or any mapping set

Accounting Methods Builder

The transaction objects and sources carry transaction information into the rules defined for each component of an entry. These components, for example, journal line type, account derivation rule, journal entry descriptions, are attached together as a journal line definition for a particular event.

Take a case if you set up a Journal line description for an invoice validation event, another one for a payment creation, another one for payment clearing. The set of such rules for a particular sub ledger application is called the application accounting definition. The set of application accounting definition for multiple applications is called sub ledger accounting method.

These accounting methods are assigned to each ledger, which determines what rules are applied when accounting is being generated for a particular ledger. If you have a setup with a primary and a secondary ledger, you could have different accounting methods attached to and used for each.


Setup - Application Accounting Definition (Navigation) o Setup > Accounting Setups > Subledger Accounting Setup > Accounting Methods Builder >

Methods and Definitions > Application Accounting Definitions Setup - Subledger Accounting Method (Navigation)

o Setup > Accounting Setups > Subledger Accounting Setup > Accounting Methods Builder > Methods and Definitions > Subledger Accounting Methods

Setup - Account Derivation Rule (Navigation) o Setup > Accounting Setups > Subledger Accounting Setup > Accounting Methods Builder >

Journal Entry Setups > Account Derivation Rules

At the data level, its a big change for all the subledgers, though there is a first generation changes we have noticed sometime when 11i Payables where concept of Accounting Events are introduced first time and accounting performed at subledger level first before moving into GL.

Inconsistencies in Accounting Generation like Summary vs. Detail Direct to General Ledger vs. Open Interface Inconsistent Drilldown from General Ledger Inconsistent Mechanisms for controlling Accounting:

o Flex Builder o Account Generator o Automatic Offsets


3. Accounts Receivables Revenue Management Enhancements

Partial Period Revenue Recognition enables the generation of revenue recognition schedules that respect the start and end dates of contractual obligations. Receivables delivers new, configurable accounting rules to determine the treatment of revenue allocations for partial periods. A contract that goes into effect in the middle of the current accounting period, revenue may be recognized for a partial, prorated amount.

As per the contractual obligations revenue can be recognized partially prorated for any accounting period based on the dates and rules. Receivables deliver new configurable accounting rules to determine the treatment of revenue allocations for a partial period. Ex: If a contract goes into effect in the middle of the period, recognize revenue partially on prorate basis for that month.

COGS and Revenue Matching

The new COGS and Revenue Matching feature satisfies this matching principle by synchronizing the recognition of revenue with the recognition of associated COGS. if revenue is partially recognized, the corresponding COGS is proportionately recognized.

Enhanced Payment-Based Revenue Recognition

Changing regulatory environment, companies are turning to payment based revenue recognition as the answer to meeting strict revenue recognition rules for specific business transactions In partnership with Lease Management and Loans, the newly enhanced Event-Based Revenue Management feature achieves payment based revenue recognition by associating transaction lines with revenue impacting contingencies. Revenue for impaired loans, evergreen-leasing agreements, and various miscellaneous fees can now be automatically deferred at first and, then, recognized when customers pay

Line Level Cash Applications

The Line Level Cash Applications solution allows application of receipts to specific transaction items such as individual lines, groups of lines, or tax or freight buckets

Funds Capture Enhancements Uptake

Oracle Receivables uptakes Oracle Payments new funds processing functionality, including new customer bank accounts model, to support the automated, electronic funds capture via Credit Cards, ACH, and bank-to-bank transfer

Refunds Enhancements

Oracle Receivables is fully integrated with Oracle Payables to deliver a seamless, automated process to generate check and bank account transfer refunds for eligible receipts and credit memos

Credit Card Chargebacks

Cardholders can dispute credit card charges with their card- issuing bank and when they do, the merchant is charged back by the card's issuing bank. This new feature allows merchants to reconcile balances accurately by recording credit card Chargebacks in the Receivables system

Balance Forward Billing

Billing functionality for industries where customers are billed for all their account activity on a regular, cyclical basis. Balance Forward Billing provides the ability to setup cycle-based billing at the account or account site levels, enable event based billing, and leverage user configurable billing formats

E-Business Tax


Oracle E-Business Tax is a new infrastructure for tax knowledge management and delivery using a global system architecture that is configurable and scalable for adding country specific tax content.

Receivables Reconciliation Enhancements

Easily reconcile your receivables using enhanced reporting. Quickly match your transactional data to your accounting data. Highlight the possibility of incorrect set up with newly added exception reporting that suggests potential reconciling items. Reconcile Receivables to the General Ledger using one flexible report that automatically compares account activity by GL account.

Audit your balance sheet accounts in Receivables with a cumulative balance report that lists details making up the account balance.

AP/AR Netting

The matching of open receivables and open payables is automated.

Bills of Exchange Obsolescence Collections Workbench Obsolescence

Uptake of Cross-Operating Unit Initiative

This allows users of Oracle Advanced Collections to view and manage their customers across operating units. Collections activities such as strategies and work items, dunning letters, and collections calls can incorporate transactional and customer data from different operating units if needed.

Consolidation of Collections Functionality into Advanced Collections

Features in Oracle Advanced Collections such as scoring, collections strategies, enhanced payment and promise processing, automated promise tracking, and automated collector work assignment

Improved Payment Processing and Customer Funds Capture

Oracle Advanced Collections uses Oracle Payments new payment formatting and end-to-end electronic payment. Collections agents can select from customer credit card and bank account data (masked if desired)

XML Publishing Technology for Collections Correspondence

Oracle leverages XML Publisher tool to manage and generate all correspondence sent to customers, including dunning notices and confirmation letters regarding payments, promises, disputes and adjustments.

Consolidated Collections with Lease Contracts or Loans

Allows a collections agent to see both Oracle Receivables and Lease Management or Oracle Receivables and Oracle Loans transactions simultaneously. This approach allows the collector to more effectively work with customers during a single customer interaction.

Forward Billing

Use balance forward billing to print a single bill that includes all of a customer's transactions for the billing period and any balance carried forward from the previous billing period. We send one consolidated bill to a customer, instead of a separate invoice for each transaction. Statements and Forward Bills are similar, but they have different purpose. Statements are for information and based statement cycle; where as Forward Bill is meant for making payment and is based on Billing Cycle and Currency.

Bill contains the following details: A beginning balance or the balance carried over from the last billing period. An itemized list of current charges and activities (such as invoices, credit memos, debit memos,

adjustments) in either summary or detail format. Payment received for the last billing period.


Current total outstanding balance.

Late Charges

We can calculate late charges against past due debit items for each customer, account, or site. Late charges are calculated according to organization's late charge policy. Late charges can be calculated using multiple methods: Interest tiers for increasing late charges as invoice becomes overdue; Average Daily Balance Charge Calculation; Setting Minimum Customer Balance for Late Charge.

The process is as follows: Design the Late Charge Policy


Assign Late Charges for Customer and Site Level Submit Generate Late Charges concurrent program to calculate late charges according to organization's

defined late charge policy. Navigation: Late Charges > Generate Late Charges Review Late Charges Report, which outlines draft or final charges Late charges are created as interest invoices or debit memos, Invoice API creates late charges. If late

charges are created as adjustments, then Adjustment API creates late charges. After creation, charges are available for inclusion on statements and dunning letters. Review final late charges in both Late Charges Batches window, as well against each charged customer's account.

Refund

In Receivables, we can Refund excess payment made by customer at the time of receipt application. We raised an invoice for USD 999 and customer makes the payment for USD 1000. Then we can apply 999 against the receipt and refund USD 1 to the customer.

The process for this refund is as follows:

Enter Customer Invoice for USD 999 and complete the Transaction. Now the customer balance is USD 999.

Enter Receipt for USD 1000 based on actual payment by customer. Apply this receipt against the transaction of USD 999.


Now we have unapplied amount of USD 1. Use Receipt application of Refund for remaining amount of USD 1. For this purpose, we need Receivables Activity for Refund as we need to mention the activity at the time of application.

Online Payments

We can receive customer payments through Credit Cards or Bank Account Transfer from customer bank account to our bank account. However receipts must come from banks as automatic receipts and it is not possible to enter them as manual receipts in AR.

When customer transaction is entered, mention the receipt method as CC/ Account Transfer Create Receipt Class separately for Credit Cards and Account Transfers Obtain Electronic Statements for receipts and create them as automatic receipts and apply them against

the transactions entered

In case of any issues with customer, use Credit Card Chargeback or Refunds to return the payment.

Accounting Process in 11i

In 11i, three distribution tables are used for invoices / Credit Memos / Debit Memos to capture accounting class & amounts information

Receipts & Adjustments, Unapplied, applied, Both debits & credits Misc. Cash Receipts, Both debits & credits

View Accounting is a report against distributions to see the accounting information stored in these tables.

How Payables Accounting happens in 11i

We know accounting data generated and stored in Accounting Events tables prior to transfer to GL in Payable. Once Transaction get completed it was need to run the Create Accounting process which basically populate data into accounting events tables. Then the actual line information move takes place from accounting events table to General Ledger Tables. The existing 11i accounting Process is can be best understood by figure below.


Subledger to Ledger Reporting in 11i

It means complete, final accounting only available in the GL

All debits and credits All journal entries All balances

How it is resolved in Release 12 Subledger Accounting

All sub ledger accounting data generated and stored in shared SLA tables prior to transfer to GL, and this is achieved by running Create Accounting to populate SLA tables (Similar to Payable events). Once this can be done, users can View Accounting only after Create Accounting is run and completed successfully.

Transferring Accounting information from AP/AR to GL in R12

The Create Accounting process has similar options, you can create accounting in Final or Draft mode and if Final mode is selected, the Transfer to GL parameter can be used to automatically transfer the accounting created by the corresponding run. When the Create Accounting process transfers the journal entries to GL it only transfers the accounting created by the process that calls it. If there is accounting created by the online option = Final or a previous Create Accounting program that was not transferred, that accounting will not be transferred. The Transfer Journal Entries to GL program needs to be run separately to transfer any accounting created online or created by a previous Create Accounting process that did not transfer the entries.

Is/was link an issue in 11i?

Yes, From Distributions to SLA

Create Accounting process Applies accounting rules Loads SLA tables, GL tables

Creates detailed data per accounting rules, stores in SLA distribution links table

SLA Distribution Links Table


Must join through to get true Distribution ==> SLA journals matches Holds finest granularity of accounting data Multiple distributions may be aggregated into a few SLA journal lines

Final picture looks like:

Event Model are basically definition of the sub ledger transaction types and there life cycle.

It has three levels

Event Entity: Highest level, often 1 per sub ledger. Ex: Payables Event Class: classifies transaction types for accounting rule purposes. Ex: Payables Invoice Event Type: for each transaction type, defines possible actions with accounting significance. Ex:

Validated, Adjusted, Cancelled

Applications must tell SLA when an event has occurred. When a user runs SLA Create Accounting program, it processes all events with appropriate status

Payables o Invoice o Debit Memo o Prepayment o Payments o Refunds

Receivables o Invoice o Deposit o Receipt o Bill Receivable

Event Types:

AP Invoice Events o Validated o Adjusted o Cancelled

AR Receipt Events


o Created o Applied o Unapplied o Updated o Reversed

Transaction Account Builder (TAB) which normally used to derive default accounts for particular transactions using sources, which is defined in Accounting Methods Builder (AMB). Normally this derives accounting codes from the TAB which internally driven the AMB setup attributes. TAB only derives default accounts for transactions. These accounts may not appear on subledger journal entries as they are generated by Create Accounting program based on application accounting definitions.

Moreover you can see the source and account derivation rules (ADD) are shared with the AMB which was discussed in one of the last post.

Multi-Fund Invoice Accrual - Balancing Method

Requirement: 1. Post Revenue to multiple Revenue accounts with different balancing segment values 2. Generate multiple Receivables Accounts based on different Revenue Accounts on a single invoice.

Functionality: 1. Function similar to Automatic-Offsets with Balancing Segment method in Accounts Payable Module is required. 2. Similar functionality exists in Receivables called Multi Fund Invoice Accrual


Steps: 1. Setup Auto accounting to generate multiple revenue accounts using standard memo lines on a single invoice with different balancing segment values

2. AutoAccounting will generate default distributions, which are not the final accounting entries

3. Modify Sub Ledger Accounting definition

4. Create invoice and check default distributions and accounting entries created by SLA

Note: - Modifications to be made by event class and testing to be done in test instance. - Need to create your own Sub Ledger Accounting Method and Application Accounting Definitions (AAD) as system will not allow you to modify any thing with owner as Oracle.

Step1: Auto Accounting Setups

Step2: Setup Memolines with different balancing segments for revenue accounts mapping


Step 3: Modify SLA definitions for Receivables Application Accounting Definition

Create Custom Account Method copying the standard accrual method Create Custom Application Accounting Definition copying the default accrual definition Assign the Custom Application Accounting Definition to Custom Accounting Method. Modify the Accounting Definition for Invoice Event Class Assign the custom Accounting Method to Ledger using the Accounting Setup Manager Validate the custom Application Accounting Definitions

a. Create Custom Account Method copying the standard accrual method

b. Create Custom Application Accounitng Definition copying the default accrual defintiion


c. Assign the Custom Application Accounting Definition to Custom Accounting Method.

d. Modify the Accounting Definition for Invoice Event Class


e. Assign the custom Accounting Method to Ledger using the Accounting Setup Manager

f. Validate the custom Application Accounting Definitions

Step 4. Create invoice and check default distributions and accounting entries created by SLA


4. Accounts Payables 4.1 Suppliers

Suppliers in 11i

Suppliers are defined in Payables using Oracle Forms Supplier Contacts are replicated for each supplier site

Suppliers in R12

Supplier becomes as TCA Party Suppliers Sites as TCA Party Site for each distinct address Contacts for each supplier/address, it means Single supplier address and contact can be leveraged by

multiple sites for each OU A single change to an address can be seen instantly by all OUs No longer need to manually push updates across OUs

The Impact from upgrade can be summarize as:

1. When we upgrade supplier tables replaced with backward compatible views.

2. One party site for each distinct supplier site address

Country and address line1 are required due to creation of suppliers as Party in TCA data model would requires Country and address information, but it also understood if there is no country or address line 1 specified for a supplier site in cases when upgrades takes place, Payables derives the country based on the most frequently used operating unit of the Suppliers historical transactions.


3. Employee as suppliers: address NOT migrated to party site in TCA remains in Oracle HR for data security reasons.

In 11i employees are part of internal suppliers record to create payments for expense reports. Employees defined in HRMS and associated with Payables supplier record have existing party information. During the upgrade, Payables updates the existing party information to have a party usage of supplier but it does not migrate the employee address to the party site in TCA, they remain in Oracle Human Resources for data security reasons.

4. Utilize TCA Party relationships for franchise or subsidiary and its parent company.

4.2 Supplier Invoices

Supplier Invoices in 11i

Till 11i version, we have seen invoices:

Had only distributions line Allocation of freight and special charges are captured at the distribution level only Tax and payment and Project accounting Payment was captured through global Descriptive Flexfields Expense Report information is transferred through Descriptive Flexfields

Supplier Invoices in R12

1. Invoice Lines as a new additional line accommodated in Invoice data model.

There is significant improvement of data flow with other modules like

Fixed Asset - Asset Tracking, Assets Book, Manufacturer details, model etc. Business Tax - Tax line Payment - Payment Sub Ledger Accounting - Accounting

Allocate freight and special charges to lines on invoice. Invoice distributions created at the maximum level of detail similar to 11i.

The impact with Upgrade can be summarized as:

1. One invoice line for every distribution in 11i 2. Sub Ledger Accounting requires that Payables transform the invoice distributions to be stored at the maximum level of detail 3. Global Descriptive Flexfields migrated to named columns.


Internal Bank Accounts

In 11i we have seen internal Banks defined in AP and that is shared by AP/AR/CE, Payroll and Treasury and they are bank accounts often replicated in multiple OUs

Where as in R12,

Bank and Branch become part of TCA Parties. Internal Bank Account in Cash Management which is owned by a Legal Entity. Here the

Operating units have granted usage rights.

Suppliers Bank Accounts

In 11i

Banks/Branches defined in AP Bank accounts often replicated in multiple OUs Before

R12

Suppliers, Banks and Branches are defined as Parties in TCA Supplier (partys) payment information and all payment instruments (Bank Accounts, Credit

Cards) moved into Oracle Payments.

The typical data model for bank can be summarized as:


Impact of Upgrade

1. With Upgrade banks and branches migrated to TCA parties 2. Banks merged if the following attributes are all the same:

a. Bank Number b. Institution type c. Country d. Bank admin email e. Bank name alt f. Tax payer ID g. Tax reference number h. Description, Effective dates

3. Bank accounts, bank account uses are migrated into cash management. 4. Transactions are stamped with the bank account uses identifiers as part of the upgrade

4.3 Retainage

The process for Retainage is as follows:

Step 1: Create Documents Style in Purchasing for Retainage:

Navigation: Setup-Purchasing-Document Style-Create


Enter Name, description and status for document style. Enable Retainage under Complex Payment Region. Once this is created, verify the status and that will be Active.


Step 2: The Retainage account is defined at the Operating Unit level in Financial Options. However the % is selected at the supplier level under Key Payment Setups.

Step 3: Enable Retainage % at supplier level:


Mention % in Retainage Rate filed.

Step 3: Create Purchase Order using Document Style created earlier. (N) Buyer Work Center-Orders or Go to (T) Orders- Create> Document Type- ABC Standard Po)


Select invoice lines and enter quantity and price. Complete the PO.

Step 4: Create Invoice based on PO:


Step 5: Notice the Retainage in Invoice Lines Distributions.


5. E-Business Tax In 11i

Oracle standard functionality was based out of User which determines tax by assigning Tax Codes at line level of invoice and Tax rules was controlled at underline code.

Global Descriptive Flex Fields were used to capture country-specific tax attributes. Taxes are defined at OU level. So we need to define the same tax once per Operating Unit

In R12

eBusiness Tax determines tax based on each transaction, Oracle has introduced additional line information at invoice level.

eBusiness Tax set and configure Tax rules can be viewed All Tax attributes are collected in fields on key entities Configure tax rules once per regime and share with your legal entities

Impact of Upgrade

Payables Tax setup, Tax Code defaulting rules defined per OU are migrated to eBusiness Tax. OUs migrated to tax content owner in R12 Tax information in tax codes are transformed to Regime-Rate flow. E-Business Tax takes information from the AP invoice lines and creates summary and detail tax lines in

the E-Business Tax repository.

Feature Release 11i Steps Release 11i Usage in E-Business Tax

Using E-Business Tax

Tax Definition

Define a tax code for a new rate. Create a tax group code for tax codes that occur together.

Define a tax classification code and create a direct rate determination rule with this code. Define a tax rate code in the context of a tax regime, tax, and tax status.

Use Place of Supply or Applicability rules to determine which taxes apply. Use Status or Rate rules, if necessary. Use jurisdiction rates. Use Recovery Rules, if applicable.

Tax Code Defaulting Hierarchy

Define defaulting hierarchy using system options and select a tax code for each source.

Update/ define defaulting hierarchy using Application Tax Options and select a tax classification code for each source.

Replace defaulting hierarchy with tax rules for specific tax regulations.

Tax Jurisdictions

Define location values under a location structure and associate each value with a tax rate.

Update/define location values and rates under: TCA geography hierarchy and tax zones Tax jurisdictions Tax rates

Define multiple tax rates for a Jurisdiction, for different statuses and rates.

Tax Inclusive Settings

Define Standard Inclusive Handling and Standard Non-Inclusive Handling at Receivables System Options, Tax Codes and Tax Groups levels. Set Tax Inclusiveness at the customer/ site and supplier/site

Update/define Standard Inclusive Handling, Standard Non-Inclusive Handling, and Special Inclusive Handling at the tax regime, tax, and tax rate levels.

Set Tax Inclusiveness on invoices at the party/party site and account tax levels. Use Configuration Owner Tax Options for a combination of configuration owner and application event class to define the order in which parties/registrations are checked for tax inclusiveness and to override tax inclusive handling on transactions.

Tax Recovery Allow Recoverable Taxes Allow Tax Recovery setting Add tax recovery rules by


setting defined at Financials System Options. Recovery rates and recovery rules associated with tax codes.

appears at both tax regime and tax levels, for more granular control. Recovery rates upgraded under the tax Primary Recovery Type. Accounting-based recovery rules upgraded as tax rules for recovery.

intended use and/or product fiscal classification. Optionally define a secondary recovery type and rates for Canadian taxes.

Tax Registrations

Define separate single tax registrations for: Supplier Supplier site Customer Customer site HR organization

Backward compatibility for: Tax reporting registration number and tax registration type for supplier/supplier site party tax profiles. Tax registrations for customer/custom per site uses level. Tax registration for first party legal establishment tax profile.

Define multiple tax registrations for the same party and different tax regimes, taxes, and tax jurisdictions. Define detailed information each tax registration. Set up user-definable tax registration types, statuses, and reasons. Use tax registration statuses in tax rule

Tax Exemptions

Define tax exemptions for both items and parties. Use Customer Exemptions set at Receivables System Options. Allow Tax Exemptions set for tax code. Define tax exemptions for a combination of party and tax code.

Tax exemptions refer to customer exemptions only; set up item exemptions as tax exceptions. Allow Exemptions set at Configuration Owner Tax Options for a combination of configuration owner and application event class Allow Tax Exemptions set at tax regime level to apply to all taxes, and at tax level for further granularity

Set up tax exemptions as part of a third party tax profile for a customer/customer site and tax regime, and optionally for a tax, tax jurisdiction, tax status, and tax rate.

Steps

Establish TCA geography for India. This is required as Taxes are levied at a level lower than country level i.e. at state level

Define Location information for first party legal entity and legal establishment First party legal entity, to represent our company First party legal establishments for tax registrations from tax authorities. Ex: Office, Warehouse Legal authorities to represent tax authorities in tax regimes where you do business. These are

Collecting and Reporting Tax Authorities. Ex: Service Tax Commissioner in a Tax Circle, where we submit Service Tax Semi annual Statements; All Nationalized Banks can be defined as Collecting Legal Authorities as they collect the Taxes on behalf of Tax Authority.

Define Tax Zones for grouping purpose, where Tax characteristics are similar Define Tax Regime for Country or Zone Define Taxes and specify geographical level, where this tax is applicable Specify Tax Jurisdiction for each tax using geography or Tax Zone Use Tax Rules for specific calculations

Complete the following at the Operating Unit Level:

Party tax profiles - To indicate that the operating unit either uses tax configuration of legal entity for transactions involving legal entity and tax regime, or acts as a configuration owner for the applicable tax regime.

Tax configuration options for applicable operating units when you set up a tax regime or a party tax profile. The configuration option associates the operating unit with tax regimes either to share the tax setup of the global configuration owner or to act as a configuration owner and maintain a separate tax setup.


Tax accounts - set up tax accounts for a single operating unit, or share tax accounts across multiple operating units. The accounting segments associated with the selected operating units are available for tax account purposes. The calculated tax amounts post to the operating unit accounts that you define.

Configuration owner tax options - Set up configuration owner tax options for a combination of operating unit configuration owner and application event class. The configuration owner tax option settings let you modify the manner in which tax data is configured.


6. Multi Org Access Control In 11i

Access one operating unit per responsibility using Profile Option: MO: Operating Unit To view second OU, switch responsibility and access

In R12

Flexibility to access one or more operating units depending on the role To Access one Operating Unit, continue with MO: Operating Unit Profile Option To access multiple operating units,

This feature enables user to access data from one or many Operating Units while within a set given responsibility. Due to this change, all processing and some Reporting in Oracle Payables is available across Operating Units from a single Applications responsibility. Hence you can isolate your transaction data by Operating unit for security and local level compliance while still enabling shared Service centre processing. Data security is maintained using the Multiple Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.

Impact of Upgrade

R12 Upgrade does not automatically create security profiles, thus is important if any one want to use Multiple Organizations Access Control, the first things is to define security profiles, then link them to respective responsibilities or users.

Process:

Define all operating units based on Company requirements Establish the hierarchy using Organization Hierarchy within or across Business Groups. This window is

available from Fixed Assets Application Define Security Profile using HRMS Application Responsibility Run Security List Maintenance Program from HRMS Responsibility Assign the Profile Option, HR: Security Profile at the Responsibility or User Level Assign the Profile Option, MO: Default Operating Unit to the frequently used Operating Unit so that it will

be defaulted in transaction windows


7. AP/ AR Netting When a trading partner is both a customer and a supplier, Netting Agreement may be made to offset open receivables against open payables items. Netting Agreements add trading partner terms as well as deploying company controls. A selection program automatically pulls information from Oracle Receivables and Oracle Payables taking into consideration discounts, late fees, and withholding taxes prior to determining the final netting amount. A review process and trading partner approval afford further verification to support the netting event.

The matching of open receivables and open payables is automated. You are now able to determine whether you or your trading partner has a greater balance outstanding and update your books, collect payments or make payments accordingly.

AP/AR Netting provides for the ability to collect on your receivables balances with the amount owed for your purchases by offsetting one against the other. This will reduce bank Charges, Fewer Transactions to Process and thus significant Cash flow Improvement.

AP/AR Netting automatically compares Payables to Receivables and creates the appropriate transaction in each system to net supplier invoices and customer invoices. With this functionality, A receivables user can

View netted receipt details directly from the receipt Create Netting Agreements and Netting Batches

With this functionality, there is significant increase in user productivity and effectiveness because of tight integration and automation. The process for this is as follows:

1. Define Netting Control Natural Account

Create one natural account in chart of accounts to handle netting transactions.

2. Create Bank Account

Create new bank account exclusively for netting purpose for a bank branch. Ensure that Netting A/c check box is enabled. Note that Payment document is not required for netting bank account. Navigation: Setup> payment> Bank and Bank Branches


3. Define Receipt Class for AR/ AR Netting

Oracle provides seeded AP/AR Netting Receipt Class. Query this and provide the bank accounts created earlier. Navigation: Receivables> Setup>Receipts>Receipt class

4. Attach your bank account in this receipt class.


5. Use System Options in Oracle Receivables and go to Transaction and Customer Tabbed Region. Enable Allow payment of Unrelated Transactions check box.

6. Create Netting Agreement

Create Netting Agreement for Trading Partners, who are suppliers and customers. Navigation: Receipts>Netting>Netting Agreement


Agreement creation is three step procedures. Select Netting A/c, Currency, and other details as shown below:

Add all Suppliers and Customers, who are part of this agreement. This means we requires one netting agreement per combination of Supplier and Customer.


Once the agreement is completed, then review the agreement for correctness.

7. Enter an Invoice in Payables, validate and run create accounting.

Enter one or more invoices for the Trading Partner. These can include Standard Invoices, Credit Memos, Debit Memos etc.

8. Enter a transaction in receivables.

Enter one or more customer transactions in receivables and complete the transactions.

9. Create Netting Batch

Netting batch can be created any time as part of business when we are ready to net the balances for the trading partner. Once parameters are entered, and then submit for creation of batch. This process is automatic. Navigation: Receipts> Netting> Netting Batch


10. Verify Netting Batch

Query your netting batch and see the status as Complete. Click on view report icon on right side. Click on run push button, you can see the final netting report.

11. Go to view > request > find

Notice 3 concurrent programs: Create Netting batch, Settle netting batch, Netting Data Extract. Check Proposed Netting Report and Final Netting Report


12. Check AP/AR Netting Receipt.

Now we can verify the receipt created by Oracle using the receipt method and bank a/c and status is cleared.


13. Verify Accounting Entry

Check the Accounting Entry created for receipt. Dr Netting Control Account (defined in first step a) and Cr Receivable Account.

14. Verify Payables Invoice and Payment

Check invoice number and click tab view payments. See payment details and copy the document number.

15. Verify Payment Document

Notice that the payment type is Netting. Click Actions button and enable check box create accounting. Once Accounting is completed, then verify the A/c entry.


8. Centralized Banks Cash Management model is used to manage liquidity and control cash, some techniques like Cash pooling will help organizations use idle funds and reduce external borrowing which will help organizations use cash optimally. Some enhancements like Bank Accounts transfers are very useful features for those who deal with multiple/concentration accounts.

New Bank Account Model:

Banks are now taken into Trading Community Architecture (TCA) which will give several benefits when customers are using shared services models for disbursements and collections. Benefits from the new bank account module are:

Internal Bank Accounts are defined and managed centrally and act as a single point of access for all other modules like payroll, payables, receivables, treasury etc.

Bank Account access for each application is made explicit for security and internal control purposes. Each bank account is defined for Bank & Bank Branch combination which is defined in TCA A single Legal Entity is granter ownership for the Bank Account and user rights are provided for

organizations. Since the bank account is at legal entity level reconciliation made easy as it is one account against

multiple in previous models, reconciliation options are defined at bank account level.

Multi-Org Access Control (MOAC): Supports MOAC and users can work on multiple organizations from a single responsibility.

Sub-Ledger Accounting (SLA): Cash management is tightly integrated with SLA and all cash management accounting is handled using SLA.

Bank Account Transfers:

Balances can be transferred between internal bank accounts manually or automatically using physical cash pools, this feature earlier supported from treasury is now supported in Cash Management.

However payment processing is handled using Oracle Payments and accounting using SLA.

Cash pooling:

Oracle Supports following cash pooling techniques:

Self Initiated Physical Cash Pools Bank Initiated Physical Cash Pools or Zero Balance Accounts (ZBA) Notional Cash Pools

Note: Cash pooling techniques which are supported earlier form Treasury are now supported form Cash Management; however cash pools spanning different legal entities are still supported from Treasury only.

Self-Initiated Cash Pool: This type of cash pool is controlled by organization users. This includes defining rules to automatically determine when bank account transfers should be made and for what amount. Users can accept or overwrite system generated Transfer Proposals.

Bank-Initiated Cash Pool or Zero Balance Bank Accounts (ZBA): This is also called as Zero Balance Accounts as no balances are left in the accounts at the end of the day as they are swept to concentration accounts.

Organizations can use Bank Service to automatically sweep all end of day balances to and from main concentration account. Oracle Cash Management automatically creates and reconciles all the related sweep transactions based on reported prior-day bank statement activity.

Notional Cash Pools: Organizations may utilize notional cash pool arrangements offered by banks that track not only individual account balances but also the net balance across all accounts. This technique is common


in some countries and does not require physical cash transfers to be made between accounts for concentration purposes.

Other Features:

Bank Statement Accounting: Users can create Matching Rules which are used to automatically create and reconcile transactions in Oracle Cash Management based on reported prior day bank statement lines. Matching Rules are defined based on Bank Accounts, Transaction Codes and Text Search Strings.

Reduces reconciliation issues associated with repetitive first notice items like bank fees or bank account interest. Transactions that were created are stored in Cash Management are available for reporting as well as for automatic reconciliation.

Support for New Balance Types: New Bank Account balance types supported for internal bank accounts (Ex: Ledger, Available, Value date, I day float, 2 day float, projected to date, MTD, YTD).

Interest Calculation: System allows the users to verify interest amounts charged or credited by their banks based on balance history and user-defined interest rate schedules.

Bank Account Signing Authority: Users can indicate single and joint signing limits for each bank account as well as signer group categories, effective dates, approval statuses and other relevant information.

Electronic copies of documents like Passport Photos, Signature files or Bank documents directly to signing authority records.

Using Oracle Workflow approval requests can be routed for signing authorities, or users can set status manually.

Cash Positioning Intra-Day Activities: Intra-Day bank statement activity can be included or excluded from Cash positioning.

Release 12, what is new than


Bank Accounts will be stored in a new table called CE_BANK_ACCOUNTS and will be located at a Bank Branch.

The new tables which hold the bank information are as:

1. CE_BANK_ACCOUNT: stores bank account attributes 2. CE_BANK_ACCT_USES_ALL: This stores the bank account use attributes specific to Operating Unit

(AR, AP) and Legal Entity (Treasury). 3. CE_GL_ACCOUNTS_CCID: The accounting data pertaining to the bank account use will be stored in the

table.


9. Funds Disbursement (Payments) Fund Disbursement functionality has been moved to new Payment module:

Creation & validation of payments Aggregation of payments into files Format & transmission of files

where as selection & approval of invoices remains in Payables itself.


10. Fixed Assets SLA Integration

Asset accounting is tightly integrated with SLA, users can use the seeded accounting definitions or can define custom definitions leveraging the flexibility of SLA.

Mass Additions Enhancements

New columns provided to Mass Additions interface tables to import certain values like asset life, depreciation method etc from legacy systems without deriving from asset category setups

New extensible pubic APIs provided to automatically prepare mass additions without user interface for all required attributes such as expense account, asset category, location etc.

XML Reports

XML publisher support major asset transaction reports in variable formats by creating your own templates using familiar tools such as Acrobat, Word and Excel.

Automatic Depreciation Rollback

Function to Roll Back Depreciation is removed as it is handled by the Assets automatically.

If users need to make adjustments to one or few assets after running depreciation without closing period, they can proceed to do so, oracle assets rollback depreciation for the assets adjusted automatically

Assets for which depreciation was rolled back is automatically picked up during the next depreciation run or at the time that the depreciation period is finally closed.

Other Enhancements

Enhanced logging for Asset Transactions and Programs

Enhanced functionality for Energy industries a) Asset Impairment b) Energy units of Production Method (UOP) c) Energy straight line method.


11. Frequently Asked Questions

1. Explain any Five Major Features in R12? 2. What is the difference between Primary ledger and Secondary Ledger? 3. What is the purpose of Data Access Set in General Ledger? 4. What are the components of Ledger? 5. What is the fourth C introduced in R12 with respect to Ledger? 6. What activities are possible with Accounting Setup Manager? 7. What are suppliers/ customers called in R12? 8. What is the relationship between Legal Entity and Operating Unit in R12? 9. Where are Banks defined? 10. Explain the sequence of steps to define Sales/ Service Tax for a supplier invoice. 11. What is the difference between intercompany and intra-company journals? 12. Explain the difference between Transaction and Accounting Chart of Accounts in SLA. 13. What is the purpose of Retainage in Payables? Under what business scenarios, is this relevant? 14. What advantages can we derive from Invoice Lines in Payable? 15. What is MOAC? How is this useful for Shared Services Business Model? 16. List at least Three Profile Options relevant for MOAC? 17. What is the purpose of MO: Default Operating Unit profile option in MOAC? 18. What is AP/AR Netting? When do we need this functionality? 19. Identify Sixth Flexfield Qualifier for Chart of Accounts? What is the purpose of this new qualifier? 20. What is Accounting/ Reporting Sequence? 21. What is Carry Forward Billing in Receivables? 22. What is the difference between Draft and Final Accounting in SLA? 23. How do we process Supplier Payment Batches in R12? 24. What is Accounting Methods Builder in SLA? 25. What is the difference between Accounting Methods Builder and Transaction Account Builder in SLA? 26. What is the difference between Event Class and Event Type in SLA? Explain with an example. 27. How is Web ADI integrated with Oracle General Ledger? 28. What are the prerequisites for creating foreign currency recurring journal in R12?

r 12 Delta Students White Paper

Documents

Transcript of r 12 Delta Students White Paper