Period-End processing in Payables R12

Accounts payable activity must be reconciled for the accounting period that is to be closed. The following steps are taken in performing period-end processing for Oracle Payables.

The posting level for Oracle Payables must be determined when planning period-end procedures. Where detail level accounting transactions are required to be posted to the General Ledger using sub-ledger accounting (hereafter referred to as SLA), there may be technical constraints involved, relating to the physical data storage volume, and posting and report processing speed degradation caused by the sheer volume of posted transactions. In Release 12 the detailed level of posting can be controlled by GL summarize options and also at SLA journal line type level. Subledger Accounting can contain all of the detailed subledger accounting level analysis, so that the general ledger can remain “thin”. Then, Subledger Accounting online inquiry and BI Publisher reports can be utilized to report and analyze balances, and their

transactions.

Procedures:

1. Complete All Transactions for the Period Being Closed

Ensure that all transactions have been entered for the period being closed.

Completing all transactions for Oracle Payables:

* Complete Invoices and Credits

* Complete Prepayments

* Complete Expense Reports

* Complete Invoice Import

* Complete Payments

If you import transactions from an external system, or you are using Internet Expenses or Xpense Xpress, ensure you have imported all transactions, and reviewed all audit trails for completeness. One consideration for Accounts Payable where there are multiple operating units within the same ledger is that all operating units must be ready to close at the same time. All of the operating units that share a ledger also share the same period statuses. When you update the period status to ‘open’ in one operating unit, that period is opened for all operating units within the ledger. When you attempt to update the period status to ‘closed’ in one operating unit, the system checks for unposted transactions in all operating units within the ledger. If there are unposted transactions in any of the operating units, the system asks you to resolve the un-posted transactions for those operating units before it allows you to close the period for the ledger. If Multi-org Access Control is implemented, period closing can be performed across OU’s from a single responsibility, through one OU at a time.

2. Run the Payables Approval Process for All Invoices

Run the Payables Approval process to approve all unapproved invoices and invoice lines in the system, so that they can be paid by Oracle Payments and posted to the general ledger.

3. Review and Resolve Amounts to Post to the General Ledger

a) Review the Invoice on Hold Report

This report enables review of any holds currently applied to invoices that would prevent the payment and/or posting of these invoices. The report details all invoices that Oracle Payables cannot select for posting and therefore cannot create journal entries. Where possible, resolve any identified holds which will prevent posting to the general ledger, and then re-run the Payables Approval process to approve these invoices.

b) Review the Journal Entries Report

This report enables review and analysis of accounting entries in the Payables subledger, as accounted by SLA. Using the report parameters, you can produce a detailed or summary listing of the accounting information you want to review. This report is owned by SLA. The report also lists, in detail, transactions that have been accounted with error and all entries that could not be transferred to the general ledger. When a transaction is accounted with errors, review the details and make necessary changes. By altering the parameters, the report also lists those transactions which have been posted in the general ledger, and those which have not been posted but have been accounted. SLA groups the report by ledger, ledger currency, source, category, and event class. Data is then sorted by accounting date, event type, supplier name, document number, and voucher number.

c) Review the Unaccounted Transactions Report

This report enables review of all unaccounted invoice and payment transactions and a view of the reason that Payables cannot account for a transaction. Accounts Payable sorts the report by transaction type (invoice or payment), exception, supplier, transaction currency, and transaction number. Run this report after you have run the Create Accounting Process. The report will then show only transactions that had problems that prevented accounting. You can then correct the problems and resubmit the accounting process. Note that this report does not include invoices that have no distributions.

d) Optionally run a Payment Process Request at the month end

By running a month end Payment Process request, you may create a payment for as

many due invoices as possible.

e) Confirm all Payment Instructions

Run the Payment Instruction Register for the period that is to be closed, or finalize any outstanding payments. Use Oracle Payments to confirm any payment instructions. Check the status of the Payment Process Request/Payments/Payment Instructions to ensure that all payments have been processed. The Payment Instruction Register lists each payment created for a payment process profile or for a manual payment. Actual payments can be compared against this register to verify that Oracle Payables/Oracle Payments has recorded payments correctly. The report lists each payment in a payment process request, including setup

and overflow payment documents, in ascending order, by payment number. This Oracle Financials E-Business Suite Release 12 Period End Procedures 24 report is automatically submitted when payment instructions are being created and can also be submitted from the standard report submission (SRS) screen.

Attention: Oracle Payables prevents the closing of a period in which all payments have not been confirmed.

f) Optionally run the Payments Register

The Payment Register details payments printed in a particular accounting period. This report can be used to review payment activity for each bank account used during the specified time period. Warning: The report total only shows the net (less discounts) payment amount, whereas the Posted Payment Register total is the total payment amount, including discounts. If only verifying report totals, these two reports would not balance. Therefore it is necessary to subtract the ‘Discounts Taken’ from the Posted Payment Register report total and then compare this calculated amount to the total displayed on the Payments Register Report.

