Oracle Confidential INTERNAL - Do not distribute to customer (OracleConfidential).
Reason: null[This section is not visible to customers.]
Applies to:
JD Edwards EnterpriseOne Accounts Receivable - Version XE and later JD Edwards EnterpriseOne General Ledger - Version XE and later JD Edwards EnterpriseOne Accounts Payable - Version XE and later Information in this document applies to any platform.
Purpose
This document discusses the post process and how troubleshoot posting issues within Oracle JD Edwards EntepriseOne Accounts Payable and Accounts Receivable modules.
Internal Note
For Project Holmes, IT Flow/Guided Resolution, this document is in the progress of splitting out into separate post failure documents for each process. Please see list of new documents below to add comments to or link in your SR going fowrard:
Use this document for those where one does not exist yet, thank you. Any questions contact Tanya McCarte. This document will archive by end of April 2015.
[This section is not visible to customers.]
Scope
This document is intended for EnterpriseOne users who are responsible for posting Accounts Payable or Accounts Receivable transactions.
Details
Overview of Posting Accounts Payable and Accounts Receivable (R09801)
Below are several posting suggestions that may assist you with posting batches within Accounts Payable and Accounts Receivable within Oracle JD Edwards EnterpriseOne Financial system.Below is a summary of how each type of batch would appear before and after the post. The post process updates the accounts in the Account Balances (F0902) table.
Accounts Payable
AP Voucher Batch - When you create a voucher you update the AP Ledger table (F0411) and General Ledger table (F0911) before posting the batch. After you post the batch, the post code for the AP ledger, if successful, should appear as D and the General Ledger post code, if successful, should appear as P and a AE entry is created updating your AP trade account.
AP Payment Batch - When you create a payment, after updating your automatic payment group and after creating your manual payment, you update the Payment header table (F0413) and Payment detail table (F0414) which stores the voucher detail information. Before posting this batch there is no data in the General Ledger table (F0911) created. After you post the payment batch, you update the payment header table (F0413) and paymente detail table (F0414) post status field (F0413) and post code field (F0414), if successful, to status of D and the General Ledger table (F0911) will create the payment record (PK or PN) with a post code status, if successful, of P and creates a AE entry for your AP trade account.
Accounts Receivable
AR Invoice Batch - When you create an invoice batch, records are created in the AR Ledger table (F03B11) and General Ledger table (F0911). After you post the batch, the posted code for the AR ledger, if successful, should appear as D and the General Ledger posted code, if successful, should appear as P. An AE entry is created updating your AR trade account. AE entries may also be created to tax accounts. Note: When the General Ledger posts the invoice and creates the AE, the F0902 account ledger is also updated. If you void an invoice, it updates the AR ledger table (F03B11) and creates a revision record in the F03B112.
AR Receipt Batch - 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: Note: When the General Ledger posts the voucher and creates the AE the F0902 account ledger is updated as well.
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.
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
Note: For Accounts Receivable, the Offset method can only be set at the company 00000 level, because it regulates how transactions are created in the F0911. This in turn has an effect on intercompany settlements, and on reconciling transactions. For that reason, you can't have one company with batch offset and another with detail offset.
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.
Error Number and Message
Reason
Result
0064 – Prior End Balance Forward Invalid
PYEB = Prior Year End Balance
You tried to enter or post a transaction to a prior fiscal year.
The system returns an error message and does not accept the entry.
0065 – Date is in the current fiscal year but prior month (PBCO).
PBCO = Post Before Cut Off
You tried to enter or post a transaction with a G/L date that is in the current fiscal year, but before the current period.
The system returns either a warning or error message, depending on the setting of the Allow PBCO Postings field in the General Accounting Constants (P000909):
If you have Allow PBCO set to Y, the system returns a warning.
If you have Allow PBCO set to N, the system returns an error.
0066 – Date is in future month of the current fiscal year (PACO).
PACO = Post After Cut Off
You tried to enter or post a transaction with a G/L date that is after the two-period window, but in the current fiscal year.
The system returns a warning message to alert you that the date is in a future period.
0000 – Date is in future fiscal year.
WACO – Way After Cut Off
You tried to enter or post a transaction with a G/L date in a future fiscal year.
The system returns a warning message to alert you that the date is in a future year.
Posting AP Vouchers (R09801)
When you use the General Ledger Post program (R09801) to post vouchers, the system creates the automatic entries for the vouchers according to the AAIs that you set up, and the processing options that you set up. The General Ledger Post program selects the unposted transactions for the selected batch from the Accounts Payable Ledger table (F0411). Next, the program creates transactions for automatic offset amounts. It also creates other related entries, such as taxes and intercompany settlements. The automatic offset amount is a debit or credit to the AP Trade Account and is controlled by the AAI item PC. The program uses the company number and the GL Offset from each voucher to locate the AAI item PC. This item contains the offset account to which you are posting. See knowledge Document 1408545.1 for information on creating and maintaining vouchers.
Post Process
When a voucher is created, the system writes records to the Accounts Payable Ledger (F0411) and the General Ledger table (F0911). Posting these records updates the Account Balances (F0902) table to reflect the new transaction. When a voucher is posted, the system:
Updates the voucher's Posted Code (data dictionary item POST) to D (Posted) in the Accounts Payable Ledger (F0411).
Updates the Posted Code (data dictionary item POST) to P (Posted) for all corresponding records in the General Ledger (F0911).
Creates the offset to the AP Trade Account (document type AE) that is defined in the corresponding Automatic Accounting Instruction (AAI PC).
Creates automatic entries to the intercompany account for the appropriate companies, if applicable.
Creates adjusting entries to the tax account, if applicable.
Updates the Taxes (F0018), if applicable.
Updates the Account Balance (F0902).
Updates the Batch Status (data dictionary item IST) to D (Posted) in the Batch Control Records (F0011) table.
Post Automatic Payments (R09801)
When a payment is created, the system writes records to the Accounts Payable Matching Document (F0413) and the Accounts Payable Matching Document Detail (F0414) tables. Posting a payment using the General Ledger Post (R09801) completes the payment process by creating records to the General Ledger table (F0911) and updating Account Balances table (F0902). When a payment is posted, the system:
Updates the Batch Status (IST) to D (Posted) in the Batch Control Records (F0011) table.
Marks the payment as posted in the Accounts Payable Matching Document (F0413) and the Accounts Payable Matching Document Detail (F0414) tables.
Adds payment records to the General Ledger (F0911) and marks them as posted:
Creates an entry to the AP Bank Account.
Creates the offset to the AP Trade Account (document type AE) that is defined in the corresponding Automatic Accounting Instruction (AAI PC).
Creates automatic entries to the intercompany account for the appropriate companies, if applicable.
Creates adjusting entries to the tax account, if applicable.
Updates the Tax (F0018) table, if applicable.
Updates the Account Balances (F0902) table.
Note: Please note that if you found this unposted automatic payment batch after running integrity reports and you have several of these batch types listed on the report, please treat each batch as separate issues. The resolution for one batch, provided by Oracle Software Support, may not be the same resolution for another.
Posting Automatic Payments in a Foreign Currency
When you post foreign currency payments the pre-post for the General Ledger Post program (R09801) retrieves the offset method from the Accounts Payable Constants program (P0000). If the offset method is B and there is at least one foreign currency payment, the pre-post changes the offset method for the batch to S (pay item) and continues processing.
When posting foreign currency payments the system might create journal entries for slight rounding differences. Those rounding differences are recorded in a realized gain or loss account even though the amounts are not caused by fluctuations in exchange rates.
Posting AR Invoices (R09801)
When an invoice batch is posted, the system:
Verifies that the batch has an Approved status.
Verifies that the GL date is the SAME for one invoice in both the Customer Ledger (F03B11) and the General Ledger (F0911).
Searches for invoices that do not have a posted code or that have a posted code of P.
Verifies that a corresponding record exists in the F0911 table and that the amounts balance to the invoice amount.
Creates automatic entries.
Updates the Account Balances (F0902) table.
Changes the posted code on invoices to D.
Changes the posted code on corresponding records in the F0911 table to P.
Changes the posted code on the batch control record to D.
If the system detects an error on one invoice transaction, the entire batch is in error and the system does not post any records. The system sends a workflow message and produces an error report. This diagram illustrates the invoice post process:
Automatic Entries Created by the Invoice Post
When you post invoice batches, the system creates automatic entries to the tax, intercompany settlement, and A/R trade accounts. The offset amount to the A/R trade account is controlled by the AAI item RC. The program uses the company number and the G/L offset from each invoice to locate the AAI item RC. This item contains the offset account to which you are posting. During the post process, the system retrieves this information for the automatic entry record based on the offset method that you specify in the A/R Constants:
Automatic offset amounts.
If the offset method is B, the system accumulates invoice amounts and creates one automatic entry for the entire batch of invoices.
If the offset method is S, the system accumulates pay item amounts and creates one automatic entry for each invoice.
If the offset method is Y, the system creates one automatic entry for each invoice pay item.
Document number.
If the offset method is B, the system assigns the batch number as the document number of the AE entry.
If the offset method is Y or S, the system assigns the document number of the invoice as the document number of the automatic entry.
Account number description.
If the offset method is B, the system writes Accounts Receivable - Trade/Offset by Batch IB (invoice batch number).
If the offset method is Y or S, the system writes Accounts Receivable - Trade/Offset by Document RI (invoice document number).
G/L Date - The system always uses the G/L date of the invoice, regardless of the offset method.
If the invoice includes taxes, the system generates an automatic offset with the same characteristics, except that the account description is from the AAI item RT (receivables tax). It records the tax amount in the Taxes table (F0018), based on a processing option.
Note: Although posting out-of-balance batches prevents the system from creating intercompany settlements, posting out-of-balance does create AE entries to the A/R trade account.
Understanding Revisions to Posted Invoices
After you post an invoice, but before it is paid, you can revise it. For example, after entering, you might need to revise the gross amount or G/L account information. When you revise or void a posted invoice, the system:
Removes the posted code on the invoice.
Adds a record to the Invoice Revisions table (F03B112).
Updates the A/R Post Status field (ISTR) to 1 on the invoice record. The system displays this field in the Revisions Made column on the Work with Customer Ledger Inquiry form. Regardless of the number of revisions you make to an invoice, the Revisions Made column always displays 1.
You can revise these fields on a posted, unpaid invoice:
Gross Amount. The system automatically recalculates the open amount.
Remark
Discount Available. Note: If you clear this field, the system automatically recalculates the discount amount based on the payment term.
Due Date
Discount Due Date
PS (Pay Status). Note: You cannot change the pay status if the value is P (paid).
Any revision that you make to an invoice on the Standard Invoice Entry form changes the status of the batch from posted to unposted and requires you to repost it. To eliminate the necessity of reposting the batch, use Speed Status Change to revise information that does not affect the invoice gross amount or G/L account information. If you need to change information in any other field, you must void and re-enter the invoice.
Understanding Invoice Voids
To remove a posted invoice or invoice pay item from the general ledger, you must void it and then post the batch again; you cannot delete a posted invoice. When you void an invoice, you specify the G/L date to use to reverse the entries from the general ledger. You can void an invoice from either the Work with Customer Ledger Inquiry or Standard Invoice Entry form.
If you void an invoice pay item only, you must use the Standard Invoice Entry form, and you cannot specify a void G/L date; the system always uses the G/L date on the invoice. When you void an invoice, the system:
Updates the gross amount to zero.
Removes the posted code from the invoice
Updates the payment status code to P (paid).
Creates a record in the F03B112 table as an audit trail for the change in gross amount.
Updates the A/R Post Status field (ISTR) in the Customer Ledger record (F03B11) to 1.
The system displays the value of this field in the Revisions Made column in Customer Ledger Inquiry. After you void an invoice, you must post the batch again. To void a paid or partially paid invoice, you must first void the customer's payment.
Note: You cannot void invoices with these document types: R1, RU, RB, and R5. These types of invoices are generated from the receipt applications and have a batch type of RB, not IB. The system creates these documents with a posted code of D, regardless of whether the receipt batch is posted.
Revising Posted Invoices
Access the Work with Customer Ledger Inquiry form. To revise posted invoices:
Locate the invoice that you want to revise, and then click Select.
On Standard Invoice Entry, revise the information in any available field, and then click OK. If you change the gross amount, you might need to revise the discount amount. The system does not recalculate the discount when you change the gross amount. If you change the gross amount, the system displays the G/L Distribution form automatically.
On the G/L Distribution form, complete the Account Number and Amount fields on a new grid line to create a balancing entry. Enter the amount as a credit.
To revise general ledger information only, on Standard Invoice Entry, select G/L Distribution from the Form menu, revise the desired fields, and then click OK.
Voiding a Posted Invoice
Access the Work with Customer Ledger Inquiry form. To void a posted invoice:
Locate the invoice that you want to void, and then click Delete. Important! If you select an invoice with multiple pay items, the system voids all pay items.
On Confirm Delete, click OK.
On Enter Void Information, complete the Void G/L Date and Invoice Revision Code fields, and then click OK.
On Void Confirmation, click OK to confirm the void.
To verify the void, locate the voided invoice on Work With Customer Ledger Inquiry, and click Select to access Standard Invoice Entry.
To review the amounts that the system reversed in the Customer Ledger, select Invoice Revisions from the Row menu on Standard Invoice Entry.
To review the reversing entries that the system creates in the F0911 table when you void an invoice, select G/L Distribution from the Form menu on Standard Invoice Entry. For Void G/L Date field enter the date to which the system posts voided transactions. Do not enter a G/L date for a previous or future period. For the Invoice Revision Code field enter the code that identifies the reason that an invoice pay item was voided.
Voiding a Posted Invoice Pay Item
Access the Standard Invoice Entry form. To void a posted invoice pay item:
Select the invoice pay item that you want to void, and click Delete.
On the Confirm Delete form, click OK.
On the Enter Void Information form, complete the Invoice Revision Code field, and click OK.
On the Void Confirmation form, click OK to confirm the void.
On the G/L Distribution form, complete the Account Number and Amount fields on a new detail line to create a balancing entry. Enter the amount as a credit.
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.
Note: The status of the receipt batch header remains "In Use" until you exit the Work With Customer Receipts Inquiry form.
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.
Note: The system creates unapplied receipt (RU), chargeback (RB), and deduction (R5) invoices with a Post Status (POST) of D in the Customer Ledger (F03B11) table. To determine whether these records are posted, you must locate and verify the posted status of the receipt document from which they originated.
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 A/R trade account to which the unapplied receipt or credit memo was posted is different from the A/R trade account to which the invoice was posted. 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 frequently asked question number 2 under Accounts Receivable Receipt Posting (R09801) Question section in Document 1412945.1.
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
Note: Starting at release 9.1 the Document Company field (KCO) has been enhanced to use the actual company value instead of using default company 00000. This was changed due to challenges the default 00000 caused for client using row security which caused a duplicate key error. This feature was added from a enhancement request. See Bug 11035643. This was released with 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.
Note: It is very important these steps are followed when all other users are out of the system because the current period for posting is affected. The Posting Edit Code (data dictionary item PEC) of the trade account may also be a factor.
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.
Open Work with Companies (P0010) on the Organization & Account Setup (G09411) menu.
Locate the company or companies involved in the batch that needs posting, including companies involved in the GL Distribution of the voucher or payment.
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).
After modifying the Current Period, log out of the system. This step is necessary because the information in this application is cached.
Log back in.
Post the batch.
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.
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).
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
Identify the GL Dates (data dictionary item DGJ) and Companies (data dictionary item CO) included in the unposted batch.
Using Work with Companies (P0010), determine the fiscal period and fiscal year corresponding to the batch's GL Dates.
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.
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.
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.
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.
Go to Standard Journal Entry (P0911).
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.
Repeat Step 3 for every entry created by the post report.
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.
After the batch is posted, revert back to the current period by either of the two methods:
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.
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.
Go back into Standard Journal Entry (P0911) and inquire on the manual journal entries created in Step 3.
Void all manual journal entries, using the current period.
Approve and post the batch.
Reverse Step 1 by changing the Posting Edit Code (PEC) for all affected accounts back to 'M' using Review and Revise Accounts (P0901).
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
Note: that the amounts are opposite of the original posting entry.
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.
Note: If a Secured User makes changes to an Approved batch, the batch is returned to a Pending Batch Status (data dictionary item IST) and must be reapproved.
A Batch Approval workflow can be implemented to approve outstanding batches using the Employee Work Center (P012503). From the Work Center (P012503), approver(s) receive notification messages, review and approve batches, and if necessary, post the batches. A list of approvers can be set up so electronic messages are sent to multiple employees at one time. When one approver accesses the notification message and takes action, the system automatically deletes the notification message for the remaining approvers. Additionally, the employee who entered the batch receives notification that the batch was approved. This workflow process allows for secured batch posting without requiring too much additional effort or time to employ.
Batch Approval and Post Security (P00241) is available for:
General Accounting.
Accounts Payable.
Accounts Receivable.
Batch Approval Configuration for Accounts Payable
How to Turn On Batch Approval
Access System Setup in one of the following ways:
Use Fast Path code 4K.
On the Accounts Payable Setup menu (G0441), select Accounts Payable Constants (P0000)..
Turn on Batch Approval by ensuring that the Manager of Approval of Input checkbox (data dictionary item IARP) is checked.
Click OK.
Access the Batch Approval/Post Securities Constants application (P00241) from the GL Advanced & Technical Operations menu (G0931).
Check one or both of the following checkboxes: AP Batch Security, Batch Review Security.
Batch Approval functionality is now turned on.
How to Assign Approved By Users
Access the Batch Approval/Post Securities Constants (P00241) from the GL Advanced & Technical Operations menu (G0931).
Select the Approved by Users option from the Form menu.
On the Work With Approved by Users (W00241G) form, click Add.
Complete the Approved By User (data dictionary item USR1) field with the User ID of the user who is authorized to approve and post batches.
Fill out the User ID(s) of the Secured Users that this user can approve batches for. If a user should be able to approve all batches, enter *ALL in the Secured Users list.
Click OK.
How to Assign Secured Users
Access the Batch Approval/Post Securities Constants (P00241) from the GL Advanced Technical Operations menu (G0931).
Select the Secured Users option from the Form Exit menu.
On the Work With Secured Users (W00241I) form, click Add.
Complete the Secured User (data dictionary item USR2) field with the User ID of the user who should not be allowed to approve or post batches.
Fill out the User ID(s) of the Approved By Users that can approve batches for the new Secured User.
Click OK.
Reports that contain lists of the Secured Users or Approved By Users can be printed by selecting the Batch Security option from the Report menu of the Batch Approval / Post Security Constants (P00241).
Setting Up Workflow to Approve and Post Batches
To increase the efficiency of the approval process, the Batch Approval workflow can be implemented. This workflow allows users to approve batches, or approve and post batches directly from the work center. The system uses the workflow process in conjunction with the Batch Approval / Post Security Constants program (P00241) to determine who receives workflow messages. Because the system sends workflow messages only to workflow recipients, employees that are identified as Approved By Users must also be set up as recipients in the workflow process.
The following workflow processes are available for approving batches:
JDEBCHAPPR - For approval of Journal Entry batches (batch type G).
JDEVBCHAPR - For approval of Voucher batches (batch type V).
Each process has the following two versions:
Version 1 - When activated, users can only approve batches from the Work Center (P012503).
Version 2 - When activated, users can both approve and post batches from the Work Center (P012503).
To complete the set up for the Batch Approval work flow:
Activate either version 1 or 2 of the JDEVBCHAPR process.
Set up approving managers in recipient rules.
Set up the message queues that users can view using the Queue Security program (P01135).
Click Add and complete the Approved by User and Secured User fields. In my case ACIOCOIU will approve batches for FMIHAI. You can add more users that need approval from ACIOCOIU. Click OK.
4. P00241 -> Form exit -> Secured Users. See that FMIHAI is approved by ACIOCOIU. Here you can add more Approved by Users for FMIHAI.
5. You can also print reports to see the Approved by Users(XJDE0001) or the Secured Users(XJDE0002): P00241 -> Report exit -> Batch Security Report.
6. Need to make sure that both users are defined in the Address Book (P01012) application
7. P0092 (Work with User/Role Profiles) verify that each User Id has the correct address book number (AB#) associated with it.
Set e-mail addresses in Work Center (P012503) -> Form Exit -> Employee Mailboxes
Row Exit -> Email preferences
9. On a FAT client P98800 (Process Master) inquire on JDEVBCHAPR: Approve voucher batches (batch type V). You can choose one of the two versions available:
Version 1: Approve batches only or
Version 2: Approve and post batches.
10. Double click on the version -> Design Tools. Make sure the status is Inactive. Press Start Workflow Modeler.
Right click on the Review ->Recipient Rules and enter the ACIOCOIU's address number.
Right click on the Review ->Event Rules and set the value of the Address Number field to Use Recipient Rules.
This will send an email to ACIOCOIU (approver). Right click on the Approved. You will see that this is set-up the right way (by using a variable).
11. Change the status of the Workflow from Inactive to Active. I selected the first one and changed the status to Active (Row exit -> Change status).
12. Under the Workflow Operations, select Process Task Monitor. Inquire by JDEVBCHAPR in the Process field. If anything is in the folder for JDEVBCHAPR, highlight it and click Terminate on the row exit bar.
13. Mail message received by Approver:
Note: that if you choose to use the workflow process, batches can still be approved through the Work with Batches program (P0011), as well as the Work Center (P00241).
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.
Caution: Only create AEs when there are posted F0911 records and the offsetting AE is missing.
How to create Manual AE(s) to get a posted batch in balance:
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.
On the Journal Entry, Reports, Inquiries menu (G0911), select Journal Entry (P0911). Click the Add button.
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.
Choose the Features form exit. Check the Out of Balance JE Mode box. Click OK twice.
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.
Post the batch and verify that the entry is correct by reviewing the General Ledger Post Report (R09801).
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.
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.).
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.
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.
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.
Note: If you select "Allow batch to post out of balance" checkbox in P0011 application but do not make the SQL updates, please ensure that you exclude the batch from integrity reports by checking the "Exclude batch from integrity report" option.
Post Troubleshooting Suggestions
There may be times when running into posting batches within Accounts Payable and Accounts Receivable modules that you need help troubleshooting. Oracle Software Support offer some suggestions on why posts fails and what suggestions they suggest to assist with troubleshooting these types of issues.
Common reasons for posting failure:
Power failure - The system may have experience a power failure while attempting to post batches.voucher batches.
Out of balance - Based on calls received within Oracle Software Support often batches fail to post due to an out of balance condition between the tables involved within that specific type of batch. The R09801 post edit report, the R09801E out of balance report may help narrow down to the document number that is causing the batch to be out of balance. If the GL (F0911) has not posted yet and no AE have been created, review each document comparing them between each table involved to find the table that is causing the out of balance condition.
Date Out of balance - Same as out of balance above, however, in this scenario it may be the dates (i.e. period field, gl date field, fiscal year field or century field) that do not match for a document within the batch between the tables involved for that type of batch.
Corrupt R09801 report specifications - R09801 report specification will sometimes become corrupt, causing the UBE process to fail. Specification corruption can occur for various reasons. It can happen as the result of a process ending unexpectedly while reading or writing spec records, because disk or memory failure, power failure, etc. When specification becomes corrupt, symptoms and issues may vary greatly.
Resolution Suggestions
In case of spec corruption of the General Ledger Post (R09801) UBE, it is recommended to try building and deploying an update package of the R09801 template and all the associated versions to the server (Doc ID 1369078.2). This would refresh the specification on the server. If this doesn’t resolve the issue, please log a service request with Oracle Software Support for assistance. See the list of documentation the support engineer will need to review the batch in question. See below for documentation requirements.
AP Voucher Batch
Query the Accounts Payable Ledger (F0411) and Account Ledger (F0911) by Batch Number (ICU) only and export all the data to excel and attach to the SR.
Attach the PDF of the R09801 post edit report.
Attach the PDF of the R09801E out of balance report (if available).
Attach a screen shot of the work center error message(s) for this batch.
AP Payment Batch
Query the Accounts Payable Matching Document (F0413) and Account Ledger (F0911) by Batch Number (ICU) only and export all the data to excel and attach to the SR.
Query the Accounts Payable Matching Document Detail (F0414) using the Payment IDs (PYID) returned in the Accounts Payable Matching Document (F0413).
Attach the PDF of the R09801 post edit report.
Attach the PDF of the R09801E out of balance report (if available).
Attach a screen shot of the work center error message(s) for this batch.
AR Invoice Batch
Query the Customer Ledger (F03B11), Invoice Revisions (F03B112) and Account Ledger (F0911) by Batch Number (ICU) only and export all the data to excel and attach to the SR.
Attach the PDF of the R09801 post edit report.
Attach the PDF of the R09801E out of balance report (if available).
Attach a screen shot of the work center error message(s) for this batch.
AR Receipt Batch
AR Receipt Batch post issues are much more complex then the other listed batch types above so the below suggested documentation is based on previous service requests that were successfully resolved using this list. These recommendations are for a basic standard type of receipt entry where no deductions involved. More information may be requested on a case to case basis.
The key to troubleshooting a Receipt batch is determining if the batch that is currently failing your Original Batch or Adjusting Batch. See knowledge Document 1413879.1 for additional details. Data requirements may be as follows:
Using the original Batch Number query the Receipts Header (F03B13), export this data to excel and attach to the SR.
From the Receipts Header (F03B13) query above, gather all unique Payment IDs (PYID) and query the Receipts Detail (F03B14), export this data to excel and attach to the SR.
From the Receipts Detail (F03B14) query above, gather all unique batch number and query the Account Ledger (F0911), export this data to excel and attach to the SR. Make note in the SR which batch numbers did not have any data in the Account Ledger.
Attach the PDF of the R09801 post edit report.
Attach the PDF of the R09801E out of balance report (if available).
Attach a screen shot of the work center error message(s) for this batch.
Caution: If you are not 100% sure how to correct the issue before trying to edit any of the documents involved, please log a service request with Oracle Software Support for assistance and attach the above documentation for assistance. If you have several batches that have failed to post, please do not assume the resolution for one batch will be the same for the other batches. Log separate service requests for each batch to ensure each batch is reviewed separately as a separate solution may be needed.
Additional Suggestions
There may be a reason to revisit the process to enter in Accounts Payable and Accounts Receivable records. To get a full understanding of how to set up and use each of these modules refer to the below knowledge documentation references for assistance:
Accounts Payable
Refer to Overview and Set Up for Accounts Payable knowledge Document 1409284.1. This document links all Accounts Payable knowledge documents and frequently asked questions knowledge documents for your reference.
Coming soon - The Accounts Payable knowledge documents are in the processing of being created within a new Information Center. This document will be updated once that is complete.
Accounts Receivable
You can search knowledge database by using the prefix of E1: 03B: to find existing knowledge documents
You can search by program ID to find existing knowledge documents
You can refer to our JD Edwards EnterpriseOne online guide by referring to knowledge Document 705443.1 scroll down and select OTN Library, select EnterpriseOne and access all online guides
Coming in the future, the consolidation to create a new Information Center knowledge document for Accounts Receivable.