89092672 r12-functionality

Sub Ledger Accounting (SLA)

"It’s not 3 C's any more".

First things first - You need not know SubLedger Accounting to perform an Implementation. One
can use the Standard seeded SubLedger accounting methods itself. However if the client wants a
special accounting treatment to be followed on a case to case basis, then we should know
something on SLA.

Firstly, one can create a new SubLedger accounting on his own (which will be a huge time
consuming process).

Secondly, one can copy an existing SubLedger accounting and make changes wherever required
(Highly recommended).

Thirdly, SubLedger methods owned by Oracle cannot be altered

SubLedger accounting method which is given by oracle are standard, which means they are not
specific to any chart of accounts, they work in the same manner. However one can create a
SubLedger accounting method for a specific chart of accounts.

The introduction of SubLedger accounting also changes the way in which transactions are
transferred to GL.

Earlier in REL 11,

SubLedger > Create Accounting >Run Transfer to GL > GL interface > GL Main Table

Now in REL 12,

SubLedger > Create Accounting > Sub Ledger tables (XLA) > Run Transfer to GL > GL Interface
> GL Main Table

The only difference in the accounting methods followed in REL 11 and REL 12 is that, access to
create an accounting method is given in the front end itself to the users in REL 12 which was not
there in REL 11.

Enhanced Feature - Create Accounting at Sub Ledger Level

Another enhanced functionality in Release 12, is nothing but CREATE ACCOUNTING program,
which is related to Sub Ledger Accounting. Briefly, Create Accounting program is used to carry
out accounting for transactions that are recorded in the sub ledgers based on the accounting rules
that are mentioned in the Sub Ledger Accounting Method.

You may think that we also had this create accounting functionality in Release 11 under Payables
Application. We did had this in Release 11 itself, but it was limited only to Payables module and
not to the other modules, now in release 12 this functionality is extended to all sub ledger
applications along with some enhanced features.

Now let us see, what the enhanced features of Create Accounting Program are.

In Release 11, when you create accounting for transactions, it will be done immediately; you did
not have the option of previewing before accounting. This led us to lot of reconciliation worries in
month end, since some manual entries get passed in General Ledger.

Unlike previous versions, Release 12 has provided the user with three new functionalities under
Create Accounting Program. They are:

1) DRAFT Mode - It is nothing but draft accounting which will help the user to know what are the
accounts that are getting used for this particular accounting event. You can correct your transaction
by looking at the draft entries. Draft entries will also be included in Accounting reports, but it
cannot be transferred to General Ledger since it does not reserve funds and does not update
balances. An entry in draft status can be Updated and Deleted.

2) FINAL Mode - It is normal online accounting functionality which we had in earlier release
also. It means that entries created using this mode cannot be changed. After performing this
accounting, transaction becomes eligible to get transferred in to General Ledger any time.

3) FINAL POST Mode - It is a very useful new feature, which does the operation of Straight
through accounting. When you select this particular feature, it Creates Accounting for the
Transaction with the mode Final, and transfers the accounting entries to General Ledger and it also
posts those entries in General Ledger.

With the help of new enhancements in Create Accounting feature, transactions and balances can be
up to date and reconciliation is made easy.

Is SLA a clone of AX?

Yes, almost the functionality was derived from there itself, lets see vis-à-vis to
uptake some of the functionality in these two products.

Not only functionality, some of the reports replaces the corresponding reports
of the Global Accounting Engine.

The good is that both the Global Accounting Engine (AX) and Oracle SubLedger Accounting
(SLA) generate accounting from a compiled definition of accounting rules defined by users. Oracle
SubLedger Accounting further maintains version control on the rules enabling users to modify the
rules while maintaining auditability

From Product Accounting to SubLedger Accounting:

Most of us are well aware that in Release 12 of Oracle Applications, SubLedger Accounting (SLA)
has been introduced, which is a Rule-based accounting engine, toolset & repository which is
supporting most of Oracle business Suite modules. As we know driver for this introduction is to
have an option of allowing multiple accounting representations for a single business event,
resolving conflicts between corporate and local fiscal accounting requirements. The Functionality
is somehow very similar to Global accounting engine, which oracle does offer for European
reporting need.

So what is SubLedger Accounting?
• SLA is an intermediate step between SubLedger products and the Oracle General Ledger
• Journal entries are created in SubLedger Accounting and then transferred to Oracle General
Ledger
• Each SubLedger transaction that requires accounting is represented by a complete and balanced
SubLedger journal entry stored in a common data model

Is this Module or what?
It is good to know, SubLedger accounting is a service, not an application.
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)

What oracle application Module is taking services for SLA?
Most of modules which need accounting entry with finance uses service of SLA Modules.
This new Product has many new functionalities such as:
• 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

The overall advantage of SLA can be summarized by oracle as below:

GL Flow with SubLedger-Level Secondary Ledger
Let us take a case, with a scenario with basic Finance module; you can find how tightly accounting
model is separated with transaction model in release 12.

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

Analyzing SubLedger accounting:
With this new feature:
• All accounting performed before transfer to the GL.
• And this is achieved by user setup of defining accounting rules.
At the data level, it’s a big change for all the SubLedgers, though there are first generation changes
we have noticed sometime when 11i Payables where concept of “Accounting Events” introduced
first time and accounting was performed at SubLedger level first before moving into GL.
The same idea has been incorporated in new sub ledger accounting model, indeed there was a real
need because of some uneven functionality likes:
• Inconsistencies in Accounting Generation like Summary vs. Detail
• Direct to General Ledger vs. Open Interface
• Inconsistent Drilldown from General Ledger
• Also it has been seen that there are inconsistent Mechanisms for controlling Accounting as
certain options has been used in existing version:
o flex builder

o Account Generator

o Automatic Offsets

What does SubLedger mean for a non finance person?
• 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
With these accounting at this level the respective sub ledgers & General Ledger is tied out, as
below.

SLA Key attribute: Something called Event Model. What is it all about?

Event Models are basically definition of the sub ledger transaction types and their life cycle.

It has three levels

• Event Entity: Highest level, often 1 per sub ledger application

• Event Class: classifies transaction types for accounting rule purposes

• Event Type: for each transaction type, defines possible actions with accounting
significance.

It is very important that applications must tell SLA when an event has occurred? When a user runs
the SLA Create Accounting program, it processes all events with the appropriate status
Some of event classes in Payable and Receivable:
• Payables
o Invoice

o Debit Memo

o Prepayment

o Payments

o Refunds

• Receivables
o Invoice

o Deposit

o Receipt

o Bill Receivable

And typical event Types are like:
• AP Invoice Events
o Validated

o Adjusted

o Cancelled

• AR Receipt Events
o Created

o Applied

o Unapplied

o Updated

o Reversed

The Legal Entity Concept:

In Oracle Ebusiness Suite 11i, the Legal Entity is tied closely to a set of books and operating Unit,
so your Legal Structure has to be defined in the way you set up your apps partitions (OU, Set of
Books etc.). In R12, financials breaks away from that with the introduction of the Legal Entity
Configurator allowing you to model your Legal Structure separately from the partitions in your
ERP system. Then you mark certain items with an owning LE, rather than use the OU or set of
books to derive the LE. So let’s see what we are getting out of it:

Let’s first look at what we map Legal Entities to:

1. Accounting Structures - Balancing Segment Values and Ledgers

2. Tax Rules in eTax - Who I am and where I am registered/located determines what tax I need to
pay

3. Bank Account - Who owns that bank account and the cash in it?

4. Payables and Receivables Invoicing - the owner of that transaction, sometimes referred to as LE
stamping

5. Intercompany Accounts and Intercompany Processing Rules

There are a number of features that you get from this, probably the biggest is tax. The new eTax
module in R12 allows very flexible definition of tax rules, based on the Legal Entities and the tax
registrations. It makes your tax calculation and reporting a breeze.

Intercompany is obviously a big feature, we now base the Intercompany rules on the From

(transacting or Initiating) LE and the To (trading partner or Recipient) LE, which not only allows
more realistic rules, but provides us with the mapping we need to give you the neat Interactive
Reconciliation Reporting.

Also on the Intercompany Front it allows us to define a couple of important rules. Firstly we can
define Intercompany Exceptions, that is for LE x, I might want to state that it should not do
Intercompany with y and z. Secondly I can set a Legal Rule to tell me when there is a Legal
requirement for an AGIS transaction to generate an Invoice rather than just create GL journals.

Bank Account ownership is now by a Legal Entity, so we can more easily determine when a cash
transaction is crossing a Legal Entity and intercompany accounting is needed.

There are also a large number of Legal reports which have Legal Entity as a parameter, so the
numerous reports shipped in R12 will make it easy to the compliance and statutory details you
need on each Legal Entity that has to report. The Oracle Financials globalization products ship the
majority of these reports.

Can I assign an operating unit to multiple legal entities?

The short answer is sort of. This is not much help to anyone.

In R12, a new Legal Entity Configurator is introduced in financials and Legal Entities defined here
are assigned to Ledgers and/or Balancing Segments (Company Codes). However it is not possible
to assign a Financials Legal Entity to an Operating Unit, you can only define a Default Legal
Context (DLC) to an Operating Unit. This assignment can cause confusion as it is only possible to
assign one DLC, but I can use more than one LE in that Operating Unit. The key word in DLC is
default.
When I am in Payables or Receivables the LE is stamped on the transactions and used to identify
the Legal Owner for legal reporting as well as Tax calculation. The invoice exists within an OU
and that OU has a ledger which will account the transactions, if that has more than one LE
associated with it then a hierarchy of LE derivation is used to default an LE, the last resort being
the DLC.
For example in AR the Legal Entity derivation hierarchy for transactions is
1. Transaction Type
2. Batch Source
Assigning a LE to a transaction type or batch source is optional and only the LE’s mapped to the
Ledger associated with the OU are available to assign.

So in R12 we have much better support for many LE accounted in a single OU as we clearly mark
the LE on the transactions.
How do I define my legal entities?

In the real world a Legal Entity (LE) can enter into contracts, own cash (bank accounts), employ
people, pay taxes, be sued and similar. In Oracle Financials Release 12, a whole new product;
Legal Entity Configurator was created to manage them. It will allow you to define your real world
Legal Entities and then map them to the E-Business Suite objects and structures. Transactions are
stamped with an owning (first party) Legal Entity and that will be used to drive tax, accounting,
intercompany and Legal Reporting.
So let’s look at the relationships LE have to other E-Business suite objects.
1- Accounting Structures
In the General Ledger Set Up a Legal Entity can be mapped to
• A Single Ledger
• One or more Balancing Segment Values (aka Company Code) within a ledger.
2 - Operating Unit
There is no explicit mapping of Legal Entity to an OU, the relationship is derived from the ledger
assigned to the OU and the Legal Entity mappings to ledgers as detailed above.
So how might you set up your LE in relation to your other set up in financials? There are two
implementation models
1: Many
• LE are mapped to the Balancing Segment Value (BSV, aka Company code) within a
Ledger, so multiple LE are accounted for in a ledger.
• An OU will have one Ledger assigned so transactions for many LE are processed and
accounted in a single OU
1:1:1
• A single LE is mapped to a Ledger
• An OU will have one Ledger assigned
• Therefore an OU only has one LE (that means it is easy to derive the LE given the OU)
So what model should you use?
That depends where the LE are registered.
The 1: M model is recommended and preferred in the US, the 1:1:1 model is recommended for
most non US regions.

We are well aware of some of Oracle E-Business Suite R12 Architectural
changes in the Financials section like:

