Oracle 12i - How to create accounting and transfer JE's to GL using SLA

I. Create Accounting Program:

The Create Accounting program processes eligible accounting events to create subledger journal entries. To create the subledger journal entries, the Create Accounting program applies application accounting definitions that are created in the Accounting Methods Builder (AMB).

The Create Accounting program:
•Validates and creates subledger journal entries
•Optionally transfers the journal entries to GL
•Optionally posts the journal entries in GL
•Generates the Subledger Accounting Program Report, which documents the results of the Create Accounting program

Draft Accounting:
When you select draft accounting, Subledger Accounting creates the relevant journal entries in draft mode. Draft entries are not posted to General Ledger. You can review the resulting entries, update the transactions, or update the accounting rules. Any changes will be reflected when the transaction is processed again for accounting.

Online Accounting (Final):
Final entries are ready to be transferred to General Ledger and cannot be modified. The transactions are considered as processed for accounting. Any changes to the rules will not impact final entries.

Straight-Through Accounting (Final - Post):
If you select Final Post, Subledger Accounting posts the journal entries all the way through to General Ledger. This means that you can update GL balances straight from the invoice entry (or any other transaction entry) window.

Create Accounting Program:
The Create Accounting program creates subledger journal entries. In general, the parameters described in the table above determine which accounting events are processed.
Navigation Paths (example Payables)
Payables: Other > Requests > Run
Receivables: View > Requests (B) Submit a New Request

Paramaters:

1. Ledger - Required; limits accounting events selected for processing to those of a particular ledger. This program is run for primary ledgers or valuation method enabled secondary ledgers. Any reporting currency or secondary ledger associated with the selected primary ledger is also processed; i.e. entries are generated for the selected primary as well as reporting currencies and non-valuation method secondaries.

2. Process Category - Optional; restricts the events selected for accounting to a particular process category. For example, Invoices.

3. End Date - Required; end date for the Create Accounting program; processes only those events with event dates on or before the end date

4. Mode (Draft/Final) - Required; determines whether the subledger journal entries are created in Draft or Final mode

5. Errors Only (Yes/No) - Required; limits the creation of accounting to those events for which accounting has previously failed

6. Report (Summary/Detail/No Report) - Required; determines whether to generate a report showing the results of the Subledger Accounting program in summary or detail format

7. Transfer to General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to transfer the subledger journal entries to General Ledger

8. Post in General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to post subledger journal entries in General Ledger

9. General Ledger Batch Name - Optional; user-entered batch name that appears on the transferred General Ledger subledger journal entries. Transfer to GL option must be set to Yes.

10. Include User Transaction Identifiers (Yes/No) - Required; controls whether the report displays user identifiers' names and values.


Create Accounting Program:
The Create Accounting program generates one or more accounting programs depending on the volume to be processed. The Subledger Accounting Program report is generated by the Create Accounting program and documents the results of the Create Accounting program. It lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events
You can run the report in summary, detail, or no report mode which are described as follows:
•Summary mode provides a summary of events processed and detailed information about their errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.
•No report mode will show an error count without actually generating the report.

II. Transfer Journal Entries to GL Program:

The Transfer Journal Entries to GL program enables you to transfer any eligible journal entries to General Ledger, including those from previous runs that have not yet been transferred to General Ledger.

Note: This program is used if you run accounting online in Final mode (not Final Post) or if you run the Create Accounting program and set the Transfer to GL parameter to No.

The only reason you would want to run the Create Accounting program and set the Transfer to GL parameter to No is if you want to run accounting at different intervals than the GL transfer, for example, you may run accounting every hour but only transfer to GL nightly.

The Transfer Journal Entries to GL program consists of a subset of parameters used in the Create Accounting program as listed below:
–Ledger
–Process Category
–End Date
–Post in General Ledger
–General Ledger Batch Name

III. Oracle Subledger Accounting Program Report:

The Subledger Accounting Program Report is generated by the Create Accounting program and lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events

You can run the report in summary or detail mode as follows:
•Summary mode provides a summary of events processed and detailed information about any errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.

IV. Transfer Journal Entries to GL Report:

The Transfer Journal Entries to GL report is generated by the Transfer Journal Entries to GL program and lists the following:
•Transfer to GL Summary
•Errors

Setting Profile Options:
The profile options listed above relate to data access and security and impact how accounting is generated through SLA in R12.

1. SLA: Enable Subledger Transaction Security in GL
•Use this profile option to combine subledger transactions security with data access security for General Ledger responsibilities when drilling down to multi-organization enabled subledger application. Transaction security in the respective subledger application is always applied when drilling down from subledger transactions to subledger journal entries.

2. SLA: Enable Data Access Security in Subledger
•This profile option determines whether the General Ledger Access Set security mechanism is applied for a subledger application responsibility when viewing, reporting, or creating subledger journal entries associated with a given ledger. The General Ledger Access Set security mechanism is always applied for responsibilities associated with the General Ledger application.
•The profile option enables you to combine data access security with subledger transaction security and therefore control access to subledger journal entries depending on the ledger to which they belong. For example, you can implement a Multi-Org Security Profile that allows you to create Oracle Receivables Invoices for two different operating units each associated with different ledgers but restrict drill-down from the subledger transaction to the associated subledger journal entry based upon the destination ledger contained in the Access Set.

3. SLA: Additional Data Access Set
•The SLA: Additional Data Access Set profile option, in conjunction with the GL: Data Access Set profile option, controls which ledgers and balancing or management segment values you can access when logging onto a responsibility. If SLA: Enable Data Access Security in Subledgers is enabled for the responsibility, you have access only to the ledgers and balancing or management segment values included in the data access sets assigned to the SLA: Additional Data Access Set and GL: Data Access Set profile options.

4. SLA: Allow Reports Journal Source Override
•This profile option applies only to the following reports:
-Open Account Balances Listing
-Third Party Balances Report
•Enable this option to change the Journal Source parameter during report submission. If the option is set to No, then you cannot change the value defaulted during report submission.
For example:
•Should the general ledger data access set security be enforced when generating accounting? For example, should journal entries be created if the user does not have ledger clearance even if they may have multiorg access to the operating unit?
•Should the transaction security model be applied when drilling down from GL? For example, should the user be allowed to inquire on journal entries of certain operating units if they do not have MO access, but have ledger clearance?
•If there are secondary ledgers and data access set security is enforced in the subledger module, then an additional data access set needs to be assigned to the user to enable access to the secondary ledger.
•Should the user be able to run certain reports across data from multiple subledger applications?

Oracle AR 12i - how to configure and use Credit Card Chargeback features

Credit Card Chargeback:

A credit card chargeback takes place when a credit card holder disputes a charge with the credit card company (e.g. VISA) and the credit card company issues a chargeback to the customer for the disputed amount and notifies the vendor that they have issued a chargeback to the customer.
A cardholder can request a charge back for many reasons including, but not limited to:
•Charges for undelivered goods
•Charges for goods or services different from what was ordered or if they received the wrong quantity of the goods or services ordered.
•Charges for goods that were not timely delivered

In release 11i, we already have the functionality for the vendor to issue a chargeback directly to the customer. The customer can however also request a chargeback from the credit card issuer, so in release 12 - we are introducing the functionality for the vendor to also be able to register and process a chargeback that a card issuer has already issued to the customer.

Benefits:
•Reduce costs by automating the credit card chargeback process

Credit Card Chargeback Process:
After having received the credit card chargeback notification from the card issuers, the vendor will:
•Find the receipt for which the chargeback was requested.
•Un-apply the application line and subtract the amount of the credit card chargeback.
•Apply the credit card chargeback activity on a new application line on the receipt. This automatically generates a negative miscellaneous receipt to the value of the chargeback.

If the vendor finds the chargeback to be valid, the vendor creates a credit memo to credit the invoice with the amount charged back.

If the vendor can prove to the credit card company that the chargeback was not valid, the vendor reverses the application of the credit card chargeback by:
•Finding the receipt
•Un-applying the credit card chargeback activity from the receipt. This automatically reverses the negative miscellaneous receipt
•Restoring the original amount on the application line.

It is important to understand how our new Credit Card Chargeback functionality differs from the Credit Card Refunds we already have in 11i:
•Credit card refunds: The merchant needs to refund the customer. So the negative misc. receipt must be remitted.
•Credit card chargebacks: The customer has already received the chargeback, so the vendor will just need to record that a chargeback has taken place. The purpose of the misc. receipt is just to keep the accounting in place.

