I previously wrote an article on the FSA dates for Benefits Open Enrollment and got positive feedback (Which I really do appreciate), along with many additional questions on Benefits Open Enrollment on ESS. From my experience with my own clients, as well as other consultants that I have spoken with, it appears that many people have had issues with open enrollment this year on ESS if you are using the ABAP Web Dynpro version (Which was released in EP6). If you go to OSS and do a search for this functionality it is clear that SAP made a lot of changes/fixes to the program, and in the process may have created some new issues. In this blog post I wanted to talk about my experience debugging a particular ESS Benefits Open Enrollment issue that we found. I will give a little bit of background on the issue, the client (This one happens to be the same client that my previous post was referring to), as well as my steps and approach in the issue debugging.

For this particular issue, I had a colleague come to me for help in regards to an error message that she was receiving when testing Benefits Open Enrollment on Employee-Self-Service (ESS). She had done all of the new configuration for open enrollment and for this year the client changes were to delimit the existing plans and create all new plans for medical and dental. This seemed straightforward enough, delimit the old plans and create new ones – no problem.

Here is a little bit of background on my client (Same client as my previous blog post)

  • SAP ERP 6.0 EHP 6 (Upgrading to EHP7)
  • Handles all Benefits through SAP
  • ESS via NWBC (ABAP WebDynpro Application)
  • Plan Effective Date = 12/15/2014
  • Open Enrollment Period = 11/24/2014-12/05/2014
  • SAP Gross to Net Payroll
  • Mostly standard SAP implementation

So my colleague did all of the configuration and moved the transport to QA in order to test and as soon as she tried to change ANY plan (Not just medical or dental) in ESS SAP would give an error message “No entry for benefit area”.

No entry for benefit area.png

This error message obviously points us to Infotype 171 to make sure the benefit area is filled (Typically comes from feature BAREA). I went and looked and everything seemed normal. I tested with a few other employees just to make sure it was not something employee specific or bad data, but still got the exact same error message. I looked through all of her configuration in the IMG and everything seemed like it was perfectly fine – she hadnt missed anything and nothing was glaringly wrong. I tested via PA30 to make sure that I could put the employee on the new plan and  delimit the existing plan with all of the correct dates and no problem. Next, I tested the benefits program within SAP (HRBEN0001) and while I did run into an error – it was completely different and related to the dates that were being pulled back and the delimited plans not falling within the dates and I was able to get it to work after playing around with it.

Now that I had ruled all of the items listed above out, the next logical step for me was to Google the error and look for other people who have had the same error message. However, when I did a search we did not see anyone else who had gotten this precise error message. Many people had the similar error message “No entry for benefit PLAN” but not an error message relating to the benefit AREA. Next, I searched for existing OSS notes and found some promising ones (1933378, 1936091, 2031955, 2072587, & 2081691 – I told you there were a lot of changes SAP made this year) but ultimately none of them panned out.

At this point I was a little bit confused on what was going on and unfortunately the next step was to debug the ESS benefits program to see why this was occurring. Debugging ESS is always more challenging than debugging anything within SAP because you have to first find the appropriate code that you want to set an external breakpoint and it is definitely a challenge to find the code that triggers at the appropriate time of processing. In SAP you can use the /h command within the transaction bar whenever you want to get the debugger to trigger.

So I did a bit of searching and found ESS Benefits function modules and thankfully SAP named them uniformly. Within SE37 you can search for “HR_BEN_ESS*” and there are 99 hits. I tried to narrow it down by looking at the description in order to see which function module that I should set my external breakpoint on, but still had to use trial and error to determine which one triggers at the appropriate time. Ultimately, Function Module HR_BEN_ESS_MODIFY_PLANS  was the one that worked for me in order to identify where the error was occuring. Within this function module I dug into it and found the following logic in my screenshot below with the root cause being the internal tale selection_display_gt not being filled when it should already have values in it from prior processing. As a result of this not having any values, the program ultimately (About 8 function modules/subroutines into the program) runs into the error of not being able to find a benefits area (Because it is looking for a blank benefits area which does not exist).

Read table.png

I did a “where used” on this field within SAP to find out where this internal table should be filled and see that it should be within HR_BEN_ESS_FILL_SELECTION_DISP. This is called from FM HR_BEN_ESS_FILL_GLOBAL_TABLES which is launched as soon as you click the accept button on the initial screen. In order to continue debugging I now set my external breakpoint within this function module.

Code Shot.png

So while I was debugging, my colleague was testing other scenarios. She found that if the associate did not have an existing plan (Or if we delimited it before 12/15/2014) then ESS processed everything correct. Now that I had two scenarios to compare I could see what was going on in the standard SAP program. It is always help to have a working scenario and a non-working scenario to see how and where they process differently.

What I found was that in the incorrect scenario the FM that is called directly before HR_BEN_ESS_FILL_SELECTION_DISP which fills the global tables (HR_BEN_ESS_GET_PARTICIPATION) has an error in it (Within the error_table there is an error message No entry for Plan ABCD Option ABCD dependent coverage ABCD) when it returns within the incorrect scenario.

This is because it is looking for the existing plan as of 12/15/2014. However this plan was delimited as of 12/14/2014 and with it no longer being around SAP is throwing an error. As a result of this error when it goes to the immediately following logic check to makesure subrc eq 0, it fails the check and bypasses the logic to fill the internal table selection_display_gt via FM HR_BEN_ESS_FILL_SELECTION_DISP and leaves the processing with the code check SUBRC EQ 0 (But it does not display any error message in the ABAP WDA) so the user has no idea that anything is wrong!! SAP needs to fix this so the error is displayed!!

Code Shot 2.png

We did try delimiting the plan on 12/15/2015 and the error did go away and the processing worked, but the issue with this is that now the plan is available to be selected during open enrollment when it should not be.