• Legal Entity
• Ledger Sets
• Accounting Engine (SLA)
• Transaction Based Taxes(E-Tax)
• Inter-company Accounting (AGIS)
• Multi Organizational Access Control (MOAC)
Let’s uptake to Legal Entity:

Financial books defined a “Legal Entity as an entity identified through the
registration with the legal authority.”

That means, in this compliance oriented world and in Oracle system it
corresponds closely. The system “Legal Entity” corresponds with an
independently identifiable “legal person” a public company, a private business
or limited partnership, a trust, a not-for-profit, a government or a non-
government organization (NGO) - that can operate as if it were a real person in
conducting business transactions.

What is meant for with LE?

• Can get the right to:
o Own property weather it is asset or inventory or receivables

o Trade (borrow, sell, buy, incur expenses, employ)

• And the responsibility to:
o Repay debt (liabilities, equity)

o Pay Taxes

o Account for themselves (legal reports, audits)

Note for R11i with respect to R12

Release 11i GRE/LEs will be upgraded as Release 12 Legal Entities.

Release 11i Operating Units and Inventory orgs will be upgraded as
Establishments.

One Legal Entity can have several establishments.

• In Release 12 there is no specific link between Operating Units and Legal Entities where as
in R11 it was.
• The Legal Entity is linked to a Ledger and the Operating unit is also linked to a Ledger.
• Every Release 12 transaction must be associated with both an Operating Unit and a Legal
Entity.
• The Legal Entity is also required for e-Business Tax to establish which taxes will be
applicable to the transaction.
The New Model called LEA (Legal Entity Architecture)

Legal Entity architecture, which is new in this release, provides users with the
ability to model an enterprise’s legal organizational structure and define rules
and attributes specific to legal entities.

Bank Account whether it is remittance bank or internal bank is now owned by
the Legal Entity instead of Operating Unit, and can be used by any of the
Operating Units sharing the same Ledger as that Legal Entity.

As marked (dotted red line) in above figure the relationship between legal
Entity and Operating Unit is no more active. This concept allows Operating
Units to be governed by more than one jurisdiction, but the accounting is still
performed in a single ledger.

Multiple Legal Entities can be associated with a single Ledger, allowing the LEs
to share the same ledger and chart of accounts, calendar and currency. Each
LE points to one Ledger.

Multiple Operating Units can also be associated with a single Ledger. Each OU
points to only one Ledger.

Take a note; in R12 EBS multiple legal entities can be associated with a single
Ledger, allowing the LEs to share the same ledger and chart of accounts,
calendar and currency. Each LE points to one Ledger. Multiple Operating Units

can also be associated with a single Ledger. Each OU points to only on Ledger.

Where it affects:

“Most of the Financial Application Products”

Cash Management (Bank)

In Release 12, Bank Accounts are owned by Legal Entities and can be
accessed by multiple Operating Units.

As we know in 11i the Bank Accounts were Operating Unit Specific.

For all Internal Banks should be assigned to a Legal Entity.
Receivables:

Now all REC activity must have a legal owner, so Legal Entity is stamped on
every transaction. Receivables activity such as transaction whether credit
memo or debit memo or invoice must have stamps on it and receipt header
with the Legal Entity information.

Because there can be multiple legal entities using the same ledger, it may be
necessary for the user to assign the LE. Each transaction can only belong to
one Legal Entity, so when multiple legal entities exist, either the system or the
user will assign the LE.

• Transaction
The defaulting hierarchy for a transaction comes from the setup of the
Transaction Type and Transaction Batch Source. Receivables will look first to
the Transaction type. If a LE has not been assigned, then Receivables will look
to the Batch Source. The assignment of the LE to the Transaction Type and
Transaction Batch Source is option, so if Receivables cannot find a default LE,
then it is up to the user to provide the LE value.

• Receipts
The LE defaulting for receipts works differently than transactions. Let’s look at
how defaulting occurs for the Receipt Header.
As we know, internal Bank Accounts are now owned by legal entities instead of
operating units, so LE defaults from internal (remittance) bank account. The
Receipt Method in Receivables has the bank account assignment, which
determines what bank account gets assigned to the receipt.

Take a note in version 11 the receipt Method was called the Payment Method.
Now in Release 12 this is featured with same name “Payment Method” now
used by new application called Oracle Payments. Therefore in AR, you will now

see a Receipt Method, which is part of receipt setup; and Payment Method,
which is part of Payments setup. Once the bank account is assigned to a
receipt header, this information can be used to find the appropriate LE.
Because the LE comes from only one source, the bank account, there is no
special setup to be performed in Receivables. Defaulting of the single LE
always occurs, so the user does not need to assign or update LE on receipts.

How LE affects receipts and their applications and refunds

We have seen that the receipts inherit the LE from the bank account weather
it is manual, Automatic, Lockbox and Post Quick Cash Programs. There is no
way that user can change the value.

Receipt application across Legal Entities is allowed if the receipt and
transactions are in same OU and Sub Ledgers Accounting will be performed by
inter-company accounting for cross-LE receipt applications or cross-LE receipt
clearing.

SLA will create inter-company accounting as long as LE is setup as one of the
CCID (Account Code Combination) segment derivation sources in SLA.

Payable

Invoices and Payments indicate the operating unit and the legal entity owner
of the transaction. The legal entity can be used as selection criteria when
preparing pay runs.

Projects

As we know in 11i, EBS maintains the default legal context on the Operating
Unit. There is not much impact in Projects model. Earlier in 11i we used to
consider the Legal Entity of the Operating Unit as the Legal Entity of the
Projects Transactions. Now the Legal Entity is attached at the Default Legal
Context of the Operating Unit is the Legal Entity of the Projects Transactions.

So the Legal Entity of the Projects expenditure transactions will be the Legal
Entity attached at the Default Legal Context of the Expenditure Operating Unit
and the Legal Entity of the Project will be the Legal Entity attached at the
Default Legal Context of the Project owning operating unit.

LE and TCA

Legal Entity is still dependent on TCA. A party (supplier, customer, bank,
student etc) is an entity that can enter into business relationships. As we know
the Oracle TCA’s model supports four types of parties: organization, person,
group, and party relationship. Under the TCA model, Parties (including Legal
Entities) exist just once in our E-business Suite system for single maintenance
and consistency. Legal Entities will be stored in TCA as Parties of party type
‘ORGANIZATION’. A Legal Profile, containing specific Legal Entity attributes,

will be associated to the TCA Party. In addition, other TCA components will be
used for Addresses, Contacts, Party Information, etc.

Where to do the setup

There should be no confusion.

May be , some may think if this is just extension of GRE/LE from old version ,
then Why this required to do set up from both ASM and HR in R12?

In R12, the legal entity is separate from the GRE which is a HR organization.
We did not link the 2 entities together as they serve 2 different purposes
altogether.

The HR model does not look at the new Legal Entity model. It continues to use
the GRE/LE as a legal entity. So the HR requirement can be achieved using the
HR organization of type GRE/LE.
Therefore, Legal Entities do have to be set up in both ASM and HR in R12

Management Reporting Security:
In R12 there is a new management segment qualifier for chart of accounts.
This would qualify a segment to be the management segment if that segment
has management responsibility and you can facilitate setting of Read, Write
access permissions while defining Data access set in GL.

With this new concept you can:

• Enable management reporting and analysis
• Provide a better controls access to specific MSVs based on management responsibility and
this can
o prevent managers/line managers from viewing or updating data for cost centers,
lines of businesses, product lines, etc. that are outside their responsibility
o Secure access to ledgers and management segment values

o Grant read only or read and write access to management segment values

This can be best understood as with this simple example, assume you
Business COA is based out of three things like

• line of business
• cost center
• product line
You can set Qualifier with any of the segments. The added benefit of using a
management segment is that you can now secure management segment values
using data access sets. So you can grant read only or read and write access to
specific management segment values to prevent certain managers from viewing and
updating data for cost centers, lines of business, or product lines outside of their
management authority.

Defining and Designing your Management segment qualifier

Define a management segment if you want to perform management reporting and
secure read and write access to segment values for the management segment. This
segment can be any segment, except the balancing segment, natural account
segment, or intercompany segment.

How it works

This can be understood as, lets we have four cost center like
C0699,C0101,C0201,C0312 and these cost center have Vice President, director A,
director B and Director C respectively. The Organizational Chart of cost center
hierarchy is as figure below.

If you assign the cost center segment as the management segment, read and write
access can be secured to certain management segment values based on the cost

center manager.

In above example , Director A has read and write access to only cost center C101.
Director A does not have access to Director B’s or Director C’s cost center or to the
Vice President’s cost center. This will true for others when you set to other. This way
you can secure Management reporting.

If you have given Read/Write to Parent Cost center 0699 to the Vice President, on the
other hand, would have full read and write access to cost center C0101, C0201 and
C0312 which is the parent of the direct reports. Thus, in that case the VP has full
access to all direct reports’ data.

Benefits of Management Reporting Security

The new management segment qualifier in combination with data access sets paves
the way for management reporting and analysis. You can restrict access to different
management segment values and assign them to different managers in your
organization.

How this can be achieved in EBS

This can be achieved by setting three steps

1. First step you have to find and designate a Management Segment for Chart of Accounts

2. Then you have to define Data Access Set to Secure the above designated Specific
Management segment values

3. Then you have to assign Data Access Set to Responsibility.
That’s all, to make security take effect for that responsibility.

Your Navigation should be from Responsibility: General Ledger

Navigation: Setup: Financials: Data Access Sets

Data Access Set and Management segment Value

As we know in Release 12, data access sets control which ledgers can be
accessed by different responsibilities. Data access sets can also limit a user
from accessing certain balancing segment values or
management segment values or grant read–only or read and write access to
data in a ledger.

GL automatically creates a data access set when you define a ledger or ledger
set. This system-generated data access set provides full read and write access
to ledgers. You can also provide more limited access to your ledgers and

ledger sets by defining your own data access sets.

Oracle General Ledger: New Features in R12
Accounting Setup Manager
The ledger is a basic concept in Release 12. 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.
Now, 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.
While a set of books is defined by 3 C’s,
1. chart of accounts
2. functional currency
3. accounting calendar,
The addition in this list the ledger is defined by a 4th C: the accounting method (Accounting
Convention).
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 is a new feature that allows you to set up your common financial setup
components from a central location.
What is Accounting Setup Manager
Accounting Setup Manager is a new feature that streamlines the setup and implementation of
Oracle Financial Applications. The Accounting Setup Manager will facilitate the setup required for
simultaneous accounting for multiple reporting requirements.
With the Accounting Setup Manager, you can perform and maintain the 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)
As discussed earlier 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 Made easy
GL has added new features and enhanced existing features to support foreign currency processing,
they are mainly as follows:
• In R12, MRC feature is enhanced with a feature call Reporting Currencies. That mean it
will now support multiple currency representations of data from any source, including
external systems, Oracle or non-Oracle SubLedgers, and Oracle General Ledger journals
and balances.
• The second one is in reporting to view balances that were entered in your ledger currency
separate from those balances that were entered and converted to the ledger currency. The
change in R12 is that balances entered in the ledger currency are maintained separately
from balances converted to the ledger currency for use in Reporting and Analysis.
Here’s an example. Assume we have a ledger and the ledger 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.
Now in 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’s 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 Oracle General
Ledger using a single responsibility, Oracle General Ledger provides you with flexible ways to
secure your 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
This can be best understood as: 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 didn’t 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 functionality is useful at the time of migrating data from legacy systems,
or from any source that can produce delimited files.
Using the Budget Wizard, you can download budget amounts to a spreadsheet, modify the
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:
1. Mass Allocation and Mass Budget Formulas
2. FSG Reports and Components
3. Accounting Calendars
4. Transaction Calendars
5. AutoPost Criteria Sets
6. AutoReversal Criteria Sets
7. Budget Organizations
8. Chart of Accounts Mappings
9. Consolidation Definitions
10. Consolidation Sets

