Reporting

A report program reads and analyzes data from one or more database tables without modifying
the database. Usually, the result of such a report program is in the form of a list which is output
to the screen or sent to a printer. SAP Reports are event-driven programs using ABAP/4
programming language. These reports are used to fetch business-specific data from SAP
standard databases under specified selection criteria, fetched data is processed to display result
on output screen. User develop SAP report object on ABAP editor using the standard SAP
transaction SE38.

Types of reporting

Classical Reports

These are the simplest reports. Programmers learn this one first. It is just an output of data using
the Write statement inside a loop. Classical reports are normal reports. These reports are not having
any sub reports. IT IS HAVING ONLY ONE SCREEN/LIST FOR OUTPUT.

Interactive Reports

As the name suggests, the user can interact with the report. We can have a drill down into the
report data. For example, Column one of the report displays the material numbers, and the user
feels that he needs some more specific data about the vendor for that material, he can HIDE that
data under those material numbers. And when the user clicks the material number, another report
(actually sub report/secondary list) which displays the vendor details will be displayed. We
can have a basic list (number starts from 0) and 20 secondary lists (1 to 21).

Events in reporting

There is no mandatory event in a report program. Events are actually used to organize the
statements and control the flow of the program. If the program contains no explicitly defined
event blocks, all the statements in the program form the entire event block START-OF-
SELECTION. ABAP runtime environment automatically introduces a START-OF-SELECTION
at the first execution line.

ABAP/4 report programs are event driven programs. Following events are triggered in a report.

LOAD OF PROGRAM. - If propgram is of type 1, M, F, or S; then LOAD-OF-PROGRAM is

triggered first and then INITIALIZATION. The purpose of load of program is to load the
program into system memory so that the program can be executed.

INITIALIZATION. - just once.

AT SELECTION-SCREEN OUTPUT. - when there is selection-screen

AT SELECTION-SCREEN. - when user interacts.

START-OF-SELECTION. - when F8.This is the default event in ABAP.

END-OF-SELECTION. - At the end

EVENTS IN A CLASSICAL REPORT:

1. INITIALIZATION: This is triggered when the report is loaded in memory.

2. AT SELECTION-SCREEN OUTPUT: This is triggered when the selection screen is loaded in

memory before being displayed.

3. AT SELECTION-SCREEN/<field> : This event is triggered before leaving the selection

screen.

4. START-OF-SELECTION: This is the first and default event for displaying the report. Data
retrieval logic is written under this event.

OUTPUT EVENT(5, 6):

5. TOP-OF-PAGE: This event is triggered every time a new page is started in the list.

6. END-OF-PAGE : This event is triggered every time the list data reaches the footer region of
the page.

7. END-OF-SELECTION: This event is triggered after the START-OF-SELECTION is

completed.
This event is used when there is use of logical data base in the report. It is triggered in type 1
programs once the logical database completes reading all data i.e. all the selection is finished and
before the list processor is started. This statement tells the server that all the database reading is
completed and no more data reading is going to take place. END-OF-SELECTION is generally
used for the summary/results of reports. In an executable program without logical data base,
there is no need to implement the event block END-OF-SELECTION.
After a program is executed by the user, the database is locked when it encounters a START-OF-
SELECTION statement and the lock is released when an END-OF-SELECTION statement is
encountered (to maintain the consistency). Data selection is done between START-OF-
SELECTION and END-OF-SELECTION. Now if we don’t write the END-OF-SELECTION
statement, the database will remain locked till the programs get terminated. Hence, the
performance will be reduced. So it is always good practice to write END-OF-SELECTION
statement after finishing the data selection from database.

EVENTS IN AN INTERACTIVE REPORT:

In addition of the above, the following events are possible in case of Interactive Reports.

1. Top of page during line selection: top of page event for secondary list.

2. At line-selection: every time user double-clicks(F2) on the list data.

3. At pF<key> : function key from F5 to F12 to perform interactive action on the list.

4. At user-command.

Finally I want to include one point:

If you debug your report program from the Abap editor screen then it triggers from
1.Initialization,
2.At Selection-screen,
3.Start-of Selection,
4.End-of Selection,
5.Top-of-page,
6.End-of-page.

But if you debug from the selection-screen then it triggers from

1.At Selection-Screen,
2.Start-of-selection,
3.Top-of-page,
4.End-of-page.

***********************************Reporting over******************************

BDC (batch data communication)

The SAP system offers two primary methods (BDC SESSION METHOD, CALL
TRANSACTION METHOD) for transferring data into the system from other systems and Non-
SAP systems.  These two methods are collectively called as ‘BATCH INPUT’ or ‘Batch Data
Communication’ (BDC).BDC is used to enter the data from flat files into the SAP system. It
helps to transfer data from the legacy system where data is in some other form as in the SAP
System. The legacy data can be uploaded in the form of text file or in the form of MS-EXCEL.
BDC is used in SAP implementation projects where data transfer/switching of technology is
needed.

Where do you use BDC?

Transferring data from another system when you install your SAP System regularly transferring
data that is captured by a non-SAP system in your company into the SAP System. Assume, for
example, that data collection in some areas of your company is still performed by a non-SAP
system.  You can still consolidate all of your data in the SAP System by exporting the data from
the other system and reading it into the SAP System with batch input. You can also use batch
input to transfer data between two R/3 Systems.  However, there are more direct methods for
doing this, such as RFC (remote function calls).

1) BATCH INPUT CONCEPTS:

The SAP System offers two primary methods for transferring data into the System from
other SAP Systems and non-SAP Systems. These two methods are collectively called
"batch input" or "batch data communication."
The batch input technique offers these advantages for transferring data:

No manual interaction is required during data transfer. If the data to be transferred is

already available in electronic form (on a tape, for example), then you can enter the data
automatically into the SAP System using batch input.

Batch input ensures data integrity. Batch input enters data into the SAP System using the
same transactions that interactive users do. Batch input data is therefore submitted to all
of the checks and controls that apply to data entered by normal interactive means.

The batch input methods.

There are several ways to process batch input data in the SAP System.
Batch input processing methods.

The first processing method could be called "classical batch input." In it, an ABAP/4
program reads the external data that is to be entered in the SAP System and stores the
data in a "batch-input session." A session stores the actions that are required to enter
your data using normal SAP transactions. 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 with the batch-input management function (System
--> Services --> Batch input) or have the session run in the background processing
system.
This method uses the function modules BDC_OPEN, BDC_INSERT, and
BDC_CLOSE to generate sessions.

In the second method, your program uses the ABAP/4 CALL TRANSACTION
USING statement to run an SAP transaction. Batch-input data does not have to be
deposited in a session for later processing. Instead, the entire batch-input process takes
place inline in your program.

There is a third batch-input method using the ABAP/4 CALL DIALOG statement.
However, SAP recommends against using this method unless necessary. The CALL
DIALOG method is now outdated and is more complex and less comfortable to use than
the other techniques.
All three batch-input methods use a common data structure for holding the instructions
and data for SAP transactions. This structure is defined as structure BDCDATA in the
ABAP/4 Dictionary.

Uses of batch input include the following:

1. transferring data from another system when you install your SAP System
regularly transferring data that is captured by a non-SAP system in your company into the
SAP System. Assume, for example, that data collection in some areas of your company is
still performed by a non-SAP system. You can still consolidate all of your data in the
SAP System by exporting the data from the other system and reading it into the SAP
 System with batch input.

2. You can also use batch input to transfer data between two R/3 Systems. However,
there are more direct methods for doing this, such as RFC (remote function calls).

Application support for batch-input.

3. The SAP applications provide pre-programmed support for batch input transfers
for many of SAP's business objects.
To implement one of the supported data transfers, you must often write the program that
exports the data from your 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.
Should you wish to write a transfer program that executes outside the SAP System, then
the SAP applications provide definitions of the required data formats for the exports.
From these definitions, you can generate code for the data structures to include in your
export program. You can also write such programs in ABAP/4, which lets you take
advantage of the comfort and conveniences of the SAP Development Workbench.
Once you have exported the data, you can then use a standard, pre-programmed SAP
report to import the data. This program uses one of the batch input methods to process the
data and add it to the SAP System.