4. Reconcile Payments to Bank Statement Activity for the Period

Once detailed bank statement information has been entered into Cash Management, the information must be reconciled with the subledger transactions.

Cash Management provides two methods to undertake reconciliations:

a) Automatic

Bank statement details are automatically matched and reconciled with subledger transactions. This method is ideally suited for bank accounts which have a high volume of transactions.

b) Manual

This method requires a manual match of bank statement details with subledger transactions. This method is ideally suited to reconciling bank accounts which have a small volume of monthly transactions. The manual reconciliation method can also be used to reconcile any bank statement details, which could not be reconciled automatically.

5. Transfer All Approved Invoices and Payments to the General Ledger

Release 12 provides 3 modes of accounting: Final, Final Post and Draft. The transactions that have been accounted in Final Post have already been transferred to, and posted in the general ledger. The transactions that have been accounted in the Final Mode have been transferred to GL or can still be within the subledger based on the parameter Transfer to General Ledger (either 'Yes or 'No') in the Create

Accounting program.

When accounting mode is Final and transfer to GL is set to ‘No’ then, “Transfer Journal Entries to GL” program needs to be run from the Standard Report Submission (SRS) window. Please review the “Transfer Journal Entries to GL” report generated by this program; make sure there are no errors reported on this report. The transactions in draft accounting mode can be included on accounting reports but cannot be transferred to the general ledger. A draft entry does not update balances and does not reserve funds.

SLA creates detail or summary journal entries for all eligible events when you post. The journal entries are posted in Oracle General Ledger to update account balances. Invoice journal entries debit the expense or other account entered on an invoice distribution line, and credit the liability account specified on the invoice, unless you have modified the SLA rules to create alternative accounting entries to address your specific business needs.

Payment journal entries debit the liability account and credit the cash account of the

bank account used to pay an invoice. The Create Accounting process transfers data to the General Ledger tables, creating journal entries for these invoice and payment transactions. Posting is determined by the parameter ‘Post in GL’ which is set during Create Accounting.

Attention: The generated journal batch needs to be posted from within Oracle General Ledger if the mode of accounting was ‘Final’, Transfer to General Ledger was ‘Yes’ and Post in GL was set to ‘No’.The journal batch will be automatically posted in General Ledger if the mode of accounting was ‘FINAL’ and Post in GL was set to ‘Yes’.

6. Review the Payables to General Ledger Posting process After Completion.

The following reports can be run to review the invoices and payments that were posted to Oracle General Ledger, from Oracle Payables, for the period that is to beclosed, i.e. the current accounting period.

a) The Subledger Accounting Program Report generated by the Create Accounting
program.This report provides either the summary or details (dependent on the parameters provided during Create Accounting program) of the subledger journal entries createdas a result of running “Create Accounting Program”. This report also provides anyerrors that may have occurred during generation of the journal entries.

b) The Posted Invoices Register

This report is used to review invoices for which information has been posted to Oracle General Ledger to create journal entries, and can be used to verify that the total invoice amount equals the total invoice distribution amount. The report lists eachAccounts Payable Liability Accounting Flexfield and the invoices posted to theaccount.

c) The Posted Payments Register

This report is used to review the payments posted to Oracle General Ledger during a particular accounting period, and can be used to review the payment activity for eachbank account used during that period.

7. Submit the Unaccounted Transactions Sweep Program

The Unaccounted Transactions Sweep Program transfers unaccounted transactions from one accounting period to another. Because you cannot close a Payables period that has unaccounted transactions in it, if your accounting practices permit it, you might want to use this program to change the accounting date of the transactions to the next open period. For example, you have invoices for which you cannot resolve holds before the close, and your accounting practices allow you to change invoice distribution GL dates, you can submit this program to change invoice distribution GL dates to the first day of the next open period so you can close the current period. The ‘Unaccounted Transactions Sweep Program’ will not roll forward accounted transactions, or accounted transactions with errors. To create successful accounting entries for accounted transactions with errors, correct any accounting errors and resubmit the Create Accounting Process. The program transfers unaccounted transactions to the period you specify by updating the GL dates to the first day of the new period. You can then close the current accounting period in Oracle Payables.

To submit the Unaccounted Transactions Sweep Program:

1. In the Control Payables Periods window if you try to close a period that has exceptions then the system enables the Exceptions button.

2. Choose the Exceptions button in the Control Payables Periods window. Payables opens a message window. From the window you can choose the following buttons:

• Review (This submits the Period Close Exceptions Report.)

• Sweep

3. Choose the Sweep button. Payables opens the Sweep to Period window. In the Sweep to Period field, Payables provides the next open period. You can accept this default or enter another open period.

