posterJob

Overview

The posterJob performs the following primary functions.

• Validation of data: Validates there are no errors in the transactions generated by General Ledger processing including pending entries that affect encumbrances, reversal entries, and indirect costs.
• General Ledger Posting: Posts entries to the General Ledger and updates balances and encumbrances.
• ICR entry generation: Generates indirect cost recovery expenses and income entries and calculates the indirect cost on any outstanding encumbrances.
• Demerge: Identifies and de-merges errors to be corrected using the General Ledger Correction Process document.

Poster

Data is run through a final validation before being posted to the General Ledger to ensure that it is complete and correct.

• Pending ledger entries previously validated by the scrubberJob are validated again to ensure that entries generated by other parts of GL processing, such as offset generation or capitalization, do not have errors. 
• Validated GL origin entries update the GL Balances and Sufficient Funds Balances table. The account sufficient funds code is used to determine the level at which Sufficient Funds Balances are maintained.
• Encumbrances: If the transactions affect encumbrances, the GL Encumbrance table is updated.
  • When a new encumbrance is added the encumbrance amount is set to the total amount.
  • When adjustments are made to existing encumbrances, the Encumbrance Update Code and the parameter OPEN_AMOUNT_DOCUMENT_TYPES is used to determine if the Open or Closed amounts are increased/decreased. 
    • Encumbrance Update Code R will update the Reference Document number closed amount. 
    • Encumbrance Update Code D will update the Document Number closed amount. 
    • Encumbrance Update Code N will not update the Encumbrance Balances table. 
  • Purchase order encumbrance entries are handled differently because a single purchase order may have several document numbers. Each time the purchase order is amended or otherwise modified, a new document number is generated for that transaction but the purchase order number (Reference Document number) remains the same. Specific document types that will always update the open amount of the Encumbrance table are defined in parameter OPEN_AMOUNT_DOCUMENT_TYPES - these doc types are primarily Purchae Order types.
  • Payment requests, credit memos or Journal Vouchers applied to the Purchase Order are document types not defined in the parameter so they always increase or decrease the Purchase Order Encumbrance Close Amount column.
• Reversals: If General Ledger origin entries contain a date in the Reversal Date field these transactions are stored in the General Ledger Reversal table until the reversal date is reached in order to generate the reversal entries.
• Demerge: The Demerge process moves all accounting entries associated with document numbers that have errors to a PostErrs file in the staging/gl/originEntry folder in order to prevent unbalanced transactions from posting into the General Ledger. The PostErrs 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. For more information about this file and other files generated by the General Ledger batch processes, see Poster Files. 

Business Rules

•    Chart code,  Balance type, Object Type  must exist in the Chart table and be active

•     Account number must exist in the Account table

•     Fiscal year must exist in the System Options table

•     Transaction ledger entry amount must be numeric

•     If Balance Type offset generation attribute is Y, the transaction debit/credit code must be C or D.

•     If Balance Type offset generation attribute is N, the transaction debit/credit code must be blank.

•    The Account Sufficient Funds Code value must indicate an object for sufficient funds checking.

Parameters

Name	Description
OPEN_AMOUNT_DOCUMENT_TYPES	Defines the document types that should always update the open amount of the Encumbrance table.
CURRENT_AND_LAST_YEAR	The month and day marking the end of non-year end transaction document processing in order to determine which version of the GL Summary Report to run.
CURRENT_YEAR_LOWER	The month and day near the end of a fiscal year when the accounting cycle will begin producing a GL Summary Report for the next fiscal year.
CURRENT_YEAR_UPPER	The month and day near the beginning of a fiscal year when the accounting cycle will stop producing a GL Summary Report for last fiscal year.

Reversal Poster

Reversal dates may be entered on a select group of documents such as the journal voucher or accrual voucher or may be provided by batch feeds from other systems. Financials will process any reversal entries that have a reversal date equal to or earlier than the current date.

This process derives the fiscal year and period code from the reversal date unless that period is closed, in which case the current period is used. It reverses the debit/credit code of the original transaction, appends the prefix AUTO-REVERSAL to the document description, and sets the reversal date to blank. Entries are validated to ensure that there are no errors and then posted to the GL.

Reversal Business Rules

•  If Reversal Date is not found in the University Date table, the transaction is flagged with an error (the message DATE FROM GL REVERSAL IS NOT IN THE UNIVERSITY DATE TABLE is generated) and reversal processing stops for this transaction.
• If the Reversal Date is not in the Fiscal Period table, the transaction is flagged with an error (the message REVERSAL DATE IS NOT IN FISCAL PERIOD is generated) and reversal processing stops for this transaction.
• If the Fiscal Period has a status of CLOSED, use the current date and fiscal period instead, unless the current date is not in the University Date table.
• If the current date is not in the University Date table, the transaction is flagged with an error (the message CURRENT DATE IS NOT IN THE UNIVERSITY DATE TABLE is generated) and reversal processing stops for this transaction.
• Following the same business rules used in the main GL posting function, the pending reversal entries are evaluated to determine whether or not they should be included for ICR. GL expense transactions will be generated for applicable entries.

