PIMS Graduation Status

The Graduation Status field (column BM/field 65 on the STUDENT template) in the PA PIMS Download reports whether a student has graduated, transferred, or otherwise completed their program. This field is populated automatically during the PIMS Student Download based on data in the student's Graduation Status (GRADS) program records.

This chapter explains:

• What setup is required before running the download

• How the system determines the graduation status value

• What each warning/error message means

• How to verify and troubleshoot common issues

Quick Troubleshooting

Use this table to quickly identify the most likely cause for common graduation status issues. For detailed investigation steps, see Deep Troubleshooting.

What Is Graduation Status?

Graduation Status is a one-character code reported to PDE (Pennsylvania Department of Education) indicating whether a student who left the school graduated, dropped out, or transferred. The valid codes are maintained in the Graduation Status Validation Table (patb_grad_stat) in eSchoolPLUS. Each code maps to a state_code_equiv value that is reported to PDE.

PDE Graduation Status Codes

Setup Requirements (Checklist)

Before running the PIMS Student Download, verify that the following setup is complete and correct.

GRADS Program Setup

The GRADS program stores graduation status information for students. Each student who has a graduation status must have a record in this program.

Where to find it: Registration – Entry & Reports – Student Demographic – Programs – GRADS-Graduation Status

What to verify:

PIMS District Defined Screen (Screen 300)

The Graduation Status field on the PIMS page is linked to the GRADS program through the district-defined screen configuration.

Where to find it: District – Setup – District Defined Screens – Screen 300 – Field 2

What to verify:

Graduation Status Validation Table

The system validates each graduation status code against the patb_grad_stat table before reporting it. This is one of several PA-specific validation tables maintained under the Pennsylvania State Reporting application.

Where to find it: Administration – General Setup – District – Validation Tables – Pennsylvania State Reporting Application – Graduation Status

Database table: patb_grad_stat

What to verify:

Building Configuration

Starting with the school year 2023 and later, graduation status is building-specific. The system only reports a grad status if the GRADS program building matches the building on the enrollment vector being processed.

Where to find it: Registration – Entry & Reports – Student Demographic – Programs – GRADS-Graduation Status – Building field

What to verify:

Building Matching Rule (School Year 2023+)

The system evaluates building match in this order:

1. GRADS building = enrollment vector building – use this grad status

2. GRADS building = NULL (blank) – fallback, use this grad status

3. No match – grad status is cleared during processing

If a NULL building record exists alongside a building-specific record, the building-specific record is always used first. The NULL record is only considered when no direct building match is found.

4.5 Related Validation Tables and Fields

In addition to the GRADS program and patb_grad_stat, the following tables and fields interact with graduation status during the download. Verify these are set up correctly.

Key Database Tables

For support engineers who need to verify data directly, the following tables are involved in graduation status processing:

How Graduation Status Is Determined During the Download

All Conditions Required for Grad Status to Be Reported (School Year 2023+)

For a graduation status value to appear in the PIMS extract for a given enrollment vector, all of the following conditions must be met simultaneously:

If any one of these conditions fails, the graduation status will be blank for that enrollment vector.

Example — Returning student at North Side Elementary (Building 13):

• Student withdrew on 02/12/2026 (W16A) – GRADS created with status O, start date 02/12/2026, end date 02/26/2026, building blank

• Student re-entered on 02/27/2026 (R9A)

• Closed vector (withdrawal 02/12): Condition 4 ✓ (has withdrawal date), Condition 5 ✓ (02/12 ≥ 02/12), Condition 6 — building check: GRADS building is blank, student building is 13, so direct match fails – fallback to NULL building ✓ – Grad status O is reported

• Active vector (re-entry 02/27): Condition 4 ✗ (no withdrawal date) – Grad status is automatically blank

The NULL building fallback is why the grad status is pulled even though the GRADS building does not match Building 13. If the district had set the GRADS building to 13, it would have matched directly without needing the fallback.

Logic Flow Diagram

GRADS program record exist for the student?
        │
        ├─ No ──────────────────────────── Grad status = blank
        │
        └─ Yes
             │
