Fiori and SAP Interactive Forms

Back in 2015 I addressed the question ‘Is SAP Interactive Forms by Adobe Dead?’, and concluded that the use cases for data capture had disappeared, but that there were many valuable scenarios for using the technology for output forms and document creation.
Since then we’ve been part of the SAP Fiori revolution, re-inventing many types of SAP interaction, both for data capture and data consumption. Surprisingly, perhaps, we continue to see the ongoing need for PDF generation across many use cases, and so the ability to easily integrate Fiori apps to output generation scenarios (both PDF and email) has become a key differentiator for us.
In this blog update I will identify four scenarios where the combination of SAP Fiori and SAP Interactive Forms by Adobe is required, and different integration approaches are used.

Of course, where organisations still use PDF for data collection – for example, in ESS/MSS or other HR processes, field sales, financials, master data management and facilities management, then the use of a Fiori app is going to be a better fit moving forwards, with few exceptions. So in general those PDF-based processes should be replaced with Fiori-based processes. With Stelo we have a fantastic tool and approach for moving from PDF to Fiori.

Replace PDF form with Fiori app

For output scenarios in which PDF remains the best choice, the challenge is to deliver the ability to generate or consume PDF documents within the Fiori app. We have encountered four types of scenario:

Trigger System Output
The simplest type of integration is where the request to trigger SAP output is performed from a Fiori app. Technically, there is a range of approaches. For example, the app might be an app for the specific purpose of triggering an output from the SAP system, or the app might save an update that subsequently triggers the output.
For example, in a field sales scenario, the sales manager might capture a new sales order via the Fiori app, and on saving the order a sales order confirmation output is generated and sent to the customer. Additionally the customer might request an account statement, which the sales manager could trigger from another Fiori app, to be generated and sent by email instantaneously.
See a demo video here

2 View PDF Documents
In some scenarios an app may be used to view pre-generated or historical PDF documents. The PDF document will physically be saved within the SAP system or in a document repository, either on premise or in the cloud.
For example, employees could be provided an app to view historical payslips, financial forms (such as P60 in the UK), or other employee correspondence such as letters of hire, promotion, benefits, annual reviews and disciplinary records. Sales managers may view customer contracts or invoices.
In this scenario, no PDF generation is taking place, but documents are being identified and presented through the Fiori app.

3 Generate Documents on Demand
In some scenarios, the Fiori app is used to generate the PDF document directly, using data captured within the app in the resulting output. In this scenario there is no SAP document like a purchase order or sales order saved to the database before the PDF document is generated, and so the solution does not rely on normal SAP document output.
Moreover, it is extremely valuable to be able to preview the output in the app. The user may review the generated output and make changes before submitting the app data, and triggering other updates or outputs to be dispatched.
There are many use cases. Using this approach we can deliver apps for Customer Agreements and Contracts, Reports and Letters (employee correspondence and external correspondence). We can add a signature pad object into the app so that documents can be signed on generation. See a demo video here. Of course we can use this to preview SAP document output too.

PDF Preview with data and signature

4 Dynamic Document Manipulation
One thing we’ve always been able to deliver with the Arch approach (with FLM and now Varo) has been to manipulate the PDF template before calling the Adobe Document Service. This means that it is easier for us to dynamically build or change PDF templates at run-time. We’ve used this in many different ways, with no visibility to the user other than a tailored, seamless process.
So within a Fiori app, we can generate a PDF document, in which not only the data is taken from data captured in the app, but also the template can be manipulated based on decisions made in the app. Any PDF object attribute can be changed, so we can dynamically show or hide, make formatting changes, sort lists, change logos, etc. There’s a big savings on the number of templates required and in the client-side scripting required, so template maintenance is much easier.
Examples of where this can be of most value include invoices for professional services – for accountants, lawyers or consultants – in order to tailor the customer invoice for particular clients or projects. Or in the creation of contracts or agreements in which different sections can be included, excluded or amended based on a mixture of selections made in the Fiori app and business logic.
Confused? See a simple demo here!

Where Stelo adds particular value is in the shared data schema architecture: data is shared automatically between the Fiori app, PDF document and any associated email. That makes integration much easier. Added to that, Arch’s long history of SAP and PDF expertise (since 2003!) means that customers can be confident that any Fiori and PDF need can be addressed.