The SLA diagnostic framework provides features to review the journal entries created by the Subledger Accounting program. It provides the input data used for each transaction, such as the following:

• Transaction objects
• Ledger information
• System sources
• Source values

In order to do a SLA Diagonostic, you have to do these steps as pre-requsite;

• enable profile option: SLA Enable Diagnostics to Yes
• run Create Accounting program which then also populates the diagnostic tables.
• run Transaction Objects Diagnostics to view the diagnostic report.

SLA Enable Diagnostics

• Reset profile option: SLA Enable Diagnostics to No

• once done , run the System Administrator submits the Purge Transaction Objects Diagnostics concurrent request.

Hope this post helps in troubleshooting accounting error when you have deal with SLA.

Supporting References enables users to enter additional information for the journal entry header and lines that can be used for analytical purposes. This functionality was earlier known as Analytical Criteria. This enhancement was released in R12.0.3.

Business Benifits of Supporting references may be used as follows:

• To provide additional business information about a subledger journal entry at the header or line level
• To establish a subledger balance for a particular source value or combination of source values for a particular account
• To assist with reconciliation of account balances, and
• For financial and managerial analysis

The use of supporting references is optional, consist of these steps in order to use.

1. Define a Supporting Reference
2. Attach the Supporting Reference to the Journal Line Type (JLT)
3. Validate the Applications Accounting Definitions

In R11i, additional data was interfaced to GL on the journals using Descriptive Flexfields where as R12 With this, customers can create customized sources as Supporting References and pass values into those sources from Subledgers like AP/AR/PA etc. Supporting references (SR) are associated at the Event Class Level. These SRs are stored in XLA_AE_LINE_ACS and associated using ae_header_id/ae_line_num. This helps link back to XLA_AE_LINES records.

From XLA_AE_LINES, the link to GL is using GL_SL_LINK_ID and GL_SL_LINK_TABLE

For setup of Supporting References, there are 3 options

• Always: Supporting Reference Balances are maintained always on a specific Code Combination and it keeps on accumulating once it is defined. At the end of a Financial Period, the balances are carried forward as the opening balances for the next financial period.
• Based on Account: Supporting Reference Balances are maintained on a specific Code Combination & it gets accumulated till the end of a financial period. The closing balances of a Financial Period are not carried forward as the opening balances of the next financial period; rather the balance is rolled back to zero (0) at the beginning of the next financial period.
• Never: Supporting Reference Balances are not maintained for that Supporting Reference, it is only used as an additional reference attribute.
  When the Create Accounting program is run in the “Final” mode for any subledger, it spawns the program “Update Subledger Balances” internally and the balances are updated in the XLA_AC_BALANCES table.

Supporting References - What Tables for Analytical

Here are the list of table. If you have plan to do some custom reporting for Analytical for Opertional reporting you can understand the data model as per figure below.

• XLA_ANALYTICAL_ASSGNS
• XLA_ANALYTICAL_BALANCES
• XLA_ANALYTICAL_DTLS_B
• XLA_ANALYTICAL_DTLS_TL
• XLA_ANALYTICAL_DTL_VALS
• XLA_ANALYTICAL_HDRS_B
• XLA_ANALYTICAL_HDRS_TL
• XLA_ANALYTICAL_SOURCES
• XLA_EVENT_SOURCES

Supporting Refrence for Manual created Refrence

In R12, supporting references were introduced and the UI enables a user to However, the current version of manual journal creation API has not been supported to capture. Check it out with latest version of the code.

Manual Subledger Journal

A manual subledger journal entry is not associated with a transaction or document of a subledger application. When users create a manual subledger journal entry, it is created with the event class and event type Manual that is seeded automatically when the subledger application is registered.

Why Its Needed

Manual entries are typically adjustments in nature. If the adjustments are due to specific subledger activity such as Payables or AR or FA, then you may want to enter an SLA manual entry instead of a GL entry.

Such entries to recorded in SLA are tied the subledger source and therefore provided more accurate subledger accounting reporting.

You need to have account, debit, and credit amounts, and accounting class in Order to pass a manual entry. in case if you have to optionally enter third party information then description, and currency details for each line of the subledger journal entry is important.

Read the rest of this entry »

Oracle provides the ability to enter manual sub-ledger journals via a button on the SLA Journal Inquiry pages.