Business Process Steps:
The business process that takes place when a credit card chargeback needs to be recorded is a three step process:
1.The vendor receives the receipt, records it and applies it to the invoice.
2.The vendor receives the Credit Card Chargeback notification and records the credit card chargeback by applying the credit card chargeback to the receipt
3.The vendor then needs to investigate if the Credit Card Chargeback is valid or not. Based on the outcome, the vendor can choose to either:
-Acknowledge the credit card chargeback and credit the invoice, or
-Prove that the credit card chargeback was not valid, and after acknowledgement un-apply the credit card chargeback from the receipt

Credit Card Chargeback Process Receive Receipt:
Example:
•A customer visits a web store and orders goods for $100 using their credit card
•The credit card company authorizes the payment and notifies the vendor of the receipt of $100
•The vendor processes the receipt and applies it to the invoice.
Please note that there are no changes in how these activities are carried out in R12.

Let’s now take a look at the credit card chargeback process.
•The customer receives the goods, but finds that goods for $25 are missing.
•The customer files a dispute with the credit card company for $25
•The credit card company credits the customer $25 and notifies the vendor that a chargeback of $25 has taken place.
•The vendor applies the credit card chargeback to the receipt which generates a miscellaneous receipt to decrease cash with $25
Here we can see how the clearing account for the receivable activity of type ‘Credit Card Chargeback’ is used. It gets credited when the credit card charge back is applied and gets debited when the misc. receipt is generated.

Accounting Entries:

•Un-apply the receipt
–DR Receivables $25
–CR Unapplied $25
•Apply the credit card chargeback
–DR Unapplied $25
–CR Credit Card Chargeback $25
•Misc. receipt is generated
–DR Credit Card Chargeback $25
–CR Cash $25

Chargeback Process for Vendor:
1.Find receipt
2.Un-apply the receipt
3.Decrease the value on the receipt application line to $75
4.Apply $25 to receipt activity ‘Credit Card Chargeback’ (creates a negative misc. receipt of $25)

Validate Credit Card Chargeback:
After the vendor has analyzed the credit card chargeback, the vendor can find the credit chargeback to be either valid or invalid.
The vendor can now either:
•Acknowledge the credit card charge back and credit the invoice.
•Prove to the credit card company that the credit card chargeback was invalid and un-apply the credit card chargeback from the receipt once it has been acknowledged by the credit card company that the credit card chargeback was invalid.

If the vendor acknowledges the credit card chargeback, the vendor simply credits the invoice by creating a credit memo for $25.

•Credit the invoice by creating a credit memo
–DR Revenue $25
–CR Receivables $25

Vendor proves the chargeback to be invalid:

•Un-apply the credit card chargeback
–DR Credit Card Chargeback $25
–CR Unapplied $25
•Misc. receipt is automatically reversed
–DR Cash $25
–CR Credit Card Chargeback $25
•Reapply the receipt
–DR Unapplied $25
–CR Receivables $25

Credit Card Chargeback Setup:
•Responsibility: Receivables
•Navigation: Receipts > Receipts > (B) Apply > Applications > (B) Chargeback
Release 12 comes with the seeded Receivables Activity Type of ‘Credit Card Chargeback’.
The only setup step required is to create a new receivables activity of type credit card chargeback and specify the GL clearing account for the new activity.
Note: Only one activity of this type can be active.

Balance Forward Billing in Oracle AR 12i

Balance Forward Billing in 12i:

Balance Forward Billing replaces Consolidated Billing feature with enhancements to bill creation and presentation.
•Billing Cycles
-Billing cycles are no longer just monthly. Easily create daily, weekly, monthly, bi-monthly, quarterly, and annual billings
-Bill on specific days of the month. User can not only specify the day of the month for the billing date, or even multiple days like “every 15th and last day of month”. User can also elect to bill on a specific day of the week, such as every Friday.
-Choose to exclude weekends. User can skip weekends when determining billing dates, so billing dates only fall on workdays
-For importing transactions with specific dates, there is an External Billing Cycle
•Consolidate invoices at different customer levels
•Activity can be consolidated across account sites, or by each billing site. This means one bill can be sent for each billing location, or a single bill can be sent incorporating all invoices for that customer account within an organization
•Not all billing sites for a customer must consolidate their invoices. A site can be excluded from the account level bill. If a site prefers to receive individual invoices, that site can be excluded from the Balance Forward bill.
•specific invoices can be excluded from the Balance Forward Bill. By changing the payment term on an invoice, it can be printed separately

Enhanced viewing and printing:
•Balance Forward Billing integrates with Oracle Bill Management, which provides formats with a more appealing layout that can be easily modified.
In 11i, there are five consolidated bill programs. The new feature consolidates these programs into three.

Benefits:
1. Flexibility
•In 11i, you had to choose between consolidating all invoices for a customer into one monthly bill, or printing all invoices separately. Plus, if you needed different billing formats that meant customizing print layouts.
•Now you have expanded billing periods definition by using the new billing cycle concept; varied levels of consolidation; the ability to exclude specific invoices, and unlimited formats that are easily created and maintained and selected automatically by a rules engine

2. Clearer communication with the customer
•User views the balance forward bill online exactly as the customer sees it
Accurate Aging
•In 11i Consolidated Billing, the payment term assigned to the transaction was ignored if consolidated billing was enabled. This meant that the due date on an individual invoice may be different then on the consolidated bill if the payment term assigned to the invoice was different than the default payment term assigned to the customer. Aging is based on due date of the individual invoice, while payment due date was based on the payment term assigned to the customer. This caused aging to be out of sync with bills due date. Now all Invoices that are consolidated on the same bill have the same payment term and due date, guaranteeing the individual invoices will age simultaneously.

Setup and Process:
The key setup steps are:
1.Define a Billing Cycle
2.Define or update the Payment term and assign it the Billing Cycle
3.Enable Balance Forward Billing for customers wishing consolidated bills at either the site or account level.
The process is then executed as follows:
1.Enter transactions or import them using AutoInvoice or Transaction API
2.Run the Generate Balance Forward Bill Program to create the bills as either draft or final, or set it up to run automatically
•The generate program will kick off the print program in BPA to create either draft or final bills.
•In Draft format, they can be reviewed before sending.
•If the process is mature, you may elect to run Generate Balance Forward Bill Program in the create Final Bill format. In which case, the BPA program will create final bills.
3.If you create bills in draft mode, you can either reject or accept the bills using the Confirm Balance Forward Bills Program.
•You can choose to reprint draft bills via the BPA Print Program by selecting the concurrent request ID.

Balance Forward Billing Setup - Define Billing Cycle:
•Responsibility: Receivables
•Navigation: Setup:Print > Balance Forward Billing Cycles
•For Daily, you can pick the number of days before the next bill. Also choose whether to include weekends in the number of days. For example, you can choose a daily cycle that is every 5 days, not including weekends in the daily count.
•For Weekly, you can pick the number of weeks before the next bill. Also, choose the day of the week the bill will be created. For example, you can choose bi-weekly billing that occurs every other Friday.

Balance Forward Billing Setup - Define Billing Cycle:
•For the monthly cycle, choose the number of months before the next bill. For example, choose 3 months if you need quarterly billing, or 6 months if you need bi-annual billing.
•Also choose the day of the month to create the bill. This option allows you to choose more than one date so billing can occur bi-monthly on the same days each month. For example, you can set it so billing occurs on the 15th and last of day of each month.
•By choosing Type of Day, you can elect to create the bills only on the workdays Monday through Friday. When you chose “Exclude Saturdays and Sundays”, if the billing date falls on a Saturday or Sunday, the billing date automatically changes to the date of the following Monday.

Balance Forward Billing Setup - Define Payment Term:
•Responsibility: Receivables
•Navigation: Setup : Transactions > Payment Terms
•Billing Cycle is a new attribute of the Payment term and must be assigned to the payment term to process balance forward billing. This field is not updateable if the payment term has been used.
•Cutoff Date information is now setup on the billing cycle, therefore the Cutoff Date block has been removed from the payment term setup window.
•The payment schedule dates:
-Due Date is calculated based on the cycle and billing date therefore, the Due Date is not enterable for Balance Forward Bills
-The Due Days field can indicate how many days after the billing date the bill is due for daily and weekly cycles
-Day of Month and Months ahead can be used with the Monthly billing cycle. It is recommended that these only be used when a single bill day is used otherwise the due date will be the same for all the bills created during the calendar month.
•After a balance forward billing payment term has been attached to a customer profile, the cycle will not be updateable.
•Existing payment terms cannot be updated to balance forward billing payment terms and vice versa.
•Consolidated or Proxima billing terms created in 11i will automatically be updated to balance forward billing payment terms.

