CALPADS error brief · IVR
IVR0034
Official CALPADS rule
What CALPADS is rejecting
Duplicate Record within File based on Operational Key
Focus fields
Fields validated
23.04 - Reporting LEA 23.06 - SSID 23.09 - Reporting SELPA 23.12 - Special Education Plan Effective Start DateRecommended correction path
Suggested resolution
PLAN validation
Severity: Fatal Type: Input Validation
Fields validated
- 23.04 Reporting LEA
- 23.06 SSID
- 23.09 Reporting SELPA
- 23.12 Special Education Plan Effective Start Date
The operational key identifies one effective PLAN segment. Non-key differences—such as disability, setting, or transition values—do not make two rows unique when all four key values match.
The four-part PLAN operational key
| Key component | What it identifies | Common source of collision |
|---|---|---|
| 23.04 Reporting LEA | The LEA reporting the plan | Files from multiple organizations were merged or mislabeled. |
| 23.06 SSID | The student | A source join emitted the same student twice. |
| 23.09 Reporting SELPA | The SELPA reporting context | A repeated membership or crosswalk row multiplied the extract. |
| 23.12 Plan Effective Start Date | The beginning of this plan version | An amendment and annual plan were given the same effective date. |
Concrete checks
- Group the raw file by all four operational-key fields.
- Compare every non-key field before deciding which row is supported.
- Determine whether the duplication came from a repeated extract, one-to-many database join, API retry, or competing source records.
- Verify that two genuinely different plan events were not assigned the same effective date.
- Confirm the correct Reporting LEA, SELPA, SSID, and effective date from authoritative records.
Recommended correction path
- 1
Preserve the rejection
Capture the submission ID, raw PLAN row, row number, file name, error details, and applicable ODS history.
- 2
Identify the exact failure
Determine whether the problem is structural formatting, a literal field value, a duplicate within the batch, or a collision with accepted history.
- 3
Confirm identity and ownership
Verify SSID, Reporting LEA, Reporting SELPA, SENR enrollment context, and the intended student before changing special education data.
- 4
Reconcile the event
Compare the governing plan, MEET event, SWDS status, local special education system, and existing PLAN history.
- 5
Correct the responsible source
Remove a true duplicate or correct an inaccurate key only when evidence supports the change. If two plan events really occurred, report their actual distinct effective dates rather than inventing dates to force uniqueness. Repair any repeatable export or crosswalk defect.
- 6
Regenerate and verify
Resubmit the untouched regenerated row, confirm acceptance, and inspect neighboring PLAN and SERV history for unintended changes.