Jackson Community College

Change Request............: 37022.44

Summary...................: California MIS Student Disabilities April 2008 Update

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/24/2008

Impact....................: Medium

Priority..................: C

Project...................:

Main Release ID...........:

Application...............: STSTATE

Module Name...............: CAST

Mnemonic..................:

Regulatory Enhancements...: Yes

Problem/Issue.............:

Clients experienced the following issues when creating or maintaining the California MIS Student Disabilities (SD) report:

-     There was no way to view or edit the data that was being sent before it was exported to the flat file.

-     There was no way to limit the report output by institution for multicampus districts.

-     There was no way to force the process to create data records for the report or to guarantee report output for a set of people.

-     The report only included enrolled students at the institution, which did not comply with the Chancellor's Office. Any person who received disability services at an institution, enrolled or otherwise, is eligible to be on the SD report.

-     Disability services staff at an institution were forced to use the Emergency Information (EMER) form to view and update disability information for a person, which allowed staff members to view other personal information that they should not have access to.

-     Error and warning messages were not descriptive or helpful for the end user running the report.

-     Multicampus districts had difficulty producing the correct institution GI01 Identifiers for each of their campuses.

-     The report did not include any type of printable report for the end user to review for data integrity checking.

-     Users experienced several different issues relating to records not being selected or computed columns failing.

The Student Basics (SB) report did not correctly identify all of the disabled students based upon the new Student Disabilities (SD) reporting domain.

Resolution................:

This software update provides the following improvements to the California State Reporting Student Disabilities (SD) report:

-     The Build Stu Disability (SD) Data (CASD) form now collects data into a work file before final export. The STUDENT.DSPS and CAST.SD.WORK files can be edited using two new forms, Student Disabilities (DSPS) and Student Disability Maintenance (CSDM), before the information is submitted to the Chancellor's Office.

-     The Student Disability (SD) Export (CSDE) form is a separate data export process for placing the SD report data into a flat file, which can be submitted to the Chancellor's Office.

-     The CASD process now allows the user to specify which institutions to report information for.

-     The CASD form and processes were modified to report by date range instead of by academic term. These date ranges are set up using the GI03 Identifiers on the California MIS Dates (CAMD) form.

-     Users can now fully control the report output produced by the CASD process in terms of number of people.

-     The CASD process now includes any person who received disability services at an institution through contacts or enrollments.

-     The new Student Disabilities (DSPS) form has been created to allow disability services staff at an institution to access only person disability data without having to use the Emergency Information (EMER) form where private information could be exposed.

-     Error reporting for the CASD process has been updated to include more descriptive messaging, and a troubleshooting section has been added to the Colleague documentation for the SD report.

-     Multicampus districts can now easily produce the correct institution GI01 Identifier information for the SD report.

-     The CASD process and the new Student Disability Data Reports (SDDR) process allow the user to print several different data reports on the collected SD data.

-     Performance has been greatly improved in the CASD process, and computed columns are no longer used in the primary record selection criteria.

A new parameter form, Student Disability Report Params (SDRP), has been added to allow easy setup of the information needed to produce the SD report in Colleague. This form takes the place of the historical CAST.SD01 and CAST.SD02 translation tables, which are no longer used.

The Student Basics (SB) report now correctly reports all disabled students on the Student Disabilities (SD) report.

Technical:

The STUDENT.DSPS file has been added to store disability related information for the California Student Disabilities (SD) report. The CAST.SD.WORK file has been added to store temporary data related to the SD report.

Client Impact.............:

CLIENT IMPACT

Clients who have licensed the California State Reporting module can now produce more accurate Student Disability (SD) reports, and easily maintain the information before submitting it to the Chancellor's Office.

The SD report was redesigned to use activity-based date range reporting instead of reporting by Colleague academic term. All other outstanding issues in AnswerNet for this report were resolved and implemented with this update. See the Description section for a complete list of resolved change requests.

Specific instructions and further details are provided in the "Using CA State Reporting - MIS Reports" manual.

Datatel's software is based on single source code architecture. To maintain the full potential, value, and benefits of your Datatel software, it is critical that all software updates are loaded for both the base system and all licensed modules, regardless of whether the specific update is intended to resolve an issue on a particular database or to provide database changes for a specific module. All future Datatel software updates and support will be based on the latest delivered version of software, so you must load this specific software update in order to take advantage of future updates and enhancements.

IMPLEMENTATION INSTRUCTIONS

Before using the new California MIS Student Disabilities (SD) processes, review your GI03/date range parameters on the California MIS Report Dates (CAMD) form. Be sure that GI03/date ranges are set up for reporting periods before and after each of your primary reporting periods.

The CAST.SD01 and CAST.SD02 translation tables are now obsolete and no longer used by the Student Disabilities (SD) report in Colleague. However, they will still be viewable on your system. Be sure to review the new Student Disability Report Params (SDRP) parameter form to set up the required data for the SD report.

TECHNICAL IMPLEMENTATION

Not applicable

NEW FORMS

SDRP - Stu Disability Report Params

DSPS - Student Disabilities

CSDM - Stu Disability (SD) Maint.

SDDR - Stu Disability Data Reports

SDBO - Stu Disability Batch Override

CSDE - Stu Disability (SD) Export

SDRC - Reported Contacts Summary

SDRS - Stu Disability Report Summary

CUSTOM IMPACT

If any custom changes have been made to any of the following processes, they will need to be reapplied after loading this software update:

Forms: ACS031 (ASTR), CASTF016 (CASB), CASTF900 (CAFP)

Inserts: I_SUBR.CAST.ACTIVE.SCS

Menus: CAP, CAS

Processes: CASTL016F

Subroutines: CASTB010, CASTB016F, CASTB115, CASTB900, S.CAST.CREATE.CAST.SM.WORK, S.UPDATE.CAST.SM.WORK, CASTB011

SOFTWARE PARTNER

