1. |
CCCApply Using SAR189U

2. What is CCCApply?
The California community colleges have been strongly encouraged by the Chancellor’s Office to use CCCApply
It is a single website where applicants can fill out applications to most of the California community colleges
CCCApply asks residency question then determines residency based on responses
There is an annual fee to use CCCApply, but the Chancellor’s Office offers grants to pay for the first few years of a school’s use |

3. CCCApply Website http://www.cccapply.org/ | www.sungardhe.com
Skip Navigation
Skip Navigation
                                                                               
               
                
                                |

4. Loading the applications in Banner
The SAR189U process can be used to load most, but not all, of the data collected by CCCApply
Flat file is loaded to the same temporary tables used by Self Service: Admissions
Once records are in the temporary tables they can be reviewed on SAAEAPS and SAAETBL
Records can be loaded by running SARETMT or by manually pushing the applications on SAAEAPS |

5. File Format
The XAP file follows the standard Postsecondary Electronic Standards Council (PESC) guidelines. |

6. Elements That Will Load
The file will have a header record that includes the sender (CCCApply) and the recipient (the college) address information |

7. Elements That Will Load
Person Data
Birth
Name
AlternateName
Citizenship
Gender
EthnicityRace
International Data
FamilyMember
Address
Phone
Residency
Contact Information
PermanentAddress
TemporaryAddress
OtherAddress
PermanentPhone
TemporaryPhone
OtherPhone
Primary
Other
High School Information
Prior College Information |

8. Elements That Will Load
Application
ApplicationDetail
School
Address
Phone
ApplicationSession (Term)
Major |

9. Elements That Will NOT Load
Residency determination questions
Program
Educational Goal
Education Level
Student Type |

10. Setting Up SAR189U |

11. SAR189U - Implementation 1. Self Service Admissions Validation Forms
Review values on this form:
Application Verification Steps (STVASTA)
Look for “IDVR” – ID Verification
STVAPLS delivered values suffice ‘WEB’ is the relevant one here
STVASTA the rows that are active and have the load indicator set are attached at the time an application is received
STVWSCT consider changing the image, the description does not appear to change what appears on the web - in spite of what is says in Bookshelf
STVWSCF |

12. SAR189U - Implementation 2. Self Service Admissions Validation Forms
Create Application Types in:
Application Type Codes (STVWAPP)
Delivered values are: 00, W1 – W7
Can add additional types
Show how this controls choice when creating new application. |

13. SAR189U –Implementation Steps
2. Self Service Admissions Validation Forms
Review values in these forms:
EDI Rule Groups (STVEGRP)
ADMS, and RESD group codes are the two most used by SAR189U.
Delivered by SunGard Higher Education
EDI Verification Labels (STVXLBL)
Show how this controls choice when creating new application. |

14. SAR189U - Implementation 3. Procedures and Routines - Concepts
To verify that applications are complete
To determine what is loaded
Attach procedures to application types
Attach routines to procedures
Application Type
Attached Procedures
Routines
These determine what data will be verified and loaded into Banner |

15. SAR189U - Implementation 3. Procedures and Routines - Concepts
Procedures and Routines can be:
System required / not system required
Required / not required
Overridden / not overridden
Required routines are attached to the applications when ‘received’ - like an active flag.
For a procedure to be ‘fulfilled’ each of the required routines need to be fulfilled.
Overriden means the process or routine can be manually overriden and the data will not be pushed.
Blank data with an override flag set will be automatically overriden
Be careful about being consistent between what is required and can not be overriden and what is required on the web page.
For example name information is required and not override-able so must be compulsory on the web. |

16. SAR189U - Implementation 3. Procedures and Routines - implementing
Electronic Admissions Procedure / Routine Control Form (SAAECRL)
Create / copy procedures
review for each application type
listed on pages of Chapter 10 of the Banner Student User’s Guide |

17. SAR189U - Implementation Self Service Admissions – Implementation
Always require these procedures; do not allow overrides!
P010 - ID Verification
P020 - Name Verification
P035 - Residency Verification
P040 - Address Verification
P070 - Phone Verification
P120 - Entry Curriculum Verification
P050 - Application Verification
P200 - Data Relationship Procedure
P900 – “PUSH” Verification |

18. SAR189U - Implementation 3. Procedures and Routines - implementing
Do not require these procedures!!!
P060 - Health Conditions (unless question uncommented in Bio page)
P090 - Language Record
P100 - Immunization Record
P135 - High School Subjects
P080 - Religion |

