CALPADS error brief · IVR
IVR0034
Official CALPADS rule
What CALPADS is rejecting
Focus fields
Fields validated
1.05 - School of Attendance 1.08 - SSID 1.22 - Enrollment Start DateRecommended correction path
Suggested resolution
Read the complete validation
CALPADS rule: Two or more records exist with the same operational key fields.
Severity: Fatal Type: Input Validation
Operational-key fields:
- 1.05 School of Attendance
- 1.08 SSID
- 1.22 Enrollment Start Date
How two different-looking rows collide
1234567123456789020260817| Submitted row | Same operational key | Different non-key payload | What CALPADS sees |
|---|---|---|---|
| Row 18 | 1234567 | | Status 10; Grade 09; no exit | Two versions of one key—not two separately identifiable enrollments. |
| Row 42 | 1234567 | | Status 10; Grade 10; exit populated |
The numbers above are fictional and illustrate key behavior only.
“Delete one duplicate” is not yet a complete correction plan. First compare every field and identify which row—if either—accurately represents the documented enrollment. Arbitrary deletion can preserve the wrong grade, wrong status, stale open enrollment, incorrect exit, or wrong student.
Classify the collision before correcting it
| Collision type | How to recognize it | Evidence-based response |
|---|---|---|
| Exact duplicate rows | Every submitted field, including transaction and payload, is identical. | Retain one intended row, remove the redundant copy, and repair the query/export process that emitted it twice. |
| Same key, conflicting payload | The three key fields match, but grade, status, exit, completion, transfer, or another field differs. | Reconstruct the actual enrollment and build one correct complete transaction for that key. |
| Original plus revised version | A source query exported both an older snapshot and its corrected version. | Identify the authoritative current record and modify the extract so only the intended transaction is emitted. |
| Two legitimate enrollments collapsed | Local evidence supports two enrollment episodes, but the submitted start dates or schools were made identical. | Correct the inaccurate key field using actual attendance/enrollment evidence; never invent a date simply to make the rows unique. |
| Two students collapsed under one SSID | Local IDs or names differ while the key uses the same SSID. | Stop processing and reconcile student identity before changing enrollment history. |
| One enrollment duplicated by a join | The same SIS enrollment appears once for each program, contact, schedule, school-year, or related-table row. | Correct the query grain so one enrollment source record generates one SENR transaction. |
| Merged export batches | The same student/key appears in two extracts concatenated into one upload file. | Submit one controlled batch and repair file-assembly or scheduling logic. |
Compare the complete rows—not only the key
| Field group | Compare | Question to answer | Evidence owner |
|---|---|---|---|
| Submission control | Transaction Type, Local Record ID, source row, batch, export timestamp. | Did one source record generate both rows, or were separate versions combined? | CALPADS coordinator and extract owner. |
| Operational key | School of Attendance, SSID, Enrollment Start Date. | Are all three values factually correct for the intended enrollment? | Registrar/enrollment staff and authorized identity staff. |
| Enrollment meaning | Enrollment Status, Grade Level, School Transfer, District of Geographic Residence. | Which row describes how and where the student was actually enrolled? | Registrar, site staff, and program owner. |
| Exit and outcome | Exit Date, Exit Reason, Completion Status, expected receiver school. | Is one row an outdated open record while the other contains the supported exit? | Enrollment, counseling, completion, or cohort staff. |
| Student identity | SSID, Local Student ID, legal-name and birth fields used for identification. | Do both rows truly belong to the same person? | Authorized student-records staff. |
| Source-system lineage | SIS enrollment ID, import origin, update timestamp, query/join path. | Which source record is authoritative, and why did the second row appear? | SIS, integration, or vendor support. |
What commonly creates the second row
| Technical pattern | Why it duplicates the key | What to inspect |
|---|---|---|
| One-to-many database join | One enrollment joins to multiple contacts, programs, schedules, services, or audit rows. | Query grain, join predicates, effective dates, and pre-aggregation. |
| Union or append without deduplication | Current and historical extracts contribute the same enrollment. | Batch boundaries, union branches, date filters, and job schedules. |
| Update emitted beside original | Both before-change and after-change versions remain in the staging set. | Change-data logic, effective record selection, and latest-row rules. |
| Manual file concatenation | The same school/student batch is pasted or appended twice. | File names, row ranges, upload assembly, and staff procedure. |
| E150 or grade-change workflow | A midyear update is generated without a genuinely distinct supported enrollment start date. | Local E150 configuration, continuation record, start/exit chronology, and current CALPADS rules. |
| Stale record not retired locally | An inactive local enrollment continues to qualify for the extract beside its replacement. | Active flags, enrollment status, effective dates, and suppression criteria. |
Choose the diagnostic pathway
- Confirm the duplicate set
- Which row numbers share the same school, SSID, and start date?
- Are there two rows or a larger duplicate group?
- Are the rows byte-for-byte identical?
- Do Local Record IDs or source enrollment IDs identify their origin?
- Does the same key appear in another batch or file?
- Reconcile student identity
- Do both rows belong to the same SSID and person?
- Do Local Student IDs and identifying fields agree?
- Could two students have been assigned the same SSID locally?
- Is the SSID active and correct after any MID resolution?
- Should submission stop for identity review?
- Reconstruct enrollment chronology
- Was there one enrollment episode or two?
- What was the first date the student was expected to attend each school?
- Are school, status, grade, start, and exit values supported?
- Did an E150 or other midyear update create a new enrollment?
- Which complete row tells the documented story?
- Compare transaction intent
- What Transaction Type appears on each row?
- Is one row an older version and the other a correction?
- Was an Add, Delete, or Replace transaction generated as intended?
- Does the current CALPADS ODS already contain the key?
- What single transaction should this file communicate?
- Trace the extract defect
- Which SIS record produced each submitted row?
- Did a one-to-many join multiply the enrollment?
- Were historical and current snapshots combined?
- Did manual file assembly duplicate a row range?
- Will the next scheduled export reproduce the collision?
Resolve the record before repairing the generator
- GroupFind matching keys.
- CompareDiff complete rows.
- ProveReconstruct enrollment.
- RepairFix source and extract.
- VerifyConfirm one correct key.
Primary participants
- CALPADS coordinator
- Registrar or enrollment staff
- Authorized student-identity staff when SSIDs differ from local evidence
- SIS system owner
- Extract, integration, or vendor support
Assign ownership by cause
- True redundant copy: extract/file-assembly owner.
- Conflicting enrollment facts: registrar and SIS owner.
- Wrong SSID: authorized identity reconciliation.
- Wrong school/start date: enrollment evidence review.
Recommended correction path
Preserve the submitted evidence
Save the untouched file, submission details, rejected row numbers, Local Record IDs, and exact duplicate-key values.
Group every matching operational key
Find all rows sharing School of Attendance, SSID, and Enrollment Start Date; do not stop after locating the first pair.
Compare every field
Determine whether the rows are exact copies or disagree on transaction, identity, grade, status, exit, completion, or transfer information.
Reconstruct the authoritative enrollment
Use SIS history, attendance, registration, transfer, withdrawal, and completion evidence to establish what actually occurred.
Choose the correct disposition
Remove a true redundant copy, build one corrected version of a conflicting record, or repair inaccurate key fields for genuinely distinct enrollments.
Correct the source and generator
Repair the SIS record, query grain, joins, filters, staging logic, scheduling, or manual assembly process that created the collision.
Regenerate a clean file
Verify each operational key occurs once and that the surviving complete row contains the intended transaction and payload.
Resubmit and inspect CALPADS
Confirm IVR0034 clears, then verify the student’s complete enrollment history rather than relying only on submission acceptance.
Search for systemic duplicates
Check other students, schools, dates, files, and scheduled exports affected by the same generation logic.
Before closing the issue
- Confirm each School + SSID + Start Date key occurs only once in the regenerated file.
- Verify the surviving row contains the correct complete transaction—not merely the first occurrence.
- Confirm the SSID belongs to the intended student.
- Verify school, start date, status, grade, and exit information against enrollment evidence.
- Inspect the accepted CALPADS enrollment history.
- Document the source-system or extract defect and test other affected records.
Official SENR IVR0034 troubleshooting page | SENR guidance | Current CALPADS system documents







































































