This chapter contains these topics:
Section 14.3, "Correspondence Journal Entry Review (P74R0911),"
Section 14.6, "Correspondence Account Balance Year Close Process."
When a batch is selected for posting, the base software posting process performs some validations and if no errors are found, the account balance is updated (file F0902). An additional validation operation verifies account correspondence processing methods and rules.
The posting process is composed of two steps:
Preposting
Posting
The preposting process performs editing for each batch that is selected for posting. An additional editing process validates accounting correspondence for each transaction document inside the selected batch.
If the correspondence constant is set to perform correspondence account editing for the company, the system performs the following operations for each batch and transaction document:
Retrieves correspondence processing method set up.
Identifies the pairs of debit / credit legal accounts according to the processing method.
Determines if a rule exists for each debit / credit legal account.
If no rule exists, updates the batch as in error and prints detailed information about the account pair in error.
For batch types that are not created in balance at transaction entry time, where the posting process creates automatic entries (document type AE), those entries are taken into account by the editing routine. This is typically the case for batches that come from the A/P or A/R subsystem.
The error report includes the following information:
Batch type
Batch number
Posting version (DREAM Writer version)
Transaction document type
Transaction document number
Transaction document company
Transaction general ledger date
Transaction company
Processing method for document type/batch type
Debit Account (mcu.obj.sub)
Credit Account (mcu.obj.sub)
Debit legal account (obj.sub or category code)
Credit legal account (obj.sub or category code)
Transaction amount
Error description
The accounting correspondence error report prints in conjunction with base software posting reports and includes information for all batches selected for posting.
Caution:
If the base software preposting report hasn't found any editing errors for a given batch, but the account correspondence editing routine detected an error for at least one transaction belonging to that batch, the entire batch will not post. Only batches without errors of any kind will post successfully and update the account balance file (F0902).It is important to fix issues as they are encountered instead of leaving them until the end of the month. Due to the intensive first time set up that is required for processing, it is probable that many errors will be found during the first months of implementation, but they will tend to be reduced as the set up is fine tuned.
When the void or reverse of a transaction is posted, the correspondence rules editing functions as if it were the original transaction but with opposite sign. Due to the nature of the system, when a transaction is voided, the debit account turns to be the credit account and vice versa. According to the Russian accounting rules, a debit account is always a debit account with sign.
For instance, suppose the following journal entry:
Account | CR | DR |
---|---|---|
Expense account | 100 | |
Bank account | -100 |
This is a valid transaction according to Russian correspondence rules because the expense account can be used in conjunction with a bank account.
If the transaction is voided, the system will record:
Account | CR | DR |
---|---|---|
Bank account | 100 | |
Expense account | 100 |
According to Russian correspondence rules, this is not a valid transaction because the expense account should always be used as a debit account. If the above transaction is entered manually into the system, it will not post because of the correspondence rules editing. But, as the above transaction has not been manually entered, instead it is automatically created by the system when the user voids the original transaction, it should be valid. The correspondence rules editing routine will take that into account and accept it as valid.
The Correspondence Journal Entry Review program (P74R0911) allows users to review online a correspondence journal entry. The program allows changes to correspondence distribution amounts, but will not allow users to add lines or remove entries. Once the correspondence journal entry is posted, no more changes will be allowed.
To review correspondence journal entries
From (G74R09), choose option 14 (Journal Entry Review)
Type I (Inquiry) in the Action Code field.
Complete the following:
Document Type
Document - Enter the document number for the journal entry.
Company - Enter the company number.
G/L Date - Enter the general ledger date of the journal entry.
Press Enter to display the selected journal entry.
If no editing errors are found by preposting, the posting is executed to update the account balance file (F0902). The posting process will also update the correspondence transaction detail file (F74R0911) with information about each correspondence debit/credit detail line that comprises the transaction posted.
After the posting process has successfully completed, the correspondence transaction file has correspondence information for the posted transactions.
The last step in the process is to post correspondence journal entries to the correspondence account balance file. This file is similar to the F0902 file. In this batch process, the user selects the unposted correspondence transactions and the account balance file is updated.
This program verifies the integrity in the Correspondence Journal Entry file (F74R0911).
The program compares the regenerated records of F74R0911 based on F0911 and the existing records of F74R0911 generated during standard posting process.
The information printed is selected by DREAM Writer from the Account Ledger file (F0911). The mandatory minimum data selection is:
G/L Posted Code = P (GLPOST)
The process generates the following three reports:
R74R0970
Contains the specific document of a batch that has a difference between old information of F74R0911 and the regenerated information (if there is more than one document in the batch, only prints the one that is different).
The document that appears in this report replaces the existing information.
Report information:
Old batch - Identifies the existing F74R0911 information
New batch - Identifies the recalculated F74R0911 information
Batch type
Batch number
Mode (based on PO 1, proof, or final)
Document type
Document number
Document company
G/L date
Company number
Ledger Type
Currency code
Correspondence method
Debit amount
Credit amount
Reverse/Void flag
Primary account: Doc ty/Nbr/Company/JE line nbr/Legal nbr
Contra account: Doc ty/Nbr/Company/JE line nbr/Legal nbr
"*" indicates in the new batch the different line
R74R0971
Contains the batches that processed without error. If the entire batch is identical (i.e., the recalculated and the old F74R0911 records are identical), the report prints with the following information:
Batch Type
Batch Number
R74R0974
Similar to the error report generated in the standard posting process, this report is generated as a result of editing process of the information retrieved from F0911 and validations according to Correspondence set up of Method, Account, and Rules.
The report contains the following information:
Batch Type in error
Batch Number in error
Document type
Document number
Document company
G/L date
Company number
Ledger type
Correspondence method
Journal entry amount
Debit amount
Credit amount
Primary account journal entry line number
Primary account Obj/Sub or Legal number
Contra account journal entry line number
Contra account Obj/Sub or Legal number
Error code
At the end of the fiscal year, after all transactions have been posted to the F0902 file and to the correspondence account balance file (F74R0912), the correspondence year close process is executed to update the new fiscal year beginning of year account balance amount.