Often, the way that R/3 stores data differs from the user's expectation of how data should appear. This difference can cause a lot of confusion to users, especially when they search for data.

Let's consider users who run a report for a range of G/L accounts: They want to select all of the loan accounts in the 140000 range using report RFSSLD00, G/L account balances. When they enter the range 140000 to 149999, they get all of the accounts they want (Figures 1 and 2). However, if they use the pattern 14*, then they find nothing (Figure 3).

Figure 1

RFSSLD00 selection with a G/L account range

Figure 2

Successful selection with a G/L account range

Figure 3

Unsuccessful selection with a G/L account pattern

This problem occurs because of the difference between the external display of account numbers and R/3's internal storage format. This is an issue that affects customer numbers, vendor numbers, material numbers, cost center numbers, and numerous other types of master data numbers.

A G/L account number such as 144099 is stored internally by R/3 as 0000144099. The translation between internal and external format is performed in R/3 by a conversion exit (Figure 4).

Figure 4

How a conversion exit works

Where Else Are Conversion Exits Used?

I will focus on the ALPHA conversion exit in this article, but it is important to note that many other fields make use of SAP R/3 conversion exits. Fields such as customer numbers, vendor numbers, material numbers, cost center numbers, and numerous other types of master data numbers all use conversion exits. See Table 1 for a list of common fields and their associated conversion exits.

Why Does R/3 Use Conversion Exits?

Given the data selection problems shown in Figure 3, what is the benefit of a conversion exit? The main reason R/3 uses conversion exits is to ensure consistent sorting and storage of data across multiple databases and languages. You must keep in mind that a G/L account does not have to be just numbers; it can also be letters. In addition, the number of characters in a G/L account does not have to be consistent, i.e., it is possible to have a chart of accounts with both six- and eight-character G/L accounts. See Table 2 for a comparison of how data is stored internally and externally.

Looking at Tables 3 and 4, you can see that sorting the G/L account numbers by the internal format results in a sort order that is more consistent with end-user expectations than sorting by the external format.

Viewing Internal Format

Given that most of the time you will see data in the external format designed for end users, how can you view the data in R/3's internal format? The best tool for doing this is transaction SE16, which has an option to turn off the conversion exit for data display. To change your user settings to turn off the conversion exit check, select Settings>User parameters from the menu, then turn off the Check conversion exits check box in the pop-up window (Figure 5). Figure 6 shows externally formatted data, and Figure 7 shows internally formatted data, which is what your data should look like once your Check conversion exits setting is deactivated.

Figure 5

Disable the Check conversion exits setting in the user parameters pop-up of SE16

Figure 6

G/L account displayed with conversion exit active, external format

Figure 7

G/L account data displayed with no conversion exit, internal format

How to Find Data

In my first example, when a user enters the G/L account range 140000 to 149999 (Figure 1), R/3 uses conversion exit ALPHA to change the range to 0000140000 to 0000149999 and the correct data is found. When the user enters 14*, R/3's conversion exit ALPHA transforms 14* into a combination of numeric and non-numeric characters. Internally, no G/L accounts start with 14, so nothing is found. Once users recognize the difference between internal and external data formats, then they realize that they are in fact searching for the internal pattern 000014* (Figure 8).

Figure 8

RFSSLD00 selection with the correct G/L account pattern

However, the data searching problems can become more acute when looking at raw data using transactions SE16 or SE17. This is also true when you search for more complex patterns, e.g., accounts starting with 2 and ending with 5, which can be found with the pattern 00002++++5 (assuming a six-character G/L account number). To reduce the problems that conversion exits can create, end users must remain vigilant in their data search techniques.

What About Dates?

Strictly speaking, date fields do not use conversion exits, but their behavior is similar to a field with a conversion exit. The conversion from internal to external format is embedded in the data type DATS, so no separate conversion exit needs to be defined in the domain. The external presentation of the date and validation of user input is based on the user defaults selected in transaction SU3, which covers all commonly used date formats, e.g., DD.MM.YYYY, MM/DD/YYYY, and YYYY-MM-DD. The internal storage is in format YYYYMMDD, which ensures that all dates sort correctly regardless of the user input date format.