19. SAR189U - Implementation 3. Procedures and Routines - implementing
P032 - International Information
P110 - Activities
P130 - High School
P150 - Test Scores
P140 - Previous College
P142 - Previous College Degrees
P145 - Previous College Majors
Require or not as appropriate to application type; allow overrides! |

20. SAR189U - Implementation 3. Procedures and Routines - implementing
Example - International info (P032)
Application section will not be included for every application type
Do not require the procedure!
Information may not be provided even when the section is included
Allow the procedure to be overridden! |

21. 3. Procedures and Routines - implementing
SAR189U - Implementation
3. Procedures and Routines - implementing
Routines:
R Date of birth
R Ethnicity
R Legacy
R Marital status
R Gender
R Citizenship
R Nation of citizenship
R Native language
R Home language
R Correspondence language
R Edit results |

22. SAR189U - Implementation 3. Procedures and Routines - implementing
Example: Bio info (P030)
Some items (home/correspondence language) are not collected on the Web
Do not require the routine!
Applicants may not supply all data which can be collected
Allow the routine to be overridden! |

23. “PUSH” Verification (P900)
SAR189U - Implementation
3. Procedures and Routines - implementing
“PUSH” Verification (P900)
Must be required/cannot be overridden
Routines may be not required if data is not collected for application type |

24. SAR189U - Implementation 3. Procedures and Routines – implementing
Electronic Application Procedures/ Routines Form (SAAECRL)
Do not delete rules!
Set Required and Override flags as needed
All delivered values are System Required
# of Routines is information |

25. SAR189U - Implementation
4. Electronic Admissions Application Rules (SAAERUL)
Control electronic admissions processing routines
Organized into groups
Modify ‘UPDATE ME’ rows to suit local needs
Rows are listed on pages of Chapter 10 of the Banner Student User’s Guide
Remember that lots of the processing is common with EDI processing. Generally can leave the EDI values as is and do a search on UPDATE ME
Examples include:
whether to accept duplication applications for the same curriculum, level, major etc in a term
and address types to use for stored addresses
how many rows to display for material request etc |

26. SAR189U - Implementation 5. EDI Cross Reference Rules Form (SOAXREF)
Controls availability of validation data
Must have values in EDI, description, and Banner value
Set up rows for address type, telephone type, major
Review values for nation, state, ethnicity,
Listed on pages in Chapter 10 of the Banner Student User’s Guide
Again, shared use with EDI processing:
The main use in Self Service Admissions is to show which values appear on the web.
If you want all values from a validation table to appear then put no values in SOAXREF
If you want some (and there is no Web indicator) add those you want to show to SOAXREF
For a row to be web enabled it must
- either have not values at all on SOAXREF
- be web enabled following the rules above
Scripts are provided to populate the rows from validation data, ie (xrefmajr.sql) |

27. SAR189U - Implementation
6. Enter EDI identification numbers on SOACURR for majors. Use the CCCApply major codes defined on SOAXREF
Table is populated by a script during install, and maintained by triggers
Must be a ‘web enabled’ major, but need not have a valid EDI code
Description is what appears on the web.
Auto student is for QuickStart
Note that only curriculum rules matching the STVWAPP level will be displayed.
Be ware about using non-unique combinations of EDI Degree Level, EDI Field of Study Qualifier, EDI Field of Study Identifier since processing will not be able to distinguish and will use the default values in SAAERUL. |

28. SAR189U - Implementation 7. Set up a default curriculum on SAAWADF
SAR189U loads the major, but not the curriculum
Set up matching and processing rules on SAAWADF |

29. SAR189U – Loading the Applications
Run the SAR189U Process
Parameter 01 File Name
The file must be loaded on the same server as Banner
The file and path name combined cannot exceed 30 characters
Parameter 02 Y to print debug messages
Parameter 03 Application Type from STVWAPP
Parameter 04 Term Code |

30. SAR189U - Admissions Office
Processing Applications
Initial Review (optional)
Electronic Application Process Form (SAAEAPS)
Match Verify and Load
Tape Interface Rules Form (GORCMRL)
Electronic Application Verify / Load (SARETMT) |

31. SAR189U - Admissions Office
Process Suspended Records
Electronic Application Process Form (SAAEAPS)
Match Verify and Load
Checklists / decisions etc in baseline Banner |

32. SAR189U - Managing Data Purging Electronic Applications Data
Electronic Application Purge Process (SARETPG)
purge by Application Source, Application Type, Term, Date, Status |

33. |
Questions and Answers