Program dates overlap submission run range?
(start_date <= submission_end
AND (end_date IS NULL OR end_date >= submission_start))
             │
             ├─ No ──────────────────────── Grad status = blank
             │
             └─ Yes
                  │
Valid code in patb_grad_stat?
                  │
                  ├─ No ──────────────────── ERROR: Invalid state code
                  │
                  └─ Yes
                       │
Student has withdrawal date on this vector?
                       │
                       ├─ No ─────────────── Grad status = cleared (active student)
                       │
                       └─ Yes
                            │
GRADS start_date >= withdrawal date?
                            │
                            ├─ No ────────── Grad status = blank + warning
                            │
                            └─ Yes
                                 │
Building match or NULL fallback?
                                 │
                                 ├─ Match ─── REPORT grad status
                                 ├─ NULL ──── REPORT grad status (fallback)
                                 └─ No ────── Grad status = blank + warning

When you run the PIMS Student Download with the Student (STU) template selected, the system processes graduation status in the following order.

Step 1 — Retrieve GRADS Program Records

The download retrieves records from the reg_programs table for all students who have a GRADS program record where:

• The program start_date is on or before the submission end date (start_date <= @EndDate)

• The program end_date is on or after the submission start date, OR the end date is NULL (end_date >= @StartDate OR end_date IS NULL)

This means:

• Open programs (no end date) are always included

• Closed programs are included only if they overlap the submission date range

Key Point: A closed GRADS program with an end date before the submission start date will NOT be picked up.

Step 2 — Validate the Status Code

Once a GRADS record is found for a student, the download:

1. Reads the program_value (the graduation status code, for example, "T")

2. Looks up the code in the patb_grad_stat validation table

3. If the code is not found in the table → the student record is marked invalid with the error: "Invalid state code for graduation status [code] for Student: [ID]"

4. If the code is found → the state_code_equiv value from the table is used as the reported graduation status

Step 3 — Building Matching (School Year 2023+)

For school year 2023 and later, the download applies building-matching logic. This step only runs for students who have a withdrawal date on the enrollment vector being processed.

The download checks, in order:

1. Match by building and date: Does the student have a GRADS record where:

   • The grad_building matches the student's enrolled building, AND

   • The GRADS start_date is on or after the student's withdrawal date?

   → If yes: Use this graduation status.

2. Fallback — no building specified: If no building-specific record is found, does the student have a GRADS record where:

   • The grad_building is NULL (no building assigned), AND

   • The GRADS start_date is on or after the student's withdrawal date?

   → If yes: Use this graduation status.

3. No valid grad status found: If neither check finds a matching record:

   • The graduation status is cleared during processing

   • A warning is logged: "Student: [ID] - Student does not have a valid grad status for building [building]"

For active students (no withdrawal date): The graduation status is cleared during processing. Active students should not have a graduation status.

Step 4 — Active Student Check

After determining the graduation status, the system performs an additional validation for the current school year:

• If a student has a non-empty graduation status AND their current status is Active ("A"):

  • A warning is logged: "Student [ID] has a current status of Active and a graduation status."

  • For Snapshot downloads, the grad status is automatically cleared

This warning exists because an active student should not have a graduation status — this would cause a PIMS validation error. If you see this warning, investigate why the student has both an active enrollment and a graduation status.

Step 5 — Grades 9-12 Withdrawal Check

For students in grades 9 through 12 (or grades 7-8 with withdrawal code WD01) during the current school year:

• If the student has a current status other than Active and no graduation status:

  • A warning is logged: "Student [ID] has a current status other than Active and no graduation status."

  • This means a withdrawn student in grades 9-12 is expected to have a graduation status explaining why they left

Common Scenarios and Expected Results

Student Withdraws with an Active Grad Status

This is the normal case. The student withdrew, has an open graduation status program for the correct building, and the status is reported.

Student Returns to the District

What the district should do:

1. Close the existing GRADS program record by entering an End Date (the day before the student re-enters the district)

2. Do not create a new GRADS record unless the student withdraws again

