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 :smile:
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).
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).
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.
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.
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.
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”.
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 :smile:
- SAP Managed Tags:
11 Comments
