24/3/2014

Document Display

R12 How To Diagnose And Reconcile Inventory AP Accrual Transactions Using Reconciliation Reports (Doc ID 728871.1)
Modified: 06-Feb-2014 Type: TROUBLESHOOTING

In this Document Purpose Troubleshooting Steps INTRODUCTION TESTCASE INFORMATION FUNCTIONALITY SETUP PROCESSING OVERVIEW Join Us Still Have Questions? References

APPLIES TO:
Oracle Purchasing - Version 12.0 to 12.0.4 [Release 12] Oracle Payables - Version 12.0.0 and later Information in this document applies to any platform. CSTCRACCRCV: Create Accounting -Receiving CSTGLTRN: Transfer to GL concurrent program CSTACRLR: Accrual Reconciliation Load Program ***Checked for relevance on 19-Aug-2013*** Reviewed by JAdjei CSTACRSM: Summary Accrual Reconciliation Report CSTACRAP: AP and PO Accrual Reconciliation Report CSTACRMI : Miscellaneous Accrual Reconciliation Report CSTACRWO: Accrual Write-Off Report POXACWRO: WIP Accrual Write-Off Report

PURPOSE
This document is intended to help understand and analyze the Functional changes in Release 12 Reconciliation Process with regard to Inventory Accrual Transactions. The new architecture is designed to improve performance, enhance usability,ensure audit ability and facilitate automation of various Forms and Reports. For Step by Step Reconciliation Process please Review Note.1107953.1 - R12 Accrual Balance Mismatch Between Accrual Reconciliation Report and GL - Troubleshooting

TROUBLESHOOTING STEPS
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9 1/13

24/3/2014

Document Display

INTRODUCTION
The Release 12 Accrual Reconciliation and write-off is a new feature set compared to 11i. It is based on the concept of incremental build and group by balance of po distributions. The new concept of doing reconciliation and writing off by balance of po distributions requires a mindset shift from the traditional 11i approach that is based on individual transactions. With this new concept, the GL date of individual transactions becomes less significant. The reconciliation unit has shifted from transaction_date (traditional approach) to po_distribution_id (new approach). This makes it easier to reconcile PO's at the lowest po denominator-the distributions. The Primary focus of the Reconciliation Reports has shifted from reconciling aggregate balance of GL Accrual Accounts to analyzing and verifying distribution balances of the PO. If the distribution, the lowest po denominator is correct the aggregate figure will be correct. The Net Accrual balance in the AP and PO Reconciliation Report at any given time excluding Manual Journals in GL should equal the current Net Accrual balance in GL. Since the Report displays only the CURRENT net accrual balances of po distributions, 'AS OF DATE' Balance will Always reflect current Net balance of the po distributions and that explains why there is no Date Parameter in the Report. The new Accrual philosophy requires customers to reconcile and complete their Accrual Reconciliations monthly. Do not run the Load Program of the next Period unless the previous month reconciliation is completed. The new architecture is designed to improve performance (dynamic reconciliation incrementally, grouped by accrual account and po_distribution_id), Enhance Usability (automatic updates to GL for write offs, mass write offs and reversal transactions), Ensure Audit ability (Audit Trail for dynamic Transactions and write offs) and facilitate Automated Process (various Forms and process). Problems of old art Performance problem, not scalable Advantages of new art Improved performance - dynamic reconciliation incrementally, grouped by accrual account and po_distribution_id Enhanced usability - write off balance, utilization of write-off and reversal txns, mass write-off Ensured audit ability - persistent write-off tables, accounting against each write-off and reversal txn Automated process - various forms and reports

Low usability

Not audit-able

Not automated

In this paper we will examine the functional changes in R12 Reconciliation Process and the architectural components, namely the Accrual Load Program and the The Reconciliation Reports: Accrual Reconciliation Summary Report, AP and PO Accrual Reconciliation Report, the Miscellaneous Accrual Reconciliation Report, and the Accrual Write Off functionality. We will also examine the basic setups, debugging tools, give a processing overview, and other essential diagnostic queries and relevant patches. Please Review Note.1107953.1 - R12 Accrual Balance Mismatch Between Accrual Reconciliation Report and GL - Troubleshooting

TESTCASE INFORMATION
The following steps give an example testcase and should be used to validate the proper steps are being used; Create Inventory Destination Transaction or Expense Destination Transaction 'Accrue On Receipt' Approve and Receive the PO Verify the Transactions in the RCV_TRANSACTIONS table Review the Accounting Entries in RCV_RECEIVING_SUB_LEDGER table. These Transactions will have ACCRUAL_METHOD_FLAG='O'
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9 2/13

24/3/2014

Review the Accounting Entries in RCV_RECEIVING_SUB_LEDGER table. These Transactions will have ACCRUAL_METHOD_FLAG='O' Run Create Accounting -Receiving process Review the Subledger Accounting Entries in View Subledger Journal Entry Inquiry Screen Run and Review Subledger Accounting Program Report Review the Journals in GL Review the Transactions in Account Analysis Report At the end of each period, make sure all receipt and invoice accounting entries are transferred to GL, and no new accounting will come into the period. Then run the accrual load program incrementally with a 'From Date' to be last period's end date minus some overlapping days and a 'To Date' to be this period's end date If there are receipts not invoiced or vice versa, the corresponding PO distribution will have a non-zero balance and show up in the report with accounting details that contribute to the balance Those accounting details are pulled from SLA and should match with GL. The user can start with Accrual Reconciliation Summary Report and then drill down to AP and PO Accrual Reconciliation Report, Miscellaneous Accrual Reconciliation Report For PO distributions with an outstanding accrual balance, the customer makes a decision on whether to write the balance off in this period or wait for more accounting data to come in next period Reconcile your Inventory AP Accrual Account in GL

Document Display

FUNCTIONALITY
In this Section, we will contrast the 11i Reconciliation process against the R12 approach, so to highlight the drawbacks of the old system and advantages of the new one. The new design of Reconciliation process ("new Art") was introduced in R12 because of the serious drawbacks and failures in the previous Reconciliation process in R11i ("old Art"). In the old Art the Reconciliation Rebuild retrieved data by transaction date and accrual_account_id. All Po's with transactions that fell within the relevant date range were retrieved and populated the PO_ACCRUAL_RECONCILE_TEMP_ALL Table. The Rebuild loaded both fully invoiced,partially invoiced and uninvoiced PO Transactions to the temp Table. Also loaded were transactions already written off marked with write_off_flag ='Y'. The result was an unbearable serious performance issues. In the old Art The Reconciliation Reports Reported by po lines. All transactions relating to a Line were reported so long as a single distribution did not Net to Zero . This resulted in reporting of many seemingly self balanced lines making the Report too cumbersome and extremely difficult to read and analyze. In the old art the focus was on reconciling the aggregate Net balance to GL rather than isolating and analyzing distributions that caused the discrepancy. Finally in the old art Accrual Write Offs removed transactions only from the Accrual Reconciliation Report and users had to do Manual Journal entries in Gl. Manual Journals are prone to mistakes and raise eyebrows of Auditors for lack of verifiable data and audit trail. The new Art provides the following advantages; The new Art concentrates on the lowest PO denominator - PO distribution rather than lines and aggregate totals The Load Program uses the 'To Date' parameter as the cut off date to retrieve only po_distribution_ids with net balance. It is based on the concept of incremental build and group by balance of po distributions. Therefore fully invoiced distributions will be excluded. Thus performance is improved. The Load program populates the CST_AP_PO_RECONCILIATION and CST_RECONCILIATION_SUMMARY Tables. The New Reconciliation Reports will only show dynamically only distributions with balances as loaded in the CST_AP_PO_RECONCILIATION and CST_RECONCILIATION_SUMMARY Tables. Thus only relevant data that directly affects the current Net Accrual Balance is reported The basic unit of reconciliation is the PO Distribution and not individual transactions anymore. Hence it is the age of of PO distributions that matters,not the transaction date of the whole Transaction. Accrual Write Off not only excludes the write off transaction from the AP and PO Report but also dynamically post to GL and excluded from the Net Accrual balance. Therefore the problems associated with Manual Journals are avoided. The AP and PO Reconciliation Report should only be used for reconciling current balances because data in CST_AP_PO_RECONCILIATION and CST_RECONCILIATION_SUMMARY Tables reflect only Net Distribution balances. Below we will contrast in more details how the old Art and New Art appear in the Reconciliation Tables when the Rebuild (old) and Load (new) programs are run respectively.
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

Let us assume we have two PO's PO#1 and PO#2

3/13

24/3/2014

Let us assume we have two PO's PO#1 and PO#2 Let us assume further that for every transaction we have 1 Line and I distribution. Period#1 Jan 2005 (For easy analysis let us presume for each PO) PO Price $10 Quantity Ordered 10 in 1/1/2005 Quantity Received 5 in 1/1/2005 Quantity Invoiced 5 for PO#1 on 1/31/2005 Quantity Invoiced 4 for PO#2 on 1/31/2005 Period#2 Feb 2005 Quantity Received 5 for PO#1 2/1/2005 Quantity Invoiced 4 fro PO#1 2/28/2005 Quantity Received 5 for PO#2 2/1/2005 Quantity Invoiced 6for PO#2 2/28/2005

Document Display

Old Art When the Accrual Rebuild is run on 1/31/2005 after invoicing the following data will be retrieved to AP_ACCRUAL_RECONCILE_TEMPS_ALL First period: Jan-2005; accrual_account po_num ACCT#1 ACCT#1 PO#1 PO#1 po_distribution_id txn_date D#1 D#1 1/1/2005 1/31/2005 txn_source Receipt Invoice receipt_num invoice_num qty R#1 V#1 5 5 amount -50 50 write_off_flag -

ACCT#1 ACCT#1

PO#2 PO#2

D#2 D#2

1/1/2005 1/31/2005

Receipt Invoice

R#2 -

V#2

5 4

-50 40

Y Y

Note: PO#1 is self balanced ie fully invoiced but still loaded to the PO_ACCRUAL_RECONCILE_TEMPS_ALL PO#2 has a balance of 10. Second period: Feb-2005; accrual_account po_num ACCT#1 ACCT#1 ACCT#1 ACCT#1 PO#1 PO#1 PO#1 PO#1 po_distribution_id txn_date D#1 D#1 D#1 D#1 1/1/2005 1/31/2005 2/1/2005 2/28/2005 txn_source Receipt Invoice Receipt Invoice receipt_num invoice_num qty R#1 V#1 R#3 V#3 5 5 5 4 amount -50 50 -50 40 write_off_flag Y Y

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

ACCT#1

PO#2

D#2

1/1/2005

Receipt

R#2

-50

4/13

24/3/2014

Document Display

ACCT#1 ACCT#1 ACCT#1 ACCT#1

PO#2 PO#2 PO#2 PO#2

D#2 D#2 D#2 D#2

1/1/2005 1/31/2005 2/1/2005 2/28/2005

Receipt Invoice Receipt Invoice

R#2 V#2 R#4 V#4

5 4 5 6

-50 40 -50 60

? ? ? ?

