Timelink International Corp

TimeLink International Corp.

School Board of Palm BeachCounty

Amendment 1

V.3.0

Document Revision History

Date / Version / Description / Author
2/14/2008 / 1 / 1st Version / K. Walsh
2/21/08 / 2 / Several additions including internal lookups for default employee record numbers for employees who don’t have multiple jobs; creation of new transaction types for employees who are unable to use the biometric component of the reader; solution for substitute teachers; online / offline indicator / K. Walsh

Table of Contents

Introduction

Palm Beach County’s Primary Change Requests and TimeLink’s Responses

Palm Beach County’s Secondary Change Requests (wish list items, not critical)

TimeLink’s Proposed Data Collection Approach

1. PeopleSoft Outbound Employee Master Data

Employee.txt File structure

2. Validation Files to Be Sent to the TL3100 Terminals

Balance.xml

Jobs.xml

3. Enrolling Substitute Teachers

4. Automated Removal of Inactive Employees from the Terminals

5. Providing a better indicator to the employee when a transaction is accepted

6. Online / Offline Indicator

7. Server-side lookup for default Employee Record Number for Employees with 1 Job

7. Alternate Clock In/Out Method for Employees without Good Fingerprints

Prompting Flow for IN Transaction

Prompting Flow for OUT Transaction

Prompting Flow for Special IN Transaction

Prompting Flow for Special OUT Transaction

Level of Effort:

Acceptance

Introduction

The Palm Beach County School Board has requested TimeLink to make changes to their current Time and Labor data collection model. Palm Beach CSD proposed their requests to TimeLink and a preliminary review was held with TimeLink on 2/5/08 to discuss theitems that could be delivered and theitems thatwould be kept out of scope.

The first section of this document lists Palm Beach CSD’s requested changes and TimeLink’s responses as to whether or not the request would be kept in scope for this change order. TimeLink’s responses are in italics. The second section details TimeLink’s new data collection approach which would need to be assembled meet the new requirements. The final section details the estimated effort and costs.

Palm Beach County’s Primary Change Requests and TimeLink’s Responses

1)PBCSD Request for Change: Validation of Employee ID (must be active in PeopleSoft) when enrolling users at the clock

This can be delivered. Details are listed in the proposed data collection approach below.

2)Multiple job descriptions must be displayed on the screen by each employee record number

Central Driver I

East Driver II

Royal Attendant

This can be delivered. Details are listed in the proposed data collection approach below.

3)Maintainable Department ID / Jobcode translation table within Synapps for display purposes

DeptID / Jobcode / Display
9320 / 33190 / Central Driver I
9324 / 33210 / East Driver II
9326 / 31070 / Royal Attendant

This will not be delivered. These associations will be maintained within PeopleSoft.

4)Remove Alternate Job key (Double Arrow Button) functionality – there should be one clock IN process and the terminal should prompt for multiple job selection only when multiple jobs exist – the clock OUT process should assume last job clocked in on and not prompt for multiple job selection

This can be delivered. Details are listed in the proposed data collection approach below.

5)Automatic removal (both terminal and Synapps) of TCD Biometric Enrollment for Inactive employees

This can be delivered. Details are listed in the proposed data collection approach below.

6)Better indicator to the user that the punch in/out was accepted (i.e. audible voice announces “Accepted” or visual display screen flashes solid green, etc.)

This can be delivered. Details are listed in the proposed data collection approach below.

Palm BeachCounty’s Secondary Change Requests (wish list items, not critical)

1)Automatic movement/maintenance of users within Synapps and TCD Types (groups) -

When a user clocks at a different site, their enrollment is moved from their original TCD Type (group) to the new TCD Type (group) which becomes their primary until they use a clock at another location [substitute teachers are a good example for understanding this request]

This will not be delivered. Primary TCD Group associations are determined by the PeopleSoft Time Reporter Data.

2)Increase the current maximum of 500 users per TCD Type (group)

This will not be delivered. This would require a new terminal purchase and re-deployment.

3)Badge reader capability instead of Employee ID prompt when working at a different site

This will not be delivered. This would require a new terminal purchase and re-deployment.

4)Online / Offline Indicator

This can be delivered. Details are listed in the proposed data collection approach below.

TimeLink’s Proposed Data Collection Approach

To provide the functionality currently requested by Palm Beach CSD, TimeLink will need to change its data collection approach at several levels. The changes in approach are described below.

1. PeopleSoft Outbound Employee Master Data

Currently, there are no employee master data being sent from PeopleSoft to TimeLink. In order to enforce validation of the finger enrollment process,facilitate automated template distribution based on the employee’s home TCD group, and to display job descriptions if the employee has more than one job, then TimeLink will require master data to be sent from PeopleSoft.

Normally, TimeLink would have PeopleSoft utilize the standard PeopleSoft Message Channels to pass the required master data. However, PeopleSoft does not have a standard message that incorporates the employee’s Employee Number, the Empl Record Number, and an associated task or job description related to the Empl Record Number. Therefore, a custom master data extract will need to be written.

The Palm Beach CSD PeopleSoft team will write a data extract that will assemble a record for each active employee containing the employee’s PeopleSoft Employee Number, the employee’s Primary Employee Record Number, the employee’s TCD Group name, and each of the employee’s alternate job descriptions and associated alternate Employee Record Numbers (up to 9). The extract will then generate a comma-delimited text file and place this file on Synapps server in the \Synapps\import directory.

****Note 1: This file must contain not only the employees who will be recording their time at the terminals but also the people who are responsible for enrolling employees. It is important to recognize the fact that enrollers may not be users of the terminals but they need to be included in the data extract for validation purposes.

****Note 2: This file must contain only active people. All inactive people must be pre-filtered before sending the file. This approach differs from using the standard PeopleSoft TL_EMPL_DTA message which sends all active and inactive employees.

The name of the file to be generated will be EMPLOYEE.TXT. The file will have a comma-delimited structure and will have the following format. (Fields not used should be filled with spaces).

Employee.txt File structure

