Look here to get the specs on all CALPADS exports and requirements.
In this lesson:
- Current CALPADS Documentation
- CALPADS Validation Logs
- Code Management (State ID Mappings)
- SENR Requirements
- SPRG Requirements
- SINF Requirements
- SELA Requirements
- SDEM Requirements
- SASS Requirements
- CRSE Requirements
- SCSE Requirements
- Postsecondary Status (PSTS)
- CRSC Requirements
- SCSC Requirements
- SDIS Requirements
- SINC, SIRS, and SOFF
- SCTE Requirements
Current CALPADS documentation
For the most updated CALPADS Code Sets, CALPADS Valid Code Combinations, CALPADS Error List, etc, see the CALPADS System Documentation page.
CALPADS Validation Logs
CALPADS has validations and requirements that are ever changing. With that said, it's a lot of validations and checks that we have to update into the system to keep up. Because of this madness, there will be some logic that we may miss.
When you generate a state report (ie. SENR, SINF, etc), there possibly can be a validation Log for that specific date/time export, that displays whatever errors are present as of that generation at X date and time. After those errors are corrected, the Validation Log that was generated at X date and time, will remain showing those errors. It is not until you go back and generate a new report, that we will query any new errors that still remain.
a. IF there is no new log for X date and time, this means that all the data as of that report, has passed our validation. This is a good sign because obviously there's nothing more that is required and the file should pass all/most of CALPADS' required fields.
b. IF there is another log for X date and time, then this means that there is at least one or more error(s) still. Correct those and repeat the steps of running the report again.
Code Management (State ID Mappings)

This is something very important to note, especially with adding/modifying code table data (ie. language codes, english prof codes, etc). This area is most responsible for all your missing-related code errors from CALPADS and on fixing, will resolve most of these errors. We use the State ID Mapping piece at the bottom of the code edit page. This is our way of extracting the correct code value per academic year.
For example, if CALPADS expects that in 2015, the code value for Hotels/Motels is "110". You'd add a record for 2015 > 110. Let's take this into the future and in 2016, CALPADS expects Hotels/Motels codes to export as "600". You can add a state mapping record for 2016 > 600. Having these records in place, if you export a 14-15 CALPADS file, it will pull the 110 code. If you pull a 15-16 file, it will pull the 600 code.
For steps on editing codes, see our Code Management help document.
SENR Requirements
Selection criteria to include students into this export:
- Student must have an SSID.
- Student must have an enrollment that overlaps the report Start Date and End Date. Using the example of 10/03/2014 to 11/03/2014, a student whose enrollment starts on 11/15/2014 will not be included. A student who started on 8/25/2013 and never left, will be included because he/she is enrolled at some point within that date range.
E150 and grade level changes
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.
-
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.
-
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.
District of Geographic Residence
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.
1.30 Met UC/CSU logic

Illuminate does have a field on the demographic details page (Met A-G Requirement: Y/N). However, this field does NOT export into the SENR 1.30. We do not use this 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:
- On the demographic details page, all students must have the Graduation Requirement Year populated.
- "Met A-G Requirements" Y/N override is applied on Demographic Details page. If no override has been applied, then #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.
In order to ensure that all students who meet CSU/UC Requirements for the academic year you are doing EOY CALPADS reporting for, we highly recommend running a Mass Grad Check Generation for all your graduating seniors for that requirement set. This is necessary to ensure all grades received by students in courses tied to that requirement get refreshed. A refresh of those grades, as they related to the course requirement set, is not automatic.
New Demographic Fields for 2018-2019
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:

