Transaction SE11 on SAP

#

Transaction SE11

#

The transaction SE11 is a central SAP tool for managing the DATA DICTIONARY or DICTIONNAIRE DE DONNEES (DDIC).
It allows creating, viewing and maintaining all objects related to data in SAP.

Objectives

#

• Understand the SE11 interface and its menus
• Know how to view and modify data objects: tables, Views, DATA TYPES
• Manage KEYS, INDEX and relationships between objects
• Use help features for creation and control

Definition

#

Imagine that SE11 is a central toolbox where all SAP data construction plans are stored.
Without this box, it’s impossible to build, connect or verify system consistency.

All objects created in SAP (fields, structures, tables, etc.) are recorded in the DDIC.
It’s the technical foundation on which the entire data model rests.

The transaction SE11 is a SAP transaction used for data dictionary management. Here are its main uses:

• Viewing data objects: SE11 allows viewing different data objects in SAP, such as DB tables, Views, Data Types, etc. This also includes viewing Fields, Primary Keys, constraints and other properties of data objects.

• Creating and modifying data objects: SAP developers can use SE11 to create new data objects or modify existing objects, such as tables or Data Types.

• Maintaining data structures: SE11 allows managing complex data structures by defining relationships between tables, adding or removing Fields, defining join keys, etc.

• Generating data reports: Users can use SE11 to generate reports on data stored in tables by allowing data access via SQL queries or reporting tools.

Menu

#

• Check object [ Ctrl ] + [ F2 ]
• Activate [ Ctrl ] + [ F3 ]
• Where-Used allows knowing where the object is used [ Shift ] + [ F3 ]
• Analyze environment lists ABAP components that the object uses [ Ctrl ] + [ Shift ] + [ F4 ]
• Application help [ Ctrl ] + [ F8 ]
• Delete object from DDIC [ Shift ] + [ F2 ]
• Copy object from DDIC [ Ctrl ] + [ F5 ]

Features

#

• Database Table: classic programming table where system information is stored.
• View: visual grouping of multiple tables.
• Data type: can be a data element, table structure or table type.
• Type Group: kind of include where several variable types are stored (Constants, table type…).
• Domain: Domain.
• Search help: Search help.
• Lock Object: allows locking a table… if needed. Creating a lock object will automatically create two function modules:
  • ENQUEUE_lock-object-name (call this function to lock the table…)
  • DEQUEUE_lock-object-name (call this function to unlock the table…)

Buttons

#

• Display [ F7 ]
• Change [ F6 ]
• Create [ F5 ]

Display window (at execution)

#

Menu

#

• <- ->

• Display <-> Change [ Ctrl ] + [ F1 ]

• ...

• Other object [ Shift ] + [ F1 ]

• Check [ Ctrl ] + [ F2 ]

• Activate [ Ctrl ] + [ F3 ]

• Where-used [ Ctrl ] + [ Shift ] + [ F3 ]

• Object list display [ Ctrl ] + [ Shift ] + [ F5 ]

  

• Display navigation window [ Ctrl ] + [ Shift ] + [ F4 ]

  

• Enable/Disable fullscreen [ Shift ] + [ F12 ]

• Manual [ Ctrl ] + [ F8 ]

• Graphic [ Ctrl ] + [ Shift ] + [ F11 ]

  

  

  

• Contents [ Ctrl ] + [ Shift ] + [ F10 ]

• Technical options of the table [ Ctrl ] + [ Shift ] + [ F9 ]

• Append structure to view structures added to the structure (MARA in our example) [ F5 ]

FIELDS TAB

#

• Fields

  

• Keys

  

• Initial value

  

• Data element

• Data type (length and decimals)

  

• Description

  

INPUT HELP/CHECK TAB

#

Input help/check is a feature that provides assistance to users when entering data in a Field.

The Input Help/Check tab displays the link between a Field and its check table.

CURRENCY/QUANTITY FIELDS TAB

#

The “Currency/Quantity Fields” tab is a feature allowing definition of specific characteristics of data fields related to currencies and quantities in SAP.

More specifically, it displays links between a Field containing a quantitative value and its unit of measure.

For example, the BRGEW field of the MARA structure represents the gross weight of an item. However, we don’t know initially if the weight is in kilograms, grams or tons. BRGEW must therefore be linked to another Field to define and store its unit of measure. In this example, BRGEW is linked to the GEWEI field (of unit of measure type) which has the description “Weight unit”.

When creating a table, it is mandatory to always link a quantity type field (data type: QUAN) with a field that will describe its unit of measure (Data type: UNIT).

---

Domains

#

Objectives

#

• Understand the role of a DOMAIN in the SAP dictionary
• Identify available data types
• Define technical and editorial properties of a DOMAIN
• Create a DOMAIN in transaction SE11 with its value ranges and conversion routines

Definition

#

It can be seen as the mold into which data must fit.

The definition of a DOMAIN constitutes the lowest level of data description in SAP.
It allows defining the technical characteristics of a field contained in a TABLE.

SE11

#

To facilitate understanding, we will take the example of the MATNR domain, accessible from Transaction SE11 by entering the searched domain name in the “Domain” input. Then click on [ Display ] (or “Display”)

Menu

#

• Two arrows: (Previous Object and Next Object) to navigate between screens.
• Display <-> Change: to switch to modification in case of display and vice versa [Ctrl][F1]
• Active <-> Inactive allows navigating between active and inactive version
• Other Object: to select another domain without going back through the initial SE11 screen. [Shift][F5]
• Check [ Ctrl ] + [ F2 ]
• Activate [ Ctrl ] + [ F3 ]
• Where-Used [ Ctrl ] + [ Shift ] + [ F3 ]
• Display Object List [ Ctrl ] + [ Shift ] + [ F5 ]
• Display Navigation Window [ Ctrl ] + [ Shift ] + [ F4 ]
• Enable/Disable Fullscreen
• Online Manual [ Ctrl ] + [ F8 ]

Description

#

Properties tab

#

• Last modification of the domain
• Package of the domain
• Original language of the domain (during its creation)

Definition tab

#

• Data type characterizing the domain format
• Number of positions This is the number of characters of a data type in the ABAP Dictionary
• Decimals
• Output length This is the output length as part of domain output properties
• Conversion routine This is the conversion routine as part of domain output properties
• Sign +/- domain parameter
• Lowercase domain parameter

Value range tab

#

A value range for a domain refers to a range or set of allowed values for that field.

If it is filled in during domain creation, when a user uses a variable defined by this domain, SAP will check if the entered value exists by consulting this value range. If it doesn’t exist, it will return an error message.

Available data types

#

• CHAR: alphanumeric character string
• CURR: currency (EUR, USD…)
• DATS: date format
• DEC: decimal number with sign and thousands separator
• FLTP: floating point number (up to 16 positions)
• INT1, INT2, INT4: integer numbers
• NUMC: numeric text (useful for concatenating numbers and text)
• STRING: long character string
• XSTRING: hexadecimal string

Imagine a cookie cutter.
The DOMAIN defines the shape and size of the cookie. Regardless of the filling (the value), it must always fit in this mold.

The DOMAIN sets the universal technical rules of a field (type, length, format).
Thus, all fields based on this DOMAIN will share the same constraints and behaviors.

A DOMAIN can be reused in multiple tables. If you modify it, all fields using it will be impacted.

Main properties

#

• Data type: base format (CHAR, NUMC, DEC, etc.)
• Number of positions: number of allowed characters
• Decimals: only for numeric types
• Output length: visible length in interfaces
• Conversion routine: automatic conversion or formatting (e.g. ALPHA)
• Sign +/-: allows negative numbers
• Lowercase: allows lowercase letters

If a DOMAIN defines a 5-character identifier, and you enter 123456, SAP will reject the value.
If you enter 123, the ALPHA conversion routine can complete with zeros to get 00123.

A length that is too short or incorrect type definition can cause truncation or incompatibility errors with other objects.

Always define type and length with functional consistency (e.g.: ZID_CLIENT → CHAR10 to allow mixed alphanumeric format).

Value range

#

A value range defines a set of allowed values for the field.

It’s like a menu in a restaurant. If the dish you ask for is not on the menu, the waiter (SAP) tells you it’s not allowed.

When a range is defined, SAP automatically checks that the entered value belongs to this list and rejects any non-compliant data.

Value ranges are useful for restricting fields such as contract type, country code, or status.

Define value ranges as soon as data is coded or limited to a closed list (e.g. Y/N, A/B/C…).

Conversion routine

#

Conversion routines allow automatically formatting data during entry or display.

A field of type MATNR (material number) must always have 10 characters.
If you enter 12345, the ALPHA routine will automatically convert it to 0000012345.

SAP uses these routines to ensure display uniformity between screens, databases and reports.
Thus, values are always stored in the same technical format, but displayed in a readable form.

If a conversion routine is not suitable, display or comparison errors may occur between systems (e.g.: between ECC and S/4HANA).

Use standard SAP routines (e.g.: ALPHA, CUNIT, CURRENCY) rather than creating new ones.

Creating a domain

#

1. Transaction SE11

2. Check the Domain option

3. Name the domain (example ZCONSULTANT_ID)

4. Create or [ F5 ]

5. Enter a description (mandatory) (example SAP AELION Consultant Identifier)

6. Insert the following information:
   • Data type: CHAR
   • Number of positions: 30
   • Output length: 30
   • Conversion routine: ALPHA

7. Save

8. Check

9. Activate

Creating a DOMAIN is like defining an official template for a form:
each field must respect this template to guarantee data uniformity throughout the system.

Domain activation automatically checks for possible inconsistencies.
In case of error, SAP precisely indicates the field or property to correct.

Summary

#

A DOMAIN defines the technical structure of an SAP field: type, length, decimals, conversion and value range.
It guarantees consistency and data quality throughout the system.

• Each field of an SAP table is based on a DOMAIN.
• The DOMAIN ensures data homogeneity and validation.
• Conversion routines and value ranges strengthen data model integrity.

Always create a reusable DOMAIN rather than defining types directly in table fields.
This simplifies maintenance and long-term data normalization.

---

Data elements

#

Objectives

#

• Understand the role of a DATA ELEMENT
• Identify the relationship between DATA ELEMENT and DOMAIN
• Define description and data presentation
• Create a DATA ELEMENT in transaction SE11

Definition

#

If the DOMAIN is the mold that defines the shape and size of the cookie,
the DATA ELEMENT is the label stuck on the cookie.
All cookies from the same mold can have different labels depending on their use (e.g.: “customer cookie”, “supplier cookie”).

A DATA ELEMENT is linked to a single DOMAIN, but a DOMAIN can be used by multiple data elements.

A DATA ELEMENT is the reference zone of data in SAP.
It defines how data is presented and used in the system, and it is always associated with a DOMAIN.

The DOMAIN sets technical characteristics (type, length, format),
while the DATA ELEMENT sets the functional meaning and display label of the field.

The DOMAIN ZCONSULTANT_ID defines a 30-character technical identifier.
The DATA ELEMENT ZCONSULTANT_ID defines how this field will appear on screen:
for example “SAP Consultant Identifier”.

The DATA ELEMENT is a presentation abstraction:
it makes technical data understandable for business users.
It’s a layer between technical (DOMAIN) and semantic (screen, form, report).

Relationship between domain and data element

#

Element	Main role	Example
DOMAIN	Technical definition (type, length, conversion)	CHAR30
DATA ELEMENT	Functional definition (text, label, help, doc.)	“SAP Consultant Identifier”

The DOMAIN says how data should be stored,
the DATA ELEMENT says how it should be understood and displayed.

Never confuse DOMAIN and DATA ELEMENT.
Modifying a DOMAIN affects all elements using it.
Modifying a DATA ELEMENT only affects field presentation (not its structure).

Creating a data element

#

Prerequisites

#

Have created a DOMAIN (e.g.: ZCONSULTANT_ID).

Steps

#

1. Transaction SE11

2. Check the Data type option

3. Name the element (example ZCONSULTANT_ID)

4. Create or [ F5 ]

5. Select Data element

6. Enter a description (mandatory) (example Consultant identification number)

7. Fill in the DOMAIN (example ZCONSULTANT_ID)

8. Press [ Enter ]

8. Fill in field descriptions in the Field label tab

Length	Nbr characters	Name
Short	10	Consultant
Medium	20	Consult.Ident.
Long	40	Consultant Identification
Heading	55	Consultant Identification

10. Save

In this example, DATA ELEMENT creation will be done locally but it is subject, like any object, to the possibility of being affiliated with a TR.

11. Check

12. Activate

These labels will be automatically used in screens, reports, ALV and forms. This allows standardizing field presentation throughout the system.

If the DOMAIN is the cookie mold,
the DATA ELEMENT adds the label and writing style on the cookie.
All cookies from this mold will be technically identical,
but the label (DATA ELEMENT) allows knowing what they correspond to.

Short, medium and long texts are used depending on display context:

• Short: lists, ALV, tables
• Medium: classic SAP screens
• Long / Heading: tooltips, input help, forms

The DATA ELEMENT should not be confused with a table field.
A table field reuses a DATA ELEMENT, it doesn’t define it.

Recommended usage

#

Recommended usage

• Create a DATA ELEMENT per distinct functional field, even if the DOMAIN is the same.
• Use explicit names (ZCLIENT_ID, ZSUPPLIER_ID) to facilitate maintenance.
• Always document field meaning in SE11 “Documentation” tab.
• This facilitates understanding and reuse in other SAP projects.

Summary

#

The DATA ELEMENT is the semantic definition of an SAP field.
It relies on a DOMAIN for its technical characteristics,
but adds meaning, labels and user help.

• A DATA ELEMENT = a functional label based on a technical DOMAIN
• A DOMAIN can be shared, but a DATA ELEMENT only references one DOMAIN
• It guarantees homogeneous presentation and clear understanding of data throughout SAP

In a well-structured SAP project, the DOMAIN + DATA ELEMENT pair
constitutes the foundation of any clean, consistent and understandable data model.

Fields / Zones / Fields

#

Objectives

#

• Understand what a FIELD is in SAP
• Identify the relationship between FIELD, DATA ELEMENT and DOMAIN
• Know how to create and modify FIELDS in SE11
• Differentiate the display of FIELDS in tables and structures

Definition

#

Imagine an Excel sheet:

• each column (e.g.: Name, First name, Date of birth) is a FIELD
• the column type (text, number, date) is defined by the DOMAIN
• the displayed label (Customer name, Age, etc.) is defined by the DATA ELEMENT

• A FIELD is an information storage zone in a table or structure.
• Each FIELD is linked to a DATA ELEMENT, which itself is linked to a DOMAIN.
• The FIELD defines the exact content, length, type and display of the data.

A FIELD (or zone) in SAP corresponds to a specific column of a table or structure.
Each FIELD contains precise information and is linked to a DATA ELEMENT and a DOMAIN that define its type and characteristics.

In the MARA table (material data):

• The FIELD MATNR corresponds to the material identifier.
• The DOMAIN defines its length (CHAR 18).
• The DATA ELEMENT defines its display label (“Material number”).

The FIELD is the physical column in the database.
The DATA ELEMENT is the functional description of the FIELD.
The DOMAIN defines the technical nature of the allowed value.

The same DOMAIN can be shared between multiple FIELDS (e.g.: customer ID, supplier ID),
but each FIELD has its own meaning via its DATA ELEMENT.

Fields in SE11 (structures)

#

In transaction SE11, when opening a structure, each line of the definition table corresponds to a FIELD.

We find the columns:

• FIELD name
• Associated DATA ELEMENT
• FIELD description
• Underlying DOMAIN

A structure is like a paper form: each box to fill (FIELD) has precise rules (DOMAIN) and a clear label (DATA ELEMENT).

Structures allow defining sets of FIELDS used in multiple tables or programs.
Thus, if the same group of FIELDS must be reused elsewhere, we can reference the structure instead of redefining everything.

• To view FIELD details in SE11, double-click on the DATA ELEMENT name.
• To know its exact type, double-click on the associated DOMAIN.

Fields in SE16N (data tables)

#

In SE16N, each FIELD corresponds to a table column.
You can view, filter or enter values in these FIELDS to query or update data.

Each column in SE16N is comparable to an Excel column.
You can sort, filter or enter values, but data form (length, type, unit) remains controlled by DOMAIN and DATA ELEMENT.

• Modifications in SE16N affect actual SAP database data.
• Direct editing in SE16N should be avoided without authorization, as a wrong value can cause inconsistencies.

SE16N is a data analysis tool, not a design tool.
FIELDS appear with their labels from data elements, making reading more intuitive.

Link between field, data element and domain

#

Level	Role	Example
DOMAIN	Defines technical type (CHAR, NUMC, etc.)	CHAR(10)
DATA ELEMENT	Defines functional meaning of FIELD	“Customer identifier”
FIELD	Concrete column in an SAP table	KUNNR in KNA1

This hierarchical link ensures consistency and definition reuse.
Thus, if a DOMAIN changes (for example identifier length),
all FIELDS using this DOMAIN will benefit from the same technical update.

Recommended usage

#

Recommended usage

• Name FIELDS with explicit prefixes (e.g.: ZCLIENT_ID, ZCITY_NAME)
• Reuse existing data elements to maintain dictionary consistency
• Never create a FIELD without DOMAIN or DATA ELEMENT (avoids inconsistencies)
• Systematically document each FIELD in SE11 (Documentation tab)

In case of doubt about a FIELD meaning, consult:

• SE11 → double-click on the DATA ELEMENT
• Where-Used (Ctrl + Shift + F3) to know where it’s used in the system

Summary

#

• Each FIELD = 1 physical column in a table or structure
• Each FIELD is defined by a DATA ELEMENT
• Each DATA ELEMENT relies on a DOMAIN
• In SE11, FIELDS are visible in structures
• In SE16N, they appear as manipulable columns

This hierarchy (FIELD → DATA ELEMENT → DOMAIN) is fundamental to understanding SAP Data Dictionary logic.
It ensures that all system data speaks the same language, both for developers and business users.

Table structures

#

Objectives

#

• Understand what a table structure is in SAP
• Differentiate a structure from a table
• Know how to create a structure and add fields to it
• Master INCLUDE and APPEND concepts

Definition

#

A table structure is a set of fields defined from data elements, without physical storage in the database.
It serves to organize, transmit and manipulate information, like a model or pattern to create tables or work on temporary data.

Imagine a mock-up or skeleton: you see the shape and components (fields), but there’s no real data yet.
The structure serves as a model to build tables or manipulate information temporarily.

• A table structure doesn’t store data, it only defines the shape and type of fields.
• Each field of a structure is linked to a data element, itself linked to a domain.
• Structures are often used to:
  • Pass parameters to programs or functions
  • Build temporary tables
  • Define models to create standard or transparent tables

The structure is a technical definition, like a form plan or table model.
We know what columns there will be and what type of data they will contain, even if no data exists yet.

Include & Append

#

Include

#

Copy an already assembled Lego block into a new construction. If the Lego block changes, all constructions using it are automatically updated.

• Integrates all fields from an existing structure into another structure or table.
• If the source structure changes, modifications automatically propagate to all structures or tables including it.
• Fields from an include appear in blue in SE11, meaning they’re not native to the main table.

To reuse standard field sets, avoid recreating them manually.

Append

#

Add an extension to a house: the original house remains intact, but you can add a room for your specific needs.

• Adds additional fields to a table or structure without modifying the original.
• Useful for standard SAP tables where direct modification is forbidden.
• Append fields are specific to your development.

Append fields must not create conflicts with existing fields. Always check consistency with original table.

Creating a table structure (SE11)

#

1. Transaction SE11

2. Check the Data type option

3. Name the element (example ZST_CONSULTANT)

4. Create or [ F5 ]

5. Select Structure

6. Enter a description (mandatory) (example ZT_CONSULTANT Table Structure).

7. Insert the following fields:

COMPONENT	TYPE CATEGORY	COMPONENT TYPE
CONSULTANT_ID	TYPES	ZCONSULTANT_ID
CITY	TYPES	CITY
COUNTRY	TYPES	LAND_X

8. Save

9. Check

10. Activate

Creating a structure is like preparing an Excel sheet with defined columns, ready to receive data. You define the information shape before filling the boxes.

• Always check that associated data elements exist and are correct.
• Field names must follow Z/AELION nomenclature to avoid collisions with SAP standard.

A structure doesn’t contain data. To store data, you’ll need to use a table based on this structure or an internal table in a program.

Best practices

#

Best practices	Explanation
Always check and activate	Verifies that structure is valid and usable
Use INCLUDE to reuse	Avoids recreating already existing fields
Use APPEND to customize	Adds specific fields without touching standard
Document the structure	Facilitates maintenance and understanding for other devs

Recommended usage

• Reuse INCLUDE to harmonize common fields in multiple tables/structures
• Use APPEND only for your specific developments or extensions

Summary

#

• A table structure is a field model without physical storage
• Include: reuses fields from an existing structure
• Append: adds specific fields without touching the original
• Structures serve to organize data and facilitate their passage between programs

The structure is like a mock-up or template.
You know which columns exist and how they’re defined, but the data itself is not yet present.

Tables

#

Objectives

#

• Understand what a table is in SAP
• Differentiate transparent table, pool table and cluster table
• Know how to create a table and add fields to it
• Master primary key, index and value range concepts
• Understand INCLUDE and APPEND
• Create a table with INCLUDE or APPEND

Definition

#

Imagine a complete Excel sheet: each column is a field, each line is a record. Unlike a structure, data is actually stored in the database.

A table is a physical storage object in SAP, composed of fields (or columns) defined by data elements.
It allows storing, organizing and managing data in a structured way.

Table types

#

Table type	Description
Transparent	Corresponds to a real table in the database, one line = one record
Pool table	Groups several small transparent tables in a single physical table
Cluster table	Groups related tables in a physical table to optimize storage

• Transparent table: an individual card for each record.
• Pool table: several mini-cards stored in a single folder.
• Cluster table: several linked cards combined in an envelope.

Primary keys

#

Primary keys, often abbreviated as “PK” for “Primary Key” in English, are a fundamental concept in database management. A primary key is one or more fields in a database table that uniquely identify each record in that table. Here are some important points to remember about primary keys:

• Record uniqueness: The primary key guarantees that each record in the database table is unique. This means no two records can have the same primary key value.

• Integrity constraint: Primary keys are often defined as an integrity constraint in the database, meaning the database management system (DBMS) guarantees the primary key is respected at all times. Thus, attempts to insert or update records that would violate this constraint are automatically rejected.

• Automatic indexing: Primary keys are often automatically indexed by the DBMS to improve search and join operation performance on the table. This speeds up data access when executing queries.

• Definition during database design: Primary keys are defined during initial database design. Database designers choose fields that should form the primary key based on specific application requirements and relationships between data.

• Types of primary keys: A primary key can be composed of a single field (simple primary key) or multiple combined fields (composite primary key). In the case of a composite primary key, the set of values from all fields forming the key must be unique.

Creating a table

#

Creating a table is like preparing an Excel folder with columns and rows, where each cell is ready to receive data.

1. Transaction SE11

2. Select the Database table option

3. Enter the table name (example ZDRIVER_CAR_FGI).

4. Create or [ F5 ]

5. Enter a description (mandatory) (example SAP Consultants Table).

6. Delivery and Maintenance tab:
   • Delivery class: class A

• Data Browser/Table View Maintenance: Display/Maintenance allowed

7. Fields tab

8. Fill in fields with their FIELDS, KEYS and DATA ELEMENTS

The cropped data element is: VLC_YEAR_OF_CONSTRUCTION

9. Foreign key

Repeat the same steps for the COUNTRY field.

No information to fill in the Currency/Quantity fields tab since there is no unit of measure needed.

10. Save and Activate

11. Enhancement category

Enhancement category is not mandatory but recommended because it defines the type of fields that will compose the table (table extension should be understood as adding fields in the table directly or through an append in the case of standard tables).

For information:

• Can be enhanced without restriction: no rule for table or structure extension.

• Can be enhanced and alphanumeric or numeric: all fields must be either alphanumeric or numeric. The difference with Can be enhanced without restriction is that it won’t be possible to add date or time type fields (for example) in an append or include.

• Can be enhanced and alphanumeric: the table or structure will only be composed of alphanumeric fields and an error will be returned if a field is defined as numeric (it will then be possible to modify the extension type).

• Not enhanced: it will be possible to add a field directly to the initial table or structure, but impossible via an append. Thus, as append is the only way to add a field to a standard table, there will be no possibility to accomplish this task.

• Not classified (default), no extension has been defined for the table or structure.

In the case of our table, there will be no need for restriction, the Can be enhanced without restriction option will therefore be chosen.

12. Input help/check tab

    Here, there’s nothing to add because we don’t have quantity and therefore no unit of measure. When you have to create a table with a field having a quantity such as a number of pieces, a size, the amount of a currency, … you’ll need (just below the line in question) to add a line with the field corresponding to its unit of measure. For example:

    • Quantity of pieces: 13
    • Type of piece: pallet

    or again

    • Amount: 12807
    • Currency: Euros

    In general, this information will be provided to you in the functional specification.

13. Save then click on Technical settings

14. General properties tab, fill in the following elements as follows:

    

    • Data class: APPL0
    • Size category: 0

15. Save then [ Green arrow ] to return to previous screen.

16. Activate

Best practices

#

Best practices	Explanation
Always define primary key	Guarantees record uniqueness
Use existing domains and data elements	Ensures consistency and facilitates maintenance
Add indexes for frequent searches	Optimizes query performance
Document tables	Facilitates understanding and maintenance

• Always define primary key before filling the table
• Reuse data elements and domains to ensure homogeneity

Include and append

#

Include

#

• Allows reusing existing fields from a structure or table in a new table or structure
• Avoids recreating the same fields in multiple places
• Fields appear in blue in SE11
• Any modification to the included structure automatically propagates

Copy a ready-to-use template into a new card, instead of rewriting all columns.

• Reuse to harmonize common fields in multiple tables
• Ensures data consistency

Append

#

• Allows adding additional fields to a table or structure without modifying the original
• Very useful for adapting a standard SAP table to specific needs
• Added fields are specific to your development

Add an extension to a standard card, without touching the original card.
E.g.: add an “Internal employee number” field to a standard customer table.

Append fields must not conflict with existing fields. Always check consistency.

Creating a table with append or include

#

Creation with include

#

1. Create a reusable structure (e.g.: ZST_ADDRESS with CITY, COUNTRY, POSTAL_CODE)
2. Open SE11 to create the table
3. In the Fields tab, add an INCLUDE of the existing structure
4. INCLUDE fields appear automatically and can be used as if you had created them directly
5. Save, Check, Activate

Copy a ready-to-use template into a new card instead of rewriting all columns.

Creation with append

#

1. Open existing table (standard or specific) in SE11
2. Click on Create Append Structure
3. Name the APPEND structure (e.g.: ZAPPEND_CONSULTANT)
4. Add additional fields in this structure
5. Associate APPEND structure to table via Append tab
6. Save, Check, Activate

Add an additional card to an existing folder, without touching original cards.

Summary

#

• A table is a physical storage object in SAP
• Each table is composed of fields defined by data elements
• Primary key uniquely identifies each record
• Tables can be transparent, pool or cluster
• INCLUDE = reuse of existing fields
• APPEND = adding new fields without touching original table
• Creating a table with INCLUDE or APPEND allows saving time, customizing SAP tables and maintaining consistency

---

SAP Views

#

Objectives

#

• Understand what a VIEW is in SAP
• Differentiate types of VIEWS: Database View, Projection View, Help View
• Know how to create a VIEW using existing tables
• Master join and field selection concepts

Definition

#

A VIEW is a logical representation of data from one or more tables.
It doesn’t physically store data but allows accessing a structured and filtered selection.

Imagine an Excel filter that only displays certain columns and rows of a workbook. The VIEW shows filtered data, but doesn’t actually copy it.

View types

#

• Database View: a pivot VIEW that combines multiple Excel tables.
• Projection View: a summary table showing only certain columns.
• Help View: a smart dropdown menu to choose a value.

VIEW type	Description
Database View	Combines fields from multiple tables linked by primary and foreign keys
Projection View	Selection of certain fields from a single table, often for specific reports or modules
Help View	Special for search helps, displays a filtered list of values for a field

VIEWS don’t write to the database, they only serve to consult or filter data.

Creating a view

#

1. Transaction SE11

2. Select View

3. Fill in a view name (for example ZV_EKKO_EKPO)

4. Create or [ F5 ]

5. Select Database view for a view of data present in the Database

6. Fill in a description (for example: View for tables EKKO and EKPO)

7. Tables/Join conditions tab

8. View fields tab

9. Save and Activate

A message will appear with the following information:

The log reports warnings about “key fields” and client dependency. This is normal since the unique key of the EKKO table (EBELN) will possibly repeat as many times as it has items in the EKPO table.

10. Transaction SE16N

A Database View ZV_CONSULTANT_INFO could combine table ZT_CONSULTANT with table ZT_PROJECTS to display consultant, their city and projects in a single VIEW.

The VIEW acts as a logical summary of tables: you can query, filter and display data without touching original tables.

Best practices

#

Best practices	Explanations
Limit fields and tables	Optimizes read performance
Always define joins	Ensures relationships between tables are correct
Name VIEWS clearly	Facilitates understanding and use in programs
Use VIEWS for logical access	Avoids directly manipulating physical tables

For reports and SAP modules, always favor VIEWS rather than tables to access data, to preserve integrity and consistency.

Don’t confuse Database View and physical table: modifying data via VIEW always impacts source table, but some VIEWS (projection/help) can be read-only.

Summary

#

• A VIEW is a logical representation of SAP data
• Types of VIEWS: Database, Projection, Help
• Allows accessing selected or combined data without physical storage
• Ideal for reports, analyses and search helps

An SAP VIEW is like an Excel filter or dashboard: it shows what you need without touching original data.

Search help (F4 Help)

#

Objectives

#

• Understand what search help is in SAP
• Know how to create search help for a field
• Know available dialog types

Definition

#

Search help allows the user to see a list of possible values directly from an SAP field.
It facilitates entry and reduces errors.

Imagine an Excel form with a “City” field. A dropdown list appears to propose all possible cities. Search help works the same way in SAP.

Dialog types

#

Dialog type	Description
Immediate value display	The list displays directly after calling help
Dialog with restriction	A dialog box allows filtering and choosing values to display
Dialog dependent on value set	The system automatically chooses according to number of values

• Immediate display: short dropdown list
• Complex dialog: advanced filter
• Dependent dialog: system decides best display according to number of values

The chosen dialog type influences help performance and ergonomics. For many values, prefer complex dialog.

Creating search help

#

1. Transaction SE11

2. Check the Search help option

3. Enter the name ZAR_MARA (“AR” for Search Help).

4. Select the Elementary search help option

5. Enter a description (mandatory) (example MARA Help).

6. Fill in the Selection method and Text table

• Description: MARA search help

• Selection method: MARA

• Text table: MAKT

7. Select the Immediate value display option (Dialog type).

This search help will display the fields:

• MATNR (material number) which will be both an import and export field
• MAKTX (material description)
• MTART (material type)
• MATKL (material group)

The parameters will look like this:

FIELD	IMP	EXP	PosL	PAR.	Data element
MATNR	X	X	1	1	MATNR
MAKTX			2	2	MAKTX
MTART			3	3	MTART
MATKL			4	4	MATKL

8. Save

9. Check

10. Activate

It’s also possible to test it with the Test… button in the toolbar, via the keyboard shortcut [F8] or through the dropdown menu.

Test the help immediately to verify it works correctly and proposes expected values.

Best practices

#

Best practices	Explanations
Test help after creation	Verifies values are correct and accessible
Use key fields and descriptions	Facilitates value identification
Choose adapted dialog type	Avoids lists that are too long or useless
Document search help	Allows other users to understand its usage

Search helps are particularly useful for fields with fixed or standardized values (e.g.: material, customer, postal code).

If the number of values is very high, favor complex dialog or filtered view, otherwise the help will be slow or unusable.

Summary

#

• Search help allows proposing possible values for an SAP field
• It can be elementary or collective and is based on a table or view
• Three dialog types allow adapting display according to data quantity
• Always save, check and activate help after creation

Search help is like a smart dropdown menu in Excel: it guides the user to avoid errors and speed up entry.