This chapter covers the following topics:
This chapter describes how to implement Oracle iStore in a global instance.
A global implementation of your Oracle Applications enables you to do business in multiple countries, languages, and currencies. Leveraging Oracle Multiple Organization Architecture ("multi-org"), a global implementation allows you to:
Create multiple sets of books, each with its own unique calendar, chart of accounts, and functional currency. Each set of books then can be tied to a sub-organization of your master organization, and to separate legal entities.
Sell Inventory from one legal entity (which uses one set of books) and ship them from another legal entity (using a different set of books). Oracle Receivables can automatically record the appropriate intercompany sales by posting intercompany accounts payable and accounts receivable invoices.
Reuse database tables, meaning one-time data entry.
Ability to segregate transactions by operating unit -- since each organization is uniquely linked to an operating unit -- yet still share certain information (such as customers) between organizations.
Support multiple currencies (including the Euro) and several languages.
For Oracle Applications multi-org information, see Multiple Organizations in Oracle Applications.
Oracle iStore is fully equipped to support a global deployment by offering --- in addition to the multi-org architecture benefits discussed above --- several features and benefits that can enable you to present a world-wide web presence. Some of these features and benefits include:
After assigning responsibilities to an operating unit, the ability to limit user purchases to one operating unit's set of books.
Online specialty sites in multiple languages and currencies.
Ability to offer translated product data and site prompts.
Support for regional payment type availability.
Restriction of bill-to and ship-to countries for each operating unit.
Localization of product catalogs and inventory.
Support for regional tax requirements, payment types, and shipping methods.
The following are the steps to successfully implement globalized specialty sites using Oracle iStore:
Step 1 - Implement Oracle Multiple Organization Architecture
Step 2 - Install Languages and Currencies
Step 3 - Set up Oracle iStore Customer Application Responsibilities
Step 4 - Create Global Sites
Step 5 - Translate Product Descriptions
Step 6 - Enable Global Currencies and Price Lists
Step 7 - Set up Global Customer Application
Step 8 - Use Global Address Formats
Step 9 - Ensure Display of Localized Quantities
A global implementation of Oracle iStore requires that iStore's mandatory dependencies be implemented using Oracle Multiple Organization Architecture. Oracle iStore relies on the schema supplied by these applications for much of its back-office global functionality.
For Oracle Applications multi-org information, see Multiple Organizations in Oracle Applications.
You can set up multiple sites (all within a single instance), each deploying a different currency and language. Oracle iStore supports all of the currencies that the Oracle E-Business Suite supports, including the Euro. Through its integration with Oracle Applications, each specialty site also can display appropriate currency symbols.
Languages and currencies are enabled in the Oracle Application Object Library (AOL) module during setup. After initially enabling languages in AOL, you set them up in Oracle General Ledger.
A web customer's preference, as defined in his Oracle iStore user profile, determines which currency and language is used for a specialty site, unless a customer explicitly selects a specialty site in a particular language. The preferred language is stored in the HZ_PERSON_LANGUAGE table. Initially, the language is the one defaulted during registration from the user's session language.
To install multiple languages and currencies see: Oracle E-Business Suite Multiple Organizations Implementation Guide.
To enable the currencies that your sites will support, see: Oracle General Ledger User Guide
Each site supports multiple responsibilities, and each iteration of a site and a responsibility make a specialty site accessible in the Customer UI. It is recommended that you set up your sites to each support a single responsibility (and thus a single specialty site). This single specialty site then can be rendered in different languages and currencies.
When a user's registration is approved, he is granted at least one responsibility. A match between a customer's responsibility and the responsibility supported by a site allows the customer to see the specialty site. Oracle iStore seeds a default responsibility, IBE_CUSTOMER, for use with your sites.
The operating unit (OU) tied to the responsibility a customer is using when he places an order determines the OU in which the order is recorded. In a multiple-OU scenario, you would create a separate IBE customer responsibility to link to different OUs. The OU associated with a customer when he places an order is determined by the settings of two multi-org profile options, as discussed in the following use cases.
Use Case 1: Multi-Org Implemented; MO: Security Profile Set to Single OU
MO: Security Profile is set to a single OU at Oracle iStore customer responsibility level. Sites using this customer responsibility are associated to the specified OU, and all the transactions are placed in this OU. In this case, the profile, MO: Operating Unit, should be set to the same OU as in the security profile.
Use Case 2: Multi-Org Implemented; MO: Security Profile Set to Multiple OUs
MO: Security Profile is set to multiple OUs, either through security profile hierarchy or to a list of valid OUs defined in Oracle Human Resources. Oracle iStore will retrieve the OU associated to the site/responsibility based on the value defined in the profile option, MO: Operating Unit. This profile option is required and should be set to a single OU. The OU associated to the Oracle iStore customer responsibility through MO: Operating Unit should be one of the OUs in the list of operating units associated to MO: Security Profile. Note that the Security Profile should list all the OUs that are used in iStore as well as those in used in Oracle Order Management/OrderCapture products; this is required in order for the iStore end user to be able to cancel orders.
Use Case 3: Multi-Org Not Implemented
MO: Security Profile is not set. MO: Operating Unit is set to one OU for each Oracle iStore Customer UI responsibility. Oracle iStore will retrieve the OU associated to the site/responsibility based on the value defined for this profile option.
Oracle iSupport and Oracle Partner Management applications should follow the same logic when using the iStore framework to create their sites.
When a customer enters a specialty site, Oracle iStore notes the customer's responsibility and the OU to which it is assigned, then restricts the customer to the items in the Inventory Organization that is associated with the OU. Oracle iStore accomplishes this by retrieving the Inventory Organization ID for the current user responsibility's OU from the OE_SYSTEM_PARAMETERS_ALL table. Use Oracle Order Management to associate Inventory Organization IDs with OUs.
Note: In all cases, the profile option, MO: Operating Unit, must be set.
Following is a sample responsibilities setup for a multi-org implementation:
Create a separate responsibility for each operating unit. You can use the seeded responsibility, IBE_CUSTOMER, as one of these responsibilities. Each operating unit must be tied uniquely to a single responsibility.
Example: Create IBE_CUSTOMER_G for your German operating unit, and use IBE_CUSTOMER for your U.S. operating unit.
Link each responsibility to an operating unit by setting the multi-org profile options discussed in the above section.
The iStore - Express Checkout Order Submission concurrent program, which converts the Express Checkout shopping carts into orders, is marked as single-organization concurrent program. In a multi-org environment, when you run the concurrent program, the system will prompt you to select a single organization from a list of accessible organizations. Choose one of the organizations from the list and run the concurrent program. The system will submit all Express Checkout shopping carts that belong to the selected organization as orders.
Using the Oracle iStore Site Administration UI, create a new site for each responsibility, and link each site with its responsibility. See the chapter, Implementing Site Management, for more information.
See the section, "Translating Product Descriptions", in the chapter, Implementing Products, for details.
Oracle iStore supports all of the currencies supported across the Oracle E-Business Suite, including the Euro, and supports multiple-currency price lists. See the chapter, Implementing Pricing, for more information.
All of the pages in Oracle iStore's Customer Application are made up of Display Templates mapped to specific JSP files. Within each template your implementation can support various content (.htm files, images) through the use of content components and media objects. In addition, hundreds of seeded text messages display in the UI. For a list of seeded Display Templates, bins, and media objects see the chapter, Seeded Display. You can find a partial list of seeded text messages in the chapter, Implementing Messages and Prompts.
In a multiple-language implementation, you must set up JSP files in the other (non-base) languages and then map the JSPs to the programmatic access names of each Display Template. See the chapter, Implementing the Catalog, for additional information.
For content, similarly, you must provide content for the other languages and map them to the content components or media objects. See the chapter, Implementing Content, for additional information.
All seeded specialty site text messages, such as prompts and labels, are stored in Oracle Applications Message Dictionary. If a global site continues to use the seeded text for messages and prompts, these the seeded text will automatically be translated when the additional languages are installed. However, if alternate messages text is created, then the merchant will need to manually translate the content. See the chapter, Implementing Messages and Prompts, for more information.
Set the following Oracle Quoting parameters: Default Salesrep, Default Contract Template ID, and Default Order Type. For more information, see the "Oracle Quoting Integration Parameters" topic in the appendix, Profile Options.
Through its integration with Oracle E-Business Tax, Oracle iStore can provide address entry formats specific to particular countries. This allows the application to dynamically provide Address Book data entry formats based on the country selected by the user.
For more information on setting up and using Oracle E-Business Tax, see the Oracle E-Business Tax Implementation Guide and the Oracle E-Business Tax User Guide.
Oracle iStore supports displaying the different quantity formats used by various languages around the world. Some languages, for example, show the quantity "one thousand" as 1,000, while others show this same quantity as 1.000. As of Release 11.5.10, Oracle iStore supports localized quantity formats, using the language of a specialty site to automatically derive the localization convention. No setup is required for quantity localization. However, merchants using Oracle iStore Release 11.5.10 with customized, pre-Release 11.5.10 Customer UI pages may experience localized quantity display issues.
This issue affects only those implementing Release 11.5.10 who are continuing to use the pre-existing (pre-R11.5.10) customized JSP pages/templates shown below.
The localized quantity support changes in Oracle iStore R11.5.10 code will cause unexpected behavior when the user interacts with the following pages:
Modify shopping cart process page.
Template name --- STORE_CART_MODIFY_P
JSP name --- ibeCScpViewA.jsp
Display model item lines page
Template name --- STORE_CART_MDL_ITEM_LINES
JSP name --- ibeCScdMdlItemLines.jsp
Modify line level shipping details process page
Template name --- STORE_CART_LINE_SPLIT_DETAILS_P
JSP name --- ibeCCkpLineSplit.jsp
Add bundle, add education, or add bundle with education page
Template name --- STORE_CART_BUNDL_EDUC_P
JSP name --- ibeCScpBundEduc.jsp
Add to Cart JSP --- This one is not a template, but a JSP file only. It is included by other JSPs and is not expected to be customized.
JSP name --- ibeCScpAddToCart.jsp
Remember that these pages are used in many flows for shopping carts, and hence a customer may encounter problems in many flows if these pages are not adjusted.
Following are examples of how the quantity localization issue may show up in the Customer UI:
If the user enters 1,5 as quantity in a German-language specialty site, some of the JSPs above will show an invalid quantity error message to the user.
If the user enters 1500.00 as quantity in a German-language specialty site, it will be interpreted as 150000, which may not be what the customer was expecting to see --- he may have been expecting the display in English notation.
Note that this localization issue does not affect the display of prices in the Customer UI.
To address this issue, Oracle iStore implementers can modify the JSP files listed above to include a call to consider the specialty site language before displaying quantities. The class, oracle.apps.ibe.util.NumFormat, which supports parsing and formatting numbers given any language. In essence, the JSPs listed above must be altered to use the NumFormat class to parse and format quantities.
In validating quantities in the above JSPs, Oracle iStore validates quantity using this logic:
Convert quantity entered by user to BigDecimal.
Check if the quantity is a valid number in the situation (e.g., it must be greater than zero, etc.).
For step 1, the code would typically be in the form:
BigDecimal quantity = new BigDecimal(request.getParameter("..."));
This should now be changed to:
NumFormat format = new NumFormat(RequestCtx.getLanguageCode());
BigDecimal quantity = format.parseNumber(request.getParameter("..."));