Introduction to Application Form

[vishal_sharda2]

Hi All,

I have tried to document the concept of Application Forms. The concept of Application Forms is to leverage standard SAP functionality for outgoing correspondence. More information on the same is shared as shown below.

Introduction to Application Form

Abstract: SAP has introduced the concept of Application Form which is majorly used for generating outgoing correspondence. For instance, generating a check in SAP can be achieved by creating an application form.

Transaction: The transaction to call application form in SAP system is ‘EFRM’, the interface looks like below.

An application form creation mandatorily needs the creation of the sub objects as shown in the image above. Let us try to understand the usage and significance of the sub objects.

The various sub objects needed to complete an application form are:

• Form Class
• Hierarchy
• Form
• Texts (only valid for SAP Scripts)
• User Exit Include
• User Top Include
• Generated Function Module
• Attributes

Form Class: Application forms make use of form classes to create correspondence forms. The form class primarily provides access to underlying data hierarchy, and (ii) the database for procurement of data in the form of ABAP code. Basically, the form class identifies what data will be available for the system to have it in the correspondence form. Some examples of form classes available in SAP are shown below.

This document will talk about form class ‘FI_CA_DME_CHECK’. As the description says, this form is used to generate correspondence in the form of bank checks.

Each form class has a dedicated library which contains the form routines for a form level. Form levels are the backbone of the data hierarchy, and forms the foundation for an application. In the screenshot above, FI_CA_DME_CHECK is the form class where as HEADER, ADDITIONS, POSITIONEN are the form levels. Now, both the form class and form level share the same library. However, the form class library has the following content:

• READ and GET subroutines for form for 1:n level
• READ and FILL subroutines for the 1:1 levels

Form Level with 1:n relationship

For instance, consider the form level HEADER. The form level HEADER has the following attributes:

The attributes reflect that the form level HEADER is having 1:n relationship (HEADER -> ADDITIONS/POSITIONEN). The underlying data base table is PAYH which holds the header data of the payment program. Additionally,there is a READ routine specified for this form level. If you click on, the control will be taken to the form class library where this routine is defined.

This routine has a certain piece of code which enables reading the header data when payment program is triggered.

Similarly, form level ADDITIONS has its own set of routines and structures defined.

Form Level with 1:1 relationship

The HEADER and RECEIVER have the 1:1 relationship and these are directly assigned to the form level (HEADER in this case). And as mentioned earlier, 1:1 relationships has READ subroutine and FILL subroutine. In this example, the header data in the correspondence (check in this case) will have details about the recipient of the check and the address of the recipient.

Form: the form type of an application form controls the configuration and the output of the form. Having a form is a MUST thing to create an application form. And once the selection is made from one of the following options, it cannot be changed later.

Based on what type of form is selected, the way the data should be processed is changed. For instance, if SAPScript is used for correspondence printing (check in this case), then standard texts (created via SO10) are assigned to hierarchy of the application form. Thus, the static or the dynamic data maintained in the texts is processed based on the hierarchy they are tied to.

However, incase smartforms are used as form type the relevant data is placed in the data structures when the print program is executed. So header data in this particular case will be captured in structure FICA_DME_CHECK_STR_HEADER.

Texts: The texts feature in an application form is valid only incase SAPScript is used as the form type. The texts are created via transaction SO10 and are capable of printing static as well as dynamic check. For example, following standard text can be created to display the address on the check stub.

Hierarchy: the standard texts created above are now need to be linked to the respective windows in SAPScript. Thus the linking of the standard text takes place at the hierarchy level. Based on what data should reflect what entity from the hierarchy, the linking is done.

In the above screenshot, the standard text *****SAPDOC is linked to window SAPDOC in the SAPScript.

The standard texts are linked at HEADER and ADDITIONS form level. The window in the SAPScript with which the text is linked can be viewed by clicking on .