Not Applicable

Description...............:

04/24/08 Update) The following software updates are now available to clients:

*********************************

SU37022.44-1805*16

*********************************

This update delivers changes to the Student Disabilities (SD) report, including the following:

- Added the ability to maintain SD report data before extracting it to a flat file for submission to the Chancellor's Office.

- Added the ability to view disability information for a person on a form designed specifically for California State Reporting.

- Added new printable report options for the SD data available during and after the data collection process.

- Corrected all outstanding issues with the SD report. See below for a list of the resolved change requests.

- Updated the report to comply with the Chancellor's Office requirements.

This update also delivers a new Envision-based file that is used in conjunction with the California Student Disabilities (SD) report.

This software update also resolves the following issues:

10753.56 - CASD: Cal MIS Disabilities process hangs - no selection The Stu Disability Export (CASD) process appeared to "hang" as it was performing the record selection and could take a very long time to complete. In Colleague Release 18, this could result in a DMI listener failure message as well.

11239.19 - CalMIS CASD: S.GET.CAST.DISABILITIES subroutine fails in Oracle The CASD process utilized a virtual field in its primary record selection, which subsequently called a subroutine that was not of the proper IS type, causing the selection failure.

12635.89 - CASD does not include students who registered and dropped before census Students who received contacts for their disabilities but who dropped all of their enrollments before first census were not being included on the SD report.

37355.81 - CalMIS SD CASD: No records selected or exported California clients using the CASD process on a SQL Server platform were not able to select any records because a computed column T-SQL script failed to execute.

Change Request............: 37161.33

Summary...................: Colleague Advancement Conversion Enhancements

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/4/2008

Impact....................: High

Priority..................: B

Project...................:

Main Release ID...........:

Application...............: CA

Module Name...............: B2A

Mnemonic..................:

Problem/Issue.............:

Several conversions with very large numbers of records were experiencing slow performance.  These include Contributions, Employment, and Relationships.  Additionally, several defects have been reported in various conversions.

Resolution................:

The following enhancements and bug fixes are delivered to facilitate a more efficient conversion.

-The Advancement conversions have been enhanced so any conversion can be divided into multiple batches called "Splits." This allows a conversion to be split into smaller batches, improving the conversion performance. 

- The newly delivered B2A Manage Splits (B2MS) process allows you to divide any conversion into "Splits" by dividing the total number of records the conversion will process into multiple batches.   The resulting Splits will be identified by the conversion number followed by a letter.  For example, the Relation N4 conversion can be split into three and would result in N4A, N4B, and N4C.

- The B2A Giving Group Update (ACU1) process has been updated so that it will select all batches in case the Relationship N4 or Person Demographic L1 conversions are run in multiple batches. 

-The Build BENCA.ACADEMIC (ACU4) process has been updated so that it will select all batches in case the Academic M3 conversion is run in multiple batches.

- The Ben to CA Conversion Groups (B2CG) form now allows you to enter address merge parameters specific to a Group.  If a "Person Preferred Address Merge Action" is entered on the B2CG form for a Group, then that action and the optional rule entered will be used.  If the "Person Preferred Address Merge Action" field is blank on the B2CG form, then the action and rule on the Ben to CA Conv Merge Defaults (BCPM) form will be used.

-The B2A Manage Groups (B2MG) process will not allow you to create Groups if the Person Demographic L1 conversion has already been divided into Splits with the B2MS process.  Additionally, the process cannot be rerun if any of the existing Groups have a "Complete" status.

- The Ben to CA Conversion Manager (B2CM) process has been updated to accommodate the conversions being divided into multiple batches.  When a conversion with Groups or Splits has all of its batches completed, the parent conversion will also be updated to "Complete."

- The BEN2CA Conversion Front-End (BCFE) form has been updated to work with Split conversions.

- The following fields have been added to the BENCA.CONV.LOG file:

--BCALOG.SPLITS

--BCALOG.SPLIT.PARENT

--BCALOG.GROUP.ADDR.MERGE

--BCALOG.GROUP.ADDR.RULE

- The Degrees N9 conversion has been updated so that an INSTITUTIONS.ATTEND record will be created even when there is no degree data to convert.

- The B2A.MACH.CTL P1 conversion has been updated to populate the maximum match amount.  Additionally, the maximum match amount allowed in the INTER.MATCH.POLICY file has been updated to 999,999,999.

Client Impact.............:

CLIENT IMPACT

Upon implementing this software update, you will be able to more easily and accurately convert data into Colleague.

IMPLEMENTATION INSTRUCTIONS

Not applicable.

TECHNICAL IMPLEMENTATION

Not applicable.

NEW FORMS

B2A Manage Splits (B2MS)

CUSTOM IMPACT

Not applicable.

SOFTWARE PARTNER

Not applicable.

Description...............:

UPDATE 4/4/2008

****************************************

SU37161.33-1805*02 is available

****************************************

This software update delivers several enhancements for the Advancement conversion programs including the B2A Manage Splits (B2MS) process.

This software update also resolves the following change requests:

10441.44

The following forms have been modified to use a multiline editor:

--ELF Field Mapping (ELFM)

--Source to Target Map (ELFS)

--ELF Target File (TGTF)

28405.37

The Inter-to-Colleague Import (ITCI) process's report has been modified to indicate the mode in which the process was run. 

Change Request............: 37356.93

Summary...................: ST-IPEDS Regulatory Updates 2008

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/17/2008

Impact....................: Medium

Priority..................: C

Project...................:

Main Release ID...........:

Application...............: STFED

Module Name...............: STFED

Mnemonic..................:

Problem/Issue.............:

Clients reported a number of issues with IPEDS reporting.  See the Description section for more information about the issues resolved with this software update.

Resolution................:

This software update resolves a number of issues with IPEDS reporting.  See the Description section for more information about the issues resolved with this software update.

Client Impact.............:

The IPEDS reports are now more accurate and up-to-date for regulatory changes. The performance for the IPEDS Fall Enrollment Survey Report (IFES) has been improved.

Description...............:

04/17/08 UPDATE: The following software update has been released and is available for Clients

***********************************

SU 37356.93-1805*07

***********************************

This is an IPEDS (Integrated Post Secondary Education Data System) regulatory update.

The following change requests are resolved with this update: 

13882.07: The Courses (CRSE) form was not allowing 000000 as a CIP (Classification of Instructional Programs) code for specific institutions. On the CIP Definition (CIPD) form, the code 000000 is allowed to be entered as a CIP code. Because it is allowed on the CIPD form, it must also be allowed to be used on the CRSE form.  The CRSE form is now able to use the CIP code 000000 or any other code in the National ID field on the CIPD form. If that field is left blank, Colleague uses the CIP code for the selected academic department by default.

34099.59: When calculating students for the IPEDS Fall Enrollment survey, the reports included students who were auditing all of their classes and excluded students who took all pass/fail classes.  A change was made in the batch process code that is called by the IPEDS Fall Enrollment Survey Report (IFES). The change was made to include students who took all pass/fail classes and exclude students who took all audited classes.

30432.89: IPEDS student loads were not correct. The subroutine S.DETERMINE.IPEDS.STU.LOAD was not calculating student loads correctly for IPEDS reporting. The subroutine S.DETERMINE.IPEDS.STU.LOAD was updated so that the correct student load is determined.

28619.59: Part G of the IPEDS Fall Enrollment Survey (IFES) process, which calculates retention rates, included graduates in the report.  The batch process STB059, called by the IFES process, was changed to exclude graduate students in retention rate calculations. This allows for retention rates to be accurate and include only undergraduate students.

28458.07: When calculating IPEDS Fall Enrollment Survey part G, retention rates calculated full-time and part-time students incorrectly when calculating students for the summer semester.  The batch process STB059 called by the IFES process was changed to make sure that if a student was full-time for any semester, that student was considered full-time for the report.

24720.44: A new regulatory update for the IPEDS Characteristic Survey is to include the average months it takes to complete a specific academic program.  The IPEDS Inst Chars Survey 1 (ICH1) process was updated to include the average number of months to complete a specific academic program. This was done by adding a new column for part D of the report.

Change Request............: 37453.52

Summary...................: FA Computed Columns: Generator Support

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/11/2008

Impact....................: High

Priority..................: A

Project...................:

Main Release ID...........:

Application...............: FA

Module Name...............: FA

Mnemonic..................:

Regulatory Enhancements...: Yes

Problem/Issue.............:

Computed columns and IS-type subroutines from file suite files with multipart keys that also use non-key data elements from the same file, and that are used by Datatel-delivered processes, require a special release to resolve the computed column generator issue described in AnswerNet change request 37694.56.

Resolution................:

Computed columns and IS-type subroutines from file suite files with multipart keys that are used by Datatel-delivered processes are delivered in this release.

Client Impact.............:

Datatel-delivered Financial Aid computed columns in file suite files affected by the computed column generator issue reported in AnswerNet activity 37694.56 will continue to function.

Description...............:

4/11/08 - The following update is available:

***************************************************

SU37453.52-1805*03

***************************************************

This software release delivers updates for computed columns and IS-type subroutines used in Datatel-delivered Financial Aid processes that are affected by AnswerNet change request 37694.56 (Cannot read data from a file suite file that has a multi-part key). This update does NOT include the revised computed column generator.

After this update has been installed, regenerating the delivered computed columns at client sites where the database is Oracle or Microsoft SQL Server (using C#) will break them. Special instructions for Microsoft SQL Server 2000 or Microsoft SQL Server 2005 clients using T.SQL are included in the Technical Implementation instructions.

The following change request is also resolved by delivery of the updated computed columns in this release:

36917.33 - R18: LAPX not selecting students when flagged ready to send The computed columns that are being used by the Electronic Loan App Export (LAPX) process are SL.LA.READY.TO.SEND and SL.LA.ELECTRONIC.APP.FLAG. This release resolves that issue for C# or Oracle databases. These computed columns were released on software update 36957.37 for UniData and T.SQL database clients.

38543.78 - FA:LAPX Unrecoverable Error

Clients were receiving the error "In ST.OBJ/_S.FA.GET.EL.SORT.KEY at line 190 Error, SUBROUTINE 'S.FA.GET.EL.SORT.KEY' has different number of arguments than its CALL statement." All instances of calls to the subroutine S.FA.GET.EL.SORT.KEY by the Electronic Loan App Export (LAPX) process have been modified to use the new year argument.  

Modified computed columns are listed by file below.

SL.ACYR

-   SL.EL.SORT.KEY 

-   SL.LA.ELECTRONIC.APP.FLAG 

-   SL.LA.LOAN.TYPE.CODE 

-   SL.LA.READY.TO.SEND 

-   SL.OFFICE 

TA.ACYR

-   TA.OFFICE  

The following IS-type subroutines have been regenerated with the modified computed column generator for this update.

- S.FA.GET.EL.SORT.KEY

- S.FA.GET.OFFICE

TECHNICAL IMPLEMENTATION

Computed columns in file suite files with multipart keys that also use non-key data elements from the same file cannot be regenerated at the client site and continue to function. If a computed column from this release becomes corrupted, you must retrieve the code from your LPR.

Clients will be able to successfully generate computed columns for file suite files with multipart keys only after AnswerNet change request 37694.56 is resolved.

Changes to the computed column generators for Microsoft SQL Server 2005 using C# mean that the corresponding Envision code is not correctly interpreted for file suite file computed columns using TRANS statements. Because of that misinterpretation, the DAS does not populate the pointers in the STRATEGIES records for affected file suite files. Clients using the Microsoft SQL Server 2000 database, or Microsoft SQL Server 2005 using T.SQL, must perform the following steps after this update has been installed in order to correctly populate the STRATEGIES record pointers.

These instructions apply to the following delivered computed columns:

-     SL.LA.ELECTRONIC.APP.FLAG 

-     SL.LA.LOAN.TYPE.CODE

-     SL.LA.READY.TO.SEND

-     SL.OFFICE

1.    In the Envision ToolKit for the ST application, for each computed column, go to the Edit Record (EDRC) form. Use ST.CDD as the file name, and the computed column name as the record name.

2.    On line 45 in the ST.CDD record, you will see code that looks like this (SL.LA.LOAN.TYPE.CODE IS USED for this example):

TRANS("LA.":"YR.ACYR",SL.APP.SEQ.NO,"LA.LOAN.TYPE.CODE","X")

3.    Replace the string <":"YR.ACYR> (without the angle brackets) with <ACYR"> (also without the angle brackets).  The new code should look like this;

TRANS("LA.ACYR",SL.APP.SEQ.NO,"LA.LOAN.TYPE.CODE","X")

4.    Save out of the EDRC form.

5.    DO NOT regenerate the element.

6.    Repeat for each element listed above.

7.    Leave the EDRC form.

8.    Clear the STRATEGIES record for each year that you have SL.ACYR records. This can be done at the colon prompt or through Management Studio.

===========

MPP 4/16/08

===========

A SQL query you can use to find these STRATEGIES records to be removed:

SELECT STRATEGIES_ID, STRATEGIES_RCD

FROM STRATEGIES

WHERE STRATEGIES_ID LIKE 'SL%'

AND LEFT(CAST(STRATEGIES_RCD as varchar), 2)  = 'FS'

9.    At the colon prompt for your environment, use the CLOSEALL command to clear the DAS cache. This will force Envision to rebuild the STRATEGIES records with the correct pointers for these computed columns.

NOTE: Regenerating these computed columns at any time will replace the computed column code you have corrected and remove the STRATEGIES pointers. You must repeat this process for each computed column in the list that you have regenerated.

CUSTOM IMPACT

Computed columns in file suite files with multipart keys that also use non-key data elements from the same file cannot be regenerated at the client site and continue to function. You will be able to successfully generate computed columns for file suite files with multipart keys only after AnswerNet change request 37694.56 is resolved.

Change Request............: 37705.81

Summary...................: Colleague Advancement Update

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/25/2008

Impact....................:

Priority..................: D

Project...................:

Main Release ID...........:

Application...............: CA

Module Name...............:

Mnemonic..................:

Problem/Issue.............:

Several issues and enhancement opportunities were discovered by Datatel and clients for Colleague Advancement. See the Description section for more information about the issues resolved with this software update.

Resolution................:

This software update resolves a number of issues and provides many enhancements for Colleague Advancement, including those described below.

-The Contribution Adjustment (CADJ) form no longer creates match expectancy records when it should not.  The subroutine S.EVALUATE.MATCHES has been modified to look at all existing CONTRIB.MATCH records before recalculating the matching information.  If any of them are (C)ollected, then the evaluation no longer occurs and it is assumed that all new matching information must be entered manually for this contribution.

-The newly delivered field in CONTRIBUTION, called CONTRIB.LEGACY.BATCH.ID, stores the ID for the session or batch in which a group of contributions were entered into the system.

-The Organization Profile (OGPR) report now displays the correct matching ratio for each employment type.

-If a donor makes an individual contribution, the system calculates a match expectancy if the donor's spouse is employed for a company that matches.

-The Delete Campaign (DLPR) process continues to function if you specify a campaign that does not exist in the system. 

-The Rebuild Donor Recog Levels (RDLU) now allows recognition programs that are past their end date to be rebuilt.  The process also now requires that at least one recognition program must be specified.

- The donor ID is now properly recorded on match expectancies. 

-This software update delivers the post-install subroutine, S_POST_33705_81_RS, which does the following:

--Removes CONSTITUENT.PREMIUM records that have no contribution, membership, recognition level, or award date.  These records were created without links through an error on the Constituent Premiums (CNPR) form, which was fixed on a previous software update. 

--Rebuilds the lost data for match expectancies and attempts to find the original expected amount on the CONTRIB.MATCH.DESIG record.  The program also fills in comments on the CONTRIB.MATCH record in the field CONMAT.COMMENTS, stating that the post-install updated these fields.

--Reads in the RT.FILES record and removes CAD.RECEIPT.NO.TYPES and CAD.RECEIPT.NO.TYPE.RULES from the list of fields in the CONTRIBUTION file because they exist in the CA.DEFAULTS file.  It also removes CONTRIB.SPECIAL.HANDLING because it is an obsolete field.

Client Impact.............:

CLIENT IMPACT

Upon implementing this software update, you will be able to manage contributions and matching gifts more efficiently. 

IMPLEMENTATION INSTRUCTIONS

Not applicable.

TECHNICAL IMPLEMENTATION

Not applicable.

NEW FORMS

Not applicable.

CUSTOM IMPACT

Not applicable.

SOFTWARE PARTNER

Not applicable.

Description...............:

Update 4/25/08

****************************************

SU37705.81-1805*07 is available

****************************************

This software update delivers many miscellaneous improvements to Colleague Advancement.  This update also delivers an automated post-install subroutine to correct erroneous data conditions.

This software update resolves the following change requests:

25426.96

The Group Pledge Write-Off Report (GPWR) lists the pledges in alphabetical order by donor name.  If one donor has multiple pledges included on the report, these pledges are additionally listed in date order.

29961.74

The contribution receipt number has been added to the Contribution Verification (CVRP) report.  It was not added to the Advancement GL Post Register (AGLR) report due to space constraints.

33205.41

The Inactive Pledge Report (NAPR) now displays the specified date range in the header.

33246.26

The CVRP report maintains the user-specified sort criteria regardless of how many times you access the contribution session prior to reconciliation.

33521.63

The contribution session ID has been added to the Bank Deposit Report (CDEP).

34374.59

The CVRP report no longer returns an error when you specify a date range and then attempt to specify a Session ID.

35424.11

When entering any contribution with a giving group, the system now maintains the giving group if all donors on the contribution are the same as the members of the giving group.  Previously, if the giving group's contribution needed to be allocated to multiple designations or campaigns, the system would remove the giving group ID from the contribution.

36348.41

The Person Advancement Inquiry (PAVI) and Major Donor Summary (MDSM) forms now allow you to access the Person Activity Inquiry (PACI) form only if the Activities and Events module has been licensed.

36895.37

The PAVI form now displays an "X" in the Academic field if the specified constituent has any academic programs defined in the STUDENT.PROGRAMS file.

36983.26

When detailing from the PAVI form to the Recognition Level Maintenance (RLM) and the Recog Program Member Detail (RPMD) forms, the recognition level descriptions now show the correct level description instead of the level code.

37695.26

The Enter Credit Card Information web form now calls the S.BUILD.CRCARD.YEARS subroutine and rebuilds the CRCARD.YEARS table before the table is used in validation of the contribution being entered online.  This ensures that the payment can be properly processed through the e-commerce provider.

37744.96

The PAVI form no longer calls the Giving Summary (GPGI) form and its subforms in inquiry mode.  They are already considered inquiry forms.  This allows the user to use these forms dynamically, changing the specified data on the fly.

37909.22

The Campaign Group by Solicitor (CGSO) and the Campaign Group by Prospect (CGPR) forms now detail directly to the Campaign Group Results (CMGR) form, returning the results for a single campaign group.

37915.67

When managing a contribution's donor allocation on the Contribution Donor Summary (CDNS) form, you may now delete an allocation and have the CONTRIB.DONOR.DESIG record successfully removed from the contribution being recorded.

38127.74

When recording a new pledge or a pledge payment, if you change the contribution amount, both the hard and soft credit allocations are now recalculated as they are on the Gift Entry (GFE) form.

Change Request............: 37727.59

Summary...................: Colleague Self-Employment and Unknown Employer Enhancements

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/7/2008

Impact....................:

Priority..................: B

Project...................:

Main Release ID...........:

Application...............: CORE

Module Name...............:

Mnemonic..................:

Problem/Issue.............:

Several issues and enhancement opportunities were discovered by Datatel and clients for converting employment information from Benefactor into Colleague. See the Description section for more information about the issues resolved with this software update.

Resolution................:

This software update resolves a number of issues and provides many enhancements for Colleague.  See the Description section for more information about the issues resolved, and the enhancements added, by this software update.

Client Impact.............:

CLIENT IMPACT

Upon implementing this software update, you will be able to more easily and accurately convert employment data from Benefactor to Colleague.

IMPLEMENTATION INSTRUCTIONS

The method for creating self employment has changed.  The self-employment section on the Employment Summary (EMPL) form has been removed.  To create a record of self-employment or unknown employment, detail from a blank line in the employment table and enter S for Self Employed or U for Unknown Employment at the LookUp prompt.  Users can also enter Self or Unknown employment on the Person Relations (PREL) form.

TECHNICAL IMPLEMENTATION

Not applicable.

NEW FORMS

Self/Unknown Employment (EMPS)

CUSTOM IMPACT

Not applicable.

SOFTWARE PARTNER

Not applicable.

Description...............:

4/7/08 Update) The following software update is available.

***************************

SU37727.59-1805*05

***************************

This software update delivers several enhancements to Colleague Core for maintaining employment information in Colleague.  This includes recording an individual's self-employment information and employment information when the employer is unknown.   It also delivers the corresponding enhancements to the ELF conversions.

This software update also resolves the following change requests:

14968.15

The Person Relations (PREL) form now displays the person status for each person related to the specified individual.

30501.59

Detailing to the Employment Detail (EMPD) form from the Employment Summary (EMPL) form no longer returns an error that HELP is not available.  The HELP has been delivered.

37187.48, 38493.89 and 38492.63

In order to properly record self-employment and to allow users to record employment information even when the employer is unknown, the following changes have been made:

-Two new fields have been added to the EMPLOYMT file.  They are EMP.SELF.EMPLOYED.FLAG and EMP.UNKNOWN.EMPLOYER.FLAG.  

-The EMPL form now allows you to enter an organization name, "S" for self-employed, or "U" for unknown employer when recording a new employment record for an individual.  When the "S" or "U" is specified, you record the employment information on the newly delivered Self/Unknown Employment (EMPS) form.

-The EMPL form has been reorganized so that all employment records are displayed together.

-The EMPD form now allows multiple employment records with no employer for a person, and updates the appropriate flags for Self and Unknown employment.

-The automated Post Install S_POST_37727_59_RS process will flag all existing EMPLOYMT records with no EMP.EMPLOYER as Self-Employed and populate the new EMP.SELF.EMPLOYED.FLAG field to "Y."

37188.63

The Person Relations (PREL) form has been reorganized to display more relations.

Detail buttons to the Self/Unknown Employment (EMPS) form have been added for Self Employment and for Unknown Employment.  An "X" is displayed if there is Self-Employment or Unknown Employment information.

37191.04

Organization names are now displayed in mixed case on the Person Relations (PREL) form.

37193.33

-The Self Employed flag in the B2A Employment conversion was changed from a Y/N flag to allow an "S" for Self-Employed and "U" for Unknown Employment.  The flag is populated by the Demographic Pre-processor (BCDM) process in Benefactor.  The B2A.EMPLOYMT conversion passes the flag from the source file BENCA.EMPLOYMT to the INTER.EMPLOYMENT file.

-The INTER.EMPLOYMENT conversion was changed to populate the correct flag in the EMPLOYMT file.  If there is an "S" in the IEMP.SELF.EMPLOYED field, the EMP.SELF.EMPLOYED.FLAG field is populated with "Y".  Otherwise, it is null.  If there is a "U" in the IEMP.SELF.EMPLOYED field, the EMP.UNKNOWN.EMPLOYER.FLAG field is populated with "Y".  Otherwise, it is null. 

37631.89

The ELF specifications that import addresses have had the following errors corrected:

-When excluding addresses of type WEB as duplicates for merging, the code was determining a WEB address type incorrectly. It now identifies WEB type addresses by the value of "3" in the first Special Processing column in the ADREL.TYPES validation code table.

-When address householding is enabled, ELF would identify an existing address that had only former residents as a possible duplicate. Now, only addresses with active or pending residents will be identified as a possible duplicate. However, addresses with only former residents will be identified as a possible duplicate if the imported person is one of the former residents. 

-When the import person ID was not known, ELF would report address duplicates that may not be valid after the import person ID is identified.  Now, ELF will only report address duplicates it can be sure are valid when the person ID is unknown as a result of a person duplicate ambiguity or the import being run in test mode.  Then it may report more address duplicates after the person ID is known.

-When importing employment and organization contact addresses through INTER.EMPLOYMENT and INTER.ORG.CONTACT, ELF was not considering organization addresses belonging to the organization for merging.  The ELF specifications now process the addresses in relation to the organization.

38049.41

The field help for the PERSON.USER2 field is now blank.

Additionally, the following internally identified enhancement has been made:

- The IEMP.BATCH field has been increased to an internal size of 20.  This prevents Active Admission batches from resulting in an error.

Change Request............: 38010.75

Summary...................: Colleague Advancement Conversion Update

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/25/2008

Impact....................:

Priority..................: B

Project...................:

Main Release ID...........:

Application...............: CA

Module Name...............:

Mnemonic..................:

Problem/Issue.............:

38541.67

After converting records from Benefactor to Colleague, it was found that some addresses that had been home and former home addresses in Benefactor were marked as business and former business addresses in Colleague.

38544.56

Contact information was associated with the wrong individual or organization during the conversion.

Resolution................:

38541.67

The conversion program has been updated to differentiate between a corporate address and a non-corporate address, allowing home addresses to properly convert.

38544.56

The conversion now puts the contact record pointer in the correct field, allowing you to see the specified individual or organization's correct set of contacts.

This software update also delivers the following enhancements:

-The contribution conversions no longer require that a solicitor have a record in the STAFF file in Colleague.

-The contribution conversions now maintain the contribution batch ID from the legacy system, which will only be used for historical reporting purposes in Colleague.

-The contribution conversions now allow multiple Next of Kin to convert successfully into Colleague.

- An unitialized variable error on the Degrees (N9) conversion has been identified and resolved.  The conversion will no longer assign the first person evaluated to the second person's degree record.

Client Impact.............:

CLIENT IMPACT

Upon implementing this software update, you will be able to more easily and accurately convert data into Colleague.

IMPLEMENTATION INSTRUCTIONS

Not applicable.

TECHNICAL IMPLEMENTATION

Not applicable.

NEW FORMS

Not applicable.

CUSTOM IMPACT

Not applicable.

SOFTWARE PARTNER

Not applicable.

Description...............:

Update 4/25/08

*****************************************

SU38010.75-1805*05 is available

*****************************************

This software update delivers several enhancements for the Advancement conversion programs, and resolves two change requests.

Change Request............: 38025.93

Summary...................: GLOM and GLA.GL.NO maintenance

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/11/2008

Impact....................:

Priority..................: B

Project...................:

Main Release ID...........:

Application...............: CF

Module Name...............: GL

Mnemonic..................:

Problem/Issue.............:

After clients used the GL Budget Officer Maintenance (GLOM) form, budget officers could no longer be found by the Budget Officer Maintenance (BOFM), Responsibility Worksheet Line (RWLI), or Officer Worksheet Line Items (OWLI) forms.

Institutions that have GL account numbers that are longer than 15 characters in length, and use underscores as delimiters in those GL numbers, received incorrect results when using the Verify Pool Postings Entries (VPPE), AR-CR Posting Analysis (ARPN), and AR-CR Posting Exceptions (ARPX) processes because GL numbers were not selected correctly. They also received incorrect results from the GLA.POOL.ACCOUNT computed column.

Resolution................:

The GL Budget Officer Maintenance (GLOM) form was updated to correctly update budget officer information.

The Verify Pool Postings Entries (VPPE), AR-CR Posting Analysis (ARPN), and AR-CR Posting Exceptions (ARPX) processes, and the GLA.POOL.ACCOUNT computed column, now use a different method of selecting GL account numbers so that they are not affected by the format of the account numbers. Technical: The affected components now use the GL.NO computed column rather than the GLA.GL.NO computed column.

Client Impact.............:

Clients can now successfully use the following:

- The Budget Officer Maintenance (BOFM) form.

- The Responsibility Worksheet Line (RWLI) form.

- The Officer Worksheet Line Items (OWLI) form.

- The Verify Pool Postings Entries (VPPE) process.

- The AR-CR Posting Analysis (ARPN) process.

- The AR-CR Posting Exceptions (ARPX) process.

- The GLA.POOL.ACCOUNT computed column.

IMPLEMENTATION INSTRUCTIONS

Not applicable.

TECHNICAL IMPLEMENTATION

Not applicable.

NEW FORMS

Not applicable.

CUSTOM IMPACT

Not applicable.

SOFTWARE PARTNER

Not applicable.

Description...............:

04/11/08 - The following software update has been released and is available to clients:

**************************

SU38025.93-1805*04

**************************

This software update resolves the AnswerNet change requests described below.

37723.63

GLOM:  Corrupts BUD.OFCR record of (W)orking budget

After a budget had been generated by using the Generate a Budget (BCGB) process, when the user accessed the GL Budget Officer Maintenance (GLOM) form, the BUD.OFCR record association for ledgers, people IDs, login, and budget was corrupted.   Then, when the user accessed the Budget Officer Maintenance (BOFM), Responsibility Worksheet Line (RWLI), or Officer Worksheet Line Items (OWLI) forms, the budget officer associated with the budget could not be found.

The GLOM process has been modified to correctly update the data in the BUD.OFCR association so that the correct information is displayed on the BOFM, RWLI, and OWLI forms.

37312.26

GLA.GL.NO converting underscores to null when selecting GL numbers

Several processes used the computed column GLA.GL.NO to select GLA.fyr records.  GLA.GL.NO had been modified in a previous software update to convert underscores to nulls in GL numbers greater that 15 characters in length.   This change caused the Verify Pool Postings Entries (VPPE) process to not update correctly because GL numbers were not selected correctly. This change also caused the AR-CR Posting Analysis (ARPN) and AR-CR Posting Exceptions (ARPX) processes in AR to not update correctly.

The GLA.GL.NO computed column has been replaced by GL.NO in cases when the literal value of the GL number was being sought.  The VPPE process in Pooled Investments, and the ARPN and ARPX processes in Accounts Receivable have been modified to select the appropriate GLA.fyr records. Also, the GLA.POOL.ACCOUNT computed column has been modified so that it retrieves the correct GL number from the GLS.fyr record.

In addition to the above changes, error messages were clarified on GLA Transaction  Inquiry (GLAI) form when the user attempted to detail on an activity that did not have a financial detail form.   Previously the message was 'Detail Information not available'.  Now the message is  'Detail information is not available for this type of transaction'.   GLAI is accessed from GL Account balance Inquiry (ACBL).

top

Change Request............: 38068.05

Summary...................: Retention Alert Update

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/18/2008

Impact....................:

Priority..................: A

Project...................:

Main Release ID...........:

Application...............: ST

Module Name...............:

Mnemonic..................:

Problem/Issue.............:

Menu items specific to Retention Alert were being displayed on client systems whether Retention Alert was licensed or not. 

The Student Search Results web form incorrectly suppressed multiple academic programs that were within the same catalog year. 

Resolution................:

Retention Alert menu items are now displayed only for institutions that have licensed Retention Alert.

The Student Search Results web form now shows multiple programs within the same catalog year.

Client Impact.............:

The user experience with WebAdvisor menus and with the Student Search Results page is improved.

Description...............:

04/18/08  - The following software update has been released and is available to Clients:

*********************************

SU38068.05-1805*02

*********************************

This software update delivers two changes to the Retention Alert module.

Change Request............: 38115.95

Summary...................: 38115.95 WA3 Updated support for Back button on WFMS web forms

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/21/2008

Impact....................: High

Priority..................: B

Project...................:

Main Release ID...........:

Application...............: UT

Module Name...............: UT

Mnemonic..................:

Problem/Issue.............:

When using a WfMS workflow in WebAdvisor, it was possible for sensitive information to be exposed when people used the Back button.

Technical:

The Allow Workflow to be Reset flag on the Workflow Parameter Definition (WFPD) was overriding the setting for Redisplay Behavior on the Form Interface parameters (UIP) and Screen Interface Parameters (SIP) form. For UI users, the only way to reset a WfMS step is for the System Administrator to reset the step, and only if the Allow Workflow to be Reset flag is "Yes".  WebAdvisor users, however, have the intrinsic ability to reset a step by using the BACK button.  Forms that contain sensitive data, like credit card information, should have their data set to expire (Redisplay Behavior is "X").  When this kind of form is part of a WfMS workflow, however, the Reset flag was preventing the data from expiring.  

Resolution................:

Because each step of a WfMS workflow in WebAdvisor can be "reset" individually, the system now uses the Redisplay Behavior flag if that has been defined. Otherwise, the system defaults to the Reset flag.

Client Impact.............:

CLIENT IMPACT

WebAdvisor is more secure because sensitive data can be expired on a form-by-form basis..

IMPLEMENTATION INSTRUCTIONS

Not applicable.

TECHNICAL IMPLEMENTATION

Not applicable.

NEW FORMS

Not applicable.

CUSTOM IMPACT

Not applicable.

SOFTWARE PARTNER

 Not applicable.

Description...............:

04/21/08 -  The following software update has been released and is available to clients:

***************************

SU38115.95-485*02

***************************

This software update resolves the following issue:

33866.63 - WA3: Backable flag not honored with WFMS

The Redisplay Behavior flag on the Form Interface Parameters (UIP) form in Envision Runtime (UT) and the Screen Interface Parameters (SIP) form in the Envision Tool Kit (TOOL) was not being honored in Workflow Management Solution (WfMS) workflows. This does not behave like normal web form functionality that prevents data from being displayed again, such as credit card information. The issue appears to be within the WebAdvisor screen processing code, but is isolated to WfMS.

Change Request............: 38576.48

Summary...................: Remove toggling of UDT.OPTIONS 85 from UT sort routines

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/10/2008

Impact....................:

Priority..................: C

Project...................:

Main Release ID...........:

Application...............: UT

Module Name...............: UT

Mnemonic..................:

Pre Install Instructions..:

You should install 37327.89 at the same time as this update

Problem/Issue.............:

Some processes could function incorrectly when doing a "LOCATE ...BY..." statement against a list that was sorted by using a call to a UT sort routine.   The exact symptoms would depend on how the process was coded to handle a failed LOCATE.

Resolution................:

Although Datatel has not identified any affected routines (and in fact, it's possible that there may not be any), we have proactively made the following changes:

1) Modified Colleague's initialization routines so that UDT.OPTIONS 85 is left in its default (OFF) setting.

2) Modified the UT sort routines so that they do not in any way change the UDT.OPTIONS 85 setting.

Client Impact.............:

1) The following seemingly impossible sequence of events will no longer occur:

- Process adds item X to a list.

- Process calls a routine to sort the list.

- Process use a LOCATE statement to determine the location of item X in the list.

- The LOCATE statement can't find item X.

2) Some numeric sorts may not succeed (for example, when combining positive and negative numbers).  See change request 32149.56 for details.

Description...............:

04/10/08 Update)  The following software update is now available for downloading:

**************************************************

SU38576.48-485*01

**************************************************

SU37327.89-485*05,  released in spring of 2008,  modified UT sort routines so that they would run left justified sorts (AL, DL) with UDT.OPTIONS 85 turned off, and right justified sorts (AR, DR) with the option turned on.

This could present a problem if  an application process calls a UT sort routine to sort a list, then subsequently does a "LOCATE ... BY..." statement to identify the position of a given item within that list.

If the UDT.OPTIONS 85 setting for the session was off, and the UT sort routine did  a right-justified sort,  or the session setting was on, and it did a left-justified sort, then, depending on the nature of the items in the list, it is possible that the LOCATE could fail to find the item in the list, even when it's actually present.

To prevent this, the UT sort routines need to be modified so that they don't change the UDT.OPTIONS 85 setting.

It is important to understand the history behind this change request, and the tradeoffs involved.    This change request is a conscious choice between two imperfect options.

   Change made in Spring  2007:

Datatel identified a problem with UniData's LOCATE statement.  It turned out that in some cases (fortunately not common in Colleague), right-justified sorts would fail.  This issue was described in change request 32149.56.     We discovered that by turning on UDT.OPTIONS 85, these problems could be solved.    Thus 32149.56 was implemented by modifying Colleague's initialization routine (SQLENVINIT) so that it turned the option on when a user logged into an account.

   Change made in Spring 2008:

Late in 2007 we discovered that this was an imperfect solution.  It turns out that, although turning option 85 on fixed some right-justified sorts, it broke some left-justified sorts.   We informed IBM of this and are working with them on a long-term solution.    In the meantime we attempted to mitigate the problem by changing the routines that do the bulk of all sorting in Colleague.   We believed that having those routines toggle option 85 on or off, depending on whether they were doing a left or right justified sort, would effectively work around the problem until IBM could give us a better solution.  The change that added option 85 toggling to the UT sort routines was released in March 2008 with change request 37327.89.

   Discoveries made late March 2008:

Since the release of 37327.89, we have discovered that, if a list is sorted with option 85 set one way, and a process subsequently should use  the "LOCATE...BY..." syntax on that list, attempting to identify the storage position of a particular item known to be in that list, and the current option 85 setting does not match what it was when the list was sorted, then depending on the attributes of the data in the list, the LOCATE could fail when it should have succeeded.

Although Datatel has not yet identified any process that would be affected by this, in reviewing all the evidence, we have decided that, until IBM addresses the problems, the best option is to

a) leave the session setting for option 85 off

b) remove the option 85 toggling feature from the sort routines.

For a detailed listing of what works and what doesn't (that is, which combination of data attributes and UDT.OPTION 85 settings work, and which do not), log in to AnswerNet and view the PDF document attached to this change request.

Change Request............: 38792.37

Summary...................: Colleague R18 HR to Ben 5.1 Payroll Deduction Interface Update

Criticality...............: Release

Status....................: Complete

Date Completed............: 4/24/2008

Impact....................: High

Priority..................: A

Project...................:

Main Release ID...........:

Application...............: HR

Module Name...............:

Mnemonic..................: BFPD

Problem/Issue.............:

Clients reported the following problems with the HR to Benefactor Payroll Deduction Interface:

When using the Benefactor Deduction Setup (BFDS) form, clients could not enter a valid Benefactor Pay Mode on deduction codes. (38696.26)

When entering a Benefactor Pledge ID on the Person's Benefactor Calc Cost (PBCC) form, the PBCC form did not properly validate the pledge as active or inactive, and did not display all of the information about the pledge.  (38696.26)

The Benefactor Payroll Deduction (BFPD) process did not correctly build complete pledge payment TX records in the Benefactor database.  The TX records did not include the donor ID numbers, credit types, and credit amounts.

Resolution................:

The Benefactor Deduction Setup (BFDS) form allows you to use the drop-down box to view valid Benefactor payment modes, and you can enter a valid Benefactor Pay Mode on any deduction code.

Entering a Benefactor Pledge ID on the Person's Benefactor Calc Cost (PBCC) form properly validates the pledge as active or inactive, and displays the pledge's donor information, designation, area of giving, campaign, and UTP code.  In addition, you are able to view valid Benefactor UTP codes using the drop-down box beside the code.

The Benefactor Payroll Deduction (BFPD) process now correctly builds complete pledge payment TX records in the Benefactor database.  The TX records include the donor ID numbers, credit types, and credit amounts.

This software update delivers the post install utility S_POST_38792_37_RS which deletes the VOC entry for S.GET.HR.TXBATCH.ID and properly catalogs this subroutine.  After loading this software update, the VOC entry for S.GET.HR.TXBATCH.ID will be listed as a catalog verb (C) instead of a sentence (SE).

Client Impact.............:

CLIENT IMPACT

Updates to the HR to Benefactor Payroll Deduction Interface enable you to set up and process  payroll deductions to Benefactor as payments on open pledges.

IMPLEMENTATION INSTRUCTIONS

Not Applicable.

TECHNICAL IMPLEMENTATION

Not Applicable.

CUSTOM IMPACT

Not Applicable.

SOFTWARE PARTNER

Not Applicable.

Description...............:

Colleague

HR

Update 4/24/08

*******************************************

SU38792.37-1805*04 is available

*******************************************

This software update resolves problems  in the HR to Benefactor Payroll Deduction Interface as a result of the encryption changes made to the Colleague/Benefactor Interface March 25, 2008 on updates 36755.74 and 36756.37.