I retired from MERS on May 1, 2004, and then came back to work on contract. I had been responsible for wage and service reporting since 1998, and they needed me to continue fixing report errors, providing customer support, and processing corrected reports until all municipalities were converted to ePASS, The 600 municipalities were divided into 12 groups. One group was to be converted each month starting in October, so the last of them would have been converted in September 2005. As it turned out, my last day of work was Thursday, August 19, 2003, but I didn't know it until Saturday, the 21st, when UPS delivered a letter to my home saying my contract had been terminated - no reason given.

I probably wore out my welcome. Contractors shouldn’t use the word “stupid” when questioning Management decisions. And while testing the new system, I had reported as “bugs” problems with ePASS that I knew were there by design – problems I’d pointed out a year earlier, before Compuware was kicked off the project. Compuware was the first contractor to take on the project, and they bungled it. GRS (Gabriel, Roeder and Smith), the same firm that provides actuarial services to MERS, took over the project and has done an outstanding job. But they had to work with the original MERS design, and I thought it had some serious problems. Here is my original summer 2003 list, less a few that I know were corrected. Others may have been fixed in the final ePASS version.

Preparing Reports Out of Sequence. Users are permitted to prepare reports out of sequence, although they must submit reports in sequence. I don’t think there is a need to prepare reports out of sequence, or to prepare more than one report at a time. Users were never permitted to prepare reports out of sequence in the old system, and no one complained. Allowing them to prepare reports out of sequence could cause problems. A user preparing a report in November for October might select November by mistake, enter all his data, then find out when he tries to submit that October is the next to be processed. He will then have to select October and re-enter all the data.

Bargaining Unit on Membership Application. When completing the Membership Application for a rehired member, the user will not be permitted to enter the employee’s current bargaining unit. The previous BU will be displayed, but they will not be permitted to change it. They have to wait and change it on the payroll report. This message will be displayed:

         Error – Bargaining Unit Transfer must be done on the edit screen

It will be hard for users to understand why they cannot enter the correct bargaining unit. Also, they might forget to change the BU when they do the payroll report.

No Bargaining Unit in Flat File. Users will be able to upload a flat file, but there is no field for bargaining unit in the flat file. This means that if there are any BU changes, the users will have to do them manually after the file is loaded. This is an extra step, and it could easily be forgotten. Users who currently use a flat file are used to maintaining the BU number for each employee in their payroll system, and not having to make additional changes after uploading the file.

BU Change Confirmation. This is not a big problem, and it has been in the design since the beginning. I am the only one who doesn’t like it. When entering payroll data, the user cannot simply change (select) an employee’s bargaining unit. He must first check a “xfer?” checkbox. The intent is to force the user to think before he changes the BU, which we hope will keep the user from making unintentional BU changes. I do not think users make frivolous BU changes, and requiring him to check the “xfer?” box is confusing and annoying. 

No Excluded Wages. The excluded wages field has been eliminated. In the old system, users reported gross wages and excluded wages, and we calculated the net as the difference. In the new system, the users will report the net wages only. Having an excluded wage field was not for the benefit of MERS. For us, it only adds complexity and takes up file space. The excluded wages field was added to the old system in about 1993, and it was added for the benefit of the users. The users wanted to see the same gross wage total on the Member Statement that they saw on the W-2 form. With ePASS, this will no longer be possible. It is unknown whether users still care about this. As far as I know, no attempt was made to find out. 

Wage Discrepancy Code. The wage discrepancy code is a new feature in ePASS, and while it has the potential for providing useful information, the current design lacks sophistication and will cause problems. As currently designed, the codes are as follows: 

DISB      = Disability
LOA       = Leave of absence
NHIR     = Newly hired
OTH       = Other
PROM     = Got a raise or promotion
RTRO     = Received retroactive pay
WCMP    = Receiving worker’s compensation
MILT     = On active military duty

