Ellucian
Banner Human Resources Change Request Resolutions
SYSTEM: Banner Human Resources
RELEASE NAME: 9.3.7
RELEASE DATE: June 28, 2018
======================================================================
Change Request (Defect) #: CR-000146367
MODULE: Regulatory
PROBLEM:
Better documentation is needed for the creation of RV
record in the W2REPORT. What should happen when there
are multiple states represented in the RS records needs
to be documented.
IMPACT:
None
RESOLUTION:
Documented in Banner HR Year-end Regulatory Handbook and
Banner HR Reports Handbook.
The W2REPORT follows federal reporting requirements
outlined in Social Security Administration Publication
No. 42-007. The SSA and IRS do not provide for state
filing needs and do not read or process the State Wage
(RS) or State Total (RV) data. If State Wage (RS)
Records exist, a State Total (RV) Record will be
created. This provides you with a basis for state
reporting, following the federal file specifications,
and should be verified for your particular state's
filing requirement needs. The existence of the RS and
RV records within the W2REPORT does not affect the
passing or acceptance of your federal filing. Contact
your State Revenue Agency to determine file acceptance
and field definitions.
Link: https://ellucian.force.com/clients/a0x160000058RIXAA2
======================================================================
Change Request (Defect) #: CR-000147186
MODULE: Regulatory
PROBLEM:
2016 had several box number changes to Form 1042-S.
These were addressed for printing and processing of
Form 1042-S, however, the changes were not updated in
the code when a Box # was referenced. See attachment.
IMPACT:
The internal code has been updated in the Foreign Person
1042S Form process (PXP1042) for references to 2016
1042-S Box numbers.
RESOLUTION:
Box variables are modified from pre 2016 to 2016 and
2017 such as 13a->13e, 13b->13f, 13c->13g, 13d->13a,
13e->13b, 13f->13c, 13g->13d, 21->17a, 22->17b, 23->17c,
and 17->13l.
Link: https://ellucian.force.com/clients/a0x160000058oFLAAY
======================================================================
Change Request (Defect) #: CR-000150227
PROBLEM:
PHPCALC.pco delivered with patch
pcr-000133760_pay8140002 fails to compile properly when
using the Microfocus Cobol compiler because lines 2939,
2947, and 2958 each begin with a tab instead of regular
blank spaces. You will receive errors that look like
this
cob -xv -PC " IBMCOMP noecho notrunc nobound confirm
errlist assign=external" -c PHPCALC.cob
cob64 -C nolist -xv -PC IBMCOMP noecho notrunc nobound
confirm errlist assign=external -c PHPCALC.cob
* Micro Focus Server Express V5.1 revision 000 Compiler
* Copyright (C) 1984-2010 Micro Focus (IP) Limited. URN
RXCTS/AA0/00000E
* Accepted - verbose
* Accepted - nolist
* Accepted - IBMCOMP
* Accepted -
noecho
* Accepted - notrunc
* Accepted - nobound
* Accepted - confirm
* Accepted - errlist
* Accepted
- assign(external)
* Accepted - list("PHPCALC.lst")
* Compiling PHPCALC.cob
2939 *
* 143-S**** ( 0)**
** Unknown IDENTIFICATION DIVISION paragraph
* Total Messages: 1
* Unrecoverable : 0 Severe : 1
*
Errors : 0 Warnings: 0
* Informational : 0 Flags : 0
* Data: 668098 Code: 0
cob64: error(s) in compilation: PHPCALC.cob
make: *** [PHPCALC] Error 12
This error does not occur
using NetCobol Compiler.
Workaround is fix the "*", comment line # 2939, 2947 and
2958 so that leading tabs are removed and replaced with
the appropriate number of blank spaces or use the
attached file PHPCALC_fixed.pco.
IMPACT:
Payroll 8.14 upgrade delivers PHPCALC.pco that will not
compile with Micro Focus. This modification corrects
that problem, and the process will compile successfully
with the Micro Focus compiler.
This will be fixed when CR-000135735 is released in HR
8.14.0.4 patch on August 25th, 2017.
RESOLUTION:
Converted tab characters to spaces.
Link: https://ellucian.force.com/clients/a0x16000005ZSP3AAO
======================================================================
Change Request (Defect) #: CR-000153744
MODULE: Regulatory
PROGRAM: pdkb_aca_coverage_s0.sql,
pdkb_aca_coverage_s1.sql,
pdkb_aca_coverage_r1.sql
PROBLEM:
Client should be able to manually enter any record in
PDAHIOC. When client tries and then attempts to save
record, they get following error: 'Medical deduction
does not have an employee coverage record,' when the
employee does have a record in PDABCOV. Per attached
test cases, defect is that PDABCOV 'Coverage Begin
Date' is required to match the PDADEDN 'Benefit Date'
for the same employee and deduction, in order to
manually enter the same deduction for the same employee
in PDAHIOC. This is problem in that the PDADEDN Begin
Date and the PDABCOV Coverage Begin Date may match, but
they often do not. The PDPOCMU .lis file is showing
that records have been created for employees in similar
status, when in fact no record was saved to the
database because of the fatal error.
IMPACT:
You will now be able to save records in PDAHIOC when the
medical deduction does not have coverage, although a
warning message will still be displayed. The PDPOCMU
process will also allow records with the same error to
be saved to the database, whereas before they were
listed in the .lis, but were not actually created.
Although no changes to the logic calculating coverage
have been made, this will be reviewed and any needed
corrections will be posted in the future.
RESOLUTION:
pdkb_aca_coverage_s0.sql and pdkb_aca_coverage_s1.sql :
-
Changed �E_DEDN_ACTIVE_NO_COV� error message to
�W_DEDN_ACTIVE_NO_COV� warning message
.
pdkb_aca_coverage_r1.sql:-
Changed �E_DEDN_ACTIVE_NO_COV� error message
to
�W_DEDN_ACTIVE_NO_COV� warning message in p_validate
procedure.
Link: https://ellucian.force.com/clients/a0x1M000005Xe4TQAS
======================================================================
Change Request (Defect) #: CR-000153987
PROGRAM: pdkb_aca_coverage0.sql
pekb_fac_jobdetail_r0.sql
pekb_fac_jobdetail0.sql
PROBLEM:
There are unprintable characters in the following object
creation scripts, which cause ORA-39346 errors when run
impdp in an Oracle 12c database. The unprintable
characters are on comment lines, so fixing them will
not change the functionality of the objects.
The objects in Human Resources with errors are:
ORA-39346: data loss in character set conversion for
object PACKAGE:"BANINST1"."PB_ACA_COVERAGE"
ORA-39346: data loss in character set conversion for
object PACKAGE:"BANINST1"."PB_FAC_JOBDETAIL_RULES"
ORA-39346: data loss in character set conversion for
object PACKAGE:"BANINST1"."PB_FAC_JOBDETAIL"
The scripts containing unprintable characters are:
pdkb_aca_coverage0.sql
pekb_fac_jobdetail_r0.sql
pekb_fac_jobdetail0.sql
These can be fixed by
running:
tr -cd '\11\12\15\40-\176' <
[file_with_unprintable_chars] > [fixed_file]
See "Article 000037359 Banner and ORA-39346 Data Loss In
Character Set Conversion During Import" for more
details and sample scripts.
https://ellucian.force.com/clients/articles/FAQ/
Banner-and-ORA-39346-Data-Loss-In-Character-Set-Convers
ion-During-Import
https://ellucian.my.salesforce.com/kA0160000001XHx
IMPACT:
There is no functional impact due to this change.
RESOLUTION:
Remove unprintable characters from the comment lines.
Link: https://ellucian.force.com/clients/a0x1M000005XgdLQAS
======================================================================
Change Request (Defect) #: 1-5JVN9N
MODULE: Payroll Processing
PROGRAM: pdkded1.sql
PROBLEM:
The Add/Replace indicator in the base deduction record
(pdrbded) is being edited for the wrong values (Y and N)
. The field should be edited for values 'A', 'R' or
null.
IMPACT:
The Add/Replace indicator in the base deduction record
(pdrbded) is being edited for the wrong values (Y and N)
. The modification has been applied to edit for "A","R",
and null. However, this package is not used anywhere
in the baseline Banner application. Customers using
this package should be aware of this situation.
RESOLUTION:
Procedure p_edit_add_repl_ind is modified to check for
correct values.
Link: https://ellucian.force.com/clients/a0xG0000001Oc7zIAC
======================================================================
Change Request (Defect) #: CR-000124571
MODULE: Benefits Administration
PROGRAM: pdklib1.sql
PROBLEM:
PDADEDN sends error message when removing an incorrectly
entered core record. The error that occurs is (ERROR:
Benefit Dependencies exist. Benefit/Deduction cannot be
deleted.) when a previously entered but terminated
contingency record existed. Please note its
corresponding core was also terminated. The new core
was entered in error and should not be checking for
terminated contingencies. The work-around is to remove
the core requirement on PTRBDCA.
IMPACT:
The Employee Benefit/Deduction page (PDADEDN) was
preventing the removal of an employee�s Core Deduction,
even though the Contingent Deduction had already been
terminated. This has been corrected to allow deletion
of a Core Deduction when no Contingent Deduction exists
for the same time period.
RESOLUTION:
pdklib1.sql :- Added cursor
c_check_contingency_terminated in P_VerifyCoreBdcaEmp
procedure to check if the contingent record is ended
before the begin date of the core record. If the
contingent record is ended before the core then system
will not
check for any further edits related to contingent record.
Link: https://ellucian.force.com/clients/a0x16000003tz4dAAA
======================================================================
Change Request (Defect) #: CR-000146141
MODULE: Benefits Administration
PROGRAM: pdpocmu.pc
PROBLEM:
PDPOCMU when run in Benefit mode produces an erroneous
API Error or Warning message � Plan Code is not valid -
for months a new employee is not employed or covered
under a newly added benefit plan. The PDPOCMU process
is inserting the Benefit Code and Plan even when the
employee didn�t have it and the benefit code and plan
were not active for that Benefit Category. The process
then lists it for any month after they are active/
enrolled as an API Error or Warning message.
IMPACT:
The �Plan Code is not valid� message will no longer be
generated when the employee is not employed or covered
under a newly added benefit plan, and that benefit and
plan will not be populated in the pdrhioc table.
RESOLUTION:
pdpocmu.pc - Created p_process_pre_employment_rec
routine for
checking pre-employment record. This routine will also
remove
benefit and plan code from printing and inserting in
PTROCMU
table.
Link: https://ellucian.force.com/clients/a0x160000058KqZAAU
======================================================================
Change Request (Defect) #: CR-000153416
MODULE: Regulatory
PROGRAM: pdpocmu.pc
PROBLEM:
When processing with Rule Run Type, PDPOCMU is not
processing some records and showing a false "Employer
Code is missing." message. The process is also
selecting employees who were terminated prior to the
reporting year, which in turn generates another
erroneous message "Warning: PDAHIOC record with no
benefits code. A benefit code is required for 1095
processing."
IMPACT:
When processing is Rule Type, PDPOCMU will find the
correct employer code, and will not include employees
that terminated prior to the current reporting year,
unless employees are enrolled in self-insured COBRA
coverage.
RESOLUTION:
pdpocmu.pc :- 1) Modified p_process_rule routine to get
employer code at correct location.
2) Modified select_employees for not selcting prior year
terminated
Link: https://ellucian.force.com/clients/a0x1M000005XcQyQAK
======================================================================
Change Request (Defect) #: CR-000147991
PROGRAM: pdpocmu.pc,phkacam.sql,phkacam1.sql
PROBLEM:
PDPOCMU process is not inserting a January 1 record
running in Benefit Mode when:
1) When date being referenced in PEAEMPL based on
parameter 04 (Employment Base Date) is outside of the
current processing year and the employee goes from
non-benefit eligible to benefit eligible.
2) When new employee hired mid-year waives coverage and
PDADEDN status is �waived�.
PDPOCMU process in Benefit Mode inserts too many records
when:
1) After an employee waives coverage/PDADEDN status is
�waived�.
All issues occur regardless of whether running for all 12
months at one time or running month by month.
The work around is to update PDAHIOC records manually.
IMPACT:
The process will create a January 1 record using Benefit
Run Type when
-An employee moves from non-benefit eligible in the prior
year to benefit eligible in the new year, and a new ACA
reportable benefit is active in the new reporting year
-An employee is hired during the reporting year and
waives ACA reportable benefit.
The process will not repeat records when an employee
waives coverage.
RESOLUTION:
pdpocmu.pc , phkacam.sql, phkacam1.sql :- Created a new
routine phkacam.p_get_valid_code and
phkacam.p_check_emp_rec_exists.
phkacam.p_check_emp_rec_exists determines the
pre-employment category and phkacam.p_get_valid_code
routine is used to find the proper safe harbor and
offer code for given employee.
Link: https://ellucian.force.com/clients/a0x16000005YGl2AAG
======================================================================
Change Request (Defect) #: CR-000153093
MODULE: Regulatory
PROGRAM: pdpomcu.pc
PROBLEM:
Two issues with PDPOCMU when run in Benefit Mode:
1) PDPOCMU is not populating the Employee Lowest Plan
Amount when offer code is other than 1A and run in
Benefit mode.
2) PDPOCMU is running for all employee classes and not
just those listed on PTROCMU.
IMPACT:
The process will only process Employee Classes that are
defined in PTROCMU for the reporting year.
The process will populate the Employee Lowest Plan Amount
when the Offer of Coverage Code is 1B, 1C, 1D, 1E, 1J
or 1K. The value for Employee Lowest Plan Amount will
be the amount defined in PTROCMU for the Employee Class
and Reporting Year.
RESOLUTION:
1. Removed the logic of not populating Employee Lowest
Plan Amount when offer code is other than 1A and run in
Benefit mode from process_pdrhioc routine.
2. Added logic to check ptrocmu entries before printing
the employee class in p_check_dedn_exists routine.
Link: https://ellucian.force.com/clients/a0x1M000005XX1hQAG
======================================================================
Change Request (Defect) #: CR-000152669
MODULE: Benefits Administration
PROGRAM: pdrhioc.pc
PROBLEM:
PDRHIOC is validating employer code in both ptrempr and
pxrmter, and it should only validate in ptrempr.
IMPACT:
The pdrhioc process will only validate ACA employers
against the ptrempr table.
RESOLUTION:
Removed pxrmter table reference from employer validation
routine, validate_empr_code.
Link: https://ellucian.force.com/clients/a0x1M000005XTYaQAO
======================================================================
Change Request (Defect) #: CR-000146100
MODULE: Regulatory
PROGRAM: pdrhioc.pc,phkacam.sql,phkacam1.sql,
pdkb_aca_coverage_r1.sql,pdkb_aca_coverage_s0.sql,
pdkb_aca_coverage_s1.sql
PROBLEM:
PDRHIOC lists erroneous warning message (HIOC record may
be incorrect; Coverage is not in force) in the
following two scenarios:
Scenario 1 - Employee has waived coverage, PDADEDN status
is set to waived and there are no PDABCOV records
Scenario 2 - Employee has active coverage and ongoing
coverage record on PDABCOV
Scenario 3 - Employee has past health coverage under one
deduction code that was terminated several years ago
and current active coverage under a different deduction
code.
In scenario 1, the warning message is created for any
month the PDRHIOC report is run or if it is run for All
months.
In scenario 2, the warning message is not created for the
first month the employee has coverage, or for January
if an evergreen employee, but will be created for any
subsequent month the PDRHIC report is run or for
subsequent months if run for a specific month.
In scenario 3, the warning message is created for any
month the report is run or if it is run for all months.
IMPACT:
Messaging has been changed to more accurately reflect
the status of the person being reported.
RESOLUTION:
phkacam.sql/phkacam1.sql/pdrhioc.pc
Edit logic, phkacam.p_get_audit_report_warning_msg
routine has been
reconstructed to handle various edit issues by moving
common edit
messages into coverage API and utilizing them.
This edit routine is called in pdrhioc process and edit
handling logic
has been modified for the multiple edit messages
returned by
phkacam.p_get_audit_report_warning_msg
routine.
pdkb_aca_coverage_r1.sql/pdkb_aca_coverage_s0.sql/
pdkb_aca_coverage_s1.sql
Added following edit messages used in PDRHIOC process
edit routine,
phkacam.p_get_audit_report_warning_msg:
WARNING_INVALID_COMB: Invalid combination of Offer Code
%01% and Safe
Harbor %02%.
WARNING_INVALID_COMB_NO_COV: Invalid combination of
Offer Code
%01% and Safe Harbor %02%; no
coverage in force.
WARNING_INVALID_COBRA_COMB: Invalid combination of
Cobra Offer Code
%01% and Safe Harbor %02%.
W_INVALID_COBRA_COMB_NO_COV: Invalid combination of
Cobra Offer
Code %01% and Safe Harbor %02%; no
coverage in force.
Link: https://ellucian.force.com/clients/a0x160000058KSXAA2
======================================================================
Change Request (Defect) #: CR-000151670
MODULE: Regulatory
PROGRAM: pekempl.sql,pekempl1.sql,pereo41.pc,pereo42.pc,
pereo4d.pc,paycmplc.pl,paycmplc.shl
PROBLEM:
For employers/agencies having less than 1000 employees,
there are certain functions which need to be reported
in the following manner:
Valid example
� Employer GOV has the following Functions with a total
of 750 employees (under 1000)
o Function 02 �Streets and Highways� has 99
employees
o Function 12 �Utilities and Transportation� has 601
employees
o Function 13 �Sanitation and Sewage� has 50
employees
� Function 12 would be reported in the normal report
format
� Functions 02 and 13 would NOT be reported on individual
reports, but would be combined on a new report
identified as Function 16 (NO TITLE)
The Function 16 report uses the same format as other
function reports, i.e.:
o Fulltime with Categories and Salary ranges
o Other than Fulltime with Categories (no salary ranges)
o New Hires with Categories (no salary ranges)
The Function 16 report is not included in Summary page of
reported function totals.
IMPACT:
The EEO-4 Summary Report (PEREO41/42) process has been
modified to comply with regulations for agencies with
under 1,000 employees. If any Function has less than
100 employees, those employees will be reported on a
separate Function 16 report. The process will:
1. Determine Total Full-time (FT) Employees for Employer;
2. If the total FT employees is < 1,000, new
functionality will be used to produce the Summary and
Detail reports;
New logic:
a. If Total employees reported in a Function is < 100,
the process will report a message on the Detail that
those totals are being reported under Function 16;
b. The original Function Code/Description will be removed
from the Summary process, and will generate a separate
Function 16 report instead;
c. No Description is associated with Function 16 on the
report;
d. If more than one Function meets the < 100 criteria,
all records, across any identified Functions, will be
combined and report on one Function 16.
RESOLUTION:
pekempl.sql/pekempl1.sql
Added f_chk_efun_16 routine to be used in EEO4 processes.
This routine is to determine function 16 which needs to
be created for functions less than 100 employees and
grand total employees of those functions doesn't exceed
1000 employees.
pereo41.pc
Modifed main, insert_g, sect_d1, sect_iv, sect_v, and
pr_info routines to add function 16 logic. Added
p_print_efun_tot to print total section at the end of
the processing
routine to distinguish functions which has less than 100
employees and grand total employees of those functions
doesn't exceed 1000 employees. A new package routine,
pekempl.f_chk_function_16 is called to determine
function 16 logic.
pereo42.pc
Fix: Modifed main, sel_function, sel_pereeos to check
function 16 and added related logic to process function
16. Added f_chk_efun_16 to check whether function 16
needs to be reported.
pereo4d.pc
Modifed main, skill_body, control_info, and function_body
routines to note function 16 if this function is to be
reported. Added f_chk_efun_16 routine to check for the
function 16. A new message, "It is recommended to run
PEREO41/42 before running PEREO4D." is added if pereo41
process is not run prior to running this process.
paycmplc.pl/paycmplc.sql
Master pro*C compilation
scripts are modified to add full compilation option.
Link: https://ellucian.force.com/clients/a0x1M000005X6h6QAC
======================================================================
Change Request (Defect) #: CR-000151945
PROGRAM: pektev1.sql
PROBLEM:
Leave Report page - "Insufficient leave balance" warning
message is not displaying when user enter more than the
available days.
IMPACT:
Now the user is able to see the warning message
"Possible Insufficient Leave Balance for Sick Pay"/
respective earn code name when entering more than the
available hours/days/units in the Leave Report.
RESOLUTION:
Added a new cursor perjobs_c in the function
f_validate_leave_balance. The correct leave category
code fetched in the cursor is passed to get the the
leave category details.
Link: https://ellucian.force.com/clients/a0x1M000005XIppQAG
======================================================================
Change Request (Defect) #: CR-000148592
MODULE: Time Reporting
PROGRAM: pektevt.sql,
pektev1.sql
PROBLEM:
Web time entry will allow for hours to be entered in for
days in a pay period before the job begin date. This
happens if the job starts mid-pay period.
Steps to reproduce:
1) Access the web time entry
screen after selecting the pay period.
2) Select a day to enter time in for.
3) Copy the full
URL.
4) Paste copied URL into URL Bar.
5) Change the date in the URL to reflect any day in the
pay period including a day before the job starts and
then hit enter.
6) System will update database with modified
information.
The hours entered are allowed to be submitted and
approved. PHPMTIM will produce an error with 'Posn/Suff/
Eff Date not found. Extract Emp?'. The corrupt data
will never make it to the timesheet.
IMPACT:
With this Modification, Web time entry will not allow
hours to be entered in for days in a pay period before
the job begin date.
RESOLUTION:
Added validation routine f_valid_time_entry_keys_ind to
validate the timesheet keys (JobSeqno, DateSelected,
EarnCode).
Link: https://ellucian.force.com/clients/a0x16000005YWsKAAW
======================================================================
Change Request (Defect) #: CR-000124698
PROGRAM: pguroptmi_08140005.sql
PROBLEM:
The self-service menu option is missing in PTRINST.
IMPACT:
The Installation Rule page (PTRINST) was missing a
self-service menu option. This has been corrected with
this CR, however, the complete correction with
navigation is only available in the 9.x page. We did
not retrofit the INB PTRINST 8x form due to the future
2018 year-end desupport of Banner 8.
RESOLUTION:
pguroptmi_08140005.sql
Script to add Self-Service option menu.
Link: https://ellucian.force.com/clients/a0x16000003u4BeAAI
======================================================================
Change Request (Defect) #: 1-8DA529
MODULE: Payroll Processing
PROGRAM: phklabr1.sql
PROBLEM:
The issue only occurs in a VPD enviroment & only when
using the Change All indicator
When processing an Adjustment using the PHAREDS form and
selecting the Change All indicator a trigger error is
generated. "CHANGE_ALL_REDISTRIBUTIONS trigger raised
unhandled exceptions." See attached screen print
IMPACT:
When processing an Adjustment using the PHAREDS form and
selecting the Change All indicator a trigger error is
generated. "CHANGE_ALL_REDISTRIBUTIONS trigger raised
unhandled exceptions.
The code has been changed such that this unhandled
exception not longer displays and the user is able to
successfully complete the labor redistribution using
the change all functionality.
RESOLUTION:
For more information regarding the archive project
please refer to article 000035006.
RESOLUTION:
Used two new local variables (lv_disp and lv_locked) to
pull out function calls (phklrcm.f_phrhist_disp and
phklrcm.f_is_phvecrt_locked) from update statements of
p_change_redistribution routine instead of direct
function calls. Using local calls prevents from causing
unhandled exception in MEP'd instance.
Link: https://ellucian.force.com/clients/a0xG0000001OYfUIAW
======================================================================
Change Request (Defect) #: CR-000103631
MODULE: Benefits Administration
PROGRAM: PHPCALC.pco
PROBLEM:
A replace on PDADEDN will generate a negative value for
the employee amount if the available net is less than
the protected minimum earnings for a calc rule 23. The
number generated is the difference between the
available net and the protected minimum earnings.
For example a calc rule 23 is entered with a replace
amount of $89. The protected minimum earnings are
$300.
The available net is $247.20
Phpcalc calculates the deduction at -$52.80 to get up to
the protected minimum earnings level. Here the result
should be 0.00 deducted regardless of add/replace.
Workaround - run the following sqlplus script to identify
anyone in the pay event that may have a negative
employee amount. If anyone is returned, go into
PDADEDN and alter the replace amount and then rerun the
phpcalc process.
select spriden_id, phrdedn_bdca_code,
phrdedn_employee_amt
from spriden,phrdedn
where spriden_change_ind is null
and spriden_pidm =
phrdedn_pidm
and phrdedn_year = '&year'
and phrdedn_pict_code = upper('&pay_id')
and
phrdedn_payno = &pay_nbr
and nvl(phrdedn_employee_amt,0) < 0
IMPACT:
An issue was reported upon processing a Protected
Earnings deduction, where a onetime replacement amount
(PDADEDN) exceeded the Available Net pay when the
deduction was being calculated. Because the Benefit
Deduction rule was set to take Partial Arrears, the
Deduction Available Net was driven negative and
returned excess money to the employee�s Net Pay.
This situation has been corrected. PHPCALC was changed
(Version 8.14.0.2) to process Protected Earnings
deductions differently for Partial Pay Arrears
scenarios. The program was modified only for
Calculation Rules 10, 12, 20, and 23 (Protected
Earnings deductions) and only in the case where the
PTRBDCA Arrears Code is set to 'Partial'.
Other arrears settings do not affect the employee's Net
Pay in these types of deductions. Using an Add or
Replace on these deduction codes will now place all
uncollected funds in arrears, when the Protected
Earnings amount is reached.
RESOLUTION:
Modified 38010-CALC-10, 38012-CALC-12, 38020-CALC-20,
and 38023-CALC-23 to set DWRK-AV-NET to zero when the
available net is a negative number.
Link: https://ellucian.force.com/clients/a0xG0000001QrKsIAK
======================================================================
Change Request (Defect) #: CR-000153008
MODULE: Regulatory
PROGRAM: PHPCALC.pco
PHPTAXS.pco
PXPVRFY.pco
PROBLEM:
MA state tax may be incorrectly calculated when fica old
age and medicare ytd amounts exceed the $2000.00 annual
limit.
IMPACT:
Banner uses the Annualization method for all State Tax
calculations. Processing logic will now look at the
employee�s year-to-date withholding for both FICA
deductions when determining if the $2,000.00 maximum
allowable amount has been met.
� If the FICA limit has not been met, the pay period
being processed will use the annualization method with
a limit of $2,000.00 as seen in Step 3 on PXACALC;
� If the FICA limit will be met in the pay period being
processed, only the difference between the maximum $2,
000.00 and the year-to-date amount will be used in the
withholding calculation;
� If the FICA limit has already been met before the pay
period being processed, zero will be used for the FICA
amount in the calculation.
NOTE: No changes were needed to the tax tables on the
PXACALC page.
RESOLUTION:
Modified the linkage area that is passed to PHPTAXS.pco.
New logic was added to PHPTAXS.pco to calculate the YTD
FICA and medicare amounts and limit the exemption to
$2000.
Link: https://ellucian.force.com/clients/a0x1M000005XWNDQA4
======================================================================
Change Request (Defect) #: CR-000151902
MODULE: Payroll Processing
PROGRAM: phpcalc.shl phpdird.shl phpfexp.shl
PROBLEM:
Banner HR Defect phpfexp.shl file does not write the
.log file to the $HOME
The phpfexp.shl writes the .lis file to $HOME but the
.log file will be written to whatever directory gurjobs
is started from.
Here is the line which writes the log and lis
file.
$PRNTOPT $HOME/phpfexp_$3.lis 1>>phpfexp_$3.log 2>&1
This is a problem with many of the p*.shl files.
For example phpcalc.shl
$PRNTOPT $HOME/phpcalc_$3.lis
1>>phpcalc_$3.log 2>&1
Other products do write to $HOME.
For example
rcpct18.shl
$PRNTOPT $HOME/rcpct18_$ONE_UP.lis 1>>$HOME/
rcpct18_$ONE_UP.log 2>&1
Workaround: Start gurjobs in the $HOME directory as
stated in Article
Article 000026194 Banner Job Submission Gurjobs started
as a Background Process in Unix
HOME=$HOME/jobsub/$ORACLE_SID; export HOME
cd $HOME
gurjobs.shl > gurjobs_start_$ORACLE_SID.log 2>&1 &
IMPACT:
The Expenditures Finance Extract process (PHPFEXP.shl)
file will now write the .log file to the $HOME
directory.
RESOLUTION:
Added $HOME in front of log file when it gets printed
via Jobsub.
Link: https://ellucian.force.com/clients/a0x1M000005XHeHQAW
======================================================================
Change Request (Defect) #: CR-000133760
MODULE: Regulatory
PROGRAM: phptaxs.pco
PROBLEM:
Total CT employee withholding cannot be less than zero.
PHPTAXS calculates a negative total withholding amount
per pay period when a negative additional withholding
amount on PDADEDN exceeds the total withholding amount.
CT 2015 Withholding Calculation rules (Rev. 08/2015),
Page 1 of 6, for Step 16 states the result cannot be
less than zero.
IMPACT:
The PHPTAXS tax calculation process was calculating a
negative total withholding amount when a negative
additional withholding amount on PDADEDN exceeded the
total withholding amount. This has been corrected to
not allow the Total Tax Withheld to be less than zero
(0.00).
RESOLUTION:
Modified 60700-GENERIC-STEP-07 to set total employee
withholding amount to zero when the total withholding
calculates to a negative value.
Link: https://ellucian.force.com/clients/a0x160000040iszAAA
======================================================================
Change Request (Defect) #: CR-000149461
PROGRAM: PHPTAXS.pco
PROBLEM:
Payroll 8.14 does not deliver the PHPTAXS.pco fixed in
change Request CR-000144949 and therefore the program
will not compile with Micro Focus.
* Compiling PHPTAXS.cob
1116 *
* 143-S**** ( 0)**
** Unknown IDENTIFICATION DIVISION paragraph
1130 * paragraph 10000-ENTER-PROGRAM.
* 143-S**** ( 1)
**
** Unknown IDENTIFICATION DIVISION paragraph
* Total Messages: 2
* Unrecoverable : 0 Severe : 2
*
Errors : 0 Warnings: 0
* Informational : 0 Flags : 0
* Data: 20370 Code: 0
cob64: error(s) in compilation: PHPTAXS.cob
*** Error code 12
make: Fatal error: Command failed for
target `PHPTAXS.o'
This error does not occur using NetCobol Compiler.
Workaround is fix the "*", comment line # 1116, 1128 and
1130 so that it starts at same position as other
comment lines.
PHPTAXS.pco with the edit already in place is attached.
IMPACT:
Payroll 8.14 upgrade delivers PHPTAXS.pco that will not
compile with Micro Focus. This modification corrects
that problem, and the process will compile successfully
with the Micro Focus compiler.
RESOLUTION:
Converted tab characters to spaces.
Link: https://ellucian.force.com/clients/a0x16000005Z36UAAS
======================================================================
Change Request (Defect) #: CR-000151295
MODULE: Regulatory
PROGRAM: ptreeosu_081401.sql,pereo41.pc,pereo42.pc,
pereo4d.pc,pekempl.sql,pekempl1.sql
PROBLEM:
The salary ranges on PTREEOS are different from what the
regulatory is looking for therefore it's throwing the
salary ranges on the report off. For example, under on
PTREEOS the annual salary level for full-time employees
start off with:
For your reference here are the salary ranges:
all in
dollars
PTREEOS What EEOC want to see
1- 7,999 1 - 15,999
2-11,999 16,000 - 19,999
3-15,
999 20,999- 24,999
4-19,999 25,999- 32,999
5-24,999 33,999- 42,999
6-32,999 43,999- 54,999
7-42,
999 55,999-69,999
8-9,999,999 70,000 plus
On the left is an example of PTREEOS and on the right is
what the EEOC salary levels requirments for the EEO4
2017 survey.
Work around: Manually update salary ranges on the
PTREEOS page.
IMPACT:
The script for PTREEOS to support EEO4 Governmental
reporting was not delivered with the 8.14.0.1 release.
This has been corrected to deliver the EEO Salary Level
Rules (PTREEOS) as seed data.
RESOLUTION:
ptreeosu_081401.sql
This update script resets maximum salary amount for each
salary level according to the Government guideline.
pekempl.sql/pekempl1.sql/pereo41.pc/pereo42.pc/pereo4d.pc
8.14.0.1 objects have been rolled into 8.14.1 release
not to require the 8.14.0.1 patch. Any government
client can apply just 8.14.1 release without 8.14.0.1
patch. 8.14.0.1 and 8.14.1 objects are identical.
Link: https://ellucian.force.com/clients/a0x1M000005J7fyQAC
======================================================================
Change Request (Defect) #: CR-000150952
MODULE: Faculty Administration
PROGRAM: ptrflct_081500_01.sql,
ptrflct_081500_02.sql,
ptkb_fac_cntract_r1.sql
ptkb_fac_cntract_s1.sql,
ptkb_fac_cntract_s0.sql
PROBLEM:
PTRFLCT always requires the Extract Job Effective Date
to be entered. This date is only used if the view is
Salaried. This date is not used when the view is Course
based.
There should be an edit to require the Extract Job
Effective date only if the view is set to Salaried.
IMPACT:
PTRFLCT always requires the Extract Job Effective Date
to be entered. This date is only used if the view is
Salaried and is not used when the view is Course
based.
An edit was added to require the Extract Job Effective
date only if the view is set to Salaried.
RESOLUTION:
1. ptkb_fac_cntract_r1.sql :-
Removed required field edit for Extract Job Effective
Date.
2. ptkb_fac_cntract_s1.sql,ptkb_fac_cntract_s0.sql :-
Removed error message code MISSING_EXTR_JOBS_EFF_DATE
as corresponding edit is also removed from the rules
API.
3. ptrflct_081500_01.sql :- Modify
ptrflct_extr_jobs_eff_date column to accept null
values.
4. ptrflct_081500_02.sql :- Modified
ptrflct_extr_jobs_eff_date column description to
OBSOLETE.
Link: https://ellucian.force.com/clients/a0x16000005Zk8EAAS
======================================================================
Change Request (Defect) #: CR-000146403
PROGRAM: pxkacef171.sql
PROBLEM:
When running PXPAC16 to regenerate an XML file get error
message:
API error during creation of filing data
Message 0 = No message text for error:
1095C_EXISTS
This error message will occur when the
PXR95EM_SURROGATE_ID_SEQUENCE tries to insert a value
already used. This can happen if the pxr95em table is
truncated and the sequence is not reset.
This error message should provide message text to provide
more information as to why it happens.
Work around is to:
Find max surrogate id seq:
SELECT max(PXR95EM_SURROGATE_ID)
FROM pxr95em;
Then get next value for:
SELECT
payroll.PXR95EM_SURROGATE_ID_SEQUENCE.nextval FROM dual;
Then alter the sequence:
alter sequence payroll.PXR95EM_SURROGATE_ID_SEQUENCE
increment by 1;
The increment by value will need to be based on what you
get as the nextval and what the max sequence is rather
than just 1.
IMPACT:
The 1094/95-C Submission process (PXPAC16) returned an
API error �1095C_EXISTS� if the pxr95em table had been
truncated and the sequence was not reset. The message
did not provide any guidance as to where the problem
occurred. The API error has been expanded to identify
the duplicate situation in the PXR95EM table: "Attempt
to insert duplicate surrogate ID %01% into pxr95em.",
where %01% is the employee ID.
Two other API errors were clarified as well:
'HEADER_RECORD_EXISTS'=> Attempt to insert duplicate
index into pxr95ef.
'ALE_GROUP_MEMBER_EXISTS'=>Attempt to insert duplicate
index into pxr94ag.
RESOLUTION:
Missing descriptive exception messages are added for
1095C_EXISTS, ALE_GROUP_MEMBER_EXISTS, and
HEADER_RECORD_EXISTS exceptions.
Link: https://ellucian.force.com/clients/a0x160000058SaPAAU
======================================================================
Change Request (Defect) #: CR-000146540
MODULE: Regulatory
PROGRAM: pxkacxm171.sql
PROBLEM:
Issue 1): PXPAC16 not correctly formatting foreign
addresses. The process is inserting extra characters
into the address format in the data file for foreign
addresses. It is inserting irs: before the
ForeignPostalCd tags. This is causing an IRS AIRSH100
error message upon submittal of the data file or errors
out on validation using the IRS schemas.
Issue 2): PXPAC16 is inserting Canadian addresses in a US
format in the data file. This also causes an IRS
AIRSH100 error message upon submittal of the data
file.
Work around for both issues is to update the XML data
file to the proper format.
Example of a Foreign Address in the data file:
9999 Ellesmere Road
Scarborough
CA
Or it
can look like this:
9999 Ellesmere Road
Scarborough
CA
M1C1H6
ForeignPostalCd>
IMPACT:
The 1094/1095-C 2016 Submission process (PXPAC16) was
not correctly formatting foreign addresses. This has
been corrected in the 2017 process (PXPAC17) to produce
the correct XML elements for foreign addresses.
RESOLUTION:
Modified function f_is_foreign_address to remove the
state code check for foreign address. Modified function
f_mailing_address_grp_str to format the address
correctly.
Link: https://ellucian.force.com/clients/a0x160000058XImAAM
======================================================================
Change Request (Defect) #: CR-000153054
MODULE: Regulatory
PROGRAM: pxkacxm171.sql
PROBLEM:
The IRS assigns a new SoftwareID each year. This ID
value needs to be entered into the 2017 XML layout when
creating the manifest file: 17A000xxxx
SoftwareId>.
IMPACT:
The IRS assigns a new Software ID each year. The 2017
ID has been entered into the package used by the
PXPAC17 process for the 2017 XML layout when creating
the manifest file: 17A000xxxx
.
RESOLUTION:
Updated the variable softwareID with new Software ID
value.
Link: https://ellucian.force.com/clients/a0x1M000005XWbAQAW
======================================================================
Change Request (Defect) #: CR-000146546
MODULE: Regulatory
PROGRAM: pxkgaca1.sql
PROBLEM:
PXRAC16 is not using the Social Security Name on PEAEMPL
for covered individuals that have their own PIDM and
PEAEMPL record.
The work around is to sql in updates to PXRCOVI table for
the dependent:
update pxrcovi
set pxrcovi_covered_first_name = 'SSN FIRST NAME',
pxrcovi_covered_last_name = 'SSN LAST NAME',
pxrcovi_covered_mi = 'SSN MIDDLE NAME'
where pxrcovi_pidm = UPDATE WITH EMPLOYEE'S PIDM
and
pxrcovi_covered_pidm = UPDATE WITH DEPENDENT's PIDM;
IMPACT:
The United States 1095-C process (PXRAC16) was not using
the Social Security Name from PEAEMPL for covered
individuals that had their own PIDM and PEAEMPL record.
This has been corrected in the PXRAC17 year-end process
and captured correctly in the PXRCOVI table.
RESOLUTION:
Modified the pxkgaca.p_build_95c_covi_2017 routine for
2017 ACA reporting year to
update the bene_name_c cursor to retrieve the SSN name
from PEBEMPL table regardless of the relationship code
(BREL_CODE) on PDABENE. SPRIDEN name will be used if
SSN name is not setup on PEAEMPL.
Link: https://ellucian.force.com/clients/a0x160000058XJuAAM
======================================================================
Change Request (Defect) #: CR-000147818
MODULE: Regulatory
PROGRAM: pxkgaca1.sql
PROBLEM:
PXRAC16 is pulling PDRBCOV/PDRBCHS records for a
non-reportable deduction code and creating coverage
records in Part III when none should be created.
IMPACT:
The United States 1095-C process (PXRACxx) was printing
Part III records when the Benefit/Deduction had not
been identified on the Tax Reporting Rules page
(PXAREPT). This has been corrected to only print Part
III records if the Benefit/Deduction is identified on
PXAREPT.
RESOLUTION:
Modified the PXKGACA package to update the pdrbcov_c
cursor to check if the coverage deduction code,
pdrbcov_bdca_code, is defined as a reportable deduction
for the 1095-C on theTax Reporting Rules (PXAREPT).
Link: https://ellucian.force.com/clients/a0x16000005YB6AAAW
======================================================================
Change Request (Defect) #: CR-000146577
PROGRAM: pxpac17.pc
PROBLEM:
PXPAC16 process is requiring parameter 07 to be entered
if saying �Y� to Parameter 06 � Authoritative
Transmittal.
Parameter 07 should not be linked to Parameter 06 since
not all employers have to complete a box on line 22 of
the 1094C.
If Parameter 07 is left blank when saying �Y� to
Parameter 06 the process will abort with the following
message:
Parameter error(s) halted program
execution.
Certification of Eligibility required for authoritative
transmittals.
The work around is to run the file with an �A� in
Parameter 07 and then remove the line that looks like
this:
1
from the data file.
Make sure to remove the line and save the XML file prior
to completing the checksum/bytesize steps.
IMPACT:
When the 1094/95-C 2016 Submission process (PXPAC16) was
run as an Authoritative Transmittal, it was requiring
an entry in Parameter 07 Certification of Eligibility.
A Certification of Eligibility was only required for
tax year 2015. This has been corrected for 2017 in the
PXPAC17 process to not require an entry in Parameter 07
when Parameter 06 is identified as an Authoritative
Transmittal.
RESOLUTION:
Modified validate_parameters routine to remove the edit
checking values of parameter 07 (Certification of
Eligibility) for the value Y of parameter 06
(Authoritative Transmittal).
Link: https://ellucian.force.com/clients/a0x160000058Yg5AAE
======================================================================
Change Request (Defect) #: CR-000153766
MODULE: Regulatory
PROGRAM: pxr1042.pc
PROBLEM:
PXR1042 - Extract blank line in address fields of 1042-S
can cause the city, state and zip line to be printed on
the next page.
IMPACT:
The Foreign Person 1042-S process (PXR1042) was
injecting an extract blank line in certain
circumstances. This was corrected by creating each
line with a hard return to maintain the correct
positioning of data in each line and box.
RESOLUTION:
Modified table definitions to include a space in each
line to prevent null variables from resulting one less
line and from firing incomplete logic of adding an
additional line. Modified print_form routine to add
empty space for each line and to remove logic checking
empty lines resulted by null variables. This fix will
remove additional line
between box 6/13i/13j and box 7a due to incomplete line
logic.
Link: https://ellucian.force.com/clients/a0x1M000005XeEXQA0
======================================================================
Change Request (Defect) #: CR-000153990
PROGRAM: pxr1095_081500_01.sql,
pxr95ef_081500_01.sql
PROBLEM:
There are unprintable characters in the following table
column comments, which cause ORA-39346 errors when run
impdp in an Oracle 12c database. .
The tables in Human Resources with errors are:
ORA-39346: data loss in character set conversion for
object COMMENT:"PAYROLL"."PXR1095"
ORA-39346: data loss in character set conversion for
object COMMENT:"PAYROLL"."PXR1095"
ORA-39346: data loss in character set conversion for
object COMMENT:"PAYROLL"."PXR95EF"
ORA-39346: data loss in character set conversion for
object COMMENT:"PAYROLL"."PXR95EF"
Workaround:
sqlplus payroll/password
COMMENT ON COLUMN
PAYROLL.PXR1095.PXR1095_ZIP IS 'ZIP CODE: The zip code
associated with the employee''s address for the
reporting year. ';
COMMENT ON COLUMN PAYROLL.PXR1095.PXR1095_NATN_CODE IS
'NATION: The nation or country associated with the
employee''s address for the reporting year. ';
COMMENT ON COLUMN
PAYROLL.PXR95EF.PXR95EF_TRANSMISSION_TYPE IS
'TRANSMISSION TYPE IND: Transmission Type Code to
identify type of records: O-Original, C-Corrections,
R-Replacement.';
COMMENT ON COLUMN PAYROLL.PXR95EF.PXR95EF_PRIOR_YEAR_IND
is 'PRIOR YEAR IND: Prior filing year indicator:
Y-Prior Year,N-Current Year.';
See "Article 000037359 Banner and ORA-39346 Data Loss In
Character Set Conversion During Import" for more
details and sample scripts.
https://ellucian.force.com/clients/articles/FAQ/
Banner-and-ORA-39346-Data-Loss-In-Character-Set-Convers
ion-During-Import
https://ellucian.my.salesforce.com/kA0160000001XHx
IMPACT:
There is no functional impact due to this change.
RESOLUTION:
Added new table comment scripts to remove the
unprintable characters.
Link: https://ellucian.force.com/clients/a0x1M000005XgeKQAS
======================================================================
Change Request (Defect) #: CR-000153196
MODULE: Regulatory
PROGRAM: pxrw217.pc
PROBLEM:
When running PXRW217 to create year end W2's, log file
contains the following warning message:
WRN-LONGTOK: Token "WH-001-733-6320-01" exceeds
containing column width (17)
The value "WH-001-733-6320-01" is the HI state account
code from the PTREMPR set up.
IMPACT:
Increased Box 15, the Employer's State ID Number field,
to display up to 20 characters. Reduced Box 16, the
State wages, tips field, from 11 digits to 10 digits.
Note: no changes have been made by the IRS to Box 15 to
provide for a longer State ID Number. This could
possibly affect the reporting of highly paid state
wages.
RESOLUTION:
box_15_empr_id and box_16 fields were changed as
followed:
- Print all 20 chars for the Employer's State ID
number
- Print 1 char less for the State wages and
tips
- No spaces between the first 3 fields (State,
State ID number, State wages and tips)
Link: https://ellucian.force.com/clients/a0x1M000005XY23QAG
======================================================================
Change Request (Defect) #: CR-000153309
MODULE: Regulatory
PROGRAM: pxrw217.pc,pxpw217.pc,pxpwc17.pc
PROBLEM:
The PXRW217 process does not display the totals
associated with box 12FF QSEHRA Health Reimbursement in
the .log file when creating W2s or in the .lis file
when running in Totals Only mode.
Box 12FF does display on the printed W2 output as well as
in the Employee Self Service display W2 option.
Work around to verify Box12FF totals is to query PERDTOT
table for specified year and BDCA code:
select sum(perdtot_empl_amt), sum(perdtot_empr_amt),
sum(perdtot_appl_grs) from perdtot
where perdtot_year = '2017'
and perdtot_bdca_code =
'UPDATE WITH BDCA CODE LISTED IN BOX 12FF ON PXAREPT';
IMPACT:
The new 2017 W-2 reportable Code 12FF QSEHRA Health
Reimbursement did not show in the Totals for the
PXRW217, PXPW217 or PXPWC17 process output. This has
been corrected to display QSEHRA Health Reimbursement
in the Totals along with any Code 12FF amounts and
populate any amounts in the W-2 and W-2c electronic
files.
RESOLUTION:
pxrw217.pc
Added box_12ff and box_12ff_total variables. Modified
totals_only_body, w2_print_control, initialize_w2_boxes,
add_to_box_totals, print_totals, and
tmInitGlobS_pxrw217 routines to add 12FF box logic.
pxpw217.pc
Added rw_qsehra_health_reimburse,
rt_qsehra_health_reimburse, gt_qsehra_health_reimburse
variables. Modified ins_rt_record,
initialize_rw_ro_data, initialize_rt_ru_data,
print_empr_totals, and print_grand_totals routines to
add QSEHRA Health Reimbursement.
pxpwc17.pc
Added rw_qsehra_health_reimburse,
rt_qsehra_health_reimburse,
gt_qsehra_health_reimburae, rcw_qsehra_health_reimburse,
rct_qsehra_health_reimburse,
gct_qsehra_health_reimburse,
p_rct_qsehra_health_reimburse variables. Modified
initialize_vars, ins_rcw_record, ins_rct_record,
main_body, initialize_rcw_rco_data,
initialize_rct_rcu_data, print_empr_totals, and
print_grand_totals routines to add QSEHRA Health
Reimbursement.
Link: https://ellucian.force.com/clients/a0x1M000005XbKkQAK
======================================================================
Change Request (Defect) #: CR-000155145
MODULE: Regulatory
PROGRAM: Year End Regulatory Handbook
PROBLEM:
Year End Regulatory Handbook needs to be updated to
fully define how the Total Employee Count is
accomplished. Current 8.14.1 handbook on page 52.
Current documentation states:
Total employee count is
required on the 1094-C form. The 1094/95-C Submission
(PXPACxx)
process scans all employee records on the Employee
(PEAEMPL) page for the given year and
employer. Those employees with a non-terminated status as
of the 1st day of each month are
selected.
The documentation should include that it looks to NBAJOBS
where an employee has a non-terminated status as of the
1st day of each month in addition to PEAEMPL.
IMPACT:
The Year End Regulatory Handbook has been updated to
include the review of Employee Jobs (NBAJOBS) in the
Total Employee Count for 1094-C reporting.
RESOLUTION:
Edited the Banner Human Resources Year-End Regulatory
Handbook for U.S. and Puerto Rico to clarify how the
system calculates the Total Employee Count. The process
counts the PEAEMPL records AND checks for employee jobs
with a non-terminated status as of the first day of the
month and includes only those employees in the count.
Link: https://ellucian.force.com/clients/a0x1M000005kpoyQAA
======================================================================
************************************************************************
Without limitation: Ellucian(R), Banner(R), Colleague(R), and Luminis(R)
are trademarks of the Ellucian group of companies that are registered in
the U.S. and certain other countries; and Ellucian Advance(TM), Ellucian
Course Signals(TM), Ellucian Degree Works(TM),
Ellucian PowerCampus(TM), Ellucian Recruiter(TM), Ellucian SmartCall(TM),
are also trademarks of the Ellucian group of companies. Other names
may be trademarks of their respective owners.
(C)2018 Ellucian.
Contains confidential and proprietary information of Ellucian and its
subsidiaries. Use of these materials is limited to Ellucian licensees,
and is subject to the terms and conditions of one or more written
license agreements between Ellucian and the licensee in question.
In preparing and providing this publication, Ellucian is not rendering
legal, accounting, or other similar professional services. Ellucian
makes no claims that an institution's use of this publication or the
software for which it is provided will guarantee compliance with
applicable federal or state laws, rules, or regulations. Each
organization should seek legal, accounting, and other similar
professional services from competent providers of the
organization's own choosing.
Ellucian
2003 Edmund Halley Drive
Reston, VA 20191
United States of America
******************** END OF COVER SHEET *********************