These fields are boolean values (Yes/No), and Default to blank, or NULL, where they would need to be manually updated depending on whether the student completed the program. For full details on CALPADS expectations, see the CALPADS System Documentation site here.
SPRG Requirements
Selection criteria to include students into this export:
- Student must have an SSID.
- Student must have an enrollment that overlaps the report Start Date and End Date.
- The program Start/End dates must overlap the report Start Date and End Date.
- The program must be State Mapped in Code Management.
Students who only have non-primary enrollments and no primary enrollment record for the reporting year must have the Site value filled in for the program on the Student Programs page.
SED or Socio Economically Disadvantage Students
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.
Year-Specific Programs
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)
- For example, the screenshot above shows student 61042 with a Free Lunch program starting on 10/03/2011.
- 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).
- 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.
For additional logic on the dates the SPRG will pull, please refer to the SPRG Student Program Tool document.
Continuous Programs
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).
- If you reference the student 62064 who has a current GATE program effective 8/11/2010.
- When generating the SPRG for 14-15, the GATE program record exports a Start Date of 8/8/2012.
- 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).
For a full list of continuous programs, contact CALPADS.
Additional
- 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.
SPRG0070: Open Education Program record exists with Different Membership Start Date
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.
Change of Primary Disability
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:
- To put the original Disability and start date & End Date in the Spec Ed tab for that student.
- Enter the new IEP/Disability in the Spec Ed tab.
As of 2019-2020, SpEd data is reported to CALPADS through SpEd vendors and not Illuminate ISI.
SINF Requirements
Selection criteria to include students into this export:
- Student must have an SSID.
- Student must have an enrollment that overlaps the report Start Date and End Date.
SELA Requirements
Selection criteria to include student into this export:
- Student must have an SSID.
- The export will include only Primary enrolled students.
- Student must have an enrollment that overlaps the report Start Date and End Date.
- If student's English Proficiency currently is EL, TBD, RFEP, the LEP Date is required.
- Depending on what the student's current English Proficiency is and whether the corresponding Date is between the report Start Date and End Date. Rules are defined below.
English Only (EO) student export logic
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).
- State School Entry Date (Language details page)
- US Entry Date (Language details page)
- US School Entry Date (Language details page)
- District Enter Date (demographic details page)
- 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.
EL, TBD, IFEP, RFEP student export logic
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.
SDEM Requirements
Selection criteria to include user(s) into this export:
- User must have one ore more site/role affiliation(s) to the reporting Academic Year.
- User is setup as Exclude From State Reporting = No or blank. This field is found in the user details edit page.
- User has a State ID (SEID) that is not blank.
Staff Employment Status (7.27), Service Years LEA (7.30), & Service Years Total (7.31) rule

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.
SASS Requirements
Selection criteria to include user(s) into this export:
- User must have one ore more site/role affiliation(s) to the reporting Academic Year.
- User is setup as Exclude From State Reporting = No or blank. This field is found in the user details edit page.
- User has a State ID (SEID) that is not blank.
- User must have one or more Job Classification in which the Job Classification Start/End Date overlaps the report Start/End Date.
Job Classification and Non Classroom Based Job Assignment Start/End Date rules

