Basic Changes

Functional design

1. Set Of Books is replaced by the term Ledger.

2. Accounting entries for transactions happening in all the applications such as Purchasing,Cost Management,Payables will go to General Ledger through a common module called “Subledger Accounting (SLA)” which is introduced in R12 and accounting entries can be viewed at SLA menu.

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

4. SLA architecture gives the flexibility to derive the accounts for all transactions when it comes to SLA using Account Derivation Rules to meet various business needs and the accounting entries using those derived accounts can be transferred to General Ledger. Also it gives the flexibility to modify the accounting line types,balance types,conditions based on which the accounting gets generated for all the event classes.

5. SLA has the option to generate the accounting entries for respective subledgers in Draft mode or Final mode. Accounting entries can be created in Draft mode first in SLA which is a rough or draft entry to see whether the journal needs any modification in terms of account code or journal category. These draft entries will not get transferred to GL at any point of time. If any modification is required, it can be done using the features available in SLA and the accounting entries can be created in Final mode once the user feels that the journals do not need any modification. When the entries get created in Final mode in SLA, it will override the entries already created in Draft mode and these final mode entries alone will get transferred to GL.

5. The concept of Secondary Ledger has been introduced so that you can have two different accounting methods set at ledger level, for eg; Accrual basis accounting method for Primary ledger and Cash basis accounting method for Secondary ledger, and the ledgers can have different chart of accounts/currencies/calenders.  Actual and Encumbrance entries in the Procure to Pay cycle can be generated in secondary ledger also along with the entries in Primary ledger.

Technical design

1. The column set_of_books_id has been replaced with ledger_id in GL Tables

2. As a part of Subledger Accounting, new SLA tables XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS have been introduced through which the accounting entries flow to GL.

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

4. Receiving Subledger/Inventory subledger/Payables subledger is not directly linked to table GL_JE_LINES,instead it is linked through the subledger tables XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS.

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

Setting up of Encumbrance

Defining the Subledger Accounting Method (SLAM) :

Navigation:

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

Subledger Accounting Method is having the option of

a) Standard Accrual
b) Encumbrance Accrual
c) Standard Cash
d) Encumbrance Cash

If Encumbrance needs to be enabled, then the Subledger Accounting Method has to be set as  “Encumbrance Accrual” in case of Accrual basis accounting method or “Encumbrance Cash” in case of cash basis accounting method for the ledger.
If Encumbrance is not used, then the Subledger Accounting Method has to be set as “Standard Accrual” or “Standard Cash” for the ledger.

Difference in Behavior between 11i and R12:

1. In 11i, Encumbrance related set ups include enabling the Budgetary control flag for the set of books, defining the Reserve for Encumbrance a/c, enabling the encumbrance for REQ,PO and INVOICE in Financial Options.
Where as in R12, Subledger Accounting Method has to be set for the ledger in addition to other set ups done in 11i. If it is set to “Standard Accrual”, Encumbrance cannot be used for that ledger even though the Encumbrance is enabled for the REQ,PO and INVOICE in Financial Options.

2. In 11i, there is an option to choose different encumbrance types for REQ,PO and INVOICE in Financial options but in R12, Financial options does not have the LOV to choose the encumbrance type. By default, Requisition encumbrance will be “Commitment”, PO encumbrance will be “Obligation” and invoice encumbrance will be “INVOICE”. If any of these 3 encumbrance types is not enabled in GL > Set up > Journal > Encumbrance, then the respective document REQ/PO/Invoice will throw budgetary control exception and will fail funds check.

Generation of Encumbrance Entries

Functional design

On Reserving and Approving the Requisition(PR)/Purchase Order(PO), Encumbrance amount gets reflected in Funds Inquiry screen and the encumbrance entries can be viewed in SLA menu in Purchasing module.

Navigation:
Purchasing>Accounting>SLA:User Main Menu>Accounting events
Query by transaction dates,ledger name and transaction number which is the PR/PO number

Following Accounting entries will be available in the HTML page

Budget a/c DR
Reserve For Encumbrance CR

There is an option to do funds check before taking the RESERVE and APPROVE action on the PR/PO by navigating to Tools > Check funds in Requisitions and Purchase Order forms to see the funds check behavior before approving the PR/PO. This funds check activity will create a draft entry in SLA and once the document is reserved, encumbrance entry will get created in Final mode overriding the draft entry already created for the “Check funds” action. If the funds check fails due to insufficient funds on taking the RESERVE action, entries will get created with Invalid status in SLA.

If Secondary ledger is associated to the primary ledger with the conversion level as ‘Subledger’ and if the secondary ledger is using encumbrance based SLAM, then encumbrance entries will get created in both primary subledger and secondary subledger on doing the RESERVE action on the PO.

The Concurrent Request “Transfer Journal Entries to GL” has to be submitted from Purchasing Responsibility to create the encumbrance entries in GL. On running this request, encumbrance entries created in Final mode alone will get transferred to GL.

Difference in Behavior between 11i and R12:

1. In 11i, encumbrance entries will get transferred to GL by running the concurrent program “Program-Create Journals” from GL responsibility. But in R12, “Transfer Journal Entries to GL” has to be submitted from Purchasing Responsibility to create the encumbrance entries in GL.

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

3. In 11i, a credit against the Reserve For Encumbrance a/c (RFE) can be seen only at the time of posting the Encumbrance debit entry in GL. But in R12, RFE a/c gets credited along with the budget a/c debit entry which can be viewed from SLA menu in Purchasing.

Technical design

On reserving and approving the PR/PO, encumbrance entries get generated in table GL_BC_PACKETS with column source_distribution_type as ‘PO_REQ_DISTRIBUTIONS_ALL’ for PR and ‘PO_DISTRIBUTIONS_ALL’ for PO and column source_distribution_id_num_1 as req distribution id for PR and po distribution id for PO.

Encumbrance entries will also get generated in the table PO_BC_DISTRIBUTIONS which has been newly introduced in R12. This table has the columns ‘reference4′ and ‘reference3′ columns where the PO/PR number and distribution id gets populated.
These accounting entries are also populated in the table XLA_AE_LINES. The table XLA_AE_HEADERS will show whether the encumbrance entry is created in Draft mode or Final mode or Invalid mode indicated by the column accounting_entry_status_code and it will also show whether the entry is transferred to GL or not indicated by the column gl_transfer_status_code.

The tables PO_BC_DISTRIBUTIONS and XLA_AE_HEADERS are linked with the column ‘event_id’.
The tables XLA_AE_HEADERS and GL_BC_PACKETS are linked with the column ‘ae_header_id’.
The tables XLA_AE_HEADERS and XLA_AE_LINES are linked with the column ‘ae_header_id’.

Once the entries are populated in GL and those entries are posted, records from the table GL_BC_PACKETS will get deleted but the entries in table PO_BC_DISTRIBUTIONS will remain always.

Difference in Behavior between 11i and R12:

In 11i, Encumbrance entries created in GL_BC_PACKETS will be directly moved to GL_JE_LINES by running the CJE program, whereas in R12, Encumbrance entries gets generated in a new table PO_BC_DISTRIBUTIONS and also in XLA tables in addition to GL_BC_PACKETS.

Receipt Accounting

As mentioned earlier, accounting entries for transactions happening in Receiving subledger and inventory subledger will flow to GL only through SLA which involves a new process called “Create Accounting process”.

Create Accounting process for Online Accruals

When purchase order is set to accrue at receipt, accounting entries get created in Receiving subledger once the receiving transactions are done. Then the Create Accounting process should take place to create journals in SLA accompanied by Transfer to GL process and posting which are optional. Users can choose whether they want the journal import and posting also to happen at the same time when the create accounting process is done or the Transfer to GL/Posting can be done explicitly. But if encumbrance is enabled, it is always preferred to do the Transfer to GL and Posting along with the create accounting process by having the values for parameters ‘Transfer to GL’ and ‘Posting in GL’ as YES while submitting the create accounting program. For more details on this, please refer to Note.728064.1. Another main implication of this model of doing the GL transfer and posting along with create accounting process is that, on failure of Journal Import, the data will be rolled back to SLA tables and hence there will not be any data in GL interface.

This Create Accounting Process involves two concurrent programs Create Accounting-Receiving which can be submitted from Purchasing>View Requests or from Cost Management Responsibility > SLA menu > Create Accounting and Create Accounting-Cost Management which can be submitted from Cost Management Responsibility > SLA menu. ”Create Accounting – Receiving” only accounts for Expense destination PO Receipt. “Create Accounting – Cost Management” accounts for all transactions mentioned below.

- Expense destination PO Receipt
- All Inventory transactions including inventory destination POs
- WIP transactions
- Accrual Write Off transactions

Parameters used while submitting the Create Accounting concurrent program:

• Ledger – Ledger (SOB) name to be given
• End date – Accounting entries to be created for all receipts  TO DATE
  a) Draft – Draft mode creates the SLA journals as Draft which can be modified. Hence these entries will not get transferred to General Ledger and it will be available only in SLA. Once the entries created in Draft mode are verified and confirmed, Create Accounting program has to be run in Final mode and the entries getting created now will override the draft entries in SLA and will get transferred to General Ledger.
  b) Final – Final mode creates SLA journals which can not be modified and can be transferred to General Ledger.
• Report – Options available are Detail or Summary
• Transfer to General Ledger – Yes or No – If the mode is set to Final and the value for this parameter is set to No, then the accounting entries will get created only in SLA table and it will not be available in gl_interface or GL. You need to submit the program “Transfer to Gl” in Cost Management Responsibility > SLA to transfer the entries created in Final mode from SLA to General Ledger.
• Post in General Ledger – Yes or No

  a) Online Accruals with Expense destination

Functional design

When the PO which is set to accrue at receipt is received and delivered to expense destination, Receipt Accounting happens in Receiving subledger. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.
This receipt accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries. These entries can be viewed in SLA menu in Cost Management module.

Navigation:
Cost Management,SLA > SLA >SLA: Inquiry > Accounting event
Query by transaction dates and ledger name

Following Accounting entries will be available in the HTML page

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

Charge a/c DR
Receiving Inspection a/c CR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows

Budget a/c CR
Reserve For Encumbrance DR

These entries can also be viewed from Receiving Transaction Summary > View Accounting.

In encumbrance enabled environment, once the receiving process is done, Create Accounting process and posting in GL has to be completed in order to get the encumbrance reversal and actuals to hit the GL funds inquiry simultaneously as the funds availability calculation in Funds Inquiry screen will consider the encumbrance reversal and actuals only when they are posted in GL.

Technical design

When purchase order has Accrue on Receipt set to YES, Receiving Transaction Processor generates the accounting entries in RCV_RECEIVING_SUB_LEDGER upon Receipt and Deliver of the PO. Then the Create Accounting process should take place to create SLA journals which will insert records in XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These accounting entries will be available in the table XLA_AE_LINES. The event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is DELIVER_EXPENSE and the event type code in XLA_AE_HEADERS for these actual entries will be RECEIVE for receipt accounting and DELIVER_EXPENSE for delivery accounting.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type “RCV_RECEIVING_SUB_LEDGER” in XLA_DISTRIBUTION_LINKS table.

  b) Online Accruals with Inventory destination

Functional design

When the PO is received and delivered to inventory destination, Receipt Accounting happens in Receiving subledger and Deliver Accounting happens in inventory subledger. Then the Create Accounting process has to be submitted to generate the receipt accounting and deliver accounting in SLA and GL. This deliver accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries.

View Accounting from Receiving Transaction Summary will show the accounting entries for RECEIVE transaction. To view the actual entries for DELIVER transaction, navigate to Material Distributions form which will show the accounting entries once the deliver transaction is costed. To view these actual entries and Encumbrance Reversal entries in SLA after create accounting process is done, navigate to

Cost Management Resp>SLA>Inquiry>Accounting event
Query by transaction dates and ledger name

Following Accounting entries will be available in the HTML page

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

Material Valuation a/c DR
Receiving Inspection a/c CR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows provided the flag “Reverse encumbrance” is checked in organization parameters > Costing tab.

Budget a/c CR
Reserve For Encumbrance DR

In encumbrance enabled environment, once the receiving process is done, Create Accounting process and posting in GL has to be completed in order to get the encumbrance reversal and actuals to hit the GL funds inquiry simultaneously as the funds availability calculation in Funds Inquiry screen will consider the encumbrance reversal and actuals only when they are posted in GL.

 Technical design

When purchase order has Accrue on Receipt set to YES and destination_type_code is set to Inventory, Receiving Transaction Processor generates the accounting entries in RCV_RECEIVING_SUB_LEDGER upon Receipt and Cost manager generates the accounting entries in MTL_TRANSACTION_ACCOUNTS upon Deliver of the PO. Then the Create Accounting process should take place to create SLA journals which will insert records in XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These accounting entries will be available in the table XLA_AE_LINES. The event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is PO_DEL_INV and the event type code in XLA_AE_HEADERS for these actual entries will be RECEIVE for receipt accounting and PO_DEL_INV for delivery accounting.

The tables MTL_TRANSACTION_ACCOUNTS and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of  inv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type “MTL_TRANSACTION_ACCOUNTS”.

Difference in Behavior between 11i and R12:

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

2. In 11i, if encumbrance is enabled, encumbrance reversal and actuals will undergo funds check when these entries are populated in gl_interface and GL funds inquiry will reflect the encumbrance reversal and actuals even before posting the entries in GL. But in R12, encumbrance reversal and actuals will hit the GL funds inquiry only when these entries are posted in GL even though funds check happens in SLA itself.

  c) Create Accounting process for Period End Accruals

Functional design

When the PO which is set to accrue at period end is received and delivered to expense destination and Receipt Accruals Period End program is submitted, accounting entries get created in Receiving subledger during period end for the PO shipments which has the received quantity greater than billed quantity. Then the Create Accounting process has to be submitted to generate the receipt accounting in SLA and GL.

This create accounting process is accompanied by Subledger Multiperiod Accounting program which gets spawned automatically to generate the reversal for the accrual entries for the next period in SLA. Depending on the value for  the parameter “Transfer to GL” given while submitting the create accounting program, Journal import will happen and the accrual entries for the current period and next period will get transferred to GL.

During this create accounting process, it has to be ensured that the end date given while submitting the Create Accounting program is greater than or equal to the first date of the next period in which accrual reversal is supposed to happen. If the end date of Create Accounting program is less than the first date of the next period, accrual entries for the current period alone will get created in Final mode and will get transferred to GL, where as  the reversal entries will get created in SLA with status as ‘Incomplete’ and it is not eligible to get transferred to GL . To transfer the accrual reversal entries which got created with INCOMPLETE status from SLA to GL, it has to be final accounted in SLA first which can be done by running the program ‘Complete Multiperiod Accounting’ with end date which includes the first date of next period and then it can be transferred to GL. If the GL period is closed for the current period or for the next period, period end accrual entries and reversal entries will get created only in SLA. To transfer these entries to GL, the concurrent request “Transfer Journal entries to GL-Receiving” needs to be submitted after opening the GL period.

This receipt accounting includes encumbrance reversal entries if the PO is encumbered, otherwise it just includes the actual entries. These entries can be viewed in SLA menu in Cost Management module and it cannot be viewed from Receiving Transactions Summary > Tools > View Accounting.

Navigation:
Cost Management>SLA Resp>SLA>Inquiry>Journal entries
Query by transaction dates and ledger name

Following Accounting entries will be available in the HTML page

AP Accrual a/c CR
Charge a/c DR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows

Budget a/c CR
Reserve For Encumbrance DR

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

AP Accrual a/c DR
Charge a/c CR

If encumbrance is enabled, encumbrance reversal also can be viewed as follows

Budget a/c DR
Reserve For Encumbrance CR

As mentioned for online accruals with Expense destination, in encumbrance enabled environment, once the receiving process is done, Create Accounting process and posting in GL has to be completed in order to get the encumbrance reversal and actuals to hit the GL funds inquiry simultaneously as the funds availability calculation in Funds Inquiry screen will consider the encumbrance reversal and actuals only when they are posted in GL.

Encumbrance will get reversed from the PO once the invoice is validated.Encumbrance on the PO will get converted to Invoice encumbrance. On doing Create Accounting for the invoice, Encumbrance on the invoice will also get reversed. But this invoice encumbrance reversal and Actuals will get reflected in Funds Inquiry screen only when these entries are posted in GL.

Technical design

When Purchase Order has Accrue on Receipt flag set to NO, Receipt Accruals Period End program generates the accounting entries only in RCV_RECEIVING_SUB_LEDGER. Then the Create Accounting process should take place to create SLA journals which will insert records in XLA_AE_HEADERS, XLA_AE_LINES and XLA_DISTRIBUTION_LINKS. These accounting entries will be available in the table XLA_AE_LINES. The event type code in XLA_AE_HEADERS for this Encumbrance Reversal entry is PERIOD_END_ACCRUAL and the event type code in XLA_AE_HEADERS for these actual entries will be RECEIVE for receipt accounting and PERIOD_END_ACCRUAL for delivery accounting.
The tables RCV_RECEIVING_SUB_LEDGER and XLA_DISTRIBUTION_LINKS can be linked using the column source_distribution_id_num_1. The value of rcv_sub_ledger_id has to be given as source_distribution_id_num_1 for the source_distribution_type “RCV_RECEIVING_SUB_LEDGER” in XLA_DISTRIBUTION_LINKS table.

Difference in Behavior between 11i and R12:

1. In 11i, Receipt Accruals Period End program creates the Receipt Accounting entries in Receiving Subledger as well as in GL_INTERFACE. Journal Import will be done to transfer the entries to GL_JE_LINES where as in R12, Receipt Accruals Period End program will create the entries only in Receiving Subledger. Create Accounting Program will create SLA journals and ‘Transfer Journal entries to Gl’ program will move the entries to GL from SLA.

2. In 11i, Accrual entries need to be reversed manually in the next period whereas in R12, reversal of accrual entries for the next period will happen automatically

3. In 11i, if encumbrance is enabled, encumbrance reversal and actuals will undergo funds check when these entries are populated in gl_interface and GL funds inquiry will reflect the encumbrance reversal and actuals even before posting the entries in GL. But in R12, encumbrance reversal and actuals will hit the GL funds inquiry only when these entries are posted in GL even though funds check happens in SLA itself.

Impact of Secondary ledger on Create Accounting process (applicable for both Online accruals and Period end accruals)

If Secondary ledger is associated to the primary ledger with the conversion level as ‘Subledger’ and if the secondary ledger is using Accrual based SLAM (e.g Encumbrance Accrual/Standard Accrual), then encumbrance entries will get created in both primary subledger and secondary subledger on doing the Create Accounting process. On the other hand, if the Secondary ledger associated to the primary ledger is using Cash based SLAM (e.g Encumbrance Cash/Standard Cash) with the conversion level as ‘Subledger’, then the setup mentioned below is mandatory. Otherwise, Create Accounting process will error out or complete with warning and will not generate the receipt accounting entries neither in Primary ledger nor in Secondary ledger.

Setup to be done for Secondary ledger using Cash based SLAM:

When the Primary ledger itself is using Cash basis accounting, Accrual based accounting entries should not get generated for Receiving transactions for the Primary ledger. In such case, it is not required to run the programs ‘Create Accounting-Receiving’ or ‘Create Accounting-Cost Management’ as no accounting entries will be created by these programs.

 Impact of Periodic Average Costing on Create Accounting process (applicable for both Online accruals and Period end accruals) 

R12 SLA design has no impact when Periodic Average Costing (PAC) is used as it follows the same 11i approach. Accounting entries created in PAC will not go to SLA and it will not undergo the create accounting process. Instead it will get transferred to GL via gl_interface from PAC distributions . But the perpetual accounting entries will also happen along with PAC entries where the perpetual accounting will follow the SLA design. But those entries should not get imported from SLA to GL as PAC accounting will be transferred to GL. To restrict the GL import of perpetual accounting entries, “Transfer to GL” option in organization parameters should be set to None for organizations which use PAC so that xla_ae_headers for perpetual accounting will have the gl_transfer_status_code as “NT” and it will not be picked by the journal import process.

Accrual Reconciliation Process

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

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

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

Parameters used while submitting the program:

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

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

