See below for a list of sap data element attributes, description and what each one is used for
A data element is an elementary type. It describes the type attributes (data type, field length and possibly the number of decimal places) and screen information (explanatory text or field help) about unstructured data objects (table fields and structure fields or variables).
Table fields and structure fields with the same contents should refer to the same data element. This ensures that the attributes of these fields are always consistent.
A data element can be referenced in ABAP programs with TYPE. This permits you to define variables that take on the type attributes of the data element in an ABAP program.
Different technical fields of the same type can be combined in a domain. Fields referring to the same domain are changed at the same time when a domain is changed. This ensures the consistency of these fields.
A user only has authorization for company code ‘MYCO’. This company code is stored in memory at the beginning of a transaction under the corresponding parameter ID.
Fields that refer to the data element are automatically filled with the value ‘MYCO’ in all subsequent screen templates.
A field in the screen template is only filled automatically with the value stored under the parameter ID of the data element if this was explicitly permitted in the Screen Painter.
You can create a change document object for a business object. This change document object contains the tables in which the data of the business object is stored. Function modules that are called in the corresponding application programs and that log the changes at runtime can be generated from the change document object.
Logging only takes place if the fields whose contents were changed refer to a data element that was flagged as relevant for the change document.
You can go to the maintenance screen for change documents from the initial screen of the ABAP Workbench with Development -> Other tools -> Change documents.
The short text is used as an explanatory text in documentation (F1 Help), and when lists are generated.
A heading can be defined to output the field values in lists. This heading is automatically included in the list header row, in the logon language.
There are the following types of search helps:
Elementary search helps to implement a search path for determining the possible entries.
Collective search helps contain several elementary search helps. A collective search help, therefore, provides several alternative search paths for possible entries.
Append search helps can be used to enhance collective search helps delivered by SAP with customer-specific search paths without requiring modification.
The three components of the input help process described by a search help are the outer interface, the online behaviour and the method of data collection.
The outer interface is defined by specifying the interface parameters. They define the context information to be used in the input help process and the attributes to be sent to the screen by the input help.
The search help attachment defines the field contents for parametrizing an import parameter and the fields of the input template in which the contents of the export parameters should be returned.
The dialog behaviour and data collection are defined differently for elementary search helps and collective search helps.
The behaviour of a search help can be made more flexible than usual with search help exits.
The parameters of a search help define the context data to be used in the input help and the data that can be returned to the input template.
There must be a parameter of the search help corresponding to each field in the dialog box for restricting values and to each field in the hit list.
The data class describes the data format at the user interface.
If a table field, structure field or a data element is used in an ABAP program, the data class is converted to a format used by the ABAP processor.
When a table is created in the database, the data class of a table field is converted to a corresponding data format of the database system used.
Some data classes have a fixed length. For example, the data class CLNT (client) always has three places. If you enter an invalid length for such a data class, the system will give you a warning and then correct the error automatically.
The types RAWSTRING and STRING for LOB s have a variable length. A maximum length can be specified, but there is no upper limit. The maximum length is an actual length that cannot be exceeded. The maximum length is used for optimizations when storing string fields in the database.
The type SSTRING also has a variable length, but this is restricted upwards by the maximum length that can be specified. The greatest maximum length is 1333. The benefit of using it, and not CHAR, is that it is assigned to the ABAP type string. Its advantage over STRING is that it can also be used for key fields in database tables.
When using data types from ABAP Dictionary which are based on the predefined types RAWSTRING, STRING, and SSTRING, you have to consider in ABAP programs that the maximum lengths defined in ABAP Dictionary have no effect on the assigned ABAP types string and xstring. As a result, writing a string that is too long to a database can raise an exception. If required, you therefore have to apply a length restriction for strings in ABAP programs, for which the predefined function dbmaxlen can be used.
Decimal places are only meaningful for the data types CURR, DEC, FLTP, QUAN, DF16_DEC, and DF34_DEC.
Type category of the row type for a table type which can be defined by:
The data type attributes of a data element can be defined by:
In the maintenance screen you can set the option you require by setting the appropriate flag (domain, built-in type, reference type) and filling in the corresponding input fields.
If this flag is set, the field content is always displayed in the basic writing direction LTR (left to right), even if the write direction of the window is RTL (right to left) – for example when logging on in Hebrew or Arabic.
When logging on in languages whose basic writing direction is LTR, this flag is irrelevant. This is the case for all languages except for Hebrew and Arabic.
The field is particularly useful for fields where content consists of digits or a combination of digits, special characters, and letters, because these may be unreadable in the writing direction RTL. Examples are telephone numbers and material numbers. SAP Note 1291845 provides further background information.
The Unicode character set contains special formatting characters with which the visual sequence can be influenced for displaying bi-directional scripts like Hebrew and Arabic. The characters themselves are not visible.
The input of invisible BIDI formatting characters in fields where data is entered can be deactivated system-wide. The characters are then filtered out of the data stream when data is exchanged between the GUI and application server. This system setting can be made with report I18N_SET_DATAELEMENT_FLAGS.
If the flag “No BIDI Filtering” is set for a data element, the BIDI formatting characters can always be entered in a ready-for-input field that links to this data element, even if filtering is activated system-wide.
If this indicator is set, the mechanism that the SAP GUI uses to handle the input history of a screen input field is switched off.
It makes sense to switch off the input history for fields that contain sensitive data (for example, account numbers).