Sei sulla pagina 1di 169


Some Facts about SAP After the internet, SAP R/3 is one of the hottest topics in the computer industry and the company that developed it. It is targeted to most industries: manufacturing, retail, oil& gas, pharmaceutical, banking, insurance, telecommunication, transport, chemical and so on. All major hardware is fully engaged to partner with SAP: AT& T, BULL, Compaq, IBM, Sun have supported and certified R/3 platform. SAP has list of major consultant all over the world like Anderson Consulting, Price WaterhouseCooper & Lybrand, Ernst & Young KPMG and many more. The company behind R/3 is SAP AG, founded by four former IBM employees in 1972. The companys headquarters are in Walldorf, a small German town. The company name. SAP stands for SYSTEMS, APPLICATIONS and PRODUCTS in data processing. In 1992 R/3 was introduced and in 1995 SAP AG was ranked fifth among independent software vendors. One of the reasons for Saps success is that since it is a standard package, it can be configured in multiple areas and adapted to specific need, of a company. All over the world there are more than 8000 installation of SAP R/3 that means more than 80000 companies rely on SAP software for their most crucial business need. SAP has two main products in the business software market: Mainframe system R/2 and Client Server R/3. Both are targeted to business application solutions. Here R indicates Real time. R/2 is SAP AG mainframe software that runs on IBM, Siemens and other compatible equipment. This type of solution cannot be open, but with ALE technology, R/2 can be linked with R/3 system and share data. This system is mainly targeted at enterprises with data-intensive and centralized industries. R/3 is the product that has really placed SAP AG as the leader in the industry. This complex Client/Server system is core of our course. The global acceptance of R/3 is not only because it caters all complex needs of business but also this international acceptance is because of R/3 s international applicability. For SAP this does not mean having software available in different language, but also covering currency, taxes Legal practice concerning HR, Import/export regulations. SAP also values its customers and it is shown by the comprehensive set of quality services put by SAP to help customers during the process of Implementing and supporting the R/3 systems. These services include product information; training, installation and upgrade services like; OSS Online Service System is one of the primary sources of service and support provided by SAP. With OSS, Customers can search the SAP information database and find solutions for errors and problems with R/3 systems. You can also submit your problems to SAP. Consulting Service with remote consulting service customer receives immediate and updated technical support and answers to their questions. Maintenance Service: This is the basic and most common type of support for customers in technical support and answers to their questions.

Information Service: These are the various information sources for receiving detailed information about the R/3 system, marketing brochures, system documentation, training information and many more things. Preventive Services: The primary one is the Early Watch service, which ensures successful and efficient installation of the R/3 system in all phases. This service makes regular performance checks and analyzes the system to identify potential problems, help system managers and SAP sends the customer a report with the result of the analysis and recommendations for avoiding potential problems such as database becoming full. So overall SAP R/3 is an open client/server software system, designed to manage business information needs of an entire enterprise. The whole dataflow of SAP R/3 works in an integrated way, which means the data needs to be entered just once and the system automatically updates other logically related data. WORKING WITH R/3 System The SAP R/3 presentation interface behaves very similarly to any other typical window application and is also known as SAPGUI. The first screen that you come across in R/3 system is SAP logon screen. SAP R/3 logon screen This is the first screen that appears when you use SAP logon utility. It has four fields: the client, the user, the password and the language.

Client: Here you enter the client number. The client is group of users who has similar rights. It can be group of users in a business entity or a whole business entity or a whole company.

User: The name of the SAP user identification. Users of the SAP system are clientspecific, which means that user belonging to one client is valid to only that particular client. Password: It is the password that has been assigned by the system administrator.

Language: SAP R/3 system supports multinational language on the same system at the same time, which is very useful for multinational companies with different branches in several countries and possibly using different languages. After entering all the fields press ENTER key and system will take you to MAIN MENU screen. User might get different screens when he logs on, depending upon default settings of the user master record i.e. if user is DEVELOPER then the screen which he often works on its editor screen and he can go directly to this screen, if system administrator sets screen for the user. Main features of any R/3 window are as follows: R/3 standard window elements behave exactly the same, as any other standard window application would like minimizing a screen, setting the active window etc. From TOP to BOTTOM, R/3 window can contain typical elements such as check boxes, push buttons, input fields and following elements: Menu bar is the first element of the every R/3 window. It contains the menu item corresponding to the particular R/3 application. The two menu options SYSTEM and HELP are always present in every R/3 window. SYSTEM menu option contains all utilities and functions, and is available to user at all the time. The HELP menu contains all the available options for the different types and methods of obtaining online help in the system. Standard tool bar: The second R/3 window element is present in every R/3 window. It is nothing but collection of icons, which perform common functions like saving the object, exit etc., the various icons on std. Tool bar as follows (from left to right): Command Field Cancel First Page Help Save Print Previous Page Back Find Next Page

Enter Exit Find Next Last Page

All icons in R/3 window application support FOCUS property. It means, if you place cursor over an icon and the system will show the function of the icon.

Application tool bar: The next part of the screen contains icons most commonly used in that particular task or transaction.

Status Bar: Is the bottom line of the screen and usually shows error or information messages to the user. It also includes other information such as system ID, session number, client, server name and the response time.

In between application tool bar and status bar you have working area, which is different for different screens. Logging Off User can log off the R/3 system from any screen. There are three ways of logging off the R/3 system, which are as follows: From the menu bar choose SYSTEM -> LOG OFF. In this case, you get the log off dialog box, which informs the user that any data not saved will be lost if continuing with the log off procedure. Use / NEX transaction code in the command field. This is dangerous, since it does not ask if you want to save the data. Clicking on the EXIT button on the R/3 initial screen.

Using Transaction Code The R/3 system provides an alternative and efficient way of selecting menu options for moving around the tasks and functions of the SAP system by using transaction code directly in the command field. When moving with transaction, you can go to any part of the system by merely typing a transaction code in the command field, provided you have authorization for that. That transaction code is the four-character code associated with any task. By typing the transaction code and pressing ENTER key, the system takes you directly to the initial screen for transaction. Whenever any transaction code is entered in the command field, it gets stored in the buffer memory. If you click on drop down arrow, system displays list of transaction code already entered and you can select from this list or enter new one. There are almost twelve thousand and ninety four transactions in SAP. For every task, transaction code is associated and it can be found by SYSTEM -> STATUS Status window is popped up which contains the transaction code in the trans field.

Through DYNAM IC MENU. It gives the list of tasks. If you click on the top line of the application areas and pressing the search and search next button will give you the Transaction code.

Important transaction codes, which you will be using often, are: Data dictionary transaction S001 SE11 SE16 SM30 SE84 SE84 SE80 SCU3 Initial ABAP/4 Development workbench screen. Initial ABAP/4 dictionary maintain screen. Data browser. General table contents display Main ABAP/4 repository information system. Repository information system for ABAP/4 dictionary object. Object browser Table history transaction.

Editor transaction SE38 SE37 SE51 SE41 Initial editor screen for programs. Function library screen Screen painter screen Menu painter screen

Getting help in the R/3 system R/3 includes many possibilities to get online help for almost every element of the system, users can get help for entire application, for specific function, for definitions of various terms used in SAP i.e., Glossary, messages, screens, fields etc.

You obtain HELP by using any of the following options: Help option from the R/3 window, which is compulsory menu item of every R/3 window. ? Icon of standard tool bar F1 function key.

The SAP system provides help on most fields that appear on the R/3 screen. To get help on particular field, position the cursor over it and press help button or F1 function key. Another way in which R/3 system provides help is when system displays error messages in the status bar. Double clicking on the status bar shows additional information about the message. Working with R/3 user sessions A very important feature provided by SAP. In R/3 system you can work with more than one task at any given point of time, by means of opening sessions. You can call sessions as independent R/3 window where you can perform other task. By default, a user can open six sessions simultaneously and can work or move around with all sessions at the same time. Sessions can be closed at any time, without having to log off the system. User can create new sessions from anywhere as CREATE SESSION comes under SYSTEM menu which is available in every R/3 window. SYSTEM -> CREATE SESSION Or /0 in command field will open a new session or window and will place it in front of all other windows. To move among sessions Just mouse click on any part of the R/3 window to make that session active. Combination of ALT + TAB key.

R/3 Architecture The overall R/3 system includes the following components:






The UPPER layer, the functional layer contains the different business application. The integration of all application depends upon basis system. All types of application are developed by using ABAP/4 (Advanced Business application - the 4th generation language) The R/3 basis software is the set of programs and tools, which interfaces with the operating, system, the underlying database, protocols and the presentation interface. This layer enable all the application to work exactly the same way no matter what operation system or database, the system is installed on. It is an independent layer and ensures the integration of all modules. Besides all these specifies jobs, basis system also contains following components and thus provides more additional features: ABAP/4 development workbench in turn includes many features like repository, data dictionary, workbench organizer that will be discussed in later part of the topics. ABAP/4 languages, system administrative tools all these components are used to control, tune the R/3 system. Spool system manages the formatting of data for printing and passing it to the host spool system. Mail system you can send and receive mail form the outside world (Internet) Communication interface to external system inside R/3 system manages communication at the operating system level (TCP/IP), at the database level and between applications (RFC, EDI, and ALE). Database interface This component supports different Relational databases from different vendors. The main task of database interface is to convert the SQL request from the SAP development environment to the databases own SQL environment.

Background processing with this facility you can submit your program for background execution.

