Even if the employee doesn't have any flagged BAS events, first reprocess the employee's BAS events to make sure all BAS events are processed in the correct order.

The order to reprocess BAS events is as follows:

1. Date order from the oldest BAS event to the newest BAS event (reprocess 1/1/2015 BAS event, then reprocess 2/1/2015 BAS event and then reprocess 3/1/2015 BAS event).
2. If you have multiple BAS events for the same date, process those BAS events in Event Priority order from lowest to highest(reprocess Event Priority 75, then 200, 290, 375, 900, etc.). Refer to the Event Class Cheat Sheet job aid for BAS event priority information.

3. If you have multiple BAS events for the same date and same Event Priority, process those BAS events by Event ID from lowest to highest(1, 2, 3, etc.).

   Always refer to the Reprocessing Instructions in CHRS when reprocessing BAS events in CHRS.

    

There are 10 new action/action reason codes for use in Job Data in CHRS. These 10 new action/action reason code use new BAS event classes in CHRS (REH, T90, T92). These 10 new action/action reason codes do not necessarily replace existing action/action reason codes that moved from HR9.0.

• HIR/X92 – does not end the employee's benefits when 9.2 to 9.2 xfrs occur. The REH BAS event is created when this action/action-reason code is used.

• REH/X92 – does not end the employee's benefits when 9.2 to 9.2 xfrs occur. The REH BAS event is created when this action/action-reason code is used.

• TER/X92 – does not end the employee's benefits when 9.2 to 9.2 xfrs occur. The MSC BAS event is created when this action/action-reason code is used. The MSC BAS event is also deleted and not processed by CHRS, thus the employee's benefits are not terminated.

• HIR/XF9 – does not treat employee as a new hire. The T92 BAS event is created when this action/action-reason code is used. (Do not create NEW.)

• REH/XF9 – does not treat employee as a new hire. The T92 BAS event is created when this action/action-reason code is used. (Do not create NEW.)

• TER/XT9 – ends employee's benefits extra month out. The T90 BAS event is created when this action/action-reason code is used.

• HIR/<30 – does not treat employee as a new hire. The REH BAS event is created when this action/action-reason code is used. (Do not create NEW.)

• REH/<30 – does not treat employee as a new hire. The REH BAS event is created when this action/action-reason code is used. (Do not create NEW.)

• HIR/>30 – treats employee as a new hire. The HIR BAS event is created when this action/action-reason code is used and default waive rows are inserted for Medical and Dental plans. (Create NEW for core benefit enrollment.)

• REH/>30 – treats employee as a new hire. The HIR BAS event is created when this action/action-reason code is used and default waive rows are inserted for Medical and Dental plans. (Create NEW for core benefit enrollment.)

Refer to the Benefits for Transfers and Rehires job aid in the CHRS Knowledgebase for when these new action/action reason codes need to be used in Job Data, and why. Be sure to review the flow charts in the job aid for each use case.
https://csuchrs.screenstepslive.com/a/1862068-benefits-for-transfers-and-rehires

Your HR, Faculty Affairs and Payroll departments will probably key the incorrect hire, rehire and transfer action/action reason codes. You will need to work with your HR, Faculty Affairs and Payroll departments to get the correct action/action reason codes keyed into Job Data so the correct BAS events are created for the employee's benefits processing.

How can you tell that the wrong hire or rehire or termination action/action reason code was used? Here's a couple of examples:

• Example 1: 

The employee's existing medical and dental benefit enrollments are suddenly waived. (HIR/APT was used in error/by habit/lack of knowledge and understand of new action/action-reason codes). The HIR BAS event waived medical and dental.
o Solution: 1) Void the HIR event and 2a) have the correct Action/action reason entered, or 2b) manually create and process the correct BAS event). Refer to the Benefits for Transfers and Rehires job aid to determine the correct BAS event.

• Example 2: 

The employee's benefits were terminated and should not have been. (TER/XFR was used in error/by habit/lack of knowledge and understand of new action/action-reason codes ). TER BAS event terminated the employee's benefits.
o Solution: 1) Void the TER event and 2a) have the correct Action/action reason entered) or 2b) manually create and process the correct BAS event). Refer to the Benefits for Transfers and Rehires job aid to determine the correct BAS event."

Benefits may terminate or be missing from the interface file for several reasons:

• Job termination, unpaid leave, short work break, or employee waiver/life event (e.g., marriage, dependent gains coverage).
• Dependent aged out (26+), though adult dependents are not currently configured to age out in CHRS.
• Delayed entry of benefit changes when using the multiple permitting event code workaround (review via Health Benefits; note Election Date is when processed in Ben Admin).
• Workaround timing issues, as daily enrollments can overwrite Ben Admin/Base Benefit tables. Review with Ben Admin and Base Benefit Audit queries.
• Interface date earlier than the Health Benefits Election Date.
• Interface selection criteria not met (e.g., missing gender, out-of-state address).

