Data is validated before being posted to the General Ledger to ensure that it is complete and correct.
Financials transaction documents generate pending ledger entries automatically. Financials validates transactions created via documents in various ways, using the Chart of Accounts and business rules to ensure that the entries generated are complete and without errors. Even so, these transactions undergo the same scrubber validation as entries from other sources to catch anything that may have happened after a transaction is approved.
Transactions that are fed into Financials from an outside system (such as a payroll or external billing system) are more likely to send data in need of correction because they may not be integrated with the Chart of Accounts. For example, an external system might try to apply expenses to a closed account because that external system does not have access to the data in the Chart of Accounts.
The transaction validation process checks to make sure that accounting string values (such as account, object code and sub-object code) are valid. It also ensures that the transaction has proper identifying information (such as a document number, document type and origination code indicating the system it came from.
Because some systems may not be capable of providing all of the information required to post a General Ledger transaction, the scrubber may assign some attributes to complete the transaction.
If necessary, the scrubber can assign a fiscal year, fiscal period, and transaction date to a transaction based on the system date (which is determined by the date on which the batch process is run). It can also assign an object code type based on the object code of the transaction.
Unless otherwise noted, documents associated with any transaction that fails the following validations will not post.
The error records will be placed in the ScrbErr file (For more information about this file and other files generated by the General Ledger batch processes, see Scrubber Files. This file can be retrieved using a General Ledger Correction Process (GLCP) document which allows for the manual correction of errors so the associated documents may be re-posted in a future batch cycle.
- Origin code must exist in the Origin Code table.
- Document number is required.
- Chart code must exist in the Chart table and be active.
- Account number must exist in the Account table.
- If the document type is in parameter ANNUAL_CLOSING_DOCUMENT_TYPE and the period is BB (Beginning Balance) or CB (Cumulative Balance) entries will post to closed accounts. Otherwise, the account cannot be closed.
- Sub-Accounts must be valid and active.
- Object must exist in the Object Code table.
- If an invalid, inactive or blank sub-object code is used, the value will be replaced with dashes.
- Balance type must exist in the Balance Type table.
- If the Origin Code is defined in the OBJECT_TYPE_BYPASS_ORIGINATIONS parameter and the Object Type code is empty; or if the Origin Code is not in the OBJECT_TYPE_BYPASS_ORIGINATIONS parameter, replace or add the Object Type code associated with the Object Type.
- Object Type code must exist in the Object Type table
- Fiscal year must exist in the System Options table
- Fiscal period must exist in the Accounting Period table and be open
- Transaction entry sequence number must be numeric. Null and blank values will be replaced with zeroes; non-numeric transactions will be demerged for correction.
- Transaction ledger entry amount must be numeric
- If Balance Type offset generation is Y or C, the transaction ledger entry amount must be greater than or equal to zero.
- If Balance Type offset generation is not N, the transaction debit/credit code must be C or D.
- If the transaction date doesn’t exist in the University date table, the invalid date will be replaced with the current date.
- If the origination code is in the TRANSATION_DATE_BYPASS_ORIGINATIONS parameter, the transaction dates in the file will be used instead of the date the file is processed.
- Document type must exist in the Document Type table.
- Project codes must be active and valid.
- If the reference document number is not blank, then the reference document type must exist in the Document Type table.
- If the reference document number is not blank, then the reference origin code must exist in the Origination Code table.
- If the transaction encumbrance update code is R, then the reference document number cannot be blank.
- If the reversal date is entered, it must exist in the University Date table.
- If the Balance Type encumbrance indicator is Y and the Object Type fund balance indicator is Y, then the transaction encumbrance update code must be D, R or N.
- If the Object Type code is expense and the Balance Type code is Actuals or Encumbrance, the sub-fund group must exist in the Sub-Fund Group table. Sub-Fund Group is derived from the account number.
The following parameters are used by the scrubberJob during data validation.
Specifies origination codes that will not be updated to match the object type assigned to the object code. This is used to ensure that files coming from external sources have the correct object type code.
Specifies for which origination codes, the transaction date in the file should be used instead of the date the transaction is processed. This is normally used for payroll feeds, so that payroll system and the financials system have the same dates.