| Purpose |
| Questions and Answers |
| Question 1: After upgrading to 8.11SP1 or any subsequent release, the R099102 Repost report prints a long list of discrepancies marked as "Debits". How to deal with this situation? |
| Question 2: What is the difference in functionality between the Account Balance to Transaction Report (R09705) and Repost Account Ledger Report (R099102)? |
| Question 3: If R099102 happens to update prior year F0902 records, what should be done in order to update Balance Forward amounts? |
| Question 4: Why does R099102 report sometimes take so long to process? |
| Question 5: If the R099102 repost is running in final (update) mode, can it be canceled without affecting/damaging anything? |
| Question 6: Is it safe to set up R099102 Repost report to run on a scheduler? |
| Question 7: Are there any special considerations while reposting Unit Ledgers like AU? |
| Question 10: When R099102 is showing discrepancies for certain accounts with subledger values (upper and lower case). How can these be fixed? |
| Question 11: Why does the R099102 fail with Duplicate Key and a Workcenter message stating that the record being inserted may already exist? |
| Question 12: Since R099102 fails to update F0902 for an account with no posted F0911 records, how can the F0902 balances be cleared for the same account? |
| Question 13: Why doesn't the Repost Account Ledger (R099102) program update the F0902 Week to Date (AWTD) data, and how can this data be corrected? |
| Additional Resources |
This document provides answers to some frequently asked questions on the Repost Account Ledger Integrity report (R099102).
Answer 1: 14 new fields AND01 - AND14 (Net Debit Posting) have been added to Account Balance (F0902) table in 8.11SP1 and forward releases to show the debit transaction into the F0902 table under the Bug 10938920 for 8.11SP1 release. The debit amount columns can be used by many various applications in E1. There are many places throughout the system where a debit or credit-posting amount is needed. Applications can retrieve this amount from the F0902 instead of having to retrieve it from the F0911 saving valuable processing time. In addition there are current Bug's in process such as one for R09473 Debit Credit T/B by Object report to change its method of balance retrieval from F0911 to F0902 making use of the new debit column. For future development, anytime a debit or credit balance is needed, it would always be retrieved from F0902 instead of F0911. Therefore it is very important to keep these amounts updated correctly in the F0902. For these reasons, it would be recommended that customers maintain correct postings to all columns in the F0902.
Once AND01 - AND14 (Net Debit Posting) columns are updated, the post process will keep the amounts in sync.
Moreover in 8.11SP1 releases and subsequent, the R099102 resulting pdf shows the results as "Debit" for all accounts even if the discrepancies are only with the Net Posting fields (AN01 - AN14). By looking at the report, one cannot tell if the issues are with the ANxx fields or with the ANDxx fields in the F0902 because all the records in the report are marked with "Debit". This issue has been addressed and fixed as follows:
Prior to this fix, "Debit" was coming for all transactions including the Net Posting ANxx, hence user was unable to identify the discrepancies. After this fix," Debit" will appear only for Net Debit Posting ANDxx.
Answer 2: Both R09705 and R099102 read and compare the Account Ledger (F0911) and Account Balances (F0902) files for accumulated ledger amounts but have following differences:
Example: If account 1.1110.BEAR has an AA ledger amount in the F0911 of $100 and an amount in the F0902 for $200 for period 8 of 2008, this condition would appear as an exception on both the R09705 and R099102 reports. But to correct this, only the Repost Account Ledger would update the F0902 amount with the F0911 amount ($100).
For more information on R09705, please refer to Overview of Account Balance to Transaction Integrity Report (R09705).
Answer 3: If the correction takes place in a prior year, the Annual Close (R098201) should be submitted for the year affected in order to refresh balance-forward and retained earnings amounts. For more information on R098201, please refer to Overview of Annual Close Report (R098201).
Answer 4: R099102 reads the Account Ledger (F0911) file and depending on the data selection used it may take hours to process. Typically the F0911 file in production environment will contain millions of records. If an imbalance can be narrowed to a small group of accounts or a particular year, use Account ID (AID) and Fiscal Year (FY) in the R099102 data selection.
Answer 5: The R099102 can be terminated but it should be known that this can cause data corruption in the F0902 and that might require the R099102 to be submitted again. The R099102 takes the current information from F0911 and updates the F0902, therefore ensure that data in F0911 is always consistent.
Answer 6: Regarding scheduler, it is not advisable to run the R099102 in update mode on the scheduler. In order to see if there are any discrepancies between the F0911 and the F0902, the R099102 can be submitted in proof mode on the scheduler. If the report comes up with any exceptions, they should be examined and if necessary the R099102 should be submitted in update mode to correct imbalances between the F0911 and F0902 files.
Answer 7: The system automatically reports the associated unit ledgers when an amount ledger is reposted. For example, to repost an actual amounts ledger (AA) with units (AU), enter ledger type AA in the data selection. The system reposts both the amount and unit ledgers.
Answer 8: Its a known issue addressed and fixed for Xe release under Bug 10749651.
Answer 9: The reason is that the R099102 Repost report does resolve any units imbalance, but then falls into code and tries to Insert the existing F0902 for the 2X ledger (duplicate key error). The General Accounting documentation states "You can create additional ledger types. Ledger types U1-U9 and UA-UZ are provided for your business needs. These ledger types are for your use only and cannot be overwritten or used for other purposes in future releases of JD Edwards EnterpriseOne software."
Ledger Type 2X and 2U are not valid. Using accepted example of UA to UU will repost successfully, correct any imbalance and not show failures on PDF or Work Center regarding inserting to the F0902. It is further suggested when using these user defined ledger types to use letters (example UA and UU) or numbers (example U1 and U9), but not mix them (example UA and U1). Also the "units" ledger should have a lower sort order (don't use UX ledger and UU ledger for units).
Answer 10: The R099102 Repost report does not have the capability to distinguish between upper case and lower case values and hence will treat them differently. This was clarified by the Development under the Bug 10965522. Since the value of SBL (Subledger Value) DD Item is by default checked as "Upper Case Only", any transactions being entered in the JDE system by any of the applications or reports should always be converted to upper case only.
Hence it would be recommended to ensure that the Subledger Value (SBL) DD item attirbute is setup correctly as "Upper Case" only. Further, there have been known issues where certain standard JDE interfaces such as R09110Z (Bug 10965522) and R04110ZA (Bug 17824443) reports have been found responsible for creating the F0911 records with SUbledger values in the mixed case i.e. both upper case as well as lower case. This will end up creating integrity issues if these F0911 records are processed by the R099102 Repost. Moreover, in scenarios of similar occurrences, it will be recommended to proceed as follows:
1. Find out the source or origin (Batch Type, Program ID) of the given transactions in question and log a Service Request with Oracle.
2. In order to fix the current data, it would be required to update the existing Subledger values to align all of them into the upper case in F0911 table, followed by clearing F0902 for the related records and then rebuilding correct F0902 via R099102 Repost.
Answer 11: There are known issues with using special characters in subledger that may cause comparison problems between the F0911 and F0902 during processing of the repost. The subledger is part of the primary key for the F0902. The repost could fail to find an existing F0902 Account Balance record and use an Insert instead of Update statement which would cause the Duplicate Key failure. It is not suggested to use special characters only letters and numbers for subledger.
Answer 12: The R099102 Repost report does not process the Account Balance (F0902) records, if it does not have any corresponding Account Ledger (F0911) posted records. In this case, you may consider the following options to clear the erroneous F0902 Account Balances:
Answer 13: Repost Account Ledger R099102 will not update the week to date field (AWTD) in table F0902. This is a known issue and is addressed in enhancement Bug 10749633 - R099102 AND AWTD FIELD - SAR: 5028846.
To speak to the functioning of this field, the AWTD field on the F0902 file really has no functionality other than as an aggregate balance of the amounts in the fourteen bucket AN01-AN14 fields. When posting normally via R09801, this field is updated as well as the applicable period bucket on an account. If the Repost Account Ledger is ever run to correct balances, the AWTD field is not updated, so the amount in that field will differ from the recalculated totals of periods 1-14. You will have no issues at all in your system if the value in that field is incorrect. The Annual Close process, and all financial reports are based on the values in the period buckets, and the APYC field. The AWTD is never used. AWTD is a week to date figure, and only has meaning if you are using 52 period accounting, and even then, you use the F0902B file which is the 52 Period Accounting Account Balances file.
If you want to keep this data field "clean", then you would have to use a data base utility to update the amounts manually to match the aggregate of the 1-14 period bucket fields, but again, from a functional standpoint you shouldn't need to do this. If a database utility is used to correct the AWTD figures, please ensure that backups of the data to be modified are taken prior to any action.