Skip to Content

How to realise which Adobe Forms Requirement

As there are several ways to realise customer requirements regarding Adobe Forms, this document will introduce them, compare them, show differences and limitations.

  1. Change a Cloud Solution standard form

    Independent from what of the below described changes is required it has to be decided how they shall be available. Has the standard form to be "replaced" or shall an additional be put next to it. "Replacing" the standard form by uploading a new version in Key User Tool has the advantage that regarding form determination nothing changes. This means especially in case of implicit process integrated backend output nothing has to be done to get the form changes.
    An additional language variant of a standard form is added as such and does not require any new determination handling.
    But if for some special case an additional form is needed also determining that when that special case occurs has to be considered. For more information, see “Create a Form Template Rule“ in the “Form Template Selection Quick Guide" in the documentation of the SAP cloud solution.

    Kinds of changes
    1. Change Header and Footer
      The so called Master Template is to be changed by the customer himself (Application and User Management > Busines Flexibility > Master Template Maintenance) and will be valid for all the forms in the system
    2. Change Layout
      Changing the Layout also means hiding Data or using by standard available Data differently to standard (for example creating new sums). Whatever change is possible without the need of competely new data (see C.) can be done in Key User Tool (Application and User Management > Business Flexibility > Form Template Maintenance) only.

      There you can change the layout via either Easy Form Editor or Adobe Lifecycle Designer. As the name of the first tells it's very easy to use but less powerful.
      In Easy Form Editor you can Add new fields (more likely to be used with C.), hide or even remove existing ones, change fields to be shown only if filled and change the sequence in a block of data.
      All other changes need to be done in Adobe Lifecycle Designer.

      Changes only done in Key User Tool could also be done by customer himself with a Business User. The disadvantage of this approach is, that this would need to be done in every tenant where needed.
    3. Add not by standard available Data
      If there's completely new data needed on a standard form, you have to do following two steps in the solution.
      Please be aware that this type of extension also has to be done if for example there's data in standard available but not used so far in the form and not directly usable, like Codes or UTC Date & Time, see C.
      1. Create a Business Object Extension Define the Business Logic for a Business Object Extension.
      2. Enhance the Form on the Business Object Extension, see Documentation about adding an extension field to a form This action will bring you to Key User Tool Form Template Maintenance that was already described a little before in B.
  2. Create a Customer solution own form
    Creating a solution own form means creating it from scratch based on a solution Business Object.

    For more information see Documentation about creating a print form
    Instead or additionally to just showing the PDF in Frontend you also can get it via Reuse Service OutputManagementUtilities.GetPDF for further usage.
  3. Limitations & Best practices
    • Backend Output
      Partner SDK currently only supports to create Frontend Output with Adobe Forms on Solution Business Objects, Backend Output is not supported for this so far. However, the extension of Standard Business Object Forms also includes the backend process.
    • Customer Changes to solution own forms
      ... are not supported yet. Instead every Customer requirement should be part of the solution and done in Studio. This brings again the advantage that they don't have to be repeated in every tenant the customer wants to use.
    • Code/ ID/ etc. Descriptions
      Normally Codes/ IDs etc. are stored as such only in a Business Object. The UI has mechanisms to show their description to End User to make them easier to understand.
      Unfortunately there is no such mechanism to do that mapping for forms.
      Current approach is to model the description fields as transient fields at the solution Business Object, fill them in after modify and use them in the form.
    • Data & Time
      Unfortunately the Adobe Document Server which renders the PDFs from Form Template and runtime data automatically converts Global Date & Times (stored in UTC with additional information about the Timezone to be used in an UI) into its own timezone which in the Cloud can be anywhere.
      As best practice the form's Date & Time needs to be given in the converted local Timezone (in case of Frontend Output most probably the logged in user's timezone), in case the Business Object doesn't provide this yet as an extra transient field to be filled in after modify.
    • Transient Fields from After Modify
      Transient Fields show only the up to date value in PDFs if a modify had be triggered before.