print workbench pwb en 03062008

Print Workbench

AD

DO

N.

FI

CA

BF

PW

SAP Online Help 13.07.2011

Print Workbench 690 2

Copyright © Copyright 2008 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.



Icons in Body Text

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Additional icons are used in SAP Library documentation to help you identify different types of

information at a glance. For more information, see Help on Help General Information Classes and Information Classes for Business Information Warehouse on the first page of any version of SAP Library.

Typographic Conventions

Type Style Description

Example text Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options.

Cross-references to other documentation.

Example text Emphasized words or phrases in body text, graphic titles, and table titles.

EXAMPLE TEXT Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE.

Example text Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text> Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.

EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.



Print Workbench 7

Form Classes 8

Properties and Attributes 9

Form Class Library 9

Smart Form/PDF Indicator 9

Test Print Indicator 10

Object Type (BOR) 10

Document Type 10

Status 10

Package Assignment and Transport 11

Documentation 12

Hierarchy 12

Form Levels 12

1:1 levels 13

Structure Logic of the Hierarchy 14

Source Text Display of the Form Class Hierarchy 16

Form Class Library 16

Automatically Generated Variable Declarations 17

READ Subroutines 17

GET Subroutines 18

FILL Subroutines 19

Global Area for Own Variables 20

Subroutine TEST_PRINT 20

Subroutine SET_ARCHIVE_INDEX 21

Subroutine PROCESS_AFTER_DOC 22

Subroutine PROCESS_AFTER_FORM 22

Controlled Terminations in Exception Situations 23

Processing Form Classes 24

Creating Form Classes 24

Creating Form Levels 25

Creating 1:1 Levels 26

Enabling Test Prints 26

Example: Flight Notification 27

Application Forms 28

Properties and Attributes 29

Form Classes 29

Form Types 29

SAPscript Form/Smart Form /PDF-Based Form 30

User Includes 30



Start/End Exit 31

Optional Static User Exits in Generated Print Program 31

Generated Modules 32

Languages 33

Status 34

The Hierarchy of an Application Form 34

Form Levels 36

1:1 levels 36

Texts (SAPscript Only) 36

Flow Logic and Processing Definition of the Hierarchy 37

Interaction of Application Forms with SAPscript Forms, Smart Forms, PDF-Based Forms 37

Access to Data Read 38

Control Variable C 39

Processing Application Forms 41

Creating Application Forms 42

Inserting Variables in Texts (SAPscript Only) 42

Creating a Summation 43

Reading Additional Data from the Database 44

Dynamic Intervention in the Process Flow in User Exits 44

Transferring Own Data to a Smart Form or PDF-Based Form 45

Optimizing Performance 45

User Exits in Application Forms 46

Declaration of Own Data Areas 47

Exit Before Loop 47

Exit During Loop 48

Exit After loop 49

Text Exit (SAPscript only) 50

Start/End Exit 50

Triggering Controlled Terminations 50

Utilities 51

Test Print 51

Breakpoints and Debugging 52

Copying from Clients 52

Uploading and Downloading Application Forms 53

Creating Links 54

Finding Variables 54

Form Information 55

Administration and Transport 55

Mass Processing 55



Mass Activation 56

Transporting Application Forms 57

Using References 58

Versioning and Archiving via Upload/Download 58

Translating Application Forms 59

Worklist 59

Creating Worklists 63

Processing Worklists 63

Collection 64

Process Flow of Collections 65

Variable C 67

Dynamic Modifications in the Process Flow 68

Interaction between Application Forms and Collections 69

Send Type e-mail 69

Data Type EFG_TAB_GENDATA 69

Data Type EFG_TABN_SEL_PER_FCLASS 70

Calling Form Printing in ABAP Programs 70

Module EFG_PRINT 71

Module EFG_PRINT_EXPANDED 72

Print Parameter Structure EPRINTPARAMS 73

Print Parameter Dialog EFG_GET_PRINT_PARAMETERS 76

Initializing and Closing Print Transactions 77

Open/Close Optimization 78

Printing Processes and Printing Scenarios 79

Further Processing of Data in External Systems 80

Archiving/Connection to ArchiveLink 81

Sending as e-mail or Telefax via SAPconnect 82

Send Control 84

Flexible Control and Modification of Print Parameters 85

Using the Print Workbench with Correspondence (CA-GTF-COR) 85

Using Print Action Records 86

Print Action Records (Technical Background) 87

Function Modules for Programming 88

Customizing 88

Individual Creation of Print Action Records 89

Mass Creation of Print Action Records 89

Reorganization 90

Integrating Print Action Records in Application Forms 90



Print Workbench

Purpose

The Print Workbench is a central development environment for creating standardized outgoing correspondence. To configure the forms, the Print Workbench uses the SAP standard components for configuring forms – SAPscript, Smart Forms, and PDF-based forms.

The Print Workbench is subdivided into the following subobjects:

● Form classes Form classes are defined by SAP applications and contain a modeling as well as access instructions for all of the data that belongs to an application or an application process. You can use form classes to create application forms where you access the data defined in the form classes. Invoices, dunning notices, and account statements are examples of form classes. The form classes are delivered with each application component that uses the Print Workbench. Changes to form classes delivered have modification status.

● Application forms You create application forms based on the form classes delivered. You can define several application forms for each form class, for example, different invoices for different business partner groups. SAP delivers example forms that you can use as a reference for your own application forms. You can use user exits to adjust the application forms to your requirements. Numerous help functions simplify form creation.

You can call up the Print Workbench via the area menu PWB.

Integration

The Print Workbench (CA-GTF-PWB) is a component of SAP Web Application Server and it can be used with no further prerequisites by every other SAP application. In the Print Workbench you can use Smart Forms (BC-SRV-SSF), SAPscript (BC-SRV-SCR), or PDF-based forms (BC-SRV-FP) alternatively.

Architecture of the Print Workbench



Generated function module(Print program) sel ect data from

database, integrates SAPscript,

SAP Smart For ms API

Form class librar y

(ABAP Report)

Data hierarchy

Form class

Application with

correspondence request

SAP

SAP

Smart Forms SAPscript

Application form

Hierarchical display

of processing logic

►(De)selection/adjus tment of data

procurement

► Selection of additional data using ABAP user exits

► Packaging of texts (only

SAPscript)

► Form type controls processing usi ng SAPscript, Smart Forms or

PDF-based for ms

SAP Customer

delivers

creates

Data model(/hierarchy)Data struc tures

Access coding

Call at runtime

(EFG_PRINT)PDF-based

forms

Form Classes

Definition

The form class is an application-specific object that contains both the underlying data hierarchy for the application and the database access required for data procurement in the form of ABAP/4 coding. When creating the data hierarchy, particular emphasis was given to a logical view of the data model. Therefore, the form classes are comparable to logical databases. In contrast to logical databases however, they have the advantage that they can swap two equal levels and duplicate a level in application forms.

Use

Form classes are used by application forms to create forms, that is, correspondence.

Structure

A form class consists of a hierarchy representing a logical view of the data model for each application or an application process. The related Form Class Library contains access instructions in the form of ABAP subroutines. Further controlling properties are defined in the Attributes of a form class.



Integration

Form classes are a fixed component of an application and cannot be changed or replaced. Form classes are usually independent of the use of the data and particularly of the category of the application form.

Properties and Attributes

Definition

The attributes of a form class contain controlling information that is important for further processing, for example, in application forms.

Structure

The attributes of a form class contain the following fields:

● Form Class Library [Seite 16]

● Smart Form/PDF Indicator [Seite 9]

● Test Print Indicator [Seite 10]

● Object Type (BOR) [Seite 10]

● Document Type [Seite 10]

● Status [Seite 10]

● Assigned Package [Seite 11]

● Documentation [Seite 12]

Form Class Library

Definition

For each form class you have to define a form class library [Seite 16]. It contains the access commands for the form levels and 1:1 levels declared in the hierarchy. From a technical view, the form class library is an ABAP report.

Smart Form/PDF Indicator

Definition

The Smart Form/PDF indicator shows whether a form class is designed for using Smart Forms or PDF-based forms. If the indicator is set for a form class, generated DDIC types are assigned to each form level by the Print Workbench. These reflect the hierarchy of the form class and are responsible for transporting data from the application form to the Smart Form or PDF-based form. If the indicator is not set, you cannot use the form class for Smart Forms or PDF-based forms.



Test Print Indicator

Definition

By setting the indicator Test Print, you can suppress the test print in the maintenance of an application form for an application. However, you should only suppress the test print in documented exception cases, since the test print is an important tool for developing forms and for error analysis.

Object Type (BOR)

Structure

A <BOR object type> can be assigned to a form class. This specification is optional and creates a logical link between the data hierarchy and a BOR object type in the system. It is used for information purposes and test printing, since when you determine the initial object key for the test print, the FIND method of the object type entered is called. The object key thus determined is interpreted as hierarchy access and transferred for further processing as the first entry in the first ranges table of the module EFG_PRINT [Seite 71].

The BOR object type specified is used as link object in archiving with SAP ArchiveLink. If no BOR object type is specified, or none is suitable, the dialog for the test print can also be carried out via a form routine in the form class library by the application.

Document Type

Definition

The specified document type is optional and provides information about which document type is used for archiving documents of the form class.

Status

Definition

The status of a form class indicates the completeness, correctness, and usability of a form class with regard to use in application forms. The following objects and object statuses are considered and checked:

● The relevant form class library exists and is syntactically correct with regard to ABAP.

● For all form levels or 1:1 levels of the form class, the obligatory READ and GET/FILL subroutines exist in the form class library.

● The DDIC structures assigned to a form level or 1:1 level are active.



● If the Smart Form/PDF [Seite 9] indicator is set in the form class, the system also checks whether all generated DDIC types specified in the form levels existand have the structure derived from the form class.

The possible statuses are:

● Inactive

● Incorrect

● Active

In the message log, you can see the details of the status for the form class check.

Use

The status of a form class is relevant for:

● Processing and activating application forms for a form class

● Transporting form classes

The actions are terminated if the form class does not have the status Active.

Package Assignment and Transport

Use

During creation you have to assign a form class, such as an ABAP program, to a package; the package controls the assignment and the transport. You can change the object catalog entry that arises for the form class later. For each change to a form class, after a transport request the system checks whether there is an entry for the form class in an open transport request. The referenced subobjects of a form class (form class library, generated DDIC types) are transported via separate transport objects and each have separate package assignments.

Integration

Form classes are transported in the correction and transport system using the transport object EFCL.

Prerequisites

To transport a form class it must be assigned to a transportable package. If a form class was created locally, that is, in package $TMP, you have to change the package assignment of the form class before the transport. The system checks whether all referenced subobjects of a form class belong to the same package as the form class itself. If this condition is not fulfilled, the system issues warning messages. If subobjects were referenced in a transportable form class, and these subobjects are assigned to a local package ($*), the system issues corresponding error messages and the form class concerned is not transported.



Documentation

Use

In the documentation of a form class you can define information about the data hierarchy and other special features of the form class.

Integration

The documentation of the form class is defined as General Text in the system and you can access it via the form class.

Hierarchy

Definition

You use the hierarchy of a form class to display and model the data of an application or process. All of the form levels together, that is, all nodes of the hierarchy, reflect the maximum quantity of data that an application supports for use in forms as standard.

Use

You transfer the hierarchy of a form class to the application forms. There you can configure the form as required. Using defined data areas, you can transfer the data declared in the form class to a form.

Structure

The hierarchy consists of two node elements: The form levels and the 1:1 levels. Each form level and 1:1 level represent a data structure that is dependent on data that is higher in the hierarchy in accordance with its hierarchical position. The individual fields of a form level or 1:1 level are defined by an assigned DDIC structure. For each level there are subroutines (ABAP form routines) in the form class library that carry out encapsulated data selections in the relevant tables of the database.

The following figure shows the hierarchy of a form class using the standard example delivered, PWB_FLIGHT_NOTIFICATION.

Integration

The hierarchy is a major component of a form class. The fixed assignment of the form class in an application form means that the hierarchy defined in the form class is always the template for the hierarchy in the application form and is always compared to it.

Form Levels

Definition

The form levels make up the main part of a form class. A form level represents an entity in the data model of the respective application, for example, account or business partner. The form levels are related to each other in a 1:n relationship. This means that for each entry belonging to a particular form level, there are n entries in the form level below it in the hierarchy. The form levels define the basic framework of a form class and data is added using the 1:1 levels.



Use

In application forms, form levels are used to select the data belonging to the form level. The data selected is placed in global data areas and can be accessed in application forms, for example, in texts. Since form levels represent a 1:n relationship between data, the execution of a data loop is always connected to a form level. Global data areas are derived from the name of the form level (WA_<name of form level>); the data is temporarily stored in these areas.

Structure

The attributes of a form level contain the following information:

● Name of the form level

● Assigned DDIC output structure or DDIC table

● Short name

● Name of the DDIC structure or table type generated if Smart Forms are active in the form class

For each form level there are exactly two ABAP subprograms in the form class library:

● READ subprogram The READ subprogram procures the initial data and is called up once at the start of form processing. The READ subprograms of a form class are called up in the application form in the order in which the related form levels exist in the hierarchy.

● GET subprogram There is one GET subprogram for each form level. This GET subprogram procures the n data records of the relevant form level dependent on the current data record of the next highest form level so that this can also be processed. When you use the subprogram types, you can choose between the following strategies:

○ All the data for a form level is procured in the relevant READ subprogram and defined in the global table. The GET subprogram extracts the n data records required for the current run from the global table.

○ The affiliated READ subroutine is empty. In the GET subprogram you procure the current data for the form level from the database directly or from other filled data buffers.

When you are developing a form class, you have to decide which strategy to use based on the data constellation and program design. With regard to performance, you should make sure that GET subprograms can be called up more than once in an application form; this means that data buffering is strongly recommended.

1:1 levels

Definition

The 1:1 levels are directly assigned to the form levels. They have a unique and direct relationship (1:1) to their affiliated form level. Typical examples for 1:1 levels are the long texts (explanatory texts) for each of the entities. A 1:1 level is dependent on the form levels to which it is assigned since the selection criteria for access to the database are in the data already imported for the superordinate form level. Form levels and 1:1 levels represent a logical or business entity.



The name of a 1:1 level and the DDIC structure below it is defined in the corresponding form class and cannot be changed.

Structure Logic of the Hierarchy

Use

The hierarchy of the form class is the tool used to model the dependencies of the data areas and the structure logic for the print transaction. The structure logic cannot be used in the form class itself. There must always be an application form for this.

Features

The system processes the form level according to the following principle: ...

1. The current form level entry is imported

2. Data from the appropriate 1:1 levels is imported

3. The complex data type is filled for Smart Forms.

4. The hierarchically subordinate form levels are processed.

Using this process definition, the hierarchy tree is processed recursively from top to bottom. In the application form, you can, for example, insert additional events (for example, printing a text or calling a user exit) between events 2) and 3) and between 3) and 4). In each run, the relevant data for the levels is placed in the global work areas (WA_<name of form level>) of the form class; these can then be accessed in texts or user exists in the application forms. The highest form level (also called document level) is very important; each entry for this level equates to a document.

Example

The process logic is described in more detail using the example PWB_FLIGHT_NOTIFICATION.



The customer (CUSTOMER, table SCUSTOM) and his postings (BOOKING, table SBOOK) represent two form levels. They have a 1:n relationship since one customer can have several postings. There is a 1:1 level posting (FLIGHT, table SPFLI) for a posting that contains additional information about the unique flight of the posting. This hierarchy is processed as follows: ...

1. All customers fulfilling the initial selection criteria are imported and placed in an internal table (T_CUSTOMER). The number of entries in this table is identical to the number of documents created later.

2. A customer is read from the internal table and archived in the global work area of the form level (WA_CUSTOMER). At the same time, a new document is opened.

3. Since the form level CUSTOMER has no 1:1 levels, the processing of the relevant form levels continues. Processing of the form level BOOKING begins. All bookings for the current customer are imported and placed in an internal table.

4. The flight belonging to the current flight booking is read and placed in the work area WA_FLIGHT.

5. Since the form level has no further dependent form levels or 1:1 levels, the processing of the next posting continues.

6. If all postings have been processed for the current customer, the processing of the form level BOOKING for the current customer is completed. The document is completed and the processing returns to processing step 2.

This flow logic can be expanded to any number of form levels. You can also process the same form levels several times running in application forms. This means the same form levels can appear several times running in the hierarchy. This is necessary, for example, if you want to access the same data in different sections of the form. In application forms, further events (for example, printing a text or calling a user exit) are added to this hierarchy.



Source Text Display of the Form Class Hierarchy

Use

The source text display enables you to display the processing in a hierarchy in the way it appears later in the generated print program of an application form. In particular, the dependencies of the different levels and call events of the subprograms are visible.

This tool enables you to understand the print processes and you can use it for developing form classes and for implementing application forms.

Features

All of the parts of a generated print program are displayed schematically:

● Global data declarations

● READ subprogram call

● Start/end of document

● The calls of the GET subprograms recursively integrated in the data loops

In the list you can double-click in the displayed subprograms and variables to navigate from the form class library.

Form Class Library

Definition

The form class library is an ABAP/4 program. Each form class has its own library. The name of the program is defined in the attributes of the form class.

Structure

A form class library has the following content:

● READ and GET subroutines for the form levels

● READ and FILL subroutines for the 1:1 levels

● Other subroutines

● Area for own data declarations to be transferred to print program

● Generated data declaration area (cannot be changed)

For technical reasons - for example in order to be able to ensure a correct syntax check - the form class library has the status of an ABAP/4 (Online) program. However, the program does not contain any functions that you can run.

When you generate a print program, the form class library copies all subprograms into the print program. In addition, the area with its own global data declarations is also copied. The generated data declaration area is not transferred, it is regenerated in the print program.



Automatically Generated Variable Declarations

Use

With each form level or 1:1 level, a global work area and a global internal ABAP/4 table are defined. Both have the DDIC table structure that is defined in the attributes for the level. The naming of the global work area follows the convention WA_<level name>, the internal table T_<level name>. For the subsequent print process, the work areas are particularly important. They represent relevant data interfaces used, for example, in SAPscript texts for a user. The total of all global work areas represents the maximum data list for an application form.

In application forms, you can use global data areas (WA_*) that are at the same hierarchical level or higher. 1:1 levels are at the same hierarchical level as the related form level. The applications are responsible for initializing the generated data areas. Since the generated print programs consist of function groups, data is retained, particularly for multiple calls.

Integration

The data declarations are generated by the Print Workbench automatically in a data area defined for this purpose. They are update with every change in the form class hierarchy.

Example

Source text of the form class PWB_FLIGHT_NOTIFICATION

*§**********************************************************************

*****THE FOLLOWING CODE IS GENERATED, NEVER CHANGE IT MANUALLY**********

**DATA ONLY FOR SYNTAX-CHECK, WILL NOT BE TRANSFERED TO PRINT PROGRAMS**

************************************************************************

…

*******************global table declarations****************************

DATA: T_CUSTOMER TYPE TABLE OF SCUSTOM

WITH HEADER LINE.

DATA: T_BOOKING TYPE TABLE OF SBOOK

WITH HEADER LINE.

DATA: T_FLIGHT TYPE TABLE OF SPFLI

WITH HEADER LINE.

*******************global workarea declarations*************************

DATA: WA_CUSTOMER TYPE SCUSTOM .

DATA: WA_BOOKING TYPE SBOOK .

DATA: WA_FLIGHT TYPE SPFLI .

*§*end*******END-OF-GENERATED-CODE**************************************

READ Subroutines

Use

A READ subroutine exists for each hierarchy level of a form class. This READ subroutine is used for reading the data from the database. It is executed just once at the beginning of the print program.



In addition to the READ subroutine, the GET/FILL subroutines can also be used for reading data from the database.

GET Subroutines

Definition

With the exception of the document level, exactly one GET subroutine belongs to each form level. The name of the GET subroutine is composed of the prefix GET, the name of the next highest form level, and the name of the form level itself. READ subroutines are at the start of a print program, and called up once only; the calls of the GET subroutines are dependent on the hierarchy in the application form.

Use

GET subroutines are used to procure the n data records for a form level dependent on the data of the next highest form level. The n data records determined are processed sequentially in the generated print program. You can follow two strategies.

● All the data for a form level is obtained in the relevant READ subroutine and defined in the global table. During the call, the GET subroutine then extracts the data records from the table that belong to the current entry of the next highest form level.

● The affiliated READ subroutine is empty. In the GET subroutine you procure the current data for the form level from the database directly or from other application-defined data buffers.

When you are developing a form class, you have to decide which strategy to use based on the data constellation and program design.

Structure

The interface of a GET subroutine contains the variables that are set as prerequisite or result for the call in by the Print Workbench in accordance with their hierarchical position. Within the READ subroutine however, you can use all global data areas (<T_*> or <WA_*>) of the same form level or all form levels higher in the hierarchy. There is no GET subroutine for the document level as loop of the hierarchy.

Integration The GET subroutines are then called in the generated print program of an application form if a form level is to be processed according to the hierarchy of an application form. The data records received are then processed sequentially. The GET subprograms are copied to the print program when you activate an application form.

Example

The source text of the GET subroutine of the form level FLIGHT is as follows. Since the posting data is read from the database in the READ subroutine, you only have to extract data from the internal global table T_BOOKING.

*&---------------------------------------------------------------------*

*& Form get_form GET_CUSTOMER_BOOKING

*&---------------------------------------------------------------------*

FORM get_customer_booking

TABLES

yt_booking STRUCTURE sbook



USING

x_customer TYPE scustom.

REFRESH yt_booking.

LOOP AT t_booking WHERE customid = x_customer-id.

APPEND t_booking TO yt_booking.

ENDLOOP.

ENDFORM. "GET_CUSTOMER_BOOKING

FILL Subroutines

&DEFINITION&

There is exactly one FILL subroutine for each 1:1 level. The name of the FILL subprogram is composed of the prefix FILL, the name of the relevant form level, and the name of the 1:1 level. READ subprograms are at the start of a print program, and called up once only, the calls of the FILL subprograms are dependent on the hierarchy in the application form.

Use

There is exactly one FILL subroutine for each 1:1 level. This FILL subprogram provides the relevant 1:1 level data for the current data record of the relevant form level. Just as with the GET subprograms, you can also follow both of the strategies described above for the data procurement for FILL subprograms.

Structure

The interface of a FILL subprogram contains the variables that are set as prerequisite or result for the call in by the Print workbench accordance with their hierarchical position. Within the READ subprogram however, you can use all global data areas (<T_*> or <WA_*>) of the same form level or all form levels higher in the hierarchy. If 1:1 levels are beneath one another hierarchically, you can also use the global variables of the 1:1 level higher in the hierarchy.

Integration The FILL subprograms are then called in the generated print program of an application form if the related form level is processed, that is, if the data records belonging to the form level are processed sequentially. The FILL subprograms return the data record of the 1:1 level belonging to the current run. The FILL subprograms are copied to the print program when you activate an application form.

Example

The source text of the FILL subprogram of the 1:1 level FLIGHT is as follows. Since the posting data is read from the database in the READ subprogram, you only have to extract data from the internal global table T_FLIGHT.

*&---------------------------------------------------------------------*

*& Form fill_form FILL_BOOKING_FLIGHT

*&---------------------------------------------------------------------*

FORM fill_booking_flight

USING x_booking TYPE sbook

y_flight TYPE spfli .

CLEAR y_flight.

READ TABLE t_flight INTO y_flight WITH KEY

carrid = x_booking-carrid



connid = x_booking-connid.

ENDFORM. " FILL_BOOKING_FLIGHT

Global Area for Own Variables

Definition

If an application requires its own global instructions (for example, include, data, type pools), you have to define the corresponding instructions in a specific area of the form class library. The area has unique limit characters and relevant comments. The comments are generated by the Print Workbench during creation of the form classes.

Use

The instructions defined for an application form in the TOP area are copied to the corresponding TOP include of the function group when the print program is generated. This means that the instructions are valid for all subroutines.

Structure

The TOP area is restricted by the following comment lines in the form class library:

*&**********************************************************************

***The following code WILL be transported to print programs*************

*************PUT HERE YOUR OWN GLOBAL DATA******************************

*type-pools .... " own type-pools

*data: .... " own global data

*&*end******END-OF-OWN-GLOBAL-DATA**************************************

Do not change the restricting comment lines generated for the TOP area of the form class library.

Subroutine TEST_PRINT

Use

You can use the test print with real data for checks during form development and maintenance and for the analysis of errors during data procurement of the form class. The test print is only possible if the form class supports it. This means if:

● A BOR object type is specified in the form class and the object key of this BOR object type is queried via the FIND method and then inserted in to the first line of the ranges table of the module EFG_PRINT. The READ subroutine of the document level must be able to process this information.

● The application implements the subroutine TEST_PRINT and specifies the input parameter for the module EFG_PRINT in the subroutine (for example, via own value queries).

The implementation of the subroutine is optional; however, you cannot change the frame generated.

Integration

The subroutine TEST_PRINT is called up from an application form for a test print.



Activities

Implement a dialog to determine an object key and place this in the ranges tables transferred such that you can use this information for the selection of relevant data in the READ subroutine of the document level.

When you have implemented the subroutine, set the export parameter y_found to X. If there

is a termination by the user, set the indicator y_cancelled to X.

Example *&---------------------------------------------------------------------*

*& Form Testprint (Optional) *

*&---------------------------------------------------------------------*

FORM test_print

TABLES

yt_ranges STRUCTURE efg_ranges

yt_ranges1 STRUCTURE efg_ranges









USING

y_found LIKE rfgen-kennzx

y_cancelled LIKE rfgen-kennzx.

***always set this !

y_found = 'X' .

CLEAR y_cancelled .

REFRESH yt_ranges .

***dialog for completion of ranges tables

ENDFORM.

Subroutine SET_ARCHIVE_INDEX

Use

The subroutine SET_ARCHIVE_INDEX sets the ID relevant for the archiving system. This has the same importance as the object key of the BOR object type used for archiving. The implementation of the subroutine is optional; however, you cannot change the frame generated. If you always call up the Print Workbench once for each document, you can specify the complete archive parameters when you call up the module EFG_PRINT. The subroutine is called up in the generated module of an application form just before the processing of a document.



Activities

In the global variable c-archive_index-object_id, set the archive index to the value of the object key of the BOR object. The global data areas (WA_*) of the document level are filled in this event.

Example *&---------------------------------------------------------------------*

*& Form set_archive_index (OPTIONAL, leave frame untouched !!!) *

*&---------------------------------------------------------------------*

FORM set_archive_index .

*** c-archive_index-object_id = wa_....

ENDFORM. "SET_ARCHIVE_INDEX

Subroutine PROCESS_AFTER_DOC

Use

The subroutine PROCESS_AFTER_DOC is designed for carrying out an application-specific activity after a single document has been processed. The implementation of the subroutine is optional; however, you cannot change the frame generated. The subroutine is called up in the generated module of an application form just after the processing of an individual document.

Activities

Implement the application-specific activities for the event specified above.

Example *&---------------------------------------------------------------------*

*& Form process_after_doc (OPTIONAL, leave frame untouched !!!) *

*&---------------------------------------------------------------------*

FORM process_after_doc.

* do something

ENDFORM. "PROCESS_AFTER_DOC

Subroutine PROCESS_AFTER_FORM

Use

The subroutine PROCESS_AFTER_FORM is designed for carrying out an application-specific activity after the application form has been processed. The implementation of the subroutine is optional; however, you cannot change the frame generated. It is called in the generated print program for the application form. At the time of the call, all data and form levels of the application form have been processed.

Activities

Implement the application-specific activities for the event specified above.



Example *&---------------------------------------------------------------------*

*& Form process_after_form (OPTIONAL, leave frame untouched !!!) *

*&---------------------------------------------------------------------*

FORM process_after_form.

*do something

ENDFORM. "PROCESS_AFTER_FORM

Controlled Terminations in Exception Situations

Use

In the subroutines of the form class library exception situations may occur (for example, unexpected data inconsistencies), where the printing of a form must be subject to a controlled termination. Controlled means that before leaving the print module, the open form process is closed so that the next document can be printed in the mass run.

Prerequisites

To terminate the print transaction, use only one of the two macros. All other message activities could disrupt the global print process.

Procedure

If you want to terminate the print transaction of an (application) form, call one of the following macros:

● MAC_PRINT_CANCEL In MAC_PRINT_CANCEL the error parameters are transferred in the macro parameters 1 to 7:

○ &1 – Message type (for example, E )

○ &2 – Message number (for example, 100)

○ &3 – Message class (for example, EZ)

○ &4 to &7 – Message parameters 1 to 4

● MAC_PRINT_CANCEL_REPEAT If a module called has triggered an exception in a subroutine with the macro MAC_MSG_PUTX, you can forward the corresponding message with the macro MAC_PRINT_CANCEL_REPEAT. The only parameter you have to specify here is the message type.

Terminations within GET or FILL subroutines end with the printing of the current form, but do not delete the texts printed in the form up to this point in the spool. Therefore, checks, such as for data consistency, should always be completed before a text is issued.

Example CALL FUNCTION ..’ABCDE’

EXPORTING

…

IMPORTING



…

EXCEPTIONS

NOT_FOUND = 1

OTHERS = 2.

IF SY-SUBRC NE 0.

MAC_MSG_PRINT_CANCEL

‘E’ SY-MSGNO SY-MSGID SY-MSGID SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

Processing Form Classes

Purpose

Creating and processing form classes

Prerequisites

To process a form class you have to

● Know the processes of the Print Workbench

● Have good ABAP programming knowledge

● Know the data model of the underlying application

● Have reconciled the data mode to the requirements of a document

Process Flow

Due to constant further development of the related application, form classes are themselves constantly developing. Once a form class has been created, it should be applied and tested using your application forms. Since form classes represent interfaces, you should avoid changes to the form class hierarchy or the assigned structures, or at least check them precisely since incompatible change could invalidate productive application forms.

Result

If a form class has the status Active, you can use it for developing application forms.

Creating Form Classes

Use

You create a form class if you want to create standardized correspondence for an application or a process.

Procedure ...

1. In the menu choose Print Workbench Form Class Process (EFCS). Specify a

name for the new form class and choose Form Class Create.

2. In the following dialog box, specify the name of the new form class library (ABAP program) and a short text. If you also want to define the form class for using Smart



Forms or PDF-based forms (recommended) set the indicator Smart Forms/PDF. You can output the remaining fields later if required.

3. Choose Continue.

4. In the subsequent dialog box, choose a package for the form class. If you initially do not want to transport the form class, you can also select the package $TMP (= local object) and reassign the form class later if necessary. If you want to use a transportable package, enter a transport request in the dialog box.

Result

The form class has been created. However, it does not have any form levels or a form class library. You now have to create form levels, 1:1 levels, and the related subprograms together with the form class library.

Creating Form Levels

Use

You create form levels to add structures to the dataset of a form class; these structures are in a 1:n relationship to existing form levels.

Prerequisites

Form levels are in a 1:n relationship to another. This relationship should always agree with the actual relationship in the data model – otherwise the hierarchy has a design error that has a negative effect on the use in application forms and the enhancement of the form class. This means that for n=1, you should use 1:1 levels.

Procedure ...

1. In the Print Workbench menu choose Form Class Process.

2. If form levels exist, place the cursor on an existing form level.

3. Choose Edit Create Lower Level or Edit Create Same Level depending on the hierarchical relationship of the new form level.

4. In the following dialog box, enter a maximum ten character name for the form level and if necessary, choose the node type Form Level. The name of the form level is binding and unique within a form class and should be fitting. Enter a short text and the output structure. If the indicator Smart Forms is set in the attributes of the form class, also enter the name of the generated structure and the generated table type.

5. Choose Continue.

The new form level is inserted into the hierarchy. Create the related READ and GET

subprograms by selecting the symbols R and G in the hierarchy. If the form class library has

not been created yet, the program is created automatically by the Print Workbench. In the READ or GET form routines, implement the coding for procuring the relevant data for the form level. In the READ subprogram you can first read all the relevant data and can only fill the relevant subareas in the required internal table in the GET subprogram. Alternatively, you can procure all the relevant data in the GET subprogram. Note that you can call the GET subprograms several times. You should therefore buffer to reduce the effect on performance.

You are responsible for initializing the global data area <WA_*>. Since the generated programs are function groups, the values in the global data areas are retained if you call a form or form routine again.



Result

You have created a form level and implemented the relevant data procurement in the relevant subprograms of the form class library. You can now include the form level in an application form and test that the subprograms work correctly. You can create additional form levels or 1:1 levels for the form level.

Creating 1:1 Levels

Use

You create 1:1 levels to add to the data list for a form level.

Prerequisites

The data must be in a 1:1 relationship to the data of the relevant form level.

Procedure ...

1. Place the cursor on a form level or a 1:1 level if the new 1:1 level is dependent on

another 1:1 level. To do this, choose Edit Create Lower Level or Edit Create Same Level.

2. Assign a new maximum ten character name for the new 1:1 level. The name of the form level is binding and unique within a form class and should be fitting. Choose 1:1 level as node type and specify the output structure. The output structure must be a DDIC table or structure. Specify a name for the 1:1 level.

3. Choose Continue.

The new 1:1 level is inserted into the hierarchy at the relevant point. Create the related READ

and FILL subprograms by selecting the symbols R and F in the hierarchy. If the form class

library has not been created yet, the Print Workbench creates the program automatically. In the READ or FILL subprograms, implement the coding for procuring the relevant data for the 1:1 level. In the READ subprogram you can first read all the relevant data and can only fill the relevant subareas in the required internal table in the FILL subprogram. Alternatively, you can procure all the relevant data in the FILL subprogram. Note that you can call the FILL subprograms more than once and should therefore buffer so that you do not affect performance.

Result

You have created a 1:1 level and implemented the relevant data procurement in the relevant subprograms of the form class library. You can now include the 1:1 level in an application form and test that the subprograms work correctly.

Enabling Test Prints

Use

You can use the test print in the application form for development and later for the error analyses in the application form or the form class. In particular, you can specifically use actual data from the system without having to create a time-consuming test case with integration in an application process. You should therefore configure each form class accordingly.



Procedure

To enable the test print, you have the following options: ...

1. In the attributes of a form class, specify a BOR object type. At the time of the test print, the Print Workbench uses the FIND method of the object type to determine an object key that is inserted in the first line of the RANGES table transferred to the application form. The form class (or the data procurement in its library) must be able to process this.

2. Implement the subroutine TEST_PRINT [Seite 51] in the form class library such that it corresponds to the dialog for determining the initial object of the form class. As return parameter the Print Workbench expects the RANGES tables transferred to the application form.

Result

You can carry out a test print of application forms for a form class.

Example: Flight Notification

This is an example of the structure of a typical form class using the example of the form class Flight Notification.

Form class: flight notification

PWB_FLIGHT_NOTIFICATION Confirmation for flight bookings

Customer

Booking

Flight

Customer

Booking

Flight

Form Levels

1:1 Level

This particular form class is attached to the CUSTOMER form level. Form classes are also frequently attached to a document (for example, invoice document). All flight bookings for one customer are shown on the BOOKING form level. Since a customer can have several bookings, this form level is below the level CUSTOMER in the hierarchy. The CUSTOMER and BOOKING form levels are in a 1:n relationship to one another. Additional flight details are stored in the flight that is assigned to a flight booking. The flight assigned to a flight booking is represented by the 1:1 FLIGHT level. All 1:1 levels are placed in the hierarchy beneath the associated form levels and can be displayed or hidden by clicking on them.



Application Forms

Definition

Application forms are configuration objects and integrate the data structure defined in the relevant form class, data procurement, the form logic you have determined, and the form layout. You can determine the form and scope of the data procurement as required and add your own data using user exits. You can also choose between the basic tools for creating the form layout – Smart Form, SAPscript form, or PDF-based form. The form class assigned to an application form determines the structure of the data delivered by SAP. When you create an application form, you have to specify the form class. Afterwards, you can no longer change the form class.

Use

If standardized correspondence is to be created from an application process, you have to configure application forms. If the application uses the Print Workbench as configuration tool, this provides a form class that you have to set as attribute in the application form.

Structure

The application form consists of:

● Properties/attributes

● Hierarchy

● Form (SAPscript, Smart Form, or PDF-based)

● SAPscript texts (SAPscript)

● User exit includes

● User top includes

● Generated print program

The core of an application form is the hierarchy. This has a similar function to the form class, but is extended. In the context of application forms, the form levels represent events in the flow logic of the form. In the events you can define further activities, such as the call of a user exit or, in the case of SAPscript, the call of texts. The status of the application form provides information about whether the application form has no errors and can be run and whether the generated print program is up-to-date with regard to the application form and its subcomponents.

Integration

An application form is closely linked with the related form class and integrates the data model and the related data procurement of the application with the requirements of the SAP customer. The generated print program integrates:

● The SAP application

● Customer-defined configurations and implementations of user exits

● Calls of the components SAPscript, Smart Form, and PDF-Based Forms.

Application forms are usually defined in Customizing tables or master data in the application. An application form is printed by calling the module EFT_PRINT that then calls the generated module for the application form.



Properties and Attributes

Definition

The attributes of an application form contain all the relevant, static settings, that is, they are independent of the hierarchy and form levels.

Form Classes

Definition

The form class of an application form contains the data hierarchy and the relevant access coding that belongs to an application for creating a form. The form classes are delivered by the applications.

Use

Form classes are used in application forms.

Form Types

Definition

The form type of an application form controls the configuration and output of a form. This setting is obligatory and cannot be changed once you have created the application form.

Use

The following form types are possible:

● SAPscript

● Smart Form

● PDF-based form

● Collection

Depending on the form type, different functions and options are offered for the form processing and form printing. In the case of SAPscript, texts are assigned to the hierarchy of an application form; depending on their position in the hierarchy they can be processed or printed. In the case of Smart Forms and PDF-based forms, data is placed in the generated data structures and transferred to the Smart Form assigned. The names of these data structures are defined in the form levels of the form class. A collection is a grouping of different application forms that are printed or output combined sequentially per call from the application (for example, in the form of an e-mail with attachment).



SAPscript Form/Smart Form /PDF-Based Form

Definition

Depending on the form type, either a Smart Form, a SAPscript form, or a PDF-based form is defined in the attributes of an application form. The form contains all relevant layout information (for example, pages, windows, paragraph formats) for preparation of the form to be printed.

Use

The application form and the related SAPscript, Smart Form, or PDF-based form are reconciled with one another during the print transaction. The application form controls the print transaction. This means that the data is read and the program interfaces of the layout tool are called for the events defined. The interfaces between the application form and the form used depend on the type of form and must be reconciled with one another.

● SAPscript

○ Window (used in the attributes for text nodes)

○ Form level symbols (WA_*) used in texts

● Smart Forms and PDF-based forms Name- and type-justified interface parameters for transferring the selected data:

○ PWB_DATA or the name of the generated DDIC type at document level

○ Data declarations in user top includes

For detailed information about SAPscript, Smart Forms, and PDF-based forms, see SAP Help

Portal at help.sap.com Documentation SAP NetWeaver SAP NetWeaver

Release/Language SAP NetWeaver Application Platform (SAP Web Application Server)

Business Services PDF-Based Forms, SAP Smart Forms, SAPscript (BC-SRV-SCR).

Integration

SAPscript forms, Smart Forms, and PDF-based forms are integrated in the configuration of the application form, which means that navigation, creation, deletion, consistency checks, copying, and upload/download take place in the processing of the application form.

User Includes

Definition

Using ABAP programming, you can enhance the function and dynamics of an application form as required. The ABAP implementations required are stored in customer-defined includes in the USER-EXIT-INCLUDE and the USER-TOP-INCLUDE. The names of both ABAP includes are defined in the attributes of an application form.

Use

Data instructions (for example, DATA: TOTAL TYPE <Data type>) are implemented in the USER-TOP-INCLUDE, the user exit subroutines are defined in the USER-EXIT-INCLUDE.

Since user includes are client-independent as ABAP program objects, under certain circumstances, different application forms can reference to the same user include from different clients. Note therefore, that a user include or



referenced application forms can be changed or invalidated by unintentional changes as part of maintenance of other application forms.

Integration

The user includes are included in the TOP included in the generated function groups of an application form. The user exits defined in the user exit include are called in the defined events for the form levels (for example, before, during, after loop). You can also define and call other user-defined form routines.

Start/End Exit

Definition

To carry out initial and closing activities pre document, you can define a start/end exit in addition to the user exits of the form levels and the text nodes.

Use

The use of these exits is optional. You can use the exits to carry out initial or closing processing. They can refer, as in all user exits, to all data areas generated by the Print Workbench or own data defined in the user top include.

Structure

The start/end exist is an ABAP subroutine. The name of the subroutine is composed of the prefix USER_EXIT and the name specified in the attributes of the application form. Both subroutines have no interface parameters.

Integration

The subroutine for the start-exit is called up in the generated print program at the start of form processing before each activity that affects a form. Here all static, globally defined Print Workbench variables (C-*) and print parameters have been set. The end exit is called at the end of the form processing. Here all of the activities that affect the form have been completed.

In the user exits, you must carry out form activities (for example, call OPEN/CLOSE_FORM modules) since this can lead to errors in the internal form control.

Optional Static User Exits in Generated Print Program

Definition

In addition to the user-defined user exits, the generated print program contains further static user exits that you can specify in the user exit include in the configuration of an application form.

Use

Static user exits fulfill functions that are independent of the actual data procurement and processing of the hierarchy.



Structure

Static user exits are subroutines that have no parameters. Customers can define them in the user exit include. The Print Workbench gives the name of a user exit.

At the time of activation, the Print Workbench recognizes the existence of the subroutines, creates corresponding calls from the generated print program, and performs the user exits. You can use the following static user exits:

● FORM CHANGE_SF_OPTIONS This form routine is called immediately before the processor for Smart Forms is opened. There you can modify the import parameters of the module SSF_OPEN (if necessary) with ABAP programming: c-sf_control_parameters_ TYPE SSFCTRLOP

c-sf_output_options TYPE SSFCOMPOP

At this point, the application data from the application form or from the form class has not been read yet.

● FORM CHANGE_PDF_OPTIONS This form routine is called immediately before the processor for PDF-based forms is

opened. There you can modify the import parameter c-pdf_output_options

TYPE SFPOUTPUTPARAMS of the module FP_JOB_OPEN.

At this point, the application data from the application form or from the form class has not been read yet.

● FORM EXIT_BEFORE_PRINT This form is called immediately before the call of a generated module of an individual SAPscript form, Smart Form, or PDF-based form. At this point, the application data from the application form or from the form class is read completely.

Generated Modules

Definition

When you activate an application form, a function group with exactly one function module is generated. This function group contains all of the settings defined in the application form in the form of coding. The function group and the module are always defined locally ($TMP). For each application form, enter the same name; the name is different for each application form in each system and client. You have to regenerate the module for each change to the application form or one of the referenced objects (for example, form class, user includes).

Use

The generated module is called if the application form is to be printed. The call takes place exclusively in module EFG_PRINT, which is called in the print event of an application. A non-Print Workbench use of the generated module is not permitted. The generated module contains all ABAP commands and function calls of the form processing (SAPscript, Smart Forms, PDF-based forms) that are responsible for the data procurement and processing and, for example, place the form in the spool of the SAP system.

You can determine the application form for a generated module or for the function group with the same name with the Persistent Garbage Collector (CA-GTF-TS-PCG) in the Print Workbench menu. There you can check the uses of generated modules and delete modules no longer used. For more information, see the documentation for the Persistent Garbage Collector [Extern]



Structure

The generated module integrates the following parts of an application form:

● The flow logic of the application form according to the hierarchy

● Data procurement from the form class (call of READ, GET, FILL subroutines)

● Calls of the program interfaces for SAPscript, Smart Form, and PDF-Based Forms.

● Call of user exit from user include

The name of the generated module is composed of the naming convention prefix of the Print Workbench /1PWB/, the client, and a number composed of the date and time of the first generation. The name is different in each system/client and has no self-explanatory semantic.

Integration

The generated module is called up dynamically in the module EFG_PRINT exclusively. Every other (for example, direct) call of the module is not supported by SAP.

Languages

Use

To create outgoing correspondence in different form languages, you have to define languages within application forms. The definition of an application is not language-dependent. However, for each application form you can define a list of languages (except the maintenance language) for which the document can be printed. The language only refers to the language-dependent components (for example, standard texts).

Integration

The languages defined are an integral part of the application form and are transported between systems.

Features

When you create an application form, the language in which you log on to the SAP system is always set in the pool. If you also want to print the form in other languages, you first have to

add the language to the language pool. To do this, choose Extras Language Create. In order to maintain the SAPscript form and the texts in languages other than your logon

language, specify the relevant language under Extras Language Select. You have the

following options for printing in different languages:

● The language is set at the start of the print process by the application in question and then retained.

● If you wish to change the language interactively for each application form, you have to

set the internal language variable c-langu in the start exit.

To ensure that the print transaction works without any errors, make sure that you have maintained all language-dependent components of the application form (texts, SAPscript form) for all languages used. If a language is used in which texts or the SAPscript form are missing, or the language is not defined in the list for the application form, printing is immediately terminated.

Activities

To translate application forms, you use the translation tools of the Print Workbench. In the translation transaction the languages are created automatically.



Status

Use

The status of an application form is defined by different system conditions and different statuses of the application form objects involved. It shows whether the generated print program is up to date with regard to the application form and the relevant subobjects. You can only print print programs with status Active.

Integration

The following (sub)objects determine the status of an application form:

● Application form (attribute, hierarchy, form levels)

● Form class (hierarchy, attribute, form levels, form class library)

● User includes (user top include, user exit include)

● Status of form elements (Smart Form, PDF-based form, or form interface)

When the module is generated, the current version information of this subobject is written into a local table and then used for determining the status. If one of the above-mentioned subobjects is changed, the status is set to Inactive. If no module has been generated from an application form, the form has the status New.

The Hierarchy of an Application Form

Definition

The hierarchy of an application form covers all of the information about the relationships of the data belonging to the form levels. The hierarchy also defines a flow logic that is used to process all form levels and 1:1 levels and the data linked to these from top to bottom in the generated print program.

Use

The hierarchy describes the flow logic of an application form. The print program that is called dynamically at runtime by the module EFG_PRINT is generated from the structure of the hierarchy.

Structure

The hierarchy consists of:

● Root level (= attribute of the application form)

● Form levels

● Document level (= first form level)

● 1:1 levels

● Placeholder for user exits (for example, B‚ D, A, or T)

● Texts for form type SAPscript (SAPscript standard texts)

The following figure contains the schematic display of the hierarchy:



The Hierarchy of an Application Form

PWB_FLIGHT_NOTIFICATION Flight confirmation for

customer

Root level/Attribute

Customer

PWB_FLIGHT_HEADER_INFO

PWB_FLIGHT_FOOTER

PWB_FLIGHT_ADDRESS

PWB_FLIGHT_INTRODUCTION

PWB_FLIGHT_ITEM_HEADER

PWB_FLIGHT_ITEM_HEADER

BOOKING

FLIGHT

PWB_FLIGHT_BOOKINGS Line Items

Flight

Booking

Heading for line items (TOP)

Heading for line items (MAIN)

Letter for customer

Address

Footer (number of pages)

Information for customer

Document level

SAPscript - texts(only SAPscript)

Form levelB D User-Exits

1:1 level

By selecting and activating form levels or 1:1 levels you can define which data is to be read. If you use SAPscript, you can also assign additional SAPscript texts to the hierarchy; these are printed according to their position. The root level contains logical data (attributes) for the application form, for example, form class and name of the user exit include and the user top include. The document level is of particular significance to the form levels. The document level is the first form level in the hierarchy and has almost the same attributes as any other form level. In contrast to other form levels however, the number of entries for this form level corresponds to the number of forms created. For this reason, this document level must not be placed equal to another level. If a form level or 1:1 level is not required for printing, you can delete it or deactivate it. If a form level is deactivated, it still appears in the hierarchy but is no longer considered for printing. Please note that when deleting or inactivating a form level, the hierarchically dependent form levels and the affiliated 1:1 levels are also deleted or inactivated. For each form level and 1:1 level there is a global variable (work area) which you can access both in texts and also in user exits. The name of the work area is formed from the prefix WA_ and the name of the form level or 1:1 level (for example, WA_CUSTOMER).

Integration

The hierarchy of an application form is the basic configuration for the generation of the print program. The hierarchy of an application form is always created following the structure of the underlying form class. You cannot select or add form levels that are not defined in the form class. If the system determines inconsistencies between the hierarchy and form classes, if, for example, a form level was deleted, you have to correct this before you can activate and print the application form.



Form Levels

Definition

Form levels form the basic framework of the hierarchy of an application form. Form levels that are hierarchically dependent on one another (parent-child dependency) have a 1:n relationship with one another. This means that for each entry in a form level there are several related entries for the form level below (for example, customer and his flight bookings). However, form levels at the same level have no hierarchical relationship to one another.

The hierarchical relationships of the levels are defined in the form class and cannot be changed. However, you can use the same form level more than once in the hierarchy (duplication). The name of a form level and the DDIC structure below it is defined in the corresponding form class and cannot be changed.

1:1 levels

Definition

The 1:1 levels are directly assigned to the form levels. They have a unique and direct relationship (1:1) to their affiliated form level. Typical examples for 1:1 levels are the long texts (explanatory texts) for each of the entities. A 1:1 level is dependent on the form levels to which it is assigned since the selection criteria for access to the database are in the data already imported for the superordinate form level. Form levels and 1:1 levels represent a logical or business entity.

The name of a 1:1 level and the DDIC structure below it is defined in the corresponding form class and cannot be changed.

Texts (SAPscript Only)

Definition

Texts are a further node type in the hierarchy of an application form of the type SAPscript. You can insert texts in the required position of the hierarchy. The texts contain the actual contents of the printed form. In the texts, you can access all work areas (WA _<level name>) and your own variables that you define in the user top include. Here too the principle applies that siblings (levels at the same hierarchy level) are independent of one another. If you want to output a text for a form level, you have to enter this text in the hierarchy as a lower level of the form level. This situation is described in more detail in the next section, together with the application form‟s general process logic.



Flow Logic and Processing Definition of the Hierarchy

Definition

The application form is a configuration object that is translated in the generated print program in a processing and flow logic at runtime.

Structure