Balance Forward Billing Setup - Customer Profile Class:
•Responsibility: Receivables
•Navigation: Customers > Profile Classes
•The customer profile class can be updated with the Balance Forward Billing information, which can then default to the profile on the customer account record.
•This region replaces the Consolidated Bill region in 11i.
•The Enable Checkbox must be checked to select a payment term with a Balance Forward Billing cycle.
•Balance Forward Bills can be created in summary or detail format: summary is at invoice total level; detail is at the invoice line level. Imported is used for the Imported Billing Number feature that was introduced in 11i.
-Note: The default print formats use this customer profile. If you do not want to use this option, you can create rules in BPA to ignore this value. When creating a rule, use the attribute “Display Format” to look at the value in this field.
•The Payment Term field allows you to choose either a Balance Forward if the Enabled checkbox is selected, or a Non-balance forward term if the Enable checkbox is not selected.
•The Override Terms checkbox means that the default Balance Forward bill payment term on an invoice can be changed. You can only select a non-balance forward payment term if you are overriding the default. Changing the payment term on the invoice means that you do not want this invoice to be included on the bill.
•Note: This is different functionality then 11i Consolidated billing which included all in voices on the bill regardless of the payment term assigned if consolidated billing was enabled.

Oracle BPA Rules Setup:
•Rules in BPA determine which template is used for printing and viewing Balance Forward Bills. Rules are created and then the templates get assigned to them.
•If you wish to have similar functionality as was provided by Consolidated Billing, use the default rules delivered with the feature. If you wish to create new BPA rules, and you want to use the Summary/Detail Type assigned to the customer profile option, use the BPA attribute called “Display Format”.
•BPA uses the following information to create the default rules:
-The Primary Data Source must be Oracle Receivables Balance Forward. Use this source when creating your own BPA rules.
-There are two Default rules: 1) one rule uses the attribute “Display Format” = Detail, 2) another rule uses the attribute “Display Format” = Summary
-These rules are then included in the rule hierarchy.
-Templates are assigned to each of rules. You can use the delivered summary and detail templates provided by BPA, or create and use your own templates
•When you run Generate Balance Forward Bills, BPA looks at the customer profile for the value assigned to the Summary/Detail Type to determine which template to choose.

Self Assessed Tax (perviously Use tax) in Oracle Payables 12i

Self-Assed Tax :
Self Assessed tax differs from regular taxes in one way: as a purchaser, you are responsible for reporting and paying the tax and the supplier is not.
This was also known as USE TAX in previous releases.
For example: You receive an invoice for $1000 which is due to be paid to the supplier. Tax A for 10% was not charged on the invoice however, as the purchaser, you recognize that you are responsible to pay tax A. You would self-assess Tax A for the $100 and include it in your filings to the corresponding tax authority.

Features:
•The flexibility to have self assessed tax automatically assessed (based on tax setup) or to manually mark the calculated tax as self assessed during invoice entry.
•An ability to have recoverable and non-recoverable portions of self assessed tax amounts based on your invoice details.
•The ability to report and account detailed recoverable and non-recoverable self assessed tax AND the corresponding Self Assessed Tax Liabilities when the transaction is accounted.

Benefits:
Improved Fiscal Discipline
•Automatic reporting and accrual helps maintain an audit trail for the tax amounts and the invoices they tie to.
•Separate liability accounts for self assessed taxes translate to more granular and accurate accounting.
Improved Operational Excellence
•By automating previously manual processes and providing functionality available during invoice entry, the propensity for human error or delayed information is reduced.

Self Assessed Tax Predetermined Process:
•During Invoice Entry, Validation, and Import, Payables gathers information known as “tax drivers’ entered on the invoice header and lines and passes that information to the new E-Business Tax module.
•Based on these tax drivers and additional information derived by E-Business Tax such as the supplier’s party tax profile and buyer’s and supplier’s tax registrations, the engine determines if any self assessed tax is applicable to the invoice.
•The self assessed tax will be passed back to Payables along with the recoverable and non-recoverable tax amounts and the General Ledger Accounts for the recoverable tax and self assessed liability.
•Payables displays the self assessed tax amount in a column on the Invoice header in the Invoice Workbench. Payables will also derive the accounts for the non-recoverable portion of the self assessed tax then store all accounts to be used later when the invoice is accounted.
•When the Invoice is Accounted, the self assessed tax and corresponding self assessed tax liabilities will be accounted along with the rest of the invoice.

Self Assessed Tax Manual Determination Process:
•This slide illustrates the process for an invoice where the calculated tax returned by the E-Business Tax engine is expected to be paid to the supplier and the Payables’ user updates the it as Self Assessed instead.
•Just like the first example, Payables gathers tax drivers entered on the invoice header and lines and passes that information to the E-Business Tax module.
•Based on these tax drivers and additional information derived by E-Business Tax, the engine calculates the tax that is expected to be paid to the supplier (in other words: Non-self assessed taxes)

Self Assessed Tax: Predetermined Set Up – First Party, Party Tax Profile:
To enable the application to automatically assess self assessed taxes for the First Party or for certain Third Party Suppliers, you need to first set up the Party Tax Profile. The Party Tax Profile is party specific, tax related information that can be associated to 1st and 3rd parties. It includes information such as defaults, tax registrations, classifications and tax reporting codes.
Using the Tax Managers responsibility, navigate to the Parties, Party Tax Profiles page. Search based on the Party Type of First Party Legal Establishment and the desired party name.
You have the flexibility to configure First Party Establishments for Self Assessed Taxes at the following levels based on your needs:
•Registration, Regime
•Registration, Regime, Tax
•Registration, Regime, Tax, Tax Jurisdiction
•From the Tax Summary Window, the Payables user marks the tax as self assessed. E-Business Tax updates their records and returns the tax details to Payables.
•Payables stores the GL Accounts, displays the self assessed tax amount in a column on the Invoice header and the validated invoice is ready for accounting.

Self Assessed Tax: Predetermined Set Up – First Party, Party Tax Profile:

•Enable Self Assessment on the Party Tax Profiles tab
•By checking the Set for Self Assessment/Reverse Charge option at a particular level, E-Business Tax returns applicable taxes for supplier invoices that fall within the level
–For example, if you enable this option at the Registration – Regime level, all invoices to be taxed within that regime will be considered Self Assessed tax

You can also set up a particular supplier’s Party Tax Profile by doing either of the following:
•Use the Tax Managers responsibility to query a Third Party
•Navigate to the Tax Details page from the Supplier (Entry) pages from the Payables Responsibility

Implementation Considerations:
E-Business Tax is a common module available with Oracle Financial Applications.
•The E-Business Tax engine is responsible for calculating tax amounts applicable to invoices.
•It also assists in automatically identifying taxes as self assessed and allows setting options for manual determination.
Subledger Accounting is also a common module available with Oracle Financial Applications.
•Subledger Accounting is not specific to this feature but a general tool to configure accounting entries and to provide accounting reports to meet your needs.

Assets related enhacements to Oracle AP in 12i

•Enhanced Asset Tracking - R12 provides the ability to track attributes of an item, such as manufacturer, serial number, from Purchasing through Accounts Payable to Fixed Assets. This increases processing efficiency and eliminates manual updates in FA that may have been required in the past.
–Item Description
–Manufacturer
–Model
–Serial Number
–Warranty Number
•Enhanced Mass Additions
–Asset Book
–Asset Category
–IPV/ERV distributions

Enhanced Asset Tracking Benefits:
Increased Efficiency and Reduced Costs
•Asset information typically entered on a purchase order, such as manufacturer, serial number, and model number, can now flow seamlessly into Payables and Assets.
Improved accuracy of information
•The Create Mass Additions process can now be submitted to select only those invoice distributions with a specific Asset Book, reducing the possibility of errors that need to be manually corrected.

