1 2 3 5 Previous Next

SAP Interactive Forms by Adobe

65 Posts

IFbA_Book_Cover_3rd_Edition_small.pngThis is only for readers who speak German: The famous team worked together on updating the book on Interactive Forms and published the 3rd German edition. The 3rd edition is an update that covers SAP NetWeaver 7.4 and Adobe LiveCycle Designer 10.40.


Besides the general update to describe the use of the latest software the team added new content (26 pages)! The book now covers PDF/A, printer options, print tickets, label printers (Zebra, Intermec, Datamax and Toshiba) and LiveCycle Designer improvements like defining keyboard shortcuts in Designer or the action generator to generate scripts.


In its  3rd edition and with 799 pages this book is the ultimate reference and provides step-by-step instructions not only for beginners but also for everyone who wants to learn what happened over the last four years in product development for IFbA at SAP and Adobe.


Check it out here: https://www.rheinwerk-verlag.de/sap-interactive-forms-by-adobe_3824/

The main advantage of using  scripting in Adobe forms is that we can improve functionality and usability of forms.

With scripting we can get full control over forms at run time.


Benefits of Scripting:

  • Display/Hide form objects based on Conditions while generating the PDF Form

        (Examples: Hide /Display Table or Page in generated PDF Form, Adding Back ground colours based on conditions )

  • Automatic calculation in Forms.

        (Examples: Sum,Avg,Percentage, etc.. )

  • Data validations.

        (Check existence of Data using flag conditions..).

        All the Actions written in Script editor will be executed at the run time.

Where should we have to write our Script in Adobe Forms:

        We can create our forms using Transaction Code SFP (Form Builder).

        Go to Transaction Code  SFP.

        Enter the Form Name

        Click on Layout.

        Menu Bar --> Pallets --> Script Editor

Script Editor.png


   Select the Script Editor.

   Select an Object in the Layout.

   The Script editor will be displayed as shown below.

2015-07-15 16_17_01-Form Builder_ Change Form ZAF_FORM_CALC.png




Objects are used to display the data in PDF Forms . Based on the data type we have to select Object from object library  and add it to layout.

Examples:  Amounts                   ---->      Numeric Field / Decimal Field.      

                    Date/Time                ---->      Date/Time Field.

                    Image                       ---->      Image Field 


We can divide the objects into two categories.

  • Objects supported by Scripting Languages.
  • Objects not Supported by Scripting languages.

Objects in Adobe Forms.png

SAP Adobe forms Supports two scripting Languages.

  • FormCalc.
  • JavaScript.

A Form can use both languages in the form at the same time but we can't use both scripting languages for single Object.



         FormCalc is the default scripting language in Designer. It is an easy-to-use calculation language.

         FormCalc is the best choice to work on functions like (date and time, financial, arithmetic , logical etc.)



  • Built-in-Functions

        FormCalc has many built in Functions that covers a range of Areas including Finance, logic, dates/times and mathematics.

  • Performance

        FormCalc usually provides better performance than JavaScript because it executes calculations and validations more quickly.

        FormCalc can be the best choice in many situations, regardless of programming experience.

  • Easier to maintain

        This scripting language is very useful for Non Programmers who need to add calculations for their forms.

        It is very similar to the Language that we use in  Microsoft Office like Excel, Most FormCalc scripts are one line long.



  • FormCalc is not as powerful or as ubiquitous as Java Script.
  • It will not work for HTML Forms ..
  • Not very useful for creating sophisticated interactive and dynamic forms.




      Go to SFP. Enter the Name of the Form and click on Create.

2015-07-15 17_24_00-Form Builder_ Entry Point.png


A pop will be displayed as shown below.Assign Interface for your form.


Interface is the place where we add code to fetch data from Data base tables.We can display the database

tables data by binding the Variables used in Interface  with the Objects in the Form(layout).


Context is the place where the connection is established between Interface and Form.

2015-07-15 17_27_53-.png

Click on Save.To design the layout(Form) click on Layout.




Example 1:

     FomCalc:  Sum of Multiple Numbers (Sum)


Drag and Drop a  Numeric Field from Object Library into the layout as shown below.. Select the Field. Go to Script Editor.

In Script editor select the event (form ready). We can see the Header line which represents the path of the form.





data.#subform[0].NumericField1::ready:form - (FormCalc, client)


  • #subform[0]                     ------>   Name of the Subform
  • NumericField1                 ------>   Name of the Field on the Layout
  • ready:form                       ------>  Event under which the script added will be executed.
  • FormCalc, client               ------>  ( Scripting language,Run at ) 


   After adding FormCalc Script,Click on Save,Activate,Execute.





Example 2:

    FormCalc: Annual Percentage of Loan(Apr)




     Example 3:

     FormCalc : To display the Number in Word Format ( WordNum )





Java Script:

Although FormCalc is default scripting language in designer, Java script is more ideal for creating sophisticated interactive and dynamic forms.


Advantages of Java script:


  • JavaScript is ubiquitous.

        JavaScript is a scripting standard that many programmers and designers already know.

  • Object -oriented.

         We can create JavaScript objects and custom functions, and use them through out Form.

         This function is not available in FormCalc.It has been scripting standard we can find sample scripts for almost we need to do.

  • Works for HTML and PDF Forms:

        We can use JavaScript for both PDF Forms and HTML Forms.


  • Performance

        Performance is lower than Formcalc.



  JavaScript:  Hide/Display entire column in a table if the total sum of the column is '0'.


    In debugging we can see the Entire column with zero values



   If the entire column doesn't have zero values set a flag as shown below. The last column SI_AMT1 doesn't have values.

   This flag value will be passed to  variable lv_si1 which is in our Java script.



    Now the added java script under the event ( Form ready) will be executed and the entire column with zero' will be removed from the table  in PDF Form  display.


     Output: We can see no entire column with zero's in table  in Output PDF Form.



Example 2 :

JavaScript:   Adding Back ground colors for the Table Fields and  field content should be displayed in Bold


  • In my table I have a Field POSID it the value of the field is Outcome then it should display all the data in  bold and back ground colors with following          properties.



  • Else if POSID field value is Output then it should display background color with following properties .



data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA.POSID::initialize - (JavaScript, client)

var numrows = xfa.resolveNodes("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA[*]").length;

var rowFillColor;

for (var i=0; i<numrows; i++)


posid = xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"].POSID").rawValue;

if (posid == "Outcome")


