CALPADS Know-It-All

CALPADS references exit code E150 be used in the event that a student enrollment has a grade level change.  So for example, a student who started the 14-15 year enrolled in 5th grade, after three weeks was assessed and determined to go back down to 4th grade, and the "Change Grade/Program" tool used to make that grade level change.

As you know, the "Change Grade/Program is one tool, but does two different functions (change Grade and/or change program).  Regardless of which option the user chooses, we always exit that enrollment record with an IRIS-1 exit code.

1. Change Grade Level:  In the described example above, let's say that the user has change grade level from 5th back to 4th.  The tool will exit the 5th grade enrollment on X date with an IRIS-1 and start a new row/record for 4th grade effective the next available in-session date.
   • Problem:  Yes, if you leave the IRIS-1 exit code, the tool will not export the expected E150 code.  CALPADS expects an E150 here.
   • Solution:  Edit the enrollment record to adjust the IRIS-1 to the E150.  The export script isn't set up to automatically pull the E150 in the event that a grade level change has occurred with an IRIS-1 exit code.  We may have an automated solution at a later time.
2. Change enrollment program:  This is the other path that the tool can take the user.  In this scenario, CALPADS does not care to report on program changes.
   • Problem:  No.
   • Solution:  Do nothing and leave the IRIS-1 exit code.  Please DO NOT replace the IRIS-1 with some other exit code or blank the exit code, because it will break our backend logic.  The IRIS-1 exit is a special code we've designed that needs to be in place so that we know that although the enrollment is broken, it still is continuous.

These codes can be managed in Code Management table called "Transfer Districts."  Once this is complete the student transfer record can be edited in Illuminate through Students > Transfer Details. See our Create a New Transfer Record help document for reference on adding transfer records.

How this translates to CALPADS and SENR District of Residence (1.32):

a. Interdistrict transfer:  Because Transfer Districts are from code management, please review your Transfer District code set.  Please ensure that the Transfer District code has a the 7 digit County-District code for in the State ID Mapping area, for the academic year of concern.

b. Intradistrict transfer:  In the event that the From school is your internal school, the 7 digit County-District code from the "From" school will export.  Please ensure that your From school has a complete 14 digit CDS code for the "State Site ID" field.

To successfully flag SENR field 1.30 (identifying if a student has met A-G) per student, the export is dependent on three things:

1. On the demographic details page, all students must have the Graduation Requirement Year populated.
2. "Met A-G Requirements" Y/N override is applied on Demographic Details page. If no override has been applied, then #3.
3. A Course Requirement must be created for the academic year in which that student is graduating.  In addition, the course requirement name must start with "CSU/UC Requirements".  We're very specific on the name and so anything else (ie. UC/CSU....) will not work.
   Within this requirement from step 1, you can create categories.  You should create a category for each letter (A-G).  If you're not sure about what each letter/subject means, please review the following link to the University of California A-G Requirements page (http://www.ucop.edu/agguide/a-g-requirements/).  Once your categories are created, within each category, you affiliate those CSU/UC courses from your course catalog that apply to that category.  For example, within your "A" category (History/Social Science), you'd want to affiliate all UC/CSU approved History/SS courses from your catalog.

The student based on their Graduation Requirement Year, will be applied to the matching CSU/UC requirement.  If the student has met all categories (A-G), then the export will produce the Y for field 1.30.  Otherwise, the student defaults to N for field 1.30.

For information about course requirements, see our Grad Requirements and Transcript Readiness, Course Requirements, and Add Courses to a Course Requirement Category help documentation.

6 new fields were added to the SENR extract per CALPADS updates:

• Postsecondary/Transition Status Indicator
• Workforce Readiness (Strategic Skills) Certificate Program Completion Indicator
• Food Handler Certification Program Completion Indicator
• Pre-Apprenticeship Certification Program Completion Indicator
• Pre-Apprenticeship Program (non-certified) Completion Indicator
• State or Federal Job Program Completion Indicator

