Print Workbench

Release 620

SAP Online Help

16.01.2004

Copyright
Copyright 2003 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, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix and Informix Dynamic ServerTM are trademarks of IBM Corporation in USA 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, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML 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. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com 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 trademarks of their respective companies.

Print Workbench

620

SAP Online Help

16.01.2004

Icons
Icon Meaning Caution Example Note Recommendation Syntax

Typographic Conventions
Type Style Example text Description Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options. Cross-references to other documentation. Example text EXAMPLE TEXT Emphasized words or phrases in body text, titles of graphics and tables. Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE. Screen output. This includes file and directory names and their paths, messages, source code, names of variables and parameters as well as names of installation, upgrade and database tools. Keys on the keyboard, for example, function keys (such as F2) or the ENTER key. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

Example text

EXAMPLE TEXT Example text <Example text>

Print Workbench

620

SAP Online Help

16.01.2004

Print Workbench Form class Properties and Attributes Form Class Library Smart Form Indicator Test Print Indicator Object Type (BOR) Document Type Status Package Assignment and Transport Documentation Hierarchy Form Levels 1:1 levels Structure Logic of the Hierarchy Source Text Display of the Form Class Hierarchy Form Class Library Automatically Generated Variable Declarations READ Subroutines GET Subroutines FILL Subprograms TOP Area for Own Variables Subroutine TEST_PRINT Subroutine SET_ARCHIVE_INDEX Subroutine PROCESS_AFTER_DOC Subroutine PROCESS_AFTER_FORM Controlled Terminations in Exception Situations Processing Form Classes Creating Form Classes Creating Form Levels Creating 1:1 Levels Enabling Test Prints Example: Flight Notification Application Forms Properties and Attributes Form Classes

7 8 9 9 9 10 10 10 10 11 12 12 13 14 14 16 16 17 18 18 19 20 21 22 23 23 24 25 25 26 27 27 28 28 29 29

Print Workbench

620

SAP Online Help Form Types SAPscript/Smart Forms User Includes Start/End Exit Generated Modules Languages Status The Hierarchy of an Application Form Form Levels 1:1 levels Texts (SAPscript Only) Flow Logic and Processing Definition of the Hierarchy Interaction of Application Forms with SAPscript/Smart Forms Access to Data Read Control Variable C Processing Application Forms Creating Application Forms Inserting Variables in Texts (SAPscript Only) Creating a Summation Reading Additional Data from the Database Dynamic Intervention in the Process Flow in User Exits Transferring Own Data to Smart Forms Optimizing Performance User Exits in Application Forms Declaration of Own Data Areas Exit Before loop Exit During Loop Exit After loop Text Exit (SAPscript only) Start/End Exit Triggering Controlled Terminations Utilities Test Print Breakpoints and Debugging Copying from Clients Uploading and Downloading Application Forms Creating References

16.01.2004 30 30 31 31 32 33 33 34 36 36 36 36 37 38 39 41 42 42 43 44 44 45 45 46 47 47 48 49 50 50 50 51 51 52 53 53 54

Print Workbench

620

SAP Online Help Finding Variables Form Information Administration and Transport Mass Processing Mass Activation Transporting Application Forms Using References Versioning and Archiving via Upload/Download Translating Application Forms Worklist Creating Worklists Processing Worklists Calling Form Printing in ABAP Programs Module EFG_PRINT Module EFG_PRINT_EXPANDED Print Parameter Structure EPRINTPARAMS Print Parameter Dialog (EFG_GET_PRINT_PARAMETERS) Initializing and Closing Print Transactions Open/Close Optimization Print Processes and Print Scenarios External Further Processing of R/3 Data Archiving/Archive Connection with ArchiveLink Sending as e-mail or Telefax via SAPconnect Dispatch Control Using the Print Workbench with the Correspondence Tool Using Print Action Records Print Action Records (Technical Background) Function Modules for Programming Customizing Individual Creation of Print Action Records Mass Creation of Print Action Records Reorganization Integrating Print Action Records in Application Forms

16.01.2004 55 55 56 56 57 57 58 59 60 60 63 63 64 65 66 67 70 71 72 73 74 74 76 78 79 79 80 81 81 82 83 83 84

Print Workbench

620

SAP Online Help

16.01.2004

Print Workbench
Purpose
The Print Workbench is a central development environment for creating standardized outgoing correspondence. For the configuration and layout of correspondence forms, the Print Workbench uses the SAP standard components for form layout SAPscript or Smart Forms. The Print Workbench is divided into the following subobjects: Form classes Form classes are defined by SAP applications and contain a modeling and access instructions for all data that belongs to an application or to an application process. Based on the form classes you can create application forms in which you can 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 exists to adjust the application forms to your requirements. The form creation is simplified by numerous auxiliary functions.

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

Integration
The Print Workbench (CA-GTF-PWB) is a component of the Web Application Server (Release 6.20) and can be used by every SAP application with no further prerequisites. In the Print Workbench you can use Smart Forms (BC-SRV-SSF) and SAPscript (BC-SRV-SCR) alternately. Print Workbench Architecture

Print Workbench

620

SAP Online Help

16.01.2004

Application Call at runtime (EFG_PRINT) with correspondence request

delivers

Layout & Design SAPscript Preparation Data interfaces

Generated Print program