The flow logic of an application form is defined recursively, that is, a flow rule is defined for a form level; it contains the processing of other dependent form levels. For each form level in the application form, the following steps are executed in sequence: ...

1. The n entries for the current form level are determined for the current entry of the superordinate form level and place in an internal table.

2. The exit before loop is called – if it exists. The table determined is transferred to the user exit. There you can evaluate and modify the table. You can use the global data areas of the superordinate form levels and the related 1:1 levels.

3. The data loop over the entries of the internal table begins. At the same time, the global data area (WA_<form level>) is filled with the current line.

4. In the loop, all global data areas of the related active 1:1 levels are filled in sequence.

5. The exit during loop is called – if it exists. In this user exit you can use and modify all global data areas of the form level and the related 1:1 levels. You can also use the global data areas of the superordinate form levels and the related 1:1 levels.

6. The hierarchically subordinate nodes of the form level are processed. If it is a text (form type SAPscript), the text is printed; if it is a form level, the form level is processed in the same way.

7. The next entry in the loop is processed. If the last entry for the current form level is reached, the loop is left.

8. The exit after loop is called – if it exists.

At document level, additional form control orders are given to SAPscript or Smart Forms, such as that a document is completed or a new document is starting.

Interaction of Application Forms with SAPscript Forms, Smart Forms, PDF-Based Forms

Purpose

In the Print Workbench, you can use the form classes delivered in different ways. As standard, SAPscript is used for print preparation. Alternatively, you can use Smart Forms for the print output. Since both components are very different, the integration in the Print Workbench is also different.

Prerequisites:

To use Smart Forms in an application form, you have to activate the relevant form class for using Smart Forms (see documentation for the indicator Smart Forms in the attributes of the form class).



Process Flow

In the SAPscript scenario, the Print Workbench provides the global data areas of the form levels and 1:1 levels defined in the form classes by the application; these can be accessed in texts with the usual symbol logic for SAPscript. The texts are inserted in the hierarchy of the application form and are called up at runtime in accordance with their position in the hierarchy. The SAPscript form assigned to the application form contains settings for the layout such as pages, window, font, paragraph formats. In the generated print program the print transaction consists of alternative calls for data procurement and calls of the SAPscript form processor (for example, OPEN_FORM, START_FORM, WRITE_FORM_LINES). This means that the form is created interactively between the Print Workbench and SAPscript. In Smart Forms and PDF-based forms, the data is read from the database and placed in the global data areas in accordance with the form class definition as for SAPscript, but the data is no longer valuated for immediate output in the form. It is firstly saved in a complex data structure also provided by the form class. The data is transferred from the global data areas to the complex data structure when the text is output for SAPscript. The complex data type of the form class agrees with the hierarchy of the form class. The nesting of the data is reflected implicitly by a complex data structure for each form level. The data written in the complex type is controlled by selecting or deactivating form levels and 1:1 levels. The name of the complex data type for the data transfer to the Smart Form corresponds to the assigned complex data type of the document level. The name of the parameter in the form interface must be PWB_DATA.

For Smart Forms and PDF-based forms, the system can create the corresponding form object for an application form automatically. The interface is created appropriate to the application form or the form class; the standard variables PWB_DATA and C are added to the form interface.

You can also adjust the form elements automatically later using a corresponding help function in the application form.

Access to Data Read

Use

During the processing of the hierarchy, data is stored in the global work areas. These work areas are the central interface of the hierarchy to the read data in the application form.

Features

In the print program, there is one work area for each form level and each 1:1 level and this has the name WA_<Level name>. You have several options for inserting symbols into a text:

● In the SAPscript text editor, choose Insert Symbols Program Symbols and select

the required symbols. All of the application form symbols that you can use based on the position of the text in the application form hierarchy appear.

● Place the cursor on the text, or on a form level or 1:1 level, and choose Extras

Display Symbols. Select the symbol you require from the list and choose Enter. The selected symbol is placed in the buffer and can be inserted again at any point. Alternatively, you can copy the symbol into the buffer by double-clicking on it in the list.

● Choose Utilities Display Hierarchy.

A new amodal window containing the form class hierarchy appears. By double-clicking on one of the levels you can display the appropriate symbol, as described in point 1. Choose the symbol you want to transfer and choose Enter. Unlike in point 2, the



selected symbols are not copied directly to the buffer unless you choose Copy to Buffer.

You can also carry out a cross-level search. To do this, place the cursor on a form level and choose Find Variable. All the variables found are listed. The search includes both the names of the variables and their short text.

The global data area that you can access in a text or a user exit depends on the position in the hierarchy. See also Flow Logic of the Hierarchy [Seite 14].

Example

In the example above, the work areas are:

● WA_CUSTOMER

● WA_BOOKING

● WA_FLIGHT

In these work areas you can access the texts and the user exits. A table or structure from the ABAP Dictionary is hidden behind each work area. You can ascertain the dictionary structure concerned in the attributes for the relevant form levels or 1:1 levels. In our example, the customer‟s number is to be printed in the text PWB_FLIGHT_BOOKINGS. You can see from the attributes of the form level that the table SCUSTOM is masked by CUSTOMER. When you double-click on the table, you can see that there is a field ID that contains the customer number. To output the customer number of the

current business partner, you must include the symbol &WA_CUSTOMER-ID& in the text.

The character & at the beginning and at the end of the instruction distinguishes SAPscript symbols (variables) from normal text. The variable is replaced with the current content in the print program at the time of printing. The Smart Forms and PDF-based forms contain own methods for accessing the data in the data categories packed. However, in this case, the global variables WA_* are still available for use in user exits.

Control Variable C

Definition

The control variable C is a global variable that exists in each application form. It contains technical data for the application form or the print environment that is relevant for the current print transaction. The variable has a fixed structure and is defined globally which means that it can be queried at any time in texts or user exits.

Use

The variable C enables you to request global information for the application form or the print environment so that you can interpret and process this information either locally in the form or externally.

Structure

The variable C consists of two parts. The first part is transferred to the Smart Form. This corresponds to the DDIC structure EFG_STRN_PRINTDATA:

Field Name

LANGU Current language for the form

DEVICE Current output type (PRINTER, TELEFAX))



RDI SAPscript indicator for RDI

FORMKEY Current application form

FORMCLASS Current form class

ITCPO Input print parameter for SAPscript as ITCPO structure

ARCHIVE_INDEX Parameters for archiving (BOR object type, BOR object ID, archive object type)

COMM_TYPE BCI send type (INT, FAX, RML)

SENDTYPE send type

SENDTYPE_EXT External send type

COPYFLAG Document is a copy

TESTMODE Test print

ITCPP

Print parameter returned by SAPscript as ITCPP structure

XSF XSF indicator for print using Smart Forms:

COLLECTION Name of collection (if integrated in a collection)

IDENTIFICATION Identification from collection (if integrated in a collection)

GET_PWB_DATA Returns data on the caller

ADDITIONAL_PARAM Parameter specified by the application for controlling print-relevant parameters

XFP Output format of PDF-based forms

The second part of the variable contains further fields:

Field Name

TABIX Count variable for the current loop

LINES Number of entries in the current loop

FORMTYPE Form type (Smart Form of SAPscript)

NO_ENTRY Last form level has no entry

PA_PRINT Print action records should automatically be printed.

PA_UPDATE Print action records to be updated

FORM_LEVEL Current form level

LEVEL_NUMBER Number of form level if multiple selection in the hierarchy

RDI_RESULT SAPscript return structure if RDI has been used

SAP_FORM Name of SAPscript form

SMARTFORM Name of Smart Form

T_LANGU Table of valid languages

REC_STRING Recipient for send type (e-mail address, fax number, user name)



SEND_STRING Sender for send type (e-mail address, fax number, user name)

MANDT Client of form

RDI RDI indicator

SMARTPRINT Indicator whether Smart Form is to be called

SMARTFILL Indicator whether the data is to be filled in the complex data types (default „X‟)

SF_RESULT Return result of Smart Form call

(structure SSFCRESCL)

SF_OUTPUT_OPTIONS Output options for Smart Forms (structure SSFCOMPOP)

SF_CONTROL_PARAMETERS Smart Forms: Control structure (structure SSFCTRLOP)

You can use the variable C at any time in texts (for example, &C-TABIX&) or in user exits. You can also change the variable; however, this is only recommended in a few cases. Via

Extras Display Control Variable, you can display the most important fields of variable C. You can display a complete list of all fields by displaying the structure EFG_STRN_PRINTDATA_EXPANDED in the ABAP Dictionary.

Integration

The variable C is globally defined in the generated print program. It is filled by the print program and interpreted later for further processing, for example, the print parameters in C-ITCPO. The variable is also defined in the form class library and can be used there, for example, to query the form type.

Processing Application Forms

Purpose

To create outgoing correspondence, you must first create the required application form. The form is only available for printing once it has been activated.

Process Flow

To create an application form, proceed as follows: ...

1. Create an application form and name the subobjects (form class, SAPscript form, Smart Form, or PDF-based form, user includes).

2. Maintain the SAPscript form, Smart Form, or PDF-based form.

3. Insert the text nodes in the hierarchy and maintain the texts (only for SAPscript).

4. Implement user exits.

Result

When you activate an application form, a print program is generated in the form of an ABAP function group and a function module. If the application form is called in a print process of the application using the function module EFG_PRINT, this generated function module is processed.



Creating Application Forms

Procedure ...

1. Choose Print Workbench Application Form Edit.

2. Enter the name of the new application form and select Application Form Create.

3. Now select the affiliated form class. By doing this, you assign the application form to an application. You cannot change this assignment later.

4. Choose the form category (SAPscript, Smart Forms, or PDF-based form). Depending on the form category, specify the name for the relevant form of the respective form tool. For all objects, consider the conventions and rules for assigning names.

5. If you want to work with user exits, specify the name for the relevant user includes. Again, see the naming conventions.

6. Choose Continue. If automatic recording of changes is active in the current clients, you have to specify a Customizing transport request.

The application form is created. The complete hierarchy of the form class is inserted into the new application form. You can now start adjusting the hierarchy to your requirements (for example, delete or deactivate form levels or 1:1 levels not used). ...

1. Edit the relevant SAPscript, Smart Form, or PDF-based form and activate it.

2. If you use SAPscript, add text nodes to the hierarchy. Pay particular attention to the hierarchical position of the text. Edit the texts.

3. If you have specified user includes, create the includes by double-clicking on the objects in the attributes of the application form.

4. Activate the application form.

Result

You can now print the application form. You can develop it further using the Print Workbench tools (for example, test print), and adjust it to your requirements.

Inserting Variables in Texts (SAPscript Only)

Use

In addition to standardized formulations and headings, the text module of a form contains data from the business process that triggered the printing of a correspondence. In this case, for example, you have to integrate the data delivered by SAP in the text.

Prerequisites

The SAPscript form for the application form is active. You have inserted one or more text nodes in the hierarchy of the application form.

Procedure ...

1. Process the required SAPscript text.

2. Place the cursor on the point where you want to insert the symbols.

3. Choose Integrate Symbols Program Symbols. A list of all fields relevant for the text node appears. The fields are displayed as symbols – they have a restricting & at the beginning and end.



4. The fields include:

○ Fields of all global data areas (WA_*)

○ Fields of the control variable C

○ Variables defined in the user top include

5. Choose one or more fields from the list.

6. Choose Continue.

Result

The selected symbols are inserted in the cursor position.

Creating a Summation

Prerequisites

A user exit include and a user top include are defined in the application form attributes.

Procedure ...

1. Determine the global data field the total is to be based on, for example, WA_CUSTOMER-FORCURAM.

2. Choose Goto User top include Display/Process to navigate to the user top include. Define a summation variable (for example, DATA SUM LIKE WA_CUSTOMER-FORCURAM >). Navigate back to the application form.

3. Place the cursor on the form level from which you wish to run the summation. Choose Choose.

4. Specify a name for the exit before loop (such as INIT_SUM) and the exit during loop (such as PERFORM_SUM). Choose Continue.

5. In the hierarchy display, the two symbols B and D (for “before” and “during”) now appear on the level on which the cursor is still placed. First choose B to navigate to the exit before loop.

6. Trigger the summation with the ABAP order CLEAR SUM. Navigate back to the application form.

7. Choose D to navigate to the exit during loop.

8. Enter the summation order, (such as ADD WA_DOC_ITEM-NETTOBTR TO SUM). Navigate back to the application form.

9. Issue the total in the form by placing the symbol &SUM& in a text after the form level (for

example, same level).

10. Activate the application form.

Result

Summation is only performed if you print and it is then output in the text.

If you need the total before a text is printed, if, for example, you want to make the layout of the form dependent on the total, SAP recommends that you first run the summation without text nodes in the form. You can then issue the text using a second form level with the same name.



Reading Additional Data from the Database

Procedure

If, during the processing of an application form, you discover that the dataset provided by the form class is not sufficient, you have to read the missing data from the database. Proceed as follows: ...

1. Determine the DDIC table containing the required data.

2. Choose Goto User top include Display/Process to navigate to the user top include.

3. Place the cursor on the form level for which you wish to read additional data and choose Choose.

4. Enter a name for the exit during loop, such as READ_DATA. Choose Continue.

5. Choose the symbol D in the hierarchy display to navigate to the user exit.

6. Enter the command that reads the data from the database, (for example, SELECT * FROM <DDIC-TABELLE> WHERE). You can use all work areas (including 1:1 levels) that belong to the form level or are higher up in the hierarchy as selection criteria.

Result

You can use the additional read data as a symbol in a text. The text must come below the form level described above in the hierarchy, in other words it must be a dependent node. This is also applicable if you use the data in another user exit.

Only use this procedure if you need data for form printing that the form class does not provide. As standard, the concept of the Print Workbench is such that all data of an application or process is provided in the form class.

Dynamic Intervention in the Process Flow in User Exits

Use

In user exists, you can make the process logic of an application form dependent, for example, on data or data constellations.

Procedure

In the Print Workbench, SAP provides the following ABAP macros that you can call up in the user exits:

● mac_next If you are in the program loop of a form level, and do not want to (or no longer want to) process the subordinate nodes in the current run, you can make the program branch to the next run by using the ABAP macro mac_next. You should only define this macro in the exit during loop and text exit.

● mac_exit If you want to terminate processing for the current node, you can define the command mac_exit in the user exit. This macro is not suitable for the exit after loop. It has no effect there.



● mac_deactivate <Name> You can dynamically deactivate a form level (or 1:1 level) defined in an application form in a user exit if, for example, it is no longer required due to a specific data constellation. When you call this macro, the form level <Name> is no longer processed, regardless of where the macro is called. This deactivation applies for all levels of the same name in the entire form.

● mac_activate You can dynamically reactivate a form level (or 1:1 level) if it was deactivated by the macro mac_deactivate in a user exit. In order to be able to activate a form level, the level must be defined as active in the application form hierarchy. You cannot activate levels that are not named or are not active in the hierarchy.

Transferring Own Data to a Smart Form or PDF-Based Form

Use

If the data defined in the form class is insufficient, or the structures do not correspond to the respective aim, you can define your own data areas in the user top include, fill them in a user exit, and use them in the related Smart Form or PDF-based form.

Procedure ...

1. Define your own data as global variables in the user top include.

2. Fill these variables with runtime data using user exits at appropriate places in the hierarchy.

3. In the interface of the Smart Form or in the form interface of the PDF-based form, define import parameters with the same name as the variables in the user top include. Make sure that the data categories are identical, otherwise errors may occur. In addition to manual maintenance, you can also generate the data definitions in a user

top include automatically in the respective form interface. To do this, choose Edit

Smart Form Compare or Edit PDF-Based Form Compare Form Interface.

Result

You can use your own global data of an application in a Smart Form or PDF-based form in the same way as the standard data transferred.

If you do not need the standard variables PWB_DATA and C in the form, or they disrupt, you can remove them from the form interface. The Print Workbench indicates that the standard parameters are missing by issuing warning messages that have no consequences.

Optimizing Performance

Use

For mass printing, optimal performance in application forms during data processing is very important. Therefore, in programming, note the following rules:

● Deactivate or delete the form levels and 1:1 levels in an application form if you do not need them for form processing.



● In SAPscript texts, use user exits instead of ABAP similar control commands. SAPscript is a meta language whose processing is low performance.

● If you read data in user exits from the database, store these in ABAP variables (for example, in global data in the user top include).

● Avoid naming form levels twice in applications unless this is absolutely necessary and justified.

● With database and ABAP traces, concentrate on the user exits that you have implemented. The reasons for low performance of processes are usually there.

User Exits in Application Forms

Use

If you want to access form processing and data procurement and realize other requirements, such as summation, interactively, you can use the existing user exit infrastructure of the Print Workbench in the application form. In user exits you can adjust application forms to your requirements and enhance your functions.

Integration

User exits are defined in the form of ABAP subroutines in the user exit include of an application form. These subroutines are called up in the generated print program according to their position in the hierarchy.

Features

The following user exit types are available:

Name of user exit Reference Call/function

Exit before loop Form level The exit is called directly before processing of the entries for a form level. The entries of the following loop are transferred to the interface of the subroutine.

Exit during loop Form level The exit is called in the loop of entries of a form level. The global data areas of the form level and the related 1:1 levels are filled with data in this event.

Exit after loop Form level The exit is called after the loop over entries of a form level. This is the last activity before the next same level or entry of the next higher form level is processed.

Text exit (SAPscript only)

Text nodes The exit is called directly before a SAPscript text is printed. The interface of the subroutine contains an indicator (Y_PRINT_TEXT) that shows whether the text is to be printed or not. (Default = Yes)

Start exit Application form The exit is called at the start of processing for a form level.

End exit Application form The exit is called at the end of processing for a form level.

Activities

Before you create one of the above-mentioned user exits, you have to specify the user exit include in the attributes of the application form. SAP recommends that you also specify the



user top include since there you have to define global data that is used, for example, in user exits. You can use the user exit includes assigned in several application forms. If you use the exit more than once (also cross-client), the system issues corresponding warnings. ...

1. Navigate to the object for which you want to create a user exit (for example, form level).

2. Specify a ten character (maximum) name. The name must be alphanumeric and unique within the application form. The user exit then appears as a symbol in the hierarchy of the application form.

○ B for an exit before loop

○ D for an exit during loop

○ A for an exit after loop

○ T for a text exit

○ S for the start exit

○ E for the end exit

Select a symbol to go to the user exit maintenance.

Example

The exits SUM_INIT (before) and SUM_PERFORM (during) exist for the form level BOOKING.

Declaration of Own Data Areas

Use

To design a flexible and dynamic application form, in addition to user exits you also need own data areas that you can fill and read when you process forms. You have to declare these data areas as ABAP variables in the user top include.

Integration

The user top included is included in the generated print program of an application form. The ABAP variables defined there are therefore available in all user exits. If you use Smart Forms and PDF-based forms, the variables defined in the user top includes are transferred to the generated module of the Smart Form in addition to the complex data type.

Exit Before Loop

Use

The exit before loop is called up before the data lines for a form level is processed; it enables you to carry out initializing activities with regard to the form level.

Features

The interface of the subprogram for the user exit is generated by the Print Workbench during creation of the exit and must not be changed. The internal table is always transferred to the subprogram that is processed next. You can modify the table and its entries in the user exit.



For example, you can reassign entries or change values for individual fields. You use the exit before loop to:

● Read additional data from the database

● Initialize summation variables

● Sort the table entries to be processed

● Process SAPscript control commands (for example, NEW-PAGE orPROTECT)

● Process SAPscript protect commands

Example *&---------------------------------------------------------------------*

*& Form USER_EXIT_SUM_INIT

*&---------------------------------------------------------------------*

FORM user_exit_sum_init

TABLES

xyt_booking STRUCTURE sbook .

CLEAR sum. “defined in user-top-include

SORT xyt_booking BY fldate ASCENDING forcurkey ASCENDING.

ENDFORM. " USER_EXIT_SUM_INIT

Exit During Loop

Use

The exit during loop is called up during the processing of a form level and enables you to carry out activities that have to be performed for each line of the form level.

Features

The exit during loop runs while the form level is being processed - immediately after data is transported to the respective work areas. In this user exit you can use the work areas belonging to the relevant form level, to the corresponding 1:1 levels, and to all form levels higher in the hierarchy. Use this user exit to:

● Perform summations

● Read additional data from the database

● Modify global data areas

Example *&---------------------------------------------------------------------*

*& USER_EXIT_SUM_PERFORM

*&---------------------------------------------------------------------*

FORM user_exit_sum_perform

USING x_booking type sbook

value(x_index) type sy-tabix.

DATA: local_amount LIKE x_booking-forcuram.

CALL FUNCTION 'CONVERT_TO_LOCAL_CURRENCY'



EXPORTING

date = sy-datum

foreign_amount = x_booking-forcuram

foreign_currency = x_booking-forcurkey

local_currency = local_currency

* RATE = 0

* TYPE_OF_RATE = 'M'

IMPORTING

* exchange_rate =

* foreign_factor = fremdkurs

local_amount = local_amount

* local_factor =

* exchange_ratex = faktorsum

* FIXED_RATE =

* DERIVED_RATE_TYPE =

EXCEPTIONS

no_rate_found = 1

overflow = 2

no_factors_found = 3

no_spread_found = 4

derived_2_times = 5

OTHERS = 6.

ADD local_amount TO sum. “execute summation

ENDFORM . " USER_EXIT_SUM_PERFORM

Exit After loop

Use

The exit after loop runs after the form level is processed and therefore, implicitly, after all the levels/texts lower in the hierarchy are processed. It is used for closing activities per form level.

Features

The exit after loop runs after the form level has been processed, therefore, after all the form levels lower in the hierarchy have been processed. In this user exit you can process closing instructions, for example, you can prepare a total for output or insert a manual page break. You use the exit after loop to:

● Analyze the summation

● Process control commands for SAPscript (for example, NEW-PAGE, ENDPROTECT)

● Initialize totals fields



Text Exit (SAPscript only)

Use

The text exit is called before a SAPscript text is printed for each data line of a form level and can be used for different activities during processing of a form level.

Features

The indicator y_print_text is transferred in the interface of the text exit; it controls whether the text of the text exit is to be printed. This enables you to dynamically control whether the text is to be printed and to carry out additional activities (for example, data selection).

If there are alternative text parts, you can use IF instructions in SAPscript texts to decide which text parts are to be printed. For performance reasons however, you should implement these instructions using text exits, since IF instructions in SAPscript texts require a time-consuming interpretations (see also Optimizing Performance [Seite 45]).

Start/End Exit

Use

Exit events are the external parentheses around an application form. In exit events you can carry out initial and final activities per application form.

Features

Selecting from these symbols will bring you to the user exit maintenance. There are also two user exits that can be used, irrespective of the hierarchy, at the beginning and at the end of the form.

● Start exit This exit is processed first when you process the form. At this point, no data has been read and no SAPscript function modules have been called.

● End exit This exit is processed last when you process the form. At this point, the whole form has been processed and the SAPscript module CLOSE_FORM has been called.

Triggering Controlled Terminations

Use

In user exits and the form routines of a form class, exception situations can occur where the system is to react with a controlled termination. The print process is not to be terminated, only the printing of the current document. To make sure that terminations that disrupt the print process of the Print Workbench do not occur, you can use the ABAP macro MAC_PRINT_CANCEL to define how the termination is to take place.

Procedure

Always use the ABAP macro MAC_PRINT_CANCEL in all user exits (see Controlled Terminations in Exception Situations [Seite 23]).



Utilities

Use

To make the development and administration in the Print Workbench more efficient, you can use various tools and functions that are described in more detail below.

Test Print

Use

A test print enables you to output a form during form development, form maintenance, or during the analysis of errors during data procurement (form class) without the related application process. You can set and vary the print data and the print parameters. Use the test print if you want to test the form without integrating it in the print process.

Integration

How the test print is initiated depends on the form class of the application form. Either the user determines an initial object via the FIND method of the BOR object type assigned, or an individual dialog takes place to select an initial object.

For some form classes you cannot carry out a test print. If a test print is not possible, the application of the form class must provide an alternative.

Prerequisites

The form class of the application form must support test prints. You can only print active application forms for test purposes.

Activities

You are in the processing or display of an active application form. ...

1. Choose Application Form Test Print Execute. In a selection dialog of the application, choose the initial object for the test print. Choose Continue.

2. Specify the send type, the printer, and the output format for the test print and choose Continue.

3. In the subsequent dialog box, specify the additional print parameters and then choose either Print or Print Preview, depending on whether you want to output the result of the test print on the printer or only display it on the screen.

If you repeat the test print, the specifications that you are made are used again. If you want to

enter new parameters for the test print, choose Application Form Test Print New Object.

If you use an application form of the type Smart Form, SAP recommends that you process the application form and the Smart Form in two separate sessions and carry out changes to the Smart Form and start the test print from the application form simultaneously. You can process the Smart Form in a new

session from the processing of the application form via Goto Smart Form Display in New Session.



Breakpoints and Debugging

Use

For example, if you want to find out why data was not output in a form or output incorrectly, you can analyze the generated print program in a runtime environment during the test print. The generated print program contains numerous breakpoint instructions that you can use if necessary.

Prerequisites

You have the relevant authorization.

Activities

In the display or processing of an active application form that can be tested, you have the following options: ...

● Place the cursor on the places in the hierarchy where you want to carry out an

analysis. Via Extras Set/Remove Breakpoints, insert breakpoints into the hierarchy of the application form.

● Navigate to the generated print program via Goto Generated Module Display or

via Goto Generated Module Subprograms and set a breakpoint in the editor.

● Navigate to – if it exists – the user exit include and set breakpoints in the coding in the ABAP Editor.

Carry out a test print for the application form. You cannot restart the transaction. In the first case, the ABAP process goes to the ABAP debugger in all relevant subprograms for the respective hierarchy nodes (for example, READ/GET/FILL subprograms, text output). In the other cases, the ABAP processor goes to your breakpoints in the debug session.

Copying from Clients

Use

You can copy application forms from other clients to the current client. Since an application form consists of different (sub)components, these components also have to be copied during the transaction.

Features

The hierarchs and the attributes of the application form are copied, along with the SAPscript form or Smart Form depending on the form type, and if necessary, both user includes. You can also suppress the copying of individual objects or reference to existing objects. You can also overwrite explicit specifications.

Activities ...

1. Choose Print Workbench Application Form Tools Copy from Client.

2. Choose the source clients and an application form.

3. In the following dialog you are requested to name the referenced subobjects (new). Pay attention to the usual naming conventions.



The referenced subobjects of an application form can be used by other application forms. Therefore, check precisely before you overwrite them. The Print Workbench shows multiple use of objects as a warning.

Uploading and Downloading Application Forms

Use

You can upload or download application forms if there is no direct transport connection between SAP systems. You can save an application form and its components in a local file of your front-end and then load them to any version-compatible SAP system. In mass processing you can also carry out a mass download.

Integration

All (sub)components of an application form are transported when you upload or download.

Features

When an application form is downloaded, all its components are saved in a local file:

● Hierarchy/attribute of the application form

● SAPscript form/Smart Form/PDF-based form and form interface depending on the form type

● SAPscript texts (only for SAPscript)

● User includes

When you upload, you can change all the names of the subcomponents before you save these in the SAP system (see also Copying from Clients [Seite 52]).

The internal data format of the files has changed considerably with Basis Release 6.20. Files created in an earlier release can no longer be read.

Activities ...

Download

1. To download an application form to a local file, choose Print Workbench Application

Form Application Form Download.

2. Specify the absolute name of the file to be written. The data is then read from the system and downloaded to the specified file. To download several application forms (for example, from other clients), select these in the mass processing of application forms and then choose Download with the right mouse button.

Upload ...

To upload an application form from a local file, choose Print Workbench Application Form

Utilities Upload. If the file contains several application forms, a corresponding list appears for you to select from. Choose an application form from the list. The subsequent dialog box is identical to the one for copying or copying from a client. When you name the new subobjects, pay attention to the naming conventions and the existing uses.



Creating Links

Use

If you want to use the same application form in several clients, you can create links to an application form in another client so that it does not have to be transported or replicated. With a link, when you print, only the runtime components from another client are used.

Prerequisites

The target client must not contain an application form with the same name.

Procedure ...

1. Choose Print Workbench Application Form Tools Create Link in Other Client.

2. Specify the (source) clients and the names of the referenced application form and choose Continue.

To create several links in one step, proceed as follows: ...

...

...

1. Choose Print Workbench Application Form Tools Mass Processing.

2. Specify the clients and the application forms in the selection conditions and choose

Program Execute.

3. Select the application forms that you want to link to, and, using the right mouse button, choose Link. The current clients must not contain the application forms selected for other clients.

After a client copy, the application forms are created as links to the source clients. If you want to create real copies of the application forms, you can transport them from one client to another. To manage and automate links over several clients, you can use the reports EFG_CREATE_LINKS and EFG_DELETE_LINKS ; these reports are available exclusively to (system) administrators.

Finding Variables

Use

Depending on the form class, the dataset contains a number of fields that are in different levels and different DDIC structures; under certain circumstances, they may be difficult to find. SAP therefore recommends you use the following procedures.

Features

The Print Workbench provides you with various options for finding variables in the data hierarchy of the form classes:

● You can display the fields of any node in the hierarchy of an application form and search there.

● In SAPscript, you can display the available variables in text processing.

● In Smart Forms, you can display the variables in the hierarchical display of the complex data structure (ABAP Dictionary).

Activities ..



1. You are in the processing/display of an application form. To search for a field in the dataset of the form class hierarchy, open the data overview of the form class in

question via Extras Display Form Class Hierarchy.

2. On the subsequent processing screen, place the cursor on the form level for which you

want to display the related data and choose Edit Display Symbols. In the following dialog box, specify the search term and the search area.

The variables found are displayed. For information about integrating variables in a text, see Inserting Variables in Texts (SAPscript only) [Seite 42].

For Smart Forms, you can find additional fields in the ABAP Dictionary. Choose Extras Hierarchy Display.

Form Information

Use

With the function Form Information, you can get a global overview of the complete content of an application form. The printed list can also be used to find symbols used in SAPscript texts and user includes.

Features

The attributes, the hierarchy in flat presentation and the contents of the user exit include and user top include texts are displayed. The contents of the SAPscript form can be printed using a corresponding function for SAPscript forms.

Activities ...

1. Choose Print Workbench Application Form and specify an application form.

2. Select Utilities Form Information.

Administration and Transport

Purpose

From an external point of view, the application forms in their entirety represent a large object structure the, due to the heterogeneity of the objects used, is difficult to administrate without special tools. The Print Workbench provides you with functions and tools for managing the objects of the Print Workbench and the referenced objects.

Mass Processing

Use

You use the mass processing of application forms to manage application forms efficiently in a client.

Integration

All subobjects of an application form are used in mass processing.



Features

You can use the following functions:

● Cross-client overview of application forms with the following subfields:

○ Status

○ Form class

○ Form Types

○ Name/package of SAPscript or Smart Form and user include

○ Reference client for references

○ Form name

● Mass activation

● Mass check

● Mass Transport

● Mass download

● Individual copy (same or other client)

● Individual deletion (only same client)

The individual functions are dependent on the selected entries.

Activities

Select the required application forms for which you want to execute a function and then choose the required function with the right mouse button.

Mass Activation

Use

You can use Mass Generation, for example, if you want to activate all or certain application forms in the background with no further dialog.

Prerequisites

The application forms to be activated must not contain errors.

Features

The mass activation program activates any number of application forms in any number of clients and delivers a results log.

Activities ...

1. Choose Print Workbench Application Form Tools Mass Activation.

2. Specify the client and the selection criteria for the application forms to be activated. If you do not want to activate the application forms that have already been activated again, set the indicator Only if Active.

3. Start the program.



In the log you can see whether all activations were successful. If you start the program in batch mode, the result log is made persistent and you can evaluate it with transaction SLG1.

Transporting Application Forms

Use

An application form consists of different, independent, transportable (sub)objects. The individual objects each have a different transport behavior.

Transport Behavior of the Objects

Object Type Transport Object (R3TR)

Client-Independent Object Catalog Entry (TADIR)

Application form EFOM NO NO

SAPscript form FORM NO YES

Smart Form SSFO YES YES

PDF-based form/form interface

SFPF / SFPI YES YES

SAPscript text TEXT NO NO

User includes PROG YES YES

Generated function group

(FUGR) (NO) $TMP (LOCAL)

An application form has only been correctly transported if all subcomponents have also been transported.

Features

You have two options for transporting application forms. The option you choose depends on the system setting of the client in which the application form is developed or maintained.

● Automatic transport If the setting Recording of Client-Dependent Customizing is active, each time you change a client-dependent object (for example, application form or SAPscript text), an entry is created in a Print Workbench transport request for the object concerned. The system requests this entry before the change. The client-independent objects are entered in transport requests as standard provided you have assigned them to transportable packages. Exception: The SAPscript is client-dependent, but has a cross-client object catalog entry.

● Manual transport You carry out a manual transport in the following cases if the recording of client-specific Customizing is not active in the client in which you are developing the application form, and/or you want to place the application form, including subcomponents, in a transport request. Proceed as follows:

...

a. Choose Print Workbench Application Form Transport.

b. In the subsequent dialog box, select the subobjects to be transported.

c. Specify a transport request and choose Continue.



When it releases the transport request, the system checks the application form specified and if necessary, reactivates it. If errors occur, the release is terminated. You can analyze the corresponding messages in the transport log for the request. During the import into the target system, the transported application forms are also activated. If an application form cannot be activated, a corresponding error entry is updated in the transport log of the request.

Using References

Use

You can set references if you want to develop and manage application forms in a system in a central client. This has the following advantages:

● You can encapsulate the original versions of the application form in a client defined for this purpose and it can then, for example, only be changed by certain users in the system.

● You no longer need to transport or copy within a system. The changes are visible and valid in other clients immediately.

● You can quickly access forms of another client.

Integration

References to other clients are a proprietary function of the Print Workbench. The client-specific objects used for the runtime are read from the referenced client and not the current one.

Features

You create references from one client to application forms of another client and can then use them as if they were in the current client. The referenced application forms do not exist physically in the current client, but are visible and you can use them for printing.

Activities

Create a reference ...

1. Choose Print Workbench Application Form Tools Create Link in Other Client.

2. Choose the client and the name of the application form. There must be no application form with the same name in the current client.

Create multiple references ...

1. To display the application forms of another client, use mass processing.

2. Select the application forms that you want to reference to from other clients.

3. With the right mouse button choose Create References. There must be no application forms with the same name in the current client.

Versioning and Archiving via Upload/Download

Use

You can use uploads and downloads for transporting into different systems. You can also use uploads and downloads to make the status of individual or all application forms persistent



outside the system and thereby carry out versioning or archiving. An integrated versioning of application forms within the SAP system is not supported.

Integration

The upload and download of application forms contains all components of an application form. In an upload, you can select the components to be loaded.

Activities

Save the selected or all application forms of a client with the download function, for example, in mass processing.

Translating Application Forms

Use

You cannot translate the Print Workbench application forms and SAPscript texts with the standard SAP translation function. You therefore have to follow a different translation procedure:

● You have to create separate worklists for translating application forms.

● Translation should take place in a special client so that a separate transport can be carried out.

● After translation, a new transport to the target system must be carried out.

Activities

To translate application forms, proceed as follows:

● Create worklist

● Process worklist

In addition, you can use further administrative tools that you access via Print Workbench

Application Forms Environment Translation Administration.

● Mass processing of worklists If there are several worklists in the system, you can manage them using this function. In particular, you can delete worklists and update their status. A statistic gives information about the status of translation activities.

● Translation of SAPscript forms not used in the Print Workbench If you use SAPscript forms that do not belong to the Print Workbench, that is, forms that are not used by an application form, you can list these with this function and check their translation status.

Worklist

Definition

Lists of objects that are to be processed once only within a certain time frame for each language. The worklist groups the individual entries and manages the list of objects to be processed, including their status and the tasks to be carried out for the objects. From the worklist status, you can assess the general processing status.



Structure

The worklist consists of three hierarchy levels and is subject to status management.

Hierarchy

The following figure shows the first level of a worklist with the individual application forms to be translated.

By expanding this level you reach the second one. Here, the worklist is subdivided into the following object groups:

● Table short text

● SAPscript forms

● SAPscript text

The individual objects to be translated are under these object groups. By expanding the second level you reach the third level (see figure).



Double-click on the individual objects to translate them.



Creating Worklists

Prerequisites ...

1. Log on to the relevant client in the system in which you translate the form, and choose

Print Workbench Application Forms Environment Translation Create Worklist.

2. Enter the name and form class of the application form to be translated and the original and target language.

3. Choose Program Execute. You obtain a list of the objects to be translated in the application forms. If there are red lines in the list, notify your system administrator. Red lines signify errors that must be eliminated.

4. To create a worklist from this list, choose Translation List Save/Send Create Worklist. In the dialog box Indicator for Worklist, enter the following:

○ ID (for example, your initials)

○ Date (for example, the current date)

○ Short text

5. Choose Continue.

Result

The worklist has been created. The technical key of the worklist is made up of the ID that you entered and the date. Once you have generated the worklist, you can process [Seite 63] it.

Processing Worklists

Prerequisites

To process a worklist you must first make sure that a worklist exists. See also the section Creating Worklists [Seite 63].

Procedure

Preparation ...

1. In the menu, choose Print Workbench Application Form Environment

Translation Worklist Edit. In the dialog box Indicator for Worklist, specify your indicator and the date on which the worklist was created and choose Continue. The desired worklist is displayed.

2. Place the cursor on an application form and, in the menu, choose Edit Expand Subtree. You now see all the objects for translation in the application form you have selected. For more information about the different hierarchy levels, see Worklists [Seite 59].

Execution

Translating Table Short Texts



To select the table short text required, double-click on it. The screen Translation of Tables with Master and Transaction Data appears; here you can translate the short text.

Translating SAPscript forms ...

1. Select the required SAPscript by double-clicking it. The SAPscript Translation screen appears.

2. In the Form field, enter the form to be translated. Enter the target language required

and choose Translation Create/Change. The screen Meaning appears; here you can translate the SAPscript form.

Translating SAPscript Texts ...

1. Place the cursor on a SAPscript text and choose Edit SAPscript Text Display Original. A new window opens displaying the original text as translation reference.

2. To select the SAPscript text required, double-click on it. The screen Change General Standard Text appears. SAPscript texts consist of:

○ Text

○ Control characters (for example, tabulator,,)

○ Control lines (for example, paragraph format :/)

○ Symbols (for example, &DATE&) Note that control characters, lines, and symbols do not have to be translated. The number and sequence of the paragraphs must, however, match the original.

3. The total number of lines does not have to match the original. Save your translation and release the translated text. To do this, place the cursor on the edited text and choose

Edit SAPscript Text Release. When you release a translation, the system

automatically compares the number and sequence of the paragraphs in the translated text with the original. If the system determines any differences, it issues a warning. You can navigate within the text to check the cause of the warning, or you can ignore the warning. If you ignore the warning, the translation is automatically released. If a standard text has already been translated and released, this version is saved in a Print Workbench buffer. If this text is then changed later, you can compare the old version with the current version.

If there is a text version in the Print Workbench buffer, the symbol with quick info text Execute Version Comparison appears next to the text. To carry out a version

comparison, double-click on the symbol with the quick info text Execute Version Comparison. This action starts the comparison editor. This provides you with information about which lines have changed in the current version.

Result

Once all items have been edited and translated, the system changes the status of the application form automatically. The worklist is considered completed once all application forms have the status Translated.

Collection

Definition

A collection is an application form of the form type collection.



Use

You use collections to group application forms so that you can process them together. In a collection, you can group both application forms from the same form class, and also application forms from different form classes. You can define your own parameters for the technical components of a collection, for example, a specific printer. You can classify the individual application forms so that they are issued sequentially or bundled. You can process

collections using transaction EFRM (SAP menu: Print Workbench Application Form Process), as for application forms.

Structure

Each collection is assigned to exactly one form class. As for each application form, a collection‟s assignment to a form class defines how it belongs to an application. Using the indicator Cross-Form Class, you can control how application forms from other form classes can be included in a collection. In the user exit include and the user top include, you can define the form routines of the user exit or your own data definitions, just as for an application form. These includes are automatically included in the generated module. They are processed at runtime. For each collection the system generates a local module that contains the complete process flow for the collection. This module also contains the calls of the module EFG_PRINT for printing the application forms to be processed. During printing, the collection transfers the selection data to the included application form via the interface EFG_PRINT. This means that wherever you can specify an application form in Customizing, you can also define a collection. If you make changes to the collection, the form class, or the user includes, the module is regenerated.

A collection is not suitable for combining different components of the same document if there are direct dependencies or references between the individual parts, for example, a sequential page numbering or a connection at the end of the last page. Collections must not contain collections or links.

Example

Grouping of technically separated documents, such as an invoice and the attached payment form, or an e-mail with an electronic document attached.

Process Flow of Collections

Purpose

A collection enables a dynamic process flow when you print several application forms in the print event.

Process Flow

The process flow hierarchy of a collection is processed similar to that of an application form. This means that the system calls the individual nodes from top to bottom hierarchically, and depending on the node type, carries out one of the following activities:

● Print application form

● Create composition

● Call user exit

You can deactivate the node types composition and application form in Customizing so that these are no longer processed. You can also deactivate each node dynamically via user exit. Collections are called up externally like normal application forms via the modules



EFG_PRINT or EFG_PRINT_EXPANDED. You enter the print parameters when you call the collection, and, apart from the printer and the storage mode, you can no longer change the parameters in the collection. For each collection there is one generated module that contains the flow logic of a collection. When an application calls up a collection, it can transfer additional selection information for other form classes to the collection for processing. The import variable X_TABN_SEL_PER_FCLASS of category EFG_TABN_SEL_PER_FCLASS is available in module EFG_PRINT(_EXPANDED) for this. Usually, only the selection data for one form class is transferred. If you want to use an application form more than once in a collection, you have to identify each use uniquely with a simple character string. This is the only way that the macros MAC_DEACTIVATE and MAC_ACTIVATE, and the processes for processing the application form can identify the nodes. For each application form included in the collection, you can define conditions. These conditions determine whether the application form is processed. You can thereby make the issue of an application form dependent, for example, on the send type or the RDI or XSF output format. Using user exits and the macros MAC_DEACTIVATE and MAC_ACTIVATE, you can also make the issue of an application form or a composition dynamic. For each application form in a collection, you can define an output device and a storage mode. These specifications override existing settings; if the fields remain empty, the setting from the print parameters of the print process is retained. If there is no selection data (ranges table of module EFG_PRINT), various different constellations can occur in the process flow of cross-form class collections. If the application has already transferred selection parameters for several form classes when calling EFG_PRINT, this information is forwarded to the relevant application form dependent on the form class. However, if the application only transfers the selection parameters for one form class (standard case), an application form may have to be called without selection parameters. To improve your control of the behavior of the collection concerned, you can configure the behavior of the program as follows:

● Suppress output

● Trigger errors

● Call application form In this case, the application form or form class called must be able to derive the selection parameters required for data procurement from other information, for example, using the variable X_TAB_GENDATA transferred. This variable can be delivered in the collection in a user exit by filling table C-T_GENDATA.

If you use the form type Smart Forms, the application form called can return the selected data to the collection using the parameter Data Handling, either in addition to the output or instead of it. The data is transferred to the variable C-T_GENDATA in the following key:

TYPE = “PWB_DATA”

KEY = <Name of application form>

ATTR = <Identification>

REF_TO_DATA = Data reference from the deep data type of the form class

XSTRING = Data as XML, including the variables in the user top include

In a user exit, you can supplement the process flow of a collection with additional dynamic logic. To do this, you have to create a form routine with the required coding in the user exit include. Within a user exit, you can, for example, access the variable C and dynamically deactivate specific nodes using the macro provided.



Variable C

Definition

Global control variable in the generated function module.

Use

As in every application form, there is also a global control variable C in the generated print program of a collection. The control variable C contains information about the process flow; this information is either exported in user exits or is used for communication with the application forms.

Structure

Variable C has the DDIC type EFG_STRN_COLL_CONTROL and has the following structure:

Field Name Data Type Description

COLLECTION EFG_DTE_COLLECTION Collection

FORMCLASS FORMCLASS Form classes

SENDTYPE RF_SENDTYPE Send type for a document

LANGU LANGU Language key

RDI RF_RDI Raw Data Interface

XSF EFG_DTE_XSF Smart Form output format

COPYFLAG RF_COPYFLAG Document is a copy

MAIL_TITLE EFG_DTE_TITLE Title of a document/attachment

SENDTYPE_EXT EFGSENDTYPE_EXT External send type

CLIENT EFG_DTE_SRCCLIENT Source client for access to other clients

ARCHIVE_INDEX TOA_DARA SAP ArchiveLink structure (DARA)

ARCHIVE_PARAMS ARC_PARAMS Archive parameters

T_GENDATA EFG_TAB_GENDATA Table for generic data

OCL_ACTIVE EFG_OCLACTIVE Open/close logic is active

ITCPO ITCPO SAPscript output interface

ITCPP ITCPP SAPscript output parameter

RDIRESULT RDIRESULT SAPscript RDI: Return structure in Mode is not spool

SF_RESULT SSFCRESCL Smart Forms: Return at the end of form printing

T_OTF EFG_TAB_ITCOO Table for OTF data

T_SEL_PER_FCLASS EFG_TABN_SEL_PER_FCLASS Selections per form class

ADDITIONAL_PARAM EFG_DTE_ADDITIONAL_PARAM Print parameter for external control

XFP EFG_DTE_XFP Parameter for control of output format for PDF-based forms



The variables T_GENDATA and T_SEL_PER_FCLASS are used for communication and data selection for various application forms. They are transferred to the application form and can be queried in the C variable there.

Dynamic Modifications in the Process Flow

Use

The individual nodes of a collection are processed from top to bottom, in the same way as for an application form. The attributes and conditions assigned to the nodes are evaluated. You can use the following ABAP macros to control the process flow of a collection dynamically in user exits.

Features

You can use the following macros:

Macro Function Note

MAC_DEACTIVATE <NAME> <IDENTIFIKATION>

Suppresses the output of the node <NAME>

If the node is an application form, the identification in the collection differentiates between the different uses. If the identification is empty or the node is a different type, enter SPACE for this macro parameter.

MAC_ACTIVATE <NAME> <IDENTIFIKATION>

Reactivates a node <NAME> The node must be actively defined in the collection, which means that using the macro is only recommended if an active node was deactivated via user exit. The parameter <IDENTIFIKATION> acts in the same way as in the macro MAC_DEACTIVATE.

MAC_CANCEL <MSGTY> <MSGNO> <MSGID> <MSGV1> … <MSGV4>

Terminates the print transaction with an error message (to be specified)

MAC_CANCEL_SY_REPEAT <MSGTY>

Terminates the print transaction by returning the last error message, for example, when calling a module.

MAC_LEAVE Terminates the processing of the collection

No error message is triggered.

MAC_EXIT Triggers exit of the current context (for example, composition)



Interaction between Application Forms and Collections

If a collection calls up an application form, information about the context is transferred to the application form, together with data and selection information. The application form receives the information about the name of the calling collection via the variable C-COLLECTION and the identification via the variable C-IDENTIFICATION. You can also deliver additional information to the application form via the variable C-T_GENDATA. This could originate from other application forms processed in a previous step or, for example, from a user exit in the calling collection. An application form can also return data by creating lines of the type EFG_STR_GENDATA in a user exit for processing later in another application form. You have to insert these lines in the global export parameter Y_TAB_GENDATA or the global field symbol <Y_TAB_GENDATA>. In cross-form class collections, you can also control the selection options transferred for the application forms called via the parameter C-T_SEL_PER_FCLASS. If the line for the respective form class was not transferred by the calling application, you have to add it to this table. This is the only way the form class can recognize it.

Send Type e-mail

Definition

Sending correspondence by e-mail

Use

If you do not use the external data processing via RDI/XSF for the send type EMAIL, the printer and spool control of the system does not execute the output; instead, the system creates an e-mail object from individual form components and forwards this directly to the SAPconnect interfaces. You define the individual parts for an e-mail in a composition. These are usually a text and one or more attached documents. You can use a composition to group and bundle application forms. If different application forms are not called up within one composition, the logical connection in the e-mail is not created. You can use the indicator Attachment to control (for send type EMAIL) whether a document is attached as PDF file to an e-mail, or whether it is converted into text and inserted in the header area of the e-mail.

Using user exits you can attach Business Communication Service documents to an e-mail. The BCS documents must be attached in a composition to the global table G_TAB_BCS_ATTACHMENTS. As line time, the table has the class CL_DOCUMENT_BCS. This means that you have to create and attach instances of this class in a user exit.

Data Type EFG_TAB_GENDATA

Use

You use table type EFG_TAB_GENDATA to flexibly transfer data between different application forms involved in the printing process and the superordinate collection.

Structure

The related data type EFG_STR_GENDATA has the following structure:



Field Name Data Type Description

TYPE EFG_DTE_GENDATA_TYPE Type ID for data

KEY EFG_DTE_GENDATA_KEY Key for data ID

ATTR EFG_DTE_GENDATA_ATTR Additional attribute

REF_TO_DATA EFG_DTE_REF_TO_DATA Reference to data

XSTRING EFG_DTE_GENDATA_XSTRING RAWSTRING for XML data

The fields TYPE, KEY, and ATTR identify/attribute the data record. You can assign these fields as you require. The field TYPE identifies a component or application. For example, PWB_DATA identifies the data selected in an application form. The field KEY identifies an object below the information in TYPE (for example, the name of the application form). In the field ATTR, you can define additional attributes or information. The fields REF_TO_DATA and XSTRING contain the data previously determined:

● REF_TO_DATA is an ABAP data reference that you have to remove before accessing the data. For detailed information, see the documentation for the ABAP Editor

(transaction ABAPHELP) ABAP Programming Language Reference. You can determine the ABAP/DDIC type dynamically using ABAP methods or using the information in TYPE and KEY. In the case of PWB_DATA, the referenced data type is the highest complex DDIC type in the form class.

● The field XSTRING transports XML data. If TYPE = PWB_DATA, this means that you configure the data of the highest complex data type of the form class and all global variables that are defined in the user top include of the application form here. To do this, use the ABAP command CALL TRANSFORMATION. Before further processing, you can also use this command to reconvert this data into ABAP variables.

