Understanding The Post Process Within JD Edwards EnterpriseOne Financial Management (R09801, P00241)

Purpose
 Internal Note
Scope
Details
 Overview of Posting Accounts Payable and Accounts Receivable (R09801)
 Accounts Payable
 Accounts Receivable
 General Ledger Post (R09801) Processing Options
 Offset Method Options
 Understanding GL Date Warnings and Errors (PYEB, PBCO, PACO and WACO)
 Posting AP Vouchers (R09801)
 Post Process
 Post Automatic Payments (R09801)
 Posting Automatic Payments in a Foreign Currency
 Posting AR Invoices (R09801)
 Automatic Entries Created by the Invoice Post
 Understanding Revisions to Posted Invoices
 Understanding Invoice Voids
 Revising Posted Invoices
 Voiding a Posted Invoice
 Voiding a Posted Invoice Pay Item
 Posting AR Receipts (R09801)
 Journal Entries Created by the Receipt Post Process
 Posting Voided and NSF Receipts
 Posting Zero Amount Receipts
 Understanding Automatic Entries Created by the Receipt Post Process
 Company 00000
 New Feature for Document Company (KCO) starting at release 9.1
 Posting to Prior Period (R09801)
 Steps to Post to Prior Period
 Posting to Prior Year (R09801)
 Steps to Post to a Prior Year
 Adjusting Amounts to Reflect in Current Period
 Batch Approval and Post Security (P00241)
 Batch Approval Configuration for Accounts Payable
 How to Turn On Batch Approval
 How to Assign Approved By Users
 How to Assign Secured Users
 Setting Up Workflow to Approve and Post Batches
 Workflow Set Up Instructions
 Manually Create an Automatic Entry (P0911)
 Post Troubleshooting Suggestions
 Resolution Suggestions
 AP Voucher Batch
 AP Payment Batch
 AR Invoice Batch
 AR Receipt Batch
 Additional Suggestions
 Accounts Payable
 Accounts Receivable

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

Accounts Receivable

General Ledger Post (R09801) Processing Options

Print Tab

Versions Tab

Edits Tab

Taxes Tab

Process Tab

Cash Basis Tab

Offset Method Options

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:

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 MessageReasonResult
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:

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:

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:

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:

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:

You can revise these fields on a posted, unpaid invoice:

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:

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:

  1. Locate the invoice that you want to revise, and then click Select.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. On Confirm Delete, click OK.
  3. On Enter Void Information, complete the Void G/L Date and Invoice Revision Code fields, and then click OK.
  4. On Void Confirmation, click OK to confirm the void.
  5. To verify the void, locate the voided invoice on Work With Customer Ledger Inquiry, and click Select to access Standard Invoice Entry.
  6. To review the amounts that the system reversed in the Customer Ledger, select Invoice Revisions from the Row menu on Standard Invoice Entry.
  7. 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:

  1. Select the invoice pay item that you want to void, and click Delete.
  2. On the Confirm Delete form, click OK.
  3. On the Enter Void Information form, complete the Invoice Revision Code field, and click OK.
  4. On the Void Confirmation form, click OK to confirm the void.
  5. 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:

If no errors occur, the system:

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:

 

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:

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:

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.

  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:
  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:
  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:
  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:

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

 

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:

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:

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:

Batch Approval Configuration for Accounts Payable

How to Turn On Batch Approval
  1. Access System Setup in one of the following ways:
    1. Use Fast Path code 4K.
    2. On the Accounts Payable Setup menu (G0441), select Accounts Payable Constants (P0000)..
  2. Turn on Batch Approval by ensuring that the Manager of Approval of Input checkbox (data dictionary item IARP) is checked.
  3. Click OK.
  4. Access the Batch Approval/Post Securities Constants application (P00241) from the GL Advanced & Technical Operations menu (G0931).
  5. Check one or both of the following checkboxes: AP Batch Security, Batch Review Security.
  6. Batch Approval functionality is now turned on.
How to Assign Approved By Users
  1. Access the Batch Approval/Post Securities Constants (P00241) from the GL Advanced & Technical Operations menu (G0931).
  2. Select the Approved by Users option from the Form menu.
  3. On the Work With Approved by Users (W00241G) form, click Add.
  4. 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.
  5. 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.
  6. Click OK.
How to Assign Secured Users
  1. Access the Batch Approval/Post Securities Constants (P00241) from the GL Advanced Technical Operations menu (G0931).
  2. Select the Secured Users option from the Form Exit menu.
  3. On the Work With Secured Users (W00241I) form, click Add.
  4. 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.
  5. Fill out the User ID(s) of the Approved By Users that can approve batches for the new Secured User.
  6. 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:

Each process has the following two versions:

To complete the set up for the Batch Approval work flow:

Workflow Set Up Instructions


1. P0000 -> Accounts Payable Constants check Manager Approval of Input.



2. P00241 -> check AP Batch Security



3. P00241 -> Form exit -> Approved by User



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:





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:

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

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
AP Payment Batch
AR Invoice 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:

 

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

Accounts Receivable