Phase-Out of Hiring Through the Student Employment Administration System (SEAS)
Hiring and pay change/termination functions were disabled in the Student Employment Administration System (SEAS) during June 2020, in anticipation of offering this functionality through Dayforce beginning in July 2020. Later it was decided that some of the hiring features in SEAS would be retained until further notice.
Freshmen Access to Student Employment Administration System (SEAS)
Currently a freshman student must be registered for their first semester of classes before they are able to access the functions of the Student Employment Administration System (SEAS), such as submitting a personal profile, etc.
Changing/Adding Department Info in SEAS
Administrative access in SEAS is required to complete this task. First, click the Departments tab in the system:
https://www.cedarville.edu/cf/finaid/admin/index.cfm?menuMode=DEPARTMENTS
Then, click the "List of Departments" link.
Locate the department by department ID or name (using the "Find..." tool on the web page can be helpful).
Click the "Edit" link in the entry for the department to be changed.
(When adding a new entry, click the "Add New" link in the Departments menu toward the top of the screen.)
Details that can be changed include the department name (as displayed in SEAS), the department number, and the LDAP group associated with that department.
Hiring Supervisor Access To Student Jobs Information
The hiring supervisors have access to the "Add New" link, for additional jobs in their departments. The "Remove" (delete) link is limited to SEAS administrators, possibly in large part due to the job IDs being used in the student profile records, for jobs in which the students have an interest. Student jobs are linked to the department, not to individual hiring supervisors.
There is some nuance to setting the fields for number of positions available (for fall-spring and/or for summer). This count must be set to the current number of openings, plus the number of students already hired for the position. The latter can be found by looking at the Hired Students tab for the department, and noting how many students are currently in the hired list for that particular job for the term in question. (Example: Two open spots for a position plus six students already holding the position would lead to a term assignment of eight.)
Hiring Supervisor Access To Student Profile Information
Currently, when a student profile (sometimes called an "application") is added to SEAS, there is no automatic notification sent to potential hiring supervisors making them aware of the presence of the new profile record. The hiring supervisors are able, however, to review student profiles and make contacts regarding student positions which are available. Supervisor notification regarding new profiles is an area for possible enhancement discussed by the Student Employment Kaizen team which met during the spring of 2018, and such a feature may be installed in the future.
Previously added student profiles should be checked periodically, i.e. at the beginning of the academic year, and also at the beginning of subsequent terms, to provide the opportunity to make updates regarding active (enrolled) students, student class standings, and new student names (primarily related to changed surnames due to marriages). Inactive students can be removed from not-hired displays by coding the Availability Term in those profile records to the spring of the previous academic year.
Specifically regarding student listings in SEAS, which in part are based on the student profiles, one aspect to note is that they all depend on the terms which are coded in the students' records in the SEAS database. As the labelling suggests, the list generated by department under the Hired Students link only shows the students currently working in the various positions within the applicable department. Under the Profiles link, the list produced by the Students Not Hired option is the same list for everyone, excluding students who have a least one active position in any department. Students will no longer appear in this list once any hiring supervisor has hired them in SEAS. The List option under Profiles works differently. It is a compilation based on the jobs in which each student has shown an interest (by including them in their individual profile records). This listing remains static from the standpoint of any hiring that has taken place or which may take place, to the point that it continues to show jobs of interest to students to which they have actually already been hired during the selected term.
One instance of a hiring supervisor not able to find/hire a particular student was resolved recently by adding a basic profile record to the SEAS database for that student. Apparently the student had never created their own profile in SEAS. Previously, the system would automatically generate a basic profile record in these cases, but that capability seems to have been thwarted with the changes made to the system during summer 2018. This deficiency is something that can be fixed as time permits.
Empty Successful Hire list - Error 31
Items to check when this error occurs while attempting to hire a student worker:
- Verify that the student's ID was entered correctly;
- Verify that the student is in a Class eligible for hiring as a student worker;
- Verify that the student has sufficient credit hours (must be half time or more; 6 hours for undergraduates, 3 for graduate students);
- Verify that a duplicate hiring record does not exist for this position (this now results in an email going to hiring supervisor and to the cuhired mailbox;
- Verify that the hiring start date is correct (if it overlaps into a previous term, especially summer, a duplicate hiring attempt could result);
- Also review any other exception messages/lists that are displayed at the time.
Deleting Outdated Jobs From Database
Those having a corresponding level of permission, when displaying a list of jobs for a department in SEAS, can click the Remove link that appears beside a job, and this will drop that job from the database. The system requests confirmation of the operation before doing it. The hiring supervisors could be allowed to delete outdated job entries for their departments; currently, this capability is not available at the hiring supervisor level of security. One issue is that job IDs are stored in student profile records for any job preferences they may have; and for hiring supervisors, the capability would have to be limited to their departments.
There is also a link under the Tools menu (also not available to hiring supervisors, but only to system administrators) called "Delete Student Jobs". At some point, this should be reviewed, because it currently generates an error message when clicked. It is also not clear whether the function is to delete job table entries, specific hiring entries for students, or job preference entries in student profiles.
Currently, SQL Server commands are used as necessary to delete job table entries, while checking for and removing any corresponding job preference entries in student profile records.
Updating Jobs In The Database
When updating jobs in the SEAS database (via www.cedarville.edu/cf/finaid/admin/jobform.cfm), the department number may be modified in this form for the purpose of customizing the GL account number to be used for a particular job. However, the next time the form is used to update that job, the Department field will be displayed as if not populated, forcing the operator to enter a selection there (since it is a required field). This can lead to inaccuracy with respect to the desired GL account number and/or repetition of effort on the part of the operator. One way to mitigate any problems in this regard would be by manual update to the record(s) by an IT staff person, via the Easy Query utility or via the MS SQL Server Management Studio. A more effective approach may be to set up the varying GL account number as its own "department" in SEAS.
Occasionally, a hiring manager may request that a job be added to the SEAS database using a number other than "1" as the first digit in the Job Code. The system uses "1" as the first digit by default, whenever a new job is added. These are also cases which may dictate a manual update to record(s) by an IT staff person, again using the Easy Query utility or the MS SQL Server Management Studio. However, up to the present time, there have been only isolated requests, and the Payroll Office has been handling most of them on their side by using the requested prefix number in the Person Position Wage (PERPOSWG) records affiliated with these particular jobs.
A method for manually adding a job record in the database is to use an INSERT INTO statement in MS SQL Server Management Studio. The SELECT clause can be used to bring in values that can be copied from an existing job record, which is used as a template, with alternate values coded directly into the SQL statement as necessary.
Prospective Change For Position Pay Type Modifications
It may be beneficial to make a change in SEAS to allow a hiring supervisor to report modifications to students' positions from RWS pay type to CWS pay type (for example) via the "Pay Info Change" link, which opens form hirededitform.cfm. This could be handled as an optional radio button on the form, and may utilize a field in the SEAS database that was previously abandoned. The purpose of this process change would be to help the Payroll Office become aware of such modifications to positions in a more timely manner, so the records in their office can be updated accordingly. For context regarding this, see incident ticket #8020710.
Using Pay Change Screen For New Student Position Assignment
Previously it was possible for the XEMP screen in SEAS (in conjunction with the Pay Change screen) to be used in an incorrect manner, resulting in "new" hired student records in the system. This was allowed due to an oversight made when the XEMP screen was changed to allow for the display and processing of Pay Change requests. Because the Edit link on the XEMP screen was opening the same form for both new hires and for pay changes, the operator was able to modify the hired term and other information in records associated with pay change requests. Effects seen as a result of this were instances where there was missing original hiring information, along with an apparently missing Pay Change Printed Date, in the corresponding student records in the FA.YEARLY.USER.ACYR files, which in turn led to missing (i.e. not printed) authorization forms in the Payroll Office. The problem appears to have been resolved by another change to the XEMP screen, so that the Edit link navigates to the correct editing forms for both new hires and for pay change requests.
Pay change and position termination functionality were disabled in SEAS during the summer of 2020 when the HR Office began using Dayforce software.
Spring/Summer Update Required For UniData Suite File
The latest file in the FA.YEARLY.USER.ACYR suite often has required a fix when it is first being used in the late spring / early summer. Symptoms may include field errors, e.g. when running XHR.MENU option 20-5 (referencing paragraph EMPLOY.AUTH in directory HR.REP) for the upcoming academic year. The following process statement, when run from the Redwood command prompt, should make the necessary repair in the file for the upcoming academic year.
VERIFY.DICT.ASSOC FA.YEARLY.USER.<<Academic Year>> FIX
Reprinting Student New Hiring Authorizations
During April 2019, the paragraph that is run for XHR.MENU 20-6 (EMPLOY.AUTH.REPRINT), the reprint option for student new hiring authorizations, was rewritten. This had become obsolete at some point in the past and was no longer was providing proper output. The updated paragraph takes four parameters, including the financial aid year, the original print date of the authorization(s) to be reprinted, student ID(s), and the form (printer) ID. All are required except for student ID -- despite the "caution" message that displays, it is okay to return that field blank, and thereby reprint all the student records that meet the other criteria. If a student has two (or more) new positions that come in on the same day, reprinting which includes that student and that day will provide all of the corresponding authorizations.
The hiring reprint functionality has not been in use since the summer of 2020, when the HR Office began using the Dayforce software.
Year Transitions & Printing Hiring Authorizations
What has been recommended, to avoid some problems with printing authorizations during a time of academic year transition, is that if any "current" academic year records are available on a given day, first select just those records in the XEMP screen, and run the process -- followed by a run of XHR.MENU 20-5 using the current academic year (four digits only). Then go back to XEMP, select any records for the "next" academic year, run that process a second time, and then run XHR.MENU 20-5 using the next academic year. Another viable option is to run XEMP once for all available records, regardless of academic year, followed by running one or both of the XHR.MENU 20-5 passes noted above, as necessary. This is a clunky way to have to do it, so if it is feasible for improvement to be made, we should do it.
The hiring print functionality has not been in use since the summer of 2020, when the HR Office began using the Dayforce software. Since that time, daily listings for hired students are provided to the HR Office through an Informer report called "SEAS Hiring Report". The scheduled report captures any hiring that was completed before 11:55 pm on the given day, which in all but very unusual circumstances provides a complete report for that day.
Student Employment Type For Summer Authorizations
On 4/29/2019, a change was made in program CALLUB.XEMP to allow for the student employment type of SSP to be coded on student authorizations for summer term. This employment type is used instead of RSW and CWS during the summer.
This feature has not been in use since the summer of 2020, when the HR Office began using the Dayforce software.
Summer Transition & Student "Red Light" Hiring Status
During late-Spring 2019 it was reported that hiring supervisors were seeing "red light" status on students who should have been eligible to work, including some students who were currently working. This problem was related to how a subroutine, HR.INSERTS S.C26.STU.EMPLOYMENT.STATUS, was calculating enrollment hours for allowance of work during summer. The subroutine was modified so that it looks at credit hours for spring, summer, and fall, and uses the highest number of hours found. This subroutine requires further modification, as soon as time permits, so it will always be called with a term being passed from the calling routine (primarily, CALLUB.GET.STUDENT.EMPLOYMENT.STATUS, which is invoked by ColdFusion process addnewhiredaction.cfm). One observation noted while looking at this module is that when hiring supervisors are hiring students for summer or for the upcoming academic year, they must create records for those students using the Add New Hire form in the Student Employment system. The impression may have been that the record for the current fall/spring academic year could also be used for summer work, which is currently not the case.
Since the summer of 2020, when the HR Office began using the Dayforce software, only the "Yellow Light" hiring status has been in use.
Identifying Student Workers In 'Add New Hire' Form
Testing was performed which indicates that student IDs or student user names can be specified in the Add New Hire form -- with the possible exception being (as indicated on the form) that only student IDs are allowed when the form is being used in multiple-hire mode. These results were as expected. A few staff people may have the impression that combination(s) of first and last name can be specified in this form (e.g. ticket #7266009), but testing indicates this does not represent valid input. A review of program code provides no sign that this was ever a feature of this form.
Inability To Hire Authorized Student
There was an instance where staff in the Payroll Office were receiving an error, "Must enter data for REQUIRED field...", on the Colleague ADAP screen, when trying to hire a student worker who happened to have not worked as a student worker here for several years. Checking to make sure that the old position and wage records had been closed out, and then trying to hire the student again, was also unsuccessful.
There was found a posting on the Ellucian Help Center (https://ecommunities.ellucian.com/thread/13148) that discussed a somewhat similar problem, one which was resolved by directly updating an employee's Person Status (PERSTAT) record. (Apparently there is currently no Colleague form available to handle this.) It was discovered that one of the student's PERSTAT records from several years back was, for some reason, missing important details (specifically, the Position ID itself, the End Date, and the End Reason). These were filled in, based on information in the last wage record. Following this, the ADAP process was attempted again, and the hiring process was completed successfully at that time. Meanwhile, staff in the Payroll Office had been unable to access the ETAX and EDDP forms for the student employee, but the CSTI form could be updated, and this in turn enabled access to update on the ETAX and EDDP screens. No update on the CPPI screen was attempted. At this point, however, the student time card was also accessible by the student worker and the supervisor.
Missing Hiring Records
Hiring records that are "missing" may simply be marked as Terminated due to start/end dates mismatching the term. Cases like this may involve use of a SQL update to correct date and status information, and removal of any duplicate records that may have been created by the hiring supervisor.