Difference Between BADI and User Exits/Customer Exits :

1. In user exits we go by general method for enhancements while BADIs we use objects (oops concepts) methods for enhancement. 
2. User exits are used for adding additional functionality to the existing SAP standard transactions. Using User exits we can add additional functionality standard SAP functionality without making any changes to the original code. BADI is a standardized interface for ABAP sources that enables partners and customers to enhance SAP-delivered programs in their namespace. 
3. Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can be inserted into the SAP System to accommodate user requirements too specific to be included in the standard delivery. Since specific industries often require special functions, SAP allows you to predefine these points in your software. 
4. As with customer exits two different views are available: 
   In the definition view, an application programmer predefines exit points in a source that allow specific industry sectors, partners, and customers to attach additional software to standard SAP source code without having to modify the original object.
   In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard logic if one is available.
5. In contrast to customer exits, Business Add-Ins no longer assume a two-level infrastructure (SAP and customer solutions), but instead allow for a multi-level system landscape (SAP, partner, and customer solutions, as well as country versions, industry solutions, and the like). Definitions and implementations of Business Add-Ins can be created at each level within such a system infrastructure.
6. SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not affect enhancement calls from within the standard software nor do they affect the validity of call interfaces. You do not have to register Business Add-Ins in SSCR.
7. The Business Add-In enhancement technique differentiates between enhancements that can only be implemented once and enhancements that can be used actively by any number of customers at the same time. In addition, Business Add-Ins can be defined according to filter values. This allows you to control add-in implementation and make it dependent on specific criteria (on a specific Country value, for example).
8. All ABAP sources, screens, GUIs, and table interfaces created using this enhancement technique are defined in a manner that allows customers to include their own enhancements in the standard. A single Business Add-In contains all of the interfaces necessary to implement a specific task.

Difference between User exits & Customer exits :

1.  A user exit is considered a modification, since technically objects in SAP namespace are modified. Customer exits do not affect standard SAP source code.
2. User Exits are forms (in the SAP Standard Includes) and are called by SAP standard programs using perform. Customer Exits are functions so they are called using call function (or more exactly Call customer function). 
3. Inside the form (user exit) you can read and change almost any global data from host program. Inside a function (customer exit) you can only access your import/export/changing/tables parameters. 
4. User exits are more flexible because you have more information to use in your code but on the other hand, it is very easy to manipulate erroneously global data and lead the standard program to a dump or even to make database inconsistent. Customer exits are more restrictive but you are sure any change you can make to any parameters will never lead to inconsistency. 
5. User-exit doesn't have any classification. In customer-exit we have function-module exit, screen exit, menu exit. 
6. User exits are basically designed For SD module. Customer exits are available for MM, SD, FI, HR... basically designed for all modules. 
7. While changing User-exit, Access Key is required, whereas in Customer-exit no access key is needed.
8. User exits are flexible and inconsistent and customer exits are restrictive and consistent. 
9. User-Exit affects modifies the standard code and this change will be effected every time. Whereas Customer-Exit will be included (or called) into the main program only when the corresponding Project is active. Thus preserving us lot of resources time.

Different Types of Internal Tables in SAP

Internal table: Allocating extra memory for a structure is called as Internal table. An internal table will have a header area and a body area. The Header area can store only one record and the body area can store more no. of records depending upon the size of the table defined during declaration.

Types of Internal tables: 

STRUCTURED INTERNAL TABLES:
Syntax for Internal table based on LIKE option.

DATA <ITAB> LIKE <DB TABLE> OCCURS <SIZE> [WITH HEADER LINE]

• Any variable defined for a table in ABAP using LIKE statement is by default a structure. It can hold only one record.
• If OCCURS <size> specification is added, SAP allocates Body area memory with out header line.
• If <size> is specified as '0', it adds 8 KB of data to the body area and if any other integer is given, memory equal to those no. of records is added.
• The memory size is not fixed with the size specification. It increases in the same width as specified in the OCCURS <size> specification.
• For defining Internal table with header line, we need to use the option WITH HEADER LINE.
   

NOTE: Internal table without header line is required in LOV concept and ALV reports.

• Internal tables with header line is used all SAP applications to program DML operations. These concepts are used in MPP and BDC also.
• If we need to populate data into internal table without header line, we need to define an explicit structure and populate data into that structure and append data from that into the body area of the internal table using APPEND or COLLECT statements.
• There are two statements for loading data into internal tables.

           1) APPEND        2) COLLECT

