Understanding Accounts Payable Payment Post Process Within JD Edwards EnterpriseOne Financial Management (R09801, P00241)

Purpose

Overview

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 payments 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.

Scope

This document discusses the Accounts Payable Payment post process within JD Edwards EntepriseOne Financial Management.

Details

Posting Accounts Payable Payment Batch (R09801)

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

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.

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.

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 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 and log back in to cache (refresh) the system. If it does not work with your CNC to cache the tables/system.
5. Post the batch.
6. 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.
7. 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).
8. 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.

Post Troubleshooting Knowledge References

There may be times when running into posting batches that you need help troubleshooting. Oracle Software Support offer some suggestions on to troubleshoot these issues.

Frequently Asked Questions Regarding AP Payment Post

Accounts Payable Automatic Payment Posting (R09801) Questions

Question 1: The General Ledger Post (R09801) triggers a Record Invalid error when posting payments, why?

Answer 1: This error has several possible causes, including:

• The payment's corresponding voucher is missing from the Accounts Payable Ledger table (F0411). If the voucher is missing, add a new voucher with the same Document Number (data dictionary item DOC), Document Type (data dictionary item DCT), Document Company (data dictionary item KCO), and Pay Item (data dictionary item SFX) using the Standard Voucher Entry application(P0411).
• Payment Amount (data dictionary item PAAP) is blank for one or several of the payments in the Accounts Payable Matching Document Detail table (F0414).
• If issued when posting a voided Payment batch it could be caused by the associated voucher. In the Supplier Ledger (F0411), verify the Gross Amount (AG) and Open Amount (AA) are correct and the Pay Status (PST) is at A for Approved.

Question 2: The General Ledger Post (R09801) triggers error Fiscal Year not set up when posting payments, why?

Answer 2: The post will not complete successfully if any of the following is true:

• Document Type Matching (data dictionary item DCTM) in either the Accounts Payable Matching Document Detail (F0414) table or the Accounts Payable Matching Document (F0413) table is blank.
• Date Matching Check or Item (data dictionary item DMTJ) in the Accounts Payable Matching Document (F0413) table is blank.
• Document Matching (data dictionary item DOCM) in the Accounts Payable Matching Document (F0413) is zero.
• Period Number (data dictionary item PN), Fiscal Year (data dictionary item FY) or Century (data dictionary item CTRY) in the Accounts Payable Matching Document Detail (F0414) table is set to zero.

Question 3: The General Ledger Post (R09801) triggers error Invalid Period No and/or Fiscal Year when posting payments, why?

Answer 3: This issue is generally caused by the Period Number (data dictionary item PN) and GL Date (data dictionary item DJG) in the General Ledger (F0911) and the Accounts Payable Ledger (F0411) tables not matching with the date pattern setup in the Work with Fiscal Date Patterns (P0008) program.

Question 4: The General Ledger Post (R09801) triggers error Insert Unsuccessful (in F0911) when posting payments, why?

Answer 4: Usually, this issue occurs when a payment is posted that has a duplicate document number (data dictionary item DOC) in the General Ledger table (F0911).

Question 5: The General Ledger Post (R09801) triggers error Invalid parameters when posting payments, why?

Answer 5: It is possible that the trade account Automatic Accounting Instruction (AAI item PCxxx) is pointing to an account with a currency different than the currency of the payment batch.

Question 6: Why are intercompany entries not created for the bank account company when posting an automatic payment batch (K)?

Answer 6: If the system is creating entries based of the lowest number company within a payment, rather than by the bank account company, it may be due to the Accounts Payable Batch Offset method in the Accounts Payable Constants (P0000). To get the system to creates one offset for each transaction by account, this should be set to Y.

Question 7: Why does the GL post (R09801) set error "Posting Edit Code Does Not Allow Entry" on AAIs PKJ and PKL when posting automatic payments even if Job Cost is not used?

Answer 7: The system may return this error when the Automatic Account Instructions (AAIs) PKJ and PKJL are not defined. These AAIs are used when processing Job Cost transactions. However, they are validated even if Job Cost is not activated. To fix this issue, add AAI PKJ and PKJL with the same information as defined for the standard Accounts Payable Discount AAIs (PKD and PKL).

Question 8: Why does the system trigger error "Company 1 does not exist in the Company Constants File" when posting an automatic payment?

Answer 8: The system may return this error when the Automatic Account Instructions (AAIs) PKJ and PKJL are not defined. These AAIs are used when processing Job Cost transactions. However, they are validated even if Job Cost is not activated. To fix this issue, add AAI PKJ and PKJL with the same information as defined for the standard Accounts Payable Discount AAIs (PKD and PKL).

Question 9: Can a zero dollar payment be posted?

Answer 9: A voucher should not have a zero dollar line that is approved for payment. If it is created from Procurement with a zero dollar pay item, this pay item should be created with a pay status = P. If it is A and the voucher is pulled into a payment group and a zero dollar payment is created, it does not post and produces the "Record Invalid" error. To create a zero dollar or negative payment (Supplier Refund), you must use Manual Payment With Voucher Match. Automatic Payment Processing cannot be used.

Question 10: A foreign currency zero amount payment was created to offset prepayment voucher's negative pay item against match voucher. After posting the payment batch, system generated a one cent rounding record to post to the bank account instead of posting to the exchange gain or loss account. Why is this so?

Answer 10: The difference is due to domestic amount of the match voucher is different from the prepayemnt voucher's domestic amount. The payment application does not know that the amount is because of exchange variance as the exchange rate of the vouchers and the payment are the same. So the difference amount is posted to bank account as in normal payments.

Workaround: The workaround is to use an exchange gain or loss object account as the bank account for such scenario.

Question 11: Why the batch post report is displaying the error message 'No F0911 records exist in this Batch' while posting an alternate currency payment batch?

Answer 11: System will throw this error message if the P7 - Alternate currency clearing AAI is not setup. Create P7 AAI to post the alternate currency payment batch.