4. Choose the Submit button to submit the Unaccounted Transactions Sweep

Program. Payables automatically produces the Unaccounted Transactions Sweep report.

8. Close the Current Oracle Payables Period

Close the accounting period by using the Control Payable s Periods window to set the Period Status to ‘closed’. This process automatically submits the Subledger Period Close Exceptions Report. The Subledger Period Close Exceptions Report lists all accounting events and journal entries that fail period close validation. It is automatically submitted by General Ledger when closing a GL period if there are unprocessed accounting events or untransformed journal entries.

You can also generate the Subledger Period Close Exceptions Report through a

concurrent request as follows:

* For the application associated with the responsibility

* For all applications in the General Ledger responsibility

9. Run Mass Additions Transfer to Oracle Assets

After you have completed all Payables transaction entries, and confirmed all invoice holds, and carry forwards, submit the Mass Additions Create program to transfer capital invoice line distributions from Oracle  Payables to Oracle Assets. For foreign currency assets, Payables sends the invoice distribution amount in the

converted functional currency. The mass addition line appears in Oracle Assets with the functional currency amount. After you create mass additions, you can review them in the Prepare Mass Additions

window in Oracle Assets. It is recommended to do a final Mass Additions Create after the period close to ensure that all Payables invoices are:

* Included in the correct period and

* Any additional invoicing will become part of the next periods invoice and asset processing period.

Suggestion: If the volume of transactions in Accounts Payable requiring Assets update is large, you should consider running the Mass Additions Createprocess on a more regular basis.

10. Open the Next Oracle Payables Period

Open the next accounting period by using the Control Payables Periods window to set

the Period Status to Open.

11. Run Reports for Tax Reporting Purposes (Optional)

A variety of standard reports can be used to provide tax information, which is required to be reported to the relevant Tax Authority, including withholding tax. Withholding tax is handled by Payables whereas other tax requirements are handled by E-Business Tax. The E-Business Tax data extract draws tax information from each application and stores the data in an interface table. Output from the tax extract is designed to look as

close to a simple tax report as possible. Suggested Reports include: Financial Tax Register Use the Financial Tax Register to view the output from the Tax Reporting Ledger. The Tax Reporting Ledger consists of accounting information created in Oracle Payables, and Oracle General Ledger. The short name of this report is RXZXPFTR.

These tax registers are available:

• Tax Register (default)

• Interim Tax Register

• Nonrecoverable Tax Register

These summary levels are available within each Tax Register:

• Transaction Distribution Level

• Transaction Level (default)

• Transaction Line Level

Tax Audit Trail Report

Use the Tax Audit Trail report to review tax information for posted or partially posted invoices. This report provides detail tax and invoice information and the total amounts for each tax rate code in the invoice currency and functional currency. The report lists, for each tax rate code, distributions of all posted or partially posted

The report includes, for each invoice, both the tax amount and the invoice amount subject to tax. The short name of this report is ZXXTATAT.

12. Run the Key Indicators Report (Optional)

This report enables review of the accounts payables department’s productivity. This statistical information can be useful for cash flow analysis and forecasting purposes, when combined with similar information from Oracle Accounts Receivable. When you submit the Key Indicators Report, Oracle Payables generates reports you can use to review payables transaction activity, and review the current number of suppliers, invoices, payments and matching holds in the system.

The Key Indicators Report generates the following reports:

a) Key Indicators Current Activity Report

Use the Key Indicators Report to review your accounts payable department's productivity. The Key Indicators Report provides current activity indicators that compare current period activity with prior period activity in three major areas: suppliers, invoices, and payments. Payables further breaks down each category into basic items, exception items, and updates. The report provides the number of transactions for each indicator (such as number of automatic payments created during a period) and amount values where applicable to the Key Indicator (such as total value of automatic payments created during a period).

b) Key Indicators Invoice Activity Report

Report that compares the invoice activity for each of your accounts payable processors during the period you specify and the previous period. Oracle Payables produces this report only if you choose ‘Yes’ for the Include Invoice Detail parameter.

c) Key Indicators State of the System Report

The Key Indicators State-of-the-System Report provides a period-end view of Oracle Payables, as well as average values. For example, it includes:

Suppliers:

* Number of suppliers.

* Number of supplier sites.

*Average sites per supplier (number of sites divided by the number of suppliers)

 Invoices:

* Number of invoices.

* Number of invoice distributions.

* Average lines per invoice (number of invoices divided by the number of distributions.)

* Scheduled payments (number of scheduled payments based on payment terms and manual adjustments in the Scheduled Payments tab).

* Average payments per invoice (number of invoices divided by the number of scheduled payments).

Payments:

* Number of payments (both manual and computer generated) created and recorded in Payables.

* Invoice payments (number of invoice payments made by Payables - a payment document can pay multiple invoices).

