Overview
The scrubberJob performs the following primary functions.
- Validation of data:
- Offset and entry generation:
- Demerge
The following table briefly describes the functionality performed by the scrubberJob. Each function is described in detail in articles linked from the Process column below.
Data Validation
Validates that data is accurate and complete prior to posting into the General Ledger. Missing and invalid values may also be completed in this step.
- 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.
Validation Business Rules
- Origination code, Chart Code, Sub-Account, Object, Balance Type, Object Type, Document Type and Project Code must be active.
- Account Number cannot be closed, unless the document type is in parameter ANNUAL_CLOSING_DOCUMENT_TYPE and the period is BB (Beginning Balance) or CB (Cumulative Balance).
- Document number is required.
- If an invalid, inactive or blank sub-object code is used, the value will be replaced with dashes and a warning is added to the scrubber.txt report.
- If the Origination code is defined in the OBJECT_TYPE_OVERRIDE parameter and the Object Type code is empty; or if the Origination code is not in the OBJECT_TYPE_OVERRIDE parameter, replace or add the Object Type code associated with the Object Type.
- 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, the transaction ledger entry amount must be greater than or equal to zero and the transaction debit/credit code must be C or D.
- If the Balance Type encumbrance indicator is Y, then the transaction encumbrance update code must be D, R or N.
- 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 TRANSACTION_DATE_OVERRIDE parameter, the transaction dates in the file will be used instead of the date the file is processed.
- If the reference document number is not blank, then the reference document type, reference origination code and encumbrance update code must exist and be active.
- If the transaction encumbrance update code is R, then the reference document number cannot be blank.
Validation Parameters
The following parameters are used by the scrubberJob during data validation.
Name |
Description |
ANNUAL_CLOSING_DOCUMENT_TYPE
|
The document type of the accounting entries generated by the year-end closing process. This document type overrides certain scrubber logic (continuation accounts, inactive sub accounts, offset generation, etc...) so entries can post in the same accounting string where the balances originated. |
OBJECT_TYPE_OVERRIDE |
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. |
TRANSACTION_DATE_OVERRIDE |
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. |
Continuation Account
Continuation Account logic is triggered when the account on the transaction has an expiration date or is closed.
- If a transaction includes an expired account and the origination code is NOT in the CONTINUATION_ACCOUNT_BYPASS_ORIGINATIONS, post the transaction to the continuation account, unless the document type is in parameter CONTINUATION_ACCOUNT_BYPASS_DOCUMENT_TYPES.
- If a transaction applies to an expired account and is not otherwise excluded, the Scrubber attempts to find a valid continuation account to substitute. Accounts are considered expired if their expiration date is less than or equal to the run date of the scrubber batch process. The expiration date of Contracts & Grants accounts may be extended by using the CG_ACCOUNT_EXPIRATION_EXTENSION_DAYS parameter.
- Financials makes ten attempts at finding a valid continuation account before reporting an error. Valid in this instance means that the account exists in the Account table and is not expired or closed. If a substitution is made, Financials adds AUTO FR and the original account number into the transaction description for tracking purposes.
Continuation Account Parameters
The following parameters are used by the scrubberJob continuation account process.
Name |
Description |
CG_ACCOUNT_EXPIRATION_EXTENSION_DAYS |
Specifies the number of days past a Contract and Grant accounts expiration date to apply continuation account logic. This parameter is used in conjunction with the CONTINUATION parameters to below. Only if the document type or origination code is also included in these parameters will the Contracts & Grant expiration date be extended by the number of days specified in this parameter. |
CONTINUATION_ACCOUNT_BYPASS_DOCUMENT_TYPES |
Specifies which document types are allowed to post to expired accounts if the initiator indicates that the transaction should post to the expired account. |
CONTINUATION_ACCOUNT_BYPASS_ORIGINATIONS |
Specifies origination codes that can post to expired accounts. |
Pre-Scrubber
The scrubber includes a pre-scrubber step that is used to complete the Chart Code for entries that do not contain them. This process is only used if the parameter ACCOUNTS_CAN_CROSS_CHARTS_IND is set to N, which prevents the same account from being used in multiple charts.
Pre-Scrubber Parameters
Name |
Description |
ACCOUNTS_CAN_CROSS_CHARTS_IND |
When set to N, the pre-scrubber process in the scrubberJob will complete the chart code for transactions that are missing them. |
Offset Generation
Offsets will be created for transactions if offsets haven’t already been created to ensure the system is balanced.
For transactions created via Financials documents, offsets should already be in place by automatically generating any required offsets when each document is submitted for approval. Prior to the batch process running, the offset transaction lines (such as offsets to cash) may be viewed within the General Ledger Pending Entries tab of a transaction document.
Financials uses the Offset Definition table to define how offsets should be generated for unbalanced transactions. This table uses information from the unbalanced transaction (such as the fiscal year and chart the transaction is being posted to and the balance type and document type associated with the transaction) to determine the object code to assign to offset entries. Transactions created in other systems may need to have offsets generated to ensure a balanced transaction.
Offset transactions are generated in the following cases:
- The document type is not in the DOCUMENT_TYPES_EXCLUDED parameter.
- The fiscal period is not included in the FISCAL_PERIODS_EXCLUDED parameter.
- If otherwise eligible and the offset generation attribute for the Balance Type of the pending entry is Y.
Normally, offsets are applied to the same account as the transaction that generated the offset.
If the USE_FLEXIBLE_OFFSET_IND parameter is set to Y, then offset entries can be posted to another specified account in order to accommodate tracking offsets such as cash or liabilities in central designated accounts as opposed to tracking such offset entries in every account.
The Offset Account document allows you to specify flexible offsets for accounts. Normally offset entries are applied to the same account that generated the offset, but with this table you can direct an accounts offsets to another account.
Offset Generation Parameters
The following parameters are used by the scrubberJob offset generation process.
Name |
Description |
DOCUMENT_TYPES_REQUIRING_FLEXIBLE_OFFSET_BALANCING ENTRIES |
Specifies which document types should look to the Offset Account table to determine which account should receive the offset. |
DOCUMENT_TYPES_EXCLUDED |
Identifies the document types that will not generate offset entries. |
FISCAL_PERIODS_EXCLUDED |
Identifies the fiscal periods for which offset entries will not be generated. |
Transaction Generation
In addition to the basic balancing offsets, additional processes in the scrubberJob can be turned on or off by your institution. The following processes generate behind-the-scenes transactions and articles that describe each are linked below:
- Capitalization of Assets Liabilities
- Plant indebtedness
- Cost share transfers
- Cost share encumbrances
Capitalization of Assets and Liabilities
If the capitalization process is turned on, the scrubberJob generates entries and offsets to properly record the capitalization of assets and liabilities. Capitalization entries are created for transactions affecting the actuals (AC) Balance Type using an object code with an asset-related object sub-type.
Capitalization entries book to a plant fund chart, account and object code.
- The plant fund chart and account is determined based on the organization associated with the account used on the original transaction that posted to the General Ledger. Campus and Organization Plant Fund chart and accounts are attributes of the Organization.
- The plant fund object code is determined by the object sub-type of the object code used on the original transaction.
- The capitalization transaction description will include Generated Capitalization or Generated Liability.
Asset Capitalization Parameters
The following parameters are used by the Scrubber Capitalization process to generate entries for allowable transactions. Component: ScrubberJobCapitalization
Name |
Description |
CAMPUS_SUB_TYPES |
Asset payments object codes with object sub types in this parameter will be capitalized on the Campus Plant Fund Account when capitalization entries are created by the scrubberJob. The Campus Plant Fund Account is assigned to the Organization associated with the asset's payment accounts. |
CAPITAL_OBJECT_CODES |
The object codes where capitalization will post when generated by the scrubberJob. The object code is assigned based on the object sub-type(s) of the original transaction. |
CAPITALIZATION_IND |
Indicates whether or not the asset capitalization process should run. |
CHARTS_EXCLUDED |
Charts excluded from the asset capitalization process. |
DOCUMENT_TYPES_EXCLUDED |
Document types that are excluded from the asset capitalization process. |
FISCAL_PERIODS_EXCLUDED |
Fiscal periods excluded by the asset capitalization process. |
FUND_BALANCE_OBJECT_CODE | Fund balance offset object code used when capitalization entries are created by the scrubberJob. If this parameter is blank, the fund balance object code assigned to the chart is used. |
OBJECT_SUB_TYPES |
Object sub-types capitalized by the scrubberJob. |
ORGANIZATION_SUB_TYPES |
Asset payments object codes with object sub types in this parameter will be capitalized on the Organization Plant Fund Account when capitalization entries are created by the scrubberJob. The Organization Plant Fund Account is assigned to the Organization associated with the asset's payment accounts. |
SUB_FUNDS_EXCLUDED |
Defines the sub-fund groups, derived from the account, excluded from the asset capitalization process. |
Plant Fund Liability Parameters
The following parameters are used by the Scrubber Plant Fund Liabiltiy Capitalization process to generate entries for allowable transactions. Component: ScrubberJobPlantFundLiability
CHARTS_EXCLUDED |
Charts excluded from the plant fund liability process. |
DOCUMENT_TYPES_EXCLUDED |
Document types excluded from the plant fund liability process. |
FISCAL_PERIODS_EXCLUDED |
Fiscal periods excluded from the plant fund liability process. |
LIABILITY_IND |
Indicates whether or not plant fund liabilities will be created. |
OBJECT_CODE |
The object code used when plant fund liability entries are created by the scrbberJob. |
OFFSET_OBJECT_CODE |
Fund balance offset object code used when plant fund liability entries are created by the scrubberJob. If this parameter is blank, the fund balance object code assigned to the chart will be used. |
SUB_FUNDS_EXCLUDED |
Sub fund groups excluded by the scrubberJob when creating plant fund liability entries. |
SUB_TYPES |
Object sub types included by the scrubberJob when creating plant fund liability entries. |
Plant Indebtedness
Plant indebtedness entries generated by the scrubberJob for notes and bonds payable are similar in nature to the capitalization entries, with a few exceptions. The original plant indebtedness entries occur on liability object codes (a balance sheet item) and, because there are fewer classifications, the same object code is used to record the item in the plant fund. Whereas the capitalization entries add items to the balance sheet (set up assets), these entries move the liability from select fund groups to the plant fund.
If the Plant Indebtedness process is turned on, bond and note liability entries are created for transactions affecting the actuals (AC) Balance Type using an account with a specified sub-fund group and object code with a plant indebtedness-related object sub-type.
- Plant indebtedness entries book to the campus plant fund chart and account associated with the organization tied to the account on the original transaction.
- Transfer to Net Plant will be included in the transaction description of the entry occurring in the original account and the description of the entry occurring in the campus plant fund account is set to Generated Transfer from (chart and account number of original entry).
- Appropriate offsets to the fund balance object code are generated to balance the entries.
Plant Indebtedness Parameters
The following parameters are used by the plant indebtedness process to generate entries for allowable transactions. Component: ScrubberJobPlantFundIndebtedness
Name |
Description |
PLANT_FUND_LIABILITY_IND |
Indicates if the Plant Indebtedness process will run. |
OBJECT_SUB_TYPES |
Defines the object sub-types that are used to determine if plant indebtedness entries should be created. |
FUND_BALANCE_OBJECT_CODE |
Fund balance offset object code to use when the scrubberJob will generate plant fund indebtedness entries. If this parameter is blank, the fund balance object code assigned to the chart will be used. |
SUB_FUNDS |
Defines the sub-fund groups for which plant indebtedness entries will be created if the object code has a specified plant indebtedness sub-type. |
Cost Share Transfers
The scrubberJob will create cost share entries based on special cost share sub-accounts.
- Cost sharing allows for sharing of costs related to Contracts & Grants accounts. Expenses associated with a grant or contract that are not paid by the sponsoring agency are considered to be cost share, and Financials can track these expenses in special cost share sub-accounts. A cost share sub-account is created as part of the contract or grant account for which costs are being shared. The sub-account is assigned a source account that identifies the account that bears the expenses that are being shared.
- Cost share transfers involve transferring of funds into a Contracts & Grants cost share sub-account (to record income), from the source account (to record the charge).
- Any expense that occurs on a cost share sub-account is eligible for this transfer of funds. Expenses occurring on selected document types or that post to specific periods may be excluded from the generation of cost share.
- For additional information, refer to Setting up Cost Share.
In order to qualify for cost share transfers, the transaction must:
- be associated with an expense object code type specified in parameter OBJECT_TYPES
- have a balance type of Actuals (AC) and
- post to a Contracts & Grants account and a cost share sub-account. Cost share sub-accounts have a sub-account type of CS.
Cost share transfers are posted at a summary level.
- The income side of the transfer is created as follows:
- Document type TF (Transfer of Funds)
- Object code specified in parameter TRANSFER_IN_OBJECT_CODE
- Origination code CS
- Document number is pre-fixed with CSHR
- Transaction description is Generated Cost Share from account XXXXXXX MM/DD
- Transaction date is the process run date
- With an appropriate offset to cash for the income side of the transfer
- The expense side of the transfer is created as above for the income side, with the following differences:
- The chart, account, and sub-account for the source account associated with the cost share sub-account
- Transaction description is Generated Cost Share to account XXXXXXX MM/DD.
- The object code is determined by the object code level specified in parameter TRANSFER_OUT_OBJECT_CODES.
Cost Share Parameters
The following parameters are used by the cost share transfer process to generate entries for allowable transactions. Component: ScrubberJobCostShare
Name |
Description |
DOCUMENT_TYPES |
Defines document types that are excluded from cost share generation |
ENCUMBRANCE_BALANCE_TYPES |
Balances types for which cost share encumbrances will be created by the scrubberJob. |
FISCAL_PERIODS |
Fiscal periods excluded from cost share by the scrubberJob. |
OBJECT_TYPES |
Object types for which cost share will be created by the scrubberJob. |
TRANSFER_IN_OBJECT_CODE |
Object code used to record cost share transfer in. The account used will be the contract & grant account associated with the cost share sub-account. |
TRANSFER_OUT_OBJECT_CODES |
The object codes used on the cost share entries created by the scrubberJob based on the object level of the original transaction. The cost share transfer out entries will post to the cost share account associated with the contracts & grants account and cost share sub-account. Format is: Object Level 1=Object Code 1; Object Level 2=Object Code 2; etc. NOTE: The parameter should also include: DEFAULT=ObjectCode to catch those entries not specified in the parameter. |
Cost Share Encumbrances
Cost share encumbrances are a management tool that enables the fiscal officer of a source account to forecast the cost share transfer activity that will occur after expenses are realized on the Contracts & Grants cost share sub-account. Any encumbrances on a cost share sub-account will trigger the generation of cost share encumbrances in the source account.
Financials checks the encumbrances associated with a cost share sub-account and generates matching encumbrances on the source account to reflect where these expenses will ultimately be applied. Eligible transactions must:
- have an expense object type defined in the OBJECT_TYPES parameter,
- have an encumbrance balance type defined in the ENCUMBRANCE_BALANCE_TYPES parameter,
- be on a Contracts & Grants account and a sub-account with a sub-account type of CS, and
- not be associated with a document type specified in the DOCUMENT_TYPES parameter.
These encumbrances are created with a cost share encumbrance balance type to ensure that they can be distinguished from the original encumbrances. Cost share encumbrances are posted at the detail level, using the same object code level mapping that is used for cost share transfers, defined in parameter TRANSFER_OUT_OBJECT_CODES.
Demerge
The GL transaction demerger process is initiated as part of the overall scrubberJob and prior to the Main Poster in the posterJob. The demerger process has several functions.
- Using the errors identified by earlier parts of the scrubberJob, it locates all of the accounting entries for each document number with a reported error and removes these transactions from processing. This action prevents Financials from posting unbalanced transactions to the General Ledger.
- It removes any offsets that were generated by the scrubberJob for the document numbers with errors. Scrubber-generated offsets are removed to prevent duplicate offset generation when the records are passed back through the accounting cycle after correction.
- The process creates a ScrbErr2 file in the Origin Entry table with all of the transactions for document numbers with errors. (ScrbErr2 is the primary error correction file for the GL Correction Process document). It also generates statistics as part of the accounting cycle control totals, recording the number of records in the error group, the number of each type of offset bypassed, the number of records passed to the Main Poster, etc.
Comments
0 comments
Please sign in to leave a comment.