Operating Unit – Select the Operating Unit for the report
Title – Enter your title for the report
Balancing Segment From and Balancing Segment To – Range of balancing segment to consider for this report

3. Miscellaneous Accrual Reconciliation Report – This report shows the transaction details based on each accrual account which got hit because of Miscellaneous Inventory transactions and AP NO PO transactions.Accrual amount will be displayed for each transaction along with the source whether it is INV or AP. This report picks data from CST_MISC_RECONCILIATION which gets populated during the load run process.

Parameters used while submitting the program:

Operating Unit – Select the Operating Unit for the report
Title – Enter your title for the report
Sort by – Parameter to specify how to sort the data at the distribution level – Valid Values – Item,Transaction Date (default) , Amount
Date From – Starting date of time period to display for this report
End Date – Ending date of time period to display for this report
Item From and Item To – Range of items to consider for this report
Min Amount and Max Amount – Limits of transaction amount to display
Balancing Segment From and Balancing Segment To – Range of balancing segment to consider for this report

Difference in Behavior between 11i and R12:

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

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

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

4. In 11i, Accrual Reconciliation Report can be run for a specific data range and accrual balances can be checked for a specific period. But in R12, Accrual Reconciliation Report always shows the ‘as on date’ accrual balance and the report cannot be run for a specific date range.

b) Accrual Write-off Process:
Once the accrual entries for the PO or invoice are shown in Accrual Reconciliation Report, Accrual Write-off can be done using Cost Management or Purchasing responsibility>Accounting>Accrual write offs>AP and PO. This will delete the accrual entry from CST_AP_PO_RECONCILIATION table and populate the write off transaction in CST_WRITE_OFFS table. This write off transaction can also be viewed in the form View Write offs.
Accounting entries have to be created in SLA and GL for these write off transactions by submitting the Create Accounting program.This can be viewed in SLA menu by navigating to Tools > View Accounting in the View Write offs form.

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

Accrual a/c DR
Offset a/c CR

Similarly for an AP PO MATCH transaction

Accrual a/c CR
Offset a/c DR

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

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

Difference in Behavior between 11i and R12:

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

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

Accounting Flow

for

Purchase Orders, Receipts and Matched Invoices in an Encumbrance Environment

An Oracle White Paper

This document details the accounting entries that are expected for purchase orders with Expense or Inventory destinations, receipts and matched invoices. It also considers the two choices of accrual available for Expense items in an encumbrance-enabled environment.

Expense items can be accrued at

a)     Period-end

b)    On Receipt

Inventory Items can ONLY be accrued at

a)     Receipt

This document consists of the following case studies/scenarios.

Accrue on receipt: (APO)

Case 1: Expense Destination/Create, Approve, Reserve/Receive/Invoice

Case 2: Expense Destination/Create, Approve, Reserve/Invoice/Receive

Case 3: Expense Destination/Create, Approve, Reserve/Receive/Invoice at a price greater than PO price

Case 4: Expense Destination/Create, Approve, Reserve/Receive/Invoice at a quantity greater than PO quantity

Case 5: Inventory Destination/ Create, Approve, Reserve/Receive/Invoice

Case 6: Inventory Destination/ Create, Approve, Reserve/Invoice/Receive

Accrue at Period-end: (APE)

Case 1: Create PO /Receive PO /Deliver PO /Invoice/Run the period end program

Case 2: Create PO /Invoice/Receive PO/Deliver PO/Run the period end program

Case 3: Create PO/Receive PO/Deliver PO/Run the period end program/Invoice

Case 4: Create PO/Receive PO/Run the Period end program/Deliver PO/Run the

period end program/Invoice

Case 5: Create PO /Receive PO /Deliver PO /Invoice at a price greater than PO

Price/Run the period end program

Case 6: Create PO /Receive PO /Deliver PO /Invoice at a quantity greater than PO

Quantity/Run the period end Program

The following Pages will explain each case in detail:

LEGEND: AOR= Accrue On Receipt, APE= Accrue at Period-End

Note:

• Corresponding offsetting accounts have same symbols.
• PO base price refers to received quantity * unit Price in PO line
• NR tax refers to Non Recoverable Tax calculated for the (received quantity * po line unit price)

• REC tax refers to Recoverable Tax calculated for the (received quantity * po line unit price)

Important Notes:

1. Accrual entries will be generated /created ONLY when the Received quantity > Billed quantity at the time of running Receipt Accruals-Period end program.

2. Under the cases mentioned above under the Period-end Section, manual reversal of journal entries are not required except for Case 3 and Case 4 since there are NO accrual entries created /generated.

3. For all these cases the account records from receiving will also be inserted into GL_BC_PACKETS, along with the other subledger tables mentioned above. These records in GL_BC_PACKETS can be viewed by querying the  max(packet_id), as there are no REFERENCE fields populated for receiving records.

4. Liability a/c  which is recorded at invoice price will also include the recoverable and non-recoverable tax rates.

Accounting Flow against Purchase Orders, Receipts and Matched Invoices.

Oracle Financial Forums

Hello All,

My new forum now is ready, so we can support each other by posting our concerns or just sharing knowledge with our friends.

Please just register and share with your connections.

Regards,

Mahmoud Elemam

Treasury Stocks or Equities FAQ

CONTENTS

——–

1.  Is it possible to record the mutual funds investments using XTR?

2.  How does the system manage loan stock?

3.  Regarding a workaround for resale stock using weighted average cost, how do you address these new problems?

Buy Stock Deal

1. Date=05-JAN-2003, Shares=2000, Price=10 –>CpartyA

2. Date=10-JAN-2003, Shares=3000, Price=11 –>CpartyB

Total Average cost per shares is 10.6=[(2000*10)+-(3000*11)/5000]

Sell Stock Deal

1. Date=11-JAN-2003, Shares=2000, Price=12 number of shares to match to buy1: 2000 * (2000/5000) = 800, remaining shares=1200 number of shares to match to buy2: 2000 * (3000/5000) = 1200, remaining shares=1800

P/L : 800 * (12-10) +- 1200 * (11-10) = 2800

The problem is one Stock issue code could buy from different Cparty, and when selling out 2000 shares, that deal is between company and CpartyA, nothing about CpartyB, after resale deal, both remaining shares should be CpartyA=0 shares                        CpartyB=3000 shares

So if you can not allocate selling out shares based on hand total shares, the P/L amount will not use weighted average cost to calculate.

Counterparty is the custodian, for particular Counterparty total selling out number of shares must be equal to total buying number of shares.

QUESTIONS & ANSWERS

——————-

1. Is it possible to record the mutual funds investments using XTR?

Answer

——

You can definitely try using the STOCK deal type in Treasury to record mutual fund investments. For example, the following features of the STOCK deal type are useful in modeling most mutual funds:

1. Price per Share.  You can use this to record the unit price of the fund, be it exchange-quoted or NAV-based.

2. Number of Shares.  This would be the number of units that you purchase or sell.

3. Cash dividends.  You can use this to model income that’s distributed by the fund.

4. Brokerage & Tax.  Useful if you need to record fees and taxes on your deals.

5. Revaluation. Useful to calculate and journalize the holding profit/loss and realized profit/loss of your deals. Market prices are either the exchange-quoted prices or the published NAV figures released by the funds.

There may be certain types of mutual funds that can’t be easily modeled by STOCK, since “mutual funds” is such a broad term itself. It is for this reason that documentation doesn’t explicitly mention it. On the other hand, deal types such as ONC in Treasury may also be suitable for certain funds (such as certain type of money market fund whose unit price is always 1).

2.How does the system manage loan stock?

Answer

——

Stock loans or securities lending is common between financial institutions, and is generally connected to short-selling. Brokerage houses often borrow stocks from other institutions for short-sellers to use (short-sellers sell stocks they don’t own and make money by “sell high, buy low”). The lending party receives money from the borrowing brokerage. When the brokerage returns the stocks later, it gets its cash collateral back.

Oracle Treasury and its Equities module are primarily designed for corporate treasury type users’ investment activities. Therefore, there’s no explicit support for stock loans/securities lending. Having said this, there ARE functionalities that may be sufficient for that prospect, depending on its specific requirements. For example, Oracle

Treasury allows you to enter and update loan securities between companies and counterparties. This is done in the Counterparty Profiles form. You can specify and update information such as estimated dollar value, valuer, valuing schedule, and related deal numbers. There is also the Loan Securities Report that report on such information by

companies. Separately, depending on the role of the company, you can use the existing functionality in the STOCK deal type to model much of the stock loan transaction, by using BUY/SELL subtypes as a workaround.

3.  Regarding a workaround for resale stock using weighted average cost, how do you address these new problems?

Buy Stock Deal

1. Date=05-JAN-2003, Shares=2000, Price=10 –>CpartyA

2. Date=10-JAN-2003, Shares=3000, Price=11 –>CpartyB

Total Average cost per shares is 10.6=[(2000*10)+-(3000*11)/5000]

Sell Stock Deal

1. Date=11-JAN-2003, Shares=2000, Price=12 number of shares to match to buy1: 2000 * (2000/5000) = 800, remaining shares=1200 number of shares to match to buy2: 2000 * (3000/5000) = 1200, remaining shares=1800

P/L : 800 * (12-10) +- 1200 * (11-10) = 2800

The problem is one Stock issue code could buy from different Cparty, and when selling out 2000 shares, that deal is between company and CpartyA, nothing about CpartyB, after resale deal, both remaining shares should be CpartyA=0 shares                        CpartyB=3000 shares

So if you can not allocate selling out shares based on hand total shares, the P/L amount will not use weighted average cost to calculate.

Counterparty is the custodian, for particular Counterparty total selling out number of shares must be equal to total buying number of shares.

Answer

——

Let’s go over this example.

Initially, you own 5000 shares in total:

2000 @10 (purchased from cparty A)

3000 @11 (purchased from cparty B)

Next, you:

sell 800 shares originally acquired @10 and 1200 shares originally acquired @11, all at once to cparty A.

After the resell, you still own 3000 shares in total:

1200 @10

1800 @11.