11. Elimination Sets
12. Ledger Sets
13. Recurring Journals and Budget Formulas
14. Rate Types
15. Revaluations
Sequence for Reporting
Maintaining two sequences have been introduced, accounting and reporting sequencing.
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.
In R12, there are many improvements to intercompany accounting. R11i’s Global Intercompany
System (GIS) has been replaced with an exciting new product called Advanced Global
Intercompany System (AGIS). Intercompany balancing support has also been extended to include
encumbrance journals.
Enhanced Intercompany
Ability to create invoices (AR and AP)
Oracle Advanced Global Intercompany System can create invoices in payables and receivables sub
ledger from intercompany transactions.
Using Oracle Advanced Global Intercompany System user can enter transactions for multiple
recipients within a single batch. This allows user to submit intercompany transactions from one
initiator to one or more recipients in a single batch.
Proration of transaction distribution amounts
When user allocates more than one distribution account in a batch that has multiple recipient
transactions, Oracle Advanced Global Intercompany System can automatically prorate the
distribution amounts based on the recipient transaction amounts. The proration of amounts is also
used by Oracle Advanced Global Intercompany System to adjust the distribution amounts in the
batch when a recipient transaction is deleted or it is rejected.

Upload Transaction Batches created in Excel
This was a missing link in the earlier version, as earlier product does not have capability to use
direct upload functionality, rather than interfacing through Open GIS interface. In Release 12 ADI
is heavily used in this module, which is replacement of external integration for AGIS System using
by mean of Microsoft based Excel spreadsheet. Now flexibility is provided to user that can
generate spreadsheet templates that have features of intercompany entry pages and using the

templates the user can enter transactions in the spreadsheet and upload them into Oracle Advanced
Global Intercompany System. The good thing has found the standard templates can be customized
by removing or adding the entry fields from a list of available fields. This feature is used to create
a template that contains only the entry fields that are important for the business. The required fields
cannot be removed from the template. Once the templates are generated, user can save them in
their local computer to reuse them in the future. This figure describes the options available in both
the versions.

Multiple recipients Support

Reversal of batch/transaction

This changed feature enables a user to reverse a whole batch or an individual transaction in a
batch. When the user reverses a batch or a transaction, a new reversal batch is created, which
displays the references to the original transaction. One point to be noticed is that new batch is
submitted automatically immediately after it is created. Not both the parties (Sender /receiver), its
only users with access to the initiator organization can reverse its batches or transactions. The set
up is there where a user can choose a reversal method determining if the new batch will be created
with opposite signs, or with switched debits and credits.

Descriptive flexfield support

In AGIS descriptive flexfields is supported on the batch and also on individual transactions within
the batch. Descriptive flexfields allow user to enter any additional information specific to the
nature of business, in the batch and in the transactions. Important to note that these DFF can be
used by sender. The user can enter descriptive flexfield information for the recipient in the
Recipient Accounting section.

Flexible Approval Rules and Workflow Notifications

In R12, AGIS very similar to other module, home page displays notifications about approval or
rejection statuses of intercompany transactions. You should note that notifications can be sent to

the users via email. The rules for approvals and notifications can be customized using Oracle
Approval Management Engine (AME), which allows the user to add extra approval rules and
hierarchies to suit their business needs.

Document attachment

The user can attach the documents for the batch as well as for each of the transaction. When user
submits the batch, the documents are transferred to respective recipients.

Transaction security

Intercompany transactions entry pages incorporate various security features. The user can enter
transactions only for those intercompany organizations that are assigned to the user. Other security
features include minimum transaction amount, control amount and function security.

For example:

Intercompany accountant processes intercompany transactions for many intercompany
organizations in the enterprise. What is different between these two is :
• R11i - Each responsibility has only one subsidiary assigned, therefore a user can
initiate intercompany transactions for one subsidiary from each responsibility
• R12 – the user can initiate intercompany transactions for many trading partners
without changing responsibility
Intercompany Periods
The new Intercompany calendar gives the user the option to control intercompany transaction
processing by periods status.
What is observed in this functionality can be best describe as:
If a user wants to control intercompany cut-off dates, then the user can choose which General
Ledger calendar will be used to control transaction entry by intercompany period status.
Intercompany Calendar prevents users from entering transactions in closed periods and from
closing the period if open transactions exist for the period user wants to close. When the user tries
to close General Ledger accounting period, or Oracle Payables period or Oracle Receivables period
while Intercompany Period is still open, the warning message can be displayed informing user
about the status of intercompany period.
Setup Profile Options
In AGIS there is no profile option; that means these three as below intercompany profile options
used in R11i are obsolete in this release.
• Intercompany: Protect Receiver Natural Account
• Intercompany: Subsidiary

• Intercompany: Use Automatic Transaction

Intercompany Reconciliation and Reporting
There are two new reports available in XML Publisher format
• Intercompany Transaction Summary report
• Intercompany Account Details report.
These reports replace reports that were available in the Global Intercompany System (GIS) in
Release 11i.
The new reports offer all of the functionality of the obsolete reports plus additional benefits.
A bit on these 2 reports:
1) Intercompany Transaction Summary report replaces the Intercompany Transaction Detail report
and Unapproved Transaction Listing report.
The purpose of this report is to give user a clear overview of intercompany transactions and their
statuses, there so that day-to-day tasks and speeds up period close activities.
This report also provides supporting documentation for intercompany reconciliation and helps
keep intercompany in balance by uncovering any potential discrepancies.
2) Intercompany Account Details report replaces the Transaction Activity Summary report
This new report provides a detailed listing of all accounting lines for intercompany batches,
grouped by transaction.
The report is divided into two sections:
• One section for outbound batches
• One section inbound transactions.
The outbound section shows transactions initiated by the organizations to which the user has an
access; the inbound section shows transactions received by these organizations. The user can
choose whether to include inbound, outbound, or both sections in the report.
The user can run the report for one or many organizations to which the user is given the access.
User can select what parameters like initiator, Recipient, GL Date range, Batch Number range,
Transaction Status, Currency, Batch Type, Invoice Number, and many more to run the report by.
User can run the report by ranges of initiator and recipient accounts to see what transactions make
up their balances.

Some of the GL Standard Reports converted into XML Publisher
Oracle General Ledger’s Account Analysis, General Journals and Trial Balance standard reports
are now integrated with XML Publisher.

Sequence in GL made legal compliance easy
In R12, to cater the need for legal compliance in some counties of Asia, Latin
America, and Europe , two Journal Sequencing options have been provided.
These are accounting and reporting sequence, in reality there is bit difference
in these two terms.

Accounting Sequence
This is sequence used in GL journals when posted in GL, Sequence SubLedger
journals when completed in SubLedger Accounting.

What we have seen in Release 11i, we had document sequencing that
sequentially numbered documents upon creation. Accounting Sequencing will
automatically assign a sequence number to GL journal entries that are posted
in GL. There’s also an option to sequence SubLedger journals when they are
completed in SLA Accounting.

Reporting Sequence
This sequence is used in GL Journals when you close a GL Period. Sequence
sub ledger Journals when you complete the accounting in SLA .This is one of
replacement of Accounting Engine (AX) legal sequencing.
These two Sequences can be assign mutually exclusive sequences based on:

• Ledgers or Reporting Currencies
• Journal sources
• Journal categories
• Balance types
The benefits of using these sequences are summarized:

a) Legal Compliance made easy: The one biggest advantage of it will now
addresses business requirements in many countries, such as Europe & Asia.
Therefore it allows fiscal authorities to verify the completeness of a company’s

accounting records.

b) Flexibility get enhanced: With this it provides greater flexibility in choosing
different journal sequencing options, as mention above, these can be based
out of these different criteria, such as by ledgers, reporting currencies, journal
sources, journal categories, and balance types.

c) No Localization Required: Somehow related to (a) discussed above, earlier it
the local reporting need was catered by localization, which now is part of GL
activity.

Where to define the sequence?

You can define the accounting sequence in the context of a ledger in
Accounting Setup Manager. There is another way i.e. Accounting Sequencing
menu function which we can create and manage our sequencing rules.

For Accounting Sequences which is internally a posting event, the GL journals are
sequenced when they are posted in GL and SubLedger journals are sequenced when
completed in SLA. For Reporting Sequences (period close event), GL journals and
SubLedger journals are sequenced when a GL period is closed. You can see both can
be appear in the Journal screen as below.

Multi org access control

Multiple Organizations Access Control or MOAC (pronounced MOW-ACK) to use
the seemingly obligatory acronym is a powerful, yet simple to implement
feature available in R12.

Implementers spend a lot of time figuring out how to configure their Legal
Entities, Ledgers and Operating Units. There are a number of options some
restrictions, depending on what features you want to implement and where
you are. However it is worth remembering that change is the Status Quo and
flexibility is important, what was the optimal way to organize your transaction
processing yesterday may not be right today. Many companies are creating
shared service centers to centralize processing of financial transactions and a
single user may process transactions on behalf of many different Operating
Units (OU).

So MOAC allows you to create a security group which can contain many

operating units and assign that to the User’s responsibility. All the forms that
process OU striped data now allow you to pick an OU to work in from a list that
contains all the OU you have access to. You will also find all the OU based
reports have a parameter added for OU.

The Set Up is straightforward. You can define a security profile in the HR
Security Profile form, adding Operating Units to it, and then you must run
Security List Maintenance program before you can assign the security profile
to the profile option MO: Security Profile for a responsibility.

The most important feature that MOAC provides in Release 12 is the ability to
handle multiple operating units within the same responsibility. This is
beneficial as users don’t have to switch responsibilities in order to change the
operating unit. Often people ask me whether it is possible to use the 11i single
organization behavior in Release 12; or more importantly whether it is possible
to use a mixture of both.

Yes, this is possible. Before knowing how to do that, let us understand how
MOAC works in Release 12. MOAC is initialized when you open a Form, OA
page or a Report. The first MOAC call checks if the profile “MO: Security
Profile” has a value. If yes, then the list of operations units to which access is
allowed is fetched and the list of values (LOV) is populated. Then default value
of the LOV is set to the operating unit specified in “MO: Default Operating
Unit”. This is how MOAC works in Release 12 when the value of “MO: Security
Profile” is set.

When the profile “MO: Security Profile” does not have a value MOAC switches
to the 11i single organization mode. As in 11i, the profile “MO: Operating Unit”
is checked and the operating unit is initialized to the one defined in it.

The important point to note here is that the profile “MO: Operating Unit” is
ignored when the profile “MO: Security Profile” is set. This enables us to use
both Release 12 MOAC behavior and 11i behavior simultaneously in Release
12. You can also choose to completely use one of them.

Multi Org Access Control

MOAC is new enhancement to the Multiple Organizations feature of Oracle
Applications.

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.

This new Feature in R12 enables companies that have implemented or implementing
shared services operating model to efficiently process business transactions by
allowing them to access, process and report on data for an unlimited number of
operating units within a single applications responsibility. Users are no longer
required to switch applications responsibilities when processing transactions for
multiple operating units.

Data security is maintained using security profiles that determine the data access
privileges associated to responsibilities granted to a user.

Because of this you can perform multiple tasks across operating units without
changing responsibilities, the simple case can be best described as diagram in the
left, where 3 user from three difference OU’s required three separate responsibility to
perform the task.

MOAC Benefits..

