E-708 Pre-GL Batch Validation

advertisement
OUM
DS.140 APPLICATION FUNCTIONAL
DESIGN - EXTENSION
E-708 Pre-GL Batch Validation
University of California
HCM - CA
Author:
Charlie Pope – Huron Consulting Group
Creation Date:
<August 13, 2012>
Updated:
<August 22, 2012>
Document Ref:
E-708
Version:
1.0
Approvals:
Document Control
Change Record
Date
Author
Version
Change Reference
8/13/2012
Charlie Pope
1.0
Initial Draft
Reviewers
Name
Linda Cornett
Janet Nichols
Ana Lebon
Cathie Staples
Cathy Rujanuruks
Mimi Belete
Brianne Compton
Terry Novorr
LeAnn Story
Paula Farrington
Pam Heintzleman
Autumn Salazar
Arvin Tumonong
Carrie Gatlin
Shaun Ruiz
Gabe Nwandu
David Gracey
Pearl Trinidad
Nini Cruz
Bill Solomon
Toni Hock
Bob Lee
Steven Engen
Monique Leduc
Walt Eissmann
Kirsten Anderson
Annie Wong
Russell Remington
Nuila Blanca
James Ringo
Cindy Jones
Lana Tymoshchenko
Position
Interim Payroll Manager
Financial Analyst
Grad Division (lead) - Director
Manager - Financial Aid Office
Prin Admin Analyst, SOM
Project Manager - Information Technology
Services
Work Study Coordinator
CAO/CFO - Brain Research Institute - UCLA
Dir, Prog & Proj Mgmt
Payroll Lead; Dir Corp Fin Srv
Director, Payroll Services
Director Of Contract And Grant Accounting
Funds Management Officer
Mgr Payroll, Personnel & Effort
Manager-Payroll Coordinator
Director Payroll
Director Enterprise Development
Director Payroll
Assoc Dir P/R
Programmer Analyst
Enterprise Systems Director
Faculty Comp Analyst
Payroll Services Director
Director, Enterprise Financial Systems
Payroll Manager
Fiscal Manager
Administrative Analyst
General Accounting Supervisor
Associate Director & Compliance Officer Office of Financial Aid & Scholarships
Accounting Services & Controls
Manager, Payroll Services
Assistant IV, Payroll Services
Organization
Irvine
Irvine
Los Angeles
Los Angeles
Los Angeles
Los Angeles
Los Angeles
Los Angeles
Los Angeles
Los Angeles
Merced
Merced
Merced
Office of the President
Office of the President
Riverside
Riverside
San Diego
San Diego
San Diego
San Diego
San Diego
San Francisco
Santa Cruz
Santa Cruz
Berkeley
Berkeley
Santa Barbara
Santa Barbara
Davis
Davis
Med Center - Davis
Version
Date
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
ii
Document1
Contributory Participants (UC Subject Matter Experts/Other UC Analysts)
Name
Position
Organization
Linda Cornett
Janet Nichols
Ana Lebon
Cathie Staples
Cathy Rujanuruks
Mimi Belete
Interim Payroll Manager
Financial Analyst
Grad Division (lead) - Director
Manager - Financial Aid Office
Prin Admin Analyst, SOM
Project Manager - Information
Technology Services
Work Study Coordinator
CAO/CFO - Brain Research
Institute - UCLA
Dir, Prog & Proj Mgmt
Payroll Lead; Dir Corp Fin Srv
Director, Payroll Services
Director Of Contract And Grant
Accounting
Funds Management Officer
Mgr Payroll, Personnel & Effort
Manager-Payroll Coordinator
Director Payroll
Director Enterprise Development
Director Payroll
Assoc Dir P/R
Programmer Analyst
Enterprise Systems Director
Faculty Comp Analyst
Payroll Services Director
Director, Enterprise Financial
Systems
Payroll Manager
Fiscal Manager
Administrative Analyst
Irvine
Irvine
Los Angeles
Los Angeles
Los Angeles
General Accounting Supervisor
Associate Director & Compliance
Officer - Office of Financial Aid
& Scholarships
Accounting Services & Controls
Manager, Payroll Services
Assistant IV, Payroll Services
Santa Barbara
Brianne Compton
Terry Novorr
LeAnn Story
Paula Farrington
Pam Heintzleman
Autumn Salazar
Arvin Tumonong
Carrie Gatlin
Shaun Ruiz
Gabe Nwandu
David Gracey
Pearl Trinidad
Nini Cruz
Bill Solomon
Toni Hock
Bob Lee
Steven Engen
Monique Leduc
Walt Eissmann
Kirsten Anderson
Annie Wong
Russell Remington
Nuila Blanca
James Ringo
Cindy Jones
Lana Tymoshchenko
Los Angeles
Los Angeles
Los Angeles
Los Angeles
Los Angeles
Merced
Merced
Merced
Office of the President
Office of the President
Riverside
Riverside
San Diego
San Diego
San Diego
San Diego
San Diego
San Francisco
Santa Cruz
Santa Cruz
Berkeley
Berkeley
Santa Barbara
Davis
Davis
Med Center - Davis
Distribution
Copy No.
Name
Location
1
2
3
Library Master
Project Library
Project Manager
iii
Document1
Note To Holders:
If you receive an electronic copy of this document and print it out, please write
your name on the equivalent of the cover page, for document control purposes.
If you receive a hard copy of this document, please write your name on the front
cover, for document control purposes.
iv
Document1
Contents
Document Control ............................................................................................. ii
Topical Essay .....................................................................................................6
Basic Business Needs...................................................................................6
Definitions....................................................................................................7
User Procedures ...........................................................................................7
Business Rules .............................................................................................8
Assumptions.................................................................................................8
Process Rules and Data Description ............................................................9
Batch Objects Inventory and Description…………………………………10
Program Description…………………………………………………………..15
When to Run the Program..........................................................................16
Security ......................................................................................................16
Functional Business Test Scenarios .................................................................17
Open and Closed Issues for this Deliverable ...................................................18
Open Issues ................................................................................................18
Closed Issues ..............................................................................................18
Approval Appendix ..........................................................................................20
v
Document1
Topical Essay
This document describes in detail the functional business requirements related to batch processing for the validation
of FAU chartfields and chartfield strings for each campus of the University of California system. The batch process is
intended to catch all payroll transactions that fail funding edits and assign them default FAUs so no transactions fail
during the Journal Edit and Post process in campus general ledgers. For this level of edits, all funding for a specific
payroll will need to be validated against funding edit rules through a custom batch process.
The process exists as a final validation prior to PAYGL02 general ledger interface. As such, it will notify users when
invalid transactions are assigned default FAUs but will not provide an opportunity to fix chartfield strings prior to
posting to the GL. The process will also produce a queryable log record containing the original FAU and the default
FAU that overwrote it for reporting and querying. There will be an accompanying report, titled the <Funding Edit
Errors Report>, which is detailed in the FIN 2.00 team Reporting Inventory.
Basic Business Needs
A business requirement has been identified for UCPath functionality to validate FAU/chartfields and/or chartfield
strings prior to the Commitment Accounting Actuals Distribution. This validation must take place prior to posting to
the General Ledger, as a hard edit makes it nearly impossible for invalid FAU’s to be recorded in the GL. Thus, a
custom batch process is needed to validate each funding combination used in Actuals Distribution (payroll and fringe
costing) to confirm that accounting combinations used in payroll and fringe journals are still valid and will post in the
to the campus labor ledgers.
PeopleSoft as delivered edits combinations when they are first entered into the system, but does not check to see that
the combinations are still valid when they are being used to distribute payroll and fringe costs. If corrections or
updates are made directly into these journals in the campus financial system ledgers, campus financial and UCPath
data would no longer be in sync. To ensure transactions can post to the general ledger in a timely fashion, invalid
FAUs will be overwritten with a default FAU and posted to campus or department-wide suspense accounts according
to campus preference.
The modification would introduce a custom, three-sequence batch process that populates a custom table with all
distinct FAUs and then verifies that list against a list of valid FAUs from the relevant financial source. . The process
then produces a log record detailing which FAUs have been invalidated and gives the full original combination code
for those FAUs and the new default code with which they were overwritten. This modification to return a list of
funding edit errors and overwrite invalid FAUs will be required in time for the first payroll run.
Two main business needs are being addressed by this process.
1. A “Funding Edit Errors Report” will need to be displayed in UCPath and viewable to users to alert that edit
errors have occurred during batch processing and that cleanup of the default FAU/funding via salary cost
transfers will be needed. This document describes the process by which the log record underlying this report
is gathered, but not the report itself.
2. If any funding edits are not corrected before GL edit and post, default funding must be assigned so the
transaction will post successfully before any DOA deadlines, and all transactions assigned to default funding
are tracked on a custom record for audit purposes. This process is called the “Replace Edit Errors” batch
process
6
Document1
Definitions