You can find information on pre-defined batch-input programs in the SAP Customizing
System. Choose Tools --> Customizing. Then display either your Enterprise IMG
(Implementation Guide) projects or the SAP standard IMG. In the project display, use the
Expand function to display all nodes in the project. You can then search for relevant
topics with the keywords batch input and transfer.

(2) TRANSFERING DATA: BATCH INPUT PROCEDURE IN OVERVIEW.

Transferring data with batch input requires the steps shown in the illustration and list
below.
Note that SAP standard batch-input programs take care of several of these steps for you.
For more information, please see BATCH INPUT CONCEPTS (1).

The procedure:

1. Analyze the data that is to be transferred to the SAP System.

Goal: Determine how your existing data should be mapped to the SAP data structure.
Method: You'll need to determine the structure of the data that is to be transferred into the
system. Using the SAP data structure that you generate in step 2, you'll need to determine
how the data to be transferred must be mapped to the SAP structure. You'll also need to
determine whether any data type or data length conversions are required.

2. Generate SAP data structures for incorporation into your data export program.
Method: Use the data structure generation function of the ABAP/4 dictionary to generate
data structures for SAP tables in any of several programming languages.
If you are using one of SAP's standard batch input programs, then use of this function is
required. The standard batch input programs generally require that you use a special pre-
defined data structure.

For more information, please see GENERATING AN SAP DATA STRUCTURE (5).

If you're writing your own batch input procedure, then you will need to determine the data
structure on your own.

3. Code your data transfer program. You can write the program in ABAP/4 or as an external
program.

4. Export the data that is to be transferred to a sequential file.

Requirements:

The file must use the logical format required by the batch-input program that will import the
file (step 6).

Reading and interpreting the file is much easier if you write it in ASCII or EBCDIC
(character) format rather than, for example, writing numeric data in hexadecimal format.

Character format is required by the pre-defined SAP batch input programs.

5. If necessary, code the ABAP/4 batch input program that will read in the data to be
transferred from your file.

SAP supplies ready-to-run batch-input programs for most of the SAP applications.

For more information on writing your own program, see WRITING A BATCH INPUT
PROGRAM : PROCEDURE IN OVERVIEW(10).

6. Process the data and add it to the SAP System. You can do this either by:

GENERATING A BATCH-INPUT SESSION(A) ; or

by processing data directly in your batch-input program with the ABAP/4 statement
CALL TRANSACTION USING (19).

7. Check that all data has been successfully processed.

Method: Analyze the batch input processing log. If you are using CALL TRANSACTION
USING, then you will need to analyze the processing messages collected by your program.
You'll find more information on running and analyzing sessions and logs in MANAGING
BATCH-INPUT SESSIONS(B).
 8. Correct and re-process erroneous data.

Method: You can use the batch-input management function to process erroneous transactions
interactively. You can correct data during this interactive processing.

A.GENERATING A BATCH-INPUT SESSION.

One of the two recommended ways to process batch input data is to store the data in a batch
input session. This session can then be run in the SAP System to enter the batch input data
into the system.

In general, preparing a session is the best and most comfortable way to process batch input
data. However, you may wish to use the alternate method, CALL TRANSACTION USING,
if your batch input sessions cannot be run quickly enough.

Creating, Filling, and Closing a Batch Input Session

To create a session, program the following procedure using the following BDC_ function
modules:

1. Open the batch input session using function module BDC_OPEN_GROUP (15) .
2. For each transaction in the session:
a. Fill the BDCDATA structure with values for all screens and fields that must be
processed in the transaction. For more information,
b. Transfer the transaction to the session with BDC_INSERT (16) .
3. Close the batch input session with BDC_CLOSE_GROUP (17).

If you want to write your own program, proceed as follows:

1. Generate the batch input session using function module BDC_OPEN_GROUP

2. The proceed as follows for each transaction that session contains:
o In the BDCDATA structure, enter the value for all screens and fields that must be
processed in the transaction.
o Use BDC_INSERT to transfer the transaction and BDCDATA structure to the session.
3. Close the batch input session with BDC_CLOSE_GROUP
4. Start to process the generated session.

BDC_OPEN_GROUP

Use the BDC_OPEN_GROUP function module to create a new session. Once you have created a
session, then you can insert batch input data into it with BDC_INSERT.

You cannot reopen a session that already exist and has been closed. If you call
BDC_OPEN_GROUP with the name of an existing session, then an additional session with the
same name is created.
A batch input program may have only one session open at a time. Before opening a session,
make sure that any sessions that program closes any sessions that it previously had opened.

BDC_OPEN_GROUP takes the following EXPORTING parameters:

 CLIENT
Client in which the session is to be processed. Default: If you don’t provide a value for this
parameter, the default is the client under which the batch input program runs when the session
is created.
 GROUP
Name of the session that is to be created. May up to 12 characters long. Default: None. You
must specify a session name.
 HOLDDATE
Lock date. The session is locked and may not be processed until after the date that you
specified. Only a system administrator with the LOCK authorization for the authorization object
Batch Input Authorizations can unlock and run a session before this date.
 KEEP
Retain session after successful processing. Set this option to the value X to have a session kept
after it has been successfully processed. A session that is kept remains in the input/output
queue until an administrator deletes it. Sessions that contain errors in transactions are kept
even if KEEP is not set. Default: If not set, then sessions that are successfully processed are
deleted. Only the batch input log is kept.
 USER
Authorizations user for background processing. This is the user name that is used for checking
authorizations if a session is started in background processing. The user must be authorized for
all of transactions and functions that are to be executed in a session. Otherwise, transactions
will be terminated with “no authorization” errors. The user can be of type dialog or background.
 Dialog users are normal interactive users in the R/3 System. Background users are user master
records that are specially defined for providing authorizations for background processing jobs.

BDC_INSERT

Use the BDC_INSERT function module to add a transaction to a batch input session. You
specify the transaction that is to be started in the call to BDC_INSERT. You must provide a
BDCDATA structure that contains all of the data required to process the transaction completely.

BDC_INSERT takes the following parameters:

 TCODE
The code of the transaction that is to be run.
 POST_LOCAL
Parameter to update data locally. If POST_LOCAL = “X”, data will be updated locally.
 DYNPROTAB
the BDCDATA structure that contains the data that is to be processed by the transaction.
DYNPROTAB is a table parameter in the function module.

BDC_CLOSE_GROUP

Use the BDC_CLOSE_GROUP function module to close a session after you have inserted all of
your batch input data into it. Once a session is closed, it can be processed.

BDC_CLOSE_GROUP needs no parameters. It automatically closes the session that is

currently open in your program. You must close a session before you can open another session
from the same program.
BDCDATA Structure

IF you want to write data to a batch input session or to process the data using CALL
TRANSACTION USING or CALL DIALOG, you must prepare an internal table <bdc_tab>.
This internal table must be structured according to ABAP Dictionary structure BDCDATA. The
internal table <bdc_tab> stores the data that is to be entered into R/3 System and the actions that
are necessary to process data. You can think of the table as storing the script that the R/3 System
is to follow in processing batch input data.

MODULARIZATION

What is Modularization and its benefits?

If the program contains the same or similar blocks of statements or it is required to process the
same function several times, we can avoid redundancy by using modularization techniques. By
modularizing the ABAP/4 programs we make them easy to read and improve their structure.
Modularized programs are also easier to maintain and to update.
How can we create callable modules of program code within one ABAP/4 Program?
A. By defining macros.

By creating include programs in the library.

What are subroutines?

Subroutines are program modules which can be called from other ABAP/4 programs or within
the same program.

What are the types of Subroutines?

Internal Subroutines: The source code of the internal subroutines will be in the same
ABAP/4 program as the calling procedure (internal call).

External Subroutines: The source code of the external subroutines will be in an ABAP/4
program other than the calling procedure.

What are the different types of parameters?

Formal parameters: Parameters which are defined during the definition of subroutine with the
FORM statement.

Actual parameters: Parameters which are specified during the call of a subroutine with the
PERFORM statement.

If the program contains the same or similar blocks of statements or it is required to process the
same function several times, we can avoid redundancy by using modularization techniques. By
modularizing the ABAP/4 programs we make them easy to read and improve their structure.
Modularized programs are also easier to maintain and to update.

How can we create callable modules of program code within one ABAP/4 Program?

A. By defining macros.
B. By creating include programs in the library.

What are subroutines?

Subroutines are program modules which can be called from other ABAP/4 programs or within
the same program.

What are the types of Subroutines?

A. Internal Subroutines: The source code of the internal subroutines will be in the same ABAP/4
program as the calling procedure (internal call).
B. External Subroutines: The source code of the external subroutines will be in an ABAP/4
program other than the calling procedure.

What are the different types of parameters?

Formal parameters: Parameters which are defined during the definition of subroutine with the
FORM statement.

Actual parameters: Parameters which are specified during the call of a subroutine with the
PERFORM statement.

How can one distinguish between different kinds of parameters?

A. Input parameters are used to pass data to subroutines.

B. Output parameters are used to pass data from subroutines.

What are the different methods of passing data?

A. Calling by reference: During a subroutine call, only the address of the actual parameter is
transferred to the formal parameters.
The formal parameter has no memory of its own, and we work with the field of the calling
program within the subroutine. If we change the formal parameter, the field contents in the
calling program also change.
B. Calling by value: During a subroutine call, the formal parameters are created as copies of the
actual parameters. The formal parameters have memory of their own. Changes to the formal
parameters have no effect on the actual parameters.
C. Calling by value and result: During a subroutine call, the formal parameters are created as
copies of the actual parameters. The formal parameters have their own memory space. Changes
to the formal parameters are copied to the actual parameters at the end of the subroutine.

The method by which internal tables are passed is By Reference.

What is the difference between the function module and a normal ABAP/4 subroutine?
In contrast to normal subroutines function modules have uniquely defined interface.
Sub routines do not return values.

Sub routines do not return exceptions.

Sub routines cannot be tested independently.
Declaring data as common parts is not possible for function modules. Function modules are
stored in a central library.

What is a function group?

A function group is a collection of logically related modules that share global data with each
other. All the modules in the group are included in the same main program. When an ABAP/4
program contains a CALL FUNCTION statement, the system loads the entire function group in
with the program code at runtime. Every function module belongs to a function group.

what is the difference between internal tables and extract datasets?

A. The lines of an internal table always have the same structure. By using extract datasets, you
can handle groups of data with different structure and get statistical figures from the grouped
data.
B. You have to define the structure of the internal table at the begining. You need not define the
structure of the extract dataset.
C. In contrast to internal tables, the system partly compresses extract datasets when storing them.
This reduces the storage space required.
D. Internal tables require special work area for interface whereas extract datasets do not need a
special work area or interface.

What are the different types of programs? (IMFEO) detail

I Include Program

M Module Pool

F Function Modules

S External Subroutines

1 Online program

Value table and check table

http://help.sap.com/saphelp_nw2004s/helpdata/en/cf/21ea77446011d189700000e8322d00/conte
nt.htm

What is primary key field and what is foriegn key field and their relationship?

Primary key field is the the database table column which helps in identifying the records
uniquely in master table.

Foreign key field is the database table column of a details table which is dependent on the
primary key field of a parent table .
e.g - In Employee Master Data table (Dept_ID is the foreign key)

       Emp_ID     Emp_name  Dept_ID

          
             1           aaa              10
             2           bbb             20
             3           ccc              30
             4           ddd             40
             5           eee              20
             6           fff                10
             7           ggg              30
             8           hhh              50
             9           iii                 10
            10          jjj                30

In Employee Details Data table (Dept_ID is the Primary key)

         Dept_ID         Dept_Name

          
            10               Accounts
            20               Sales
            30               Purchase
            40               Inventory
            50               Administration

The above information is sufficient for you to undersatnd the concept of primary and foreign key
relationship