GENERAL LEDGER
Business Case Review
Journal Mover
OVERVIEW: This Journal Mover engine would dramatically simplify the process to perform a bulk reclass as the user could simply
search and select the lines to reclass and enter the reclass destination. The engine would create all of the necessary debits and
credits. This process would be easier than creating a traditional Journal Entry via the delivered Journal Entry pages. There are several
areas where this process would solve existing problems:
• A lot of the data movement/reclass needs today result from Grant transactions that need to be reclassified due to: (1) Fund Codes
corrections (2) cost transfers (3) cost sharing
• Grant Out of Bounds Corrections – this is another type of correction entry that originates due to transactions attempting to charge a
grant after the allowable project close window.
• Details of current reclassification or correction entries are currently lost and are therefore not easily traceable in the data warehouse
reporting.
RECOMMENDATION: Create a new custom Journal application that has the ability to move/reclass Journal Lines using the
transaction level detail from All Trans query results as the data source. All Trans contains details from certain accounting line tables all
pulled together into one location with a one-day lag. Transaction level details including Vendor, Invoice, and Payment information from
All Trans are necessary for the user to easily identify the transactions to reclass plus GL only holds summarized data from the
accounting tables due to Journal Generation process. The tool should allow a User to
(1) search for transactions that are candidates to move/reclass
(2) have the ability to select specific lines to move/reclass
(3) the ability to enter the reclass SpeedType location.
Owners
Overall Process & Policy Change Owners
Belva White, Kerry Peluso
Module Owners
Project Work Owners
David Giles
2
David Giles
Journal Mover
Impacts
People
Process
System
Module Support
Central Administration
Grants Administration would be able to more efficiently review cost transfers and
adjustments due to the detail included in the proposed entry.
Campus Users
The engine would create all of the necessary debits and credits so accounting
backgrounds for end users would be less than required for a regular journal entry.
Module Support
Allows combo rules to be bypassed without turning them off system wide.
Central Administration
Allows for the correction of journals using an invalid chartfield string.
Campus Users
Simplify the process to perform a bulk reclass as the user could simply search and
select the lines to reclass and enter the reclass destination.
Module Support
Eliminates the need for technical assistance for each GOOB journal.
Central Administration
Campus Users
Training
Allows campus users the ability to move transaction lines at the detail level instead of
the summarized level.
Module Support
Central Administration
Campus Users
3
Journal Entry Engine
OVERVIEW: Emory has a significant number (30-40) of external systems that must send financial entries to the Compass/PeopleSoft General
Ledger (GL). The process to post these entries is known as the Journal Sweeper/Journal Entry Engine. An underlying assumption was built into
the original Journal Entry Engine (JEE) process that all entries must post somewhere. This design assumption led to a larger
than anticipated downstream cleanup effort that is more complex than expected and that also came along with unintended negative
consequences. After living with the JEE over the last five years, we are proposing a series of changes based upon lessons learned to remedy
some of the common issues that currently complicate the process to post these 3rd party entries and complicate the Month End Close process.
The proposed change removes the assumption that all entries must immediately post somewhere as part of the JEE. Rather than posting
immediately, the existence within the file of any of the following conditions would result in that line being removed from the file and the file being
re-balanced using a default ChartField combination defined based upon Source: (1) invalid Account value (2) blank Account value (3) Any
Journal line with a Project Status not set to Open or with a Project Status not set to Ended as compared with Current Date as opposed to the
Accounting Date in the source file (4) Combo Edit errors. The line that is removed from the file will be placed in a “Hold” table and a reclass will
be possible through an easy to use page. This reclass will result in the automated clearing of the default ChartField combination that was used to
balance the original file.
RECOMMENDATION: Take the lessons learned over the past five years and enhance the existing Journal Entry Engine customization. The
process would remain the same on the front end but as bad or invalid lines are detected during processing they would be removed and placed
on a HOLD table. The file would then be balanced using a default ChartField combination defined for each Source. This would allow valid
accounting lines to post as intended but prevent invalid lines from posting to suspense or using a default SmartKey for accounting lines with
project status issues (which results the need for a GOOB).
Owners
Overall Process & Policy Change Owners
Nancy Mears
Module Owners
David Giles
Project Work Owners
David Giles
4
Journal Entry Engine
Impacts
People
Process
System
Training
If Approved
Module Support
Dramatically improve current state correction/suspense process.
Central Administration
A change in roles as the function moves from decentralized to centralized.
Campus Users
Prevents the downstream issues with the data warehouse so reporting will be improved, which will help end
users.
Module Support
Dramatically improve current state correction/suspense process.
Central Administration
(1) Prevents improper cost collection for Projects (2) Allows all valid lines to post as intended but prevents
invalid lines from posting to incorrect chartfield strings. (3) The 3rd party source that originates the file will not
get 100% of recharge revenue until all lines post to proper ChartField string. This may provide an incentive for
the 3rd party sources to provide error free files in the future, they will have a vested interest.
Campus Users
Allows all valid lines to post as intended but prevents (1) Combo Edit errors from posting to a Suspense Account
and requiring a Suspense Correction (2) The need for a GOOB to reclass Project Status errors which result in
the use of a default SmartKey
Module Support
Dramatically improve current state correction/suspense process.
Central Administration
Will streamline the correction process. Today not all GOOBs are corrected from the default SmartKey. There is
no central oversight to monitor and ensure that a correction was made to reclass the entry from the default
SmartKey.
Campus Users
Will lead to better data and reporting.
Central Administration
Requires new business process to monitor and age items on the HOLD table. Please note: there is a desire to
auto reclass items in the HOLD table if the item ages beyond a certain point, however, this is not yet
defined.
Campus Users
No training required or needed.
5