3. Verify the GRADS program start date — it must be on or after the student's withdrawal date for the building-matching logic (2023+) to find it

Why this works: The download processes each enrollment vector separately. For the closed (withdrawn) vector, the GRADS record is correctly matched and the historical graduation status is reported. For the active (re-entry) vector, the student has no withdrawal date, so the system sets the grad status to blank (Step 3 — line 1929 in ValidateAndSetStudentData.cs).

How GRADS program dates affect retrieval:

• The GRADS program is retrieved when its date range overlaps the submission date range: start_date <= EndDate AND (end_date >= StartDate OR end_date IS NULL)

• If the GRADS program end date is before the submission start date, it will not be retrieved at all — no grad status appears

• If the GRADS program end date falls within the submission range, it will be retrieved and matched to the closed enrollment vector

Common mistake #1: If the district does not close the GRADS program when the student returns, the system may pull a stale graduation status for an active student, generating the warning: "Student has a current status of Active and a graduation status."

Common mistake #2: If the GRADS program start date does not align with the withdrawal date, the building-matching logic (2023+) will fail to find the record and clear the grad status, generating: "Student does not have a valid grad status for building [building]." Adjusting the GRADS start date to match the withdrawal date resolves this.

Known Behavior — CurrentStatus vs. Vector Status

The active student check (Step 4) uses the student's CurrentStatus field, which is computed based on the student's latest enrollment state relative to the run end date — not the enrollment vector being processed. This means that when the download processes a historical (closed) withdrawal vector for a returning student, the student's CurrentStatus may already be 'A' (Active) from the re-enrollment.

This can cause a false warning: "Student has a current status of Active and a graduation status" on the closed vector, even though the graduation status is correct for that historical enrollment. The warning is cosmetic — for non-snapshot downloads, the grad status value is retained in the extract despite the warning. For snapshot downloads, the grad status may be incorrectly cleared.

Workaround: Ensure the GRADS program end date falls before the submission start date so the record is not retrieved at all for the current run. Alternatively, if the closed vector must report grad status, the warning can be safely ignored for non-snapshot downloads.

Grad Status Program Is for a Different Building

Starting with the school year 2023, the system matches the GRADS program building to the student's enrolled building. If they do not match, the grad status is not reported for that building.

What to verify:

• Check the GRADS program's building field

• Ensure it matches the building being reported

• If the student transferred between buildings, each building may need its own GRADS record

Student Has a Closed GRADS Program

If the GRADS program is properly closed and the student is active:

• The program's end date determines whether it is even retrieved by the query

• If retrieved, the active student check (Step 4) clears the grad status

• If the program end date is before the submission start date, it won't be retrieved at all

If you still see a warning, check whether the GRADS program end date overlaps the submission date range. If it does, the record is still being picked up. Adjust the end date or verify the submission date range.

Student Is Active with No Withdrawal Date

For school year 2023+, when a student has no withdrawal date (still enrolled), the download clears the grad status during processing regardless of what the GRADS program contains. Active students should not have a graduation status.

Student Has Multiple Enrollment Records

When a student has been enrolled in multiple buildings during the same school year, each enrollment vector is evaluated independently. The grad status building must match the building on the enrollment vector being processed for the value to be reported.

Special Education Graduate from the Previous Year

This logic applies only to school years 2015 through 2022. The system checks if the student was a previous year graduate with special education status and adjusts the graduation status code to "S" accordingly.

Note: This scenario does not apply for school year 2023 and later, which uses the building-matching logic instead.

Real-World Scenarios from Escalations

The following scenarios are drawn from actual district escalations and illustrate how the graduation status logic handles (or has handled) specific situations. Understanding these helps anticipate similar cases.

Scenario A — Grad Status Blank for a Withdrawn Student (ESP-106270)

District situation: A student withdrew from the district, and the district correctly created a GRADS program with the appropriate graduation status code. The GRADS program start date was set to the same date as the student's withdrawal date. However, when the PIMS Student Download was run, the graduation status appeared as blank instead of the expected value.