rowFillColor = "191,191,191";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").border.fill.color.value = rowFillColor;

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").POSID.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").POST1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").T_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").F_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").S_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").TH_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").FO_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").FI_AMT1.font.weight = "bold";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").SI_AMT1.font.weight = "bold"; 


else if (posid == "Output")


rowFillColor = "217,217,217";

xfa.resolveNode("data.Overal_Budget_Same_Currency.GT_TOT_BUD_SAMECUR.DATA["+i+"]").border.fill.color.value = rowFillColor;


delete outcome;




    All the Rows  which has  Outcome in first cell are displayed in Bold with the  assigned Back Ground Color.

    All the Rows  which has  Output     in first cell are displayed with assigned Back ground Color.


We have to decide the script language to be used in Adobe Forms, based on the Scenario/Functionality we need to achieve.

SAP Forms as a Service is a new PDF form rendering service on the HANA Cloud Platform (HCP).  It is a cloud service for the rendering and de-assembly of PDF forms, based on the Adobe Document Services (ADS) component that traditionally runs on an SAP NetWeaver JAVA stack on premise.  It is a version of SAP Interactive Forms by Adobe with the ADS component in the cloud.


SAP Forms as a Service2.png


Since the ‘Form Processing Framework’ and template repository remain on premise, this is a hybrid solution for delivering SAP Forms.


What does it do?

Functionally this provides the same scope as the on premise version:

  1. Render of non-interactive (‘print’) PDF forms for print, e-mail or archive;
  2. Render of interactive PDF forms for off-line scenarios;
  3. Render of interactive PDF forms for on-line scenarios.



The interactive forms can be ‘static’ in order to support annotations, or ‘dynamic’ to support client-side presentation logic.  The technology supports attachments, digital signatures and server signatures/certificates.


The only significant difference, apart from some restrictions on digital signatures (HSM / MSCAPI credentials) is that the HCP version does not support parallelization, which has been essential for some customers who need to generate very high numbers of documents.


How it works

Setting up the new service is straightforward.  The first step is to subscribe to the new service.  This allows you to assign roles and then configure the ADS service through the HANA Cloud Platform.

SAP Forms as a Service3.png


Then you re-point your on premise ABAP stacks by configuring a new ‘ADS’ RFC connection in transaction SM59, and import some certificates to the Trust Manager in transaction STRUST in order to establish an SSL connection to the cloud.

Finally, some scenarios require the HANA Cloud Connector, and so this also needs to be set up and configured.

SAP Forms as a Service1.png


Benefits of the new approach

SAP Forms as a Service provides a number of benefits:

  • Some customers will find that they no longer need to manage an on premise SAP NetWeaver JAVA stack if they move to HCP.  This means a saving on hardware and maintenance, and a simplification of the on premise SAP landscape.
  • Since SAP manages the ADS on HCP, customers do not have to handle any patches and updates.
  • SAP will handle the sizing, load balancing and hardware set up.
  • For periodic processes, or processes which have occasional activity ‘peaks’, the solution will automatically scale: customers no longer have to invest in hardware to support peak processes.


The licensing model is simplified and may benefit many but not all customers:  The on premise arrangement is that [i] print forms are free, and [ii] customers pay for the use of interactive forms that are not pre-delivered by SAP.  The cloud model makes no distinction between the types of form, but is based purely on a package of billable requests.


Our testing

Arch worked with SAP on a Customer Engagement Initiative and a Customer Validation Initiative for SAP Forms as a Service, and we conducted wide-ranging testing, which included:


  • On-line form testing
    • Simple form process using Arch FLM
    • Complex form template rendering and submission
    • Attachment capture and reproduction
    • Annotation capture and reproduction
    • Validation error handling
  • Off-line form testing
    • Simple off-line form process using Arch FLM
    • Off-line form with server certificate
    • Client-side digital signature capture on static off-line form
    • Server-side digital signature on static off-line form
  • Print form testing
    • Simple print form render
    • Letter generation end-to-end process using Arch Aquiller
  • Performance testing
    • Simple interactive on-line form template
    • Complex interactive on-line form template
    • Simple print form template


All the scenarios were validated successfully, and so we are content that our products FLM and Aquiller both support SAP Forms as a Service.


The performance test results, however, were disappointing for larger or more complex form templates.  We are hoping that this is an issue that SAP will address in the coming months, and hopefully an upgraded HANA Cloud Platform in 2016 will have a positive impact.

Use Cases

Our recommendation is that SAP Forms as a Service should be used for processes that use simple form templates, or processes where no user is waiting for the form to render.

The best use-case for SAP Interactive Forms as a Service is for standard output forms, where the printing or output is performed by a batch job, so that nobody is waiting.  On occasion, a render will be required for ‘print preview’, and ideally the ADS render should take less than 1 second.  This should be possible with careful form template design.

The other scenario that we recommend the service for is off-line interactive forms. Since off-line forms are normally either distributed by e-mail or rendered at design-time, there is no user waiting for the form to render.

HTML for on-line forms

We now recommend HTML forms for all on-line scenarios unless specific PDF functionality is required.  This is partly due to the rendering time for PDF interactive forms, but also due to diminishing browser support for on-line PDF forms.  Web browsers now support PDF reading as a standard feature, but do not support interactive PDF forms.  We see this on mobile devices such as iPads and Android tablets, in Google Chrome and now in ‘Microsoft Edge’ (the Windows 10 browser).



Arch FLM complements SAP Forms as a Service by delivering HTML form rendering natively as well as integrating with SAP Forms as a Service for PDF forms.  Customers wishing to move away from on-line PDF forms can use Arch FLM to help them on their journey, while still using SAP Interactive Forms for off-line and print form requirements.

Arch FLM can help customers make the move to SAP Forms as a Service by providing the on premise form processing framework for ADS integration, and by providing the HTML alternative for on-line PDF forms which are approaching end-of-life.


For SAP output scenarios, customers should consider moving to SAP Forms as a Service.  The Arch Product Suite complements this in two ways:

  • Arch Floe can be used to deliver HTML e-mail output.  This can be used alongside SAP Forms as a Service to send PDF forms as an e-mail attachment, or can replace some SAPScript / Smartforms / IfbA templates by delivering the output within the body of the e-mail instead of in a separate PDF attachment.
  • Arch Aquiller integrates with SAP Forms as a Service for the generation of employee letters and contracts.



For interactive forms scenarios, customers should consider HTML forms delivered by Arch FLM to replace complex on-line PDF forms, and consider SAP Forms as a Service alongside Arch FLM for off-line form processes.  For scenarios in which customer are using pre-delivered SAP forms templates, we recommend no short-term change, but consider that browser support may be more limited in the future.