* Average invoices per payment (number of payment documents divided by the number of invoice payments).

Matching holds:

* Matching holds (number of matching holds in Payables).

* Average matching holds per invoice on matching hold (number of matching holds divided by the number of invoices on matching hold).

Period End Process In General Ledger R12

Period End Process In General Ledger R12:

In Oracle General Ledger, an accounting period is closed after all the accounting transactions have been completed for the period. A closed period can be re-opened (provided it has not been permanently closed), if it is necessary to enter or modify accounting transactions for that period.

For most modules you can view and select one of the following:

* Never Opened - The period has never been used.

* Future Enterable - The period is open to accept transactions from other modules. Usually used where modules are maintained in different periods, and transactions are likely to be posted across modules.

* Open - Period is available for data entry

* Closed - Period is closed for processing, but can re re-opened if required.

* Permanently Closed - No further processing is possible.

Managers have the discretion to immediately close a period to prevent unauthorized processing, but be able to re-open periods for post processing adjustments. The periods can then be permanently closed as required, independent of the period/year end process.

Suggestion: Periods are usually only ‘finally closed’ when all adjustments and reporting requirements for the prior financial year are finalized.

Combined Basis Accounting:

If you have installed combined basis accounting, then the steps detailed below will need to be completed for both your accrual and cash Ledgers. This will mean that you will need to select the responsibility relevant to both Ledgers when completing these tasks. Depending on the Ledger set/Data Access Set attached to a responsibility, these tasks could be performed from a single responsibility. Procedures

The following steps are taken in performing period-end processing for Oracle General

Ledger.

1. Ensure the Next Accounting Period Status is set to Future Entry

Set the status of the next accounting period to ‘Future Entry’ if it is not already, except at year-end.

At year-end, it is recommended that you complete all period end processing, prior to opening the first period of the new financial year.

2. Complete Oracle Sub-ledger Interfaces to Oracle General Ledger

Journals are created to load accounting information into Oracle General Ledger. Journals are comprised of batch level, journal entry level, and journal entry line level, information. Ensure that the accounting information  from the sub-ledgers (Oracle Payables, Purchasing, Inventory, Order Management, Receivables, Cash Management, Assets, Treasury and Projects) have been transferred to Oracle General Ledger. Run Create Accounting program or the appropriate program (based on previous runs of Create Accounting) to transfer data from subledgers, into Oracle General Ledger. The Create Accounting process of SLA submits Journal Import Process (based on appropriate parameters as discussed in previous sections). This process populates the GL_JE_BATCHES, GL_JE_HEADERS, and GL_JE_LINES tables, and is run automatically.

Attention: The journal posting process, run in Oracle General Ledger, updates the GL_BALANCES table.

Journal Import:

* If not automatically completed, review the Journal Import Execution Report to identify which journal entry batches were not successfully imported.

* Delete any error journal entry batches. Determine the source(s) for these error batches, and retrieve the run ID from the Journal Import Execution Report.

* Make the necessary corrections - in the GL_INTERFACE table, via the Correct Journal Import Data window.

* Re-import these corrected journal entry batches from the GL_INTERFACE table. Simply re-enter the source from which journal entry batches are to be imported.

Note: If journal import fails when importing from the sub ledger modules, data will be rolled back to SLA tables, so that there would not be any data left in the GL_INTERFACE table, when the profile option ‘SLA:Disable Journal Import’ is set to ‘No’.

Attention: Leave sufficient time to re-import any journal entries not successfully imported from the feeder systems. Then update and post them.

3. Upload Journals from Web Applications Desktop Integrator (Web ADI) to Oracle General Ledger (Optional)

Journal information can also be imported from spreadsheets into Oracle General Ledger using Web ADI.

4. Complete Non-Oracle Sub-ledger Interfaces to Oracle General Ledger

(Optional: only required if you want to post from non-Oracle systems)

Following the same procedures as for Step 2:

* Ensure that the accounting information from any site specific, non-Oracle subledgers has been transferred to Oracle General Ledger.

* Run the Journal Import process for these sources and ensure the resulting Journal Entries are posted either automatically by AutoPost or manually.

Note: If you are loading accounting journals for 3rd party systems directly to Oracle General Ledger, use the GL_Interface. If you are using Oracle Financials Accounting Hub to generate accounting for your 3rd party systems, the accounting journal details will automatically by stored in the XLA tables, prior to being transferred (in summary or detail) and imported into Oracle General Ledger.

5. Generate Reversal Journals (Optional)

Select all the Journals to be reversed. Submit the process to generate the Reversal Journals. This process can be run across ledgers.

6. Generate Recurring Journals (Optional)

Select all the Recurring Journals that require generation for the current period. Submit the process to generate the Recurring Journals. This process can be submitted for foreign currency and for multiple ledgers, provided the access is available.