The first problem is that the same explanations are accepted for both unusually high wages and unusually low wages. PROM is acceptable for low wages; LOA is acceptable for high wages. ePASS will allow bad information to be collected.

Even if the explanation is appropriate for low wages, it still might be invalid. ePASS could display a warning message to get confirmation. For example, if the reason is DISB, wages are zero, and service credit is “full”, the warning could say “To earn service credit, employee must work 10 days or disability payments must be reported." Or if reason is LOA, NHIR or OTH, wages are low, and service credit is “full”, the warning could say “To earn service credit, employee must work 10 days."

The second problem is that explanations for unusually low wages will be required even if the user has indicated that the employee received no service credit. If the employee is not receiving service credit, we don’t care if the wages are unusually low. The only reason we ever question low wages is if service credit is being granted. We want to make sure the employee earned it. Nevertheless, a code will be required even when no service credit is indicated, and none of the current codes are appropriate. In this case, ePASS will require bad information to be collected.

But if we are going to require an explanation when service credit is “none”, we should use warnings to question some entries. When the reason is WCMP or MILT and service credit is “none”, the warning should say "Employee should receive full service credit when on worker's comp or active military duty."

ePASS will not require a wage discrepancy code when a termination date is reported. This is good. A termination date indicates that the employee did not work the entire month (explaining low wages) and that payoffs of accumulated leave may have been received (explaining high wages).

No Flat File Upload for Corrected Report. The corrected report process in ePASS does not allow the user to upload a flat file. All corrections to past reports must be done as manual corrections to the displayed original. This is fine when there are only a few corrections, but not when it involves corrections to several hundred employees, as might be required when the user finds that they forgot to include a payroll. It might not happen often, but when it does and the user is told they will have to enter all the corrections manually even though they have a corrected file in the proper format, they are not going to be pleased.

In a separate email exchange in July 2003, I expressed my misgivings about requiring the municipality to provide information from the Membership Application before they were allowed to include an employee on a payroll report:

ePASS Project Team:

Although I agree that it would be a great help to us here at MERS if RU's were forced to provide complete membership info on new members before they are allowed to submit a payroll report, I think it would be too much of a hardship for the RU. Isn't there some other way we could handle it? We could encourage them to provide the info when they add a new member, but I don't think we should require them to. Instead, could we not flash a warning something like this when a report is successfully submitted:

YOU HAVE MEMBERS FOR WHOM YOU HAVE NOT PROVIDED MEMBERSHIP INFORMATION TO MERS. PLEASE...

 It would go on to tell them where to go to enter the info.

 The person who prepares the payroll report may not be the person who collects the Membership Applications, so the information may not be readily available. Also, there may be instances in which it is impossible for the RU to get a Membership Application within the next few days . They may not be able to reach the employee. He could be on vacation, in jail, in a coma, dead, or at MERS' Annual Meeting. Are we prepared to fine a RU for being late with their report when the only reason they were late was because they could not get membership info for a new employee?

 I am not against allowing RU's to enter member info online, and I am not against strongly encouraging them to get it done. But I don't think we should keep them from submitting their payroll report because they don't have the info for one new member. Membership info consist of the following:

• Hire date

• Birthdate

• Address

• Beneficiary designation

Steve H.

 Here is Deb Peake's response:

We know there will be an adjustment for the municipalities to remember this information must be submitted with their payroll reports.  If this weren't required information to run the annual valuations and member statements at the end of the year, then we would agree with you.  We very strongly want this requirement in our department because our staff spends a considerable amount of time trying to track it down because the employers don't follow through. If we make sure the employers/payroll departments know ahead of time that this is a new requirement of this program, hopefully they will be ready when they start reporting on it. 

Here is Luke Huelskamp's response:

Steve in other Pension payroll systems I have worked with they require you to have the information before you submit your monthly payroll.  ICMA, Manulife, and others won’t let you submit unless that person is set up.  I know it may be a bit of a bother for some of the municipalities but by and large that information should be readily available.  Thanks, Luke