• Multi-Org Access Control feature allows you to enter, process data and generate reports
from a single responsibility

• This is achieved by providing the Operating Unit field on the forms/pages and while
running the concurrent processes

• To Set this feature you need to define the security profile containing operating units and set
it at MO: Security Profile

• You can default the Operating Unit on forms/pages by setting the MO: Default Operating
Unit profile
What are the new changes
?

• As discussed above, security Profiles for data security

o MO: Security Profile

o List of operating units for a responsibility

• OU field on UI
o all transactions

o setup data specific to OU, like transaction type

• Enhanced Multi-Org Reporting and Processing
• Ledger/Ledger Set parameter on accounting reports and processes
• OU parameter on other standard reports and processes
o For example: submit the Payables Open Interface Import w/OU param null to
import all records across all OUs
Where and how to define a security profile?

Using Oracle HRMS, you can define your security profile using two forms:

• The Security Profile form
• The Global Security Profile form that is shown here.

The Security Profile Form allows you to select operating units from only one
Business Group. The Global Security profile Form allows you to select
operating units from multiple Business Groups.
The decision on which form to use is really up to you and depends on your HR

implementation and how you want to partition data. All you need to do is enter a
name, and select the Security Type called “Secure organizations by organization
hierarchy and/or organization list”. This allows you to assign multiple OUs. When
assigning operating units, first select classification Operating Unit, and then select the
organization or Operating Unit name. You can assign as many operating units as you
want.

New and changed features in Oracle Assets:
Here are the six new and changed features for Oracle Assets in Release 12.

• Sub Ledger Accounting Architecture
• Enhanced Mass Additions for Legacy conversions
• Automatic Preparation of Mass Additions
• Flexible Reporting using XML publisher
• Automatic depreciation rollback
• Enhanced functionality for Energy industry
Fixed Assets tied with SLA (Sub Ledger accounting)
As we have already seen SLA is a rules-based engine for generating accounting entries based on
source transactions from ALL Oracle Applications. Therefore Fixed Asset module does integrated
with such functionality to cater the asset accounting at ledger level. With this feature:
• Oracle Assets is fully integrated with SLA, which is a common accounting platform for
Sub Ledgers.
• Customers can use the seeded Account Derivation definitions or modify them as required.
• Continue to support Account Generator functionality for existing Asset Books.
• New SLA Accounting report and online account inquiry.
What you will notice create Journal Entries (FAPOST) process feeding into the GL_INTERFACE
table is no more exist .This is replaced with the Create Accounting – Assets process (FAACCPB).
With this replacement, the some of high point in term of benefits are:
• It leads to faster closings: Since there is no requirement of having to close the period,
accounting can be created for FA transactions and sent to GL on a continual basis

throughout the period.
• There is no need to wait until the end of the month to run Create Accounting in order
to get the data to GL.
Therefore with this new enhancement allows clients to meet multi-GAAP, corporate, and fiscal
accounting requirements. The tool, Accounting Methods Builder, allows you to determine the
accounts, lines, descriptions, summarization, and dates of your journal entries.
This can be best understood as this example, if you do a large amount of asset additions on the first
day of the month, you can run Create Accounting and get all the Cost and Cost Clearing lines over
to GL at the close of business that day.
Enhancements have been made to the FA_MASS_ADDITIONS table.
Now with this enhanced feature, we can populate the values for the new attributes directly in the
FA Mass Additions interface table rather than accepting default values from the asset category.
Legacy conversion can be completely automated. These are new add-ons:
• Asset Life
• Depreciation Method
• Prorate Convention
• Bonus Rule Ceiling Name
• Depreciation Limit
What is understood is that Web ADI has also been upgraded to include the new Attributes.
• New columns in the Asset Additions WebAdi
• Additional attribute can be used to populate values directly thereby eliminating the need to
override the defaults from the Asset Category
• These new data fields will benefit data conversion by allowing the converted data to be
brought into Oracle with the asset life information.
New Automatic Preparation of Mass Additions
• This new feature consists of default rules and Public APIs that can be used by customers to
complete the preparation of mass addition lines automatically.
o Auto populate required fields such as Expense Account, Asset Category etc.

o Avoid manual intervention during the Mass Additions prepare process

o Avoid customization and use public APIs to effect custom business logic.

• Assets now uses Flexible Reporting using XML publisher

o Major Asset Transaction reports have been modified to support XML publisher.

o Users can modify or use new templates to view report output.
Those who are very new to Asset module must have question, What is meant by Default
Rules?
• Asset Category – this is derived from the asset cost clearing account, as long as
there is a one to one relationship between the account and asset category. This
process will only impact items in the ‘New’ and ‘On Hold’ queue names.
• Expense Account – this is derived from the clearing account combination and
overlaying the natural account segment with the value of the natural account
segment of the depreciation expense defined in the asset category. If the program
cannot derive an expense combination, the queue name is set to ‘On Hold’.
So what is meant for Consultant by this feature..Please note
• This should minimize the amount of manual efforts involved in the Prepare Mass
Additions Process. Manual updating is still required some fields may not be
populated but are required.
• Asset Category – a one to one relationship between cost clearing account and asset
category – this will expand the COA of many companies.
• Expense Account – the expense combination is going to be derived from a BS
account. Oracle will simply overlay the natural account segment, replacing the cost
clearing account with the depreciation expense account leaving all other segment
values alone. If there are certain requirements for P&L accounts versus BS
accounts, i.e. cost center required for P&L, this may present issues.
• Manual efforts are required to perform Merging, Splitting, Add to Assets, and
Merge Then Split functionality.
Flexible Reporting into XML Publisher
These asset reports have been converted in XML Publisher based report.
• Create Accounting – Assets
• Transfer Journal Entries to GL – Assets
• Journal Entry Reserve ledger Report
• Asset Additions Report
• Asset Transfer Report
• Asset Retirement Report
• Transaction History Report

• Asset Reclassification Report
• Mass Additions Create Report
• Mass Additions Posting Report
• Cost Adjustment Report
• Cost Detail report
• Cost Summary Report
• Reserve summary Report
• Reserve Details Report
• Mass Revaluation Preview Report
• Revaluation Reserve Details Report
• Revaluation Reserve Summary Report
• CIP Capitalization report
• CIP Detail Report
• CIP Summary Report
You can design and control how the report output will be presented in separate template files.
Publish in PDF format that can support colors, images, font styles, headers and footers, and other
formatting. You can create new report templates, or modify existing templates to view your report
output.
Automatic Depreciation Rollback
Depreciation is rolled back automatically by the system when any transaction is performed on an
asset if the following conditions are met:
• Depreciation has been processed in that period
• The period is not closed
That mean, it is no longer required to run depreciation rollback program manually as we have seen
in release 11i.
Depreciation rollback is executed only on select assets as required and not on the entire Asset
Book this enhances performance of the program.
Since release 11i, users have been able to run depreciation for an asset book without closing the
period. If additional adjustments are required in the current period, then the user submits a process
to roll back depreciation for the entire book; performs the necessary adjustment(s) and then
resubmits the depreciation program. In Release 12 the intermediate manual step of rolling back

depreciation for the entire book in order to process further adjustments on selected assets is no
longer necessary. As before users may submit depreciation for the entire book prior to closing the
period. If it becomes necessary to process financial adjustments on one or more assets, the user
may proceed with the transaction normally via the asset workbench or mass transactions.
Oracle Assets automatically rolls back the depreciation on just the selected assets (instead of the
whole book) and allows the transaction(s) to be processed normally. The asset(s) 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.
Enhanced functionality for Energy Industry
As per RCD, this can be understood as;
• Energy Units of Production Method for Group Assets
In the oil & gas industry, asset properties may include fields, leases and wells. These assets are
typically associated with units of production (UOP) and are depreciated using a special UOP
depreciation method. ‘Energy’ assets are generally structured into two levels, group and member
assets, where the group asset is a collection of several members.
• Allow Production method for Group Assets
• Allow Production upload to Group Assets
• Energy Straight line Method
This feature is used in oil & gas industry, where non-producing assets are depreciated using the
energy straight-line method based on the asset’s net book value. Assets that depreciate using the
energy straight-line method may either depreciate at the member asset level or group asset level.
A note on Straight-Line Depreciation – Assets that depreciate using energy straight-line method
may either depreciate at the member asset level or group asset level.
• When at the member level, depreciation is calculated based on each member’s life
and then summarized up to the group asset.
• When at the group level, depreciation is calculated at the group asset level, the life
of the group asset is used.
• Net Book Value / Remaining Life
• Asset Impairment – this is basically an unplanned depreciation and will utilize this feature
to perform asset impairments. Now the ‘impairment’ expense account may be derived from
the asset category setup or manually entered.

How Receivables Accounting happen in 11i
As we know the final accounting data is not generated prior to transfer to GL as only distribution
level information is passed to GL.
In 11i, we know three distinct distributions tables, invoices / Credit Memos / Debit Memos have to
capture accounting class & amounts information but not debits & credits.
•

o Receipts & Adjustments

 Unapplied, applied
 Both debits & credits
o Misc. Cash Receipts

 Both debits & credits
• As we know “View Accounting” is a report against distributions to see the accounting
information.

How Payables Accounting happen in 11i

We know that accounting data is 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 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