7. Generate Mass Allocation Journals (Optional)

Select the Mass Allocation Journals that require generation for the current period. Ensure that all entries to the source accounting flexfields used in the MassAllocation Journal definitions are finalized for the current period, prior to generating the journal. Post step-down allocations in the correct order (i.e. perform the calculation and post, for each successive level of allocation entry). This process can be run across ledgers

and across currencies.

8. Review and Verify Journal Details of Unposted Journal Entries

Review any remaining unposted journal entries for the current period. Update journal entries as appropriate.

Attention: Journal entries can be reviewed on-line, or via reports. Reviewing journal entries prior to posting minimizes the number of corrections and changes after posting. Following review of journal entry batches, perform any journal entry updates, including any adjusting entries, before posting.

Standard Journal reports available included:

a) Journal Batch Summary Report

b) Journals - General Report

c) Journals - Entry Report

d) Journals - Line Report

e) Tax Journals Report

f) General Ledger - Entered Currency

g) Journals by Document Number Report (when document sequencing is used)

9. Post All Journal Batches

Post all journal entries for the current period, including reversal, recurring and allocation journals.

Review the results of the post:

* The Posting Execution Report facilitates review of the results of journal entry posting. Oracle General Ledger generates this report every time posting of journal entry batches occurs. This report indicates any errors in journal entries or journal entry lines were discovered during the posting process.

* Run the Journals - General Report with a Posting Status of Error Journals to review error journal entry batches and their journal entries. Update unpostable journal entries. Locate the problems with unpostable journal entry batches using the following information:

a) Control Total

When using a control total, ensure that the debits and credits equal the control total.

b) Period Status

Post Actual batches to open periods.

Post Budget batches to any period in an open budget year.

Post Encumbrance batches to any period up to the last period in the latest open encumbrance year.

c) Batch Status

Oracle General Ledger describes the problems with unpostable batches.

Common reasons for unpostable batches are:

* Control total violations

* Posting to unopened periods

* Unbalanced journal entries

Attention: All errors in the journal entry batches must be fixed, and the corrected journal entries re-submitted for posting. Post updated journal entries.

9a. Run the Period Close Exceptions Report

This is a new step in Release 12. The General Ledger accounting can run the Period Close Exceptions report to double check that there are no outstanding transactions in the subledgers and GL, and ensure a follow-up with relevant colleagues if any exceptions are identified.

10. Run GL Trial Balances and Preliminary Financial Statement Generator Reports (FSGs)

To maintain a consistent audit trail, it is advisable to create a standard period-end accounting report set that can be run at each period end. Custom accounting reports can be created by using the ‘Financial Statement

Generator (FSG)’.

Suggestion: To prevent confusing different versions of accounting reports for a specific accounting period, discard any obsolete versions of your report for that accounting period. Request financial reports such as:

a) Balance Sheets e.g. Detail Trial Balance Report

b) Income Statements

c) Gross Margin Analysis

11. Revalue Balances (Optional)

Revalue account balances to update functional currency equivalents.

12. Translate Balances (Optional)

Define any new currencies to which accounting balances are to be translated. Maintain period-end exchange rates for all foreign currencies to which you want to translate. Maintain average exchange rates for all foreign currencies to which you want to translate. Maintain historical rates or amounts for any owner’s equity accounts to be translated. Translate account balances to any defined currency.

13. Consolidate Ledgers (Optional)

Attention: You can consolidate using Global Consolidation System, Financial Consolidation Hub or the Hyperion Consolidation functionality. Whichever you choose you can run your extract programs to extract the data from General Ledger to the consolidation systems.

* Consolidate within ledgers

a) Enter consolidating journal entries

The following two methods can be used to create eliminating entries for multiple companies using a single Ledger:

Automatic Eliminating Entries - define mapping rules to eliminated intercompany receivables, payables, investments in subsidiaries, intercompany sales etc. Recurring Journals- use formulas

b) Post consolidating journal entries.

c) Define a reporting hierarchy that consolidates all the companies.

d) Define financial statements with the reporting hierarchy.

Suggestion: To automatically generate the amounts and accounts for consolidating and eliminating journal entries, use recurring journal entry formulas.

Suggestion: To produce financial reports that reconcile your consolidating companies with the consolidated totals, enter the consolidating entries to a separate company, and build reports with a separate column for ‘consolidating entries’.

* Example of consolidation across ledgers when sharing same COA and Calendar

(Using Ledger Set and access granted via ‘Data Access Set’):

a) Define consolidated FSG

b) Perform revaluation and translations across ledgers

c) Enter consolidated and eliminating entries

d) Report on FSG by selecting the ledger set option while running

* Example of consolidation across ledgers using the Global Consolidation System

(GCS):

a) Define consolidations.

