R12 How to Diagnose and Reconcile AAP 728871.1

24/3/2014 Document Display

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

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 laterInformation in this document applies to any platform.CSTCRACCRCV: Create Accounting -ReceivingCSTGLTRN: Transfer to GL concurrent programCSTACRLR: Accrual Reconciliation Load Program***Checked for relevance on 19-Aug-2013*** Reviewed by JAdjei

CSTACRSM: Summary Accrual Reconciliation ReportCSTACRAP: AP and PO Accrual Reconciliation ReportCSTACRMI : Miscellaneous Accrual Reconciliation ReportCSTACRWO: Accrual Write-Off ReportPOXACWRO: 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 newarchitecture 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/DocumentDisplay?id=1107953.1



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 individualtransactions. With this new concept, the GL date of individual transactions becomes less significant. The reconciliation unit has shifted from transaction_date (traditional approach) topo_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. Ifthe 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 timeexcluding 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 OFDATE' 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 previousmonth reconciliation is completed.

The new architecture is designed to improve performance (dynamic reconciliation incrementally, grouped by accrual account and po_distribution_id), Enhance Usability (automaticupdates 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 Advantages of new art

Performance problem, not scalable Improved performance - dynamic reconciliation incrementally,grouped by accrual account and po_distribution_id

Low usability Enhanced usability - write off balance, utilization of write-offand reversal txns, mass write-off

Not audit-able Ensured audit ability - persistent write-off tables, accountingagainst each write-off and reversal txn

Not automated Automated process - various forms and reports

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 POVerify the Transactions in the RCV_TRANSACTIONS tableReview the Accounting Entries in RCV_RECEIVING_SUB_LEDGER table. These Transactions will have ACCRUAL_METHOD_FLAG='O'




Review the Accounting Entries in RCV_RECEIVING_SUB_LEDGER table. These Transactions will have ACCRUAL_METHOD_FLAG='O'Run Create Accounting -Receiving processReview the Subledger Accounting Entries in View Subledger Journal Entry Inquiry ScreenRun and Review Subledger Accounting Program ReportReview the Journals in GLReview the Transactions in Account Analysis ReportAt 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 dateIf 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 thatcontribute to the balanceThose 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 ReportFor 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 tocome in next periodReconcile your Inventory AP Accrual Account in GL

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 newdesign 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 wereretrieved and populated the PO_ACCRUAL_RECONCILE_TEMP_ALL Table. The Rebuild loaded both fully invoiced,partially invoiced and uninvoiced PO Transactions to the tempTable. 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 . Thisresulted 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 totalsThe 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 andgroup by balance of po distributions. Therefore fully invoiced distributions will be excluded. Thus performance is improved. The Load program populates theCST_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 andCST_RECONCILIATION_SUMMARY Tables. Thus only relevant data that directly affects the current Net Accrual Balance is reportedThe 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 ofthe 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. Thereforethe 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 andCST_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.

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



Let us assume we have two PO's PO#1 and PO#2Let 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

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 po_distribution_id txn_date txn_source receipt_num invoice_num qty amount write_off_flag

ACCT#1 PO#1 D#1 1/1/2005 Receipt R#1 - 5 -50 -

ACCT#1 PO#1 D#1 1/31/2005 Invoice - V#1 5 50 -

ACCT#1 PO#2 D#2 1/1/2005 Receipt R#2 - 5 -50 Y

ACCT#1 PO#2 D#2 1/31/2005 Invoice - V#2 4 40 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 po_distribution_id txn_date txn_source receipt_num invoice_num qty amount write_off_flag

ACCT#1 PO#1 D#1 1/1/2005 Receipt R#1 - 5 -50 -

ACCT#1 PO#1 D#1 1/31/2005 Invoice V#1 - 5 50 -

ACCT#1 PO#1 D#1 2/1/2005 Receipt R#3 - 5 -50 Y

ACCT#1 PO#1 D#1 2/28/2005 Invoice V#3 - 4 40 Y

ACCT#1 PO#2 D#2 1/1/2005 Receipt R#2 - 5 -50 ?




ACCT#1 PO#2 D#2 1/31/2005 Invoice V#2 - 4 40 ?


ACCT#1 PO#2 D#2 2/28/2005 Invoice V#4 - 6 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 havemultiple 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 andwill 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 andcontinue 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 stillbe 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 continueto 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 andhave 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 werun 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 contributedto 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 TablesCST_AP_PO_RECONCILIATION and CST_RECONCILIATION_SUMMARY when the New Load Program is run:

First period: Jan-2005

Reconciliation summary

accrual_account po_num po_distribution_id RCV_balance AP_balance WO_balance total_balance write_offcheckbox

ACCT#1 PO#2 D#2 -50 40 0 -10 X

Reconciliation details

accrual_account po_distribution_id txn_date txn_source receipt_num invoice_num write_off_id qty amount




ACCT#1 D#2 1/1/2005 Receipt R#2 - - 5 -50

ACCT#1 D#2 1/31/2005 Invoice - V#2 - 4 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 isin 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 ispersistent. 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 reversecheckbox

W#1 ACCT#1 PO#2 D#2 1/31/2005 - write off 10 under invoice X

Write-off details

write_off_id txn_date txn_source receipt_num invoice_num qty amount

W#1 1/1/2005 Receipt R#2 - 5 -50

W#1 1/31/2005 Invoice - V#2 4 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 reversecheckbox

W#1 ACCT#1 PO#2 D#2 1/31/2005 - write off 10 under invoice -

W#2 ACCT#1 PO#2 D#2 1/31/2005 W#1 write_offreversal

-10 made a mistake -

Write_off details

write_off_id txn_date txn_source receipt_num invoice_num qty amount

W#1 1/1/2005 Receipt R#2 - 5 -50

W#1 1/31/2005 Invoice - V#2 4 40



W#1 1/31/2005 Invoice - V#2 4 40

W#2 1/1/2005 Receipt R#2 - 5 -50

W#2 1/31/2005 Invoice - V#2 4 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.



ACCT#1 PO#2 D#2 -50 40 0 -10 -



ACCT#1 D#2 1/1/2005 Receipt R#2 - - 5 -50

ACCT#1 D#2 1/31/2005 Invoice - V#2 - 4 40

ACCT#1 D#2 1/31/2005 Write-off - - W#1 - 10

ACCT#1 D#2 1/31/2005 Write-offreversal

- - W#2 - -10

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#1makes it unbalanced for the first time, so we will load all its txns.



ACCT#1 PO#1 D#1 -100 90 0 -10 -



ACCT#1 D#1 1/1/2005 Receipt R#1 - - 5 -50



ACCT#1 D#1 1/1/2005 Receipt R#1 - - 5 -50

ACCT#1 D#1 1/31/2005 Invoice - V#1 - 5 50

ACCT#1 D#1 2/1/2005 Receipt R#3 - - 5 -50

ACCT#1 D#1 2/28/2005 Invoice - V#3 - 4 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 theprimary 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 NetBalance 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 certaintime 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/PurchasingOptions`/AccrualSetup

The Inventory AP Accrual Account defaults from Inventory Responsibility/ Setup/Organization/Parameters/Other Accounts/Inventory AP Accrual Account

Defaulting Rules for Accrue_on_receipt_flag



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 onreceipt 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 WriteOffs/Select Accrual Accounts.



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 inmoving and verifying the Transactions from the PO Tables to RCV_RECEIVING_SUB_LEDGER to SLA and finally to GL





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 haveaccrue_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. TheseTransactions 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 storespo_distribution_id,accrual_account_id,PO Balance,AP Balance and Write Off BalanceCST_AP_PO_RECONCILIATION: AP and PO Accrual Journals. The Table storesTransaction_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 PoMatch, Amount Received and Amount MatchedCST_MISC_RECONCILIATION:INV miscellaneous and AP miscellaneous data

The following Tables store Write Off Data: CST_WRITE_OFFS and CST_WRITE_OFF DETAILSCSTACRLR 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 thisprogram 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 ofmiscellaneous 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 toexisting 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 agiven 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 fromdate" 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 youcannot 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 thebalance 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,displaysthe 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 transactiondetails. 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 informationCSTACRMI 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.



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 ReportPOXACWRO module: WIP Accrual Write-Off Report This Report lists WIP Transactions written off.

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 notalready enrolled in the Procurement community, you can do so by clicking on the link Edit Subscriptions).

OR

From "My Oracle Support" as follows:

1. Log into My Oracle Support2. Click on the 'Community' link at the top of the page3. Click in 'Find a Community' field and enter Procurement4. Double click on Procurement in the list5. Click on the 'Create a Community Post' button and submit your question.

REFERENCES

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

https://community.oracle.com/thread/3370368




Documents

R12 How to Diagnose and Reconcile AAP 728871.1