3rd Friday of September, Year End, and Child Count Collections
Year End files, 3rd Friday of September (formerly named Count Date) files, and combined Year End / 3rd Friday of September files have the same layout but different requirements apply. Note in particular the Record Type column in B.2 of the Interface Specifications which indicates which data elements apply to each file/record type.
- Year End (YE) Files. YE files include YE records for students enrolled during the most recently completed school term. One YE record is expected for each enrollment period at each school during the school term; students who move between schools or who have multiple enrollment periods in the same school will have multiple YE records for the same school term. YE records will be the primary source of information for progress and summary reports about attendance, high school completion, dropout, and retention/promotion data will be collected in YE records.
- 3rd Friday of September (CD) Files. CD files include CD records for students enrolled on the current year count date. Think of these records as snapshots of enrollment on the specified count date (e.g. third Friday of September). CD records will be used for disaggregated enrollment, WSAS Pre-ID, acquisition of English proficiency, IDEA exits, and preliminary membership reporting purposes. Some CD data are used along with YE data to generate or check YE data.
Child Count has a unique layout and requirements.
There is one type of Load File for the Individual Student Enrollment System (ISES) -Child Count. CC files include CC records for students with disabilities enrolled on October 1st of the current year. These records are a snapshot of enrollment on the specified count date (e.g. October 1).
There is one type of Load File for the Individual Student Enrollment System (ISES) - Discipline Collection. A single Record Type Discipline (D) is used for all records.
A minimum amount of data is required for successful load. Much of the additional data marked as "nullable" or "optional" in the Interface specifications (B.2) will be required prior to locking data. These additional data can be submitted by file upload, on-line data entry, or some combination of the two.
Questions have come up about data to be generated by ISES as a result of the ISES data validation process. This validation process may be initiated after file upload or may be user-initiated. ISES-generated data elements fall into the following categories:
- Certain data omitted by your district can be reliably calculated using other WSLS or ISES data. This happens when other data provided about certain students provides information to generate the omitted data for these students. (For example, 'COMPLETED_TERM' can be calculated using a WSLS 'EXIT_DATE' and local school term end date from the PI 1203.) You may view data validation messages for your district using the Reports Menu of ISES when this occurs. Because for individual students these data may not be correct, ISES will not overwrite data provided by your district and your district may overwrite data provided by ISES.
- Data provided by your district are inconsistent with other ISES or WSLS data for a student. (For example, your district provided the 'EXIT_TYPE' ODO dropout but WSLS data provide evidence of transfer to another school.) Inconsistent data will be overwritten by ISES or reset to null depending on the situation. You may view data validation messages for your district using the Reports Menu of ISES when this occurs. Your district will need to correct WSLS or other ISES data, if ISES-generated data are incorrect.
- Certain data calculated by ISES for every student in every 3rd Friday of September, Year End, Child Count, or Discipline record. (For example, 'MAX_AGE_YEAR' is calculated using the WSLS 'DOB'.) These data are not in the Student Load file layout so are not collected, but they can be downloaded from ISES (Interface specifications, B.5).
To minimize the amount of on-line data entry required, it is recommended that districts provide all readily available data in the Load file. Exception: data should be left null/omitted in the Load file if not relevant based on other data provided in the same file for the student. (For example, do not send a high school completion CREDENTIAL unless the student has an EXIT_TYPE of HSC high school completion.) These situations are addressed in the B.2. of the Interface specifications and are labeled "COND" (conditionally required) in the Nullable Upload column.