Skip to main content

CALPADS error brief · IVR

IVR0612

Duplicate Plan Effective Start Date
Severity
FATAL error - Must be corrected in order to post the record and/or certify the data.
Error type PLAN - Special Education Plan
Record type IVR

Official CALPADS rule

What CALPADS is rejecting

Student has an existing record with the same Special Education Plan Effective Start Date

Focus fields

Fields validated

23.04 - Reporting LEA 23.06 - SSID 23.09 - Reporting SELPA 23.12 - Special Education Plan Effective Start Date

Recommended 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

One student may have many PLAN records over time, but only one record may use a particular effective-start key for the same Reporting LEA and Reporting SELPA.

IVR0034 and IVR0612 are related—but not identical

ErrorWhere the competing record is foundFirst diagnostic action
IVR0034Another row in the same submitted fileGroup and compare the batch by the four-part operational key.
IVR0612The student’s existing CALPADS PLAN historyOpen the ODS history and compare the accepted record with the rejected row.
Existing PLAN segmentOne supported effective date and set of plan facts.
New submissionAdd, correction, amendment, or accidental duplicate?
Supported historyRetain one evidence-backed record for the key and reconcile dependent files.

Concrete checks

  • Open the student’s PLAN history and locate the existing matching effective date.
  • Compare the existing record with the rejected row field by field.
  • Determine whether the new row is an accidental Add, a correction to the existing plan, or a genuinely different event with a wrong date.
  • Verify the transaction process required by the current PLAN effective-date model.
  • Review connected MEET, SWDS, and SERV dates before changing history.

Recommended correction path

  1. 1

    Preserve the rejection

    Capture the submission ID, raw PLAN row, row number, file name, error details, and applicable ODS history.

  2. 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. 3

    Confirm identity and ownership

    Verify SSID, Reporting LEA, Reporting SELPA, SENR enrollment context, and the intended student before changing special education data.

  4. 4

    Reconcile the event

    Compare the governing plan, MEET event, SWDS status, local special education system, and existing PLAN history.

  5. 5

    Correct the responsible source

    Do not add a second version with the same key. Preserve the existing record when it is correct; otherwise use the supported correction process or correct the rejected event date when authoritative evidence shows it is wrong. Repair any repeatable export or crosswalk defect.

  6. 6

    Regenerate and verify

    Resubmit the untouched regenerated row, confirm acceptance, and inspect neighboring PLAN and SERV history for unintended changes.

Official references