• Append statement is used to add header data always a new record. Whereas Collect statement verifies whether the current header data is available in the body area. If found, Integer fields are added up with the current header data value. Else, adds a new record. If there are no internal fields, no records are added.
• For displaying Internal Table data we can use the Data Base loops.

        1) Select - End Select 2) Loop - End Loop.

• Select - End select statement is used to fetch data from DB tables into Application Server memory. Memory created by ABAPer in form of structure or internal tables is called as Explicit memory.
• Loop - End loop is used to display data in internal tables.
• Example for using Loop - End loop and Append statements:

        Data WA like KNA1 occurs 0 with header line.

        Wa–kunnr = 'customer 1'.

        Wa–land1 = 'in'.

        Wa-name1 = 'Indian'.

        Append wa.

        Wa–kunnr = 'customer 2'.       Wa–land1 = 'in'.       Wa-name1 = 'indian2'.       Append wa.            Loop at wa.         Write: / wa-kunnr, wa-land1, wa-name1.        Endloop. 

• In the above example, if the internal table doesn't have the WITH HEADER LINE option, it would have generated an error.
• For such internal tables, we need populate using an work area also display using an work area.
• In the above example if header line is not specified, define another wa (wa2) of the same type, add the values into that wa2 instead of wa. and in place of append statement, use "Append WA2 to WA".
• For displaying, in Loop statement, use "Loop at wa into wa2". Then in Write statement, use the values in wa2.
• When we give Select - End Select statement, the data is retrieved from the data base table record by record. For displaying all the records in one hit to the data base, use the option INTO TABLE <INT_TAB> in the SELECT statement. In this case, there is no need of any ENDSELECT.
• By using the above method, the performance of the program increases.

NOTE:Begin of  - End of  is best useful in Reprots. Like Syntaxes are best useful in DML Operation.
EXIT:This statement is used for coming out of the loop with out checking for any condition. SORT: This statement is used to sort data of the internal table based on the field selected for sorting in the manner required.

        Syntax: SORT <INTAB> [BY <FIELD[S]>]    [ASCENDING / DESCENDING]

• If sorting is not specified, the sorting is done in Ascending order based on Key field.
• If no sorting mode is specified, then also sorting is done in the Ascending order based on the fields selected. 

Different type of internal table definitions using BEGIN OF … END OF:

First syntax for declaring internal tables.

Data:begin of itab occurs 0,

             mandt like kna1-mandt,

             kunnr like kna1-kunnr,

             .

             .

         end of itab.
 

Second syntax for declaring internal tables.

Data begin of <itab> occurs 0.

           include structure <dbtab>.

data end of <itab>. 

This syntax is used to add the same structure of data base table into current internal table or workarea with help of include statement.This syntax is used to insert or modify the data of data base table based on internal table values.
 

3rd Syntax a of Internal table using like and occurs options.

data <var> like <db_tab>.

ex: data wa like kna1.

wa is called as structure, number of fields in wa is same as kna1 field fields. wa can hold only one record memory.
 

3RD SYNTAX b

    DATA : ITAB LIKE <DBTAB> [OCCURS <N>] [WITH HEADER LINE].

OCCURS <N> IS THE OPTION WHICH MAKES THE VARIABLE AS INTERNAL TABLE, BY DEFAULT THIS STATEMENT CAN ALLOCATE MEMORY FOR ONLY BODY AREA. IF ABAPER HAS TO GET BACK HEADER LINE FOR THE INTERNAL TABLE USE "WITH HEADER LINE" OPTION. IF A INTERNAL TABLE IS DECLARED WITHOUT HEADER LINE, THEN HOW TO POPULATE DATA, AFTER POPULATING HOW TO SEE THE DATA..?

IF THE INTERNAL TABLE IS NOT DECLARED WITH HEADER LINE , THEN DECLARE ANOTHER STRUCTURE FOR WITH SAME FIELDS, USING "APPEND <WA> TO <ITAB>" SYNTAX POPULATE ONE ONE RECORD INTO INTERNAL TABLE BODY AREA.

NOTE:

LOOP AT ITAB IS THE SYNTAX TO DISPLAY THE CONTENTS OF INTENRAL TABLE. BUT THIS STATEMENT CAN ALLWAYS CHECKS FOR THE INTERNAL TABLE HAS HEADER LINE, IF ITAB HAS NO HEADER LINE THEN ABAPER CAN USE "INTO" OPTION TO REDIRECT THE DATA TO DESTINATION WORKAREA.

EXAMPLE PROGRAM.

DATA ITAB LIKE MARA OCCURS 0."HAS NO HEADER

DATA WA LIKE MARA. "HAS HEADER LINE.

WA-MATNR = '1780'.

