Oracle E-Business Suite Release 12 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 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 Oracle E-Business Suite products provided 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.
Note: 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 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.
Note: 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, 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 11-30-09, 30/11/09, or 2009-11-30. The only exception is with Oracle Reports, which always uses the format DD-MON-RRRR, for example 30-NOV-2009.
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.
Note: For details of setting up Oracle E-Business Suite to use multiple time zones, see Oracle E-Business Suite System Administrator's Guide - Configuration. Also see My Oracle Support Knowledge Document 402650.1, User Preferred Time Zone Support in Oracle E-Business Suite Release 12.
The Reporting Currencies feature, described in more detail in Chapter 15, 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.
A secondary ledger is 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: chart of accounts, accounting calendar/period type combination, currency, or subledger accounting method.
A reporting currency is a currency, other than your ledger currency, for which you need to report. The reporting currency shares the same chart of accounts and accounting calendar as the source ledger (either the primary ledger or secondary ledger), but typically uses a different currency. The reporting currency allows you to report in a different currency than that of your primary or secondary ledger.
Each ledger is defined with a ledger currency that is the primary record-keeping currency to record your business transactions and accounting data within subledgers and General Ledger. In the primary ledger, the ledger currency is always the primary ledger currency. Usually, the primary ledger currency is the currency in which you perform most of your business transactions, and the one you use for legal reporting.
You must define a separate reporting currency for each additional currency representation you need. You assign reporting currencies to primary and/or secondary ledgers using General Ledger’s Accounting Setup Manager.
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, 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 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.
Note: See Oracle E-Business Suite System Administrator's Guide - Configuration for a list of external documents provided in Release 12.