# / Data Element / Type / Field Len
EMPLOYEE ID (Pad left with 0s. TimeLink to remember to right trim 7 digits in its validation file). / Char / 11
DEFAULT EMPLOYEE RECORD NUMBER (pad left with 0s) / Char / 3
BADGE ID (Insert the TCD Group Code Here) / Char / 20
EMPLOYEE PIN (To be used as a flag for the “special” validation group. For employees who are not able to use the fingerprint reader place a “1” in this field. Else, remain empty, pad with spaces) / Char / 6
POSITION DESCRIPTION 1 (insert the description of the employees Primary/default joband right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 1
(insert the employee’s Primary/default Employee Record Number here) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 2 (job description) (insert the description of the employees 1st alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 2
(insert the employee’s 1st alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 3 (job description) (insert the description of the employees 2nd alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 3
(insert the employee’s 2nd alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 4 (job description) (insert the description of the employees 3rd alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 4
(insert the employee’s 3rd alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 5 (job description) (insert the description of the employees 4th alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 5
(insert the employee’s 4th alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 6 (job description) (insert the description of the employees 5th alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 6
(insert the employee’s 5th alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 7 (job description) (insert the description of the employees 6th alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 7
(insert the employee’s 6th alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 8 (job description) (insert the description of the employees 7th alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 8
(insert the employee’s 7th alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 9 (job description) (insert the description of the employees 8th alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 9
(insert the employee’s 8th alternate employee record number) (Pad left with 0s) / Char / 6
POSITION DESCRIPTION 10 (job description) (insert the description of the employees 9th alternate job if one exists and right pad with spaces to field length. / Char / 20
OVERRIDE EMPLOYEE RECORD NUMBER 10
(insert the employee’s 9th alternate employee record number) (Pad left with 0s) / Char / 6

Once the EMPLOYEE.TXT file is delivered to the Synapps\import directory, Synapps will import this data into its EMPLOYEE table.

The Palm Beach CSD PeopleSoft Team will be required to configure TCD Groups inside PeopleSoft. The PeopleSoft TCD group names must mirror the Synapps terminal group names that have already been established in the Palm Beach CSD Synapps System. The PeopleSoft team will need to configure Time Reporters in PeopleSoft. Each Time Reporter will need to be associated with a TCD group. This will enable the PeopleSoft team to write out the appropriate TCD group name into the employee’s EMPLOYEE.TXT record.

TimeLink and the Palm Beach will configure queries within the Synapps time device group configuration to decide which employee’s data will go to the terminals configured in a specific terminal group. The table to be queried will be TimeLink’s EMPLOYEE table.

2. Validation Files to Be Sent to the TL3100 Terminals

Currently, there are no validation files being utilized in the TL3100 terminals. The only data being validated is the employee’s finger template when the employee makes a transaction attempt.

To facilitate enrollment validation for the home users in a TCD group and to display alternate jobs for both home users and visiting users, TimeLink will need to create two validation files.

Balance.xml

The balance.xml file will contain a list of Employee IDs to be loaded into terminals that are members of a given Synapps terminal group. The employee IDs chosen for any given list will be based on the PeopleSoft TCD group that Time Reporters are enrolled in (again, the PS TCD Group Name should match the terminal group name in Synapps. Only the IDs in this list (enrollers and employees) can be enrolled at the terminals in a given group. If an employee is denied enrollment at a particular terminal, it will be due to the fact that their PeopleSoft Time Reporter Record says that they are associated with a different TCD group. The required course of action would be to changethe Time Reporter record to the appropriate TCD group, let the employee extract run (typically overnight), and attempt to enroll the next day.

Jobs.xml

The jobs.xml file will contain a list of employees who have multiple jobs containing theiralternate Employee Record Numbers and the descriptions of each of their jobs. During a transaction attempt the terminal application will first validate the employee’s finger template. Once the finger template is validated, the terminal application will try to find the employee id in the jobs.xml file. If terminal application cannot find the user id in the Jobs.xml file, it will simply accept the transaction and write the transaction record. A default Employee Record Number of 0 will be written to the transaction record. If the terminal application finds the employee id in the Jobs.xml file, it will display the description for each of his / her jobs. Once the employee chooses a job from the list, the transaction is accepted. The Employee Record Number associated with the job description that the employee chose will be written to the transaction record.

****Note: TimeLink will attempt include only employees with multiple jobs in this file. TimeLink will also attempt to include all Palm Beach CDS employees that have multiple jobs into this one file. This will accommodate employees who make transactions in their home terminal group as well as in groups that they visit. However, there is a risk that this file may be too large for the terminal to read into memory. If this is found to be true, we would need to designate logical regions (maybe 4 or so). This would enable us accommodate as many people as possible as to where they may travel to use a terminal while staying within the technical capacity of the terminal. Palm Beach CSD anticipates a total user population of between 5000 and 10000. It’s estimated that about 70 % of the population will have multiple jobs. The vast majority of the population who has multiple jobs has only 2 jobs.

Special.xml

This file will contain all Employee IDs of people who will not be using the fingerprint reader to identify themselves because of problems with their fingers. This will be a global file sent to all terminals throughout the district to allow these special users to use all terminals. A key on the terminal will be designated for these employees to start their transactions. The prompting sequence under this key will require the employee to key in their employee id but will not require them to present their finger. They will be given transaction options to choose from and the remainder of the prompting sequence will mimic the sequences used for the biometric users.

3. Enrolling Substitute Teachers

Substitute teachers can work in different schools around the district. Therefore, it doesn’t make sense to have them configured in a particular PeopleSoft TCD group at a particular school or facility. To accommodate this scenario, all substitutes will be enrolled at the PBCSD Central HR office. The terminal in central office will be connected to Synapps. We can have enrollment validation either turned on or off for this enrollment terminal. If PBCSD wants to validate the enrollment attempt, then they will need to associate all substitutes with a single PS TCD group. A Synapps TCD group will also need to be configured in order to receive the substitute teachers who can enroll in this terminal. If PBCSD chooses not to validate the enrollment process because it takes too much administrative time to configure the new substitute in PeopleSoft and to send him / her to the terminal, then the substitute would not need to be associated with a TCD group. When the substitute is enrolled, his / her template will be sent and stored in the Synapps FP_TEMPLATES and FP_USERS tables. After the enrollment is completed, the enroller will immediately delete the substitute’s template so the terminal will not fill up with templates. The substitute’s template will be erased from the FP_USERS table but will remain in the FP_TEMPLATES table. Therefore, moving forward, whenever the substitute teacher visits a new school, the terminal will be able to grab their template from the FP_TEMPLATES table and enable them to use the terminal as a “verification” user. This means that they will always need to key in their employee id as well as present their finger.

4. Automated Removal of Inactive Employees from the Terminals

The Synapps Synclockval and terminal application will be reprogrammed such that if an employee no longer resides in the balance.xml file lookup designated for the terminal group that they are currently a member of, his or her templates will be removed from the terminal’s database in the terminals within that group.