A manual subledger journal entry is not associated with a transaction or document of a subledger application. If you are considering using the manual SLA journal feature to represent accounting in legacy systems, you can take the advantage of API which allows you to import such transactions into SLA rather than into the GL directly (via the GL interface).

You can use the API XLA_JOURNAL_ENTRIES_PUB_PKG and any of these functions:

• Create_Journal_Entry_Header: This is used creates a new subledger journal entry header
• Update_Journal_Entry_Header: This is used to modifies an existing manual subledger journal entry header, if journal entry is not Final and GL_DATE used must belong to a valid accounting period.
• Delete_Journal_Entry:This deletes all information of a subledger journal entry including journal entry header and journal entry line
• Create_Journal_Entry_Line:This is used to Create the JE line
• Update_Journal_Entry_Line :This is used to Delete the JE line
• Delete_Journal_Entry_Line :This is used to Delete the JE line
• Complete_Journal_Entry: This is used to completes a subledger journal entry
• Reverse_Journal_Entry : This is used to reverse the entry.

These API's you can find more on Oracle Financial Services Accounting Hub Implementation Guide Release 12 Part No. B14420-01

You don't need to have an FSAH License to be able to use those APIs.

R12.1.1 and R12.1.2 SLA enhancements

When you create new sub ledgers for reporting currencies, a new concurrent program SLA Secondary/ALC Ledger Historic Upgrade is provided to initialise the historical transactions for proper reconciliation.

This program retroactively posts historical accounting data from primarly ledgers to the newly created secondary or reporting currency ledgers.

Read the rest of this entry »

What is GL Drilldown

GL Drilldown feature allows users to view sub ledger transaction information for the GL journal line created by importing information from the sub ledger products. Users are able to view sub ledger transaction information for different Products using the GL Drilldown feature by navigating to the Product UI that is the source of such transaction.

The Drill Down feature is invoked by Drill Down button on Journal Review screen. The Drill Down button opens XLA Drill Down UI. The UI shows product transaction and accounting information related to journal line.

This post is another extension of my previous post.

If you are starting Drilldown from General Ledger that will takes you SLA Journal details. Typically the flow is as:

1. Drilldown is performed from Journal lines in General Ledger, that means data is stored in the table GL_JE_LINES. The link between SLA data and data in GL is through the table GL_IMPORT_REFERENCES.
2. This data is populated in GL_IMPORT_REFERENCES only if "Import References"¨ option is selected in the Journal source definition.
3. Once Populated, the data can be mapped from GL_JE_LINES to GL_IMPORT_REFERENCES table using the columns je_header_id and je_lines_num.
4. From subledger side , SLA Journal line data is stored in the table XLA_AE_LINES, which is connected with its header which stored in XLA_AE_HEADERS.
5. Then data in GL_IMPORT_REFERENCES can be mapped to XLA_AE_LINES using the columns gl_sl_link_id and gl_sl_link_table.
6. When Transfer happen, typically it can be done either Summary or Detail mode, which typically configure when you define the Event Class, which is attached to the Journal Line Type.
   • Take a note, if the transfer is done in Summary mode, then the Reference columns will not be populated in any of these table GL_IMPORT_REFERENCES or GL_JE_LINES
7. Then Journal Line Type is then attached to the Journal Line Definition, which internally hookup with Subledger Accounting Method.
8. Data from SLA, which comes to GL_INTERFACE, can then be imported in either Summary or Detail Mode.
9. The option for summary or details is configure in the Accounting Setup Manager
10. If you are importing data in Summary mode, then the Reference columns are populated in GL_IMPORT_REFERENCES (provided data has come in Detail mode from SLA), while GL_JE_LINES will not have the Reference columns populated.
11. On the other hand if data is imported in Detail mode, both GL_IMPORT_REFERENCES and GL_JE_LINES tables will have the Reference columns populated (again provided the data has come in Detail mode from SLA).
12. Table XLA_AE_LINES Column gl_transfer_mode_code gives the information for the transfer mode from SLA to GL.
13. For the Journal Import mode, the values for specific applications is stored in the table XLA_LEDGER_OPTIONS which stores the setup for various applications for the Ledgers defined. The column indicating the Journal Import mode is transfer_to_gl_mode_code, which have three values as P (Summarized by Period), A(Summarized by Accounting Date) or D(No Summarization i.e. Detail mode)
14. The XLA_TRIAL_BALANCES table is populated after successful journal import.
15. You can use the different SLA reports for pulling SLA data.
16. Last but not the least, drilldown will work from GL to all the Subledgers that are using the SLA Engine

