When you modularize source code, you place a sequence of ABAP statements in a module. Then, instead of placing all of the statements in your main program, you just call the module.When the program is generated, the source code in the modularization unit is treated as though it were actually physically present in the main program.
In this tutorial you will learn:
How-to: retrieve information from a SET (T-code GS01) sciccarelli / April 11, 2012 You created a “SET” and you want use the stored information when executing an ABAP program. SetIds are created in SAP using the transaction GS01. In the initial screen, specify a name for SetId; for example, for a list of vendors who are to be included in Automatic Purchase order creation, you can give a name “AUTO-PO-VENDORS”.
Need of Modularization
- Improve the structure of the program.
- Easy to read the code
- Easy to maintain the code
- Avoid redundancy and promotes code reuse
- Use of Macros
- Use of include files
- Subroutines
- Function Modules
SAP- ABAP Macro
If you want to reuse the same set of statements more than once in a program, you can include them in a macro.
You can only use a macro within the program in which it is defined, and it can only be called in lines of the program following its definition.
Macros can be useful for long calculations or complex WRITE statements.
Syntax
Macros can use Parameters &N where N = 1,2,3...
Example:-
Output: 2
Include Programs
Include Programs are solely for modularizing source code, and have no parameter interface. Include programs allow you to use the same source code in different programs. They can be useful if you have lengthy data declarations that you want to use in different programs.![Gs01 Gs01](http://sapsharks.com/wp-content/uploads/2018/11/Overheads_24.jpg)
Syntax
Points to Note
- Include programs cannot call themselves.
- Include programs must contain complete statements.
Subroutines
Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally. If you want a function to be reusable throughout the system, use a function module.
Syntax-
<Subroutine> = Name of the subroutine
<pass> = Parameters being passed
Types of Subroutines
- Internal
- Subroutine defined in same program being called.
- Can access all the data objects declared in the main ABAP/4 program.
- External
- Subroutine defined outside the program being called.
- Need to use the <pass> option or declare data objects in common parts of memory.
<subroutine> = Name of the subroutine
<pass> = Parameters being passed
![Sap Sap](/uploads/1/2/3/7/123750556/992647600.jpg)
Data declared in main program is automatically available.
External Subroutines
Points to Note
- Nested calls are allowed in subroutines (i.e. PERFORM within a FORM ... ENDFORM ).
- Recursive calls are also possible.
- To define local data, use the DATA statement after FORM . Each time you enter the subroutine, the data is recreated (with an initial value) and released at the end (from the stack).
- To define global data used within a subroutine, use the LOCAL statement after FORM . The values are saved when you enter the subroutine and then released at the end (from the stack)
Function Modules
Function Modules are general purpose ABAP/4 routines that anyone can use. Infact , there are a large number of standard function Modules available.
Function Modules are organized into Function Groups: Collections of logically related functions. A Function module always belongs to a Function Group.
Syntax- Important information Associated with Function Module
- Administration
- Import/Changing/Export parameters.
- Table Parameters/Exceptions.
- Documentation
- Source code - L<fgrp>U01 . <fgrp> is the Function Group
- Global Data - L<fgrp>TOP .Global data for the function group- Accessible across function modules in the function group.
- Main Program - SAPL<fgrp> . Contains the list of all the include files for that function group
To call a function module, use the CALL FUNCTION statement:
Function Groups
Function groups are containers for function modules. Infact, there are a large number of standard Function Groups. All of the function modules in a function group can access the global data of the group.
Like executable programs (type 1) and module pools (type M), function groups can contain screens, selection screens, and lists.
Points to Note
- Function Groups cannot be executed.
- The name of a function group can be up to 26 characters long.
- When you create a function group or function module, the main program and include programs are generated automatically.
- Function groups encapsulate data.
- Goto Transaction SE80.
- Select Program in the DropDown.
- Write the name of the Function Group That you want to create. Generally User made Function groups start with 'Z'. e.g. - <Z_FUNCTION_GROUP_NAME> . Hit Enter Key.
- Note that The TOP Include is create by default if the user checks the option of creating a TOP include.
- Create a function Group (say 'ZCAL').
- Create a function module, set the attributes like (Function group, Application, Short Text and Process Type) and Save.
- Include file 'LZCALU01' will have source code of first function module.
- Include file 'LZCALTOP' will have global data.
- Main program 'SAPLZCAL' contains
- Global data Include file 'LZCALTOP'
- Function modules include file 'LZCALUXX'
- User defined Include files 'LZCALF..', 'LZCALO..' and 'LZCALI..'
- Define interface parameters and Exceptions
- Write the source code
- Activate Function Module
- Testing the Function Module - Single Test & Debugging
- Documenting and Releasing a Function Module
Intro:
There's always an issue that SAP users by mistake post some GL accounts to cost centers although according to company policy these accounts should only post to internal orders or production orders.
The same approach provided below can also be manipulated to allow specific cost centers for specific GL Accounts
The best way to prevent this mistake is to use Validation Rules (Trx GGB0) and specify the GL accounts that are not allowed on a cost center so the user gets an error whenever SAP is posting these GLs to a Cost Center.
Since validation rules are part of system config, it's a lot of headache to change the GLs in the rule later in case a new GL is created or an exception is needed.
To be able to edit the rule's GLs without doing any configuration, we can maintain an Account Set in the validation rule instead of specific GL accounts, in this case the Set can be edited freely in Production environment (by authorized users).
This will involve creating a user exit and editing a copy of a standard SAP program
Steps:
1) Trx GS01 > Create the Account set
2) Trx SE38 > Copy program RGGBR000 to ZRGGBR000 and add the below code at the end of the standard code
-----------------------------------------------------
exits-name = 'ZCC'.
exits-param = c_exit_param_none.
exits-title = text-103.
APPEND exits.
FORM ZCC USING b_result.
RANGES: GLS FOR BSEG-HKONT.
Select VALSIGN AS SIGN VALOPTION AS OPTION
VALFROM AS LOW VALTO AS HIGH
FROM SETLEAF INTO CORRESPONDING FIELDS OF TABLE GLS
WHERE SETNAME = 'GL_CC_BLOCK'.
if SY-SUBRC = 0.
IF BSEG-HKONT IN GLS.
b_result = b_true.
else.
b_result = b_false.
ENDIF.
endif.
ENDFORM.
------------------------------------------------
3) Trx GCX2 >> Assign program ZRGGBR000 to Validation Rule Exits
4)Trx GGB0 >> Create Validation
5) Trx OB28 >> Activate Validation on the company code level
Now test the validation using any transaction, try FB50
Thank you for reading.
Best regards,
Abdullah Galal
SAP Finance and Integration Consultant