Further Reading




During the IFbA Roadmap sessions at TechEd last year there were a number of questions about HTML form generation.  HTML forms had been planned for IFbA but now have been removed from the roadmap.  Arch FLM provides the ability to render and manage dynamic HTML input forms, but there was also keen interest was really around document output scenarios, where the HTML output form would be sent as the e-mail body, meaning no need for any PDF attachment.


This got me thinking about how I get communication from many companies.  As a customer I regularly receive order confirmations, deliver confirmations and even invoices from lots of different customers.  So why do I need a PDF attachment for SAP document output?  Even with S/4 HANA.  It seems astonishing that there is no ability to maintain an HTML output template.  I spoke to a number of customers and SAP employees, and everyone was equally astonished.  It just isn’t there. Really!


In the SAP Business Suite we have SAPScript output, Smartforms and Interactive forms by Adobe.  All three options designed for print output in the first instance, with lots of print controls, support for barcodes and font printing etc.  When communication is sent by e-mail the document is sent as an attachment and there is little control over the e-mail body content without a lot of extra development.  Plus, when you trigger the e-mail the message subject in the SAP outbound queue (transaction SOST) is limited to 50 characters, which can be very irritating!


It seems to me that in the last 10 years the world has moved on but the SAP solution hasn't.  Today's companies have largely eradicated the use of paper. We don't use fax any more.  We don't need to physically print and sign documents. But we do receive e-mails on hundreds of devices of different sizes.  E-mails rich in graphical content; e-mails that responsively change based on the screen size; e-mails that look fantastic.


Of course there is a place for PDF output, especially for legal documents such as employee contracts*, and actually one requirement I've seen several times recently is for multiple documents to be sent together as a pack.  But there are lots of scenarios where using HTML e-mail has great advantages over using PDF attachments:



  • Single system.

With no PDF rendering there is no need for a JAVA stack which means that the infrastructure is simpler and the performance is faster.

  • E-mail size.

With no PDF attachment the e-mail is much smaller, which provides benefits for space and performance in the SAP database, the e-mail server for both sender/recipient and the e-mail client)

  • Delivery confidence.

With no attachment the e-mail is less likely to be trapped by corporate firewalls or treated as SPAM.


Arch already provides HTML e-forms to complement IFbA in the shape of FLM, and a business requirement we often see for forms-based processes is to trigger a variety of notification e-mails at different processing steps.  This includes process notifications (to inform users that a form has been routed to them), and also to inform different departments and sets of users of process progress or resulting SAP updates.  There is often a lot of data from the form within the body of the e-mail and sometimes the entire form is attached in a 'flattened' PDF format.  This is a normal project task, but involves some development, and the management of HTML e-mail templates is not easy.


So last year we decided to build an e-mail solution to deliver the benefits for document output and handle e-mail templates much more easily.  The result is Arch Floe, launched at Sapphire Orlando, May 2015.



Floe is a development tool which is an ABAP add-on, either for SAP NetWeaver of for S/4 HANA.

It delivers the management of e-mail templates within SAP, and provides the ability to add logic to tailor the content of the generated e-mail based on SAP data.



At run-time, Floe generates e-mails based on the selected template and SAP data, substituting the data into fields in the e-mail.  It provides the ability to define HTML blocks within the template that can repeat or have business logic to optionally include or exclude from the generated e-mail.

This makes it easily possible to build templates for document output like sales order confirmations; documents with repeating rows or nested repeating sections; the e-mail content is generated based on the data. 




The developer's job is to change the output program to call the Floe API, simply passing in the document data, and then add formatting logic (for date fields and currency fields, for example).  Then add in the HTML template as separate maintainable blocks.



At development time, a developer can generate several user-exits for each template. This means that there is a place to easily add business logic for:

  • Recipient determination;
  • Language determination;
  • HTML block determination;
  • Data (variable) determination;
  • Attachment determination;
  • Embedded image determination.


Floe delivers the ability to deliver complex requirements but simple notification e-mail can be built in minutes, as this video shows.




Floe can also be used for any notification e-mail, and for mass correspondence.  The benefit of using Floe over a tool like Mailchimp lies in

  • SAP integration

Any data from SAP can be included in the e-mail, and

  • Personalisation

As each generated e-mail can dynamically include different content, a single e-mail sent to many recipients can be personalised to each recipient, not only by simple data substitution but also in content too.




Since we've started showing Floe to customers and partners we've seen great interest; it feels like a neat tool that can add value to any SAP Business Suite customer.


For more information and demonstrations check out www.floe.com



*Arch Aquiller provides an easy tool to build dynamic PDF output for employee contracts and many other business requirements.  It integrates with IFbA for PDF generation.

Hi Experts,

i need help in  Adobe Interactive Forms development. I want to group a table by using the control level at the context menu. And it works in every case out of one. If I use one specific column the group function doesn’t works correct any longer.

In Detail: I use a table like this one:




This Table is grouped by column a. And it works correct until I insert a value at column b then the table don’t summarized all equal values at column a but a is getting repeated at every record.

Does anybody know why or have an Idea ?


Thank you.

Best regards,


Merging internal table cells dynamically in SAP Adobe forms using Java script code

This blog describes how to merge cells dynamically in a table of SAP Adobe forms.


  • Basic knowledge on Adobe designing and
  • Adobe Java Scripting.


Customer requirement is to have the table format as per the below screen shot.


Observations from the above requirement:

  1. We can simply say it is an M x 9 matrix with different widths for each column.
  2. The first four table columns (table cells) change dynamically.
  • Column-1: Outcome
  • Column-2: Output
  • Column-3: Activity
  • Column-4: Estimated completion date


Depending on which we have to merge the first four table columns (table cells) dynamically..?


  1. If first cell (Outcome) contains data, then we need to merge the first 3 table cells and show the complete data related to Outcome only.
  2. If second cell (Output) contains data, then we need to merge the Output and Activity table cells and show the complete data related to the Output only.
  3. If third cell (Activity) contains data, then no action is required. Leave this cell as is.
  4. I just crop the last two rows from the above table provided in the customer requirement.



   In the above table, red border indicates that the first four cells are merged...why..?


   In this case Outcome, Output, Activity and Estimated Completion Date cells are empty.

   So, we need to merge all the four cells into a single cell.


Procedure on how to achieve this functionality:

In this requirement I am just giving you a brief overview of Java script coding part involved not the Adobe form table design.


1. After the completion of adobe table design, select the table cell (Outcome cell) as shown below and write the Java script code in the initialize event.


Here is the Java script coding part in the adobe initialize event related to Outcome.



2. Select the table cell (Output cell) as shown below and write the Java script coding in the initialize event.


Here is the Java script coding part in the adobe initialize event related to Output.


Step by step explanation of Java script coding part related to “Outcome”:


Calculate no of rows in a table using the following Java script coding:

My adobe table name: GT_PROJECT

My adobe table body: GT_PROJECT.DATA


Java script syntax to calculate no of rows in a table:

var numrows = xfa.resolveNodes("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA[*]").length;



Loop each row:


for (var i=0; i<numrows; i++)


First take the values from the four cells:

Cell-1 -> Outcome:

outcome = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").rawValue;


Cell-2 -> Output:

output = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").rawValue;


Cell-3 -> Activity:

activity = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").rawValue;


Cell-4 -> Latest finish / estimated completion:

latfinish = xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].LATEST_FINISH").rawValue;



Use appropriate conditions as required:

if((outcome == null) && (output == null) && (activity == null) && (latfinish == null))


xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").colSpan = "4"; 

  xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").presence = "hidden";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "hidden";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].LATEST_FINISH").presence = "hidden";




if (outcome !== null)


xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").colSpan = "3"; 

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").presence = "hidden";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "hidden";




xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTCOME").colSpan = "1"; 

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").presence = "visible";

xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "visible";  



delete outcome;



Step by step explanation of Java script coding part related to “Output”:


Follow the first two steps as explained above.


Use appropriate conditions as per required:

if (output !== null)

{ xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].OUTPUT").colSpan = "2";   xfa.resolveNode("data.PAGE11.Newtable.#subform[0].GT_PROJECT.DATA["+i+"].ACTIVITY").presence = "hidden";   






delete output;



Resultant PDF Output:



At SAP TechEd && d-code recently I heard a question at the IFbA Roadmap session about support for forms in SAPUI5. 

Since the ‘standard’ approach for on-line e-forms is to publish them via a custom Web Dynpro, there was an assumption that this was the only way to use SAP e-forms.  Not so: Here I describe ten different ways we see SAP e-forms being used, and none of them require any Web Dynpro development.  Instead, FLM is used to deliver the form through a URL hyperlink that can be embedded in many different places.

[1] SAP Enterprise Portal

For organisations making use of the SAP Enterprise Portal, links can be added in any page to launch new e-forms, or to the e-forms inbox, or to forms previously saved as draft.

sap ep.JPG

[2] HANA Cloud Portal

Similarly, where organisations are using the HANA Cloud Portal, e-forms can be easily embedded.


[3] Fiori LaunchPad

As companies start to embrace the Fiori LaunchPad as a work portal, tiles can be used to launch e-forms easily.



Where Employee Self-Service is used this is an obvious place for launching and HR form.


[5] OrgPublisher

When third party products like OrgPublisher are used, this is often the best way to launch a form for a particular SAP object in order to pre-populate the form for a particular Employee, Position, Org Unit etc.


[6] Direct e-mail link

Embedded links within html e-mails are often used for work in progress.  Notification e-mails can contain the link to open up for form for approval, for example.


[7] SAP Universal Worklist

When the SAP Universal Worklist is already being used then it makes sense to use this inbox for e-forms in process.


[8] FLM Portal (SAPUI5)

The FLM Portal includes an e-forms inbox, new form launcher and a variety of other functions.


[9] Web transaction (e.g. BSP, SAPUI5, Web Dynpro)

E-forms can be launched from any web-based transaction.

web dynpro.jpg


Finally, you can even access e-forms through the SAPGUI.


E-forms remain an important tool for process automation and better usability, and as the number of options and technologies from SAP grows, the number of ways we can access e-forms increases.

Next year watch this space for E-forms integration with SAP Fiori!

Hi all


we faced Syntax Errors in Function Modules /1BCDWB/SM00000XXX and /1BCDWB/SM00000XXX_TEST (Missing Table FPTESTDATA)


the Table does not exist in the new Release any more.



Use SA38 Report FP_GENERATE_FUNCTION_MODULE to Fix the Error



worked nice for us



Who’s Afraid of the Big Bad Data?

Bad data is everywhere.  It’s like a virus in our organisations, which prospers unless we deal with it effectively.  It can crops up all over the enterprise and cause little irritations which add up to enormous hidden costs.  As we move into an era of Big Data, it is even more important to ensure that the data we collect is clean, so we don’t enter an era of Big Bad Data.

But here’s the thing: Bad data is both fixable and avoidable. It’s not like many other business challenges for which our tools are incomplete or which are caused by external factors out of our control.  I’ll go further: there’s no excuse for bad data in organisations any more, and IT Directors should take responsibility for ensuring data quality.  If your processes are not in place to manage data quality, then you’re not ready for small data, never mind about big data!

In this blog post, I identify 5 causes of bad data, and discuss how they can be rectified and avoided without a budget of $millions.

[1] Obsolescence

Have you ever encountered the scenario where you have to scroll through lots of records to find the one you are looking for, in the knowledge that many of those records flying by are not used or needed any longer? Perhaps you are participating in a transactional process or running a report and need to select that customer, material or GL account.  And you know the record you’re looking for is on the second or third page down.  You know that you haven’t used many of the entries on the list for years.

Never mind about data quality issues, you have a data inequality problem, where lots of data are obsolete and should be removed from the system.

I hardly need to say that data archiving solves all this.  20 years ago many SAP projects went live with a note that archiving would be tackled down the line, but these days all this should be in place, with regular archiving runs in place to remove the obsolete data.

[2] Out-dated Data

I make a careful distinction between obsolete data and out-date data.  ‘Obsolete data’ I define as the data that you don’t want in your core systems and should be archived.  ‘Out-dated data’ I define as data that has changed in real life but not on the system.  You work with the data records, but you know that are out-of-date.

Has your enterprise ever continued to pay an employee after they have left employment?  Or sent an account statement to the wrong customer address? Or send information by e-mails that bounce?  Do you run ESS but know that employees consume data without updating it?  I met one customer who didn’t actually know how many employees they had because they had a 3-month backlog of processing joiner and leaver forms.

These are all symptoms of out-dated data: data that describes how life used to be, rather than what it’s like today.

There can be a one-off or scheduled clean-up activity for this data, but really the solution lies in capturing changes as they occur.  This can involve:

i) Automatically triggering a form to capture data changes based on events.  For example, triggering a form to capture employee changes after each performance assessment meeting.  For example, sending a link for customers to check their own details when an order is placed after a period of inactivity.

ii) Automatically triggering a form to capture data changes based on a schedule.  For example, sending a link for employees to check/confirm their own data each year.

iii) Enabling the easy manual creation of a form to trigger master data updates when a user notices that something is incorrect.

[3] Erroneous & Missing Data

Do you ever hear people say that they don’t trust the system?  Or see users who keep their own files in Excel to check what the system suggests.  Do you see purchase orders where the ‘long text’ fields are used to describe the material or service to be purchased in great detail, because the description of the material master isn’t really what is wanted?

Have you seen a world in which the people responsible for the creation of master data are not the same people who work with that master data, and there’s a gap between how master data is expected to be used and how it is used in practice? Perhaps the data creation task is outsourced, and you are now finding a hidden cost of outsourcing?

There are many examples where the data is just plain wrong.  Users struggle with the system and try to find the closest match.   Sometimes the record is missing completely and users don’t request the new data record, but re-use an old one instead.

This type of bad data differs from out-dated data, because at least the out-dated data was right once.  In this type of scenario we are dealing with data that was never correct because it wasn’t captured correctly in the first place.

The solution relies on better data capture.  That means using integrated data capture e-forms, and throwing away Word or Excel solutions.  That means running validation rules at the point of data capture.  That means not only checking that mandatory fields are captured, but that they are filled with something meaningful.  It requires a mixture of automatic and manual data checks before the record is saved to the SAP system.

[4] Inconsistent Data

Do you get strange results when running reports, only to later realise that customer or material master records have been inconsistently defined? Do you use many different grouping fields on master records and then rely on them for reporting?  Do you see employees struggle because they don’t know what fields to use, or because they don’t know why they always have to fill particular fields?

Or do you see times when employees cannot find the right material to use because the descriptions don’t make sense to them?  (Of course this may lead to them requesting the creation of a new material record unnecessarily.)

Organisations’ use of master data changes over time, and fields may have been crucial for historical data upload, or EDI/ALE, or transfer to BW, or reporting through LIS or COPA.  However those same grouping fields may no longer have any relevance or any understood relevance.  You end up with inconsistent use of master data records, which can cause great user confusion.  And this isn’t master data management, it’s master data mismanagement.

You need to be clear and consistent in the use of fields such as grouping terms, search terms, description fields and product hierarchies, and of course for every other field.

With an e-form for automatic record creation, rules can be added for automatic generation of description fields.  Many fields can be hidden and filled automatically and consistently.  Validation checks can include checking the categorisation of similar records in order to throw out exceptions and suggestions to make the user’s task easier and deliver a bullet-proof master data request process.

[5] Duplication

I’ve separated out duplication as a separate cause of bad data as it’s a particular bug bear.  When employees see a list of vendors and do not know which one to use, the process is broken before it is started.  When the task of determining what record to use to difficult, employees may avoid this and simply ask for a new record to be created.  When the appropriate checks and balances are not in place, the creation of new records can spiral out of control.  And as soon as a customer, material, vendor or GL account has some transaction history it becomes troublesome to remove.

During master data request processing, a duplicate record check is essential. This might involve quite complex algorithms, to identify a list of suspected duplicates, in order to stop the process before it begins.  Where a process continues, request forms can be dynamically routed for a manual check of candidate duplicates before the form is accepted and the update made to SAP.

Fixable and Avoidable

I make no apology that all this seems obvious.  But I repeat, all these sources of bad data are both fixable and avoidable with modest investment.  Bad data is now a choice for organisations.   They can keep it at their own risk, and bad data isn’t free.

Of course there are many specialist tools and services available, but simple, integrated e-forms, together with robust business logic for validation, duplication checking, consistency checking, routing and SAP updating, can deliver the solution to all the above.  You can even use an e-form to request/approve a record to be archived.

So next time you see any issues resulting from bad data, note that someone has chosen to keep that issue, as it is all perfectly solvable.

The most common problem we often face when we have to dispaly the date format and Quantity format according to the User settings.


To overcome this problem the easiest way is




DATA : lv_date         TYPE  sy-datum,       

           lv_date1        TYPE  char10,

           gv_date         TYPE char10.


     CLEAR lv_date.

     CLEAR lv_date1.

     CLEAR gv_date.

     lv_date = sy-datum.

     WRITE lv_date TO lv_date1.

     gv_date = lv_date1.

     CONDENSE gv_date.


Adobe Form:


In the Adobe Form take the Date field as TEXT and bind it with gv_date





     DATA : lv_menge(16) TYPE p DECIMALS 3,

                lv_menge1 TYPE char20,

                gv_menge  TYPE char20.


       CLEAR lv_menge.

       CLEAR lv_menge1.

       lv_menge = <fs_mditems>-menge. "Quantity

       WRITE lv_menge TO lv_menge1.

       CONDENSE lv_menge1.

       gv_menge  = lv_menge1.

       CONDENSE  gv_menge.


Adobe Form:


In Adobe Form Take the Quantity field as TEXT and bind it with gv_menge .


Conclusion: Write makes the Quantity, Date and also time according to the current user settings.

After reading difficulties of several people on SCN posts regarding basic ADS configuration, I thought of writing this simple blog on ‘How to setup simple ADS between an ABAP and JAVA systems?’.

Use case:

  • ABAP system should be able to print PDF through ADS on JAVA stack.
  • ABAP and JAVA are standalone systems (not dual stack).
  • To be specific; SE38 > FP_TEST_00 > F8 > F8 > (Output device LP01 – Dummy printer) > Print preview > PDF should be displayed.See the screenshots below.


IMPORTANT: Please read and understand the document “Configuration Guide for SAP Interactive Forms by Adobe Adobe Document Services”. Below steps are not complete, they are in supplement to the steps given in the configuration guide.

When things don’t work even after following the configuration guide, you can use below steps to understand, double check and fix it.