b) Perform revaluation and translation of foreign subsidiaries as required.

c) Run consolidations.

d) Enter consolidated and eliminating entries.

e) Report on this consolidated ledger using FSG’s.

f) Analyze results using drill-down capability from Parent ledger to Subsidiary

ledger/s.

Attention: All errors in the journal entry batches must be fixed, and the corrected journal entries re-submitted for posting.

13a. Reconcile Intercompany (optional)

Advanced Global Intercompany System in Release 12 provides more advanced features such as automatic generation of intercompany invoices in AP and AR, improved online reconciliation reporting, and is also fully integrated with SLA. A new, online reconciliation report provides drill-down to underlying sources and source journals for easy identification of reconciliation differences.

14. Review and Correct Balances (Perform Reconciliations)

Oracle General Ledger should be reconciled with all other modules. Adjust journals to correct any errors in the journals. Create and post adjusting journals to correct errors in account balances.

* Review Detail Account Balances On-line

* Review Account Balances via Reports

Request accounting reports such as general ledgers, general journals, trial balances, and accounts analysis reports to facilitate reconciliation of Oracle General Ledger with the other Financials and manufacturing modules.

a) General Ledger Reports

General Ledger Reports facilitate tracing back each transaction to the original source. These reports list beginning and ending account balances and all journal entry lines affecting each account balance. The report provides detailed information on each journal entry line including source, category and date.

b) Accounts Analysis Reports

These reports list the accumulated balances of a range of Accounting Flexfields and all journal entries that affect that range. Detailed information is provided for each journal entry line, which includes the source, batch name, and description.

c) Trial Balance Reports

Use trial balance reports to review account balances and activity in summary or detail.

d) Journal Reports

These reports print journal entry batches and include journal entry subtotals, and descriptions and reference information for each journal entry line. You can report on foreign currency, posted, unposted or error journal entries and report on a specific batch or on journal entries from a specific source.

* Journal Reconciliation:

General Ledger Entry Reconciliation lets you reconcile transactions in GL accounts that should balance to zero. With General Ledger Entry Reconciliation, you can selectively cross-reference transactions in GL with each other by entering reconciliation reference information at the journal line level. When the balance for

group of transactions is zero you can mark the transaction as reconciled.

* Clear Suspense Accounts

Examine the General Ledger and account analysis reports to identify the source of entries to the suspense accounts. Determine the adjusting entries required to net these accounts to zero.

Attention: If suspense accounting is not allowed, Oracle General Ledger will not post out-of-balance batches.

* Reconcile Subsidiary Ledgers

Identify differences between subsidiary ledgers and the General Ledger. Determine which differences are errors requiring adjustment to the General Ledger.

* Check other key system accounts have not been transacted by ad-hoc journals, for

example, Creditors Control, Debtors Control, Intercompany accounts, etc.

15. Enter Adjustments and / or Accruals and Post

To correct errors in account balances made by posting incorrect journals, create and post adjusting and reversing journals.

Attention: The details of posted journals cannot be changed, except to mark or unmark for reversal. An incorrectly entered posted journal must be reversed to back-out the accounting of the original posted journal.

Other journal entry adjustments, for example, write-offs (refer Accrual Write-Off Report), and manual accruals can be entered into Oracle General Ledger at this point also.

16. Perform Final Adjustments

Enter and Post any final adjustments as required by the organization.

17. Close the Current Oracle General Ledger Period

Close the current GL accounting period in the Open and Close Periods window. The period can be ‘soft closed’, if later adjustments to the balances for that period may be applicable, or ‘permanently closed’, which means that the period cannot be re-opened in the future.

This step will need to be repeated for each ledger unless a data access set is setup to give access to multiple ledgers. This is controlled by GL: Data Access Set profile option. With a data access set across ledgers programs can be run for multiple ledgers from a single responsibility.

18. Open the Next Oracle General Ledger Period

Open the next General Ledger accounting period in the Open and Close Periods window. This operation can be performed across ledgers provided ‘Data Access Set’ grants access.

Choose status ‘Open’ to open a new accounting period, or to re-open a previously soft closed period to enable adjustments to be made. Generate and post reversal journals that were entered in the prior period. For example any Oracle Purchasing receipted accruals and manual accruals. This step will need to be repeated for each ledger unless a data access set is setup to give access to multiple ledgers. Any Journals entered into this period while it had a status of Future Enterable, can now be posted as the period now has a status of Open. This is controlled by GL: Data Access Set profile option. With a data access set across ledgers programs can be run for multiple ledgers from a single responsibility.

19. Run Financial Reports for the Closed Period

Run a final Trial Balance Report.

Run final Financial Statement Generator Reports (FSG) or Report Sets as required by the organization including Income Statements and Balance Sheets. FSGs can also be published via the Application Desktop Integrator (ADI).