- 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.
CRSE Requirements
Selection criteria to include Course/Section data into this export:
- There are multiple levels in which to flag Exclude From State Reporting and can be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area (and child-affiliated data) is flagged to Exclude From State Reporting = No or blank.
- Site level exclusion: No CRSE data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).
- Course level exclusion: CRSE data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections tied to this course will be excluded.
- User level exclusion: CRSE data affiliated to this user will not export (ie. the 5 sections the user is scheduled to will not export).
- Section level exclusion: CRSE data for that specific section will be excluded from the export.
- Those Course/Section in which the section Start/End Dates overlap the report Start/End Date.
CRSE will pull records in which:
1. At least one student is rostered to the section within the date span selected
OR
2. The section has an Itinerant Teacher (identified via Job Classification)
Note: If the Itinerant Teacher has sections at multiple school sites, the Job Classification FTE would need to be split to show 1 classification per school site (split and all total to 100 FTE).
9.13 CRS-UC CSU Approved Indicator logic

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.
- 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".
SCSE Requirements
Selection criteria to include Student/Course/Section data into this export:
- There are multiple levels in which to flag Exclude From State Reporting and can be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area is flagged to Exclude From State Reporting = No or blank.
- Site level exclusion: No SCSE data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).
- Course level exclusion: SCSE data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections (along with the schedules) tied to this course will be excluded.
- User level exclusion: SCSE data affiliated to this user will not export (ie. the 5 sections the user is tied to, along with the students scheduled will not export).
- Section level exclusion: SCSE data for that specific section will be excluded from the export.
- Those Course/Section data in which the section Start/End Dates overlap the report Start/End Date.
- Those Student/Section data in which the students' Entry/Exit Dates overlap the report Start/End Date.
Postsecondary Status (PSTS)
Illuminate has released the Postsecondary Status extract to generate the PSTS file for CALPADS submission. Please see the Postsecondary Status (PSTS) help document for details on data entry and how to generate file for submission.
CRSC Requirements
Selection criteria to include Course/Section data into this export:
- There are multiple levels in which to flag Exclude From State Reporting and can be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area (and child-affiliated data) is flagged to Exclude From State Reporting = No or blank.
- Site level exclusion: No CRSC data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).
- Course level exclusion: CRSC data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections tied to this course will be excluded.
- User level exclusion: CRSC data affiliated to this user will not export (ie. the 5 sections the user is scheduled to will not export).
- Section level exclusion: CRSC data for that specific section will be excluded from the export.
- Those Course/Section in which the section Start/End Dates overlap the report Start/End Date.
- Secondary schools in which there are Secondary Final Grading Periods and the Grading Period Start/End Dates overlap the report Start/End Date.
SCSC Requirements
Selection criteria to include Student/Course/Section data into this export:
- There are multiple levels in which to flag Exclude From State Reporting and can be done at the Site, Course, User, or Section level. Depending on which level you switch to include/exclude, will affect that specific level and its' child-affiliated data. The export is triggered to extract data in which the area is flagged to Exclude From State Reporting = No or blank.
- Site level exclusion: No SCSC data will export for this entire site. Because this is the highest level in the hierarchy, it overrides all child levels (Course or User or Section).
- Course level exclusion: SCSC data relating to this course will be excluded. For example, Course X is tagged to exclude and so the 10 sections (along with the schedules) tied to this course will be excluded.
- User level exclusion: SCSC data affiliated to this user will not export (ie. the 5 sections the user is tied to, along with the students scheduled will not export).
- Section level exclusion: SCSC data for that specific section will be excluded from the export.
- Secondary schools in which there are Secondary Final Grading Period and the Grading Period Start/End Dates overlap the report Start/End Date.
- The student received a Final grade within the Section/Course.
- The student earned the grade while enrolled in grade levels 7-12.
Carnegie Units Earned
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.
Note: Semester, Full Year, Quarter, Trimester, Hexmester classification relies on Term Type settings of Secondary Final Grading Periods. Term Type values must also be state mapped in Code Management to pull into SCSC file.
SDIS Requirements
For 2019 and Earlier Only
Selection criteria to include student Behavior data into this export:
- Student must have an SSID.
- Student enrolled at a school tagged with Exclude From State Reporting = No or blank.
- Student must have an enrollment that overlaps the report Start Date and End Date.
- The incident date must occur between the report Start Date and End Date.
- Include only valid Consequence(s) per the participant, per the incident. Invalid Consequence(s) that have no State ID Mappings (Code Management) are automatically excluded.
- Include only valid Violation(s) per the participant, per the incident. Invalid Violation(s) that have no State ID Mappings (Code Management) are automatically excluded.
- Include only incidents that have been marked as completed.
- Depending on the student's status/violation:
- SPED students who committed any Violation offense (48900, 48915).
- Non-SPED students who committed a Violation offense (48900, 48915) and received a Suspension (300) as a result.
- All students who committed any Fire Arm Violation offense (100, 101, and 105).
9. The incident must be a Major incident.
Additional Notes
- 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.
SINC, SIRS, and SOFF Extracts
For the 2019-2020 year and moving forward, CALPADS is expecting 3 new discipline extracts:
Illuminate added new Consequence codes to all ISI client databases in the Summer of 2019. Codes added were 400, 501, 502, 700, and 800.
The same workflow in creating Major Behavior Incidents is still expected to report data for these new files. Consequences, Consequence Duration, and Violations are all entered/updated under Participants.
All 3 extracts will include Validation Logs to cross-check valid code combinations for these new files. It is recommended to run Validation Logs prior to submitting to CALPADS. The order for submission to CALPADS should follow: 1) Student Incident (SINC), 2) Student incident Result (SIRS), then 3) Student Offense (SOFF).
Please refer to CALPADS System Documentation or contact CALPADS support for additional details on which codes/code combinations are expected for data entry.
Database Team limitation: If there is data missing or incorrect for behavior incidents, this must be corrected/updated manually per incident in Illuminate.
SCTE Requirements
Selection criteria to include students into this export:
- Student must have an SSID.
- The export will include only Primary enrolled students.
- Student enrolled at a school tagged with Exclude From State Reporting = No or blank.
- Student must have a CTE Pathway record for the academic year that matches the report Academic Year.
For details on designating CTE Pathways, please refer to our CTE Pathways - California Version help document.
Comments
0 comments
Please sign in to leave a comment.