If an employee’s Payroll Status changes, their benefits may be waived or terminated. In some cases, a Suspended status can also result in cancelled benefits in CHRS.

• Review BAS events and changes: Benefits > Manage Automated Enrollment > Employee Event Details (see Cheat Sheet).
• Check overall enrollments: Benefits > Review Employee Benefits > CSU Benefits Summary.
• Review detailed enrollments: Base Benefit tables (Health, Disability, Life/AD&D, Spending Accounts).
• Did the employee voluntarily waive benefits while on leave, short work break, or due to a life event? Confirm via Employee Event Details.

Some benefits terminate based on Benefits Employee Status. If the status is Leave of Absence, Terminated, Retired, or Deceased, benefits may be waived or terminated. Employees may also voluntarily waive benefits during unpaid leave, short work breaks, or life events. Review BAS events in Benefits > Manage Automated Enrollment > Employee Event Details (see Cheat Sheet).

Depending on the situation, additional questions may need to be asked:

• Did the employee lose eligibility due to ACA?
• Did the employee end another CSU job?
• Did the employee’s Benefits Primary Job change? (Benefits > Maintain Primary Jobs > Maintain Flags)
• Did the employee waive benefits while on unpaid leave, short work break, or a life event? (Benefits > Manage Automated Enrollment > Review Processing Results > Employee Event Details)
• Did the employee’s work location or address change to outside a geographic eligibility area? (Contact Information & Work Location pages; review Geographic Location Elig Table)
• Did Elig Fld 1–5 values change for the employee’s Benefits Primary Job? (Job Data > Benefits Program Participation)

Depending on the situation, additional questions may need to be asked:

• Did the dependent age out (26 for a qualified child)? (Benefits > Employee/Dependent Info > Update Dependent/Beneficiary) — note: adult dependents are not currently set to age out in CHRS.
• Was this a conversion issue from HR9.0 (dependent missing or dropped in HR9.0 to CHRS)? Compare HR9.0, campus conversion DB, and CHRS.
• Is the dependent disabled but not flagged as disabled for the time period? (Update Dependent/Beneficiary)
• Did the dependent’s relationship change (e.g., spouse → ex-spouse, domestic partner → ex-domestic partner)? (Update Dependent/Beneficiary)
• Did Elig Fld 1–5 values change for the employee’s Benefits Primary Job? (Job Data > Benefits Program Participation)

Review Job Data and check the action/action-reason combinations used for termination and hire rows. Benefits may have ended incorrectly due to how these rows were entered or because of gaps in CSU business processes. If so, coordinate with CHRS App Dev and Systemwide HR (SWHR) to determine if CHRS configuration or business process changes are needed.

For employees transferring between CSU locations, also review Employee Event Detail > Plan Type to confirm Ben Admin changes (see the Employee BAS Event Details Cheat Sheet for guidance).

Flagged BAS events often result from retroactive changes in CHRS (e.g., late hires, rehires, transfers, terminations), Job Data corrections, selective processing by Benefits Officers, or daily BAS events generated before prior events are resolved.

To investigate:

• Go to Benefits > Manage Automated Enrollment > Events > Update Event Status or Review Processing Results > Employee Event Detail to check for flagged BAS events.
• Review flags:
  • Out of Sequence → Events must be reprocessed in the correct order (see Reprocessing Cheat Sheets).
  • Address Eligibility Changed → Check Modify a Person for home state/zip changes and Job Data for work location changes. Moves may affect eligibility for regional plans.
  • Job Eligibility Changed → In Job Data, review fields such as Benefits Employee Status, Location, Empl_Class, Employee Type, FTE, Union Code, Pay Group, and Elig Flds 1–9.
  • Multi Job Indicator Changed → Review the same Job Data fields across all active jobs.

Processing BAS events out of order can incorrectly terminate benefits. Delivered PeopleSoft does not show the exact order of past manual processing, though you can use Ben Admin and Base Benefit Audit table queries (via the CSU Benefits Administrator Tile or Query Viewer) for partial insight. For audit table use, see the CHRS Benefits Audit Table User Guide.

The best solution is to reprocess BAS events in the correct order:

1. By Event Date – Process from oldest to newest (e.g., 1/1/2022 before 2/1/2022).
   Check Event Date in:Benefits > Manage Automated Enrollment > Events > Update Event Status or the Event Status Update button in On Demand Event Maintenance.
2. By Event Priority – For events on the same date, process in order from lowest to highest priority (e.g., 35 → 45 → 200 → 375).
   Check Event Priority in the same pages above.
3. By Event ID – For events with the same date and priority, process in ascending Event ID order (e.g., 1 → 2 → 3).
   Check Event ID in the same pages above.

There are numerous delivered and CSU-custom eBenefits, Ben Admin, and Base Benefit configuration pages. If you suspect a CHRS Benefits configuration issue, submit a Optimize Case for CHRS App Dev to review.