Subroutine in PAI

Hi,
i´m developing a modulpool and in an INPUT module there is a sentence: perform do_selection.
This form does exist in an include MZSDXXF01 but when i double click on it says that it does not.
I´ve noticed as well that although all my form/endform´s are in an include MZSDXXF01, this include does not appear in the corresponding folder of transaction SE80.
does anyone know why is this happening?
Best regards.

Typically when you create programs and activate them, the navigation index(this is what allows you to double click on something to navigate to the object) should be updated automatically. But for reasons that I am unaware of, sometimes this does not happen. In such cases, you need to do this 'update navigation index'.
Also, basis folks can schedule a job in production for running the program SAPRSLOG that updates all the navigation indexes. This will make sure that all the navigation indexes are updated properly.
Regards,
Srinivas

Similar Messages

Usage of LDB

I want to try a report where I can use LDB.So tried as follows
Report zgldb.
Nodes:pap.
When I just compile it says 'PAP is not a node of Logical database _S'..
what does this mean.How to use LDB in a report?
Thank you

Dear Gopi,
Logical Databases
Logical databases are special ABAP programs that retrieve data and make it available to application programs. The most common use of logical databases is still to read data from database tables by linking them to executable ABAP programs.
However, from Release 4.5A, it has also been possible to call logical databases using the function module LDB_PROCESS. This allows you to call several logical databases from any ABAP program, nested in any way. It is also possible to call a logical database more than once in a program, if it has been programmed to allow this. This is particularly useful for programs with type 1.
Logical databases contain Open SQL statements that read data from the database. You do not therefore need to use SQL in your own programs. The logical database reads the program, stores them in the program if necessary, and then passes them line by line to the application program or the function module LDB_PROCESS using an interface work area.
Logical Databases - Views of Data
A logical database provides a particular view of database tables in the R/3 System. It is always worth using logical databases if the structure of the data that you want to read corresponds to a view available through a logical database.
There are two ways of using a logical database: Either by linking it with an executable program, or by using the function module LDB_PROCESS in any ABAP program.
When you link a logical database to an executable program, the user can enter values on the selection screen, and the data read by the logical database is passed back to the program using the interface work areas. If you call the logical database using a function module, the selection screen is not displayed. The calling program does not have to provide interface work areas. Instead, it uses special subroutines called callback routines, which are called by the function module and filled with the required data.
Linking a Logical DB to an Executable Program
When you link an executable program to a logical database by entering the name of the logical database in the program attributes, the subroutines of the logical database program and the event blocks of the executable program form a modularized program for reading and processing data. The individual processing blocks are called in a predefined sequence by the runtime environment (see the diagram in the section Logical Databases and Contexts). The runtime sequence is controlled by the structure, selections, and PUT statements in the logical database, and by the GET statements in the executable program.
Selection Screen
If you specify a logical database in the attributes of an executable program, this affects the standard selection screen of the program. It contains both the selection fields from the logical database and those from the program itself. You can specify which of the logical database selections are relevant for your program, and should therefore appear on the screen, by declaring interface work areas for the relevant nodes.
Runtime Behavior
The following list shows the sequence in which the ABAP runtime environment calls the subroutines of the logical database and the event blocks in the executable program. The runtime environment executes a series of processors (selection screen processor, reporting processor). The ABAP code listed below shows the processing blocks that belong to the individual steps.
Initialization before the selection screen is processed.
Subroutine:
FORM INIT
This subroutine is called once only before the selection screen is first displayed.
Event block:
INITIALIZATION.
This event occurs once only before the selection screen is first displayed.
PBO of the Selection screen Initialization before each occasion on which the selection screen is displayed (for example, to supply default values for key fields).
Subroutine:
FORM PBO.
This subroutine is called each time the selection screen is sent (before it is displayed).
Event block:
AT SELECTION-SCREEN OUTPUT.
This event is called each time the selection screen is sent (before it is displayed).
The selection screen is displayed at the presentation server, and the user can enter data in the input fields.
Input help (F4) or field help (F1) requests.
Subroutines:
FORM <par>_VAL.
FORM <selop>_VAL.
FORM <selop>-LOW_VAL.
FORM <selop>-HIGH_VAL.
If the user requests a list of possible entries for database-specific parameters <par> or selection criteria <selop>, these subroutines are called as required.
If the user requests field help for these parameters, the subroutines are called with the ending _HLP instead of _VAL.
Event blocks:
AT SELECTION-SCREEN ON VALUE-REQUEST FOR <par>.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR <selop>-LOW.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR <selop>-HIGH.
If the user requests a list of possible entries for database-specific parameters <par> or selection criteria <selop>, these events are triggered as required.
If the user requests field help for these parameters, the events with the addition ON HELP-REQUEST occurs instead of ON VALUE-REQUEST.
PAI of the selection screen. Checks to see whether the user has entered correct, complete, and plausible data. Also contains authorization checks. If an error occurs, you can program a user dialog and make the relevant fields ready for input again.
Subroutines:
FORM PAI USING FNAME MARK.
The interface parameters FNAME and MARK are passed by the runtime environment.
FNAME contains the name of a selection criterion or parameter on the selection screen.
If MARK = SPACE, the user has entered a simple single value or range selection.
If MARK = '*', the user has also entered selections on the Multiple Selection screen.
Using the combination FNAME = '*' and MARK = 'ANY', you can check all entries at once when the user chooses a function or presses ENTER.
Event blocks:
AT SELECTION-SCREEN ON <fname>.
Event for processing a particular input field.
AT SELECTION-SCREEN ON END OF <fname>.
Event for processing multiple selections.
AT SELECTION-SCREEN.
Event for processing all user input.
Processing before reading data.
Subroutine:
BEFORE EVENT 'START-OF-SELECTION'.
The logical database can use this subroutine for necessary actions before reading data, for example, initializing internal tables.
Event block:
START-OF-SELECTION.
First event in an executable program after the selection screen has been processed. You can use this event block to prepare the program for processing data.
Reading data in the logical database and processing in the executable program.
Subroutine:
FORM PUT_<node>
The logical database reads the selected data of the node <node>.
Event block:
GET <table> [LATE].
This event is triggered by the PUT statement in the above subroutine. This event block allows you to process the data read for <node> in the corresponding interface work area.
Processing after reading data.
Subroutine:
AFTER EVENT 'END-OF-SELECTION'.
The logical database can use this subroutine for necessary actions after reading data, for example, releasing memory space.
Event block:
END-OF-SELECTION.
Last reporting event. You can use this event block to process the temporary dataset that you have created (for example, sort it).
If a list was generated during the above steps, the list processor in the runtime environment takes control of the program and displays the list.
Suppose TABLE1 is the root node and TABLE2 is its only subordinate node in a logical database. The processing steps for reading and processing data would then have the following hierarchical order:
START-OF-SELECTION.
FORM PUT_TABLE1.
GET TABLE1.
 FORM PUT_TABLE2.
 GET TABLE2.