Comments: At end of second Period : Feb-2008 the above transactions will exist in PO_ACCRUAL_RECONCILIATION TABLE after the Rebuild is run. a) Despite the fact that PO#1 Transactions for Jan-2005 are self balancing (Fully Invoiced) they still exist in the PO_ACCRUAL_RECONCILE_TEMPS_ALL b) In the above examples for simplicity we assumed that PO#1 had 1 line and 1 Distribution. Let us be more pragmatic and assume like in most businesses where lines have multiple distributions that PO#1 had 1 line and 8 distributions and 6 of the 8 distributions were self balancing ie fully invoiced. The Rebuild will still load all 8 Distributions and will remain in the PO_ACCRUAL_RECONCILIATION TABLE c) Let us even assume further that a PO had one Line and 80 Distributions and 79 of the Distributions were fully invoiced guess what all 80 Distributions will be loaded and continue to exist in the PO_ACCRUAL_RECONCILE_TEMPS_ALL TABLE d) If we decided in the Example for PO#2 to write off all 10 outstanding Transactions and PO#2 became self balancing, all quantities including the written off amounts will still be retrieved and continue to exist in the PO_ACCRUAL_RECONCILE_TEMPS_ALL TABLE. The written off Transactions will be tagged with Write_Off_Flag ='Y' and will continue to exist in the TEMP Table e) Data therefore keeps growing in the TEMP TABLE developing serious performance problems. Most of the Data existing in the Temp Table is irrelevant and obsolete and have no impact in determining the Net Accrual Balance in GL. This indeed is a very inefficient way of storing data. f) ACCRUAL RECONCILIATION REPORT - In our example above where we presumed a PO had 1 Line and 80 Distributions if 79 of the Distributions were fully invoiced if we run the Accrual Reconciliation Report all Transactions of the line would still appear in the Report despite the fact that only one distribution had a Net balance that contributed to the Balance of the Accrual Account in GL. New Art Let us now contrast this with the New Art. We will assume the same data as we used for the Old Art. This is how the data will appear in the new Tables CST_AP_PO_RECONCILIATION and CST_RECONCILIATION_SUMMARY when the New Load Program is run: First period: Jan-2005 Reconciliation summary accrual_account po_num ACCT#1 Reconciliation details
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

po_distribution_id RCV_balance D#2 -50

AP_balance 40

WO_balance 0

total_balance -10

write_off checkbox X

PO#2

accrual_account po_distribution_id txn_date

txn_source

receipt_num

invoice_num

write_off_id

qty

amount

5/13

24/3/2014

Document Display

accrual_account po_distribution_id txn_date ACCT#1 ACCT#1 D#2 D#2 1/1/2005 1/31/2005

txn_source Receipt Invoice

receipt_num R#2 -

invoice_num V#2

write_off_id -

qty 5 4

amount -50 40

Comment : Only unbalanced PO distributions will be in the reconciliation tables. Lean and scalable. At this point, PO#1 is self-balanced so it will not be loaded into the tables. Only PO#2 is in the tables. Customers can use the write_off checkbox to write off balance. They could also do mass write-off based on the tolerance. Assuming they choose to write off the balance for PO#2, the write-off will immediately make PO#2 balanced. PO#2 and its details will disappear from the reconciliation tables. Dynamic reconciliation. The write-off txn and its details will be generated. The automated accounting is done against the write-off txn. The data in write-off tables is persistent. There is a track record, audit-able.

Write-off summary write_off_id accrual_account po_num po_distribution_id write_off_date reversal_id write_off_type wo_amount write_off_reason reverse checkbox W#1 ACCT#1 PO#2 D#2 1/31/2005 write off 10 under invoice X

Write-off details write_off_id W#1 W#1 txn_date 1/1/2005 1/31/2005 txn_source Receipt Invoice receipt_num R#2 invoice_num V#2 qty 5 4 amount -50 40

Suppose a mistake is made in the write-off, use the reverse checkbox to reverse it. The reversal txn will have its own accounting and transaction details. It also points to its original write-off txn. Auditable again. Write-off summary write_off_id accrual_account po_num po_distribution_id write_off_date reversal_id write_off_type wo_amount write_off_reason reverse checkbox W#1 W#2 ACCT#1 ACCT#1 PO#2 PO#2 D#2 D#2 1/31/2005 1/31/2005 W#1 write off write_off reversal 10 -10 under invoice made a mistake -