I believe what may be incorrect is the begin date variable (process_begda_g) passed to FM HR_BEN_ESS_FILL_SELECTION_DISP should be subtracted a date and use 12/14/2014 instead of 12/15/2014. Even the SAP comments have a note saying “Get current plans between today and of process_begda – 1” but nowhere in this logic does it subtract a date.

Code Shot 3.png

In order to do a proof of concept on my theory I manually changed this variable in the debugger to use 12/14/2014 and everything appeared to process just fine and I was able to add/remove plans. I advised my client to create a high priority OSS note with SAP with all the information from my analysis, but unfortunately SAP could not get to the fix in time to meet the requirements of our open enrollment date. We were very short on testing time and rather than do an enhancement spot in the standard code, my colleague and I created an LSMW in order to delimit the existing plans for everyone so that the program would process correctly. The reason I decided against doing an enhancement spot is because I was not 100% sure that subtracting this date minus one is the correct fix, or if that will have adverse impact elsewhere. Given our timeline and inability to retest everything we decided to go with the safer route. Also, I expect SAP will update their own code with a note to fix this issue and it may have an impact on any enhancement spot that we put in place. I will update this article when SAP responds to the high priority issue and provides a fix so that anyone else who needs it will be aware.

When you find an issue with SAP functionality, I always recommend my clients and other consultants to create a note with SAP. I have found that far too often people just elect to bypass or fix the issue themselves and SAP does not hear about the issue in order to resolve it and other people having the same issue may not get a fix and could have problems in the future. For this particular issue, many clients wont face it because it appears to only be relevant if you are delimiting prior years plans, which many companies will not be doing. Even if you are too busy and are sure that SAP cannot get the fix in time to meet your requirements, I still encourage you to at least create a note with SAP to make them aware of issues with standard functionality.

I hope this blog post helps anyone else who may need to debug an ESS Benefits Open Enrollment issue! Feel free to leave comments and feedback if you have anything to add or anything else that you have found to be helpful when debugging ESS/Open Enrollment.

**Update 12/31/2014** – SAP has released a note that fixes this issue. The OSS Note = 2112870.

I pulled the note up in SNOTE to see the changes, and this is a 1 line code change by SAP to comment out “SUBRC EQ 0” which was the logic that I pointed out in my previous analysis that makes it so the global internal table is not filled due to the hard error. When my client asked SAP why the root cause (The error message saying the plan/option/dependent coverage does not exist) is not displayed on the screen they replied letting us know that the error message “is only relevant to be displayed in HRBEN0001 because it is valid to be seen only by administrators and not by end-users”. Here is a screnenshot of the note (With NWBC 5.0 & Tabbed browsing, as well as the new SAP Blue Crystal theme) as well as a screenshot showing the changes

image 1.png

image 2.png

I did respond to the note to SAP asking them if it is correct for the original error message to even occur and pointed them back to my analysis on why I think it should not have occurred. They responded saying they will conduct an additional analysis to determine if another change is needed for that error message displaying incorrectly.

**Update 02/02/2015** – SAP has released another note that fixes this issue. The OSS Note = 2031822

Here is the SAP Reps response “I am happy to let you know that I have found the root cause of why the Dental and Vision Plan options are not being presented. Also, I will explain below why you are getting the error in the first place. First of all as per your current system configuration the Plans are not delimited, it is still valid.That is the reason why the existing Plan options are still being verified and the error occurs. The error ‘No entry for Plan ABCD/option ABCD/dependent Coverage ABCD’ occurs because the combination of this Plan option and Dependent coverage is valid only until 01/25/2015 as per the cost rule definition(Table T5UBB). If you check the table T5UBB you will not find any cost rule associated with the dependent coverage ‘ABCD’ from 01/26/2015 onwards. Since the system is not able to find the cost rule defined for the existing Plan’s dependent coverage option it gives this error. That is the same reason why you were not getting any Plan options listed for Vision Plan also. But if there are other valid cost rules defined for the same Plan with other options then those options needs to be displayed for enrollment. Then the end user will have the provision to change to other options from the current invalid option. This is not currently happening in your system. This is due to a bug in standard which was recently corrected with Note ‘2031822’. Hence kindly implement the Note ‘2031822’ and test whether you are able to get the right options displayed for Dental and Vision type Plans.”

Image 1.png

Once again, I cannot stress the importance of creating notes with SAP for standard issues to make sure that they resolve them rather than just fixing the issue yourself – this helps make the software better for all of us!!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Krishna Kishore

    I did find the same issue and opened a high OSS message with SAP but until now resolution.. 🙁

    Our issue was different though, one of the dependent data is not correct and instead of showing the dependent error, it simply will not fill the global internal table and when we try to change the plan it shows the same error( because of no data in that internal table). Seems Benefits enrollment is not yet fully tested. Fortunately our’s was an issue with 10+ employees so we managed with entering manually for them.

    1. Imran Sajid Post author

      Hi Krishna,

      Thanks for sharing! Just curious, did you guys delimit some existing dependent configuration (Option/Plan) from last year? I am wondering if the message in the error table is displaying incorrectly as is the case in my scenario above and if the solution I proposed in the article (process_begda_g – 1) would work in your scenario as well or if there is a bigger issue going on.

      I am glad that the impact was much more limited in your scenario and that you could handle it manually. SAP has still not given a solution to the note that we created as well, and we had to use the workaround of delimiting everyone’s existing medical and dental records with an LSMW.

      SAP definitely needs to make a change so that the message that is in the error table is output to the front end screen so that people can at least have a correct idea of their issue because most people are not going to debug the standard program in order to determine the issue. This is especially true for scenarios where people may have made a mistake in their configuration and the program is throwing a completely non-related error message.




Leave a Reply