Benefits Enrollment And Termination (565)

SAP Best Practices

© SAP 2008 / Page 2

Scenario Overview – 1

Purpose This scenario describes the typical process performed by the Human Resources

department to enroll employees to the available Benefit Plans and then to discontinue the plans upon departure of the employee.

Benefits Employee is enrolled into benefits and retirement savings plans Employee master records are updated, and the payroll deductions are timely

and accurate Benefits vendor interfaces can be processed accurately and timely, thus

minimizing confusion and employee coverage updates

Key process flows covered Benefits Enrollment and Termination Processing

Purpose and Benefits:

© SAP 2008 / Page 3

Scenario Overview – 2

Required SAP ECC 6.0 EhP3

Enterprise roles involved in process flows Benefits Administrator Employee

SAP Applications Required:

© SAP 2008 / Page 4

Scenario Overview – 3

Benefits Enrollment and Termination Processing

Mass Generation of Adjustment Reason Adjustment Reasons is created The adjustment reasons are maintained

Benefit Enrollment for New Hires Employee requests for enrollment to the benefits plans General Benefits Information and an Infotype for each enrolled benefit plan

is created

401K Enrollment / Participation

Mapping Dependents/Beneficiaries to Benefit Plans

Check Benefits Maintenance - Participation Monitor

Check Benefits Administration - Insurability

Detailed Process Description:

© SAP 2008 / Page 5

Scenario Overview – 4

Benefits Enrollment and Termination Processing, cont’d

Run Confirmation Statement

Termination of Benefit Plans

Detailed Process Description:

© SAP 2008 / Page 6

Process Flow Diagram

Benefits Enrollment and Termination Processing

Legend – Please see next page

© SAP 2008 / Page 7

Legend

Symbol Description Usage Comments

Band: Identifies a user role, such as Accounts Payable Clerk or Sales Representative. This band can also identify an organization unit or group, rather than a specific role.

The other process flow symbols in this table go into these rows. You have as many rows as required to cover all of the roles in the scenario.

Role band contains tasks common to that role.

External Events: Contains events that start or end the scenario, or influence the course of events in the scenario.

Flow line (solid): Line indicates the normal sequence of steps and direction of flow in the scenario.Flow line (dashed): Line indicates flow to infrequently-used or conditional tasks in a scenario. Line can also lead to documents involved in the process flow.

Connects two tasks in a scenario process or a non-step event

Business Activity / Event: Identifies an action that either leads into or out of the scenario, or an outside Process that happens during the scenario

Does not correspond to a task step in the document

Unit Process: Identifies a task that is covered in a step-by-step manner in the scenario

Corresponds to a task step in the document

Process Reference: If the scenario references another scenario in total, put the scenario number and name here.

Corresponds to a task step in the document

Sub-Process Reference: If the scenario references another scenario in part, put the scenario number, name, and the step numbers from that scenario here

Corresponds to a task step in the document

Process Decision: Identifies a decision / branching point, signifying a choice to be made by the end user. Lines represent different choices emerging from different parts of the diamond.

Does not usually correspond to a task step in the document; Reflects a choice to be made after step execution

Symbol Description Usage Comments

To next / From last Diagram: Leads to the next / previous page of the Diagram

Flow chart continues on the next / previous page

Hardcopy / Document: Identifies a printed document, report, or form

Does not correspond to a task step in a document; instead, it is used to reflect a document generated by a task step; this shape does not have any outgoing flow lines

Financial Actuals: Indicates a financial posting document

Does not correspond to a task step in a document; instead, it is used to reflect a document generated by a task step; this shape does not have any outgoing flow lines

Budget Planning: Indicates a budget planning document

Does not correspond to a task step in a document; instead, it is used to reflect a document generated by a task step; this shape does not have any outgoing flow lines

Manual Process: Covers a task that is manually done

Does not generally correspond to a task step in a document; instead, it is used to reflect a task that is manually performed, such as unloading a truck in the warehouse, which affects the process flow.

Existing Version / Data: This block covers data that feeds in from an external process

Does not generally correspond to a task step in a document; instead, this shape reflects data coming from an external source; this step does not have any incoming flow lines

System Pass / Fail Decision: This block covers an automatic decision made by the software

Does not generally correspond to a task step in the document; instead it is used to reflect an automatic decision by the system that is made after a step has been executed.

<F

unct

ion>

Ext

erna

l to

