Issues with S54 Admission Application Import (AAI)

Issues with S54 Admission Application Import (AAI)

SOW’s S540411A (Jan 2005) and S540501A_M (Oct 2005)

created February 9, 2007

last updated July 31, 2007

South Dakota Board of Regents began utilizing the custom Admission Application Import program created by Datatel (Yash Sharma, programmer) in our production environment on August 15, 2006. The custom Admission Application Import program consists of three-delivered mnemonics that will be referenced throughout this doc:

XAID – for setup purposes (no problems with this mnemonic at this time)

XISA – original import process – run students through this process in non-update mode first

XITC – (a custom version of ITCI)- import students in update mode using XITC after resolving possible dups listed during XISA in non-update mode – students who had no duplicate issues are imported via XISA in update mode. In several scenarios below,the problem may occur in XITC but not XISA. Any changes to the import program should be done in both XISA and XITC so they both import students the same way regardless of which mnemonic we use to import in update mode.

An overall view of the Admission Application import process is that datasets for import are dropped off nightly in the S54.APIMP.INBOUND directory on our Colleague production box. Users run XISA to import the dataset in non-update mode. XISA generates three sets of output. Users then run XISA to import the dataset in update mode. If there were records in the dataset that did not import due to possible duplicates, then the user must manually resolve the ambiguity(ies) then import in updatemode using XITC (a custom version of ITCI).

EnrollmentServicesCenter, whose staff runs the AAI import process, has reported the following issues with the AAI program, ie XISA and/or XITC, that will require a programming modification to resolve. Those issues are:

1. Date received does not populate on the HSA screen for the transcript type only when importing via XITC. It does populate correctly when imported through XISA in update

mode.

The following record was loaded through XISA in the update mode:

| 11/09/06 14:01 HIGH SCHOOLS ATTENDED HSA |

| McMahon, Cody J. ID: 1669763 SSN: XXX-XX-XXXX |

| HartfordSD57033-5708Home: 605-528-6293 Acct: X |

|------|

|CEEB/FICE |

| Institution...... : 1109429 WestCentralHigh School 420570 |

| Date Recd Status |

| 1 Transcript Type...: 1: HS Final High Sch11/06/06 NR Not Received |

| 2: PHS Partial High S11/06/06 NR Not Received |

| 2 Years Attended....: 1: 2007 2007 |

| 3 Start/End Dates...: 1: 05/31/0705/31/07 |

| 4 Rank and/or Pct...: / % |

| 5 Graduation Type...: N Not Graduated |

| 6 * Counselor...... :|

| 7 High School GPA...: 3.630 Equivalent Transfer |

| 8 Summary Credits...: |

| Degree/CCDs MM/YR |

| 9 * Acad Credentials: 1: |

| 2: |

| 10 Credentials End Dt:|

| 11 * Comments...... : 1:

The following record was loaded through XITC modein update mode.

------

| 11/09/06 14:25 HIGH SCHOOLS ATTENDED HSA |

| Archambeau, TeAndre M. ID: 1839001 SSN: XXX-XX-XXXX|

| WagnerSD57380 Home: 605-286-3879 Acct: X |

|------|

| CEEB/FICE |

| Institution...... : 1109353 AvonHigh School 420065 |

| Date Recd Status |

| 1 Transcript Type...: 1: HS Final High SchNR Not Received |

|2: PHS Partial High SNR Not Received |

| 2 Years Attended....: 1: 2007 2007 |

| 3 Start/End Dates...: 1: 05/31/07 05/31/07 |

| 4 Rank and/or Pct...:/ % |

| 5 Graduation Type...: |

| 6 * Counselor...... : |

| 7 High School GPA...: Equivalent Transfer |

| 8 Summary Credits...: |

| Degree/CCDs MM/YR |

| 9 * Acad Credentials: 1:|

| 2: |

| 10 Credentials End Dt: |

| 11 * Comments...... : 1:|

Note that the Date Recd column is blank for this particular student, but should not be.

2. XISA run in non-update modenot always generating dup application message when student already has that program/application in Colleague. A student can only have two applications per term per university. For example, if a student has an application for USD already on hand and they have two more coming in on an admission application for BHSU, then both of those applications should import. If the student already had an application in Colleague for both USD and BHSU and two more were coming in on the application admission import for BHSU, then only the first application read could be imported into the Colleague – the other application would generate a message during XISA that is stated as this: “Application skipped – either duplicate or two applications limit reached – program: (name of program) Location: BHSU”.This same message should appear if the admission application import program is attempting to import an exact same application for the exact same term for the exact same school for the same student. Students can have the same application if the applications are in different terms or for different schools. The problem is, on occasion, this message alerting us to a duplicate application is not getting written to the output report generated by XISA when it should.

For example, as shown below students Merkel and McNary both were already in Colleague under the same term and programs as the new incoming applications. Examples are from the batch 14187001 dated 11/03/06.

XISA output:

14187001*17 Chief, Ace Max * had the exception message – in Datatel with a duplicate term and program

14187001*9 Merkel, Michael - duplicate program APPN– no exceptions message

14187001*23 McNary, Jacquelyn - duplicate program APPN – no exceptions message

Here’s the APPN screen for Jacquelyn – note the application dates:

The relevant portion of the import record coming in for Jacquelyn was for USD on 11/3/2006:

063: FA

064: 2007

163: UDHYG

Which according to the translate table:

------

| 07/13/07 14:12 FILE TRANSLATION TABLES FLTT |

| ELF Table: S54.APIMP.PROGRAMS |

|------|

| 1 Description....: Programs Table |

| 2 Orig Code Field: |

| 3 New Code Field.: APPL.ACAD.PROGRAM |

| |

| Special Processing Fields |

| 4 * Orig Code New Code Field 1 Field 2 |

| 31: UDCOM U.BA.DCOM |

| 32: UDHYG U.NODEG.P-DNH |

translates UDHYG to U.NODEG.P-DNH when it imports into Colleague. From the APPN screen above, we can see she had this exact same app for the same term, 2007FA, on 10/30/06 but this app was processed days later on 11/3/06; yet when we ran XISA in non-update mode XISA did not list that this was a possible duplicate application and it should have.

3. Type not populated for Alternate ID’s on the DADD screen. We originally requested that the AAI program not only import an alternate id, but also the corresponding type on the DADD screen.

In the above example of an alternate id brought in by the AAI program, staff at the Enrollment Services Center (ESC) had to manually populate the type UXPR for each student imported by this program from the Princeton Review, now known as Embark. We would like the AAI program to import the value UXPR alternate id type for alternate id’s whose types starts with UP. Would that last rule best be accomplished with a translate table on FLTT whereby we would look at the value of field 1, in this case, UP, then on FLTT map UP to alt id type UXPR to be used on this screen? This could be hardcoded in your program, but then if/when we add a new vendor to import data from we would have to modify the import program again. If we add a new translate table, then we could just add the new entry on the translate table. A possible new name for the translate table might be S54.APIMP.VENDORS.

We were told automatically importing the alt id type was not possible since that field was not part of the ELF intermediate file specs. Answernet doc 9935.37 –(INTER.BIODEMO needs to have ALT.ID.TYPES)has a possible workaround to this problem listed so we would like to evaluate/consider implementing the workaround if it would not negatively affect how our system is currently setup and working.

4. TS transfer status not correctly calculated when importing via XITC.

A) In the following example, student Steiner listed the following information on her undergrad admission app:

inst attend: 003466 9/1996 – 5/2000

these values can be seen in fields 208-215 of her import record:

163: UNURS  app coming in for USD – know this because she lists a major for USD

208: 003466

209:

210:

211:

212: 09

213: 1996

214: 05

215: 2000

However, the Admit Status the AAI program assigned to her is T but should be TS:

According to the original AAI specs, if a student had previously attended any SD Regental school,FICE codes 003459(BHSU), 003466(NSU), 003474(USD), 003463(DSU), 003471(SDSU) or 003470(SDSMT), and the previous SD Regental school attended is not the same as the one the app is for, then the AAI program should assign an admit status of TS for transfer in-state instead of T as it did for this student. In this case, the student’s app is coming in for USD (import field 163) but she listed she had already attended NSU (field 208) so the Admit Status should be TS since she is transferring between SD Regental institutions (transferring in between 03466 to 03471).

B) Related to item 4A is the problem that some students answer yes to the questions “Did you previously attend BHSU, DSU, SDSMT, NSU, SDSU, or USD…”, then later in the app fail to list that same institution in the institutions attended section (where they can list up to 12 inst’s attended), which is the same section checked for the TS status in 4A. Therefore, if the student does not list that they attended 003459(BHSU), 003466(NSU), 003474(USD), 003463(DSU), 003471(SDSU) or 003470(SDSMT) in any of the 12 institutions attended fields (fields 207, 217, 227, 237, 247, 257, 267, 277, 287, 297, 307, 317), then the import program logic should next check to see if they answered Yes to any of the “…previously attended SD…” fields questions (fields 95, 106, 117, 128, 150, 176). If they did answer Yes to at least one of the “…previously attended SD schools…” fields, and checking the dates that is the last school they attended, then the TS status should be calculated for that student. If they did answer Yes to at least one of the “…previously attended SD schools…” fields, but according to the dates attended they attended another non-SD specific school in between (not one of the six FICE codes), then the status should NOT be TS.

5. Change DD portion of MMDDYY date for end dates for Spring on INAT screen.

There is a section of code in the AAI program that says if the institutions attend dates are for

Spring – then the start DD date should be 01 and the end DD date should be 31,

Summer – then the start DD date should be 01 and the end DD date should be 31,

Fall – then the start DD date should be 01 and the end DD date should be 31.

In the above example, the student attended school in Fall so their import record has these values:

208: 003466

209:

210:

211:

212: 09

213: 1996

214: 05

215: 2000

So according to the above, their start and end dates on INAT should be 9/1/1996 thru 5/31/2000. This change probably needs to be made in both XISA and XITC.