BASIS system contains the layered components that facilitate the development of client/server architecture. Client/server architecture Client/server architecture is mainly a software concept that includes a set of service providers and service requesters. The set of computers acts as service providers and is called as server. The sets of software components, which act as service requester, are called as client. In the client/server architecture, the database acts like a library clerk retrieving books from the shelf. The user programs have to request database for the data instead of searching for the data themselves. This way there is no risk of the users putting the data out of order. If the desired data is in use, the database make the user wait until it is free. The major advantage of the client/server architecture is that the server is available for a number of clients and there is distribution of work between the clients and the server. The user directs the request to the client in turn understands the users request and redirects the request to the server. The server retrieves the data, gives it to client. You can have client and server on the same machine or on different machine. Each client has a corresponding process inside the server. One of the most used client/server configurations with theR/3 system is the 3-tiered architecture, which separates systems computer into 3 functional group: Three tier architecture of R/3 Database Server Application Server Presentation Server (Unlike normal Client server architecture where you have only two layers i.e. client and Server.) (Communication among the 3 tiers is accomplished by standard protocol services like TCP/ IP or CPIC (Common Programming Interface Communication).

Database Server

Application Server

Application Server

Application Server











on Server


In above case database server stores the data centrally. Basically contains database engine and associated processes. The database layers contain the database system used by all servers. Application server contains software components to run program. It contains a SAP kernel, which can run ABAP/4 program. The presentation server is your client through which you send your request to application server. It is also called as (SAP graphical user interfaces) known as SAPGUI and is available in windows 3.1, NT, Windows 95, and Macintosh. They all look similar whatever underlying system they are running on. The SAPGUI includes all graphical capabilities of window interface with menu bars, tool bars, focus property, and the entire mouse clicking options. The R/3 system is open system in the sense that it can run on any operating system or any database and any communication technology. It means that. R/3 system can run on any operating system platform such as UNIX, NT, 95,AS/400 It supports various RDBMS such as SQL server, oracle, Informix, DB2 Standard GUIs supported by R/3 are Windows 95, NT, Windows 3.1,and Macintosh. SAP can use standard communication protocols TCP/IP, CPIC<OSF/DCE/DME for network

ABAP/4 Development Workbench The development environment of SAP R/3 system is fully integrated set of various development tools, data dictionary, and programming language. Full integration of all components means that changes in any part have direct and immediate effect on all application using those components. The screen of ABAP/4 development workbench look like

Tools of ABAP/4 workbench For programming

ABAP/4 dictionary: Defining, maintaining and storing the data dictionary of the SAP R/3 system stores all the dictionary objects including tables relationship and help information. Transaction code for this is SE11

ABAP/4 editor: Creating and maintaining the ABAP/4 program editing function modules, logical database, and screens. Transaction code is SE38 Function library: Defining and maintaining the ABAP/4 function modules. Transaction code is SE37 Screen painter: Designing and maintaining the screens in transaction. Transaction code is SE51. Menu painter: Designing and maintaining the menus for graphical user interface Transaction code SE41 For navigation


Object browser Managing and organizing the development object in a hierarchical form. Transaction code is SE80 ABAP/4 repository information Navigating and searching for the dictionary objects, development objects and relationship objects. Transaction code SE84. Data browser Navigating in the data tables of the database. Transaction code is SE16.

For debugging

SQL trace: Tracking the database calls form the system transaction and programs. Transaction code is ST05. Debugger: Stopping the program and analyzing the results of the execution of every program statements.

Runtime Analysis: Analyzing the performance the system calls. Transaction code is

SE30. Organizing development Workbench organizer controlling and keeping track of development work and team related development projects and managing versions of development objects. Transaction code is SE09. Transport system Performing and managing the transport development object across different system. Transaction is SE01. Data Dictionary The ABAP/4 dictionary is the central workbench repository utility providing the data definition and the information relationship that are later used in all the business application within R/3. The ABAP/4 dictionary can be seen as a logical representation or a superior layer over the physical underlying database. This database must support the relational data model. This model is strictly followed by data dictionary. About data dictionary A Data dictionary in computing is the source of information in which system data is defined. The data dictionary is the centralized and structured source of information for business applications. You can say that is core of a well-structured development environment. The elements that make up a dictionary are known as metadata (metadata is the term for the data whose function is to describe other data). Data in dictionary is not the actual data like emp name or emp num, address but rather a type of data whose function is to define the properties of the data, such as type, length, and relationship. Advantages Advantages of using data dictionary is avoiding inconsistencies when defining data type that will later be used in different application, this avoids redundancies. When type is defined in the dictionary, it is available to any program in the application. A change in the definition of a type of data in the dictionary automatically affects any other data or program, which has this data.


Again, data dictionary is a fast and efficient way to answer questions such as which entries exists in a table of the database, what the structure of table is. Activation of dictionary objects For a dictionary object to be effective at runtime, that is, for a dictionary object to be available for use within a program, transaction, and so on, it must be in active status. For objects to become active, R/3 includes the ACTIVATION function. When a table or aggregated object is activated, it is placed at the disposal of the system as a runtime object in a way that makes it available quickly for the application program access relevant information of new activated objects. When mass activation is performed massively, it might take quite a long time and it should be in the background system. This type of activation is known as background activation. The ABAP/4 Data dictionary is the central component of ABAP/4 repository. A data dictionary is centralized and structured source of information for business application. The ABAP/4 dictionary is the core of the R/3 development system. It is the source of every definition, within R/3 forms the very basic domain to the company data model. It is totally integrated with other tools of the development environment like screen painter, menu painter, and editor. Some of he main available functions in the ABAP/4 dictionary are as following Add, delete, modify, and manage the definition of the dictionary data. Preserve the data integrity. Be the central source of information e.g. form the dictionary you get the information about this defined relationship between tow tables or even the directory tells whether table is active or empty. It also permits documentation of system data In the R/3 system instead of working with original objects, you work with internal representation of objects. With this type of operation the system performance is enhanced and has the advantage that the development tools, screen interpreters always access current data. When any of the data dictionary objects are used in other parts of the development workbench for example in program programmer only have to enter a table name or field name. The system automatically knows all the properties of and information of the field. To call ABAP/4 dictionary, form the main menu, Tools ABAP/4 workbench data dictionary or enter transaction SE11.


Data dictionary objects:

Tables A table is two dimensional data matrix. A table contains rows and columns. Rows contains data while column indicates fields. Table can contain 0 or multiple rows. Structures The object structure refers to the definition of object that does not have any contents. It is like table or view, but it never has entries i.e. it is only a structure. The basic difference between structure and table is that the structure does not exist at the underlying database system level. Structure exists as definition in the dictionary.

Views A view is an imaginary table. It contains data, which are really stored in other tables. The contents for the view are dynamically generated when called from program. Data element They are definition of the properties and type for a table field. It is an intermediate object between the object type domain and the table field. A field in R/3 system is always associated with a data element, which at the same time is related to domain.

Domains They are formal definition of the data types from a technical point of view. They set attributes such as data type, length, possible value range and so on. Lock objects These types of objects are used for looking the access to database records in table. This mechanism is used to enforce data integrity that is two users cannot


update the same data at the same time. With lock object you can lock table-field or whole table.

Matchcode objects are similar to table index, which gives list of possible values for either primary keys or non-primary keys. Tables in ABAP/4 dictionary Tables are the basic objects in R/3 application. There are almost 8000 tables in R/3 system. Following types of tables are available. 1. Transparent tables 2. Pool tables 3. Cluster tables From user point of view, all tables are used to store data whatever be the type of table. There is no difference in the behavior or operation of these tables. All of them can be managed by using standard OPEN SQL. However from an administrator point of view transparent table do exists with the same structure both in dictionary as well as in the database. While other two are not transparent in the sense that they are not manageable directly using database system tools. You cannot use native SQL on these tables. Pool or cluster tables are logical tables, which are arranged as records of transparent table. A table is made up of rows and columns. When the table is created, its columns are named; data type is supplied for each column. There can be only one data value in each column of each row in a table. Record or row or tuple as it called in different RDBMS is nothing but group of fields. While a column is a field of a table. A table is an indexed file. The main index is called as primary key, which can be a single field or combination of keys or fields. (A primary key can be defined as a field, which identifies a single unique record of the table) a table cannot have record with duplicate primary key. In any RDBMS, tables are related to each other. But to relate table to each other it is necessary that one of the tables contain some information of other table. Mostly tables are related to each other through primary keys. The primary key of one table, if it exists in other table then it is called foreign key. This type of database management system means that there is some redundancy of data. But it can minimize by using normalization procedures available. One of the most important function foreign key is to ensure data integrity. For example say you have EMP table, which has fields,, dept. code, salary and you have DEPT table which has dept.code and dept.desc. then in DEPT table dept.code is primary key while dept.code in EMP table is foreign key. If you enter dept.code for particular employee in EMP table the dept.code should exists in DEPT table, and if does not exists then will flash error. In this case DEPT is called check table while EMP foreign key table. Creation of table Steps to create a table Create a domain Create data element Create actual table

Creating Domain


Domain as already explained defines the technical properties of a field such as type and value range. A domain can be created from initial screen of data dictionary by clicking on create and clicking domain radiobutton. Parameters to be passed are: (Data type) where you need to enter the data type available in SAP Field length: Field length is the number of valid position. Value table Name of the table to be entered. The fields referring to this domain may only assume values contained in the value table. Once the domain is created, save and activate it, so that it can be used for further objects (basic rule of dictionary) Creating Data Element The second step of table creation is to create data element. It assigns a certain meaning to the table fields, which are defined using that data element. A Data element always needs to be defined over a domain and field is always defined over a data element. This allows all fields with same technical properties to use the same data element. Parameters to be passed when creating a data element Short text. Mandatory field. Domain: A mandatory field. If the domain does not exist, SAP can take you directly to domain definition screen. Text element. You can enter description in short or long text for the field. This text is used when entering data for these fields. Save and activate. Creation of actual table. Parameters to be passed for creation of a table. Short description. Mandatory field. Delivery class. Table fields: Specify whether primary key. In this case it is mandatory to enter data element. Data class: Establishes the physical area of the database. Size category: Allows you to specify estimated space requirement for the table. Further down under buffering square box, the system allows specifying whether table is going to be buffered. When a table is buffered, it is loaded into the table buffer from the application server memory and it will remain there until you switch off or reboot system. If the table is to the buffered then you need to specify the type of buffering. Full is for entire table while partial is for only those records which are being accessed. Once the table is created, it has to be generated or activated to be able to be accessed by other objects like programs. General introduction to ABAP/4 SAP originally developed the programming language ABAP/4(advanced Business Application Programming for internal use to provide best working conditions for developers. SAP constantly improves the language to adapt to the increasing requirements of the business application. At present ABAP/4 is the only tool for developing application at SAP.


SAP customers use ABAP/4for their own developments. The ABAP/4 Development Workbench contains all tools you need to create and maintain ABAP/4 programs. ABAP/4 programs are not compiled but generated. During generation, the system creates a so-called runtime object from the source code and the program attributes. When you start the program the system executes the runtime object. ABAP/4,a fourth generation language, contains all usual control structures and modularizing concepts for structured programming. The three parts of the ABAP/4language are: Structure and execution of ABAP/4 programs Basic language elements Programming reports Programming dialogs Structure and execution of APAP/4 programs are essentially different form entirely sequential programming languages such a s FORTRAN, PASCAL, or C, ABAP/4 instead shares certain similarities with modular, event oriented programming languages such as Visual Basic or JAVA. The two most important statements concerning structure and execution are: An ABAP/4 program has a modular structure. For execution, you need a special runtime environment. This means, that ABAP/4 source texts always consist of a collection of program modules (one single module in the easiest case) or the sequential set of statements. The individual program modules consist of sequential statements. The set of statements of a program module is also called processing block. The runtime environment is responsible for calling the individual program modules one after the other. The runtime environment is the ABAP/4 processor, which can communicate with the list processor or the dialog processor, depending on the program type. Program flow within the individual processing blocks is sequential, as you know it from other sequential programming languages (for example, FORTRAN, PASCAL, and C). Within the processing blocks, you can use the general control statements for the program flow, such as IF, DO, WHILE. ABAP/4 does not contain GOTO statements. We mainly use programs that consist of single processing block only and, therefore, behave most likely like programs of other sequential programming languages. For programming applications, the entirely sequential concept is not sufficient. SAP distinguishes between two general types of application programs. Reports You use reports to databases and represent the results in list. Reports are collections of processing block that the system calls depending on events. Dialog programs Your use dialog programs to execute transitions, which usually read and change databases. Dialog programs are collection of processing blocks (so-called module pools) that are called by screen flow logic. The third part of the users Guide describe dialog programming in detail. Report can call dialog programs and vice versa.


In its easiest an ABAP/4program contains one single sequential piece of coding and, thus, one single processing block. Characteristics of the ABAP/4 programming language: Declarative elements for declaring data of different type and structures. Operational elements for manipulating data. Control elements to control processing flow. ABAP/4 is multi-lingual. Text elements such as titles, headings, and text body are stored separately, independent of the program codes. This, you can change, translate, and maintain text elements without having to adapt the coding. ABAP/4 supports business-related data types and operations. You can execute calculation using special date and time fields. The system automatically executes all necessary type conversions. ABAP/4 provides a number of functions for processing character strings. ABAP/4 allows you to define and call subroutines. You can even call subroutines of other programs. There are different ways of how to pass parameters to a form the Subroutines. ABAP/4 contains a special type of subroutine, called function module. Function modules are stored and maintained in central library. They have clearly defined data interfaces to the calling program. You can test function modules in a standalone mode independent of the calling program. ABAP/4 contains an SQL subset called OPEN SQL. OPEN SQL allows you to read and change database tables independent of the underlying database system. ABAP/4 allows you to define and process internal tables that exist only for the execution period of the program. Internal tables most efficiently support the usage of database tables and allow you to implement complex data structures in a program. ABAP/4 allows you to store data not only on databases but also as sequential files on application and presentation server.

Reports Reports are ABAP/4 programs. You use reports to evaluate data form database tables. The results of such an evaluation can be displayed on the screen or printed from. Reports are stand-alone programs. The user can execute reports directly via the program name, for example, by choosing System Utilities Reporting. Reports are controlled by events. A report program contains a collection of processing blocks for different events that are always triggered externally. In a report, you can react on events by programming the corresponding processing blocks or ignore the events by not writing the corresponding processing blocks or ignore the vents by not writing the corresponding processing blocks. A report itself never creates events. Reports can use logical databases or select statements defined by developer. For each application, SAP supplies logical databases. Or you can easily create logical databases yourself. Event control of a report corresponds to a certain scheme.


When a report is executed, the ABAP/4 processor creates together with the logical database use (if any) a sequence of certain events for which you can program processing block. The chronology of the events is (more or less):

Steps involved in creating a Report: 1. Processing the selection screen. After starting a report, the selection screen allows the user to enter limits or control values for further report processing. The report can contain several processing block for events during selection screen processing, for example, for checking the input values. 2. Reading the database After selection screen processing come the events for reading the database. Either the report reads data from relational databases it using the corresponding APAP/4 statements (OPEN SQL) or leaves this task to a logical database. In the latter case, the logical database creates a sequence of events to allow the report to copy the data. 3. Evaluating data and creating lists During or after the database the report creates the output list. During list creation, several events allow you to layout the output list (for example, layout the page header). 4. Outputting a list The last part of the processing sequence controlled by the ABAP/4 processor is the list output on the screen or printer. When displaying the list on the screen, the report user can trigger a number of other, interactive, events, for example, by clicking the mouse. By programming processing blocks for these events, you can change a normal report to a so-called interactive report. If a report does not contain event keywords, the entire coding of the report belongs to a single processing block, which is called by a standard event. This standard event is triggered directly after processing the selection screen. DIALOG PROGRAMS Characteristics of a Dialog Program: You use dialog programs to execute transactions. The users of dialog programs in dialog session are read and change database tables. Apart form the actual data processing (Open SQL), update and en-queue concepts are of great importance when programming dialogs. Dialog programs are not stand-alone. To execute dialog programs, they must be linked to at least one screen that itself is linked to a transaction code. The transaction code determines the initial screen with which the dialog session starts. Dialog programs are controlled by screen flow logic. The actual ABAP/4 dialog program is a so-called module pool. A module pool contains a collection of dialog modules that are called by the screen flow logic.


To each module pool, at least one but usually several screens are allocated. Each screen has flow logic. The flow logic contains of BPO (Process Before Output) and PAI (Process After Input) blocks. This flow logic does not use the ABAP/4 programming language and the ABAP/4 Editor tool, but a special statement set and the Screen Painter tool, which you also use to layout screens. The flow logic mainly contains the chronologically ordered calls of the modules in the corresponding module pool. The Collection of PBO flow logic, screen and PAI flow logic is called Dynamic Program (Dynpro). A module pool must have at least one dynpro. Each screen of a dialog session thus is the visible part of a dynpro, to which also the flow logic belongs. The processing logic of a dialog session is stored in the corresponding module pool in the form of ABAP/4 modules. The ABAP/4 modules in the module pool are separated into PBO and PAI modules. The PBO or PAI blocks of the flow logic of each dynpro of a module pool can call each PBO or PAI module of this module pool. You can use ABAP/4 statements in the processing logic of the module pool to control the chronology of the different dynpros. After starting a dialog session via the transaction code, which is firmly connected to a dynpro of the module pool, the screen flow logic passes user entries to the processing logic in the ABAP/4 module pool. The processing logic processes the user entries (database accesses) and, if required, defines the appropriate subsequent screens.

Data Types and Data Objects Data types and data objects are essential components of the ABAP/4 type concepts. Both can be declared and maintained by user. Unlike other programming languages in ABAP/4 you can create DATA TYPES independently. Data Types Are pure descriptions No memory is associated with data types. Describes the technical properties of data objects. Structure and definition classify data types. Can be of: 1. 2. Elementary or structures Predefined or use4r defined. ELEMENTARY Predefined C, D, F, I, N, P, T, X You can use directly STRUCTURED Predefined types are TABLES User-defined Based upon elementary Data types Ex. TYPES: number type i. Cannot allocate memory to types. User defined structured types are Field String and internal tables.

Data Objects Data objects are units created during runtime. Data object cannot exist without data type.


Occupies memory space.

Kinds of Data Objects 1. INTERNAL DATA OBJECTS Literal A literal has a fixed value. Ex. WRITE WORK HARD. Variables DATA statement is used to create variables. Ex. DATA: NUM TYPE I. NUM is a variable declared by DATA statement. Any variable, which you use in program, need to be declared before you use it and can be done by DATA statement. Here variable is declared by referring to existing data type. Variable can also be declared by referring existing data object. Ex. We have already declared NUM by DATA statement. DATA : PRICE LIKE NUM. Here variable is declared by using LIKE parameter, which tells system that price has all the attributes of data object NUM i.e., PRICE is also of type I. The main difference between TYPE and LIKE parameter when defining or declaring the object is that TYPE is used to refer existing DATA TYPE (elementary or structured or user defined) while LIKE is used to declare data objects with reference to existing DATA OBJECTS. Constant Constant is a data object, which contains fixed value through out the program. Constant can be declared in program by using CONSTANT statement. Ex. CONSTANT: INT TYPE I VALUE 15. In program value of INT cannot be changed. If you give a statement like INT = 20. In this case system will give error. 2. EXTERNAL DATA OBJECTS Are defined in tables i.e., In ABAP/4 dictionary. You can access this data from table. TABLES: SFLIGHT. DATA: SEATS LIKE SFLIGHT-SEATSMAX. 3. SYSTEM-DEFINED OBJECTS SPACE & SYSTEM VARIABLES like sy-uname, sy-datum, sy-repid. 4. SPECIAL DATA OBJECTS PARAMETERS: are variables, which can accept value from user.


SELECTIONS CRITERIA: are special internal tables to accept value range from user.

Need for Data types: Consider the following example. DATA: fname(20), mname(20), Iname(20), add1(20), add2(20), add3(20)

If you have DATA statement like above, and if you need to change the length of all the fields say from 20 to 25, then you need to change all the fields i.e., going through each and every statement. But consider the following case where TYPES has been used. TYPES: string(20) DATA: fname type string Mname type string Lname type string Add1 type string Add2 type string Add3 type string In this case if you need to change the length of all fields from 20 to 25. then just change the length of STRING and change will reflected for all the fields. If you define all the types in TYPE-POOL ie., global definition of all the types, you can use these types anywhere and in any program. Parameters Parameter statement is used to accept input from user. PARAMETER statement is used when you want user to enter data and depending upon what he enters you need to take action. The parameter statement declares the variable and also allows system to accept data into that variable. Syntax. Parameters : num type i. Here parameter statement declares the variable and creates the selection screen on which user enters the data i.e., in this case num is declared of type I and user can enter any number. Entered value is stored in the same variable and can be used in program. Data : m type I Parameters : num type I M = num + 5


Write : / The number is m. You can define default values with parameter statement for example Parameter : num type I default 12. In this case when selection screen is displayed the default value is displayed. User can either use same value or overwrite the value. Parameter of type character and length one, can be displayed as checkboxes and radio buttons. Parameter : C1 as checkbox C 2 as checkbox Parameter : R1 radiobutton group g1 R2 radiobutton group g1 When parameter is defined as radiobutton, it needs to be attached to one group. Only one radiobutton of one group can be clicked. Every parameter can be associated with language dependent text that is displayed on the selection screen. This can be done by using text elements. WRITE STATEMENT About WRITE statement The basic ABAP/4 statement for outputting data on the screen is WRITE. Syntax : write <field> This statement outputs the field <f> to the current list in its standard output format. By default, the list is displayed on the screen. The field<field> can be any variable or table field or just literal. PROGRAM ZDEMO WRITE : /HELLO When you start this program, the system leaves the current screen i.e., your editor screen and branches to the output screen, which is also called as, list screen: The list screen has the same name as the title of the program specified in the program attributes. First line on the screen contains the list header. By default, the list header is the same as the title of the program. The current page number (1) appears on the right. The list header is followed by one line and then the output is displayed. Write : HELLO Write : WORK HARD On the screen, the output is normally left justified. But in above case, because we have used two WRITE statements, the output fields are displayed one after the other, each separated by one column (i.e., one blank). If there is not enough space for an output field on the current line, a new line is started. Almost all system-defined fields are right justified except FLOAT, INTEGER, and PACKED i.e., number field. The numeric data types F, P and I are right justified and padded with blanks on the


left. If there is sufficient space, thousand separators are also output. If a type P field contains decimal places, the default output length is increased by one. With the data type D, the internal format of a date differs from its output format. When you use the WRITE statement for outputting data, the system automatically outputs dates of type D in the format specified in the users master record (e.g. DD/MM/YYYY or M/DD/YYYY). Formatting output You can position the output of a WRITE statement on the screen by making a format specification before the field name as follows : Syntax WRITE AT [/][<pos>][(<len>)]<f> Where .the slash / denotes a new line, <pos> is a number or variable denoting the position on the screen, <len> is a number or variable long denoting the output length. For variables you need a mention the AT, for direct values it is not necessary. DATA : LEN TYPE I VALUE 10, POS TYPE I VALUE 11, TEXT (10) VALUE 1234567890 WRITE AT POS (LEN) TEXT. This produces the following output on the screen : The text 1234567890 appears in the text. If the output length <len> is too short, fewer characters are displayed. Numeric fields are truncated on the left and prefixed with an asterisk (*). All other fields truncated on the right, but no indication is given that the field is shorter. DATA : NUMBER TYPE I VALUE 1234567890, TEXT (10) VALUE abcdefghij WRITE : (5) NUMBER, /(5) TEXT. This produces the following output : 7890 adcde In the default setting, you cannot create empty lines with the WRITE statement. WRITE : One / , / Two The output looks as follows : One Two The system suppresses lines that contain nothing but empty spaces.


You can use various formatting options with the WRITE statement. Syntax WRITE ..<field><option> Formatting options for all data types Option LEFT-JUSTIFIED CENTERED RIGHT-JUSTIFIED UNDER<g> NO-GAP USING EDIT MASK <M> USING NO EDIT MASK NO-ZERO Purpose Output is left justified Output is centered Output is right justified. Output starts directly under the field <g> The blank after the field <f> is omitted. Specifies a format template <m> Deactivates a format template specified in the ABAP/4 Dictionary. Zeros, these are replaced by blanks. For type C and N fields, leading zeros are replaced automatically.

Formatting options for numeric fields Option NO-SIGN DECIMALS <d> EXPONENT <e> ROUND<r> CURRENCY<c> UNIT<u> Horizontal lines You can generate horizontal lines on the output screen by using the following syntax : Syntax ULINE Will draw a horizontal line. ULINE (10) Will start drawing horizontal line from 10th column position. WRITE at 10(40) SY-ULINE This statement draws a horizontal line from 10th position. Vertical lines Purpose The leading sign is not output. <d> defines the number of digits after the decimal point. In type F fields, the exponent is defined in <e> Type P fields are multiplied by 10**(-r) and then rounded. Format according to currency <c> in table TCURX. The number of decimal places is fixed according to the unit. <u> specified in table T006 for type P fields.


You generate vertical lines on the output screen by using the following syntax : Syntax WRITE [AT [/][<pos>]] SY-VLINE. Blank lines You can generate blank lines on the screen by using the following syntax : Syntax SKIP [<number>] Starting on the current line, this statement generates <number> blank lines on the output screen. If no value is specified for <number>, one blank line is output. In the standard setting, you cannot create empty lines with the WRITE statement alone. To position the output on a specific line on the screen use : Syntax SKIP TO LINE <number> This statement allows you to move the output position upwards or downwards. Branches Like other higher programming languages, ABAP/4 provides standard keywords to control the flow of a program. Usually ABAP/4 programs get executed statement by statement. Many times you need to skip few statements depending upon certain conditions i.e. you change the flow of program. This can be done by : Branching (IF, CASE) Looping (DO, WHILE) However, unlike other languages where you have internal control, ABAP/4 has internal control and external control of the program flow. The internal control is steered by standard keywords as mentioned above. You define this in your program code. The external control is steered by events. Events are generated either from other ABAP/4 programs or from interactive user input (like, for example, using the mouse to click on the screen ). The system does not necessarily process the statements in the same sequence as they are listed in an ABAP/4 program. This makes ABAP/4 an event-driven programming language. The external control plays an important role mainly for report programs. Branching with IF statement The IF statement allows you to divert the program flow to a particular statement block, depending on a condition. This statement block consists of all the commands which occur between an IF statement and the next ELSEIF, ELSE, or ENDIF statement.


Syntax IF <condition1> <statement block> ELSE <statement block> ENDIF If the first condition is true, the system executes all the statements up to the end of the first statement block and then continues processing after the ENDIF statement. To introduce alternative conditions, you can use ELSEIF statements. If the first condition is false, the system processes the following ELSEIF statement in the same way as the IF statement, ELSE begins a statement block which is processed if none of the IF or ELSEIF conditions is true. The end of the last statement block must always be concluded by ENDIF. IF<condition1> <statement block> ELSEIF <condition2> <statement block> ELSEIF<condition3> <statement block> ELSE <statement block> ENDIF ABAP/4 allows unlimited nesting of IF ENDIF statement blocks, but they must terminate within the same processing block. In other words, an IF ENDIF block cannot contain an event keyword. Branching with CASE statement To execute different statement blocks depending on the contents of particular data fields, you can either use IF statement or the CASE statement as follows : Syntax CASE <f> WHEN <f1> <statement block> WHEN <f2> <statement block> WHEN <f3> <statement block> WHEN OTHERS <statement block> ENDCASE. The system executes the statement block after the WHEN statement if the contents of <f> equals the contents of <f1>, and continues processing after the ENDCASE statement. The statement block after the optional WHEN OTHERS statement is executed if the contents of <f> do not equal any of the <f1> contents. The last statement block must be concluded with ENDCASE.


The conditional branching using CASE is a shorter and simpler form of similar processing with IF. When you have many conditions IF becomes more complicated, in such cases CASE is used.

LOOPING Looping with DO statement If you want to write your name say for 10 times, then you need to write WRITE statement for 10 times. When you want to process a statement more than once, you can write this statement within a lop with the DO statement as follows : Syntax DO 5 times Write :/ name ENDDO The system continues processing the statement block for 5 times the loop has been processed so in this case when the loop is over value of sy-index will be 5. In this case you know that, you want to perform WRITE statement for 5 times. But that is not the case always. Many times you need to terminate the loop depending upon certain conditions. This can be done by using EXIT or STOP statement. The important point to remember when you dont you use TIMES option, is to avoid endless loops when working with the DO statement. If you do not use the TIMES option, include at least one EXIT, STOP statement so that system can leave the loop. Exit and stop takes you out of that loop. Looping with WHILE loop If you want to process a statement block more than once as long as a condition is true, you can program a loop with the WHILE statement as follows : Syntax DATA : M TYPE I VALUE 0 WHILE M < 10 WRITE : / M M = M + 1. ENDWHILE The system continues processing the statement block introduced by WHILE and concluded by ENDWHILE statements as long as M is less than 10 or until the system finds an EXIT, STOP. The system field SY-INDEX contains the number of times the loop has been processed. You can nest WHILE loops any number of times and also combine them with other loops.


Difference between DO loop and WHILE is that In WHILE, condition is checked first and if condition is true then loop is executed while in DO loop, the loop gets executed first if you dont have TIMES option and then the condition is checked (if you have any) You can have nested DO and WHILE or DO and IF or IF and IF or any possible situation. String Operations ABAP/4 provides several keywords fro processing data objects of type C, also known as character strings. Shift command To shift the contents of a field, by one position or one character you can use the SHIFT statement. Using SHIFT allows you to shift field contents byte by byte or character by character. With the SHIFT statement, you can execute the following : String = HELLO String1 = ALL OF YOU String3 = WORK HARD Shift String Shift string1 by 2 places Shift string2 right Shift string1 by 2 places circular The output will be ELLO By default if nothing is specified then string is shifted by one position. L OF YOU Here the string is shifted by 2 places. _WORK HARD In this case the string is shifted to right by one place (with leading blanks) K HARDWOR In this case the string is shifted to the left so that 3 characters on the left appear on the right. Replace command You use the REPLACE statement. Syntax REPLACE <str1> WITH <str2> INTO <c> [LENGTH <1>]. ABAP/4 searches the field <c> for the first occurrence of the first <1> positions of the pattern <str1>. If no length is specified, it searches for the pattern <str1> in its full length. Then, the statement replaces the first occurrence of the pattern <str1> in field <c> with the string <str2>. If a length <l> was specified, only the relevant part of the pattern is replaced. REPLACE STR1 WITH STR2 INTO STRING Here whole string is searched for string1 and is replaced with str2. REPLACE & WITH M


Here the system searches string for & and replaces it with M TRANSLATE command Syntax TRANSLATE<c> TO UPPER CASE. TRANSLATE<c> TO LOWER CASE. These statements convert all lower case letters in the field <c> to upper case or vice versa. You can use TRANSLATE to substitute the characters in a string like replace. But the main difference between Translate and Replace is that Replace statement replaces only occurrence of particular character while Translate replaces all the occurrences of the character. When using substitution rules, use the following syntax: Syntax TRANSLATE <c> USING <r> OVERLAY command Syntax OVERLAY <c1> WITH <c2> [ONLY <str>]. This statement overlays all positions in field <c1> containing letters which occur in <str> with the contents of <c2>. <c2> remains unchanged. If you omit ONLY <str>, all positions of <c1> SEARCH command Syntax SEARCH <c> FOR <str> <options> This statement searches the field <c> for the character string in <str>. If successful, the return code value of SY-SUBRC is set to 0 and SY-FDPOS is set to the offset of the string in the field <c>. Otherwise SY-SUBRC is set to 4. STRLEN command To determine the length of a character string up to the last character other than SPACE, use the built-in function STRLEN as follows: Syntax N = STRLEN (STR) Here N is defined in DATA statement as type i. STRLEN processes any operand <c> as a character data type, regardless of its real type. No conversions are performed. CONDENSE command


To delete superfluous blanks in character fields, use the CONDENSE statement. Syntax CONDENSE <c> [NO-GAPS] This statement removes any leading blanks in the field <c> and replaces other sequences of blanks by exactly one blank. The result is a left-justified sequence of words, each separated by one blank. If the addition NO-GAPS is specified, all blanks are removed. CONCATENATE command To concatenate separate character strings into one, use the CONCATENATE statement : Syntax CONCATENATE <c1> <cn> INTO <c> [SEPARATED BY <s>] This statement concatenates the character fields <c1> to <cn> and assigns the result to <c> Trailing blanks are ignored during this operation. CONCATENATE STR : STR2 INTO STRING Here str, str2 and : is concatenated and result is stored in string. SPLIT command To split a character string into two or more smaller strings, use the SPLIT statement : Syntax SPLIT <c> AT <del> INTO <cl> . <cn> This statement searches the character field <c> for delimiter strings <del> and the parts before and after the delimiters are placed in the target fields <c1> <cn> To place all fragments in difference target fields, you must specify enough target fields. Otherwise, the last target field is filled with the rest of the field <c> and still contains Delimiters. SPLIT STRING AT , INTO P1 P2 P3 P4 Here the string is split at , and is put into strings p1, p2, p3, p4. In ABAP/4, you can specify offset values for elementary data objects in all statements, which process these data objects. To do so, specify the name of a data object in a statement as follows : Syntax <f>[+<o>][(<1>)]


The operation of the statement is performed for the part of the field <f> that begins at position <o>+1 and has a length of<l> If the length<l> is not specified, the field is processes for all positions between <o> and the end of the field String = string l + 3(4) Assuming that string 1 = abcdefgjk Here string will contain defg OPEN SQL In the R/3 system, long-life data is stored in relational database tables. Structured Query Language (SQL) was created for accessing relational databases. SQL has two statement types : Data Definition Language (DDL) statements and Data Manipulation Language (DML) statements. TO include these SQL statements in an ABAP/4 program, use Native SQL to avoid incompatibilities between different database tables and also to make ABAP/4 programs independent of the database system in use, SAP has created a set of separate SQL statements called Open SQL. Open SQL contains a subset of standard SQL statements as well as some enhancements, which are specific to SAP. Using open SQL enables you to access any database tables available to the SAP system, regardless of the manufacturer be it oracle, Informix etc. The difference between Open SQL and Native SQL is as follows : A database interface translates SAPs Open SQL statements into SQL commands specific to the database in use. Native SQL statements access the database directly. Open SQL keywords Keywords Used for SELECT : Reading Data from Database Tables INSERT : Adding Lines to Database Tables UPDATE : Changing Lines in Database Tables MODIFY Adding or Changing Lines DELETE : Deleting Lines from Database Tables When using open SQL statements in an ABAP/4 program, you must ensure the following: 1. 2. The database system being addresses must be supported by SAP The database tables being addressed must be defined in the ABAP/4 Dictionary. Select Statement The following system fields play an important role in Open SQL operations : SY-SUBRC As with other ABAP/4 statements, the return code value in the system field SY-SUBRC indicates after each Open SQL operation whether or not the operation was successful. If an operation is successful, SY-SUBRC = 0. If an operation is not successful SY-SUBRC <> 0. SY-DBCNT


The value in the SY-DBCNT field indicates how many lines were affected by the operation or how many lines have already been processed. To read data from a database table, use the SELECT statement. Syntax SELECT <what> FROM table name> [INTO <variable, another table>] [WHERE <condition<] This statement has several basic clauses. Each clause is described in the following table. SELECT <what> FROM table name> [INTO <variables or another table>] [WHERE <condition<] The SELECT clause defines whether the result of the selection is a single line or a whole table, or few columns. FROM <table name> The FROM clause specifies the database table or view <source> from which the data is to be selected. INTO<variable, another table> The INTO clause determines the target area <target> into which the selected data is to be read. It can also be placed before the FROM clause. If you do not specify an INTO clause, the system uses the table work area. The table work area is a header line, which is automatically created by the TABLES statement. WHERE <condition> The WHERE clause specifies which lines are to be read by specifying conditions for the selection. Choosing the Lines to be Read For Selecting All data from table. i.e., read all columns and all the rows from database table. Syntax SELECT * FROM <table> (Here you are not specifying WHERE condition) Selecting All Data from a Single Line To read all columns of a single line from a database table, use the SELECT statement as follows: SELECT SINGLE * FROM <table> .. WHERE <condition> The result of this statement is a single line. To make sure you retrieve desired unique single record, you must link all the fields which form the primary key of the database table by AND in the WHERE condition. Prerequisite for SELECT SINGLE 1. Use all primary keys in WHERE condition 2. Always check for SY-SUBRC


3. Clear work area for table Aggregate Expressions By using aggregate expressions, you can extract characteristic data from a column <a> of the database table. MAX MIN AVG SUM COUNT (*) : : : : : returns the maximum value of the column returns the minimum value of the column returns the average value of the column counts values or lines as follows. returns the total number of lines in the selection.

You must include spaces between the parentheses and the arguments. The arithmetic operators AVG and SUM can only work with numeric fields. Sometimes you retrieve few columns form database table i.e., you have list in the SELECT Clause and INTO Clause. If there is a list in the SELECT clause, you must use the INTO clause with the SELECT statement. You can use either a work area <wa> or an internal table ,itab> or list of variables as an argument. Syntax TABLES : SFLIGHT DATA : CARRID1 LIKE SFLIGHT-CARRID, CONNID LIKE SFLIGHT-CONNID SELECT CARRID CONNID FROM SFLIGHT INTO CARRIDI, CONNIDI) WRITE :/ CARRIDI, CONNIDI ENDSELECT Many times you retrieve related data from two or more tables. In such cases you use nested selects by linking tables with common primary keys. But as far as possible avoid using nested selects as time required to access nested table is very high. Syntax : TABLES : SFLIGHT, SBOOK SELECT * FROM SFLIGHT WHERE CARRID = LH SELECT * FROM SBOOK WHERE CARRID = SFLIGHT CARRID AND CONNID = SFLIGHT CONNID WRITE : / SFLIGHT CARRID, SFLIGHT CONNID, SBOOK BOOKID. END SELECT END SELECT Some performance hints for Open SQL statements. Keep the selected dataset small Keep the number of selected data as small as possible to avoid unnecessary network transports. Use the respective Open SQL statements always with the WHERE clause. Avoid complex WHERE clauses. The system must split up those into single statements for the database system.


Do not use the logical NOT in WHERE clauses but inverted operators instead. The logical NOT is supported by the database indexes. Keep the transferred data small Transfer only those columns of a database table that you really need. Avoid SELECT if you do not want to read all columns of a database. Use a list in the SELECT clause instead. Use aggregate expressions in the SELECT clause to perform calculations instead transporting great amounts of data calculating thereafter. Keep the number of database accesses small Use operations on packages of data instead of operations on single data if you want to analyze selected data more than once. To do so, transfer the data in a single operation between database tables and internal tables. Avoid nested SELECT loops. Instead, work with internal tables and SELECT statements using the FOR ALL ENTRIES addition. Insert Statement INSERT statement inserts a single record into the database table. Syntax Tables : sflight Sflight-carrid = LH Sflight-connid = 234 Insert sflight. Table sflight is inserted with the record. The SY_SUBRC is returned for this statement. If the entry already exists then the SY-SUBRC is set to non-zero value and you can do processing for existing record by giving some error message. Update Statement To update database table UPDATE statement is used. This allows you to change either a single record or several records. You can use UPDATE when you know which record you want to change. But if you do not know whether the primary key of the line you want to insert already exists or not, you can use the MODIFY statement. The MODIFY statement changes existing lines and inserts lines which do not exist. Sflight-carrid = MN Sflight-connid = 454 UPDATE SFLIGHT where CARRID = LH Or TABLES SFLIGHT UPDATE SFLIGHT SET PRICE = 1100 WHERE CARRID =LH Here price of sflight will get updated with new price 1100


Delete statement To delete records form a database table, you use the DELETE statement. DELETE FROM SFLIGHT WHERE CARRID = LH AND CONNID = 454. Will delete the single record where conditions are met from SFLIGHT. You can delete the multiple records from database table by putting all the record, which you want to delete in internal table. For example DELETE SFLIGHT FROM TABLE ITAB. In this case whatever you have in internal table will be deleted from SFLIGHT. Note : append internal table with al the entries, which you want to delete.

EXERCISES SIMPLE WRITE STATEMENTS 1. write a program which generate the model list as shown. Use these system fields in your program. SY-DATUM, SY-UZEIT, SY-UNAME Maintain the list headings. 12/12/97 FIRST PROGRAM This list is generated On : 12/12/1997 At : 13:40:35 By : ABAP1 2. Create a list as shown --------------------------------------------------------------------------------------------------------------------------------XYZ Co. Pvt. Ltd. Date: todays date Page No.1 ------------------------------------------------------------------------------------------------------------program name: ZDEMO. SYMBOLS, ICONS AND FORMATTING 1. Write a program to show the following using system variables (hint :use include <symbol>and include<icon>) Symbols: Telephone, Fax machine, Hand pointing left, Hand pointing right, Caution,


Egg: write sym _phone as symbol, telephone.

2. Write a program to show a string with different background colors. Ex : Write HEADER color col_heading. (Col_heading is abap/4 name for grayish blue color. Other colors are col_key for bluish green, col_normal for bright gray, col_background for gray, col_positive for green, col_negative for red, col_group for violet and col_total for yellow) 3. Use Format intensified-format intensified off, Format color<color_ name>-format off, Format inverse-Format inverse off.

4. Show current time and todays date 5. Show a value 23456 as 12:34:56 using using edit mask. 6. Take a number as 0000011. Suppress all leading zeros. 7. suppress assign before a number. GENERAL PROBLEMS 1. Create an adding machine for numbers The two values to be added must be entered on the selection screen as parameters. Output the result. 2. Create the dividing machine for numbers. The two values must be entered on the selection screens as parameters. Output the result. 3. Create your output as shown below. * ** *** **** ***** 4. Write a program accept the two numbers from the user and swap the values. 5. Declare a string echo and design your output e ec ech echo ech ec e


DO-ENDDO,IF-ELSEIF-ELSE-ENDIF,CASE-ENDCASE 1. Write a program with Do-Enddo loop, Display squares of numbers 1 to 10. 1 1 2 4 3 9 2. Write a program to accept a number(say 2)from user and create a multiplication table. 2*1 = 2 2*2 = 4 2*10 =20 3. Accept. a number from user and find Factorial of the same. If the number is negative then display some message 4. Write a program with Do-Enddo loop first 20 numbers. -Output should contain only Even numbers -Odd numbers should not be displayed 5. Accept numbers and choice EVEN or ODD from the user and display the numbers in that range according to users choice. 6. Write a program with Do-Enddo loop for first 20 numbers. -Odd numbers &Even numbers should be displayed with alternate intensities.(Use Format intensified-on-off) 7. Create a calculator which perform the four basic types of calculations on two whole numbers. The two values and the option to be entered on the selection screen as parameters. Output the result with 2 decimal places. 8. Write separate programs using CONTINUE and EXIT statements in DO-LOOP

STRING OPERATIONS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Accept a string and determine its length. Accept a string & number. Write the string that many number of times. Accept two strings and swap their contents. Accept two strings and concatenate into one string. Accept one string with delimiter (, or ;) and split it into two strings. Accept a string abcdef and use shift <string>, shift <string>right, shift<string> up to def. Accept a string eg. Apple. Change first occurrence of p to b. (use replace command) Accept a string eg. Apple. Change all the occurrences of p to b. (use translate command) Accept two strings and compare the two strings using co, ca, cs, cp. (output shall be true or false for each comparison.) Accept a string ABCDEF. Output only DEF using offset command. Accept first name, last name and middle name. Eg. Nandamuri Taraka Ramarao display as N.T.Ramarao. Accept a string. Change all occurrences of a to b. Accept a number and swap first and last digit of the same.

12. 13.


14. 15.

Accept a string and display the string in reverse order. Accept a string and check for palindrome.

DATE PROBLEMS 1. Accept a date earlier to todays date and find the difference in number of days. 2. Accept a date from user and display first day of the month and last day of the previous month. 3. Accept a date from user and add six months to the date. 4. Accept a date from user and convert month part to jan. feb etc., and display this date. 5. Write a program to accept month. Display no. of days in that month. Make use of -Text element for your selection screen box. -selection text. 6. Accept birth date from user and output age in years, months and days. CHECK BOXES AND RADIO BUTTONS 1. Write a program with - Parameter as checkboxes - If checkbox 1 is clicked write c.b 1 clicked else c.b 1 not clicked - If checkbox 2 is clicked write c.b 2 else c.b not clicked. - If checkboxes 1 & 2 are clicked write c.b 2 are clicked. - If checkboxes 1 & 2 are not clicked write c.b 1 & c.b 2 are not clicked. 2. Write a program with - Parameters as two groups of Radiobuttons(two radiobuttons in each group). - Give detailed coding as abov, to show the Radiobuttons and groups - Selected. 3. Write a program with - Parameter as checkbox - If you click the checkbox then display first day of the next year. - If the checkbox is not clicked then display last day of the current year. 4. Write a program with -Parameter a group of 3 radiobuttons -If first radiobutton is clicked, display last day of the current month. If second radiobutton, display first day of the next month. If third radio button, display date after six months. SELECT STATEMENTS 1. 2. 3. 4. 5. 6. 7. List all the rows from the table VBAK. List single row from the table BKPF. List up to 5 rows from the table BSIS. List all ERDATs. For better readability crate a column heading in the list. Display total amount for carrid LH. (Tables : SFLIGHT) List all the flights for which booking date is grater than01.06.1995. List all the flights for which payments currency is DEM.


8. 9. 10. 11.

List all the flights where carrid is between LH and SQ. Select a single record where carrid = LH, flight-no = 0400 and fldate = 28.02.1998. Display carrid, connid, fldate and luggage weight multiplied by 2. List the maximum capacity, occupied seats a total of current bookings for each flight in the following format. Max.Capacity Occupied seats Total of current bookings

Carrier id

12. From the given from-city and to-city, list all the available on this route: From:<from-city> To:<to-city> (say from Frankfurt to Madras) Carrier id C OPEN SQL 1. Accept document no. from user and display particulars of sales document. (default no. 001000031) (Table : VBAP) Created on : xxxx Created by : xxxx Time : xxxx 2. Accept sales document no. from user and display corresponding material no. description of that material and item category (Table : VBAP) 3. Accept material no. & item category by default PP100 and KMN respectively. Display corresponding details of sales document (table : VBAP) 4. Display fields from BKPF. Document type = AB and Document date = 05.02.1998. Also display no. of records selected. 5. Display Co.code., acct.ttype. tax code. Make use of select-options to give range of document type. Display title of your program at the end of program. 6. Accept from user. Display, doc.status, date of doc., doc.type. 7. Display single record for document where date = 05.02.1998, type = AB and document no. = 0100000006. 8. Accept plant from user eg. PLTP. Display document details for that plant like, doc.status, date of document etc., DEBUGGING Many times an error free program doesnt give desired output. Behavior of program is different in different situation, with different values of variable. Such program needs additional testing, by which you can test the program by stopping each point where you feel program is behaving abnormally. Departure time Start Airport Destination Airport


The ABAP/4 debugger is the development workbench tool, which allows you to stop a program during its execution when a particular condition is met. When the program is stopped, you can use the debugger to display the contents of the table and variable being used by the program. It allows you to execute the program step by step, reviewing exactly the real flow of the program execution. There are many occasions during normal system operation during which the ABAP/4 automatically started when the system encounters a breakpoint. Starting the ABAP/4 debugger There are many ways to start debugger -By clicking the Execute button and selecting the debugging mode. -From the ABAP/4 editor, by executing a program choosing Program Debugging from the menu. -Setting breakpoint in the program. Components of ABAP/4 debugger The debugger shows the program information using six different views. O Presents the program structure, events, subroutines and modules. S displays the calling sequence within a particular event, up to the current breakpoint. V it is the default view, which displays the contents up to four field. F Displays the field contents and in this view you can define values for the watch points. T Allows modifying the contents of internal table. P displays all program, which are needed for program debugging including system program.


All these options are shown in the following screen.


Arrow indicates the breakpoint of the program i.e., where user has stopped the program. Breakpoints A breakpoint is the signal, which is specified in the program, tells the system to stop the program execution and to start the debugger. Following types of breakpoint are available with ABAP/4. Static are set up with the BREAKPOINT keyword inside the program, which you can directly display with the ABAP/4 source code editor. To set the breakpoint in the program enters the keyword BREAKPOINT. Dynamic this breakpoint is not visible in the code. Position the cursor over the source code line to have the breakpoint and then select utilities -> breakpoint -> set. You can delete them or display them from breakpoint list. Or you can execute the program in the ABAP/4 debugger i.e., in debugging mode. Watch points are field specific. The program is stopped when the field reaches the value specified in the watch point. Execute the program in debugging mode. Position the cursor over the needed field. Press the F button to get the view of field. Select the checkbox for the needed watch point. Click on the continue button. Keywords / events . The program stops just before executing a specific event / keyword. To set breakpoint at particular event from initial screen of debugger, select Breakpoint -> Breakpoint at -> at event at keyword. Enter the name of the keyword or event. Click on the OK. Navigating through the breakpoint


Following buttons are used to navigate through the program and debugger.

Single step Executes a single program command. Execute Similar to single step, but when a program calls a subroutine, it executes the whole subroutine unlike single step. Continue Executes the program until it is finished or until it finds next breakpoint. Return Allows for executing the program instruction up to the end of a routine and stops in the line of code where the subroutine gives back control to the main program. Tables switches the debugger to the table view. Displaying and modifying values Every time the program is stopped within a debugger, you can display and modify the contents of table field and fields. To display the fields, click on V and you can view the contents of system field, program field, ABAP/4 dictionary fields, and external program fields. Displaying and modifying internal tables When you click on the Table button from the initial ABAP/4 debugger screen, the system will display the table debugger view. Here you need to enter the name of the internal table to be displayed. You can modify or delete or add i.e., insert the internal table contents. These changes are applicable only for the debugging and do not affect the structure of internal table in the program.

Setting WATCHPOINTS Execute a program in debugging mode. Position the cursor over the needed field. Press the F button to get a view of the fields. Select the checkbox for the needed watch point. Click on the CONTINUE button. To display the active watch point select Goto -> Breakpoint INTERNAL TABLES Consider the following cases : You want to reorganize the contents of table . You want to modify few details of table and then display the contents of table to user. You want to perform table calculations on subset of database table. In above cases you need to reorganize or to change the database table contents. In ABAP/4 you work mainly with tables. Long life data is stored in database tables. You cannot afford to lose data from database table. In such cases where you can not work directly with database table (where you are modifying contents of table or reorganizing the contents of table or


any other case where you are altering contents of table and then displaying output to the user) hence need of intermediate table where you put in all the data from database table and work with this data thus avoiding accidental loss of data. These intermediate tables are called INTERNAL TABLES in ABAP/4 and are Created only during runtime i.e., no memory is reserved for internal tables. When you use Internal Table in program, three steps are associated with it. 1. Declaration of Internal Table. 2. Populating internal Table. 3. Processing Internal Table. DECLARATION OF INTERNAL TABLE Depending upon how you create, internal tables are of two types. Internal tables with header line When you create internal tables with header line, then default workarea or header is created. And you can work with this header. Internal Table without header line. In this case you need to create explicit workarea to work with table. Only advantage of internal tables without header line is that you can nest them i.e., you can have table within table. Which is not possible in internal tables with header line.

Internal table can be declared in following ways. Data : itab like sflight occurs 0 with header line. Here you are declaring internal table which is similar to sflight i.e., itab like sflight i.e., you are referring to existing table (like). (By default internal table created with this declaration is without header line) Data : Begin of itab occurs 0. Include structure sflight. Data : End of itab. (Internal Table created with this type of declaration is similar to declaration done in a type the only difference is by default internal table created by this type is with header line) Data : begin of itab occurs 0. carrid like sflight-carrid, connid like sflight-connid, fldate like sflight-fldate, end of itab.


By default internal table created by this type of declaration is with header line. In this type of declaration, you are using only those fields from databvase table which you require for processing. Data : begin of itab occurs 0, carrid like sflight-carrid, connid like sflight-connid, bookid like sbook-bookid, id like scustom-id, end of itab. Here you are combining fields from three different tables in one internal table. Data : begin of itab occurs 0. Carrid like sflight-carrid. End of itab.

POPULATING INTERNAL TABLE Itab-name = ABCD Append Itab. (In this case itab is filled with one name i.e., ABCD) Do 5 times. Itab-number = sy-index. Append itab. Enddo. ( In this case itab is filled with sy-index for 5 times) Select * from sflight into itab. Append itab. Endselect. Select * from sflight into table itab. (note that with one addition of TABLE into select statement, you omit append itab and endselect) Select * from sflight. Move-corresponding sflight to itab. Append itab. Endselect. (Note that when you use move-corresponding, field names of your database table and internal table should be same) Select * from sflight. Move sflight to itab. Append itab. Endselect. (In this case structure of sflight and itab should be similar).


Select carrid1 connid1 from sflight into (itab-carr1,itab-connid1). Append itab. Clear itab. End select.

PROCESSING INTERNAL TABLES Processing of internal table includes: Writing : write: / itab-carrid. (will write only one field) loop at itab. (to write whole internal table) Write itab. Endloop. Reading : You can read internal table by Read table itab with key carrid = LH. (here you are reading table with key) Or Read table itab index 3. (Here you read table with index 3) (Note : Reading of internal table can be done inside the loop or outside the loop) Modifying : You can modify contents of internal table by specifying key or index. Itab-carrid = LM Modify table itab index 3. Delete : delete table itab index 3. (will delete record with index 3)

Commands associated with clearing of internal tables are as follows: Clear itab Clear itab[] Refresh itab Free itab : Will clear header of internal table. : Will clear body of table. : Will remove contents of internal table. : Will deallocate memory associated with internal table.

Sorting of Internal tables To sort contents of internal table you can use SORT ITAB This command will sort internal table on all non-numeric primary keys in Ascending order. To specify internal table for given key the syntax is. SORT ITAB BY CARRID ASCENDING. In this case the table itab is sorted with carrid key in ascending order. You can sort table in either ASCENDING or DESCENING order. ASCENDING. The default order is

You can sort table with multiple keys also. The number of SORT key fields is restricted to 250. If you specify more than one field then the system sorts the records first by f1, then by f2 ad so on. (Here f1,f2 are the fields)


Control Break Statements Control break statements are used to create statement blocks which process only specific table lines inside the LOOP ENDLOOP block. You open such a statement block with the control level statement AT and close it with the control level statement ENDAT. The syntax is as follows: Table should be sorted when you use control-break statements. You can break the sequential access of internal tables by using these statements. SYNTAX At first. <statement block> endat. This is the first statement to get executed inside the loop (remember control break statements are applicable only inside the loop) So in this block you can write or process those statements which you want to get executed when the loop starts. At new carrid Write : / carrid. Endat. In this case whenever the new carrid is reached. Carrid will be written. At end of carrid. Uline. Endat. In this case whenever the end of carrid is reached a line will be drawn. At last. Write : / all records over. Endat. Processing of statements within this block is done when entire processing of entire internal table is over. Usually used to display grand totals. You can use either all or one of the above control break statements with in the loop for processing internal table. At end of carrid. Sum. Endat. In above case the statement SUM (applicable only within AT-ENDAT) will sum up all the numeric fields in internal table and result is stored in same internal table variable. SUBROUTINES


The process of breaking down a large program into smaller modules is supported by ABAP/4 through subroutine also called forms. Subroutines are programs modules which can be called from ABAP/4 programs. Frequently used parts of program can be put into subroutines and these subroutines can be called explicitly from the program. You use subroutines mainly to modularize and structure your program. DEFINING SUBROUTINES A subroutine is block of code introduced by FORM and concluded by ENDFORM. Following syntax is used to define a form or subroutine: FORM <name> <parameters> . ENDFORM. Here parameters is optional. You can have plain subroutine without the parameters for example. FORM SUB1. ENDFORM. CALLING SUBROUTINE You can call subroutines from program by following statement: PERFORM <subr> [<para>] Parameters are optional. i.e, You can call subroutine without passing any parameter. Perform SUB1.

PASSING DATA TO SUBROUTINES When you work with global data in subroutines, you can put a copy of the global data on a local data stack and use it to avoid accidental loss of data (In this way you protect global data) You can pass data between calling program and subroutines by using parameters. Parameters which are defined during definition of a subroutine with FORM statement are called formal parameter. Parameters which are specified during the call of a subroutine with PERFORM statement are called actual parameter. Parameters are passed to the form either: o By Value. o By Reference. o By Value and return. BY VALUE Data: a type I value 20. Perform sub1 using a. Write a. FORM sub1 using value (p_a). P_a = 15.


ENDFORM. In this case during subroutine call, the formal parameter are created as copies of actual parameter. The formal parameter have their memory of their own. Changes made to formal parameter have no effect on the actual parameter. Like in this case, through value of p_a is changed to 15, it has no effect on a which remains as 20. BY REFERENCE. DATA : A TYPE I VALUE 20. PERFORM SUB1 USING A. WRITE A.

CALLING A FORM VALUE OF A FORM SUB1 USING (P_A). PROGRAM P_A = 15. ENDFORM. By default system calls all the form by reference.


VALUE OF A FORM (p_a = 15)

In this case ,only the address of the actual parameter is transferred to the formal parameters. The BEFORE change the A = 20 formal parameters has no memory of its own .if youCALLING formal parameter, change is visible in actual parameter also. FORM BY VALUE AND RETURN. BY VALUE Data: a type I value 20. Perform sub1 changing value (p_a). P_a = 15. Endform.

A = 20

P_A = 100 (changing value of p_a) A = 20

In this case if you change formal parameter ,then the value of actual parameter is changed FROM FORM when the control is transferred back to the main program. Assuming A is declared by DATA statementA = 20 value 20 and subroutine SUB1 is called by and has passing A.





A = 20 P_A = 100 (changing value of p_a) A = 100




A = 20 P-A = 100 (changing value of p_a) A = 20 48



Passing Table To The Subroutine You can pass internal tables as parameters by using or changing in the form and perform statements. If you want to access the components of the internal table, you must specify the type of the corresponding formal parameter. You also must distinguish between internal tables with or without header lines. For internal tables with header lines, you must specify the table body by using square brackets [ ], after the table PROGRAM ZDEMO. name to distinguish it from the header line.

DATA: Begin of itab you can With internal subroutines, occurs 0,use TYPE or LIKE to, refer to the internal table you want to pass directly. Number type I,
You can pass all internal tables as parameters in this list after TABLES in the FORM and PERFORM statement. Internal tables passed with TABLES are always called by reference.

End of itab


If you can pass an internal table with header line, the table body and the table work area are passed to theITAB LOOP AT subroutine. If you pass an internal table with out a header line, a header line is created automatically as a local data object in the subroutine. WRITE:/ itab-number.



After starting ZDEMO the output appears as follows: 1 2 3 In this example, an internal table ITAB is declared with a header line. ITAB is passed to the subroutine SUBI, where it is filled using the table work area F_ITAB. And itab is written in main program.

FUNCTIONS About function Function modules are special external subroutine stored in a central library. The R/3 system provides numerous predefined function modules that you can call from your ABAP/4 programs, and plus you can create you own functional modules. The main difference between a function module and normal ABAP/4 subroutine is as follows: Functions are stored in central library and have global presence while subroutine is confirmed to a particular program. Subroutine cannot return values while functions can return values. Unlike functions subroutines cannot handle exceptions. And last but not least, the difference in the way the parameters are passed to the functions. Declaring data as common parts is not possible for function modules. The calling program and the called function module have separate work areas in ABAP /4 dictionary tables. You use the ABAP/4 workbench to call and maintain functional modules. You can combine several function modules to form a function group in the function library. Since you can define global data that can be accessed from all function modules of one function group, it is reasonable to include function modules that operate with the same data, for example internal table for sales module can be grouped, in one function group. Via the ABAP/4 development workbench screen, choose development Function library or select function library in the application toolbar or use se37 transaction code.


The Function Library:


The function library maintain Function Modules screen displays following components: All function name should start with Z_or Y_ followed by any name. Source code. Documentation. Administrative info. Import-export parameters. Table parameters and exception interface. Global data. Main program. (not necessarily in the same order) Documentation The documentation describes the purpose of the function module, lists the parameters for passing data to and from the module, and the exceptions. The parameters of the parameter type I are important parameters, which are used to pass data to the function module. Parameters of the parameter type E are export parameters, which are used to pass data from function module to the calling program. Exceptions descr5ibe error scenarios which can occur in function modules. Import-Export Parameters Import parameters correspond to the formal input parameters of subroutines. They pass data from the calling program to the function module.


Export parameters correspond to the formal input parameters of subroutines. They pass data from the function module back to the calling program (which is not possible in subroutines). Table Parameters Table parameters are internal tables. Internal tables are treated like changing parameters and are always passed by reference. Exceptions Exceptions are used to handle error scenarios which can occur in function modules. The function module checks for any type of error and raise exception and returns SY-SUBRC to the calling program. Main program checks this SY-SUBRC for any errors that have occurred and then takes action accordingly. Source Code The ABAP/4 Editor screen displays the ABAP/4 source code of the function module. You can work with the source code in the same way a you would work with normal ABAP/4 programs. Import parameters, changing parameters, and table parameters can be optional. This mean that you can omit the corresponding actual parameter when you call the function in the calling program. If the parameter is optional and the actual parameter is not specified, you can specify a default value for use in the function module. Export parameters are always optional. As with subroutines, you can specify the data types of the formal parameters in the field Reference type. In the field Ref. structure, you can specify ABAP/4 Dictionary reference, structure of fields. Then, the system checks the current parameters against the structure or field at runtime. Testing of Function Module You can test a function module without calling it from an ABAP/4 program via the Functional Library Maintain Function Module screen by choosing single test. You can assign values to the import parameters in the test function module screen. Calling Function Modules. To call a function module from an ABAP/4 program, use the CALL statement as follows: SYNTAX: CALL FUNCTION <module> [EXPORTING f1 = s1 f2 = s2 fn = sn (parameters which you pass from program to function are s1,s2,sn)] [IMPORTING f1 = r1 f2 = r2 fn = rn (parameters which program receives from function in r1,r2,rn)] [TABLES f1 = a1. fn = an] [EXPECTATIONS not valid = 1 not correct = 2 others = 5]


you can specify the name of the function module <module> as a literal or a variable. Parameters are passed to and from the function module by explicitly assigning the actual parameters to the formal parameters in the list after the EXPORTING, IMPORTING, TABLES. If in your function if you have raised exception not valid then this exception can be handled in main program. Functions returns different sy-subre for different exception. REPORTS About Reports Reports, in R/3 system are online programs whose function is to retrieve data from database and display it or print it for the user. All end user often need some information to look up, depending upon it various management decision are taken, or to just see business results or simply to continue work. As R/3 is nothing but collection of all business application is has provided a very powerful feature to satisfy this crucial business need i.e. reports are involved at each and every step of business. This type of extracting, collecting and formatting data, which is stored in the database, is done by REPORT program. The program which is written to retrieve and display data is REPORT program and the data which is displayed on the screen when you execute the program is called as LIST (output of the report) SAP has provided thousands of preprogrammed reports. User just selects a menu option or just one click here and there and the report is displayed. Often user is unaware that by clicking one button he is executing a complicated report program, which is actually accessing database and then displaying the result. An end user might not feel the necessity of writing a report program but a developer has to develop a report manually using the functions and facilities provided by the R/3 system. How to develop a report using these facilities is the purpose of this section. When you display a data, you need to display the data which user needs, for example user wants to see the all the employee record who have joined after 12 th December 1997. In this case user has to pass this information , to the system, that he needs only those employee where joining date is greater than 12th December 1997. For an user it is passing information to the system but for the system it is input from the user. System takes input form the user before it retrieves the data from the database. This is very common requirement of any report as the need of any business is to display data, which is required by user. Selection Criteria System accepts input from user through SELECTION CRITERIA Selection criteria are nothing but input fields which allows the user to restrict information given to program for processing further data. If you dont specify any criteria for selection than your report program produces a long list of data, which might not be needed by the user. Basically, selection criteria are the fields where user can enter some value for which he needs information. Through selection criteria user can enter discrete value or ranges. For example, user wants to see all the records who have joined between 12th December 1997 and 12th May 1998. this range can be entered in selection criteria. As the user becomes more specific for mentioning the criteria, the list will be smaller and more specific. SYNTAX SELECT-OPTIONS <fields> for <table field> Field is the variable, which you declare for accepting input from the user. Table field is reference field.


SELECT-OPTION: Fld1 like sflight-fldate, Carrid1 for sflight carrid. Maximum length of the select-option variable is eight characters. When system executes this statement, the selection screen is displayed and is like this

When you enter the desired information and click on execute button, rest of the program is executed, that is retrieval of data from database, which matches this information, and then the list is displayed. Behavior of SELECT-OPTION When the select-option statement is executed the system creates the internal table with the same variable name (in this case it will be carrid1). This table is also called as selection table. The main purpose of selection table is to store selection criteria. The table has four standard fields, which are as follows: SIGN is a variable, which denotes the system whether the result should be included with that particular criterion. It can contain either I or E. I denote Inclusion. The criterion is included. E denotes Exclusion. The criteria are excluded from the results.


LOW the data type of LOW is the same as the field type of the database table, for which you are using selection criteria. This acts as lower limit of the selection.

HIGH the data type of HIGH is the same field type of the database table, for which you are using the selection criteria. This acts as higher limit. If you dont enter HIGH value then the LOW value defines a single value selection.

OPTION is two-character field, which contains operations like EQ, GT, LT, GE and LE. When the user enters both the values i.e. high and low then this field act as BT (between). If you dont enter high value then all other operations can be applicable.

For each select-option statement system creates internal table. Default values for select-options If you want to display default values for the selection criteria before your screen is displayed then giving default values for the selection table field i.e. low or high can do it. SELECT-OPTION: CARRIDI FOR SFLIGHT-CARRID DEFAULT CARRIDI-LOW = LH AND CARRIDI-HIGH = SQ In this case when selection screen is displayed with default values LH for lower range and SQ for higher range. User can use same values or overwrite these values with new values, which he needs. Standard Report The normal format of any report is as follows: HEADING FOR THE LIST i.e. header area


Detailed Data.

At the end of pages you can have sub total or page number i.e. footer area.

Usually any report has some page headings at the top of page and then if data is displayed then column headings, which are followed by data and at the end of page, may be some grand total or page number. And such report can be displayed by using report program. Such report is called as CLASSICAL REPORT. Usually a standard report produced by system is one continuous page of 65k lines. The standard report can be declared as follows;


REPORT ZDEMO By default the report produced by system is standard report. But when you need to have your report divided into pages say 20 lines and you want to reserve some area for footer then you need to use following format of report statement. REPORT ZDEMO line-count 20(3) Line-size 75. In this case the line count for one page is 20 lines and in that 3 lines are reserved for footer. You can display your data only in 17 lines. The width of page will be 75 characters. As all of us know ABAP/4 is event driven languages. The ABAP/4 processor controls the executive of events. For example in above report when end of page is reached, you want to write to say page number reaching end of page is an event or whenever there is top of page you want to write list headers, then in this event you can write the code for displaying the list header. Report program is nothing but a set of events as your top of page is reached on your screen or on your printer and is no way connected to your program. Internal events are those events, which are controlled inside the program i.e. either by if endif statement or any other decision making statement. A simple report program without any events is as follows: Report zdemol, Tables: sflight. Select-option carrid1 for sflight-carrid, * for accepting input from user. Write:/ this is my first report program Write:/ 10carried id , 20 connection id 30 flight date * These two write statements are for writing heading and column headings. Select * from sflight where carrid in carrid 1 Write: /10 sflight-carried, 20 sflight-connid, 30 sflight- fldate Endselect. Write:/ page number : , sy-pageno. In this case we are writing list headings for reports. But these list headings are applicable only for the first page. If your list is spilling over multiple pages, then these list headings are not applicable to other pages. Again in this program we are writing page number after all the data is displayed. This is fine as long as you have one page, but the moment your list spills over multiple pages, this page number will be displaced only after all the records are displayed. So to have some data like company name or list headings or page number or total of some number field on each page, you need to make use of events. CLASSICAL REPORTS Events In Classical Reports Events associated with classical reports are as follows and each will be discussed in detail INITIALIZATION AT SELECTION-SCREEN


AT SELECTION-SCREEN ON <FIELD> START-OF-SELECTION TOP-OF-PAGE END-OF-PAGE END-OF-SELECTION In this case 1st three events are associated with selection screen. Rest all events are associated with your list INITIALIZATION We have already see how to fill default values for the selection criteria. But in many cases you need to calculated the value and then put it in selection criteria for example say you are accepting date from user and you need to fill in the default value for lower range as sy-datum 30 days and sy-datum for higher range. In this case you are calculating lower range and then filling in the criteria. And this can be done in INITIALIZATION event. Piece of code to do the above task would look like this. Select-option: fldate for sflight-fldate Initialization Data: date1 like sy-datum Date1 = sy-datum 30 Fldate1 low = date1 Fldate high = sy-datum. Append fldate. * here appending is required because fldate1 is internal table and you are filling in the field from table with some data This event is trigged when you execute your program for the first time i.e. before selection screen displayed. AT SELECTION-SCREEN When user enters the values in the fields of the selection screen and clicks on execution button, this event gets triggered. This event is basically for checking the values entered by the user for the fields of the selection screen i.e. data validity checking. This event is for entire selection screen. For example if You are accepting carrid, connid, fldate from user and you dont want to proceed if user enters no value for carrid and fldate. Using at selection-screen can do this. Selection-option: carrid1 for sflight-carrid, Connid1 for sflight-connid, Fldate for sflight fdate. AT SELECTION-SCREEN If carrid1-low ne and fldate1-low = Error message. Endif. In this case, if both the fields are entered blank then the user gets error message. Basically, this event is for many fields on selection screen. Usually, for fields which are logically related.


AT SELECTION-SCREEN ON <field> When you want to check for specific value of a field for example carrid should be in the range of LH and SQ. Then this can be done in this event. Basically, this event is for checking individual fields. You can have as many AT selection-screen events in your program. (i.e. for each field specified in the select-option). Select-option carrid1 for sflight-carrid. AT SELECTION-SCREEN If carrid1-low ne LH and carrid1-high ne SQ Error message Endif. Here system will not proceed if values entered are wrong. START-OF-SELECTION This is the first event for your list. Once all the events are triggered for selection screen, the data is retrieved from the database. Whatever you want to do, when your report starts, is done in this event like data declaration, select statements. Take following example: Start-of-selection Data: m type Tables: sflight Select *from sflight when carrid = LH Write:/ sflight-carrid.sflight connid Endselect. TOP-OF-PAGE This event is triggered with first WRITE statement or whenever new page is triggered. Advantage of using this event is that, whatever you write under this event is applicable to all the pages. If you dont have any write statement before TOP-OF-PAGE or in START-OF-SELECTION then this event is not triggered at all. For example if you want to say name of company and column headers for all the pages then this can be written in this event. TOP-OF-PAGE Write:/ Reliance Global Services Write:/ 10 carrid, 20 connid, 30 fldate END-OF-PAGE This event is triggered when end of page is reached. End-of-page. Write:/ page number, sy-pagno. In this case page number will be written on every page.


Conditional Triggering Of EOP Consider the following case REPORT ZDEMO1 line-count 15(3) Top-of-page Write:/ this line is written by top-of-page event Start-of-selection Write:/ this line is written by start-of-selection event End-of-page Write:/ this line is written by end-of-page event In this case end of pages will never be triggered, as end of page is never reached. The total line count defined for page is 15 and in that 3 lines are stored for footer area. The out put of the above code Will be This line is written by top of page event. The line is written by start of selection event. As in output screen only two lines are written and cursor is still on 3rd line, the end of pages event is not triggered. To trigger end of page event, cursor should reach at the last position, in this case on 11th line. Such cases are quite common, and could be over come by conditional triggering of end of page. Sy-linct is the system variable, which gives total line count of a list. Sy-linno is the system variable, which gives the current line number where the cursor is placed on the list. Take following case: Report zdemo 1 line count 20 (1) Start-of-selection. Data: m type i. Write :/ this is first line Do 5 times Write :/ the number is, sy-index. Enddo M = sy-linct - sy-linno 1 Skip x. End-of-page. Write :/ page end The out put of the above page is as follows This is first line. The number is 1 The number is 2 The number is 3 The number is 4 The number is 5 After skipping 10 lines Page end


In this case with all write statement, you dont reach to the end of page. After all write statement, m is calculated in this case: M = 20 8, 1. So m is 12. And 11lines are skipped after write statement and end of page is reached. ( In this case you have 6 write statements so6 lines + 1 line for page number and 1horizontal line which is displayed for any list. So cursor is on 8 th line and is subtracted from total line count i.e. 20) Common errors that user commits. Starting of another event denotes the end of any event. If you forget to mention the next event then everything is included in the same event. Consider the following case AT SELECTION SCREEN If carried1-low ne Error message Endif Write :/ Reliance Global Services P. Limited WRITE :/ 10 CARRID, 20 CONNID. 30 FLDATE START-OF-SELECTION In this case all the write statement are included in the at selection screen as top-of-page is not specified. The end of at selection-screen is denoted by starting of start-of-selection. Though the sequence of events in program is immaterial, it is good programming practice to write all the events in the order specified above. Using Variant With Selection Criteria In many cases you need report at regular intervals for certain fixed values of selection criteria. That means each time you execute the report you need to enter it values again & again. ABAP/4 provided facility by which you define the values for selection screen and store it. Using VARIANTS can do this. It can be defined as a group of values used for selection criteria when executing report. For a particular report you create a variant which means variant created for particular report cannot be used for another report. The group of values for the selection criteria is saved and assigned a variant name. So every time you call a report you need not specify the values for selection criteria but instead call the variant thus avoiding extra typing. User can have as many variant for a single report. Each of them can be used different type of information. For eg. : If manager want to see how employee of personnel department or admin. Department have performed. Then for him no need to enter department, just execute the report with variant. And if he doesnt know which variant are available, then he can display list of variants attached to the report and values assigned to each variant. Creating Variant

Execute the report program, the selection screen is displayed. Enter the values for selection screen and click on saves. o System displays the variant screen.


Enter the variant and description for it. Save it.

Usually the variant are useful when you need to execute the report in background, which will be discussed in the background processing. INTERACTIVE REPORTS About interactive reports A classical report consists of one program that creates a single list. This means that when the list is displayed, it has to contain all data requested, regardless of the number of details the user wants to see. This procedure may result in extensive and cluttered lists from which the user has to pick the relevant data. The desired selections must be made before hand and the report must provide detailed information. This is not possible using the classical report and for this ABAP has provided reporting features called INTERACTIVE REPORTS. The list produced by classical report doesnt allow user to interact with the system but the list produced by the interactive reports allows the user to interact with the system i.e. the user can tell the system, that he needs further information and depending upon what user tells the system, the action is taken. Interactive reporting thus reduces information retrieval to the data actually required.


Interactive reporting allows the user to participate in retrieving and presenting data at each level during the session. Instead of presenting one extensive and detailed list with cluttered information by positioning the cursor and entering commands. Detailed information is presented in the second list. A secondary list may either overlay the basic list completely or appear in an additional dialog window on the same screen. The second list can itself be interactive again. The basic list is not deleted when second list is created. User can interact with the system by: Double click or pressing F2 Selecting menu options Like classical report, the interactive report is also event driven. Both the action mentioned above triggers events and code is written to handle these events. The events triggered by this action are as follows:

At line selection At user command

Interactive report consists of one BASIC list and 20 secondary lists. Basic list is produced by START-OF-SELECTION event. When the user double clicks on the basic list or chooses the menu option, the secondary list is produced. All the events associated with classic reports except end-of-page are applicable only to basic list. AT LINE-SELECTION EVENT Double clicking is the way most users navigate through program. Double clicking on basic list or any secondary list triggers the even AT LINE-SELECTION. SY-LSIND denotes the index of the list currently created. For BASIC list it is always 0. Following piece of code shows how to handle the event. Start-of-selection Write:/ this is basic list At line selection Write:/ this is first secondary list In this case the output will be displayed on the basic list i.e. This is basic list When user double clicks on this line the event the line selection gets triggered and secondary list is produced i.e. This is first secondary list You can go back to the basic list by clicking on F3 or back icon on the standard tool bar. For this list the value of sy-lsind will be 1. HIDE Technique In this case things are much simpler. Consider the following case where in the basic list you are displaying fields from table sflight. When user double clicks on any sflight-carrid, you are displaying the detailed information related to the particular carrid on secondary list. Hence need to store the clicked carrid in some variable. So that you can access this carrid for next list. ABAP/4 has facility; a statement called HIDE, which provides the above functionality. HIDE command temporarily stores the content of click field in the system area.


Syntax: HIDE <FIELDS> This statement stores the contents of variable <f> in relation to the current output line (system field SY-LINNO) internally in the so-called HIDE area. The variable <f> must not necessarily appear on the current line. You have to place the HIDE statement always directly after the output statement i.e. WRITE for the variable <f>. As when you hide the variable, control is passed to next record. While writing, WRITE statement takes that record from header and writes it on to the list, but when writing onto your interactive list you will miss out 1st record. To hide several variables, use chain HIDE statement. As soon as the user selects a line for which you stored HIDE field, the system fills the variables in he program with the value stored. A line can be selected

By an interactive event.

For each interactive event, the HIDE field of the line on which the cursor is positioned during the events is filled with the stored values. The HIDE area in a table, in which the system stores the names and values of all HIDE field for each list and line number. As soon as they are needed, the system reads the values from the table. (Please try to find the name of this table). Sy-lsind indicates the index of the list and can be used to handle all the secondary lists. When you the user double click on the line or presses F2, sy-lsind is increased by one and this new sylsind can be handled. For example, Write:/ this is basic list Will create a basic list AT LINE SELECTION. If sy-lsind = 2, Write:/ This is first secondary list Elseif sy-lsind = 2. Write:/ this is second secondary list Endif When this code is executed. Basic list is produced When user clicks on the basic list, sy-lsind becomes one. AT LINE-SELECTION event is triggered. Whatever is written under IF sy-lsind = 1, gets executed Secondary list is produced Again if user clicks on this list, sy-lsind becomes two. AT LINE-SELECTION gets triggered. Code written under IF sy-lsind = 2, gets executed. A sample program for at LINE-SELECTION.


User Interface An interactive report starts with basic list where condensed information is stored on basic list and detailed information on secondary list. To implement this kind of reporting, you need to provide the user with things like menu, icons, function keys and you need to write code, must react, to the users action. For this you need to create the interface, which interacts with the user. The user interface is independent of the program or list or screen. How ever both interfaces and list can be associated by means of GUI status. A GUI status groups together the interface components.

Menu bar Application tool bar. Function keys Title bar.

The last element of the user interface is independent of the GUI status i.e. title bar. To assign status to your list the statement SET PF-STATUS Some facts about GUI status are:

A program can have multiple GUI status and tiles for different lists. Multiple lists can be assigned to same GUI status Normally both GUI status and title go together.

Function Code An important concept when working with user interface. Function is a four character alphanumeric code, which the system stores in the system variable called SY-UCOMM for each function key, push button, or menu option. Whenever any pushbutton is clicked or menu options is selected the code attached to that is stored in SY-UCOMM and can be handled in your program. Menu Painter Menu Painter is the ABAP/4 workbench tool for creating and maintaining user interface. Starting Menu Painter ABAP/4 development workbench menu painter Or Transaction SE41 in the command field Or Through program SET PFSTATUS <var> If you click on the variable the system takes you to the menu painter screen.


Creating Menu Bar Steps involved are as follows: Enter the name in the 1st field. It is just a name given to the menu and nowhere in output it is displaced. Enter the name of each menu item. You can create up to six menus (total eight menu items are available. Out of which system and help are mandatory) Enter name of the menu item and function code. You can have fifteen menu items under one menu. If you leave function blank then the system assumes that this particular menu item will have sub menu. And you can create the sub menu items under this menu item. User can go up to three levels.


Creating Application Tool Bar

I application tool bar you can include icon assigned for functional keys. To do this

Select function key From the menu, more utilities change text type. The system displays a dialog box, on icon and press ENTER. Select icon from list of icons displayed.

Creating GUI Title. From your program you can set title for your list and SET TITLE BAR is used. Syntax: SET TITLEBAR <var> Here var can be any three-character name. When developer double click on the var system displays the dialog box in which you enter the title number, the description and the actual text for title. Similar to directory objects, the GUI status must be generated to be able to accessible by program.


AT USER-COMMAND When the user selects the menu item or presses any functional key the even that is triggered is AT USER-COMMAND, and can be handled in the program by writing code for the same. The system variable SY-UCOMM stores the functional code for the clicked menu item or for the function key and it can be checked in the program. Sample code would look like AT USER-COMMAND Case sy-ucomm When DISP Select * from sflight Write sflight-carrid, sflight-connid. Endselect. When EXIT LEAVE In GUI status, say you have set menu bar for two items and the function code is DISP and EXIT respectively. If the user clicks the menu item DISPLAY, then function code DISP is stored in the sy-ucomm and whatever is written under the when DISP gets executed. Same thing is applicable for EXIT Sy-lsind for the screen increases when the user clicks the menu item. Usually you have combination of all the three navigations in your user interface i.e., you have to create menu bar, assign function code fro the function keys and write code to handle all this and plus handle double clicking. Things to remember when using all the combinations : Sy-lsind increases even if you select menu-item. When the user double clicks on particular line, value of sy-ucomm is PICK You set sy-lsind = 2 for your 4th secondary list then when control is transferred to the IInd secondary list then all the other lists after IInd are lost or memory allocated to then is lost. Sy-lisel also gives you the value of clicked line but in this case you can not differentiate between field. To retrieve the exact field, you have to know the field length of each field. If you use statement SY-LSIND = 1. The system reacts to a manipulation of SY-LSIND only at the end of an event, directly before displaying the secondary list. So, if within the processing block you use statements whose INDEX options access the list with the index SY-LSIND, make sure that you manipulate the SY-LSIND field only after processing these statements. The best way is to have it always at the as the last statement of the processing block. Important system fields for reports Sy-linent Sy-linno Sy-listi Sy-listi Sy-lilli Sy-lisel Sy-ucomm Gives total line number for a page. Gives current line number on the list Index of the lists created in interactive report. Index of the list from where event was triggered usually previous list. Line number of a list from where event was triggered. Contents of a line from where event was triggered. Holds the function code of clicked menu item or function key.



status of the displayed list.

INTERNAL TABLES 1. 2. and Tax code from table BSEG and display the same with column headings. 3. Create an internal table with following fields. Sales Document and Material from table VBAP. Date, Name of the user and sales document type from table, VBAK and Price group and customer group from table VBKD. Sort the table according to Material number and display the contents. 4. Create an internal table called T_BSIS having a similar structure as table BSIS. Explore all possible methods to create the internal table with header line/ without header line. (Use data types, data begin of .end of, datalike, datainclude structureetc.,) Also create a field string F_BSIS. Populate the internal table with the content of BSIS. Sort the table according to company code and display contents. 5. Determine for each material type (MTART) the 5 tables entries with the highest gross weight (as ranked list). To do this read the table MARA and store the material type (MTART), material number (MATNR), unit if measure (MEINS) and grow weight (BRGEW) into an internal table. Allow the user to specify the Material type as a parameter on the selection screen. 6. Create a list of maximum number of available seats for each carrier. To do this read the table SFLIGHT and store the airline carrier id (CARRID) and the maximum number of seats (SEATSMAX) in an internal table. Determine the total number of seats for each airline carrier when filling the internal table. 7. Read the table SFLIGHT into an internal table and then output the internal table with the fields CARRID, FLDATE and PRICE. Delete all the internal table entries where the airline carrier (CARRID) is not equal to LH Read the internal table with entry with the key CARRID = LH and CONNID = 0400, multiply the price by 3 and write the modified entry back to the internal table. Then Output the internal table. 8. Read table TABNA into internal table and output the fields. Country, id, name1, and sales. Sort the table with Country. Delete all internal table lines with sales lower than 50,000. Read internal table with key GB and 00000003 and multiply the sales by 3 and change table entry. Insert any one record of your choice. Find out how many lines are there in the internal table. Remove all the contents of the table. Reallocate the memory associated with table. 9. Use Tables LFA1, LFB1 and LFM1. Define an internal table with the following Lifnr like lfa1-lifnr, Bukrs like lfb1-bukrs, Ekorg like Lfm1- ekorg. Add data from these tables into the internal tables. Sort the internal table Lifnr. Create an internal table taking all the fields from BKPF and display fields company code, Document number, Document type and date of document. Create an internal table taking fields Company code, Document number, Account type


Read the internal table with Lifnr= A5 and change name to trainee. Put back the record into the table. Delete first three records of internal table. Clear header for internal table each time you access a record. 10. Create a report which will give the existing stock for a material. The report should have a subtotal of the stock for each storage location and Grand Total of the stock at the end of the plant. Plant Data should start a new page. Input: Selection screen which will allow to select a range of materials. Materials: Output Plant Report Format as Follows: Storage Material Location Number Description Stock (unrestricted)

Tables and fields: Material Number MARA-MATNR Description MAKT-MAKTX Plant MARC-WERKS Storage location MARD-LGORT Use Standard Formatting colors. Exception handling: Error message Material not found if material not present. 11. Generate a report to list the following details from the tables LFA1 & LFB1 vendor no., vendor name, city, state, telephone no., fax no., company code and terms of payment. User shall have options to select the vendor number range for which the report is generated. Report title: Vendor Master Listing 2. Vendor name: Address: Telephone no: Company code Vendor no.: Fax no: Terms of payments

All text used in the report shall be generated using text elements only. The output list shall have a footer showing page no., date and Intelligroup(left corner) 12.Generate a report for displaying material description, plant & storage data.Input: material number (MARA-MATNR) Data to be displayed for the following three materials only. 1. BP770M15 2. FP56790031 3. FP28652011


Output format: 11/11/1998

Report to analyze material stocks

Material No. FP96412101 Plant Xxxx

Description Medintech Patterned Weld Rod Oatmeal 60 Storage Loc. xxxxxxxxxx Unrestricted stock xxxxxxxxxxxx

All texts are to be generate using Text Elements only. Use tables : MARA, MAKT, MARC and MARD. SUBROUTINES 1. Read a number between 0 and 100 and another digit between 0 and 9. Write a subroutine that will calculate the sum of all numbers (below the limit) that end with the digit. The parameters to be passed are limit and digit both by value and sum by reference. Ex. If limit = 67 and digit = 4 then the sum should be the sum of 4,14,24,34,-------64. 2. Write a subroutine CENTRE-STRING which will output a string on the center of a line. The subroutine will accept parameters STRING pass by value. 3. Write a program extensively using subroutines to print the equivalent number in words.

For example : if the number is 66, the output should be SIXTY SIX. Limit the number range from 0-99. Accept the input number as a parameter. 4. Accept a date from the user. Write a date as dd-mmm-yyyy where mmm is month written as JAN/FEB/MAR--------etc.. Make use of subroutines. 5. For each flight connection calculate the sales for all flights of an airline carrier. Use internal table for calculating the sales. Use a subroutine for the output by passing the internal table as the parameter.


DIALOG PROGRAMMING (TRANSACTIONS) General Introduction To Transaction About Transaction TRANSACTION, in R/3 system is an operation that lets the user to make necessary changes to the database. The entire R/3 system to SAP R/3 database, or modifying data, or deleting data, which is not required, is done through transaction. For SAP system. TRANSACTION is nothing but sequence of steps called a dialog steps and for user it is sequence of screens, which appears one after the other depending upon the option he is selecting. The special transaction monitor called the SAP dispatcher handles the sequence of steps that takes place in any transaction. The main task of transaction is to update database table. The database table is not updated until a transaction is completed. All changes can be rolled back if the transaction has not finished. The transaction contains two steps which are as following. Interactive phase: In this step, user enters the data, which needs to be inserted or deleted or modified on to the screen. There can be single screen or multiple screens depending upon the transaction. So this step can consist of single step or multiple steps. In this phase you prepare database record. Update phase: This phase processes the database record and updates the database table. Actually updating of database table takes place in this phase. All the transactions are associated with transaction code. And all these codes are stored in a table called TSTC. Logical Unit Of Work The R/3 system is multi user system and many users access same information at the same time, which is mainly DATA. Consider the case where one user is modifying a record. And second user is trying to delete the same record. If the second user is successful in deleting the record than the first user will face problem for modifying the record that is already deleted. To avoid such situation, R/3 system has provided. Logical unit of work is defined as a looking mechanism to protect transaction integrity. Of course, there are other measures, which ensures data integrity like check table i.e., foreign key relationship. Within SAP system there are three types of transaction and may be distinguished as : Database transaction known as LUW. It can be defined as period in which operation requested must be performed as a unit, i.e., all or nothing operation. At the end of LUW, either the database changes are committed or rolled back. Update transaction or SAP LUW. One SAP LUW can have several databases LUW. So a set of database is either committed or rolled back. The special ABAP/4 command COMMIT WORK., marks the end of a SAP LUW. ABAP/4 transaction. Is made up of set of related task combined under one transaction code. ABAP/4 transactions are for programming environment, in which ABAP/4 transaction functions like one complete object containing screens, menus and transaction codes. R/3 system has provided in built locking mechanism, which defines the Logical Unit of work. Also user can set his own locking mechanism. The LUW starts when a lock entry in the system table is created, and it ends when the lock is released.


To provide the user the facility to communicate with the table in order to modify or delete or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design screen, process screen through program and update the database table. SAP has provided one and only one way to update the database table i.e., transaction. Though you can update database table by using open SQL statement through program, SAP usually doesnt recommend this kind of updating. Many standard transactions are available to update standard table but if the need arises, the developer of database tables. This can be achieved by using various components of screen painter. Following are the few concepts and steps for creating entire new transaction. DYNPRO concept A dynpro refers to the screen + flow logic. With screen painter you can develop screen and flow logic. The relationship between screen, flow logic and program can be shown as follows.

Flow logic SCREEN 100

Module Pool Program

Flow logic SCREEN 100 Flow logic SCREEN 300

Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to module pool program. A transaction consists of many screens and for each screen flow logic is attached. When the transaction is executed, the screen places a call to flow logic and flow logic in turn places a call to module pool program. A module program is nothing but usual ABAP/4 program which consist nothing but set of modules and data declaration. ABAP/4 is event driven language and for screen, also event gets triggered and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor. The system automatically displays the two important events for the flow logic. Screen is the important component of dynpro and can be created, designed by screen painter.


Screen Painter Starting Screen Painter A Screen painter can be started by Development workbench Or SE51 transaction code. Using Screen Painter The process of creating a dynpro includes the creation and definition of all the needed screen components. The steps involved in creating the dynpro are as follows: Create screen and attributes by using screen attribute screen. Select and place the needed fields within the screen by using dict/program fields. Establish the field attributes to which the screen belongs by using field list. Define the flow logic with respect to the transaction to which it belongs by using flow logic. Screen painter

Creating a New Screen Steps involved are as follows: Enter the name of program and number of the screen Click on create. On screen attribute screen enter short description. Enter screen type. Normally you select NORMAL option for usual R/3 screen. Other options available are SUBSCREEN and MODAL DIALOG BOX. Modal dialog box is used to establish independent and interactive dialog box while subscreen is screen within screen. Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.

Designing of Screen Screen can be designed by using FULL SCREEN EDITOR. You can go full screen editor From screen attribute screen By pressing full screen editor push button. Or From initial screen of screen painter. There are two modes available with full screen editor. Graphical mode. The mode works similarly to typical window application. Alphanumeric mode (rarely used )


Elements of screen Text Standard text or field labels. Entry display field. Radiobutton All radio buttons must be associated with one group. Checkbox Normally used for YES/NO operations. Pushbutton Used for activating particular function. Boxes grouping together many screen elements. Subscreens This is a screen area in which you can display another screen. Table controls This area of screen is similar to table but should be treated as loop. Status Display output fields containing icon.

All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed. Selecting Screen Fields Screen field can be either dictionary objects or program fields. Steps involved in the placing of the fields on the screen are as follows: Click on pushbutton Dict/program fields on the full screen editor Or Goto dict prog fields. Enter table name. Click Get from dictionary. Select fields. Click copy pushbutton. Position the cursor where you want those fields to be placed.

To adjust various screen elements, you can use drag and drop facility for screen elements. Attributes of Screen Elements The entire element of a screen has some attributes, which determines their behavior. General These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen. Dictionary Dictionary attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like matchcode object, foreign key. Program Display behavior of the element with respect to their display feature. Attribute dialog box can be displayed by Clicking on the ATTRIBUTE push button on the application tool bar. Double clicking on the element.


Field List This list displays a list of all screen elements together with their screen attributes. One important element of field list is OKCODE. Any push button is associated with function code as in menu item in menu painter. When the user clicks the push button this code is stored in OKCODE. This okcode is created by system with out a name and is not visible on the screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the variable and is the last field of the field list and is invisible. Hence user needs to give the name OKCODE. It is mandatory to give the name OKCODE: developer can give any name to this field. Screen Flow Logic You can go to this screen either by Initial screen of screen painter Flow logic Or From Screen attribute screen flow logic When transaction is executed, the screen is displayed; user enters few fields, select few functions. Then the screen is processed and processing of screen is done by flow logic. The events that are associated with screen are as follows: Process before Output Process after input Process on value request Process on help request (PBO) (PAI) (POV) (POH)

The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO. PBO event This event is triggered before the screen is displayed. The processing of screen is displayed. The processing of screen before the screen is displayed is done in this event. For example filling in default values in the screen fields. PAI event This event is responsible for processing of screen after the user enters the data and clicks the push button. The processing of screen can include displaying another screen or just displaying list or quitting the transaction itself and many more things. Usually it is displaying another screen. These operations can be carried out in the PAI event. OKCODE plays an important role in this operation. POV event Process on value request is triggered when the user clicks F4 key by writing code for the same in module pool program. Normally when the user press F4 list of possible values is displayed. The


standard list produced by system is adequate for applications you develop yourself. However you also can have the option of setting up your own documentation and lists of possible values that are more detailed. POH event Normally when the user places the cursor on the field and presses F1function key the system displays its own help for that particular field. You can add your own functionality to the help button by writing code for the same in the POH event. Module Pool Program About Module Pool Program This component though is not attached to the screen painter plays important role in transaction. Normally for reports on line executable programs are written but for transaction. Module pool programs are written. The module pool program contains only modules to handle various events associated with screen and data declaration statements. System divides the module pool program into several include program. These are global field, PBO modules and PAI modules. It is entirely users decision whether to use these modules or write directly into main program. Creation of Module pool program You can create module pool program either through Object browser System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules. Or ABAP/4 editor In this case it is similar to normal program creation. Type of program should be given M and is not created by system. Communication between Dynpro and Module Program For each screen the system executes the flow logic, which contains corresponding events and then the control is passed to Module Pool Program. Module Pool Program handles the code for this events and again passes back control to the flow logic and finally to screen. Unlike on line program, in this case the control remains with flow logic. The switching of control between flow logic and module pool program and back is common process when user executes transaction Creation of complete Transaction Steps Involved to create a complete transaction Create module pool program From screen painter create screens Write flow logic for each screen Write code for all the events in module pool program


Check for any error in screen and flow logic Generate each and every components of screen i.e., flow logic and screen Single screen can be tested using screen painter Create transaction code through object browser Generate the transaction code User can execute the transaction by entering the transaction code in the command field

Handling of Functions Code The function code of OKCODE is the last field list. Function code can be handled as follows: During the designing of the screen, a function code is assigned to pushbutton. In field list, developer needs to specify OKCODE as last field. In module program it is a global field and can be evaluated in the PAI event. A function code is treated in the same way; regardless it comes from pushbutton, menu item or any other GUI element. A complete example for transaction is shown below: If you have screen like following:

When the user clicks on the Display button, then you want to display details of sflight, with corresponding carrid and connid (which is entered by the user).



When user clicks on display, control is transferred to screen number 200 on which you are displaying sflight details and on the same screen, when user clicks on BACK button, he comes back to main screen. Flow logic for screen 100 is as follows: PROCES AFTER INPUT. MODULE INPUT. Flow logic for screen 200. PROCESS AFTER INPUT. USER_COMMAND_0200. MODULE Modules are handled in module pool program. You need to write flow logic for screen 200 and design screen 200.


In case of transaction transfer of data from program to screen is automatic i.e. you need not to transfer data from program to screen explicitly. The fields, which you define in the screen receive the data from program and displays the same.


The Field Checks About Field Checks As already mentioned Transaction is the only method, which SAP recommends to update the database tables. Data entered is validated at each and every point. ABAP/4 offers various methods to validate data and those are as follows: Automatic field checks Checks performed in the flow logic Checks performed in the ABAP/4 module pool program.

Automatic Field Checks These checks are based on the field information stored in the dictionary. These checks are performed by the system automatically when the user enters the data for the screen field. System performs these checks before PAI event is triggered. Types of field checks performed by system are as follows: Required input While designing the screen, for particular screen field if you click the Req.Entry checkbox. Then the field becomes mandatory. When the transaction is executed if user leaves this particular field blank then system displays error message. User cannot proceed until the user enters some data. Proper Data format Each field has its own data format whether it is table field or screen field. Whenever data is entered, system checks for the proper format of the data. For example date. Each user has its own format for date which is defined in the user master record. If the date defined in the user master record is in the format DD/MM/YYYY, if the user enters the date say YY/DD/MM then the error message is displayed by the user. System also checks for the value of month or days. For example if month entered is greater than twelve then the error message is displayed. Valid Value For the Field In data dictionary two tables are related by Primary key-Foreign key relation ship. Whenever the data is entered by the user the system checks for the check table values. Also in Domain if you have fixed values then the system checks for these values. Automatic field checks are repeated each time the user enter the data. About AT EXIT-COMMAND Automatic field checks can be avoided by EXIT-COMMAND, which works exactly the same way as CANCEL works on application tools bar. In the R/3 screen, if you want to quit the processing of that particular screen without entering the mandatory fields then user can click the CANCEL button, same functionality can be incorporated in the user defined transaction by using AT EXITCOMMAND. This module can be called before the system executes the automatic field checks and it goes without saying that before PAI event also. Code for EXIT-COMMAND in flow logic and in module pool program can be written as follows:


In flow logic.

Process After Input.

Module exit AT EXIT-COMMAND. In module pool program. Module exit. Case okcode. When EXIT. Leave to screen 0.

TO achieve this kind of functionality a pushbutton or menu item should be assigned a function type E. It tells the system to process this particular module before carrying out any field checks. Flow Logic Validations Consider the case where you want user to enter only LH and SQ for sflight-carrid. In this case you are restricting value of a screen field. This cannot be achieved by automatic field check. Hence need of additional validation and can be done in flow logic by using following statement: Field ----------- Values SYNTAX PAI Field sflight-carrid values(LH). For multiple values PAI. Field sflight-carrid values (LH SQ). Field sflight-price values (between 1000 and 2000). In this case when the user enters the value, PAI is triggered and field is checked for that particular value. If entered value is wrong then that field is enabled for user to enter. If you have multiple Field statements in your flow logic then it is sequential execution. Consider the following case. PAI. Module assign. Field sflight-carrid values (LH SQ). In ABAP/4 Module assign. Data : carrid1 like sflight-carrid. Carrid1 = sflight-carrid. Endmodule.


In this case sflight-carrid is used in the flow logic before the field statement. The system will give invalid value or some previous value as the field sflight-carrid is used in module before it is checked i.e. field statement is after the module in which sflight-carrid is being used. The field is not available to the system unless it executes the field statement. The FIELD statement transfers the values to the program and is done only once. If you dont have FIELD statement in your flow logic then transfer of values takes place in PAI event. Consider one more case where you have multiple field statement. PAI Field sflight-carrid values (LH). Field sflight-connid values (0400 0500).

In this case if the user enters only carrid wrong, then this particular field is enabled and rest all the fields are disabled for user to input. Many times if the user enters wrong value for one field then you might want to give option to user to enter all the fields . Which is not possible by using only FIELD statement. This functionality can be achieved by CHAIN-ENDCHAIN. SYNTAX Chain. Field sflight-carrid values (LH). Field sflight-connid values (between 200 and 500). Endchain. Field sflight-price values (100 1000). In this case if the user enters wrong value only for carrid then both the fields i.e. carrid and connid are enabled as they are grouped together in the CHAIN statement. The field price will be disabled for input. Usually related fields are grouped together with Chain-Endchain statement. Checking fields in ABAP/4 program includes Field statement in flow logic Module statement in ABAP?4 module pool program.

SYNTAX PAI. Field sflight-carrid module <name>. This module can be handled in the main program i.e. module pool program. For example PAI. Field sflight-carrid module check. In ABAP/4 program Module check


Select single * from sflight where carrid = sflight-carrid. If sy-subrc ne 0. Message e001. Endif. In this case field sflight-carrid is checked in the table for its existence. Dynamically calling the screens About Displaying Next Screen The Transaction is nothing but a sequence of screens, which are displayed one after the other. The next screen displayed depends upon the attributes of first screen. In attributes you need to give Next Screen number i.e. if next screen displayed should be 200 screen, then this number should be given in Next Screen attributes. These are static attributes of the screen. By default if nothing is specified ion the program the system branches out to the screen number, which is specified in the attribute screen. But this is not always the case, if you have many pushbuttons on the screen like in the following case:


In this case if user select MARA pushbutton then fields from Mara table are displayed and when the user clicks on the MARD then the fields from Mard table are displayed. From same screen depending upon users selection the screen is branched out and this has to be done during runtime. This functionality can be achieved by dynamically calling the screen in module pool program. The screen can branch out to new screen depending up on user selection and can be done by following command in module pool program. SET SCREEN CALL SCREEN LEAVE TO SCREEN <number>

All these commands override the specifications given in the attributes. This overriding is temporary in the sense that values stored in the attribute are not changed. SET SCREEN SYNTAX Set screen <number>. In module pool program Case okcode. When DISP Set screen 200. When LIST Set screen 300. Endcase. In this case the entire processing of current screen takes place and then the system branches out to next screen. If you want to branch out to the next screen without processing the current screen then LEAVE SCREEN should be used along with the SET SCREEN. For example: Case okcode. When DISP. Set screen 200. Leave screen. When LIST Set screen 300. Leave screen. Endcase. When SET SCREEN is used control cannot be transferred to main screen or previous screen, unless you write code for the same.


CALL SCREEN Usually used for pop up screens. Many times, there is need for user to enter additional information or secondary information on another screen or pop up screen. Once the user enters the data, he should be able to go back to main screen or to the screen where he started. This is not possible by using SET SCREEN. This functionality is achieved by CALL SCREEN. SYNTAX CALL SCREEN 200 Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking on BACK button. To call screen as pop up screen the syntax is Call screen starting at <> <line no> Ending at < col no> <line no>. In this case window will be popped as window and user can close it by using BACK button. LEAVE TO SCREEN To SET a new screen without processing current screen you need to use the following two statements together. SET SCREEN 200. LEAVE SCREEN. Or a single statement LEAVE TO SCREEN 200. SUBSCREEN A subscreen is a screen. Consider the following case.


If user clicks on the FIRST pushbutton, then say you want to display details of MARA table and if user clicks on the SECOND pushbutton you want to display details of MARD table. You can do this by calling two different screens. But the information will be displayed on the next screen. Displaying of the data on the same screen can be done by using SUBSCREENS. Steps to create a subscreen are as follows: Create a subscreen area on MAIN screen and name it. Create a separate screen of subscreen type. Arrange the fields on this screen so that they fit in subscreen exactly. If it is larger then only that part of the screen will be visible that fits in the main area. Write code for calling subscreen in flow logic.

To call subscreen, from your flow logic you need to include the statement both in PAI and PBO. SYNTAX PBO. Call sucreen <area> including <prg name> <screen no>. PAI. Call subscreen <area> Area is the name of the area on main screen. Prg. Name is the name of the module pool program. Screen number is subscreen screen number. There are many DONTS with the subscreen and these are GUI status cannot be set to the subscreen OKCODE is not applicable to the subscreen. Subscreen cannot call another screen. It cannot contain AT EXIT Command.


You can call multiple subscreen in the same area (at any given point of time only one subscreen can be called in the subscreen area) and is done dynamically during runtime by using variable screen number. TABLE CONTROLS About Screen Tables A table can be created in transaction. These tables when designed on the screen are called as SCREEN TABLES. These screen tables are of two types viz. Table controls Step loops

Though these are tables when code is written to handle them the tables are treated as loops.

Features of Table Controls Data is displayed in the form of table when many records match the criteria. Table control gives user the feeling of an actual table. You can scroll through the table vertically. (The way you do it for actual table) You can select rows and columns RE-size the width of a column You can have separator lines between rows and columns. Automatic resizing of the table when the use resizes the window. In general table control includes all the features of the actual table and user gets the feeling that he is actually working with the table. You can update information in table control and it can be updated in the database by writing code for it. Steps associated for creating complete screen table is as follows: Declaration of table control in module pool program. Designing of table controls on the screen. Passing data to table in flow logic.

Declaring of Table Control in the Module Pool program SYNTAX: Controls TC1 type Tableview using screen <screen no.> When you use table control in a screen you must declare the structure in module pool program. Important fields of tableview are as follows: Lines number of displayable rows in a table. Top_line the row of table where the screen displays starts. Current_line The row currently being processed inside a loop.

When you process the table control in flow logic depending upon where you want to start display of rows you need to use to use these variables.


Designing Table Control on Screen To design table control on the screen, you need to click on TABLE in control bar and place it on the screen. You can adjust the length and width of table control. Name the table control. (Here you need to use same name which you have used for declaration of table control in module pool program) From dictionary method object, select table fields and place them in the table control.

Passing data to Table control As already mentioned table controls are tables but are treated like loops. Usually transfer of data from program to screen is automatic. But in case of table control, transfer of data is not automatic. You need to explicitly transfer data to table control. ABAP/4 provides LOOP statement, which is associated with flow logic to transfer the data. Because table control is treated alike a loop, data from where it is transferred should be a loop. You cannot transfer the data by only select statement; you need to put the data into internal table. ABAP/4 provides the LOOP statement, which is associated with the flow logic and allows you to loop through the table control and internal tables. In between LOOP ENDLOOP, you can use most of the flow logic keywords like field, values, module etc. You need to code a LOOP statement in both PBO and PAI event of the screen. With LOOP statement, you can transfer the data from program to table control, then you can update database table with this value. And this can be done in PAI event. So even if you are not updating database table through the table control, you need to put the LOOP statement in the PAI event also. SYNTAX PBO LOOP AT < internal table> with control <table control name> Cursor <scroll variable> PAI. LOOP at itab. Proper usage of Table Control is as follows: In flow logic.

LOOP AT ITAB WITH CONTROL TC1 CURSOR TC1-TOP_LINE. MODULE ASSIGN. ENDLOOP. PAI. LOOP AT ITAB. ENDLOOP. Considering we have following fields in table control and the screen looks like this, then


In Module Pool Program


Module assign. Sflight-carrid = itab-carrid. Sflight-carrid = itab-cannid. Sflight-fldate = itab fldate. Endmodule.

This transfer of data from program to table control takes place in steps and these steps are as follows:

With LOOP AT statement the first row is picked up and placed in the header of the internal table. Whatever statements you have in between LOOP ENDLOOP are executed: In this case you have module statement. In module statement value of internal table are assigned to table control field. The row in internal table transferred to the first line of the table control as stated in the LOOP AT statement. The system encounters the ENDLOOP statement and control is passed to the next line of the internal table. In the same way all the records of the internal table are passed to the table control.



Step loops are type of screen table as already mentioned. Step loops are nothing but repeated blocks of field in a screen. Each block contains one or more fields and these blocks are repeated. Step loops dont give you that feeling of actual table. You can scroll vertically but not horizontally. Again three steps are associated with creation of step loops:

Creation of step loops on screen, which includes declaring fields on the screen and then defining the step, loops for these fields. Passing data to the step loop is exactly similar to the passing of data to table controls. In step loop you dont need to define the step loop as such in the module pool program but the cursor needs to be defined in the program.

Types of step loops Step loop can be of two types:

Static: Static loop have fixed size that cannot be changed during the runtime, in the sense that if user resizes the window, the size of the static step loop is not changed Dynamic: Dynamic step loops are variable in size. When the user resizes the window, the system increases or decreases the number of the step loop blocks.

You can have only one dynamic step loop and can have as many static loops in your transaction. Programming with the static and dynamic step loop is exactly same. For the system or for the user it doesnt make any difference whether it is static or dynamic steep loop. Only attribute, which you fix during designing of the step loop, is type attribute for step loop F for Fixed i.e. static and V for variable i.e. dynamic. Writing code for step loop in the flow logic

PBO. Loop at itab cursor c1. Module Assign. Endloop. PAI. Loop at itab. Endloop.

(Empty loop is must for both table control and step loop) LOOP AT statement for step loops and table control is same in the sense that LOOP At statement transfers the data to screen table. You need to have the module to assign the values for the screen table. In module pool program you need to define the cursor. Data: c1 type i. Cursor parameter tells which line of step loop display should start.


Module assigns in module pool program assigns the values to step loop field, which is similar to table controls.

Branching To List Processing Switching to list mode You can display a list within a transaction. You can produce a list from module pool program by using the command. LEAVE TO LIST PROCESSING This statement switches the system from dialog mode to the list mode. And from this point onward until you return to dialog mode, you can use all the normal report statement like write, select or any other event. Returning back from LIST mode.

You can return back to dialog mode by clicking on the BACK button.


You can have your GUI status and write code for the same. In this you can include the command LEAVE LIST-PROCESSING. When the system reaches this command it leave the list mode and returns to dialog mode.

HELP and VALUE Request About HELP In any transaction, when the user presses F1 or ? on a field, system provides the help facility for that particular field. In dialog program, when the F1 is pressed. Help provided by R/3 system is sourced from data element documentation. If this documentation is not present for that particular field or if user needs to display additional information for that particular field , then user defined help can be provided through PROCESS ON HELP REQUEST. In ABAP/4 help can be provided to the user by: Data element documentation. The F1 help can be enhanced by adding an additional text for the data element in the ABAP/4 dictionary. And can be done by the following steps: Place cursor on the screen field GOTO DOCUMENTATION DATA ELEMENT DOCUMENT You can now extend the existing help. USING THE PROCESS OF HELP-REQUEST If you dont have this event in a program, then the documentation of the field in the ABAP/4 dictionary is taken into consideration. If this event exists in the program then it is executed.

PROCESS ON HELP-REQUEST EVENT. This event is triggered when user presses F1 on a screen field. You need to handle this event in flow-logic by specifying the fields and attaching the module to it. SYNTAX: PROCESS ON HELP-REQUEST FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID In module pool program MODULE HELP Write :/ this field is from sflight table Write :/ it is of four characters ENDMODULE. When the user presses F1 on this particular field then this message will be displayed on the screen. VALUE REQUEST Whenever the user presses F4 on the screen field list of possible values for that particular fields are displayed. If the standard value-help is inadequate or if you want to display additional fields or with different combination of fields, then developer can program this in PROCESS ON VALUEREQUEST event in the flow-logic and subsequent module in the module pool program. When the


user processes F4, list of possible values are displayed either from match code objects or help view or domain. Each of it is explained briefly

Match-code objects: As aggregated dictionary objects and detailed procedure to create these objects is explained in the later part of this material. Check Table: If a check table is assigned to the table field and if the user presses F4 for that particular field, then all the key fields are displayed. Domain Values: The values defined the domain are displayed. These values are displayed in domain when the domain is created in the dictionary. Help Views: In cases where the check table is not sufficient, you can create help view with this check table. Which gives additional information like explanatory text for the fields of the check table.

PROCESS ON VALUE-REQUEST. Each times the user presses F4 on the screen field following algorithm is called internally.


Does this field has its own F4 module in the Screen Painter Yes No

Execute module


Matchcode object in the screen



Execute Matchcode help

Check table?



Help view for the check table?

Domain Values?





Display view


Display Check

Display Domain Values

Message No display of possible entries here


When the user presses F4 on flight number, the following screen is displayed.

The screen displayed is pop-up screen and code for the flow logic and module is written below




Changing the screen during the runtime The attributes are assigned to the screen field when the screen is designed in full screen editor. Such kind of assignment is static in the sense that these attributes are fixed, but many times the need to change the attributes of the screen arises and has to be done during runtime. Need To Change Screen These can be requirement in the transaction that certain field on the screen

Appear only in certain conditions. Are in change/display mode according to user inputs Becomes mandatory subject to specific inputs. Changes its format depending upon certain conditions.

Modifying The Screen At the runtime, attributes for each screen field is stored in a system defined internal table, with header line, called as SCREEN TABLE. It contains name of field and its attributes. This table can be modified during the runtime i.e. through module pool program. Screen table has following fields: FIELD NAME NAME GROUP1 GROUP2 GROUP3 GROUP4 ACTIVE REQUIRED INPUT OUTPUT INTENSIFIED INVISIBLE LENGTH DISPLAY 3D VALUE_HELP LENGTH 30 3 3 3 3 1 1 1 1 1 1 1 1 1 DESCRIPTION Name of screen field Field belongs to field group1 Field belongs to field group2 Field belongs to field group3 Field belongs to field group4 Field is visible and ready for input. Field input is mandatory Field ready for input Field for display only. Field is highlighted. Field is suppressed Field output length is reduced. Field is displayed with 3-D frame Field is displayed with value help.

Eg:- SCREEN-ACTIVE = 0 has the effects a the following statementsSCREEN-INPUT = 0 SCREEN-OUTPUT = 0 SCREEN-INVISIBLE = 1.

The fields SCREEN-NAME and SCREEN-GROUP1 through SCREEN-GROUP4 tell you which field and/ or field group has the attributes. You can assign up to 4 groups to a field. You need to program screen modification in module, which is processed during the event PROCESS BEFORE OUTPUT.

SCREEN is an internal table and, in order to change the field values, LOOP statement has to be used so that the header line can be populated with the new values, changing the earlier values the SCREEN table had for that screen. Finally the changed record in the header line is NOT


MODULE MODIFY_SCREEN ------------------------------------------------------------------------------LOOP AT SCREEN. APPENDED,SCREN-NAME = SFLIGHT-CARRID. IF but is MODIFIED to the screen table. That is, we first use LOOP AT SCREEN then assign the values and finally PRIOR TO ENDLOOP give MODIFY SCREEN. SCREEN-INPUT = 1. ENDIF. MODIFY SCREEN. SCREEN ENDLOOP.

PROCESS BEFORE OUTPUT ------------------------------------------------------------------MODULE MODIFY_SCREEN OUTPUT. ----------------------------------------ABAP/4

MODULE MODIFY_SCREEN. --------------------------------------------------------------------------LOOP AT SCREEN. IF SCREEN-NAME = SFLIGHT-CARRID. SCREEN-INPUT = 1. END IF. MODIFY SCREEN. ENDLOOP.

WORKING WITH MATCHCODE OBJECTS A Matchcode is an aggregated object and for a user it gives list of possible values. A matchcode is a collection of search term on which you retrieve a data from the database table. All matchcode are associated with either selection criteria or parameters. When a input field has a little triangle in the right hand corner, it indicates that it has an associated match code. When you click on drop-down arrow or press F4 button, it gives list of all possible values. For example matnr field i.e. material number from MARA table. User might not know all the all the material number, but they might know other details like material description, type or any other details. You can crate matchcode, Which has all these search terms i.e. you can create matchcode with description as search term or matchcode with types as search term.


R/3 system includes many predefined matchcode but developers can creat new matchcode and is created in following case. Usually, system displays list of possible values for all the primary keys with particular search term. Usually you create matchcode in following cases: When you use non primary key of input You need different search term for the primary key. Creating Matchcode Object Entire matchcode object is crated in two steps: Defining of matchcode object Defining one or more search ids for the object Defining Matchcode object It includes all the tables and fields which make up the matchcode, which are used for matchcode Ids. Steps for defining matchcode object are as follows: From dictionary enter name(four character) Select Matchcode radiobutton and click on CREATE Define attributes for the object i.e. description. Select primary table Select the fields for the table by clicking on the fields. Activate the object

If at all you are selecting secondary table then it is done after the selecting primary table and steps are as follows: Tables choose secondary table A dialog box appear, which displays list of possible secondary tables. Select the table by Choose Copy To activate the object, Match code object Creating Matchcode Ids. Once the object is created, you need to define search term for the object and steps are as follows: Click on the Matchcode ID from maintenance screen. Enter attributes for the matchcode Id. Short text. Update type Default is 1 for logical updation. It means that at the moment when you access the matchcode object the table is created like view. Unlike logical updation, in physical updation each matchcode has its own table in the system. Types of physical updates are: A,S,P. System matchcode If you click this particular field then it indicates a system matchcode which is used by SAP software and cannot be changed by the end user. Autho.checks If it is checked then system performs authorization checks for this matchcode Id. activate


Selecting secondary tables Position the cursor on the base table of the ID. Edit Choose secondary tables A dialog box appears listing the tables linked to the table by foreign keys Select table Save

Selecting Fields for Matchcode Id Select fields Choose fields Once all the fields are selected, click on copy fields. Fields are transferred to the matchcode Id.

Activation of Id. A corresponding database view is created in the database during activation for the Ids of update type I. During activation, a check is made to see whether the corresponding index to support view selection Exists in the database. IF it doesnt, then warning is displayed. Testing the Matchcode Id. To test the matchcode Id. Maintain matchcode object Utilities display matchcode data.

Using Matchcode Id. When the user do not know which matchcodes are available for a field, user can find the matchcode by: Position the cursor on a field and click on drop down arrow or press the F4 key. A dialog box appears with a list of available matchcode User can select another matchcode by clicking on the NEW selection button. Double click on a matchcode to use it. If you want to use this as default matchcode then click on standard button. If user does this then next time the selected matchcode is proposed automatically. You can enter the search term and press ENTER. If no search term is specified then the system displays all the records for that matchcode.

LOCK OBJECTS In a system where many users can access the same data, it becomes necessary to control the access to the data. In R/3 system, this access control is built-in on database tables. Developers can also lock objects over table records. To lock an object you need to call standard functions, which are automatically generated when defining the lock object in ABAP/4 dictionary. This locking system is independent of the locking mechanism used by the R/3 system. This mechanism also defines LUW i.e. Logical Unit Of Work. Whenever an object is locked, either by in built locking mechanism or by function modules, it creates corresponding entry in global system table i.e. table is locked. The system automatically releases the lock at the end of transaction. The LUW starts when a lock entry is created in the system table and it ends when the lock is released.


Creating Lock Objects Lock object is an aggregated dictionary object and can be defined by using following steps: From initial data dictionary screen, enter the name for the object, click Lock object radiobutton and then click on Create. The system displays a dialog box for maintain Lock Objects screen Enter short text as usual and the name for primary table. Save Select Tables option From this screen you can: Select secondary tables, if any, linked by foreign key relationship. Fields for the lock objects. This option allows you to select fields for objects(R/3 system allows locking up to record level). Lock object argument are not selected by user but are imposed by the system and includes all the primary keys for the table.

Types of locks You can lock the table or record by using following types of locking: Exclusive(E) The locked data can only be displayed or modified by a single user i.e. the owner of the object. Access to other users is denied. Shared (S) several users can access the same record simultaneously but only in display mode and except the first one, who has asked for the data in update mode. Exclusive not cumulating (X) It is similar to exclusive lock in the sense that it allows only a single user access. E can be called several times from the same transaction. In contrast, a lock type X can be called only once during the transaction. Any other call for this lock is rejected.

Activation of Lock Object When you activate the object the lock object the functions are automatically generated. And these are ENQUEUE-EZN and DEQUEUE-EZN. Where EZN is name of the lock object. ENQUEUE is used in program to set the code over the selected data depending upon the lock object arguments DEQUEUE is used to release the lock. EXERCISES 1. Create a matchcode for MARA-MATNR with one matchcode ID. The fields in the ID should be MARA_MATNR, MARD-WERKS, MARD-LGORT, MAKT-MAKTX. 2. Create a GUI status of type list with the following features and attach it to a report (create a simple report with WRITE statement) Use the statement SUBMIT REPORT AND RETURN to call a report. Menu: REPORTS Materials Vendors Exit SYSTEM HELP


Application tool bar : 3 push button Material, Vendors, exit. When material push button or menu option is chosen to display a list of materials with the following Fields: MARA-MATNR, MARD-WERKS, MARD-LGORT, MAKT-SPRAS. When vendor push button or menu option is chosen, display a list of vendors with the following fields. LFAI-LIFNR, LFA1-NAME1,LFA1-ORTO1. Exit to quit the program. 3. Create a transaction with three screens Screen one: Radiobutton: 2 R1,R2. Pushbutton: 2 Next, Exit. When NEXT button is pressed Display screen 2 or screen 3 on the radio button selected. i.e. if R1 is selected display screen 2 or if R2 is selected display screen3. Screen 2: Entry fields : SPFLI-CARRID, SPFLI-CONNID, SPFLI-CITYFROM, SPFLI-CITYTO. Pushbutton : Firstscreen. Exit. Screen 3. Entry fields : SFLIGHT-CARRID, SFLIGHT-CONNID, SFLIGHT-FLDATE,SFLIGHT-SEATMAX, SFLIGHT-SEATSOCC. Pushbutton : Firstscreen, Exit. Firstscreen pushbutton is to display screen 1 and exit is to quit the transaction; ******** Use SELECT-SINGLE ******** 4. Create a transaction with one screen. Screen one: Entry fields : MARD-MATNR, MARD-WERKS, MARD-LGORT Pushbuttons : Firstrecord, Nextrecord, Previousrecord, Lastrecord,Exit. Select the data from MARD into an internal table and whenever a button is pressed display the corresponding record ( i.e. first, Next, previous, or last) using the internal table index. Exit to quit the transaction. 5. Copy above transaction and enhance it with the following features. Place another pushbutton LIST . When this button is pressed Display a list with the following fields. MARD-MATNR, MARD-WERKS, MARD-LGORT. ******** Use LEAVE-TO-LIST-PROCESSING*******


6. Create a transaction with two normal screens and two subscre3ens. Screen1 : normal screen Entry-fields:MARA_MATNR Radiobuttons : Plant,Description Push-button : Display, Exit. Screen2 : Normal screen. Display fields : MARA-MATNR. Pushbuttons : Back, Exit. Screen3 : subscreen Display fields : MARD-WERKS, MARD-LGORT. Scren4:Subscreen. Display fields : MAKT-SPRAS, MAKT-MAKTX. When the display pushbutton is clicked, display screen2 with the proper subscreen attached to it based in the selection of radio button.( i.e. screen3 if plant is selected and screen 4 if description is selected)


BDC(BATCH DATA COMMUNICATION) About data transfer Implementing a new software system takes major efforts. New implementation requires moving data from the present system i.e legacy system into the R3 system. The product, components, customers and vendors have to be available in the new system. Initial data transfer is the process of populating your R3 database with data from your legacy system. To prepare for the data transfer there are certain tasks you need to perform

First understand your SAP system to know which data needs to be transferred e.g. you would not transfer any sales order if you do not use the Sales and Distribution module. Second, you need to know the contents of existing data in your legacy system.

Data transfer program, an effective and efficient way of transferring large amount of data into your new system, saves time and resources, but more importantly it ensures that accurate data is transferred into R/3. Two steps involved in data transfer are CONVERSION and SAP DATA TRANSFER.

CONVERSION: data is converted from your legacy system into the required flat file format. SAP DATA TRANSFER: data is automatically entered into the SAP system. A SAP data transfer program reads the prepared data from the flat file and moves it into R/3.

Steps for any data transfer Preparation for legacy database This is the first step of transfer though not associated with SAP, plays very important role in data transfer. Before data is extracted, delete obsolete data in the legacy system and fix inconsistencies. It is easier this way, than doing it during conversion. The two steps in this are: Data purging & data cleansing Data Purging: Before transferring data from legacy system, delete all the old & obsolete data e.g. to save conversation time and disk space you may delete all one-time customers, vendors and all unused materials. Data Cleansing: This process corrects data inconsistencies and ensures the integrity of the existing data during the transfer process. Mistakes must be fixed before the transfer.

Converting legacy data to the flat file.


For this second step SAP provides no specific tool

In the ABAP /4 development work bench, write an ABAP/4 program to convert a file from your legacy system into the required flat file structure. Use other programming language to write convertion program. For C, COBOL you can easily download the table definition for the specific flat file structure. Use third party tools, such as format editors and code generators that support mapping and conversion between different file formats. For other RDBMS like Oracle, Sybase, MS-Access you have EXPORT utility. By which you can directly export data to flat file.

Files will be discussed in detail in later part of the topic Getting The Data Into R/3 This step actually transfer data to SAP database. After converting the data into the flat file you are ready to begin the third step of the data transfer. Data transfer is an iterative process. You may often feel like you are taking two steps forward and one step back. For example short steps involved in whole process are as follows:

Convert the data from legacy system into the flat file format Run the data transfer program Check data for error Is the transfer working as it was designed? If no, adjust the data/conversion program and start with step1. You are going back to step one, if you dont get the desired result.

You have three different options to enter your data into R/3:

Automatically with SAP standard data transfer program Automatically, by creating your own batch input programs Manually, by entering the data via the corresponding online transaction.

Automatic Transfer With A Standard Data Transfer Program Which can be done if, A standard program exists for the data transfer of a business object in R/3 the data is available in the electronic form. There are significant number of records you want to transfer The cost of converting the legacy data into the required flat file format is acceptable.

Manually Transferring Business Objects You should manually transfer the data if,

You have no legacy system There is only small number of records to enter Translating legacy data into the R/3 structure is more effort than manually entering the data.


Using Customer Specific Batch Input To Transfer Business Object Create batch input program to transfer data if,

No standard program exists to transfer that business object in R/3 The data is available in electronic form There are significant number of records you want to transfer Translating your legacy data into the structure required by your custom program is easier than manually entering data.

Batch input is a standard procedure for transferring large amount of data into the R/3 system. It simulates manual data entry. Data consistency is ensured because batch input uses all the checks conducted on the normal screen. Using batch input is like entering the data online. Another advantage to batch input is that you do not have to check the data in advance. Batch input is a two-step procedure, involves a program that creates the batch input session. This session is the data file that includes everything to begin the transaction and the data to enter on the appropriate screen. The data is not yet in the database table of R/3 application. The second step is to process the session, which then actually transfers the data to the database table. You can transfer data directly to the database table by using CALL TRANSACTION method also. Another method direct input is done for high volume of data for standard application. All these methods are discussed in detail in the later part of the topic. Basically there are two steps involved in any transfer of data from legacy system to SAP system,

Creation of file and transferring file into SAP system Transferring data to database table.

Whenever, you create flat file following points should be considered;

Provide the data in a ASCII/Text file format Know how each line of the file is structured. Know how the required flat file for the business object must be structured

Once your flat file is ready, the data should be transferred into SAP system FILE HANDLING IN SAP Introduction

Files on application server are sequential files. Files on presentation server/workstation are local files. A sequential file is also called a dataset.

Handling of Sequential file. Three steps are involved in sequential file handling OPEN PROCESS CLOSE Here processing of file can be READING a file or WRITING on to a file. OPEN FILE


Before data can be processed, a file needs to be opened. After processing file is closed. SYNTAX:



This statement returns SY_SUBRC as 0 for successful opening of file or 8, if unsuccessful. FOR OUTPUT Opens the file for writing. If the dataset already exists, this will place the cursor at the start of the dataset, the old contents get deleted at the end of the program or when the CLOSE DATASET is encountered. FOR INPUT Opens a file for READ and place the cursor at the beginning of the file. FOR APPENDING Opens the file for writing and places the cursor at the end of file. IF the file does not exist, then it is generated. IN BINARY MODE The READ or TRANSFER will be character wise. Each time n characters are READ or transferred. The next READ or TRANSFER will start form the next character position and not on the next line. IN TEXT MODE The READ or TRANSFER will start at the beginning of a new line each time. If for READ, The destination is shorter than the source, then gets truncated. If destination is longer, then it is padded with spaces. Defaults: If nothing is mentioned, then defaults are FOR INPUT and in BINARY MODE. PROCESS FILE: Processing a file involves reading the file or writing on to the file TRANSFER. TRANSFER statement SYNTAX:

TRANSFER <field> TO <file name> <field> can also be a field string/ work area/ DDIC structure


Each transfer statement writes a statement to the dataset. In binary mode, it writes the length of the field to the dataset. In text mode, it writes one line to the dataset. If the file is not already open, TRANSFER tries to open file FOR OUTPUT (IN BINARY MODE) or using the last OPEN DATASET statement for this file. IN FILE HANDLING, TRANSFER IS THE ONLY STATEMENT WHICH DOES NOT RETURN SY-SUBRC. READ statement SYNTAX

READ DATASET < file name > INTO < field > <field> can also be a field string/ work area/ DDIC structure
Each READ will get one record from the dataset. In binary mode it reads the length of the field and in text mode it reads each line. CLOSE FILE All sequential files, which are still open at the end of the program, will be closed by the program. However, it is a good programming practice to explicitly close all the datasets what were opened. SYNTAX:


SY-SUBRC will be set to 0 or 8 depending on whether the CLOSE is successful or not. DELETE FILE Dataset can be deleted. SYNTAX:


SY-SUBRC will be set to 0 or 8 depending on whether the DELETE is successful or not. Pseudo logic for processing the sequential files: For reading:

Open dataset for input in a particular mode. Start DO Loop Read dataset into a filed. If READ is not successful Exit the loop Endif Do relevant processing for that record. End the DO loop Close the dataset. 109

For writing:

Open dataset for output / appending in a particular mode. Populate the field that is to be transferred. Transfer the filed to a dataset. Close the dataset.

HANDLING OF LOCAL FILES Introduction Files on presentation server / workstation are LOCAL FILES. HANDLING OF LOCAL FILES Local files are processed using UPLOAD and DOWNLOAD FUNCTIONS. The local files are brought into ABAP/4 memory using these functions. Unlike dataset, all the records of the file are UPLOADED into an internal table in one shot. Similarly, all records are DOWNLOADED in one shot from an internal table to a local file. DOWNLOAD function: Important EXPORTING parameters for this function are : Filename = name of the local file to which the internal table is to be downloaded. Filetype = file type, default values are ASC, DAT, BIN Mode = Write mode, overwrite ( ) or append ( A ) Important IMPORTING parameters are: Filename = actual file name entered Tables to be passed to the function: Date_tab = the internal table that is to be downloaded. Similar functions called WS_DOWNLOAD is used to download the information from internal table to local file. The only difference between download and WS_DOWNLOAD is that, download does not require the FILENAME and FILE TYPE to be exported to the function; instead it will ask for the same at runtime. However, for WS_DOWNLOAD. These two parameters need to be passed. UPLOAD function Upload function is used to upload the local file to internal table into SAP System. Parameters passed are similar to DOWNLOAD function. For uploading, you have similar function called WS_UPLOAD.



Many times the input files will have records with different structures. In all such cases each record will have a field (usually the first) which identifies the record (ex. H for header, D for detail or 1 & 2 etc) Text file with multiple record types would be like this : Hxxxxyyyyyyyynnnnnnnn Daaaaaaaaaabbbbbbbbbcccccccc Daaaaaaaaaabbbbbbbbbcccccccc Hxxxxyyyyyyynnnnnnnnnnn Daaaaaaaaaabbbbbbbbbcccccccc Daaaaaaaaaabbbbbbbbbcccccccc Processing Text file with multiple record types: To process such files, it is necessary to first read the record into a character field that is atleast of minimum of the lengths of the different structure in the file. If H type record is 30 char long (including the record identifier) and D type is 40 long (including the record identifier), then this character field should be atleast 40 char long. Pseudo logic for processing the sequential files with multiple record types (text mode):

Open dataset DO Read dataset into character filed. If sy-subrc ne 0 Exit Endif If record id of the char field (or the first char of field) is H Do processing for H type of records. Else Do processing for d type of records. Endif Enddo
Pseudo logic for processing the local files with multiple record types:

WS_UPLOAD into itab Loop at itab If itab-recid is H Do processing for H type record Else Do processing for D type record Endif Endloop


BATCH DATA COMMUNICATION About Data Transfer In R/3 System When a company decides to implement the SAP R/3 to manage business-critical data, it usually does not start from a no-data situation. Normally, a SAP R/3 project comes in to replace or complement existing application. In the process of replacing current applications and transferring application data, two situations might occur:

The first is when application data to be replaced is transferred at once, and only once. The second situation is to transfer data periodically from external systems to SAP and vice versa. There is a period of time when information has to be transferred from existing application, to SAP R/3, and often this process will be repetitive.

The SAP System offers two primary methods for transferring data into SAP Systems from nonSAP Systems or legacy system. These two methods are collectively called batch input Or batch data communication. 1. SESSION METHOD 2. CALL TRANSACTION 3. DIRECT INPUT Advantages offered by BATCH INPUT method: 1. 2. 3. 4. Can process large data volumes in batch Can be planned and submitted in the background No manual interaction is required when data is transferred Data integrity is maintained as whatever data is transferred to the table is through Transaction. Hence batch input data is submitted to all the checks and validations.

To implement one of the supported data transfers, you must often write the program that exports the data from you non-SAP System. This program, known as a Data Transfer. Program must map the data from the external system into the data structure required by the SAP batch input program. The batch input program must build all of the input to execute the SAP transaction. Two main steps are required. To build an internal table containing every screen and every field to be filled in during the execution of an SAP transaction To pass the table to SAP for processing Prerequisite for Data Transfer Program Writing a Data Transfer Program involves following prerequisites: 1. Analyzing data from local file 2. Analyzing transaction

Analyzing transaction involves following steps


The transaction code, if you do not already know it Which fields require input i.e. mandatory Which fields you can allow to default to standard values. The names, types, and lengths of the fields that are used by a transaction Screen number and name of the module pool program behind that particular transaction

To Analyze a transaction do the following:

Start the transaction by menu or by entering the transaction code in the command box. (you can determine the transaction name by choosing System Status) Step through the transaction, entering the data will be required for processing your batch input data. On each screen, note the program name and screen (dynpro) number. (dynpro = dyn + pro. Dyn = screen. Pro = number) Display these by choosing SystemStatus. The relevant fields are program (dynpro) and Dynpro number. If pop-up windows occur during execution, you can get the program name and screen number by pressing F1 on any field or button on the screen. The technical info pop-up shows not only the field information but also the program and screen For each field, check box, and radio button on each screen, press F1 (help) and then choose Technical info.

Note the following information: The field name for batch input, which youll find in its own box. The length and data type of the field. You can display this information by double Clicking on the Data Element Field.

Find out the identification code for each function (button or menu) that you must execute to process the batch-input data (or to go to new screen). Put the cursor on the button or menu entry while holding down the left mouse button. Then press F1 In the pop-up window that follows, choose technical info and note the code that is shown in the Function field. You can also run any function that is assigned to a function key by way of the function key number. To display the list of available function keys, click on the right mouse button. Note the key number that is assigned to the functions you want to run. Once you have program name, screen number, field name (screen field name), you can start writing DATA TRANSFER program 3. Declaring internal table: First internal table similar to structure like local file Declaring internal table like BDCDATA

The data from internal table is not transferred directly to data base table, it has to go through transaction, you need to pass data to particular screen and to particular screen-field. Data is passed to transaction in particular format hence the need for batch input structure. The batch input structure stores the data that is to be entered into SAP System and the actions that are necessary to process the data. The batch input structure is used by all of batch input methods. You can use the same structure for all types of batch input, regardless of whether you are creating a session in the batch input queue or using CALL TRANSACTION


This structure is BDCDATA structure, which can contain the batch input data for only a single run of a transaction. The typical processing loop in a program is therefore as follows: Create a BDCDATA structure Write the structure out to a session or process it with CALL TRANSACTION USING; and then Create a BDCDATA structure for the next transaction that is to be processed.

Within a BDCDATA structure, data is organized by the screens in a transaction. Each screen that is processed in the course of a transaction must be identified with a BDCDATA record. This record uses the program, Dynpro, and Dynbegin fields of the structure: The screen identifier record is followed by a separate BDCDATA record for each value that is to be entered into the field. These records use the FNAM and FVAL fields of the BDCDATA structure. Values to be entered in a field can be any of the following: Data that is entered into screen fields Function codes that are entered into the command field. Such function codes execute functions in a transaction, such as Save or Enter.

The BDCDATA structure contains following fields: PROGRAM

Name of module pool program associated with the screen. Set this field only for the first record for the screen. DYNPRO

Number of the screen, Length (4). Set this field only in the first record for the screen. DYNBEGIN

Indicates the first record for the screen, Length(1). Set this field to X only for the first record for the screen.(Reset to (blank) for all records.) FNAM

Name of a field in the screen. Length (35).The FNAM field is not case sensitive. FVAL

Value for the field named in FNAM. Length (132). The FVAL field is case sensitive. Values assigned to this field are always padded on the right if they are less than 132 characters. Values must be in character format. 4. Transferring data from local file to internal file Data is uploaded to internal table by UPLOAD or WS_UPLOAD function.

5.Population of BDCDATA


For each record of internal table, you need to populate internal table which is similar to BDCDATA structure. All these five initial steps are necessary for any type of BDC interface. DATA TRANSFER program can call SESSION METHOD or CALL TRANSACTION. The initial steps for both the methods are same. First steps for both the method is to upload the data to internal table. From Internal Table the data is transferred to database table by two ways i.e. Session method and Call transaction. SESSION METHOD About Session method In this method you transfer data from internal table to database table through sessions. In this method. an ABAP/4 program reads the external data that is to be entered in the SAP System and stores the data in a session. A session stores the actions that are required to enter your data using normal SAP transactions i.e. Data is transferred to session which in turn transfers data to database table. Session is intermediate step between internal table and database table. Data along with its action is stored in session i.e. data for screen fields, to which screen it is passed, the program name behind it, and how next screen is processed. When the program has finished generating the session, you can run the session to execute the SAP transactions in it. You can either explicitly start and monitor a session or have the session run in the background processing system. Unless session is processed, the data is not transferred to database table. BDC_OPEN_GROUP You create the session through program by BDC_OPEN_GROUP function. Parameters passed to this function are 1. 2. 3. 4. User name Group Lock Date Keep after : : : : User name. Name of the session The date when you want to process the session. This parameter is passed as X when you want to retain session even processing it. Or to delete it after processing. This function create the session through program. Data is transferred to Session by BDC_INSERT.

Some additional information for session processing


When the session was generated using the KEEP option within the BDC_OPEN_GROUP, the system always keep the sessions in the queue, whether it has been processed successfully or not. However, if the session is processed then you have to delete it manually. When session processing is completed successfully and the KEEP option was not set, then it will be removed automatically from the session queue. Log is not removed for that session. If the batch session is terminated with errors, then it appears in the list of INCORRECT session and it can be processed again. To correct incorrect session, first you can analyze the session. The Analysis function allows to determine which screen and value produced the error. If you find small errors in data, you can correct them interactively, otherwise you need to modify batch input program, which has generated the session or many times even the data file. CALL TRANSACTION About CALL TRANSACTION A technique similar to Session method. While batch input is a two-step procedure, Call Transaction does both steps online one right after the other. In this method, you call a transaction from your program by Call transaction<tr.code>using<Bdctab> Mode<A/N/E> Update<S/A> Messages into <int.table>. Parameter-1 is transaction code. Parameter-2 is name BDCTAB table Parameter-3 here you are specifying mode in which you execute transaction A is all screen mode. All the screen of transaction are displayed. N is no screen mode. No screen is displayed when you execute the transaction. E is error screen. Only those screens are displayed wherein you have error record. Parameter-4 Here you are specifying update type by which database table is updated. S- is for Synchronous update in which if you change data of one table then all the related tables gets updated and then sy-subrc is returned i.e. sy-subrc is returned for once and all. A- is for asynchronous update. When you change data of one table, the sy-subrc is returned and then updation of other tables still sy-subrc returned is 0(i.e. when first table gets updated). Parameter-5 When you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains following fields:

1. 2. 3. 4. 5. 6. 7.

T code : transaction code. Dyname : Batch input module name. Dynumb : Batch input dyn number Msgtyp : Batch input message type ( A/E/W/I/S) Msgspra : Batch input lang. Id of message Msgid : Message id. Msgv1.Msgv5 : Message variables.


For each entry updated in the database table message is available in BDCMSGCOLL. As BDCMSGCOLL is structure you need to declare a internal table, which can contain multiple records(unlike structure). Steps for CALL TRANSACTION method 1. Internal table for the data (structure similar to your local file) 2. BDCTAB like BDCDATA 3. UPLOAD or WS_UPLOAD function to upload the data from local file to itab (Considering file is local file) 4. Loop at itab. Populate BDCTAB table. Call transction <tr.code> using <Bdctab> Mode<A/N/E> Update <S/A> Refresh BDCTAB. Endloop. (To populate BDCTAB, you need to transfer each and every field)

The major differences between Session method and Call transaction are as follows: SESSION METHOD Data is not updated in database table unless Session is processed. No sy-subrc is returned Error log is created for error records Updation in database table is always synchronous. CALL TRANSACTION 1. Immediate updation in database table 2. Sy-subrc is returned 3. Errors need to be handled explicitly. 4. Updation is database table can be synchronous Or Asynchronous

Error Handling in CALL TRANSACTION When the records are updated in database table by Session Method, error record is stored in the log file. In Call transaction there is no such log file available and error record is lost unless handled. Usually you need to give report of all the error records i.e. records which are not inserted or updated in the database table and this can be done by following method.


Steps for the error handling in CALL TRANSACTION Internal table for the data (structure similar to your local file) BDCTAB like BDCDATA Internal table BDCMSG like BDCMSGCOLL Internal table similar to 1st internal table (Third and fourth steps are for error handling) 5. UPLOAD or WS_UPLOAD function to upload the data from local file to itab (Considering file is local file) Loop at itab. Populate BDCTAB table. Call transaction <tr.code> using <BDCTAB table. Mode<A/N/E> Update<S/A> Messeges BDCMSG. Perform check Refresh BDCTAB Endloop Form check. IF sy-subrc ne 0. (Call transaction returns the sy-subrc if not successful in updation). Call function Format_message. ( this function is called to store the message given by system and to display it along with rrecord) AAppend itab 2. A Display the record and message.

DIRECT INPUT About Direct Input In contrast to batch input, this technique does not create sessions, but stores the data directly. It does not simulate the online transaction. To enter the data into the corresponding database tables directly, the system calls a number of function modules that execute any necessary checks. In case of errors, the direct input technique provides a restart mechanism. However, to be able to activate the restart mechanism, direct input programs must be executed in the background only. Direct input checks the data thoroughly and then updates the database directly. You can start a Direct Input program in two ways ; Start the program directly This way is the quickest to see if the program works with your flat file. This option is possible with all direct input programs. If something is going wrong and the program ends abnormally, you will not have any logs telling you what has or has not been posted. To minimize the change of this


happening, always use check file option for the first run with your flat file. This allows you to detect format errors before doing transfer. Starting the program via the DI administration transaction. This transaction restarts the processing, if the data transfer program aborts. Since DI document are immediately posted into the SAP D/B, the restart option prevents the duplicate document posting that occurs during a program restart (i.e. without adjusting your flat file) Direct Input is usually done for standard data like material master ,FI accounting document, SD sales order and classification for which SAP has provided standard programs. First time you work with the Direct Input administration program, you will need to do some preparation before you can transfer data: Create variant Define job Start job Restart job

Common batch input errors The batch input BDCDATA structure tries to assign values to fields which do not exist in the current transaction screen. The screen in the BDCDATA structure do not match the right sequence, or an intermediate screen is missing. On exceptional occasions, the logic flow of batch input session does not exactly match that of manual online processing. This can be discovered by testing the sessions online. The BDCDATA structure contains fields which are longer than the actual definition. Authorization problems.

Recording a BATCH INPUT A BI recording allows you to record a R/3 transaction and generate a program that contains all screens and field information in the required BDC-DATA format. You can either use SHDB transaction for recording or SYSTEM SERVICES BATCH INPUT And from here click recording. Enter name for the recording (dates are optional) Click recording. Enter transaction code. Enter. Click save. You finally come to a screen where you have all the information for each screen including BDC_OKCODE. Click Get Transaction. Return to BI. Click overview. Position the cursor o the just recorded entry and click generate program. EDIT


Enter program name. Click enter.

The program is generated for that particular transaction. BACKGROUND PROCESSING Need for Background processing When large volumes of data is involved, usually all batch inputs are done in background. The R/3 system includes functions that allow users to work non-interactively or offline. The background processing systems handles these functions. Non-interactively means that instead of executing the ABAP/4 programs and waiting for an answer, user can submit those programs for execution at a more convenient, planned time. There are several reasons to submit programs for background execution The maximum time allowed for online execution should not exceed 300 seconds. User gets TIMEOUT error and an aborted transaction, if time for execution exceeds 300 seconds. To avoid these type of error, you can submit jobs for background processing. You can use the system while your program is executing.

This does not mean that interactive or online work is not useful. Both type of processing have their own purposes. Online work is the most common one entering business data, displaying information, printing small reports, managing the system and so on. Background jobs are mainly used for following tasks: to process large amount of data, to execute periodic jobs without human intervention, to run program at a more convenient, planned time other than during normal working hours e.g. Nights or weekends. The transaction for background processing is SM36 Or Tools Or System services Jobs Administration Jobs Define jobs

Components of the background jobs A job in background processing is a series of steps that can be scheduled and step is a program for background processing. Job name. Defines the name of assigned to the job. It identifies the job. You can specify up to 32 character for the name. Job class. Indicates the type of background processing priority assigned to the job. The job class determines the priority of a job. The background system admits three types of job classes: A B & C, which correspond to job priority. Job steps. Parameters to be passed for this screen are as follows:


Program name. Variant if it report program. Start criteria for the job: Option available for this are as follows: Immediate allows you to start job immediately. Date/Time allows you to start a job at a specific time. After job you can start a job after a particular job. After event allows you to start a job after a particular event. At operation mode allows you to start a job when the system switches to a particular operation mode. Defining Background jobs It is two step process : you first define the job and then you have to release it. When users define a job and save it, they are actually Scheduling the report i.e. specifying the job components, the steps, the start time. When users schedule program for background processing, they are instructing the system to execute an ABAP/4 report or an external program in the background. Scheduled jobs are not executed until they are released. When jobs are released, they are sent for execution to the background processing system at the specified start time. Both scheduling and releasing of jobs require authorizations. Handling of pop ups in BDC Many times in transaction pop up screen appears and for this screen you dont pass any record but some indication to system telling it to proceed further. For example following screen





To handle such screen system has provided a variable called BDC_CURSOR. You pass this variable to BDC DATA and process the screen. Usually such screen appears in many transactions, in this you are just passing information, that YES you want to save the information, that means YES should be clicked. So you are transferring this information to BDCDATA ie field name of YES, which is usually SPOP_OPTION. Instead of BDC_OKCODE. You are passing BDC_CURSOR. BDC_CUROR is also used to place CURSOR on particular field. An example with session method Following program demonstrate how data is passed from flat file to SAP transaction and from there to database table by using SESSION method The transaction is TFBI (To change customer)


A simple transaction where you are entering customer number on first screen and on next screen data is displayed for that particular customer number. Field, which we are changing here, are name and city. When you click on save the changed record gets saved. Prerequisite to write this BDC interface as indicated earlier is: 1. 2. 3. 4. To find screen number To find screen field names, type of the field and length of the field. To find BDC_OKCODE for each screen. Create flat file.

Flat file can be created in your hard disk as follows 12 8 Leela Penta Sameer Bombay Delhi

(Where 1st character field is customer number 2nd field is customer name and 3rd field is city). To transfer this data to database table SCUSTOM following interface can be used.


REPORT DEMOI Following internal table is to upload flat file DATA: BEGIN OF ITAB OCCURS 0 ID (8) NAME (25) CITY (25) END OF ITAB. *Following internal table BDCDATA is to pass data from internal table to session. DATA: BDCTAB LIKE BDCDATA OCCOURS 0 WITH HEADER LINE. *Some other data DATA: DATE1 LIKE SY DATUM.DATE1 = SY-DATUM-1. THIS IS FOR HOLDDATE. *To upload flat file to internal table. CALL FUNCTION UPLOAD (Only three parameters are passed ie filename, file type, internal table) EXPORTING * CODEPAGE = * FILE NAME = C:\SAPGUI\NEW1.TXT * ITEM = * FILEMASK_MASK = * FILEMASK_TEXT = * FILETYPE_NO_CHANGE = * FILEMASK_ALL = * FILETYPE_NO_SHOW = * LINE_EXIT = * USER_FORM = * USER_PROG = * SILENT = S * IMPORTING = * FILESIZE = * CANCEL = * ACT_FILENAME = * ACT_FILETYPE = TABLES DATA_TAB = ITAB EXPECTATIONS CONVERSION_ERROR =1 INVALID_TABLE_WIDTH = 2






An Example with CALL TRANSACTION. Same steps to be repeated for CALL TRANSACTION The only difference between the two types of interface is in session method, you create session and store information about screen and data into session, when session is processed the data is

transferred to database while in CALL TRANSACTION data is transferred directly to database table.

REPORT DEMO1 *Following internal table is to upload flat file. DATA: BEGIN OF ATDIB OCCOURS 0 ID(8) NAME(25) CITY(25) END OF IT AB *Following internal table BDCDATA is to pass data from internal table to session DATA: BDCTAB LIKE BDCDATA OCCURS 0 WITH HEADER LINE. *To upload flat file to internal table. CALL FUNCTION UPLOAD (only three parameters are passed i.e. filename, file type, internal table






LSMW Legacy System Migration Workbench LSMW is an R/3 based tool to transfer data from legacy (non-SAP) to SAP once or periodically. Migrating data from legacy systems to your new SAP solution is crucial to the success of your implementation. The data must be complete and accurate, and migrated to your SAP solution in a timely and cost-effective manner. LSMW was developed on the basis of many years of experience conducting SAP R/2 to SAP R/3 migrations -- and has been successfully used in hundreds of migration projects. With LSMW, you start by defining the rules for the changeover. LSMW uses those definitions to generate an ABAP program, providing significant support during migration. When data is imported, the system performs the same checks as it does during online entry. The update in your database is performed through the Standard Batch Input Program, the Standard Direct Input Program, IDoc interfaces, or BAPIs. Data migration is 20% of total R/3 implementation expenses. To decrease project budget and project runtime, LSMW can be used.

SAP Legacy System Migration delivers the following key benefits: Dramatically reduces the cost and time of migrating data. Allows you to trace migration history at any time. Ensures optimum quality and consistency through import checks. Allows data mapping and conversion rules to be reused for other migration projects.

Advantages of LSMW: a) There is consistency in migrated data due to standard import techniques i.e., B.I, D.I, BAPI, IDOC. b) It supports data transfer for the most important master and transaction data. c) It is a part of R/3 therefore platform-independent. d) Wide range of data conversion techniques (fixed values, translation, ABAP coding, etc). e) Migration customizing: no literals in rules. f) Conversion program generated from conversion rules. g) Clear interactive process guide: data migration in 14~20 steps. h) Interface for data in spreadsheet (EXCEL sheet) format. i) Available free of charge for SAPs customers and partners. j) Less programming required. The LSM Workbench lets you check the data for migration against the current settings of your customizing. The check is performed after the data migration, but before the update in your database. The LSM Workbench covers the following steps: Read the legacy data from one or several files (e.g. spreadsheet tables, sequential files). Convert the data from source format to target format.


Import the data using standard interfaces (Batch Input, Direct Input, BAPI, IDoc).

Note: With background processing, the input file must not be located in the presentation server. Access to presentation server files is only possible when you are working online. The number of steps can be selected from User menu on the application tool bar. The Main steps option on the user menu activates all steps mandatory for a data conversion. Transaction code: LSMW. Steps in LSMW (BATCH INPUT METHOD):Enter the project name starting with Z click on create. Enter the short description. Press enter. Enter the subproject name starting with Z Enter the short description. Press enter. Enter the object name starting with Z Enter the short description. Press enter. Choose GOTO on the main menu Recordings. Click on create. Enter the name for the recording and the short description. Press enter. Enter the Transaction Code for eg- ME21 for purchase order. Press enter. Record the transaction.The recording appears on the screen. Delete the unwanted fields that do not occur in the legacy file. Click on default all option to get the field names and descriptions. Click on SAVE. Click on BACK twice. Click on execute.

1) Maintain Object Attributes execute click on change <--> display mode.

Choose data transfer once only or periodic. Select the import method- Batch input Recording. Enter the recording name. Click on SAVE and BACK.

2) Maintain Source Structures execute click on change mode create source structure.
Enter name and description. Click on SAVE and BACK.

3) Maintain Source fields execute - click on change mode select the source structure
and click on create source field. Enter the field name, field label, length and type. Click on this field on the screen and repeat the procedure (create source field) so that the fields appear in the order that occurs in the legacy file. Click on SAVE and BACK.

4) Maintain Structure relations execute click on change mode select the structure and
click on create relationship (Here, we create a relationship between the recording and the source structure). Click on SAVE and BACK.

5) Maintain field mapping and conversion rules - execute click on change mode choose
Extras auto-field mapping. This is to map the fields of the recording with fields of the structure.

6) Maintain fixed values, translations, user-defined routines execute click on change

mode In this step, we can maintain fixed values for the fields, translate them to lowercase or uppercase and define routines wherein we can write our own code.


7) Specify files execute click on change mode - If the legacy file is on the presentation
server, double click on on the PC (front end). Enter the file path, name, choose the separator if any (for eg: if the legacy file contains ; as separator between the fields, choose the radiobutton- semi-colon. Click on SAVE and BACK.

8) Assign files - execute click on change mode assign file (the legacy file is assigned to
the source structure). Click on SAVE and BACK.

9) Read/Import data - execute Enter the transaction number range which you want to read
from the legacy file. Click on execute BACK BACK.

10) Display Read/Imported data execute Displays the data/records read/imported from
the file. Click on BACK.

11) Convert data execute - Enter the transaction number range i.e., the records which are
converted from .read to .conv (the conversion routines are applied here and the data is converted into LSMW format). Click on BACK BACK.

12) Display converted data execute - Displays the converted data/records. 13) Create batch input session execute check the keep session checkbox if you want to
retain the session after it is processed. We can specify the number of transactions (records) per Batch Input session. Execute Enter.

14) Run Batch Input session execute This automatically takes you to the transaction
SM35 Batch input session overview screen. Select the session and release/process it in foreground/background or error screen mode. View the session log for any errors. Steps in LSMW (DIRECT INPUT METHOD): Enter the project name starting with Z click on create. Enter the short description. Press enter. Enter the subproject name starting with Z Enter the short description. Press enter. Enter the object name starting with Z Enter the short description. Press enter. 1) Maintain Object Attributes execute click on change <--> display mode. Choose data transfer once only or periodic. Select the import method- Standard Batch/Direct input. Object 0020(for material master), Method 0000.The program name RMDATIND (standard program) automatically appears. Program type D (Direct input) appears. Click on SAVE and BACK. 2) Maintain Source Structures execute click on change mode create source structure. Enter name and description. Click on SAVE and BACK.

3) Maintain Source fields execute - click on change mode select the source structure
and click on create source field. Enter the field name, field label, length and type. Click on this field on the screen and repeat the procedure (create source field) so that the fields appear in the order that occurs in the legacy file. Click on SAVE and BACK.


4) Maintain Structure relations execute click on change mode select the structures:a) BGR00- Batch Input structure for session data, b) BMM00 Material Master: Transaction data, c) BMMH1 Material Master: Transfer of main data. and click on create relationship (Here, we create a relationship between the target structures and the source structure). Click on SAVE and BACK.

5) Maintain field mapping and conversion rules - execute click on change mode click on
TCODE and click on constant. Enter the transaction code - choose Extras auto-field mapping. This is to map the fields of the recording with fields of the structure.

6) Maintain fixed values, translations, user-defined routines execute click on change

mode In this step, we can maintain fixed values for the fields, translate them to lowercase or uppercase and define routines wherein we can write our own code.

15) Specify files execute click on change mode - If the legacy file is on the presentation
server, double click on on the PC (front end). Enter the file path, name, choose the separator if any (for eg: if the legacy file contains ; as separator between the fields, choose the radiobutton- semi-colon. Click on SAVE and BACK.

16) Assign files - execute click on change mode assign file (the legacy file is assigned to
the source structure). Click on SAVE and BACK.

17) Read/Import data - execute Enter the transaction number range which you want to read
from the legacy file. Click on execute BACK BACK.

18) Display Read/Imported data execute Displays the data/records read/imported from
the file. Click on BACK.

19) Convert data execute - Enter the transaction number range i.e., the records which are
converted from .read to .conv (the conversion routines are applied here and the data is converted into LSMW format). Click on BACK BACK.

20) Display converted data execute - Displays the converted data/records. 21) Start Direct Input program execute choose radiobutton-program RMDATIND. Choose
the radiobutton-using physical file name, lock mode-E. Click on execute. Press enter. The message Transaction completed is displayed.


SAP SCRIPTS Getting started with the SAP script Editor SAP script is the integrated text management system of the SAP R/3 System. You will find that it looks and feels a lot like other leading word-processing systems that you may use on your personal computer. SAP script is tightly integrated into the SAP System. You will therefore be using it for many different word-processing tasks all over the SAP System Managing Forms You can modify the SAP R/3 application-specific form or create new forms specific to your requirements. Components of a form are: Header Paragraph formats Character formats Windows Page windows Text elements Header The header data in a form consists of: Administrative data: Enables you to specify the form name, description of the form, and the development class in the administrative data section. You can also specify language attributes, such as the original language, current language, translation information, and the current status of the form. Basic settings: Enables you to specify defaults, such as page formats and page orientation in the basic data section. You can also specify the default text formatting values, such as the default paragraph and default font in the basic settings section. NOTE: You need to complete the paragraph and character format definition before specifying basic data for the header. The paragraph and character format definition are specified in the basic data section for the header. Paragraph Formats You can format a paragraph and specify attributes for paragraph formats in a form. Types of paragraph attributes are: Standard paragraph attributes: Help define the margins, indentation, space control, paragraph alignment, line spacing, blank lines, and page protection. Standard attributes


Font attributes: Help define font attributes for paragraph formats. Font attributes consist of font family, font size, bold/italics, and underline. The group of font attributes is called a system font or SAP font. You can maintain fonts by selecting Tools-> SAP script-> Administration-> Font. Tabs: Help define tab stops for a document. Tab stops define the blank space from the left margin window to the beginning of the text in a paragraph. After specifying the tab stop, you can specify the alignment for text, such as left, right, centre, sign, or decimal in the tab attributes option. Tabs Settings Outline attributes: Helps specify the paragraph numbers and marking attributes to structure the text into sections and subsections. You can specify the outline level, outline name, margin between the number and the window border, left and right delimiters, number chaining, numbering type, and the numbering format. Character Formats Character formatting helps format text within a paragraph. You can specify standard and font attributes for character formats. Standard Attributes The standard attributes help specify character string attributes for a SAP script form. Standard attributes are: String: Enables you to specify the name of the character format. The name starts with a letter and can be followed by a numeral. For example, A1 is the name of the character format. Marker: Enables you to define search keys for character strings in a SAP script document. The character string is replaced with the search key in the output generated by SAP script. Bar codes: Enables you to define a character format to print character strings as bar codes. For example, AUFNR is a SAP bar code used to print production order numbers in production order documents. Protected: Enables you to prevent lines from splitting across pages.

Hidden: Enables you to make character strings visible on the text editor but not on the screen or printer output. Superscript: Enables you to display text half a line above the normal text. For example, you can use superscript to display exponents. Subscript: Enables you to display text half a line below the normal text. You can specify character strings such as base values in the subscript format.


Font Attributes Font attributes for character formats are identical to the paragraph font attributes. Font attributes consist of font family, font size, bold/italics, and underline. The group of font attributes is called a system font or SAP font. You can maintain fonts by selecting Tools-> SAP script-> Administration-> Font.

Windows Windows represent specific areas in a page and are used to display text. You must define at least one window for each form. Types of windows in SAP script are: MAIN: Enables you to display contiguous text in a main window. Note: You can have only one main window for each form. VAR: Enables you to assign the text element to each variable window. SAP script displays the corresponding text when the document is viewed or printed. If the text exceeds the window size, the remaining text is not displayed. Pages A page is a form component that helps define windows in a form. A form must have at least one page. The first page is assigned to the form header. You must specify the Next page attribute for pages to enable SAP script to process. You can have multiple main windows on a page. SAPscript handles multiple main windows using unique main window names, such as MAIN 00, MAIN 01, or MAIN 02. Text Elements Text components of a form are known as text elements. You can define a name for each text element and use the text element in the window. Advantages of text elements include: Helps define text elements of infinite length Helps include symbols within text elements Helps define multiple formats for a single text element Enables you to use SAPscript control statements within a text element You can define text elements without names. Such elements are known as default text elements. Default text elements are processed when you process the corresponding window. You can have only one default text element in a window. Default text elements are defined at the beginning of a window and is processed until a /E command is encountered. Changing and Activating Styles Styles combine paragraph and character formatting for a document. You can define a style that can be applied to a form, a window, paragraphs, or specific text. SAP contains built-in styles to CONST: Enables you to display constant contents.


display mail messages and online documentation. You can modify SAP system styles according to requirements. Style Naming Conventions A style name should begin with a letter and can have maximum of eight characters. You cannot use special characters, such as *, &, /, and blanks.

Style Components When you create a style, you need to specify the header data, character formats, and paragraph formats for it. The header information consists of administrative data and standard attributes. Administrative data specifies the system information, such as the client, style name, language key, and the development class. Specify a short description and a default paragraph in the standard attributes section. Managing Styles You can use transaction SE72 to manage styles or select Tools-> SAPscript-> Style from the SAP initial screen. Creating Styles To create a style: 1. Select Tools-> SAPscript-> Style from the SAP initial screen. 2. Specify the name of the style in the Style field. 3. Click Create. The Style: Change Header screen for the new style appears. 4. Type a brief description for the style in the Description field. 5. Select Style-> Save to create the style. 6. Select Goto-> Paragraph formats to specify paragraph formatting for the style. The Style: Change Paragraphs screen appears. 7. Select Goto-> Character formats to specify character formatting for the style. The Style: Change Character Strings screen appears. 8. Select Goto-> Header and complete the header information by editing the Default paragraph field. Activating Styles To activate styles: 1. Select Style-> Check. The check process ensures there are no errors in the style creation. 2. Select Style-> Activate to make the style available to end-users. Using Form Design Tools SAPscript provides the following tools to design forms: Graphical Form Painter: Helps manage forms in SAP release 4.0 and later. Components of a graphical form painter are header, page layout, paragraph formats, character formats, and documentation. You can include graphics in forms by using a graphical form painter. Alphanumeric Form Painter: Helps manage forms in SAP release 4.0 or earlier. Components of an alphanumeric form painter are header, character formats, paragraph


formats, windows, pages, and page windows. You must define the dimension and position of windows in a page window.

Understanding SAPscript Functions SAPscript control commands and symbols enable you to maintain the SAPscript form. The SAPscript composer processes the control commands and helps control the output. Symbols help define placeholders for the text in a SAPscript document. These symbols are replaced with data when SAPscript processes the document. Using Symbols Text objects in a SAPscript document use data from SAP tables. For example, you can define placeholders for table fields in a SAPscript invoice document. SAPscript dynamically includes the data from the table when the print program processes the invoice document. This helps create a flexible text module that contains symbols and reflects the current data from the table in the invoice. Syntax for Symbols You can distinguish symbol names from text using a delimiter. The symbol naming rules are: Precede and succeed symbol names by a delimiter, &. Exclude blanks or special characters, such as +, ', (, or) in symbol names. Specify formatting options with symbol names. The formatting code must follow the symbol name within braces. Define symbol names that are case insensitive. Few valid symbol names are: &ZSYMBOL & &DATE& &MARA-MATNR& &SYMBOL1(I)& Symbol Types There are four types of symbols in SAPscript, system, standard, program, and text. System Symbol Values for system symbols are defined in the SAP R/3 system. Current date, current time, current page number, and spaces are system symbols. Names of system symbols are reserved and you cannot modify them. Examples of System Symbols Symbol &DATE& &MONTH& Description Displays the current date. The value is retrieved from the SYDATUM field in the SYST structure. Displays the current month number, such as 12.


Examples of System Symbols Symbol &YEAR& &PAGE& &NEXTPAGE& &ULINE& Description Prints the current year as a four-digit number. Displays the page number on each page. You can define the page number format in the page attributes of a form. Prints the number of the next page. Prints a string of underline characters in the output. You must specify the number of underline characters. SAPscript prints one underline character by default. Prints vertical line characters in the output. The default vertical line character is 1.


Standard Symbols Standard symbols are language specific and are defined in table TTDTG. The TTDTG table consists of the language key field, symbol, and the symbol value. Standard symbols are preformatted as character strings. You can define customer-specific standard symbols. For example, you can define material numbers as standard symbols specific to a customer. Program Symbols You can transfer data stored in work areas defined in an ABAP/4 program to SAPscript documents. Program symbols obtain values from ABAP/4 print program work areas. SAPscript uses formatting options from the data dictionary for program symbols. Table work area fields are: SYST: Contains data that can be used as program symbols. The fields in the SYST structure are dependent on the programming environment. USR03: Contains the user master record for an end user, such as the address, telephone, fax, user language, department, and the cost center. SAPSCRIPT: Contains fields, such as SAPSCRIPT-DRIVE, SAPSCRIPT-FORMPAGES, and SAPSCRIPT-JOBPAGES that can be used as program symbols. Text Symbols You can define text symbols in a form using the DEFINE statement as: /: DEFINE &usr_symbol& = 'Example' * &usr_symbol& In the above code, SAPscript prints the value Example in the form output. Working with Control Commands SAPscript control commands help control the output of SAPscript documents. These commands are used in SAPscript text editors. The SAPscript composer parses control commands. The composer applies character and paragraph formatting to text and symbols in a form.


The lines prefixed by /: in the format tag column are control command lines. For example, keywords PROTECT, ENDPROTECT, IF, and ENDIF in the program are control commands. Examples of SAPscript Control Commands Control Command NEW-PAGE Meaning Opens a new page and inserts a page break in the current page. Prevents splitting of a paragraph into two pages. Creates a text symbol. Includes the standard text in the current text. Syntax /: NEW-PAGE name] [page


/: PROTECT ... ... /: ENDPROTECT /: DEFINE &symbol name& = 'value' /: INCLUDE name [OBJECT o] [ID I] [LANGUAGE l] [PARAGRAPH p] [NEWPARAGRAPH n] /: ADDRESS ... ... /: ENDADDRESS /: IF (condition) ... /: ELSE ... /: ENDIF /: PERFORM <form> IN <program_name>



Formats the address based on the country postal convention. Defines conditional statements using control branching. Calls ABAP/4 subroutines from another program.



SAPscript Programming Interface The five components of SAPscript: SAPscript Components Component Editor Styles and Forms Description Provides storage of the text. Controls the output of the text.


SAPscript Components Component Composer Programming interface Database tables Description Prepares output devices documents on printers. and manages printing of

Helps include SAPscript components into the application and controls the output of forms. Stores text, styles, and forms.

The form specifies the layout for the text. The print program retrieves data from the underlying database and the composer processes the form. The programming interface helps integrate SAPscript and ABAP/4 programs. The interface consists of function modules, data structures, and control tables. Using Function Modules Function modules are global functions or procedures defined in function groups. You can invoke function modules from any ABAP/4 program. SAPscript uses functional modules for functions related to database, forms, text administration, editor, print, and consistency checks. Database Functions You can use database function modules in SAPscript to perform text operations, such as reading from the text module and passing it to work areas, saving text, and deleting text. Function Modules for Database Operations Function Module READ_TEXT READ_TEXT_INLINE Description Reads the text from the text file or the text memory. Reads the text from the text file or the text memory into work areas and transfers lines from the LINES table to the INLINES table based on the INLINE_COUNT parameter value. Writes the text module to the text file or the text memory. Deletes the text module from the text file. Copies the text from a text file. The TEXTS table stores the text to be copied. Creates a table using the text headers of text modules matching the selection fields specified in the function call, such as OBJECT, NAME, ID, and LANGUAGE.



Form Functions You can perform form-related operations, such as opening forms, printing forms, finding form elements, and starting a new form using function modules. Form Function Modules Function Module OPEN_FORM WRITE_FORM Description Opens a form for printing. You can specify the name of the form in the FORMS parameter. Writes the form element specified in the ELEMENT parameter to the output. You can specify the name of the window for output using the WINDOW parameter. Starts a new form. You can have multiple forms within the OPEN_FORM and CLOSE_FORM function calls and use START_FORM to switch between forms. End the current form using the END_FORM before starting a new form. Ends a current form in execution. Closes the form opened using the OPEN_FORM statement. Passes SAPscript control commands to the form. You can specify the control command using the EXPORTING COMMAND parameter.



Modifying SAPscript Forms: The Basics Overview This chapter focuses on basic form modifications as: Copying a form Test printing a form Modifying the layout of a form (creating, renaming, moving, resizing, or deleting a window) Modifying the content of a form (moving fields or tabs, looking up a field in the data dictionary, adding fields to your form, or adding fields to a print structure) Copying a Form Forms must be copied before changes are made. The following example shows how to copy a form. Example Task: Copy a form for a sales order confirmation. 1. From the SAP standard menu, choose Tools SAPscript SE71 - Form.



On the Form Painter: Request screen: Enter the name of the new form in the Form field. This name should be as similar as possible to the old name and has to begin with Z or Y, since the new form name has to be in the name range for customer objects (for example, the new name for the Sales Order Confirmation is ZVORDER02). Enter EN in the Language field. Choose Choose 4. Create.


to accept the message displayed in the popup window.

On the Administrative Screen: a. Enter Sales Order Confirmation in the Description field. b. From the menu bar, choose Form Copy from. In the popup window: a. Enter ZVORDER01 in the Form field. b. c. Enter EN in the Language field. Choose .


If you activate the form, it is not necessary to save the form in step 6a, because the form is saved during activation in step 6b. 6. On the Form: Change Header: ZVORDER02 screen: a. Save form ZVORDER02. b. c. To activate the changes, choose . Go Back to return to the SAP standard menu.

To test the form during sales order customizing, specify that form. ZVORDER02 should be used to print all sales order confirmations. Test Printing a Form Test prints provide an easy way to check modified forms. On a test print, SAPscript prints a string of Xs for all of the variables used in the form. For example, if a variable is 5 characters in length, SAPscript prints XXXXX in its place. All windows, except MAIN, are printed as they appear in the actual output. MAIN contains a list of all defined text elements. Example Task: Execute a print test of a form. 1. From SAP standard menu, choose Tools SAPscript SE71 Form. 2. On the Form Painter: Request screen: a. Enter ZVORDER02 in the Form field. b. From the menu bar, choose Utilities Test print. 3. On the Print screen: a. Enter a printer name (for example, LP01) in the Output Device field. b. Select Print immediately. c. Choose Print.


4. On the Form Painter: Request screen, go Back to return to the SAP standard menu.

Manipulating the Layout of a Form Manipulation of the layout of a form can be subdivided into the following operations: Creating a new window Renaming a window Changing the position of a window Changing the size of a window Removing a window Aligning a window

Creating a New Window Example Task: Add a new window to a form. 1. From the SAP standard menu, choose Tools SAPscript SE71 Form.


On the Form Painter: Request screen: a. Enter ZVORDER02 in the Form field. b. Enter EN in the Language field. c. Select Page layout.

d. Choose 3. 4. 5. 6.


The window can also be created by choosing Edit Windows Create Variables window from the menu on the Administrative Screen. In the Design Window, right-click to access the form layout manipulation menu and choose Create window. Click on the Administrative Screen. To activate the changes, choose .

Renaming a Window Example Task: Change the name (and description) of the existing window (for example, WINDOW1 to ADDRESS2). 1. From the SAP standard menu, choose Tools SAPscript SE71 Form.


On the Form Painter: Request screen: a. Enter ZVORDER02 in the Form field. b. Enter EN in the Language field. c. Select Page layout. d. Choose Change.



In the Design Window: a. Select WINDOW1. b. Right-click to access the form manipulation menu and choose Rename.



On the Rename window: a. Enter a name (for example, ADDRESS2) in the to field. b. Choose . Click on the Administrative Screen. On the Administrative Screen: a. Enter a description for the renamed window (for example, Shipping Address) in the Description field.

5. 6.

b. To activate the changes, choose . c. Go Back twice to return to the SAP standard

7. The window can also be renamed by choosing Edit Windows Rename from the
menu bar on the Administrative Screen.

Changing Window Position or Size Using Design Window Example Task: Enlarge or shrink the size of a window, or place a window at another position in the form.

standard menu, choose Tools SAPscript SE71 - Form.

From the SAP


On the Form Painter: Request screen:

a. b. c. d. 3.

Enter ZVORDER02 in the Form field. Enter EN in the Language field. Select Page layout. Choose Change.

In the Design Window: a. To move a window, grab the window by pressing the left mouse button. Move the window to the new position while keeping the left mouse button pressed. Release the left mouse button at the new position. b. To change the size of a window, position the cursor on the corner or edge of the window and press the left mouse button. Keep the left mouse button pressed while changing the window size. Release the left mouse button when the new size is adjusted.


Click on the Administrative Screen.

a. To activate the changes, choose


b. Go Back twice to return to the SAP standard

menu. Changing Window Position or Size Using Administrative Screen Example Task: Change the position or size of a window by changing the margin or the width and height of a window. From the SAP standard menu, choose Tools SAPscript SE71 Form. 2. On the Form Painter: Request screen: a. Enter ZVORDER02 in the Form field. b. Enter EN in the Language field. c. Select Page layout. d. Choose Change. position


3. 4.

Click on the Administrative Screen. In the Windows section of the Administrative Screen:

a. Choose a window by clicking the arrow in the Name field.

b. Choose the desired window name. c. To change the position of the chosen window, change the values in the Left margin and Upper margin fields. d. To change the size of the chosen window, change the values in the Window width and Window height fields.

e. To activate the changes, choose . f. Go Back twice to return to the SAP standard
menu. Removing a Window Example Task: Delete the window ADDRESS2 from the form.

standard menu, choose Tools SAPscript SE71 - Form.





On the Form Painter: Request screen: a. Enter ZVORDER02 in the Form field. b. Enter EN in the Language field. c. Select Page layout. d. Choose Change. In the Design Window: a. Select ADDRESS2. b. Right-click to access the form manipulation menu and choose Delete. Click on the Administrative Screen. On the Administrative Screen:



4. 5.


a. To activate the changes, choose . b. Go Back twice to return to the SAP standard
menu. Deleting Window Text Using the PC Editor To delete the content of a line in a window, highlight and delete the content. Then place the cursor on the empty line and delete the line. To delete an entire block, highlight and delete the block. Deleting Window Text using the Text Editor To delete a line in a window, overwrite the line (including the format column) using spaces. To delete an entire block of lines, mark the block by double-clicking on the format columns of the first and last lines. Choose Delete. Removing a Field There are several different cases to consider when removing a field. Case 1: The field is not located with other fields in a command line. You can remove the field by deleting the command line. Case 2: The field is located with other fields in a command line. Tabs do not separate the fields. You can remove the field by changing the command line. In the command line, highlight the field and delete it. Case 3: The field is located in a line item table. Tabs separate the different table columns. For example, to remove the item number from a sales order confirmation deletes the text ITEM and the subsequent tab in the item header and move the text Material and Description. Next, delete the item number variable and move the material number and the description variables. Example Task: Remove the item number from a sales order confirmation. 1. From the SAP standard menu, choose Tools SAPscript SE71 - From. 2. On the Form Painter: Request screen: a. Enter ZVORDER02 in the Form field. b. Enter EN in the Language field. c. Select Page layout. d. Choose Change. 3. In the Design Window: a. Activate the MAIN window. b. Right-click to access the form layout manipulation menu and choose Edit text.

The PC Editor for the MAIN window is displayed on the Administrative Screen. 4. On the Window MAIN screen: a. Scroll down until you see the command line ITEM_HEADER. b. From the menu bar, choose Format Paragraph on/off to display the tabs in the PC Editor. 5. Highlight the text Item and the subsequent tab (represented by an arrow) and delete both (press the Delete key on your keyboard).


6. If you do not know the paragraph format which is used for a text element in the PC Editor, you can display the paragraph format by choosing Formats. For the first text element displayed under the command line &ULINE (71), the paragraph format is IL (line item). 7. On the Window MAIN screen: a. Scroll down until you see the command line ITEM_LINE. All lines within this section have the paragraph format IL (line item). b. Click the variable &VBDPA-POSNR&. c. 8. 9. Choose to delete the variable.

Delete the tab that follows &VBDPA-POSNR&. Delete the first tab in the four lines that follow.

The screenshot shows the result of the changes. Since you deleted the first tab in the paragraph format IL (line item), you have to adjust the tabs for this paragraph format. 10. 11. a. b. c. Go Back to return to the Administrative Screen. On the Administrative Screen: Choose Paragraph formats. Double-click paragraph format IL. Choose Tabs.

d. To delete the first tab you have to overwrite the first tab position 7.00 with blanks. e. To move the second tab to the left you have to adjust the second tab position by overwriting 26.00 with 19.00. Since the first tab was positioned seven characters from the left, the second tab has to be moved nineteen characters to the left (26 minus 7). f. g. To activate the changes, choose . Go Back twice to return to the SAP standard menu.

Printing a Company Logo (Windows BMP Format) Starting with Release 4.6, SAPscript offers you a new tool for importing graphicsin the Windows bitmap formatinto your forms (for example, logos). Called SAPscript Graphic Management, this new solution: Gives you more flexibility in creating graphics Helps you manage your graphics with ease Helps you easily include graphics in forms Updates the former complex process for importing graphics The SAPscript Graphic Management can also manage graphics saved as Baseline TIFF 6.0 format. To include a graphic in your form, perform the following steps: 1. Import the graphic into the document server. 2. Preview the graphic printout. 3. Include the graphic in a form.


Step 1: Import the Graphic into the Document Server 1. From the SAP standard menu, choose Tools SAPscript Administration SE78 - Graphic. 2. From the workplace menu, choose Stored on document server GRAPHICS BMAP. Graphics stored in the document server are separated into graphic objects and graphic IDs.

3. 4. a.

On the SAPscript graphics management window, choose . On the Import graphic window: In the File name field, enter the file location (on your presentation server) where the import program can find the graphic (for example, C:\SAPlogo.bmp). b. In the Name field, enter a name for the graphic (for example, LOGO_01). c. In the Description field, enter a description (for example, COMPANY LOGO). d. Choose . 5. Choose Exit to return to the SAP standard menu.

Step 2: Preview the Graphic Printout 1. From the SAP standard menu, choose Tools SAPscript Administration SE78 - Graphic. 2. From the workplace menu, choose Stored on document server GRAPHICS BMAP. 3. On the SAPscript graphics management screen: a. Enter the graphic name in the Name field (for example, LOGO_01). b. To preview the graphic, choose . c. Choose Exit to return to the SAP Easy Access screen. d. A color graphic can be viewed only in color. Step 3: Include the Graphic in a Form To include your company logo in a form, you must create a graphic. SAPscript creates a new window and places it automatically on the top left corner of the page. Example Task: Include a graphic in a form by creating a graphic window. 1. From the SAP standard menu, choose Tools SAPscript SE71Form. 2. In the Form Painter: Request screen: a. Enter ZVORDER02 in the Form field. b. Enter EN in the Language field. c. Select Page layout.

d. Choose 3.


In the Design Window, right-click to access the form layout manipulation menu and choose Create graphic.



On the Include graphic screen: a. Enter the name of the graphic (for example, LOGO_01). The name of the graphic is the name you defined when you imported the graphic onto the document server. b. Choose .

5. The new graphic is always positioned in the top left corner of the form. 6. You can move the graphic window easily using the drag-and-drop technique, but you cannot resize the graphic within SAPscript. You have to resize the graphic using a graphics tool outside SAPscript. You must then import the graphic onto the document server and include it in your form. 7. Select the Administrative Screen.

8. On the Administrative Screen: a. To activate the changes, choose . b. Go Back twice to return to the SAP standard

NACE Transaction This transaction is used to link the driver program, form routine and the copied zform. Select the application for the form for eg: EF for purchase order and click on output types. Choose the output type (NEU for purchase order), double-click on processing routines, click on change mode and replace the form name with the zform name. Click on Save. ME9F Transaction ( for Purchase Order ) In this transaction, enter the document number (PO number) and click on execute. Check the checkbox and click on display message. The form is displayed.

SMARTFORMS Introduction to SAP Smart Forms SAP Smart Forms is introduced in SAP Basis Release 4.6C as the tool for creating and maintaining forms. The basic structure of SAP Smart Forms consists of the Smart Form Builder, the Smart Form print form template (which you create or is given to you as a pre-configured


starting point), the Smart Form function module, and the Smart Form print program (also described as a driver program). SAP Smart Forms allow you to execute simple modifications to the form and in the form logic by using simple graphical tools; in 90% of all cases, this won't include any programming effort. To print a form, you need a program (driver program) for data retrieval and a Smart Form that contains the entire from logic. The Smart Form print programs are not the same as SAP Script programs, and you cannot use a SAP Script print program with a Smart Form print form. As data retrieval and form logic are separated, you must only adapt the Smart Form if changes to the form logic are necessary. Programming Flow When an SAP Smart Form template is created, a user creates the form layout, defines the required fields, conditions, and special programming instructions in the Smart Form template using the Smart Form Builder. After the form design is complete, the form needs to be activated before it can be tested or made accessible by print programs. When a smart form is activated, the system generates a function module that encapsulates all the attributes of the smart form. This function module interacts with the application program and print program to create the output in the user-defined output media for the specified device. At runtime, the system processes this function module. As soon as the application program calls the function module, the smart form uses the module interface to transfer any table data previously selected and to print the form according to the form description. You can insert static and dynamic tables. This includes line feeds in individual table cells, triggering events for table headings and subtotals, and sorting data before output. You can check individual nodes as well as the entire form and find any existing errors in the tree structure. The data flow analysis checks whether all fields (variables) have a defined value at the moment they are displayed. SAP Smart Forms allow you to include graphics, which you can display either as part of the form or as background graphics. You use background graphics to copy the layout of an existing (scanned) form or to lend forms a company-specific look. During printout, you can suppress the background graphic, if desired. Execute transaction SMARTFORMS to start SAP Smart Forms. You design a form using the graphical Form Painter and the graphical Table Painter. The form logic is represented by a hierarchy structure (tree structure) that consists of individual nodes, such as nodes for global settings, nodes for texts, nodes for output tables, or nodes for graphics. To make changes, use Drag & Drop, Copy & Paste, and select different attributes. These actions do not include writing of coding lines or using a Script language. Using your form description maintained in the Form Builder, Smart Forms generates a function module that encapsulates layout, content and form logic. So you do not need a group of function modules to print a form, but only one.


For Web publishing, the system provides a generated XML output of the processed form. Smart Forms provides a data stream called XML for Smart Forms (XSF) to allow the use of 3rd party printing tools. XSF passes form content from R/3 to an external product without passing any layout information about the Smart Form. Difference with SMARTFORMS vs. Sap Scripts (SE71) The Following are the differences: a) Multiple page formats are possible in Smart Forms which is not the case in SAP Scripts b) It is possible to have a Smart Form without a main window. c) Labels cannot be created in Smart Forms. d) Routines can be written in Smart Forms tool. e) Smart Forms generate a function module when activated.

Smart forms described: Smart Forms is very similar to SAP Scripts. This is also a tool, which is extensively used to create layouts, and then a separate print program is created. This print program is used to create the output internal table, which in turn is thrown to the smart form where the field values are displayed. In the print program mentioned below, an output internal table is created by populating certain fields from database tables into it. Once the output internal table is ready, then the function module SSF_FUNCTION_MODULE_NAME is called. Here, in the import parameters, the name of the smart form is given. The output of this function module is the name of another function module. This function module is again called, in this example, the name of the function module is "/1BCDWB/SF00000007". The output of this function module is the output internal table that we have created earlier in the program. So, in case of smart forms, we use 2 function modules for the processing of the smart form. Once this internal table is thrown from the smart form, then in the layout, the required fields can be displayed. This is how a smart form works:REPORT ZRGSSAMPLE. TABLES: EKPO. DATA: FM_NAME TYPE RS38L_FNAM. PARAMETERS: P_EBELN LIKE EKPO-EBELN.




Smart Forms in detail: Smart Forms are used in SAP to create and maintain forms for mass printing. The Smart Forms offer the following advantages:


Creating and maintaining forms require half the time. Adapting to forms without any programming techniques due to GUI. Web publishing using the generated XML output.

Migration from SAP Script to Smart Form is supported in smart forms. In a smart form one describes: The layout of the form (element positions on a page). Individual elements to be displayed, for ex: text, graphics, addresses, tables etc., The form logic, for example to read the application data from internal tables, to introduce conditions and to control the process flows. A form interface to transfer the application data to form definition. Creating Forms Using SAP Smart Forms When creating a form one must: Retrieve the application data Describe the form Pass the application data to the form Retrieving the application data: Write an ABAP program to retrieve data or include a retrieval routine (form routine) into the application. This code consists of statements that select data from databases according to certain selection criteria. Store the retrieved data in internal tables, structures or variables and transfer it to the form in one step. Describing the Form: The user defines the form using a smart form. Use the tools of the form builder as listed below: Use the form painter to position the windows, graphics and addresses on a page. Use the PC editor to write the texts. Use the table painter to format the tables. The flow control is used to print the pages and elements. Form Logic (Introduction) In the form builder one can describe a smart form by a set of nodes. The node global settings and its three successors form attributes, form interface and global definitions always exist for any newly created forms. To describe the form logic, create the hierarchy under the node pages and windows. The following rules apply to control the flow of the form output. The nodes in the tree structure are processed from top to bottom. For each node there is a tab, this can be used to link the node to a condition. If the condition is true, the system processes the node. If not, it skips the node and all its successors. One should define a next page for each page. To define the text formats, one can use the Smart Styles. We can create paragraph and character formats, which you can then assign to texts and fields in the Smart Form. Style builder:


The style builder screen consists of the predetermined nodes (header data, folder for paragraph formats, folder for character formats). On the right one can see the maintenance screen with its tab pages. At the bottom the preview of the selected font can be viewed. Field list: The field list displays the following data in the form of a tree structure: All tables, fields and structures passed via the form interface. System fields and the fields that are defined in the global definitions. Error list: ` This allows one to check whether a correct field name has been entered or not and that the form knows the field or not. To display the field list, in the form builder choose Utilities - field list On/Off. The error list contains the list of errors and warnings displayed at the bottom of the maintenance screen. Node types: When a form is created, the tree structure of the form painter contains two root nodes. The successors of the global settings node are used to maintain form attributes, the form interface and global definitions. The successors of the pages and windows node to create the pages of the form, position elements on these pages, and determine the sequence on how to process these created elements. Special Node Types: The following node types describe advanced use of SAP Smart Forms by users. The command node contains both simple commands (dynamic page break and initializing an outline paragraph) and commands for special usage (inserting print controls, spool attributes). Command nodes contain commands for different application purposes. In most cases, you need the command node to insert a dynamic page break within the main window. You use program lines nodes to enter free ABAP coding. These nodes are evaluated at the moment they are processed according to their position in the tree. If you insert program lines at the appropriate position in the tree structure, you can use it, for example, to calculate subtotals and grand totals in tables. Program lines nodes are not intended to print output in the form. Therefore, they have no Output options tab.

The complex section unites the attributes of different nodes. Before the new node types for tables, templates, and loops were introduced, you used complex sections to deal with these constructions. Older forms still use this node; but for new forms you should prefer the new node types.

Basic elements of a form Creating pages:


Each form consists of one or more pages. The first page in the tree structure is the start page and the processing of the form starts with this page itself. Open the context menu for existing page node and choose createpage. Enter a unique name for the node and a description. Determine the format and the mode of the page counter on the general attributes Determine the print attributes of the page on the output options. Determine a background graphic for the entire page on the background tab.


Creating windows: One can set the size and position of the window graphically in the form painter. There are main windows and subwindows. The difference between these two is that the output in a main window can cover several pages. Open the context menu for an existing page node and choosewindow Enter a name for the node and a description On the general attributes indicate whether the window is a main window. If sub window wants to be created then leave the checkbox empty

Positioning texts on the form The texts are displayed in the form using text nodes. The only exceptions are addresses. This uses its own node.

The predecessor node of the text node determines its use: Predecessor node Sub window Main window Template Table Header and footer Event node Used to Position text on one or more pages Display text in relation to other nodes in the main window, it may cover several pages Displays texts for table cells of a static table Display table contents Display column headings and grand totals in tables Display subtotals in a table

There are three text types: Text element: to enter new text in the PC editor Text module: to include a text module Include text: to include an existing SAP script text

Inserting addresses: One can use the address node to insert an address into the form. This guarantees that the address is formatted according to the postal rules of the sender country.


To create an address node, call the context menu for that node in the tree structure that one wants to contain the text and choose create->text Enter a name for the node and a description Determine the address type on the general attributes tab For organizational addresses one has to specify the address number, for any other one has to specify the person number and the address number In the box additional addresses one can maintain other attributes to specify how to display the address Printing graphics: Goto tcode se78 to import graphics into the SAP system. The transaction imports the graphics and stores it in the document server and then it can be displayed in the form. To create the graphic node, call the context menu for that node in the tree structure and choose create->graphic Enter a name for the node and the description On the general attributes determine whether a colored or a black and white Use the fields object, id and name to identify the graphic

Define the table layout: The table layout is used to determine the following, The number of lines and cells The height and width of each cell The alignment of the table in the window Whether and where to display separator lines or frames.

Steps to create a simple SMARTFORM: 1. Create a new Smart Form 2. Define looping process for internal table 3. Define table in Smart Forms 4. To display the data in the form. 5. Calling Smart Forms from your ABAP program.

Create a new Smart Form Transaction code SMARTFORMS Create new Smart Form call ZRGS_SAMPLE The followings screen format will appear: - Form ZRGS_SAMPLE - Global settings


- Form attributes - Form interface

Description, Page formats you declare variables that are passed in and out of the Smart form (in from the print program to the smart form and out from the smart form to the print program).

- Global definitions - Pages and windows + %PAGE1 New page

Global data are declared

You can click at the Form Painter button to view the graphical display layout of your Smart Form. Define looping process for internal table Pages and windows First Page -> Header Window (Cursor at First Page then click Edit -> Node -> Create) Here, you can specify your title and page numbering &SFSY-PAGE& (Page 1) of &SFSY-FORMPAGES & (Total Pages) Main windows -> TABLE -> DATA In the Loop section, tick Internal table and fill in IT_EKPO (table in ABAP SMARTFORM calling function) INTO IT_EKPO Define table in Smart Form Global settings: Form interface Variable name Type assignment Reference type IT_EKPO TYPE Table Structure Global definitions Variable name Type assignment Reference type IT_EKPO TYPE Table Structure To display the data in Smart form Make use of the Table Painter and declare the Line Type in Tab strips Table e.g. Header for printing column headings, Details for printing data details, Footer for printing footer texts. You have to specify the Line Type in your Text elements in the Tab strips Output options. Tick the New Line and specify the Line Type for outputting the data. Declare your output fields in Text elements. Save and check the form. Activate the form.


You can directly test the function module that is generated or else you can write a print program from which you can call the function module to get the output. You can know the function module name by clicking Environment on the Menu bar and choosing Function module name. Migrating SAP Scripts to Smart Forms: You can migrate a SAP script form into a Smart Form and convert a SAP script style into a Smart Style. When converting a SAP script style into a Smart Style, the system converts all paragraph and character formats with all their properties and attributes without any changes. Thus you can use the converted Smart Style without making any adaptations. When migrating a SAP script form into a Smart Form, the system executes the following steps: It copies the language attributes and the output options. It migrates the layout information including pages, windows, and their attributes and positions on the page. It copies the texts in the form. It displays the fields (SAP script notation: program symbols) in the texts. It converts the SAP script commands (such as NEW-PAGE or IFENDIF) to comment lines and displays them in the texts.


1. Go to the SAP Smart Forms initial screen (transaction SMART FORMS). 2. In the Form field enter the name of the Smart Form you want to create. 3. Choose Utilities Migrate SAP script form.
The dialog window Migrate SAP script Form appears. 4. Enter the name and the language of the source form (SAP script). 5. Choose Enter. This takes you to the change mode of the SAP Form Builder (If the selected SAP script form does not exist in the selected language, a dialog window appears on which you can select one of the existing languages). 6. Now change the design of the form and of the form logic. To activate the Smart Form choose Activate.

Smart Styles The Style Builder is used to define Smart styles. In a Smart Style you define the paragraph and character formats, which you can then assign to texts and fields in the Smart Form. On the left, you see the style tree, which consists of predetermined nodes (header data, folder for paragraph formats, folder for character formats). You can navigate between the nodes and create new nodes. On the right, you see the maintenance screen with its tab pages (here, for example, standard settings for the font in the selected color blue). At the bottom right, you see the preview of the selected font.


Features A Smart Style contains: Header data containing the default values of a Smart Style Paragraph formats including indents and spacing, font attributes, tabs, and outline and numbering Character formats including effects (superscript, subscript), barcode and font attributes Colors and underlines for a paragraph or character format Preview


1. Choose transaction SMARTSTYLES. The Smart Styles initial window appears. You can
also enter a style in the SAP Smart Forms initial screen (transaction SMARTFORMS) to branch to the Style Builder. 2. Enter the style name. 3. To create a Smart Style, choose Create. 4. To activate the Smart Style, choose Activate. Note: To be able to use and transport a Smart Style in a Smart Form, you have to activate it first. During activation, the system checks the Smart Style for errors and, if necessary, displays an error list. You must assign a Smart Style to each Smart Form. You do this globally for the entire Smart Form in the form attributes. In addition, you can assign a Smart Style locally to a node, for example, a text node. This assignment then applies for the entire sub-tree and overrules the global settings. To reuse styles, you can download a Smart Style locally on your PC and upload it again later, for example in a different system. To do this, choose Utilities Download or Utilities Upload. Note: You can convert an existing SAP script style into a Smart Style.

Header data: In the header data you maintain the default values of a Smart Style. If you do not assign different values to the paragraph and character formats in the Smart Form, the system uses these default values. You must define the following values in the header data: Standard paragraph Default tab stops Characters per inch/Lines per inch Font family and font size


Paragraph formats: A paragraph format contains information on indents, spacing, font settings, text color, tabs, numbering and outline. Each paragraph format must have a unique name. In the PC Editor, you assign these formats to a text or a field. Font Settings: If a paragraph format does not contain any font settings, the system uses the default values from the header data. For each paragraph format, you can define any number of tabs. Creating paragraph formats:

1. In change mode of the Smart Style, select the node Paragraph Format and choose

2. In the Paragraph Format field enter a two-character paragraph key.

3. Select the desired attributes on the individual tabs. 4. Choose Activate. Character Formats: Character formats are used to assign special output attributes to sections of texts or character strings within a paragraph. A different name must be given for each character format. A Smart Style can consist of nothing but character formats. However, at least one standard paragraph must be defined. After creating a character format, you can choose the following attributes: Font attributes and superscripting/subscripting Bar code

Font Attributes - You maintain font attributes on the Font tab of a character format. Using the combo boxes Font Type, Font Size, and Font Style, choose a font type from the SAP standard. Bar Codes Barcodes can be read automatically by scanners. You maintain bar codes in transaction SE73. There, you can differentiate between system bar codes and printer bar codes. Creating character formats:

1. In change mode of the Smart Style, choose the Character Formats node and then

2. In the Character Format field, enter a two-character character key.

3. Select the desired attributes on the individual tab pages. 4. Choose Activate.

NACE Transaction This transaction is used to link the driver program, form routine and the copied zform (Smart Form).


Select the application for the form for e.g.: EF for purchase order and click on output types. Choose the output type (NEU for purchase order), double-click on processing routines, click on change mode and replace the form name with the zform name. Click on Save. ME9F Transaction (for Purchase Order) In this transaction, enter the document number (PO number) and click on execute. Check the checkbox and click on display message. The form is displayed.

PERFORMANCE TUNING RUNTIME ANALYSIS The runtime analysis is an additional development workbench tool that is quite useful for analyzing performance of an ABAP/4 program or transaction. With this tool, the system can display information about the following.

Executed instruction. Accessed execution time. Tables and types of access. Chronological execution flow.


The runtime analysis tool creates lists that reveal expensive statements, summarize table accesses. Runtime analysis is specifically designed for tuning individual programs and transactions. The Runtime analysis tool measures ABAP/4 statements that are potentially expensive in terms of CPU time. The most significant of these are: Statement used for database access like select. Statement used for Modularization like module, perform, call function. Internal table statements like append, collect. Starting Runtime Analysis

From ABAP/4 development workbench select Test Runtime Analysis. From ABAP/4 editor, select utilities more utilities Runtime Analysis. From ABAP/ source code screen, select Execute Runtime Analysis. From R3 screen, select System Utilities Runtime Analysis. Entering Transaction code SE30 in the command field.

Following screen is the initial screen for SE30 transaction

On the initial screen, select the needed object you want to analyze i.e. program or transaction. Enter the name of the object. Click on execute. The system will execute the specified object and will generate a trace file or performance data file, which can then be analyzed when the transaction or program has finished. Analyzing a performance data file These files are created at operating system level and many times occupy large memory space, so be sure to remove the files, which are no longer needed. To analyze the files, Click on Analysis. Following screen is displayed From GOTO option you can get overview of runtime analysis. The options are as follows:


Hit List displays a list with the most system expensive instructions. Tables - displays the most important tables, the number of accesses and the time needed for the accesses. Group hit list-displays a list with the performed instructions classified by instruction type. Call hierarchy-Presents a chronological listing with the flow of calls during the execution of the program. During Runtime Analysis, the system measures the statements and stores these measurements in a performance data file. If you measure the same program or transaction several time, the data can vary. Many factors make it difficult to reproduce identical result eg. Network traffic. When you evaluate this file, the system then displays the overview Runtime Analysis Evaluation screen including a bar chart for total execution time. From this screen you can analyze several types of information like: Hit list displays the list with the most system-expensive instructions. Tables displays the most important tables, the number of accesses, and the time needed for the accesses. Group hit list displays a list of performed instruction classified by its type. Call hierarchy presents a chronological listing with the flow of calls during the execution of program. SQL Trace About SQL Trace The SQL trace is a tool, which allows for displaying and analyzing the contents for the database calls, which are made by the reports and transactions written in ABAP/4. It monitors programs and transactions on the database level. Using this facility for every open SQL instructions, you can display which SQL Embedded (DECLARE, OPEN, FETCH) statement have been executed. And analyze the system performance. Steps to Creation To create SQL trace perform following steps: From R3 screen, select system Utilities SQL trace. Or Enter transaction STO5. Click the trace on button. Enter the user name whose programs are going to be traced. Execute the program or transaction you want to trace. Return to SQL trace initial screen and press the button SQL trace off. This switching off is necessary because if it is not done then SQL trace will trace each and every program executed by that particular user. And is quite expensive in terms of memory and time of the system. Analyzing the Trace File To analyze the created trace, press the button list trace. Using this file you can see exactly how the system handles the database requests. The first screen of the SQL trace data file displays each measured data base requests the application made. The trace file records when the request occurred and its duration. To display dictionary definition information about the table field, position the cursor on the table field and click on the DDIC info button. When this button is clicked system information like object name, table class, whether buffering is allowed or not i.e. information related to dictionary.


Explain SQL This button provides the functionality, which includes the utility for providing detailed information about the SQL operation Strategy followed by the underlying database system. For this you need to click on Explain SQL button. The system displays the execution plan for SQL statements. Here you can display the actual SQL statement like select, which fields are being accessed, Table being accessed, all where conditions. ABAP/4 Display Gives you the actual ABAP/4 code. More information gives the detailed information for time, select statement, client, number of records selected etc. Replace variable will display the SQL statement with another variables. VIEWS About Views A view is an aggregated dictionary object. Aggregate object or complex objects are objects, which are created by using basic object e.g. Table is created using data element and domain, a view is created using tables. A view is nothing but an imaginary table or virtual table. A view can be created by using one or more tables. Physically view does not contain any data. the view is filled dynamically during runtime. View is mainly used to restrict or limit the access to information or data by employees, area plant and so on. By using view, you can display only that information which is meaningful to particular user or to their work or the information for which they have access right. Types of Views R/3 system offers following types of views: Database view you can create this view on transparent table. It supports all the three operational operators: Selection, in this you select records, which matches with particular condition. Projection, in this you select few fields. Join in this type of retrieval you retrieve records by joining two tables. Projection view this type allows you to suppress some fields from the transparent table. This view is defined only with relational operator projection. Help view these views are exclusively used by the SAP help system. All relational operators are supported. These views are generated when the user presses F4 function key on the field on selection screen. You can see these views only with SAP help and not with open SQL statements. Maintenance view this type of view enables the maintenance of a group of related tables using SM30 transaction which is for extended table maintenance.

Created view From initial screen of data dictionary, enter the name of object i.e. view. Select View radio button and click on the push button. Dialog box is displayed for types of views.


Select the view type. On the next screen you have to pass following parameters. Short text In the Table box you need to enter the table names which are to be related. In join table box you need to join the two tables. Click on the TABFIELD. System displays the dialog box for all the table fields and user can select the fields from this screen. These fields are displayed in the view fields box. Save and Activate. When the view is activated, view is automatically created in the underlying database system. As long as the table exists in the data base the view also exists (Unless you delete it).

WORK BENCH ORGANIZER & TRANSPORT SYSTEM About system in SAP SAP recommends three types of systems for implementation purpose Development System Test System Production System Though number of systems used by an organization depends upon many factors such as size of implementation, budget etc.,. However even in the smallest installation a second system is must. Development system Development System is the system where the actual development takes place. Normally the development is carried out for objects and these objects are original for these systems. Test system Is also known as quality assurance system and are used to test the objects. You test you objects on development system also, but on the test system the object is tested against real data. When the tests are validated the development objects are transported to the production system. Production System The Production system is where the end user enters real business data and where the actual business runs. No development takes place in this system. You need to transfer the objects from test system to production system. The overall flow of objects can be understood by following diagram:





Developer creates the objects in the development system, these objects are transported to the Test system to test them against the real data and when validated, these objects are transported to the Production system. To transport these objects from one system to another, ABAP/4 development workbench provides the tool called Workbench organizer, which is also used to manage activities that are important in the overall development environment. Example of these activities are: The management and control of new development requests, Modification of objects, Version management. In a distributed environment work bench Organizer transports the development object between different SAP System. In the following example the objects are transported from the development system to production system. e.g. between development and production system.

Type Users:
Developers, Consultant.

Productive System End Users

Develop System, New Development Workbench Organizer

Cannot do any development

The most puzzling topic of R3 system is intended to help functions for system development.

Concepts of workbench Development objects records and controls changes to existing development objects as well as new

Workbench objects.

A development object is nothing but any object created in R/3 system. Dictionary objects: Tables ,Domains, Match code objects, Data Elements. Programs, screens, function modules

The workbench is fully integrated into the ABAP/4 development workbench. Development Classes


A Development class classifies the objects belonging to the same development project. When a user creates a object in R/3 system, the object needs to be stored in particular development class. The development class are objects themselves. In R/3 system you can store objects. In local object i.e. object is stored in $tmp class and cannot be transported from one system to another. User can assign his own development class and can be transported.

Transport system: Within R/3 system Developers are in charge of creating or correcting data objects and will create change request, which can be for individual object, or common request for a project. When the change request is released the system performs the transport. R/3 administrator is the person who sets up the transport system. This group works both at the R/3 application level and at the operating system level using transport control (tp) program.

Change Request A Change request is a list in the system, which mainly contains the object to be transported. It also contains the transport type, the request category and the target system. When the change request is created either manually or automatically, the system assigns a number to it automatically and this number is known as change request number. The format of this number is normally <SID>K<Number> eg. DD1K<900002> where DD1 is system identification number(SID) K is keyword The number is automatically generated by system and starts with 900001. The change request records all modifications made to development object. When the changes have been made and the change task (will be discussed) have been released, the change request can be released.

SE09 transaction Or Tools ABAP/4 W.B overview W.B organizer

Will display and check all the change request. Tasks


A Task in the workbench organizer is an activity in which user either creates an object or modifies the same. In workbench organizer, task can be either development or repair task. A task is related to single user while change request contains tasks belonging to different users. You cannot transport task as such, but as a part of request. Each task is associated with task number, which is similar to change request number. Usually when a development work starts a system administrator or project manager crates a change request to define tasks for all users involved in the project. The user starts modifying objects or creating new object. Once user finishes his task, they must release them. Only when all tasks under the same change request are released a change request can be released for transporting. Objects included in task become locked against other development work on the same object. Version Management ABAP/4 workbench and the organizer provide a version management for all the objects in the system. With version management user can compare current version object and object with previous version. To display the version for a object, Locate your object through the change request number of workbench organizer. Click on the object and from menu. (or) Utilities display version.

It displays what has been modified and who did it. Version management is important for developers also as it allows user to compare previous programs with the current one. Transport A Transport the process of moving something from one place to another. In R/3 system this something means change request. To transport the objects you need to create the change request and can be done by using workbench organizer. Transport system and workbench organizer are closely linked to each other.

A object original is a development object that has been created in the system in which you are working. DD1 Zsus001 (Development system) Zsus001 (Production system) PP1


Suppose you transport object ZSUS001 to another system then ZSUS001 is object original for system DD1. If anyone tries to modify the program, he will be making repair to it, provided he has the access key for the same. R/3 system offers this security measure to ensure that development object remain consistent for all system, thus preventing parallel work on the same objects. Correction of objects and development of objects can be only in original system. The difference between Repair and Correction is as follows: If you modify an object in a system in which it is created, then you are making Correction to it. If you modify an object in a system in which it was not created then you are making Repair task.

Releasing Tasks and Request When new development or correction is complete, developer must release their task and request. To release a task Find a task from the workbench initial screen Position the cursor over the task Click on the release button.

A request is released by either system Administrator or Project managers. Once all the tasks are released.