CALPADS error brief · IVR
IVR0180
Official CALPADS rule
What CALPADS is rejecting
Focus fields
Fields validated
1.01 - Record Type Code 1.02 - Transaction Type Code 1.05 - School of Attendance 1.08 - SSID 1.22 - Enrollment Start DateRecommended correction path
Suggested resolution
Read the complete validation
CALPADS rule: The submitted record attempts to delete the Last Enrollment Record for a student in CALPADS.
Severity: Fatal Type: Input Validation
Fields validated:
- 1.01 Record Type Code
- 1.02 Transaction Type Code
- 1.05 School of Attendance
- 1.08 SSID
- 1.22 Enrollment Start Date
“Last Enrollment Record” means the student’s sole remaining SENR record—not necessarily the newest, current, or still-open enrollment. CALPADS is preventing the submitted transaction from leaving the SSID with no enrollment history.
First determine what staff are actually trying to accomplish
| Intended outcome | Usually appropriate action | Why |
|---|---|---|
| Close an enrollment because the student left | Update the enrollment with the supported Exit Date and Exit Reason | An exit closes the enrollment but preserves it as part of the student’s history. A delete erases the record. |
| Correct a non-key value | Submit an Add/Update transaction using the same operational key | Grade level, enrollment status, exit information, and other non-key values can be updated without deleting the enrollment. |
| Correct the School of Attendance, SSID, or Enrollment Start Date | Delete the record under its old key and add the corrected record under its new key | These fields identify the SENR record. Changing one creates a different operational key. |
| Remove a duplicate created under the wrong SSID | Reconcile the student identity first; then follow the authorized SSID/enrollment correction procedure | A local duplicate can represent two CALPADS identities. Deleting first may destroy evidence needed for reconciliation. |
| Erase an enrollment because the student never attended | Confirm the factual record and obtain the current CALPADS procedure if this is the student’s only enrollment | IVR0180 deliberately blocks a stand-alone deletion that would reduce the student’s CALPADS enrollment history to zero. |
Example: correcting the enrollment start date
The fictional student’s only CALPADS enrollment has a start date of August 17, but the authoritative SIS and enrollment documentation establish August 18.
| Record | School of Attendance | SSID | Enrollment Start Date |
|---|---|---|---|
| Existing CALPADS record | 1234567 | 1234567890 | 20260817 |
Delete transaction (D) | 1234567 | 1234567890 | 20260817 |
Corrected Add/Update (A or permitted blank) | 1234567 | 1234567890 | 20260818 |
Do not place August 18 on the delete row. CALPADS uses the delete row’s operational key to find the existing August 17 record. The corrected date belongs on the corresponding Add/Update row. The same old-key/new-key logic applies when correcting School of Attendance or SSID.
What the successful correction is intended to preserve
- Existing rowConfirm the last record.
- Old keyTarget the stored values.
- New keyBuild the corrected row.
- PostUse the supported workflow.
- VerifyHistory remains intact.
What commonly produces IVR0180
| What you find | Likely cause | Durable correction |
|---|---|---|
The file contains only a D row | The SIS emitted the deletion but filtered out, delayed, or failed to create the corresponding corrected enrollment. | Repair the extract workflow so the complete authorized correction is produced. |
| Staff meant to record the student’s departure | Delete was confused with exit. | Restore the enrollment and submit the supported Exit Date and Exit Reason instead. |
| Only grade, status, or exit information was wrong | A non-key edit was unnecessarily converted into delete-and-add. | Use Add/Update with the existing operational key. |
| Delete and add use the same corrected start date | The extract overwrote the old key before constructing the delete row. | Retain the old key for D; use the corrected key for the new record. |
| The corresponding row has a different SSID | A duplicate SSID, local-ID crosswalk, or identity merge is unresolved. | Reconcile the student identities and document which SSID survives before changing enrollment history. |
| Staff expected another enrollment to remain | The other enrollment never posted, belongs to another SSID, or was already deleted. | Inspect the student’s current CALPADS enrollment history rather than relying on the SIS display alone. |
| The student truly never attended | The only CALPADS enrollment was created in error. | Document the nonattendance and obtain the current authorized process for removing the final record. |
Choose the diagnostic pathway
- Confirm the current CALPADS enrollment history
- Is this truly the only SENR record under the SSID?
- Is it current, exited, or historically closed?
- Does another expected enrollment exist under a different SSID?
- Do the School of Attendance and Enrollment Start Date match the submitted delete?
- Distinguish delete from exit and update
- Did the student leave, or was the enrollment itself created in error?
- Is the correction limited to a non-key field?
- Would an Add/Update preserve the existing key and history?
- Are staff trying to make the record disappear merely because it is open?
- Compare the old and new operational keys
- Which school, SSID, and start date are currently stored?
- Which one is being corrected?
- Does the
Drow use all three old values? - Does the corresponding Add/Update row use the supported corrected values?
- Inspect the complete generated file
- Did the extract produce both parts of the intended correction?
- Was one row excluded by date range, school filter, status, or file partition?
- Do both rows identify the same student?
- Did a spreadsheet alter the SSID or date?
- Escalate identity or transaction ambiguity
- Is a duplicate or retired SSID involved?
- Does the correction cross schools or reporting LEAs?
- Does the SIS vendor prescribe a special key-change workflow?
- Can staff preserve the raw rows, submission ID, screenshots, and source evidence for CALPADS support?
Primary participants
- CALPADS coordinator
- Registrar or authorized enrollment staff
- Student records or records-management staff
- SIS system owner
- Extract, integration, or vendor support
Evidence to preserve
- Current CALPADS enrollment history
- Authoritative enrollment documentation
- Old and corrected operational keys
- Raw delete and corresponding add rows
- Submission ID and record-level results
Recommended correction path
Stop the stand-alone deletion
Do not repeatedly submit a transaction that would erase the student’s only enrollment record.
Confirm the intended student
Match SSID, local student ID, legal identity, and enrollment documentation before changing history.
Inspect CALPADS—not only the SIS
Verify that the targeted record is the student’s sole remaining SENR enrollment and capture its exact operational key.
Classify the correction
Determine whether the proper action is exit, Add/Update, operational-key correction, identity reconciliation, or authorized removal.
Return to authoritative evidence
Establish the correct school, SSID, start date, attendance history, and—if applicable—exit information.
Construct both keys correctly
For a key correction, use the stored key on the delete row and the supported corrected key on the Add/Update row.
Use the supported posting workflow
Follow current CALPADS and vendor instructions for the coordinated correction; escalate if validation order prevents the intended pair from posting.
Verify the resulting history
Confirm IVR0180 clears and at least one accurate enrollment remains under the correct SSID.
Repair the source process
Correct the SIS workflow, extract query, key-change logic, or identity crosswalk so future files do not recreate the orphaned delete.
Before closing the issue
- Confirm the student retains an accurate CALPADS enrollment history.
- Verify the delete targeted the old operational key—not the corrected key.
- Confirm the corrected record uses the supported school, SSID, and start date.
- Ensure a departure was recorded as an exit rather than a deletion.
- Review downstream SINF, SPRG, SELA, assessment, accountability, and special-education dependencies as applicable.
- Document the evidence, transaction path, final CALPADS state, and source-system repair.
Official SENR IVR0180 troubleshooting page | CALPADS SENR guidance | Current CALPADS system documents