◉ are used to construct the actual data types (data elements, structures (including database tables and views), table types, and CDS entities) in ABAP Dictionary In ABAP, however, they cannot be addressed directly using only these types and are therefore known as external data types.
◉ have special technical and semantic attributes that support modeling of semantic models.
◉ represent an interface between the predefined ABAP types and all possible vendor-specific data types of the supported databases. A corresponding mapping takes place in both directions.
The following sections describe the attributes of the predefined data types in ABAP Dictionary:
◈ Overview of All Predefined Dictionary Types
The following tables show the predefined types in ABAP Dictionary and their fundamental technical attributes. For each predefined data type in ABAP Dictionary, the last column specifies the predefined ABAP type to which the predefined type is mapped in type references from an ABAP program to ABAP Dictionary. An initial value is assigned to most predefined data types. These initial values are applied, for example, when initial dynpro fields are displayed and when database fields are initialized.
General Types
Predefined data types without special semantic attributes.
Numeric Types
| Type | Valid Places m | Initial Value | Meaning | ABAP Type |
| INT1 | 3 | 0 | 1-byte integer, 0 to 255 | b |
| INT2 | 5 | 0 | 2-byte integer, -32,768 to 32,767 | s |
| INT4 | 10 | 0 | 4-byte integer, -2,147,483,648 to +2,147,483,647 | i |
| INT8 | 19 | 0 | 8-byte integer, -9,223,372,036,854,775,808 to +9,223,372,036,854,775,807 | int8 |
| DEC | 1-31 | 0 | Packed number BCD format | p, length m DIV 2 + 1 |
| DF16_DEC | 1-15 | 0 | Decimal floating point number stored in BCD format | decfloat16 |
| DF16_RAW | 16 | 0 | Decimal floating point number stored in binary format | decfloat16 |
| DF34_DEC | 1-31 | 0 | Decimal floating point number stored in BCD format | decfloat34 |
| DF34_RAW | 34 | 0 | Decimal floating point number stored in binary format | decfloat34 |
| FLTP | 16 | 0 | Floating point number | f |
Character-Like Types
| Type | Valid Places m | Initial Value | Meaning | ABAP Type |
| CHAR | 1-30000, maximum of 1333 for table fields | m blanks | Character string | c, length m |
| LCHR | 256-32000 | None | long character string | c, length m |
| SSTRING | 1-1333 | Empty string | Character string | string |
| STRING | 256-... | Empty string | Character string (CLOB) | string |
Byte-like types
| Type | Valid Places m | Initial Value | Meaning | ABAP Type |
| RAW | 1-32000 maximum of 255 for table fields | None | Byte string | x, length m |
| LRAW | 256-32000 | None | Long byte string | x, length m |
| RAWSTRING | 256-... | Empty string | Byte string (BLOB) | xstring |
Special Types
Predefined data types with special semantic attributes.
Date Types/Time Types
| Type | Valid Places m | Initial Value | Meaning | ABAP Type |
| DATS | 8 | 00000000 | Date in the format YYYYMMDD | d |
| TIMS | 6 | 000000 | Time in the format HHMMSS | t |
| ACCP | 6 | 6 blanks | Posting period in the format YYYYMM | n, length 6 |
Character-Like Types with Special Semantics
| Type | Valid Places m | Initial Value | Meaning | ABAP Type |
| NUMC | 1-255 | m zeroes | Numeric text | n, length m |
| CLNT | 3 | 000 | Client | c, length 3 |
| LANG | 1 | Blank | Language key | c, length 1 |
Currency Fields and Quantity Fields
| Type | Valid Places m | Initial Value | Meaning | ABAP Type |
| CURR | 1-31 | 0 | Currency field in BCD format | p, length m DIV 2 + 1 |
| CUKY | 5 | 5 blanks | Currency key for currency fields | c, length 5 |
| QUAN | 1-31 | 0 | Quantity field in BCD format | p, length m DIV 2 + 1 |
| UNIT | 2-3 | 2 or 3 blanks | Unit key of a quantity field | c, length m |
Obsolete Types
| Type | Valid Places m | Initial Value | Meaning | ABAP Type |
| DF16_SCL | 16 | 0 | Decimal floating point number stored in binary format with scaling specified (obsolete) | decfloat16 |
| DF34_SCL | 34 | 0 | Decimal floating point number stored in binary format with scaling specified (obsolete) | decfloat34 |
| PREC | 2 | 0 | Obsolete data type | s |
| VARC | 1-... | None | Obsolete data type | c, length m |
◈ Attributes of the Predefined Dictionary Types
1. General dictionary types
➤ Integers, packed numbers, binary floating point numbers
The following types are used for general descriptions of the numeric types (except for decimal floating point numbers):
- INT1, INT2, INT4 INT8 for integer numbers
These types describe general 1-byte, 2-byte, 4-byte and 8-byte integers. The ABAP types b and s, assigned to the types INT1 and INT2, cannot be specified either statically or dynamically in ABAP statements. These types only occur in ABAP programs, in relation to the types INT1 and INT2 from ABAP Dictionary.
- DEC for packed numbers
This type describes general packed numbers in BCD format. When used, a length and the number of decimal places must be added to the type.
- FLTP for binary floating point numbers
This type describes general binary floating point numbers with 16 places. Table fields of this type cannot be used as key fields of database tables.
Notes
- An odd number of places should be used in the definition of data types based on the predefined type DEC. These values are stored in BCD format, for which in ABAP (data type p), only an odd number of places is possible, since a half byte is used for the sign. If a data type DEC has an even number of characters, however, the length of the associated ABAP type p is rounded up and hence contains the next highest odd number of places. This can cause, for example, overflows and then exceptions when writing to database tables. The same applies to the predefined types CURR, DF34_DEC, DF16_DEC, and QUAN, which are handled technically like the type DEC.
- The output formats for fields on dynpros and Web Dynpros and in the statements WRITE or WRITE TO can be predefined for the numeric types specific to each user in the user master record. The output length required for formatted output is usually greater than the number of places in ABAP Dictionary. If the output length is too short, any formatting characters are suppressed.
- If a dynpro field has one of the predefined numeric types, the output of a sign must be defined in a domain so that negative values can be represented.
➤ Decimal floating point numbers
In decimal floating point numbers, a maximum of 16 or 34 places are returned exactly in the mantissa depending on the data type.
◈ Handling in ABAP Dictionary
◈ Handling in Dynpros - Output Length and Output Style
◈ Handling in ABAP Programs
Handling in ABAP Dictionary
In ABAP Dictionary, the following data types are available for decimal floating numbers:
◈ DF16_DEC and DF16_RAW for 16-digit numbers.
◈ DF34_DEC and DF34_RAW for 34-digit numbers.
These data types are a replacement for real decimal floating point types that are supported by all database systems:
◈ DF16_DEC and DF34_DEC
In database fields of this type, decimal floating point numbers are stored as a packed number (format DEC). The length and the number of decimal places must be specified when defining a data type in ABAP Dictionary. Calculations (SELECT with appropriate SQL expressions or with the aggregate functions SUM and AVG, UPDATE with SET +, and -) can be performed on the database for this type. When there is a write to the database, the system implicitly rounds off to the number of decimal places and decimal overflows can occur. Database fields with these types can be edited in Native SQL.
◈ DF16_RAW and DF34_RAW
In database fields of this type, decimal floating point numbers are stored as binary (In RAW format). The length is set to 16 or 34 places. Values can be sorted, compared, and used in indexes. For this type, no calculations can be executed on the database. This is an SAP-specific format, which means that the corresponding fields also cannot be edited in Native SQL. The scaling is lost when writing to the database.
Notes
◈ The actual predefined data type from ABAP Dictionary used for decimal point numbers depends on their purpose.
◈ The types DF16_DEC and DF34_DEC can be used for calculations on the database, but their value ranges are smaller than those of real decimal floating point numbers.
◈ The types DF16_RAW and DF34_RAW cover the whole value range, but are not recognized as numbers by the databases.
◈ As in the general packed numbers, the number of places in the types DF16_DEC and DF34_DEC should be odd.
◈ As well as the types above, there are also the obsolete predefined data types DF16_SCL and DF34_SCL for decimal floating point numbers with scaling.
◈ In database fields of this type, decimal floating point numbers are stored in the same way as DF16_RAW or DF34_RAW (length 16 or 34 places, and the same restrictions apply). The scaling must be specified in a direct successor database field with type INT2. When a decimal floating point number is written, this field is automatically filled with the scaling and during reading, the scaling is automatically taken from it.
◈ It is strongly advised not to use the types DF16_SCL and DF34_SCL. Their functions are rarely needed and the additional column for scaling makes them too complicated and error-prone to use correctly.
Handling in Dynpros - Output Length and Output Style
The maximum output length that can be specified in a domain for a 16-character decimal floating point number is 24. For a 34-character numbers, 46 is the maximum output length. These are also the default values.
In a domain, or directly in a structure component created using one of the types for decimal floating numbers (but not in data elements with directly specified technical attributes), one of the following output styles is always defined. The output style defines how a dynpro field defined with reference to this domain (or a corresponding ABAP field in the case of list output) is formatted.
◈ Simple
Mathematical or scientific notation (depending on space)
◈ Leading Sign to the Right
Commercial notation (canceled if not enough space instead of implicit transformation to scientific notation)
◈ Scale-preserving
Format with preservation of scaling, including trailing zeroes in the decimal places
◈ Scientific
Scientific notation
◈ Scientific with leading zero
Scientific notation with a 0 as an integer digit
◈ Scale-preserving scientific
Scientific notation including trailing zeroes in the mantissa.
◈ Technical
Scientific notation where the exponent is always an integer and a multiple of 3. The value range of the integer digits is between 1 and 999 (except if the source field has the value 0).
For dynpro fields whose data type is not defined in ABAP Dictionary, the output style can also be determined in Screen Painter. In the case of formatting with the statements WRITE or WRITE TO, the addition STYLE is available (as for the string templates).
Notes
◈ If scientific notation is used, a limited number of displayed places in the mantissa is recommended. This can be specified using the predefined function rescale.
◈ The "scale-preserving" style ensures that the scaling is restored in conversions from dynpro fields to ABAP, and not just the original value.
◈ If vertically aligned decimal separators and exponents are needed on UIs, the scale-preserving scientific notation can be used.
Handling in ABAP Programs
The ABAP types which correspond to the 16 or 34 figure decimal floating numbers in ABAP Dictionary are decfloat16 and decfloat34, which are handled internally according to the IEEE-754-2008 standard, and are supported by all ABAP operations. In arithmetic SQL expressions, decimal floating point numbers are not supported.
The STYLE addition after WRITE [TO] and the STYLE formatting option in embedded expressions are available for the formatting of decimal floating numbers in programs. These overwrite the output style defined in ABAP Dictionary.
➤ Character-like and byte-like types
◉ Character Strings
◉ Byte Chains
◉ Notes on Strings
◉ Use in Open SQL
Character Strings
The following predefined data types in ABAP Dictionary are available for general character strings:
◉ CHAR for text fields
The predefined type CHAR, mapped to the ABAP type c, is used to describe general text fields with a maximum length of 30000 characters (only 1333 characters for table fields).
◉ LCHR for long text fields
The predefined type LCHR, also mapped to the ABAP type c, is used to describe general text fields with lengths between 256 and 32000 characters. In database tables, the maximum length must be specified as the value of a preceding INT2 or INT4 field. Table fields of this type cannot be used as key fields of database tables or in any positions in Open SQL statements.
◉ SSTRING for short text strings
The predefined type SSTRING is mapped to the ABAP type string, but handled like the type CHAR or VARCHAR in ABAP Dictionary and by database tables. The length is restricted to a maximum of 1333, but table fields of this type can also be used as key fields by database tables and used by Open SQL statements in almost all positions where text fields are possible.
◉ STRING for text strings
The predefined type STRING is mapped to the ABAP type string and also handled like a text string (CLOB) in ABAP Dictionary and by database tables. Table fields of this type cannot be used as key fields or index fields in database tables or in any positions in Open SQL statements.
Notes
◉ In general structures, the length of a component of type CHAR is not restricted to 1333.
◉ In database tables, there can be only one table field of the type LCHR and it must be the last table field. This means that the type LRAW cannot be used simultaneously in the same database table. If the statement SELECT is used to read an LCHR field, the preceding length field must also be read. In writes using Open SQL, the length field must be given the correct value or data may be lost.
◉ LCHR is no longer recommended for new developments. The type STRING is recommended instead, however it is also not suitable for key fields of database tables or for unrestricted use in Open SQL. Where possible, SSTRING can be used here instead.
◉ Switching existing dictionary objects from LCHR to STRING or SSTRING, on the other hand, can be critical, since all ABAP types and ABAP objects that reference dictionary objects like this are then given a deep data type. A switch from a flat data type to a deep data type usually constitutes an incompatible change and can produce syntax errors in ABAP programs.
Byte Chains
The following predefined data types in ABAP Dictionary are available for general byte chains:
◉ RAW for byte fields
The predefined type RAW, mapped to the ABAP type x, is used to describe byte fields with a maximum length of 32000 characters (only 255 characters for table fields).
◉ LRAW for long byte fields
The predefined type LRAW, also mapped to the ABAP type x, is used to describe byte fields with lengths between 256 and 32000 characters. In database tables, the maximum length must be specified as the value of a preceding INT2 or INT4 field. Table fields of this type cannot be used as key fields of database tables or in any positions in Open SQL statements.
◉ RAWSTRING for byte strings
The predefined type RAWSTRING is mapped to the ABAP type xstring and also handled like a byte string (BLOB) in ABAP Dictionary and by database tables. Table fields of this type cannot be used as key fields or index fields in database tables or in any positions in Open SQL statements.
Notes
◉ In general structures, the length of a component of type RAW is not restricted to 255.
◉ In database tables, there can be only one table field of the type LRAW and it must be the last table field. This means that the type LCHR cannot be used simultaneously in the same database table. If the statement SELECT is used to read an LRAW field, the preceding length field must also be read. In writes using Open SQL, the length field must be given the correct value or data may be lost.
◉ LRAW is no longer recommended for new developments. The type RAWSTRING is recommended instead, however it is also not suitable for key fields of database tables or for unrestricted use in Open SQL.
◉ Switching existing dictionary objects from LRAW to RAWSTRING, on the other hand, can be critical, since all ABAP types and ABAP objects that reference dictionary objects like this are then given a deep data type. A switch from a flat data type to a deep data type usually constitutes an incompatible change and can produce syntax errors in ABAP programs.
Notes on Strings
The following points must be remembered when using predefined data types for text strings or byte strings:
- The types STRING and RAWSTRING for LOBs have a variable length. A maximum length can be specified, but there is no upper limit.
- 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 SSTRING, 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 databases and in any places in Open SQL in which the type CHAR is also possible.
- The maximum possible length for the types STRING and RAWSTRING and the mandatory maximum length for SSTRING must not be exceeded in writes performed on database fields of these types using Open SQL. If it is exceeded, an exception of the class CX_SY_OPEN_SQL_DB is raised. Truncations of strings when read to a target field, however, are ignored.
- In ABAP programs, maximum lengths defined in ABAP Dictionary for the types STRING, RAWSTRING, and SSTRING are ignored by 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, the ABAP program itself must handle the length restrictions on strings.
- The maximum length of data types based on STRING, RAWSTRING, and SSTRING can be identified in an ABAP program using the predefined function dbmaxlen.
- Trailing blanks are saved in table fields of the type STRING but not in table fields of the type SSTRING. This is particularly significant when short strings are used as key fields of database fields, since trailing blanks cannot be used as distinguishing characteristics here.
- LOBs of the types STRING and RAWSTRING are usually handled as deep data objects in which only one LOB locator is saved within the data record. This locator references the actual string data. Database fields of the type SSTRING are usually saved as flat fields. An empty long string can also be saved using the null value. The actual handling, however, depends on the individual database system and is not important for ABAP programs.
- If a work area or an internal table is used to access table fields of the types SSTRING, STRING, or RAWSTRING in Open SQL, the work area or the row type of the internal table must be compatible with the database structure.
- If structures, database tables, or views that have strings as components are used for typings in ABAP, it must be remembered that these objects are deep structures. This means, for example, that they cannot be used in the TABLES statement (obsolete for database accesses) or for typing the obsolete table parameters of procedures.
- Access may be slower for long strings (LOBs) in database tables than for other data types. If not all data is needed at once (and to bypass any memory limits on the application server), streaming and locators can be used to access long strings.
The following restrictions apply when accessing database fields with character-like and byte-like types in Open SQL:
- There are no access restrictions to database fields with the data types CHAR and RAW in Open SQL.
- Database fields with the data types STRING and RAWSTRING plus LCHR and LRAW cannot be used in the following operand positions:
- As arguments of aggregate functions and SQL expressions
- In the SELECT list when the addition DISTINCT is used
- In the SELECT list when the addition FOR ALL ENTRIES is used In the strict mode from Release 7.40, SP05, this produces a syntax error. Otherwise, the extended program check produces a syntax warning that can be hidden by a pragma.
- In the WHERE clause or HAVING clause and in ON conditions of joins.
- In the GROUP BY clause
- In the ORDER BY clause
- The data type SSTRING can be used without restrictions, except in the coalesce function and in CASE expressions.
The same restrictions apply to the obsolete data type VARC as to STRING and RAWSTRING plus LCHR and LRAW.
2. Special dictionary types
◆ Date types and time types
The following character-like data types in ABAP Dictionary describe date fields and time fields:
◈ DATS or date fields
From a technical perspective, the predefined data type DATS describes objects of the type CHAR with a length of 8 characters. It is designed for calendar dates in the format YYYYMMDD, but this is not checked when performing writes and reads on database fields with this type. Automatic checks are only made for dynpro fields typed with reference to DATS. In ABAP, DATS is assigned to the special type d and the associated rules apply.
◈ TIMS for time fields
From a technical perspective, the predefined data type TIMS describes objects of the type CHAR with a length of 6 characters. It is designed for times in the format HHMMSS, but this is not checked when performing writes and reads on database fields with this type. Automatic checks are only made for dynpro fields typed with reference to TIMS. In ABAP, TIMS is assigned to the special type t and the associated rules apply.
◈ ACCP for posting periods
From a technical perspective, the predefined data type ACCP describes objects of the type CHAR with a length of 6 characters. It is designed for posting periods in the format YYYYMM, but this is not checked when performing writes and reads on database fields with this type. Automatic checks are only made for dynpro fields typed with reference to ACCP.
Notes
◈ The output formats for fields on dynpros and Web Dynpros and in the statements WRITE or WRITE TO can be predefined for the types DATS and TIMS specific to each user in the user master record. The output length required for formatted output is usually greater than the number of places in ABAP Dictionary. If the output length is too short, any formatting characters are suppressed.
◈ When a dynpro field is represented with reference to the type ACCP (but not in the statements WRITE or WRITE TO) and there is enough output length, a point is inserted between the year YYYY and the month MM.
◆ Special character-like types
The following character-like data types in ABAP Dictionary have a special semantic meaning:
◈ NUMC for numeric texts
From a technical perspective, the predefined data type NUMC describes objects of the type CHAR with a maximum length of 255 characters. It is designed for numeric texts, but this is not checked when performing writes and reads on database fields with this type. Automatic checks are only made for dynpro fields typed with reference to NUMC. In ABAP, NUMC is assigned to the special type n and the associated rules apply.
◈ CLNT for client columns
From a technical perspective, the data type CLNT describes objects of the type CHAR with length 3. If the data type CLNT is used for the first key field of a database table, this makes the database table client-specific.
◈ LANG for text language
From a technical perspective, the predefined data type LANG describes objects of the type CHAR with length 1. It is dedicated to language keys. A component of structures or database tables that has the data type LANG, can be identified as text language. Text language is used to convert character-like components of the structure when importing data from data clusters and for binary RFC protocols for passing TABLES parameters between MDMP systems and Unicode systems.
Note
When the statements WRITE or WRITE TO are used to represent a dynpro field with the type LANG (and when a field that references this type is formatted), this field has an output length of 2 and is converted automatically from the single-character internal language ID to the matching two-character ISO ID using the conversion routine ISOLA (and back).
◆ Currency fields
A currency field is a component of a structure, database table, or view defined in ABAP Dictionary of type CURR, for the inclusion of an amount in a specific currency. The amount is specified as a whole number in the smallest unit of the currency. A currency field must be associated with a currency key of a structure, database table, or view that specifies the currency and number of decimal places. A currency key is a component of a structure, database table, or view defined in ABAP Dictionary, has the type CUKY, and can contain a currency ID from the database table TCURC.
By default, the number of fractional digits for a currency is always two. Currencies with a different number of fractional digits must also be entered in the table TCURX, where the number of fractional digits can be defined explicitly.
1. Handling in ABAP Dictionary
2. Handling in Dynpros
3. Handling in ABAP Programs
Notes
▣ Currencies are handled as specified by the data saved in the database tables TCUR... of the package SFIB. The exchange rates and other settings can be edited in transaction OB08.
▣ Currency fields are defined as elements of CDS entities using semantics annotations.
1. Handling in ABAP Dictionary
A data element of data type CURR is handled as a field of data type DEC and is stored in database tables in the BCD format. When creating a data element or a structure component of the data type CURR in the ABAP Dictionary tool, a number of fractional digits other than zero must be defined. The standard value is two fractional digits.
For every structure component of data type CURR, a component of the same structure or of a different structure, database table, or view must be specified in the individual editing of the component as a reference field, which has the data type CUKY. This field is the currency key which determines the actual currency. From a technical perspective, the data type CUKY is handled like a type CHAR with length 5.
Notes
▣ The number of fractional digits for the currency defined by the currency key of type CUKY only determines the formatting and checking of a currency field on a dynpro. In principal, it is independent of the number given for the currency field of type CURR. The default value of two fractional digits for currency fields in ABAP Dictionary is chosen because most of the currencies in the TCURC database table have two fractional digits and are not entered in the database table TCURX. It is not advisable to use any other value, since in this case any unforeseen operations with currency keys in ABAP programs are largely ignored.
▣ The conversion function CURRENCY_CONVERSION in ABAP CDS also assumes two decimal places for currency fields. If the function for currency fields is used with other amounts of decimal places, unexpected behaviour may be produced.
▣ As in general packed numbers, the number of places in type CURR should be odd.
2. Handling in Dynpros
For the display of an input/output field of type CURR on a dynpro, the content is displayed as character-like and in accordance with a type dependent template, as for all dynpro fields. The positioning of the decimal point for a currency field of type CURR on a dynpro is thereby completely independent of the number of fractional digits specified by the data element in ABAP Dictionary (greater than or equal to one, the default value is two). The number of fractional digits on a dynpro is determined as follows:
▣ When displaying a dynpro field of type CURR, the reference field for the currency key is searched for in the global data of the current ABAP program. The content of this field must be a valid currency ID from the database table TCURC. If the reference field is not found or there is no entry in the TCURX database with the content of the field, the currency field is displayed with two fractional digits by default.
The reference field is either defined in the relevant structure in ABAP Dictionary or was determined using Screen Painter for the attributes of the dynpro field. It does not have to be present on the dynpro itself.
▣ If the currency ID for the reference field is found in the database table TCURX, the currency field is displayed with the fractional digits specified there. This also applies to initial reference fields.
Note: A dynpro therefore only uses the string of digits of a currency field from the ABAP program (or a conversion routine in between) or just sends this. Information about currency keys and fractional digits is not passed automatically. It must be ensured that the reference field for PBO is filled with the appropriate value. For PAI, the correct currency key plays a part in the automatic format check. Especially on dynpros in which currency fields are displayed in differing currencies, it must be ensured that the reference field is transported before the currency by using the statements CHAIN and FIELD.
3. Handling in ABAP Programs
The ABAP type which corresponds to the CURR data type is p. An ABAP data object, which is declared with reference to a dictionary type of type CURR, has the number of fractional digits defined there (greater than or equal to one, the default value is two). These fractional digits are respected for all operations and calculations, as for all packed numbers. The only exceptions are the programs for which the program property fixed point arithmetic has not been set.
To work correctly with a currency field, all digits in the number must be recorded as currency amounts in the smallest possible currency units, regardless of the number of fractional digits. This occurs automatically sometimes, for example, if CURRENCY is used after WRITE [TO] or the formatting option CURRENCY in an embedded expression of a character string template. For other operations, the following restrictions apply:
▣ Comparison, addition, subtraction, and division of two currency fields with the same number of fractional digits are not critical.
▣ Multiplication with and division by a currency-independent number is not critical.
▣ All other operations are critical, for example:
- Multiplication of two currency fields.
- Operations between two fields with different currencies that include assignments.
- Assignments of currency-independent numbers to currency fields.
Do not expect accurate results when performing critical operations if the number of fractional digits in the program does not match the number in the currency.
Note: For currencies, one of the data types for decimal floating point numbers is recommended rather than the data type CURR. The currency-friendly formatting is supported on dynpros by output styles and by style-friendly formatting in ABAP programs.
◆ Quantity fields
A quantity field is a component of a structure, database table, or view of type QUAN defined in ABAP Dictionary, used to include a quantity in a specific unit. A quantity field must be associated with a unit key of a structure, database table, or view which determines the unit and the number of fractional digits. A unit key is a component of a structure, database table, or view of type UNIT defined in ABAP Dictionary and can contain a unit ID from the database table T006.
1. Handling in ABAP Dictionary
2. Handling in Dynpros
3. Handling in ABAP Programs
Notes
▣ Quantities and units are handled as specified by the data saved in the database tables T006... in the package SZME. This data can be edited using the transaction CUNI.
▣ Quantity fields are defined as elements of CDS entities using semantics annotations.
1. Handling in ABAP Dictionary
A data element of data type QUAN is handled as a field of data type DEC and is stored in database tables in the BCD format. When creating a data element or a structure component of the data type QUAN in the ABAP Dictionary tool, any number of fractional digits can be defined. The default value is no fractional digits.
For every structure component of data type QUAN, a component of the same structure or of a different structure, database table, or view must be specified in the individual editing of the component as a reference field, which has the data type UNIT. This field is the unit key which determines the unit of the quantity. From a technical perspective, the data type UNIT is handled like a type CHAR with length 2.
Notes
▣ The number of fractional digits for the unit defined using the unit key of type UNIT only influences the formatting of a quantity field on a dynpro. In principal, it is independent of the number given for the quantity field of type QUAN.
▣ As in general packed numbers, the number of places in type QUAN should be odd.
2. Handling in Dynpros
For the display of an input/output field of type QUAN on a dynpro, the content is displayed as character-like and in accordance with a type-dependent template, as for all dynpro fields. The system tries to create a display which suits the unit of the quantity field.
To determine the unit, the global data of the current ABAP program is searched for the reference field associated with the field for the unit key. The content of this field must be a valid unit ID from the database table T006. If the reference field is not found or if there is no entry in the database table T006 with the content of the field, the quantity field is displayed as a regular field of type DEC.
The reference field is either defined in the relevant structure in ABAP Dictionary or was determined using Screen Painter for the attributes of the dynpro field. It does not have to be present on the dynpro itself.
If the unit ID of the reference field is found in the column MSEHI of the database table T006 and the quantity field does not have any fractional digits with a value other than 0, except the accuracy defined in the DECAN column, the quantity field is displayed with this accuracy. For a unit without fractional digits, the decimal separator is suppressed. If the quantity field has fractional digits with a value other than 0 outside of its accuracy, however, it is displayed as a regular field of type DEC.
Note
A display that matches the accuracy of a quantity field is only then possible if no information is lost. This allows average values instead of integer units to be displayed in a relevant quantity field, for example.
3. Handling in ABAP Programs
The ABAP type which corresponds to the data type QUAN is p. An ABAP data object declared with reference to a dictionary type of type QUAN has the number of fractional digits defined there. These fractional digits are respected for all operations and calculations, as for all packed numbers.
The unit defined for a quantity field only plays a part in ABAP programs if it is specified after the addition UNIT of the statement WRITE [TO].
3. Obsolete dictionary types
The following predefined data types in ABAP Dictionary are obsolete and should no longer be used:
◉ The data types DF16_SCL and DF34_SCL for decimal floating point numbers with scaling are obsolete and their use is strongly discouraged.
◉ The data type PREC is obsolete and should no longer be used. In ABAP Dictionary and in ABAP programs, it is handled like INT2, despite the predefined length (2). The length 2 is relevant only for dynpro fields of the type PREC, which can have two-character positive values at most. The property sign cannot be set for a domain of the type PREC
◉ The data type VARC is obsolete and cannot be used for new definitions. It was previously used for character strings with variable lengths. Existing data types with this predefined type can still be used. When table fields with this type are used in Open SQL, the same restrictions apply as to fields with the types STRING and RAWSTRING plus LCHR and LRAW.
The predefined types in ABAP Dictionary are used for the definition of the elementary parts of all data types, including reference types in ABAP Dictionary, and for specifying some types in Open SQL and ABAP CDS. The predefined types in ABAP Dictionary cannot be specified directly in any places other those specified below.
◉ Data elements
A data element for an elementary data type has either a directly specified predefined type or a type specified using a domain. In references to data elements in an ABAP program, this type is mapped to predefined ABAP type in accordance with the last column of the tables of predefined types.
◉ Structures, database tables, and classic views
The elementary components of a structure have either a directly specified predefined type or a type specified using a data element. In references to structures in an ABAP program, the structures are mapped to a structured type, where the elementary components are mapped to predefined ABAP types in accordance with the last column of the tables of predefined types. The same applies to the table fields of database tables and view fields of classic views.
◉ Table types
The row types of a table type are defined using existing data types from ABAP Dictionary, whose elementary components have a predefined type (as shown above). When a reference is made to a table type in an ABAP program, the type is mapped to a matching ABAP type. Here, the elementary components are mapped to predefined ABAP types in accordance with the tables of predefined types.
◉ Reference types
Data elements, components of structures, or row types of table types can be reference types. Reference types for data reference variables with an elementary static data type are defined by specifying a predefined type directly or by using a data element.
◉ Types specified in SQL
- Typing of elements and input parameters of CDS entities in ABAP CDS.
- Cast expression cast in the DDL in ABAP CDS
- SQL expression CAST in Open SQL
The data type of all elementary components in a CDS entity, such as view fields, literals, parameters, and other operands is based indirectly on the predefined data types in ABAP Dictionary.
Unlike when using the data types above, TYPE references to the predefined data types in ABAP Dictionary are not possible in ABAP programs. In addition to the role of predefined types from ABAP Dictionary in defining data types, these predefined types in must also be considered in Open SQL statements and when working with dynpros:
◉ Open SQL statements work with database tables defined in ABAP Dictionary whose columns have external data types to which the actual platform-dependent types of the databases are mapped.
◉ Screen fields are declared in Screen Painter, also with reference to external data types. In dynpro fields, the special semantic attributes of their data type are usually significant and are evaluated for input masks and for checking input.
Note: In ABAP development, only mappings from the predefined dictionary types to the predefined ABAP types are relevant. In database accesses using Open SQL, the actual database type, such as NVARCHAR, is replaced by the dictionary type, in this case CHAR.
Example
The following type reference in an ABAP program does not use the predefined type INT2 directly. Instead, it used the identically named data element INT2 whose type is itself defined using the identically named domain INT2. Here, the predefined type INT2 is specified.
DATA num TYPE int2.
No comments:
Post a Comment