The only issues in pre R12 versions was to link summarized accounting data with source details.

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(Very 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

And Final picture looks like:

Welcome to Accounts Payable Release 12:

As we learnt during Release 12, the E-Business Suite has couple of new
products like SubLedger Accounting, E-Business Tax thus significant changes
have been observed in Account Payable data module as some of functionality
is shared by some other products. Thus it is important to understand what is
new. Let us identify some of new changes and underlying impact on the
objects. More details can be found in R12 release documents.

Let’s have a dissection view of R12 payable, with some of its core objects

Supplier

We have seen in 11i
• Suppliers defined in AP.
• Supplier contacts replicated for each supplier site.
Where as 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
o A single change to an address can be seen instantly by all OUs

o No longer need to manually ‘push’ updates across OUs.This can be best understood
by the figure below.

Then the question is what will happen if any one can come from existing
financial products. The Impact from upgrade can be summarized 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, this is because creation of suppliers in
Party in TCA data model would requires Country and address information, but
it is 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 Supplier’s historical
transactions.

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

As we know in 11i employees are part of internal supplier’s record in order for
Oracle Payables to create payments for their expense reports. Employees
defined in Oracle Human Resources and associated with an Oracle Payables
supplier record have existing party information. During the upgrade, Oracle

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.

Invoice

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.
But in R12,

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

Because of introduction of invoice line there is significant improvement of data flow
with other oracle modules like

• Fixed Asset - Asset Tracking

• Business Tax - Tax line

• Payment - Payment

• SubLedger Accounting - Accounting

2. Allocate freight and special charges are captured to the lines on the invoice
3. Invoice distributions created at the maximum level of detail similar to 11i.
4. Core functionality

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.

That means functional testing is more required while upgrade takes place.

Banks and Bank Details

Now a days corporate treasury role has been greatly enhanced thus picking up
a global bank as partner for all banking need is demand of time in global
working model. The recent couple of years have seen drastic increase in
acquisition and merger of company thus global working as well as global
instance get popularity in ERP arena, and this is one of the reasons bank data
model has been significant changes from 11 to 11i and 11i to R12.

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 (party’s) 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

Integration with Oracle 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 captured for country-specific tax attributes.
• More importantly most of the setup performed at OU level.
In R12

• A new module eBusinessTax determines tax based on facts about each transaction, this is
reason why Oracle has introduced additional line information at invoice level.
• The module “ebusiness Tax” set and configure Tax rules which can be viewed
• Tax attributes collected in fields on key entities
• Configure tax rules once per regime and share with your legal entities
Impact of Upgrade:
1. Payables Tax setup, Tax Code defaulting rules defined per OU are migrated
to eBusiness Tax.
2. OUs migrated to tax content owner in R12
3. Tax information in tax codes are transformed to Regime-Rate flow.
4. E-Business Tax takes information from the AP invoice lines and creates
summary and detail tax lines in the E-Business Tax repository.

R12 Banking Model:
There is one thing that keeps changing since last 2 releases …the bank. We
have seen there was once from pre 10.x to 11i when supplier bank separated
from suppliers data and now its again in R12 when it becomes part of TCA.
This time, it is because of changing business need and high demand of global
partners working model. Not only your company is operating globally, your

partner too is operating global, then why not use them. In typical business
cost model, if corporate office is using Citibank for payroll for USA operation
then why not Citibank Singapore branch is used for payroll for Singapore if
they are operating there. Sound bit low…why..

As we aware the key message of R12 while release was:

• Think Globally - using business intelligence and analysis tools
• Work Globally - using the global capabilities of the applications
• Manage Globally - using the latest system architecture and middleware
So what, think globally and work globally is factor driving for the changes .This
release has witnessed the great changes ever into the bank model. Now the
bank accounts are attached to your legal entity level rather than Operating
Unit in which current and existing versions Offer. This makes bank with strong
capability to pay across operating units. More over it is important to
understand that banks accounts can be shared by applications and can be
designed for use by Payables, Receivables and Payroll.

What is new in R12 for Bank

These changes make easier and more reliable by

• Single access point
• Single Legal Entity ownership
• Usage rights granted to one or more Organizations
o Reconciliation option defined at Bank Account level

o More flexibility and control

Comparing the 11i Vs R12

If we compare the bank in 11i with R12, we can notice the bank was utilized
into three different places, finance, payroll and treasury, which requires
altogether a different setup. It was one of the big issues with integration
aspect, as significant problem was recognized once the Expense management
and payroll uses same bank for the respective person.

There was a common question/confusion between the Integration Existence
between Bank Data in Accounts Payable and Bank Data in Payroll.

As discussed above, you know most of release of 11i family of oracle
Application does not have integration between HR and AP for bank account
data.

We have noticed in 11i there was functionality in Payables in which we create
an employee type supplier from HR data and it will contain name and address
info but not bank information. The reason for this is that HR/Payroll does not
store the bank information in a standard way that makes the integration
possible.

So now in R12, this is well taken care and integration is built. There are plans
under way for all bank account data models in the various products to be
consolidated in the new TCA architecture. The Cash Management team is
working on this project. Payables and HR/Payroll are working so that the
eventual idea will be that you can set up bank accounts in one place and then
indicate the usage (pay, expense reimbursement, etc).

For understanding following is comparison between 11i and release 12, where
TCA community take cares of every things.

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.
This new data model allows the bank and bank branch entities to be defined
separately allowing users to establish a hierarchical relationship between
them.

Missing link between Supplier And Supplier Banks

You should know

• The link between PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id.
• The link between PO_VENDOR_SITES_ALL and HZ_PARTY_SITES is
PO_VENDOR_SITES_ALL.party_site_id.
• When a Supplier is created Record will be inserted in HZ_PARTIES. When the Supplier
Site is created Record will be inserted in HZ_PARTY_SITES. When Address is created it
will be stored in HZ_LOCATIONS
• When a bank Is Created, the banking information will be stored in
IBY_EXT_BANK_ACCOUNTS IBY_EXT_BANK_ACCOUNTS.BANK_id =
hz_paties.party_id

• When the Bank is assigned to Vendors then it will be updated in
HZ_CODE_ASSIGNMENTS.
HZ_CODE_ASSIGNMENTS.owner_table_id =
IBY_EXT_BANK_ACCOUNTS.branch_id.

Internal Bank Accounts & Supplier and Customer Bank Accounts in
R12

Internal Bank Accounts
In Release 12, each internal bank account is assigned to a Legal Entity. Any or
all operating units associated with that legal entity are permitted to use that
bank account.

Supplier and Customer Bank Accounts
Release 12 provides a centralized repository for suppliers’ and customers’
bank account and credit card information. All data is stored in one, secure
place, providing shared service centers and collection department’s consistent
information that they need.

What’s new in Oracle Receivables R12:
Release 12 of the E-Business Suite is also called the “Global Business
Release”, as it has numerous enhancements designed to make it easier to do
business on a global basis. A more flexible, centralized global accounting
structure has been introduced which makes it easier to operate between and
across operating units and legal entities. Overall, R12 contains 18 new
modules and 2443 enhancements to existing functionality.

Oracle’s Release 12 (R12) of their E-Business Suite continues to extend the
functionality of the Receivables arena, in addition to incorporated new
financial architecture and new products , Oracle Receivables is now very
natured product. Let us look at Oracle’s newest/enhanced offerings in Oracle
Receivables.

Revenue Recognition

In R12 revenue recognition is based on Rules and Events, and they are:

• Time-Based Revenue Recognition
o Ratably Over Time

o Upon Expiration of Contingencies

• Event-Based Revenue Recognition
o Payment

o Customer Acceptance

• Rule-Based Revenue Recognition
o Payment Term Thresholds

o Refund Policy Thresholds

o Customer Credit worthiness

Let us take a quick look on some of the new changes:

• Daily Revenue Recognition
o Revenue distribution over full as well as partial accounting periods.

o Fulfills stringent accounting standards

o Accuracy to the number of days in the accounting period.

• Enhanced Revenue Contingencies :
o Fully Supports US GAAP and IAS

o User definable contingencies

o User definable defaulting rules for contingencies assignment

o Supports parent-child (e.g. Product and Service) relationship

o Integration with Order Management and Service Contracts

o User Interface as well as Programming Interface (API) support

o Access control through seeded Revenue Managers Responsibility

• Deferred Revenue Management
Event-Based Revenue Management in Oracle Receivables allows users to
define revenue deferral reasons or contingencies and corresponding revenue
recognition events. In Release 12, revenue contingencies for customer
acceptance that are applied to goods sold in Order Management are now

applied to services
sold to cover those
goods. Revenue is deferred for service ordered in
both Order Management and Service Contracts.
Acceptance contingencies associated with an item instance are automatically
applied to service revenue associated with the item instance when it is
covered in a Service Contract as a Covered Product. Revenue for services on
other covered levels, subscriptions and usage is not impacted by
contingencies applied to goods associated with those services.
Global Architecture

As we know, with in global architecture, these new things have been introduced.

• Sub ledger Accounting - Journal Creation takes place prior to GL.

• Bank Model - This unified model enables to park customer Bank as well as Internal bank
information into there new model, so that working capital cash flow should be enhanced.

• EBusiness Tax - Oracle E-Business Tax is a new product that uniformly delivers tax
services to all Oracle EBusiness Suite business flows. In Release 12, Receivables is
enhanced to support
integration with the E-Business Tax product.

• Intercompany - This is enhanced by automatic balancing,

MOAC Control
This enhance you by enabling and performing tasks across operating Units (OUs),
where you have access to without changing responsibilities. As we know , MOAC
enables companies that have implemented a Shared Services operating model to
efficiently process business transactions by allowing them to access, process, and
report on data for an unlimited number of operating units within a single applications
responsibility.

In nutshell, once MOAC is enabled, then you can:

• Perform Setups for any OU

• Enter invoices across OUs

• Receive Cash for any OU

• Manage Customer Credit across all OU

• Run reports across OUs

Because of this
greatly enhanced
Role based security
options, the ability to
access multiple
operating units with a
single responsibility
can simplify SOX
compliance
monitoring from finance controller side.

Line Level Cash Applications
The Line Level Cash Applications solution allows the application of receipts to
specific transaction items such as individual lines, groups of lines, or tax or freight
buckets. From the receipt workbench, you are able to choose whether to allocate
cash to the entire transaction or to apply amounts against specific items according to
the customer remittance.

• Apply to specific lines or groups of lines

• Indicate when tax, freight or finance charges only are paid

• Make changes as needed

• Easily view activity against receipts

• Know what historical activity affects your receipt

• See what prior activity affects a new application

Enhanced Customer Screen

We have seen 11i Customer standard forms makes easier by simple
navigation. This times there is clearer separation of the party and account
layers, which makes a consistent look and feel. Moreover full backward
compatibility with 11i UI Bill Presentment Architecture has been provided.

The AR Create Customer page in R12 has eliminated the navigation to
separate windows. Now, users can specify the following on a single page:

• Customer Information
• Account Details
• Address
• Account Site Details

• Business Purpose

Refunds

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.

Late Charges

As we know oracle receivables delivers enhanced Late Charges functionality enabling
the creation of standard late charge policies that can be assigned to customer
accounts or account sites. Flexible policy configurations include multiple interest
calculation formulas, transaction and account balance thresholds, and currency-level
rate setups. With new changes these are the enhanced functionality:

• Expanded assessment and calculation capabilities

• Tiered charge schedules

• Penalty charge calculation

• Integration with Balance Forward Billing

• Centralized setup and maintenance of late charge policies

• Calculation performed independent of Dunning and Statement processing

AR-AP Netting

The matching of open receivables and open payables is automated.

Balance Forward Billing

This makes easy transaction processing.

Balance Forward Billing is an enhanced version of the existing consolidated 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 provided by Oracle Bill Presentment Architecture.

A typical case can be best understood as

• Payment Term defaults

• from Site profile if Bill Level = Site

• from Account profile if Bill Level = Account

• Billing Date derived from transaction date and billing cycle

• Due Date derived from billing date and payment term

• Optionally select non-Balance Forward term if Override Terms = Yes

R12: AP/AR Netting

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.

You can access the process via:

• Navigation: Receipts > Netting > Netting Batch
• Navigation: Receipts > Netting > Netting Agreement
• Receipts > Receipts > Action Menu : AP/AR Netting
After Querying a netted receipt, the user can see more details about the batch by selecting
AP/AR Netting from the Action menu. This launches the AP/AR Netting batch window.
Netted Receipts are created automatically by the AP/AR Netting process and cannot be
updated by the user from the Receipts Workbench
As we have seen Contra charging has been replaced by AP/AR netting, lets
take a setup walk though to use this functionality.

1. Define netting control account

Setup>Financials>Flex field>key>values

2. Create bank

Setup>payment>Bank and Bank Branches

You should note, Payment document is not required for netting bank account.

3. Go to receivables responsibility, receipt class definition form

Setup>Receipts>Receipt class

Query the ‘AP/AR Netting’ receipt class which is a seeded one.

4. Attach your bank account in this receipt class.

5. Go to system options, transaction and customer tabbed region,
there enable ‘Allow payment of Unrelated Transactions’ check box

6. Create netting agreement

Receipts>Netting>Netting Agreement

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

8. Enter a transaction in receivables.

9. Create Netting Batch

Receipts >Netting >Netting Batch

10. Query your netting batch and see the status as Complete. also
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

You can see 3 concurrent request programs

• Create Netting batch
• Settle netting batch
• Netting Data Extract
12. Now go to receipts and query the AP/AR netting receipt.

13. Now Go to Tools >view Accounting, you can see Netting control
account (defined in first step a) debited and receivable account credited.

14. Now go to payables and query your invoice number and click the
tab view payments. You can see the payment details and copy the
document number.

15. Query your copied payment document number. What you can see
the payment type as netting.

16. Click actions button and enable the check box create accounting.

17. Go to tools>view accounting .You can see the accounting entry

Posted in Oracle Payable, Release12, R12, Oracle Receivable | 4 Comments »

Contra Charging to AP/AR Netting:

1. Customer ABC raise an order to your company and your have made shipment of goods
they have requested and you have raised an invoice of X amount, that you are expecting the
money should be paid by customer.
2. Same time , you have some taken some services to the same customer which is a vendor in
your Payable, and now you have liability to pay the amount Y, you received against PO.
What the business demand here is “Net off your supplier balance in AP
(Payables) with customer balance in AR (Receivables)”

These kinds of business scenario always exist, especially if you are dealing
with client whose line of business is either Airlines or Cargo or Healthcare
domain. Such events are always there, therefore designing, configuring and
identifying such need is foremost important step while implementing ERP.
What we seen after 11.5.9, where similar kind of functionality Oracle has
offered in term of “Contra Charging” which initially limited in European
Localization and on and after 11.5.10, the same functionality have been
standardize and incorporated in the product.

Contra Charging

Contra Charging allows you to select customer and suppliers through the
screen and net their balances. This will submit two requests used to populate
the Receivables and Payables Transaction Interface. These credit memos can
then be imported through the standard invoice import in AR and AP. The base
Functionality that currently exists in 11.5.10 is:

• Use the Contra Charging window to physically match the customer to the supplier and
allocate an amount for contra charging
• Automatically populate the AR and AP Invoice Interface tables to create credit memos for
the source Contra
• Import the invoices
o in AR with the Submit Invoice Import window, using the source Contra

o in AP with the Auto Invoice Import Program on the Run Auto Invoice window,
using the source Contra
• Use the standard functionality to post the imported credit memos to Oracle General Ledger
• Use the Contra Netting Report
o to report on the netted contra charging transactions

o to check that the contra charging has been carried out successfully in Oracle
Receivables and Oracle Payables

How to make Contra Charging Feature enabled

Follow the below mentioned steps and you should be able to use the contra
charging functionality.

1. Define document sequences; assign the document sequence to Contra
document category.

• You can assign a unique document sequence to each invoice and payment document in
your Payables system so you have a unique identifier for each document.
• A document category is a set of documents (invoices or payments) that share similar
characteristics. You can assign a single document sequence to one or more document
categories.
• Use assignment window in System administrator responsibility to attach the document
category with the document sequence created for contra charging invoices.
2. Setup Payables Contra Source.

A lookup is any predefined value that was not defined in a setup window.

3. Setup user profile for AP Responsibility, including the following:

• Tax: Allow Override of Tax Code (Yes)
• Tax: Allow Override of Customer Exemption (Yes)
• Sequential Numbering (Partially Used)
• JG: Contra - Include Future Dated Payment in Supplier Balance (Yes)
4. Define Document Category called ‘Contra’.

5. Define Payables Lookup for ‘Contra’.

A lookup is any predefined value that was not defined in a setup window. Use
the Oracle Payables Lookups window to review and maintain sets of values, or
lookups, that you use in Payables. Use the Oracle Payables Lookups window to
create a new Payables lookup for contra charging.

This New Contra Lookup Code will be used as a source when the Contra
Charging Credit memos are created.

6. Assign a ‘Contra Charging’ Menu to ‘AP_NAVIGATE_GUI12′ main menu,which
tied to AP Responsibility.

To attach the Contra Charging Form to the Existing Payables Responsibility,
attach JG_CONTRA_CHARGE_GUI Sub Menu to AP_NAVIGATE_GUI12 Main
Menu.

Navigation Path: System Administrator responsibility: Application: Menu Form

7. Having created the new form ‘Contra Charging’, enter Contra Charging
Transactions, then ‘Submit Contra transaction.

What’s new in Release 12

When a trading partner is both a customer and a supplier, an 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.

Benefits:
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.

From 11i to R12

R12 Netting solution replaces 3 solutions (FV, JE, and IGI) in 11i.

In R12 the Contra Charge functionality has been optimized and therefore
changed into the AP/AR Netting functionality. In the Payables module as well
as the Receivables module, there is a Netting submenu.

• Payables: Payments -> Entry -> Netting
• Receivables: Receipts -> Netting

R12 Oracle Payments module:
As we know, fund disbursement functionality has been moved from Oracle payables to new
Payment module, which provides this functionality like;

• Creation & validation of payments

• Aggregation of payments into files

• Format & transmission of files

whereas selection & approval of invoices remains in Payables itself.
It is very important to understand some of important changes impact while upgrading 11i to r12 to
some of the custom reports if they are based out of R11i10 version schema model.

Understand some of the changes because of Funds Disbursement(Oracle Payment)
Some of the important changes can be summarized as:

Subledger Accounting Cost Management –Details

Subledger accounting in R12 is an enhanced accounting process. The SLA process allows
customers to personalize the process for specific events. The user sets the rules to be followed.
Accounts are still defined the same way as prior application versions via the same forms.
Organizations are defined the same way. If there are no rules entered into the SLA engine, the
accounts defined the traditional way will be used to generate the journal entries posted to GL. All
setups to use preR12 functionality are automatic. The default base setup is US GAAP. This uses
the traditional account definitions. This is delivered and works out of the box.

SLA uses events for processing transactions. An event is the recording of a change of status in the
transaction life cycle, i.e., invoice approved, payment received, period close, etc. This allows for a
clear separation between transactions and accounting representation. Events are the bridge between
transactions and journal entries, so product teams are involved for coordinating actions based on
event models.

R12 Subledger Accounting Rules:
SLA uses a rules-based accounting engine that posts entries into GL. The rules used by the engine
are user defined. The rules are stored in a common repository for all subledger applications. A
subledger application would be a product area, such as Inventory, Payables, Receivables,
Purchasing, etc.

The R12 SLA process has created a common accounting process to be used across all applications.
This allows the customer to have a single method for defining accounting behaviors.

The engine supports the use of multiple currencies. This also allows for various audit tools and
reports to be used when reviewing GL postings.

The SLA process allows for the display of the inventory valuation accounts to be seen for a user

defined date range. The engine also allows the accounting department to maintain control over
accounting and chart of accounts for the ledgers used.

When rules are created, the rules engine will override user entered accounts that might be
incorrect. This is important to control user errors that can occur within a period. The rules will
automatically redirect the costs to the correct account. The rules can be created for most item
attributes to allow for granularity of costs if so desired.

After the rules are established, the Cost Management – SLA responsibility allows for the creation
of the user-defined accounting data. The request group related to this process includes all SLA
processes as well as standard accounting processes.
For inventory transactions, a transaction would be received or costed. The transaction will then
be passed to GL via the Create Accounting – Cost Management program.
So for Misc receipt:
User creates misc receipt
Cost Manager processes transaction
Create Accounting - Cost Management Inventory Category process is run
This validates the accounts to be used as per any rules that have been defined.
If no rule defined for a transaction event then the default account value set for the
organization is used.
If the setting were final and post, the details would be transferred to GL. If no transfer to
GL was indicated and the setting was final and post, then the Transfer to GL process still needs to
be run via CSTGLTRN - Transfer Journal Entries to GL.
Transfer and Post to GL are recommended to be included in Create Accounting- Cost
Management when creating the accounting for the transactions. An exception would be Draft
mode.

Create Accounting – Receiving
This process is tied to the Purchasing responsibility.
Process Category is not a parameter for this request as only receiving transactions can be
processed from Purchasing. It will default with Process Category of Receiving.

Create Accounting – Cost Management
This process is tied to the Cost Management – SLA process and uses the following Process
Categories:
Inventory Receiving
Work in Process Third Party Merge
Manual

The process then completes or shows errors that need correction.

Create Accounting – Cost Management Parameters:
Ledger Required; limits accounting events to the chosen
ledger If profile option SLA: Enable Data Access
Security in Subledgers = Yes, only the ledgers
included in the SL Access Sets assigned to the

responsibility is on the LOV
Optional; Restricts events selected to particular
process category. The program selects events
Process Category
with event types that are part of the event class
assigned to the process category.
Required; End date for the program to use. Will
End Date only process those events with event dates on or
before the end date.
Optional; Determines if entries created in Draft
or Final mode.Draft Mode –Transfer to GL, Post
in GL, and GL Batch Name fields are disabled as
Mode
the draft entries cannot be transferred to GL; It is
recommended to run in draft first to check for
errors
Required; Limits the creation of accounting to
those events that previously failed. If set to Yes
Errors
the program will process all events with the
status of error.
Optional; determines if the report showing the
Report results of the SLA program is in summary or
detail.
Required if mode = Final; Determines if the
Transfer to GL subledger journal entries are transferred to GL.
Journal Import is not launched if set to Yes
Required if mode = Final or Create Accounting is
Post in GL
set to No
Optional; user entered batch name appears in
GL Batch Name transferred GL Subledger journal entries.
Transfer to GL must be set to Yes
Required; identifies the org each accounting
Included User Transaction Identifiers
entry belongs to

The Create Accounting - Cost Management request creates accrual journal entries, accrual
reversals, and multi-period journal entries.
To transfer the details to GL:
1- Set the parameter in the Create Accounting to Yes
2- If parameter is set to No, then the Transfer to GL process must be run manually as this
will only create accounting but no values are passed to GL.

There is an option to make the journal entry and post the journals automatically at the time of
submitting the Create Accounting program itself.

This option is used by setting the profile SLA: Disable Journal Import to "NO" .This will be the
most preferred setting for this profile option and this indicates that Journal Import will ALWAYS
accompany the transfer of data from Subledger. Another main implication of this value is that, on

failure of Journal Import, the data will be rolled back to SLA tables and hence there will not be any
data in GL_INTERFACE.

If you want to do the transfer to GL separately from creating accounting in the subledger
you can use the Create Accounting Program to create the accounting in the subledger only and then
run a different program CSTGLTRN - Transfer Journal Entries to GL to transfer the journal and
post to GL

CSTGLTRN - Transfer Journal Entries to GL - Cost Management
This is used to transfer final journal entries to GL that were processed by the Create Accounting
process but not transferred for some reason.
To View Accounting Events
Cost Management SLA Responsibility
SLA > Inquiry
Tools Menu Options
Then select Accounting Events, Journal Entries, or Journal Entry Lines to open.

You can also view the Account Journal Entries and Accounting Events from the View
Transaction Windows:
View Receiving Transactions
View Material Transactions
View Resource Transactions

The function Tools > Options is only available if SLA is being used for the transaction.
If there is no SLA being used, the distributions button will show the transaction details.

Basic Steps to Build Accounts:
These steps are needed for each different journal line type that is going to be used. For example,
Inventory valuation, Receiving valuation, WIP valuation, Cost of Goods Sold.

Step 1 Create Account Derivation Rule (ADR)

Step 2 Define conditions required for the ADR created

Step 3 Create Journal Line Definitions (JDL) for an event class
a- query the LOV of seeded event classes
b- copy the seeded event class using the Copy Definition button
c- replace existing ADR in the Journal Line type form with the new ADR
this is in the Line Assignments sections, using Line Type

Step 4 Create new Applications Accounting Definition (AAD)
a- query for the seeded AAD
b- copy from this to create a new AAD
c- associate the new JLD assignments created in Step 3
d- validate the definition. If successful continue to next step or continue creating the JLDs
required. If unsuccessful, check the setup for all steps above before moving to next steps

Step 5 Associate the new AAD with the Subledger Accounting Method (SLAM)
a- query SLAMs to view existing methods
b- for the existing AAD enter an end date to stop this from being used
c- attach the new AAD with the start date
Step 6 Assign the SLAM to the Ledger

Accounting Methods Builder

Ledger
|
Subledger Accounting Method (SLAM)
|
Application Accounting Definition (AAD)
|
Journal Line Definition (JLD)
|
-------------------------------
| |
Journal Line Types Account Derivation Rule
(JLT) (ADR)
|
Sources
|
Transaction Objects

The process is built from the bottom up.
Ledgers replace Set of Books.
The 3C’s is now known as the 4C’s:
Chart of Accounts
Calendar
Currency
Accounting convention

This allows for accounting to be used at the local level (by country) and also by the line of
business (sales, consulting, etc). The Ledger and Ledger Sets (group of Ledgers) use the Multi-Org
Access control (MOAC) that is expanded in R12.

Examples of Subledger Methods (SLAMs)
US GAAP
FRENCH GAAP
Cash Basis Accounting
Accrual Basis Accounting

The following SLAMS are seeded in Oracle:
Standard Accrual
Standard Cash
Encumbrance and US Federal

Product teams are responsible for the following:
Identify transaction entities with accounting impacts
Define event types that correspond to different status in the lifecycle
Create events for transactions when passing from status to another …this is transparent to the
customer although the creation is triggered by the user action.
Define transaction objects that provide data that SLA uses to create journal entries
Population of transaction objects is the responsibility of product teams

SLA Team is responsible for the following:
Defining data model for events
Develop/Maintain programs and APIs that create and maintain events and related objects
Processing events as part of the Create Accounting programs

Events

Event Entities have Event Classes. Each Event Class has Event Types.
There are four Main Entities for Cost Management:

Inventory:
Material Accounting Events
Event Classes:
PO Delivery in Inventory
Sales Order Issue
Internal Order to Expense
WIP Material
Consigned Inventory Ownership Transfer
Miscellaneous
IntraOrg transfer
Direct Interorg Shipment
Direct Interorg Receipts
Intransit Interorg Shipment – FOB Shipment
Intransit Interorg Receipt – FOB Receipt
All other intransit interorg transactions
Material cost update
Retroactive price adjustment
Logical Intercompany
WIP Material Lot

Purchasing/Receiving
Write Off Accounting Events
Receiving Accounting Events

Work in Process:
WIP Accounting Events
Event Class:
WIP Absorption
Event Type:
Resource Absorption
Resource Overhead Absorption
Scrap Absorption
Outside Processing
Event Type:
OSP Transaction
ShopFloor Delivery for Direct Items
IPV transfer to Work Order
WIP Variance
Event Type:
Period Close Variance
Job close Variance
Fin WIP Lot
Event Type:
WIP Lot Split
WIP Lot Merge
WIP Lot Update Quantity
WIP Lot Bonus
WIP Cost Update
Event Type:
WIP Cost Update

The Work in Process list above shows the Main Event Entity is WIP Accounting.
The Event Classes are then listed with each Event Type that is part of the Event Class.

Definitions:

Accounting Methods Builder
This is the process that created a SLAM and assigns it to the Ledger.

Ledger
The ledger determines the rules that are applied when accounting is generated. Ledgers replace Set
of Books. Each Operating Unit is associated with a Primary Ledger. Multiple Legal Entities can be
tied to a Ledger through the accounting set up flow. Multiple SLAMs can be assigned to a Ledger.
There can be a primary and Secondary ledger setup that can use different accounting methods in
each ledger.

Subledger Accounting Method (SLAM)
This is the subledger accounting method that is built and assigned to a Ledger. This will be created
via the Accounting Methods Builder and includes all the details needed to created the appropriate

journal entries.

Application Accounting Definitions (AAD)
The application accounting definitions is made up of the Journal Line Definition, Journal line
types, and Accounting Derivation Rules. These are developed using the event classes and types. A
new AAD can be created or a seeded AAD can be used. The details are assigned and validated to
be certain the setup at this level is correct.

Journal Line Definitions (JLD)
JLT, ADR and JED are combined to create the JDL for an event. These can be shared across
AADs and can be used to create sets of line assignments for event classes and types.

For Cost Management, The Journal Entry Description is not seeded by default in Costing
application accounting definition. This has been submitted as an enhancement request.

Journal Line Types (JLT)
The types are defined for each particular class to be used. These must be assigned to the Journal
Line Definition (JDL) to be used. These determine the journal entry line options to be used. These
options include identifying the natural side used (debit, credit, gain/loss), accounting class,
summarization, and other conditions that will cause the rule to create a journal entry.

Account Derivation Rule (ADR)
This is used to determine the accounting combinations that will be used for the journal entries.
Various rules can be defined. These can be defined by segment, accounting combination, or value
set. The simplest way to derive an account is to establish the account as a constant value-use the
account combination that is defined in the accounting chart of accounts.

Mapping Sets
These sets are optional and user defined. If the user determines that the seeded details are
insufficient, then mapping sets can be setup to allow for more specialization in the accounts. This
is not supported by development as this would require customization. Seeded details are supported
as they are provided by Oracle code.

Transaction Objects/Sources
Transaction objects and sources carry transaction information into the rules defined for the
accounting chart of accounts.

Event:
An event is the recording of a change of status in the transaction life cycle, i.e., invoice approved,
payment received, period close, etc. These are defined for each
SLAM used. Event classes and event types are used to create the events to be used

Event Class
This classifies the types of transactions that are to be accounted for. An example of an event class
is WIP Variance.

Event Type
This defines actions that are possible for an event class that has potential accounting significance.
Examples for the WIP Variance Event CLASS would have event TYPES defined for Period Close
Variance, Job Close Variance, and Final Completion Variance.

References:
Note 429105.1
Note 466522.1

Impact of R12 design on PO accounting

This document explains the impact of R12 design in PO Accounting and
Difference in Behavior between 11i and 12i in the following areas

1. Setting up of Encumbrance
2. Generation of Encumbrance Entries
3. Receipt Accounting
a) Online Accruals
b) Period End Accruals
4. Accrual Reconciliation Process
a) Accrual Reconciliation Reports
b) Accrual Write-off Process

