If you are dealing with transfer of data between SAP or non-SAP systems, you would have certainly come across the term IDoc. In this post, lets get an overview about IDoc.

• IDoc stands for Intermediate Documents. It’s a data container used to exchange data between two software processes. It’s created by an outbound ALE (Application link enabling)/EDI (Electronic data interchange) process and acts as input to an inbound ALE/EDI process.
• Data in IDoc are stored on database in different database tables instead of flat files.
• Every IDoc has a unique number.
• IDocs are independent of sending and receiving systems.
• IDocs are based on EDI standards, but is closest to EDIFACT standard.
• Different outbound and inbound processes can use the same IDoc e.g. IDoc type ORDERS01 is used by MM module for purchase order as well as by SD module for accepting sales order.
• IDocs contain data in character format (no binary data) i.e. can be viewed in simple text viewer.

IDoc Definition Components

Basic IDoc Type

• Name:

Before release 4.0           – 8 characters

Since release 4.0              – 30 characters

Last 2 characters represent the version number. After a basic IDoc type is released and you move to a newer version of SAP, any change to basic IDoc type would create a new version of basic IDoc type e.g. ORDERS01, ORDERS02, ORDERS03 etc.

• List of permitted segments
• Hierarchy of permitted segments – Parent child relationship
• Mandatory vs. Optional segments – Which segment is mandatory and which one is optional?
• Minimum/maximum range for each segment – What is the minimum and maximum number of data records corresponding to a particular segment in an IDoc?

Segments

Segments define the structure and format of data records. These are reusable components i.e. could be used in more than one IDoc types.

Three parts:

• Segment type : Version independent name of a segment. Begin with E1/Z1.
• Segment definition :

Version dependent definition of a segment where the data fields are specified. Can not be more than 1000 characters.

Segment definition name : Upto 30 characters. Start with E2/Z2 and last 3 characters for version. E.g. Z2TEST, Z2TEST001, Z2TEST002 etc.

• Segment Documentation : Each segment has only one documentation with name starting from E3/Z3. It contains description about each field.

Data Fields

It represents a single data item in a segment. Can be only alphanumeric e.g. CHAR, CLNT, CUKY, DATS, LANG, and NUMC.

IDoc Runtime Components

An IDoc is a instance of IDoc type. At runtime, the IDoc contains several records which can be classified into following broad categories:

• Control record
• Data record
• Status record

IDoc number is the element which ties the control record, data records and status records together.

Control record

Control record contains the control information about an IDoc e.g. IDoc number, sender & receiver information, IDoc type etc.

There’s only one control record per IDoc.

• DDIC structure :

Before release 4.0           -              EDI_DC

Since release 4.0              -              EDI_DC40

• Transparent table : Stored in client dependent table EDIDC. Key field of this table is IDoc number.

Data record

Data records contain application data.

• Each data record has 2 parts:

Administrative section : Segment name, Client, IDoc number, segment number and hierarchy level information.

Data section : 1000 bytes of application data.

• DDIC structure :

Before release 4.0           -              EDI_DD

Since release 4.0              –              EDI_DD40

• Transparent table : Stored in client dependent table with key field as IDoc number, Counter in cluster table and Segment number.

Before release 4.0           -              EDID2

Since release 4.0              –              EDID4

Status record

During the lifecycle of IDocs, various status records are attached to an IDoc.

Multiple status records could be attached to an IDoc.

Latest status code is also maintained in the control record.

• Status codes:

For outbound process :  01           -              49

For inbound process    :  50           and above.

• Transparent table:           Stored in table EDIDS.

List of status codes can be viewed using transaction WE47.

Hope that the above content brings you to talking terms about IDoc. In my future posts, I would throw more light on working with IDocs. Until then, GoodBye.

• User exits allow you to add additional functions to the SAP standard.
• Programs with user exits contain Subroutine (Form Routines) calls at certain points in their syntax that are identified by the prefix USEREXIT.
• The actual User Exits Form Routines are located in an Include Program that has been assigned to a Module Pool Program.. The following diagram explains this:

• In the User Exits Form Routines customers can include any changes (enhancements) that they want to make to the system. These includes are always processed during program flow
• So the SAP developer creates a special include in a module pool. These includes contain one or more subroutines routines that satisfy the naming convention USEREXIT_<name>. The calls for these subroutines have already been implemented in the R/3 program.
• A user exit is considered a modification, since technically objects in the SAP namespace are being modified.
• After delivering them, SAP never alters includes created in this manner; if new user exits must be delivered in a new release, they are placed in a new include program.

2. In which SAP component User Exits are primarily used?

User exits are primarily used in the Sales and Distribution component.

3. What are the advantages and disadvantages of User Exit?

Advantage: In principle, customers can modify anything they want that is found in the include (tables, structures, and so forth).

Disadvantage: SAP cannot check the individual enhancements themselves which often leads to errors in the enhancement process.

4. How can we find overview of User Exits as well as a description of those user exits that exist in SD?

We can find overview of User Exits as well as a description of those user exits that exist in SD in the SAP Reference IMG under Sales and Distribution -> System Modification -> User exits.

Steps:

• Go to transaction : SPRO
• Go to Sales and Distribution -> System Modification -> User exits

5. How do you find User Exit in any transaction say VA01 – Create Sales Order?

Step 1: Find the Module Pool Program

Go to the transaction – VA01 – Create Sales Order.

Then Go to SYSTEM in the Menu bar and then to STATUS from where we can find the ‘Program (screen)’.

Step 2: Find the Includes Program that contains User-Exits

Double click that ‘Program (screen)’. Generally user-exits are always at the start of the standard SAP program

Step 3: Find the User Exit Subroutines

Double click on any of these Includes that contains User-Exits. You can see various subroutines with prefix USEREXIT.

Customers can insert their standard code inside these form routines.

Customers can create their own form routines but should begin with ‘ZZ’.

A more faster way to search is to search the string ‘PERFORM USEREXIT’ inside the program.

SAP offers a wide variety of enterprise solutions catering to different business areas for large, mid-size and small enterprises.

SAP Solutions can be broadly classified into following elements:

SAP Netweaver

SAP NetWeaver is the technological infrastructure for all SAP solutions. All other SAP solutions are built upon it. ABAP workbench and runtime are also part of this element. This can very well independently be used to develop customer applications also. This element will be dealt more in my next post.

SAP Business Suite

SAP Business Suite bundles all cross-industry, SAP NetWeaver-based SAP solutions. For example, SAP ERP (consisting of Material management – MM, Production planning – PP, Sales & distribution – SD, Financial accounting and Controlling – FICO, Financial supply chain management – FSCM, Human capital management – HCM, Human resource management – HR etc.), SAP CRM, SAP SRM, SAP SCM etc.

SAP Smart Business Solutions

SAP Smart Business Solutions are the solutions provided by SAP to small and mid-size customers which reuse certain functionalities from the SAP Business Suite solutions. However, SAP haven’t got enough success in this market segment yet.

SAP Solutions Portfolio

SAP xApps (SAP Collaborative Cross Applications)

SAP xApps (Collaborative Cross Applications) allow you to integrate existing applications with each other by accessing existing datasets and functions using open interfaces. This means that you can implement new applications based on an existing infrastructure.

Industry Solutions

Each industry segment works in different manner. In order to cater the needs of different industry segments, along with SAP Business Suite containing cross-industry solutions, SAP provides various industry add-ons. These add-ons are called industry solutions.

The reason lies behind my own experiences during preparing for SAP ABAP certification examination. Any book or study material is successful only if it perfectly knows its readers, their level of knowledge in the area being dealt. Though, ABAP certification materials provided by SAP is very comprehensive and exhaustive, it just seems to be a huge bulk of information put in front of you. When you start reading it, very often you would find repetitive information at some places and on the other hand, not even doing justice to many important topics. Above all this, the study material consists more than 2500 pages, good enough to test a normal human being’s patience.

Having said this all, I would also like to remind you that these study materials provided by SAP still hold good when it comes to gaining detailed knowledge at times. They can become a really good supplement if you have a teacher to explain the concepts to you. In the series of posts to follow, I have tried exactly to fill this role. I have tried to explain the gist of each topic both in writing and in form of video. After going through each of these posts and understanding them, you can refer the corresponding section in SAP ABAP certification study material and make your understanding air-tight.

In this series of posts, I plan to cover each topic consisting ABAP certification syllabus in almost the same sequence in which they appear in SAP ABAP certification material. This would help you to refer the corresponding section in SAP ABAP certification material easily. In these posts, I would try to keep myself as precise and sufficient in imparting the information about each topic, as possible.

Without wasting any more time of yours, I would list below the table of contents in this series of posts.

Table of contents – SAP ABAP Certification Online Training & Tutorial

Hi friends!!!

Have you ever felt the need of compressing large text or binary data in ABAP. I am sure whether or not you have come across it till now, it would prove to be very handy knowing how to do it. I can mention few example situations where you could use it. Suppose, you have large amount of text e.g. comments, notes etc. which need to be persisted in the database tables. Another example could be a case where you need to save a serialized object(instance) in the database which you later want to use.

Netweaver ABAP provides a service class CL_ABAP_GZIP to achieve this. This class has methods to compress as well as decompress text as well as binary data. I am briefly describing the methods of this class.

COMPRESS_TEXT:

This method is used to compress text data and get the compressed binary data. This method takes a character sequence (CHAR of any length, STRING etc.) input – TEXT_IN and returns compressed binary (XSTRING, RAW) output – GZIP_OUT.

DECOMPRESS_TEXT:

This method is used to de-compress compressed binary data and retrieve the text data back. This method takes a binary (XSTRING, RAW) input – GZIP_IN and returns character sequence (CHAR of any length, STRING etc.) output – TEXT_OUT.

COMPRESS_BINARY:

This method is used to compress binary data. This method takes a binary (XSTRING, RAW) input – RAW_IN and returns compressed binary (XSTRING, RAW) output – GZIP_OUT.

DECOMPRESS_BINARY:

This method is used to de-compress compressed binary data and retrieve the original binary data back. This method takes a binary (XSTRING, RAW) input – GZIP_IN and returns binary (XSTRING, RAW) output – RAW_OUT.

Soon, I will come back with more utilities in ABAP which make our lives easier. Till then, Cheers

You can achieve this objective using property ROW_POS of Field catalog. Just assign a value between 1 to 3 to each of the records (denoting output internal table’s columns/fields) in field catalog. That’s it. Value is restricted between 1 and 3 since ALV can handle maximum of 3 rows for 1 ALV line item.
The example followed will completely clear the usage.

Here is the code to build the field catalog of an ALV.

FORM e01_fieldcat_init USING e01_lt_fieldcat TYPE slis_t_fieldcat_alv.

DATA: ls_fieldcat TYPE slis_fieldcat_alv.

ls_fieldcat-fieldname = ‘CARRID’.

ls_fieldcat-key       = ‘X’.

ls_fieldcat-ref_fieldname = ‘CARRID’.

ls_fieldcat-ref_tabname = ‘SFLIGHT’.

ls_fieldcat-row_pos = 1.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CONNID’.

ls_fieldcat-key       = ‘X’.

ls_fieldcat-ref_fieldname = ‘CONNID’.

ls_fieldcat-ref_tabname = ‘SFLIGHT’.

ls_fieldcat-row_pos = 1.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘FLDATE’.

ls_fieldcat-key       = ‘X’.

ls_fieldcat-ref_fieldname = ‘FLDATE’.

ls_fieldcat-ref_tabname = ‘SFLIGHT’.

ls_fieldcat-row_pos = 1.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘PRICE’.

ls_fieldcat-ref_fieldname = ‘PRICE’.

ls_fieldcat-ref_tabname = ‘SFLIGHT’.

ls_fieldcat-row_pos = 2.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CURRENCY’.

ls_fieldcat-ref_fieldname = ‘CURRENCY’.

ls_fieldcat-ref_tabname = ‘SFLIGHT’.

ls_fieldcat-row_pos = 2.

APPEND ls_fieldcat TO e01_lt_fieldcat.

ENDFORM.

Multi-lined ALV using ROW_POS specified in Field catalog

So, how would the user be able to see his screens defaulted to his last used field values when he logs on next time?

The solution is through making use of ‘Parameters’ tab in User profile (Transaction: SU01/SU02/SU03). Here, you can set the default values of various parameter ids for the particular user. When this user logs on to the system next time, the SET/GET parameters will be automatically filled with the values defined in the user profile and set in the SAP memory. Rest is simple. Now, when the user opens his screens, the screen fields if attached to a parameter id will be automatically filled with the values in SAP memory.

Setting the values of parameter ids in user profile can be done manually using the transaction SU02.

Maintaining SET/GET Parameters in User Profile (Transaction SU02)

You can do this programatically as well by making new entries/modifying entries in the table USR05 as mentioned below. This table stores the values of various parameter ids for different users.

DATA wa_usr05 TYPE usr05.

wa_usr05-mandt = [client].

wa_usr05-bname = [user].

wa_usr05-parid = [parameter id].

SELECT SINGLE parva INTO wa_usr05-parva FROM usr05

WHERE bname = wa_usr05-bname

AND   parid = wa_usr05-parid.

IF sy-subrc <> 0.

wa_usr05-parva = [parameter value].

INSERT usr05 FROM wa_usr05.

ELSE.

wa_usr05-parva = [parameter value].

MODIFY usr05 FROM wa_usr05.

ENDIF.

CALL FUNCTION ‘DB_COMMIT’.

We will now see how the parameter ids can be attached to screen elements in order to populate them by default with the previously set parameter value.

This can be done in the following ways:

Attaching SET/GET Parameters to Selection Screen

You can attach SET/GET parameter to Selection screen parameters / selection options using the keyword MEMORY ID.

PARAMETER para TYPE datatype MEMORY ID parameterid.

SELECT-OPTION sopt FOR datatype MEMORY ID parameterid.

Here, parameterid is the SET/GET parameter id attached to selection screen parameter para and select option sopt. On attaching this parameter id to the selection screen elements, they will automatically get defaulted to whatever value is stored in the parameter id in the SAP memory.

An example mentioned below will clarify the behaviour.

Here, the first program sets the value of parameter id BUK as ‘0001′.

REPORT first_program.

SET PARAMETER ID ‘BUK’ FIELD ‘0001′.

After executing this program the value of parameter id BUK will be set to ‘0001′ in SAP memory.

Now, lets see what happens when the 2nd program is executed after the above one.

REPORT second_program.

PARAMETER: p_cocd TYPE bukrs MEMORY ID buk.

You will obtain the following result:

Attaching SET/GET Parameter with Selection screen parameter

You can observe that the selection screen parameter ‘Company Code’ got automatically filled with value ‘0001′ since the value of parameter id BUK was set to ‘0001′ in the SAP memory by the first_program.

Attaching SET/GET Parameter to the Screen Field

Parameter IDs can be assigned to normal ABAP screen fields. This can be done from two places.

First option is through the screen field’s properties in the Screen’s ‘Layout’. You can go to the Screen painter (transaction SE51) and open the ‘Layout Editor’ for your screen. Here, You can double click the screen field to open its attribute’s popup where you can specify the parameter id.

Attaching SET/GET Parameter with Screen fields

In the attributes, you can specify the respective parameter id to be attached to the screen field. This alone doesn’t work. You will find two checkboxes ‘SET Parameter’ & ‘GET Parameter’ below the field ‘Parameter ID’. If you mark the checkbox ‘GET Parameter’, the system will automatically fetch the value of specified parameter id from SAP memory & fill the screen field with fethced value if it’s not filled programatically.

You can mark the checkbox ‘SET Parameter’ to automatically set the value of parameter id in the SAP memory to the value typed by the user in the screen field. This can come handy in increasing the usability of your frequently used screens. I would advice to use this feature judiciously because excessive use of this feature may sometime irritate the user.

The Second option to do the same thing is also through Screen painter (transaction SE51). You can go to screen’s ‘Element list’. Here in the ‘Special attributes’ tab, you can specify parameter id in the column ‘Parameter ID’ against you screen field. You will also find checkboxes ‘SET Parameter’ & ‘Get Parameter’.

Attaching SET/GET Parameter to Data Element

You can attach the SET/GET Parameter to Data element. To do this, go to the data element’s definition using transaction SE11. Here, you will find a field ‘Parameter ID’ in the tab ‘Further Characteristics’. In this field, you can specify the parameter ID which you want to associate this data element with.

Attaching SET/GET Parameter with Data element

Whenever a field is added from data dictionary to the screen (dynpro), which is associated with a data element having a parameter id, the parameter id is fetched to the screen field’s attribute. So, you will not have to specify the parameter id manually in each screen where you add a field with this data element. The rest of behaviour is similar to the previous section.

Hope, I have been clear enough in explaining the topic. Please do comment, if you find something to add.

What are SET/GET parameters or SPA/GPA Parameters?

SET/GET Parameters or SPA/GPA parameters are the means through which you can make use of SAP memory to pass data between different main ( external ) sessions of a teminal ( user ) session. To elaborate a little on the terms used above, when you logon to SAP system, you basically create a terminal or user session. This terminal session can have multiple main or external sessions within it, which you can relate to multiple screens opened withing one user logon. SAP Application server allocates a memory area dedicated to each user or terminal session which can then be shared between all the main sessions within this user session. This user-specific memory dedicated to a user session is called SAP memory. SET/GET parameters basically enable the exchange of data between these external sessions within the same user session through SAP memory.

How to create SET/ GET parameters?

Before you can make use of SET/GET parameter, you will have to create one, failing which you would get error while performing ‘Extended Check’ of your program. However, you wont get any compile time error or runtime error. SET/GET Parameters are also treated as repository objects and have normal Object directory entry (TADIR) similar to other repository objects. You can create SET/GET parameter using Object navigator (transaction SE80). Just select the package under which you want to create the SET/GET create parameter and follow the following path in the context menu obtained by right-clicking on the package. <Package/Development Class> -> Create -> Other(1) -> SET/GET Parameter ID

Create SET/GET Parameter ID

The definition of SET/GET parameters can be found in the transparent table TPARA.

How to transfer data from one external session to other using Parameter IDs? I mean, How to read / set values for the Parameter IDs in program?

After creating the parameter, the next step is setting the values to the created parameter ids. You can do this using the below mentioned ABAP command.

SET PARAMETER ID parameterid FIELD dobj.

Here, parameterid is the SET/GET Parameter ID whose name should not be of more than 20 characters. dobj is a flat character type data object whose value needs to be set to the parameter id mentioned earlier. You can read the value of any parameter id in the same or different main/external session of the same user/terminal session using a similar ABAP statement.

GET PARAMETER ID parameterid FIELD dobj.

Same as above, parameterid is the name of parameter id whose value needs to be fetched and dobj is the flat character type data object to which the fetched value will be assigned. A small example to illustrate the above statements:

REPORT ZAS04. DATA: lv_cocd TYPE bukrs. SET PARAMETER ID ‘BUK’ FIELD ‘0001′. GET PARAMETER ID ‘BUK’ FIELD lv_cocd. WRITE: ‘Value fetched from Parameter ID – BUK : ‘, lv_cocd.

