Understanding The A/R Cash Receipt Post Process (R09801)

Purpose

Overview

When you create a Original Receipt you update the Receipt Header table (F03B13) and Receipt Detail table (F03B14). Before posting there is no General Ledger table (F0911) record created. After you post the Original receipt batch, you update the receipt header table (F03B13) and paymente detail table (F03B14) post code, if successful, to status of D and the General Ledger table (F0911) will create the receipt record (RC or RK) with a post code status, if successful, of P and creates a AE entry for your AR trade account.  If you create an adjustment on an existing receipt record, you create a new batch within the Receipt detail table (F03B14) before posting this new batch, no General Ledger record is created yet. After post, the new batch in the receipt detail table (F03B14) post code, if successful goes to D and a receipt record is created in the General Ledger table (F0911) within a post code, if successful, of P and a AE entry for a hit to AR trade account. Note: When the General Ledger posts the voucher and creates the AE the F0902 account ledger is updated as well. 

Scope

This document discusses the post process and how troubleshoot posting issues within Oracle JD Edwards EntepriseOne Accounts Receivable Receipts.

Details

Setup

General Ledger Post (R09801) Processing Options

Print Tab

• Processing Option 1: Account Format - Specifies the account format that is displayed on the General Ledger Post (R09801) PDF report.
• Processing Option 2: Print Error Messages - Determines if error messages are printed on the General Ledger Post (R09801) PDF. If left blank, error messages are only sent to the Work Center (P012503).

Versions Tab

• Processing Option 1: Detail Currency Restatement Version - Determines the version of the Detailed Currency Restatement (R11411) program that is used to create currency restatement entries. If left blank, the program does not run and detailed currency restatement entries are not created.
• Processing Option 2: Fixed Asset Post Version - Determines the version of the Fixed Asset Post (R12800) program that is used to create fixed asset entries. If left blank, the program does not run and fixed asset entries are not created.
• Processing Option 3: 52 Period Post Version - Determines the version of the 52 Period Accounting Post program (R098011) that the system uses to update the Account Balances (F0902) table and the Account Balances - 52 Period Accounting (F0902B) table. If left blank, the program does not run and these tables are not updated.
• Processing Option 4: Create Burdening Transactions Version (R52G11) - This option is not valid for AP and AR posting.

Edits Tab

• Processing Option 1: Update Transaction - Determines if the Account ID (data dictionary item AID), Company (data dictionary item CO), Fiscal Year (data dictionary item FY), Period Number (data dictionary item PN), Century (data dictionary item CTRY), and Fiscal Quarter (data dictionary item FQ) are updated on unposted records in the General Ledger (F0911). The system updates these values as follows:
• The Account ID (AID) and Company (CO) are updated using the value in the Account Number (data dictionary item ANI) field.
• The Fiscal Year (FY), Period Number (PN), and Century (CTRY) fields are updated using the value in the G/L Date (DJG).
• The Fiscal Quarter (FQ) field is set to blank.

Taxes Tab

• Processing Option 1: Update Tax File - Determines if the Taxes table (F0018) is updated when posting transactions with tax information.
• Processing Option 2: Update VAT Discounts - Determines if any tax amount fields should be adjusted during posting. The system adjusts the tax amount fields only for transactions with tax explanation code V. To use this processing option, tax rules must be configured for tax on gross including discount and discount on gross including tax.
• Processing Option 3: Update VAT Receipts and Write Off - Determines if any tax fields should be adjusted during posting.

Process Tab

• Processing Option 1: Explode parent item time - This option is not relevant for posting AP and AR batches, it only applies to posting T (Equipment Time Entry) batches.

Cash Basis Tab

• Processing Option 1: Units Ledger Type - Determines the Units Ledger Type the system uses for cash basis entries. The value in this option must be a valid ledger type from the UDC table 09/LT (Ledger Types). If left blank, the system uses the default ledger type ZU.
• Processing Options 2: Create Cash Basis Entries Version - Determines the version of the Create Cash Basis Entries (R11C850) program to run. This program is run after the post completes. If left blank, the program does not run and cash basis entries are not created.

Offset Method Options