Write_off details write_off_id W#1 W#1 txn_date 1/1/2005 1/31/2005 txn_source Receipt Invoice receipt_num R#2 invoice_num V#2 qty 5 4 amount -50 40
6/13

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

24/3/2014

W#1 W#2 W#2

1/31/2005 1/1/2005 1/31/2005

Invoice Receipt Invoice

R#2 -

Document Display

V#2 V#2

4 5 4

40 -50 40

As soon as the reversal is done, the PO#2 becomes unbalanced again and it comes back to the reconciliation tables. Dynamic reconciliation again. Both write-off and its reversal contribute to the total balance of a PO distribution. Reconciliation summary accrual_account po_num ACCT#1 Reconciliation details accrual_account po_distribution_id txn_date ACCT#1 ACCT#1 ACCT#1 ACCT#1 D#2 D#2 D#2 D#2 1/1/2005 1/31/2005 1/31/2005 1/31/2005 txn_source Receipt Invoice Write-off Write-off reversal receipt_num R#2 invoice_num V#2 write_off_id W#1 W#2 qty 5 4 amount -50 40 10 -10 PO#2 po_distribution_id RCV_balance D#2 -50 AP_balance 40 WO_balance 0 total_balance -10 write_off checkbox -

Second period: Feb-2005 When new txns for both PO#1 and PO#2 come in Feb, the new data actually makes PO#2 balanced, so it comes off the reconciliation tables. However, the new data for PO#1 makes it unbalanced for the first time, so we will load all its txns. Reconciliation summary accrual_account po_num ACCT#1 Reconciliation details accrual_account po_distribution_id txn_date ACCT#1 D#1 1/1/2005 txn_source Receipt receipt_num R#1 invoice_num write_off_id qty 5 amount -50 PO#1 po_distribution_id RCV_balance D#1 -100 AP_balance 90 WO_balance 0 total_balance -10 write_off checkbox -

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

7/13

24/3/2014

ACCT#1 ACCT#1 ACCT#1 ACCT#1

D#1 D#1 D#1 D#1

1/1/2005 1/31/2005 2/1/2005 2/28/2005

Receipt Invoice Receipt Invoice

Document Display

R#1 R#3 -

V#1 V#3

5 5 5 4

-50 50 -50 40

The data in write-off tables remain. So at the end of second period, we have data in reconciliation tables for PO#1 that need to be taken care of. We also have data in write-off tables for PO#2 for legal and auditing purpose. For normal business, over the time most POs should be self-balanced and write-off would be needed only for a small portion of problematic POs. Therefore, we will have lean reconciliation tables and manageable size of write-off tables.

Reports to use for Reconciling GL Accrual Balance a) AP and PO Reconciliation Report The new Architecture requires Customers to complete each months Reconciliation before moving to the next Period. The AP and PO Reconciliation Report, even though the primary focus is reconciling po_distribution amounts it can be used by customers to reconcile CURRENT Months inventory Accruals. By design the Report retrieves data from CST_AP_PO_RECONCILIATION and CST_RECONCILIATION_SUMMARY which only stores the Net po_distribution amounts. The Net Balance per Accrual Account displayed by the Report should reconcile with current Net Accrual Balance in GL excluding manual journals. There is currently no mechanism to purge data yet if the user has earlier run the report for a longer time span, but then wanted to go back and unload the data for certain time span. A workaround that could be use would be the following: 1. Delete from CST_AP_PO_RECONCILIATION where OPERATING_UNIT_ID=&your_ou_id; 2. Delete from CST_reconciliation_summary where OPERATING_UNIT_ID=&your_ou_id; 3. Rerun the accrual load program with a prior 'To Date'. b) The Open Account Balances Listing This is documented in Chapter 9 of SLA Implementation Guide in conjunction with View Subledger Journal Entry Inquiry and SubledgerAccounting Program Report can be used to reconcile SLA Transactions and GL. The SLA Reports are based on XML Publisher and give user certain flexibility to configure the Reports