What happened: The building-matching logic (for school year 2023+) requires the GRADS program start_date to be on or after the student's withdrawal date. In this case, the dates were equal (start_date = withdrawal_date), but date formatting differences between the stored program date and the enrollment withdrawal date caused the in-memory comparison to fail. The system treated the GRADS record as not matching and cleared the grad status.

How it was addressed: The matching condition was initially changed from a start-date check to an end-date check — looking at whether the GRADS program was open or still active through the withdrawal date, rather than requiring the start date to be on or after withdrawal. This resolved the blank grad status for the reported student.

Side effect: This change also removed a safeguard that cleared graduation status for active students (those without a withdrawal date). That removal introduced a regression where GRADS records were being matched even for students who were still enrolled, causing the problems described in Scenarios B and C below.

Current state: The original start-date matching was restored in a later release. The correct resolution for this type of issue is to ensure the GRADS program start date is properly aligned with the withdrawal date, using consistent date formatting.

Scenario B — False "Active with Graduation Status" Warnings After Update (ESP-109037)

District situation: After the November 2025 update, multiple districts began receiving a high volume of "Student has a current status of Active and a graduation status" warnings during PIMS Student Downloads. The warnings appeared for students who were currently enrolled and should not have had a graduation status. The warning message did not include the building number, making it difficult for districts to determine which building or GRADS record was responsible.

What happened: Two changes from the November 2025 fix (Scenario A above) combined to create this issue:

1. The safeguard that cleared graduation status for actively enrolled students (those with no withdrawal date) was removed. Without this check, the system no longer distinguished between withdrawn and active students during GRADS matching — all students with a GRADS record received a graduation status value, even if they were still enrolled.

2. The change from start-date matching to end-date matching was more permissive. Closed GRADS programs whose end date fell on or after the withdrawal date would match, even when the student had subsequently re-enrolled and the GRADS program no longer applied.

How it was addressed: The warning message was updated to include the building number ("Student has a current status of Active and a graduation status for building X") to help districts identify the source of the warning. However, the underlying false-positive logic was not resolved in this release — the message was improved for diagnostic purposes only.

Current state: The warning message was later reverted to the original format (without building number) as part of the full revert described in Scenario C.

Scenario C — Grad Status Pulling for Wrong Building in Multi-Building Districts (ESP-109547, ESP-109179)

District situation: A multi-building charter school district reported that graduation status was being pulled for the wrong building. Students enrolled in one building were receiving a graduation status value that belonged to a GRADS program configured for a different building. Additionally, closed GRADS programs were incorrectly contributing graduation status values for students who were currently active.

What happened: The end-date based matching introduced in the November 2025 fix (Scenario A) did not properly constrain results by building. When checking end_date IS NULL OR end_date >= withdrawal_date, the system could match a GRADS program from Building A to a student enrolled in Building B, as long as the program's date range overlapped. The building field was checked, but the more permissive date matching allowed records from other buildings to appear in fallback scenarios.

Combined with the removal of the active-student clearing logic, this produced two problems:

• Active students received graduation status from closed GRADS programs that should no longer apply

• Students in multi-building districts received graduation status from GRADS programs configured for a different building

How it was addressed: All changes from the November 2025 and January 2026 releases were fully reverted back to the December 2025 release state. This restored:

1. Start-date based matching: The GRADS program start_date must be on or after the student's withdrawal date. This ensures the GRADS record corresponds to the specific withdrawal event, not just any overlapping date range.

2. Building-specific matching with fallback: The system first looks for a GRADS record matching the student's enrolled building. Only if no building-specific record is found does it fall back to GRADS records with no building assigned (NULL). This prevents cross-building contamination.

3. Active-student clearing: Students without a withdrawal date (still enrolled) automatically have their graduation status set to blank. This prevents stale GRADS records from producing false graduation status values for active students.

4. Original warning message: The building number was removed from the warning message, reverting to the original format.

Current state: This is the current production behavior. The three-tier matching logic (match by building, fallback to no-building, clear if no match) with start-date validation is the approved approach for school year 2023 and later.

Scenario D — Returning Student with GRADS Program Date Overlap (ESP-109962)