Do you know, In Release 12.1 Trade Management is now a suite of four products as below in a new product family called Oracle Channel Revenue Management that manages financially oriented channel processes.

1. Accounts Receivable Deduction Settlement
2. Advanced Rebates and Point of Sale Management
3. Price Protection [This is new product in R12.1]
4. Supplier Ship and Debit [This is new product in R12.1]

Adding these Products in Line of your Business will help you to :

• Decrease in Deductions DSO and improved visibility into all processes
• Improved Margins through process automation and accuracy with an integrated solution
• Increased productivity through automation of traditional spreadsheet managed processes
• Reduced revenue leakage

Typically these products are best suited for industry like High Tech, Life Sciences/HealthCare, Wholesale/Retail, that application are best suited if you are considering for "Invoice to Settlement" Business flow.

Lets have a brief introduction for these family products.

ACCOUNTS RECEIVABLE DEDUCTIONS SETTLEMENT

This provides a central repository of all claims and deductions to claim analysts, giving them easy access to the information they need to resolve claims quickly, and to give management full visibility into outstanding claims and deductions. It integrates resolution of deductions and claims with receivable systems and accounts payable and validates that the correct general ledger accounts are assigned. Properly approved claims automatically spawn payments and credits in Oracle Payables and Oracle Receivables.

Some of key functionality for this products are :

• Dispute/deduction handling
• Rebates Settlement
• Promotional Payments View
• Complete AR processing that means you get high visibility into aging buckets and total amounts outstanding
• Lockbox integration additional you have customer reason code mapping
• Auto-write offs
• Mass Settlements

This application is have Integration with Accounts Receivables, Accounts Payable, Order Management, General Ledger, Channel Rebate and POS Management ,Tax Engine and Oracle Collection.

Those who have high transactional volume of invoicing and disputes and currently using Oracle Financials and Order Management take take advantage of this products. This also help in order to meet your compliance regulations

ORACLE CHANNEL REBATE AND POINT-OF-SALE (POS)

Oracle Channel Rebate and Point-of-Sale Management provides functionality above and beyond that provided by Oracle Advanced Pricing for pricing scenarios including net accruals, retroactive pricing, complex volume pricing agreements, supplier ship and debit and the ability to update the correct general ledger accounts for all pricing situations including discounts. This is the only system in Oracle today that provides the correct accounting procedures for price reductions given on invoices. It also controls pricing in multi-tiered distribution.

This system addresses four critical areas related to the effective processing, POS data load, data validation & cleansing, dispute handling and Claims settlement.

ORACLE PRICE PROTECTION

Oracle Price Protection is a new module in Release 12.1 that provides distributors the ability to adjust and control their inventory valuations, purchasing costs and sales pricing based on pricing changes received from vendors. Price Protection automates the price protection processes when a vendor changes the price of a product and adjusts the GL records systematically.

More specifically, this product:

• Generates and tracks price-protection claims for both on-hand product inventory and customer product inventory
• Updates inbound prices lists and purchasing systems with new prices
• Updates costing and financial systems to reflect new prices and its execution can be done by
  • Providing consolidated view of inventory across WMS and TM (Channel inventory)
  • Calculating accruals and generate debit claims for vendors
  • Calculating accruals and issue credits for customers
  • Integrating with Oracle Costing to adjust Cost of Goods and Services (COGS)
  • Integrating with Oracle Purchasing to adjust inbound price list and purchase orders
  • Integrating with Oracle Pricing to update inbound price list with new price
  • Integrating with Oracle Financials to handle deferred revenue recognition

Price Protection leverages Oracle Fusion Middleware and has service-oriented architecture to allow for rapid deployment into heterogeneous environments. Price Protection is designed to work out-of-the-box with Oracle E-Business Suite

This product is Integrates with Procurement, Warehouse / Inventory, Costing, General Ledger, Accounts Payable, Accounts Receivable.

This new products is targeted for Wholesalers/distributors specially for High Tech customers. This application is having dependency and perquisite of first two application discussed above.

ORACLE SUPPLIER SHIP & DEBIT