Enhanced Asset Tracking Process:
•Enter or import a Payables Invoice and Match to Purchase Order.
•Payables retains the asset information.
•Optionally, update asset information on the invoice line or distribution.
•Submit the Create Mass Additions Process to transfer the Assets.

Invoice Lines:
Oracle Payables incorporates Invoice Lines into the invoice model. Adding Invoice Lines is a key architectural change, which enables Oracle Payables to better model the paper or electronic business document yet maintain key features that exist at the invoice distributions level.

Merged into the current invoice transaction business flows, Invoice Lines support the representation of the goods or services as well as tax, freight, and other charges as lines with distributions tied to each line. Additional fields record attributes such as serial numbers and item descriptions.

This feature offers the ability for line level approval and matching between an invoice line and a purchase order shipment pay item, or receipt. Furthermore, it facilitates the capture and transfer of additional, pertinent information to and from Oracle Projects and Oracle Assets.

Deferred Recoverability feature of AP in 12i

Deferred Recoverability:

Deferred Recoverability refers to an accounting process where tax recovery is reported when the invoice is paid. The accrual (and therefore the settlement and/or reporting) of recoverable taxes is delayed due to special tax rules either enforced by the Tax Authority, or allowed with the agreement of the Tax Authority.

Features:
•Accurate reporting and accounting of pending recoverable tax amounts for the recoverable portion of the tax.
•When payment is made, whether fully or partially, the corresponding tax is automatically recorded as recoverable and reversed from the interim recoverable account.

Benefits:
1. This feature allows you to meet the challenge of adhering to local tax laws that require deferred recoverability whether you need this feature now or plan to expand into new, international markets in the future.
2. Streamlined operations and operational excellence both contribute to lower costs. Automatic accrual means less time spent accruing accounts manually, providing better control over accounting and reducing the propensity for manual errors.
3. Fiscal Discipline is improved as General Ledger accounts reflect transactions that have occurred and automated accounting reduces auditing time

Deferred Recoverability Process Part 1: Set Up and Invoice:
You must first configure E-Business Tax Service for deferred recoverability and optionally tailor the Subledger Accounting definition if needed for accounting.
•During Invoice Entry, Validation, and Import, Payables gathers information known as tax drivers that are entered on the invoice header and lines and passes that information to the new e-Business Tax module.
•Based on these tax drivers and additional information derived by e-Business Tax such as the supplier’s party tax profile and buyer’s and supplier’s tax registrations, the engine determines the applicable tax, returns both recoverable and non-recoverable amounts and, in the case of deferred recoverability, the interim tax General Ledger account for recoverable taxes.
•Payables displays the tax amount in a column on the Invoice Header and in the Summary region, creates the tax lines in the Lines tab, and records the Distributions including the interim recoverable tax account.
•When the Invoice is Accounted, the interim recoverable tax account is posted to General Ledger.

Deferred Recoverability Process Part 2: Set Up and Payment:
At payment time, Payables determines if the invoices being paid are subject to deferred recoverability. If so, Payables requests the distribution accounts for the recoverable tax from E-Business Tax.

Payables determines how much is recoverable based on how much of the invoice is paid, then records the amount and corresponding distribution account.

When the payment is accounted, the interim recoverable tax account is reversed and the recoverable tax is posted to General Ledger.

Setup Taxes with Deferred Recoverability:
•Responsibility: Payables
•Navigation: Setup > Tax > E Business Tax Home > Task List > Task Configuration > [Tax Regime, Tax, Tax Status, Tax Rate] > Create > Controls and Defaults > Allow Tax Recovery
To enable taxes with deferred recoverability, enable the Allow Tax Recovery and the Default Recovery Settlement options at the Regime, Tax, Tax Status, or Tax Rate levels. Set the Default Recovery Settlement option to Deferred.
In addition, when you set up a Tax with deferred recoverability, ensure that you define the following Tax Accounts for that tax:
•Tax Expense
•Recoverable Tax
•Interim Tax (used only for Accrual Based accounting)
The default account for recoverable taxes in Subledger Accounting is Accounts Payable deferred. You can change this account if necessary.

Implementation Considerations:
E-Business Tax is a common module available with Oracle Financial Applications.
•The e-Business Tax engine is responsible for calculating tax amounts applicable to invoices.
•E Business Tax configuration qualifies taxes with attributes to meet tax compliance requirements
Subledger Accounting is also a common module available with Oracle Financial Applications. Subledger Accounting is not specific to this feature but a general tool to configure accounting entries and to provide accounting reports to meet your needs.

New Accounts Payable architecture for 12i

Suppliers in the Trading Community Architecture (TCA) :

The Trading Community Model:
•Is a highly flexible architecture
•Allows you to model real world entities in your trading community
•Allows you to accurately represent complex relationships among entities
•Is the core data model for trading partners used by Oracle E-Business Suite applications

TCA Security by Functional Areas:
A new user interface presents a clear distinction between the supplier’s company details and terms and controls for the trading relationship. Managing the attributes specific to particular functional areas such as Oracle Payables,
Purchasing and Receiving can be controlled with the use of Function Security.
•You can add new locations or relationships with additional operating units
•You can modify a quick update page with those values most often updated for faster maintenance
•Additional tax and legal registrations provide key information to meet reporting and compliance needs
The new supplier UI also includes a Survey section that provides administrators with access to the results of questionnaires that the supplier has been asked to complete, either during self-registration or as part of profile maintenance through iSupplier Portal. Purchasing Category assignments further designate the type of goods and services the supplier will provide.

Bank Accounts are:
•Centrally defined
•Managed and secured
•Include the legal ownership and operating unit access for each bank account

Supplier Bank Accounts:
The bank account is tied directly to the trading partner allowing one bank account definition to be leveraged by a ‘supplier’ trading partner and shared if the trading partner is also an employee or customer. This approach provides for easier and centralized maintenance and security of the bank account information.

This definition is targeted directly towards ‘trading partner’ bank accounts leaving internal bank accounts out of the user interface. In other words, the supplier’s banking information is entered and assigned right in the Supplier Entry and Maintenance user interface.

Collaboration with Suppliers to Resolve Disputes:

Holds on invoices that are a result of differences between the invoiced and planned amounts or quantity result in disputes that must be resolved. Invoices that have been approved by the owner of the purchasing transaction but rejected during the approval process may also be subject to disputes with the supplier.

Leveraging workflow notification, disputes are communicated and negotiations can be suggested to the Supplier. Suppliers are able to accept the suggested changes, withdraw their invoice, or submit their counter proposal. The negotiation continues until the issues are finally resolved. Suppliers can also negotiate online via iSupplier Portal. All changes and comments entered during the collaboration are tracked in Payables and can be viewed at any time.

Invoice Requests:

•Invoices entered by Suppliers via iSupplier Portal where a purchase order has not been obtained
•Are visible in Oracle Payables
•Are not paid or accounted until the invoice can be verified and approved

Whats new for Fixed Assets in 12i

I. Subledger Accounting Architecture:

•Oracle Assets is fully integrated with SLA, which is a common accounting platform for Sub Ledgers
•You can use the seeded Account Derivation definitions or modify them as required
•SLA supports Account Generator functionality for existing Asset Books
•Supports new SLA Accounting report and online account inquiry

Benefits:
The flexibility of the accounting rule setup allows meeting different requirements in different legislative, geographic or industry contexts within a single instance. Assuming operations in multiple countries, each with its own legal requirements and accounting standards, you are able to define a setup to meet each of the requirements. SLA allows for multiple accounting requirements for a single transaction or business event.

The accounting data that is generated is viewable and provides full auditability.

Subledger Accounting Process:
The process is executed as follows:
•Enter transactions in Oracle Assets
•Run the Create Accounting Program to process accounting.
•Inquire and drilldown from SLA Pages

II. Enhanced Mass Additions for Legacy Conversions:

• Many attributes have been added to the FA MASSADDITIONS interface table, including:
–Asset life
–Depreciation method
–Prorate convention
–Bonus rule Ceiling name
–Depreciation limit

• Oracle Web Applications Desktop Integrator (Web ADI) has been enhanced to support the following new columns:
–Depreciation Method
–Life in Months
–Basic Rate
–Adjusted Rate
–Prorate Convention
–Bonus Rule
–Depreciation Limit Type