Data Type EFG_TABN_SEL_PER_FCLASS

Use

In order to carry out cross-form class processing in collections, you must be able to transfer or hold selection options for several form classes simultaneously. Table type EFG_TABN_SEL_PER_FCLASS carries out this function.

Structure

Table type EFG_TABN_SEL_PER_FCLASS has the structure EFG_STRN_SEL_PER_FCLASS. The structure EFG_STRN_SEL_PER_FCLASS consists of the field FORMCLASS and the selection table EFG_STRN_SELECTION. This selection table contains the selection and import parameters (for example, ranges tables) for the module EFG_PRINT.

Calling Form Printing in ABAP Programs

Use

An application form is a configuration object from which a runtime object in the form of a function module is generated. The following is a description of how the runtime object is called from an ABAP program to print an application form.



Integration

Form printing is called exclusively via central interfaces of the Print Workbench.

Activities

The modules EFG_PRINT and EFG_PRINT_EXPANDED are available. Use module EFG_PRINT in individual print processes and EFG_PRINT_EXPANDED in mass printing. The difference is in the use of send control, which is triggered in the module EFG_PRINT_EXPANDED.

Module EFG_PRINT

Definition

The module EFG_PRINT reflects the central interface for printing an application form. The parameters of the module contain

● All controlling information for the Print Workbench (for example, application form, form class)

● Control information for the print process (for example, output formats, ITCPO)

● Information for the data procurement of the form class (ranges tables)

The call of the module is independent of the form, the form class, and the form tool used (SAPscript, Smart Form, or PDF-based form).

Structure

The interface of the module consists of the following parameters:

Import parameters

X_PRINTPARAMS EPRINTPARAMS Structure of the print parameters

X_ARCHIVE_INDEX TOA_DARA Archive information per document (optional)

X_ARCHIVE_PARAMS ARC_PARAMS General archive information (optional)

X_DIALOG (Indicator) Execute dialog for print parameters (optional, default: SPACE)

X_RECIPIENT SWOTOBJID Object handle for recipient (optional)

X_SENDER SWOTOBJID Object handle for sender (optional)

Export parameters

Y_PRINTPARAMS EPRINTPARAMS Print Workbench result structure

Y_RDI_RESULT

RDIRESULT Result of RDI print

Y_PRINTPARAMS

EPRINTPARAMS Print Workbench result structure



Y_SF_RESULT SSFCRESCL Result of printing by Smart Form

Table parameters

XT_RANGES<number> (10)

EFG_RANGES Ranges table for interpretation of data selection in form class

YT_OTF_DATA ITCOO OTF data returned (if required by application)

The most important control information for printing is in the import structure X_PRINTPARAMS (for example, application form, printer). The user can also set or modify these by calling the module EFG_GET_PRINT_PARAMETERS.

The archiving data that belongs to the application (for example, document type, BOR object type, BOR object ID) is transferred in both import structures X_ARCHIVE_INDEX and X_ARCHIVE_PARAMS; without this data, optical archiving of correspondence is not possible. You can also use module EFG_GET_ARCHIVE_PARAMS to fill these structures. Both object reference IDs X_RECIPIENT and X_SENDER are of the type RECIPIENT and must be created with the BOR methods first.

You can only print application forms that have the status Active. If the module EFG_PRINT is called, first the status of the form is checked. If the status is not Active, an activation of the form and generation of the related print program are triggered.

Module EFG_PRINT_EXPANDED

Definition

The module EFG_PRINT_EXPANDED is an extended variant for calling form printing in the Print Workbench. Above all, the module is designed for mass printing, while the module EFG_PRINT should be called for individual printing or online printing. In comparison to the module EFG_PRINT, you can use the module EFG_PRINT_EXPANDED to change the print parameters with the send control or send the outgoing correspondence in different ways (for example, as letter and as e-mail).

Structure

The interface of the module consists of the following parameters:

Import parameters

X_PRINTPARAMS EPRINTPARAMS Structure of the print parameters

X_ARCHIVE_INDEX TOA_DARA Archive information per document (optional)

X_ARCHIVE_PARAMS ARC_PARAMS General archive information (optional)

X_SENDCONTROL SENDCONTROL Send control (optional)

X_RECIPIENT SWOTOBJID Object handle for recipient (alternative to X_REC_ADDR and X_REC_PERSNUMBER) (OPTIONAL)

X_REC_ADDR AD_ADDRNUM Address number of recipient



from central address management (optional)

X_REC_PERSNUMBER AD_PERSNUM Person number from central address management (optional)

Export parameters


Table parameters

XT_RANGES<number> (10)

EFG_RANGES Ranges table for interpretation of data selection in form class

You define the send control in the Customizing of the Print Workbench. It enables you to change the technical print parameters transferred in accordance with the setting in the send control. This enables you to send the same correspondence several times using different send types.

Print Parameter Structure EPRINTPARAMS

Definition

In all programming interfaces of the print workbench a structure of the type EPRINTPARAMS is used. It contains all relevant control fields that are relevant for the Print Workbench itself or for SAPscript or Smart Forms.

Structure

The structure EPRINTPARAMS consists of two parts:

● Structure EFG_PRINTPARAMS of the Print Workbench

● The structure ITCPO relevant for the form tool (SAPscript/Smart Forms/PDF-based forms)

Structure of EFG_PRINTPARAMS

DEVICE Device type for SAPscript/Smart Forms/PDF-based forms

● PRINTER for normal print output (default)

● MAIL for other send types (e-mail, fax)



RDI RDI indicator for output via SAPscript

● <space> = Normal output (OTF)

● X = Output al RDI (via spool)

● X = Output as simple RDI (via spool)

● I = output as RDI-IDoc

● * = Specification in SAPscript form applies

FORMKEY Name of application form

FORMKEY_RDI (Used externally: Name of application form for RDI)

DELAYED_PRINT Indicator: Creation of print request, no direct print

LANGU Language of form

TEST_MODE Indicator: Test mode

DEBUG Indicator: Debugging mode when calling the generated module

SENDTYPE Send type:

● PRINTER = Correspondence as printed letter

● EMAIL

● TELEFAX

● RMAIL = SAP internal mail

REC_ADDR (Internal use: ID of addressee from central address management)

REC_STRING (Internal use: Address as string)

SEND_ADDR (Internal use: Sender address as string)

COPYFLAG Indicator: Is a copy

REC_PERSNUMBER (Internal use: ID of person number from central address management)

LAST_DOC Last document in mass case (obsolete, should no longer be used)

LAST_DOC_ACT Output of spool request at the end of the print process

OCL_ACTIVE Open/close control is active

SENDTYPE_EXT External send type

NO_ACTIVATION Indicator: Suppress activation



XSF XSF indicator for output via Smart Forms:

● <space> = Normal output (OTF)

● X = Output in XSF format

● D = Output in XDF format

● * = Specification in Smart Form applies

GET_XSF Indicator: Return XSF/XDF data to calling application

NO_OPEN_FORM Is obsolete and should no longer be used.

NO_CLOSE_FORM Is obsolete and should no longer be used.

ADDITIONAL_PARAM Custom parameters for controlling the print process

XFP Indicator for the output format for PDF-based forms (raw data)

● <space> = Normal output (PDF)

● X = Output in XFP format with context evaluation

● X = Output in XFP format without context evaluation

The most important ITCPO print parameters for the Print Workbench print processes

TDDEST Output device (printer)

TDNEWID Force new output request

TDIMMED Output output request

TDFINAL Close output request

TDTITLE Name of output request

TDSUFFIX1 ID 1

TDSUFFIX2 ID 2

These print parameters are modified, in particular for mass printing, such that, for example, there is only one output request per run or per defined subunit of run. If the parameter LAST_DOC_ACT (Output after Last Document) is set, this prevents output requests that arise during a run being closed or printed (TDIMMED = TDFINAL = <space>). Instead, the individual documents are inserted sequentially in one or a few output requests and output in a closing event (EFG_PRINT_CLOSE).

Whether an existing output request is added or a new request opened depends on the different parameters. An output request is only added if:

■ The parameters TDDEST, TDTITLE, TDSUFFIX1, TDSUFFIX2 agree

■ The output request to be added has not been output or closed

■ The parameter TDNEWID is not set

■ The user creating the output request is the same

If one of the conditions listed above is not fulfilled, the system creates a new output request.



Although the related program interfaces use other structures, structure ITCPO is also used for Smart Forms and PDF-based forms. Since the fields are mostly identical, in the print transaction, the Print Workbench maps the fields of structure ITCPO appropriately.

Print Parameter Dialog EFG_GET_PRINT_PARAMETERS

Definition

The module EFG_GET_PRINT_PARAMETERS is a dialog that can be configured by the application. It enables you to enter the user-relevant print parameters for the Print Workbench and for SAPscript/Smart Forms.

Structure

You can set the following print parameters:

● Form (form class required)

● Output format SAPscript

● Output format Smart Form

● Indicator Output after Last Document

● Indicator Deactivate Open/Close Control

● All print parameters from SAPscript (ITCPO), for example, printer

● Choose between immediate print or creation of a print request

Apart from the printer, all print parameters are optional. The module has the following parameters:

Import parameters

X_PRINTPARAMS EPRINTPARAMS Input structure of print parameters

X_ARCHIVE_BOR_OBJECT SAEANWDID BOR object type for archiving (optional)

X_ARCHIVE_ARC_OBJECT SAEOBJART Document type (archive) (optional)

X_ARCHIVE_OBJECT_ID SAEOBJID ID of BOR object (optional)

X_NO_DELAYED_PRINT (Indicator) No option for print requests visible (optional, default ‘X’)

X_NO_FORMKEY (Indicator) No form input (optional)

X_NO_ARCHIVE (Indicator) No archiving field (optional)

X_CHECK_ARCHIVE (Indicator) Check archiving parameters (optional)

X_FORCE_SAPSCRIPT (Indicator) Force SAPscript print parameters dialog box (optional)

X_NO_PREVIEW (Indicator) No print view possible



(optional)

X_ONLY_PRINTER (Indicator) Only show printer as input field (optional)

X_NO_LAST_DOC (Indicator) Output after last document (optional)

X_NO_DIALOG (Indicator) Suppress dialog (only provide user defaults) (optional)

X_ONLY_SENDTYPE_PRINTER (Indicator) Only offer send type Print (optional)

X_NO_OCL_ACTIVE (Indicator) Suppress open/close optimization active option (optional, default ‘X’)

Export parameters


Y_ARCHIVE_INDEX TOA_DARA Archive information (1)

Y_ARCHIVE_PARAMS ARC_PARAMS Archive information (2)

Initializing and Closing Print Transactions

Use

In mass printing, SAP recommends that you initialize and complete the print process both before and after the operational calls of the modules EFG_PRINT or EFG_PRINT_EXPANDED. The module EFG_PRINT_INIT initializes the print process and makes sure that the application form used and transferred are activated if necessary. If errors occur, the incorrect application forms are reported to the calling application as not capable of being activated. The module EFG_PRINT_CLOSE postprocesses the output requests that have expired during the print process (usually outputs them) and initializes the internal data buffer in the Print Workbench.

Features

The module EFG_PRINT_INIT has the following structure:

Import parameters

X_ITCPO ITCPO Print Parameters

X_TAB_FORMKEY EFG_TAB_FORMKEY Table of application forms (optional)

X_FORMKEY FORMKEY Application form (optional)

X_FORMCLASS FORMCLASS Form class (optional)

X_TAB_FORMCLASS EFG_TAB_FORMCLASS Table with form classes (optional)

Export parameters

Y_TAB_ERRORFORMS EFG_TAB_ERRORFORM Table with incorrect



application forms

The module EFG_PRINT_INIT has the following structure:

Import parameters

X_FLG_OUTPUT (Indicator) Triggers output of spool requests

X_FLG_FINALIZE (Indicator) Close output requests

X_FLG_CLEAR_SPOOLIDS (Indicator) Delete spool IDs from main memory

Export parameters

Y_TAB_SPOOLIDS TSFSPOOLID Table of expired output requests in main memory

Open/Close Optimization

Use

One of the main requirements of the Print Workbench and the print processes defined by the applications is performance. In individual printing, creating a document means calling the complete SAPscript and Smart Form API. In the case of SAPscript, this takes place as follows:

OPEN_FORM

START_FORM

.... <Texts>

END_FORM

CLOSE_FORM

If you work with the same print parameters and want to output the individual documents in the same output request, you do not need to call the OPEN/CLOSE_FORM modules. The calls have such a negative affect on performance that for each CLOSE_FORM, the output request used is not noted and for the subsequent OPEN_FORM, the system has to determine from all of the existing output requests on the database. The Print Workbench is set up so that if the calling application so requires, the calls of OPEN/CLOSE_FORM can be suppressed. The performance benefit is between 10% and 30% depending on the number of output requests in the system.

Features

If the calling application has set the indicator OCL_ACTIVE in the print parameter structure when calling the print modules EFG_PRINT or EFG_PRINT_EXPANDED, the Print Workbench executes the open/close optimization internally.

Due to the considerable improvement in performance described above, SAP recommends that you activate this function. However, since the change to the control logic can lead to undesired side effects under some circumstances, you must be able to parameterize the function. To do this, the Print Workbench provides you with a separate field in the print parameter dialog EFG_GET_PRINT_PARAMETERS. The application has to make it visible and make a default entry.



Printing Processes and Printing Scenarios

Purpose

Strictly speaking, the Print Workbench is not a tool for processing forms. It controls and standardizes the processes for transferring the application data to the form tool selected by the user to process forms. From this point of view, the Print Workbench provides a standardized infrastructure for processes that take place during printing triggered by an application and that you can configure accordingly.

The Print Workbench supports all form tools provided by SAP equally and guarantees SAP customers the free selection of a form tool with no functional restrictions.

Process Flow

From the view of the SAP application, how the data is used is neither known nor relevant. You can prepare the application data as a form in the SAP system using functions of the Print Workbench, either with SAPscript, Smart Forms, or PDF-based forms or process the data further externally via a raw data interface. If the data is processed further externally, it is transferred from the SAP system to SAPscript via the RDI interface, or to Smart Forms via XSF or XDF, and can then be processed according to local requirements using special software.

Printing Processes and Output Formats

Smart-Forms SAPscript-

form

Output

formats

RDI

(SAP Spool/IDOC)

XSF/XDF

(SAP Spool)

Output Management System (OMS)➔ External printing• Scenarions for mass printing

• Postprocessing (use of strike codes,OMR)• Postage determination/use of franking mach ines

• Information about reduction of postage• Editors for layout creation

Data procurement

and integration of

layout tool

Layout

&

Design

Application form

Generated print program(function module)

PDF-based

form

Categoryof applicationform:

PDF-based form

SAP Smart FormSAPscript

Logicalprinter

XFP

(SAP Spool)

OTF

(SAP Spool)

PDF

(SAP Spool)

Logicalprinter

Logicalprinter or IDoc

System formassprinting

RDI, XSF, and XFP

are officialcertifiable SAP

interfaces for theextraction of raw

data

The SAP system has no control for external print logistics, such as postage optimization or control of printing processes. Outside of the SAP system, form data and other data is increased, or the correspondence categories are sorted and mixed. For large volumes of



data, SAP therefore recommends external processing by means of an output management system.

Further Processing of Data in External Systems

Use

In mass processes, the data is usually not actually processed within the SAP system. It is processed outside of the system using external software.

Integration

Depending on the form tool (SAPscript, Smart Forms, PDF-based forms) you can use separate data interfaces (RDI, XSF/XDF, XFP) that are an integrated component of the respective form tool and that mutually exclude each other.

Prerequisites

To process data externally, you have to configure logical output devices in the central SAP printer management (except in RDI IDoc (SAPscript) mode); these forward the files that result to an external address.

Features

Depending on the form tool used, you can use the following raw data variants:

Form Tool Variants Output Channel Certifiable Comment

SAPScript RDI IDoc Yes

RDI Spool Yes

Simple RDI Spool No Compressed variant (pure data)

Smart Forms XSF Spool Yes Meta information of layout document

XDP Spool No Pure data extraction

PDF-based forms XFP (1) Spool Yes With PDF-based form context evaluation

XFP (2) Spool Yes Without PDF-based form context evaluation

The supplement Spool defines that the data output is controlled by SAP spooling and the logical output devices. You can define logical output devices in the spool administration and define additional instructions, such as target directories or processing commands for the file.

SAP provides special device types for this (for example, RDI and XSF). See also the relevant SAP Notes (for example, SAP Note 6753).

Activities

To select one of the data formats supported, specify the option in the print options. You should also optimize the application forms used for the respective raw data variant.



Archiving/Connection to ArchiveLink

Use

If a document is dispatched, it is often necessary to archive a copy of the document. Documents are archived in an external optical archive and connected to the SAP system via SAP ArchiveLink. In SAP ArchiveLink you make all the settings that classify a document and make it accessible for an application. For archiving, the Print Workbench uses the standard interface of SAPscript or Smart Forms, which means that communication with the SAP ArchiveLink is exclusively via these forms.