District situation: Two students at Central Dauphin ISD had previously withdrawn (with withdrawal code W16A — Runaway/whereabouts unknown) and were correctly given a GRADS program with graduation status O (Dropped out — Other reason). The students later returned to the district and re-enrolled. The district properly closed the GRADS program by setting the end date to the day before re-entry. However, the PIMS download was generating a false warning ("Student has a current status of Active and a graduation status") for the closed enrollment vector.

What happened: The download processes each enrollment vector separately. For the historical (closed) withdrawal vector, the system correctly matched the GRADS record and assigned graduation status O. However, the active student check (Step 4) uses the student's CurrentStatus field, which is computed based on the latest enrollment state — not the vector being processed. Since the student had re-enrolled, CurrentStatus was 'A' (Active), triggering the warning on the historical vector even though the graduation status was correct for that closed enrollment.

For non-snapshot downloads, the warning is cosmetic — the grad status value is retained in the extract. For snapshot downloads, the grad status could be incorrectly cleared by this check.

How it was resolved: Adjusting the GRADS program start date to properly align with the withdrawal date resolved the issue. The key was ensuring the GRADS program date range did not overlap the submission period for the active enrollment run, so the closed GRADS record was only retrieved when processing the historical vector's submission period.

Current state: This is a known behavior where CurrentStatus reflects the student-level status rather than the vector-level status. The workaround is to ensure GRADS program dates are properly aligned so the record is only retrieved for the appropriate submission period.

Scenario E — Grad Status Blank After Cross-Building Transfer with Closed GRADS (ESP-109962)

District situation: A student was enrolled at one building and withdrew with a code indicating the student was committed to a correctional institution. The district created a GRADS program with graduation status O (Dropped out — Other), with the start date set to the day after the withdrawal, a closed-end date several weeks later, and the building field left blank. The student later re-enrolled at a different building within the same district. The student is currently active in the new building. When the PIMS download is run, the graduation status appears blank.

Why the grad status is blank: The download evaluates each enrollment vector separately against the conditions required for grad status to be reported.

For the active enrollment vector at the new building, the student has no withdrawal date. Because active students do not receive a graduation status, the system sets the value to blank immediately. The GRADS program created for the previous building's withdrawal does not carry over to the new building's enrollment. This is the record that appears in the PIMS extract for the student's current enrollment.

For the closed enrollment vector at the original building, the student does have a withdrawal date, and the GRADS program start date is after the withdrawal date, so the date condition passes. The building match uses the NULL fallback since the GRADS building was left blank. Whether the grad status is reported for this vector depends on whether the GRADS program dates overlap the submission run range — if the run range does not include the period when the GRADS program was active, the record will not be retrieved at all, and the closed vector will also be blank.

Key takeaways from this scenario:

1. Grad status does not transfer across buildings. A GRADS program created in connection with a withdrawal from one building does not apply to a subsequent enrollment at a different building. The new building's enrollment is active with no withdrawal, so its grad status is always blank.

2. The GRADS program start date must align with the withdrawal date. The GRADS start date must be on or after the student's withdrawal date for the matching condition to pass. If the start date is set before the withdrawal date, the system will not find a valid match and the grad status will be blank even for the closed vector.

3. Submission run range determines GRADS retrieval. A closed GRADS program is only retrieved when its date range overlaps the submission period. If the run range ends before the GRADS program started, the record is not in the dataset and cannot be matched.

4. Blank building relies on the NULL fallback. When the GRADS building is left blank, the system cannot directly match it to the student's enrolled building. It only matches through the NULL building fallback, which is used when no building-specific GRADS record exists. If a building-specific record existed for the original building, the direct match would take precedence over the NULL fallback.

Warning and Error Messages

Quick Warning Lookup

Graduation Status — Direct Errors and Warnings

Graduation Status — Related Errors and Warnings

These messages appear during the Student Download and involve fields that interact with graduation status:

Deep Troubleshooting

If a student's graduation status is not appearing correctly in the PIMS extract, work through the following steps:

The grad status is BLANK when it should have a value:

• [ ] Does the student have a GRADS program record? (Student – Programs – Graduation Status)

• [ ] Is the GRADS program open (no end date), or does the end date overlap the submission date range?

• [ ] Is the GRADS program start date on or before the submission end date?

• [ ] Does the GRADS program have a valid graduation status code?

• [ ] Is the code present in the Graduation Status validation table (patb_grad_stat)?

• [ ] For school year 2023+: Does the GRADS building match the students' enrolled building?

• [ ] For school year 2023+: Is the GRADS start date on or after the student's withdrawal date?

• [ ] Does the student have a withdrawal date? (Active students will always have a blank grad status.)

The grad status has a VALUE when it should be blank:

• [ ] Is the GRADS program closed (has an end date)?

• [ ] Is the GRADS program end date before the submission start date? (If not, the record is still being retrieved.)

• [ ] Is the student currently Active? (Active students should not have a grad status.)

• [ ] Did the student return to the district? If so, was the GRADS program closed with an end date before re-entry?

• [ ] Is the GRADS building different from the student's current enrolled building?

The warning message appears but seems invalid:

• [ ] Check the GRADS program dates — is it actually open, or does it overlap the submission range?

• [ ] Check the PIMS District Defined Screen (Screen 300, Field 2) — does it show a graduation status value?

• [ ] Verify the student's enrollment history — are there multiple entry/withdrawal records?

• [ ] Run the download in debug mode to see the actual SQL queries and data being processed.

Pre-Run Verification Steps

Before running the PIMS Student Download, perform these verification steps to avoid common issues:

Step 1: Verify GRADS Program Data

1. Navigate to Student – Programs – Graduation Status (GRADS)

2. For each student expected to have a graduation status:

   • Confirm the GRADS program record exists

   • Confirm the status code is valid (matches a code in patb_grad_stat)

   • Confirm the start date is set

   • Confirm the building field matches the student's enrolled building

3. For students who have returned to the district:

   • Confirm the old GRADS program record is closed (has an end date)

   • Confirm that no new GRADS record was created unless the student has withdrawn again

Step 2: Verify Returning Students

1. Identify students who were previously withdrawn and have re-enrolled

2. For each returning student:

   • Check that the previous GRADS program record has an end date set to the day before re-entry

   • Check that the PIMS page (Screen 300) does not show a graduation status value

   • If the PIMS page still shows a value, the GRADS program may not be properly closed

Step 3: Verify Building Assignments

1. For districts with multiple buildings, verify that each student's GRADS record has the correct building

2. Pay special attention to students who transferred between buildings during the school year

3. Remember: a grad status for Building A will NOT appear on Building B's report

Step 4: Review the Download Prompts

When setting up the PIMS Download:

Step 5: Run in Debug Mode (Optional)

For complex cases, run the download in debug mode:

1. Enable debug mode before running

2. After the download completes, review the debug log for:

   • The SQL query used to retrieve GRADS records (SQL for Graduation Status Code)

   • Which students had grad status records found

   • Which warnings were generated and why

3. The debug log will show the exact data used in each decision

Step 6: Review the Log After Running

After the download completes:

1. Open the task log

2. Search for any graduation status warnings (refer to Common Scenarios and Expected Results)

3. For each warning, follow the Troubleshooting Checklist

4. Verify the output data in: Regulatory – Pennsylvania – Summary – Student Download Summary

Known System Behaviors

These are documented system behaviors that support teams should be aware of. They are not bugs — they are characteristics of how the graduation status logic works.

CurrentStatus vs. Vector Status

The active student check (Step 4) uses the student's CurrentStatus field, which is computed based on the student's latest enrollment state relative to the run end date — not the enrollment vector being processed. For returning students, the CurrentStatus may already be 'A' (Active) from the re-enrollment, triggering a false warning on the historical withdrawal vector. For non-snapshot downloads, the grad status value is retained despite the warning. For snapshot downloads, the value may be incorrectly cleared. Refer to Student Returns to the District for the workaround.

Multiple GRADS Records