On executing this small program, you will get the following output:

Example of ABAP Statement 'SET PARAMETER ID' & 'GET PARAMETER ID'

In my next posts ( Associating SET/GET Parameters to Screen elements & Persisting SET/GET Parameter values in User Profile ), we will continue to learn how to use SET/GET parameters to default the screen fields and how to set persist the value of parameter ids, so that user can continue to make use of these preset values in his next user/terminal sessions.

As explained in my previous post (Introduction to Field Catalog ( SLIS_T_FIELDCAT_ALV )) :

KEY : This field indicates if the respective column is the key field in the tabular data to be displayed. The columns marked as ‘Key’ fields will always be positioned before the non-key fields.

COL_POS : Specifies the position of column in the ALV display. If this property is not specified, the columns/fields of data table will appear in ALV display in the order in which their “fieldname” appear in the field catalog. “Key” fields will always have higher priority than non-key fields. You are free to use the same position number for key fields & non-key fields. However, if two key fields or non-key fields have been assigned the same position number, they will be displayed in the order in  their “fieldname” appear in the field catalog.

Here, you would be able to experience the real effect of these properties.

Lets, begin with an ALV list where only the mandatory field FIELD_NAME is provided for each of the columns in field catalog. So, the code for field catalog looks as below:

FORM e01_fieldcat_init USING e01_lt_fieldcat TYPE slis_t_fieldcat_alv.

DATA: ls_fieldcat TYPE slis_fieldcat_alv.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘PRICE’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CURRENCY’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CARRID’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CONNID’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘FLDATE’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

ENDFORM.

The above ALV field catalog produces the output as shown below:

ALV with only FIELDNAME specified in Field catalog

Now, lets introduce the property KEY for some of the columns to be displayed on ALV. Find below the modified code:

FORM e01_fieldcat_init USING e01_lt_fieldcat TYPE slis_t_fieldcat_alv.

DATA: ls_fieldcat TYPE slis_fieldcat_alv.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘PRICE’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CURRENCY’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CARRID’.

ls_fieldcat-key       = ‘X’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CONNID’.

ls_fieldcat-key       = ‘X’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘FLDATE’.

ls_fieldcat-key       = ‘X’.

APPEND ls_fieldcat TO e01_lt_fieldcat.

ENDFORM.

Just, notice the effect:

ALV with KEY specified in Field catalog

You would notice two important effects:

1. All the columns marked as KEY fields are positioned before non-key fields. This preference of key fields over non-key fields can not be altered by  any other property in field catalog.

2. All the columns marked as KEY fields are highlighed.

Having, understood the effect of property KEY in the field catalog, lets proceed to the usage of property COL_POS.

Property COL_POS is used to arrange the key fields and non-key fields within themselves. If specified, the columns will appear in the ascending order of COL_POS. In case of conflict e.g. two key fields or two non-key fields having same COL_POS, they will be positioned in the order in which they appear in the field catalog internal table.

Lets observe the effect of changed code with COL_POS property incorporated.

FORM e01_fieldcat_init USING e01_lt_fieldcat TYPE slis_t_fieldcat_alv.

DATA: ls_fieldcat TYPE slis_fieldcat_alv.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘PRICE’.

ls_fieldcat-col_pos   = 2.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CURRENCY’.

ls_fieldcat-col_pos   = 1.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CARRID’.

ls_fieldcat-key       = ‘X’.

ls_fieldcat-col_pos   = 2.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘CONNID’.

ls_fieldcat-key       = ‘X’.

ls_fieldcat-col_pos   = 2.

APPEND ls_fieldcat TO e01_lt_fieldcat.

CLEAR ls_fieldcat.

ls_fieldcat-fieldname = ‘FLDATE’.

ls_fieldcat-key       = ‘X’.

ls_fieldcat-col_pos   = 1.

APPEND ls_fieldcat TO e01_lt_fieldcat.

ENDFORM.

ALV with COL_POS specified in Field catalog