First let’s make ADS working on JAVA alone.

    • Create user J2EE_ADSUSR (equivalent to ADSUSER) as described in the section “Creating the User ADSUser and Assigning the Security Role” in the configuration guide.
    • Visual Admin > Cluster tab > Server  > Services > Security Provide > User Management tab >Edit mode > Create User button. Make sure you add the user to ADSCallers Group.


    • On the Policy Configurations tab, in the Components area, select com.adobe/AdobeDocumentServices*AdobeDocumentServicesAssembly.jar.
    • On the Security Roles tab, select ADSCaller from the Security Roles list.
    • In the Mappings area, choose Add > assigns the J2EE_ADSUSR user to the ADSCaller security role



    • On the Policy Configurations tab, in the Components area, select the wsnavigator and make the change as shown below, so that wsnavigator service is accessible to all.


    • Change the user type of J2EE_ADSUSR to technical type.


    • Stop and start below two applications


    • Update URL, User & Password as show below in Server → Services → Web Services Security →Web Service Clients → sap.com.tc~wd~pdfobject → com.sap.tc.webdynpro.adsproxy.AdsProxy*ConfigPort_Document.


    • Restart Web Services Security by clicking on 1.png and then on 1.png



Let’s test if it works.

Open the URL http://<host>:<port>/wsnavigator in web browser

It should open without asking password.

Then open the URL http://<host>:<port>/AdobeDocumentServices/Config

Again without asking password a page like below should be displayed.




Click on Test > Then on rpData (test.types.p1.RpData parameters) > Then on Send button > Enter user as J2EE_ADSUSR and its correct password > Press Submit button


You should see the OK response as show below.




Congratulations! ADS standalone on JAVA side works correctly.


Next step is to create RFC in SM59 on ABAP side. Create the RFC named ADS as show  below.




And perform the connection test. You should get OK code.





Little more to do.

JAVA has to send back pdf after processing, therefore it needs a connection (JAVA to ABAP> and credentials.

Let’s do that now.


Create a user ABAP_ADSAGNT on ABAP side and assign the role SAP_BC_FPADS_ICF. If you don’t have the role, download and upload from any other systems if you have. Make sure PFCG > SAP_BC_FPADS_ICF > Edit > Authorization tab is green and User tab is green, else generate profile and do user comparison to make them green.


Make sure the user type as system or communication so that you are not asked to change the password while logging in.


Activate SICF services; /default_host/sap/bc/fp  and  /default_host/sap/bc/fpads


Go to Visual Admin > Server > Services > Destinations > HTTP > New button > FP_ICF_DATA_<SID>


In URL field enter as given below



The existing entries <server> and <port> refer to the AS ABAP. The ABAP HTTP port is provided in transaction SMICM; choose Goto -> Services.


Enter client where ABAP_ADSAGNT user was created.


Change Athentication to BASIC and enter user ABAP_ADSAGNT and password





Up to SAP NetWeaver 7.0x, choose 'Save and Test'; as of SAP NetWeaver 7.10, choose 'Ping Destination'.


You should see code 200.





IMPORTANT: Remove the /sap/bc/fp/form/layout/fp_test_00.xdp part of the URL. Means do not forget to change the URL back to http://<server>:<port>


And press SAVE button (NOT SAVE & TEST), only SAVE button please.


Congratulations! JAVA to ABAP connection is also done.


Time to test with SE38 > FP_TEST_00  as shown in the use case in the beginning of this blog.



Best Regards,


SAP e-forms processes are great for collecting data for single transactions, but when multiple updates are required, users prefer an Excel approach to a PDF approach.  By combining both approaches with a single set of business logic, organisations can benefit from automatic validation, drop-down lists, workflow and SAP update logic across both approaches.  This means that the benefits of SAP Interactive Forms can be extended to data collection with Excel.


SAP e-forms are best used for data collecting for a single transactions or small number of transactions.  Great benefits include form pre-population, data validation on submission, form routing and form updates.  In situations like organisational re-structure or changes of HR benefits, it is not practical to submit hundreds of individual forms, and so a ‘file upload’ approach is a better fit.  The trouble with the common upload approaches is that the benefits of the e-forms processes are lost: there is no data pre-population, generated drop-down lists, data validation or approval workflow.  Instead, the spreadsheet is filled in manually, and the upload simply calls a BDC recording or a BAPI, and the user only sees posting errors.


FLM Excel forms share business logic with PDF and HTML forms.  This means that the Excel form is generated supporting logic such as:

  • Read-only and open fields
  • Date fields, text fields and drop-down lists
  • Mandatory fields

On submission the Excel form calls the same field validation logic built for the PDF form, and triggers single or multiple workflows so that pre-built approval processes are followed for the mass update scenarios.  The Excel form also uses exactly the same logic for updating SAP as the PDF form.  This makes mass update processes secure and powerful, ensures process compliance, and easy to build.  Any PDF form process can be initiated with an automatically-generated Excel form, and no extra development is required.

Let’s consider 3 scenarios:

Scenario 1: Organisational Change

Organisational Change can impact in 2 ways:

  • Mass updates of existing records: For example, updating personnel areas, position relationships or pay scale data across many employee records.
  • Mass intake of new data: For example, creating thousands of new employee records due to a merger or outsourced payroll arrangement


In both scenarios a PDF form can be used to handle individual transactions – Employee data change/transfer or New Joiner.   The individual form process may include not only the SAP HR update, but also secondary processes, employee correspondence and notifications to several departments or managers.
Using an Excel form the same business process can be replicated.  When existing employee records are being updated, the Excel form can be pre-populated with existing data.  For new employee records, validation and drop-down lists rules will be added automatically.


Scenario 2: Data Cleansing

Incorrect customer, vendor or employee records can lead to many issues with payments, reporting and communication.  A PDF form for customer master changes will contain drop-down list data and be pre-populated with key customer data.

The same logic can be applied to an Excel form, with the added logic to select multiple records for download.  The Excel form can then be pre-filled with thousands of rows of customer data, ready for checking and fixing in Excel.  Where no data is changed, the record will be ignored when subsequently uploaded.  Where data is changed, the normal form process can be triggered including complex updates and notifications.


Scenario 3: Periodic Tasks

Form-based processes are a great fit for many periodic tasks, such as employee performance reviews.  Instead of triggering each form manually, Excel form can be used to trigger hundreds or thousands of form processes for specific employees added into the spreadsheet.

The e-form processes by the employee may be HTML or PDF: The Excel form is just used to instigate the multiple processes.


VIDEO: Excel forms in action


Excel forms can complement the PDF form process or enhance it to reach more user communities and more business processes.  The combination of Excel and PDF form processing steps in a single process is what I call a simple ‘multi-UI’ process.   Organisations’ ability to consume multiple user interface technologies within a single process will give them flexibility and speed from which they can derive a competitive edge.


Find out more about FLM Excel forms

Over the years the biggest bugbear that customers have with SAP Interactive Forms is performance: time and again I hear reports that the PDF forms render too slowly.  In this blog update I’m going to discuss what causes performance issues and what we normally analyse to overcome such issues.





The time it takes to open a rendered PDF form is comprised of several components:

  • ADS Render time;
  • Application logic time;
  • Data transmission time;
  • Adobe Reader launch time;
  • PDF rendering on the client / script running time.



Each of these components needs to be considered to determine where the delays are occurring.



ADS Render

Often the main bottleneck is the time the form takes to render in ADS.  The two major considerations in ADS performance is the underlying CPU architecture, and the design of the form template [overlapping objects, use of drop-down lists etc.].  Using the ADS trace can provide some insight.  Also consider:

  • Platform Architecture where ADS is deployed;
  • Java JVM version being used;
  • Use of web dispatcher;
  • Form template optimization.



Of course, the ADS component doesn't operate in isolation and overall system performance and bottle necks will impact its performance.  This can also include landscape architecture, SAP release and support packs deployed, and the physical locations of server hardware.  Consider:

  • Overall server load;
  • SLD setup;
  • Physical locations of ABAP and Java Stacks;
  • SAP Release and Java JVM version.



Application logic

The application used to call ADS and to serve the e-form to the user may also cause issues.  For example, the HCM P&F framework can be slow, or custom form applications may need optimising both in the ABAP application logic and in the portal page.  If a web Dynpro layer is used between the web front end and the back-end system then SAP software versions can impact results.  Traditional SAP tools for performance optimisation can be used in some cases.  Also consider:

  • Use of RFCs;
  • Custom ABAP code;
  • How ADS is called by the application program.



Data transmission

Another key factor in addressing any perceived end-user performance issues is network speed. Depending on the usage scenario slow network speeds can be have a serious impact on the usability of large and complex SIFbA processes. Consider:

  • Bandwidth Speeds;
  • Remote locations;
  • Firewall  / VPN constraint;
  • Form template size in bytes optimization.


Adobe Reader launch

An often overlooked aspect of ADS and SIFbA performance analysis is the user’s desktop configuration and ensuring that the combination of software being utilized is compliant with SAP recommendations.  Of particular interest are:

  • Desktop Speed and Windows Version.
  • Avoid Reader X prior to 10.1.2 as there is a network and JavaScript bugs that can affect performance.
  • Anti-Virus software.



Local Rendering

The final component to check is what processing is occurring within the form when it is rendered locally by Adobe Reader.  Check for:

  • Client-side JavaScript running during initialization and form ready events;
  • Web service calls without user action.



Consider the Process

When considering performance and sizing for SAP Interactive Forms you should consider the peaks in activity: Some form processes are not particularly time-critical and do not typically have activity peaks, whereas processes such as timesheets and expense forms may need to be submitted by a particular date/time, and may cause performance issues during specific time periods unless this has been considered properly.



Another potentially unforeseen issue is in the use of attachments.  If users attach many / large attachments to forms then this can cause performance issues due to the size of the data packet.  You can optionally remove the ability for users to add attachment files, or you can add a check to limit the size of attachments in order to combat this issue.



Finally, a multi-UI approach with Arch FLM will reduce the number of calls to ADS, improve render speed and enable process mobilisation.  FLM also includes an ADS Performance Workbench to help identify performance issues before they impact the business.



If you consider this checklist adequately there is no reason why SAP Interactive Forms by Adobe should run slowly any more.



Arch FLM is a SAP-endorsed business solution.

SAP-endorsed business solutions are complementary to SAP® software offerings, have been specifically integrated with SAP solutions and tested by SAP, and provide additional choices and flexibility for businesses running SAP software. SAP-endorsed business solutions are offered by SAP partners.

This document includes some most common requirements of sap adobe forms.


1) To hide/display an Image at Run time


