Title: Steps To Resolving AR Integrity Issues

----------------------------------------------
Abstract: Documents how to research and resolve integrity issues on the A/R integrity reports, especially the The A/R to
Account Balance by Account ID Report (R03B707).
----------------------------------------------

INTRODUCTION

The A/R to Account Balance by Account ID Report (R03B707) is used to ensure that the total amount of open A/R
invoices in the Customer Ledger (F03B11) table is equal to the balance in the Account Balance table (F0902) for the
associated A/R offset accounts. The report compares posted amounts in the A/R transaction tables to the amounts
updated in the corresponding Account Balances table (F0902). The A/R tables used are:

· Customer Ledger - F03B11

· Invoice Revisions - F03B112
· Receipts Header - F03B13
· A/R Check Detail - F03B14

The report also compensates for unposted transactions in the Invoice Revisions table.

FUNCTIONALITY

The program utilizes several Automatic Accounting Instructions (AAIs) to determine the open balances for the invoices
sorting by the G/L Offset field. The program considers the A/R offset accounts (AAI item RC), write-off accounts (AAI item
RA), deduction accounts (AAI item RN), discount accounts (AAI item RK), bank accounts (AAI item RB), delinquency fee
accounts (AAI items RFC and RFD), and gain/loss accounts (AAI items RG and RL).

The system stamps each A/R transaction with the appropriate account ID at the time that each record is created. When
this integrity report is run, the program accumulates amounts from the A/R transaction tables by account ID, company,
fiscal year, century, G/L period number, and base currency code. The system then prints the total open amount in the A/R
tables and the balance in the Account Balance table. If there is a difference, it will print in the difference column of the
report.

The report will not consider R1 (draft invoices), RU (unapplied receipts), RB (chargeback invoices), and R5 (deduction)
records from the Customer Ledger table (F03B11). It will also not consider records that have not been posted, with the
exception of unposted voids and revisions residing in the F03B112 table.

This program runs over all the records in the system and shows the balances at that moment in time. The data selection
and data sequencing cannot be changed.

STEPS FOR RESOLVING PROBLEMS ON THIS REPORT