Integration

SAP ArchiveLink is called directly during the print process with the form created completely dynamically provided you have made the system settings necessary for SAP ArchiveLink (document types, links, archive connection).

Prerequisites

SAP ArchiveLink must contain all the required settings, such as document types, links between document types, and BOR object types and archives. The document types used usually correspond to form classes of the Print Workbench, and are generally defined in the attributes.

Features

The following different scenarios exist:

Preparation in the SAP system with no external processing of data

SAPscript, Smart Forms, and PDF-based forms support parallel (asynchronous) optical archiving of documents during printing. The formatted document is sent via SAP ArchiveLink to an external archive and archived there. During the print process, the SAP system sends an archiving command to the archive system containing both the document to be archived in a particular format (for example, PDF), and the following data for the logical link:

● Client

● BOR object type

● BOR object ID

● Archive system ID

● Document Type

If archiving is complete, the archive generates a 40 character ID and, via RFC or BAPI, creates a link entry in the SAP system with the data received. This link entry represents the logical link between a business object (for example, an invoice document or a contract account) of the SAP system and the technical object in the archive.

Archiving during form output in SAP system



Formatted document, example, PDF

BOR objectBOR ID

Document typeArchive ID

Smart Forms

SAPscript

BOR object

BOR IDDocument typeArchive ID

+ Archive document ID

SAP Archive

ASYNCHRONOUSASYNCHRONOUS

Archive Link

Formatting by external system

If the document is not formatted in the SAP system and a data format for external processing is used instead, the outbound document from the SAP system is not archived, and the external system also has to control the archiving as well as formatting the document. This means that the external system has to carry out the functions described above. The external system has to send the required parameters to the archive so that the archive can create the link entry. The raw data must contain the archive parameters.

Activities

Activate the archiving by setting the archiving parameter Print and Archive (3) or Only Archive (2) in the dialog box Print Parameters. Once you have successfully activated archiving, you can access archived documents, for example, using the button Archived Documents in the respective application. The prerequisite for correct display of a document from the archive is the complete installation of the component SAP ArchiveLink in the SAP GUI of the relevant

presentation server, and of a corresponding viewer (such as Acrobat Reader for PDF documents).

Sending as e-mail or Telefax via SAPconnect

Use

You can send documents using various different send types. SAPconnect [Extern] is used for send types TELEFAX, EMAIL, SMS, or RMAIL (SAP internal send). SAPconnect is a standard application of the SAP system. If you choose a send type other than PRINTER, the document formatted by SAPscript is transferred to SAPconnect along with information, such



as fax number and e-mail address, needed for sending it. SAPconnect places the document in a send queue which is released for processing by an administrator or a program that runs periodically.

Prerequisites

● To ensure the correct functioning of the alternative send types, activate the

communication types in the SAP menu under Tools Business Communication

Office General Office Settings.

● Set the communication methods to SAPconnect. In the SAP menu, choose Tools

Business Communication Communication SAPconnect. Define the

communication nodes that define the route that a document sent to SAPconnect is to take. For detailed information about SAPconnect, see the documentation for the transaction.

● Maintain the user data for each communication type.

● Maintain the address data in the master data of the business partner for the communication types.

Features

Aside from the standard send type PRINTER, a document can also be sent via SAPconnect as a fax, e-mail, or internal r-mail. With regard to the use of raw data interfaces, you have to differentiate between the following scenarios:

● Preparation in SAP system (no raw data) In this case, the preparation is according to the standard procedure of SAPconnect. The document created is placed in the SAPconnect send queue and is transferred later to an external fax or e-mail server to be sent.

● Preparation by external systems (raw data) In this case, instead of control by SAPconnect , only a raw data flow is created. In this case, an external system must also take over sending the document. All parameters required must be integrated in the raw data flow. For this purpose, the Print Workbench provides the following fields in the C global variables in the generated programs of the application forms:

○ c-sendtype (Print Workbench send type (PRINTER, TELEFAX, EMAIL, RMAIL, SMS))

○ c-comm_type (SAPconnect communication type (FAX, INT, RML, PAG))

○ c-rec_address (recipient address as character string (telefax number, e-mail address))

○ c-send_address (sender address as character string (telefax number, e-mail address))

To be included in the raw data flow, customers must integrate these fields explicitly (dependent on the form tool).

Activities

You can define the send type in the dialog box Print Parameters. Specify the send type in the Send Type field. In the dialog box that follows, specify each address according to send type. If the address type has been maintained in the master record of the business partner associated with a transaction, this address is defaulted in the parameters.



Send Control

Use

Using send control you can use special print parameters, for example, using different send types (letter, fax, e-mail), to send an application form and/or to send multiples of forms.

Integration

You define the send control in the Customizing of the Print Workbench. For it to be relevant for the print process, the calling application must have named a send control in Customizing or in the master data.

Prerequisites

If you use archive mode 2 or 3, you must have configured the connected archive via SAP ArchiveLink. If the send type is not PRINTER, SAPconnect requires the correct setting.

Features

Dispatch control consists of control lines that each contain the following fields:

● send type (PRINTER, TELEFAX, EMAIL, RMAIL, SMS)

● Output format SAPscript (<BLANK>, *, X, I, S)

● Output format Smart Forms (<BLANK>, *, X, D)

● Output format PDF-based forms (<BLANK> X, R)

● Number of copies (number)

● Archive mode (1,2,3)

● Copy indicator (<BLANK>, X)

● Output device

● External send type

The send control overwrites on a field basis. This means that print parameters defined completely in the print transaction are overwritten by a send control on a field basis. For empty fields, the standard setting for the print transaction is used.

Activities

To use the send control, proceed as follows: ...

1. Define the send controls in Customizing for the Print Workbench in the activity Define Send Control.

2. Enter each send control to be used in Customizing or in the master data of the calling application.



Flexible Control and Modification of Print Parameters

Use

The complete set of print parameters specified for each print run is the basis for the complete run. However, under certain conditions, you may have to specify or default the print parameters individually. For this purpose, the Print Workbench provides various methods that you can use to modify the print parameters.

Features

You can use the following methods to default and modify the print parameters:

● User-specific default of certain parameters using SET/GET parameter IDs for the print parameter dialog.

Using user-specific SET/GET parameters, you can define certain print parameters as default, such as printer or RDI indicator. For more information, see SAP note 131277.

● Use of send controls

You can use send control to set certain print parameters, such as printer and send type. However, you can only use this method if the send control is integrated in the Customizing or master data of the application you are using. This is the only way that the required send control is used at the correct time. As standard, the send control is not defaulted in the print parameters.

● Use of customer enhancement EFG_PRINTPARAMS

You use this customer enhancement to default print parameters by means of ABAP. The enhancement contains three events or methods:

...

○ Print parameter dialog default

○ Print parameter dialog subsequent entry

○ In the print run

For details about using the individual events or methods, see the documentation for the customer enhancement EFG_PRINTPARAMS.

● Use of static exits in the application form

The generated print program of the application forms contains static user exits that you can use to specify the print parameters that are only relevant for Smart Forms or PDF-based forms.

Using the Print Workbench with Correspondence (CA-GTF-COR)

Use

If you do not want to print correspondence immediately, you can create requests for print transactions to carry out the print in a central run (for example, as parallel background job). The correspondence tool carries out this function. The correspondence tool is optimized for the standard sending of mass correspondence and provides the Print Workbench with a standard print process with numerous application and customer exits.



Integration

The correspondence tool is not integrated in the Print Workbench, it is only used by the Print Workbench. Most applications that use the Print Workbench use the correspondence tool before the print modules of the Print Workbench are called, to carry out collective and parallel printing and to standardize the print process.

Prerequisites

You can only use the correspondence tool if the application/component has implemented a corresponding connection to the correspondence tool.

Features

If the application supports the creation of print requests for correspondence, the Print Workbench offers the options Print Immediately and the option of creating print requests. When you create print requests, the system creates a request for the correspondence type concerned in the form of a correspondence container. These correspondence containers can then be processed and marked as printed in special print runs. For each correspondence container the Print Workbench is called up once. The correspondence tool provides the application and customer with various events for determining the following objects:

● Sender

● Receiver

● Language

● Send control

● Application form

● Address type

● Archiving ID

For more information about correspondence, see the documentation for Correspondence [Extern]

Using Print Action Records

Use

A print action record is a variable text or data supplement that is determined during print processing and can be integrated in form processing. A print action record is used if you also want to print out a variable text in a form, or if you want to send additional information to the recipient in the form of a flyer. In a print action record, you can define additional parameters, such as the validity or the maximum number of processing.

Features

A print action record consists of the following indicators and fields:

● BOR object type (key field)

● BOR object key (key field)

● Form classes

● From date



● To date

● Maximum number of processing times

● Frequency

● Priority

The search for related print action records must be integrated in the form class. This is usually displayed by an appropriate form level in the form class. The form level must also be integrated and active in the application form in which it is used. To create individual print

action records, choose Print Workbench Print Action Records Create in the menu. If you want to create several print action records simultaneously (mass processing), you have to create a report using the report SAPRISU_PRINTACTION_GENERATE delivered by SAP as a reference. The print action records are integrated in an application form either by means of a form level that corresponds to the BOR object of the print action record, or, alternatively, you can integrate the search for print action records in the user exits of an application form by means of the programming interface. If a print action record is determined during the printing transaction, if you use SAPscript, you can display the content immediately in the MAIN window or store it temporarily as a variable and then output it as a symbol. In the case of Smart Forms, the print action record must be saved as a variable and then output as symbol.

Print Action Records (Technical Background)

Features

Print action records are defined in the application table EPRINTACT and have the following key fields:

● FORMCLASS: Form class

● OBJ_TYPE: BOR object type

● OBJ_KEY: BOR object key

During the print transaction, the system searches for print action records with these keys. It also evaluates the following fields to process the print action records:

● TRIG_FROM: From date for processing

● TRIG_TO: To date for processing

● TRIG_COUNT: Total number for processing

● MODULO: Frequency (Example: 3 = every third time)

● TRIG_DONE: Number of completed operations

● LAST_DATE: Date of last processing

A print action record contains definitions such as which text is to be printed or which flyer ID is to be used. For this purpose, fields have been provided in each case for five standard texts and ten flyer IDs. The following fields concern the five standard texts:

● TDNAME1 to TDNAME5

● TDID1 to TDID5

● TDSPRAS1 to TDSPRAS5



For the ten flyer IDs, the fields FLYERID1 to FLYERID10 are decisive. The texts or flyers to be selected are defined in the Customizing table EPRINTACTF (Define Flyer/Standard Texts for Print Action Records). You maintain the entries in this table in the Implementation Guide, the underlying transactions in transaction SO10. In the EPRINTACTF table you can either define an ID for a flyer or the key fields for a SAPscript standard text. During printing, the function module ISU_S_PRINTACT_SEARCH_UPDATE can find and process a print action record. This function module is called up using the above keys and processes all valid print action records for these keys. The module returns a table with these print action records.

Function Modules for Programming

Use

● ISU_S_PRINTACT_SEARCH_UPDATE This module determines appropriate print action records for the keys described under DDIC. If the module finds these print action records, it prints, as a standard, the texts which belong to them and raises the number of times they have been processed by 1. You can control the function of the module explicitly using its import parameters:

○ X_PRINT Texts are printed (only recommended for SAPscript).

○ X_UPDATE Print action records are updated

● ISU_S_PRINTACTION_TEXT_PROVIDE This function module provides the text for a print action record. You can use this text for any further processing.

● ISU_S_PRINTACT_PRINT_UPDATE This module determines the relevant text for a print action record and prints it. It also raises the number of times that print action record has been processed by 1. In the same way as function module ISU_S_PRINTACT_SEARCH_UPDATE, you can also control the explicit function externally.

Customizing

Use

You maintain the system settings for the print action records in the IMG under Print

Workbench Print Action Records.

Activities ...

Choose Define Flyer/Standard Texts for Print Action Records and maintain the standard texts and flyers that can be selected for the print action records. The standard texts that you define here must be maintained using transaction SO10 (standard text maintenance). If texts or flyers that you set in the creation reports in the print action records are not defined here, this can lead to errors in maintaining the print action records. If you use a text that has not been entered in this table in a print action record, it is also not displayed by the above-mentioned transactions and when you save the print action record, it is deleted from the record completely.

Choose Define Links between Object Types and Form Classes and define the supported combinations of form class and BOR object types for the print action records. When delivered, this Customizing table already contains the combinations found in the form classes delivered. If you need additional combinations, you can enter these here. If you want to incorporate print



action records in an application form yourself, you have to make an entry for the combination BOR object/ form class here.

Individual Creation of Print Action Records

Use

A print action record is created if a letter is to contain some additional item of information. You can define this information in a print action record.

Features

The creation of a print action record is usually triggered by a business transaction. There are therefore different ways of creating a print action record. Print action records are determined and evaluated when application forms are printed. In order for the system to determine print action records, the correct search routines must already be in place in the application forms. The following criteria determine the validity of a PAR (print action record):

● From date

● To date

● Frequency

You can assign an individual text to each print action record. In a print action record, you can also set texts or flyer indicators for further processing. These text or flyer indicators are defined in Customizing for print action records.

Activities

You can create print action records as follows:

1. In the menu under Print Workbench Create Print Action Records.

2. With the Create Print Action Record function in an application.

3. By calling the Create method for BOR object type BUS4402 (print action record).

Choose one of the options from the list above and specify the properties of the print action record. If required, create an individual text. However, you can only create an individual text if you have deleted the print action record.

Mass Creation of Print Action Records

Use

If an additional variable text is to appear on multiple forms, a print action record must be created for each form or each form level on which text is to be printed. This takes place with a report maintained by the user and designated for a specific purpose. The prerequisite for using the report is that the search function for print action records has been implemented in the application form.

Prerequisites

Copy the sample report SAPRISU_PRINTACTION_GENERATE and adjust it to meet your requirements.



Features

By adjusting the report, you determine why the print action records are created and the entities to which they belong.

Activities

Once you have copied and adjusted the report, run it. You can then use the print action records for selection.

Reorganization

Use

To keep the number of print action records to a minimum, you should carry out a reorganization at regular intervals.

Features

Using this transaction you can select print action records and either output them in a list or delete them immediately. If you delete directly, you can use the indicator Dialog Indicator to control whether there is a security prompt before deletion.

Activities

Choose Print Workbench Print Action Records Selection List. Enter the parameters

(selection restriction, deletion, and dialog indicator) and choose Program Execute.

Integrating Print Action Records in Application Forms

Use

Use a print action record if you want to print a variable text on all forms. Variable means that the text changes over time (for example, information or a note that is temporarily valid).

Integration

Print action records are either integrated into the form class belonging to an application form with form levels or must be implemented using user exits. In the first case you have to leave the level in question in the hierarchy. The texts behind the print action records are printed automatically.

Features

If the print action records are integrated in an application form, the printing of the related texts can be transferred immediately or you can decide how and which part of the print action records is to be printed. In the simplest variant, in which the print action records exist as a level in the application form, printing begins automatically.

Application forms with print action records already included

If the print action records have been implemented in the form of form levels in the form class, the form levels can be left in the hierarchy. If you want to prevent the texts in a print action record from being printed automatically, set



global parameter C-PA_PRINT to <blank> in the exit before loop of the form level. In this case you have to print the text yourself.

Application forms without print action records

To integrate print action records in an application form that have not been implemented in the form of a level in the form class, you have to perform the following steps: ...

1. Decide for which form level of the form class hierarchy you want to find print action records. It is important that you search for an entity that has a corresponding object type in BOR.

2. In table EPRINTACTT (transaction SM30), maintain an entry with the following keys: AREA = „Z„, OBJ_TYPE = <BOR object>, LFDNR = <document number>, and FORMCLASS = <form class>

3. Determine the position of the call of the print action records in the application form. The position corresponds to the form level.

4. Create an exit during loop for the form level in question and, from there, call function module ISU_S_PRINTACT_SEARCH_UPDATE. Specify parameters X_OBJ_TYPE with the BOR object mentioned above, X_FORMCLASS with the current form class, and X_OBJ_KEY with the entity key from the current form, (for example, WA_CONTR_ACCT-VKONT for a contract account) for the call. The parameters X_PRINT and X_UPDATE determine whether a print takes place or whether the print action records are updated. Usually you should set both indicators.

5. If you do not want the text to be printed automatically, evaluate the table of the print action records received.

In mass processing you have to create the print action records with a report based on report SAPRISU_PRINTACTION_GENERATE. Specify the parameters above (form class, BOR object, object key) in the appropriate position in the report. In addition to mass processing, you can also create single print action records that have a generic effect on all combinations of form class and BOR object. To do this, manually create a print action record in transaction EPA1 and define a dummy object for OBJ_KEY. Then enter this dummy value in parameter X_OBJ_KEY when you call the module ISU_S_PRINTACT_SEARCH_UPDATE in the above-mentioned exit.