Oracle E-Business Suite Release 12.2 is designed for ease of deployment in a single global instance that meets the complex requirements of a worldwide enterprise. Globalization is the process of designing and deploying software that supports a global enterprise. Key globalization features provided by Release 12.2 include support for a wide variety of languages and territories, flexible date and number formats to suit local custom, reporting currencies, and other country-specific functionality to provide compliance with local statutory requirements.
The majority of Release 12.2 Oracle E-Business Suite products provide multilingual support at the product data level, utilizing the Unicode character set. As Unicode supports all characters in common use in all of the world's modern languages, this means there is no inherent limitation on the number of supported languages that can be run in a single database.
Additional Information: To learn more about about character sets, see Oracle Database Globalization Support Guide. For more detailed information about globalization, see My Oracle Support Knowledge Document 393861.1, Globalization Guide for Oracle Applications Release 12.
National Language Support (NLS) refers to the ability to run an Oracle E-Business Suite instance in a supported language, including specific regional number and date formats.
Multiple Language Support (MLS) refers to the ability to support multiple languages in the same Oracle E-Business Suite instance. Most products in Oracle E-Business Suite Release 12.2 are MLS-enabled. Using a Unicode character set with the MLS architecture allows Oracle E-Business Suite to use any combination of supported languages from one database instance. Because it covers the widest range of characters, a Unicode character set such as AL32UTF8 is recommended as the character set for installations that support, or plan to support, multiple languages. Oracle supports over thirty languages in Release 12, which are installed via NLS patches.
Additional Information: For a full list of supported languages, see Oracle E-Business Suite Installation Guide: Using Rapid Install.
By default, Rapid Install creates a production database with the US7ASCII character set, and a Vision demo database with a Unicode character set such as AL32UTF8. However, you can if desired choose any other supported character set during the installation. Rapid Install recommends a character set based on the languages you license.
Before installing Oracle E-Business Suite, you should carefully consider the future language requirements of your installation. The character set you choose during installation determines which languages the instance can support. Review the Oracle Globalization Support Guide before choosing a character set. Changing character sets after installation is an involved process, and can be avoided by choosing a character set that will meet your long-term needs.
The US7ASCII character set only supports American English. All other character sets vary in the number of languages they support. For example, if you need to support the French language and also want to use the euro symbol, WE8ISO8859P15 is a superset of US7ASCII, supports both English and French, and contains the euro symbol. If, for example, you need to support English, French, Japanese, and Arabic, you must choose a Unicode character set (such as AL32UTF8) to be able to support all these languages.
The extended multilingual support present in the Oracle E-Business Suite Release 12 data model may increase database storage requirements. For a new installation, consider the database space required for a single language, and multiply this by the number of languages you will license. In the case of an upgrade, some of the data currently in a single language structure will be converted to a multilingual structure, which will require additional storage.
Note: For further details of installing character sets, see Oracle E-Business Suite Installation Guide: Using Rapid Install.
Using a multibyte character set such as Unicode AL32UTF8 or Japanese JA16EUC (as opposed to a single-byte character set such as WE8ISO8859P15) may also affect the overall space required for language setup and transaction data, because some characters used may require more than one byte of storage space.
Note: For further details of supported character sets, tips on choosing a database character set, and storage requirements, see My Oracle Support Knowledge Document 393861.1, Globalization Guide for Oracle Applications Release 12.
By default, Rapid Install creates the application tier file system for a production instance with the US7ASCII character set, and the file system for a Vision demo instance with the AL32UTF8 character set. However, you can if desired choose any other supported character set during the installation. Rapid Install recommends the application tier character set based on the languages licensed.
To prevent data loss, character sets on all tiers must be compatible with each other. If one character set does not contain all characters in the other, replacement characters will be used and data lost as a result.
Note: As AL32UTF8 is a superset of all other supported character sets, there are no other fully compatible character sets. If you use AL32UTF8 on the database tier, you must use AL32UTF8 on all other tiers.
Rapid Install installs American English on all servers in the application tier. Additional languages may also need be installed, so that all application tier servers have the same set of languages installed.
Language support, which includes support for data input methods, character sets, and fonts, must be available on the desktop client. The character set of the browser is set by Oracle E-Business Suite for each session.
The desktop browser must support character set and language-specific capabilities. For instance, Hebrew and Arabic require bidirectional support for right-to-left display, and Arabic also requires a browser capable of special character shaping.
In Release 12.2, user runtime NLS settings are stored as profile options in the database. The profile options for language and territory are configured at site level when running Rapid Install. The base language is used for the default language setting. The default user territory you choose is used for the territory profile option.
The site level profile option values provide the default NLS settings for all end users. Users inherit these values the first time they log on to Oracle E-Business Suite using the Oracle E-Business Suite home page. A user can continue to use the default values, or change any of the NLS settings to alternative values. The updated values are stored in the database at user level, and all future sessions are started with them.
A user's NLS preferences (such as language, territory, date format, and number format) are passed with each user request to the application tier servers, where a session is started with the corresponding NLS settings. Application tier processes must be started with the character set of the server, as determined when Rapid Install was run.
You can enter and view dates in any valid format, such as 10-20-11, 20/10/11, or 2011-10-20. The only exception is with Oracle Reports, which always uses the format DD-MON-RRRR, for example 20-OCT-2011.
You can also enter and view numbers with either the period (full stop) character or comma as the decimal separator. For example, 1.02 or 100,000.02 (using the period), or alternatively 1,02 or 100.000,02 (using the comma).
Note: For further details of date and number formats, see My Oracle Support Knowledge Document 393861.1, Globalization Guide for Oracle Applications Release 12.
Regardless of the various formats that may be used to enter dates and numbers, the actual values are stored in the database in uniform canonical formats. This allows date and number values to be entered in one format, and viewed in an alternative format by another user.
This section describes the key criteria involved in designing and implementing applications that will be used in multiple countries, perhaps all over the world.
Release 12 of Oracle E-Business Suite includes as standard a feature called User-Preferred Time Zone Support. In most existing E-Business Suite implementations, all users interact with the system in the "corporate" time zone, which will normally be the time zone of the headquarters of the implementing company, and the time zone in which the database runs. This means that remote users have to be aware of the time difference between their location and that of the corporate headquarters.
Employing the user-preferred time zone feature enables users to specify their local time zone for both display and entry of date-with-time fields. Key consequences of this are:
Users see date-with-time fields in their preferred (local) time zone, and can enter dates with time in this time zone
Date fields without a time component are not affected by this feature
The data in the database continues to be stored in the standard corporate time zone
Conceptually, there are two types of date fields:
Dates with a time component – used to indicate a specific point in time within a particular day
Dates without a time component – used to denote a particular day, but not a specific point in time within that day
Date fields with a time component can be represented in any time zone, and thus displayed in whichever time zone is most meaningful to the end user. Generally, users prefer to view dates in their own (local) time zone. With the user-preferred time zone feature enabled, date with time fields will be converted to the user's preferred time zone for display.
Date fields without a time component cannot be represented in different time zones, because no meaningful conversion is possible for a date that does not include a specific time. Such a date is entered with respect to one time zone, and in general must be viewed as a day in that time zone, regardless of the location (and possibly different time zone) in which it is being viewed. Oracle E-Business Suite typically uses the corporate time zone for these day definitions: dates without a time component represent the day with respect to the corporate headquarters (corporate days).
There are some exceptions to the above rule. For example, dates without a time component may be held as ANSI dates, to represent dates independently of the time zone in which they are being viewed. In such a case, a benefit that starts on 1st January will start on that date wherever in the world it is made available; that is, it will apply to anyone who is in a time zone where it is 1st January.
Many dates without a time component represent pointers to a financial period. These dates are not meant to indicate the exact hour and minute that a transaction occurred, but rather the financial period into which the transaction is accounted. This is a financial bucketing from the perspective of the implementing company. For example, the invoice dates on Payables or Receivables invoices never change based on who is looking at them: they are classified as invoices for that day (and thus that period), regardless of the viewer's local time zone.
Additional Information: For details of setting up Oracle E-Business Suite to use multiple time zones, see Oracle E-Business Suite Setup Guide. Also see My Oracle Support Knowledge Documents 402650.1, User Preferred Time Zone Support in Oracle E-Business Suite Release 12, and 563019.1, Complying with Daylight Saving Time (DST) and Time Zone Rule Changes in E-Business Suite 12.
The Reporting Currencies feature allows you to report on and maintain accounting records in more than one functional currency. This can be done at the subledger journal level, General Ledger journal level, or balance level. You define one or more reporting currencies, and assigning them to a primary ledger or secondary ledger using General Ledger's Accounting Setup Manager.
The following terms are fundamental to the principles described in this section.
| Primary Ledger | A financial reporting entity in which you conduct business. The primary ledger acts as the main, record-keeping ledger and uses a particular chart of accounts, accounting calendar, currency, and subledger accounting method. |
| Secondary Ledger | An optional, additional ledger that is associated with the primary ledger for an accounting setup. Secondary ledgers can be used to represent the primary ledger's accounting data in another accounting representation that differs in one or more of the following from the primary ledger:
|
| Ledger Currency | The currency used to define a ledger, which is also the base currency used to record your business transactions and accounting data within the General Ledger module of Oracle E-Business Suite. The primary ledger currency is generally the currency in which you perform most of your business transactions, and the one you use for legal reporting. |
| Reporting Currency | The currency used for an organization's financial statements. Shares the same chart of accounts and accounting calendar as the source ledger (either the primary ledger or secondary ledger), but need not be the same currency as that of the primary or secondary ledger. |
| Functional Currency | The main currency used by a organization. The functional currency can be different from the ledger currency that is assigned to the primary and secondary ledgers. For example, you may choose Japanese Yen (JPY) for your ledger currency, even though the functional currency for the accounting purposes of your integrated business group is actually US Dollars (USD). The determination of the functional currency is based on a number of factors, discussed in SFAS #52 and IAS 21. |
You must define a separate reporting currency for each additional currency representation you need. You assign one or more reporting currencies to your primary ledger or secondary ledger using General Ledger's Accounting Setup Manager.
Unlike secondary ledgers, reporting currencies must share the same chart of accounts, accounting calendar/period type combination, subledger accounting method, and ledger processing options as their source ledger.
As a general rule, always use reporting currencies instead of secondary ledgers if you only need to maintain an accounting representation that differs in currency alone. You can assign reporting currencies to both primary and secondary ledgers. Reporting currencies are maintained at one of the following currency conversion levels:
Subledger: Maintains a currency representation of your subledger journals, General Ledger journal entries, and balances. When using the subledger level reporting currency, you must define subledger accounting rules using Subledger Accounting. These rules provide instructions on how to convert subledger data entered into the source ledger to one or more subledger level reporting currencies. You must also define journal conversion rules that General Ledger Posting uses to automatically convert specific journals, such as manual journal entries, to one or more subledger level reporting currencies.
Note: Subledger level reporting currencies can only be assigned to primary ledgers, not secondary ledgers.
Journal: Maintains General Ledger journal entries and balances in another currency representation. Journal level reporting currencies are maintained using the General Ledger Posting Program. Every time a journal is posted in the source ledger, such as the primary ledger or secondary ledger, the journal is automatically converted to the respective journal level reporting currency based on the journal conversion rules defined.
Balance: Maintains balances in another currency. The General Ledger Translation program is used to convert balances from the source ledger to the balance level reporting currency. When you run Translation in your primary or secondary ledger and specify a target currency, the translated balances are reflected in the balance level reporting currency.
Note: If a balance level reporting currency is not assigned to the ledgers in the accounting setup, a balance level reporting currency is automatically created the first time Translation is run. The name of the balance-level reporting currency is the same as its source ledger, except that its currency code, such as GBP, is appended to its name.
The subledger level and journal level reporting currencies act similarly to ledgers. You must open and close the periods for these reporting currencies before you can enter transaction and journal entries. You can also enable journal approval for these reporting currencies if planning to enter manual journal entries directly to these reporting currencies.
Note: For further details about reporting currencies, see Journal or Subledger Level Reporting Currencies in Oracle General Ledger User's Guide, and Reporting Currencies inOracle Financials Implementation Guide..
For further details about secondary ledgers, see Secondary Ledgers in Oracle Financials Implementation Guide.
One requirement for successful globalization is to meet the statutory, legal, and cultural practices of a given locality. In Oracle E-Business Suite Release 12.2, this is achieved is through national and regional extensions called country-specific functionalities. Because country-specific functionalities are all compatible with each other, installation of all required country-specific functionalities results in a globalized implementation.
All country-specific functionalities are installed when you run the Rapid Install. You simply need to license those you wish to use. The functionality of each country-specific functionality is described in a special User's Guide for each country.
External documents are those documents intended for customers and trading partners, such as bills of lading, commercial invoices, and packing slips. Oracle E-Business Suite Release 12.2 is capable of producing external documents in any of the active languages, simultaneously and with a single request. A company's customer in Italy, for example, could receive invoices printed in Italian, and a customer in Poland could receive invoices printed in Polish.
You can send external documents to different printers based on language, and route completion notifications to different people according to the requested language. For example, you could route all French documents to one printer, and all other documents to another printer. You could send completion notifications for Spanish documents to one user, and all notifications, including Spanish, to another.
Additional Information: See Oracle E-Business Suite Setup Guide for a list of external documents provided in Release 12.2.