20. Run Reports for Tax Reporting Purposes (Optional)

A variety of standard reports can be used to provide tax information, which is required to be reported to the relevant Tax Authority, including withholding tax. The Financial Tax Register can be used to view the output from the Tax Reporting Ledger using Reports Exchange and Application Desktop Integrator (ADI). Using

these products you can change the layout of the report, publish the report in different formats, and export the data to a tab delimited or HTML file. The Tax Reporting Ledger consists of accounting information created in Oracle Receivables, Oracle Payables, and Oracle General Ledger. The Financial Tax Register uses this data to generate Tax Register reports using the Rxi reporting tool.

The following tax registers are available:

a) Deferred Output Tax Register

b) Recoverable and Non-Recoverable Tax Registers

c) Single Cross Product Tax Register

d) Standard Input and Output Tax Registers

21. Perform Encumbrance Year End Procedures (Optional)

Oracle Financials provides a number of facilities for the processing of outstanding encumbrances as part of year-end processing. The default processing for Oracle Financials at year end is to extinguish any outstanding encumbrances/ unused funds when you close the last period of the Financial Year within the General Ledger application.

The carry forward process enables managers to perform any of the following:

* Carry forward encumbrances for existing transactions (purchases/requisitions).

* Carry forward encumbrances, and the encumbered budget.

* Carry forward the funds available as at the end of the year. Other facilities available:

* Use mass allocations to bring forward part of the funds available.

* Carry forward budgets into the current appropriation budget, or to a separate budget to identify between current year and carry forward amounts if required. Mass budget processing also allows you to combine these budgets. To perform Encumbrance year-end procedures, including Carry Forward, you must complete each of the following steps:

a) Open the next encumbrance year

Use the Open and Close Periods window to open the next encumbrance year.

b) Open the next budget year

Use the Define Budget window to define a budget for the next budget period.

Attention: Ensure that the budget that you use is inclusive of the periods for the next budget year that you require

Attention: Ensure that the calendar periods for the next budget year have

been created prior to running this step. Verify that the next year budget figures have been entered. If you define a new budget for the purposes of the next year budgetary control, you may also need to update the

following:

Define Budget Organizations, where you have attached the funding budget to defined

account ranges within this form.

Define Summary Accounts, where summary templates are used as the basis for the budgetary control procedures.

c) Run Year End Carry Forward

This process enables you to determine the criteria that you want to use for carrying forward your encumbrances

The year-end carry forward is normally completed in two steps:

1) Perform the Year End Carry Forward in Preview mode

2) Perform the Year End Carry Forward without selecting the Preview option

Within the Year End Carry Forward form, you can select a wide range of criteria for carrying forward balances:

* Carry Forward Rule - This rule enables you to select Encumbrances Only,

Encumbrances and the Encumbered Budget, or Funds Available as the basis for the

Carry forward

* Encumbrance Type - Select ‘All’ for all encumbrances, or select the encumbrance

type that you require i.e. Commitment, Obligation etc.

* From/To Budget and Budget Organization- Select the budgets where they are

different

* Accounting Flexfield Ranges - Select the range of relevant accounting flexfields to

be carried forward.

How to enable and retrieve FND debug log messages [ID 433199.1] Free Hit Counters Starting in 11.5.10, FND has incorporated a debugging technique to enable debug messages to get stored into the table FND_LOG_MESSAGES. This method was introduced in 11.5.10 and it is available in subsequent releases. This note gives simple steps on how to enable and retrieve the debug messages. This method will pick up *all* debug messages from a particular log_sequence value. As such, it is particularly useful when you are having trouble retrieving the debug messages associated to a particular concurrent request, or user. However, if there are multiple users with FND debugging enabled running various processes, you could end up picking up debug messages pertaining to their activities.

Solution 1) set up profiles for the User / Responsibility to be used to reproduce the issue Profile Name Suggested value Comments FND: Debug Log Enabled YES This turns the debugging feature on FND: Debug Log Filename NULL Use when you want debug messages to get stored to a file FND: Debug Log Level STATEMENT Following are options listed from least to most detailed debugging : Unexpected, Error, Exception, Event, Procedure, Statement FND: Debug Log Module % Indicate what modules to debug. You can use something like 'ar%' or even '%arp_rounding%' to limit modules debugged Following are examples on how you would set the above profiles depending on what you want to debug : sample setting to debug everything : FND: Debug Log Enabled YES FND: Debug Log Filename NULL FND: Debug Log Level STATEMENT FND: Debug Log Module % sample setting to debug ONLY Receivables : FND: Debug Log Enabled YES FND: Debug Log Filename NULL FND: Debug Log Level STATEMENT FND: Debug Log Module ar%