It also gives a basic idea of table level flow of accounting entries from
Purchasing to General Ledger

Document History
Author : Manighandan Venkatraman
Create Date 27-APR-2007
Update Date 27-APR-2007
Expire Date

Impact of R12 Design in PO Accounting
Basic Changes:

1. Set Of Books is replaced by the term Ledger. The column set_of_books_id
has been replaced with ledger_id in Gl Tables

2. Subledger Accounting (SLA) options has been introduced and accounting
entries can be viewed at SLA menu

3. Accounting entries can be created manually at SLA level and can
be transferred to General Ledger by running the program 'Transfer to GL'.

4. As a part of Subledger Accounting, new SLA tables XLA_AE_HEADERS,
XLA_AE_LINES and XLA_DISTRIBUTION_LINKS have been introduced.

5. PO details are not available in reference
columns(reference_1,reference_2...) in GL_JE_LINES and GL_BC_PACKETS.
Hence accounting entries in these tables can be retrieved only using SLA
tables and GL_IMPORT_REFERENCES

6. Receiving Subledger is not directly linked to GL_JE_LINES,instead it is linked
through the subledger tables XLA_AE_HEADERS, XLA_AE_LINES and
XLA_DISTRIBUTION_LINKS.

XLA_AE_LINES is mapped to GL_IMPORT_REFERENCES with the gl_sl_link_id
and gl_sl_link_table columns. The linking columns between
GL_IMPORT_REFERENCES and GL_JE_LINES are je_header_id and je_line_num

