This document outlines and describes the rationale behind our current proposal for the use of the JOBCOST tables, and the alternatives that we considered...

JOBCOST is the field we use to enter the 10 digit FRS account and object code. For employees paid by default, this data is entered in their masterfile records. For hourly employees paid by timesheet data entry, this value is entered along with hours worked. As delivered, CSS expects the jobcost tables to be filled with valid values. This is a departure from the way in which we have used PC Payroll since 10/1/93, and actually brings us back to the types of edits we had back when we ran payroll in-house with 1022.

Loading Initial Jobcost Data

We will use PC Exchange to create an import file to load the default jobcost numbers from the PC Payroll masterfile into the two Autolink tables (AL_JOBCOST_TBL & AL_PG_JOBCOST). We will then search through the S1032 DISTRIBUTE dataset to select all account/object codes that student payroll has been charged to, again to create an import file for thes two Autolink tables.

Maintaining the Tables

We do not yet see an automated way in which to maintain these Autolink tables, for the following reasons...

• FRS accounts can be created at any time and by a number of various sources.
• Timesheets charging a new account might be submitted for data entry before the new account has actually been entered into FRS.
• In calendar year 1996 the number of FRS accounts which were actually charged by payroll was ~ 800, a small subset of all FRS accounts (~ 3,800). As there are 34 valid object codes for payroll, it does not seem sensible to load all possible combinations (3,800 * 34 = 129,200) into the global table, although there would only be a subset of these for each paygroup. One of the additional features of limiting the accounts within each paygroup table is that the tables can be used as 'prompt tables' so that the account and object code can be selected from a pick list rather than typed in. This feature would be useless if we mass loaded all possible valid values.

Gil will be responsible for maintaining the two jobcost tables, and we plan to establish some form of procedure for notifying Gil as new accounts are added to FRS.

While we like the idea of validating account number/object codes as they are entered into employee's masterfile records, we do not want this validation to completely stop timesheet data entry. It will be a great help that the system will give an error message so that the data entry person can recheck the number, this should eliminate some of the typos. What we need to avoid is the case where the number on the timesheet itself is in error, we do not want the person entering the data to have to stop and research to find the appropriate number. As such, we plan to add '9999999999' as a valid value, with a description as 'ACCOUNT UNKNOWN'. This number can be used when a valid number is not known, and when this hits FRS it will go directly to Suspense. Gil will know that there is a problem and will be able to address it before the next pay cycle.