WA-MBRSH = 'P'.

WA-MTART = 'FERT'.

WA-MEINS = 'KG'.

APPEND WA TO ITAB.

WA-MATNR = '1781'.

WA-MBRSH = 'P'.

WA-MTART = 'COUP'.

WA-MEINS = 'KG'.

APPEND WA TO ITAB.

WA-MATNR = '1782'.

WA-MBRSH = 'M'.

WA-MTART = 'BEVR'.

WA-MEINS = 'KG'.

APPEND WA TO ITAB.

WA-MATNR = '1783'.

WA-MBRSH = 'C'.

WA-MTART = 'DRIN'.

WA-MEINS = 'KG'.

APPEND WA TO ITAB.

LOOP AT ITAB INTO WA.

  WRITE :/ WA-MATNR , WA-MTART, WA-MBRSH, WA-MEINS.

ENDLOOP.

EXAMPLE2.

DATA ITAB LIKE MARA OCCURS 0 WITH HEADER LINE.

ITAB-MATNR = '1780'.

ITAB-MBRSH = 'P'.

ITAB-MTART = 'FERT'.

ITAB-MEINS = 'KG'.

APPEND ITAB.

ITAB-MATNR = '1781'.

ITAB-MBRSH = 'P'.

ITAB-MTART = 'COUP'.

ITAB-MEINS = 'KG'.

APPEND ITAB.

LOOP AT ITAB.

   WRITE : ITAB-MATNR , ITAB-MBRSH , ITAB-MEINS , ITAB-NTART.

ENDLOOP.

SORTING THE DATA OF INTERNAL TABLE.

DATA : ITAB LIKE KNA1 OCCURS 0 WITH HEADER LINE.

SELECT * FROM KNA1 INTO TABLE ITAB.

SORT ITAB DESCENDING.

LOOP AT ITAB.

  WRITE : / ITAB-KUNNR , ITAB-LAND1 , ITAB-NAME1.

ENDLOOP.

SORTING IS PERFORMED BASED ON ASCCI CHARACTERS

Notes:

data itab like kna1 occurs 0 with header line. itab key field and dababase key fields are same, is not possible to change the key fields.

Syntax 4.

if any case if the data base key field and internal table key field should be changed for report generations then use "standard" internal table.

data : itab like standard table of <dbtab>

            [with unique/non-uniqe key <fld>]

                [with header line]

                     [initial size <n>].

example :data: itab like standard table of kna1 with non-unique key name1 with header line initial size 0. 

select * FROM KNA1 INTO TABLE ITAB.

SORT ITAB.

LOOP AT ITAB.

  WRITE : / ITAB-KUNNR , ITAB-LAND1 , ITAB-NAME1.

ENDLOOP.

STANDARD: This internal table is used in ABAP to change Key field priority in the Internal table. Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition. This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps.

Syntax:

data : <itab> like standard table of <db_table>

with <default/non-unique> key <fld>

with header line

initial size <n>.

example:

data : itab like standard table of kna1

with NON-UNIQUE key name1

with header line

initial size 0.

select * from kna1 into table itab.

sort itab.

loop at itab.

write : / itab-kunnr , itab-land1 , itab-name1.

endloop.

SORTED: Data is sorted into these internal tables at the time of Data population itself. These internal tables can't be resorted by ABAPer using "SORT" statement. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables. This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it.

syntax:

data : <itab> like sorted table of <db_table>

with <default/non-unique> key <fld>

with header line

initial size <n>.

example code.

data : itab like sorted table of kna1

with non-unique key land1

with header line

initial size 0.

select * from kna1 into table itab.

loop at itab.

write : / itab-kunnr , itab-land1 , itab-name1.

endloop.

 

Note: For all Above Internal tables Indexing is generated automatically by sap as Row ID. Based on This index number abaper can read the requied data from Internal table body area using "read" statement.

READ STATEMENT SYNTAX.

READ TABLE <ITAB> INDEX <NUM>.

This statement for Internal tables reads Data of Internal table for Specified Index Number and Populates the data into Header area of the Internal table.

example code.

DATA : BEGIN OF ITAB OCCURS 1,

F1(10),

F2(20),

END OF ITAB.

PARAMETERS : NUM TYPE I DEFAULT 1.

ITAB-F1 = 'INDIA'.

ITAB-F2 = 'AP'.

APPEND ITAB.

ITAB-F1 = 'INDIA'.

ITAB-F2 = 'TN'.

APPEND ITAB.

ITAB-F1 = 'INDIA'.

ITAB-F2 = 'MH'.

APPEND ITAB.

ITAB-F1 = 'INDIA'.

ITAB-F2 = 'UP'.

APPEND ITAB.

ITAB-F1 = 'INDIA'.

ITAB-F2 = 'KA'.

APPEND ITAB.

READ TABLE ITAB INDEX NUM.

WRITE : ITAB-F1 COLOR 5 , ITAB-F2 COLOR 7.

Note: IF THE INDEX NUMBER IS SPECIFIED MORE THAN SIZE OF INTERNAL TABLE, THEN READ STATEMENT GETS DATA INTO HEADER OF THE LAST RECORD IN THE INTERNAL TABLE.
HASHED: These internal tables are called as Non index internal tables. As this internal body is created in Hashed format, indexing can't be generated for the records. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition. This table type is particularly suitable if you want mainly to use key access for table entries. Hashed tables are a useful way of constructing and using internal tables that are similar to database tables.

Syntax:

DATA : ITAB LIKE HASHED TABLE OF <DB_TAB>

WITH UNIQUE KEY <FLD_NAME>

WITH HEADER LINE

INITIAL SIZE <N>.

 

EXAMPLE:

DATA : ITAB LIKE HASHED TABLE OF VBAK

WITH UNIQUE KEY VBELN

WITH HEADER LINE

INITIAL SIZE 0.

SELECT * FROM VBAK INTO TABLE ITAB.

LOOP AT ITAB.

WRITE : / 'VBELN' , ITAB-VBELN.

WRITE : / 'ERDAT' , ITAB-ERDAT.

WRITE : / 'ERNAM' , ITAB-ERNAM.

ULINE.

ENDLOOP.

SELECT Statements in SAP ABAP

There are different types of Select Statements in ABAP. Below are some select statements for frequently used cases.
<FLD_LIST> -> List of Fields from Data Base table for selection
<DB_TABLE> -> Source Data Base Table
<WA> -> Target Work Area/Structure
<ITAB> -> Target Internal Table
<CONDITION> -> Where condition in the select statement based on DB Table Fields.

1. 
   
   SELECT *|<FLD_LIST>                             (We can select all fields or the fields in given order of the internal table)
   FROM <DB_TABLE>
       INTO <WA>
           WHERE <CONDITION>.

        ENDSELECT.
    Ex: SELECT * FROM KNA1
        INTO W_KNA1

WHERE KUNNR GT '0000100000'. (Where W_KNA1 is a STRUCTURE similar to KNA1)

        WRITE: / W_KNA1-KUNNR, W_KNA1-NAME1.
ENDSELECT.

PS: This is a loop on data base table. This Select-EndSelect loop will retrieve records one after the other from data base and places it in the structure/Work Area. Programmer can use the structure data for their programming purpose within the Select – EndSelect Statements.

     2.  SELECT *|<FLD_LIST>

    FROM <DB_TABLE>

        INTO TABLE <ITAB>

            WHERE <CONDITION>.

        Ex: SELECT * FROM KNA1

             INTO TABLE IT_KNA1

       WHERE KUNNR GT '0000100000'. (Where IT_KNA1 is an internal table with structure similar to KNA1)

              LOOP AT IT_KNA1.
                  WRITE: / IT_KNA1-KUNNR, IT_KNA1-NAME1.
              ENDLOOP.
            

PS: When INTO TABLE is used, it will no more be a Loop. ENDSELECT is not needed here. This is a single statement to get all the required records from the Data Base table into our internal table in a single step, which will be very faster as compared with earlier process as well as reduces number of hits to the DB and thus optimizing our programs performance.

Also, here we will have all the records for processing at a later stage in our internal table.


     3.  SELECT SINGLE *|<FLD_LIST>    (We can select all fields or the fields 
                                                                                in given order of the internal table)

     FROM <DB_TABLE>

          INTO <WA>

              WHERE <CONDITION>.

          Ex: SELECT SINGLE * FROM KNA1
                     INTO W_KNA1

          WHERE KUNNR GT '0000100000'. (Where W_KNA1 is a 
                                                                   STRUCTURE similar to KNA1)

PS: In this case also we don't need ENDSELECT. This is a statement which will bring the first selected record from the Data Base Table and place it in our structure/WA. This will be useful if we need only one record from the DB table thus not looping over the DB table number of times.

NOTE: One important thing to remember for all the above cases (when using the <FLD_LIST> in the Select statement) is that, the order of the fields in the <FLD_LIST> should be same as the order of the fields defined in the Work Area/Internal Table.

System will try to place the selected fields of each record in the order (i.e., first field into first field etc.). So, if the fields defined in the internal table and fields selected in Select statement are not in same order, there will be errors in the data selected (sometimes running into Run-Time errors when there is a data type conflict). The solution to this scenario is below.

          4. SELECT <FLD_LIST>

         FROM <DB_TABLE>

              INTO CORRESPONDING FIELDS OF < ITAB>

                  WHERE <CONDITION>.

By Using the INTO CORRESPONDING FIELDS OF addition, the select statement will try to identify the corresponding field of the Internal Table which has the same name as the Selected field from the Data Base table and updates it in that field. Thus even if the order of selection for the fields in the Select statement and in the Internal table do not match, the data is populated into the corresponding fields.
    The same functionality applies to all the three scenarios explained above.
    NOTE: One Limitation here however is that, the Names of the Fields in the Internal Table should be the same as the names of the Data Base Table. Or else, system cannot find any such field and so the fields will not be updated.
Below is a detailed description of the Generic Select Statement Syntax and its different parts.
Syntax:
SELECT <result>
INTO <target>
FROM <source>
[WHERE <condition>]
[GROUP BY <fields>]
[HAVING <cond>]

[ORDER BY <fields>].

The SELECT statement consists of a series of clauses, each of which fulfils a certain task:
SELECT clause: Defines the structure of the selection.

Syntax

SELECT [SINGLE]|[DISTINCT]

* | <si>...

<agg>( [DISTINCT] <sj>) [AS <aj>]...

The selection can be a single line SINGLE or a series of lines. You can eliminate duplicate lines using the DISTINCT addition. To select the entire line, use *, otherwise, you can specify individual columns <si>. For individual columns, you can use aggregate functions <agg>, and assign alternative column names <ai>.

 INTO clause: Defines the target area into which the selection from the SELECT clause is to be placed.

Syntax

... INTO [CORRESPONDING FIELDS OF] <wa>

| INTO|APPENDING [CORRESPONDING FIELDS OF] TABLE <itab>

[PACKAGE SIZE <n>]

| INTO (<f1>, <f2>,...)

The target area can be a flat work area <wa>, an internal table <itab>, or a list of fields <fi>. If you use the CORRESPONDING FIELDS addition, data is only selected if there is an identicallynamed field in the target area. If you use APPENDING instead of INTO, the data is appended to an internal table instead of overwriting the existing contents. PACKAGE SIZE allows you to overwrite or extend the internal table in a series of packages. The data type of the target area must be appropriate for the selection in the SELECT clause.

 FROM clause: Specifies the database tables from which the data in the selection in the SELECT clause is to be read.

Syntax

... FROM [<tab> [INNER]|LEFT [OUTER] JOIN] <dbtab> [AS <alias>]

[ON <cond>]

[CLIENT SPECIFIED]

[BYPASSING BUFFER]

[UP TO <n> ROWS]

You can read a single table <dbtab> or more than one table, using inner and outer joins to link tables with conditions <cond>, where <tab> is a single table or itself a join condition. You can specify individual database tables either statically or dynamically, and you can replace their names with an alternative <alias>. You can bypass automatic client handling with the CLIENT SPECIFIED addition, and SAP buffering with BYPASSING BUFFER. You can also restrict the number of lines read from the table using the UP TO <n> ROWS addition.

WHERE clause: Restricts the number of lines selected.

Syntax

... [FOR ALL ENTRIES IN <itab>] WHERE <cond>

The condition <cond> may contain one or more comparisons, tests for belonging to intervals, value list checks, subqueries, selection table queries or null value checks, all linked with AND, OR, and NOT. If you use the FOR ALL ENTRIES addition, the condition <cond> is checked for each line of the internal table <itab> as long as <cond> contains a field of the internal table as an operand. For each line of the internal table, the lines from the database table meeting the condition are selected. The result set is the union of the individual selections resulting from each line.

 GROUP BY clause: Groups lines in the selection

Syntax

... GROUP BY <s1> <s2>

Groups lines with the same contents in the specified columns. Uses aggregate functions for all other columns in each group. All columns listed in the SELECT clause that do not appear in the GROUP BY addition must be specified in aggregate expressions.

 HAVING clause: Restricts the number of line groups.

Syntax

... HAVING <cond>

Like the WHERE clause, but can only be used in conjunction with a GROUP BY clause. Applies conditions to aggregate expressions to reduce the number of groups selected.

 ORDER BY clause: Sorts the lines in the selection.

Syntax

... ORDER BY PRIMARY KEY |... <si> [ASCENDING|DESCENDING]...

Sorts the selection in ascending or descending order according to the primary key or the contents of the fields listed.