Oracle Supplier Ship and Debit is a new module in Release 12.1 and a new flow introduced that enables Distributors to more quickly and intelligently respond to market conditions by automating special price requests to Vendors, in order to close more sales and increase profitability. Distributors are able to reduce the cost of managing the special pricing process as the execution and the more tedious claiming process are completely automated thereby providing greater visibility.

This products sound similar to Wholesalers/distributors specially for High Tech customers. This application is having dependency and perquisite of first two application discussed above.Supplier Ship & Debit application have Dependencies and perquisite with AR Deduction Settlement and Channel Rebate & Point of Sale Management application.

Thanks to reader Ganesh, you pointing this functionality availability in EBS.Last time I observed this lacking functionality while one client migrated from SAP to oracle.

Good news for those having Oracle R12.1.1 , they can utilize this new functionality where a new attribute in the supplier form enabled them link the payee of supplier A to the payee for supplier B(alternate payee). Then after Payable department can enter an invoice you go to the Remit-To columns and set them to the alternate payee.

You need to update the supplier and create a relationship with the alternate supplier in the suppliers form. When new invoices are entered these remit to supplier fields at the invoice header default if just one relationship exists or can be selected from LOV if multiple exist. It appears that if there were multiple relationships this can be changed after validation but prior to accounting.

Check it out for more details at metalink #949183.1

Reference Post

• http://www.oracleappshub.com/account-payable/why-alternative-payee-is-missing-in-oracle-payablepayment/

These are major enhancement in R12 Advance Collection.

• Multi Org Access Control MOAC) enabled.
• Uptake of Cross-Operating Unit Initiative: Collections activities such as strategies and work items, dunning letters, and collections calls can incorporate transactional and customer data from different operating units if needed.
• Consolidation of Collections Functionality into Advanced Collections: Collections Workbench in AR is obsolete.
• New Implementation Checklist and Setup Screens: New implementation tool designed to ease setup and provide a single place to record and manage implementation decisions.
• Improved Payment Processing and Customer Funds Capture: Seamless integration with Oracle Payments’ make payment formatting and end-to-end electronic payment processing features very efficient.
• Use of Oracle Territory Management to Define Collections Territory Hierarchy.
• XML Publishing Technology for Collections Correspondence.
• Configurable Metrics: A new configurable Metrics tool allows managers to define metrics formulas that are automatically calculated and displayed on the Profile tab for collections users.

This is New Product in R12 which provides the infrastructure for transaction tax knowledge management and delivery using a global system architecture that is configurable and scalable for adding country specific tax content.

• Modules Integrated with EB Tax:
  • Oracle Purchasing
  • Oracle Internet Procurement
  • Oracle Receivables
  • Consigned Inventory
  • Oracle Payables
  • Oracle Intercompany Invoicing
  • Oracle Order Management
  • Oracle Trade Management
  • Oracle Services Contracts
  • Oracle Order Capture/iStore/Quoting
  • Oracle Internet Expenses
  • Oracle Project Accounting
  • Oracle General Ledger
• Configuration Options & Provider Service Subscriptions: Users using a subscription model can share the tax setup. The owner of tax setup data is defined as a Configuration Owner and can be an Operating Unit or a Legal Entity.
• Events and Configuration Owner Options: Tax Events model allows E-Business Suite applications to map their various documents and actions across applications into corresponding tax event classes and tax event types.
• Tax Configuration Manager: This component is responsible for creating and maintaining the structural foundation of tax, the building blocks.
• Tax Determination Services: This component calculates transaction taxes based on transaction details and tax setup information.
• Centralized Tax Record Repository for Audit and Reporting
• Tax Reporting: Tax Reporting is flexible enough to provide data in a user-friendly format that allows the standard and identified country specific requirements to be met.
• Tax Simulator: This user interface help the tax manager simulate the effect of a new rule or new ‘incremental’ setup data, such as a new tax rate.
• Guided Configuration: Enables a tax manager, i.e., an expert in the domain of tax, to configure the system to meet the tax requirements in one or more countries.
• Additional Enhancements:
  • Deferred Tax in Payables
  • Enhanced handling of Tax on Freight
  • Sales and Use Tax in procurement
  • Enhanced exemptions and exceptions
  • Multiple Tax Registrations
  • Multiple Recovery types
  • Tax reporting codes
  • Cash as well as Accrual Basis reporting for tax
  • Enhanced handling of Tax on Intercompany Movements