Last updated: 9/2/2022

TABLE OF CONTENTS


Background  ↑

Why are Extract changes needed as a result of the Post-Redesign Project?


When CALPADS launched their new environment, There were fundamental changes to the overall CALPADS process that were not clearly defined prior to launch. As a result, many customers were having their files rejected because of overlapping record errors. These files were never rejected before. For example, when a student exits one school and enrolls in another school in the district, the file is rejecting the 2nd enrollment record that is in the SENR file. CALPADS recently admitted that there are two sets of file validations that are running when a file is submitted. Instead of just checking for internal file errors as they originally planned, a second file validation process checks for conflicting data within the existing CALPADS records. A single error in ANY of these validations causes the entire file to be rejected. CALPADS has been communicating to both LEAs and Vendors that they have been investigating how to resolve these errors for a couple of weeks. 


After much discussion and research, they informed all SIS Vendors that the new CALPADS system MUST run both these validation checks before accepting any records into their system, and they will NOT be going back to allowing some records to post and rejecting only the problematic ones. Therefore, the ONLY way forward is to make the Vendors change how the extract files are created, to allow them to pass into their system. We had NO warning that this directive would be coming, and are left with no other options. 


Therefore, we began to make immediate changes to our CALPADS File Extraction process. The only way forward, rather than create one extract file (SENR, SPRG, etc.) with all the student changes, we now must create 3 files, one with records to be deleted, one with records to be updated, and one with records to be added. This will be true for ANY CALPADS extract file, except for full replacement files.  Also, these separate files must be uploaded and posted in a certain order.


We began this work immediately prioritized them according to the annual submission workflow to enable the most functionality to our clients as possible. As these processes were developed and tested, they were subsequently released to our customers. We are continuing to research and refine these processes as necessary.  We ask for your patience as we respond to these new challenges. Rest assured, we will do everything in our power to help make this change as easy for our customers as possible.


We will be updating this post as we go along, with the exact plans moving forward, let you know when releases are ready for deployment, and also work on updating our documentation since that will also need to change.


Process Changes  ↑

Enrollment Updates:

The process to update student enrollments (especially ending enrollments at the end of SY 21-22) was immediately needed. We needed to change our overall schema of CALPADS Updates, and move from a model of full extract files, within certain timeframes) to a transactional model, where we only send records to CALPADS where there is a difference between what CALPADS already knows, and current status in Aeries. 


We already had a rudimentary process for this that was embodied in our ODS Reconciliation process for several extracts (SENR, SPRG, SELA) so we started there. One change that was needed was to store inside Aeries a separate table (XRP) containing what data CALPADS currently holds for your LEA. Then, we can run comparisons between what CALPADS 'knows' and what we need to tell them about student enters, exits, change in status, etc. Then, output multiple files, broken down by type of transaction:

  • Removals
  • Exits
  • Updates
  • Adds

Since the process of obtaining an ODS extract in CALPADS can be cumbersome, we also created a process where customers can identify which specific files are accepted and posted by CALPADS, to update this CALPADS History Table (XRP) with those changes. In effect, this updates what we understand CALPADS 'knows' about your students' status, and can generate files again, based on that updated knowledge. However, if you are making manual changes inside CALPADS, even if those changes are also accurately reflected in Aeries, they are NOT reflected in the CALPADS History table, so our process will continue to want to submit those changes. That's why it's important, if you make lots of manual changes, you should do a new SENR ODS process and start with a fresh CALPADS History table. 


Identifiers:


Fall 1:


Fall 2:


EOY:



NOTE: Put a WARNING note here.