Chartfield- In PeopleSoft applications, the fields that store your charts of accounts and provide your system
with the basic structure to segregate and categorize transactional and budget data are called Chartfields. Each
Chartfield has its own attributes for maximum efficiency and flexibility in recording, reporting, and analyzing
its intended category of data. While a particular Chartfield always represents only one category of data, it
stores many values that you use to further categorize that same data.
Chartfield String-A combination of Chartfield values that represent a funding source in the General Ledger.
PAYGL02 - The batch process that provides Commitment Accounting Actuals information in a format that
can be used by the journal edit and post processes. Makes GL interface possible.
Pay Run ID – A user-defined ID number that specifies the company, pay group, and pay end pertaining to a
group of funding entries. In this context, it is used to tell the Load Edits batch process which FAUs it should
reference when populating the custom <Load Edits Table>
FAU Validation – An FAU (Full Accounting Unit) is the combination of chartfields (e.g. Fund, Program,
Department, Cost Center, Location, etc.) that specify a unique funding source. The validation process of
FAUs involves insuring that the individual chartfields and the FAU as a whole are valid by comparing them
to a data from the relevant financial institution.
User Procedures
 Between the aforementioned initial entry stage and the GL interface, changes to FAU chartfields may be
made on the campus financial system side. The user will run the batch process sequences immediately
prior to GL interface to check for any chartfields or chartfield strings that have been invalidated due to
changes on the campus financial side. To run batch process:
a. User specifies the Pay Run ID at the <Pay Run Control> page to indicate which pay run’s funding
entries require validation.
b. User presses submit, triggering the batch process verification.
c. The user will receive two reports:
i. Simple log output file indicating a successful run of the batch process or, if unsuccessful,
indicating error source
ii. “Funding Edit Error Report” indicating which FS Combo edits were deemed invalid and
providing the full combination code as well as a description of the error messages that
indicate the funding edit rule that was violated
d. User specifies the Pay Run ID at the <Final Edit Run Control> page and presses submit. This
initiates the <Replace Edit Errors> batch.
 The user will use the “Funding Edit Error Report” to aid in FAU cleanup via SCT as detailed in functional
design CEMLI ID I-309
7
Document1
Business Rules

To accommodate for variability among campus preferences/capabilities, two options for the Batch Edit
process will be presented, each with the end goal of identifying invalid FAUs from the list compiled in the
Load Edits:
o Campus financial systems run their respective edit processes on the list of distinct FAUs and inform
UCPath as to which are valid and invalid.
o Campus financial systems provide a list of all valid FAUs to UCPath on a nightly basis. File is used
for editing in UCPath. Result is an error file.

Batch process validation of the combination string will be available. Some campuses do not have the ability to
verify full FAUs so they will use batch process validation on individual chartfields.

If an individual chartfield is deemed invalid immediately prior to posting to the GL, the entire chartfield
string will be overwritten with a default FAU, effectively suspending the entry. A log record will be
generated recording the original FAU and the new default FAU. This log will be used for
reporting/querying.

The aforementioned default FAUs will be campus specific and, at each campuses’ discretion, posted to either
a campus-wide or department-wide default account.

Lists of valid chartfields and chartfield strings will be updated nightly by the campus financial systems to
allow for the most up-to-date information short of a live FS call-out

If, for any give Pay Run ID, over 50% of the FAUs are deemed invalid, a process error is assumed and edit
aborted. This will prevent overwrite of an excessive number of FAUs in the case of a process error.
Assumptions

