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 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. 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 *********************