• Automatic Offset Method Y (Detailed) - If you use offset method Y, the posting process creates one offset for each document, even if the invoice document contains both positive and negative pay items.  Note. (FRA) Users in France should use offset method Y because it maintains the correct separate debit and credit balances, even if positive documents (invoices) and negative documents (credit memos) are included in the same batch.
• Automatic Offset Method S - If you use offset method S, the posting process creates one offset for each pay item, including discounts and tax. Method S creates multiple records in the General Ledger table, but maintains the correct debit and credit balances within the French legal system. This offset method creates a large number of automatic entries, which considerably increases the size of the General Ledger table. In this example, the batch includes an invoice with two items: one for 10,000, and one for 5,000. The batch also includes a credit memo with two items: one for 3,000, and one for 1,000. The posting process created four automatic entries: debits of 10,000 and 5,000 to offset both items on the invoice, and credits of 3,000 and 1,000 to offset both items on the credit memo.
• Automatic Offset Method B - When you use offset method B, the system creates a cumulative automatic entry that does not include separate debit and credit totals. Note. (FRA) If offset method B is used to post transactions in France, procedures should be established to control the entry of different types of transactions, such as invoices and debit notes, in the same batch for posting. Although it is a common business practice, businesses in France are not legally required to provide a detailed journal to justify the offset to the bank account for each payment or receipt. If multiple payments and receipts are made on the same bank account, printing one cumulative entry for the bank account is acceptable. If you use offset method B, you can use the Transaction Journal to justify the centralized automatic entries that the system creates when you run the General Journal Report. In this example, the batch includes an invoice with two items: one for 10,000, and one for 5,000. The batch also includes a credit memo with two items: one for 3,000, and one for 1,000. The posting process created one automatic entry: a debit of 11,000 to offset all items. The system uses the batch number as the document number of the automatic offset.

Key to Method Used

This table shows the type of journal entry that the system creates according to the settings in the general accounting and accounts receivable constants.  Note - the Journal Entry Creation Method is driven by a processing option in the applicable receipt entry application.






Offset Method:

• Y = One automatic entry offset per document, regardless of the number of line items
• S = One automatic entry per pay item
• B = One automatic entry per batch

Understanding GL Date Warnings and Errors (PYEB, PBCO, PACO and WACO)

When you enter a transaction, the system validates the G/L date against the open period in the company constants. If you enter a transaction with a G/L date that is not in the current or next accounting period, you get a warning or an error message.

The following table lists the warning and error messages that the system returns when you enter a transaction outside of the two-period window.

Posting AR Receipts (R09801)

After you enter receipts, you must approve them and then post them to the general ledger to update the appropriate account information. Depending on the organization's policy, management approval might
be required before you can post receipt batches. The process to review and approve batches is the same regardless of the batch type. Because the system creates all of the entries to the Account Ledger table (F0911) when you post receipts, balancing errors occur only when the post program is interrupted. If the post program is aborted before it completes, run the post program again to delete the entries that the system created, and then run the post program a third time to create new entries.

During the post, the system:

• Selects unposted receipt transactions from these tables:
• Receipts Header (F03B13).
• Receipts Detail (F03B14).
• Validates each transaction.

If no errors occur, the system:

• Debits the appropriate bank account for the receipt amount, which creates bank deposit records in theAccount Ledger (F0911) table.
• Creates automatic offsets (credits) to the A/R trade account in the Account Ledger (F0911) table.
• Creates automatic entries to the discount, write-off, chargeback, or deduction accounts, if applicable.
• Updates balances in the Account Balances table (F0902).
• Marks the transactions as posted (P) in the Account Ledger (F0911) table.
• Updates the Receipts Header (F03B13) and Receipts Detial (F03B14) tables with a D in the Posted Code (POST) field.
• Updates the status of the Batch Control Record table (F0011) to D.

You can also post receipts from the Work With Batches (P0011), located on the same menu as the post program.

Journal Entries Created by the Receipt Post Process

When you post receipts to the general ledger, the system creates the Account Ledger record (F0911) differently, depending on the setting of the processing option for the journal entry creation method in the receipts entry program. Regardless of the method that you use to create journal entries, the system updates these fields in the receipt detail record (F03B14) from the journal entry that the system creates:

• Document Type - JE (RZDCTG).
• Document Number - JE (RZDOCG).
• Document Company - JE (RZKCOG).

Posting Voided and NSF Receipts