The batch process will be designed to run immediately prior to compute for every instance of Commitment
Accounting Actuals (PAYGL02) to prevent invalid edits from reaching the GL

The “Funding Edit Errors Report” should be stored in a PeopleSoft log record and viewed through a query or
online page. This is the final pre-GL validation, so all invalid FAUs will be overwritten with default FAUs to
allow the GL to post.

The “Funding Edit Error Report” will show all combinations that fail funding edits as well as full descriptions
of the error messages that indicate the funding edit rule that is violated. These error messages will be campus
specific and provided to UCPath by each campus.

Campuses will be able to determine the type of suspense account (department level or campus-wide) that
invalid FAU post to in the case where a transaction fails edits up to the time of journal edit and post.

No corrections for UCPath related journals will occur in the campus general ledgers; they will all occur in
UCPath

Batch funding edits must be run at least once per payroll calculation and include all payroll transactions that
have not yet completed Commitment Accounting Actuals Distribution that are still in error. The final edit
process will be run in nightly batch after Actuals Distribution but before Providing GL Information
(PAYGL02).
8
Document1
Process Rules and Data Description
Inventory of All Impacted Objects
Object (PS name or New Object
Description
<Load Edits>
<Batch Edit>
<Replace Edit Errors>
<Pay Run Control>
<Load Edits Table>
Type (Record, Page, batch, etc.)
Impact (New/Modify)
Batch
Batch
Batch
Page
Record
<Record to store Funding Edit
Errors>
<Default Audit Query>
Record
New
New
New
New
New (Will vary according to
campus specific FAU elements)
New
<Final Edit Run Control>
Page
Query
Query of Default Audit table
published to Public Library and
made available to campuses and
departments
Run control page for <Replace Edit
Errors> Batch Process
9
Document1
Data Process Flow Charts
Pre-GL Batch Validation: Option A
Program #2: Batch Edits
Program #3: Replace Edit Errors
FAUs broken into individual
chartfields
Distinct FAUs
from DIST
tables
Chartfields populate
the <Load Edits
Table>
Results populate
<Edit Errors Table>
Results populate <Record to
Store Funding Edit Errors>
Invalid FAUs
replaced with
Default FAUs
Default FAUs
Original invalid
combinations
DB Link/
Webservice
DB Link/
Webservice
Campus FS performs edits on
<Load Edits Table>
Campus FS
Processes
PeopleSoft Processes
Program #1: Load Edits
Load Edits Table
Valid FAUs
Pre-GL Batch Validation: Option B
Campus FS
Processes
PeopleSoft Processes
Program #1: Load Edits
FAUs broken into individual
chartfields
Distinct FAUs
from DIST
tables
Program #2: Batch Edits
Program #3: Replace Edit Errors
UCPath performs edits
Chartfields populate
the <Load Edits
Table>
<Load Edits
Table>
Valid FAUs
Results populate
<Edit Errors Table>
Invalid FAUs
replaced with
Default FAUs
Results populate <Record to
Store Funding Edit Errors>
Default FAUs
Original invalid
combinations
FS interfaces list of
valid chartfields and
FAUs to UCPath
nightly
10
Document1
Batch Objects Impact Inventory & Description
Program Description #1: Load Edits
Initiates process where, for an entered Pay Run ID, all distinct FAUs from DIST tables are loaded into the <Load Edits
Table>.
Business Logic/Calculation Rules:
1. Select all distinct ACCT_CDs from PAY_ERN_DIST, PAY_DED_DIST, PAY_TAX_DIST and
PAY_LIAB_DIST for the combinations associated with input Pay Run ID, which will be fetched from
the Pay Calendar. Link to ACCT_CD_TBL to determine the individual chartfields that make up each
ACCT_CD. Populate this list of all distinct ACCT_CDs with individual chartfield makeup in a custom
<Load Edits Table> in UCPath.
Program Description #2: Batch Edit (Two options according to campus preference)
Initiates process for Payroll Funding to be edited against campus financial system FAU list and returns results of edit
errors in custom UCPath record
Option A
 Campus financial systems run their respective edit processes on the list of distinct FAUs and inform UCPath
as to which are valid and invalid. A count of invalid FAUs is taken as a percent of the total number of FAUs
in the relevant Pay Run ID; if over XX% of FAUs are deemed invalid, UCPath will assume errors were a
result of a process error. This option is available, but should be verified with campuses.
Business Logic/Calculation Rules:
1. Each campus financial system will use a technical solution (TBD) to access data from the custom edit table,
identity invalid FAUs and update the table with results.
2. Campus financial system executes combo edit rules on Load Edits FAUs and returns a valid or invalid result,
along with invalid error message description, for each FAU.
3. Use technical solution (TBD) to link from campus financial system to a custom “Edit Errors” table in UCPath
to populate results of campus edit process. May need separate edit error table per campus, TBD. A count of
the number of errors will need to be included in the SQR to perform the overall process validation in the
following step.
4. Perform overall process validation. If greater than XX% of transactions are in error, abend process. In this
case, it is assumed that a process error has occurred rather than funding edit errors The Process Monitor
should show that the process did not run to success and a line should be inserted into the log file to indicate
“Maximum Error Capacity Exceeded. Too many edit errors, which assumes that the process is in error.” If
less than XX% of transactions are in error, proceed to <Replace Edit Errors>.
Option B
 Campus financial systems provide a list of all valid FAUs to UCPath on a nightly basis. File is used for
editing in UCPath. Result is an error file. A count of invalid FAUs is taken to test for process error.
Business Logic/Calculation Rules:
1. UCPath pairs Load Edits table (populated in Load Edits Batch) with the list of valid FAUs from the relevant
campus financial center.
2. UCPath executes combo edit rules on Load Edits FAUs and returns a valid or invalid result, along with
invalid error message description, for each FAU. This data populates a custom “Edit Errors” table in UCPath.
A count of the number of errors will need to be included in the SQR to perform the overall process validation
in the following step.
11
Document1
3.
Perform overall process validation. If greater than XX% of transactions are in error, abend process. In this
case, the Process Monitor should show that the process did not run to success and a line should be inserted
into the log file to indicate “Maximum Error Capacity Exceeded. Too many edit errors, which assumes that
the process is in error.” If less than XX% of transactions are in error, proceed to <Replace Edit Errors>.
Program Description #3: Replace Edit Errors
Each FAU that is identified as invalid is replaced with Default FAU to 5 PAY_XXX tables. This generates a log record
with original and new (default) FAUs to be used for reporting/querying.
Inputs

PAY_ERN_DIST distribution information where Commitment Accounting Actuals Distribution is completed
but Commitment Accounting GL Interface has not been run (POSN_FUND_RUN=’Y’ and
CA_GL_INTFC_RUN=’N’ on PAY_CALENDAR)
Business Logic / Calculation Rules
1. Each combination code is split out into its chartfields by joining PAY_ERN_DIST to the ACCT_CD_TBL and is
edited using the campus financial system
2. Any transactions in error are assigned to default combination code, and deductions and taxes on
PAY_DED_DIST and PAY_TAX_DIST associated with earnings in error on PAY_ERN_DIST are also assigned
to default combination code
3. Original combination code for all transactions assigned to default combination code is appended to <Record
to Store Edit Errors>
4. Update PAY_ERN_DIST to show that row has been corrected and to show default combination code.
HP_DISTRIB_OVRRIDE = ‘Y’ and ACCT_CD = Default Combination Code for Earnings row in error and
associated Deduction and Tax rows
Outputs



Updated Earnings and their associated Deduction, and Tax rows on PAY_ERN_DIST, PAY_DED_DIST,
PAY_TAX_DIST, PAY_DED_LIAB_AP, and PAY_DED_LAIB_AP tables for all transactions that failed final
funding edits
Custom Audit record saved to UCPath that shows all transactions where funding was replaced with Default
funding <Record to Store Edit Errors>
“Funding Edits Error Report, ” describing Edit Rule violation and full error message. This report will be used
for research and follow up, but it is outside the scope of this spec. .
Object Descriptions
Object Name
Pay Run Control
Parameter Name
Pay Run ID
Page Purpose
Enter Pay Run Control to prompt <Load Edits> batch prior to GL interface
Field Type
User defined.
Description/Format
Signifies Company > PayGroup > PayEnd
12
Document1
Pay Run Control Mockup
Object Name
Load Edits Table
Page Purpose
Custom table populated with all distinct FAUs from DIST tables to be
edited against campus specified valid FAUs. Format will vary by campus.
Record Descriptions - <Record to store Funding Edit Errors>
Record Name
<Record to store Funding Edit
Errors>
Page Purpose
Stores record of which funding entries failed and the original
FAUs. This record will be custom designed to include search
fields based on campus-specific FAU elements
The following table identifies fields that may be included in each campus’s FAU.
FAU Elements by Campus Placeholder:
13
Document1
Query Description
Name of Query
Default Audit Query
Function
Query of all fields on <Record to Store Funding Edit Errors>.
This is a query that can be run by campuses or departments to
see what payroll transactions failed final funding edits and
was assigned to default funding for a given pay group or pay
period. The query will be available to be exported to Excel
or HTML for easy printing by campus users.
Sample Query Report (after export to Excel)
14
Document1
Program Description
When to Run the Program
The batch process will be run immediately prior to Commitment Accounting Actuals (PAYGL02) and General Ledger
interface. Put another way, the batch will function as a final check that FS chartfield edits have not been invalidated
between the time the edits were entered and the time they go to the General Ledger. Funding edits should not go to
GL interface without first running the batch process.
Restart Procedures
No specific restart procedures are required for either of the batch process sequences.
Error Handling

If over XX% of FAUs are deemed invalid, the program will assume the batch process has been run incorrectly and will
return this message: “Maximum Error Capacity Exceeded. Too many edit errors, which assumes that the process is in
error.”
o Check that Pay Run ID was correctly entered
o Contact UCPath tech support for assistance
Security
Add/update access to the funding edit page will be restricted to individuals who have been granted an Inputter or
Approver funding role. Inputters may have Home department or Campus-wide Add/Update Access. Approvers will
have Home Department only Add/Update access.

There will exist only one home department per position, so alternate departments will not be configured by
the HR team.

UCPath Center will have a unique role created for global add/update access

An approver can be granted campus-wide access
In order to prevent changes to deductions and taxes after the Actuals Distribution, security access will be restricted for
the ‘Review Actuals Distrib’ page. Access will only be given to technical users for troubleshooting any load errors.
15
Document1
Functional Business Test Scenarios
The batch process design and coding will be accepted if:
#
1
2
3
4
Test Scenario
Expected Results
Transaction fails one combo edit
rule
Transaction fails multiple combo
edit rules
Transaction fails edits and appears
on Edit Errors report. Error is
corrected campus financials and
<Funding Edit Errors> process
runs again
Transaction fails final edit
<Replace Edit Errors> process
Error report should show edit rule that is
violated as well as full error message
Error report should show edit rules that
are violated as well as full error message
Transaction previously in error should
drop off report
5
More than XX% of transactions
fail
6
Transaction fails and is updated
with something else that gets
immediately inactivated after
online entry, so it subsequently
fails anyway.
Actual Results
New row should be inserted on <Record
to Store Funding Edit Errors> indicating
error
<Replace Edit Errors> batch job shows
“No Success” in process monitor. On log
file for job, a line exists that states the job
failed because Maximum Error Capacity
was exceeded.
Transaction should be assigned to default
funding during <Replace Edit Errors>
batch process. Transaction will also be
insterted into <Record to Store Funding
Edit Errors>
16
Document1
Open and Closed Issues for this Deliverable
Open Issues
ID
Issue
Identify Campus-specific
default FAUs
Department vs. Campuswide suspense accounts
For campuses that will use
batch process, Option A or
B?
FAU Chartfields by campus
Resolution
Responsibility
Target Date
Impact
Date
Target Date
Impact
Date
FIN 5.00
FIN 5.00
Campuses
Matrix in progress
Shashank
Closed Issues
ID
Issue
Resolution
Responsibility
Abend process if >XX% of Campuses agreed to have this as 50% FIN 2.00
FAUs are deemed invalid?
17
Document1
Appendix A
Related GAP form if applicable
18
Document1
Approval Appendix
19
Document1
Download