Enhanced Mass Additions for Legacy Conversions Benefits:
You can use the mass additions process to convert data from a previous asset system. Instead of loading the asset information into multiple Oracle Assets tables, load it into the FA_MASS_ADDITIONS table. The Post Mass Additions process can then be used to move the asset information from the table to Oracle Assets. After placing your data in this table, you run the Post Mass Additions program to perform the data import.

III. Automatic Preparation of Mass Additions:

•Consist of default rules and Public APIs that can be used by customers to complete the preparation of mass addition lines automatically
•Auto populate required fields such as Expense Account, Asset Category, and others

Benefits:
The major benefits of this feature are that you can:
•Avoid manual intervention during the Mass Additions prepare process
•Avoid customization and use public APIs to effect custom business logic

To process mass addition lines:
1.Interface Mass Additions Lines from Accounts Payable or any other system
2.Run the Prepare Mass Additions Program
3.Optionally verify Mass Additions data
4.Post Mass Additions

Automatic Preparation of Mass Additions Setup Quickcodes
Set up the Rules to Prepare Mass Additions in Quickcodes:
•Use Default: The Asset Category is derived based on the Asset Clearing Account if there is a one to one match in the Asset Category setup. The Expense account is derived based on the Clearing Account by replacing the natural account segment from the Asset Category.
•Use Custom: The Prepare Mass Additions program will use the custom logic coded in the Public API
•Use Custom Energy: Energy industry specific custom rule.

IV. Flexible Reporting Using XML Publisher:

•Major Asset Transaction reports have been modified to support XML publisher
•You can customize report output by modifying seeded templates or by using new templates

XML reporting is available for the following asset reports:

•Asset Transfers Report
•Transaction History Report
•Asset Reclassification Report
•Mass Additions Create Report
•Cost Adjustment Report
•Cost Summary Report
•CIP Summary Report
•Reserve Summary
•Journal Entry Reserve Ledger
•Asset Additions Report
•CIP Capitalization Report
•Mass Additions Posting
•Asset Retirements

Set up Procedure:
1.Query up the concurrent program as system administrator
2.Change the output format to XML
3.Once the output is flagged as XML, submit concurrent request


V. Automatic Depreciation Rollback:
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, you can submit depreciation for the entire book prior to closing the period. If it becomes necessary to process financial adjustments on one or more assets, you 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 transactions to be processed normally. The assets for which depreciation was rolled back is automatically picked up during the next depreciation run or at the time that the depreciation period is finally closed.

Benefits:

1. It is no longer required to run depreciation rollback program manually.
2. Depreciation rollback is executed only on select assets as required and not on the entire Asset Book, thereby enhancing performance of the program.

12i Cash Management new features - PART 2

IV. Bank Statement Reconciliation – Description:

In Release 12, Bank Transaction Codes can be linked to multiple sources. Previously each bank transaction code had to be linked to a single source, such as Accounts Payable. This could create an issue if the bank was using the same transaction code to report back a payment that was initiated from an application other than Accounts Payable. In Release 12, you can link bank transaction code to as many sources as you would like and also assign a priority number used in the auto reconciliation for sequencing.

Reconciliation tolerances in Release 12 are moved from the system level to the bank account level. This means that each bank account can have a unique set or reconciliation tolerances. Moreover, there is now a distinction between tolerances for manual and auto reconciliation. Furthermore, auto reconciliation tolerances can be unique for each source – Accounts Payable, Accounts Receivable, Cash Management and Open Interface.

Finally, since now it is possible to use the same bank account, created in the centralized model, in multiple organizations, the bank statement reconciliation is also done across Operating Units.

Bank Statement Reconciliation - Benefits:
The enhancements for the Bank Statement Reconciliation process allows you to improve efficiency. By having granular level reconciliation tolerances and the ability to cross operating units, you will increate straight-through processing success rate of the auto reconciliation.

Setup:
•Now part of bank setup
•Transaction Codes
–Assign a transaction code to multiple transaction sources
•Account Controls
–Reconciliation control parameters

V. Multi-Org Access Control and Security:

•Provides bank account maintenance security.
–Privilege to create and update bank accounts that belong to the legal entities that the user can access
•Provides bank account access security.
–Bank Account Access Cash Management Security Profile: Which organizations the user can access. Sets:
—Bank Account use
—Treasury security
—MOAC security
—Payroll security

Benefits:
•Reduced Costs: Enable shared services centers and cut down processing time.
•Improved Efficiency: Easily access data from different operating units.
•Improved Security Control: Explicitly grant access to specific users for specific purposes.

VI. Cash Pooling:

Cash leveling or Cash Pooling is a cash management technique aimed at optimizing the balances of the internal bank accounts held at one or several banks. It is usually performed on a daily basis and can be done by transaction or by total net end-of-day balances. To perform cash leveling, you need to define a cash pool and assign internal bank accounts setup in Oracle Treasury to the cash pool.

Creating Cash Pools:
•Notional Cash Pools:
–Consist of one concentration account and multiple sub accounts
–Are used for cash leveling similar to zero balancing without the actual funds movement
•Physical Cash Pools:
–Consist of one or two concentration accounts and multiple sub-accounts with funds transfer rules specified
–Are used for cash leveling wherein you can initiate fund transfers or mirror outsourced cash pools

Viewing and Updating Cash Pools:

•You can view cash pool information as follows:
–Search for the cash pool name
–Click on the cash pool name in the Search and Results page
•If you have the appropriate user security, you can update the cash pool

12i Cash Management new features - PART 1

I. Bank Account Balances and Interest Calculations:

In prior releases, bank account balances were only available as a part of the bank account statement. The bank account interest calculation was only available for bank accounts set up in Treasury. In Release 12, the functionality to keep track of the multiple bank account balance types and calculate accrued interest is available to all internal bank accounts set up in the centralized bank account model.

Not only can you enter the balances manually, but also you can import them automatically at the same time when the bank statement is imported. In addition to the actual historic balances, you can keep track of the projected balances. Such balances can be entered manually or copied over from the Cash Position. You can then create reports that will compare the actual balances versus projected, and you can accomplish it in either an onscreen report or via XML Publisher. Finally, to simplify the bank account interest calculation, you can create reusable interest rate schedules that will contain the interest rates and other interest calculation parameters. Interest calculation features will work not only for stand-alone bank accounts but also for the notional cash pools as well.

Bank Account Balances and Interest Calculations - Benefits:
The new bank account model allows you to view bank account balances independent of the bank statement, calculate accumulated interest on the fly, and create customized balance reports.

Bank Account Balances and Interest Calculations Maintenance:
Once you have defined your bank accounts in the centralized bank account model, query them in the bank account balance page and manage historical or projected amounts.

Bank Account Balances and Interest Calculations Setup:
To obtain a balance report, create a report layout or a view and generate a report based on that. To calculate interest on the bank account balance, create the interest rate schedules, tie them to the bank accounts and use the interest calculator page to view the accumulated interest.

II. Bank Account Transfers:

In Release 12, you are able to create bank account transfers in Cash Management. The transfers can be initiated, approved, settled and accounted for. The settlement is done through the Payments application, while the accounting is done though the Subledger Accounting engine.

Bank Account Transfers Description:
Bank Account Transfers can be created manually by the user in the system. In addition, if there are any physical cash pools defined in the system, the transfers can be created automatically when the cash leveling process is run or when a bank statement with ZBA sweep lines is processed.

With manual transfers, you have the option of creating and using a payment template. The template will default the transfer information, such as the source and destination bank accounts, currency, and payment method, and can be used in the same fashion as a repetitive or semi-repetitive wire template created by your bank.

In cases when the settlement of the bank account transfer does not have to be initiated by the system (for example, for ZBA bank account transfers that the bank processes on its own), there is an option to exclude such a transfer from the settlement process and only create the accounting entries.

Finally, the UMX security model lets you define who can create bank account transfers for which legal entities. The settlement authorization function is also separate from the transfer creation, so you can implement the separation of duties for bank account transfer management.

Bank Account Transfers - Benefits:
The bank account transfer functionality enriches the Cash Management functionality so that you could take action on the projected closing balances calculated by the system. The seamless integration with the Payments application allows you to send payment instructions to the bank in a variety of payment formats and the integration with the Subledger Accounting allows you to use flexible journal creation rules.