The system also creates different journal entries when you post a receipt that has been voided or designated as insufficient funds (NSF). Regardless of the processing option setting for the journal entry creation method, this occurs:

• When you post a voided receipt, the system creates a journal entry with the document type RO.
• When you post a receipt that is designated as NSF, the system creates a journal entry with the document type RV.

The system updates the Void Document (DOCQ), Void Document Type (DCTQ), and Void Document Company (KCOQ) fields in the Receipt Header (F03B13) record with the document number and document type that the system assigns to the journal entry.

Posting Zero Amount Receipts

When you fully apply credit memos or Unapplied receipts to invoices, the system does not generate journal entries to the bank account because the amount of the receipt is zero. Additionally, the system creates an automatic entry (document type AE) only when the GL Offset is different.  If the trade accounts are the same for the credit memo or Unapplied receipt and the invoice, the system does not generate AE entries or produce a posting edit report.

Additional Information:
Creation of F0911 records on posting of zero receipt is dependent on the Batch Offset in AR Constants.  Refer to Troubleshooting the Cash Receipts Review and Post Process in Accounts Receivable Within EnterpriseOne (R09801, P00241) for the item "Unable to post a zero receipt transaction to GL with transaction created in F0911" for details..

The F0911 entries created would be dependent on the offset method defined in Receivables Constants and the offset trade accounts for the invoices being matched. For instance:

• Case 1: If offset method is 'Y' i.e. one offset per document, it will summarize multiple pay items by account. Now if the zero receipt amount is matched with two invoices having same trade account, it will not create F0911 transactions in this case, as this is a zero value receipt and debit & credit transaction go to the same offset account.
• Case 2: If offset method is 'S' i.e. an individual offset for each pay item and if the zero receipt amount is matched with two invoices having different trade account, it will create F0911 transactions for each trade account separately in this case with zero amount.
• Case 3: If offset method is 'Y' i.e. one offset per document and if the zero receipt amount is matched with two invoices having different trade account, it will still create F0911 transactions for each account with zero amounts.

Understanding Automatic Entries Created by the Receipt Post Process

When you post receipts, the system creates automatic entries (document type AE) in the F0911 table. The system uses the account IDs from fields that the system updated when you entered the receipt. This table lists the fields that the system uses during the post process to locate the account for the AE entry based on the type of receipt.

Company 00000

When the system creates automatic entries for receipts, it always assigns company 00000 to the document company field of the journal entry (KCO), regardless of the setting of the offset method in the constants. The system must assign company 00000 because of the one-to-many relationship inherent in the receipt entry process-that is, one receipt can pay many invoices from different companies. If the post did not use company 00000, it would have to create additional journal entries to accommodate each invoice document company.

New Feature for Document Company (KCO) starting at release 9.1

Posting to Prior Period (R09801)

Occasionally, batches must be posted to a closed period that is several months back or even in a prior year without affecting financial statements or reports that have been processed for the closed period or year. This document provides steps to posting batches to a prior closed period or year. The process described has a zero dollar effect on the General Ledger balances for the prior period or year and updates the current period with the batch balances.

Steps to Post to Prior Period

These steps take into account the following example, please adjust instructions to fit your specific case:

Example: A voucher was created and posted with a GL Date (data dictionary item DGJ) of 10/01/2001. Using the fiscal date pattern of `R' for a regular calendar year this would be period 10. The business process requires that the entries be entered in November (period 11) instead of October. Because the GL Date (DGJ) of a voucher cannot be changed, the steps provided in this document must be followed.

1. Open Work with Companies (P0010) on the Organization & Account Setup (G09411) menu.
2. Locate the company or companies involved in the batch that needs posting, including companies involved in the GL Distribution of the voucher or payment.
3. Change the Current Period for General Accounting, Accounts Payable and Accounts Receivable modules for each of the companies found in step 2 back to period 10 (October).
4. After modifying the Current Period, log out of the system. This step is necessary because the information in this application is cached.
5. Log back in.
6. Post the batch.
7. Open Revise Single Account (P0901) on the Organization & Account Setup menu (G09411) and verify that the Posting Edit Code (data dictionary item PEC) allows manual entry to the affected trade account. In the standard setup for a trade account, the Posting Edit Code (PEC) is typically set to `M' (machine-generated transactions only). If this is the case, change the value to blank. Changing this value will temporarily allow all postings to this account.
8. In Standard Journal Entry (P0911) on the Journal Entry, Reports, Inquiries (G0911) menu, enter a reversing entry with an October GL Date (DGJ). This entry should offset the original entries posted for the original record. Verify that the Reverse radio button is checked. By marking the reverse radio button, the system automatically creates a reversing entry on the first day of the next period. In this case, the reversing entry will be created for 11/01/01. The net effect of these entries is $0. The journal entry should look have information in the F0911 as follows:
• AP Trade XX (Debit)
• Expense XX (Credit).
• Post the Journal Entries. Use data selection to specify the batch number.If the Posting Edit Code (PEC) was changed in Step 7, change it back to 'M' using Review and Revise Accounts (P0901).
9. In Company Names and Numbers, set the Current Period back to 11 (November) for all Modules. Because this information is cached, remember to log off so the change takes effect.