These new fields are visible on the Student Demographics page:

Back to Top

Currently, only 2 attributes are being tied to a student to assign a SED status in Illuminate. California disaggregates the data with additional attributes that then affiliate the SED status to the student, thus giving a different number than what you see in Illuminate.

Academic year specific programs:  Some programs are specific to only that academic year of reporting.  For example, Lunch program (free or reduced) data is one of those that CALPADS expects to start & end within each year and they don't want the data to overlap many years.  Makes sense because F/R lunch generally requires re-evaluation, etc.  So for this reason, the F/R lunch program export script to pull a lunch record only based on the current year's enrollment dates. 

• The following programs are academic-year specific programs: Free Lunch Program (181), Reduced Lunch Program (182), Transitional Kindergarten Program (185)

1. For example, the screenshot above shows student 61042 with a Free Lunch program starting on 10/03/2011.
2. When generating an SPRG for the 14-15 year, the export produces the Free Lunch program (181) with the Start Date (7/01/2014) to End Date (6/30/2015).
3. When you cross reference enrollment, the export is exporting the 2014-2015 enrollment Entry Date for the program Start Date and assumed Term End Date for the program End Date.

Continuous Programs:  Contrary to academic-year specific programs, you have for example the 504 program (101) that is continuous and doesn't necessarily need to be closed out every year.  CALPADS expects that as soon as a student leaves a school and starts a new school, then the program should also reflect that change.  So when you generate an SPRG today, we make an attempt to pull Start/End dates as far back as possible, comparing the program dates with enrollment.

• Here are a few examples of continuous programs: Migrant Ed Program (135), Title I Part A Basic (122), GATE (127), 504 Program (101), Homeless Program (191).

1. If you reference the student 62064 who has a current GATE program effective 8/11/2010.
2. When generating the SPRG for 14-15, the GATE program record exports a Start Date of 8/8/2012.
3. Comparing this Start Date with the student's enrollment and based on the student's current school, the student was continuously enrolled in that school back to 8/8/2012.  Although the student started GATE while enrolled in Elementary, the export will not pull the exact Start Date from the program record.  This rule is to adhere to CALPADS current way of storing program data (School > Program > Start Date > End Date).

• Because enrollment is closely tied to programs, exit codes make a big impact on whether a program is continuous or true break.  If a valid CALPADS exit code (other than IRIS-1, E150, and E155) is used to end/close an enrollment record, the exit code breaks the enrollment and the program Start Date may be different.  Only those exit codes determine that an enrollment/program is continuous and possibly goes back further.

You uploaded your SPRG data to CALPADS and WHAM!  You received hundreds of errors back from CALPADS complaining about an "Open Education Program record exists with Different Membership Start Date".  In looking closer, Illuminate is producing a program start date for the student(s) that is doesn't match the current open program record in CALPADS.

If you've got a small number of errors, you can make manual edit of the students' current program in CALPADS.  However, please be extremely careful that you edit the program End Date accordingly.

Special Ed historical data is not stored in Illuminate. If a student disability changes, you would go to the Student Special Ed page and change the start date to reflect the start date of the new disability.  We encourage our clients who are not using our SPED product to store historical special ed data in the system they are using, such as SEIS for example.



If you need to track disability changes for special ed students in Illuminate, you can use Student Programs to track that information. Student Programs would reflect historical start/end dates for all disability changes for a student. Please NOTE that student programs does not report special ed data to CALPADS.

Best practice is recommended to be the following:

1. To put the original Disability and start date & End Date in the Spec Ed tab for that student.
2. Enter the new IEP/Disability in the Spec Ed tab.

Back to Top

In the event that a student's English Prof. = EO, then we will export the following dates (whichever comes first, and we will use that date to compare).

1. State School Entry Date (Language details page)
2. US Entry Date (Language details page)
3. US School Entry Date (Language details page)
4. District Enter Date (demographic details page)
5. School Enter Date (demographic details page)