This report gives a `big picture view' showing whether the detail matches the amounts that are posted in the Account
Balance table (F0902). In order to solve differences, the following steps should be taken to find where differences have
occurred.

1) Make sure all batches are posted. Other integrities on the Integrity Reports and Updates menu (G0922) can
be run to check for outstanding issues with unposted or problem batches. Run the batch integrities in the
following order:

· Batch to Detail and Out of Balance (R007031)

This program updates batch headers to a posted status if all transactions in the batch are posted. It also
deletes any empty batch headers. A report will also be generated for batches with discrepancies.
· Transactions to Batch Header (R007021)
This program reports any batches with a status of posted whose transactions are not posted. Run this
program for unposted batches only by using a processing option and make sure that the report output is
blank ("clean").
· Print Unposted Batches (R007011)
Now that the batch headers have been updated properly, this program will print a report that is accurate.

2) Run the A/R to G/L by Batch integrity (R03B701) on the Period End Processing menu (G03B21) to see if any
invoice batches are out of balance. This report compares the batch amount of the Customer Ledger
transactions (F03B11) to the batch amount of the corresponding Account Ledger (F0911) records. To
determine which transaction in the batch is out of balance, run a General Journal by Batch report (R09301)
for the batch in question and compare the information printed to the corresponding records in the F03B11
and F03B112 tables. The information in these tables can be found by use of SQL, UTB or other database
tools. These tools are also helpful in finding potential data issues on these records that will effect the
integrity.

3) Run the F03B14 to F0911 Conversion Integrity (R890911BI) on the Financials Integrities menu (G97UE91)
 to find out of balance receipt batches. The report can be run in proof or final mode. (Note: Run the report in
final (update) mode only when performing the Euro conversion.) This report verifies that the posted gross
amounts in the A/R Check Detail table (F03B14) are in balance with the corresponding G/L receipt amounts
in the Account Ledger table (F0911). To determine which transaction in the batch is out of balance, run a
General Journal by Batch (R09301) for the batch in question and compare the information printed to the
corresponding F03B13 and F03B14 tables just as above.

4) Check the Batch to Detail and POB report that was run in Step 1 to find any A/R batches reported as having
been posted out of balance. Research any of these batches to verify that correcting entries were made to
put the batches in balance. If correcting entries were made, check to see that they were correct in the same
batch. If they were not, two batches should appear to be out of balance.

5) Run the Repost Account Ledger program (R099102) from menu G09316 in report mode to verify the F0911
transactions equal the F0902 balances. To validate that the F0902 balances by period are correct to the
F0911 transactions, run this program with the processing options set in the balance forward tab. If an entry
was posted incorrectly to a prior year, it could result in an out of balance condition on this report.

6) Run the Account Balance to Transactions report (R09705) from the Integrity Reports and Updates menu
(G0922) to verify there are not F0902 balance records unsupported by F0911 detail transactions.

7) Verify that all the document types in the A/R trade account are Document Type AE. If other document types
exist, verify their origin. Trade accounts should always be set with a Posting Edit Code of M. This means that
the entries on this account can only be generated by machine and prevents the ease of balancing entries to
this account without case. This is important because A/R will not track a journal entry entered through G/L.
Since A/R is set up to validate this account through the AAIs, these transactions will prove to be out of
balance. The account should contain only AE entries unless a journal entry was created to correct an out of
balance condition. Run the General Journal by Account (R09311) to verify there are no unauthorized
document types, or unidentified AE entries with a G batch type.

8) Run the following global update programs:

· Update BU/Obj/Sub to Jrnl Ent (R09806) on the Global Updates menu (G09316)
· Acct Master w/o BU Master (R097041) on the Integrity Reports and Updates menu (G0922)*
· Acct Balance w/o Acct Master (R097031) on the Integrity Reports and Updates menu (G0922)*
· Transactions w/o Acct Master (R097021) on the Integrity Reports and Updates menu (G0922)*
*Run the programs in Update Mode (see processing options)

9) Verify that no A/R trade AAI items (RC) were changed. If they were, add the balance from the previous
account to the balance on the report. If the difference is zero, then journalize the previous A/R trade account
balance to the new A/R trade account.

10) Look for damaged records. Verify that fields utilize by the business view contained in this integrity have
correct values. Database tools will be necessary in this step.

11) Check for SARs under this program to see if outstanding issues exist.

12) Verify that the source code is pristine and rule out custom modifications.

13) Verify that all A/R batches are posted. Using database tools, query the F03B11, F03B112, F03B14, and
F03B13 tables. The only selection criteria should be Post Code not equal to D. This will display any
unposted records that were not previously detected by other integrity reports. If any records are selected
during this query, they should be investigated and appropriate corrections made.

14) Other issues that affect this program:

· Is the out-of-balance condition a result of converted data?
· Has this report ever been in balance?
· Do the accounts balance if you use the As Of process to balance? If so, there are probably damaged
records.
· Do the accounts balance if all the transactions are posted and the A/R Open Detail Report is run (not
using the As Of processing) and compared to the Account Balances?

15) Verify that the period numbers on the A/R transactions match those of the corresponding F0911/F0902
records.

Question 1 - What is the purpose of the Post program?

Answer: The main purpose of the General Ledger Post program (R09801) is to update the Account Balances (F0902)
table amounts with the amounts of the associated Account Ledger (F0911) entries. The Post creates necessary automatic
offsets and other related entries, such as tax entries and intercompany settlements, in the F0911 table, which are also
updated to the accounts in the F0902.
---------------

Question 2 - Why are some Posted Code (POST) fields in transaction tables, like the F03B11 and the F0411, populated
with a "P" instead of a "D?"

Answer: The Posted Code value of "P" in the F0911 table signifies a posted record. However, a posted code value of "P"
in a transaction table (F03B11 or F0411) designates the records as being in a pre-post state. A record could be in a pre-
post state because it had been submitted to post, but the post failed, or the record may have been previously posted, then
modified or voided, requiring the record to be submitted to post again.
---------------

Question 3 - If a posted batch is accidentally submitted to post again will the batch "double-post" to the Account Balances
(F0902) table and/or create additional automatic entries (AEs)?

Answer: No. When a batch is submitted to post, the Post program will skip over entries that are marked as posted and
post only the unposted records. Also, if the data selection of the R09801 includes the criteria, "Batch Status (F0011) is
equal to 'A,'" the batch will not be selected if the batch header (the associated header record for the batch in the F0011) is
marked as posted. All XJDE* and ZJDE* versions of the R09801 have data selection with this criteria. Submitting a posted
batch with data selection set for approved batches only will create a report with the message "No Data Selected."
---------------

Question 4 - Why do some Account Ledger (F0911) records have a value of "AE" in the Line Extension (EXTL) field while
others have blank values?

Answer: The General Ledger Post program (R09801) in PeopleSoft® EnterpriseOne tracks which General Ledger
(F0911) records the Post program created and which F0911 records were created at the time of the transaction entry. In
PeopleSoft® World, one program both creates and posts the necessary records. However, in PeopleSoft®
EnterpriseOne, separate business functions create the records and post them. For example, when a payment is written in
Accounts Payable or a receipt is entered in Accounts Receivable, no F0911 records are created until the Post program is
run. When the Post is run, a pre-post business function creates the F0911 records for the payment or the receipt and
another business function posts the amount to the Account Balances (F0902) table.

If the Post fails with errors in the batch, any F0911 records created by the Post must be removed so that unbalanced
records do not remain in the F0911. The AE value in the EXTL field is a flag for the Post to determine which records must
be removed to return the F0911 table back to its status prior to the failed posting.
---------------

Question 5 - Why are AE documents not created when the Post program (R09801) is submitted to post out of balance?

Answer: Posting will produce two types of AE documents: Automatic Offsetting Entries (AEs) for Accounts Payable and
Accounts Receivable transactions, and Intercompany Settlements entries. Posting out of balance prevents the creation of
Intercompany Settlements, but the AEs for A/P and A/R transactions are still created.
---------------

Question 6 - What if the Post program did not write needed tax entries to the Tax file (F0018), can the F0018 still be
updated?

Answer: Re-submitting a posted batch to post again will not create the entries in the F0018 because the Post program
skips posted records. If not created through the Post program, tax entries have to be manually created through the Tax
File Revisions program (P0018) on the Tax Processing and Reporting menu (G0021). To have the Post program create
the entries for future batches, enable the R09801 processing options on the Taxes tab.
---------------

Question 7 - What causes the error "not authorized to change batch status" when attempting to post a batch? OR Why is
the "Post by Batch" and/or "Batch Approval" option disabled (grayed-out) in the Row exit bar?

Answer: The Post Security Constants (P00241) on the G/L Advanced_Technical Operations menu (G0931) have been set
up to secure the user from approving or posting batches. Either remove the user from the list of Secured Users or
uncheck the box(es) enabling security. Since these are constants (which are cached information), it is necessary to log
out of EnterpriseOne for the changes to take affect.
---------------

Question 8 - Why does the Post program fail with intercompany settlement errors if only one company is included in the
batch?

Answer: If Intercompany Settlements have been enabled in the General Accounting Constants, a valid ICCC Automatic
Accounting Instruction (AAI) must exist for all companies. An ICH AAI is also required if a hub company is used. The Post
program will validate these AAIs prior to checking the details of the transactions and the companies involved in the batch.
If all intercompany AAIs are not all defined, the batch will fail and an intercompany settlements error will be sent to the
Work Center.
---------------

Question 9 - What causes a post to fail and issue "commit failed" errors referencing Z tables (outbound transaction tables,
like the F0411Z3 or F0911Z4) in the jde.log?

Answer: This is most likely caused by having interoperability functionality enabled. When activated, interoperability
processing will attempt to write records to the associated outbound tables in addition to the Post's attempt to write to the
internal EnterpriseOne tables (e.g. F0411, F0911). If the interoperability process is unable to write to the Z table(s) it will
cause the entire Post process to fail.
---------------

Question 10 - Is it possible to set up batch posting so that the jobs process at a time when the server is not busy?

Answer: Batches can be submitted to a subsystem queue for processing at a later time. Batches can also be run using
EnterpriseOne Scheduler, where the specific time to run jobs can be scheduled.
---------------

Question 11 - Why is the Post Error Report (R09801E) created for some failed post jobs but not for others?

Answer: For performance reasons, the R09801E report is only created when a batch fails due to an out of balance
condition and was not set to allow out of balance posting.
---------------

Question 12 - What is the best method to begin troubleshooting a batch that errored during the post?

Answer: First, check the Work Center for error messages. Look for "R09801 Completed with Errors" and expand these
messages to find the specific batch, and possibly, a specific transaction that caused the post to fail. Use the messages to
search the Knowledge Garden for clues on how to resolve the post failure and investigate the specific transaction(s) for
problems. If further help is needed, Support Assistant has profiles for specific batch types that can be run to gather
information about the batch

Title: Manually Create an Automatic Entry (AE)

----------------------------------------------
Abstract: Documents how to manually create an AE when the entry is not created by the posting of a batch.
---------------

Purpose

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. 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)). R09301 shows 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.

Create Manual AE

Follow these steps to properly create a manual AE entry.

Note: It is recommended that these steps be done during off-peak hours.

1) 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. 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
· G/L Date - Original G/L date of the batch*
· 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.

* If the offset method in the Accounts 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
G/L date of the corresponding record.

Verify that this G/L period is open or that the "allow PBCO posting" field in the GL constants (P0000) is
checked so the record can be posted.

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 Line
Number (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 A/P Orig Doc to G/L by Batch (R04701) or A/P
Payments to G/L 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 G/L by Batch Integrity (R03B701) or A/R 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.

INTRODUCTION

The status of Accounts Receivable (A/R) batch header records (F0011) for both invoice (IB) and receipt (RB) batch types
should always display a posted code (POST) of D when a batch is posted. The detail for A/R Invoices Batches is located
in the Customer Ledger (F03B11) and Invoice Revisions (F03B112) tables. The detail for Receipt batches resides in the
Receipts Header (F03B13) and A/R Check Detail (F03B14) tables. There can be a discrepancy in the batch header
showing the batch as not posted, even though the detail transactions of the batch are posted. The functionality of how a
batch is reopened that causes this issue is explained below.

FUNCTIONALITY PRIOR TO Xe

When drilling into a transaction that was created from A/R from a Journal Review application (P0011) and pressing OK,
the program reopens the batch. The Batch Status field is changed from Posted (D) to a status of either Pending (P) or
Approved (A) depending on whether Management Approval of Input is activated in the A/R Constants for Company
00000.

NOTE: If there is no need to reopen the batch to post new transactions, do not press OK after reviewing the transaction.
Press Cancel instead.

Xe FUNCTIONALITY

Posted invoice batches are no longer reopened by pressing OK, unless the invoice amount is changed.

CORRECTING BATCH HEADER RECORDS

To correct batch header records, run the Batch to Detail & Out of Balance program (R007031) located on the Integrity
Reports and Updates menu (G0922). This program validates the posted code of the transaction detail lines against the
status of the batch header. If all transactions in a batch are posted, the program changes the status on the batch header
record to Posted (D).

The integrity report Transactions to Batch Headers (R007021) reports any batch headers that are in a posted status, but
have transactions that are not posted.