Data : ... Select * from ... Call Smart Forms or SAPscript API

Form type

Application Form
Hierarchical display of processing logic

Form class
Data hierarchy

created
Form class library (ABAP Report)

SAP

Data (hierarchy) Data structures Access coding (if necessary)

Event-oriented processing User exits for all events Texts (only SAPscript) Form type controls whether procesing via Smart Forms or SAPscript

SAP customer

Form class
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 datamodel 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.

Print Workbench

620

SAP Online Help

16.01.2004

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 Forms 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 Indicator

Definition
The Smart Form indicator shows whether a form class is designed for using Smart 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. If the indicator is not set, you cannot use the form class for Smart Forms.

Print Workbench

620

SAP Online Help

16.01.2004

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 65]. 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.

Print Workbench

620

10

SAP Online Help The DDIC structures assigned to a form level or 1:1 level are active.

16.01.2004

If the indicator Smart Forms is set in the form class, the system also checks whether all generated DDIC types specified in the form levels exist and 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, a transport request is queried or 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 form class concerned cannot be transported.

Print Workbench

620

11

SAP Online Help

16.01.2004

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, reflects 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.

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.

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

Print Workbench

620

12

SAP Online Help

16.01.2004

PWB_FLIGHT_NOTIFICATION

Flight confirmation to customer

CUSTOMER

Customer

Form level
5 BOOKING R G Booking

FLIGHT

R G Flight

1:1 level

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 a one GET subprogram for each form level. This GET subprogram procures the n

Print Workbench

620

13

SAP Online Help

16.01.2004

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
In this way, a form level is always processed according to the same 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

Print Workbench

620

14

SAP Online Help

16.01.2004

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.

PWB_FLIGHT_NOTIFICATION

Flight confirmation from customer

CUSTOMER

Customer

BOOKING

R G

Booking

FLIGHT

R G Flight

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.

Print Workbench

620

15

SAP Online Help

16.01.2004

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

Definition
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.

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

Structure
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

Integration
In the list you can doubleclick 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

Print Workbench

620

16

SAP Online Help 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)

16.01.2004

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.

Print Workbench

620

17

SAP Online Help

DATA: T_FLIGHT TYPE TABLE OF SPFLI WITH HEADER LINE. *******************global workarea declarations************************* DATA: WA_CUSTOMER DATA: WA_BOOKING DATA: WA_FLIGHT TYPE SCUSTOM TYPE SBOOK TYPE SPFLI . . .

16.01.2004

**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.

Print Workbench

620

18

SAP Online Help

16.01.2004

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 USING x_customer REFRESH yt_booking. LOOP AT t_booking WHERE customid = x_customer-id. APPEND t_booking TO yt_booking. ENDLOOP. ENDFORM. "GET_CUSTOMER_BOOKING TYPE scustom. STRUCTURE sbook

FILL Subprograms
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.

Print Workbench

620

19

SAP Online Help

16.01.2004

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 y_flight CLEAR y_flight. READ TABLE t_flight INTO y_flight WITH KEY carrid = x_booking-carrid connid = x_booking-connid. ENDFORM. " FILL_BOOKING_FLIGHT TYPE sbook TYPE spfli .

TOP 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 in the TOP area are copied to the corresponding TOP include of the function group when the print program is generated for an application form. This means that the instructions are valid for all subroutines.

Print Workbench

620

20

SAP Online Help

16.01.2004

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 .... *data: .... " own type-pools " 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 the user terminates, set the indicator y_cancelled to X.

Example
*&---------------------------------------------------------------------* *& Form Testprint (Optional) *

*&---------------------------------------------------------------------* FORM test_print TABLES

Print Workbench

620

21

SAP Online Help

yt_ranges STRUCTURE efg_ranges

16.01.2004

yt_ranges1 STRUCTURE efg_ranges yt_ranges2 STRUCTURE efg_ranges yt_ranges3 STRUCTURE efg_ranges yt_ranges4 STRUCTURE efg_ranges yt_ranges5 STRUCTURE efg_ranges yt_ranges6 STRUCTURE efg_ranges yt_ranges7 STRUCTURE efg_ranges yt_ranges8 STRUCTURE efg_ranges yt_ranges9 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

Print Workbench

620

22

SAP Online Help

16.01.2004

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

Print Workbench

620

23

SAP Online Help

16.01.2004

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 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.

Example
CALL FUNCTION ..ABCDE EXPORTING IMPORTING EXCEPTIONS NOT_FOUND OTHERS 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. = 1 = 2.

Print Workbench

620

24

SAP Online Help

16.01.2004

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 (recommended) set the indicator Smart Forms. 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.

Print Workbench

620

25

SAP Online Help

16.01.2004

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. Call up the form class processing. 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.

Print Workbench

620

26

SAP Online Help

16.01.2004

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:
...

Print Workbench

620

27

SAP Online Help

16.01.2004

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 _F LI GH T_ NO TI FI CA TIO N Bes t ti gu ng f r F lu gbu ch un ge

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. They integrate the data structure defined in the relevant form class, the data procurement, the form logic that you have determined, and the form layout. You are free to determine the form and scope of the data procurement and you can add your own data using user exits. You can also choose between the basic tools for creating form layouts Smart Form and SAPscript. The form class assigned to an application form determines the structure of data using the data list provided by SAP. When you create an application form, you have to specify the form class. You can then no longer change the form class.

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