6. SPEC.SPEC application records created by the XISA in update mode should have an admit status of SP (for special). XISA created the following application of U.SPEC for student Lindahl:

Any application coming in as a SPEC.SPEC, ex. B.SPEC.SPEC, D.SPEC.SPEC, M.SPEC.SPEC, N.SPEC.SPEC, S.SPEC.SPEC or U.SPEC.SPEC, should set the admit statusto S for Special, not T for Transfer as was assigned above, AND the educational goal fieldshould be set to SP for special, not BA as was assigned above.

7. Need to have Graduation Type field on HSA auto-populate to N for every student imported. Field INSTA.GRAD.TYPE on the HSA screen should auto populate to the value of N for each record created for every student in the AAI import load UNLESS there is already a value in that field, then the import program should not do anything and leave the existing value in INSTA.GRAD.TYPE alone, ie not overwrite it. Here’s the screen/field for this item to be populated:

This change should be made to both XISA and XITC.

8. Students who indicate they have a GED (import layout field 192) are having their institution listed correctly on the HSA screen; however, the Transcript Type field for that record on the HSA screen should populate with the value of GED but is currently populating with the value HS.

Students import record looks like this:

192: 960000

193: 05

194: 1995

195:

When this student’s record was imported via XITC, the HSA record created by the AAI import program looks like this:

Anytime the institution coming in is GED, FICE code 960000 in field 192 of the record import layout,the transcript type should be GED.

9. A student had a middle initial populate via XITC in the Other LFM field on BIO, but the student did not fill in any Other Name information on the app other than the first name, middle name, and last name so nothing should have populated for this field. Here are the other name fields that came in on the record import layout for this student:

Top of "pts/136_0_values.in.line#6" in "AE_COMS", 355 lines, 646 characters.

001: PR

002: 7211083

003: Barse

004: Cody

005: Arthur

006: xxx-xx-xxxx

007:

008:

009:

According to the app import record layout, other/preferred name would be in fields 7, 8 and 9, which are empty, so why did the app import program put an A in the Other LFM field on BIO?

10. Mail Pref and Pref Res not populating correctly via XITC for LOC address type on ADR for some students. Here’s how this students addresses looked on the application import record:

Top of "pts/136_0_values.in.line#8" in "AE_COMS", 355 lines, 724 characters.

001: PR

002: 31006389

003: Jackson

004: Jamie

005: Lee

006: xxx-xx-xxxx

007:

008:

009:

010: Jamie

011: 09

012: 17

013: xxxx

014: 202 E. Rogers St.  start of perm address/phone info

015:

016: Bison

017: SD

018: 57620

019: US

020: 605

021: 2445997  end of perm address/phone info

022: CLB-13 TS Detachment  start of current address/phone info section

023: Box 555707

024: CampPendleton

025: CA

026: 92055

027: US

028: 760

029: 4968228  end of current address/phone info section

030: 760

031: 7631771

032: BUS

033:

034:

035:

036: Landphere

037: Glenda

038: MO

039:

040:

046: US  start of emergency information section

047: US

048: US

049: N

050: SD

051: PER

052:

053: Y

054: Y

055: Y

According to the specs for the original import program:

- If there is a permanent (HOM) address only, populate Fields 7 & 8Mail Pref & Pref Res with Y's.

- If there is a permanent (HOM)and a local (LOC) address, then the localADR fields 7 and 8 should be populated with Y'.

- If the permanent, local and emergency addresses are all the same, ADR fields 7 & 8 should be populated with 'Y' for the permanent address.

Stated another way, the thought process that mirrors current functionality in Colleague is:

• Upon data entry of an applicant’s address, the “Y” is entered on Mail Pref and Pref Res of the ADSU screen when the applicant has indicated that theaddress is their permanent address (coded as HOM). The “Y” willautomatically populate when you update the screen if only one ADRrecord is populated.

If a current address (coded as LOC) is listed on the application and itis different than that of the permanent address, the current addressis then considered to be the preferred mailing address. Mail Pref and Pref Res Fields #7 and #8 are manually updated to 'Y'.

If an emergency address (coded as FAM) is listed on the application and isdifferent than both the permanent (HOM) and current (LOC) thenMail Pref and Pref Res fields #7 and #8 are N’s for the emergency address

11. Need to add a field to the application for a student to indicate their interest in teacher education so we can import that into Colleague for reporting purposes. This value sent by the vendor in field 356 will be imported as is to the SPIR screen in the Recruited For field and the date of the import will be imported into the Date field:

Note that we would like to add 19 additional fields like this that all behave the same, 20 fields total, where if there is a code value in any of the 20 fields, the code and date for those fields will import to SPIR. We will add these 20 additional fields to the end of the AAI import layout in fields 356-375.

12. When pulling up the XAID screen in R18, we receive a message about Legacy record id that we did not when pulling the screen up in R17:

It appears that we can click on OK and then should be able to change items on the screen. We change this screen yearly so is not one we change a lot.