Bank Account Transfers Process:
•Responsibility: Cash Management
•Navigation: Cash Management > Bank Account Transfers
Once the setup is in place, you can start creating the bank account transfer. If the system parameter requires authorization, the bank account transfer must be authorized before it is available for settlement or journal creation. Otherwise, you can proceed to settle or journalize the bank account transfer immediately after creation and validation.

The Payments application formats your payment request and sends it to the bank. Any exceptions in the payment process are communicated back in the form of an error status. If settlement of the bank account transfer errors out, you can see the reason so that the cause of the error can be rectified and the bank account transfer recreated. If the payment is processed without any exception, you see a successful payment status returned.

The subledger accounting process creates journal entries according to your setup and you can drill down to view these journal entries.

Bank Account Transfers – Dependencies and Interactions:
The bank account transfer feature depends on Payments application in cases where the settlement of the bank account transfers is required. There is also a dependency on the Intercompany setup when funds are transferred between different legal entities. Finally, all of the accounting activity for bank account transfers happens in the Subledger Accounting framework.

Bank Account Transfers Setup:
•Responsibility: Cash Management
•Navigation: Setup:System Parameters > (T) Cash Management Transactions
If you are using the cash leveling or ZBA features, the setup starts with the new system profile. Then, optionally, you can set up Transaction Subtypes and Payment Templates for bank account transfers. The Payment Templates are required if you intend to send the payment instructions to the bank to process the bank account transfer. The Transaction Subtypes are optional and can be used for reporting purposes.

Bank Account Transfers Setup – Set System Profile:
The new system profile option CE: Bank Account Transfers defines where the cash transfers will be created as a result of the cash pool activity. If you choose Cash Management, then the cash transfers created by the cash leveling or ZBA sweep activity are created in Cash Management using the Bank Account Transfer framework. If you choose Treasury, then these cash transfers are created in Treasury using Inter-Account Transfers (if both bank accounts belong to the same legal entity) or Intercompany Funding transactions (if bank accounts belong to different legal entities). Before Release 12, Bank Account Transfers could only be created in Treasury. This functionality is preserved but now you have a choice.

III. Subledger Accounting:

Subledger Accounting provides a common flexible framework for creating journal entries for Bank Account Transfers and Bank Statement Cash Flows in Cash Management. Prior to Release 12, Cash Management produced journal entries for bank statement activity based on simple rules and sent them to the General Ledger interface. In Release 12, in addition to the bank statement activity, a new source of accounting entries is available – bank account transfers – and the rules for journal entry creation are more flexible and sophisticated. Finally, you can now view all the journal entries produced by Cash Management events in Cash Management.

Subledger Accounting for Cash Management:
In Cash Management Release 12, bank account transfers and bank statement cash flows are the two objects that can produce accounting events. Once the events are created and the accounting program is run, the journal entry setup and the accounting configurations are referenced to produce journal entries. The journal entries are then transferred to GL. GL has visibility into the source transactions and Cash Management users can drill down from the transaction level to the journal entry details.

Subledger Accounting - Benefits:
The Subledger Accounting feature allows multiple accounting representations for a single business event, resolving conflicts between corporate and local fiscal accounting requirements. In addition, with subledger accounting you retain the most granular level of detail in the journal entries, with different summarization options in the General Ledger, allowing full audit and reconciliation

Subledger Accounting Key Concepts :
Here are some key subledger accounting concepts:
•Event model is defined in SLA for each subledger represents the transaction/document types and the lifecycle of each transaction:
-Event class classifies transaction types
-Event type defines possible actions on each event class with possible accounting significance.

The journal creation rules are defined per event class/event type. In Cash Management, there are two event classes: Bank Account Transfer and Bank Statement Cash Flow. An accounting event for a Bank Account Transfer, for example, would be the creation or cancellation of a bank account transfer. So, any time a bank account transfer is created, an accounting event is created as well. Based on the rule setup, there may or may not be a resulting journal entry. You may set up rules to generate journal entries for some events, but not for others.

Transaction object and sources are the data model for each subledger that contains the transaction attributes/information made available to be used during journal rule setup and journal entry generation.

Bank Account Model in Release 12i

Here is a summary of the new features introduced by 12i in the area of Bank Account Model:

Bank Account Model Definition:
The new bank account model allow you to define and keep track of all bank accounts in the e-Business Suite in one place and explicitly grant account access to multiple operating units/functions and users. Bank accounts for internal use in Cash Management, Payables, Receivables, Treasury and Payroll are consolidated in Release 12. If you were using internal bank accounts in prior releases, all bank accounts will be migrated into the centralized bank account model automatically during the upgrade.

UMX-based Security:
The CE UMX Security Wizard is available under the User Management (UMX) responsibility. The wizard helps you quickly define the legal entities available for a role. To launch the wizard, log in as System Administrator, then in the User Management responsibility, go to Roles & Role Inheritance.

Bank Account Model Interaction :
In previous releases, Oracle Accounts Payable owned banks, bank branches and bank accounts. Such bank accounts could also be used by Accounts Receivable. Payroll and Treasury, however, had their own bank account models. In Release 12, banks and bank branches are created as Trading Community Architecture parties. The bank accounts are associated with Bank Branches but reside within the Cash Management application. During the bank account creation, you will be able to define in which applications this bank account can be used.

Bank Account Model Benefits:
The new model reduces the number of access points to manage bank accounts by providing a centralized user interface where all internal bank accounts can be set up. Bank account access in the new model can be granted to multiple operating units, thus eliminating the redundant duplicate bank account setup under different operating units in case these operating units share the same bank account. This simplifies the reconciliation process since now one bank account is the system corresponds to one bank account at the bank.

Cash Management Security Components:
Set up security for access to Cash Management activities by using components from different applications. The specific steps required to secure access to your bank accounts depend on the type of access you want to secure, the applications that you use for your business, and your organization structure.
•Use the CE UMX Security Wizard to grant a role (responsibility) the ability to perform bank account activities in the following areas:
-Use: View bank statements, reconcile cashflow transactions, work with cash forecasting, cash positioning, and cash pools
-Maintenance: Create and update bank accounts
-Bank Account Transfers: Transfers funds from and to internal bank accounts.
•When creating bank accounts, specify the legal entity that owns the account and the organizations that the account is used for (Payables, Receivables, Treasury, Payroll).
•Create security profiles to define the list of organizations that a user can access. Set up security profiles in the following applications as needed:
-MOAC: to define the list of operating units a user can access for Payables and Receivables and be able to reconcile AP and AR bank statement lines.
-Cash Management: to define the list of organizations a user can access to reconcile cashflow transactions. This security profile also allows users to access bank accounts for cash forecasting, cash positioning, and cash pools if no other security profiles are set up.
-Treasury: to define the legal entity that the Treasury user can access and be able to reconcile Treasury bank statement lines.
-Payroll: to define the business groups a user can access and be able to reconcile payroll transactions.

Bank Account Model Setup and Process:
•Responsibility: Cash Management
•Navigation: Setup:Banks > Banks
The key setup steps are:
•Define Banks in Oracle Cash Management.
•Define Bank Branches in Oracle Cash Management.
If you intend to use this bank account in Oracle Treasury as a company bank account, switch to that application, define Bank Counterparties and link them to Bank Branches that you have created. If you do not intend to use this bank account in Oracle Treasury, skip this step and proceed straight to the Bank Account definition.
At this point the system verifies your privileges for bank account maintenance. If you are authorized to maintain bank accounts for this legal entity, you will be able to create your Bank Accounts in Oracle Cash Management.
If you do not intend to use this bank account in Payroll, then the setup process is complete for you. If you intend to use this bank account in Payroll, switch to that application and add this bank account to the organizational payment method.

Implementation Considerations:
The bank new account model has several dependencies on other applications and centralized features.
•There is a dependency on the Trading Community Architecture because this is where the banks and the bank branches are stored.
•The organizational hierarchy comes from Human Resources.
•Finally, the General Ledger accounts that are assigned to the bank accounts are defined in General Ledger.
•If you are using Payroll or Treasury, then the bank account set up depends on those applications as well.

Implementation considerations for R12 General Ledger setups

Many clients ask for best practices and implementation considerations for implementing a new GL in 12i, here are some important implementation considerations:

Chart of Accounts:
–Share the same value set for the balancing segment across charts of accounts