Print Workbench

620

28

SAP Online Help

16.01.2004

Structure
The application form consists of: Properties/attributes Hierarchy SAPscript or Smart Form form SAPscript text User exit includes User top includes Generated print program

The core of an application form is the hierarchy. It has a similar function to the form class, but is extended. In the context of application forms, form levels represent events in the process logic of the form. In the events, you can define additional activities, such as calling a user exit, or for SAPscript, calling a text. The status of an application form tells you 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 thus integrates an application form in the data model of the application. The assigned and configured SAPscript forms and texts and Smart Forms integrate application forms in the design of the form layout. The generated print program integrates: The SAP application Customer-defined configurations and user exit implementations SAPscript and Smart Form components and their calls in ABAP Application forms are generally defined in Customizing tables or master data. Application forms are printed by calling the module EFG_PRINT, which calls the generated module for an 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. Print Workbench 620 29

SAP Online Help

16.01.2004

Use
Form classes are used in application forms.

Form Types
Definition
The form type of an application form controls whether a form is to be configured and output with Smart Forms or SAPscript. This setting is obligatory and cannot be changed once you have created the application form.

Use
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, data is placed in the generated data structures and transferred to the Smart Form assigned.

SAPscript/Smart Forms
Definition
Depending on the form type, either a Smart Form or a SAPscript form is defined in the attributes of an application form. In both cases 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 or Smart Form are reconciled with one another during the print transaction. The application form controls the print transaction, that is, the data is read and the program interfaces are called in the events defined for the SAPscript or Smart Form. 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 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 and Smart Forms, see the SAP library under Basis Basis Services/Communication Interface (BC-SRV) SAPscript (BC-SRV-SCR) or SAP Smart Forms (BC-SRV-SCR).

Print Workbench

620

30

SAP Online Help

16.01.2004

Integration
SAPscript forms and Smart Forms are integrated in the configuration of the application form, which means that navigation, creation, deletion, and consistency check 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 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) are implemented in the USER-TOPINCLUDE, 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 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.

Print Workbench

620

31

SAP Online Help

16.01.2004

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. If the OPEN/CLOSE optimization is active in the print parameters, you cannot carry out any form activities (for example, call of OPEN/CLOSE_FORM modules) in the user exits, since this can lead to errors in the internal form control.

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). They have the same name, which is different for each application form. 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 module is called if the application form is to be printed. This takes place in module EFG_PRINT, which is called in the print event of an application. The generated print program contains all ABAP commands and function calls of the form processing (SAPscript, Smart Forms) that are responsible for the data procurement and processing and, for example, place the form in the R/3 spool.

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) Call of SAPscript or Smart Form program interfaces 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/ and a number composed of the date and time of the first generation.

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.

Print Workbench

620

32

SAP Online Help

16.01.2004

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 R/3 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, select 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)

Print Workbench

620

33

SAP Online Help Form class (hierarchy, attribute, form levels, form class library) User includes (user top include, user exit include)

16.01.2004

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

Print Workbench

620

34

SAP Online Help

16.01.2004

PWB_FLIGHT_NOTIFICATION 5 CUSTOMER

Flight confirmation to customer

Root level/Attribute Document level

Customer

PWB_FLIGHT_HEADER_INFO Information for customer PWB_FLIGHT_FOOTER Footer (Number of pages) PWB_FLIGHT_ADDRESS Address Letter for customer Heading for posting items (MAIN) Heading for posting items (TOP)

PWB_FLIGHT_INTRODUCTION PWB_FLIGHT_ITEM_HEADER PWB_FLIGHT_ITEM_HEADER 5 BOOKING FLIGHT Bookings

SAPscript-texts (SAPscript only)

B D

Form level User-Exits 1:1-leve

Flight

PWB_FLIGHT_BOOKINGS Posting items

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) that 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.

Print Workbench

620

35

SAP Online Help

16.01.2004

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 forms general process logic.

Flow Logic and Processing Definition of the

Print Workbench 620 36

SAP Online Help

16.01.2004

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/Smart 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).

Print Workbench

620

37

SAP Online Help

16.01.2004

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, 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 Smart Form must agree with the name of the parameter or be PWB_DATA. The system can create the Smart form for an application form of type Smart Form automatically. The interface is created appropriate to the application form or the form class. You can also adjust the interface of the Smart Form 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

Print Workbench

620

38

SAP Online Help

16.01.2004

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 customers 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.

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 LANGU DEVICE Name Current language for the form Current output type (PRINTER, TELEFAX))

Print Workbench

620

39

SAP Online Help

16.01.2004

RDI FORMKEY FORMCLASS ITCPO ARCHIVE_INDEX COMM_TYPE SENDTYPE SENDTYPE_EXT COPYFLAG TESTMODE ITCPP XSF

SAPscript indicator for RDI Current application form Current form class Input print parameter for SAPscript as ITCPO structure Parameters for archiving (BOR object type, BOR object ID, archive object type) BCI send type (INT, FAX, RML) send type External send type Document is a copy Test print Print parameter returned by SAPscript as ITCPP structure XSF indicator for print using Smart Forms:

The second part of the variable contains further fields: Field TABIX LINES FORMTYPE NO_ENTRY PA_PRINT PA_UPDATE FORM_LEVEL LEVEL_NUMBER RDI_RESULT SAP_FORM SMARTFORM T_LANGU REC_STRING SEND_STRING MANDT RDI Name Count variable for the current loop Number of entries in the current loop Form type (Smart Form of SAPscript) Last form level has no entry Print action records should automatically be printed. Print action records to be updated Current form level Number of form level if multiple selection in the hierarchy SAPscript return structure if RDI has been used Name of SAPscript form Name of Smart Form Table of valid languages Recipient for send type (e-mail address, fax number, user name) Sender for send type (e-mail address, fax number, user name) Client of form RDI indicator

Print Workbench

620

40

SAP Online Help

16.01.2004

SMARTPRINT SMARTFILL SF_RESULT SF_OUTPUT_OPTIONS SF_CONTROL_PARAMETERS

Indicator whether Smart Form is to be called Indicator whether the data is to be filled in the complex data types (default X) Return result of Smart Form call (structure SSFCRESCL) Output options for Smart Forms (structure SSFCOMPOP) 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 available fields of variable C.

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 an outgoing correspondence, you first have to create the required application form. The application form is then 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 or Smart Form, user include). 2. Maintain the SAPscript form or Smart Form. 3. Insert a text. 4. Insert the text nodes in the hierarchy and maintain the texts (only for SAPscript). 5. Implement user exits.

Result
When you activate the 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 via the function module EFG_PRINT in a print process of the application, this generated function module is processed.

Print Workbench

620

41

SAP Online Help

16.01.2004

Creating Application Forms

Procedure
...

1. Choose Print Workbench Application Form Process. 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 type (SAPscript or Smart Form). Depending on the form type, specify the name for the relevant SAPscript form or Smart Form. When naming the new objects you should also take into account the name ranges. 5. If you want to work with user exits, specify the names for the relevant user includes. Again, see naming conventions. 6. Choose Continue. If the automatic recording of changes is active in the current client, you have to specify a Customizing transport request. The application form is created. The complete hierarchy of the form class is inserted in the new application form. You can now start adjusting the hierarchy to meet your requirements (for example, delete or deactivate form levels or 1:1 levels not used).
...

1. Process the relevant SAPscript form or Smart Form and activate it. 2. If you are using SAPscript, insert text nodes in 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 doubleclicking 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 continue to develop it and adjust it to your requirements using the tools of the Print Workbench (for example, test print).

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. Print Workbench 620 42

SAP Online Help

16.01.2004

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 have been defined in the application form attributes.

Procedure
...

1. Specify the global data field the total is to be based on, for example, WA_CUSTOMERFORCURAM. 2. Choose Goto User top include Display/Process to navigate to the user top include. Define a summation variable, such as 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 Select. 4. Specify a name for the exit before loop (for example, INIT_SUM) and the exit during loop (for example, 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 command, such as ADD WA_DOC_ITEM-NETTOBTR TO SUM. Navigate back to the application form. 9. Output the total in the form by placing the symbol &SUM& after the form level (for example, same level) in a text. 10. Activate the application form.

Result
The summation is now executed during the print and output in the text. Print Workbench 620 43

SAP Online Help

16.01.2004

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

Reading Additional Data from the Database

Procedure
If, when you are processing an application form, you determine that the dataset provided by the form class is insufficient, you have to read the missing data from the database. To do so, 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 Select. 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, such as 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 Print Workbench concept is aimed at providing all data for an application or a process 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:

Print Workbench

620

44

SAP Online Help

16.01.2004

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 Smart Forms

Use
If the data defined in the form class is insufficient and you have defined own data areas in the user top include and fill them in user exits, you can also make this data available in the related Smart Form.

Procedure
Include the global data on the interface of the Smart Form using the same name. The data definitions must have the same data type as the user top include, since otherwise runtime errors could occur when you call up the Smart Form from the generated print program of the application form. In addition to manual maintenance, you can also generate the data definitions in a user top include automatically in the Smart Form. To do this choose Edit Smart Form Compare.

Result
You can use your own global data of an application in a Smart Form in the same way as the standard data transferred.

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

Print Workbench

620

45

SAP Online Help

16.01.2004

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 duplicate naming of form levels in application forms. 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 Exit before loop Reference Form level Call/function 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. 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. 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. 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) The exit is called at the start of processing for a form level. The exit is called at the end of processing for a form level.

Exit During Loop

Form level

Exit-After loop

Form level

Text exit (SAPscript only)

Text nodes

Start exit End exit

Application Form Application Form

Print Workbench

620

46

SAP Online Help

16.01.2004

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, 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.

Print Workbench

620

47

SAP Online Help

16.01.2004

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

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

Print Workbench

620

48

SAP Online Help

FORM user_exit_sum_perform USING x_booking type sbook value(x_index) type sy-tabix.

16.01.2004

DATA: local_amount LIKE x_booking-forcuram. CALL FUNCTION 'CONVERT_TO_LOCAL_CURRENCY' EXPORTING date foreign_amount foreign_currency local_currency * * RATE TYPE_OF_RATE IMPORTING * * exchange_rate foreign_factor local_amount * * * * local_factor exchange_ratex FIXED_RATE = = fremdkurs = local_amount = = faktorsum = = sy-datum = x_booking-forcuram = x_booking-forcurkey = local_currency = 0 = 'M'

DERIVED_RATE_TYPE = EXCEPTIONS no_rate_found overflow no_factors_found no_spread_found derived_2_times OTHERS = 1 = 2 = 3 = 4 = 5 = 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

Print Workbench

620

49

SAP Online Help

16.01.2004

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 Print Workbench 620 50

SAP Online Help

16.01.2004

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 24]).

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.

Print Workbench

620

51

SAP Online Help

16.01.2004

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.

Prerequisite
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.

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 second case, the ABAP processor goes to your breakpoints in the debug session.

Print Workbench

620

52

SAP Online Help

16.01.2004

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 to R/3 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 R/3 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, 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 R/3 System (see also Copying from Clients [Seite 53]).

Print Workbench

620

53

SAP Online Help

16.01.2004

The internal data format of the files has changed considerably with R/3 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 References
Use
If you want to use the same application form in several clients, you can create links to an application form in other clients so that it does not have to be transported or replicated. For a reference, only the runtime components from another client are used during printing.

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

Procedure
...

1. Choose Print Workbench Application Form Tools Create Reference in Other Client. 2. Specify the (source) clients and the names of the referenced application form and choose Continue. To create several references 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 criteria and choose Program Execute. 3. Select the application forms that you want to reference to, and with the right mouse button, choose Reference. The application forms selected from other clients must not exist in the current clients.

Print Workbench

620

54

SAP Online Help

16.01.2004

After a client copy, the application forms are created as references to the source clients. If you want to create real copies of the application forms, you can transport them from one client to another.

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.

Print Workbench

620

55

SAP Online Help

16.01.2004

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

Print Workbench

620

56

SAP Online Help Mass download Individual copy (same or other client) Individual deletion (only same client)

16.01.2004

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)

Print Workbench

620

57

SAP Online Help

16.01.2004

Application forms SAPscript forms Smart Form SAPscript text User includes Generic function group

EFOM FORM SSFO TEXT PROG (FUGR)

NO NO YES NO YES (NO)

NO YES YES NO YES $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-Independent Customizing is active, each time you change a client-independent 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. To do so, 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 ENTER. The application forms placed in the request are checked and reactivated if necessary when you release the transport request. If errors are determined, the release must be 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 used by certain users in the system.

Print Workbench

620

58

SAP Online Help

16.01.2004

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 Reference 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 R/3 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.

Print Workbench

620

59

SAP Online Help

16.01.2004

Translating Application Forms

Use
You cannot translate the Print Workbench application forms and SAPscript texts with the standard R/3 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: Creating Worklists Processing Worklists

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.

Print Workbench

620

60

SAP Online Help

16.01.2004

Worklist ET 12.08.98 Test list

Application form Application form Application form Application form Application form Application form Application form Application form Application form Application form

FI_CA_INSTALL_SAMPLE FI_CA_PAYMENT_SAMPLE FI_CA_RETURN_SAMPLE FI_CA_DUNNING_SAMPLE FI_CA_ACCTSTMT_SAMPLE IS_U_CA_CASHPAYMENT_RECEIPT01 FI_CA_ACCTBALA_SAMPLE IS_U_SECURITY_REQUEST ZZ_CHHE_ACCT_STMT FI_CA_ACCTINFO_SAMPLE

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).

Print Workbench

620

61

SAP Online Help

16.01.2004

Worklist TSAN 10.09.1998 Test list

5 5

Application form Table short texts EFRMTE EFRMSTRTE

5

IS_U_BILL

SAPscriptFormular IS_U_BI_BILL

SAPscriptTexte IS_U_BILL_ADDRESS IS_U_BILL_HEADER IS_U_BILL_ITEM_CONSUMPTION_HEA IS_U_DOC_ITEM_CONSUMPTION IS_U_BILL_DISCOUNT IS_U_DOC_ITEM_AMOUNT_HEADER

Doubleclick on the individual objects to translate them.

Print Workbench

620

62

SAP Online Help

16.01.2004

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 Creating Worklists [Seite 63].

Procedure
Preparation
...

1. In the menu, choose Print Workbench Application Form Environment Translation Worklist Process. In the dialog box Indicator for Worklist, enter your indicator and the date on which the worklist is to be generated and choose Continue. The required 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 60].

Execution
Translating table short texts Print Workbench 620 63

SAP Online Help

16.01.2004

Select the required table short text by doubleclicking 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 form by doubleclicking it. The SAPscript Translation screen appears. 2. In the field Form, enter the form to be translated. Enter the required target language 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 session is opened and here you can see the original text as translation reference. 2. Choose the SAPscript text by doubleclicking 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 you do not have to translate control characters, control lines, and symbols. 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 then release the translated text. To do this, position 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 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, you can compare the old version with the current version. If there is a text version in the Print Workbench buffer, the symbol appears next to the text. To carry out a version comparison, double-click on the symbol . 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.

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. Print Workbench 620 64

SAP Online Help

16.01.2004

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 format (SAPscript or Smart Form).

Structure
The interface of the module consists of the following parameters: Import parameters X_PRINTPARAMS X_ARCHIVE_INDEX X_ARCHIVE_PARAMS X_DIALOG EPRINTPARAMS TOA_DARA ARC_PARAMS (Indicator) Structure of the print parameters Archive information per document (optional) General archive information (optional) Execute dialog for print parameters (optional, default: SPACE) Object handle for recipient (optional) Object handle for sender (optional) Print Workbench result structure Result of RDI print

X_RECIPIENT X_SENDER Export parameters Y_PRINTPARAMS Y_RDI_RESULT

SWOTOBJID SWOTOBJID

EPRINTPARAMS RDIRESULT

Print Workbench

620

65

SAP Online Help EPRINTPARAMS SSFCRESCL

16.01.2004

Y_PRINTPARAMS Y_SF_RESULT Table parameters XT_RANGES<number> (10) YT_OTF_DATA

Print Workbench result structure Result of printing by Smart Form

EFG_RANGES ITCOO

Ranges table for interpretation of data selection in form class 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 X_ARCHIVE_INDEX X_ARCHIVE_PARAMS EPRINTPARAMS TOA_DARA ARC_PARAMS Structure of the print parameters Archive information per document (optional) General archive information (optional)

Print Workbench

620

66

SAP Online Help

16.01.2004

X_SENDCONTROL X_RECIPIENT

SENDCONTROL SWOTOBJID

Send control (optional) Object handle for recipient (alternative to X_REC_ADDR and X_REC_PERSNUMBER) (OPTIONAL) Address number of recipient from central address management (optional) Person number from central address management (optional)

X_REC_ADDR

AD_ADDRNUM

X_REC_PERSNUMBER

AD_PERSNUM

Export parameters Y_PRINTPARAMS Table parameters XT_RANGES<number> (10) EFG_RANGES Ranges table for interpretation of data selection in form class EPRINTPARAMS Print Workbench result structure

You define the send control in Customizing for the Print Workbench. It enables you to change the technical print parameters transferred according to the settings 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 from the known SAPscript interfaces (for example OPEN_FORM) relevant for SAPscript

Structure of EFG_PRINTPARAMS DEVICE Device type for SAPscript/Smart Forms PRINTER for normal print output (default) MAIL for other send types (e-mail, fax)

Print Workbench

620

67

SAP Online Help

16.01.2004

RDI FORMKEY FORMKEY_RDI DELAYED_PRINT LANGU TEST_MODE DEBUG SENDTYPE

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

Name of application form (Used externally: Name of application form for RDI) Indicator: Creation of print request, no direct print Language of form Indicator: Test mode Indicator: Debugging mode when calling the generated module Send type: PRINTER = Correspondence as printed letter EMAIL TELEFAX RMAIL = R/3 internal mail

REC_ADDR REC_STRING SEND_ADDR COPYFLAG REC_PERSNUMBER LAST_DOC LAST_DOC_ACT OCL_ACTIVE SENDTYPE_EXT NO_ACTIVATION

(Internal use: ID of addressee from central address management) (Internal use: Address as string) (Internal use: Sender address as string) Indicator: Is a copy (Internal use: ID of person number from central address management) Last document in mass case (obsolete, should no longer be used) Output of spool request at the end of the print process Open/close control is active External send type Indicator: Suppress activation

Print Workbench

620

68

SAP Online Help

16.01.2004

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 NO_OPEN_FORM NO_CLOSE_FORM

Indicator: Return XSF/XDF data to calling application Is obsolete and should no longer be used. Is obsolete and should no longer be used.

The most important ITCPO print parameters for the Print Workbench print processes TDDEST TDNEWID TDIMMED TDFINAL TDTITLE TDSUFFIX1 TDSUFFIX2 Output device (printer) Force new output request Output output request Close output request Name of output request ID 1 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.

Print Workbench

620

69

SAP Online Help

16.01.2004

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 X_ARCHIVE_BOR_OBJECT X_ARCHIVE_ARC_OBJECT X_ARCHIVE_OBJECT_ID X_NO_DELAYED_PRINT X_NO_FORMKEY X_NO_ARCHIVE X_CHECK_ARCHIVE X_FORCE_SAPSCRIPT EPRINTPARAMS SAEANWDID SAEOBJART SAEOBJID (Indicator) (Indicator) (Indicator) (Indicator) (Indicator) Input structure of print parameters BOR object type for archiving (optional) Document type (archive) (optional) ID of BOR object (optional) No option for print requests visible (optional, default X) No form input (optional) No archiving field (optional) Check archiving parameters (optional) Force SAPscript print parameters dialog box (optional) No print view possible (optional) Only show printer as input field (optional)

X_NO_PREVIEW X_ONLY_PRINTER

(Indicator) (Indicator)

Print Workbench

620

70

SAP Online Help

16.01.2004

X_NO_LAST_DOC X_NO_DIALOG X_ONLY_SENDTYPE_PRINTER X_NO_OCL_ACTIVE

(Indicator) (Indicator) (Indicator) (Indicator)

Output after last document (optional) Suppress dialog (only provide user defaults) (optional) Only offer send type Print (optional) Suppress open/close optimization active option (optional, default X)

Export parameters Y_PRINTPARAMS Y_ARCHIVE_INDEX Y_ARCHIVE_PARAMS EPRINTPARAMS TOA_DARA ARC_PARAMS Print Workbench result structure Archive information (1) 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 (for example, 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 X_TAB_FORMKEY X_FORMKEY X_FORMCLASS X_TAB_FORMCLASS Export parameters Y_TAB_ERRORFORMS EFG_TAB_ERRORFORM Table with incorrect application forms ITCPO EFG_TAB_FORMKEY FORMKEY FORMCLASS EFG_TAB_FORMCLASS Print Parameters Table of application forms (optional) Application form (optional) Form class (optional) Table with form classes (optional)

Print Workbench

620

71

SAP Online Help The module EFG_PRINT_INIT has the following structure: Import parameters X_FLG_OUTPUT X_FLG_FINALIZE X_FLG_CLEAR_SPOOLIDS Export parameters Y_TAB_SPOOLIDS TSFSPOOLID (Indicator) (Indicator) (Indicator)

16.01.2004

Triggers output of spool requests Close output requests Delete spool IDs from main memory

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 modules. In the case of SAPscript, this takes place as follows: OPEN_FORM START_FORM .... <Texte> 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 depends 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

Print Workbench

620

72

SAP Online Help

16.01.2004

EFG_GET_PRINT_PARAMETERS. The application has to make it visible and make a default entry.

Print Processes and Print Scenarios

Purpose
The Print Workbench is not a tool for processing forms. It regulates and standardizes the processes for determining the application data in the tool selected by the user for processing forms. From this point of view, the Print Workbench is a standardized infrastructure for processes that take place in a print event triggered by an application and can be configured accordingly.

Process Flow
From the view of the application, the type of use of the data is neither known nor relevant. The application data can be prepared in a form in the R/3 System using the Print Workbench functions either with SAPscript or Smart Forms, or can be processed further externally. With external further processing, the data is transferred from the R/3 System via the RDI interface in SAPscript or via XSF or XDF in Smart Forms, and can be processed by special software according to the local requirements. Print Processes and Output Formats

created

Generated Print Program

Form type = Smart Forms Form type = SAPscript

XSF/RDI:
Control data sort data Variables, symbol names, and values Texts Pages, windows Certifiable R/3 Standard

Application form
Form type: Smart Form or SAPscript

Smart Forms form

SAPscript form

XSF Parameter XSF/XDF (File)

RDI Parameter RDI (File/IDOC)

Output formats

OTF (R/3 Spool)

External Further processing Output Management System (OMS)

Printing large quantities Postprocessing (use of line codes OMR) Postage determination/use of franking machine Information about reducing postage Integration of document management and archiving systems Editors for creating layout

External Further processing

SAP recommends external processing via an output management system where large volumes of data are concerned, since the R/3 System doe not have a control for external print logistics, such as optimizing postage or controlling print streams. In many cases, outside of the R/3 System forms and other data is multiplied or the different correspondence types are sorted and mixed.

Print Workbench

620

73

SAP Online Help

16.01.2004

External Further Processing of R/3 Data

Use
In mass processes, the data is not actually processed within the R/3 System. It is processed outside of the system using external software.

Integration
The data interfaces RDI and XSF/XDF are integrated components of SAPscript and Smart Forms and are accessed from the Print Workbench via corresponding runtime parameters.

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

Features
If you use SAPscript, you can use the following formats for external further processing: X = RDI (spool, certifiable) S = Simple RDI (spool, not certifiable) I = RDI IDoc (not certifiable) X = XSF (spool, certifiable) D = XDF (spool, certifiable)

If you use Smart Forms, you can use the following formats:

The supplement Spool defines that the data output is controlled by R/3 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.

Activities
To select one of the data formats supported, specify the relevant field (one for each SAPscript and Smart Form) for the output format in the print options of the Print Workbench.

Archiving/Archive Connection with ArchiveLink

Use
If a document is sent, you frequently have to archive a copy of the document. Documents are archived in an external optical archive system and connected to the R/3 system through SAP ArchiveLink. SAP ArchiveLink contains 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, so that communication with the SAP ArchiveLink takes place exclusively via this interface.

Print Workbench

620

74

SAP Online Help

16.01.2004

Integration
SAP ArchiveLink is called directly from SAPscript or Smart Forms during the print process provided you have made the required system settings 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 R/3 System with no external processing of data SAPscript and Smart Forms both 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 R/3 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 completed, the archive generates a 40 character ID and in the R/3 System creates a link entry, via RFC or BAPI, with the data received. This link entry creates the logical link between a business R/3 object (such as an invoice document or a contract account) and the technical object in the archive. Archiving during form output in R/3 System

Print Workbench

620

75

SAP Online Help

16.01.2004

R/3 Smart Forms SAPscript Archive Link

Formatted document, for example, PDF BOR object Archive BOR ID Document type Archive ID

ASYNCHRONOUS
BOR object BOR ID Document type Archive ID + Archive document ID

Formatting by external system (RDI) If the document is not prepared in the R/3 System, and one of the data formats for external further processing is used, the document from the R/3 System is not archived and the external system must also control the archiving as well as the preparation of the document. This means that the external system must execute the functions described above. The external system must provide the archive with the required parameters so that the archive can create the link entry. Since the RDI flow does not contain any archive information, in this case you have to transfer the archive parameters to the RDI flow explicitly. To do this, you can use the variable c-archive_index (DDIC-structure TOA_DARA) in the application forms. If you use this variable as symbol, you can add this to the RDI flow in a SAPscript text.

Activities
Activate the archiving by setting the archiving parameter Print and Archive (3) or Only Archive (2) in the dialog box Print Parameters. Following a successful report form the archive, 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. You can use the interface to SAPconnect [Extern] provided by SAPscript to use the send types TELEFAX, EMAIL, and

Print Workbench

620

76

SAP Online Help

16.01.2004

RMAIL. TELEFAX stands for faxes, EMAIL for Internet e-mail (SMTP), and RMAIL for documents sent within R/3. 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.

Integration
All send types require a document created by SAPscript. SAPconnect is a standard application in the R/3 system and is included automatically.

Prerequisites
To ensure that the different send types function correctly, you have to make the following system settings: Activate the communication types. To do this choose Tools Administration Management Transaction Method Office General Office Settings. Set the communication methods to SAPconnect. To do this choose Tools Administration Management Transaction Method Communication SAPconnect Goto Customizing Communication Types. Create SCOT communication nodes in the transaction Communication Types. These define, which route a document sent to SAPconnect should take. Maintain the user data for each communication type in the system. 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. Because SAPscript also enables you to use the raw data interface to format documents in external systems, you must differentiate between the following scenarios: Formatting by SAPscript (no RDI) Processing takes place automatically according to the standard procedure in 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. Formatting by external system (RDI) If the RDI indicator is set in the printing parameters, an RDI flow is created instead of starting SAPconnect. In this case, an external system must also take over sending the document. The data contained in the RDI flow is used for this purpose. Prior to SAP Release 4.6B, there was no sending information for sending as fax, e-mail, or r-mail. For this purpose, the Print Workbench provides the following fields in the c global variables in the application forms: c-sendtype : print workbench send type (PRINTER, TELEFAX, EMAIL, RMAIL)

c-comm_type :SAPconnect communication type (FAX, INT, RML, OFF) c-rec_address: recipient address as character string (fax number, e-mail address)

c-send_address: sender address as character string (fax number, e-mail address)

To appear in the RDI data flow, these fields must appear as symbols in SAPscript texts.

Print Workbench

620

77

SAP Online Help

16.01.2004

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.

Dispatch Control
Use
You can use this function to send an application form several times and in any of several different ways, such as a letter, fax or e-mail.

Integration
You have processed the different send controls in Customizing for the Print Workbench.

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)

Output format SAPscript (<BLANK>, *, X, I, S) Output format Smart Forms (<BLANK>, *, X, D) Number of copies (number) Archive mode (1,2,3) Copy indicator (<BLANK>, X) Output device

The control lines taken together constitute send control. The settings for a send control line overwrite by field; this means that if a setting has been set for a field, this setting is evaluated and used. For empty fields, the standard setting for the print transaction is used. In the send control you only make the technical settings for sending the documents. The application links a transaction with a send control logically in Customizing or in the master data.

Activities
The send control is entered in the applications. During the print process, the send control is transferred to the Print Workbench via module EFG_PRINT_EXPANDED and evaluated. Each line in the send control triggers a new preparation and processing of the document.

Print Workbench

620

78

SAP Online Help

16.01.2004

Using the Print Workbench with the Correspondence Tool

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). This function is provided by the correspondence tool outside of the Print Workbench. 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 Recipient Language Dispatch control Application forms Address type Archiving ID

For more information about correspondence, see Correspondence [Extern].

Using Print Action Records

Use
A print action record is a variable text or data supplement that is determined at the time of print processing and that can be integrated in form processing. A print action record is used if you also Print Workbench 620 79

SAP Online Help

16.01.2004

want to print out a variable, user-defined 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 period or the maximum number of processing steps.

Features
A print action record consists of the following indicators and fields: BOR object type (key field) BOR object key (key field) Form class From date To date Maximum number of processing times Frequency

The search for related print action records must be integrated in the form class. This is usually shown by a corresponding 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 example of the report SAPRISU_PRINTACTION_GENERATE delivered by SAP. Print action records are integrated in an application form either via a form level that corresponds to the BOR object of the print action record, or you can integrate the search for print action records via the programming interface in the user exits of an application form. If a print action record is determined during the print transaction, if you use SAPscript, the content can be output immediately in the MAIN window, or saved in a variable and then output as symbol. In the case of Smart Forms, the print action record must be saved in 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: OBJ_TYPE: OBJ_KEY: Form class BOR object type 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: TRIG_TO: TRIG_COUNT: MODULO: From date for processing To date for processing Total number for processing Frequency (Example: 3 = every third time)

Print Workbench

620

80

SAP Online Help TRIG_DONE: LAST_DATE: Number of completed operations Date of last processing

16.01.2004

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.

Print Workbench

620

81

SAP Online Help

16.01.2004

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
The creation of a print action record is usually determined by a business transaction. Therefore, print action records can be created in different ways. A print action record is created if a letter is to contain some additional item of information.

Integration
Print action records are created so that they can be 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.

Features
Several items of information can be stored in a print action record. The following criteria determine the validity of a print action record: From date To date Frequency

You can also assign a freely definable text to a print action record. You can also set texts or flyer indicators for further processing in print action records. These text or flyer indicators are defined in Customizing for print action records. 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).

Activities
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.

Print Workbench

620

82

SAP Online Help

16.01.2004

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.

Print Workbench

620

83

SAP Online Help

16.01.2004

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_ACCTVKONT 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

Print Workbench

620

84

SAP Online Help

16.01.2004

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.

Print Workbench

620

85