Print Support For FPM in HCM Processes and Forms

Last fall when I was writing the chapter on the new FPM forms version for the book I co-authored with Justin Morgalis (@SAP_jmorgalis) on HCM Processes and Forms*, I was very happy with what I saw. SAP had finally delivered a smooth, clean, intuitive front-end to pair with the powerful back-end HCMPF toolset.

Based on what I saw then, I was already convinced that most customers evaluating the two approaches should go with the new FPM Forms since doing so meant eliminating the chief complaints I had heard from customers regarding the Adobe-fronted HCM Processes and Forms: additional per-form licensing costs for Adobe Interactive and the headaches that come with supporting the interactivity through Adobe Reader for end-users throughout the company.

However, there were three gaps that remained at that point between Adobe capabilities and FPM capabilities. This kept the competition from being a complete rout:

1. The lack of support for dynamic changes to the UI based on user input. For example, making the “Region” field visible based on the country being selected.
2. No support for formatted front-end printing for end-users
3. No support for digital personnel file storage for finalized processes

One Gap Eliminated…

Dynamic  fields was the first of the 3 issues to be resolved resolved.  In the informative blog  http://scn.sap.com/community/erp/hcm/blog/2013/02/12/fpm-forms-scripting, Raja Sekhar Kuncham highlighted this new functionality described how you can make FPM Forms dynamic using generic services. One down, two to go.

…Which Brings Us To Printing

This left two gaps: support for front-end printing and support for digital personnel files (DPF) storage.  As of HCM_ASR_CI_5, these were addressed as well with one solution.  A new section was added to the design-time repository where companies can add a print version of their form as the picture below illustrates

This read-only form is then accessible when users are accessing on the front end.  Below is a screenshot of how you get to the front-end printing:

For DPF support, the anchoring is the same as takes place as for Adobe.  (Note: I didn’t have time to fully test this functionality.)

The Implication of the Printing Approach
To reiterate, SAP has plugged the major gaps with FPM forms, so we’re happy.  For the glass-half-empty crowd though, there’s something here for you as well.  The downside of the way that SAP has built the print support is that if you require print support you’ll still need to develop an Adobe Form using Adobe Designer in addition to configuring the FPM form.  Therefore for those customers requiring DPF or printing it’s no longer a true statement that Adobe Designer is no longer required.  However, the design effort for this form should be less than an interactive form since you will now only need to create a static version.  Also, because we are just talking about a static form,  we still avoid the per-license costs and support issues we would have have with the Interactive Forms.

Bottom Line

This is another example of the HR Renewal team listening to customer feedback and rapidly incorporating into the product. I look forward to seeing which other wish list items make it into future releases (Dynamic actions, combination org/pa forms, etc.).

* In case you missed it, yes, that was a shameless plug for our HCM Processes and Forms book: http://www.sap-press.com/products/SAP-ERP-HCM-Processes-and-Forms.html