xits in Vista 3.2

There are several places in the Benefits processing module where you can include custom processing without changing the base Vista code.

The below diagram illustrates the seven points where you can insert custom logic during the overall benefits processing flow. Each of these points is implemented as a user-exit stored procedure.

Let's review each of these seven user exits.

1. This customization point is the BEN_Main_X() user exit stored procedure, which is called right at the beginning of Benefits processing. The parent BEN_Main() procedure sets up the initial set of benefits processing work tables—rpt_bel, rpt_belpeople, and rpt_belplanlist—from the main benefits tables (benplan, et al); therefore, the BEN_Main_X() user exit can be used for several purposes, including the following:
• It can do any kind of validity check to prevent processing to continue if not appropriate.
• It can add to or subtract from the list of people and/or plans being processed. (The list of people is written to rpt_belpeople and the list of plans to rpt_belplanlist.)
• It can also alter any other setting (e.g., update/validation mode, clearing or updating YTD values, etc.)
• It can do any eligibility preprocessing to resolve eligibility rules, writing the results to existing or newly created database fields. This can be used to handle complex eligibility rules that can't otherwise be handled by the benefits engine; alternately, this can be used to combine several eligibility rules into one simple field to improve the performance of the engine.
• It can kick off an Enterprise Server job to send a notification that Benefits is being run to anyone (either all of the time or only under specific situations).
2. This second customization point is the first start-point of the BEN_Final_X() user exit stored procedure. The parent BEN_Final() procedure calls the routines to do all of the calculations (valuations, premiums, deductions, etc.), writes data back to the main benefits tables (benplan, et al), and kicks off the final reports. The first start point for BEN_Final_X() occurs just before calculations (i.e., between eligibility and calculations). Therefore, it can be used as follows.
• It can validate or supplement the results of the eligibility processing (e.g., force people to be eligible or ineligible, overriding the Benefit engine's base determination).
• It can tag specific people/plans to NOT have any calculations performed in the subsequent steps.
  
3. The third customization point is the BEN_CalcsVal_X() user exit. The parent BEN_CalcsVal() procedure is called by BEN_Calcs(), which in turn is called by BEN_Final() to perform benefits calculations. BEN_CalcsVal() calculates valuations, so BEN_CalcsVal_X() can be used as follows.
• It can validate or alter any valuation calculation performed.
• It can perform valuation calculations for any user-defined valuation type codes (from cdvaluein).
• It can abort further valuation calculations.
  
4. The fourth customization point is the BEN_CalcsPrem_X() user exit. The parent BEN_CalcsPrem() procedure is also called by BEN_Calcs(). BEN_CalcsPrem() calculates employer, employee, and other premiums; therefore, BEN_CalcsPrem_X() can be used as follows.
• It can validate or alter any premium calculation performed.
• It can determine any user-defined range basis value (from cdbenprbasis) to pass to the actual premium calculation routine (#5 below).
• It can abort further premium calculations.
  
5. The fifth customization point is the BEN_CalcsPremERO_X() user exit. The parent BEN_CalcsPremERO() procedure is called by BEN_CalcsPrem three times—once each for the employer, employee, and other premium calculations—after BEN_CalcsPrem() determines the range basis value. BEN_CalcsPremERO() does the actual premium calculation; therefore, BEN_CalcsPremERO_X() can be used as follows.
• It can validate or alter any individual premium calculation.
• It can perform a custom calculation based on any user-defined premium calculation type (from cdbenprctype).
• It can abort further premium calculations.
  
6. The sixth customization point is the second start-point of the BEN_Final_X() user exit stored procedure. This is called from the BEN_Final() routine after all calculations are done and written to the benplan set of tables. Therefore, this can be used as follows.
• It can review the entire set of eligibility determinations and calculations to alter or validate any one or more. (Previous custom points could only look at one person's plan/option at a time.)
• It can abort any final updates (i.e., transferring the calculated data back to the benplan set of tables).
• It can prevent or alter the subsequent generation of reports.
7. The seventh customization point is the third (and final) start-point of the BEN_Final_X() user exit stored procedure. This is called from BEN_Final() after any desired reports have been scheduled. Therefore, this can be used as follows.
• It can run further sequential jobs, such as notification emails or interfaces to external systems.
• It can schedule future jobs. For instance, if a person is made future-eligible at a mid-month point in time, this can schedule a Little Ben to kick off for that person on the date he becomes eligible.
• If a person becomes eligible or ineligible during a run, it can automatically send that person an email indicating the status change.
• The above notification can even be scheduled as a workflow so that an administrator can get involved in the election.

All of these user exits are available so you can tailor your benefits processing without touching any of the base Vista system code.

Marco Padovani
Senior Software Specialist
PDS