2) Since the debugging routine will start writing messages to the table, we want to know which messages pertain to our test. If you are tracking the debug messages for a concurrent request, note down the Concurrent Request id. Otherwise, note down current max value of log sequence retrieved as follows : SELECT MAX(LOG_SEQUENCE) FROM FND_LOG_MESSAGES

 3) Run your test case, try to stay on track in reproducing the issue and leave out extraneous steps so that you don't end up with debug messages that are not relevant to your issue. It is ideal to not have anyone else using the Responsibility you have enabled debug for, so that only messages pertaining to your testcase are picked up.

 4) For ease of review by Development, spool the output of the following to a .xls spreadsheet : a) If you are debugging a concurrent process : SELECT log.module , log.message_text message FROM fnd_log_messages log, fnd_log_transaction_context con WHERE con.transaction_id = < request_id > AND con.transaction_type = 'REQUEST' AND con.transaction_context_id = log.transaction_context_id ORDER BY log.log_sequence; b) Otherwise, SELECT module, message_text FROM fnd_log_messages WHERE log_sequence > &max_log_from_step2 ORDER BY log_sequence; Or you may select all columns with: SELECT * FROM fnd_log_messages WHERE log_sequence > &max_log_from_step2 ORDER BY log_sequence;

P2P Tables

REQUISITIONS: SELECT * FROM PO_REQUISITION_HEADERS_ALL WHERE TYPE_LOOKUP_CODE='PURCHASE' AND TRUNC (CREATION_DATE) =TRUNC (SYSDATE) SELECT * FROM PO_REQUISITION_LINES_ALL WHERE TRUNC(CREATION_DATE)=TRUNC(SYSDATE) SELECT * FROM PO_REQ_DISTRIBUTIONS_ALL WHERE TRUNC(CREATION_DATE)=TRUNC(SYSDATE)
RFQ  SELECT * FROM PO_HEADERS_ALL WHERE TYPE_LOOKUP_CODE='RFQ' AND QUOTE_TYPE_LOOKUP_CODE='BID' AND TRUNC(CREATION_DATE)=TRUNC(SYSDATE) SELECT * FROM PO_LINES_ALL WHERE PO_HEADER_ID=110306 SELECT * FROM PO_LINE_LOCATIONS_ALL WHERE PO_HEADER_ID=110306
 QUOTATION SELECT * FROM PO_HEADERS_ALL WHERE TYPE_LOOKUP_CODE='QUOTATION' AND QUOTE_TYPE_LOOKUP_CODE='BID' AND TRUNC(CREATION_DATE)=TRUNC(SYSDATE) SELECT * FROM PO_LINES_ALL WHERE PO_HEADER_ID=110307 SELECT * FROM PO_LINE_LOCATIONS_ALL WHERE PO_HEADER_ID=110307
PURCHASE ORDER SELECT * FROM PO_HEADERS_ALL WHERE TYPE_LOOKUP_CODE='STANDARD' AND SEGMENT1='6025' SELECT * FROM PO_LINES_ALL WHERE PO_HEADER_ID=110308 SELECT * FROM PO_LINE_LOCATIONS_ALL WHERE PO_HEADER_ID=110308 SELECT * FROM PO_DISTRIBUTIONS_ALL WHERE PO_HEADER_ID=110308
 INVOICES SELECT * FROM AP_INVOICES_ALL WHERE INVOICE_NUM='1234' SELECT * FROM AP_INVOICE_LINES_ALL WHERE INVOICE_ID=211300 SELECT * FROM AP_INVOICE_DISTRIBUTIONS_ALL WHERE PO_DISTRIBUTION_ID IN(270850,270851) (OR) SELECT * FROM AP_INVOICE_DISTRIBUTIONS_ALL WHERE INVOICE_ID=211300
PAYMENT SELECT * FROM AP_INVOICE_PAYMENTS_ALL WHERE INVOICE_ID=211300 SELECT * FROM AP_PAYMENT_SCHEDULES_ALL WHERE INVOICE_ID=211300 SELECT * FROM AP_CHECKS_ALL WHERE CHECK_NUMBER=6396 SELECT * FROM AP_CHECK_FORMATS SELECT * FROM AP_PAYMENT_HISTORY_ALL WHERE CHECK_ID=77530 SELECT * FROM AP_BANK_ACCOUNTS_ALL SELECT * FROM AP_BANK_BRANCHES SELECT * FROM AP_TERMS_TL WHERE TERM_ID='10002' SELECT * FROM AP_TERMS_LINES WHERE TERM_ID='10002' SELECT * FROM AP_HOLDS_ALL

R12 Procure to Pay Process flow(P2P)

R12 Procure to Pay Process flow(P2P)

R12 Order to Cash flow(O2C)

R12 Order to Cash flow(O2C)

Tips on Exporting your Oracle Applications Reports to Excel

Tips on Exporting your Oracle Applications Reports to Excel.