If a student has multiple valid GRADS program records that match the retrieval criteria, the download uses the most recent valid record (ordered by start date descending). If multiple records exist for different buildings, the building-matching logic determines which one is used for each enrollment vector.

Date Formatting in Matching

The building-matching logic compares the GRADS start_date against the student's withdrawal date using an in-memory DataTable filter. Date formatting differences (for example, MM/dd/yyyy vs. yyyy-MM-dd) can cause comparisons to fail even when the dates are logically equal. If a GRADS record appears to meet all conditions but the grad status is still blank, date formatting may be the cause. This was the root cause of the original ESP-106270 escalation.

When to Escalate to Engineering

Escalate to the development team if the following conditions are met and the issue cannot be resolved through data corrections:

Before escalating, confirm that:

• [ ] The GRADS program data has been verified directly in the database (refer to Key Database Tables)

• [ ] The download has been run in debug mode and the debug log reviewed

• [ ] The troubleshooting checklist has been completed

• [ ] The student's enrollment vectors and withdrawal dates have been verified

12. Frequently Asked Questions

Q: A student returned to our district. How do I remove their old graduation status?

A: Close the GRADS program record by adding an End Date set to the day before the student re-entered the district. Do not delete the record — close it. Once closed and the student is active, the system will report a blank graduation status. This is documented in the PA User Guide.

Q: I'm getting the warning "has a current status of Active and a graduation status," but the student's GRADS program is closed. Why?

A: Check whether the GRADS program end date falls within the submission date range. If the end date is within the run range, the record is still being retrieved by the system. Also, verify that the PIMS District Defined Screen (Screen 300, Field 2) does not show a graduation status value.

Q: The grad status is pulling for the wrong building. How do I fix it?

A: Check the GRADS program's building field (GBuilding). Starting with the school year 2023, the system matches this field to the student's enrolled building. Update the GRADS building to match the correct building, or create a separate GRADS record for each building where the student was enrolled.

Q: I see the warning "Student does not have a valid grad status for building X," but the student has a GRADS program.

A: This means the GRADS record exists but does not match the criteria for the student's building. Verify:

1. The GRADS building matches the students' enrolled building

2. The GRADS start date is on or after the student's withdrawal date

3. If neither condition is met, the system cannot find a valid record for that building

Q: Why does the graduation status show correctly for some students but not others?

A: The most common reasons are:

• Different buildings between the GRADS program and the students' enrollment

• The GRADS program is closed, but the end date overlaps the submission range

• The student re-enrolled, and the old GRADS program was not closed

• The graduation status code in the GRADS program does not match a valid code in the validation table

Q: What is the difference between the PIMS page graduation status and the PIMS extract graduation status?

A: The PIMS page (Screen 300) shows the raw value from the GRADS program link. The PIMS extract value goes through additional processing: building matching, date validation, and code mapping through the validation table. They may show different values if the GRADS program does not meet all the criteria for the extract.

Q: A returning student is getting a false "Active with graduation status" warning. How do I fix it?

A: This happens because the system evaluates the student's overall CurrentStatus (which reflects the latest enrollment) rather than the status of the specific enrollment vector being processed. For the historical withdrawal vector, the student is already re-enrolled, so CurrentStatus = 'A'. The fix is to adjust the GRADS program dates so the record does not overlap the submission date range for the current run. Set the GRADS program end date to the day before re-entry, and ensure the start date matches the withdrawal date. If the end date falls before the submission start date, the GRADS record will not be retrieved, and the warning will not fire.

Q: What happens if the GRADS program has no building assigned?

A: For school year 2023+, the system first looks for a GRADS record matching the student's enrolled building. If none is found, it falls back to GRADS records with a NULL (blank) building. This is intentional — PA allows GRADS records without a building. However, if a building-specific record also exists, the building-specific one takes precedence.

Q: Does changing the GRADS program start date affect which enrollment vector it matches?

A: Yes. For school year 2023+, the building-matching logic requires GRADS start_date >= student's withdrawal date. If the GRADS start date is before the withdrawal date, it will not match, and the grad status will be blank. Aligning the GRADS start date with the withdrawal date ensures the record is found.