SA

P

Business Activity /

Event

Unit Process

Process Reference

Sub-Process

Reference

Process

Decision

Diagram Connection

Hardcopy / Document

Financial Actuals

Budget Planning

Manual Proces

s

Existing Version /

Data

System Pass/F

ail Decisio

n

© SAP 2008 / Page 8

Appendix – Public Sector Clients

In many cases, various aspects of benefits functionality are outsourced in the public sector. Customized processes need to be tailored for each individual situation. It is important to use benefits consultants with public sector experience to be successful.

Public sector benefits offerings frequently involve public pensions such as CalPERS. Significant governmental regulations apply to these sorts of arrangements including special tax withholding exemptions for covered employees and complex interfaces. Extremely close collaboration between the benefits and payroll consultants is required to be compliant. CAUTION – Fines and penalties frequently apply for late or noncompliant interface filings.

Public pension plans frequently require per period breakdowns for both wages and contributions whenever retroactive pay changes are made. The effort to code such interfaces typically averages 300% over what is required for interfaces that do not require this type of functionality. The ability to develop and code such interfaces is a special skill set that should be a written requirement for project team members.

© SAP 2008 / Page 9

Appendix – Public Sector Clients, cont‘d

Employer contribution rates for public sector savings plans often go out to 3 or 4 decimal places. Standard SAP configuration allows for only 2 decimals, however. Such requirements can be addressed by customizing BADI’s or writing payroll rules as required.

Standard system functionality allows for one type of employer contribution to be generated per plan. In some public sector scenarios, multiple employer contributions are required from the same plan. Such requirements can easily be satisfied using payroll rules INSTEAD of configuring multiple types of plans.

In some public sector environments, employees have the choice of selecting among a large number of vendor-providers for 403(b) plans. (For various reasons, there is no single vendor). In such cases, multiple plans should generally NOT be configured. Instead, please see Note 824473.

© SAP 2008 / Page 10

Appendix – Public Sector Clients, cont‘d

Payment models are typically required for public sector benefits as deductions are often not taken each pay period for each plan.

Confusion often occurs with respect to flexible spending plans for public sector clients because clients often wish to use payment models for deducting them. This approach is contrary to SAP design and is not advised because the SAP process is based upon guidance from the IRS. Similar confusion often results surrounding the use of arrears tracking for FSA deductions. Once again, the standard process is highly advised.

Worker’s Compensation programs are often administered within the Benefits agencies for public sector clients. In many cases, rules that are very different from private sector environments exist which may require special development, configuration and processes. This consideration should be explored during effort estimation for public sector installations.

© SAP 2008 / Page 11

Appendix – Public Sector Clients, cont‘d

Unlike the typical private sector environment, employer costs for benefits must often be split among multiple sources of employee funding in the public sector. Requirements for doing this vary among states and types of employers. For ECC 6.0, the supported SAP approach to delivering this functionality is payroll function XCODI.

Savings bond programs sometimes exist in public sector benefits offerings. Many clients are choosing to discontinue these in light of the significant free functionality now available to all from the U.S. Treasury Department’s website http://www.savingsbonds.gov . In cases where payroll deductions are needed in SAP, infotypes 103 and 104 are preferable to infotype 14. Conversion of these types of deductions requires existing balances even in cases when a payroll go live is on January 1. It is advisable to refund old deductions from the legacy systems and begin taking new ones in SAP to avoid needing to run the ULK9 schema only for this purpose. In addition, the standard ULK9 schema must be modified to accommodate savings bonds.

© SAP 2008 / Page 12

Appendix – Public Sector Clients, cont‘d

In educational environments where employees work only during the academic year but have benefits coverage throughout the entire year, special configuration and effort is required to accommodate the accrual and postings for the supporting deductions. Rules vary by state and location. It is advisable to review this scenario when estimating effort to install.

Employee eligibility within public sector environments tends to vary by plan type in many instances. Eligibility determination can be challenged by temporary periods during which the employee appears to lose eligibility but does not because of special plan provisions that can be based upon union agreements, seniority, or other criteria. Such scenarios should be carefully considered when estimating efforts for these types of installations.

ESS iViews must frequently be enhanced for public sector clients due to special requirements such as manually providing birth certificates before coverage can be extended to new births, adoptions, etc. Many similar examples occur, so the impact of whatever is relevant to a particular installation should be considering during the scoping and estimation process.