Determine the Number of Legal Entities to Assign in an Accounting Setup based on:
–Statutory and legal requirements for legal entity accounting, such as document sequencing, tax accounting, and intercompany accounting
–Business Needs

Types of Accounting Setups:

1. Accounting Setup with No Legal Entity (LE)
–Can be used for GL only implementations
–Used for a business need where no legal entity is required or management reporting
–Cannot maintain legal entity context in subledger transactions
–Cannot set up Operating Units
–Cannot use Advanced Global Intercompany Accounting System

2. Accounting Setup with One LE
–Cannot perform lump sum payments across legal entities in AP

3. Accounting Setup with Multiple LEs
–Cannot perform autonomous document sequencing and tax that is unique per legal entity
–Consider local laws that prohibit commingling transactions with multiple LEs

Choosing the Ledger to be the Corporate Representation:

Best practice is to choose the primary ledger to be the corporate representation in the local currency:
–Provides the most detail
–Allows you to assign a subledger level reporting currency if you want to maintain a detailed additional currency representation
–Note: Secondary Ledgers cannot have subledger level reporting currencies assigned

Legal Entity (LE) Accounting:

1. LE above Ledger
–If you require multiple primary ledgers to perform accounting for the same legal entity, you must create dummy legal entities because a legal entity can only be assigned to one accounting setup, not multiple accounting setups

2. LE = Ledger
–If legal entity equals the primary ledger, you may choose not to assign balancing segment values to the legal entity

3. LE Below Ledger
–Legal entities should be represented by one or more balancing segment values

Balancing Segment Value (BSV) Assignment:

1. No BSVs Assigned = All values available for data entry
2. Assign specific BSVs to LEs at any time
3. Behind the scenes, BSVs assigned to LEs are automatically assigned to the ledgers
4. No BSV validation performed across accounting setups
5. BSV assignment is required for Intercompany Accounting
6. Optionally assign BSVs to the ledger for non-legal entity related transactions, such as management adjustments
7. Before BSVs can be assigned to the ledger, they must be assigned to LEs first, if used

Reporting Currencies (RC):

1. Journal and Subledger level RCs act like regular ledgers
2. To automatically populate historical data, run the Create Opening Balance Journals in Reporting Currency program.
3. Conversion for subledger sources that uptake SLA are disabled for Subledger Level SLs
4. When posting a journal to the PL, journals for the RC will be automatically created/posted in the same batch
–Ensure same open periods for source ledger and RC
5. Data access set should include same write access to source ledger and RCs to prevent posting errors

Subledgers that uptake SLA (Assets, Budget Execution, Cash Management, Cost Management, Inventory, Oracle Loans, Payables, Payroll, Property Manager, Purchasing, and Receivables)

Secondary Ledgers (SL):

1. Can be added at any time with an unlimited number allowed
2. To populate historical data, use Consolidation (GCS)
3. Secondary Ledgers cannot have Subledger Level RCs assigned
4. COA Mapping required if COAs are different between the PL and SL
–COA Mapping can be used if the COAs are the same except for Subledger Level SLs
5. Conversion for subledger sources that uptake SLA are disabled for Subledger Level SLs

R12 Multi-Org Access Control - Preferences

Multi-Org Access Control Preferences - Description :

Multi-Org Preferences allows you to control the list of operating units to which you have access. For example, a system administrator may create a security profile that has ten operating units assigned to it and assign it to your responsibility. But, you may only deal with five of the operating units on a daily basis and do not want work space cluttered with extraneous operating units. You could set up Multi-Org preferences to restrict the list of operating units; you have complete control over this and can change it at anytime. In addition, you can specify a default operating unit.

Multi-Org Access Control Preferences - Benefits:

•Increase Efficiency
–Save key strokes with default operating unit
–Limit access to operating units you use most
•User Level Control
–Eliminate using System Administrators; you can control your own access
•Reduce cost
–Perform processes quicker


Multi-Org Access Control Preferences Setup:
Most products have added the Preferences user interface to their responsibility menus. You can select preferred operating units which represent a subset of operating units assigned to your responsibility’s security profile. You can also set a default operating unit.


Multi-Org Access Control Preferences – Setup – Add to SubMenu:

To enable and display Preferences in your menu
1.Request that your System Administrator to add the function FNDMOPREFS to your menu definition
•The System Administrator should use either the System Administrator or Application Developer responsibility, and select the Menu (Application) option
2.Select your product’s menu and add the function named User Preferences (FNDMOPREFS)


Multi-Org Access Control Preferences – Setup – Set Preferences:

Multi-Org Preferences page:
•The header displays:
–The user name that you are logged in as
–The responsibility name
–The Security Profile that you are currently assigned to
•The Default Operating Unit region is where you select a default OU.
•Preferred Operating Units is where you select the subset of operating units you want to work with.

R12 Multi-Org Access Control - Setups

Multi-Org Access Control Setup:

•Responsibility: Human Resources
•Navigation: Security > Profile
In Release 12, when you define your security profile in HR using the Security profile form or the Global Security profile form, you must:
•Assign all of the operating units that you want a responsibility to access. Run a concurrent request called “Run Security List Maintenance” from HR which makes those security profile available and allows you to assign them to a responsibility via a profile option called MO: Security Profile.


Multi-Org Access Control – Setup – Create Operating Unit:
•Responsibility: General LedgerNavigation: Accounting Setup Manager > Financials : Accounting Setup : Accounting Setup Manager

•Responsibility: Human Resources:Navigation: Work Structures : Organization > Description
In Release 12, you can define your operating units in two places. You can continue to define them in the Oracle HRMS Organization Form or you can define them in the new Accounting Setup Manager feature in General Ledger.

The Accounting Setup Manager streamlines the setup and implementation of Oracle Financial Applications. It centralizes the setup and maintenance of common financial components, such as legal entities, operating units, and ledgers. So when you create an accounting setup, assign a legal entity and create the ledgers that will perform the accounting for that legal entity, you can also define and assign the relevant operating units. By leveraging Accounting Setup Manager to define your OUs, you can streamline your setup.

In R12, is instead of attaching an OU to a LE, you assign it to a default legal context. All Release 11i HR Organizations classified as “Operating Units” will be preserved in Release 12. If operating units are assigned to a set of books, then they will be associated to a primary ledger in an accounting setup. You will be able view all operating units assigned to an upgraded primary ledger using Accounting Setup Manager.


Multi-Org Access Control – setup Define Security Profile:
•Responsibility: Human Resources
•Navigation: Security : Profile or
•Navigation: Security : Global
Using Oracle HRMS, you can define your security profile using two forms:
•The Security Profile form, which allows you to select operating units from only one Business Group
•The Global Security Profile form, which allows you to select operating units from multiple Business Groups

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 multiple operating units.

Multi-Org Access Control – Setup – Run System List Maintenance:

•Once the security profile has been created, run the Security List Maintenance program.
–This ensures that all of the security profiles that you created are available for assignment to your responsibilities.


Multi-Org Access Control – Setup – System Profile Options:

•The MO Security Profile controls the list of operating units that a responsibility or user can access. If you set the security profile at the responsibility level, then all users using that responsibility will have access to only the operating units available in the security profile. If you set the security profile at the user level, then the user will have access to only those operating units, irrespective of application responsibility that they log into.

•The MO: Default Operating Unit is optional and allows you to specify a default operating unit that defaults when you open different subledger application pages. Because you can access multiple operating units, you may want to set up a default one instead of forcing users to constantly have to choose one. User Preferences allows you to specify a default operating unit at the user level. Use the MO: Default Operating Unit profile option to set the operating unit context or default operating unit when accessing an applications.

•The last profile option is for backwards compatibility and to support products that do not use Multiple Organizations. The release 11i setting was for this is preserved during upgrade. The Release 11i MO: Operating Unit profile option is supported in Release 12 as not all customers of Oracle products require multiple organizations.

Implementation Considerations:

•Oracle HRMS
–Define operating units
–Set up Multi-Org Security Profiles
•Accounting Setup Manager
–Define operating units
–View all operating units assigned to the primary ledger
•Oracle E-Business Suite Products that Use Operating Units
–Process data across multiple operating unitsusing Multi-Org Access Control

R12 Multi-Org Access Control - features and benefits

Multi-Org Access Control - Description:

