Globalization

Translation

Sales Audit supports operating the user interface in 19 languages, including English. As part of the install options for Merchandising, you'll designate one language as "primary". This primary language is used by Sales Audit as well and determines how labels and data are displayed by default to users, what is held in the base tables for data entities, and what is used in integration to other systems. The primary language is also what is loaded as a default for all screen labels, error messages, and seeded data at the time of installation. By default, only the primary language is loaded in Sales Audit, but if you wish to have more languages loaded, then you can request to have the language strings loaded for these languages as well.

In addition to English, the languages that can be supported in the user interface include:

Arabic
Chinese (simplified)
Chinese (traditional)
Croatian
Dutch
French
German
Greek
Hungarian
Italian
Japanese
Korean
Polish
Portuguese
Russian
Spanish
Swedish
Turkish

This means that all screen labels, error messages, and menu options are supported out of the box in these languages and users are able to select from these languages as their preferred language. Data translation is also supported to allow data that you create as part of your implementation, such as tender types, can be seen in the preferred languages of your users as well.

Translate Retailer Data

When creating data in Sales Audit, such as a new rule, total, tender type or error code, it is assumed that data is always entered initially in the primary language for the main entity. But, you can also enter translations for the data, as needed, by selecting the translation iconic button (). See the Oracle Retail Sales Audit Do the Basics User Guide section on translation for details on how to add translations for your data via the user interface. Additionally, for entities that are uploaded via spreadsheet, translations can be provided via the upload.

Translate Labels and Seeded Data

If you would like to modify the translations for labels, error messages, codes and descriptions, or other seeded data, or to add translations for other languages^Foot 1 that are not included in the list above, there are several methods provided. The method used will depend on the data that needs to be updated/added. Translatable text is held in two different ways for Sales Audit, resource bundles and database tables.

Resource Bundles

Screen labels and other UI related data that may require updates/additions for Sales Audit are managed in resource bundles. For details on how to make updates to resource bundles see the "Resource Bundles" section in the Oracle Retail Merchandising Customization and Extension Guide.

Database Tables

Many other labels and drop-downs that are not managed in resource bundles are managed in the Sales Audit Codes and Descriptions spreadsheet download/upload process in Merchandising for the code types describe in this document. You can use the method described for managing codes in the Merchandising Implementation Guide to update or add your translations in the designated tab in the spreadsheet.

Error messages and other foundational data entities are also managed via spreadsheet download and upload. For each of these entities, where applicable, translations can also be added in the spreadsheet in a separate tab, using the entity ID as a cross reference. The details on the translation for these entities is found with the information on managing these entities in either the user guides or in this document.

For the base strings in English for these tables, see My Oracle Support ID 1608569.1 and select the Sales Audit document (resa_translation_pairs.xls). These can be used as a basis for adding your own translations.

Configure User Language

Users can choose their preferred language to have the user interface displayed as part of setting up their user preferences, as described in the Sales Audit Do the Basics User Guide. As noted above, the values loaded in the base table of an entity are always maintained in the primary language. And as such all users, irrespective of their configured language, will see the primary language in the screens where an entity is created and maintained, and translations (including their preferred language) are shown in separate translation screens. However, if that same screen is accessed in view mode the description will be shown in their preferred language. Similarly, if viewing the entity in another UI - for example, viewing the error codes in the Transaction Maintenance screen - the description will be shown in their preferred language.

Not Translated

The following information is available in English only:

Documentation, including online help, release notes, and product guides
Batch programs and messages
Log files
Configuration tools
Demonstration data
Training materials

Currencies

Currencies and exchanges rates are managed in Merchandising, but used by Sales Audit. Not only is it used to validate currency information on transactions, but it also is used to determine the retail precision for the currency. This precision is used by Sales Audit when evaluating the data sent from the selling solutions and posting to the General Ledger. It is expected that the selling solution will always send retail values in terms of the precision defined for the currency, whether that is zero decimal places or more. If the precision is greater than what is expected for the currency, it will be flagged as an error in Sales Audit.

In some currencies, like the Australian Dollar where they have eliminated the use of pennies, there may be situations where a customer paying cash has their total rounded (e.g. 10.50 AUD), but if the customer was paying by credit card, they would pay the full precision amount (e.g. 10.53 AUD). To make up for this discrepancy between the actual value of the sale and what the customer pays, a special tender type, called Rounding Tender, part of the Cash tender group, is used.

Currency Rounding Rules

Although there are spreadsheet upload and download capabilities for this defining rounding rules in Sales Audit, this is related to older functionality that is no longer used in the solution.

Tax

Sales Audit supports both sales tax (e.g. the US tax model) and Value Added Tax (VAT), used by most other countries. In addition, Sales Audit supports managing taxes at the transaction level or the item level. This is usually determined by how your selling solutions will be sending you tax information. Sales Audit uses the tax type that is configured in Merchandising system options, either Sales or VAT to determine what type of tax information to expect in the RTLOG files.

Tax Levels

Taxes within Sales Audit can be supported at the transaction level or the item level. The level at which taxes are communicated from the selling systems and managed within Sales Audit is configurable by store. Taxes for a given store must be managed at either the transaction level or the item level, which is configured via the Store Data setup. The presence of an Item Level Tax import record for the store indicates that a store is using item level taxes, not transaction level. If this record is not present for a store, Sales Audit will expect transaction level taxes. This allows you to handle taxes in different ways for different store, which may be necessary if you have different POS solutions running in some stores or if POS and OMS differ in how they handle taxes. Refer to the "Store Data Configuration" section for more details on this setup.

Transaction Level Taxes

When a store is configured to managed taxes at the transaction level the total tax paid by the customer per tax code on a transaction will be managed at the transaction level and the selling solutions will communicate taxes via the RTLOG in the TTAX record type. For GL posting, the transaction level tax is prorated to the items on the transaction by Sales Audit.

Item Level Taxes

When more granular level management of taxes is required, taxes can be communicated and managed at the item level and the selling solutions will communicate taxes via the RTLOG in the IGTAX record type.