Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
1
This is the SICAS Student 8.5S1 release.
This upgrade requires a minimum of Oracle Database Release 10.2.0.3 with patch 5874989 (patch 6812783 for Windows
32 bit environments) or 10.2.0.4.
This release is dependent on the following releases:
Student 8.3S1
Finaid 8.10S1
General 8.4S1
This release is dependent on the following patches:
8S7248
8S7215
8S7007
8S6644
8S6598
SICAS Release Highlights:
As of this release, the Study Abroad field has been removed from the General Student SGASTDN form. The Study
Abroad field was moved to the Student Course Registration Form SFAREGS at Banner 8 and is available in the
Enrollment Block of that form.
Problem Resolutions:
RF#
5679
6162
Campus
SICAS Center
SICAS Center
Reported
Release
8.1S2
8.1S2
6239
SICAS Center
8.1S1
6243
Oswego
8
6247
Jefferson CC
7.5S2
6276
6286
6292
6347
6366
6422
6425
Fredonia
Geneseo
Corning CC
SICAS Center
SICAS Center
SICAS Center
SICAS Center
7.5S1
8.3S1
8.3s1
8.0S1.1
7.5S2
6433
SICAS Center
8/7
Object(s)
SFKYFEES.SQL
Title
SWAP feature not performing correctly
ASC Decision application needs better way of
determining ASC applications
ISPRYSFN,ISTVYVTL,S SIRIS Former Name sends names never sent by
FKYCVI1,SFKYCVIR,SF SIRIS
KYSI1,SFKYSID,SPRYS
FN
TSDS - Allow 1 banner bldg/room to crosswalk to
more than 1 PSI bldg/room combo
SORYALD
When delete/inactivate some fields need to be set to
zero
SORYADF
SORYADF - Output File Name
SSRYSFA
8S6225 not correct
SHRYCRN1.SQL
uniqueness error while running TSPYCCB
Updates for the ASC Application process
ISTVYVTL
Multiple SIRIS SDS
RPRYGAS.SQR
$banterm does not exist in let $newterm = $banterm
ISTVYVTL
SDS - Highest Degree sending default of 10/HS
Status is null when no HS record
SAAYASC
Banner ID is not retained
Release Notes for Student 8.5S1
_________________________________________________________________________
6446
6447
SICAS Center
SICAS Center
8.3S1
8.3S1
6462
Geneseo
8.3s1
6475
SICAS Center
8.3S1
6488
6542
6552
6562
Cayuga CC
SICAS Center
SICAS Center
SICAS Center
8.0S1.1
8.0S1
8.3S1.3
8.3S1
6570
SICAS Center
8.3S1
6596
Jefferson CC
8.3S1
6615
6633
Monroe CC
Broome CC
8.0s1.1
7.4
6638
6660
6667
6715
Corning CC
SICAS Center
SICAS Center
SICAS Center
8.3S1
8.3S1
8.7S
8.3S1.6
6785
6808
6815
6834
SICAS Center
SICAS Center
SICAS Center
SICAS Center
7/8
7/8
8
8.1S2
6859
Binghamton
8
6865
SICAS Center
8.3S1.1
April 2011
2
SSKYLAS1
Wrong Qualifier Code assigned for Email
SFKYCVTS,
Multiple SIRIS Errors
SFKYCVT1,
ISTVYVTL,GOKYWSRD,
GOKYWSR1,GPAYEXT
Soryapcp10.sqr does not run in Banner Job
submission.
IGUBOBJS
SIRIS/SDF - Some Forms/Processes not accessible
- not on GUAOBJS form
SPRYIMM
SPRYIMM 8.0S1.1 missing term in heading?
STVYASO.FMB
STVYASO.FMB was not shipped with Banner 8.
SSKYLASC
Foreign Temporary Address Stop process when null
GORYDTI, SFKYCVIR, Multiple SIRIS Fixes and SOAYDTI Enhancements
SFKYCVI1, SFKYCVTS,
SFKYCVT1, ISTVYVTL,
GOKYWSRD,
GOKYWSR1
GOKYLOA1.SQL
ASC 2011 and Common App Templates plus
GOKYLOAD.SQL
Multiple Fixes
GOKYSRE1.SQL
GOKYSREP.SQL
GOPYLOD.SQP
GOPYLOD.SQR
IGOBYTPL_6570.SQL
IGOBYTPL_COMM_657
0.SQL
IGORYTPL_6570.SQL
IGORYTPL_COMM_657
0.SQL
IGTVYTPL_6570.SQL
SARYXRF.SQR
SSKYLAS1.SQL
SSKYLASC.SQL
SFRYCAP
SFRYCAP Control Report Parameters not Printing
Correctly
SOAYWSP
Form Hangs
SFVYCRS, SFVYFRS, SFVYSRS - Course ID
problem
SFRYCFA will not run when using Student ID option.
SFVYCRS
Add INSTRUCTOR_SOURCEID to Course XEI view
2010 Changes for State Certification
SSKYLAS1.SQL,
ASC Fixes
SAAYASC.FMB
SFKYCVT1/ISTVYVTL
VISA Code2 validation codes missing
SFKYCVT1, SFKYCVTS Multiple CDS (SIRIS)
SLKYAUTO, SLKYAUT1 Correct insert to tables to use list of columns.
SFKYSID,SFKYSI1
SIRIS Former Name logic fails on Two Names sent
the same day
SSKYLAS1::SAAEAPS::I Multiple ASC Fixes
SARERUL_6859::ISORX
REF_6859
MULTIPLE
Board of Regents Adopts Emergency Definition of
Remedial
Release Notes for Student 8.5S1
_________________________________________________________________________
6941
Cayuga CC
8.0
6976
SICAS Center
8.3S1
7017
SICAS Center
7036
Monroe CC
DB New
Beta
8.0S1
7045
7059
7101
Binghamton
Buffalo State
SICAS Center
8.1S2
8.3S1
8.3S1
7131
SICAS Center
8.3S1
7143
8.3
7185
7195
7212
Fashion Institute of T
echnology
Jefferson CC
New Paltz
Farmingdale
7232
7242
7249
7299
Hudson Valley CC
Binghamton
Buffalo State
SICAS Center
8
8.0
7.7S1/8.3S
1
8.0S1.1
8.1S2
8.3S1
8.0S1
7325
SICAS Center
8.3s1
7329
7343
7376
7416
7492
7522
Jamestown CC
SICAS Center
Herkimer CC
SICAS Center
Plattsburgh
SICAS Center
8.3S1
8.3S1
8.3S1
N/A
8.3S1
8.3S
7550
SICAS Center
8.3S1
7575
Monroe CC
8.1s1
7597
7612
Fredonia
Monroe CC
8.3S1
8s7575
7659
7801
Oneonta
SICAS Center
8.10S1
8.0S1.1
April 2011
SOAYTRC
Err: FRM-40735: When-Validate-Item trigger raised
unhandled excep. ORA-0422
SAAYASC::SSKYLAS1:: Multiple ASC fixes
SSKYLASC
DB New Beta forms that won't compile
SGKYIMM, SGKYIMMS, Problem with Immunization Health Survey
SPAYHIS
SFKYFEES
Swap Fee Assessment fix removing all liability
Issues loading phone numbers
ISTVYVTL
Visa Code2 Element is selecting codes that Expired
long before the Term starts
SFKYCVIR, SFKYCVI1, SIRIS SDS Prior Colleges not found and HS Status
ISTVYVTL
sometimes NULL on HEH of 5
SORYADP
Decision process returning no students
ISTVYVTL
SABYASC
SAAEAPS::SSKYLAS1::
SSKYLASC
SORYULE
SFKYFEES
SOAYTRO, SOAYTRC
SORYDTS,
JOBSUB_SORYDTS
SARYXRF
SCRYEMG
MULTIPLE
SORYALD
SSRYSFA
GOKYWSR1,
GOKYWSRD,
IGTRYVTR, ISTVYVTL,
SFKYCVI1, SFKYCVIR,
SFKYCVT1,
SFKYCVTS, SFKYSD1,
SFKYSDS, SFKYSI1,
SFKYSID, SFKYSIR1,
SFKYSIRS, SFKYTSD1,
SFKYTSDS
SAAYASC:SAPYASC::S
APYASM
SPAYHIS, SGKYIMMS,
SGKYIMM1, ISPBYIMM
SAPYASC
SPAYHIS, SGKYIMMS,
SGKYIMM1, ISPBYIMM
STVYTTY
SZFYANGL
Oracle error on Tenure Status
Inserting new records into SAAYASC
Error while running Saretmt and SAAEAPS
Unable to locate existing rules
Refunding Error with New SICAS Swap Feature
First TAP award year in Banner
SORYDTS Term Code Validation Issues
Update new crosswalks and rules and curriculum
duplicate check
NY Alert and deceased individuals
TAP Q&A refers to Good Cause
Sicas Center Banner to Aleph Process
SIRIS Multiple Enhancements
Missing IPEDs Part A Field 02b
Multiple SIRIS fixes
ASC Fixes and Enhancements
RF#7036
Missing Entries in SABYASC
8s7575 Install Fails
STVYTTY didn't have a Primary Key
FZ_ANGEL_PW function has PL/SQL error
3
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
7806
7822
SICAS Center
Nassau CC
8
8.3S1
ISTVYVTL
Building and Room data not updating in TSDS
SFKYCVIR,SFKYCVI1,G Multiple SIRIS fixes
OKYWSRD,GOKYWSR1
7912
7930
Adirondack CC
SICAS Center
8.4
8
8045
8063
7917
Oneonta
SICAS Center
SICAS Center
8.3S1.18
8.X
8.3S1
SSKYLAS1
SOBYINS1, ISTVYVTL,
SFKYCVIR, SFKYCVI1
SSKYLAS1
MULTIPLE
4
Multiple ASC Fixes
Multiple SIRIS Fixes
Checklist items being deleted
SFAYLAB - Error Message
2011-12 NYS Budget Contains 2010 SAP Charts
RF# 5679 SWAP feature not performing correctly
Problem:
We have discovered a bug with SICAS Fee Assessment that prevents the SWAP feature from working properly.
The SICAS Fee Assessment process functions by re-reading each CRN in drop date order each time fee
assessment is run. A test is performed each time to see if SWAP is on or off based on the setting on SOATERM.
Because of this functionality, a CRN processed while SWAP was on could later be re-assessed after SWAP had
been turned off. This can cause unpredictable results and the assessed amount could change.
Response:
The SICAS resolution to this problem is to provide a form to be used by a campus to indicate the dates that
SWAP is on during a semester. This form will serve as the on/ off switch for SWAP. The SICAS Fee Assessment
process will not use the SOATERM SWAP indicator. Those using baseline fee assessment should continue to
use SOATERM to turn SWAP on and off.
The SICAS fee assessment process will look at the dates on this form to determine if SWAP was on and will
assess tuition accordingly. In the example given above, the tuition for COMP 100 will not change.
The SWAP feature does not apply to Section Fees or Assess by Course rules.
Both the SICAS and SunGard swap feature use have been problematic for a long time. A common complaint is
the 24 hour range restriction. Campuses have often requested the option to set a date range when the swap
feature was active, for example just for the first week of add/drop. Also there is no indicator in Banner that
identifies a course drop as being part of a swap so back-dating and re-assessment have caused problem.
For those campuses using the SICAS modified version of fee assessment we believe we have corrected this. This
patch will provide a new date range feature and also allow for the 24 hour constraint to be used if a campus
prefers. It also now correctly handles back dating or re-assessment even if the number of added versus dropped
credit hours change.
This is all accomplished using the new SICAS form SFAYSWX. This form must be updated each term just like
SOATERM. An very important constraint with this feature is that it will override the setting for ‘SWAP’ on the
SOATERM form!
RF# 6162 ASC Decision application needs better way of determining ASC applications
Problem:
ASC only wants to receivedecisions for applicants that were sent by ASC. Campuses are now loading applicants
from the Common App and other sources.
RF6030 attempted to resolve this by using the data_origin field = 'Banner' on the SARADAP record or the
existence of the record in the SABYASC table. This option was not good because NOLIJ software also loads the
SARADAP table with Data_origin = 'Banner'. Some campuses also use the SICAS ASC tables for storing
application information from sources other than ASC.
Response:
Add data_origin fields to SABYAPC and SABYASC tables (create alter scripts for tables). Populate the
data_origin fields with "SICAS" during processing (modify SORYAPCP10.SQR, SSKYLASC.py_Migrate
procedure). Modify ASC Decision process (SORYADP.SQR) to select SARADAP records where applicant exists
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
5
in either the SABYASC or SABYAPC table for the term and the data_origin = "SICAS".
Campuses using the SICAS tables, must leave the data_origin null or populate with a word other than "SICAS".
When this RF is installed, the value of data_origin will be set to "SICAS" for all records currently in the tables.
Campuses must evaluate which records need to have the data_origin value updated to null or some other value.
RF# 6239 SIRIS Former Name sends names never sent by SIRIS
Problem:
The former name logic used throughout SIRIS interfaces uses former names in SPRIDEN but sends the most
recent former name even if that name never was used in a former submission.
Response:
Resolves RF 6343.
Dependent on RF 6243 (SFKYCVI1 references column added in this RF)
The solution is to track former names separately for SIRIS submissions. A new table with pidm, first, middle and
last name data and date will be populated during Posting of any interface that sends people. Only names that
don't match the most recent will be inserted.
RF# 6243 TSDS - Allow 1 banner bldg/room to crosswalk to more than 1 PSI bldg/room combo
Problem:
The PSI relationships that SICAS developed in the previous millennium (STVBLDG - STVYCCB - STVYCRR STVYCRO) are not working for us since we constructed our Campus Center. We are having difficulty with the
functionality. We would like you to consider changing the relationship between building and PSI building. We were
able to deal with it with CASA because our IR office opted to correct data using SOAYCAS.
This is our story....
SUNY Oswego recently combined two buildings in to one, which is identified as CAMCTR. It includes our student
union and many classrooms. We reassigned the rooms that were in the two buildings (Poucher and Swetman) to
be in the same (new) building, CAMCTR. The PSI database in Albany does not recognize the rooms as being in
CAMCTR. They want the former Poucher rooms to be reported as PSI building PO-3. I believe the former
Swetman rooms are reported as PSI building for the CAMCTR (CC-3), but I am not sure.
Our problem is that we cannot report the old Poucher rooms as (psi) PO-3 because they are in the CAMCTR
building, which is linked to (psi) CC-3 in the stvbldg table.
STVYCBB defines PSI building codes. STVYCRR links PSI room numbers with PSI building codes. STVYCRO
links the Banner building and room number with the PSI room number. The PSI building relationship is done on
STVBLDG.
Would you consider moving the STVBLDG_YCBB_CODE_SCAS column to a column in the STVYCRO table and
add that column to the STVYCRO form allowing us to specify a PSI building code for each building/room
combination rather than each building?
Response:
**You MUST install Student 7.7S1 or 8.3S1 before installing this patch.**
This affects State Operated campuses or any campus sending building/room information in SIRIS Term Section
Data Submission.
Add PSI Building column to STVYCRO table and form. Allow PSI building field on STVYCRO to be updated to
any value existing on STVYCBB. PSI room code on STVYCRO must still validate against building/room
combination from STVYCRR.
Copy existing PSI building info from STVBLDG to the STVYCRO PSI building column where the stvbldg_code
matches the stvycro_bldg_code.
Modify SFKYCVIR package body to select PSI building and room information from crosswalk of campus
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
6
building/room on STVYCRO. Campus building and room are obtained from the building and room assigned to the
section on the SSRMEET table via SSASECT form.
This will allow campuses to crosswalk one campus building to multiple PSI buildings. The Crosswalk of the
campus building to PSI building will still be done on STVBLDG form. The STVYCRO form will still be used to
defined Banner room codes and assign PSI rooms. The only difference is that the PSI building will now appear on
the STVYCRO form and be able to be updated. Prior to this modification, only the PSI room code was visible on
STVYCRO after selecting the PSI room from an LOV containing PSI building/room combinations.
RF# 6247 When delete/inactivate some fields need to be set to zero
Problem:
We are using Aleph version 18.
After testing both the delete and inactive SORYALD processes, both .plif files were rejected by the Aleph system.
The error message is the same in each case, #5024, and on all records in each file. In the Aleph manual, this
message means “Number of records specified in the input file is not numeric”, and the reason is because at least
one of these fields is not numeric: user_rec_no_address, user_rec_no_bor, user_rec_no_id.
The contact at ALEPH says to put zeros in the user_rec_no_address, user_rec_no_bor, and user_rec_no_id
fields in the .plif output file.
Response:
In the Process_inativate_delete procedure, modified setting of user_rec-no_id, user-rec-no-address, and userreco-no-bor to zero rather than the ignore character when inactivating patrons. When deleting patrons, needed to
add these fields to the record being sent and set the fields to zero.
RF# 6276 SORYADF - Output File Name
Problem:
When we went to run the SORYADF process today the output filename was in the following format
SORYADF.out
Could this be adjusted to create a filename like
soryadf_683335.out
Response:
Modified the code in the RETRIEVE_JS_PARMS procedure.
RF# 6286 8S6225 not correct
Problem:
Defect fix 8S6225 is not correct. Where the fix changed a selection from "between 0 and 30000" to "between 99999 and 30000".... 3 dropped out because they had income levels less than -99999. In addition 1 other dropped
out because the same select looks for sobysfa_model_cde of 'I' or 'D' and 1 was null. In summary, to fix this I
changed the selection in procedure SFAS_REPORT6A with..
AND ((nvl(SOBYSFA_MODEL_CDE,'I') = 'I' AND nvl(SOBYSFA_INCOME_LEVEL,0) <= 30000)
OR(nvl(SOBYSFA_MODEL_CDE,'I') = 'D' AND
((nvl(SOBYSFA_INCOME_LEVEL,0)+ nvl(SOBYSFA_PAR_INCOME_LEVEL,0)) <= 30000)))
Response:
Modified the codes at SFAS_REPORT6A procedure to fit the negative income level and
SOBYSFA_MODEL_CDE is null condition.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
7
RF# 6292 uniqueness error while running TSPYCCB
Problem:
Attached please find the 2 records that are violating uniqueness. They are both brought in by the tspyccb job and
have the same activity date, so even if one or both are removed the job still tries to insert them both. How can I
get around this? Can I add the shrycrn_capital_credit_hrs to the uniqueness key to force them to be unique? Will
this harm anything in your opinion?
We receive the following error when running tspyccb.
Enter Username:
Hyperion SQR Server - 8.5.0.0.0.566
Copyright (c) 1994-2006 Hyperion Solutions Corporation. All Rights Reserved.
TSPYCCB
7.3S2
SICAS County Charge Back Process
Enter Run Sequence Number (Optional):
842087
Error Occurred During The Execution Of A Package
TSKYCCBB.py_ccb_billing
ORA-00001: unique constraint (SATURN.UK_SHRYCRN) violated
ORA-06512: at "BANINST1.TSKYCCBB", line 2626
ORA-06512: at line 1
SQR: End of Run.
[ 5 pages * 1 copy ] sent to A106_5SIM
I have followed the instructions in rf 5380 and have removed both records that the select statement had
pinpointed as violating uniqueness. After re-building the uniqueness constraint the job ran fine in audit mode. But
when it is executed in update mode we receive the error again. This does not make sense since the problem
records were both removed.
Response:
Looks like the constraint is being caused by reversal of records when a student had a Certificate status of 'W'
(waiting for certification), then 'C' (certified), and then had a reversal. System was trying to reverse 2 'W' records
and caused the constraint error. Need to add SHRYCRN_COR_IND column to unique key.
Corning CC is the only campus that is using the 'W' status to bill with.
RF# 6347 Updates for the ASC Application process
Problem:
1. SAAYASC needs to be modified:
A. So that a user can enter the form with a valid ID even if there is no data on the form.
B. So that a user can enter and/or update data on the form.
Both of these changes will allow SAAYASC to function in the same way SAAYAPC does. There are several
campuses that use the APC form for data entry on Common Aplications, graduate applications and foreign
applications.
The load process needs to store the VISA code in GOAINTL. Currently it is only being stored on SAAYASC.
Response:
Banner 7 - Need to install RF 6162 before installing this RF
Banner 8 - Need to have 8.3S1 installed or RF 6162 installed before this RF.
Changed the form to allow inserts and updates. Campuses can now use SAAYASC to store data for applicants
who do not apply through ASC. Campuses can also update existing data if needed. This form was originally
inteded to store data from the ASC tape load to maintain a history of what data came in on the ASC data load.
Updating records or adding records deviates from this usage.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
8
Security will also need to be updated from query to maintenance.
The EXTENDED VISA code is being stored on GOAINTL. The VISA code that is in bold letters on SAAYASC is
the old 2 digit visa code that is no longer sent by ASC. The field remains on the form to accomodate data the will
be brought over from SAAYAPC.
Made changes to SARYXRF.SQR which include:
1. The report has been reorganized for better readability.
2. Applied DRY principle (removal of duplicate code).
3. Added more comprehensive exception handling for the Setup loading. If an exception is encountered, the error
in the report or log file will provide better trouble shooting if an error is encountered during an insert. This
information will assist in fixing the data.
Security needs to be changed from Query to Maintenance in order to update and insert on the SAAYASC from.
RF# 6366 Multiple SIRIS SDS
Problem:
Multiple SIRIS Problems
1. SDS -The Degree element which reports Highest Degree earned is being reported for students that are not
transfers or new graduate students. It is only required for Higher Ed History of 2(undergad Transfer) and 6 (new
Graduate.
2. SDS- The High School Status element is reporting for all students instead of just just for students for
Undergraduate First time (1), Undergraduate Transfer (2) and Concurrently Enrolled in HS (5). The default is
being sent for students who do not have an HEH = 1,2,5.
3. SDS- The DOB Logic needs to be changed so that when there is no valid DOB a NULL is sent.
Response:
1. The Degree element now uses a DECODE on HEH so that the function that returns the highest degree is only
called when HEH is 2 or 6. The element forces NULL into the column for all other HEH values.
2. Added a new element of "HS Status2" which follows the initial logic and removes or corrects the element to
match HEH value on the record. Specifically, when HEH=5 this value is now forced to 4 and the value is removed
if the HEH is not within 1, 2 or 5. When required, the value now defaults to 6 if no value is stored by the first HS
Status element.
3. The DOB Element is now decoding the 00000000 birthdate to NULL instead of to the original 09-09-9999 date
originaly used for NULL dates.
RF# 6422 $banterm does not exist in let $newterm = $banterm
Problem:
For part-time TAP recipients, identifying whether or not an award was received in a prior term was not done
properly. This may have affected pursuit calculations for part time TAP students.
Response:
1. Changed {let $newterm = $banterm} to
{let $newterm = $ban_term} in procedure GET_GAS_POINTS.
The assignment statement needed to be changed to use $ban_term rather than $banterm. Not setting the
$newterm variable correctly caused the award status (#a_stat) to be set to zero during further processing. This
affected the determination of whether a part-time student received a prior term award because the determination
was based on the award status being >= 4. The pursuit functionality would not be called.
RF# 6425 SDS - Highest Degree sending default of 10/HS Status is null when no HS record
Problem:
All the patches including 6366 have been applied to PPRD and I have two questions:
1. the sobysds_highest_degree field is being set to the default when the higher ed hist is not 2 or 6. Is this
correct? I thought the highest degree would be null if the higher ed hist is not 2 or 6.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
9
2. the sobysds_hs_status is null when there is no high school record - is it supposed to default to a 6 if the higher
ed hist is 1 or 2 and there is no high school record?
Response:
***must be installed AFTER 6366****
All standard SOAYDTI defaulting has been removed and additional "Degree2" and "HS Status2" elements now
provide conditional defaulting.
The degree element will default 9 when the HEH is 2 and no degree is found. We are not defaulting any degree
information for students with an HEH of 6 because those students should have degrees. Students with an HEH
not equal to 2 or 6 will have nothing sent for this element.
The HS Status will default to 6 (Unknown) for students with an HEH of 1 or 2 and no HE Status is found. Students
with a HEH of 5 will default to a HS STatus of 4 and all others will have no HS Status sent.
RF# 6433 Banner ID is not retained
Problem:
When entering the SAAYASC form, the Banner ID is not retained.
Response:
Made changes to form level triggers GLOBAL_COPY and SAVE_KEYS so the Banner ID number is retained.
RF# 6446 Wrong Qualifier Code assigned for Email
Problem:
The ASC processing was using the SOAXREF cross reference for STVTELE to return the Email Qualifier code.
The logic should be getting this code from SAAERUL for the PQLF Group.
Response:
Changed the code in the processing to return the Email Qualifier from SAAERUL instead of SOAXREF.
RF# 6447 Multiple SIRIS Errors
Problem:
1) error in the select code used to collect the Visa Code element. If a student has more than one active Visa you
will receive an Oracle Error (ORA_01427) and no Visa codes are reported. The result is Visa errors on all
international students.
2) There are also oracle errors with the UP GPA elements and PROG ID 1 and 2 elements.
3) Default on the Section "OnlineType" element is an invalid code.
4) Adding records on SCACRSE did not save changes made in the SUNY IR block. This was RF#6214.
5) Error Message collection problem when WS Response fails to process. Real error is not returned.
6) GPAYEXT Form not supporting custom key settings for Form calls with PIDM based Extracts.
Response:
1. The automated response to ORA-01427 Errors when processing an SQL with a sub-query was fixed in a
reposted RF#6122. That fix was lost when Release 8.3S1 was shipped. The code has been corrected to the
reposted version of the routine.
2. The "UP GPA" error reported was also a sub-query problem related to this fix. A recent insert script inserted
SQLs that started with two SELECT keywords for both "PROG ID1", "PROG ID2" and "Award LVL". The inserts
are corrected in this patch. The procedure has been corrected.
3. Default value on the "OnlineType" was changed to the new value of 1 (previous value was ZERO).
4. CDS IR Data Shadowing procedure in the SFKYCVTS package was attempting an autonomous transaction
which prevented it from seeing form committed data.
5. Error processing in GOKYWSRD WS Calls corrected to include returned text in the Additional Data box.
6. GPAYEXT Custom Key processing duplicated in the PIDM based routine within the WHEN-NEW-FORMINSTANCE trigger at the form level.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
10
RF# 6462 Soryapcp10.sqr does not run in Banner Job submission.
Problem:
(SQR 5528) ORACLE fOCIStmtFetch error 24374 in cursor 1:
ORA-24374: define not done before fetch or execute and fetch
(SQR 1940) Error fetching row.
The job does not complete - errors out. The parameters are not the same from job submission
or when running from Unix command line.
The job completes successfully from the command
line. The above error represents job submission.
Response:
The "DATE-TIME" syntax was deprecated in SQR 9.3, which is the version of SQR this error was reported under.
Modified the program to use the RETURN_DATE_TIME function from GUPYLBS in place of DATE-TIME.
RF# 6475 SIRIS/SDF - Some Forms/Processes not accessible - not on GUAOBJS form
Problem:
Some forms/processes related to SIRIS on Banner 8 and SDF on Banner 7 cannot be accessed.
Response:
A script, dgubobjs.sql, was sent in the Student 8.3S1 release in an effort to make objects that were de-supported
in Banner 8 or just plain old objects unavailable in banner by deleting them from the GUAOBJS/GUBOBJS
form/table (this defines the object to Banner for accessibility).
Some objects, like the STVYSSA - SUNY Study Abroad Validation form was inadvertently deleted when it was not
actually de-supported in Banner 8.
The script was also sent in the Student 7.7S1 release. It should not have been sent out for 7. This caused
SDF/CASA related forms and processes, the SICAS Mass Swap form, and some other forms/processes that were
de-supported in banner 8 unaccessible in Banner 7.
Solution - Create script at 7 and 8 versions to insert needed objects back to GUBOBJS table so they are
accessible.
RF# 6488 SPRYIMM 8.0S1.1 missing term in heading?
Problem:
SPRYIMMM 8.0S1.1 is missing term in heading
Response:
Added Validate_term in the RETRIEVE_JS_PARAMETERS procedure to retrieve the $term_desc.
This RF is dependent on the Student 8.3S1 release because this program was shipped in 8.3S1. It can be
installed before the 8.3S1 release, but would then need to be re-installed after 8.3S1.
RF# 6542 STVYASO.FMB was not shipped with Banner 8.
Problem:
The STVYASO was not shipped with the 8XS release of Student.
Response:
Ran Banner 8 forms converter on STVYASO and shipped at 8.3S1.0 level.
RF# 6552 Foreign Temporary Address Stop process when null
Problem:
When the Foreign Temporary Address is null, processing stops.
Response:
Wrong variable used when processing Temporary Addresses.
Made corrections in procedure py_Address.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
11
RF# 6562 Multiple SIRIS Fixes and SOAYDTI Enhancements
Problem:
***** Multiple SIRIS Interface Issues
1. SDS VISA Information not selected if the VISA expires during the report term or becomes active before the end
of the report term but is not active at the time the report process is run.
2. "Simult Use" TSDS Element is not checking Building or Days of Week data so it determines overlapping use for
classes that do not meet together.
3. Course level code is being treated as a string not as a number which can result in an incorrect calculation of
State Supported Credit hours.
4. Home institution flag on SOAPCOL being selected for all students and not just those with HEH 7-9.
5. Prior institution and Degree are not being sent for students who are enrolled in combined programs
(Bachelors/Master) and are moved to the Masters level without the Bachelors degree being awarded. We need a
way to default these elements for students in this situation.
***** Multiple SOAYDTI Enhancements Needed
1. PII Data needs to be masked out by hand when submitting XML to SICAS or System Admin which if very time
consuming and error prone for Campus staff. The form needs to mask this data during XML extraction.
2. Searching through the XML when extracted on the Processing Errors tab to find the XML tags for specific
values when debugging XML problems is also time consuming for campus staff. Could a search feature be added
to the extracted XML block on the Processing Errors tab of SOAYDTI?
3. Most of the interfaces transmitted using SOAYDTI require TR (transmit replace) runs because incorrect data
sent resulted in SUCCESS status records which are not resent in TU mode (transmit update) runs. Some
mechanism for updating the status of individual records needs to be implemented.
4. Many Elements are too complicated to code in a single SQL Select. One way to implement these items is to
use more than one SOAYDTI Column Definition to populate the same column. This requires careful NVL() code
on the second and subsequent SQLs to prevent overwritting the results of earlier SQLs. This also results in long
execution times since all records are processed multiple times. Could an option be added to replace only rows
where the value is NULL?
5. It is hard to tell when and what changes are made to SOAYDTI Records (both SQL changes and other
changes to the element definitions). We need some kind of Audit Trail capability.
6. Need to change the code on the rank and tenure records for community colleges to default 7 and 3 respectively
when no data is found.
Response:
NOTE: This RF resolves RFs 6544, 6465 and 6547 (see notes below) (Banner 7 requires application of RF#6755
following this patch)
***** Multiple SIRIS Interface Issues
1. New SDS VISA Code select added that updates the column with VISA data that was valid for any part of the
term. Only replaces column if it remained NULL after the first VISA SQL executed. Resolves RF#6544.
2. "Simult Use" TSDS Element is now checking that Building and Days of Week data match in order to mark
records with Simultaneous Use. Resolves RF#6547.
3. treating the course level as a number in SDS instead of a string. This will allow state supported credit hours to
be calculated correctly.
4. Altered the selct for the Home institution element so that the Home Institution is only being selected if the
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
12
students HEH is 7-9.
5. To send prior institution and a degree for students who are in a combined Bachelors/Masters program and are
moved to the Masters level without being awarded the Bachelors degree you need to:
Create a prior college on SOAPCOL using your institution, check the SDS Prior Institution box and enter a prior
degree of 000000. You also need to crosswalk that code to 9 (No Degree) on SOAYDTI. If your institution uses
000000 on other records and you do not wish to send 9, cross walk 000000 to 10 (Unknown prior degree).
**Resolves RF 6465**
6. Moved the Campus ID element from the validation tab of each element to the validation tab of the SIRS
element.
***** Multiple SOAYDTI Enhancements Needed
1. New SOAYDTI Record Type of PII added to TSDS and SDS (and will be included in new interfaces containing
PII columns) to identify the PII columns and define a mask used to hide data. A single record can be used to hide
data in multiple columns. SICAS has placed these columns after all existing columns on the Column Definition
tab. Masking is optional and is controlled by the "Mask PII" checkbox on the Web Service Request tab.
2. The extracted XML block generated from the Web Service Request or Response tab "Extract" button now has
a "Find" button and related Edit Box. The user can enter text in the box and press "Find" to locate the text within
the block. Pressing the button again finds the next instance of the text within the block. A message is diplayed if
the text cannot be found.
3. The Data Review Tab has been enhanced to support Status Change views. These views display a leading
checkbox before each record and a button on the bottom of the form to process the checks. SDS and TSDS have
new dataviews that support marking the checked records as READY to send. No option exists to reverse this
setting for a record.
4. A new tab has been added to the lower tabbed dialog on the Column Definitions tab on SOAYDTI (actual form
changed is GORYDTI) which allows an UPDATE CONDITION to be assigned to the SQL. This condition limits the
records the SQL is applied to. This condition is not limited to the target column being NULL but that is certainly
supported.
5. An Audit Trail tab has been added to the Lower Tabbed Dialog on the Column Definitions tab on SOAYDTI
(actual form changed is GORYDTI). SICAS will update this Audit Trail when modifying the record.
6. Defaults added to the Tenure and Rank elements for Instructors. Clients will need to remove and recreate their
local mod records setting the Process Method to "Use SQL Code".
RF# 6570 ASC 2011 and Common App Templates plus Multiple Fixes
Problem:
Multiple fixes for the ASC application load process.
1. In package SSKYLASC, Function fy_CURR2CURR was not using 'YASO' in selection criteria.
2. Report shows no errors, but EDI temporary tables not loaded.
3. SARYXRF needs more checks for setup checks..
4. ASC 2011 Template needed.
5. Common Application Template needed.
8. Latest versions of General File Load key files out of sync.
Response:
Multiple fixes for the ASC application load process.
1. Fixed procedure fy_CURR2CURR in the SSKYLASC Package to select the correct SOTCNVT records.
2. Fixed problem with error messages not being stored and sent to the error report.
3. Created Third report which will contain only Error and warning messages from SSKYLASC. This should assist
in resolving setup problems.
4. Added more checks to SARYXRF.SQR. The report now covers more information on the ASC EDI setups.
5. Added to the errors reported.
6. ASC 2011 Template.(Name is ASC2011)
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
13
7. Common Application Template. (Name is COMM2011)
8. Latest versions of General File Load key files.
RF# 6596 SFRYCAP Control Report Parameters not Printing Correctly
Problem:
The parameter section of SFRYCAP is not printing correctly.
Response:
Modified the control report print section to call a new modified version of printstuid.
Included in this RF are the changes for 4688.
***************************************************************
Need easier method to change results back to System from Manual
***************************************************************
Once a Manual adjustment is made on the SFAYRCP form there is no way to set it back to process using
System, unless you DD the course and re-register.
There needs to be an easier method to identify that you want the process to revert back to a system calculation.
Perhaps an indicator on the SFAYRCP next to the manual/system indicator - once checked fires off compliance
(ignoring the manual setting) and reverts back to a system calculation.
Modifications made to accomodate changing a student from manual to system.
User must run the SFRYCAP report and set parameter 14 Override Manaul to System to a 'Y'.
The control report issue was at only occurring with Banner 8.
RF#4688 is an enhancement.
This rf will not ship for Banner 7.
RF# 6615 Form Hangs
Problem:
We have converted to Banner 8 and the SOAYWSP form hangs.
Enter application ID and term, next block, and the form hangs. We have recompiled the form, and that did not
work.
Response:
The Primary Key was created with columns in an order that prevents the related index from being used in
common selects and updates. This may be slowing the display down significantly making clients think the form
locked up. Indexing issues seem to be worse on Banner 8 than they were on Banner 7.
The Primary Key is reorganized to allow it to speed up common selects and updates used within the SSB Toolset.
RF# 6633 SFVYCRS, SFVYFRS, SFVYSRS - Course ID problem
Problem:
The COURSE_ID field in the SFVYCRS, SFVYFRS, & SFVYSRS views are created using the (
ssbsect_term_code
|| '-'
|| fy_gtvsdax_ext ('CAMPUS', 'SICAS_ANGEL', NULL, 'N')
|| '-'
|| ssbsect_subj_code
|| '-'
|| ssbsect_crse_numb
|| '-'
|| ssbsect_seq_numb)
fields to create Term-College-Subject-CourseNumber-Section. (ex: 201030-CHM-145-Y01)which is the unique
identifier for Angel.
These fields above can be modified at anytime in Banner unless the whole course process is locked which many
schools do NOT due until well into the semester. Because of this, there are issues with Angel creating new course
shells everytime one of these fields change. Banner's practice is to utilize the ssbsect_term_code & ssbsect_crn
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
14
which never change and set the relationships to the registration file using these two fields. We need to be able to
create a unique course field in the Views that would be compatible with Banner and prevent changes from
occurring. Utilizing and concantenating the:
( ssbsect_term_code
|| '-'
|| fy_gtvsdax_ext ('CAMPUS', 'SICAS_ANGEL', NULL, 'N')
|| '-'
|| ssbsect_crn)
from the SSBSECT table is the best solution since these fields can NOT be changed and the registration table
utilizes the same unique fields to join the enrollments to the correct course.
Response:
Created fz_angel_course_id as local campus modification function so campuses can create their own
combination of unique fields for the Angel Course ID value. The function will default to the current combination of (
ssbsect_term_code
|| '-'
|| fy_gtvsdax_ext ('CAMPUS', 'SICAS_ANGEL', NULL, 'N')
|| '-'
|| ssbsect_subj_code
|| '-'
|| ssbsect_crse_numb
|| '-'
|| ssbsect_seq_numb)
so campuses do not have to make modifications to the function if this value was working for them.
For campuses that want to change the value of Course ID, the function shipped with this patch will need to be
updated to include the local campus code. The function is the only object that needs to be updated. The
sfvycrs(course), sfvyfrs (faculty roster), and sfvysrs (student roster) views have been modified to call the new
function so no modifications neeed to be made to the views.
RF# 6638 SFRYCFA will not run when using Student ID option.
Problem:
I am unable to print the outcome tracking results when using individual ID numbers. Using a population selection
the process runs and prints. Forwarding copies of LIS and LOG files to [email protected] address.
Response:
Changes were made, the student id's were not being loaded into the GJBCOLR.
The missing GJBCOLR records were causing invalid id errors on the report.
RF# 6660 Add INSTRUCTOR_SOURCEID to Course XEI view
Problem:
We would like to request an update to the COURSES XEI view based on a change in ANGEL 7.4. We are
proposing that this update be the addition of a single column to preserve backward compatibility with campuses
using ANGEL 7.3.
The additional column / value that needs to be added to the COURSES XEI view is the
INSTRUCTOR_SOURCEID. This INSTRUCTOR_SOURCEID should match what is currently being used in the
ENROLLMENT XEI views to reference the user account's SourceID (SFVYFRS_USERID).
Response:
RF 6633 should be installed prior to this RF.
Added sfvycrs_instructor_sourceid to view. The value is the same value as the faculty view USER_ID column SFVYFRS_USERID.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
15
RF# 6667 2010 Changes for State Certification
Problem:
Enacted 2010-2011 New York State Bugdet contains new SAP Charts.
New SAP Charts for Bachelor and Associate Degree programs Effective 2010-11 for non-remedial students
receiving first NYS award payment in 2007-08 and thereafter.
Changes affect Certification and Good Academic Standing.
Response:
Campuses must make sure that the HESC Year of 2007 terms are present
in the STVYTTY form. If the HESC Year of 2007 is not present in STVYTTY
the New SAP Charts for 2007 will not display on the SOAYSAP form.
A Remedial rule type has been added to SORYULE for those programs other than
EOP/HEOP that meet the State Education Department's definition of Remedial.
Insert new SAP Charts with Hesc Year of 2007.
Made changes to RPRYGAS, SORYTCE, SHKYGAS and SOAYSAP.
RF# 6715 ASC Fixes
Problem:
1. Web applications are having a problem with crosswalk with label SBGIQLFR. Hard codes values in the
SSKYLASC package is conflicting with web applications. Other hard coded values could potentially cause
problem should ASC or EDI values change. Web applicants are not loading.
2. Contact type not loaded to the Application.
3. EOP applicant is not assigned the correct WAPP code when the EOP_IND = Y and the EOP_CHNG is NULL.
In this case the student is assigned a regular WAPP code and not an EOP WAPP code.
4. Residency not correct on the application, is reported as unknown.
5. If the EDI box is not checked on SAAERUL, the rule fails.
6. DOB fails when zero filled.
7. Cannot use 4 digit Phone Type
Response:
Multiple fixes.
Fixes in SSKYLASC
1. Removed hard coded values. These are now on SAAERUL. This
provides more flexability for the campus in what values they
would use.
2. Added logic to load the Application source and Contact type. There is setup on STVCTYP and STVINFC.
3. Fixed logic for determining EOP. When EOP_CHNG value was NULL and EOP_IND = 'Y', the process was not
handling the NULL value correctly and therefore did not determine that the student sas an EOP student. The
STVWAPP code was not set to an EOP WAPP code.
4. Residency logic added to procedure py_PT to correct the residency (this resolves RF 6648).
5. Removed restriction on SAAERUL for the EDI box to be checked.
6. Added logic to check for zero filled Date of Birth.
7. Made code corrections so that 4 digit phone type can be used.
Other
Entry needed on STVCTYP of ASC for Contact type.
Entry needed on STVINFC. This will set default for common matching. It also defines the source code and contact
type for the application.
RF# 6785 VISA Code2 validation codes missing
Problem:
The Visa Code 2 element was added to SOAYDTI for the SDS submission. When SDS is run each student
receives an error indicating that the VISA code 2 has not been cross walked. I attempted to cross walk those
values on the cross walk tab and the interface code validation has nothing in it. I am unable to crosswalk the visa
code 2 element.
Response:
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
16
1.The "VISA Code2" has been altered so that it uses the "VISA Code" element crosswalk and therefore requires
no additional crosswalk effort on the part of our clients.
2. (second unrelated issue) The code to rewrite the update SQL to correct for ORA-01427 errors has been altered
to be valid in more situations. The old rewrite often built in invalid update statement (usually when complex
WHERE clauses existed)--the new rewrite does not need to alter the WHERE clause.
NOTE: This patch depends on changes made in RF#6562.
RF# 6808 Multiple CDS (SIRIS)
Problem:
Multiple SIRIS Issues:
1. Force update does not work on CDS.
2. In CDS a TR does not send equivalent courses.
Response:
Both of these are related to the CURRENT status assigned to records that contain the exact data last sent to
System Admin. Equivalent Course records were getting marked current during TR runs which should not happen.
When we changed the Submit Status to READY in the Force Resend option the feature would work as long as
data changes occurred but otherwise the record would also be marked CURRENT and not be sent. This prevents
resending when something changes on the System Admin side but our data remained the same.
CURRENT status updates to Equivalent Course records are now not made when the process runs in AR, TR or
UR modes.
The Force Resend option now sets the Force Update status on SCACRSE so that the next transmission will
always include the record.
RF# 6815 Correct insert to tables to use list of columns.
Problem:
The SFKYREG and SLKYAUTO objects do direct inserts into tables without listing the table columns to be
inserted to. This causes problems with SunGard's conversion of the database to add 5 new fields for the database
new portion of the Horizon project.
This is a Banner 8 only issue.
Response:
Corrected Insert statements that will be invalid after Sungard's mass table update scripts are run for Project
Horizon.
RF# 6834 SIRIS Former Name logic fails on Two Names sent the same day
Problem:
When two different names are sent to SA on the same day, later calls to the Former Name SENT and POST calls
fail with TOO_MANY_ROWS error.
This prevents further use of the submission system.
Response:
Process now uses the sequence number to break Last Date Sent ties. The cursor will now always bring back
exactly one row regardless of the number of alternate names combinations are sent the same day in SIRIS
submissions.
RF# 6859 Multiple ASC Fixes
Problem:
Residency is being set to the SAAERUL DFLTRESDCODE value (0) when it should be R. We only have 3 EDI
Equiv's on STVRESD set (N,Y,U) and Y goes to R (for NY State)
Full/part time indicator is not loading correctly
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
17
Address erros when address have dates with all zeros
Problems navigating in SAAYASC
Invalid SSN's are being loaded when the GTVSDAX entry is set to NOT load them.
Response:
Now setting the SARRESD_CQLF_CDE to "RI". Additional crosswalk needed on SOAXREF Label = RESDCRIT
for the ASC values of {Y,N,U} to the Banner values.
**Additional information has been added to this RF based on campus setup and testing. In addition to the new
crosswalk mentioned above, campuses need to also go to SAAERUL and update the rules in the ADMS group
OUTRESIDCODE, INRESIDCODE, and FORRESIDCODE.**
This fixes the Residency problem of not loading correctly.
1. Fixed application source. In procedure SSKYLASC.py_ASCctyp, removed hard
coded value. The Contact type is now passed in. Added rule to SAAERUL for
contact type and removed hard coded value. This gives the campus the flexability to use the old value of “APC”.
2. Fixed procedure SSKYLASC.py_AddressUpdate for date issues and removed hard coded values. ASC sends
all zero’s for some dates which causes an exception.
3. Fixes to procedure SSKYLASC.py_Create_CommenT. Increased s_data variable
to VARCHAR(3). Fixed cursor to use passed in value. Removed call to
GOKYSREP.py_Print which caused an exception.
4. Fixed procedure SSKYLASC.py_PT to not insert residency. Added call to get
SARADAP application number. Also fixed the Full time Part time to load correctly.
5. Removed call to SSKYLASC.py_PhoneHome from procedure SSKYLASC.py_Migrate. Baseline is handling
this now.
6. Fix to calculation of the Visa Start Date in function SSKYLASC.fy_VisaStartDate. The end date had a tendency
to be less than the start date.
7. Fix to SSKYLASC.py_Address to not load non numeric county codes. Also added exception handler.
Applications did not push correctly because these non county codes are not cross walked. They should not be
loaded.
8. Fix to procedure SSKYLASC.py_Reference for exceptions. To fix unhandled exceptions.
9. Fix to procedure SSKYLASC.py_Phone for exceptions. To fix unhandled exceptions.
10. Fix to procedure SSKYLASC.py_Resd - CQLF code populated. This fixes the residency so it loads correctly
though baseline.
11. Fix to procedure SSKYLASC.py_Prior_sessions for date problems. Dates may come in as all zero’s or nines,
which should not be loaded.
12. Fix to procedure SSKYLASC.py_PriorCollege for date problems. Dates may come in as all zero’s or nines,
which should not be loaded.
Fixed the SAAYASC form to correctly handle ID retention in the key block.
Removed all check boxes from the SAAYASC form.
Fixed the logic to not load invalid SSN numbers.
RF# 6865 Board of Regents Adopts Emergency Definition of Remedial
Problem:
For the 2010-11 academic year only, a student who first received an award prior to the 2010-2011 academic year
and does not meet the eligibility requirements to be certified for TAP under the 2010-2011 SAP shall be deemed
to be in an approved program of remedial study for the 2010-11 academic year solely for the purpose of defining
which standards of academic progress apply for the 2010-11 academic year.
Response:
Changes made to the SICAS State Award Certification Process, SORYTCE and the SICAS Good Academic
Standing Processes, RPRYGAS and the SHKYGAS.FyCalcNYSGAS function.
The output listing from SORYTCE and RPRYGAS have been modified to display
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
18
whether or not a Student is in a Remedial Program of Study. The report
label REM will have the following value:
B - Student meets both the EOP and Remedial Rule
E - Student meets only the EOP Rule
Y - Student meets only the Remedial Rule
This posting is dependent on RF# 6667, which inserted in the new SAP Charts
to be used in 2010 for Non-Remedial students first receiving aid in 2007 or thereafter.
RF# 6941 Err: FRM-40735: When-Validate-Item trigger raised unhandled excep. ORA-0422
Problem:
I have a student who apparently came in on 2 Cert Rosters from HESC for the same term in 09-10. I need to
make a change to his cert status, however, I cannot open either file on SOAYTRC. When I attempt to open I
receive message:
FRM-40735: When-Validate-Item trigger raised unhandled exception ORA-0422: exact fetch returns more than
requested number of rows
Response:
1. There were repeated records for the students with distinct sobytrh_roster_number,
but repeated sobytrh_term, not unique.
2. The select into statement in the WHEN-VALIDATE-ITEM trigger of SSN item in
the KEY_BLOCK had repeated records whose sobytrh_term was the same.
3. Added a new condition {AND SOBYTRH_ROSTER_NUMBER = :ROSTER_NUMBER} to this
select into statement to separate the two repeated records.
RF# 6976 Multiple ASC fixes
Problem:
Reported Severity: Low
Platform: UNIX
Object Locally Modified: No
Patch for multiple ASC fixes
Response:
1. Fix for Prior college transfer hours which were not l;oading previously.
2. Fix in procedure py_InsertSarrsrc for application source to load
application source when that source exists from a previous application of the same type.
3. Fix in procedure py_Reference for the visa type variable to use typing from the expanded visa type. This was
causing the load to fail.
4. For High School data, allow the information to load if the CEEB code is '000000' as unknown.
5. Added more information to error handling in package SSKYLASC. This will help campuses when a load fails.
6. For Prior College, allow the information to load for CEEB codes '0000' as unknown.
7. Fixed mouse navigation on the SAAYASC Form. A user can now click into the data block and the records will
display if they exists.
8. Leave Alien registration number blank if no value comes in on the file.
RF# 7017 DB New Beta forms that won't compile
Problem:
Reported Severity: Low
The student forms SAAYDME, SOAYWAC, SPAYMNG, will not compile after the db new table changes are
made. Errors attached. (on STST11G)
Response:
Modified insert sql to list columns that are inserted into. DMB
RF# 7036 Problem with Immunization Health Survey
Problem:
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
19
The question set code in Health Display is not showing our data correctly. I have attached the code we have in
this seq no. 141. THe Mantoux result is stored in the spryhis table and because the formula is looking at spbyimm
table, we get an * in the display even though the student has a result. When we tried to modify the code, we had
issues. I noticed the SPBYIMM_TB_COMPLIANCE is still stored in SPBYIMM, but the SPBYIMM_MANTOUX
DATE and MANTOUX result are in SPRYHIS with a shryhis_sryhis_yhis_code of TB. Can someone explain?
Response:
Added a new procedure named py_SPBYIMM_sync_SPRYHIS to sync the legacy columns in SPBYIMM after
SPRYHIS records are altered. This will initially be called only by the SPAYHIS form when the user saves data.
The logic included was a somewhat altered version of the trigger on SPAYIMM that synchronized the legacy
columns after returning from SPAYHIS and after edits to SPRYHIS table done directly on SPAYIMM form.
Altered the logic on the SPAYHIS form to call that new procedure after insert, update and deletes have been
committed to the database.
We did leave the existing logic active in SPAYIMM form (not shipped in Patch) because the logic on that form also
updated a number of on screen display fields that could not be updated by a PL/SQL call.
RF# 7045 Swap Fee Assessment fix removing all liability
Problem:
Fee assessment is removing all tuition fee liability even though the drop is occuring well beyond the refund period.
The refund information on SFAREGF is being shown as Zero refund of tution and fees yet all charges associated
with the courses are being removed (refunded).
Response:
SICAS Swap Feature was performing incorrectly under some scenarios.
WARNING: This patch MUST be applied IMMEDIATELY following the application
of the RF 5679 patch for SICAS fee assessment!
WARNING: DO NOT apply this patch or RF 5679 to production without a complete
test in a test database!
Re-wrote the swap logic in FY_RULE_LIABLE_AMOUNT
Removed the extra table in py_procees_hours_swap cursor to sum(drop hours)
Renamed the g_swap_diff_hrs global to swap_drop_hrs_liable for clarity!
Passing three new variables from py_applyrules to fy_rule_liable_amount
flat_rgfe_amount_in, flat_rgfe_from_hrs_in, flat_rgfe_to_hrs_in
Currently used for swap calc if an actual flat fee recocd is passed in.
Re-wrote the portion of the swap logic that was failing
RF# 7059 Issues loading phone numbers
Problem:
We have recently upgraded to Banner 8 and we are trying to load our applications but they are erroring out due to
the phone number. I assume it might have something to do with the phone number length going from 7 to 12
characters since it worked in Banner 7. Any ideas on how to resolve this issue? Thanks
I put in a request to Sungard about this issue and this is what they responded:
Hi Pamela,It appears the issue is with the way the SICAS center is loading your data.
From your CMCHKAPP SARPHON record the data is
*WEB*3477505420
The system seeing ast the area code is 34775 and the phone is 5420.
Ask SICAS to load the numbers like
*WEB*347 7505420
I've attached my SARPHON record for you to review.
I did notice that when using GOAMTCH to match a student through SAAEAPS the phone number gets filled in
odd. For instance, say a person has a phone number of 7165551234, the phone are code field gets filled in with
716555 and the phone number field gets filled in with 1234.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
20
The following setup has been checked:
Go to SAAERUL for the label TELE Area code length is 3 and the phone number length is 7.
group YGRP set accordingly:
DAYPHONEPQLF = DP
HOMEPHONEPQLF = HP
Response:
Updated Package SSKYLASC procedure py_Phone with SunGards recommendation and phone numbers are
loading correctly.
Test this patch in test first to ensure the phone numbers are loading correctly.
RF# 7101 Visa Code2 Element is selecting codes that Expired long before the Term starts
Problem:
1. An LPR visa code that expired long before the start of the term is being reported in the term's ESS-SDS
submission. Visa Code 2 select returned LPR incorrectly when tested by the client.
2. Prog ID and Award level are not being selected when a new version of the program exists on SOACURR with a
later effective term.
Response:
1. The select was not restricting the term which the visa code appeared in. This select was adapted from a select
that did not use the term table and this restriction should have been added when that table was added. The
restriction has been added to the select.
2. Effective date logic was added to prog ID 1, Award Level and prog ID 2 to allow the process to select the
appropriate version of a program from SOACURR.
RF# 7131 SIRIS SDS Prior Colleges not found and HS Status sometimes NULL on HEH of 5
Problem:
Prior College select is no longer returning anything. This started after RF#7046 (Infinite Looping in Prior College)
was applied.
Also when HEH is 5 then HS Status is supposed to be forced to 4 but this only happens some of the time.
**RF 7046 was pulled, the problem that was reported in RF 7046 is:"Campuses are reporting a problem with the
process hanging while it is collecting the prior college element. This problem is caused by a part of the routine
that is attempting to accomodate for letters attached to IPEDS Codes. the process hangs when it encounters an
IPEDS Code taht is not found in the STVYIPD table."
Response:
The "HS Status2" element was changed to not depend on any table being populated (it now runs against DUAL
since the test only requires the existing SOBYSDS record). The data will be updated in all cases now.
The Prior College function fixed in RF#7046 contained a typo that prevented the function from finding the Prior
College data. That has been fixed and RF#7046 has been pulled.
The solution provided in RF 7046 is:"the function had been fixed in RF 5956 for infinite looping on conversion to
CEEB but the IPEDS and FICE conversions had not been altered at that time. All looping related to these
conversions have been rewritten to avoid infinate loops.
RF# 7143 Decision process returning no students
Problem:
We just ran soryadp for our fall call and it pulled no students. The File is due 11/1.
Can you plese help
Response:
Campus did not have any existing SORYADC records before running the process. The campus is at 11.0.1
version of SQR and Oracle is at 11.1.0.7.
Problem seems to stem from newer version of SQR not initializing an & variable to NULL.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
21
The SORYADP process was assuming that the &valid_ind in the following statement would be initialized to NULL.
If records existed in the SORYADC table, the &valid_ind variable would be set to 'Y'.
BEGIN-SELECT
DISTINCT 'Y' &valid_ind
FROM SORYADC
END-SELECT
Upon return from this statement a check was done on the value of $valid_ind. If ISNULL(&valid_ind), the process
continued. If not null, the error message - "You Must Run The SORYADF Report To Continue Processing. The
APC Decsion
Process Output Table (SORYADC) Has Already Been Loaded." was given.
Modified the process to initialize $valid_ind to 'Y' and set it to 'N' if records existed in SORYADC table. Checked
for $valid_ind = 'Y' upon return rather than checking ISNULL (&valid_ind).
RF# 7185 Oracle error on Tenure Status
Problem:
When running TSDS I received two oracle errore on the Instructor Tenure Status.
ORA-01427: single-row subquery returns more than one row
ADDITIONAL DATA:The SQL code defined for this element encountered a data error.
The Error Generated was: ORA-01427.
The Code is defined as follows: single row sub-query returned more than one row.
The UPDATE has been modified to update rows with good data. Records with NULL values should be reviewed
and data errors should be corrected.
ORA-00936: missing expression
ADDITIONAL DATA:The SQL code defined for this element is invalid.
The Error Generated was: ORA-00936: missing expression.
The Code is defined as follows:
SELECT P.PERAPPT_TENURE_CODE
FROM PERAPPT P
WHERE P.PERAPPT_PIDM = :pidm
AND NVL(P.PERAPPT_TENURE_EFF_DATE,PERAPPT_ACTIVITY_DATE) =
NVL((SELECT MAX(I.PERAPPT_TENURE_EFF_DATE)
FROM PERAPPT I
WHERE I.PERAPPT_PIDM=P.PERAPPT_PIDM),PERAPPT_ACTIVITY_DATE)
Response:
Replaced the select with code tested at a Community College. The new select does not result in the Oracle error
reported at that campus.
RF# 7195 Inserting new records into SAAYASC
Problem:
Is there a script or trigger that creates a SABYASC record for an application that is entered manually into the
system from a paper application
Response:
There is no script to populate SABYASC when you are manually entering an application. The SABYASC data is
the raw data from the ASC file along with data the does not have a home in banner. A script or trigger would not
have that data. We have made the form editable so that you can manually enter the information without a home.
The users are reporting that they are getting an error when trying to create a new record on SAAYASC. The error
is FRM40508: ORACLE error, unable to insert record. The version of the form is 8.3S1.6
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
22
When entering new records, the Term Code needs to be entered in the detail block. A valid ID needs to be
entered in the Key Block.
Made a change to the form so that if there is a Term Code in the Key Block then it populates if the record is new.
RF# 7212 Error while running Saretmt and SAAEAPS
Problem:
After installing patch 7007, these errors occur when processing SARETMT
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "BANINST1.SSKYLASC", line 3471
ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at "BANINST1.GOKYSREP", line 1115
ORA-06512: at "BANINST1.GOKYSREP", line 1162
ORA-06512: at "BANINST1.SSKYLASC", line 1203
ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at line 1
WRN-ORACERR: Error occurred in file "saretmt.pc" at line 1286
WRN-ERRSTMT: Following statement was last statement parsed:
begin SSKYLASC . py_Migrate ( :recnum , :sicas_err_msg:Ind_01 ) ; END
saretmt terminated with error
12 lines written to saretmt.lis
Response:
The error message from the SSKYLASC Package was larger than the variable could hold. Made changes to
SSKYLASC so that the error is truncated to a reasonable size.
Some of the calls in the SSKYLASC package had calls to the report package GOKYSREP. This was causing an
exception. Made new functions without calls to the GOKYSREP Package.
On SAAERUL, Group ADMS, Label DFLTSBGIWEB needs to have a default SBGI code for Prior College.
Made change to contact insert that checks that the Primary Key is not violated.
Made change in the curriculum check for multiple rows being returned. This could cause the wrong program from
being selected.
RF# 7232 Unable to locate existing rules
Problem:
Unless one knows the term code for a particular rule one can not find the rule. The term code list of values needs
to list the term code and group information for the type of rule selected so the user can make intelligent choice.
Current list of values is just a list of stvterm entries.
Response:
1. Added a new functionality.
2. Expanded sorydgt_RG and sorydgt_LOV to show term description, rule type, group code and group description
for the popup window "Effective Term Codes with Existing Rules".
3. Tied the term code to the rule type already selected.
4. Included the rule type into the where-clause of record group sorydgt.
5. Added new trigger to the effective term click button.
6. Created four new sorydgt record groups and four sorydgt LOVs.
7. Modified the key-cquery trigger of the term code field in the key_block.
RF# 7242 Refunding Error with New SICAS Swap Feature
Problem:
When I drop a course the system is accurately adjusting the tuition to the amount per the SFARSTS schedule but
it is adding fees even though it is a drop. Secondly, when I go in and add the second course, the tuition is being
reflected properly and the fees are being removed.
Response:
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
23
SICAS swap date range feature did not correctly evaluate flat fee to per credit drops at zero percent refund. Zero
percent refund, which must be handled uniquely throughout fee assessment (SICAS and SunGard) was the
problem.
IMPORTANT Note: The SICAS swap feature is new and all campuses are STRONGLY advised to test this new
feature before applying it to production. Three patches must be installed: RF 5679, RF 7045, and this one RF
7242 (8.1S2.3)
RF# 7249 First TAP award year in Banner
Problem:
Question: Where in Banner (what form or table) shows the first HESC award year? I thought it might be on
SOIYTRC but I cannot find that information.
Thanks
Response:
In reality, the first year a student receives a TAP award is stored on Banner – however it is not displayed except
on the output for SORYTCE when run in Update Mode.
However, due to you submitting your RF Helpdesk request, SICAS is going to put this in as a programming
upgrade to place the first year student receives TAP (perhaps on SOAYTRO or SOIYTRC). It will go in as a Low
Priority because of our current workload , but it will get in and get done.
Thanks very much for bringing this up.
RF# 7299 SORYDTS Term Code Validation Issues
Problem:
SORYDTS attempts to validate Term Code entry. At some point that validation was broken and new Banner 8
migrations receive that broken validation.
In addition to this problem, future submissions will not all be term based so the process shouldn't be validating this
column any longer.
SORYDTS has the following two issues when used with the new interfaces FADS and SRDS:
1 - The parameter validation for the Submission does not include the new codes.
2 - The Term parameter is validated to codes included on STVTERM. This validation is done both in JOBSUB and
within the SQR.
Response:
SICAS removed the Term Code validation found in the SORYDTS SQR object. The Term Code valid is no longer
validated and has been retitled Batch Period so that the relationship to term is no longer assumed.
SICAS added the FADS and SRDS interface codes to the JOBSUB Parameter validation table and remove the
Parameter Definition validation entry to allow Job Submission to handle FADS and SRDS parameters.
Important Notes:
1) Some campuses have had Term Code validation problems with this process after moving to Banner 8. This RF
should fix those campuses as well.
2) This is a BANNER 8 only Patch. The FADS and SRDS interfaces are not being released for BANNER 7.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
24
RF# 7325 Update new crosswalks and rules and curriculum duplicate check
Problem:
Platform: UNIX
ASC has new rules and crosswalks that need to be added to the report
Response:
New rules and crosswalks have been added to the SICAS ASC process. The report needs to have these new
items added.
A new part of the report contains a duplicate check on curriculum to help assist campuses in correcting these
duplicates. If duplicates are not corrected, then the wrong curriculum may be assigned.
RF# 7329 NY Alert and deceased individuals
Problem:
I recently noticed that SCRYEMG created a file that indicated that a recently deceased student had opted into the
NY Alert program. While that may be technically true, I don't think that the system should call his home phone the
next time that we have a snow day.
Ideally, SCRYEMG would indicate that he had opted out. Or, if that's not possible, it should at least exclude him
from the file.
Response:
Added code BEFORE extraction to scan SPBPERS for deceased individuals and perform the following changes
to the NY-ALERT records as appropriate:
1 - We always mark the SCBYNYA records so that the individual is OPT OUT.
2 - On Full Update runs we mark the SORYWSP record INACTIVE.
3 - On Update we leave SORYWSP alone so the OPT OUT will be sent as an update.
RF# 7343 TAP Q&A refers to Good Cause
Problem:
TAP Q&A refers to "Good Cause" for continuing students in the Spring 2011.
Create GTVSDAX Entry
Code: GOOD
Group: SICAS_CAUSE
Initially set to 'N'
If campuses decide to run using Good Cause switch external code on the GTVSDAX entry to 'Y' and re-run the
processes.
Response:
Made changes with several objects for TAP Q&A to "Good Cause" for continuing students in the Spring 2011.
RF# 7376 Sicas Center Banner to Aleph Process
Problem:
On SORYULE I added in a verification for the SORYIDS_YIDS_CODE “07”. We want the verification for this to be
SSN, so I selected SSN from SPBPERS in the rules section for the SQL. Now with this in place SSN should be
showing up in the PLIF instead of the “+” for verification for the type “07”, correct?
So far It has not been, and I have been becoming increasingly confused! I deleted everything from SORYLID, and
SORYIDS, and started over and it still didn’t show up instead of the “+”.
Response:
Also resolves RF7154
Modified SQR to avoid setting variables to '' and using "not null" and "is not null" comparisons. Set variables to '**'
and did comparisons on this value. Newer versions of SQR seem to be handling '' and null differently. Also, &
variables set by SELECT statements within SQR do not seem to be initialized to NULL because checks for "not
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
25
null" or "is null" don't seem to work if the select statement does not return a value (not found condition).
Campus is at SQR 8.5 release.
RF# 7416 SIRIS Multiple Enhancements
Problem:
Multiple Enhancements to the tools used to support SIRIS programming require modifications in support of SIRIS
Interfaces in modules other than STUDENT.
This patch prepares the SIRIS related tools for the Financial Aid (FAISMGR) submission (FADS) and Student
Revenue (ARSYS) submission (SRDS).
Some enhancements also improve existing SIRIS interfaces but many will not impact the existing interfaces at all.
Response:
The required enhancements have been completed and released to keep existing SIRIS applications in sync with
the new FADS and SRDS submissions.
These changes include:
New shared error processing routines provided to support their use from Java transmission objects. These calls
are not currently used in CDS, SDS and TSDS interfaces.
New logic for processing returned person SUNY IDs; new IDs are reported in a DEBUG message as an update;
returned IDs that match the existing ID on file are NOT reported in DEBUG messages and returned IDs that DO
NOT match the ID on file are reported with a Warning message. This change is implemented in SDS and TSDS
interfaces. CDS does not return person SUNY IDs.
Error and Debug messages that reported the SOAYDTI form as the location to review configuration now report
the Main Module version of that form. This means that Student Module interfaces (CDS, SDS, TSDS and
eventually DADS will still report SOAYDTI); FADS will report ROAYDTI and SRDS will report TOAYDTI.
Note that SQL changes to STVYINF table allow interfaces to appear on multiple forms (FADS will ship with an
optional script to place the interface on both SOAYDTI and ROAYDTI) but the form reported will remain the
primary module form for the interface.
Default handling fixes have been applied to the SFKYCVTS package allowing crosswalks with appropriate
DEFAULT values to use the default for uncrosswalked values WITHOUT recording a conversion error. Crosswalk
items with DEFAULT values do not have to be fully crosswalked to avoid conversion errors. This effects all active
interfaces.
RF# 7492 Missing IPEDs Part A Field 02b
Problem:
Last year IPEDS asked for five groups in Part A: Establishing Your Groups. This year IPEDS has asked for six
groups under Part A. Below is a list of all six groups. The output for SSRYSFA (see attached) is missing the
number of students for Group 02b.....
01. Group 1 All undergraduate students enrolled in Fall 2009
02. Group 2 Of those in Group 1, those who are full-time, first-time degree/certificate-seeking
02a. Of those in Group 2, those who received any Federal Work Study, loans to students, or grant or scholarship
aid from the federal government, state/local government, the institution, or other sources known to the institution
02b.Of those in Group 2, those who received any loans to students or grant or scholarship aid from the federal
government, state/local government, or the institution
03. Group 3 Of those in Group 2, those paid the in-state or in-district tuition rate who received grant or scholarship
aid from the federal government, state/local government, or the institution. Exclude other sources of grants.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
26
04. Group 4 Of those in Group 2, those paid the in-state or in-district tuition rate who received Title IV federal
student aid
Response:
1. Added codes in the SFAS_REPORT1 procedure to meet IPEDs Part A field 02b.
RF# 7522 Multiple SIRIS fixes
Problem:
Is race information updated for all students when SDS is run in TU mode or only for students who are not
"SUCCESS"?
A second problem from RF#7515 (TSDS includes students that did not remain enrolled through the Census Date)
has been combined with this problem report. The original text for that Problem is:
We are experiencing a TSDS 'Grade Earned is Invalid' message on courses having a dropped (DC) status. The
'Gradable Indicator' flag is not checked on STVRSTS for our DC status. Should our DC courses have a grade?
We also noticed that courses dropped prior to census date are being included in TSDS. Does TSDS use the
same logic as SDS to exclude these courses?
TSDS also has had an issue reporting MEETS SAME TIME AS courses; some courses would report their own
course reference as a simultaneous section.
Response:
***THE BANNER 8 VERSION OF THIS PATCH IS DEPENDENT ON RF7416. ***
Race, Disability and Criteria cursors all seem to select without regard for the Submit Status. The following
changes have been made:
1 - The c_Race cursor has been updated to only return records for READY Students
2 - c_Disability required two patches (one on each table in the UNION select)
3 - c_Criteria and c_Criteria2 were both updated (two different mods were needed)
The DELETE statements that remove SORYSDS records prior to Race, Disability and Criteria insert loops were
altered to only remove records related to a READY student record (in SOBYSDS).
These changes, taken together, should prevent changes (removals or additions) from being performed for
Students that are not set to READY. Since TU operations leave SUCCESS students alone, now these repeating
table routine will also ignore the repeating records related to those students.
RF#7515 reported that TSDS included students who were not enrolled through the census date for the section.
Previous versions of the package contained the commented out code to implement that filter on the list of
students. The code was returned to the cursor and the census date parameter was set to NULL (this becomes the
end of time) and the following parameter was set to tell the function to ignore the census date--this is the SDSEOT method for screening students.
This should correct the list of students so that those reported on SDS-EOT will also be reported in TSDS.
Changed the logic that is used to select the Student earned grade so that it selects the grade code from
SHAGRDE with the maximum effective term. The code was selecting multiple grades from SHAGRDE if they
were present. Some campuses have multiple entries for the same letter grade.
Added element Stu GradNR that will send a grade of NR for all courses that have not been graded. Set the
process method to "force to Null" if your campus does not wish to default missing grades to NR.
Meets Same Time As logic corrected so that the other section ID is always reported. This may correct
UNKNOWN errors related to some simultaneous use marked sections.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
27
RF# 7550 ASC Fixes and Enhancements
Problem:
Errors are not returned when SAPYASC sqr is executed.
Process needed to migrate data from APC to ASC table.
Former name not properly handled.
Database procedure py_ASCMigrate needs to be dropped.
Common application phone number larger than column in SABYASC.
Response:
The SAPYASC sqr program now accepts the return error message from the SSKYLASC package. In SSKYLASC,
logic has been wrapped to prevent further processing when an error occurs. The returned error code will assist in
trouble-shooting errors.
RF 7152
New process SAPYASM sqr to migrate data from the SABYAPC table to the new SABYASC table. A script to
alter the SABYASC table is provided to increase columns for data from SABYAPC that is larger than allowed.
W.A.R.N.I.N.G. - SAPYASM sqr should only be run when the old APC process is no longer being executed. This
process can only be run one time to migrate the data. Additional runs will not migrate any data.
In the post migration steps, the former name was not being properly extracted. Corrected logic.
Script added to drop deprecated procedure py_ASCMigrate
RF 7545
Script is provided to adjust the phone column for common application phone length. Increased field size for phone
numbers on SAAYASC. Also increased address columns for Web Applications.
Made cosmetic changes on the SAAYASC form to better match the widths of fields on SPAIDEN.
RF# 7575 RF#7036
Problem:
Original Problem for RF#7036
------------------------------------------------------------------The question set code in Health Display is not showing our data correctly. I have attached the code we have in
this seq no. 141. THe Mantoux result is stored in the spryhis table and because the formula is looking at spbyimm
table, we get an * in the display even though the student has a result. When we tried to modify the code, we had
issues. I noticed the SPBYIMM_TB_COMPLIANCE is still stored in SPBYIMM, but the SPBYIMM_MANTOUX
DATE and MANTOUX result are in SPRYHIS with a shryhis_sryhis_yhis_code of TB. Can someone explain?
------------------------------------------------------------------We put the Defect 8S7036 patch into test. I looked at some students, but they still have a blank in SPBYIMM
resulting in still having the * display.
The patch states
"Added a new procedure named py_SPBYIMM_sync_SPRYHIS to sync the legacy columns in SPBYIMM after
SPRYHIS records are altered. This will initially be called only by the SPAYHIS form when the user saves data."
So what about the students who are already in SPBYIMM with blank fields? Is there a process to update them?
Response:
The original patch corrected the objects involved so that future edits would not create students with mismatch
between SPAYIMM and SPAYHIS forms. It did not attempt to correct existing records with issues created by the
bug.
This patch replaces the patch for RF#7036. It contains the same version of the SPAYHIS form (so that this patch
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
28
can fully replace the prior patch which will be made obsolete).
Changes have been made to the py_SPBYIMM_sync_SPRYHIS procedure to correct a problem found during
testing--duplicate records caused that procedure to fail. The procedure is now tolerant of duplicate records on
SPAYHIS.
An iSPBYIMM script is included which will update ALL SPBYIMM records during the installation so that records
left out of sync by the old version of the form will be corrected by the installation of the patch.
RF# 7597 Missing Entries in SABYASC
Problem:
I was wondering if someone could help me find a way to re-load records and get an entry pushed into SABYASC.
We have approx 151 applications from ASC that don't have a corresponding SABYASC entry. I tried running the
SABYASC process to "Post" entries but either I've got my timing wrong, or I'm missing something. We've had a
few batches of files loaded now after we applied patch, and I think it's these individuals who are missing their
SABYASC records. I'm still researching but I'd like to work with someone who can assist me with getting this
resolved.
Response:
The SICAS SAPYASC process should always be run in "P" mode before running the baseline EDI Purge process
SARETPG. SAPYASC is dependent on the EDI processing table to crosswalk the AIDM to the PIDM.
Created new process SAPYASX.SQR that can be run in Audit and Update modes. When run, it will look for a
matching SSN number. There is a count on the report. If the count is greater than 1, then the SAPYASX should
not be run in Update mode.
A form has been created called SAAYASX. This form is used to assign the pidm to the ASC record. A LOV is
available to select the pidm. This form can be used to assign the pidms when there is a count greater than 1 in
the SAPYASX report.
When the records with counts greater than 1 have been resolved on SAAYASX, SAPYASX can be run again in
Update mode. The post processing will be done, the records removed from the SATYASC table and SABYASC
table will be populated.
If an error is incountered, processing will stop and the error will be sent to the report.
Review RF#7652 for a list of required ASC patches.
When SARETPG.PC is executed the Admissions EDI processing tables are cleared. The SICAS SAPYASC.SQR
process migrates the data from SATYASC to SABYASC. It is dependent on vlaues in the Admissions EDI
processing tables. SAPYASC will not pick up any records.
The correct this error in the job stream, SAPYASX.SQR has been created to address this. It is not dependent on
the Admissions EDI processing tables.
The Job Stream for ASC processing is as follows:
1. Run GOPYLOD to load the Application Flat file.
2. Review Reports for errors.
3. Run SARETMT batch process to verify and push the application.
4. Use the SAAEAPS form to manually push applicants or applicants suspended after running SARETMT.
5. Run SAPYASC which will do post steps and migrate data to SAAYASC.
6. Run SARETPG to purge applications from the Admissions EDI processing tables.
Migration Solution:
In the event that SARETPG was executed before SAPYASC, SAPYASC will not be able to process the post steps
or migrate the data to SAAYASC. To correct this problem follow these steps:
1. Run SAPYASX in Audit mode.
2. Review report for match counts greater than 1.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
29
a. If there are counts greater than 1, then use the SAAYASX form to manually assign the pidm to the SATYASC
record.
3. Once the duplicate matches have been corrected on SAYYASX, re-run SAPYASX once more in Update mode
(or you can re-run in Audit as many times as needed) to do the post steps and migrate the data to SAAYASC.
Both SAPYASC and SAPYASX will stop processing when an Error is encountered. Most causes are due to setup
problems. Correct any setup problems and re-run. If errors continue then submit a problem report on the SICAS
web site.
Thank you to Fredonia in their assistance in testing this solution.
NOTE: On SAAERUL, Group YGRP, a new rule has been added with the Label "FOLKRELT" that requires a
relationship code. The Banner code you enter needs to be a valid code on STVRELT. This code is used on
SOAFOLK to identify what type of relation the person is to the student. This record needs to be manually entered
on SAAERUL. It is not inserted by the RF.
RF# 7612 8s7575 Install Fails
Problem:
Original Problem for RF#7036
------------------------------------------------------------------The question set code in Health Display is not showing our data correctly. I have attached the code we have in
this seq no. 141. THe Mantoux result is stored in the spryhis table and because the formula is looking at spbyimm
table, we get an * in the display even though the student has a result. When we tried to modify the code, we had
issues. I noticed the SPBYIMM_TB_COMPLIANCE is still stored in SPBYIMM, but the SPBYIMM_MANTOUX
DATE and MANTOUX result are in SPRYHIS with a shryhis_sryhis_yhis_code of TB. Can someone explain?
------------------------------------------------------------------RF#7575 addressed old data problems but when used against database with duplicate entries for SPAYHIS on
the same DAY they had the following error:
Step 6 of the 8s7575 install fails with the following error message:
Running ispbyimm_7575
DECLARE
*
ERROR at line 1:
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at "BANINST1.SGKYIMM", line 2760
ORA-06512: at line 7
Response:
Corrected another place in the package where duplicate SPRYHIS records on the same day cause a problem
when synchronizing the SPBYIMM table.
Added the SPAYHIS and iSPBYIMM script into this patch so that RF#7575 becomes obsolete and only this patch
needs to be applied.
RF#7036 was the initial problem report for this patch.
RF# 7659 STVYTTY didn't have a Primary Key
Problem:
Reported Severity: Production Medium
Object Locally Modified: No
STVYTTY didn't have a Primary Key
Response:
Create script to drop Primary Key and recreate on this table.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
30
RF# 7801 FZ_ANGEL_PW function has PL/SQL error
Problem:
This is a problem at Banner 8 only.
The following error is encountered when selecting information using angel view SFVYFAC at Maritime.
ORA-20100: ERROR occurred in LOCAL campus function: fz_angel_pw. ORA-06502: PL/SQL: numeric or value
error: character string buffer too small ORA-06512: at "BANINST1.FZ_ANGEL_PW", line 89 ORA-20100: ERROR
occurred in LOCAL campus function: fz_angel_pw. ORA-06502: PL/SQL: numeric or value error: character string
buffer too small ORA-06512: at "BANINST1.FZ_ANGEL_PW", line 89
Response:
Modified fz_angel_pw function to substring GORPAUD_PIN to 15 characters from 256 characters to avoid
receiving PL/SQL numeric/value error.
***NOTE***
This RF only needs to be installed if the campus is using the SICAS Code for the fz_angel_pw function which
selects the GORPAUD_PIN for the ANGEL password. If the campus has written their own code for this function,
this RF does not have to be installed. If the campus wants the SICAS code for the fz_angel_pw function to take
affect, the function must be dropped before installing this patch so the function will be created new again with the
fix.
This function is shipped in szfyangl.sql. This script contains other Angel functions that have already been created,
so when installing this, there will be errors that the functions already exist. This is ok because SICAS ships these
local functions as CREATE rather than CREATE or REPLACE to avoid wiping out any modifications that may
have been made by the campus to the local functions.
RF# 7806 Building and Room data not updating in TSDS
Problem:
The building and room information is not updating in the TSDS submission and is causing a fatal error on every
section.
Response:
The Building and Room elements now properly access SECTION BASE data when execution of SQL (due to
SELECT MOD or Force to NULL operation). This frees campuses to replicate and modify the record.
New elements named Building2 and Room2 have been created. These will update Building and Room entries to
NULL when location is not On-Campus (001).
Community Colleges are best served by setting Building and Room Process Methods to "Force to NULL" and set
the Building2 and Room2 Process Methods to "Use Existing".
RF# 7822 Multiple SIRIS fixes
Problem:
1. After having SICAS patches including 7806,7522 and 7416 installed on PROD over the weekend, I am now
getting the following XML error when running SDS ESS in TU mode.
ORA-20906: Web Service failed on: ORA-31011: XML parsing failed
ORA-19202: Error occurred in XML processing
LPX-00235: invalid XML version, must be 1.0 or 2.0
ORA-31011: XML parsing failed
ORA-19202: Error occurred in XML processing
LPX-00210: expected '<' instead of 's'
Error at line 1
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
31
2. Disability codes are being duplicated during the SDS transmission.
Response:
Added line to detect shorting of the new XML Tag (multi-byte char counting problem) and correct tag when it is
not correctly formed.
RF# 7912 Multiple ASC Fixes
Problem:
py_PT-20100ORA-20100: ::Cannot find record using primary or unique key::
Is there a way to bypass a record when running the sapyasc process? Otherwise all further processing is halted
until the error is corrected....and we don't know what the issue is specifically so it will take time to get to the
bottom.
I beleive that if we delete it off of the saaeaps screen.....we could always come back and reload the tape that this
record came in on.
We are in our test enviornment still catching up to records that were loaded into prod last year prior to the
introduction of SAPYASC. We had one missing patch 86664 and a couple of eruls that weren't defined at the time
that saretmt was run in prod, but do to error handling it ran without error.
We suspect that this is the root of the issue...but need to confirm we don't have an unresolved issue before going
forward and putting the patches into prod. Any assistance that you can provide interpreting and resolving this
error would be appreciated.
Response:
The following error: py_PT-20100ORA-20100: ::Cannot find record using primary or unique key:: was resolved by
correcting the following issues.
1. Fixed SARADAP cursor to use the Term from the application. This fixes the problem with updating the Part/Full
time indicator.
2. Enhanced post processing error handling. Applicants in error will have an error message sent to the report. In
addition, the process will continue
to process the next applicant. Previously, the process would fail.
3. Updated procedure py_Address. If the temporary address and date is expired, the temporary address will not
be loaded.
4. Updated function FY_LOSTONES to produce errors to the report. If a record has an error, send message to
report and continue
to the next record. Previously, the process would fail.
5. Updated procedure py_Orphans to produce errors to the report. If a record has an error, send message to
report and continue to the next record. Previously, the process would fail.
6. Added term code variable to procedure py_Contact that is used in the SARADAP cursor.
7. Updated logic in procedure py_AddressUpdate to handle temporary address end date population problems.
8. Added term code to procedure py_PT that is used in the SARADAP cursor.
9. New procedures and functions used to fix the check list:
a. fy_IsPcol
b. py_UpdatePcol
c. py_UpdateSarchkl
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
32
d. fy_PcolSequence
e. py_ScrubSarchkl
RF# 7930 Multiple SIRIS Fixes
Problem:
1. Need to create a way to block sections with zero enrollment from being sent in TSDS.
2. In TSDS, the type of the SOBYINS_COUNTRY_DEG column in the SOBYINS table is incorrectly defined as a
number column. It should be defined as a VARCAR2 (5).
3. Need to remove course fees for sections where the course fee is a negative value. System admin does not
want these fees and it is causing fatal errors.
4. I just ran TSDS in TU mode and it seems to have updated the data for all records on the TSDS Banner tables
sobystu, sorystu, sorymet and sobyins even though it only transmitted the data which had failure errors to SUNY.
Response:
1. SFKYCVIR Package Body TSDS Submit procedure Section build logic marks empty sections (no listed
enrollment and no enrollment count) as NO-TSDS or DELETE depending on run mode. These sections will be
removed now.
2. Column type changed from NUMBER(3) to VARCHAR2(5). The column was built to hold their values, not the
Banner values we actually collect. Conversion is done as we transmit.
3. TSDS "Sect Fee" element SELECT CODE was changed to only collect Positive Fee amounts. Campuses with
negative fees will need to make sure that they have the funding source set to "State Supported" and not "State
Supported with associated fee."
4. The TSDS process has been corrected so that the data is only updated when a record is being retransmitted.
An error in the SOBYINS1.SQL script forced us to REPOST this patch.
RF# 8045 Checklist items being deleted
Problem:
py_FixCheckList was updated to call a new procedure, py_ScrubSarchkl, which deletes any sarchkl record where
sarchkl_code_value is null (the Item field on the Banner form). This is deleting all of the default items that are
added to the checklist based on the rules set up on SAACHKB.
Also, is there any way for us to disable the whole "fix" checklist processs without going in and commenting out the
code?
Response:
THIS PATCH IS DEPENDENT ON RF7912.
Added two new rules on SAAERUL under the group "YGRP".
New function: CHKLSTCLEAN - will remove unused checklist items for prior college that have the ADMR codes
defined on SAAERUL group=YGRP. A campus may enter "N" to not remove these.
New function: FIXCHKLST that will allow a campus to skip the check list post processing if "N" is entered.
Made a fix in the SSKYLASC package to procedure py_ScrubSarchkl to only remove the ADMR entries defined
on SAAERUL that do not have the prior college SBGI code entry in the value field.
RF# 8063 SFAYLAB - Error Message
Problem:
When creating a new lab code, error message is displayed when attempting to tab to the description field. See
screen shot of error message.
Response:
1. Commented out {go_item('SFRYLAB_YLAC_CODE');} in the WHEN-VALIDATE-ITEM
trigger of SFRYLAB_CODE in the SFRYLAB data block.
Release Notes for Student 8.5S1
_________________________________________________________________________
April 2011
33
RF# 7917 2011-12 NYS Budget Contains 2010 SAP Charts
Problem:
Need to prepare for the new 2010 SAP Charts introduced in the 2011-12 NYS Budget.
To be released once the budget gets passed.
This patch is dependent upon RF #7343.
Response:
Made changes for the new 2010 SAP Charts introduced in the 2011-12 NYS Budget
***NOTE*** This patch can be installed prior to Student 8.5S1. It has been included in Student 8.5S1
and should not be reinstalled after that release. ****