The following notes have been delivered that will significantly improve the performance of the lanes including the expanded lane for HR Renewal for ESS/MSS -
In one project there was a requirement to maintain persons in appraisal document body. This was done in BADI HRHAP00_ENHANCE_FIX.
Also position's name was required next to person's name.
Standard solution - Z column with BADI HRHAP00_HRHAP00_VAL_DET with autofilling comment field. But comments are hide by default and user have to unhide them every type. Users were very fastidious and claimed more comfortable solution.
The Solution:
There is web description for every element. But unfortunately it is a constant in standard appraisal system.
Lets do it dynamic like this.
And enhance two FMs HRHAP_DOC_BODY_ENHANCE and HRHAP_DOCUMENT_GET_DETAIL in the end, instead of variable [plan] fill descriptions from position's name.
FIELD-SYMBOLS: <descr> like LINE OF t_body_element_descr.
DATA: ls_plans type pa0001-plans,
ls_text type hrp1000-stext,
ls_element like LINE OF t_body_elements.
LOOP AT t_body_element_descr ASSIGNING <descr>.
IF <descr>-tline = '[plans]'.
Read table t_body_elements into ls_element with key row_iid = <descr>-row_iid.
SELECT single plans into ls_plans
FROM pa0001
WHERE pernr = ls_element-foreign_id
AND begda <= s_header_dates-ap_end_date
AND endda >= s_header_dates-ap_end_date.
SELECT SINGLE stext into ls_text
FROM hrp1000
WHERE plvar = '01'
AND otype = 'S'
and objid = ls_plans
and begda <= s_header_dates-ap_end_date
and endda >= s_header_dates-ap_end_date
and langu = sy-langu.
<descr>-tline = ls_text.
endif.
endloop.
After that we have persons position's name next to name of element (person's name).
We’re honored to be recognized by the 2014 IDC MarketScape for Worldwide Integrated Talent Management. We believe this report is a further testament to not only our comprehensive, integrated talent management suite, but also to our strategy and direction in talent management.
But perhaps first and foremost it’s a testament that our customers – like you-- are able to derive strategic business value from our talent solutions. So, thank you to all of our customers for trusting us to help attract, develop, and retain their organization’s talent.
Being recognized as a leader in talent management by the IDC MarketScape means that our current capabilities, and our strategy and direction are at the forefront and setting the pace for what’s possible in talent management. In fact the IDC MarketScape specifically mentioned our strengths around depth of our portfolio, global reach, features, technology, and reporting. You can download an excerpt of the report here.
It’s important to note that the IDC MarketScape’s assessment is based on taking an intensive look at our talent management offering (including things like integration), go-to-market (things like service and support), and business (things like growth, viability, and employee engagement) -- each based on both current capabilities (today) and planned strategies (tomorrow).
Our focus on talent management innovation and customer success has never been stronger. As a proof point, and in addition to our continued enhancements in Workforce Analytics and mobile experiences, here are some of the innovation highlights in talent management we’ve released in 2014:
· Talent Presentations– enabling you to prepare presentations in record time, blending PowerPoint files with live data and insights from SuccessFactors.
· Learning Programs and Quick Guides– supporting our expanded vision and direction for learning- where everyone in the organization can become both a student and a teacher
· Recruiting ‘Marketing Central’– making it simpler to manage candidate marketing across a variety of sources
· Onboarding ‘Guided Tour’– creating a more intuitive, engaging experience for new hires
· Enhanced Goals Management Experience–making goal setting and management even easier
· Automated ‘Push’ of Suggested Roles to Employees– creating better employee engagement and retention
· Compensation Custom Fields– creating more flexible compensation plans based on your unique business requirements
And we’re not done yet. Some key talent highlights of our upcoming final release of 2014 will include: Action Search– an incredible new, intuitive search that provides immediate access to people and actions. We’re also unveiling New Talent Analytics Tiles– which are pre-built and ready apply to your SuccessFactors home page for quick visibility into talent process status.
Plus, we’re increasing the flexibility and insight of Talent Flow Analytics– so it will be even easier to view and assess talent movement – in, thru, across, and out of departments, organizational units, geographies, jobs and many other categories.
Speaking of flexibility, this is one of the hallmarks of our Talent Management suite—you can start with any of our talent solutions, and grow into other areas over time. This gives you the ability to act tactically and get results fast- yet plan and scale over time based on what makes sense for your business.
We maintain a passionate, deep development and commitment not only on unified talent experiences, processes, and data – but also on each specific talent solution area: Compensation, Learning, Succession & Development, Recruiting, Onboarding, and Performance & Goals.
And speaking of commitments—we just made quite a few to you – our valued customer. These commitments were originally communicated by Mike Ettling our HR LoB President for SAP/ SuccessFactors, at SuccessConnect. Beyond product innovation they specifically spell out even more ways we will improve our service and support in talent and our entire HCM suite as we move into 2015.
As you’ll hear Mike mention, we realize – just like the IDC MarketScape has affirmed-- success and leadership is not just about “product innovation” – perhaps even more importantly, it’s about service. We look forward to continuing to deliver innovative talent capabilities and simply amazing service and support. Thanks again for your continued trust and confidence.
I recently had the opportunity to meet and speak with Mike Ettling, the recently appointed President: HR Line of Business at SAP. In this role, Mike now leads both the on-premise and Cloud HCM business areas for SAP. In this Q&A, I chatted with Mike about future of HR, customers, and putting the Service in SaaS.
Thanks for joining me Mike. Could you take a brief moment to introduce yourself and your role at SAP?
It’s a pleasure Luke. I always like to use what I have on my Twitter account: Husband, Dad, supporter of the Springboks, running the leading and only profitable cloud business in HR. Changing how we engage our talent all over the world.
How do you see the current state of HR technology and what is your future vision for SAP?
The current state of HR technology is very exciting and interesting. Obviously there is a huge amount of change in HR at the moment and technology is all about trying to enable organizations to cope with their change. At the same time, it’s also a very challenging environment because there’s so much change, because there are so many challenges, because legacy HR technology has been around for so much time and people are looking for something new. The pressure on making the right decision is higher. The challenge I have is not what is the point B that clients need to get to, but how do they get from point A to that point B? It’s a very exciting time; there’s lots of innovation happening at the moment, but it makes the decision harder for customers.
We want to be the company that creates enabling technology and enables their workforce to be better engaged. It’s all about better engagement. We want to be the company that is the trusted advisor to get from point A to point B, not just the company that sells the solution at point B.
You’ve inherited both the existing on-premise business as well as the SuccessFactors business, which has largely been incorporated into SAP. What sort of challenges do you see on the road ahead and how do you plan to address them?
I’m always the glass half full guy. I always tend to see opportunities more than challenges. I’ll give you an example. How do you integrate the broader part of SAP and how do you leverage 7k sales people in driving the growth and business of the company? There’s a tremendous amount of opportunity going forward. The single biggest thing to get right is going to be that most of the cloud companies started with SME and mid-market customers. SAP is known for serving the enterprise-level customers. The thing to get right is: how do I scale this business to be a natural choice for Fortune 500 companies? The challenge for most cloud companies will be dealing with these type of customers. We are better placed than most.
How does SAP’s overall simplification message fit in with your HCM strategy? Will this impact SAP’s existing messaging around on-premise and Cloud?
“Run Simple” plays right into the market and our software. We think that the whole concept of SuccessFactors is running simple and we’ve been doing it for many years. One of my big mantras is around simplification and standardization through the cloud. I couldn’t have asked Bill to pick a better rallying cry for the company than “Run Simple”. It’s so relevant in the HR world right now.
What are your views on the second S in SaaS: Service?
It is absolutely essential. It is ignored by many of the other cloud players in the market and is misunderstood. I’ve said publicly that we’ll make service a differentiator in the marketplace in the next 6 to 12 months. I fundamentally believe that one of the interesting things in the market is that service in the SaaS world is the opposite side of the coin from service in the outsourcing world. Service in the on-premise world is a totally different point. One reason that SaaS companies struggle with getting the service part right is because they use leaders from the on-premise world. The skills you need are all in the BPO and IT outsourcing service world. It’s one thing doing it for SME and mid-market clients, but it is different thing doing it for enterprise customers of 50k, 100k employees. SAP has traditionally been good at this. This is one area where we take SAP capabilities like MaxAttention, escalation process, etc. and try to deploy them in the cloud world. It’s going to make a huge difference in our positioning in the marketplace.
What are your views on “architectural purity”? Do single architectural models work in today's world of innovation, speed, acquisitions, and hybrid environments?
I think there is too much hype in the market and too much noise about architectural purity. They’re kind of putting the cart before the horse. Tech is there to enable business and if I want to be a total cynic then I would say look at platforms like Tesseract Payroll Software – which are still running the payroll of major companies – and General Mainframe software – which are still running major financial institutions transactions
Business outcomes and ROI are more important, as is architecture that is scalable and that can create a price point that is effective to achieve those outcomes. It just so happens that one way of achieving that is using the Metadata Framework (MDF) – a single object model architecture – but in 2 to 3 years’ time that paradigm might change. I see too much written by certain analysts in the market that if it doesn’t comply with certain architectural standards it doesn’t suit a client, but I don’t think that is fair. Shouldn’t it be what helps the customer? Shouldn’t it be what benefits them and helps to achieve ROI?
There are often examples of inconsistency with SuccessFactors branding, particularly across SuccessFactors’ own materials. Will this be addressed as part of your simplification?
It is being addressed and is continuing to be addressed. We are not dropping the SuccessFactors brand and we’ve recently designed new brand standards. Our business cards at SuccessConnect Vegas show the new brand logos. There is dual-branding; the strength of SAP and the strength of SuccessFactors have a lot of benefits together. We will continue to use the SuccessFactors brand for our cloud HR business.
We’ve tidied up a lot of our presentation decks and material recently and we are going through a 2nd iteration now. We are also making them more business-oriented rather than tech-oriented. So absolutely there’s a desire to not lose the SuccessFactors brand and a desire to get much more consistency in the materials that we use when we’re out in the marketplace.
One of the big things that this touches on is that I’ve appointed a head of innovation and enablement and I’m building – or re-building – an enablement and innovation and excellence group. They will look after content and all enablement to support people, partners, and sales people. We will centralize this in one group. It has been a bit dispersed over the last 2 or so years before I joined and this has helped create some of the inconsistencies that are being experienced in the field.
With the release of SAP Simple Finance, do you see a synergy with packaging Cloud HR and Cloud Financials?
We play in the big boy’s league when we play with finance. The complexity of the finance we play with is very high. What is important is that there is a degree of data integration that you need between any Finance and any HR system. Org structures need to be passed to finance for approvals and cost center structures need to be passed to HR. We built an integration to on-premise finance that is critical (3rd party systems will never get that right). We will have a tight integration with Simple Finance as well. I don’t believe there is a unique advantage to have a single architecture and data model around finance and HR. I think analysts hype this too much. If you are a small services company, for example, then this could be of an advantage, but that is a procurement decision when it is cheaper to run solutions from one vendor. Yes there will be integration and yes it will be unique, but we play in the big leagues when it comes to finance so it’s not something we need to offer as a combined offering.
How do you plan to address education and training?
There’s a lot of investment going into training. Once the enablement group is up and running we’re going to invest a lot in OpenSAP and we’re going to introduce a SuccessFactors introductory course on OpenSAP. We’re going to leverage all of SAP’s learning capabilities and we need to communicate that better. We’re divorcing the consultant training from the partner certification. Today, consultants can only get training if they work for a partner. We’re going to open that up. Anyone can go and get training, but we’re going to control the quality and control the certification of partners. We want to create a vibrant marketplace for SuccessFactors consultants to invest in their own training. I want someone to come out of college and think “If I can get trained on SuccessFactors, I can get a better job”.
Although my overall experience is fairly positive and some customers have highlighted an improvement with SuccessFactors Support, some customers still have concerns. Do you have any plans to enhance the customer support experience?
Support is something we want to turn into a differentiator. We recently made the commitment to our customers that we are one team here to serve them. We also made two commitments to our existing customers:
There are opportunities to improve and we know what it is as we’ve done a large study of customers. They’ve told us what is working and what isn’t. We’ve got a roadmap of what we need to do to be a world class support organization. When I look at customer satisfaction it is improving every quarter. Is it where I’d like it to be? No, but I know where I want it to be. By Q2 next year I hope that our support is going to be very differentiating in the market.
If you could provide one message to SAP ERP HCM on-premise customers, what would that be?
Don’t be afraid. We are here to help you on this journey from A to B. We’re the only player that can really enable you on this journey with a hybrid model. We’re not going to ram rip-and-replace down your throat. We are best equipped to help you on this journey with low risk and high ROI and to ensure that you leverage your existing investment and get those returns at the same time. The way we do this is through things like the hybrid model and maintenance replacement offers.
Thanks for joining me Mike, it’s been a pleasure to talking to you.
Thanks Luke. It was great to chat again and great to catch-up.
Mike can be followed on Twitter via @mikeettling You can find me via @lukemarson.
If there was ever a better, easier use-case for HCM Processes & Forms and furthermore, HCM P&F using the "old" Adobe Interactive Forms interface than bringing your company into compliance with the "new" Voluntary Self-Identification of Disability requirements, then I would love to see what it is! This is literally the easiest, fastest HCM P&F process I have ever built. But what is the urgent need for it and why do you care?
Well, under revised United States Office of Federal Contract Compliance Programs (OFCCP) regulations implementing Section 503 of the Rehabilitation Act of 1973 (Section 503), covering individuals with disabilities, employers must invite job applicants and employees to self-identify their disabilities on a standard “Voluntary Self-Identification of Disability” form prescribed by the agency. The final, "legal" form was approved on January 22, 2014.
Under the new regulations, employers are required to survey their existing workforce within the first year of the employer’s next regular affirmative action program (AAP) update following March 24, 2014, the effective date of the regulations. Furthermore, the form must be provided to employees at least once every five years. That means if employers/companies have not already provided this to their employees/applicants, then it is high time to get on the ball!
Here is more information about it direct from the government .... http://www.dol.gov/ofccp/regs/compliance/section503.htm ....and here is the PDF form itself... http://www.dol.gov/ofccp/regs/compliance/sec503/Voluntary_Self-Identification_of_Disability_CC-305_SD_Edit1.24.14.pdf
So what does this mean for us working within the trenches (or "paradise" depending on your perspective haha) of SAP HCM? This kind of information is typically stored in infotype 0077 (Additional Personal Data) along with things like race and veterans status. I have heard of many companies as well as have my own clients that have looked for the best way to handle this to insure compliance (especially in large organizations where we are talking several thousands of employees and possibly thousands of new applicants daily as well!). Sure there are many possible solutions, but of course, HCM P&F is near and dear to my heart. haha
Let's see here....so we need a PDF-like form where the employee can go online, make their selection, submit it and their HR specific record gets updated? Hmmmmm now why does that sound so familiar? .....where have I heard that before?.......hmmmmm....Oh yeh! That is EXACTLY what HCM Processes and Forms can do! So why not use it?!?!?!?! But now.....some other considerations.
Although Adobe Interactive Forms (AIF) are considered "the old way" now in HCM P&F, they are actually the BEST solution in this case. Because our form requires very specific layout (font family, size, position, etc) and the US government already provides it as a PDF, it is very easy to duplicate (import and modify with our needed data bindings) as a HCM P&F form. This is just not possible (and you will get arguments that it does not meet legal requirement either) if you use the "newer" FPM forms or other similar solutions. Yes, this is that one special case where AIF beats FPM hands down...there....I said it...you read it....let's move on. haha
Now, aside from using AIF, we do have some technical hurdles. As you should know if using HCM P&F, we rely on the decoupled (detached) infotype framework. In it, there are classes for our infotypes such as 0077. Within some of these, there are stricter "validations" than one might encounter in the "old" PA30 way of updating infotypes. Sadly, many of these "checks" will cause us grief for automating our IT0077 updates. Thankfully, SAP released some notes/updates related to this (thanks to my good friend Siddharth Rajora who is always on the "ball" for providing this information ...look at notes note in sequence to apply: 1 - 1976932 2 - 1996041 3 - 1995948 4 - 1995949) which will modify some of the decoupled infotype class "validations" and other things that will need to be taken care of to properly handle our updates to IT0077 via HCM P&F.(side note: in some case, especially for clients not on correct component levels or can't apply notes/packs as mentioned, I have seen them just create their own simple custom infotype with the fields needed to store the selection, dates, etc. and use that in place of IT0077 and the standard IT0077 related decoupled infotype classes....so it is even possible that way too but will require a bit more work)
Pretty much, all you do is map each field form the US IT0077 structure (make sure you use the US structure and not just the "common" XX one or you will hit Veteran Status errors) to your form scenario fields in SAP_PA. I go the extra step of flagging the "disability" date fields to be excluded from the operation since there are still "checks" in the standard 0077 class that will error/warn you about entering those dates. (You may need to check your own requirements in case you need to actually set the disability related dates...disabled date/date learned....as they may require you writing your own backend service to set these correctly based on user's selection...but even this is easy! You will notice these are checked in the class CL_HRPA_INFOTYPE_0077_US method CHECK_DISABILITY as well.) Secondly, set your operation as a "change" on IT0077. Lastly, I add a "rule" assigned to this operation so that it only does the "change" if the user has selected an allowed value for the "disability status" (you need to check your own value range allowed.....but let's say we only allow "X" , "N" or "A"). So my configuration looks like...
Overview
SAP_PA operations
SAP_PA fields
Rules
....better known as "the proof is in the pudding". haha....here you go..
(1) before running the form, we look at our employee's IT0077 record via PA20 and get:
(2) now we execute the form, make our selection, and submit.
(3) now looking again in PA20 at the employee's IT0077 record, we can see our selection is there.....and in compliance! (haha)
I won't get into it here (because in good ol' consultant speak "it depends" haha), but your next step will be to make this available via your ESS solution. This might involve changes to your homepage framework or launchpad configuration (or elsewhere) and possibly portal content changes as well. But I will leave all that fun to you. Hey, I can't do all the work for you....at least not for free! hahahaha
Well, like I said.....(1) easy (2) quick (3) best use of AIF I have seen! I hope this helps as I know others are looking to get this knocked out quick as well. As always, I do it just to help others and will keep blogging if you keep reading (haha). Till next time...
Based on practical experiences I can say that Agility approach will benefit a lot in transformation program of HR administration into integrated system. And this time not the enablement of creativity will be the main benefit. This time the learnability will profit by iterative approach: learning of the team by “hands-on” exercises will enable changes caused by discovering of new possibilities and not very formalized aspects of legacy system as well as bad quality of migrated data.
Simply put: instead of investing a lot of time and money in scrupulously efforts to describe the to-be in blueprint with view on inevitable changes that may destabilize project schedule get the changes as the drive of the project and call them A.S.A.P. That means lean blueprint and first prototypes in paralell of the main components.
Transformation of HR Administration I define not only in scope of HR-PA implementation but also the wide aspect of realization (automation) of all aspects of employees in SAP or/and integration and providing all other back office and front office systems with adequate subset of personal data. By the way: still many organizations have a lot to do in this area.
I see a lot of possibilities to use ASAP Agile as effective method on SAP Projects like I wrote in:
AGILE for SAP implementation? Yes of course!
I am very interested in your opinion.
My disdain for the HCM Processes & Forms (HCM P&F) interpretation of "user event" is pretty well documented. I have let it be know via blogs, forum posts, etc. that I think the way HCM P&F user events are handled is completely backwards from what any developer (especially those with an OO background) would think of them....let alone any person with "walking around sense". I will not "beat a dead horse" and go into that again here. I will just say that I do not like how they are configured, but I have learned how to deal with them when needed through a few tricks of my own.
One of the major problems with HCM P&F is that all you do is define an "event" and then what fields should be passed to the backend for the event. It then leaves it up to the framework to determine from the fields passed back, what operations/services those fields are used in so that they should be executed. People have come up with clever uses of rules and "flag" fields to help handle some of this. There really is no way to define a "listener" for the event or say "for this event XXXX, I want you to only do this operation from this service"....well, that is until now. I have a few little clever tricks up my own sleeves that I use to handle this. In this way, I can tell exactly WHICH event fired. I can then "listen" for that in my own services and respond to it without the needed for additional rules, "flag" fields or the like.
If you are still using Adobe Interactive Forms or anything other than the FPM form options for HCM P&F, this method will apply to you. I am not particularly fond of this solution as it (1) requires an enhancement to standard SAP code and (2) it relies on memory handling commands. However, it DOES work VERY well.
The first part is an enhancement t to class CL_HRASR00_GENSERV_MAPPER method IF_HRASR00_MAPPER~DO_OPERATIONS that sets/exports to a “memory ID” which can be retrieved later.
If you have it available on your system (came available in a later HR Renewal feature pack), the class CL_HRASR00_PROCESS_EXECUTE method EXECUTE_EVENT_PRIVATE is probably a better location for the enhancement as this would catch the event (and any events) much better. There is an enchancement spot right before the "DATA" statement that you can use just as the example above.
Now, within my own generic service (in initialization, "do operation", help data methods or where ever), I can read this memory ID value and find out exactly what event was triggered.
(*note: be careful "freeing" the memory ID if you might need it elsewhere in other services later)
So now, I could for example, always read this in my "do_operations" method and maybe have a whole other set of logic for the "user event" but otherwise call my operations as normal or I could just say "if this user event was triggered, do nothing....just leave." as I would have done with a "rule" before.
If you are using the FPM form option with your HCM P&F processes, you are in luck! Because you are using the Floorplan Manager (FPM) framework, you have a whole new world of interfaces and classes available to you. I stumbled upon this quite by accident when actually looking at other standard SAP code that uses several FPM interface classes. I saw one that read the "events" and had a "eureka moment" of my own. I out in similar code into my own backend service and "viola", it worked like a charm!
Now, from anywhere within your own custom generic service, you can now get a "handle" to the FPM instance and "listen" for events. The code is as simple as this....
Now.....to REALLY blow your mind and/or put a smile on your face, we can go a step further. We can now not only say "user event XXXX was triggered", but we can also know exactly which form field triggered this event! Check out this simple code that "listens" for my custom event and also will tell me which field sent it....
So now, in a round-about / let's-make-it-work-when-it-doesn't-work-normally kind of way, we can define true "event listeners", and we now have the power to respond exactly how we want to an event. Keep in mind, this allows us visibility to not only our "custom" user events, but we can also "see" any of the other standard events as well ("check", "initialize", and many more). This means we can completely handle in code how we want to respond/react and not just execute the operations we have exposed and configured in HCM P&F Design Time. We might have code in "do operations" now that says "if CHECK event, then call operation XYZ for field validation.....however, if user event MY_CUSTOM_EVENT was triggered, don't validate but fill in other help values". I am sure you can come up with SEVERAL use cases of your own (haha).
Well, as always, I hope this helps. I thought it might be an interesting new take on "user events". Heck, I might even be close to saying I kinda like HCM P&F user events now.....I said "might" (haha). I have more blogs planned, so I better get to it. Till next time....
If you read my recent blog, HCM Processes & Forms: Making "User Events" Useful Again!, you might have caught on to the very cool fact that in FPM forms, making use of FPM interface classes, we can tell exactly what "event" is triggered and which form field triggered it. Of course, this got my head spinning with all kinds of use cases, but the first that came to mind was the good old, tried-and-true "make selections in a drop-down list control the options in another drop-down list" (also known as "dependent drop-down lists"). But that's "low hanging fruit". I thought "how can I make it even cooler?".
What if I showed you a way to make a secondary "dependent" drop-down list whose options we populate in response to the "change" event on our primary drop-down (ie. "master")? But now because I can tell which form field triggers the event, what if I can also populate (add additional entries?) depending on which form field triggered the event (for example a "regular" drop-down list vs. a "super user" drop-down list). So then, we have TWO "master" controls that will fire an event and our "dependent" control will populate accordingly (ie. because it knows WHICH master threw the event).
First, I built a basic process and form scenario.
Make a simple process
Form Scenario based on FPM form
I defined 3 Form Fields and assigned all the data element "SUBTY" ( a char 4 field). Notice that their "input help" (ie. F4) values are configured to come from my backend service "Y_GS_SOLO".
User Event
This is a key step. I defined a simple user event, made a field group with our 3 form fields and assigned the field group to the user event.
FPM Form definition/development
I developed my very basic FPM "form" type configuration.
The FPM attributes for the "Food Category" and "Food Category (Super Shopper)" drop down list set the user event "UE_CAT_CHANGE" (from our HCM P&F configuration above) on the "change" event of the drop down list. This is another key step in making it all work.
Backend Generic Service
You might have noticed in the Form Scenario configuration above, I developed one, simple custom backend service "Y_GS_SOLO". It has one operation "CHECK_CATEGORY" with my 3 fields mapped to it. However, the main "magic" happen in my methods to populate the help values (F4 values).
Before showing off the code, let's see how this all looks in run time, so you really get the idea of what is going on....
First off, you will notice that I have hidden the "admin/super user" field for now. I just want to show how this "dependent" population works from one "master"drop-down. The user first sees....
Now we make selection from the "master" drop-down list...
We can see in the ABAP debugger that the "event" is caught...
And now we can see the new options in the "dependent" drop-down list...
If we change the "master" again, we can see how it changes the "dependent" options again..
But now, I want to really get you excited about this. Again, because we know WHICH field triggered the event we are "listening" for, we can now react differently.
Here, I add the "admin/super user" field to the form. It will also trigger the same event that the previous, existing "master" drop-down did.
Again, we pick from our regular "master" field and get the options populated in the "dependent" drop-down...
But now, I pick from the “admin field”…..it fires the same event BUT we know where the even came from. In the debugger, we can see the fieldname of the form field that triggered out event...
So, now, we can make a different selection list based on which field fired the event…here, you can see I added option that ONLY the "admin" can pick from...
…and again, we make another round of changes and compare….
So you can imagine that you might have other logic that looks at the form scenario step or the initiator and determines which "master" drop-down to display. But then nothing more is needed for the "dependent" drop-down. It will merely have more or less options available that we handle already in our custom service. Therefore, the same form field can be used regardless. Very cool!
So how is this done? TO THE CODE!!!!! (haha)
First off, in our standard generic service interface method GET_HELP_VALUES, I have a loop that checks which "help" field we are talking about and calls a private method to populate these.
[code]
method IF_HRASR00GEN_SERVICE~GET_HELP_VALUES.
FIELD-SYMBOLS <help_dataset_wa> TYPE hrasr00gs_help_dataset.
LOOP AT help_datasets ASSIGNING <help_dataset_wa>.
CASE <help_dataset_wa>-fieldname.
WHEN C_FLD_FOOD_CATEGORY OR C_FLD_FOOD_CATEGORY_SUPER. "Category
CALL METHOD me->GET_F4_CATEGORIES
EXPORTING
SPECIAL_FIELDS = special_fields
SERVICE_FIELD_VALUES = service_field_values
CHANGING
HELP_DATASETS = <help_dataset_wa>.
WHEN C_FLD_FOOD_ITEM. "Items
CALL METHOD me->GET_F4_ITEMS
EXPORTING
SPECIAL_FIELDS = special_fields
SERVICE_FIELD_VALUES = service_field_values
CHANGING
HELP_DATASETS = <help_dataset_wa>.
ENDCASE.
ENDLOOP.
endmethod.
[/code]
Here is the code to load up the help values for the “food category”….
[code]
method GET_F4_CATEGORIES.
TYPES : BEGIN OF ty_cat,
code_val TYPE subty,
code_text TYPE TEXT40,
END OF ty_cat.
TYPES : tty_cats TYPE TABLE OF ty_cat.
DATA: service_field_value TYPE hrasr00gensrv_dataset.
DATA: field_catalog TYPE hrpad_f4help_table_column_tab.
DATA: field_catalog_wa TYPE hrpad_f4help_table_column.
DATA: lt_cats TYPE tty_cats,
ls_cat TYPE ty_cat.
FIELD-SYMBOLS <help_values> TYPE table.
" create field catalog
CLEAR field_catalog.
CLEAR field_catalog_wa.
field_catalog_wa-fieldname = 'CATEGORY'.
field_catalog_wa-headertitle = 'Category'.
APPEND field_catalog_wa TO field_catalog.
field_catalog_wa-fieldname = 'CATEGORY_TEXT'.
field_catalog_wa-headertitle = 'Category Text'.
APPEND field_catalog_wa TO field_catalog.
help_datasets-field_catalog = field_catalog.
help_datasets-keycolumnname = 'CODE_VAL'.
help_datasets-valuecolumnname = 'CODE_TEXT'.
CREATE DATA help_datasets-data TYPE STANDARD TABLE OF ty_cat.
ASSIGN help_datasets-data->* TO <help_values>.
ls_cat-code_val = '0'.
ls_cat-code_text = 'Fruits'.
APPEND ls_cat TO lt_cats.
ls_cat-code_val = '1'.
ls_cat-code_text = 'Vegetables'.
APPEND ls_cat TO lt_cats.
ls_cat-code_val = '2'.
ls_cat-code_text = 'Meat'.
APPEND ls_cat TO lt_cats.
<help_values> = lt_cats.
endmethod.
[/code]
And here is the code to detect the user event and which field fired it to then build our help values accordingly.
[code]
method GET_F4_ITEMS.
TYPES : BEGIN OF ty_item,
code_val TYPE subty,
code_text TYPE TEXT40,
END OF ty_item.
TYPES : tty_items TYPE TABLE OF ty_item.
DATA: service_field_value TYPE hrasr00gensrv_dataset.
DATA: field_catalog TYPE hrpad_f4help_table_column_tab.
DATA: field_catalog_wa TYPE hrpad_f4help_table_column.
DATA: lt_items TYPE tty_items,
ls_item TYPE ty_item,
lv_cat TYPE subty.
FIELD-SYMBOLS <help_values> TYPE table.
* determine event and field it came from
DATA: lt_event_queue TYPE cl_fpm=>if_fpm~ty_t_event_queue,
ls_first_event TYPE cl_fpm=>if_fpm~ty_s_event_queue_entry,
lo_fpm TYPE REF TO if_fpm,
lo_event TYPE REF TO cl_fpm_event,
lt_params TYPE apb_lpd_t_params,
ls_param LIKE LINE OF lt_params.
DATA: l_flg_was_admin TYPE bool.
CONSTANTS: c_usr_event_catchange TYPE string VALUE 'UE_CAT_CHANGE'.
lo_fpm = cl_fpm_factory=>get_instance( ).
CHECK lo_fpm IS BOUND.
lo_fpm->read_event_queue( IMPORTING et_event_queue = lt_event_queue ).
IF NOT lt_event_queue[] IS INITIAL.
READ TABLE lt_event_queue INTO ls_first_event INDEX 1.
IF ls_first_event-id = c_usr_event_catchange.
"do stuff for our user event!
ENDIF.
"determine which field fired event
lt_params[] = ls_first_event-parameter.
LOOP AT lt_params INTO ls_param WHERE key EQ 'FIELDNAME'.
IF ls_param-value = C_FLD_FOOD_CATEGORY_SUPER.
l_flg_was_admin = 'X'.
READ TABLE service_field_values INTO service_field_value WITH KEY fieldname = C_FLD_FOOD_CATEGORY_SUPER.
IF sy-subrc = 0.
lv_cat = service_field_value-fieldvalue.
ENDIF.
ELSE.
CLEAR l_flg_was_admin.
READ TABLE service_field_values INTO service_field_value WITH KEY fieldname = C_FLD_FOOD_CATEGORY.
IF sy-subrc = 0.
lv_cat = service_field_value-fieldvalue.
ENDIF.
ENDIf.
* l_event_fieldname = ls_param-value.
EXIT.
ENDLOOP.
ENDIF.
" create field catalog
CLEAR field_catalog.
CLEAR field_catalog_wa.
field_catalog_wa-fieldname = 'ITEM'.
field_catalog_wa-headertitle = 'Item'.
APPEND field_catalog_wa TO field_catalog.
field_catalog_wa-fieldname = 'ITEM_TEXT'.
field_catalog_wa-headertitle = 'Item Text'.
APPEND field_catalog_wa TO field_catalog.
help_datasets-field_catalog = field_catalog.
help_datasets-keycolumnname = 'CODE_VAL'.
help_datasets-valuecolumnname = 'CODE_TEXT'.
CREATE DATA help_datasets-data TYPE STANDARD TABLE OF ty_item.
ASSIGN help_datasets-data->* TO <help_values>.
CASE lv_cat. "build help based on category selected
WHEN '0'. "fruit
ls_item-code_val = '0010'.
ls_item-code_text = 'Apple'.
APPEND ls_item TO lt_items.
ls_item-code_val = '0011'.
ls_item-code_text = 'Banana'.
APPEND ls_item TO lt_items.
ls_item-code_val = '0012'.
ls_item-code_text = 'Orange'.
APPEND ls_item TO lt_items.
IF l_flg_was_admin = 'X'.
ls_item-code_val = '0014'.
ls_item-code_text = 'Pineapple (admin only)'.
APPEND ls_item TO lt_items.
ls_item-code_val = '0016'.
ls_item-code_text = 'Tomato (admin only)'.
APPEND ls_item TO lt_items.
ENDIF.
WHEN '1'. "vegetables
ls_item-code_val = '1010'.
ls_item-code_text = 'Celery'.
APPEND ls_item TO lt_items.
ls_item-code_val = '1011'.
ls_item-code_text = 'Lettuce'.
APPEND ls_item TO lt_items.
ls_item-code_val = '1012'.
ls_item-code_text = 'Spinach'.
APPEND ls_item TO lt_items.
IF l_flg_was_admin = 'X'.
ls_item-code_val = '0016'.
ls_item-code_text = 'Tomato (admin only)'.
APPEND ls_item TO lt_items.
ENDIF.
WHEN '2'. "meat
ls_item-code_val = '2010'.
ls_item-code_text = 'Beef'.
APPEND ls_item TO lt_items.
ls_item-code_val = '2011'.
ls_item-code_text = 'Fish'.
APPEND ls_item TO lt_items.
ls_item-code_val = '2012'.
ls_item-code_text = 'Pork'.
APPEND ls_item TO lt_items.
WHEN OTHERS.
ls_item-code_val = '0000'.
ls_item-code_text = 'Please select category.'.
APPEND ls_item TO lt_items.
ENDCASE.
<help_values> = lt_items.
endmethod.
[/code]
The “magic” is really this small piece of code which captures the event and the field that fired it. You can really use this anywhere (ie. in help value methods, your “do operations”, deep within your own private methods, etc.) , so it is quite nice for “event” detection.
[code]
* determine event and field it came from
DATA: lt_event_queue TYPE cl_fpm=>if_fpm~ty_t_event_queue,
ls_first_event TYPE cl_fpm=>if_fpm~ty_s_event_queue_entry,
lo_fpm TYPE REF TO if_fpm,
lo_event TYPE REF TO cl_fpm_event,
lt_params TYPE apb_lpd_t_params,
ls_param LIKE LINE OF lt_params.
DATA: l_flg_was_admin TYPE bool.
CONSTANTS: c_usr_event_catchange TYPE string VALUE 'UE_CAT_CHANGE'. “your event name
lo_fpm = cl_fpm_factory=>get_instance( ).
CHECK lo_fpm IS BOUND.
lo_fpm->read_event_queue( IMPORTING et_event_queue = lt_event_queue ).
IF NOT lt_event_queue[] IS INITIAL.
READ TABLE lt_event_queue INTO ls_first_event INDEX 1.
IF ls_first_event-id = c_usr_event_catchange. “here we can check for a particular event name
"do stuff for our user event!
"determine which field fired event
lt_params[] = ls_first_event-parameter.
LOOP AT lt_params INTO ls_param WHERE key EQ 'FIELDNAME'.
* l_event_fieldname = ls_param-value. <====this is the field that fired the event
EXIT.
ENDLOOP.
ENDIF.
ENDIF.
[/code]
Well, that is it. I hope you really see what is possible now with this, and it gets you as excited as I was when I "discovered" it. It's not even about drop-down list....it's about being able to respond (be it adding help values, show/hide fields, populate data, etc) by knowing not only WHAT event was triggered but also WHICH form field triggered it. It makes a lot of things easier and also adds a new level of form interaction. I know I will be using it! As always, I hope this helps others, and I will keep cranking these out as long as you keep reading. Till next time....
These are the highlights of the productized integrations made available as part of the November 2014 release.
Talent Hybrid Deployment Model
Packaged integrations supporting the Talent Hybrid deployment model
1. Integration of SuccessFactors Variable Pay with SAP ERP HCM
Feature Description: Variable pay is a significant element of the direct compensation package of a growing number of organizations. A packaged integration that connects SAP ERP HCM with SuccessFactors Variable Pay is now available. The integration will be powered by SAP Process Integration (PI) enterprise application integration (EAI) technology. The current implementation guides are available from help.sap.com/erp-sfi
Please note that parts of this packaged integration have dependencies on on-premise SAP ERP HCM support packs which will be released in January 2015. Support for SAP HANA Cloud Integration (HCI) is planned for January 2015.
Full Cloud HCM Deployment Model
Productized integration components supporting Full Cloud HCM
1.Position and Employee Position assignment integration
Feature Description: The packaged integration sends Position information from SuccessFactors Employee Central to SAP ERP. Employee Position assignment information is also sent to SAP ERP.
2.Employee Central integration with Thomsons Benefits
Feature Description: Thomsons is a 3rd party benefits provider. The packaged integration sends Employee data from SuccessFactors Employee Central to Thomsons benefits system. The packaged integration also sends benefits information from Thomsons to Employee Central Payroll. The integration will be powered by Dell Boomi enterprise application integration (EAI) technology. The current version of the integration guide is at the help.sap.com/cloud4hr location.
3.Globalized Standard Payroll Templates for SuccessFactors Employee Central
Feature Description: A globalized standard payroll integration template that will enable customers to connect SuccessFactors Employee Central with 3rd party payroll providers will be provided. This template will have features that simplify the integration of Employee Central with global payroll providers. The current version of the standard payroll information integration guide can be found at help.sap.com/cloud4hr .
4.SAP Rapid Deployment Solution for Employee Central to ERP Integration
Feature description: A Rapid Deployment Solution (RDS) is available to enable customers implement the packaged integrations between SuccessFactors Employee Central and SAP ERP. More information on the release will be available at the RDS web site in service market place.
This is an overview of the SuccessFactors variable pay integration with SAP ERP HCM. Please note that a portion of this integration is planned for release in November 2014. A part of this packaged integration requires an SAP EPR HCM support pack that is planned for release in January 2015.
1.1 What is SuccessFactors Variable Pay?
SuccessFactors Variable Pay is a software module in the SuccessFactors HCM suite. It calculates employee bonuses based on quantitative performance of the business and individual employee performance in a given period.
1.2 What is the business need?
The SuccessFactors variable pay module requires employee history information to determine bonus eligibility and calculate variable pay amounts. Once variable pay is calculated in SuccessFactors variable pay module, that information needs to be sent to SAP Payroll on-premise for bonus payouts. Today, these steps are performed manually by compensation experts and payroll administrators. Such a manual process is labor intensive, error prone and puts sensitive compensation data at risk. Customers either adopt such an inefficient, error prone and risky manual process or build a customer integration that costs a significant amount of time, money and expertise to build and maintain. The packaged integration for variable pay aims to provide a best practice integration that is built and maintainted by SAP. The packaged integration aims to significantly reduce the manual labor, errors, time and risk associated with the variable pay process.
1.3 Purpose of this document
This document is meant to enable a conversation about SuccessFactors Variable Pay integration with SAP ERP HCM and Payroll. After reading this document, SAP solution architects and cloud architects should be able to explain the integration to customers and help them make appropriate business process decisions. This document also outlines known assumptions and design boundaries of the packaged integration. This document is not an implementation guide. However, implementation teams will get a conceptual understanding of the packaged integration, the value it brings and the boundaries of the design.
Document authors and subject matter experts
This document was written by Prashanth Padmanabhan, the SAP SuccessFactors Integration solution manager and Ganesh Kudva, the engineering product owner for the integrations discussed in this document. It is written based on the technical specification for variable pay written by Scilly Wang and Ganesh Kudva.
These are the subject matter experts for this integration. The product manager responsible for the integrations discussed in this document is Yamini Polisetty. Yannick Peterschmidt is the solution manager responsible for SuccessFactors Compensation and Variable Pay. Anup Yanamandra is the SuccessFactors Compensation and Variable Pay product manager, and is a subject matter expert.
1.4 Pre-requisites and Assumptions
The packaged integration makes some assumptions about the customer’s landscape and business requirements. This section talks about those assumptions and pre-requisites. This packaged integration is meant for customers who run SuccessFactors Talent Solutions, particularly Variable Pay module, along with SAP ERP HCM and SAP Payroll on-premise. Before implementing the packaged integration for variable pay, customers should have implemented the packaged integration for employee master data.
2. SuccessFactors Variable Pay integration with SAP ERP HCM
SuccessFactors Variable Pay module is normally sold as a bundle along with the SuccessFactors Compensation module. Both Compensation and Variable Pay modules require employee master data as input to enable compensation planning processes and perform all bonus calculation processes. A packaged Integration between SAP HCM and Compensation already is avaiable today. A snapshot of current employee master data is sufficient for compensation process. However, Variable Pay requires more information that just employee master data. Variable Pay module requires historical Employee data to make bonus calculations. This historical employee data integration is part of the variable pay integration.
2.1 How does the integration work?
In the figure below, you will see the integration process from a business process perspective. SuccessFactors variable pay process starts with import of historical employee data from SAP HCM system. Employee history data is needed as inputs for the bonus calculations and planning process. The standard integration processes employee master data and prepares it as required by SuccessFactors Variable Pay before transmission. At the end of the variable pay process, bonus allocations are exported from SuccessFactors back to SAP HCM system for Payroll purposes.
2.2 Data Preparation and Flow from SAP to SuccessFactors
Transfer of data from SAP to SuccessFactors Variable Pay
SuccessFactors Variable Pay expects selected employee records that are eligible for a variable pay planning cycle. The packaged integration provides functions and features on SAP HCM side to select eligible employees so that only the correct records will be loaded into the Variable Pay system. The eligible employees are selected in two steps.
First step is a selection based on employee attributes. For example, customers may want to select all employees who belong to a specific department for export into a specific Variable Pay program. Once the first selection is done, there may be some special rules that can make an employee ineligible. This needs to be handled with special filtering logic. These business rules usually vary from customer to customer. The packaged integration enables customers to modify the business logic to suite their variable pay eligibility requirements.
Example of special rules for employee variable pay eligilbility
1. Customers may want to select salaried employees from select divisions
in the company. In such cases, only the salaried employees from selected divisions are included in the Employee History.
2. Customer wants to exclude employees who are terminated and not active on end date of Variable Pay program. In this case, terminated employees who are not active on end date are not included in the employee history.
3. Customer wants to include terminated but were employed partially during the program period. In this case, employees who were terminated in the period of Pay program are included in the employee history.
4. Customer wants to include terminated employees who are marked for “Re-hire”. In this case, employees who are terminated during the period and marked for Re-hire must be included in the employee history.
5. There is an employee who resigned mid of the year and is re-hired again within the Variable Pay period. The Employee must be included in the history file, but only the 2nd split must appear. The old split is not valid anymore, despite sharing the same employee number.
2.3 Data flow from SuccessFactors Variable Play to SAP ERP HCM
2.4 Prerequisites
The packaged master data integration between SAP ERP HCM and SuccessFactors Talent Suite should be in place.
2.5 Known assumptions and design boundaries
1. The packaged integration for employee master data between SuccessFactors Talent Solutions and HCM should be in place before this integration can be implemented.
2. During recurring update of Employee History data in VarPay staging area, it is possible that some of the data records in Staging area need deletion and replaced with new reocrds (for example, delimition that changes the key of data records). This is rare, but still possible. In such cases, its necessary that VarPay administrators trigger a update of calculated information on all the VarPay forms. It is assumed that VarPay administrators take care of this by setting up a recurring batch job to update the calculated information. This job needs to be setup in SuccessFactors Provisioning.
3. This packaged integration assumes that the customer does not use SAP ERP HCM on-premise Compensation Management. This packaged integration does not and will not rely on functions and features of SAP ERP HCM Compensation Management on-premise.
4. This packaged integration assumes that the effective date for VarPay is determined via user input since the date information does not exist in SFSF VarPay result.
5. For employees with splits or different assignments in employee history, Variable Pay can aggregate the bonus amount for different assignments into one final payout amount and converted the currencies into one functional currency. This packaged integration assumes that such payout aggregation and currency conversion are done on the SuccessFactors side and appeared as Variable Pay result. They are mapped directly and transferred to SAP HCM payroll. However, customer can implement differently in they wish to do so.
6. This packaged integration assumes that Variable Pay result via AdHoc report is always based on completed Variable Pay process.
7. This packaged integration assumes that there will be no changes made to variable pay data on the SAP HCM side after transfer from SuccessFactors. All data change has to be adjusted and generated on the SuccessFactors.
3. Integration Technology
SAP Process Integration (PI) on-premise integration middleware technology is supported. SAP HANA Cloud Integration (HCI) support is planned for release in the first quarter of 2015.
4. Implementation and Enablement Resources
4.1 Administration Guide
The detailed administration guide will be available in Service Market Place at service.sap.com and will be linked from help.sap.com/cloud4hr
4.2 Rapid Knowledge Transfer
A rapid knowledge transfer session will be conducted by product managers to enable implementers. A recording of the session will be made available in service market place.
4.3 Help Portal
Help.sap.com/cloud4hr will be updated with the appropriate help documentation.
4.4 Rapid Deployment Solutions
There are no Rapid Deployment solutions covering these packaged integrations as of November 2014.
6. Summary
SuccessFactors Variable Pay is a software module in the SuccessFactors HCM suite. It calculates employee bonuses based on quantitative performance of the business and individual employee performance in a given period.
The SuccessFactors variable pay module requires employee history information to determine bonus eligibility and calculate variable pay amounts. Once variable pay is calculated in SuccessFactors variable pay module, that information needs to be sent to SAP Payroll on-premise for bonus payouts.
There is a packaged integration to connect SuccessFactors Variable Pay with SAP ERP HCM and Payroll on-premise. As part of the packaged integration SAP ERP HCM sends employee history data to SuccessFactors Variable Pay module. The SuccessFactors Variable Pay module calculates the variable pay and sends the data back to SAP ERP HCM and Payroll on-premise.
SAP NetWeaver PI is the integration technology used by the packaged integration. This packaged integration is meant for customers who use the Talent Hybrid deployment model. The packaged integration for employee master data is a pre-requisite for this integration.
The third packaged integration for integrating SAP HCM and SuccessFactors – Integration Add-on for SAP ERP Human Capital Management and SuccessFactors Business Execution 3.0 – was released on SAP Service Marketplace on October 15th 2014. The packaged integration introduced qualification integration between SuccessFactors HCM suite or SuccessFactors Learning and SAP ERP HCM. A brief overview of all of the packages and the strategy for integration can be found in my blog SAP HCM and SuccessFactors Integration Packages: a brief overview.
The Package
The packaged integration provides one-way integration of either competencies and employee competency assignments from SuccessFactors HCM suite or of curricula and employee curricula assignments from SuccessFactors Learning to SAP ERP HCM so that:
Additionally, there is a report to perform a one-time extract of qualification data from SAP ERP HCM to upload to SuccessFactors HCM suite. This is not available for SuccessFactors Learning. The packaged integration only supports legacy competencies and not the MDF competencies that are part of Job Profile Builder. The figures below demonstrate the process and data flows for each scenario.
Figure 1: Integration between SuccessFactors HCM suite and SAP ERP HCM
Figure 2: Integration between SuccessFactors Learning and SAP ERP HCM
Interestingly, this is the first package that is designed to function with only one middleware platform: SAP HANA Cloud Integration (HCI). Functionality will be released at a later date to enable SAP Process Integration (PI) to be used. The integration process is also different from previous packages as this integration is triggered by the middleware as opposed to being triggered in SAP.
This integration means that in this scenario the system of record for competencies/qualifications is SuccessFactors HCM suite or SuccessFactors Learning and not SAP ERP HCM. SAP ERP HCM should be made read-only for both the qualification catalog and the employee qualification profiles.
The add-on includes a number of new features and functionality:
The screenshot below show report RH_SFI_EXPORT_QUALI.
Important Notes
There are several important notes regarding the operation of the integration:
For SuccessFactors Learning specifically there are some caveats to consider:
Configuration and Setup
This packaged integration requires setup in SAP HANA Cloud Integration and in the SAP Implementation Guide (IMG).
In HCI for SuccessFactors HCM suite there are two processes that must be enabled and, if required, configured. For the one-time extract of qualifications data from SAP ERP HCM the integration process com.sap.SFIHCM03.hcm2bizx.EmployeeQualificationRating should be enabled, although the one-time import can also be made in SuccessFactors Provisioning. The main process for the integration is com.sap.SFIHCM03.bizx2hcm.UserCompetencyRating. For Learning curricula there are two processes: com.sap.SFIHCM03.bizx2hcm.CurriculumCatalogue and com.sap.SFIHCM03.bizx2hcm.UserCurriculumStatus. If PD qualifications are used in SAP ERP HCM then a default Qualification Group must be defined for those Curricula that do not have a parent Curricula Type. This can be seen in the screenshot below.
Configuration in SAP is performed within the IMG under Personnel Management > Integration Add-On for SAP ERP HCM and SuccessFactors BizX >Integration Scenario For Qualification Data. The node can be seen in the screenshot below.
The following customizing activities need to be performed:
Once this configuration has been completed then the add-on is ready to use. The one-time export of qualification data can now be performed and the output uploaded to SuccessFactors either via HCI or Provisioning.
Summary
This enables competency data to be managed in SuccessFactors talent management processes and for that data to be also used in SAP ERP HCM processes. This can be important for customers whom manage competencies in SuccessFactors but rely on that data to make decisions for activities such as workforce planning, staffing, and health & safety. It enables this integration to occur whether SuccessFactors HCM suite competencies or SuccessFactors Learning curricula are used to manage competencies. The integration relies on HCI, so might not be suitable for all customers at this time. It has some caveats that must be considered prior to implementation. Overall, this integration is extremely simple to setup and manage yet reliable and comprehensive.
Within my last blog Roadmap Forms and Dynamic Processing Rules - enhanced data quality and higher system automation with HR renewal 2.0 Feature Pack 1 I announced a down port of the HR renewal 2.0 functionality to EhP6 in November 2014, so that all customers who have implemented HR renewal 1.0 based on EhP6 can also get the great new functionality of e.g. Dynamic Processing Rules.
I am now happy to inform you that this downport has been available since November 13, 2014 with Support Package 31 (SP31) of HR renewal 1.0.
HR Renewal 2.0 FP1 and FP2 offer a wide range of new functionality for HR Professionals users. This functionality has also been downported to HR Renewal 1.0 SP31. The following enhancements are included:
For more information and documentation links, see SAP Note 2071342 (http://service.sap.com/sap/support/notes/2071342).
Note: If you are on a support package (SP) lower than SP 31, and you require corrections to any objects that have been changed in this SP, you must
implement this SP to get the applicable corrections.
Detailed configuration information and screenshots for the new features are available in SAP Service Marketplace at http://service.sap.com/hcm> CoreHR and Payroll> HR_Renewal> Resources> Implementation Information.
Note: You need to be a registered user to view content in SAP Service Marketplace: http://service.sap.com/login.
We will also have two Expert sessions for partners in January 2015
To register please go to SAP Partner Edge https://partneredge.sap.com, and search for HR renewal.
HR Renewal 2.0 FP1 and FP2 offer new functionality and enhancements for ESS and MSS users too. This functionality has also been downported to HR Renewal 1.0 SP31. Here the following enhancements are included:
For more information and documentation links on ESS/MSS downport, see SAP Note 2063410 (http://service.sap.com/sap/support/notes/2063410).
You might also find these three blogs of my colleague Gertrud Beisel regarding the delivery of HR renewal 2.0 itself useful:
HR Renewal 2.0 Initial Shipment Released for General Availability
Feature Pack 2 Released for HR Renewal 2.0
Hope to welcome you in our sessions 
And... as always... Looking forward to your feedback. If you have any questions feel free to contact me.
Sylvia Strangfeld
I recently had a client come to me for help regarding an issue with FSA dates on Infotype 170 when they were doing their benefits open enrollment testing. The issue was that they wanted their FSA plans to be based upon the calendar year even though their other plans are not based upon the calendar year.
Here is a little bit of background on my client
Currently, when they were testing, the FSA entries were being created per the configuration on V_5UB3_1 for the administrative parameters (Screenshot below). I tested this in both ESS as well as HRBEN0001 and found that the issue was occurring in both places which lead me to believe that it was being pulled from configuration although I was not 100% sure.
When I logged into ESS, I saw the following under the FSA portion of the guided activity floor plan:
When I saved the record and looked at the Infotype 170 record created behind the scenes via PA20 I saw the following for the entry:
My first question to the client was whether this was working previously and it turned out that it was NOT working previously. They had the same issue last year and they MANUALLY fixed it. This meant their benefits team going into PA30 and updating over 1,000 records manually! Ouch!!
In the past clients where I had worked on ESS Benefits Open enrollment I had not really paid too much attention to this because no one said anything, but it was quite the big deal here. So I looked through the IMG, did a little bit of research (Google) and did not have much luck in my initial research. Ultimately, I searched OSS and found SAP Note 989966 (attached here). This was an older note (2007) which has the following description
"Currently, in the standard system, when FSA plan enrollment occurs either via Employee Self-Service (ESS) or from the Enrollment Workbench, the validity of the FSA plan is automatically derived from the administrative parameters of the benefit area. However, in accordance with the law, employees may only be enrolled in an FSA plan during the current year".
So this confirmed my suspicion that the dates were coming from the administrative parameters table. So in this note which was released back in 2007 SAP gave us an option in order to adjust the dates for these plans only and not all of the other ones (There are notes for each of the different types of plans where you can do the same thing as I am doing here). It requires using a BADI in order to adjust the dates passed to the screens. I went to transaction SE18 and created the BADI Implementation for PBEN0038 per the instructions on the note.
I wrote some very simple code to pass the date logic (I do not do much programming although I debug code quite often) and activated the BADI. The BADI is called from within standard FM HR_BEN_GET_SPENDA_OFFER in case anyone is interested. Here is a screenshot of my code (I know there are probably 100 other ways to write this with the same results, including some standard SAP function modules).
Once I activated the BADI and I tested, I saw that the dates looked good in both ESS & HRBEN0001! Here is what it looked like on ESS
I saved the records via ESS and then went to PA20 and the Infotype also looked correct --> using 01/01/2015 & 12/31/2015 dates as expected!
I just wanted to share this experience in case anyone else has to deal with anything similar. Overall, my research and implementation of this simple solution saved the client a lot of headache and manual labor (Although if I did not figure it out then I would have recommended a Program/BDC/LSMW instead of having their benefits team manually doing this!!
Anyone in HCM P&F working with FPM forms will eventually stumble upon the requirement to provide a table of data that the user can view existing records and add new ones directly too. And almost equally as predictable, they will also be asked to make some fields read-only while allowing others to be directly editable. However, this is not as easy as it first sounds....but hopefully, this blog will help ease the time/sweat/cursing/frustration involved if you had to figure this out on your own.(haha)
For someone new to this, they are likely to think "oh, this is going to be easy. I will just set the UI attributes for the form field in configuration or in my own generic service. I will be done with this in a few minutes and can take a long lunch for the day!" Not so fast! You might want to hold up on those lunch plans because here lies the big "catch".
For just single form fields, setting the UI properties (open for input, invisible, or read-only) directly in HCM P&F Design Time configuration or using the newer access to "ui_attributes" in our back-end services works wonderfully well. Our standard feeder class, CL_HRASR00_FPM_FEEDER, can read, understand this and make the settings perfectly for us. With multi-line fields (ie. tables), however, this is where it has a bit of a problem.
Suppose we have a table of wage type entries. We want to list existing wage types but only allow the user to edit the end date and amount (wage type and begin date should be read-only). We also want the user to be able to add a new "row" and be able to edit all fields. If we simply set our form field attributes the "usual" way, this is what we will get.
What we see it that it correctly made our "existing" records first two columns as "read only", but it incorrectly applied this to our "new" row too, so the user can not even enter a new record correctly. What is worse is that if we completely handle adding the new row ourselves (custom back-end operation) and even implicitly set the UI attributes for all those "new" fields with the same index (meaning same row) to "open for input" (ie. "I" setting) , it STILL will ignore all of it and make our fields as "read only" in the first two columns. It does this because the feeder class has code that just looks at the FIRST occurrence of the field and whatever that field's UI setting is becomes the setting for all other entries in that column (ie. it sets the "field usage"). In our case, it saw that the first use of "Wage Type" was read-only, so then, all other cells in that column get set to "read-only" (again, regardless if we actually set them independently by field index in ui_attributes in our custom service....I think this is a BUG in SAP code, but will leave it to them to decide/fix.)
So I set off to fix this on my own...and because I happened to be working on something very similar for a client at the time.(haha) First and foremost, I want to mention that it was Raja Sekhar Kuncham's blog FPM Forms Scripting (Continued)... that was the spark/motivation for this blog. He mentioned the usage of ET_FIELD_DESCRIPTION if setting multiple UI properties if only we could have access to these. I took it as a challenge. I tried many ways to get a handle/reference to the FPM feeder class of my UIBB list element, the good ol' standard CL_HRASR00_FPM_FEEDER class, thinking that if I could just do that, it would be easy to change/set/inspect the ET_FIELD_DESCRIPTION structure. It was easy enough to get reference to the FPM framework instance itself ("FPM factory, get_instance"), so I thinking the feeder class surely had a simple "get instance" method too, right? No luck.
After poking around on SCN in FPM related threads and scouring Google searches, it seemed I had two options. One, I could do some things in the "GET_DATA" method to set UI properties, but it sounded like it would get too specific to one particular process and really require a completely custom feeder class. I did not want to go that route just yet. Second, I found several mentions of using the method "GET_DEFINITION" which...and I know how strange this will sound....is where you define how the form fields appear and what they can do (ie. search helps) up front (whereas in GET_DATA, you can override/change this later in a more dynamic way).
Again, because for single form field values the UI attribute settings already work correctly, I did not have to look at the FPM GUIBB "form" related "GET_DEFINITION" method. I focused only on the FPM GUIBB "List" code as this is what/how we display tables of information on our FPM forms. After debugging through this method several times, this did seem like a good spot. I decided I would do an "enhancement" in this class method to handle my own UI attribute settings. If you look at it, you will find it has two enhancement locations...one at the top and one at the bottom of the method.
I wanted my code to be executed after everything else had been set and done. Furthermore, instead of having code in there directly for all my processes, form fields, etc. that I would have to update/change as I used this more and more, I instead created a custom class that I pass the "et_field_description" structure to in order to make changes and pass back. In that way, I simply only have to change my custom class code as needed. Scroll to the bottom and create your own enhancement (I will leave it to you to figure “how” to do this if you are not already familiar with it.)
One thing you will notice in et_field_description is that many of the UI related fields (viability, read only, mandatory, tooltip, etc) will have a corresponding "reference" field. What this means is that you "could" for instance set a field as "read only" by marking the "read only" field as "X". Or you could say, "I am not sure how this field will be set, so I want another field to decide this at run time" and THAT is what the "reference" field is for. You are, in effect, naming another field that will decide this for you dynamically. Take note, though, you would never set both....that is, I would not have a field set as "read only" but also having a "read only reference field" set too. The second, and likely foremost, important piece of this is that whatever field we use as a "reference field" must have it's setting for "technical field" in et_field_description as "X". This tells us that THIS field is in fact a "reference field" and should NOT be considered for having UI settings of it's own. The nice thing here too is that we can use this same "reference field" for any number of other fields. For example, suppose we had 4 fields on our form and our reference field too.
WAGE_TYPE WAGE_AMOUNT WAGE_BEGIN_DATE WAGE_END_DATE WAGE_REFERENCE_FIELD
And in ET_FIELD_DESCRIPTION, we had something like this:
| Field Name | Technical Field | Read Only Reference |
|---|---|---|
| WAGE_AMOUNT | WAGE_REFERENCE_FIELD | |
| WAGE_BEGIN_DATE | WAGE_REFERENCE_FIELD | |
| WAGE_END_DATE | WAGE_REFERENCE_FIELD | |
| WAGE_REFERENCE_FIELD | X | |
| WAGE_TYPE | WAGE_REFERENCE_FIELD |
Then at run time, if we set the WAGE_REFERENCE_FIELD's value to "X", it would then cause all the related fields to appear as "read only" (greyed out). Pretty nice to control several fields with one field setting! For tables, we could decide this "per index" even so that it affect a row but not all rows. (remember in HCM P&F "tables" that all fields in each column with the same index represent a table row).
Now, back to our own class, we can handle setting/controlling UI elements much easier. I have methods for each type of UIBB “get definition” possible (form and list) as their “et_field_description” structure is slightly different. Of course, you can probably come up with all kinds of more clever ways to do this, but I will just make the changes directly. You can see here how I set up the "technical field" and "reference field" relations. I am telling it that "for the wage type and begin date fields, I want their read-only setting to be determined by another field called wagetype_ref_readonly at run time."
The next big part of this is that we also make settings in our custom back-end generic service. Over in the service in our “initialize” method as we fill our wage type values, we just make sure we set these values for our “reference” field and make sure it’s index matches the correct row (ie. make it match our “wagetype” row). In our case, if we have an existing wage type record, we want to make the field “read only”, so the value then for our “reference” field is “X”.
Similarly, in our “do operations” method, I am catching if the user event for “add row” is triggered using the same way I mention in another blog. I will also mention that I made a custom user event and do not use the standard “USER_EVENT_ADD_ROW “ event so that I can “catch” it in my method (the standard event would not trigger my “do operations”). You can see here that I clear the "reference field" value so that means our field will be open for input.
After all of this, if I run my process again and form is displayed, this is what we now see:
You can see that for the “existing” entries, the first two cells of each row “read-only”. However, all “new” rows are now correctly completely open for input.
Now, if we take this a little further, using the fields now exposed to us in our class, using many of the various “reference fields” in et_field_description and more, we can have all kinds of fun controlling just about everything on our table as you see here:
We have a custom column header now, a custom tooltip (we can make the tooltips different for each row or one generic message for all rows…think about that! Wooo whoo!!!! haha), and again, we control the cells on the first two columns being read-only or not. Now, you should understand (and have the power to control!) just about any and every thing about your FPM list/table UI display.
You can look through the structure FPMGB_S_LISTFIELD_DESCR for more. I will leave a few of them up to you to play with….hey, I can’t be having all the fun over here! (haha) As always, I hope this has helped, and I will keep churning them out if you keep reading them. Till next time...
Hello payroll professionals,
As you read in earlier posts the new SAP Payroll control center add-on provides a fundamentally new approach to ensure payroll accuracy in which potential issues are pointed out near real-time by the application rather than payroll administrators digging through information and trying to find issues and resolutions themselves. With this functionality payroll administrators only need to focus on issue solving and this saves payroll departments a lot of valuable time.
SAP now released a rapid-deployment solution with pre-configured validation rules which focus on Master Data monitoring, for the pre-payroll process, and Reconciliation Rules for post-payroll processing. With this rapid-deployment solution SAP provides best practice examples and documentation which serve as a foundation for the implementation of the SAP Payroll control center add-on. This helps organizations to increase the efficiency of the process, reduces errors, and improves the accuracy of the payroll.
Validating master data before the payroll runs helps customers to optimize their data quality and it provides certainty around error free payroll runs. Personally I have talked to customers that have implemented the SAP Payroll control center add-on which are really helped by the capabilities the solutions delivers to validate their master data.
The examples provided in the rapid-deployment solution are used as examples and are easily copy pasted to create new validations. Customers told me they can implement new validations within 30 minutes based on the examples provided.
The following predefined master data validation rules are part of the rapid-deployment solution:
One of the benefits for the master data validation capability in the SAP Payroll control center add-on is decentralization. The ability to provide stakeholders in the business almost continuous access to potential issues they need to solve before the payroll can run is vital for a quick processing time. The authorization framework only points out the relevant potential issues to the end-user. They now instantly see which corrections are necessary to run a successful payroll.
In addition to this, the payroll manager has a helicopter view dashboard which points out the errors that still need to be processed and or fixed before they can run the payroll.
The rapid-deployment solution also contains predefined validation rules which run after the payroll run is executed. This provides insight into the payroll results and ensures that payment to employees will be correct.
The following predefined reconciliation validation rules are part of the rapid-deployment solution.
These validation rules are executed on the payroll system after running the payroll. The rules run on data in the new declustered tables. More information on declustered tables can be found here: http://scn.sap.com/community/erp/hcm/blog/2013/12/19/how-do-sap-hcm-customers-benefit-from-declustering-payroll-and-time-management-on-sap-hana
An additional benefit of declustering is the ability to perform ad-hoc reporting on this data. This post provides an overview on how to accomplish that. http://scn.sap.com/community/erp/hcm/blog/2014/07/04/new-analytic-capability-of-payroll-results-via-declusteringSpeed improvements (even on traditional data bases) have been really massive. This helps to get rid of background processes for payroll result report assemblance and to provide instant insight into your payroll data.
More information around the rapid-deployment solution can be found here https://service.sap.com/public/rds-pcc.You can download the package and a step-by-step guide on how to implement the functionality.
Please also double check the following notes:
A fundamental change in the way SAP delivers rapid-deployment solutions is that the content like the step-by-step guide that help you to implement are now available to customers free of charge.
The biggest benefit of the SAP Payroll control center add-on is the flexibility the framework offers to create meaningful validations. Until now SAP could serve all customer requests for payroll validations so we have yet to experience the limits of the framework. However, the flexibility in the framework is a result of coded validation rules. Think of them as individual BAdIs per validation rule. Obviously this requires strong skills to implement the SAP Payroll control center add-on.
One of the lessons learned from implementing the functionality is that this rapid-deployment solutions really helps to drive a best practice for implementation. The predefined validations helped experienced consultants and developers to build a quick and detailed understanding of how to develop content. In addition, one of the benefits is that the predefined content accelerated the understanding of working with data in declustered tables. This avoids pitfalls for poorly performing validation rules. So if you want your validations to run in real-time you need to understand how to develop the validations.
Rapid-deployment solutions are also provided by SAP to official SAP Partners. That means that partners can also leverage the 24 predefined rules to accelerate implementations, get a best practice on how to code the rules and use it as starting point to build out own content.
Therefore I really recommend everyone who implements the SAP Payroll control center add-on to leverage this best practice!!
Looking forward to your implementation experiences!
And if you need more information you can always reach out to me or to the package owner for this RDS: alexsandra.zanetti@sap.com
Best regards,
Frans Smolders
I am delighted to announce details of the 2nd edition of the best-selling SAP PRESS title SuccessFactors with SAP ERP HCM that will be released on December 3rd 2014. Authored by Amy Grubb and myself – along with contributions from Atif Siddiqui– the title is not just an updated edition, but also includes brand new content. SAP Jam also continues to feature in the book.
Some background
Just over a year ago saw the release of the first edition of the SuccessFactors book. It was a long awaited release that became an SAP PRESS best seller and helped educate thousands of individuals about the SuccessFactors suite and what it has to offer.
But getting there was no easy task. The book came together from a team of 6, most of whom spent every waking hour writing. And also while maintaining their career, social, and personal lives! In addition, we were delighted to get plenty of support from SAP and SuccessFactors and I enjoyed some personal sessions with product management experts to show me new and upcoming functionality. We were also blessed to have Dmitri Krakovsky, SVP of Product Management at SAP write a wonderful foreword for the book. He has been a real proponent of the book and both its quality and accuracy.
For the second edition the team became 3 and despite being "just" an "update", the level of effort for the authors and contributor was much more than expected. 5 quarterly releases, terminology changes, evolving products, changes in strategy, and new integration content made sure that we were very busy with content changes, taking new screenshots, and re-writing chapters. Just to punish ourselves further, we decided to add some new chapters! But thanks to the great work of Amy Grubb and Atif Siddiqui we achieved an even better title with more content and featuring the latest innovations and integration content from SAP and SuccessFactors.
Now, let's take a brief look at what's new.
Updated and Revised Chapters
There have been 5 releases of SuccessFactors since the first edition – 1308, 1311, 1402, 1405, and 1408 – and so each chapter of the book has been updated to reflect new features, terminology, and UI changes. In addition, SAP have released numerous packaged integrations and updated their roadmap and strategy. Changes to the suite terminology, UI, and logos have been updated throughout.
Both the Integration and Employee Central chapters have been extensively re-written to provide the latest and greatest information and functionality, as well as further ensure that the chapters provide maximum value to the reader. Both chapters also include around 30 new pages of content each, which we’ll cover below.
New Content
Updating the content was not enough for us, so we decided to add some new content! This includes:
Platform and Extensibility
For the first time, features of the SuccessFactors Platform have been documented to enable readers to learn about those features not covered under each of the main applications. This includes Role-Based Permissions, Company Info, Presentations, Job Profile Builder, and more. It also now contains the previous technical architecture, security, Metadata Framework (MDF), and Employee Profile content, fully updated.
Integration
As well as a full update and inclusion of the latest Talent Hybrid packaged integrations, the integration chapter has been extended to include details of the APIs available in SuccessFactors, other talent integration content (such as Recruiting integration to 3rd party vendors), and Employee Central integration for both the Full Cloud HCM and Side-by-Side deployment models.
Employee Central
Since Employee Central is evolving at such a fast-pace, it was necessary to re-write and extend the chapter to include some of the new features in detail. The new features covered include:
In addition, detailed explanation of concepts such as employee status, effective-dated data model, and Event Derivation has been included.
Administering SuccessFactors
For the first time, some of the most practical ongoing administrative activities have been documented. Common tasks like managing the password policy, Picklists, data retention and workflow requests can now be discovered in detail.
Summary
The book is more than just an update of the first edition. In addition to including features from the previous 5 releases, it also includes brand-new content never before made available to customers or partners. On top of that, significant content has been re-written to add additional clarity, relevance, and detail to existing topics. Read more on the SAP PRESS website and order your copy!
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)
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".
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).
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.
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 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 make sure 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 (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!!
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.
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.
In early 2013 SAP launched SuccessFactors Onboarding, the latest addition to the SuccessFactors talent suite. With a fresh, comprehensive approach focusing on the needs of the new hires and hiring managers, SuccessFactors takes onboarding beyond orientation and compliance and elevates it to be a strategic part of talent management.
And the news is just in: SuccessFactors leads the pack in overall functionality according to Bersin’s Onboarding Software Solutions 2014: On-Ramp for Employee Success.
SuccessFactors’ leadership position is based on primary research and an unwavering focus the needs of people and their managers.
The hierarchy of new hire needs is a result of primary research conducted in the design phase of the SuccessFactors Onboarding solution.
Similar to Maslow’s needs pyramid at the lowest level are the most basic needs – where paperwork is taken care of, equipment needs to be ordered and data needs to be entered in HR systems. Compliance and administration is important, but tactical. Employers can make significant improvements by automating this part and making it available before the start date. Investments here result in a more efficient process.
But, every step up this pyramid gets more strategic and has a bigger impact on new hire engagement, attrition and time to productivity. The second level is dealing with the new hire’s first day anxieties and the need for information. Proactively providing new hires information about the company, its’ culture and what to expect on their first day helps them to get through this, makes them feel welcome and puts them at ease.
Once the basic needs are met, socialization is important. People want to be connected. They want to feel like they are part of the team and the organization – not an outsider. Formal and informal networks and access to content help new hires get oriented, feel comfortable and start getting their job done.
Finally, the ultimate value creation is achieved when onboarding enables development and contribution. While the employer has a big stake in ramping new hires up quickly, the new hires themselves also want to feel like they are contributing as quickly as possible. To do that they need to know what is expected of them, have individualized development activities lined up and have first short-term objectives.
If employers can take care of all of these new hire needs, then they are laying the foundation for a successful employee, and they can really start to have long term, strategic impact.
SuccessFactors Onboarding addresses the needs of the new hire, the hiring manager and the other constituents of the onboarding process in three unique ways:
SuccessFactors Onboarding efficiently guides all constituents through the onboarding process. Best practices help standardizing activities that lead to new hire success. Hiring managers are notified when they need to complete an activity such as selecting a buddy, inviting the new hire for lunch or setting up a meeting to talk about expectations and first milestones. They are guided through each step of the onboarding process. This is critical, as many hiring managers want to provide the support, information and resources new employees need, but often require guidance to do so accurately and effectively.
At the same time, new hires have access to everything that can ease their entry into their new jobs. This includes information and training tailored to their roles within the organization or selected by the hiring manager. They also have visibility into the necessary paperwork. As new hires complete forms, HR and other corporate users of the solution can turn to detailed process dashboards to monitor their progress and – when necessary – move things along. The SuccessFactors new hire process is device agnostic, enabling access from mobile devices as well as a desktop. This is key, given an increasingly mobile workforce.
SuccessFactors Onboarding links new employees with the onboarding team, their manager, coworkers and others, even before their start date, with tools such as a photo-rich interface, organizational chart and contact data. Hiring managers can use these features to initiate introductions between team members, peers and others in the organization, giving new hires a sense of community and culture prior to day one. Access to the knowledge of others in the organization helps new hires more quickly understand and acclimate to its operation and culture and more rapidly achieve their first milestones.
SuccessFactors Onboarding is built on a robust talent management platform. It links new employees with relevant learning, development and social initiatives and starts the process of managing their progress toward first goals. For managers, the solution suggests learning topics for employees to explore, and helps them set initial objectives and milestones. At the same time, new employees gain easy access to assigned learning activities and additional development opportunities based on their jobs and individual needs.
SuccessFactors Onboarding’s ability to guide, connect and develop everyone involved in the onboarding process allows organizations to meet the hierarchy of new hire needs and addresses both the strategic and tactical aspects of the onboarding processes. Because of this, SuccessFactors Onboarding enhances employees’ engagement, development, satisfaction and productivity while ensuring a simplified, compliant, and measurable onboarding process for the organization.
On December 11th, in SAP's Newtown Square offices, participants at the ASUG Philadelphia Chapter meeting will have a unique opportunity for a sneak peak at SAP's latest innovation for workforce management: "Side by Side - Integration of SuccessFactors, an SAP Company Cloud Suite with SAP ERP HCM On Premise." That's a mouthful. But the details behind that mouthful are worth understanding.
There are a limited number of opportunities to experience the solution hands-on in a usability session; however, those who are unable to get a seat in a usability slot can learn about the solution in an overview presentation.
There are also opportunities to network with other SAP / SuccessFactors customers and to attend other education sessions. The full chapter meeting sessions are described on the ASUG Philadelphia Chapter Meeting event page.
ASUG Members should register for the chapter meeting on the event page at https://www.asug.com/events/detail/Pennsylvania-Philadelphia-Chapter-Meeting-Dec-11-2014. Anyone interested in one of the limited usability sessions should email Joyce Leung [Joyce.Leung@sap.com].
If you do attend, I would love to hear your thoughts after seeing these latest innovations. I will be there myself checking it out!
The first service package for the third packaged integration for integrating SAP HCM and SuccessFactors – Integration Add-on for SAP ERP Human Capital Management and SuccessFactors Business Execution 3.0 Service Package 1.0 – was released on SAP Service Marketplace on October 16th 2014. The packaged integration introduced variable pay integration between SuccessFactors Variable Pay and SAP ERP HCM. A brief overview of all of the packages and the strategy for integration can be found in my blog SAP HCM and SuccessFactors Integration Packages: a brief overview.
The Package
The packaged integration enables employee history and changes to employee history to be transferred from SAP ERP HCM to SuccessFactors Variable Pay. The second part of the process – transferring variable pay results back to SAP ERP HCM so they can be processed in Payroll – is due in a later Service Package. Like most process-based packaged integrations, this packaged integration only uses middleware. Currently only SAP Process Integration (PI) is supported, but support for SAP HANA Cloud Integration (HCI) is also planned. More specifically, PI version 7.11 SP12 or above is required. The figures below demonstrate the process and data flow for this scenario.
Once the remaining integration is provided – which is planned for add-on 3.0 SP2 – then the full process flow will look like this:
The add-on includes a number of new features and functionality:
The screenshot below shows the selection screen for report RH_SFI_SYNCH_VAR_PAY_DATA.
The screenshot below shows the selection screen for report RH_SFI_SYNCH_VAR_PAY_METADATA.
Important Notes
There are several important notes regarding the operation of the integration:
Configuration and Setup
Configuration in SAP is performed within the IMG under Personnel Management > Integration Add-On for SAP ERP HCM and SuccessFactors BizX >Integration Scenario For Variable Pay Data. The node can be seen in the screenshot below.
The following customizing activities need to be performed:
*Note that this activity is not transportable
Once this configuration has been completed then the add-on is ready to use. To use the add-on, simply run and/or schedule report RH_SFI_SYNCH_VAR_PAY_DATA (also accessible via transaction HRSFI_VARPAY_DATA).
Summary
The latest support package adds the first half of process integration to the packaged integrations for SAP ERP HCM customers who want to perform Variable Pay planning processes in SuccessFactors. Although it does not yet transfer the resultant process data back to SAP ERP HCM for payroll processing, this is planned for a later service package. The integration has some technical differences from previous integrations and these should be thoroughly reviewed and compared to the existing landscape, if any.
The result: innovation that promises to meld SAP HR on-premise and SAP SuccessFactors / Employee Central cloud solutions.