SETUP
To achieve the best results for 'Accrue_ON_Receipt' Transactions the following minimal setups are recommended: The Purchasing Options Form allows users to set Expense items to accrue on 'On Receipt' or 'At Period End. Nav:Purchasing Super User/Setup/Organizations/Purchasing Options`/AccrualSetup The Inventory AP Accrual Account defaults from Inventory Responsibility/ Setup/Organization/Parameters/Other Accounts/Inventory AP Accrual Account
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

Defaulting Rules for Accrue_on_receipt_flag

8/13

24/3/2014

Document Display

Defaulting Rules for Accrue_on_receipt_flag Oracle inserts the accrue on receipt flag in po distributions based on the following logic If the destination_type_code = 'INVENTORY' OR 'SHOP FLOOR' then the value of accrue on receipt flag will be Yes If the destination_type_code = 'EXPENSE' we check the value of the receipt_required_flag at the item level Line Type Vendor System parameters(in that order) If the value is N , then accrue on receipt flag will be No else if accrual mode is PERIOD END then accrue on receipt flag will be No. if accrual mode is RECEIPT then accrue on receipt flag will be YES. Also of course the User can override 'Accrue_On_Receipt_Flag' at Po Shipment If Expenses accrue On Receipt at PO Options. Disable Journal Import in Edit/Preferences: Profile: 'NO' means Create Accounting automatically activates Transfer to GL Concurrent Program Value. If Profile is set to 'YES' then Journal Import has to be run separately to move the accounting entries to GL. The following Accounts set up is required for all Accrual Accounts to be used in the Reconciliation Reports and Write Off. Navigate: Purchasing Responsibility: Accrual Write Offs/Select Accrual Accounts.

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

9/13

24/3/2014

Document Display

PROCESSING OVERVIEW
Accrue_On_ Receipt in R12 is a process that must be carefully reviewed and implemented. There are different components of the process and each performs a separate function in moving and verifying the Transactions from the PO Tables to RCV_RECEIVING_SUB_LEDGER to SLA and finally to GL

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

10/13

24/3/2014

Document Display

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

11/13

24/3/2014

Document Display