Adobe 1.pngAdobe 2.png

  • To add an Image, select and drag Image object from Object Library and give the path of the image in the URL field of the Object palette as shown above.

Adobe 3.png

  • As shown in figure above, suppose there are 2 images: – Image 1 and Image 2. One of these have to be hidden at run time based on a flag value say GV_FLAG.
  • To do so, wrap the 2 images and the flag into a subform as shown above and make the text field of the flag invisible.
  • Now click on the subform and write a script in the script editor as shown below.

Adobe 4.png

  • The image would be hidden based on the value of the flag passed as shown below.

Adobe 5.png


2) To display related information from different internal tables

  • Suppose there are 2 internal tables, GT_MARA having Material information and GT_MAKT having Material description.
  • Material description for a material in GT_MARA needs to be printed with the material information simultaneously having common field MATNR.


  • As shown above, first drag GT_MARA into the context of the form.
  • Then drag GT_MAKT into the data of GT_MARA as shown below.


  • Then double click on GT_MAKT and add the condition as shown below.


  • In the layout, position the fields from both the internal tables as required.

         A sample positioning is shown below.


  • The output that shall be displayed is shown below.


3) To remove Leading Zeros from a field value

  • Suppose a field consists of leading zeros as shown in figure below.


  • To remove the leading Zeros, first of all, change the type of field to Numeric Field.


  • Then from the Display patterns select a suitable pattern to be displayed (comma, without comma, percent, dollar, etc.)



  • The output would appear as per the selected pattern.


4) To display footer only on last page

  • Suppose there is a footer section, as shown below, that has to be printed only on last page.


  • Place the text field (here TextField3) in the Master Page and write the following JavaScript in the Script editor.


  • The text field shall only be printed on the last page.

5) To hide a Table Column and adjust width of other Columns

  • As shown in figure below, suppose we want to hide a column of a table at run time based on some condition and want to adjust the width of the other columns.


  • In order to do this, write the script to hide the individual row of the table at appropriate event and appropriate location as shown below.




  • At the table level in Initialize event, add the following script indicating the new widths of the columns to be displayed (along with unit) and Zero width of the column to be hidden.


  • The output shall appear with the appropriate columns.


7) Using sub form to create a table