GET TABLE1 LATE.
END-OF-SELECTION.
Authorization Checks in Logical Databases
It makes sense to use authorization checks using the AUTHORITY-CHECK statement in the following subroutines in the database program or event blocks of the executable program:
Subroutines in the database program:
- PAI
- AUTHORITY_CHECK_<table>
Event blocks in the executable program:
- AT SELECTION-SCREEN
- AT SELECTION-SCREEN ON <fname>
- AT SELECTION-SCREEN ON END OF <fname>
- GET <table>
Whether you place the authorization checks in the database program or in the executable program depends on the following:
The structure of the logical database.
For example, you should only check authorizations for company code if you actually read lines containing the company code at runtime.
Performance
Avoid repetitive checks (for example, within a SELECT loop).
The separation of database access and application logic allows you to program all of your authorization checks centrally in the logical database program. This makes it easier to maintain large programming systems.
Calling a Logical Database Using a Function Module
From Release 4.5A it is possible to call logical databases independently from any ABAP program. Previously it was only possible to link a logical database to an executable program, in which the processing blocks of the logical database and the program were controlled by the ABAP runtime environment.
To call a logical database from another program, use the function module LDB_PROCESS. This allows you to use the logical database as a routine for reading data. You can call more than one logical database from the same program. You may also call the same logical database more than once from the same program. In the past, it was only possible to use a logical database more than once or use more than one logical database by calling a further executable program using SUBMIT. These programs had to be linked to the corresponding logical database, and the data had to be passed to the calling program using ABAP memory or a similar technique.
When you call a logical database using the function module LDB_PROCESS, its selection screen is not displayed. Instead, you fill the selections using the interface parameters of the function module. The logical database does not trigger any GET events in the calling program, but passes the data back to the caller in callback routines. Calling a logical database using LDB_PROCESS thus decouples the actual data retrieval from the preceding selection screen processing and the subsequent data processing.
There is no need to adapt a logical database for use with LDB_PROCESS, except in the following cases: If you do not adapt a logical database, it is not possible to use the function module to call the same logical database more than once. The PAI subroutine is not called when you use LDB_PROCESS. This means that none of the checks for selections programmed in it are performed. You can work around these restrictions by including the subroutines LDB_PROCESS_INIT and LDB_PROCESS_CHECK_SELECTIONS in the database program.
Runtime Behavior
The subroutines in the logical database are called in the following sequence when you call the function module LDB_PROCESS:
LDB_PROCESS_INIT
INIT
LDB_PROCESS_CHECK_SELECTIONS
PUT <node>.
None of the subroutines used to process the selection screen when you link the logical database to an executable program are called, neither does the runtime environment trigger any reporting events in the calling program. Instead, the PUT statements in the logical database trigger actions in the function module that call callback routines in the calling program. In other words, the function module catches the events that are otherwise processed by the runtime environment.
Parameters of LDB_PROCESS
The function module has the following import parameters:
LDBNAME
Name of the logical database you want to call.
VARIANT
Name of a variant to fill the selection screen of the logical database. The variant must already be assigned to the database program of the logical database. The data is passed in the same way as when you use the WITH SELECTION-TABLE addition in a SUBMIT statement.
EXPRESSIONS
In this parameter, you can pass extra selections for the nodes of the logical database for which dynamic selections are allowed. The data type of the parameter RSDS_TEXPR is defined in the type group RSDS. The data is passed in the same way as when you use the WITH FREE SELECTION addition in a SUBMIT statement.
FIELD_SELECTION
You can use this parameter to pass a list of the required fields for the nodes of the logical database for which dynamic selections are allowed. The data type of the parameter is the deep internal table RSFS_FIELDS, defined in the type group RSFS. The component TABLENAME contains the name of the node and the deep component FIELDS contains the names of the fields that you want to read.
The function module has the following tables parameters:
CALLBACK
You use this parameter to assign callback routines to the names of nodes and events. The parameter determines the nodes of the logical database for which data is read, and when the data is passed back to the program and in which callback routine.
SELECTIONS
You can use this parameter to pass input values for the fields of the selection screen of the logical database. The data type of the parameter corresponds to the structure RSPARAMS in the ABAP Dictionary. The data is passed in the same way as when you use the WITH SELECTION-TABLE addition in a SUBMIT statement.
If you pass selections using more than one of the interface parameters, values passed in SELECTIONS and EXPRESSIONS overwrite values for the same field in VARIANT.
Read Depth and Callback Routines
When you link a logical database with an executable program, the GET statements determine the depth to which the logical database is read. When you call the function module LDB_PROCESS, you determine the depth by specifying a node name in the CALLBACK parameter. For each node for which you request data, a callback routine can be executed at two points. These correspond to the GET and GET LATE events in executable programs. In the table parameter CALLBACK, you specify the name of the callback routine and the required execution point for each node. A callback routine is a subroutine in the calling program or another program that is to be executed at the required point.
For the GET event, the callback routine is executed directly after the data has been read for the node, and before the subordinate nodes are processed. For the GET_LATE event, the callback routine is processed after the subordinate nodes have been processed.
The line type of the table parameter CALLBACK is the flat structure LDBCB from the ABAP Dictionary. It has the following components:
LDBNODE
Name of the node of the logical database to be read.
GET
A flag (contents X or SPACE), to call the corresponding callback routine at the GET event.
GET_LATE
A flag (contents X or SPACE), to call the corresponding callback routine at the GET LATE event.
CB_PROG
Name of the ABAP program in which the callback routine is defined.
CB_FORM
Name of the callback routine.
If you pass an internal table to the CALLBACK parameter, you must fill at least one of the GET or GET_LATE columns with X for each node (you may also fill both with X).
A callback routine is a subroutine that must be defined with the following parameter interface:
FORM <subr> USING <node> LIKE LDBCB-LDBNODE
 <wa> [TYPE <t>]
 <evt>
 <check>.
The parameters are filled by the function module LDB_PROCESS. They have the following meaning:
<node> contains the name of the node.
<wa> is the work area of the data read for the node. The program that calls the function module LDB_PROCESS and the program containing the callback routine do not have to declare interface work areas using NODES or TABLES. If the callback routine is only used for one node, you can use a TYPE reference to refer to the data type of the node in the ABAP Dictionary. Only then can you address the individual components of structured nodes directly in the subroutine. If you use the callback routine for more than one node, you cannot use a TYPE reference. In this case, you would have to address the components of structured nodes by assigning them one by one to a field symbol.
<evt> contains G or L, for GET or GET LATE respectively. This means that the subroutine can direct the program flow using the contents of <evt>.
<check> allows the callback routine to influence how the program is processed further (but only if <evt> contains the value G). The value X is assigned to the parameter when the subroutine is called. If it has the value SPACE when the subroutine ends, this flags that the subordinate nodes of the logical database should not be processed in the function module LDB_PROCESS. This is the same as leaving a GET event block using CHECK in an executable program. If this prevents unnecessary data from being read, it will improve the performance of your program.
Exceptions of LDB_PROCESS
LDB_ALREADY_RUNNING
A logical database may not be called if it is still processing a previous call. If this occurs, the exception LDB_ALREADY_RUNNING is triggered.
LDB_NOT_REENTRANT
A logical database may only be called repeatedly if its database program contains the subroutine LDB_PROCESS_INIT, otherwise, this exception is triggered.
LDB_SELECTIONS_NOT_ACCEPTED
Error handling in the subroutine LDB_PROCESS_CHECK_SELECTIONS of the database program can trigger this exception. The error message is placed in the usual system fields SY-MSG....
For details of further exceptions, refer to the function module documentation in the Function Builder.
Example
TABLES SPFLI.
SELECT-OPTIONS S_CARR FOR SPFLI-CARRID.
TYPE-POOLS: RSDS, RSFS.
DATA: CALLBACK TYPE TABLE OF LDBCB,
 CALLBACK_WA LIKE LINE OF CALLBACK.
DATA: SELTAB TYPE TABLE OF RSPARAMS,
 SELTAB_WA LIKE LINE OF SELTAB.
DATA: TEXPR TYPE RSDS_TEXPR,
 FSEL TYPE RSFS_FIELDS.
CALLBACK_WA-LDBNODE = 'SPFLI'.
CALLBACK_WA-GET = 'X'.
CALLBACK_WA-GET_LATE = 'X'.
CALLBACK_WA-CB_PROG = SY-REPID.
CALLBACK_WA-CB_FORM = 'CALLBACK_SPFLI'.
APPEND CALLBACK_WA TO CALLBACK.
CLEAR CALLBACK_WA.
CALLBACK_WA-LDBNODE = 'SFLIGHT'.
CALLBACK_WA-GET = 'X'.
CALLBACK_WA-CB_PROG = SY-REPID.
CALLBACK_WA-CB_FORM = 'CALLBACK_SFLIGHT'.
APPEND CALLBACK_WA TO CALLBACK.
SELTAB_WA-KIND = 'S'.
SELTAB_WA-SELNAME = 'CARRID'.
LOOP AT S_CARR.
MOVE-CORRESPONDING S_CARR TO SELTAB_WA.
APPEND SELTAB_WA TO SELTAB.
ENDLOOP.
CALL FUNCTION 'LDB_PROCESS'
 EXPORTING
 LDBNAME = 'F1S'
 VARIANT = ' '
 EXPRESSIONS = TEXPR
 FIELD_SELECTION = FSEL
 TABLES
 CALLBACK = CALLBACK
 SELECTIONS = SELTAB
 EXCEPTIONS
 LDB_NOT_REENTRANT = 1
 LDB_INCORRECT = 2
 LDB_ALREADY_RUNNING = 3
 LDB_ERROR = 4
 LDB_SELECTIONS_ERROR = 5
 LDB_SELECTIONS_NOT_ACCEPTED = 6
 VARIANT_NOT_EXISTENT = 7
 VARIANT_OBSOLETE = 8
 VARIANT_ERROR = 9
 FREE_SELECTIONS_ERROR = 10
 CALLBACK_NO_EVENT = 11
 CALLBACK_NODE_DUPLICATE = 12
 OTHERS = 13.
IF SY-SUBRC <> 0.
WRITE: 'Exception with SY-SUBRC', SY-SUBRC.
ENDIF.
FORM CALLBACK_SPFLI USING NAME TYPE LDBN-LDBNODE
 WA TYPE SPFLI
 EVT TYPE C
 CHECK TYPE C.
CASE EVT.
 WHEN 'G'.
 WRITE: / WA-CARRID, WA-CONNID, WA-CITYFROM, WA-CITYTO.
 ULINE.
 WHEN 'L'.
 ULINE.
ENDCASE.
ENDFORM.
FORM CALLBACK_SFLIGHT USING NAME TYPE LDBN-LDBNODE
 WA TYPE SFLIGHT
 EVT TYPE C
 CHECK TYPE C.
WRITE: / WA-FLDATE, WA-SEATSOCC, WA-SEATSMAX.
ENDFORM.
The data structure in a logical database is hierarchical. Many tables in the R/3 System are linked to each other using foreign key relationships. Some of these dependencies form tree-like hierarchical structures. Logical databases read data from database tables that are part of these structures.
Tasks of Logical Databases
As well as allowing you to read data from the database, logical databases also allow you to program other tasks centrally, making your application programs less complicated. They can be used for the following tasks:
Reading the same data for several programs.
The individual programs do not then need to know the exact structure of the relevant database tables (and especially not their foreign key relationships). Instead, they can rely on the logical database to read the database entries in the right order during the GET event.
Defining the same user interface for several programs.
Logical databases have a built-in selection screen. Therefore, all of the programs that use the logical database have the same user interface.
Central authorization checks
Authorization checks for central and sensitive data can be programmed centrally in the database to prevent them from being bypassed by simple application programs.
Improving performance
If you want to improve response times, logical databases permit you to take a number of measures to achieve this (for example, using joins instead of nested SELECT statements). These become immediately effective in all of the application programs concerned and save you from having to modify their source code.
A program-specific selection screen is defined at the beginning of the program. This requires the TABLES statement. Next, the required variables are defined for the interface.
The internal table CALLBACK is filled so that various callback routines are called in the program for the two nodes SPFLI and SFLIGHT. For SPFLI, the routine is to be called for GET and GET_LATE, for SFLIGHT, only at the GET event.
The internal table SELTAB is filled with values for the node SPFLI from the selection table S_CARR from the program-specific selection screen.
The program then calls the function module LDB_PROCESS with these parameters.
The subroutines CALLBACK_SPFLI and CALLBACK_SFLIGHT serve as callback routines. The interface parameter WA is fully typed, so you can address the individual components of the work areas. The events GET and GET LATE are handled differently in CALLBACK_SPFLI.
Regards,
Rajesh K Soman
Please reward points if found helpful

Problem with subroutine- need urgrnt help

hai all,
need help in subroutine.
in a report program,
i had calculated to get the total collection amount and need to generate a list for every day.
on next day that collection amount must come as a poeninig balance at the top of the list.
this i had done using two subroutines.
i have to call the subroutine for opening balance for previous day's collection first. after that in have to calculate the todays collection.
how can i have this please give me a suggession.
thanks in advance.
this is my report.
i want the 'Progressive Total C/O ' from subroutine form f002_item_data. of today to be come in
'Progressive Total B/F -
' ,106 w_total_bf. of the subroutine form f001_progressive_total on next day..
here is the code.....
*& Report ZVR023_COLL_STATEMENT *
report zvr023_coll_statement no standard page heading .
 MODULE. MSD *
 Objective : *
 Program : Updates Tables ( ) Downloads data ( ) *
 Outputs List ( X ) *
 Date Created *
 Author *
 Location *
 LDB ..... *
 External Dependencies *
Amendment History *
Who Change ID Reason *
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ *
XXXXXXXXX AADDMMYYYY Where XXXX = Developers Name................. *
 AA- Developers Initial ................................ *
 Includes *
*INCLUDE : *
 Tables *
tables : vbak,bsid,kna1,t001,adrc,vbrk,knvv.
 Types Begin with TY_ *
types : begin of ty_cust,
 belnr type bseg-belnr,
 wrbtr type bseg-wrbtr,
 xref1 type bseg-xref1,
 kunnr type kna1-kunnr, " sarang
 bschl type bseg-bschl,
 hkont type bseg-hkont,
 end of ty_cust.
types : begin of ty_bp,
 kunnr type vbak-kunnr,
 bukrs type bseg-bukrs,
 budat type bkpf-budat,
 end of ty_bp.
types : begin of ty_kna1,
 kunnr type kna1-kunnr,
 name1 type kna1-name1,
 ort01 type kna1-ort01,
 end of ty_kna1.
types : begin of ty_lst,
 vbeln type vbrk-vbeln, " INVOICE NO
 fkart type vbrk-fkart,
 posnr type vbrp-posnr ,
 fkimg type vbrp-fkimg , " qty
 fkdat type vbrk-fkdat, " date
 vkorg type vbrk-vkorg, " sales org
 vtweg type vbrk-vtweg, " division
 spart type vbrk-spart, " distribution
 knumv type vbrk-knumv, " Number of the document condition
 matnr type vbrp-matnr ,
 med_prod type jptmg0-med_prod,
 kunrg type vbrk-kunrg,
 kwert type konv-kwert,
 kbetr type konv-kbetr,
 netwr type vbrk-netwr,
Address Details
 KUNRG type vbrk-KUNRG,
 name1 type kna1-name1,
 stras type kna1-stras,
 pstlz type kna1-pstlz,
***Added For Billing
 bukrs type vbrk-bukrs, " Company code
 xblnr type vbrk-xblnr, " Bill Ref
 ismpublication type mara-ismpublication,
Condition Type
 kschl_zj01 type konv-kschl,
 kschl_zdis type konv-kschl,
 kschl_znet type konv-kschl,
 kwert_zj01 type konv-kawrt, " Base Condition
 kwert_zdis type konv-kawrt,
 kwert_znet type konv-kawrt,
 adrnr type kna1-adrnr,
 end of ty_lst.
types : begin of ty_lst1,
 vbeln type vbrk-vbeln, " INVOICE NO
 fkart type vbrk-fkart,
 fkdat type vbrk-fkdat, " date
 fkimg type vbrp-fkimg, " qty
 kunrg type vbrk-kunrg, " Payer
 fkimg_1 type vbrp-fkimg, " qty
 fkimg_2 type vbrp-fkimg, " qty
 fkimg_3 type vbrp-fkimg, " qty
 fkimg_4 type vbrp-fkimg, " qty
 fkimg_5 type vbrp-fkimg, " qty
 matnr type vbrp-matnr,
 med_prod type jptmg0-med_prod,
 kwert type konv-kwert,
 kbetr type konv-kbetr,
 netwr type vbrk-netwr,
Address Details
 KUNRG type vbrk-KUNRG,
 name1 type kna1-name1,
 stras type kna1-stras,
 pstlz type kna1-pstlz,
***Added For Billing
 bukrs type vbrk-bukrs ,
 xblnr type vbrk-xblnr,
 ismpublication type mara-ismpublication,
****SPLIT FOR RATE
 kbetr_1 type konv-kbetr,
 kbetr_2 type konv-kbetr,
 kbetr_3 type konv-kbetr,
Condition Type
 kschl_zj01 type konv-kschl,
 kschl_zdis type konv-kschl,
 kschl_znet type konv-kschl,
 kwert_zj01 type konv-kawrt, " Base Condition
 kwert_zdis type konv-kawrt,
 kwert_znet type konv-kawrt,
 end of ty_lst1.
types : begin of ty_condition,
 kschl type konv-kschl, " Condition Type
 kwert type konv-kwert, " Condition Value
 knumv type konv-knumv, " Document Condi
 kposn type konv-kposn,
 kbetr type konv-kbetr, " Condition Rate
 end of ty_condition.
types : begin of ty_bkpf ,
belnr type bkpf-belnr,
gjahr type bkpf-gjahr,
bukrs type bkpf-bukrs,
end of ty_bkpf.
 Constants Begin with C_ *
*CONSTANTS: *
 Data Begin with W_ *
data : w_cnt type i .
*DATA : W_DMBTR TYPE BSID-DMBTR. " Open Value
*DATA : W_KWERT TYPE VBRP-FKIMG. " Invoice Value
*DATA : W_QTY_CON TYPE VBRP-FKIMG. " QTY
*DATA : W_TO_QTY_CON TYPE VBRP-FKIMG. " QTY
*DATA : W_DIFF TYPE BSID-DMBTR. " W_DIFF Bt Open & Invoice
*DATA : W_DMBTR_CR TYPE BSID-DMBTR. " Cr Value
*DATA : W_DMBTR_DR TYPE BSID-DMBTR. " Dr Value
*DATA : W_DMBTR_TO TYPE BSID-DMBTR. " Total Value
*DATA : W_KDGRP(2) .
*DATA : W_CNT_IS TYPE I.
*DATA : W_CNT_IS1 TYPE I.
*DATA : W_CNT_IS2 TYPE I.
*DATA : W_CNT_FIRST TYPE I.
*DATA : W_CNT_ITAB TYPE I.
*DATA : W_CNT_FIRST1(2).
*DATA : W_CNT_TAB(62),
 W_CNT_TAB_HEA(62),
*data: W_CNT_POS TYPE I.
Variable for balance window
data : w_open_bal type dmshb_x8,
 w_total_bf type dmshb_x8,
 w_sub_tot type dmshb_x8,
 w_total_co type dmshb_x8,
 w_bill_bal type dmshb_x8,
 w_drn_bal type dmshb_x8,
 w_othr_chr type dmshb_x8,
 w_total_bal type dmshb_x8,
 w_coll_bal type dmshb_x8,
 w_unsd_cr type dmshb_x8, "Unsold Credit
 w_inceve type dmshb_x8, "Incentive
 w_cr_nt type dmshb_x8. "Cr Note
data : w_pos type bseg-wrbtr. " Total Value
data : w_neg type bseg-wrbtr. " Total Value
data : w_du_start_date like sy-datum,
 w_du_end_date like sy-datum .
**vARIABLE DEFINED FOR CONSOLIDATED WINDOW
data : w_prod_cnt type i .
data : w_prod_ch(2) .
data : w_prod_rate type i .
 Infotypes ( HR Module Specific) *
*INFOTYPES : *
 Internal tables Begin with IT_ *
data : it_bp type table of ty_bp with header line,
 it_bp1 type table of ty_bp with header line,
 it_bp2 type table of ty_bp with header line,
 it_bp3 type table of ty_bp with header line,
 it_kna1 type table of ty_kna1 with header line,
 it_cust type table of ty_cust with header line,
 it_cust1 type table of ty_cust with header line,
 it_bkpf type table of ty_bkpf with header line,
 it_cust2 type table of ty_cust with header line,
 it_cust3 type table of ty_cust with header line.
data : it_pos like rfposxext occurs 1 with header line,
it_check like rfposxext occurs 1 with header line,
it_pos_bc1 like rfposxext occurs 1 with header line,
it_pos_bc like rfposxext occurs 1 with header line,
it_pos_nc like rfposxext occurs 1 with header line,
 it_pos1 like rfposxext occurs 1 with header line,
 it_sec like rfposxext occurs 1 with header line.
data : it_bal like rfposxext occurs 1 with header line.
data : w_text(100) type c.
data : w_cnt1(3).
data : l_date like mara-ismpublperiod .
data : p_date1 like jkpaz-jkpavon.
data : l_day_c(2).
data : l_month_c(2).
data : l_base_yr_c(4).
data : w_text1(100) type c.
data : w_text2(100) type c.
 Field Symbols Begin with FS_ *
*FIELD-SYMBOLS: *
field-symbols: type ty_condition.
 Insert *
*INSERT : *
 Select Options Begin with SO_ *
selection-screen skip 1.
selection-screen: begin of block b1 with frame title text-001.
select-options : so_bukrs for vbrk-bukrs no intervals no-extension obligatory .
select-options : so_kunrg for vbrk-vkorg no intervals no-extension obligatory,
 so_vkbur for knvv-vkbur no intervals no-extension ,
 so_fkdat for bsid-budat no-extension obligatory ,
 so_bdat1 for bsid-budat no-display ,
 so_bdat3 for bsid-budat no-display ,
 so_kunnr for kna1-kunnr no-display.
selection-screen: end of block b1.
 Parameters Begin with PR_ *
*PARAMETERS : *
selection-screen begin of block b3 with frame title text-003.
parameters pr_3 radiobutton group rad1.
parameters pr_4 radiobutton group rad1.
selection-screen end of block b3.
selection-screen begin of block b2 with frame title text-002.
parameters pr_1 radiobutton group rad.
parameters pr_2 radiobutton group rad.
selection-screen end of block b2.
*INITIALISATION :
 At selection-screen *
*AT SELECTION-SCREEN.
 S T A R T O F S E L E C T I O N *
start-of-selection.
if pr_3 is not initial.
Code commented/added by Praveen on 20.07.2006
 SELECT kunnr INTO CORRESPONDING FIELDS OF TABLE it_bp1 FROM knvv
 WHERE vkorg IN so_kunrg
 AND kunnr GE '0004000000'
 AND kunnr LE '0004999999'.
 select kunnr into corresponding fields of table it_bp1 from knvv
 where vkorg in so_kunrg
 and aufsd <> '01'
 and kunnr ge '0004000000'
 and kunnr le '0004999999' .
 and
 PLTYP ne 'HB'.
*ends here
endif.
if pr_4 is not initial.
 clear so_kunnr[].
 clear so_kunnr.
 so_kunnr-sign = 'I'.
 so_kunnr-option = 'BT'.
 so_kunnr-low = '0001000000'.
 so_kunnr-high = '0001999999'.
 append so_kunnr.
 so_kunnr-sign = 'I'.
 so_kunnr-option = 'BT'.
 so_kunnr-low = '0002000000'.
 so_kunnr-high = '0002999999'.
 append so_kunnr.
 so_kunnr-sign = 'I'.
 so_kunnr-option = 'BT'.
 so_kunnr-low = '0007000000'.
 so_kunnr-high = '0007999999'.
 append so_kunnr.
Code commented/added by Praveen on 20.07.2006
 select kunnr into corresponding fields of table it_bp1 from knvv
 where vkorg in so_kunrg and
 kunnr in so_kunnr and
 vkbur in so_vkbur.
 AND kunnr GE '0001000000'
 AND kunnr LE '0001999999' .
 select kunnr into corresponding fields of table it_bp1 from knvv
 where vkorg in so_kunrg and
 aufsd <> '01' and
 kunnr in so_kunnr and
 vkbur in so_vkbur.
 AND kunnr GE '0001000000'
 AND kunnr LE '0001999999' .
ends here
endif.
if pr_1 = 'X'.
 perform cust_prog.
 perform cust_line.
 perform f001_progressive_total.
 perform f002_item_data.
elseif pr_2 = 'X'.
 perform cust_line.
 perform f002_item_data.
endif.
*& Form cust_prog
 text
form cust_prog.
clear it_bp3[].
p_date1 = so_fkdat-low.
call function 'Z_VF053_DATE_GET_YEAR_MONTH'
 exporting
 i_date = p_date1
 importing
 e_dd = l_day_c
 e_month = l_month_c
 e_year = l_base_yr_c.
ranges so_bdat2 for bsid-budat.
clear : so_bdat3[].
if l_day_c > 01.
 l_day_c = '01'.
 concatenate l_base_yr_c l_month_c l_day_c into l_date.
 so_bdat2-low = l_date.
 so_bdat2-high = so_fkdat-low - 1.
else.
 so_bdat2-low = '00000000'.
 so_bdat2-high = '00000000'.
endif.
so_bdat2-sign = 'I'.
so_bdat2-option = 'BT'.
append so_bdat2 to so_bdat3.
select kunnr bukrs budat into corresponding fields of table it_bp3 from bsid
 for all entries in it_bp1
 where bukrs in so_bukrs
 and kunnr = it_bp1-kunnr
 and budat in so_bdat3.
select kunnr bukrs budat
appending corresponding fields of table it_bp3
from bsad
for all entries in it_bp1
where bukrs in so_bukrs
and kunnr = it_bp1-kunnr
and budat in so_bdat3.
sort it_bp3 by kunnr .
delete adjacent duplicates from it_bp3 comparing kunnr.
sort it_bp3 by kunnr .
clear w_total_bf.
endform. "cust_prog
*& Form cust_line
 text
form cust_line.
clear it_bp[].
select kunnr bukrs budat
into corresponding fields of table it_bp
from bsid
for all entries in it_bp1
where bukrs in so_bukrs
and kunnr = it_bp1-kunnr
and budat in so_fkdat.
select kunnr bukrs budat
appending corresponding fields of table it_bp
from bsad
for all entries in it_bp1
where bukrs in so_bukrs
and kunnr = it_bp1-kunnr
And budat in so_fkdat.
sort it_bp by kunnr .
delete adjacent duplicates from it_bp comparing kunnr.
sort it_bp by kunnr .
endform. "cust_line
*& Form f001_progressive_total
 text
form f001_progressive_total.
if not it_bp3[] is initial.
 clear : w_text ,w_cnt,p_date1,l_base_yr_c, l_month_c,l_day_c,l_date.
 w_cnt1 = sy-tabix .
 CONCATENATE w_cnt1 ' Feaching Data ' INTO w_text.
 CALL FUNCTION 'SAPGUI_PROGRESS_INDICATOR'
 EXPORTING
 text = w_text.
 ranges so_bdat2 for bsid-bldat.
 clear : so_bdat1[].
 p_date1 = so_fkdat-low.
 call function 'Z_VF053_DATE_GET_YEAR_MONTH'
 exporting
 i_date = p_date1
 importing
 e_dd = l_day_c
 e_month = l_month_c
 e_year = l_base_yr_c.
 if l_day_c > 01.
 l_day_c = '01'.
 concatenate l_base_yr_c l_month_c l_day_c into l_date.
 so_bdat2-low = l_date.
 so_bdat2-high = so_fkdat-low - 1.
 else.
 l_day_c = so_fkdat-low.
 so_bdat2-low = l_date.
 so_bdat2-high = '00000000'.
 endif.
 so_bdat2-sign = 'I'.
 so_bdat2-option = 'BT'.
 append so_bdat2 to so_bdat1.
 export so_bdat1 to memory id 'DATE1'.
 export it_bp3 to memory id 'IT_BP3'.
 clear : so_bdat1, it_bp3.
 submit z_rfitemar1
 with x_aisel = 'X'
 with x_norm = 'X'
 with dd_bukrs-low = so_bukrs-low "#EC *
 and return.
 clear : it_pos[], it_pos .
 import it_pos from memory id 'zit_pos'.
 free memory id 'zit_pos'.
 delete it_pos where blart <> 'DZ'.
Here Plz Clear all the varible to avoid overlap
 clear : w_open_bal,w_du_start_date,w_du_end_date.
 select belnr bukrs gjahr into corresponding fields of table it_bkpf
 from bkpf for all entries in it_pos where belnr = it_pos-belnr and gjahr = it_pos-gjahr
and bukrs = it_pos-bukrs and xreversal = ' '.
endif.
 loop at it_pos.
 clear it_bkpf.
 read table it_bkpf with key bukrs = it_pos-bukrs belnr = it_pos-belnr gjahr = it_pos-gjahr.
 if sy-subrc eq 0.
 append it_pos to it_check.
 endif.
 endloop.
 it_pos[] = it_check[].
***opening bal
since runtime error is coming while summing the alternate way is being used ... done by jayakumar on 11 10 06
 LOOP AT it_pos .
 SUM .
 w_open_bal = it_pos-dmshb .
 EXIT .
 ENDLOOP .
 loop at it_pos .
 read table it_cust3 with key belnr = it_pos-belnr.
 it_pos-dmshb = it_cust3-wrbtr.
 w_open_bal = w_open_bal + it_pos-dmshb .
 endloop .
 if w_open_bal < 0 .
 w_open_bal = w_open_bal * -1.
 endif.
 w_total_bf = w_total_bf + w_open_bal.
endif.
write :20 'Progressive Total B/F -
' ,106 w_total_bf.
skip 1 .
endform. "f001_progressive_total
*& Form f002_item_data
 text
form f002_item_data.
if not it_bp[] is initial.
 select * into corresponding fields of table it_kna1 from kna1
 for all entries in it_bp
 where kunnr = it_bp-kunnr .
 export so_fkdat to memory id 'DATE'.
 export it_bp to memory id 'IT_BP'.
 clear : so_fkdat, it_bp.
 submit z_rfitemar1
 with x_aisel = 'X'
 with x_norm = 'X'
 with dd_bukrs-low = so_bukrs-low "#EC *
 and return.
 DELETE it_pos WHERE u_xreversal <> ' '.
 clear : it_pos[], it_pos .
 import it_pos from memory id 'zit_pos'.
 free memory id 'zit_pos'.
 delete it_pos where blart <> 'DZ'.
 sort it_pos by belnr.
 APPEND LINES OF it_pos TO it_pos1.
 DELETE ADJACENT DUPLICATES FROM it_pos COMPARING belnr." commented by sarang
 clear : it_cust[], it_cust.
 if not it_pos[] is initial.
 select belnr wrbtr xref1 kunnr bschl
 into corresponding fields of table it_cust
 from bseg
 for all entries in it_pos
 where belnr = it_pos-belnr
 and bukrs = it_pos-bukrs
 and gjahr = it_pos-gjahr
 and bschl in ('15','40') .
 it_cust2[] = it_cust[].
 delete it_cust where bschl ne 15.
 delete it_cust2 where bschl ne 40.
 sort it_pos by konto.
 else.
 write : 20 '**No Transaction to Display**'.
 endif.
 DELETE it_pos WHERE u_xreversal = 'X'.
 tables bkpf.
 loop at it_pos.
 select single * from bkpf where belnr = it_pos-belnr and bukrs = it_pos-bukrs and gjahr = it_pos-gjahr and xreversal = ' '.
 if sy-subrc = 0.
 append it_pos to it_pos_bc1.
 endif.
 endloop.
 clear it_pos.
 it_pos[] = it_pos_bc1[].
 sort it_pos by konto belnr xref3.
 loop at it_pos.
 read table it_cust2 with key belnr = it_pos-belnr.
 on change of it_pos-konto or "IT_CUST2-xref1 or
 it_pos-belnr.
 it_pos_bc[] = it_pos[].
 delete it_pos_bc[] where konto ne it_pos-konto.
 delete it_pos_bc[] where belnr ne it_pos-belnr.
 loop at it_pos_bc.
 sum.
 exit.
 endloop.
 append it_pos_bc to it_pos_nc.
 endon.
 endloop.
 free it_pos.
 it_pos[] = it_pos_nc[].
 data : w_amt1 type bseg-dmbtr,
 w_amt2 type bseg-dmbtr.
 clear : w_amt1 , w_amt2.
 sort it_pos by budat belnr konto.
 data : w_ch(5) type c,
 w_i type i.
 w_i = 0.
 loop at it_pos where shkzg = 'H' .
 clear w_text.
 w_i = w_i + 1 .
 w_ch = w_i.
 read table it_cust with key belnr = it_pos-belnr kunnr = it_pos-konto.
 read table it_kna1 with key kunnr = it_pos-konto .
 CONCATENATE it_kna1-name1 INTO w_text.
 w_text = it_kna1-name1.
 CONDENSE w_text NO-GAPS.
 write : / w_ch left-justified , 07 it_pos-budat ,20 it_pos-belnr(10) ,31 it_pos-konto(10),42 w_text(60).
 read table it_cust2 with key belnr = it_pos-belnr.
 if it_cust2-xref1 = 'Cash Payment' or it_cust2-xref1 = 'Cash'.
 if it_pos-dmshb < 0 .
 it_pos-dmshb = it_pos-dmshb * -1 .
 it_pos-dmshb = it_cust2-wrbtr.
 else. "+PM28072006
 it_pos-dmshb = it_pos-dmshb * -1 . "+PM28072006
 it_pos-dmshb = it_cust2-wrbtr.
 endif.
 write : 72 it_pos-dmshb.
 w_amt1 = w_amt1 + it_pos-dmshb.
 else.
 if it_pos-dmshb < 0 .
 it_pos-dmshb = it_pos-dmshb * -1 .
 it_pos-dmshb = it_cust2-wrbtr.
 else. "+PM28072006
 it_pos-dmshb = it_pos-dmshb * -1."+PM28072006
 it_pos-dmshb = it_cust2-wrbtr.
 endif.
 write : 87 it_pos-dmshb.
 w_amt2 = w_amt2 + it_pos-dmshb.
 endif .
 endloop .
else.
 write : 20 '**No Transaction to Display**'.
endif.
clear : it_cust1[] ,w_pos .
it_cust1[] = it_cust[] .
sort it_cust1 by wrbtr.
delete it_cust1 where xref1 <> 'Cash Payment' .
delete it_cust1 where xref1 <> 'Cash' .
loop at it_cust1.
 sum .
 w_pos = it_cust1-wrbtr .
 exit .
endloop .
clear :it_cust1[],w_neg .
it_cust1[] = it_cust[] .
sort it_cust1 by wrbtr.
delete it_cust1 where xref1 = 'Cash Payment' .
delete it_cust1 where xref1 = 'Cash' .
loop at it_cust1.
 sum .
 w_neg = it_cust1-wrbtr .
 exit .
endloop .
if w_pos < 0.
 w_pos = w_pos * -1 .
else. "+PM28072006
 w_pos = w_pos * -1. "+PM28072006
endif.
if w_neg < 0.
 w_neg = w_neg * -1 .
else. "+PM28072006
 w_neg = w_neg * -1. "+PM28072006
endif.
write sy-uline(125) .
write : /20 'Total Collection Amount -
>'.
write : 76 w_amt1 ,91 w_amt2.
w_sub_tot = w_amt1 + w_amt2.
if w_sub_tot < 0.
 w_sub_tot = w_sub_tot * -1.
endif.
write : 106 w_sub_tot.
if pr_1 = 'X'.
 w_total_co = w_total_bf + w_sub_tot.
 if w_total_co < 0.
 w_total_co = w_total_co * -1.
 endif.
 write : /20 'Progressive Total C/O -
>'.
 write : 106 w_total_co.
endif.
write sy-uline(125) .
endform. "f002_item_data
 ENDIF .
*END-OF-SELECTION.
 E N D O F S E L E C T I O N *
 At line selection *
*AT LINE-SELECTION.
 User Command Processing *
*AT USER-COMMAND.
 Top Of Page *
top-of-page.
select single * from t001 where bukrs = so_bukrs-low .
select single * from adrc where addrnumber = t001-adrnr . "EC *
write : /05 t001-butxt.
CONCATENATE adrc-house_num1 '-' adrc-street INTO w_text1.
CONCATENATE adrc-city1 '-' adrc-post_code1 INTO w_text2.
WRITE : /05 w_text1 .
WRITE : /05 w_text2 .
write : /05 'Sales Organisation:', so_kunrg-low.
write : /05 'Sales Office:', so_vkbur-low.
skip 1.
if pr_3 = 'X'.
 write : /05 'Agent Circulation Collection Statement From ' , so_fkdat-low , ' to ' ,so_fkdat-high .
else.
 write : /05 'Advertisement Collection Statement From ' , so_fkdat-low , ' to ' ,so_fkdat-high .
endif.
if pr_3 = 'X'.
 write :/ sy-uline(125) .
 write :/07 'Date' ,20 'Doc No',31 'Code' ,42 'Agent Name & Place',84 'BY CASH' ,97 'BY CHQ/DD' ,115 'Prog. Total'.
 write :/ sy-uline(125) .
else.
 write :/ sy-uline(125) .
 write :/07 'Date' ,20 'Doc No',31 'Code' ,42 'Advertisers Name' , 84 'BY CASH' ,97 'BY CHQ/DD' ,115 'Prog. Total'.
 write :/ sy-uline(125) .
endif .
 End Of Page *
END-OF-PAGE.END-OF-PAGE.

Hello Selvi
There is no need to use two subroutine. Actually, this would be bad programming. Instead use a switch for your subroutine which determines whether the calculation should be done for the actual and the previous day, e.g.:
PERFORM do_calculation
 USING 'X' " 'X' = calculate for previous day as well
 USING p_date " current date
 CHANGING gt_list. " itab with list data
And that's how the subroutine could look like:
FORM do_calculation
 USING VALUE(ud_calculate_previous_day) TYPE c
 VALUE(ud_date) TYPE d
 CHANGING ct_list TYPE <table type>.
* define local data
DATA:
 ld_date_prev TYPE d,
 lt_list_prev TYPE <table type>. " list for previous day
* Do the calculations for the current day
IF ( ud_calculate_previous_day = 'X' ).
 ld_date_prev = ud_date - 1.
 PERFORM do_calculation
 USING ' ' " ' ' = no calculation for previous day
 ld_date_prev
 CHANGING lt_list_prev. " itab with list data
ENDIF.
* Post-processing after calculation for both days
ENDFORM.
Regards
Uwe

Passing parameters to subroutine

Hi,
I have a subroutine which is being called from the 2 PAI modules of the different screens.The subroutine has two queries which are the same for both the modules , the only difference I want is that after the queries there is a call to a new screen.I want different screens to be called for both the PAI modules.Please suggest what should I pass to the subroutine so that different screens can be called based on the PAI module.

Hi Sunil ,
You can use the same subroutine along with the using .
You need to call the same subroutine with different interface parameter.
In the interface parameter you need to specify the screen no (For example).
Check the code as a example --
perform screen using '100'.
perform screen using '101'.
*&      Form SCREEN
*       text
*      -->P_0006   text
form SCREEN using    value(p_scrno).
call screen p_scrno.
endform.                    " SCREEN
Regards
Pinaki

Invoice split based only on payer, material, invoice date

Dear Friends,
I have an issue which I don't know how to move further..
Task: avoid Invoice split during collective invoice creation in VF04. Invoice should be grouped by: payer, material, invoicing date.
What I'm doing: clearing all fields which could cause invoice split in copy routine rv60c903 ( this one is used for this type of invoices ) in VBRK. Then changing partners - sold-to, ship-to, bill-to in enhancement., so that they are equal for all invoices with the same payer party. And also VBRK-ZUKRI is filled accordingly with the grouping parameters: VBKD-PERFK and VBRP-MATNR.
What I can't understand: when I run SIMULATE in VF04, the invoices are grouped correctly, BUT when I run the actual Collective Billing button, for each delivery a new billing document is created.. I can't understand this!
Thanks a lot in advance!

Hi
As Madhu tells you, check your settings in customizing (tcodes VTFA and VTFL). Second, take in account always the SAP Note 11162 - Invoice split criteria in billing document and related notes. Finally, set your own algorithm to rule the splitting defining ZUK structure to determine the value of VBRK-ZUKRI (remember that this field is a char 40) in your own VOFM subroutine.
I hope this helps you
Regards
Eduardo

Subroutine parameters ..by default pass by value or pass by ref

how parameters pass ? value or ref
if we use changing in both perform and form...will it become CALL BY REF?
Message was edited by:
balaji velpuri

Hi,
The Parameter Interface
The USING and CHANGING additions in the FORM statement define the formal parameters of a subroutine. The sequence of the additions is fixed. Each addition can be followed by a list of any number of formal parameters. When you call a subroutine, you must fill all formal parameters with the values from the actual parameters. At the end of the subroutine, the formal parameters are passed back to the corresponding actual parameters.
Within a subroutine, formal parameters behave like dynamic local data. You can use them in the same way as normal local data objects that you would declare with the DATA statement. They mask global data objects with the same name. The value of the parameters at the start of the subroutine is the value passed from the corresponding actual parameter.
Subroutines can have the following formal parameters:
Parameters Passed by Reference
You list these parameters after USING or CHANGING without the VALUE addition:
FORM <subr> USING ... <pi> [TYPE <t>|LIKE <f>] ...
CHANGING ... <pi> [TYPE <t>|LIKE <f>] ...
The formal parameter occupies no memory of its own. During a subroutine call, only the address of the actual parameter is transferred to the formal parameter. The subroutine works with the field from the calling program. If the value of the formal parameter changes, the contents of the actual parameter in the calling program also change.
For calling by reference, USING and CHANGING are equivalent. For documentation purposes, you should use USING for input parameters which are not changed in the subroutine, and CHANGING for output parameters which are changed in the subroutine.
To avoid the value of an actual parameter being changed automatically, you must pass it by value.
Input Parameters That Pass Values
You list these parameters after USING with the VALUE addition:
FORM <subr> USING ... VALUE(<pi>) [TYPE <t>|LIKE <f>] ...
The formal parameter occupies its own memory space. When you call the subroutine, the value of the actual parameter is passed to the formal parameter. If the value of the formal parameter changes, this has no effect on the actual parameter.
Output Parameters That Pass Values
You list these parameters after CHANGING with the VALUE addition:
FORM <subr> CHANGING ... VALUE(<pi>) [TYPE <t>|LIKE <f>] ...
The formal parameter occupies its own memory space. When you call the subroutine, the value of the actual parameter is passed to the formal parameter. If the subroutine concludes successfully, that is, when the ENDFORM statement occurs, or when the subroutine is terminated through a CHECK or EXIT statement, the current value of the formal parameter is copied into the actual parameter.
If the subroutine terminates prematurely due to an error message, no value is passed. It only makes sense to terminate a subroutine through an error message in the PAI processing of a screen, that is, in a PAI module, in the AT SELECTION-SCREEN event, or after an interactive list event.
Specifying the Type of Formal Parameters
Formal parameters can have any valid ABAP data type. You can specify the type of a formal parameter, either generically or fully, using the TYPE or LIKE addition. If you specify a generic type, the type of the formal parameter is either partially specified or not specified at all. Any attributes that are not specified are inherited from the corresponding actual parameter when the subroutine is called. If you specify the type fully, all of the technical attributes of the formal parameter are defined with the subroutine definition.
The following remarks about specifying the types of parameters also apply to the parameters of other procedures (function modules and methods). If you have specified the type of the formal parameters, the system checks that the
corresponding actual parameters are compatible when the subroutine is called. For internal subroutines, the system checks this in the syntax check. For external subroutines, the check cannot occur until runtime. By specifying the type, you ensure that a subroutine always works with the correct data type. Generic formal parameters allow a large degree of freedom when you call subroutines, since you can pass data of any type. This restricts accordingly the options for processing data in the subroutine, since the operations must be valid for all data types. For example, assigning one data object to another may not even be possible for all data types. If you specify the types of subroutine parameters, you can perform a much wider range of operations, since only the data appropriate to those operations can be passed in the call. If you want to process structured data objects component by component in a subroutine, you must specify the type of the parameter.
Regards,
Bhaskar

[PAI] Refresh a screen field within PAI

Hi,
During the PAI process, I would like to refresh the content of a screen field (so that it is calculated automatically from the value of another field).
Indeed, the user would greatly benefit from this field condidering the checks performed during the PAI.
I tried the FM 'DYNP_VALUES_UPDATE' but without success...
Has someone another idea ?
Thanks in advance.
Best regards,
Guillaume

Hi,
Thanks for your insights !
I have 2 fields on the screen : my_source_field and my_pourcent.
Here is the code :
PROCESS AFTER INPUT.
MODULE exit AT EXIT-COMMAND.
CHAIN.
 FIELD my_source_field MODULE calculate_%.
ENDCHAIN.
CHAIN.
 ... lot of checks here, where the user requires the value of a % mininum
ENDCHAIN.
and in the calculate_% subroutine :
IF my_source_field <> 0.
 CLEAR my_pourcent.
 my_pourcent = ( k_%_mini * 100 ) / my_source_field.
* Updating screen immediately
 CLEAR : wt_update.
 REFRESH : wt_update.
 wt_update-fieldname = 'MY_SOURCE_FIELD'.
 wt_update-fieldvalue = my_source_field.
 APPEND wt_update.
 CALL FUNCTION 'DYNP_VALUES_UPDATE'
 EXPORTING
 dyname = sy-cprog
 dynumb = sy-dynnr
 tables
 dynpfields = wt_update
 EXCEPTIONS
 INVALID_ABAPWORKAREA = 1
 INVALID_DYNPROFIELD = 2
 INVALID_DYNPRONAME = 3
 INVALID_DYNPRONUMMER = 4
 INVALID_REQUEST = 5
 NO_FIELDDESCRIPTION = 6
 UNDEFIND_ERROR = 7
 OTHERS = 8.
 IF sy-subrc <> 0.
 ENDIF.
ENDIF.
Any idea ?
Best regards,
Guillaume
Message was edited by: Guillaume Garcia

Payer determination for Billing

Hi gurus,
we have following situation
normally when we create a billing document the payer will copied out of the sales document. However, we have cases in which the payer is not the same as the SP, SH and BP but is at the same time a customer which has a different payer as well.
e.g..
Customer 1000 -
> Payer 710
Customer 710 -
> Payer 1
Result must be creating an sales order for Customer 1000 billing document will have automatically payer 1. I could not find any user exits. If anybody can help?
Any information are really appreciated.
Thanks

Hi,
Check the subroutines in the include RV60AFZD. You have some comments.
Regards,
Eduardo

How to modify changes of table control data in PAI

I have a table control where the columns are brought by dict fields.I am able to bring data into table control through an itab.
Now what i want is whenever user edits data in table control and clicks on save button the corresponding changes should be made in database.
For this according to my understanding we need to (in PAI) modify the changes in itab from the table control and then in SY-UCOMM of SAVE button we need to update in database table using itab.
For this , I am not able to write code for modifying the changes in itab from table control. Here is my code below.Please tell me how to do this.
PROCESS BEFORE OUTPUT.
MODULE FILL_DATA.
LOOP AT ITAB INTO ZEMPLOYEE_MASTER WITH CONTROL EMPTABLE CURSOR
EMPTABLE-CURRENT_LINE.
ENDLOOP.
MODULE STATUS_0001.
PROCESS AFTER INPUT.
LOOP AT ITAB.
   MODULE MODIFY_ITAB.
ENDLOOP.
MODULE USER_COMMAND_0001.
REPORT ZDATA_FORM1.
TABLES: ZEMPLOYEE_MASTER.
CONTROLS EMPTABLE TYPE TABLEVIEW USING SCREEN 0001.
data: begin of itab occurs 0,
       emp_no like zemployee_master-emp_no,
       name like zemployee_master-name,
       city like zemployee_master-city,
      end of itab,
      rowno TYPE I VALUE 1.
*&      Module STATUS_0001 OUTPUT
*       text
MODULE STATUS_0001 OUTPUT.
* SET PF-STATUS 'xxxxxxxx'.
* SET TITLEBAR 'xxx'.
ENDMODULE.                 " STATUS_0001 OUTPUT
*&      Module USER_COMMAND_0001 INPUT
*       text
MODULE USER_COMMAND_0001 INPUT.
MESSAGE 'Inside INPUT' TYPE 'I'.
CASE SY-UCOMM.
   WHEN 'SAVE'.
     UPDATE zemployee_master.
   WHEN 'EXIT'.
     LEAVE PROGRAM.
ENDCASE.
ENDMODULE.                 " USER_COMMAND_0001 INPUT
*&      Module fill_data OUTPUT
*       text
MODULE fill_data OUTPUT.
select emp_no name city from zemployee_master into TABLE itab ORDER BY emp_no.
Describe table itab lines EMPTABLE-LINES.
ENDMODULE.                 " fill_data OUTPUT
*&      Module modify_itab INPUT
*       text
MODULE modify_itab INPUT.
* MODIFY itab from zemployee_master index
* MESSAGE 'Inside modify_itab' TYPE 'I'.
ENDMODULE.                 " modify_itab INPUT

Hi
In the following module of your code
MODULE modify_itab INPUT.
MODIFY itab from zemployee_master index tc-current_line " Where TC is the name of the Table control on the Screen
ENDMODULE.
Table control data gets refreshed on *enter*
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/2165e990-0201-0010-5cbb-b5c2ad436140
Cheerz
Ramchander Rao.K

How to call Subroutines,Standard Text & using Internal Table in SmartForm

Hi all,
need help in the following areas.Its very urgent!
1.How to CAll Subroutines in Smart Forms
2.How to CAll Standard Text in Smart Forms
Situation:
We have an Internal Table T_SALES with all the data which am going to display in the smartform,How to retrive data from an internal table in Smart forms
Any Help in this direction would be highly appreciated.
Regards
Ramu

Hi,
When you are using quantity or currency fields, you have to mentiong the reference fileds in a tab called CURRENCY/QUANTITY FILEDS in the GLOBAL DATA node.
Specifying a Currency or Quantity Reference
Use
In the ABAP Dictionary, you can assign a currency or quantity field to a table field. In the output of these fields, the system can then insert the relevant currency or unit:
·        If the value field is in the same table as the corresponding currency or quantity field, the system recognizes the reference automatically, and formats the value field according to the currency or unit in the assigned field.
·        If the value field is in a different table from the currency or quantity field, the system cannot recognize this reference automatically.
In the second case, you must indicate this reference to the system in the form, to ensure that the value field is formatted correctly.
Procedure
You want to assign a currency or quantity field in one table (for example, CURTAB) to a value field in another table (for example, VALTAB).
       1.      Create the reference to the currency field by entering the following values:
-         Field Name: VALTAB-VALUE, if this is the value field of VALTAB that you want to display.
-         Reference Field: CURTAB-CURRENCY, which is the currency field of CURTAB.
       2.      Under Data Type, specify whether the data type is a currency or quantity.
Result
In the output of the PDF-based print form, the system formats the value field VALTAB-VALUE according to the assigned value in the currency or quantity field of the global variable CURTAB-CURRENCY.
Thanks and Regards,
Bharat Kumar Reddy.V
Message was Added by: Bharat Reddy V
Message was Added by: Bharat Reddy V

PBO/ PAI

Hi folks,
              We generally know that we write " SELECT Statements " in PBO.
               But if i write SELECT STATEMENT IN PAI. then wht will be the outcome and if there is any example plz suggest.
thnking u.
   regards,
   satya.

In PAI of the screen 9100 write as belwo
module USER_COMMAND_9001 input.
CASE sy-ucomm.
    WHEN 'EXIT' or 'CANC'.
* free the container
* leave program.
      LEAVE PROGRAM.
    when 'BACK'.
* free ALV grid
      set screen '0'.
      leave screen.
* This leaves the program but you may need to re-call the
* transaction to go back to the original screen
When 'ME32K'.
   CALL TRANSACTION 'ME32K' .
Similarly u can write ur query or anything depending
upon ur fcode created in the screen painter. This part of teh code will work only when u press the button after the display.
    when others.
ENDCASE.
endmodule.                 " USER_COMMAND_9001 INPUT
module STATUS_9001 output.
*enable the back and cancel buttons
SET PF-STATUS 'Z_TEMPLATE_STATUS'.
SET TITLEBAR 'ZTITLE'.
* This form create the Docking container and the ALV grid.
perform f9000_objects_create.
Hope this solves ur query.
In PBO u will be setting the PF-STATUS and u have to specify the FCODE for
BACK, Cancel and Exit.

Structure is not getting filled in the subroutine

Hi Gurus,
I'm working on a Z-report ZMB52 for fetching Reserved Stock and showing it in a column.
The following code in a subroutine I've written for the same.
DATA: GS_RESB LIKE LINE OF GT_RESB.
    CLEAR: BESTAND.
    IF BESTAND[] IS NOT INITIAL.
      SELECT MATNR
             BDMNG
        FROM RESB
        INTO TABLE GT_RESB
        FOR ALL ENTRIES IN BESTAND[]
        WHERE MATNR EQ BESTAND-MATNR.
        IF SY-SUBRC EQ 0.
          SORT GT_RESB BY MATNR.
          LOOP AT BESTAND.
           READ TABLE GT_RESB INTO GS_RESB WITH KEY MATNR = BESTAND-MATNR. "BINARY SEARCH.
             IF SY-SUBRC EQ 0.
               MODIFY BESTAND TRANSPORTING BDMNG WHERE MATNR = BESTAND-MATNR.
             ENDIF.
             CLEAR: BESTAND, GS_RESB.
          ENDLOOP.
        ENDIF.
     ENDIF.
When I debug, I can see that the structure GS_RESB is not getting filled through the READ TABLE statement. However, GT_RESB shows the data.
Could you please tell me where am I going wrong and a way to correct it?
Thanks in Advance!
Best Regards,
Ashutosh.

Hi Joshi
You can use
LOOP AT GT_RESB INTO GS_RESB WHERE MATNR = BESTAND-MATNR. "BINARY SEARCH.
              MODIFY BESTAND TRANSPORTING BDMNG WHERE MATNR = BESTAND-MATNR.
            CLEAR: BESTAND, GS_RESB.
ENDLOOP.
And please check in debug BESTAND-MATNR .
Best regards.

Want to change payer and update credit limit data with out delete documents

Hi Expert,
I have a problem that user feed 50-60 documents ( Sale order & delivery ) with wrong payer. Now we want to change payer and shift credit limit data ( open sale order , open delivery ) from old payer to new payer is any option for this.
Thanks in advance
Regards
Suresh Kumar

Hi
Ideally in your case, you may have to delete the delivery documents and then recreate the deliveries after updating the payer in the sales order. This is because the source for the partner function in Delivery will be mostly updated as "from sales order" and hence it is not possible to change the payer in the delivery document.
In this case, you have to first find out the relevant delivery documents and delete them
Then you can change the partners in the sales order
Finally you can recreate the delivery documents.
However I would request you to do the following test before following this.
In the SO, change the payer without deleting the delivery. If the partner in delivery gets changed automatically then it is fine. You can ensure this by checking the delivery in DISPLAY mode.
If payer is not changing automatically then go to delivery in CHANGE mode and now check it. If the payer changes automatically now, you are spared with the pain of deleting and recreating deliveries once again.
If both of them fails, then the only way is to delete deliveries first, change payer in SO and then recreate deliveries.
This is applicable only if PGI is not yet done.

PAI is NOT trigger for ALV in subscreen

Hi, All
Currently, I am using ALV object to output ALV report in one SUBSCREEN.
When I double-click, the PAI is not trigger. But just go into double-click event directly.
However, If I use AVL function or object to output in NORMAL screen, PAI is trigger after double click.
SY-UCOMM is like %_GC 920 3

Hello Ocean
The ALV grid is a special control in terms that all the events are already pre-registered at the control (method SET_REGISTERED_EVENTS). This means that as soon as you define an event handler method and SET HANDLER for the corresponding event your application can deal with this event.
You can register all events of the ALV grid as application events (i.e. after any event handling PAI of the screen is triggered) at the CONSTRUCTOR method:
I_APPL_EVENTS = 'X'
However, I prefer to use method CL_GUI_CFW=>SET_NEW_OK_CODE because it offers more flexibility to me:
Only those event where I need to trigger PAI after event handling are affected
By setting a new ok-code I can trigger a specific logic at PAI
Regards
Uwe

Customer Hierarchy Partner determination in a Sales Order using Payer ?

Dear SD Experts/Gurus
We use Customer Hierarchies extensively in Sales Orders for Pricing & Rebates and it all works fine.
The Hierarchy structure consists at the bottom level of a SoldTo linked to a Hierarchy Customer and many SoldTos can have the same Hierarchy Customer.
We set price conditions at the Hierarchy Customer and that all works fine.
We would like to change our Customer Hierarchy to link the Hierarchy Customer to the Payer rather than to all the individual SoldTos.
This is because we have many SoldTos linked to 1 Payer and this will allow us to have simpler Customer Hierarchy structures making it easier to setup and maintain.
I have changed the SAP configuration to do this and I can certainly maintain the Customer Hierarchy without any problem using transaction VDH1N.
But when I create a Sales Order, the Hierarchy Customer does not get pulled through to the Sales Order Header Partners based on the Order Payer and hence no Hierarchy Customer price conditions are pulled through.
Is what I'm trying to do possible in SAP ?
If so please advise how this can be achieved.
Thanks David
Edited by: David Steele on Apr 15, 2008 1:57 PM

Hello,
I have a similar requirement, although we are building the hierarchies directly in CRM (as we are with BP's in general), and I am using hierarchy category 01 - PRICING.
What I have found is that a sold-to BP must:
1. be assigned to a hierarchy node
2. appear TWICE (!!!) in the document part.det.procedure, once in partner function 000001 (sold to) and again in partner function 00000121 (Authorized partner: sold to).
When the sold to customer exists in both functions within the document, I am able to determine the hierarchy node properly.
Now, my question is, can anyone guess why the main partner (sold to) must appear twice??? or, is this an error in my customizing?
Thank you in advance for your help, and I do hope my observation can help others find a solution.
Regards,
Allon
PS in terms of customizing, I used the following:
partner function 00000001 - sold to
partner function 00000121 - Auth. Partner: Sold-to Party
access for Auth. Partner: 0017 - current partner: sold to *this copies the sold to partner into this partner*
partner function 00000076 - Hierarchy Node Partner
access for hier.node partner: CRM_PARTNER_G Pricing hierarchy
The last bit presupposes that the hierarchy is set up using hierarchy category '01 - pricing'.
Message was edited by:
Allon Riczker - Added configuration steps

Subroutine in PAI

Similar Messages

Maybe you are looking for