What Are The Events In ALV
What are the events in alvs and which events not used in alvs?
Events in alv and their FM The main events in alv and their FM and why we use these:
1. SLIS_PRINT_ALV.
2. SLIS_T_LISTHEADER.
3. SLIS_T_EVENT.
4. SLIS_T_SORTINFO_ALV.
5. SLIS_T_LAYOUT_ALV.
6. SLIS_T_FIELDCAT_ALV.
and in classic reports what is the sequence of events: === Events are
At selection-screen output.
Initialization.
At selection-screen on field
At selection-screen on end of field
At selection-screen on Radiobutton Group R1. (If you have any radio buttons)
At selection-screen on block b1. (If you have any blocks)
Start-of-selection.
Get node. (if the data is retreived from a logical database)
Get node late. (if the data is retreived from a logical database)
Top-of-page. (if the write statement is in the end-of-selection event or we can say that before the first write statement)
end-of-selection.
and fuction modules are
LISTHEADER - Is used to print the header information in the ALV List. Name, Date, Time, ALV Name and other details are called as Header information. EVENT - Basically this is the FM to handle Event's. When the user needs to do some event operation like when double clicking the a particular field we need to perform some operation. These events are captured by this FM. LAYOUT - This FM is used to define the layout of the List. There are many options available in this FM to define the Layout style. FIELDCAT - These are used to populate the List header. We can change them according to our req.
User-defined Text Output Event
Application
print_end_of_list
Define output text to be printed at the end of the entire list
print_top_of_list
Define output text to be printed at the beginning of the entire list
print_end_of_page
Define output text to be printed at the end of each page
print_top_of_page
Define output text to be printed at the beginning of each page
subtotal_text
Define self-defined subtotals texts
Mouse-controlled Actions in the Grid Control Event
Application
button_click
Query a click on a pushbutton in the ALV Grid Control
double_click
Query a double-click on a cell of the ALV Grid control
hotspot_click
Query a hotspot click on columns defined for this purpose in advance
onDrag
Collect information when elements of the ALV Grid Control are dragged
onDrop
Process information when elements of the ALV Grid Control are dropped
onDropComplete
Perform final actions after successful Drag&Drop
onDropGetFlavor
Distinguish between options for Drag&Drop behavior
Processing of Self-defined and Standard Functions Event
Application
before_user_command
Query self-defined and standard function codes
user_command
Query self-defined function codes
after_user_command
Query self-defined and standard function codes
Definition of Self-defined Functions Event
Application
toolbar
Change, delete or add GUI elements in the toolbar
menu_button
Define menus for menu buttons in the toolbar
context_menu_request
Change context menu
onf1
Define self-defined F1 help
All of these can be found under type group SLIS.
* Events
SLIS_EV_ITEM_DATA_EXPAND TYPE SLIS_FORMNAME VALUE 'ITEM_DATA_EXPAND',
SLIS_EV_REPREP_SEL_MODIFY TYPE SLIS_FORMNAME VALUE 'REPREP_SEL_MODIFY', SLIS_EV_CALLER_EXIT_AT_START TYPE SLIS_FORMNAME VALUE 'CALLER_EXIT',
SLIS_EV_USER_COMMAND TYPE SLIS_FORMNAME VALUE 'USER_COMMAND',
SLIS_EV_TOP_OF_PAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_PAGE',
SLIS_EV_DATA_CHANGED TYPE SLIS_FORMNAME VALUE 'DATA_CHANGED',
SLIS_EV_TOP_OF_COVERPAGE TYPE SLIS_FORMNAME VALUE 'TOP_OF_COVERPAGE',
SLIS_EV_END_OF_COVERPAGE TYPE SLIS_FORMNAME VALUE 'END_OF_COVERPAGE',
SLIS_EV_FOREIGN_TOP_OF_PAGE TYPE SLIS_FORMNAME
VALUE 'FOREIGN_TOP_OF_PAGE', SLIS_EV_FOREIGN_END_OF_PAGE TYPE SLIS_FORMNAME
VALUE 'FOREIGN_END_OF_PAGE',
SLIS_EV_PF_STATUS_SET TYPE SLIS_FORMNAME VALUE 'PF_STATUS_SET',
SLIS_EV_LIST_MODIFY TYPE SLIS_FORMNAME VALUE 'LIST_MODIFY',
SLIS_EV_TOP_OF_LIST TYPE SLIS_FORMNAME VALUE 'TOP_OF_LIST',
SLIS_EV_END_OF_PAGE TYPE SLIS_FORMNAME VALUE 'END_OF_PAGE',
SLIS_EV_END_OF_LIST TYPE SLIS_FORMNAME VALUE 'END_OF_LIST',
SLIS_EV_AFTER_LINE_OUTPUT TYPE SLIS_FORMNAME VALUE 'AFTER_LINE_OUTPUT', SLIS_EV_BEFORE_LINE_OUTPUT TYPE SLIS_FORMNAME VALUE 'BEFORE_LINE_OUTPUT',
SLIS_EV_SUBTOTAL_TEXT TYPE SLIS_FORMNAME VALUE 'SUBTOTAL_TEXT'.
Wednesday, June 29, 2011
CONSITENCEY THROUGH INPUT CHECKS:
CONSITENCEY THROUGH INPUT CHECKS:
The domain describes the value range of a field by specifying its data type and field length. If only a limited set of values is allowed, they can be defined as fixed values.
Specifying fixed values causes the value range of the domain to be restricted by these values. Fixed values are immediately used as check values in screen entries. There is also an F4 help.
Fixed values are only checked in screens. No check is made when data records are inserted in a table by an ABAP program.
Fixed values can either be listed individually or defined as an interval.
The value range of a field can also be defined by specifying a value table in the domain.
In contrast to fixed values, however, simply specifying a value table does not cause the input to be checked. There is no F4 help either.
If you enter a value table, the system can make a proposal for the foreign key definition.
A value table only becomes a check table when a foreign key is defined.
If you refer to a domain with a value table in a field, but no foreign key was defined at field level, there is no check.
In the ABAP Dictionary, such relationships between two tables are called foreign keys and they must be defined explicitly for the fields.
Foreign keys are used to ensure that the data is consistent. Data that has been entered is checked against existing data to ensure that it is consistent.
In order to define the foreign key, these three fields are assigned to fields of the foreign key table (foreign key fields) with which the input to be checked is entered on the screen. In table SBOOK these are the fields: MANDT, CARRID, COUNTER. The entry is accepted if it represents a valid counter; otherwise the system will reject it.
The foreign key is defined for field SBOOK-COUNTER (check field), which means that the entry in this field is checked. Field COUNTER is therefore called the check field for this foreign key.
A combination of fields of a table is called a foreign key if this field combination is the primary key of another table.
A foreign key links two tables.
The check table is the table whose key fields are checked. This table is also called the referenced table .
An entry is to be written in the foreign key table. This entry must be consistent with the key fields of the check table.
The field of the foreign key table to be checked is called the check field.
Foreign keys can only be used in screens. Data records can be written to the table without being checked using an ABAP program.
In the ABAP Dictionary, the same domain is required for the check field and referenced key field of the check table so that you do not compare fields with different data types and field lengths. Domain equality is essential. Different data elements can be used, but they must refer to the same domain.
The requirement for domain equality is only valid for the check field. For all other foreign key fields, it is sufficient if the data type and the field length are equal. You nevertheless should strive for domain equality. In this case the foreign key will remain consistent if the field length is changed because the corresponding fields are both changed. If the domains are different, the foreign key will be inconsistent if for example the field length is changed.
If the domain of the check field has a value table, you can have the system make a proposal with the value table as check table. In this case a proposal is created for the field assignment in the foreign key.
CAUTION!
The constellation that a domain that itself has table SAIRPORT as value table is used following field SAIRPORT-Airport is correct !! However, a foreign key is never defined on this field (avoiding a loop).
The cardinality describes the foreign key relationship with regard to how many records of the check table are assigned to records of the foreign key table. The cardinality is always defined from the point of view of the check table.
The type of the foreign key field defines whether or not the foreign key field identifies a table entry.
This means that the foreign key fields are either key fields or they are not key fields or they are a special case, namely the key fields of a text table.
There are the following kinds of foreign key fields:
not specified: No information about the kind of foreign key field can be given
no key fields/candidates: The foreign key fields are neither primary key fields of the foreign key table nor do they uniquely identify a record of the foreign key table (key candidates).
The foreign key fields therefore do not (partially) identify the foreign key table.
Key fields/candidates:
The foreign key fields are either primary key fields of the foreign key table or they uniquely identify a record of the foreign key table (key candidates). The foreign key fields therefore (partially) identify the foreign key table.
Key fields of a text table :
The foreign key table is a text table of the check table, i.e. the key of the foreign key table only differs from the key of the check table in an additional language key field. This is a special case of the category Key fields / candidates.
Only one text table can be created for a table.
The domain describes the value range of a field by specifying its data type and field length. If only a limited set of values is allowed, they can be defined as fixed values.
Specifying fixed values causes the value range of the domain to be restricted by these values. Fixed values are immediately used as check values in screen entries. There is also an F4 help.
Fixed values are only checked in screens. No check is made when data records are inserted in a table by an ABAP program.
Fixed values can either be listed individually or defined as an interval.
The value range of a field can also be defined by specifying a value table in the domain.
In contrast to fixed values, however, simply specifying a value table does not cause the input to be checked. There is no F4 help either.
If you enter a value table, the system can make a proposal for the foreign key definition.
A value table only becomes a check table when a foreign key is defined.
If you refer to a domain with a value table in a field, but no foreign key was defined at field level, there is no check.
In the ABAP Dictionary, such relationships between two tables are called foreign keys and they must be defined explicitly for the fields.
Foreign keys are used to ensure that the data is consistent. Data that has been entered is checked against existing data to ensure that it is consistent.
In order to define the foreign key, these three fields are assigned to fields of the foreign key table (foreign key fields) with which the input to be checked is entered on the screen. In table SBOOK these are the fields: MANDT, CARRID, COUNTER. The entry is accepted if it represents a valid counter; otherwise the system will reject it.
The foreign key is defined for field SBOOK-COUNTER (check field), which means that the entry in this field is checked. Field COUNTER is therefore called the check field for this foreign key.
A combination of fields of a table is called a foreign key if this field combination is the primary key of another table.
A foreign key links two tables.
The check table is the table whose key fields are checked. This table is also called the referenced table .
An entry is to be written in the foreign key table. This entry must be consistent with the key fields of the check table.
The field of the foreign key table to be checked is called the check field.
Foreign keys can only be used in screens. Data records can be written to the table without being checked using an ABAP program.
In the ABAP Dictionary, the same domain is required for the check field and referenced key field of the check table so that you do not compare fields with different data types and field lengths. Domain equality is essential. Different data elements can be used, but they must refer to the same domain.
The requirement for domain equality is only valid for the check field. For all other foreign key fields, it is sufficient if the data type and the field length are equal. You nevertheless should strive for domain equality. In this case the foreign key will remain consistent if the field length is changed because the corresponding fields are both changed. If the domains are different, the foreign key will be inconsistent if for example the field length is changed.
If the domain of the check field has a value table, you can have the system make a proposal with the value table as check table. In this case a proposal is created for the field assignment in the foreign key.
CAUTION!
The constellation that a domain that itself has table SAIRPORT as value table is used following field SAIRPORT-Airport is correct !! However, a foreign key is never defined on this field (avoiding a loop).
The cardinality describes the foreign key relationship with regard to how many records of the check table are assigned to records of the foreign key table. The cardinality is always defined from the point of view of the check table.
The type of the foreign key field defines whether or not the foreign key field identifies a table entry.
This means that the foreign key fields are either key fields or they are not key fields or they are a special case, namely the key fields of a text table.
There are the following kinds of foreign key fields:
not specified: No information about the kind of foreign key field can be given
no key fields/candidates: The foreign key fields are neither primary key fields of the foreign key table nor do they uniquely identify a record of the foreign key table (key candidates).
The foreign key fields therefore do not (partially) identify the foreign key table.
Key fields/candidates:
The foreign key fields are either primary key fields of the foreign key table or they uniquely identify a record of the foreign key table (key candidates). The foreign key fields therefore (partially) identify the foreign key table.
Key fields of a text table :
The foreign key table is a text table of the check table, i.e. the key of the foreign key table only differs from the key of the check table in an additional language key field. This is a special case of the category Key fields / candidates.
Only one text table can be created for a table.
INTERNAL PROGRAM MODULARIZATION:
INTERNAL PROGRAM MODULARIZATION:
An ABAP program is a collection of processing blocks. A processing block is a passive section of program code that is processed sequentially when called.
Processing blocks are the smallest units in ABAP. They cannot be split, which also means that they cannot be nested.
There are various kinds of ABAP processing blocks:
Event blocks are ABAP processing blocks that are called by the runtime system. Event blocks can logically belong to the executable program, to the selection screen, to the list or to the screen. This unit deals with event blocks that belong to the executable program. You can find information on event blocks that belong to the selection screen, the list or the screen in the units on user dialogs.
Subroutine processing is triggered by an ABAP statement. Parameters can be passed to
subroutines using an interface and subroutines can contain local variables.
Modules are special ABAP processing blocks for processing screens. Therefore modules are dealt with in the User Dialogs: Screens unit.
Memory areas are made available for all a program's global data objects when that program is started. Declarative ABAP statements are therefore not components of ABAP processing blocks but are collected from the overall source code using a search when the program is generated. The exceptions to this are local data objects in subroutines.
In all of the programs that we have seen so far in this course, there has only been one processing block in addition to the data declaration. In this case, there is no need to declare the processing block explicitly. However, in more complex programs, we will require several different processing blocks and will need to specify the type and name.
The program shown above is an example of event blocks. It contains an input value for a date on a selection screen. The default value is the date from the week before. This cannot be realized by a default value from the PARAMETERS statement, since a calculation is required. The DEFAULT addition to the PARAMETERS statement ensures that the data object is filled with the default value at the start of the program.
Default values can be literals or fields from the sy structure. The runtime system fills the sy-datum field with the current date at the start of the program. You can use the INITIALIZATION event block to change variables at runtime but before the standard selection screen is sent. START-OF-SELECTION is an event block for creating lists.
All global declarations are recognized as such by the system by the declarative ABAP key words that they use, and these form a logical processing block (regardless of where they are placed in the program code). When you generate the program, the system searches the entire program code for declarative statements. However, for the sake of clarity, you should place all declarative statements together at the beginning of your programs. The PARAMETERS statement is one of the declarative language elements. When the program is generated, a selection screen is also generate d along with the information on the elementary data object of the type specified.
The easiest events to understand are those for an executable program (type 1).
The ABAP runtime system calls event blocks in a sequence designed for generating and processing lists:
First, the INITIALIZATION event block is called
Then a selection screen is sent to the presentation server
After the user leaves the selection screen, START-OF-SELECTION is called
If the START-OF-SELECTION event block contains the ABAP statements WRITE, SKIP or ULINE, a list buffer is filled.
The list buffer is subsequently sent to the presentation server as a list.
Event blocks are processing blocks that are called by the ABAP runtime system. The sequence in which they are processed is determined by the runtime system.
In executable programs, there are different event blocks for the various tasks involved in creating lists.
In an ABAP program, an event block is introduced with an event key word. It ends when the next processing block starts. There is no ABAP statement that explicitly concludes an event block.
Event blocks are called by the ABAP runtime system. The order in which you arrange the event blocks in your program is irrelevant - the system always calls them in a particular order.
START-OF-SELECTION is the first event for generating a list. It is called by the ABAP runtime system as soon as you have pressed the execute button.
INITIALIZATION is an event that you can use if you need to set a large number of default values.
This event block allows you to set default values that can only be determined at runtime. In the above example, the date 'A week ago' is calculated and placed in data object pa_date. The ABAP runtime system then sends a selection screen to the presentation server containing the calculated value as a default. The value can, of course, still be changed by the user.
Subroutines are processing blocks with a defined interface that can be called from any processing block using the ABAP statement. Subroutines provide internal program encapsulation.
You can navigate from the program object list to the subroutines.
The where-used list for a subroutine displays all the program lines that call the subroutine.
Ideally, all you need to do to determine the functional scope of the subroutine is to examine the subroutine name, the interface and the comments. If the subroutine contains the functionality you require, then you need the following information to be able to call the subroutine:
Subroutine name
Interface parameters it accesses (read-only): the parameters are listed after the USING addition.
The type and sequence of the interface parameters is important.
Interface parameters it changes: the parameters are listed after the CHANGING addition. The type and sequence of the interface parameters is important.
When a subroutine is called, all the interface parameters have to be filled with values. A distinction is made between the following parameters:
After USING, the parameters that the subroutine only needs to read are listed.
After CHANGING, the parameters that are changed in the subroutine are listed.
If the subroutine is called from the ABAP processing block by a PERFORM statement, the system interrupts the processing block to process the subroutine sequentially. When the last line of the subroutine (ENDFORM.) is reached, the system carries processing after the PERFORM statement.
You can track runtime behavior in the debugging mode. This gives you various options:
You can go through the entire program, including the subroutine, line by line, using Single Step
You can go through a processing block line by line using Execute. Subroutines are then executed as a whole
You can leave single -step processing of a subroutine and return to the calling program using Return
The method used for calling the interface parameters is set in the subroutine interface. The
parameters can be called either by reference or by value.
Calling by reference: The address of the actual parameter is called. Within the subroutine, the variable is addressed using the formal parameter name. Changes have an immediate effect on the global variable. If only the formal parameter name is specified in the subroutine interface, then the parameter is called by reference.
Calling by value: When the subroutine is called, a local variant is created with the formal parameter name and the actual parameter value is copied to the formal parameter. There are two types of call by value:
Calling by value: the formal parameter is listed in the interface after the USING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter only affect the local copy, not the actual parameter.
Calling by value and result: the formal parameter is listed in the interface after the CHANGING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter initially only affect the local copy. When the ENDFORM statement is reached, the formal parameter value is copied back to the actual parameter.
The parameters in the interface are called formal parameters , and the parameters that you pass to the subroutine are called actual parameters .
You must have the same number of actual parameters as formal parameters. You cannot have optional parameters. Parameters are assigned in the sequence in which they are listed.
When you call a subroutine using PERFORM, the system checks whether the types of the actual parameters in the PERFORM statement are compatible with the formal parameters. Different kinds of checks are performed for different types:
Complete type checks:
TYPE D, F, I, T or . These types are fully specified. The system checks to see if the data type of the actual parameter is identical to the type of the formal parameter in its entirety.
Partial type checks of generic types
TYPE C, N, P or X. The system checks whether the actual parameter has the type C, N, P or X. The length of the parameter and the number of decimal places in the DECIMALS addition (type P) are passed from the actual parameter to the formal parameter.
TYPE all unspecified information from generic
Dictionary types is inherited by the formal parameter from an actual parameter.
The interface is defined in the FORM routine. USING and CHANGING in the PERFORM statement are purely documentary.
An ABAP program is a collection of processing blocks. A processing block is a passive section of program code that is processed sequentially when called.
Processing blocks are the smallest units in ABAP. They cannot be split, which also means that they cannot be nested.
There are various kinds of ABAP processing blocks:
Event blocks are ABAP processing blocks that are called by the runtime system. Event blocks can logically belong to the executable program, to the selection screen, to the list or to the screen. This unit deals with event blocks that belong to the executable program. You can find information on event blocks that belong to the selection screen, the list or the screen in the units on user dialogs.
Subroutine processing is triggered by an ABAP statement. Parameters can be passed to
subroutines using an interface and subroutines can contain local variables.
Modules are special ABAP processing blocks for processing screens. Therefore modules are dealt with in the User Dialogs: Screens unit.
Memory areas are made available for all a program's global data objects when that program is started. Declarative ABAP statements are therefore not components of ABAP processing blocks but are collected from the overall source code using a search when the program is generated. The exceptions to this are local data objects in subroutines.
In all of the programs that we have seen so far in this course, there has only been one processing block in addition to the data declaration. In this case, there is no need to declare the processing block explicitly. However, in more complex programs, we will require several different processing blocks and will need to specify the type and name.
The program shown above is an example of event blocks. It contains an input value for a date on a selection screen. The default value is the date from the week before. This cannot be realized by a default value from the PARAMETERS statement, since a calculation is required. The DEFAULT addition to the PARAMETERS statement ensures that the data object is filled with the default value at the start of the program.
Default values can be literals or fields from the sy structure. The runtime system fills the sy-datum field with the current date at the start of the program. You can use the INITIALIZATION event block to change variables at runtime but before the standard selection screen is sent. START-OF-SELECTION is an event block for creating lists.
All global declarations are recognized as such by the system by the declarative ABAP key words that they use, and these form a logical processing block (regardless of where they are placed in the program code). When you generate the program, the system searches the entire program code for declarative statements. However, for the sake of clarity, you should place all declarative statements together at the beginning of your programs. The PARAMETERS statement is one of the declarative language elements. When the program is generated, a selection screen is also generate d along with the information on the elementary data object of the type specified.
The easiest events to understand are those for an executable program (type 1).
The ABAP runtime system calls event blocks in a sequence designed for generating and processing lists:
First, the INITIALIZATION event block is called
Then a selection screen is sent to the presentation server
After the user leaves the selection screen, START-OF-SELECTION is called
If the START-OF-SELECTION event block contains the ABAP statements WRITE, SKIP or ULINE, a list buffer is filled.
The list buffer is subsequently sent to the presentation server as a list.
Event blocks are processing blocks that are called by the ABAP runtime system. The sequence in which they are processed is determined by the runtime system.
In executable programs, there are different event blocks for the various tasks involved in creating lists.
In an ABAP program, an event block is introduced with an event key word. It ends when the next processing block starts. There is no ABAP statement that explicitly concludes an event block.
Event blocks are called by the ABAP runtime system. The order in which you arrange the event blocks in your program is irrelevant - the system always calls them in a particular order.
START-OF-SELECTION is the first event for generating a list. It is called by the ABAP runtime system as soon as you have pressed the execute button.
INITIALIZATION is an event that you can use if you need to set a large number of default values.
This event block allows you to set default values that can only be determined at runtime. In the above example, the date 'A week ago' is calculated and placed in data object pa_date. The ABAP runtime system then sends a selection screen to the presentation server containing the calculated value as a default. The value can, of course, still be changed by the user.
Subroutines are processing blocks with a defined interface that can be called from any processing block using the ABAP statement. Subroutines provide internal program encapsulation.
You can navigate from the program object list to the subroutines.
The where-used list for a subroutine displays all the program lines that call the subroutine.
Ideally, all you need to do to determine the functional scope of the subroutine is to examine the subroutine name, the interface and the comments. If the subroutine contains the functionality you require, then you need the following information to be able to call the subroutine:
Subroutine name
Interface parameters it accesses (read-only): the parameters are listed after the USING addition.
The type and sequence of the interface parameters is important.
Interface parameters it changes: the parameters are listed after the CHANGING addition. The type and sequence of the interface parameters is important.
When a subroutine is called, all the interface parameters have to be filled with values. A distinction is made between the following parameters:
After USING, the parameters that the subroutine only needs to read are listed.
After CHANGING, the parameters that are changed in the subroutine are listed.
If the subroutine is called from the ABAP processing block by a PERFORM statement, the system interrupts the processing block to process the subroutine sequentially. When the last line of the subroutine (ENDFORM.) is reached, the system carries processing after the PERFORM statement.
You can track runtime behavior in the debugging mode. This gives you various options:
You can go through the entire program, including the subroutine, line by line, using Single Step
You can go through a processing block line by line using Execute. Subroutines are then executed as a whole
You can leave single -step processing of a subroutine and return to the calling program using Return
The method used for calling the interface parameters is set in the subroutine interface. The
parameters can be called either by reference or by value.
Calling by reference: The address of the actual parameter is called. Within the subroutine, the variable is addressed using the formal parameter name. Changes have an immediate effect on the global variable. If only the formal parameter name is specified in the subroutine interface, then the parameter is called by reference.
Calling by value: When the subroutine is called, a local variant is created with the formal parameter name and the actual parameter value is copied to the formal parameter. There are two types of call by value:
Calling by value: the formal parameter is listed in the interface after the USING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter only affect the local copy, not the actual parameter.
Calling by value and result: the formal parameter is listed in the interface after the CHANGING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter initially only affect the local copy. When the ENDFORM statement is reached, the formal parameter value is copied back to the actual parameter.
The parameters in the interface are called formal parameters , and the parameters that you pass to the subroutine are called actual parameters .
You must have the same number of actual parameters as formal parameters. You cannot have optional parameters. Parameters are assigned in the sequence in which they are listed.
When you call a subroutine using PERFORM, the system checks whether the types of the actual parameters in the PERFORM statement are compatible with the formal parameters. Different kinds of checks are performed for different types:
Complete type checks:
TYPE D, F, I, T or . These types are fully specified. The system checks to see if the data type of the actual parameter is identical to the type of the formal parameter in its entirety.
Partial type checks of generic types
TYPE C, N, P or X. The system checks whether the actual parameter has the type C, N, P or X. The length of the parameter and the number of decimal places in the DECIMALS addition (type P) are passed from the actual parameter to the formal parameter.
TYPE all unspecified information from generic
Dictionary types is inherited by the formal parameter from an actual parameter.
The interface is defined in the FORM routine. USING and CHANGING in the PERFORM statement are purely documentary.
Display more than one Internal Table in ALV using Object Oriented ABAP Programming
By Ashwini Thoutireddy, Phifer Wire Products Inc
Applies to:
This document applies to SAP ECC 6.0, SAP Net weaver 2004s.
Scenario
Displaying more than one table in ALV grid report by splitting the custom container.
TABLE 1 TABLE 2
TABLE 3
Step by step Solution
Step 1: Creating Screen
Go to Screen painter Transaction Code SE51.
Create a screen with no 9010.
Provide description for the screen and click on the Layout Button.
Place a Custom container UI element and give name as ‘CCONTAINER’ now you will have a screen with custom container as below screen shot. Activate the Object.
Step 2: Flow Logic
Go to the Flow Logic Tab to write coding for PBO & PAI.
Step 3: Report
Go to SE38 and create a program in Z name space and paste the following code snippet.
Click here to continue...
...Previous
*&---------------------------------------------------------------------*
*& Report ZPC_CONTAINER_CONTROL *
*&---------------------------------------------------------------------*
REPORT zpc_container_control.
*Declaration
DATA: Splitter_1 TYPE REF TO cl_gui_splitter_container,
Splitter_2 TYPE REF TO cl_gui_splitter_container,
Container TYPE REF TO cl_gui_custom_container,
Container_1 TYPE REF TO cl_gui_container,
Container_2 TYPE REF TO cl_gui_container,
Container_3 TYPE REF TO cl_gui_container,
Grid1 TYPE REF TO cl_gui_alv_grid,
Grid2 TYPE REF TO cl_gui_alv_grid,
Grid3 TYPE REF TO cl_gui_alv_grid.
DATA: Gt_sflight_1 TYPE TABLE OF sflight,
Gt_sflight_2 TYPE TABLE OF sflight,
Gt_sflight_3 TYPE TABLE OF sflight,
G_container TYPE scrfname VALUE 'CCONTAINER'.
DATA: ok_code TYPE sy-ucomm.
* fetching data from table for different internal tables
SELECT * FROM sflight INTO TABLE gt_sflight_1. “Itab 1
SELECT * FROM sflight INTO TABLE gt_sflight_2 UP TO 3 ROWS. “Itab 2
SELECT * FROM sflight INTO TABLE gt_sflight_3 UP TO 2 ROWS. “Itab 3
CALL SCREEN 9010.
*&---------------------------------------------------------------------*
*& Module STATUS_9010 OUTPUT *
*&---------------------------------------------------------------------*
MODULE status_9010 OUTPUT.
SET PF-STATUS 'TEST'.
*creating object reference for container
CREATE OBJECT container
EXPORTING
container_name = 'CCONTAINER'. “Pass name of container created in Screen no 9010
*splitting the main container into 1 row & 2 coloum
CREATE OBJECT splitter_1
EXPORTING
Parent = container
Rows = 1
Columns = 2.
*getting the reference for the splited container (row 1 & col 1 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_1.
*getting the reference for the splited container (row 1 & col 2 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 2
RECEIVING
Container = container_2.
*splitting the 2nd coloum container in to 2 rows & 1 coloum
CREATE OBJECT splitter_2
EXPORTING
Parent = container_2
Rows = 2
Columns = 1.
*getting the reference for the splited container2 (row 1 & col 2 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_2.
*getting the reference for the splited container2 (row 2 & col 1 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 2
Column = 1
RECEIVING
Container = container_3.
*populating first internal table to the container
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid1
EXPORTING
i_parent = container_1.
CALL METHOD grid1->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_1.
*populating second internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid2
EXPORTING
i_parent = container_2.
CALL METHOD grid2->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_2.
*populating third internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid3
EXPORTING
i_parent = container_3.
CALL METHOD grid3->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_3.
ENDMODULE. “STATUS_9010 OUTPUT
*&---------------------------------------------------------------------*
*& Module EXIT INPUT *
*&---------------------------------------------------------------------*
MODULE exit INPUT.
*free the container memory when exit
CALL METHOD container->free.
LEAVE PROGRAM.
ENDMODULE. “EXIT INPUT
*&---------------------------------------------------------------------*
*& Module USER_COMMAND_9010 INPUT *
*&---------------------------------------------------------------------*
MODULE user_command_9010 INPUT.
CALL METHOD cl_gui_cfw=>dispatch.
CASE ok_code.
WHEN 'BACK'.
LEAVE SCREEN.
WHEN 'CANCEL'.
LEAVE PROGRAM.
WHEN 'EXIT'.
LEAVE SCREEN.
ENDCASE.
ENDMODULE. “USER_COMMAND_9010 INPUT
By Ashwini Thoutireddy, Phifer Wire Products Inc
Applies to:
This document applies to SAP ECC 6.0, SAP Net weaver 2004s.
Scenario
Displaying more than one table in ALV grid report by splitting the custom container.
TABLE 1 TABLE 2
TABLE 3
Step by step Solution
Step 1: Creating Screen
Go to Screen painter Transaction Code SE51.
Create a screen with no 9010.
Provide description for the screen and click on the Layout Button.
Place a Custom container UI element and give name as ‘CCONTAINER’ now you will have a screen with custom container as below screen shot. Activate the Object.
Step 2: Flow Logic
Go to the Flow Logic Tab to write coding for PBO & PAI.
Step 3: Report
Go to SE38 and create a program in Z name space and paste the following code snippet.
Click here to continue...
...Previous
*&---------------------------------------------------------------------*
*& Report ZPC_CONTAINER_CONTROL *
*&---------------------------------------------------------------------*
REPORT zpc_container_control.
*Declaration
DATA: Splitter_1 TYPE REF TO cl_gui_splitter_container,
Splitter_2 TYPE REF TO cl_gui_splitter_container,
Container TYPE REF TO cl_gui_custom_container,
Container_1 TYPE REF TO cl_gui_container,
Container_2 TYPE REF TO cl_gui_container,
Container_3 TYPE REF TO cl_gui_container,
Grid1 TYPE REF TO cl_gui_alv_grid,
Grid2 TYPE REF TO cl_gui_alv_grid,
Grid3 TYPE REF TO cl_gui_alv_grid.
DATA: Gt_sflight_1 TYPE TABLE OF sflight,
Gt_sflight_2 TYPE TABLE OF sflight,
Gt_sflight_3 TYPE TABLE OF sflight,
G_container TYPE scrfname VALUE 'CCONTAINER'.
DATA: ok_code TYPE sy-ucomm.
* fetching data from table for different internal tables
SELECT * FROM sflight INTO TABLE gt_sflight_1. “Itab 1
SELECT * FROM sflight INTO TABLE gt_sflight_2 UP TO 3 ROWS. “Itab 2
SELECT * FROM sflight INTO TABLE gt_sflight_3 UP TO 2 ROWS. “Itab 3
CALL SCREEN 9010.
*&---------------------------------------------------------------------*
*& Module STATUS_9010 OUTPUT *
*&---------------------------------------------------------------------*
MODULE status_9010 OUTPUT.
SET PF-STATUS 'TEST'.
*creating object reference for container
CREATE OBJECT container
EXPORTING
container_name = 'CCONTAINER'. “Pass name of container created in Screen no 9010
*splitting the main container into 1 row & 2 coloum
CREATE OBJECT splitter_1
EXPORTING
Parent = container
Rows = 1
Columns = 2.
*getting the reference for the splited container (row 1 & col 1 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_1.
*getting the reference for the splited container (row 1 & col 2 container)
CALL METHOD splitter_1->get_container
EXPORTING
Row = 1
Column = 2
RECEIVING
Container = container_2.
*splitting the 2nd coloum container in to 2 rows & 1 coloum
CREATE OBJECT splitter_2
EXPORTING
Parent = container_2
Rows = 2
Columns = 1.
*getting the reference for the splited container2 (row 1 & col 2 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 1
Column = 1
RECEIVING
Container = container_2.
*getting the reference for the splited container2 (row 2 & col 1 container)
CALL METHOD splitter_2->get_container
EXPORTING
Row = 2
Column = 1
RECEIVING
Container = container_3.
*populating first internal table to the container
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid1
EXPORTING
i_parent = container_1.
CALL METHOD grid1->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_1.
*populating second internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid2
EXPORTING
i_parent = container_2.
CALL METHOD grid2->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_2.
*populating third internal table
CREATE OBJECT container
EXPORTING
container_name = g_container.
CREATE OBJECT grid3
EXPORTING
i_parent = container_3.
CALL METHOD grid3->set_table_for_first_display
EXPORTING
i_structure_name = 'SFLIGHT'
CHANGING
it_outtab = gt_sflight_3.
ENDMODULE. “STATUS_9010 OUTPUT
*&---------------------------------------------------------------------*
*& Module EXIT INPUT *
*&---------------------------------------------------------------------*
MODULE exit INPUT.
*free the container memory when exit
CALL METHOD container->free.
LEAVE PROGRAM.
ENDMODULE. “EXIT INPUT
*&---------------------------------------------------------------------*
*& Module USER_COMMAND_9010 INPUT *
*&---------------------------------------------------------------------*
MODULE user_command_9010 INPUT.
CALL METHOD cl_gui_cfw=>dispatch.
CASE ok_code.
WHEN 'BACK'.
LEAVE SCREEN.
WHEN 'CANCEL'.
LEAVE PROGRAM.
WHEN 'EXIT'.
LEAVE SCREEN.
ENDCASE.
ENDMODULE. “USER_COMMAND_9010 INPUT
SAP LANDSCAPE.
SAP Landscape
ü Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the server’s viz. SAP is divided into three different landscapes DEV, QAS and PROD.
DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test. QAS may again have multiple clients for ex: 300- Integration Test, 700 to 710 Training. PROD may have something like a 200 Production. These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how are the client's business scenario.
Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage). As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving every time. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).
You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) clients. This is a configuration only client. Now upon a successful transport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients.
But in the Testing client you cannot even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practiced in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.
The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.
ü In summary:
Landscape: is the arrangement for the servers
Landscape: is the arrangement for the servers
IDES: is purely for education purpose and is NOT INCLUDED in the landscape.
DEVELOPMENT ---> QUALITY ----> PRODUCTION
Ø DEVELOPMENT: is where the consultants do the customization as per the company's requirement.
Ø QUALITY: is where the core team members and other members test the customization.
Ø PRODUCTION: is where the live data of the company is recorded.
A request will flow from Dev->Qual->Prod and not backwards.
1. Sandbox server: In the initial stages of any implementation project, You are given a sandbox server where you do all the configuration/customization as per the companies business process.
2. Development Server: - Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.
3. Production Server: This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new development is done is development client and the request is transported to production.
These three are landscape of any Company. They organized their office in these three ways. Developers develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.
Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed.
Application Server - Where SAP Installed.
Database Server - Where Database installed.
o Why do we call client 000 as golden client?
Golden client contains all the configuration data and master data so some extent. All the configuration settings are done in golden clients and then moved to other clients. Hence this client acts as a master record for all transaction settings, hence the name "Golden Client".
DEVELOPMENT
| SANDBOX |
| GOLDEN |
| QUALITY |
| ABAP |
| LIVE DATA USER |
PRODUCTION.
o What is the meaning of "R" in R/3 systems?
R/3 stands for real-time three tier architecture. This is the kind of architectures SAP R/3 system has.
R/3 means three layers are installed in Different system/server and they are connected with each other.
1) Presentation
2) Application
3) Database
2) Application
3) Database
Using ME57 to create an RFQ from multiple lines on multiple PRs
When using ME57 to create RFQs how can I select multiple line items from multiple purchase requisitions to turn into a single RFQ? If I select multiple lines and then use 'RFQ with Vendor', it only selects one line item. After further research it appears that you can only create only line at a time (very time consuming).
If you use ME41 and create with reference to PR then you cannot sort or filter columns to allow for easy consolidation.
Another forum recommended the following when using ME57 which works but it again adds extra steps to the process.
The whole process is as follows -
1) When you are in the 'Assign and Process Purchase Requisition' screen, select related PR and then click on 'Without Vendor' icon to flag all PRs for RFQ processing.
2) Select these PRs again and click further on 'Assignment Overview' icon (Shift and F5). The next screen will appear - Assign and Process requisitions - Overview of Assignments screen.
3) Select the 'PReq' column and then click further on 'Process Assignment' icon (F2). The next screen will appear where you have to maintain the 'quotation deadline' information.
4) Then click on 'Continue' icon (enter).
http://www.sapfans.com/forums/viewtopic.php?f=6&t=198768
So is there any way to either 1) enable sorting of data in ME41 or 2) use ME57 to create one RFQ from multiple line items of multiple purchase requisitions when selecting 'RFQ with Vendor'.
If you use ME41 and create with reference to PR then you cannot sort or filter columns to allow for easy consolidation.
Another forum recommended the following when using ME57 which works but it again adds extra steps to the process.
The whole process is as follows -
1) When you are in the 'Assign and Process Purchase Requisition' screen, select related PR and then click on 'Without Vendor' icon to flag all PRs for RFQ processing.
2) Select these PRs again and click further on 'Assignment Overview' icon (Shift and F5). The next screen will appear - Assign and Process requisitions - Overview of Assignments screen.
3) Select the 'PReq' column and then click further on 'Process Assignment' icon (F2). The next screen will appear where you have to maintain the 'quotation deadline' information.
4) Then click on 'Continue' icon (enter).
http://www.sapfans.com/forums/viewtopic.php?f=6&t=198768
So is there any way to either 1) enable sorting of data in ME41 or 2) use ME57 to create one RFQ from multiple line items of multiple purchase requisitions when selecting 'RFQ with Vendor'.
purchase requisition
· SAP Purchase Requisition 1
This series of article introduces the purchase requisition as an in-house instrument for entering requirements. The creation of purchase requisitions is shown using an example of consumption material with and without a material master record.
Following will also be covered in these articles:
- Use of transaction ME51N for purchase requisitions
- Creating a purchase requisition with items with single and multiple account assignments
- Requesting a material without a material master record
A practical example would be that in any plant maintenance department, you must have sensors and a particular testing instrument. Because this testing instrument is required for only one time, you do not want to create a material master record for it. Now you want to test the use of a purchasing requisition to process the internal requisition of these materials directly for your cost center.
Purchase Requisition in Procurement
In procurement, the internal requisition for materials or services triggers a procurement process. Purchase requisitions are internal documents for asking your Purchasing department to procure a particular quantity of a material or a service for a particular date. A purchase requisition (PReq) can be created directly or indirectly in the SAP R/3 system.
SAP MM Consumption Material Procurement PR
Figure SAP MM Consumption Material Procurement PR
“Direct” means that a purchase requisition is created manually in the department that made the request. Whoever creates the purchase requisition determines which material or service is ordered, and the quantity and date.
“Indirect” means that that purchase requisition from another SAP component is created automatically. Purchase requisitions can be created automatically, as follows:
- in MRP
- with maintenance orders
- with production orders
- with networks
- Purchase requisitions can also come from the SAP Advanced Planner and Optimizer (SAP APO) or the SAP Enterprise Buyer (SAP EBP).
SAP MM Purchase Requisitions
Figure SAP MM Purchase Requisitions
When you create a purchase requisition for materials that have a material master record, SAP R/3 transfers data in the material master record to the purchase requisition. You can convert purchase requisitions into RFQs, purchase orders or outline agreements.
SAP Purchase Requisition - 2
In this article we will discuss the structure of the purchase requisition. By highlighting common features and differences between a purchase requisition and a purchase order, such as the following:
- Missing a “proper ” document header in the purchase requisition • Specifying the vendor at item level of the purchase requisition is possible, but not compulsory
- Document overview in transactions ME21N and ME51N
In the transactions for creating, changing or displaying a purchase requisition (ME51N, ME52N, ME53N), there are single-screen transactions, just as in the purchase order. The division into different screen areas (header data, item overview, item details, document overview) and the operation correspond with the purchase order transaction.
SAP MM Purchase Requisition with ME51N, ME52N, ME53N
Figure SAP MM Purchase Requisition with ME51N, ME52N, ME53N
Entering the Account Assignment
If you want to request materials or services directly for an account assignment object, for example, for your cost center or for an asset, you must specify in the item overview the corresponding account assignment category. This means that you have to enter additional account assignment data in the item detail on the Account assignment tab.
If you have the single account assignment screen displayed on the Account assignment tab, you can use Multiple account assignment to switch to the multiple account assignment screen. On the multiple account assignment screen, choose Single account assignment to switch to the single account assignment screen. The SAP R/3 system stores your last setting. On the multiple account assignment screen, you can also create single account assignments.
With multiple account assignment, you can distribute the costs for one purchase order item among several cost centers, for example. In this case, the created account assignment data represents individual account assignment items. With multiple account assignment for an item, you must decide whether the value of the item is to be distributed on a quantity basis or as a percentage (for example, 10 pieces or 10% of the purchase order value to cost center 1000).
SAP MM Single or Multiple Account Assignment
Figure SAP MM Single or Multiple Account Assignment
If there are partial invoices, you can choose whether
- the partial invoice amount is distributed proportionally to the account assignment items
- the partial invoice amount is distributed to the account assignment items one after the other
The partial invoice indicator can also be derived automatically from the account assignment category if a partial invoice indicator is specified in Customizing for the account assignment category. For items with multiple account assignments, the system automatically sets the GR non-valuated indicator.
If you want to distribute the quantity in a purchase requisition item with account assignment to the different account assignment items, you just need to enter the account assignments, but not the quantity. The system automatically distributes the requested quantity proportionally to the existing account assignment items. If you change the requested quantity in the item overview, the quantity is adjusted in the relevant account assignment items. As soon as you change the quantity or percentage of the account assignment item, the system can no longer execute an automatic distribution.
SAP MM Single or Multiple Account Assignment
Figure SAP MM Single or Multiple Account Assignment
Example of an automatic account assignment distribution: You have requested 90 office chairs and assigned them equally to three cost centers. However, because you require 120 office chairs, you change the requested quantity in the item overview. The system then automatically changes the distribution so that 40 office chairs are assigned to each cost center.
SAP Purchase Requisition – 3
Features of the Purchase Requisition
In this article, we will start discussing the most important features of the purchase requisition: account assignment category unknown is allowed and then valuation price will be discussed.
Account assignment category: Unknown
If you do not know the account assignment object for which the material is being procured when you create the purchase requisition, you can use account assignment category U (unknown) in the purchase requisition
Then you do not need to enter any more account assignment details. If you create a purchase order with reference to this purchase requisition, you must specify precise account assignment information because account assignment category Unknown is not allowed in the purchase orders. Account assignment category U is allowed in purchase orders for external services and blanket purchase orders.
SAP MM Features of Purchase Requisition
Figure SAP MM Features of Purchase Requisition
Valuation price
When you create a purchase requisition item for valuated material, the valuation price is pulled from the material master record. For non-valuated material or material without a master record, the creator must manually enter the valuation price. This valuation price can be used for a value-related release procedure. The release can refer to the value of the individual item or to the total value of the requisition. If a previously defined release strategy becomes effective, you can create a request or a purchase order with reference to a purchase requisition only after the purchase requisition has been released. You can also dispense with the manual entry of a valuation price and use the missing valuation price as a criterion for your release strategy.
Status and Creation Indicator
If you want to trace whether your purchase requisition items have been processed, evaluate the processing status of the item. You can see the processing status on the Status tab page in the item detail area. The processing status provides information about whether the item has been ordered, not ordered or requested, or whether the item has been converted into an outline agreement. On this tab, the purchase order history of referenced purchasing documents (created with reference to this purchase requisition item) is listed. You can obtain information about previously posted goods receipts and invoices.
SAP MM Processing Status and Creation Indicator
Figure SAP MM Processing Status and Creation Indicator
For you as a buyer, it might be interesting to see how the purchase requisition was created in the system, manually or automatically (for example, through materials planning). In the item detail on the Contact person tab, the creation indicator can provide information.
Subscribe to:
Posts (Atom)