Instead of using Table Designer, build this form design with a set of nested subforms and then set the accessibility role of the subforms to emulate a table. Use nested subforms instead of Table Designer because a table with multiple header and body rows is not accessible. As illustrated below, when a table has multiple rows, the form generates multiple lines of accessibility tags. The form design generates these accessibility tags even if the body rows are grouped in a table section.


  • To create Header subform


     1.  In the Hierarchy palette, create a text element for header text inside Line_item body page.

     2.  Wrap the text in a subform giving the accessibility as header row.


  • To create Body row

          Move the fields, which you want to view from data view on to the body page individually.


  • To set the accessibility role for each subform:


    In the Accessibility palette, select the Subform Role for each subform as follows:


  • To make multiple page table

          In the Object palette, click the Subform tab and select Flowed from the Content list.


  • To set the Header subform to appear at the top of each page:


        In the Object palette, click the Pagination tab. Under If Dataset Must Be Paginated, select Header from the Overflow Leader list.


  • Form shall be printed across multiple pages.



PDF forms have enabled many SAP customers to automate manual processes, remove paper forms and replace processes based on Excel/Word forms that require manual re-keying.
However, many form-based processes involve multiple processing steps, such as levels of approval, and these steps might be processed on a multiple of devices, where PDF is the wrong user interface or where the version of Adobe Reader does not support Interactive Forms.

The solution might involve a complex mixture of interactive forms, portal pages, mobile apps and even SAP Fiori, as one size does not fit all.


  • Portal pages based on BSP or web Dynpro can have limitations with mobile devices.  SAPUI5 is a much better alternative, but it takes a lot of extra development to create a SAPUI5 page that works on many devices.
  • Custom mobile apps overcome this issue, but they can be expensive to maintain.  Plus, users do not want to manage many mobile apps on their devices.
  • SAP Fiori has the advantage of acting as a container for multiple simple transactions, but users will not want to manage many tiles within SAP Fiori, and the standard transaction screens delivered within SAP Fiori will often not fit the business requirement closely enough.   Plus, SAP Fiori works only ‘on-line’ whereas custom apps can be developed to work off-line and synchronise data later.

Moreover, for many business processes, you do not know what device the user will use at each step of the process.  Processes may be triggered from desktop or mobile device, and approved in the office or on the move.  Users will have multiple devices and it is not realistic to expect them to install and manage a range of apps on a range of devices.

Let’s consider a simple real-life example.



Company A has 10,000 employees, all of whom have access to ESS.  Within ESS each employee is empowered to update their own personal data such as home address, next of kin and bank details.  The problem is that they don’t.  Many users only have a SAP ID for ESS access, and they don’t use it as they have long forgotten their password, or don’t realise that SSO is in place.

This leads to a variety of issues for Company A, with a high HR administration cost.

Company A also has 2,000 temporary employees who have employee records but no ESS access.  The personal data for these employees is also incomplete or incorrect.

No combination of mobile apps, SAP Fiori and portal pages is going to fix this issue: it is one of process compliance, and that’s where a forms-based process can add huge value.

A possible solution could be:


  • Process triggered by HR Admin, Manager or background job
  • For each selected employee a form is generated and they are sent a notification e-mail.
  • For employees with no SAP access, or with no recent activity in the SAP system, a PDF interactive form is attached to the e-mail.  This is pre-populated with their own data which they can confirm or correct and submit back.
  • For employees with active SAP users, then they can be presented with a link to an on-line version of the form, which can be rendered in HTML5, so that they can use any device to check and correct their own data.  Alternatively they can use ESS (or a custom app) to update their data.
  • When a form is submitted back then the employee data is automatically updated.
  • A background job can check for any unprocessed forms –and check whether the employee master record was updated – and if not, then trigger a reminder e-mail.  As time passes the employee’s line manager can be informed:  The system can ‘chase’ each employee until they have confirmed their own data.


So here a solution involving multiple UIs and many devices can solve a business problem without a large scale roll out of mobile apps or SAP Fiori.


Let’s consider another example:



Company A is processing a mixture of expense forms. Some employees are using an Excel spreadsheet, some are using SAP Portal.  Some employees are scanning receipts, others are posting the receipts.  It’s a mess.


The company wishes to introduce an expenses mobile app, whereby the employees can enter details and attach photos of receipts, taken on mobile or tablet.


As part of the expense form, the employee indicates the project or cost centre against each item, and then approval for those items has to be sought from the budget owner.


In some cases the form will need to be approved by a line manager or by an administrator to ensure receipts have been checked.  This might be a dynamic rule based on the form data or simply a governance rule (such as 5% of expense claims must be randomly checked).


Not all users will have mobile devices and not all users will have SAP access.   Users will want to be able to track the progress of their expense form through approval stages.  At any time the expense form can be rejected back to the user.


Users can be notified by e-mail and SAP Universal Worklist, and so there isn’t any value of adding an ‘inbox’ function within the expenses app.

Users who submitted expenses claims without using the app also need to track their forms, and so there isn’t any point in building the tracking capability into the app either.


So quickly we see that the best fit is, once again, a multi-UI process.


With a multi-UI process, employees with SAP access could elect to start the process using an on-line form, the custom mobile app.  Employees without SAP access could either be sent a PDF form each month, or could download a PDF form from the company intranet, or could use a published html form on the intranet.  The benefit of sending the form to the employee is that it can be pre-populated with their own data.


Wherever the form was submitted from the rest of the process should now be common.  Data from each form will be collated by cost center / project and routed to each budget holder for approval.  Only when all parts of the form have been approved will the form be moved on to the next stage of the process.   Users will be notified by Universal Worklist, E-mail or both.  Off-line users will continue to work with off-line forms. On-line users will work with on-line html forms.


The point for organisations to consider when introducing new UI solutions is that the mixture should be the norm. They should not design a single new process and manage all exceptions separately: the management of those exceptions is where a lot of hidden cost lies.  Designing the process first and the technology second will result in a better business fit, and greater overall process efficiencies.   I caution against selecting ‘web Dynpro’ (because that’s what we always do) or ‘SAP Fiori’ (because that is what SAP are selling us) or ‘custom app’ (because users are crying out to use their iPads).  That’s no way to start a project.

Some simple forms infrastructure, like Arch FLM, will provide the framework for easy development and management of multi-UI processes.  FLM provides common form services, such as device determination, pre-population, data validation and form routing, which can be re-used by a variety of UIs such that organisations can maintain their business logic centrally instead of replicating it to support each different UI.

When organisations adopt a multi-UI approach they future-proof their business processes from changing UIs.


Arch FLM is a SAP-endorsed business solution.

SAP-endorsed business solutions are complementary to SAP® software offerings, have been specifically integrated with SAP solutions and tested by SAP, and provide additional choices and flexibility for businesses running SAP software. SAP-endorsed business solutions are offered by SAP partners.


Filter Blog

By author:
By date:
By tag: