Skip to Content
Author's profile photo Former Member

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, 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:

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Suresh Datti
      Suresh Datti

      I must say the Print Option is half-baked.You still have to adjust the Form layout in SFP. And it isn't an exact replica of what you see in the browser ( I'm referring to all the static text on the Form ). It would have been nice if the PDF was generated on the fly from the front end. May be I am asking a little too much. Despite its limitations I like the WDA UI option.

      Author's profile photo Former Member
      Former Member
      Blog Post Author


      I agree that the solution you suggest would be ideal.  I had actually written the part about auto-generation in the blog originally but deleted it in the interest of brevity.  Still, while the solution is "half-baked" (your words)-- it IS a solution--which at least allows a credible path forward for customers with printing/DPF requirements.  Plugging gaps in a span of 3 months is a lot better than waiting years like we're used to.

      Thanks for the comments!

      Author's profile photo Suresh Datti
      Suresh Datti

      I am part of the glass-half-empty crowd (your words ).. that aside, while you can forward navigate to SFP from HRASR_DT, you cannot come back.. it dumps on  you.. at least on my system.. translates to half-baked. I agree it is much better than having no Print Option at all.. hopefully it will get fixed.

      Author's profile photo Luke Marson
      Luke Marson

      Hi Brandon,

      Great blog and nice to see some of the new enhancements. Also, a shameless plug is acceptable - as long as the book is good for customers!

      Best regards,


      Author's profile photo Naveena Duraisamy
      Naveena Duraisamy

      Hi Brandon,

      Very useful blog, Thanks for that.

      I have performed all the config and I could also see the 'Form Untilies' button on the form. But when I click on 'Generate pdf' nothing happens. Am I missing something.

      Please help.



      Author's profile photo Marco Furlanetto
      Marco Furlanetto

      Hi Brandon, all,

      I believe I have configured everything correctly. When I'm filling the form I have the toolbar button "Form Utilities -> Generate PDF" which prints the form correctly. However, once the process finishes/form is submitted, this button is no longer available.

      Not sure if this is an error or FPM forms are just printable when users are filling it.

      Please let me know if you are aware of this behavior.

      Many thanks


      Author's profile photo Former Member
      Former Member

      Hi Brandon,

      I was bit frustrated before I read this blog, Thanks. Apart from the ones you have mentioned I feel there are some more. One is I cannot set any service flags as I could in Adobe forms using javascript, using this service flag I could use if else statment in generic services as per the required business logic.

      Secondly, I have not still found a mutlilanguage translation method other than coding, In adobe we had a very simple way of doing it.



      Author's profile photo Former Member
      Former Member

      I want to use HCM Processes and Forms as a platform for employees to create PDF documents for themselves (kind of ESS application).

      You probably ask yourself why HCM P&F and not just develop a WD application.

      There are some reasons for that:

      First and foremost, "Print Form (FPM Form Only)" feature of HCM P&F let you create a PDF document very easy since it uses PA/PD built-in services to retrieve the data from the DB to the form and by that saves the need to develop the PDF interface. Second, P&F has a built in tracking ability that records all PDF documents that were produced and the data in them and let you retrieve data easily. Third, if approval is needed to produce the document then WF is built in P&F.

      I wonder how to enforce the user to click on the "Send" button in order to generate the PDF so the process will be logged and can be retrieved by HR Administrator using the standard processes search. If the user just generate a pdf document without clicking on "Send" button, the process isn't saved and therefore can't be retrieved. Other option may be to enforce PDF generation only after clicking "Send" button, and not as a separate button on the screen.

      I don't know how to implement these ideas and if it's really possible.

      I would appreciate your opinion and even new ideas.