Your average cost basis remains 10.6/share. The “Shares Remaining” field for the BUY deal in Treasury lets you know how many shares out of that particular BUY deal (with a particular acquisition price) is available for future sale. Don’t think of it as a tally of how many shares you still have with the particular counterparty. If you think from the perspective of the Company, hopefully your confusion is gone.  I agree that the following two scenarios are not exactly identical, for the reason that you’ve mentioned – from the perspective of remaining shares with the particular cparty.

(1)   BUY 2000 shares, cparty A –> SELL 2000 shares, cparty A.

BUY 3000 shares, cparty B

(2)  BUY 2000 shares, cparty A –> SELL 800 shares, both in 1 deal with cparty A.

BUY 3000 shares, cparty B –> 1200 shares,

In (1), after resell, cparty A has 0 remaining and cparty B has 3000 remaining.  In (2), after resell, cparty A has 1200 remaining and cparty B has 800 remaining.

IF all buying and selling is done with the same cparty, then the specific identification method can replicate the weighted average cost method.

In the example, if cparty A has to be the custodian, for (2) to replicate (1), the assumption is that 1200 shares need to be transferred to cparty A prior to the resell deal. This transfer is outside of Treasury.

Being able to resell to ANY counterparty is common in Treasury. The cparty used in the resell deal doesn’t need to have any BUY history. For example, you may have bought securities with cparty A and cparty B only, but you can use cparty C in the resell deal. Treasury doesn’t track the quantity of securities at the cparty level; the remaining quantity notion is from the perspective of individual BUY deal.

Our suggested workaround (for average cost method) is based on this premise. It is not the same as having the real average cost method – for example, the manual allocation becomes difficult to manage if your volumn gets bigger.

Treasury does not directly support average cost basis method in all security modules (equities, bond, discounted securities). What is offered in these deal types is the specific identification method; this is more flexible and can be used (with manual allocation) to mimic other cost methods such as average cost, FIFO, LIFO, etc, and achieve the same valuation results.

Also, common in all security modules in Treasury, the “remaining” quantity concept is within the context of the original BUY deal and is not intended to be used to reconcile the on-hand quantity with your custodian.

In this specific example, the workaround will satisfy your valuation requirement, but will make reconciliation with your custodian difficult. IF ONLY all your purchase and resell is with a single counterparty, then even reconciliation is a non-issue.

Solution Explanation:
=====================
The formula used to calculate DSO is : 

ROUND( ( (SUM( DECODE(ps.class,'INV',1,'DM',1,'CB',1,'DEP',1,0
                      ) * ps.acctd_amount_due_remaining
             ) * MAX(sp.cer_dso_days
                     )
          )
/* Pick amount_due_original only when the gl_date lies between sysdate and dso_days */
/* The Denominator would be 1 when no records are found meeting the decode criteria */
          / DECODE( SUM( DECODE(ps.class,'INV',1,'DM',1,'CB',1,'DEP',1,0
                                )* DECODE(SIGN (trunc(sysdate
                                                      ) - ps.gl_date - sp.cer_dso_days
                                                )  ,-1,
                                                (ps.amount_due_original + nvl
                                                      (ps.amount_adjusted,0
                                                      )
                                                 ) * NVL(ps.exchange_rate,1
                                          ),0
                         )
                   ) , 0,1, SUM( DECODE(ps.class,'INV',1,'DM',1,
                                                 'CB',1,'DEP',1,0
                                        ) * DECODE(SIGN (trunc(sysdate
                                                               )- ps.gl_date
                                                                - sp.cer_dso_days
                                                         ), -1,
                                                               (ps.amount_due_original
                                                                   + nvl
                                                                   (ps.amount_adjusted,0
                                                                    )
                                                                ) * NVL
                                                                    (ps.exchange_rate,1
                                                                     ),0
                                                    )
                                )
                                 )
                                 ),0
                                 ),/* dso */ 

Total outstanding receivables (open)/total sales for prior dso days) * dso days 

Currently if total sales for prior dso days is zero, we substitute a 1, which
could result in a high DSO. (You can't divide by zero). 

To get the total sales it uses the
   (amount_due_original + amount_adjusted )* exchange rate
       from ar_payment_schedules_all.
To get the total open, you use the
   (amount_due_remaining + amount_adjusted )* exchange rate
       from ar_payment_schedules_all. 

You use the amount_due_original instead of amount_due_remaining, if the gldate
lies between the sysdate and the dso days. 

You select dso days in the systems options. 

Note: credit memos are not taken into consideration. 

You can't compare the total net Receivable reported in the form with the
reports, as the date cutoff is different. The forms use todays date.
The reports use as of date.

1. Confirm additional product installation:

Confirm that you have the appropriate products installed to allow Collections to work properly. The following files will need to be compiled on your instance resulting in .plx files. Without these files compiled, Collections will not work properly.

CUSTOM.pll, GLOBE.pll, FNDSQF.pll, JE.pll, JA.pll, JL.pll,
JTF_GRID.pll, JTFDEBUG.pll, JTF_UTIL.pll ,ASOCORE.pll
ASTTMLIB.pll, ASTBOMAN.pll, IEUPUWQ.pll
CSUTILS.pll, CSQKMENU.pll, (ASTCORE.pll in Release 11i only)

2. Setup your Collections User:

Refer to Note: 230346.1 How To Setup a Collections User Account.

A. To create an account:

In System Administrator Responsibility> Security>User>Define

Enter a Username and Password

Assign the following responsibilities:

• System Administrator
• Application Developer
• Receivables Manager
• Collections Agent
• Collections Forms Administrator
• CRM Resource Manager
• Collections HTML Admin
• Telesales Agent
• Human Resources Manager
• CRM Administrator

B. In your HR Responsibility :

• Setup employee
• People>Enter & Maintain
• Enter name, birthday, gender, SSN and Save
• Note the employee number

C. In System Administrator Responsibility:

• Security>User>Define
• Query your Username
• Enter the Full Name as it appeared in the HR setup screen above
• Save

D. Using the CRM Resource Manager Responsibility

• Menu: Maintain Resource
• Create a Group
  • -Name/Start Date (you can use anything)
  • -Assign Usages
    • Collections Application
  • • Sales & Telesales Application
  • -Roles
  • Collections Agent
  • Telesales Agent
• Import Resource
  • Resource Cat = Employee
  • Enter Employee # that was noted previously
  • Click search/select employee
  • Click create resource
• Default Value window
  • select start date of the resource
• Close the window
• Select Resources click Save
• Click Details
• From the Resource Management Form, enter the Username
• Click on Roles Tab (Security & Access)
  • Add the following roles:
  • Collections Role Type
  • Collections Agent Role
  • Telesales Role Type
  • Telesales Agent Role
• Click on the Group Tab
• Query Group you created previously
• Add as an employee to the Group
• Close the form.

3. Decide what level you want the Dunning and Strategies to work.

For Release 11i:    Customer, Account, Bill-To, Delinquency
Use the responsibility – Collections HTML Administrator>Setup

For Release 12: Customer, Account, Bill-To, Delinquency
Use the responsibility – Collections Administrator>Setup Checklist

Please be sure to read the Oracle Advanced Collections User and Implementation Guides for details on the setup of the application for your instance.

4. Setup the UOM for the Strategy processing to use:

There are 2 mandatory setups:

1-  For the UOM to appear under Work Item Template, the UOM must be created under class Time class (not TIME)

2- Please ensure the UOM has a conversion attached to it. The UOM will only appear if there has a conversion attached to it.

3- After this information has been save, please bounce the apache server, clear the _oa__html_pages directory and the browser cache

A. To create a UOM and UOM class:

Defining Unit of Measure Classes
Responsibility Inventory
Menu: Setup > Units of Measure > Classes.
Steps
1. In the Units of Measure Classes window, select File > New.
2. Enter a unique name for the unit of measure class.
3. Enter a description for the UOM class.
4. Define the base unit of measure for this class.
5. Enter a unique abbreviation for the unit of measure with a maximum length of three characters.
6. Select the “inactive on” date from the date picker.
7. Save your work.

B. Click on Conversion and define the conversion for the UOM you just created.

C. The profile option : Time unit of Measure Class (JTF_TIME_UOM_CLASS) needs to be set for Collections HTML administration to determine the UOM class needed to be used.

1- Please set the profile Time unit of Measure Class (JTF_TIME_UOM_CLASS)
2- Save
3- Clear the browser cache
4- Bounce the apache server and clear the _pages directory:
- log onto UNIX
- dir comn/admin/scripts
- stop apache
adapcctl.sh stop
- navigate back to _oa__html pages directory
comn/html/_pages
- run command to delete all pages
rm -rf *
- navigate back to scripts directory
- start apache
adapcctl.sh start

5. Setup Credit Management with Credit Management Super User responsibility

Oracle Collections is designed to read data from the AR_TRX_BAL_SUMMARY table for use in the customer balances of the UWQ and the last payment information in the Collections Header. For this reason, you MUST install Credit Management and the latest patchset to have these functions working in Collections. Credit Management concurrent processes populate and update the data in the AR_TRX_BAL_SUMMARY table.

Collections also uses the Exchange Rate from Credit Management, so you must setup:

-Using Credit Management SuperUser responsibility
-Policy Management>System Options
-Make sure that these settings are set including Exchange Rate
-You can tell if they are set because when you first look at the screen, if you can select an aging bucket, then it’s not set. When the system options are set, you should not be able to select an aging bucket.

For specific information on setting up Credit Management, please review the Credit Management User Guide.

For information on the new UWQ Summary Table in Release 11i.IEX.H RUP 4 and R12, see Note 405933.1.

6. Collections prior to 11i.IEX.H uses the Territory setup to differentiate what customer belongs to what resource.

Use the CRM Administrator responsibility>Territory Administration to setup Territories. You must use the Sales & Telesales usage; the Collections Usage is not working at this time.

Oracle Collections is designed to read the AS_ACCESSES_ALL table for the assignment of resources to the work in Collections. You must use the Telesales and Sales Usage in Territory Manager to setup your Territories. Then run the Generate Territories and Assign Territories in that product to load the AS_ACCESSES_ALL table. None of these steps are considered to be part of Oracle Collections. You will need to discuss issues with Territories with the Oracle Territories team via an SR and issues with Sales Teams with the Telesales group via an SR. Until this is setup, you will need to keep the profile OS: Customer Access Level at Full in order to see your customers. If you set the profile to Sales Team, it will require the setup of territories and sales teams.

Note:

Once you setup your resources and create strategies to have the work items assigned;

If you decide to change the resources/territories in a major way, the strategy work items will still be assigned to the original resources/territories. Once a work item is created and assigned it will not be reassigned based on the new resource/territory strategy. There is an option in the Collections HTML Administrator responsibility that allows you to change the owner of the work item for that work item only. Future work items will be created with the new resource/territories in place.

For instruction on how all this changes in Release 11i.IEX.H and R12, please see Note 367373.1.

7. Next, you’ll need to create delinquencies:

• Collections Forms Administrator>Submit Request
• Run the following jobs:
  • IEX: Promise Reconciliation
  • IEX: Scoring Harness
    • One line per parameter in this order 2,1,6
    • Engine 2 to create the delinquency
    • Engine 1 to score the Party
    • Run engines 6 or 7 depending on setup of strategies.
    • 6 is for Account
    • 7 is for Bill To
  • IEX: Strategy Management

The aging of delinquencies occurs in the Delinquency Management process, which automatically runs with the Scoring Harness jobs. To confirm that you have created delinquencies, you can do a query on the iex_delinquencies_all table.

Select count(*) from iex_delinquencies_all;

If you choose to create custom scoring engines, and you have multiple concurrent processes spawning, you may need to run the scoring engines separately or you will run into FND Bug 2576919.

8. You will need to setup the Strategies at this point.

Strategies are the work items that your collectors will use to determine the course of action to closing the delinquency and receiving the money from the customer. The steps are too lengthy to explain here, please review the User Guide and White Papers for more information. (see below for white paper location)

9. Schedule Processes

In order for Work Items to be advanced in Collections you’ll need to schedule the following processes to run on a regular basis automatically:

Collections Forms Administrator responsibility – Menu>Submit Request>Single Request

Workflow Background Process

Item: Strategy Fulfillment Mailer

This will move work items waiting to go to Fulfillment.

Item: Collection Strategy Work Flow

This will keep the work items moving once they are created.

To confirm that you have created strategies and work items you can query the tables as follows:

Select count(*) from iex_strategies

Select count(*) from iex_strategy_work_items

For more information on Scoring Engines and Strategy Work, please review the White Paper that has been written by development and is available on Metalink.

11. Validate setup correct

If you have followed all the steps correctly, you will see the data in the Universal Work Queue.

If you created delinquencies, you will see the delinquencies in the appropriate node on UWQ. If you ran the Strategy Management process you will see Work Items in the Work Item node waiting to be completed.

STRATEGY

1. An incorrect strategy has been assigned via strategy management program to the customer, Why?

a. Please check the score of the customer/account/bill to/delinquency as applicable and check the minimum applicable score of the strategy template.
b. Make sure you have not selected the strategy from Change strategy button
c. If the object (customer/account/bill to/delinquency) doesn’t fall in segment corresponding to any strategy template and then default strategy will be assigned.

2. Strategy is missing in strategy tab?

a. Make Sure Score exists for the customer/account/bill to/delinquency as applicable
b. Make Sure Default Strategy template exists
c. Sometime Strategy has only one work item which is optional and skips after optional wait time and strategy closes by the time user notices
d. Make Sure Default Collector Exists
e. Make Sure IEX: Process Strategies by Operating Unit is No if it is yes
f. Make sure there are delinquent invoices for the customer/account/bill to as applicable
g. Make sure it is not within the grace period.
h. Make sure CP has not been run in Draft mode
i. If IEX: Process Strategies by Operating Unit is Yes then make sure the user has access to particular OU which customer/account/bill to has
j. If IEX: Skip Default Strategy Assignment is Yes and there is no matching strategy found with customer, it will not assign default strategy also
k. If there is a single automatic work item without any pre-wait/post-wait then also it completes immediately and strategy will be closed immediately.

3. Collector of my customer is not assigned to the customer’s strategy work item?

a. Please check whether your collector is assigned to customer/account/bill to/delinquency as applicable
b. If your work item requires skill make sure your collector has the skill if not it will go to default collector

4. Work item doesn’t appear in UWQ.

a. Only Manual open work items assigned to the logged in collector come in UWQ
b. Make sure your collector has access to corresponding Operating Unit.
c. If your collector doesn’t have access to a work item and if he wants to see the work item then make sure profile “IEX: Work access level” is set to Full

5. My strategy is created at a different business level than expected?

a. This will happen only when multiple level strategy is enabled
b. Make sure your operating unit doesn’t have a different business level then site business level
c. Make sure your customer doesn’t have a different business level preference than operating unit or site business level

6. Change Strategy button in strategy tab is disabled.

a. Only an active collector having active collections manager role can modify change strategy from strategy tab i.e. role should not only exists but also should not be end dated.

7. Under what circumstances will my strategy will go on hold?

a. If all the delinquencies for the corresponding customer/account/bill to/delinquency based on the business level are promised and promise is not broken in total
b. If all the delinquencies for the corresponding customer/account/bill to/delinquency based on the business level are paid

8. Under what circumstances my strategy will go on hold change to open?

a. If any of the open promises are broken
b. If any of the open promises are cancelled
c. If any of the payments is reversed
d. If any new delinquency comes into picture

9. My strategy doesn’t automatically change if any activity happens for the customer.

a. If and only if Automatic change is disabled in the strategy template setup then strategy will not automatically change.
b. Even though in the template setup we have enabled automatic change, it may also happen that when we run strategy management concurrent program we pass no for strategy tolerance override parameter

10. Strategy automatic work items delivery status is not successful. It is in XMLDATA/XMLDOC status.

a. If “IEX: Deliver Dunning Letters” is set to “batch” then strategy automatic work items will be send only if you run IEX: Bulk XML Delivery program
b. To send immediately you need to set “IEX: Deliver Dunning Letters” to Immediate

11. Strategy tab is missing in collections form

a. This happens only if Collections method is selected as dunning or the Strategy Tab has been disabled from the menu setup.

12. Why latest work item is still in status “To be created” even after completion of previous work item?

a. There may be post wait time for previous work item. Once the post wait time is completed then the next work item will go into pre-wait or open based on setups.

13. Why work items corresponding to a strategy has different resource assigned?

a. This happens when there is a group collector assigned to the business level.
b. When group collector assigned to this customer at the corresponding business level, work items will be assigned to different resource of that group based on load balancing.

14. Strategy for Bankruptcy is not created?

a. Make sure your bankruptcy workflow is approved by collections manager. Strategy is created only when it is bankruptcy is approved
b. Make sure profile “IEX: Strategy Creation on Bankruptcy” is set to Yes

15. Work item with skill is not assigned to the collector of the customer.

a. If the skill doesn’t exist or is not valid on the date of the work item to the collector of the customer then default collector will be assigned to the work item.

16. Why fulfillment work item is not completed even after running IEX: Bulk XML delivery manager concurrent program?

a. If profile “IEX: Work item delivery waiting time” is set to more than 0 then work item waits until the delivery completes.
b. If the delivery doesn’t complete within no of days specified in the profile option work item goes to in error.
c. We need to run IEX: Bulk XML Delivery Manager Concurrent program for “Get status only” parameter as Yes to get the delivery status before running Workflow Background Process for Strategy Workflow.
d. If IEX: Bulk XML Delivery Manager Concurrent program for “Get status only” parameter as Yes is not run then work item will end in error after the time mentioned is passed.

DUNNING

1. My invoice(s) doesn’t appear in stage dunning letter.

a. Check if your invoice is current invoice and your setup doesn’t contain include current invoices
b. If your transaction is promised and it is still open i.e. not broken then it will not appear.
c. Check if your invoice is disputed invoice and your setup doesn’t contain include disputed invoices
d. Make sure your customer doesn’t have grace days setup made in the dunning plan. In this case invoices will not come until grace days have not been passed.

2. My invoice(s) doesn’t appear in days overdue dunning letter.

a. Check if your invoice is current invoice. Current invoices don’t appear in day’s overdue dunning letter.
b. Check if IEX: Hold Dunning if Full Amount Promised is Yes then promised invoices may not appear.

3. Dunning letter is not generated for the customer.

a. Check if your score exists based on the current business level and for the scoring engine attached in the dunning plan.
b. Check if your profile doesn’t have send dunning in profile class unchecked
c. Make sure the dunning amount and dunning invoice amount surpasses minimum dunning amount and minimum dunning invoice amount in the profile class.

4. Dunning Callback is not created for dunning record.

a. Dunning record should be in Open status
b. Make sure you are trying to create call back on call back date. Call back date is determined from days specified in the dunning plan setup.
c. Make sure callback is enabled in the dunning plan setup

5. When will dunning record be in Close status?

a. A new dunning record may be created for the same dunning method i.e. Days overdue or stage dunning
b. A payment must have been made for the transactions appearing in dunning letter and running delinquency management will close the dunning record.
c. You may have run in draft status.

6. Please explain how the dunning correspondence gets picked up from Days Overdue dunning plan.

a. First criteria is score of a customer/account/bill to/delinquency based on business level and scoring engine assigned in dunning plan.
b. Secondly score should match with the aging line where your oldest delinquent transaction lies. The correspondence of that will be matched accordingly.

7. Please explain how the dunning correspondence gets picked up from Stage dunning plan.

a. First criteria is score of a customer/account/bill to/delinquency based on business level and scoring engine assigned in dunning plan.
b. Secondly score should match with the stage level where your delinquent transaction lies.
c. The correspondence of stage level will be grouped for various stage levels of that line into a single letter

8. Is there a way to deliver dunning letter in a different format for an email method?

a. Set your profile IEX: Email Delivery Format to a format (PDF Attachment, XLS Attachment, RTF Attachment and Inline) for the user to which collector of the customer/account/bill to has access

9. How will my collector get copy of dunning letter sent to his customer?

a. Set IEX: Copy Dunning to Collector to Yes and dunning letter copy will be sent to the collectors email.

10. Only a single letter is sent for different stages belonging to different lines for a stage dunning plan.

a. This will happen only if you pass parameter Single Stage letter as Yes while running dunning plan concurrent program

11. Modification of stage dunning level from transactions tab is disabled.

a. Only an active collector having active collections manager role can modify the stage dunning level i.e. role should not only exists but also should not be end dated.

CONTRACTS & LATER STAGE DELINQUENCIES

1. I am not able to view a bankrupt customer in UWQ. Why?

a. Make sure profile “IEX: Hide Bankruptcy in UWQ” is set to No

2. Unable to create litigation and repossession for a transaction from life cycle tab (or) Maintain status in lifecycle tab is disabled.

a. Check profile “IEX: Maintain Status in lifecycle tab” must be set to No

3. Repossession for a contract is disabled?

a. In case no asset exists for a contract then repossession will be disabled

4. What setups are required for write off of a contract?

a. There should be receivable activity created.
b. Approver should have limits for the write off.
c. Accounting template for Adjustment (named as receivable activity) should be setup in lease.

5. Write-off of contracts cannot be approved?

a. Sometimes some transactions may have multiple contract reference which is currently not supported for approval.

6. Cases are created for the customer but how the contracts are filtered between cases?

a. For each bill to for a customer case is created.
b. Hence contracts are filtered based on the bill to location between cases

COLLECTION SETUPS

1. Loans / Contracts tabs cannot be seen in collections form.

a. This will happen if loans and leasing are disabled in Setup checklist, or the tab is disabled in the menu.

2. How is correspondence for various collection activities like adjustments, disputes, promises etc sent?

a. It all depends upon value of profile “IEX: Send Correspondence Automatically” which has 3 values:
i. Automatic – Sends correspondence automatically
ii. Manual – Prompts window for sending correspondence after activity has been executed
iii. Disabled – Will not sent correspondence

3. Can I disable particular collection activity?

a. Various activities of collections can be disabled. Following profile options control various activities
i. IEX: Enable Electronic Funds Payment
ii. IEX: Enable Credit Card Payment
iii. IEX: Enable Receipt Reversal
iv. IEX: Allow Disputes
v. IEX: Allow Adjustments
vi. IEX: Enable Promise To Pay
vii. Later stage delinquencies can be disabled from Setup checklist

4. My unpaid reason code doesn’t appear while assigning unpaid reason to a transaction, Why?

a. Unpaid reason code must be future dated or end dated in the past

5. Newly created Aging bucket is missing in Aging tab.

a. Checking of Active checkbox must have been missed while creating aging buckets

6. What setups are required for setting up collector at customer level?

a. For Setting up collector at customer level we need to create territories.
b. For creating territories following setups are required.
i. Territory roles to the user
ii. Territory attributes need to be enabled for creating territory templates
iii. Territory templates required for creating territories
iv. Territory should have the employee or group attached
v. Need to run “Synchronize Territory assignment rules” program in CRM and “IEX: Territory Assignment” in collections.

OTHER COLLECTION ACTIVITIES

1. Can see multiple values for each metric in profile tab?

a. This happens only if operating unit is selected to all.
b. Metric is displayed for each OU

2. I am not able to cancel dispute as cancel dispute is disabled.

a. Cancel dispute button will be disabled in 3 situations
i. Dispute is already approved and credit memo is created
ii. Dispute is already cancelled
iii. Dispute workflow is rejected by customer

3. Details for dispute in history tab is disabled.

a. Details will be enabled only if dispute is made on a specific invoice line

4. Unable to View /Print Invoices for BPA templates from Collections.

a. Do not print for the transaction type for the transaction must be set to Yes. Change to No for printing.

5. Unable to Promise delinquent invoices.

a. Make sure Promise days in Setup checklist (or Profile “IEX: Maximum Promise to Pay Range”) is within the range of delinquent invoice i.e. no of days of delinquency should not be more than promise allowed days.

6. Unable to make payment or promise for multiple transactions.

a. You can make payment or promise for multiple transactions only if it is of the same account.
b. In case you need to make payment or promise for multiple transactions of different accounts then your account needs to be related to other account

7. Only few records are shown in transactions tab. Not all delinquent transactions are shown?

a. It may happen that some filter is applied in transactions tab. Remove the filter and then you can view all delinquent transactions.

8. Why Amount columns (Amount overdue, net balance & Last payment amount) in Collections header are null?

a. If Operating Unit is all and operating units has different functional currencies then these columns will be null.

9. Why Aging tab is disabled?

a. If Operating Unit is all then aging tab will be disabled.

SCORING

1. Score did not appear for customer.

a. Make sure you haven’t run any “IEX: Purge Score History” concurrent program
b. Make sure all the score component of the scoring engine has valid query.
c. Make sure the customer/account/bill to/delinquency which is to be scored is actually covered under the segment view.

2. My scoring engine do not appear for running in Concurrent Program.

a. Make sure scoring engine is enabled
b. Make sure scoring engine start date is not in future
c. Make sure scoring engine is not end dated

3. Scoring engine output includes limited records.

a. This happens only if Max no of records parameter is passed while running scoring engine concurrent program
b. It may also happen if “object id” parameter is passed which will filter the records based on party/account/site id.

4. Why value of Score in collections header is not changing, when changing view by object?

a. Score field in header always show score of the party.

LOANS

1. When and How does Loan status change?

a. If there is one overdue invoice for a loan then loan status becomes “delinquent”.
b. If there is more than one overdue invoice for a loan then loan status changes from “delinquent” to “in default”

COLLECTIONS SEARCH

1. When opening search form, from Collections form, why search type is not getting defaulted to value in IEX: Default Universal Search Type?

a. When opened from collections form, Search form’s search type default value is determined by the focus before clicking on torch button. If focus in Organization field default type will be Organization. If focus is in First Name/Last Name field, it defaults to Person search.

Intracompany Balancing Rules

Intracompany balancing rules are used for creation of balancing lines on journals between balancing segment values either within the same legal entity, or where there is no legal entity context.

Intracompany balancing rules are used when more than one balancing segment value exists on a transaction or journal entry, as long as you have selected the Balance Intracompany Journals option for the ledger. You cannot post a journal in general ledger when the debit and credit amounts for each balancing segment value do not net to zero. These journals can be balanced automatically if you setup balancing rules and enable the option to balance cross-entity journals.

You must define intracompany balancing rules if you want to balance journals automatically. You may define as many or as few balancing rules as you choose, and each balancing rule may have many accounting rules. Because balancing is an automated process, there should be at least one balancing rule with at least one accounting rule to proceed. This default balancing rule should be defined for the journal source Other and journal category Other for the ledger and legal entity you wish to balance. The default accounting rule on each balancing rule is defined for the debit balancing segment value All Other and credit balancing segment value All Other.

With intracompany accounting, you can define both a debit (due from) and credit (due to) balancing segment, which gives you more control over each balancing relationship. You can specify different debit and credit accounts for each different intracompany trading partner, which is represented by a specific balancing segment value.

All Other is also available as a balancing segment value if you want the balancing segment value to use the same due to / due from accounts for every intracompany trading relationship that has not been specifically defined.

If you set up a specific debit and credit balancing segment value, then the exact debit and credit accounts are used. If you use All Other, the appropriate trading partner balancing segment value replaces the balancing segment of the account combination.

For balancing many-to-many journals there are several balancing segment values with net debits and net credits on a transaction and it is not possible to determine which balancing segment value is trading with which balancing segment value. You can decide whether to use a clearing balancing segment value or a default rule to handle these transactions.

Evaluation Order

Intracompany balancing allows you to define as much flexibility as your business dictates. When there are many balancing rules defined, the Balancing API uses an evaluation order to pick the appropriate rule. Once the balancing rule is selected, there may also be several accounting rules that must be evaluated on the balancing rule. The Balancing API uses the same order for evaluating accounting rules, and understanding this evaluation order will help you define your balancing rules and your accounting rules.

1. Explicitly defined rules are checked first, and they take precedence over all other rules.

a. For balancing rules, this means a specific combination of journal source and journal category exists for the ledger and legal entity. For example, a balancing rule for the journal source Adjustment and the journal category Assets.

b. For accounting rules, this means a specific combination of debit balancing segment value and credit balancing segment value. For example, debit balancing value ’01′ and credit balancing segment value ’02′.

2. If the Balancing API finds no explicit match, then it next searches for a rule with explicitly defined combined with a default value.

a. For balancing rules, this means a combination of a specific journal source and the default journal category for the ledger and legal entity. For example, a balancing rule for the journal source Adjustment and the journal category Other.

b. For accounting rules, this means a combination of a specific debit balancing segment value and the default credit balancing segment value. For example, debit balancing value ’01′ and credit balancing segment value All Other.

3. If the Balancing API finds no match, then it next searches for a rule with a default value combined with an explicitly defined value.

a. For balancing rules, this means a combination of the default journal source and a specific journal category for the ledger and legal entity. For example, a balancing rule for the journal source Other and the journal category Assets.

b. For accounting rules, this means a combination of the default debit balancing segment value and a specific credit balancing segment value. For example, debit balancing value All Other and credit balancing segment value ’02′.

4. Finally, if the Balancing API finds no match after checking for all three previous steps, then the default value should be used.

a. For balancing rules, this means a combination of the default journal source and the default journal category for the ledger and legal entity. For example, a balancing rule for the journal source Other and the journal category Other.

b. For accounting rules, this means a combination of the default debit balancing segment value and the default credit balancing segment value. For example, debit balancing value All Other and credit balancing segment value All Other.

Summary Net and Detail Mode

You determine the level that the Balancing API uses when balancing journals by selecting either Summary Net or Detail. If you select Detail, each line on the journal is balanced individually and a balancing line is generated for each line on the journal. If you select Summary Net, the Balancing API summarizes the debits and credits for each balancing segment value on the journal, determines the overall net debit or net credit for each balancing segment value, balances using the net amounts for each balancing segment value, and produces a summary balancing line for each balancing segment value.

When processing in Summary Net mode, the Balancing API retains the differences in exchange rates for lines with the same balancing segment value. Also note that for lines with negative amounts (debits or credits), if the Balancing API is set to process in Detail mode, the sign of each original line is retained in the balancing line. If the Balancing API is set to process in Summary Net mode, negative debits are interpreted as positive credits and negative credits as positive debits, because each balancing segment value is summarized.

Journal Mode

In order to balance a journal, the journal type must be determined. A journal may be one-to-one, one-to-many, many-to-one, and many-to-many. The type of journal is determined by netting the debit and credit amounts for each balancing segment value and examining the trading relationship.

Below are examples of each journal mode.

One to One

In a one-to-one journal, there is only one balancing segment value with a net debit, and only one balancing segment value with a net credit.

This example uses a chart of accounts with three segments: balancing, natural account, and intercompany. Assume you define the accounts shown in the table below for a specific legal entity, source, category, and the balancing level is set to Summary Net.

 
You create the following journal, shown in the table below, which the Balancing API must balance:

 
The Balancing API sums the debits and credit for each balancing segment value to determine the type of journal. In the example shown in the table below, the journal is one-to-one (01 to 02) and 01 is trading with 02.

 
The Balance By option is set to Summary Net, so the each balancing segment is netted and balanced with one line. The Balancing API creates the balanced journal shown in the table below:

The result is now each balancing segment value balances.

One to Many

In a one-to-many journal, there is only one balancing segment value with a net debit and many balancing segment values with a net credit. All credit balancing segment values are assumed to be trading with the single debit balancing segment value (the driving segment), and all credit balancing segment values balance with the single debit balancing segment value.

This example uses a chart of accounts with three segments: balancing, natural account, and intercompany. Assume you define the accounts shown in the table below for a specific legal entity, source, category, and the balancing level is set to Summary Net.

 
You create the following journal, shown in the table below, that the Balancing API must balance:

 
The Balancing API sums the debits and credit for each balancing segment value to determine the type of journal. In the example shown in the table below, the journal is one-to-many with 01 on the debit side, 02 and 03 on the credit side, and 01 being the driving segment.

 
The Balance By option is set to Summary Net, so each credit balancing segment is netted and balanced with one line against the single debit balancing segment. The Balancing API creates the balanced journal shown in the table below:

The result is now each balancing segment value balances.

Many to One

In a many-to-one journal, there are many balancing segment values with a net debit and only one balancing segment value with a net credit. All debit balancing segment values are assumed to be trading with the single credit balancing segment value (the driving segment), and all debit balancing segment values balance with the single credit balancing segment values.

This example uses a chart of accounts with three segments: balancing, natural account, and intercompany. Assume you define the accounts shown in the table below for a specific legal entity, source, category, and assume the balancing level is set to Detail.

 
You create the following journal, shown in the table below, which the Balancing API must balance:

 
The Balancing API sums the debits and credit for each balancing segment value to determine the type of journal. In the example shown in the table below, the journal is one-to-many with 01 and 02 on the debit side, and 03 on the credit side, and 03 being the driving segment.

 
The Balance By option is set to Detail, so the Balancing API begins processing with the first line and skips all the lines of the driving segment (03). The Balancing API creates the balanced journal shown in the table below:

The result is now each balancing segment value balances.

Many to Many

In a many-to-many journal, there are many balancing segment values with a net debit and many balancing segment values with a net credit. With a many-to many journal, there is no automated way to determine which balancing segment values should balance against each other, so you must use a default rule or clearing company.

Note: If you need more detail and do not want to use
a default rule or clearing company, use Oracle
Intercompany for complex many-to-many transactions.

This example uses a chart of accounts with three segments: balancing, natural account, and intercompany. Assume you define the accounts shown in the table below for a specific legal entity, source, and category. The many-to-many balancing option is set to Use Clearing Balancing Segment Value and the balancing level is set to Summary Net. The clearing balancing segment value is 99.

The result is now each balancing segment value balances.

You create the following journal, shown in the table below, which the Balancing API must balance:

The Balancing API sums the debits and credit for each balancing segment value to determine the type of journal. In the example in the table below, the journal is many-to-many with 01 and 03 on the debit side, 02 and 04 on the credit side.

The Balance By option is set to Summary Net, so each balancing segment is netted and balanced with one line against the clearing balancing segment value.

The result is now each balancing segment value balances, as does the clearing balancing segment value.

Balancing API for Intercompany Journals

If each balancing segment value represents a different legal entity, intercompany accounts are used to balance a journal with these balancing segment values. The intercompany payables and intercompany receivables accounts are used, rather than intracompany balancing rules.

The Balancing API is used by general ledger and subledger accounting to build accounting lines automatically. The Balancing API uses Intracompany Balancing Rules for balancing segment values in the same legal entity, or those with no legal entity context. The Balancing API uses intercompany payables and receivables accounts when each balancing segment value represents a different legal entity.

If there are both intercompany and intracompany lines in the same transaction, the Balancing API will first perform intercompany balancing across legal entities, and then intracompany balancing across balancing segment values within each legal entity. Intercompany balancing results in debits and credits balanced for each legal entity. Afterwards, intracompany balancing results in debits and credits balanced for each balancing segment within each legal entity. The Balancing API is called when posting journals in general ledger, or when accounting for transactions in the subledgers

Intercompany Balancing

Intercompany journals are the journals that involve balancing segment values that map to different legal entities. These journals are balanced for each legal entity by using their intercompany accounts. The Balancing API uses the intercompany accounts defined for the relevant effective date range. Since multiple accounts may be defined for the same date range, Balancing API will pick the accounts flagged with the Use for Balancing indicator (see Set Up Intercompany Accounting) . The offsetting debit for a legal entity goes into its intercompany receivables account. The offsetting credit goes into the legal entity’s intercompany payables account.

Intercompany accounts may be defined at the legal entity level. That is, each transacting legal entity has different intercompany accounts defined for different trading partner legal entities regardless of which specific balancing segment values of those legal entities are used in the journals. The transacting and trading partner balancing segment values are then not explicitly specified in the definition and are set to All.

Intercompany accounts may be defined at the balancing segment level of the legal entities. In other words, a transacting legal entity can use different accounts for different transacting balancing segment values depending on what the trading partner legal entity and trading partner balancing segment value are. In that case, transacting or trading partner balancing segment values may be explicitly specified in the intercompany account definitions.

There are several types of intercompany journals possible. The Balancing API will first determine the type of the intercompany journal (one-to-one, one-to-many, many-to-one, or many-to-many) with respect to the legal entities. For intercompany balancing there is no Clearing Company usage and all legal entities are balanced by summary net with respect to each other.

The following examples consider these types journals and how they are balanced. Since it is easier to follow the process when the intercompany accounts are defined at the legal entity level, those scenarios are considered first. The way the journals are balanced for intercompany account definitions at the balancing segment value level is explained afterwards. For the scenarios below assume that the ledger is assigned to a Shared accounting configuration and has a chart of accounts with three segments: balancing, natural account, and intercompany segments.

Intercompany Accounts at the Legal Entity Level

One Legal Entity to One Legal Entity

Suppose that legal entity LE1 maps to balancing segment values 10 and 11, while LE2 maps to balancing segment values 20 and 21. Consider the following intercompany account setup:

Journal 1:

 
Since Journal 1 is between two balancing segment values (BSV’s) that belong to different legal entities (LE’s) then intercompany accounts will be used to balance it. First the After the balancing entries are added, the journal is shown below:

Journal 1 – Balanced by legal entity:

Next, consider the following journal that contains more balancing segment values:

Journal 2:

 
This is a one legal entity to one legal entity journal between legal entities LE1 and LE2. After the summary net balancing entries are added, the journal is shown below:

Journal 2 – Balanced by legal entity:

 
Notice that Balancing API adds lines 5 and 6 to make the journal balanced for each legal entity. In other words, the debits and credits net to zero for both LE1 and LE2. However, notice that for LE1 we still need to perform intracompany balancing since the entries are not balanced by balancing segment values (10 or 11). Intracompany balancing within LE1 will be performed using the relevant intracompany balancing rules. Suppose that the relevant intracompany balancing rule (summary net, no clearing company) is as follows:

 
Then intracompany balancing lines 7 and 8 are added to Journal 2. Journal 2 thus shows the results of both intercompany and then intracompany balancing.

Journal 2 – balanced by legal entity and balancing segment value:

 
Many legal entity to One legal entity and One legal entity to Many legal entity types of journals are balanced similar to the One-to-One type. That is, each legal entity on the “Many” side is balanced against the legal entity on the “One” side.

Many Legal Entities to Many Legal Entities

For Many-to-Many intercompany journal type, it is not possible to determine which legal entity is trading with which trading partner. The Balancing API uses the intercompany accounts defined for the All Other legal entity trading partner.

BSV 10 maps to LE 1. BSV 20 maps to LE 2. BSV 30 maps to LE 3. BSV 40 maps to LE 4. Consider the following intercompany account setup:

 
Consider the following journal.

Journal 3:

 
This journal is a Many-to-Many journal since multiple legal entities are present on both the debit and the credit side. Since the Balancing API cannot determine the explicit trading partners for each legal entity, the intercompany accounts set up for All Other trading partner legal entity are used:

Journal 3 – balanced by legal entity:

Intercompany Accounts at the Balancing Segment Value Level

Previous examples demonstrated how intercompany accounts can be defined and used at the legal entity level. Intercompany accounts can also be defined in the context of balancing segment values, or at the balancing segment value level. So the account definition could explicitly refer to the transacting balancing segment value and the trading partner balancing segment value. This way, different accounts can be used for the same two trading legal entities depending on which balancing segment values both entities are using. In general, each combination of transacting legal entity, transacting balancing segment value, trading partner legal entity, and trading partner balancing segment value may have its own intercompany account definition.

The journal entries for each legal entity can be composed of several balancing segment values belonging to this legal entity. The intercompany balancing procedure in case of intercompany accounts defined for various combinations of transacting and trading partner balancing segment values is very similar to the way the journals are balanced with account definitions at the legal entity level. Just like in the case of account definitions at the legal entity level, intracompany balancing may take place after intercompany balancing entries are added for each legal entity.

Balancing API will proceed according to the steps outlined below for intercompany balancing in the general case (when some accounts are defined at the balancing segment value level):

1. Group all debits and credits by legal entity. Determine the number of legal entities involved in the journal. There are 4 possibilities:

2. One legal entity to One legal entity journal: the journal is between two legal entities. For a journal between two legal entities, determine the balancing segment values involved on the side of each legal entity. There are 4 possibilities:

a. One balancing segment value to One balancing segment value: for each legal entity determine what intercompany accounts will be used to do intercompany balancing. We will look for and use an intercompany receivables account to create an offsetting debit. We will look for and use an intercompany payables account to create an offsetting credit. The Use for Balancing flag in Intercompany Accounts UI tells us which account should be used in balancing when multiple accounts are defined. The determination of the intercompany accounts is performed according to the Hierarchy Table below starting with rule 1 (From LE, From balancing segment value, To LE, To balancing segment value) and stopping when an account is found.

b. One balancing segment value to Many balancing segment values: same as for One balancing segment value to One balancing segment value case except the Hierarchy Table rules checked are 2, 4, and 5.

c. Many balancing segment value to One balancing segment value: same as for One to One balancing segment value case except the Hierarchy Table rules checked are 3, 4, and 5.

d. Many balancing segment value to Many balancing segment value: same as for One balancing segment value to One balancing segment value case except the Hierarchy Table rules checked are 4 and 5.

Table 1 Hierarchy Table

3. One legal entity to Many legal entity journal: the balancing procedure for this case is to break down the journal into One LE to One LE journals and perform intercompany balancing within each journal (each journal then is One to One and be balanced as shown in step 2).

4. Many legal entity to One legal entity journal: same as One legal entity to Many legal entity journal.

5. Many legal entity to Many legal entity journal: this journal is balanced for each legal entity by using the Transacting Legal Entity and Trading Partner All Other Legal Entities accounts.

Consider the following setup. The COA for this example has two segments: balancing, and natural account. Assume that balancing segment values 10 and 50 map to legal entity LE1, balancing segment values 20 and 60 map to legal entity LE2, and balancing segment values 30 and 70 map to legal entity LE3. The intercompany accounts are set up as follows:

Now consider Journal 4:

With respect to legal entities, we can represent it as follows:

So this journal is a one legal entity to many legal entity journal. We will only show how INTERCOMPANY balancing will be performed. Note that INTRACOMPANY balancing within each LE will be performed after the entries are balanced for each LE.
This journal with respect to legal entities is composed of LE1 on the “One” side and LE2 and LE3 on the “Many” side.
Consider LE1 to LE2 entries. Notice that on the side of LE1 we have two BSV’s: 10 and 50. Also note that on the side of LE2 we have two BSV’s: 20 and 60. So our LE1 to LE2 journal is a Many balancing segment value to Many balancing segment value journal. So the offsetting entry for LE1 is a credit to the Payables account from the rule Transacting LE=LE1, Trading Partner LE=LE2: 10-4020. The offsetting entry for the LE2 is a debit to the Receivables account from the rule Transacting LE=LE2, Trading Partner LE=LE1: 20-2011.
Next consider the LE1 to LE3 entries. On the side of LE1 we still have two balancing segment values (10 and 50). On the side of LE3 we have one balancing segment value (30). For LE1 the offsetting entry is a credit to the Payables account from the rule
Transacting LE=LE1, Trading Partner LE=LE3, Trading Partner BSV=30: 10-4030. For LE3 the offsetting entry is a debit to the Receivables account from the rule Transacting LE=LE3, Transacting BSV=30, Trading Partner LE=LE1: 30-2077.

Journal 4 – balanced by legal entity:

Setting Up Balancing

To set up intercompany and intracompany balancing, you must set up legal entities, ledgers, enable the Balance Intracompany Journals ledger option, and define intercompany accounts and intracompany balancing rules. If the Balance Intracompany Journals option is not enabled, no intracompany balancing rules can be defined.

Set up Legal Entities and Ledgers

To set up ledgers and legal entities:

1. Navigate to the Accounting Setup page.
2. Define your legal entity. For more information, see Legal Entities in Accounting Setup.
3. Define your ledger. For more information, see Ledgers in Accounting Setup.
a. Enable the Balance Intracompany Journals option.
4. Define your accounting configuration by assigning legal entities and ledgers.
5. Proceed to define Intracompany Balancing Rules and Intercompany Accounts.

Set up Intracompany Balancing Rules

To set up intracompany balancing rules:

1. Navigate to the Intracompany Balancing Rules page for the relevant configuration ledger in Accounting Setup Manager.
2. In the Intracompany Balancing Rules Summary page, select the legal entity for which the balancing rules will be defined. Note that you may also select a special value of No Legal Entity if you want to associate the rule with the ledger. Click on Define Rules.
3. Observe various source-category combinations for which balancing rules have already been defined. Click the Create Rule button to create balancing rules for a new source-category combination.
4. In the Create Intracompany Balancing Rules page, select a source and category for which you want to define the rules.
5. You may add descriptive flexfield information at the balancing rule level with Intracompany Rule Descriptive Flexfield. You may also use the Intracompany Accounts Descriptive Flexfield at the accounting rule level.
6. Enter a debit (due from) and credit (due to) balancing segment value for each debit and credit intracompany account. You can choose All Other to have each balancing segment value use the same due to and due from accounts for every intracompany trading relationship that has not been explicitly defined.
7. In the Options subtab specify:
a. if you want Summary Net or Detail level of summarization;
b. if you want the Clearing Balancing Segment Value to be used for All Journals or only for Many to
Many journals;
c. how to proceed if the clearing company is necessary yet unspecified:
i. use the Default Clearing Balancing Segment Value (you have to specify that value in the field below
the dropdown list)
ii. use the Manually Entered Balancing Segment Value. This option should not be used for journals
coming from subledgers since there is no way to specify a clearing company for them.
iii. use the Default Rule. The Default Rule is the All Other-All Other rule. It can only be used if the
Clearing Balancing Segment Value is used for Many to Many journals.
8. Click Apply to save your changes.

Set up Intercompany Accounting

To set up intercompany accounting:

1. Navigate to the Intercompany Accounts page for the relevant configuration ledger in Accounting Setup Manager.
2. Click on the Define Relationships icon for the relevant legal entity.
3. In the Intercompany Accounts table, select the Transacting Balancing Segment Value for the intercompany accounts. Select the Trading Partner Legal Entity and the Trading Partner Balancing Segment Value. For both the Transacting Balancing Segment Value and Trading Partner Balancing Segment Value you can select the special value All to define accounts at the legal entity level. Note that if you have mapped your balancing segment values to legal entities, only the relevant balancing segment values will be available for selection. For example, only balancing segment values that are mapped to the transacting legal entity can be selected as the Transacting Balancing Segment Values.
4. The Trading Partner Ledger will be selected automatically and cannot be changed. If the accounts are defined for the primary transacting ledger, then the primary ledger of the trading partner legal entity will be selected. If the accounts are defined for the secondary transacting ledger, then only the same secondary ledger can be used as the trading partner ledger.
5. Click on the Define Accounts icon for the relevant trading partner.
6. In the Define Accounts page, specify intercompany receivables and payables accounts you want to use with the trading partner. Specify the effective date ranges for your accounts.
7. You may also enter descriptive flexfield information using the Intercompany Receivables Accounts and Intercompany Payables Accounts descriptive flexfields.

Note: If the intercompany accounts are being defined between two legal entities that share the same
ledger, a Use For Balancing radio button allows you to specify which of these accounts is to be used
for balancing intercompany journals in General Ledger and Subledger Accounting Architecture.

Attention: You may choose “All Other” in the Trading Partner Legal Entity allows you to define the
same accounts for all trading partners. This approach is not recommended since it will be challenging
to reconcile intercompany balances.

8. Click Apply and save your work.

All ledgers in a ledger set must share the same chart of accounts and accounting calendar/period type combination. They do not have to share the same currency. This allows you to group the primary or secondary ledgers with their associated reporting currencies to reduce maintenance efforts and streamline processing.

Note: Both the source ledger and its reporting currency (Journal and Subledger level) must have the same open periods to prevent problems during posting in General Ledger.

When Ledger Sets are used?
Some of the General Ledger features that benefit from the use of ledger sets are as follows:
• Translation and Revaluation: Translate balances and run revaluation across multiple ledgers in a ledger set.

• Open and Close Periods: Open and close periods for multiple ledgers within a ledger set from a single operation.
• Reporting: Submit standard reports and Financial Statement Generator (FSG) reports across multiple ledgers in a ledger set.
The added benefit of using ledger sets in FSG reports is to aggregate data and create summarized balances across multiple ledgers in a ledger set.
• Inquiry: Perform online inquiry on account balances or journals across multiple ledgers in a ledger set from a single view; drill down to the journal details and subledger transaction for each ledger.

How to define Ledger Sets?
To define a ledger set:
1. Navigate to the Ledger Set window.
2. Enter a name for the Ledger Set, a Short Name for the ledger set,(Optional) Enter a Description for the ledger set.
3. Choose a Chart of Accounts.
4. Choose a Calendar and Period Type.
5. (Optional) Specify a default ledger. The default ledger automatically defaults in all windows where the Ledger field is required.
Note: A Default Ledger is required for Financial Statement Generator (FSG).
6. (Optional) Select the Enable Security checkbox to secure the Ledger Set definition. If you do not enable security, all users who have access to this definition will be able to use, view, and modify the ledger set definition.
If the Assign Access function is available for your responsibility, the Assign Access button will be enabled once you select the Enable Security checkbox. Choose the Assign Access button to assign the definition to one or more Definition Access Sets with the desired privileges. For more information, see Definition Access Sets, page 1-136.
If the Assign Access function has been excluded from your responsibility, you will be unable to view the Assign Access button in the Ledger Sets window. You can still secure the Ledger Set definition by selecting the Enable Security checkbox, but only Definition Access Sets that are AutoAssigned will be automatically assigned to this Ledger Set. See your System Administrator for more information on Function Security.
7. In the Ledger/Ledger Set column, choose the ledgers and/or ledger sets to be included in the ledger set. Only those ledgers and ledger sets that share the same chart of accounts, calendar, and period type specified for the ledger set definition will be available.
If you use reporting currencies (journal or subledger level), you can choose reporting currencies to be included in the ledger set. Only those reporting currencies that share the same chart of accounts, calendar, and period type specified for the ledger set definition will be available
8. Save your work. The General Ledger Accounting Setup Program will be submitted.
Ensure this program completes successfully. Once saved, a ledger set cannot be deleted. You can only add or remove ledgers and ledger sets from ledger sets.

Note: You must have at least one ledger or ledger set assigned to a ledger