In this blog-post i want to mention some caveats when implementing SAP for new countries or regions. Primary focus is the ABAP developer perspective, the translation and not the customizing topics.
Regional Differences
Due to business and legal requirements SAP implementations often use different:
- G/L accounts
- Chart of accounts
- Cost centers
- Tax codes
- Currency codes
- Organization structures (sales organization, purchase org., plants, company codes etc.)
for different countries and regions.
So one of the first tasks is to search for hard coded G/L accounts, chart of accounts, cost centers, tax codes, currency codes, sales organizations, purchase organizations, plants and company codes in custom ABAP programs and replace the findings by appropriate variables or customizing tables.
Currency Codes
Replacing hard coded currency codes should be pretty simple. Most transactional data tables have both fields (amount beside and currency code) and the currency code is part of the company settings in table T001, too. So instead of hardcoding the currency code it`s better to read the currency code from the transactional data table where applicable or from the T001-table. If hard coded currency codes are used to decide whether a currency conversion must be performed the decision can be simply omitted as the currency conversion between the same currency leads to the same result.
Calculations done with currency values
Special care must be taken in custom programs, which calculate differences or ratios between two currency values. If the program simply subtract or divides those two values, you will get wrong results when the first value has a different currency than the other. In one of my projects we had this issue, because the programs were built at the time, where SAP was implemented for only one country and all values were in the same currency.
Translation
Translation API
Translating all objects with transaction SE63 is quite impractical as you need to go through every single object. Under the hood the transaction SE63 uses a API, which can be used to build your own more practical translation program. This API (translation API) consists of the following parts:
- the table LXE_ATTOB, which contains the types of translation objects
- the function module LXE_OBJ_OBJECTS_GET, which reads the translation objects for a given object type and collection. In case of ABAP development objects the collection is the package.
- the function module LXE_OBJ_TEXT_PAIR_READ to read the text pairs
- the function module LXE_OBJ_TEXT_PAIR_WRITE to write the text pairs
- the function module LXE_OBJ_CREATE_TRANSPORT_ENTRY to append the translation object to a workbench request
The GitHub repository https://github.com/SAP-Easy-Translation/abap_client is a example, how the translation API could be used to select the text pairs from a range of packages and edit or review these text pairs in a more practical way.
Other language dependent texts
The translation needs to cover all language dependent texts. Beside the obvious ABAP development objects (Dictionary-Objects, Text-Elements in programs and classes, T100-Messages, Forms etc.) there are a few more language dependent texts:
- Descriptions for customizing objects (custom sales documents types, Sales order reasons, Delivery note types, Invoice types, Conditions, Purchase Order Types, Material groups etc.)
- Report variant descriptions
- Queries build with transaction SQ01
- SapScript Standard Texts maintained in transaction SO10
You shouldn’t forget to translate these objects, too.
Customizing objects
The descriptions of the customizing objects can be edited directly in the maintenance views or by selecting the object types TADC, TADE, TADG, TADS, TADW, TAIC, TAIE, TAIG, TAIS and TAIW in the translation transaction SE63.
Report variant descriptions
Report variant descriptions can be found under the object types VARI (system variants) and VARX (local report variants).
Queries
Queries can be translated in the transaction SQ02 by going to the menu Environment -> Language comparison.
and by entering the Query and the user group or the InfoSet in the next screen.
Both query and InfoSet should be translated and after the translation you should regenerate the Query program (Transaction SQ01 -> Menu -> Query -> More functions -> Generate program).
SapScript Standard Texts
SapScript Standard Texts are translated in transaction SO10. Enter Text name, Text ID and the target language and press the “Create”-Button or “Change”-Button to translate the text.
SapScript Standard Texts are not automatically added to a workbench request. The program RSTXTRAN must be called to achieve this.
Form Printing
When you print SapScript forms or SmartForms, make sure to activate UPE (Unicode Printing Enhancement) as described in note 1812076. Otherwise you will get hashmarks (#) for characters, which are not included in the character set of the printer.
Conclusion
This blog post should show you some of the caveats when implementing SAP for new countries or regions. However there some more cultural differences between regions. Some asian countries like Thailand have two different calendars (buddhist calendar and gregorian calendar) and in some countries like Japan the fiscal year is different from the calendar year. These differences should be keept in mind when dealing with issues or when adapting custom ABAP code for new countries or regions.