The following gives some of the key code and configurations used during the processing; Receiving Transaction Processor populates the RCV_RECEIVING_SUB_LEDGER with Receiving Transactions with ACCRUAL_METHOD_FLAG='O'. These Transactions must have accrue_on_receipt_flag ='Y' CSTCRACCRCV- Create Accounting -Receiving moves the Inventory Transactions with Accrual_ Method_flag ='O' from RCV_RECEIVING_SUB_LEDGER to SLA Tables. These Transactions must meet the criteria for EVENT CLASS Journal Category 'Receiving' CSTCRACCRCV may also automatically kick off Journal Import and Transfer to GL concurrent program if the parameters: Transfer and Post to General Ledger ='Y'. CSTACRLR module: Accrual Reconciliation Load Program populates the following Tables: CST_RECONCILIATION_BUILD:Track of 'Accrual Build' CST_RECONCILIATION_SUMMARY:Data summarized based on PO_DISTRIBUTION_ID only for AP and PO Reconciliation. The Table stores po_distribution_id,accrual_account_id,PO Balance,AP Balance and Write Off Balance CST_AP_PO_RECONCILIATION: AP and PO Accrual Journals. The Table stores Transaction_Type_Code,Accrual_Account_id,Po_distribution_id,invoice_id,RCV_Transaction_id,write_off_id,Ae_header_id,Ae_line_num, Quantity Received, AP Po Match, Amount Received and Amount Matched CST_MISC_RECONCILIATION:INV miscellaneous and AP miscellaneous data The following Tables store Write Off Data: CST_WRITE_OFFS and CST_WRITE_OFF DETAILS CSTACRLR module: Accrual Reconciliation Load Program The Load program is used to to populate the accrual reconciliation tables with all the necessary transaction data needed to perform the reconciliation process. Running this program is normally the first step in the reconciliation process. The program parameters From date and to date can be used to fetch the transaction information from the transaction tables. All the affected Po distributions (in the case of AP/PO transactions and individual transactions in case of miscellaneous transactions) within the date range wil be deleted first and current/updated values for the transactions in the date range will be fetched and appended to existing data in the Tables. Note that already existing data not falling within the date range will remain intact. When the accrual load program is run for the first time for a given Operating unit,old write off transactions for that operating unit (write offs from prior releases) are upgraded and loaded into the new reconciliation tables. "The from date" for this very first run is ignored and the load runs from the start of transaction history to the current system date (or the "to date" provided by user). Additionally you cannot reverse write off transactions that were written off in prior releases. After running the Load program each of the remaining Reports can be run independently of each other. CSTACRSM module: Summary Accrual Reconciliation Report The purpose of the Accrual Reconciliation Summary Report is to show users which accounts have balances in them. The report will also give a partial breakdown of the balance source. Users can see whether related AP and PO transactions and/or miscellaneous AP and inventory transactions are contributing to the balance. Furthermore, the report will show users the amount of write-offs already performed against the accrual account. CSTACRAP module: AP and PO Accrual Reconciliation Report This Report has no date range because it at any given time only display the Net balances of the current po_distributions. The AP and PO Accrual Reconciliation Report,displays the transactional breakdown of each accrual account with a net balance greater than 0. The report will also allow users to view a summarized version or full transaction details. In summarized mode, for each accrual account, only the distribution information and PO, AP, WO (Write-Off) and Total Balances will be displayed. For detailed mode, the individual transaction details for each distribution will be shown in addition to all the distribution information CSTACRMI module: Miscellaneous Accrual Reconciliation Report The Miscellaneous Accrual Reconciliation Report displays all the miscellaneous AP (not matched to PO) and inventory transactions hitting accrual accounts. The report is first grouped by accrual account, then by each accrual code that hits the specific accrual account and then by purchase order distribution id. Within the accrual code (A/P No PO, Miscellaneous Receipt, etc), the individual transactions are displayed.
https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9 12/13

24/3/2014

Miscellaneous Receipt, etc), the individual transactions are displayed. CSTACRWO module: Accrual Write-Off Report This Report lists the Transactions marked as written off in the Accrual Write Off window. Use the AP and PO Accrual Write Offs window to indicate which AP and PO transactions you wish to write off and remove from the AP and PO Accrual Reconciliation Report POXACWRO module: WIP Accrual Write-Off Report This Report lists WIP Transactions written off.

Document Display

Join Us

Join our conversation today on this note via the direct Procurement Community link at https://community.oracle.com/thread/3370368

Still Have Questions?

Join our growing Oracle Procurement Community and learn from your peers and Oracle on how to address your unique issues in Procurement. You can access the main Oracle Communities page at http://communities.oracle.com (If you are enrolled, the Procurement community will be listed on your left. If you're not already enrolled in the Procurement community, you can do so by clicking on the link Edit Subscriptions). OR From "My Oracle Support" as follows: 1. 2. 3. 4. 5. Log into My Oracle Support Click on the 'Community' link at the top of the page Click in 'Find a Community' field and enter Procurement Double click on Procurement in the list Click on the 'Create a Community Post' button and submit your question.

REFERENCES
NOTE:222339.1 - Procurement Family Patch Release History NOTE:558421.1 - How To Diagnose Issues With Create Accounting Process For Procure To Pay Cycle In R12 NOTE:603971.1 - R12 How To Diagnose Issues with Period End Accruals

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=14atgt8np2_9

13/13