Skip to Content

The situation

If you have ever developed PDF-based print forms on a project, you probably already faced the following issue. The blueprints for print forms are produced by business people, who choose very often to use well-known SmartForms and their corresponding interfaces.

The print workbench (TCode EFRM) allows us to create application forms, which are themselves called by applications. An application forms has the following attibutes:

  • Application form;
  • Form class;
  • Form type (SAPScript, SmartForm or PDF-based Form);
  • PDF form (defined with SFP transaction)
  • Interface

Issues

The form class, used by the print workbench, must match with the used interface, so you sometimes have to use an interface defined for SmartForms. Problem is that the predefined SmartForm-compatible interfaces cannot be used for PDF-based print forms!

Also, as PDF is newer than SmartForm technology, all SmartForms interfaces are not available for PDF print forms.

Another issue is that the PDF print forms require a specific printer driver (PDF1 – PDF ISO Latin-1), different than the one used by SmartForms, which depends on your local printer.

So, if you want your users to print directly without having to switch printer type depending on the form they choose to print (for an end-user, this can be very confusing), you have to use one type of print forms. In my case, requirement was to use PDF-based print forms.

Why?

First of all, the PDF will become the standard print forms technology for all new releases. Also, because the ADS component is by default present on the J2EE stack of the SAP WebAS, as of NetWeaver 04 SR1, which is the technology platform most commonly used on new projects involving ECC. On this project, there was only a small amount of quite simple forms to be printed (around 200 / day) so performance and sizing was not a concern.

I’m planning to write, in some new weblog, a more comprehensive comparison between SmartForms and PDF-based print forms.

Using SmartForms-compatible interfaces with PDF-print forms

In fact, it’s quite easy: the hardest part was to understand all this architecture with application forms, interfaces, forms etc.

Now, just copy the SmartForm-compatible interface you wish to use. Modify its type to ‘ABAP Dictionar-based’ interface. Save and activate.

Then, with transaction SFP, create a form specifying the interface you’ve just created.

And of course, build the layout of your form according to your business requirements.

The last step is to create an application form according to the application you need. You can typically find this information by looking in the customizing of your system. Of course, assign your newly created PDF form to this application form. And it’s done!

Hints on PDF print-forms development

For print forms, you’ll very often have to deal with dynamic tables. This element is much easier to use with LiveCycle Designer version 7.1. So, consider to upgrade before starting to build your layouts. To upgrade, simply uninstall the previous version of your Designer and install the new one, available on http://service.sap.com/swdc (perform a search on ‘Designer 7.1’). A wizard is available, allowing you to create dynamic nested tables easily.

Also with print forms, a very useful functionality is the Floating Field element. Drag and drop a static text, then, within this text, in the menu select Insert > Floating field. This automatically creates a dynamic field, which you can now bind to any value of your interface.

Of course, the Adobe LiveCycle Designer embedded in an SAP environment offers a lot more possibilities. More information with BC480 – PDF based print forms course (3 days).

Related Content

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply