ABAP Report ProgrammingSAP-ABAP supports two types of Programs -  Report Programs & Dialog Programs. Report Programs are used when large amounts of data needs to be displayed

Purpose/Use of Report Programs

They are used  when data from a number of tables have to be selected and processed before presenting

Used when reports demand  a special format Used when the report has to be downloaded from SAP to an

Excel sheet to be distributed across. Used when the report has to be mailed to a particular person.Important Points to Note About Report Program

Report Programs are always Executable Programs. Program Type is always 1.

Every Report program corresponds to a particular Application Type i.e. either with Sales & Distribution, FI - CO etc. It can also be Cross Application i.e. type '*'.

Report Programming is an Event-driven programming. The first line of a report program is always Report <report-

name>. In order to suppress the list heading or the name of the

program the addition No Standard Page Headingis used. The line size for a particular report can be set by using the

addition line-size <size>. The line count for a particular page can be set by using the

addition line-count n(n1). N is the number of lines for the page and N1 is the number of lines reserved for the page footer.

To display any information or error message we add a message class to the program using the addition:Message-id <message class name>. Message classes are maintained in SE91.

Therefore an ideal report program should start with:

1 Report <report name> no standard page heading

2

3

4

5

6

7

 

line-size <size>

 

line-count <n(n1)>

 

message-id <message class>.

Selection Screen"Selection screen"  is the screen where one specifies the input values for which the program should run.

The selection screen is normally generated from the

1. Parameters2. Select-Options

Syntax

1

2

3

4

5

6

Selection-screen begin of screen <screen #>

selection-screen begin of block <#>  with frame title <text>

.........

.........

selection-screen end of block <#>

selection-screen end of screen <screen #>

Parameters

Parameters helps one to do dynamic selection. They can accommodate only one value for one cycle of execution of the program.

Syntax

Defining parameters as a data type

1 Parameters p_id(30) type c.

Defining parameters like a table field.

1 Parameter p_id like <table name>-<field name>.

Parameters can be Checkboxes as well as Radiobuttons.

1

2

Parameters p_id as checkbox.Parameters p_id1 radiobutton group <group name>.

Parameters p_id2  radiobutton group <group name>.

Parameters can be listbox.

1 Parameter p_id like <table name>-<field name> as listbox

Select Options

A Select-Option is used to input a range of values or a set of values to a program

Syntax

1 select-options s_vbeln for vbak-vbeln.

You can also define a select option like a variable

Events in an ABAP Report ProgramABAP report programs are event driven programs. The different events in a report Program are:

Load-of-program

Triggers the associated event in an internal session after loading a program of type 1, M, F, or S.

Also runs the associated processing block once and once only for each program and internal session.

The processing block LOAD-OF-PROGRAM has roughly the same function for an ABAP program of type 1, M, F or S as a constructor has for classes in ABAP Objects

Initialization.

This event is executed before the selection screen is displayed .

Initialization of all the values. You can assign different values other than the values defaulted

on the selection screen . You can fill your selection screen with some values at runtime.At Selection-Screen.

The event is processed when the selection screen has been processed (at the end of PAI ).

Validation & Checks of inputted values happen hereStart-of-Selection.

Here the program starts selecting values from tables.End-of-selection.

After all the data has been selected this event writes the data to the screen.

Interactive Events

Used for interactive reporting. It is used to create a detailed list from a basic list.

Formatting the reportABAP allows the reports to be formatted as the user wants it to be. For example, "Alternate Lines" must appear in different colors and the "Totals" line should appear in Yellow.

Syntax

123

Format Color n Format Color n Intensified On

n may correspond to various numbers

Please note that there are other additions along with format as well

1 FORMAT COLOR OFF INTENSIFIED OFF INVERSE OFF HOTSPOT OFF INPUT OFF

Interactive Programming Using Interactive Programming users  can actively control the

data retrieval and display of data Used to  create a detailed list from a very basic list The detailed data is written on a secondary list. The secondary list may either completely overlay the first

screen or one can display it in a new screen The secondary lists can be themselves interactive. The first list may also call a transaction. There are different events associated with interactive

programming.Some commands used for interactive programmingHotspotIf one drags the mouse over the data displayed in the repor the cursor changes to a Hand with an Outstretched Index finger. An hotspot can be achieved using the FORMAT statement.

1 Syntax:      Format Hotspot On (Off).

HideThis command helps you to store the field names based on which one will be doing further processing to get a detailed list. It is written directly after the WRITE statement for a field. When a row is selected the values get automatically filled in the variables for further use.

1 Syntax:     Hide <field-name>.

Logical Databases Instead of using "Select" queries you can use logical database

to retrieve data for a program. Logical databases are created by transaction SE36 The name of a logical database can be up to 20 characters

long. It may begin with a namespace prefix. The data is selected by another program and one can access

the data using GET <table-name> command which places the data in the work area <table-name>.

Advantages of a logical database over normal Select queries.

1. It offers check conditions to see whether the input is correct, complete and plausible

2. It contains central authorization checks for database access

3. Enhancements such as improvement in performance immediately apply to all reports which use logical database.

 Note: Due to the complexities involved, logical databases are not used in most of the cases

Dialog ProgrammingSAP-ABAP supports two types of programs - Report Program and Dialog Program.

If your ABAP program demands user input , Dialog programming is used.

A  user dialog is any form of interaction between the user and the program and could be any of the following

Entering data Choosing a menu item Clicking a button Clicking or double clicking an entryDialog program is also used when we need to navigate back and forth between screens

Dialog programs are created with type as 'M' - Module Pool. They cannot be executed independently and must be attached to at least one transaction code in which you specify an initial screen.

Difference between Report and Dialog Programs

Report Program:

A report is a program that typically reads and analyzes data in database tables without changing the database.

Dialog Program:

A dialog program allows you to work interactively with the system and to change the contents of the database tables. Each dialog program has a certain sequence of screens that are processed by the system one after the other.

A Sample transaction processing in Dialog Programming

Components of Dialog ProgramUnlike report which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects none of which can be executed on it's own. Instead all objects are linked hierarchically to the main program and and are executed in a sequence dictated by the Dialog Main Program.

The components of a dialog program are:

Transaction code

The transaction code starts a screen sequence. You create transaction codes in the Repository Browser in the

ABAP Workbench or using Transaction SE93. A transaction code is linked to an ABAP program and an initial

screen. You can start a screen sequence from any ABAP program using

the CALL SCREEN statement.Screens

Each dialog in an SAP system is controlled by one or more screens.

You create screens using the Screen Painter in the ABAP Workbench through transaction SE51

Each screen belongs to an ABAP program. These screens consist of a "screen mask" or "layout" and its

flow logic. The screen has a layout that determines the positions of input/output fields and other graphical elements such as checkboxes and radio buttons. A flow logic determines the logical processing within screen.

GUI status

Each screen has a GUI status(es) which are independent components of a program.

This controls the menu bars, standard toolbar, application toolbar , with which the user can choose functions in the application.

You create them in the ABAP Workbench using the Menu Painter.

ABAP Program

Each screen and GUI status in the R/3 System belongs to one ABAP program.

The ABAP program contains the dialog modules that are called by the screen flow logic, and also process the user input from the GUI status.

ABAP programs that use screens are also known as dialog programs.

In a module pool (type M program); the first processing block to be called is always a dialog module. However, you can also use screens in other ABAP programs, such as executable programs or function modules. The first processing block is then called differently; for example, by the runtime environment or a procedure call. The screen sequence is then started using the CALL SCREEN statement.

Screen Flow Logic

Screen Flow logic is primarily divided into four components.

Process Before Output (PBO) event: which is processed before the screen is displayed

Process After Input (PAI) event: which is processed after a user action on the screen

Process on help request (POH): which is processed when F1 is pressed

Process on value request (POV):which is processed when F4 is pressed

Dynpro

A screen together with its Flow logic  is called a Dynpro ("Dynamic Program" since the screen flow logic influences the program flow)

Each dynpro controls exactly one step of your Dialog Program. The screens belonging to a program are numbered. The 

screen flow sequence can be either linear or cyclic. From within a screen chain, you can even call another screen chain and, after processing it, return to the original chain. You can also override the statically-defined next screen from within the dialog modules of the ABAP program.

ABAP Module Pool

On a PBO or PAI event a Dynpro calls an ABAP dialog program.  Collection of such programs is called the ABAP module pool.

For example modules called at the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.

All dynpros to be called from within one transaction refer to a common module pool.

Structure of a Dialog Program

Process Flow for a Dialog Program

SubscreensSubscreens A subscreen is an independent screen that is displayed in an

area of another ("main") screen. Subscreens allow you to embed one screen within another at

runtime. You can include multiple sub-screens on main screen. The term subscreen applies both to the screen that you

embed, and the area on the main screen in which you place it. This tutorial is about subscreen areas. The actual screens created through SE51 transaction, are called subscreen screens if defined in screen attributes.

When you use a subscreen, the flow logic of the embedded screen is also embedded in the flow logic of the main screen.Hence, Using subscreens on screens is like using includes in ABAP programs.

To use a subscreen, you must follow three simple steps

1. Define the subscreen area(s) on a screen2. Define suitable subscreen screens

3. Include the subscreen screen in the subscreen area.

Also, you need to adjust the frame of sub-screen and main screen. You need to name it in the field name field.

Further, you also need to adjust the fields within the subscreen to make them appear in main screen. In case the sub-screen is defined to be larger than the available area in the main screen, only the part of subscreen will be visible that fits in the the area available. The area is always measured from the top left corner of screen. Hence you should take adequate care while defining sub-screen areas and creating sub-screens.

EXAMPLE

For instance here we have defined two sub-screen areas on main screen and have attached two different Sub-screen to corresponding areas. Whenever main screen is called, the PBO of main screen is

called. But before display, the PBO's of each screen attached with sub-screen areas on main screen are also called.

You can include a subscreen screen using the CALL SUBSCREEN statement in the flow logic of the main screen.

To include a subscreen screen in the subscreen area of the main screen and call its PBO flow logic, use the following statement in the PBO event of the main screen:

12345

PROCESS BEFORE OUTPUT.   CALL SUBSCREEN <area> <span style="list-style: none; float: none; cursor: pointer !important; color: rgb(0, 153, 0) !important; position: relative !important; font-size: inherit !important; vertical-align: inherit !important; display: inline !important; text-align: left !important; margin: 0px !important; border-style: none none solid !important; border-color: initial !important; border-bottom-width: 1px !important; padding: 0px 0px 0.065em !important; text-decoration: underline !important; line-height: 20px;" class="intexthighlight" phasehl="km:en" id="JtIdp" title="">INCLUDING</span> [<prog>] <dynp>.

This statement assigns the subscreen screen with number <dynp> to the subscreen area called <area>. You can also specify the program in which the subscreen screen is defined (optional). If you do not specify the program explicitly, the system looks for the subscreen screen in the same ABAP program as the main program. If it does not find a corresponding subscreen screen, a runtime error occurs. The PBO flow logic of the subscreen screen is also included at the same point. This can call PBO modules of the ABAP program in which the subscreen screen is defined. At the end of the subscreen PBO, the global fields from the program are passed to any identically-named screen fields in the subscreen screen. The PBO flow logic of the subscreen screen can itself include further subscreens.

The name <area> of the subscreen area must be entered directly without inverted commas. You can specify the names <prog> and <dynp> either as literals or variables. If you use variables, you must declare and fill identically-named variables in the ABAP program. The screen number <dynp> must be 4 characters long. If you do not assign a subscreen screen to an area, it remains empty.

To call the PAI flow logic of the subscreen screen, use the following statement in the PAI flow logic of the main screen:

12345

PROCESS AFTER INPUT.   CALL SUBSCREEN <area>.

This statement includes the PAI flow logic of the subscreen screen included in the subscreen area <area> in the PBO event. This can call PAI modules of the ABAP program in which the subscreen screen is defined. Data is transported between identically-named fields in the subscreen screen and the ABAP program either when the PAI event is triggered, or at the corresponding FIELD statements in the PAI flow logic of the subscreen screen.

Points to Remember

Names of elements of sub-screens within a screen should be unique

You should not have OK_CODE or FCODE attached with sub-screen. The OK_CODE of main screen itself is OK_CODE of sub-screen

Sub-screens cannot have any dialog modules containing SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN or LEAVE TO SCREEN. This will cause runtime error.

You need to call it in the flow logic (both PBO and PAI) of the main screen.

CALL SUBSCREEN is not allowed in CHAIN..ENDCHAIN and LOOP ENDLOOP statements

Can not have an AT EXIT-COMMAND module The fields that you use are the global fields. They must be

declared in the top include If using subscreens from another dialog program the data

transfer will not happen unless you add specific code.

Process On Value and Process On Help- Screen Flow logic and their uses in SAP

Process on Help-Request (POH) : F1 Help Whenever F1 is pressed the POH event  for the specified data

element  is executed. If the PROCESS ON HELP-REQUEST event does not exist in the

process logic of a screen, the documentation of the field in the ABAP Dictionary is taken as a basis and displayed.  Even if that does not exit no help is displayed.

To display field help documentation, you must code the following screen flow logic in the POH event:

12

PROCESS ON HELP-REQUESTFIELD &lt;f&gt; [MODULE &lt;mod&gt;] WITH &lt;num&gt;

If there is screen-specific data element documentation for the field <f>, you can display it by specifying its number <num>.

The number <num> can be a literal or a variable. The variable must be declared and filled in the corresponding ABAP program.

Note, the FIELD statement does not transfer the contents of the screen field <f> to the ABAP program in the PROCESS ON HELP-REQUEST event. It just shows help documentation. That's it.

The module <mod> is defined in the ABAP program like a normal PAI module. The processing logic of the module must ensure that adequate help is displayed for the field in question. Instead of calling an extra screen with text fields, you should use one of the following function modules to display a suitable SAPscript documentHELP_OBJECT_SHOW_FOR_FIELD

This function module displays the data element documentation for components of any structure or database table from the ABAP Dictionary.

You pass the name of the component and structure or table to the import parameters FIELD and TABLE.

HELP_OBJECT_SHOW

Use this function module to display any SAPscript document. You must pass the document class (for example, TX for general

texts, DE for data element documentation) and the name of the document to the import parameters DOKCLASS and DOKNAME.

For technical reasons, you must also pass an empty internal table with the line type TLINE to the tables parameter of the function module.

Process on Value (POV): F4 When the user chooses the function Possible entries (F4), the

system displays the possible input values for a field (values, check table, matchcode), provided they were stored by the developer.

The event PROCESS ON VALUE-REQUEST is always processed if the user has called "Possible entries".

To define Possible values for a field on screen, you need to defined following in POV event of screen flow logic:

123

PROCESS ON VALUE-REQUEST FIELD <em>field name</em> MODULE <em>module name</em>

For Possible values, within module defined above, you should use the general function moduleHELP_VALUES_GET_WITH_TABLE to get possible values from ABAP Dictionary.

There are some other functions that can also be used for input help :

F4IF_FIELD_VALUE_REQUEST

Calls the input help of the ABAP Dictionary dynamically. You can pass the component names of a structure or

database table of the ABAP Dictionary to the function module in the import parameters TABNAME and FIELDNAME.

The function module starts the ABAP Dictionary input help for this component.All of the relevant screen fields are read.

If you specify the import parameters DYNPPROG, DYNPNR, and DYNPROFIELD, the user's selection is returned to the corresponding field on the screen.

If you specify the table parameter RETURN_TAB, the selection is returned into the table instead.

1234567891011121314151617

MODULE VALUE_CARRIER INPUT. CALL FUNCTION 'F4IF_FIELD_VALUE_REQUEST' EXPORTING TABNAME         = 'DEMOF4HELP' FIELDNAME     = 'CARRIER1' DYNPPROG       =  PROGNAME DYNPNR            =  DYNNUM DYNPROFIELD= 'CARRIER'. ENDMODULE.

F4IF_INT_TABLE_VALUE_REQUEST This function module displays a value list that you created in

an ABAP program. The value list is passed to the function module as

the table parameter VALUE_TAB. If you specify the import parameters DYNPPROG, DYNPNR, and

DYNPROFIELD, the user's selection is returned to the corresponding field on the screen.

If you specify the table parameter RETURN_TAB, the selection is returned into the table instead.

123456789

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'EXPORTING<p>RETFIELD         =  'CONNID'DYNPPROG         =  PROGNAMEDYNPNR           =  DYNNUMDYNPROFIELD      =  'CONNECTION'VALUE_ORG        = 'S'TABLESVALUE_TAB        = VALUES_TAB.</p>

ALV - ABAP List Viewer ProgrammingThe common desired  features of any  report are "column alignment", sorting, filtering, subtotals, totals etc. To implement these from scratch , a lot of coding effort  is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).

Using ALV, we can have three types of reports:

1. Simple Report2. Block Report

3. Hierarchical Sequential Report

Each of these reports provide function modules which help in producing desired output without much effort. Let’s look at them in detail -

Simple ReportImportant function modules in these report are -

Reuse_alv_fieldcatalog_merge Reuse_alv_list_display Reuse_alv_events_get Reuse_alv_grid_display Reuse_alv_commentary_writeREUSE_ALV_FIELDCATALOG_MERGE

This function module is used to populate a field catalog which is essential to display the data in ALV.

If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter (I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.

Note : Fieldcatalog can be filled manually also by filling up all the required details into the internal table

Important parameters in are:

1. Export:

I_program_name : report id I_internal_tabname : the internal output table I_inclname : include or the report name where all the dynamic

forms are handled.2. Changing

ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in the type pool SLIS.

REUSE_ALV_LIST_DISPLAY

This is the function module which prints the data.

The important parameters are:

1. Export:

I_callback_program : report id I_bypassing_buffer : 'X' I_buffer_active : ' ' I_callback_pf_status_set : routine where a user can set his own

pf status or change the functionality of the existing pf status. I_callback_user_command : routine where the function codes

are handled. I_structure name : name of the dictionary table Is_Layout : structure to set the layout of the report It_fieldcat : internal table with the list of all fields and their

attributes which are to be printed (this table can be populated automatically by the function)

It_events : internal table with a list of all possible events of ALV and their corresponding form names.

2. Tables:

a. t_outtab : internal table with the data to be output

REUSE_ALV_EVENTS_GET:

Returns table of possible events for a a list type

1. Import:

Et_Events :The event table is returned with all possible CALLBACK events for the specified list type (column 'NAME'). For events to be processed by the Callback, their 'FORM' field must be filled. If the field is initialized, the event is ignored. The entry can be read from the event table, the field 'FORM' filled and the entry modified using constants from the type pool SLIS.

2. Export:

I_list_type: 0 = simple list REUSE_ALV_LIST_DISPLAY

1 = hierarchical-sequential list  REUSE_ALV_HIERSEQ_LIST_DISPLAY

2 = simple block list REUSE_ALV_BLOCK_LIST_APPEND

3 = hierarchical-sequential block list   REUSE_ALV_BLOCK_LIST_HS_APPEND

REUSE_ALV_GRID_DISPLAY

A new function from ABAP4.6 version, to display the results in grid rather than a preview.

Parameters : same as reuse_alv_list_display

 Note:Grid cannot handle high volumes. Functions like sort, scrolling down consumes a lot of resources / time if the volume of data to be displayed is high. There is no clear cut definition such that if the amount of data is X go for list or grid  but the developer has to take a call based on his experience. If not sure, then list is the better option

REUSE_ALV_COMMENTARY_WRITE

This is used in the Top-of-page event to print the headings and other comments for the list.

Important Parameters

It_list_commentary : Internal table with the headings of the type slis_t_listheader.

This internal table has three fields:

1. Typ : 'H' - header, 'S' - selection, 'A' - action2. Key : only when typ is 'S'.

3. Info : the text to be printed

Block ReportThis looks like a simple report but this report has the features of sorting and filtering only.This report is used if you have to display more than one report on the output. Technically speaking if you have multiple internal table with data to be displayed as separate blocks then we go for block report of ALV.

The important functions used for creating this report are:

REUSE_ALV_BLOCK_LIST_INIT REUSE_ALV_BLOCK_LIST_APPEND REUSE_ALV_BLOCK_LIST_DISPLAYREUSE_ALV_BLOCK_LIST_INIT

This function module is used to set the default gui status etc. The parameters are similar to the one used in reuse_alv_list_display or reuse_alv_grid_display

REUSE_ALV_BLOCK_LIST_APPEND

This function module adds the data to the block.

Important Parameters

1.Export :

is_layout : layout settings for block it_fieldcat : field catalog I_tabname : internal table name with all all possible events2.Tables :

t_outtab : internal table with output data.REUSE_ALV_BLOCK_LIST_DISPLAY

This function module display the list with data appended by the above function.

Parameters : All the parameters are optional.

Hierarchical ReportsHierarchical display is used for displaying data that are related. Like sales order and item details. Here sales order details can be the header data whereas them items in the sales order can be the item data

The function module used for this is

REUSE_ALV_HIERSEQ_LIST_DISPLAY

Export:

I_CALLBACK_PROGRAM I_CALLBACK_PF_STATUS_SET I_CALLBACK_USER_COMMAND IS_LAYOUT It_fieldcat It_events

I_tabname_header : Name of the internal table in the program containing the output data of the highest hierarchy level.

I_tabname_item : Name of the internal table in the program containing the output data of the lowest hierarchy level.

Is_keyinfo : This structure contains the header and item table field names which link the two tables (shared key).

Tables

t_outtab_header : Header table with data to be output t_outtab_item : Name of the internal table in the program

containing the output data of the lowest hierarchy level.All the definitions of internal tables, structures and constants are declared in a type-pool called SLIS. This internal table can be populated automatically by using REUSE_ALV_FIELDCATALOG_MERGE'.

Display Variants Display variants are used to set the default properties of an alv

output like sort criteria, filtering criteria, totaling and subtotaling etc

Display variants can be user specific and standard (standard variants can be used by any user )

Kind of display variants that can be saved is controlled by the parameter i_save that is passed in function modules  reuse_alv_list_display / reuse_alv_grid_display

You can provide an option on the selection screen to select what display variant to be used

The common function modules related to selecting / validating display variants are

1. Reuse_alv_variant_default_get2. Reuse_alv_variant_f4

3. Reuse_alv_variant_existence