So for example, if you generate a SELA report using the dates of 8/15/2014 - 11/17/2014.

1. Does the student have a State School Entry Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and State School Entry Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

2. Does the student have a US Entry Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and US Entry Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

3. Does the student have a US School Entry Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and US School Entry Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

4. Does the student have a District Enter Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and District Enter Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

5. Does the student have a School Enter Date?  If blank, the tool moves to the next field.  Otherwise if Yes, then does this date fall within the SELA report Start/End dates? If the date falls between, the student exports with the EO status and School Enter Date as the SELA Effective Start Date.  If the date does not fall between, the student is excluded from this export.

Concern 1: This will mean that the exports will not include an EO student who has a State School Entry Date of, for example 8/1/2005.  This student is new to my district this year and I need to submit the student's EO status.

Basically, if the student truly has a State School Entry Date of 8/1/2005, that first CA district who enrolled that student in 2005, should have added the status for the student.  If not and the student somehow never had a status reported, then please ensure that the student has a State School Entry Date populated in Illuminate, that falls within your report date range.

Concern 2:  I see within CALPADS, that the student currently has an EO status effective X date that is owned by District 1.  But doesn't CALPADS require/need that I add an EO record for my district/LEA, with a new effective date?

CALPADS currently only allows for one EO status, regardless of which LEA owns that EO record in CALPADS.  CALPADS will NOT allow you to add a new EO record that is owned by you, if that status already is present.  Oddly, CALPADS is a bit buggy too in that you may actually find some student scenarios where there are overlapping same status, from different districts/owners.

Concern 3: So it seems that this logic should only pull new EO students, such as TKs and Kinders?

That's correct.  If you think about it for example, a new Kinder student should have a State School Entry Date that is pretty recent.  If the student started Kinder with you on 8/25/2014, then most definitely the State School Entry Date should be equal to that (or somewhere within range).  Having a State School Entry Date of 8/25/2014 and assuming you generate your report from 8/25/2014 - 11/1/2014, the export will find this student and export.

Concern 4: It seems that the State School Entry Date is the best match.  Why do I need to bother with all those other fields (US Entry Date, US School Enter Date, etc)?

If you do have the State School Entry Date populated for all your students, you're definitely correct that you don't have to deal with our logic of looking at those other fields.  Those fields were added into the formula as backups, in case you don't have a State School Entry Date populated.  We have plans to take away those other fields and making State School Entry Date the only field to compare against the report dates.

Recommendation:

For students new to the district but not new to CA, there should only be one initial Home Language Survey.  If a new Home Language Survey is collected by the new district  and the student is incoming from another CA school district, then the EL status should be verified with the previous district or by looking up the EL status in CALPADS to ensure the data is consistent from district to district.

CALPADS expects that Illuminate export only students who have changes in English Proficiency status going forward.  Illuminate will search for all students who matches the following logic, using the sample dates of 8/15/2014 - 11/17/2014:

• When the student's English Proficiency = (EL or TBD) and the LEP Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the EL/TBD status, and LEP Date as the SELA Effective Start Date.
• When the student's English Proficiency = IFEP and the FEP Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the IFEP status, and FEP Date as the SELA Effective Start Date.
• When the student's English Proficiency = RFEP and LEP Date is not blank and the Reclassification Date is between 8/15/2014 - 11/17/2014, Illuminate will export the student, the RFEP status, and Reclassification Date as the SELA Effective Start Date.

Back to Top

Behind the scenes, the 3 fields above are tracked per academic year.  If you toggle your Control Panel to the 2014-2015 year, then these 3 fields will yield the data per that year.  While in that academic year, these 3 data elements should reflect what the user is/should be for that year of reporting.  If this data is missing for YYYY academic year, then that year's SDEM export will be missing these 3 data elements.  So please ensure that your control panel is set to the correct academic year (doesn't matter what school/district) prior to adjusting this data.