Posting to Prior Year (R09801)

Occasionally, batches must be posted to a closed period that is several months back or even in a prior year without affecting financial statements or reports that have been processed for the closed period or year. This document provides steps to posting batches to a prior closed period or year. The process described has a zero dollar effect on the General Ledger balances for the prior period or year and updates the current period with the batch balances.

Steps to Post to a Prior Year

1. Identify the GL Dates (data dictionary item DGJ) and Companies (data dictionary item CO) included in the unposted batch.
2. Using Work with Companies (P0010), determine the fiscal period and fiscal year corresponding to the batch's GL Dates.
3. Determine a time when either dates or constants may be changed to allow for prior period postings. This process should be run outside of business hours because it requires that no other batches are created or posted.
4. Determine the best method to use for posting the problem batch and make necessary change. There are two possible options:
• In Work with Companies (P0010), change the affected companies' Accounts Payable, Accounts Receivable and General Ledger periods and fiscal year (if necessary) to the earliest periods and fiscal years identified in Step 2.
• If the unposted batch is in the current fiscal year, change the value of the Allow PBCO Postings (data dictionary item PBCO) field in the General Accounting Constants (P0000) to Y. This modification allows updates to prior periods without having to change the dates for each company.User must log out and back in for the change to take effect.
5. Approve and post the batch. Retain the PDF of the General Ledger Post (R09801) generated during the post. It lists all journal entries created in the General Ledger (F0911) for the batch.

Adjusting Amounts to Reflect in Current Period

After a batch is posted to a prior period, these amounts need to be removed from the prior period and included in the current period. To do so, follow the steps below.

1. Determine if any of the GL Accounts listed on the PDF need the Posting Edit Code (data dictionary item PEC) updated to allow manual journal entries:
• Using Review and Revise Accounts (P0901), inquire on the account(s).
• If the Posting Edit Code (PEC) is set to 'M' (machine-generated transactions only), temporarily change it to blank.
2. Go to Standard Journal Entry (P0911).
3. Create a Journal Entry with the amounts opposite of the original entry and the account numbers are the same as above, for the prior period in question.
4. Repeat Step 3 for every entry created by the post report.
5. Post the manual journal entries while the prior period is still open. The prior period should have a zero net change to the General Ledger and all batches should be posted.
6. After the batch is posted, revert back to the current period by either of the two methods:
1. In Work with Companies (P0010) change the affected companies' Accounts Payable, Accounts Receivable and General Ledger periods and fiscal year (if necessary) back to the current period and year.
2. If the Allow PBCO Postings (PBCO) field in the General Accounting Constants (P0000) is Y, change it back to N. Log out and log back in for change to take effect. 
7. Go back into Standard Journal Entry (P0911) and inquire on the manual journal entries created in Step 3.
8. Void all manual journal entries, using the current period.
9. Approve and post the batch.
10. Reverse Step 1 by changing the Posting Edit Code (PEC) for all affected accounts back to 'M' using Review and Revise Accounts (P0901).
11. Run integrity reports, if desired, to ensure no other integrity issues exist.

Example
The example below is the General Ledger portion of an Accounts Payable payment to a prior period and year. Posting Journal entries would be:

• GL Date: 11/30/2003
• Cash in Bank: 100.1110.BEAR 100.00
• AP Trade Acct: 100.4110 <100.00>

After posting the batch, create a manual journal entry using Standard Journal Entry (P0911) for the following:

• GL Date: 11/30/2003
• Cash in Bank: 100.1110.BEAR <100.00>
• AP Trade Acct: 100.4110 100.00

The final step to moving the amounts from the prior period and year to the current period and year. After the manual entry above is posted in the prior period, it must be voided in the current period. The following entry is created at the completion of Step 8:

• GL Date: 01/31/2004
• Cash in Bank: 100.1110.BEAR 100.00
• AP Trade Acct: 100.4110 <100.00>

Batch Approval and Post Security (P00241)

Batch Approval allows management to control which users are permitted to post transaction batches. This functionality utilizes two lists of users that are defined by management to help secure the posting process:

• Secured Users: users included on this list are unauthorized to approve and post batches.
• Approved by Users: users on this list can approve and post batches on behalf of secured users.

For full details on how to set up this feature, please refer to knowledge Overview of Batch Approval and Post Security Setup (P00241/P0000)

Manually Create an Automatic Entry (P0911)

Automatic Entries (AEs) should be system-generated by the General Ledger Post (R09801), however, it may be necessary to create an AE manually if the system fails to create it and the Account Ledger table (F0911) records have been posted. This is done by creating one-sided journal entries. To determine if the AE was created, run a General Journal by Batch (R09301) report by batch number only (Journal Entry, Reports, Inquiries menu (G0911)). This UBE displays which records were created and which records were posted.

How to create Manual AE(s) to get a posted batch in balance:

1. During off peak hours when no one is posting batches go to menu G09411 (Organization Account Setup menu) select Revise Single Account (F0901). Inquire on the appropriate company's Accounts Payable or Accounts Receivable trade account. Temporarily remove the M (machine generated transactions only) from the Posting Edit field. This will allow the posting of the manual entry.
2. On the Journal Entry, Reports, Inquiries menu (G0911), select Journal Entry (P0911). Click the Add button.
3. Create the journal entry by populating these fields:
• Document Type - AE
• Document Number - Original batch number (if posting in summary) or original document number (if posting in detail)
• Document Company - Company number used on the records in the batch
• GL Date - Original GL date of the batch
• Caution: If the offset method in the Account Payable or Accounts Receivable Constants is B (one offset per batch), then use the last date of that period. If the offset method is Y (one offset per record), then use the GL date of the corresponding record.
• Verify that this GL period is open or that the (allow PBCO posting) field in the GL constants (P0000) is checked so the record can be posted.
• Account Number - Appropriate trade account
• Amount - Amount for the missing AE. Refer to the General Journal by Batch report (R09301) to determine if it needs to be a debit or credit.
4. Choose the Features form exit. Check the Out of Balance JE Mode box. Click OK twice.
5. Note the batch number, then select General Journal Review (P0011). Inquire on the batch, highlight it, select the Revise row exit, choose the Overrides form exit, then check the Allow Batch to Post out of Balance box.
6. Post the batch and verify that the entry is correct by reviewing the General Ledger Post Report (R09801).
7. On the Organization Account Setup menu (G09411), select Revise Single Account (F0901). Inquire on the appropriate company's Accounts Payable or Accounts Receivable trade account. Enter M (machine generated transactions only) in the Posting Edit field.
8. To add the new entry to the original batch, use a database tool, such as SQL, to change these F0911 fields:
• If the new AE is for a void entry and/or if another AE exists, change this new AE's Journal Entry LineNumber (JELN) to a unique number.
• Change Batch Number (ICU) to the original batch number.
• Change Batch Type (ICUT) from G to the appropriate batch type (V for a voucher batch, IB for an invoice batch, etc.).
9. Run the General Journal by Batch report for the original batch number again to confirm the batch contains the new AE and that the batch is in balance.
10. Optional: Delete the batch header for the new journal entry since it is no longer needed. Running the Batch to Detail and Out of Balance integrity report (R007031) will automatically delete the empty batch header.
11. If the AE was added to an Accounts Payable batch, run AP Orig Doc to GL by Batch (R04701) or AP Payments to GL by Batch (R04702A) on the Period End Processing menu (G0421). If the AE was added to an Accounts Receivable batch, run A/R Invoices to GL by Batch Integrity (R03B701) or AR to Account Balance by Account ID (R03B707) on the Period End Processing menu (G03B21). If this batch is not displayed, the AE entry and the batch is correct.