Indirect Cost Recovery

• ICR expenses and income entries are generated using the values defined on the Indirect Cost Recovery Rate table.  In order to generate indirect costs, transactions must have an object type code that has the ICR Selection Type value set to Yes and the Indirect Cost Rate of the account must not be blank.
• Expenses may be restricted by directly excluding the account which are maintained in the Indirect Cost Recovery Exclusion by Account form or exclusions can be restricted by object code which are maintained in the Indirect Cost Recovery Exclusion by Type form.
• Generated entries will have a document number which is set to the run date (YYYYMMDD), and the transaction identifies the item as a charge or income with the ICR type, ICR percentage, object code of the original expense, and direct cost amount. The chart, account number, sub-account, object code, sub-object code, and debit/credit code are based on the values in the Indirect Cost Recovery Rate table. The amount of the ICR transaction is set to the original direct cost amount times the defined ICR percent.

ICR Business Rules

• ICR indicator of the object type indicates expenditures directly related to a project.
• Indirect Cost Rate ID of the account number must exist in the Account table.
• Fiscal period code is 01 through 13.
• Sub-account type code must not indicate a cost share account.
• Object code exists in the Object Code table.
• Chart code, account number, reports to chart code of object code, and reports to object code do not exist in the Indirect Cost Recovery Exclusions by Account table (by agreement with sponsor or agency, some types of direct expenses may not be eligible for ICR).
• Chart code, account number and object code do not exist in the Indirect Cost Recovery Exclusions by Account table (the COA/Account is excluded for some object codes, but not the reports-to object code).
• ICR type code of account and the expense object code do not exist in the ICR Exclusion by Type table.
• ICR type code of the account, reports to chart code of object code, and reports to object code do not exist in the ICR Exclusion by Type table. (Sponsor or agency does not reimburse some types of expenses that the institution groups by object code within ICR type code.)

Indirect Cost Recovery Encumbrance

This process retrieves all GL encumbrances for applicable balance types and calculates ICR for each encumbrance and the indirect cost on the outstanding encumbrance amount.

Generated entries will have the same as the values of the original encumbrance with the following exceptions:

• Transaction Ledger Entry Description: ICR Encumbrance Document Type and Document Number. (i.e. ICR Encumbrance PO 23253)
• Object Code will be associated with the ICR Rate.
• Origination code will be the value set in ENCUMBRANCE_ORIGINATION_CODE.
• The amount of the ICR transaction is set to the outstanding encumbrance amount times the ICR percent identified on the table.

ICR Encumbrance Business Rules

• ICR indicator of the object type indicates expenditures directly related to a project.
• Indirect Cost Rate ID of the account number must exist in the Account table.
• Fiscal period code is 01 through 13.
• Sub-account type code must not indicate a cost share account.
• Object code exists in the Object Code table.
• Chart code, account number, reports to chart code of object code, and reports to object code do not exist in the Indirect Cost Recovery Exclusions by Account table (by agreement with sponsor or agency, some types of direct expenses may not be eligible for ICR).
• Chart code, account number and object code do not exist in the Indirect Cost Recovery Exclusions by Account table (the COA/Account is excluded for some object codes, but not the reports-to object code).
• ICR type code of account and the expense object code do not exist in the ICR Exclusion by Type table.
• ICR type code of the account, reports to chart code of object code, and reports to object code do not exist in the ICR Exclusion by Type table. (Sponsor or agency does not reimburse some types of expenses that the institution groups by object code within ICR type code.)

Indirect Cost Recovery (ICR) Parameters

Name	Description
DOCUMENT_TYPE	Document type used on the indirect cost recovery actual and encumbrance entries created by the posterJob.
ENCUMBRANCE_BALANCE_TYPES	Encumbrance balance type codes included by the posterJob when calculating indirect cost encumbrances.
ENCUMBRANCE_IND	When set to Y indirect cost recovery encumbrances will be calculated and posted by the posterJob.
ENCUMBRANCE_ORIGINATION_CODE	Origination code used on the indirect cost recovery encumbrance entries created by the posterJob. Entries with this origination code are also excluded from having indirect cost recovery calculated.
EXCLUSIONS_IND	When set to Y the posterJob walks up the object code reports-to hierarchy checking every level to see if an Indirect Cost Recovery Exclusion by Type or Indirect Cost Recovery Exclusion by Account exists for the given transaction. When set to N only the transaction's object code and the top level object code of the hierarchy are checked.
FISCAL_PERIODS	Fiscal periods excluded from indirect cost recovery calculations by the posterJob.
TYPE_CODES	Indirect cost recovery type codes excluded by the posterJob when creating actual and encumbrance indirect cost recovery entries.