Setting up of Encumbrance:

Navigation:

General Ledger>Set up>Financials>Accounting Set up Manager>Accounting
Set ups
Query the ledger and you can find the option for setting up the Subledger
Accounting Method

Subledger Accounting Method is having the option of
a) Standard Accrual
b) Encumbrance Accrual

If Encumbrance needs to be enabled, then the Subledger Accounting Method
has to be set as "Encumbrance Accrual" for the ledger.
If Encumbrance is not used, then the Subledger Accounting Method has to be
set as "Standard Accrual" for the ledger

Difference in Behavior between 11i and 12i:

In 11i, there is no need of enabling Encumbrance for the Set of books in GL

module other than enabling the Budgetary Control option
where as in R12, Subledger Accounting Method has to be set for the ledger. If
it is set to "Standard Accrual", Encumbrance cannot be used for that ledger
even though the Encumbrance is enabled for the REQ,PO and INVOICE in
Financial Options

Generation of Encumbrance Entries:

On Reserving and Approving the PO, Encumbrance entries get generated in
GL_BC_PACKETS with SOURCE_DISTRIBUTION_TYPE as po_distributions_all and
SOURCE_DISTRIBUTION_ID_NUM_1 as po_distribution_id.

Encumbrance entries will also get generated in the table
PO_BC_DISTRIBUTIONS which has been newly introduced in R12. This table
has the reference4 and reference3 columns where the PO/PR number and
distribution id gets populated.

Accounting entries created on reserving the PO can be viewed in SLA menu in
Purchasing module

Navigation:

Purchasing>Accounting>SLA:User Main Menu>Journal Entries
Query by transaction dates and ledger name

Following Accounting entries will be available in the HTML page

Budget a/c DR
Reserve For Encumbrance CR

These accounting entries are populated in the table XLA_AE_LINES. The event
type code in XLA_AE_HEADERS for this Encumbrance entry is
PO_PA_RESERVED

The table PO_BC_DISTRIBUTIONS and XLA_AE_HEADERS are linked with the
column event_id.
The table XLA_AE_HEADERS and GL_BC_PACKETS are linked with the column
ae_header_id.
The table XLA_AE_HEADERS and XLA_AE_LINES are linked with the column
ae_header_id

The Concurrent Request "Transfer Journal Entries to GL" has to be submitted
from Purchasing Responsibility to transfer the Encumbrance Entries to GL.


1. In 11i, Encumbrance entries created in GL_BC_PACKETS will be directly

moved to GL_JE_LINES by running the CJE program, whereas in 12i,
Encumbrance entries gets generated in a new table PO_BC_DISTRIBUTIONS in
addition to GL_BC_PACKETS. These entries will be moved to GL by running the
program "Transfer Journal Entries to GL" instead of CJE program.

2. In 11i, it is not possible to view the Encumbrance entries in Purchasing
module, where as in 12i, the entries can be viewed from SLA menu in
Purchasing

3. In 11i, a Credit against the Reserve For Encumbrance a/c (RFE) can be
seen only at the time of posting the Encumbrance Debit entry in GL, But in
12i, RFE a/c gets credited along with the PO Reservation ( budget a/c debit
entry) and these entries can be viewed from SLA menu in Purchasing

Receipt Accounting:
a) Online Accruals:
When Purchase Order has Accrue on Receipt set to Y, Receiving Transaction
Processor generates the accounting entries in RCV_RECEIVING_SUB_LEDGER
upon Receipt and Deliver of the PO. Then the Create Accounting-Receiving
concurrent program has to be submitted from Purchasing>View Requests or
from Cost Management Responsibility > SLA menu > Create Accounting to
create SLA journals which will insert records in XLA_AE_HEADERS,
XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. This program will spawn another
program called "Accounting Program" which will generate the entries in
GL_INTERFACE. There is an option to make the journal entry and post the
journals automatically at the time of submitting the Create Accounting
program itself. This option is used by setting the profile SLA: Disable Journal
Import to "NO" .This will be the most preferred setting for this profile option
and this indicates that Journal Import will ALWAYS accompany the transfer of
data from Subledger. Another main implication of this value is that, on failure
of Journal Import, the data will be rolled back to SLA tables and hence there
will not be any data in GL_INTERFACE.

Parameters used while submitting the Create Accounting-Receiving concurrent
program:

Ledger - Ledger (SOB) name to be given
End date - Accounting entries to be created for all receipts TO DATE
a) Draft - Draft mode creates the SLA journals as Draft which can be modified.
Hence these entries will not get transferred to General Ledger and it will be
available only in the subledger table without gl_sl_link_id. Once the entries
created in Draft mode are verified and confirmed, Create Accounting program
has to be run in Final mode and the entries getting created now will be
transferred to General Ledger.
b) Final - Final mode creates SLA journals which can not be modified and can
be transferred to General Ledger.

For the values of the profile option SLA: Disable Journal Import , Draft and Final
options work in the same way
c) Final Post - “Final Post” works differently for the two values of the Profile
option. If profile option is set to No, then “Final Post” creates the SLA journals
in Final mode, transfers the data to GL_INTERFACE, runs Journal Import and
triggers the General Ledger Posting program too.
If profile option is set to Yes, then “Final Post” will create the SLA journals in
Final mode and will transfer the data to GL_INTERFACE. Thus the data will be
in GL_INTERFACE table, which will have to be manually Imported.

Report - Options available are Detail or Summary

Transfer to General Ledger - Yes or No - If the mode is set to Final and the
value for this parameter is set to No, then the accounting entries will get
created only in SLA table and it will not be available even in gl_interface.
You need to submit the program "Transfer to Gl" in Cost Management
Responsibility > SLA to transfer the entries created in Final mode from SLA to
General Ledger.

Post in General Ledger - Yes or No

Once the accounting is created for Receiving transactions in SLA, the
encumbrance reversal entry can be viewed in SLA menu in Purchasing module
as well as in SLA menu in Costing

Navigation:

Purchasing>Accounting>SLA:User Main Menu>Journal Entries


Budget a/c CR
Reserve For Encumbrance DR

These accounting entries will be available in the table XLA_AE_LINES. The
event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is
DELIVER_EXPENSE for Expense destination and PO_DEL_INV for Inventory
destination.

These two entries can also be viewed as follows –
Receiving Transaction Summary>Deliver Transaction>View Accounting
But the actual entries for the DELIVER transaction cannot be viewed from View
Accounting. Only the actual entries for the RECEIVE transaction can be viewed
from View Accounting.
The Actual entries created by the Receipt & Deliver transaction will not be
available in the Purchasing>SLA Main Menu , even though the Create

Accounting Program is run /completed . SLA in Purchasing will only show the
Encumbrance entries , It is required that we navigate to the Cost Management
responsibility to view the Actual entries .
Navigation:

Cost Management>SLA Resp>SLA>Inquiry>Journal entries


AP Accrual a/c CR
Receiving Inspection a/c DR

Charge a/c DR
Receiving Inspection a/c CR

event type code in XLA_AE_HEADERS for these actual entries is RECEIVE,
DELIVER_EXPENSE and PO_DEL_INV

Note : These actual accounting entries can be seen in SLA only when the
Create Accounting program is run. Likewise, other subledger (Inventory,
Payables) transactions are made as SLA journals on running the respective
Create Accounting programs.

The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can
be linked using the column SOURCE_DISTRIBUTION_ID_NUM_1.
RCV_SUB_LEDGER_ID has to be given as SOURCE_DISTRIBUTION_ID_NUM_1 for
the source_distribution_type "RCV_RECEIVING_SUB_LEDGER" in
XLA_DISTRIBUTION_LINKS.

Similarly for the deliver transactions to inventory destination, the tables
MTL_TRANSACTION_ACCOUNTS and XLA_DISTRIBUTION_LINKS can be linked
using the column SOURCE_DISTRIBUTION_ID_NUM_1. INV_SUB_LEDGER_ID has
to be given as SOURCE_DISTRIBUTION_ID_NUM_1 for the
source_distribution_type "MTL_TRANSACTION_ACCOUNTS".


In 11i, Receiving Transaction Processor creates the Receipt Accounting entries
in Receiving Subledger as well as in GL_INTERFACE. Journal Import will be done
to transfer the entries to GL_JE_LINES where as in 12i, Receiving Transaction
Processor will create the entries only in Receiving Subledger. Create
Accounting Program has to be run to create SLA journals which in turn will
trigger the journal import.

b) Period End Accruals:
When Purchase Order has Accrue on Receipt set to N, Receipt Accruals Period
End program generates the accounting entries only in
RCV_RECEIVING_SUB_LEDGER during month end when the received quantity is
greater than billed quantity.Then the Create Accounting-Receiving concurrent
program has to be submitted to create actual entries in SLA and GL. This
program will spawn another program called "Subledger Multiperiod Accounting
and Accrual Reversal Report" which will automatically reverse the actual
entries in the next period in SLA as well as in GL. Encumbrance reversal will be
created in Receiving subledger by the period end program but this entry will
not get transferred to SLA or GL by the Create Accounting program.
Once the accounting is created for Receiving transactions,the actual entries
can be viewed in SLA menu in Costing

Navigation:
Cost Management>SLA Resp>SLA>Inquiry>Journal entries


AP Accrual a/c CR
Charge a/c DR

for the period in which Receiving is done and for the next period,you can see
the reversal entry as

AP Accrual a/c DR
Charge a/c CR

event type code in XLA_AE_HEADERS for these actual entries is
PERIOD_END_ACCRUAL

Encumbrance will get reversed from the PO once the invoice is
validated.Encumbrance on the PO will get converted to Invoice encumbrance.
On doing Create Accounting for the invoice, Encumbrance on the invoice will
also get reversed.


1. In 11i, Receipt Accruals Period End program creates the Receipt Accounting
entries in Receiving Subledger as well as in GL_INTERFACE. Journal Import will
be done to transfer the entries to GL_JE_LINES where as in R12, Receipt
Accruals Period End program will create the entries only in Receiving
Subledger. Create Accounting Program has to be run to create SLA journals
which in turn will trigger the journal import.

2. In 11i, Accrual entries need to be reversed manually in the next period

whereas in R12, reversal of accrual entries for the next period will happen
automatically

Accrual Reconciliation Process:

a) Accrual Reconciliation Reports:
After completing the Receipt transactions and Invoice matching, Create
Accounting program has to be run in Final mode along with the subsequent
transfer of entries to General Ledger after which the Accrual Reconciliation
Process has to be started.

"Accrual Reconciliation Load Run" program has to be submitted with
transaction date as the parameter which will populate the data in two tables
called CST_RECONCILIATION_SUMMARY and CST_AP_PO_RECONCILIATION.
Now run the Accrual Reconciliation Report for the operating unit and do the
reconciliation. There are 3 different types of Accrual Reconciliation Report

1. AP and PO Accrual Reconciliation Report - This report shows the transaction
details based on each accrual account for each PO distribution with the
Receiving transaction amount and invoice transaction amount with a net
balance greater than zero.

Parameters used while submitting the program:

Operating Unit - Select the Operating Unit for the report
Title - Enter your title for the report
Sort by - Parameter to specify how to sort the data at the distribution level -
Valid Values - Age in days,Total Balance,Vendor,PO number (default)
Aging Period Days - The number of days by which to group transactions sorted
in descending order
Item From and Item To - Range of items to consider for this report
Vendor From and Vendor To - Range of Vendors to consider for this report
Min Outstanding Balance and Max Outstanding Balance - Limits of distribution
balance to dispaly
Balancing Segment From and Balancing Segment To - Range of balancing
segment to consider for this report

2. Summary Accrual Reconciliation Report - This report shows the total
balances for each accrual account without any distribution details and
individual transaction amount and also shows whether that summarized
accrual balance is related to AP PO transaction or AP no PO transaction or
Miscellaneous Inventory transaction.



3. Miscellaneous Accrual Reconciliation Report - This report shows the
transaction details based on each accrual account which got hit because of
Miscellaneous Inventory transactions and AP NO PO transactions.Accrual
amount will be displayed for each transaction along with the source whether it
is INV or AP.


Sort by - Parameter to specify how to sort the data at the distribution level -
Valid Values - Item,Transaction Date (default) , Amount
Date From - Starting date of time period to display for this report
End Date - Ending date of time period to display for this report
Item From and Item To - Range of items to consider for this report
Min Amount and Max Amount - Limits of transaction amount to display


1. In 11i, the Accrual Rebuild Reconciliation Report which was required to be
run to populate the accrual reconciliation table is now replaced by "Accrual
Reconciliation Load Run" program in 12i. The table
PO_ACCRUAL_RECONCILE_TEMP_ALL has been replaced by the tables
CST_RECONCILIATION_SUMMARY and CST_AP_PO_RECONCILIATION in R12.

2. 11i has only one Accrual Reconciliation Report which will show all the
transactions for the accrual account irrespective of whether it is Miscellaneous
INV transaction or AP NO PO transaction. But in 12i, there are 3 different
reports, one for AP-PO individual transactions, one for Miscellaneous
transactions showing the individual transaction details for source INV and AP
and one for showing the summarized accrual balance for all transaction types.

3. 11i has the option of running the Accrual Reconciliation Report with net
accrual balance as 0 as well as net accrual balance greater than 0. But in R12,
Accrual Reconciliation Report will show only the transactions having net
accrual balance greater than zero.

b) Accrual Write-off Process:
Once the accrual entries for the PO or invoice are shown in Accrual
Reconciliation Report, Accrual Write-off can be done using Cost Management
or Purchasing responsibility>Accounting>Accrual write offs>AP and PO. This

will delete the accrual entry from CST_AP_PO_RECONCILIATION table and
populate the write off transaction in CST_WRITE_OFFS table. This write off
transaction can also be viewed in the form View Write offs.
Accounting entries have to be created in SLA and GL for these write off
transactions by submitting the Create Accounting program.This can be viewed
in SLA menu by navigating to Tools > View Accounting in the View Write offs
form.

Following Accounting entries will be available in the HTML page for a RECEIVE
transaction

Accrual a/c DR
Offset a/c CR

Similarly for an AP PO MATCH transaction
Accrual a/c CR
Offset a/c DR

This Offset a/c will always be the Invoice Price Variance account.

Accounting events for this write off transaction will show the Event status as
"Final Accounted" once the Create Accounting program is submitted and the
entries are transferred to GL.


1. The table PO_ACCRUAL_WRITE_OFFS_ALL has been replaced by the
table CST_WRITE_OFFS in R12.

2. In 11i, accounting will not get created for the write off transaction and
accrual entry has to be manually adjusted in GL whereas in R12, Create
Accounting program will create the accrual entry for the write off transaction
in SLA as well as in GL and hence manual adjustment of accrual entry is not
required.

Please do the following to assign Legal Entities to the Cash Management responsibility :

1. Log in as Sysadmin.

2. Go to the User Management Responsibility.

3. Path: Roles & Role Inheritance

4. In the Type field select Roles and Responsibilities

5. Wait until a new field appears, you will see the category field, please select Miscellaneous

6. In the Application select 'Cash Management' and click on GO button.

7. Search your Cash Management responsibility or role that you are using to create your bank
account.

8. Click on the update icon.

9. A new window will be displayed, please click in the Security wizard button.

10. For CE UMX Security wizard click on the Run Wizard.

11. In this window you should add the legal entities that you want to grant the access to all the

bank accounts within a legal entity and choose the privilages that you want to assign to this role on
the

bank accounts such as: USE, MAINTENANCE and BANK ACCOUNT TRANSFERS.

12. Save and apply the changes and then verify in Cash management responsibility if you now are

able to see that legal entity in the bank account creation form.

89092672 r12-functionality

More Related Content

What's hot (20)

Similar to 89092672 r12-functionality (20)

Recently uploaded (20)

89092672 r12-functionality