Long time back I wrote a blog introducing “Roadmap forms” through the blog – HR Renewal FP4 – What’s new in HCM Process and Forms . This is the first time SAP has introduced such functionality which would definitely impress people on the very first look. But after getting into details I have realized few interesting facts that I would like to share in this blog. Along with these facts, I tried putting down my wishes(as usual) too 🙂

Fact#1 – Generic Services are not supported

Generic Services is one of the most important and powerful features in HCM Processes and Forms. We generally use these generic services to declare generic service based fields, default data based on custom logic, perform validations, etc. There is no concept like “Generic Services” in Roadmap forms. These forms are so simple that we just add a bunch of Configuration ID’s i.e. infotypes (whose screens are configured in a customizing table) to the configuration and maintain the operation per each infotype (Create/Copy/Modify/Delimit). We don’t even have to manage creation of FPM Forms(which act as steps or individual infotype screens) from HRASR_DT transaction for these Roadmap forms(which also means that the traditional FPM forms can’t be reused as steps in these Roadmap forms due to difference in feeder classes). Neither can we manage any fields from this transaction HRASR_DT for these roadmap forms (which leaves us not to have any Form Level fields [fields that doesn’t belong to any infotype] at least).

P11.png

Wish#1

Centralizing infotype maintenance using Configuration ID’s in a customizing table (VC_T77PAOMDCF) and that are used in “Roadmap forms” and “Maintain Master Data Application” is definitely a smart move. But I wish SAP provides one more column (displaying the FPM Form name that is attached to the Configuration ID) in the above roadmap table to maintain or at least display the related infotype screen/form. Let’s say we add a new Configuration ID – IT0105, then based on the configured FPM form in the view – VC_T77PAOMDCF, it should be defaulted in this column. On clicking this FPM Form, it should launch the FPM form (allowing us to edit/display the layout of the form).


Fact#2 – Only one action is supported per form

Though these forms allow us to maintain the default “Action Type” and “Action Reason”, there is absolutely no way to maintain multiple “Action Types” in one single form. Let’s say in my organization there are two transfer actions defined for ‘Transfer and employee’ i.e. “Transfer with promotion” and “Transfer without promotion”, with this restriction in place, I would have to create two different forms with the same configuration(except these different action reasons).

P22.png

Wish#2

I wish to have the “Action Type” field accommodate multiple “Action Types” configured instead of only one action for each form in HRASR_DT transaction. The “Action Reason” should be dynamic based on the “Action Type” selected. On opening the roadmap form, user should have the option to display the list of “Action Types” as a dropdown (forcing user to select only one action type) that are configured in HRASR_DT transaction. The advantage that we would get is a solution to map multiple actions into a simple single form (Though it still runs only one selected action in the backend on click of “Save”). This feature would really be helpful in reducing the number of forms for similar actions types.


Fact#3 – Scenario Steps are not Scenario Steps

In HCM Process and Forms, Scenario steps allows us to define various flavors of the form (with different set of fields) based on processor of the form. I think “Scenario Steps” is one more important feature that makes HCM Processes and Forms very powerful when integrated with workflows. Though we can create various “Scenario Steps” for ‘Roadmap Forms’, we can’t do much like assigning any fields or defining field properties like in traditional HCM Processes and Forms.

P33.png

Wish#3

I wish this feature (Scenario Step) mimics the Original functionality. I mean it would nice if we can assign the “Configuration IDs” to the scenario step. This would make the Workflow integration more powerful by exposing only few roadmap steps to the initiator and displaying all roadmap steps to the final approver.


Fact#4 – Roadmap steps don’t talk between each other

Data in the first step – “General Process Data” doesn’t get passed to the next/subsequent steps like if I change the Personnel Area and/or Personnel Sub Area and/or Employee Group and/or Employee Sub Group in the General Process Data I see that these changes doesn’t get passed to the very next step i.e. Organizational Assignment. I see that these steps works in “Async” except for few core fields like Start Date/Effective Date, End Date, Position, etc which are dictated by the framework.

P44.png

P55.png

Wish#4

Yes, my wish here is a smart way(as an additional step in HRASR_DT like the below step – ‘Transfer of Field Values’) to do the mapping between the fields i.e. I would expect to map the infotype fields i.e. mapping “General Process Data” to fields in “Organizational Assignment” or between any infotype fields.

P66.png

Fact#5 – Many traditional features were missing

Not sure if there is a reason, but most of the traditional features of HCM Processes and Forms are missing in Roadmap forms – “Rules”, “User Events”(not sure), “Message Mapping”, “Print Form”, “Attachments” and “Generic Services”.

P77.png

Wish#5 –

After working in traditional HCM Processes and forms for years, I definitely wish SAP to provide relevant generic features like “Rules”, “User Events”(not sure), “Message Mapping”, “Print Form”, “Attachments” and “Generic Services”.

Hope by now, you must have clearly realized what has been delivered in Roadmap forms under HR Renewal 1.0 Feature Pack 4.

Let me know your thoughts on my wonderful wishes 🙂

To report this post you need to login first.

9 Comments

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

  1. Christopher Solomon

    GREAT write up (and you saved me one! haha) I JUST had this discussion this past week or so via emails with another HCM P&F blogger/writer. We discussed just how limited the “roadmap” form option really is (almost not an option since with just minimal work/config, you can accomplish much more functionality). I think this was just “low hanging fruit” for SAP to offer up and say “hey, here is something new!” as well as pushing more PA30/40-ness to the web. It also is VERY easy for functional-only folks to set up quickly with NO development needed. BUT, as you mentioned very well, in doing so, you are really limiting yourself. Maybe this was just a first pass and more functionality will be ported over *grin*.

    (0) 
  2. Raja Sekhar Kuncham Post author

    Also, want to add one more wish – Add a individual “Check” button on beside “Next” and “Skip” buttons. Right now, we only have “Check All” button that is going to throw errors in all screens(if something is wrong). This behavior is sometimes annoying where user doesn’t even enter the data in further steps, but starts seeing error messages 🙁 ! So having individual “Check” buttons is the best option.

    Thanks

    Raja Sekhar

    (0) 
  3. Saurabh Gupta

    Hi Raja,

    I am using CL_HRASR00_PROCESS_EXECUTE class ‘s Initialize method to execute a road map form from my report. But I am not getting values but we can get it for simple FPM form.

    Please suggest.

    Thanks,

    Saurabh

    (0) 
  4. Nguyen Hugo

    Hi Raja, is it possible via BADI to default an value for Start date in Roadmap form.  If yes can you tell be what BADI ? I have look into the BADI HRPADINFTYBL and it does not look like it stop. Any want can help ? Thanks Hugo

    (0) 

Leave a Reply