In 11i, when users had to enter or process data for multiple operating units, they had to login to different responsibilities because each responsibility could only access one operating unit. So if there were a centralized payment processing center where users processed payments for multiple organizations, they would have to keep logging in and out of different responsibilities to process payments for a different organization or operating unit.

Now in Release 12, Multi-Org Access Control enables companies that have implemented a Shared Services operating model to efficiently process business transactions by allowing users to access, process, and report on data for an unlimited number of operating units within a single application’s responsibility.

This increases the productivity of Shared Service Centers as users no longer have to switch application responsibilities when processing transactions for multiple operating units. Data security and access privileges are still maintained using security profiles that will now support multiple operating units.

Multi-Org Access Control - Example:

For example, if you have three operating units in the center you were managing, such as a Belgium Operating Unit, a Holland Operating Unit, and a Denmark operating unit, in 11i you needed to define three different responsibilities. If you had one user who processed payables invoices across all three operating units, then you would need to assign the three responsibilities to that user and then the user would need to log in and out of each responsibility to process invoices.

In Release 12, you can create a Security Profile and assign as many operating units as you want to that security profile. So in this example, you could assign all three operating units to the same security profile. Then, you can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA Payables responsibility to allow that responsibility to process invoices across all three operating units.

Processing payables invoices is just one example, with Multi-Org Access Control, you can efficiently perform other processes, such as processing receivables invoices, viewing consolidated requisitions, performing collections using Advanced Collections, and process receiving and drop shipments.

MOAC - Benefits:

•Improve Efficiency
–Process data across multiple OUs from one responsibility
–Process transactions more efficiently for companies that have centralized business functions or operate Shared Service Centers
•Obtain better information for decision making
–Obtain a global consolidated view of information
–View information, such as supplier sites and customer sites across multiple OUs
•Reduce Costs
–Speed data entry
–Reduce setup and maintenance of many responsibilities


Multi-Org Access Control Process Summary:

Each Financials product team has implemented MOAC to best suit their business process flows. For example, in AP, there’s a new operating unit field on their Invoice Workbench. The OU list of values reads from the Security Profile assigned to the responsibility to determine which OUs should be displayed in the LOV. In general, when a user logs in to a responsibility and opens an application, the application will determine which operating units can be accessed and used for processing. The user can then view or process transactions for multiple operating units.

R12 Financials Overview and new features at a glance (PART 2)

Oracle E-Business Tax (eBTax):
consists of a tax knowledge base, a variety of tax services that respond to specific tax events, a set of repositories (for tax content and tax recording) that allow customers to manage their local tax compliance needs in a proactive manner, as well as the ability to integrate with external tax content providers through a single integration point.


Advanced Global Intercompany System:
•Addresses the Top Barrier to a Fast Close
•Generates subledger invoices
•Controls transaction entry with Intercompany Calendar
•Has a Fully Configurable Approval Rules
•Has a Flexible Security Model
•Has a Centrally defined Intercompany Accounts


Centralized Banking:
•Bank account is now associated with the LE instead of the Operating Unit
•A single bank account serves multiple Operating Units
•Any and all Operating Units associated with a ledger can be permitted to use the bank account
•There is a centralized Credit Card Model
•There is Credit Card Encryption
•The Supplier & Customer Banks are in TCA

Multi-Dimensional Analysis & Reporting:
•In product row/column UI or within a Spreadsheet
•You can create the following reports & graphs:
– Historical
– Current
– Projected data
•You can analyze performance:
– Detect trends
– Define
– Variance
– Thresholds
•Receive auto-alerts

Financial Consolidation Hub:
R12 includes interactive spreadsheet reporting with live drill down to transactions


XML Publisher:
Enables you to format, manage, and deliver documents
•Meets business requirements such as:
-Removes complexity
-Reduces maintenance cost
-Reduces TCO
•Integrated with: R9 CRM, ESA, FMS, HCM, and SCM

New Standard Reports:
•Uses XML Publisher
•835 Templates are available
•Merges custom templates and data extracts at run-time
•Delivers output in PDF, HTML, RTF, Excel (HTML), or text for use with EFT and EDI transmissions
•98 Global reports have been replaced with 19 Extracts, 86 Templates

Other new features:

•Live AR-Inventory. Revenue-COGS Match
•Deferred COGS and Revenue Automation
•Advanced collection, Dunning, Loans
•Invoice Lines
•Suppliers in TCA: one setup per partner
•Supplier, users invoice self service
•Straight through processing (STP) at banks
•Per diems, approval enhancements
•Expense Bar Codes
•Self Service receipt matched invoices
•Real time contract T&Cs in PO, AP
•Asset Automatic Depreciation Rollback

R12 Financials Overview and new features at a glance (PART 1)

Why R12:

Release 12 is defined as “The Global Business Release.” Global is not just a geographic perspective, but also a comprehensive perspective; release 12 functionality spans across both industries and business functions.
•Flexible, centralized, global accounting structure
•300+ enhancements to best practice business processes
•Comprehensive governance, risk and compliance platform
•Truly integrated performance management
•Real-time profitability analysis
•Unified financial and operational analytic applications
•Integration with core industry applications
•Self-service report formats and publicationSuperior ownership experience

New architecture and benefits:

The major components of the new architecture include:
•Multi-Org Access Control
•Ledger and Ledger Sets
•Subledger Accounting
•Tax Engine
•Intercompany
•Bank Model

Benefits of the new architecture include:
•Maintain 1 Ledger with 1 OU for each Company (LE)
-Get privacy for each company’s data
-Manage each company’s national and local compliance
•Combine many companies’ ledgers in a set
-Share GL services and workload
-Get combined data
•Use MOAC to enable access to many OUs
-Process in and report across many Companies’ Operating Units


MOAC: Multi-Org Access Control:
MOAC provides role based access to Operating Units, and allows you to perform multiple tasks across operating units without changing responsibilities.


Subledger Accounting:
Subledger accounting provides centralized rules and a common repository, and global control of your accounts. Features include:
•Accounting Rules
-SarBox & 8th Dir.
-User Editable
•Subledger Daybooks (Journals)
•Subledger Balancing
•Reports, inquiries, open items, et cetera
•Multiple Representations
•Common Posting to GL Ledgers
•Real time or Periodic

Benefits of subledger accounting are:
•Faster, Easier Reconciliation
•Corporate Rules = Accounting Standardization
•Local Rules = Improved Local Compliance
•Automate “Apples to Apples” Adjustments
•Improved Audit- ability
•Improved Internal Control

Ledger:

•One Repository of Financial Truth
•Implements the 4 C’s:
–Chart of Accounts
–Currency
–Calendar
–Accounting Convention
•Example:
–The balance on Creditors (COA)
–is 4.2M Eur (Currency)
–on March 31, 2006 (Calendar)
–according to IAS/IFRS definitions (Accounting Convention)


Ledger Sets:
Ledger sets provide global information at a glance. Ledger sets share a chart of accounts and a calendar. The key benefits to many Ledgers in one set are:
•Decision-driving business information always available
•Simpler processing and General Ledger management
•Data and definitions that can be shared and secured


Ledger Architecture:
Typical Ledger Sets:
•All IAS/IFRS or US GAAP ledgers
•26 Subs in 1 country
•35 countries in 1 region


Legal Organization:
Legal Entities (Les) such as Parent companies, own or control subsidiaries. There are no group entities
•LEs pay the taxes and therefore need tax registrations
•Trade between LEs needs intercompany
•LEs own the money and bank accounts
•LEs file the accounts and take care of accounting
•LEs comply with whatever needs compliance: “legal” in LE


Enhanced Legal Support:
•Did not replace GRE/LE - employer
•Added TCA parties for the Authorities
•Added a Legal Entity Configurator
•Introduced the following new terms:
-Jurisdiction: A legislative category and territory, has legal rules
-Legal Authority: Legal body who enforces legislation, collects fees / taxes, etc
-Legal Function: Functions that companies are required to perform (e.g. produce yearly report, pay taxes, etc.)
-Legal Associations: Mapping companies to Ledgers, BSVs, OUs and other system entities


Examples of using Legal Entities:
•Accounting Setup Manager: Assign books, bookkeeping rules and currency management to your registered companies
•EBusiness Tax: Have your registered companies calculate, file, and pay the transaction taxes they owe
•Intercompany: Do business between and across your registered companies with full legal documentation
•Bank Model: Have your registered companies use their money to pay their bills, etc.