• Previous clients:  If you used Illuminate the previous year and assuming you did submit this data then to CALPADS, logging into the new year will not copy this data over for all your users (ie. same Position Status, +1 to Yrs Service, +1 to Yrs District).  There is no process that will populate your new year with this new data.  Our developers have created a script that will copy (same Position Status, +1 to Yrs Service, +1 to Yrs District) from the previous year to current.  The script will only rollover this info if the user has the data in the previous year.  Please email ISIsupport@illuminateed.net to make this request.

Back to Top

• Start Date:  Please ensure that you enter (at best), the date of when the user began this Job Classification and/or Assignment at the Site specified.
• End Date: For this Job Class/Assignment and user, if the user is expected to end on a certain date, please input the date.  Otherwise, if the user is expected to continue with this same Job Class/Assignment from one year to next, please leave the End Date blank.  A blank date is interpreted as continuous and will yield the same Job Class/Assignment next year for the user.  This will avoid having to rollover or re-enter the same data.

Back to Top

To successfully flag CRSE/CRSC field 9.13 (identifying a course as CSU/UC compliant), the export is dependent on one thing.  This same logic is also applied to SENR field 1.30.

1. A Course Requirement must be created for the academic year in which you are generating/submitting.  In addition, the course requirement name must start with "CSU/UC Requirements".  We're very specific on the name and so anything else (ie. UC/CSU....) will not work.
   Within this requirement from step 1, you can create categories.  You should create a category for each letter (A-G).  If you're not sure about what each letter/subject means, please review the following link to the University of California A-G Requirements page (http://www.ucop.edu/agguide/a-g-requirements/).  Once your categories are created, within each category, you affiliate those CSU/UC courses from your course catalog that apply to that category.  For example, within your "A" category (History/Social Science), you'd want to affiliate all UC/CSU approved History/SS courses from your catalog.

If the course is assigned to one or more categories within this requirement, this field will export a "Y".  Otherwise, "N".

Back to Top

A new column for Carnegie Units Earned has been added with the following logic:

• For final grades being pulled into the SCSC, where grade levels 9-12 and CRS-State Course Code is less than or greater than 1000, the following default values will appear:
  • Semester Class with passing grade earning credits = 0.5 Carnegie Unit
  • Full Year Class with passing grade earning credits = 1 Carnegie Unit
  • Quarter Class with passing grade earning credits = 0.25 Carnegie Unit
  • Trimester Class with passing grade earning credits = 0.33 Carnegie Unit
  • Hexmester Class with passing grade earning credits = 0.17 Carnegie Unit
  • Classes with failing grades earning 0 credits = 0 Carnegie Units

In the event the default logic does not apply for student records, manual changes must be made in CALPADS.

• If you generate an SDIS report and you get no results, more than likely the problem/solution may be the following.  Pay special attention to rules #5 and #6 above.  If there should be any Violation or Consequence codes that do not have State ID Mappings for the given academic year, will filter out those behavior/participant records that tie to that Violation or Consequence.
• For example, within an incident a student received X consequence (ie. After School).  The consequence value does not have a State ID Mapping for the year.  Per our report filters, this consequence for this student will not export on the SDIS.
• While you are not required to report summer school enrollments, you are required to report out summer school behavior incidents as you would in the normal school year. On the May 14 EOY CALPADS call they recommended that you manually add a secondary enrollment for the student(s) involved for the day of the incident and use a T160 exit code. All behavior incidents that happen between July 1, 2014 and June 30, 2015 will need to be reported in the 2015 school year. All behavior incidents that happens between July 1, 2015 and June 30, 2016 will be reported in the 2016 school year.
• The logic for field 4.21 is as follows: If, on Disciplinary Incident Occurrence Date, Education Program Code = 144 (Special Education) and Incident Disciplinary Action Taken Code is not equal to 300 (No Suspension or Expulsion) Then Y; Else N. This logic is being applied in the script and should return a Y or N where appropriate.

Back to Top