Implementing Carts and Orders

This chapter covers the following topics:

Overview of Implementing Carts and Orders Chapter

This chapter contains information on implementing and configuring Oracle iStore shopping carts and lists, order placement, order tracking, returns, and customer contact information functionality.

Shopping Carts

Oracle iStore Customer Application shopping carts enable customers to store products for purchase and then ultimately to purchase the items using the carts. The ability to create and save shopping carts is automatically enabled in your specialty sites. Several other cart features are controlled by profile options whose setups are discussed in this chapter.

Shopping Carts Overview

For both B2B and B2C users, Oracle iStore shopping carts are characterized by the following:

Types of Shopping Carts

In Oracle iStore, shopping carts are categorized as follows:

Shopping Cart Menu

The Cart menu in the Customer Application allows users to manage their shopping carts. Users select the Cart icon in the Customer Application screen to access this menu. The following subtabs are available within the Cart menu:

Note that the user interface of the above pages is designed with an Actions drop-list which allows users quick access to a variety of allowable actions. See the "Common Shopping Cart Elements" section, below, for more information about the actions.

Active/Saved Carts Process Flow

The following is a high-level process flow for active and saved shopping carts in Oracle iStore's Customer Application pages.

Note: Carts must be active to be modified by the user. To add an item to an active cart, the user can be a guest or a signed-in user. The user will be required to sign in when he attempts to save the cart.

  1. A user enters a specialty site and adds one or more items to the shopping cart by selecting the Add to Cart button. When the user selects the Add to Cart button, if the user already has an active cart (whether an unsaved cart or a saved cart), Oracle iStore will add the items to the existing active cart.

  2. The active cart appears within the Shopping Cart subtab in the Cart menu, with the page title, Shopping Cart.

    • Special scenario with logged-out user having an active shared cart/quote: If a logged-out user has a shared cart or quote as his active cart --- and then signs-in and presses Add to Cart --- Oracle iStore places the shared cart/shared quote into a de-active, saved state, and at the same time, adds the items to the active cart, making the guest cart the active cart. This scenario can occur if the user had been logged in, was viewing the active shared cart/shared quote, and then logged out. The user can retrieve the de-activated cart in the Carts or Quotes pages.

  3. The user can select the Save Cart action and press Go in the Shopping Cart page to save the active cart. This de-activates the cart. The user can then create a new active cart and access the saved cart at a later time.

    In addition, please note the following:

    • The user can verify that the cart has been saved by viewing the cart name at the top of the cart.

      • A shopping cart can be saved at any time, until the order is placed with the cart. After order placement, the cart will no longer be available to the user, whether he has saved it or not.

      • The user does not need to save the cart to place an order with it.

    • If the user attempts to save the cart and the cart does not yet have a user-defined name (it may already have a system-saved name), after selecting the option to save the cart, the user is given the following choices in the Save Cart page:

      1. Create a new saved cart --- To create a new cart, the user selects the Cart Name radio button. The user must then enter a name for the cart. The name does not have to be unique.

      2. Add items to an existing cart --- This option is only available if the user has at least one saved cart. To add items to an existing cart, the user selects the Add to Existing Cart radio button and selects an existing saved cart from the existing carts drop-list. If this option is chosen, all items added to the cart inherit cart-level information of the target cart.

  4. If the cart already has been saved/named by the user, then the cart is simply re-saved when the user saves the cart. Performing an action that saves a cart de-activates the cart, and a new, active cart becomes available.

  5. To complete the save process, the user selects the Apply button, and a confirmation message is displayed.

    The expiration date for the cart is set to the value determined by the cart expiration profile value. The expiration date can be seen by the user in the Carts and Shopping Cart pages. See the "Shopping Cart Expiration Values" section, within this chapter, for more information.

    The user can access the saved cart at any time. See the "Accessing Saved Carts" section. The user must log in to access a saved cart.

The following diagram shows the active/saved cart process.

Active/Saved Cart Process Flow

the picture is described in the document text

Note that the above flow does not cover the quote updates. See the "Update Quote Process Flow" in the chapter, Customer Application Process Flows, for this flow.

Common Shopping Cart Elements

Following are common shopping cart elements and related behavior:

Accessing Cart Lists in the Carts Page

To view a list of saved or shared carts, both B2B and B2C registered users select the Cart icon in the Customer UI, and then select the Carts subtab. In the Carts page, carts are organized by type, with the most recently created cart appearing first in its section. Shopping cart expiration dates also display. Cart names are hyperlinks which lead to the details page for the cart. Alternatively, customers can select several actions from a drop-list and then press Go to perform the action.

See also: "Working with the Active Cart" section, within this chapter

The main sections on the Carts page are:

Additional Carts Page Behavior

Following are some additional points regarding Carts page behavior.

The following figure shows a typical Carts page for B2B users.

Carts Page - B2B Users

the picture is described in the document text

The following figure shows a typical Carts page for B2C customers.

Carts Page - B2C Users

the picture is described in the document text

For more information, see the following sections within this chapter:

Accessing Saved Carts

From the Carts page, customers select a saved cart name hyperlink to retrieve the Saved Cart Details page. This page shows all items in the cart, as well as item prices, sold-to customer information, and shipping/billing information. Note that users without the IBE_VIEW_NET_PRICE permission will not see discount and net prices.

Saved Cart Details Page Activities

From the Saved Cart Details page, the user can perform the following actions:

See the "Common Shopping Cart Elements" section, above, for more information about these actions.

Accessing Saved Quotes

From the Quotes page, customers select a saved quote name hyperlink to retrieve the Saved Quotes Details page. This page shows all items in the quotes/cart, as well as item prices, sold-to customer information, and shipping/billing information.

Important: This functionality requires integration with Oracle Quoting. Refer to the chapter, Integrating Oracle iStore with Oracle Quoting, for more information.

Saved Quote Details Page Activities

From the Saved Quote Details page, the user can perform the following actions:

Note: Updating quotes is only allowed when the profile option, IBE: Allow Update for Draft Quotes, is Yes.

See the "Common Shopping Cart Elements" section, above, for more information about these actions.

Working with the Active Cart

The active cart is the cart currently being updated by the user. It always appears under the Shopping Cart subtab within the Cart menu, and has the page title, Shopping Cart. Only one cart can be active for a user at a time. To activate a saved or shared cart, the user must either update the cart or start the checkout process.

The shopping cart displays the following columns with item information: part number, item name, UOM, quantity and price (net total price). The total price hyperlink launches a pop-up window that displays list price, net price, and all discounts and price adjustments for that unit and the total quantities of the item.

Active Cart Activities

In the active cart, the user can perform the following actions:

Note: When an active cart contains no items, the user will only have the following actions available: Continue Shopping, Save Cart, Share Cart (if implemented), Delete Cart, and Direct Item Entry (B2B only).

See the "Common Shopping Cart Elements" section, above, for more information about these actions.

Identification of Active Carts for Users

The following behavior exists with active carts and user identification:

System-Saved and Default-Named Shopping Carts

When a new cart is created by the system --- for example, when a user adds an item to a cart for the first time --- it is given a default name, which can be defined by the merchant. When this default-named cart gets saved while activating another cart, it becomes a system-saved cart and is given the system-saved name, as set up by the merchant.

Example:

  1. A user with no active cart selects the Add to Cart button. A cart is immediately created for the user, which is now the user's active cart (Cart A).

    At this point, the system has named Cart A, "Store" (this name can be specified by the merchant).

  2. The user leaves this active cart (Cart A) and navigates to the Carts page. He selects a previously saved cart (Cart B) and updates/activates it (by pressing Update or Checkout button).

    At this point, the system gives Cart A the default system-saved name, "Store Saved" (this name can be specified by the merchant).

  3. At any point in this process, the user can explicitly save the cart by selecting the Save Cart button.

See the section, "Naming Behavior for System-Saved and Default-Named Carts", below, for more information.

Naming Behavior for System-Saved and Default-Named Carts

The default name given to default-named and system-saved carts can be controlled by mapping a source file to the message-class media objects associated with these carts, or by updating the FND message text in Oracle Forms.

Note: It is not required that you change the names of system-saved and default-named carts. By default, their names will be Store (default-named) and Store Saved (system-saved).

Out-of-the-box, these media objects have no site/language mapping. Oracle iStore uses the DisplayManager.getTextMediaOrFndMsg API to get the cart name, and this API returns a custom prompt (media object site/language mapping), if defined; otherwise, it returns the FND message text.

A cart name can be mapped to all sites and all languages, or can be mapped by site/language, using standard Oracle iStore media object site mapping functionality. For more information, see the chapter, Implementing Content.

To change the name of the carts using Oracle Applications text messages, you can update the FND message text. See the chapter, Implementing Messages and Prompts, for steps.

Following are the values for the two message-class media objects for default-named and system-saved carts:

Duplicating Shopping Carts

Customers can duplicate shopping carts and quotes (including shared carts and quotes) from several cart-related areas of the Customer Application. When a cart or quote is duplicated, customers are prompted to name the cart/quote. Once named and saved, duplicated carts or quotes behave as any other saved cart (or saved shared cart or quote).

Duplicating Carts

Customers can duplicate shopping carts from the following pages: Carts page, Saved Cart Details page, and Shared Cart Details page.

Duplicating Quotes

Customers can duplicate quotes from the following pages: Quotes page, Quote Details page, and Shared Quote Details page. In the Actions LOV, the quote duplication action is labelled Copy to Cart. Duplication of quotes follows the same rules of standard shopping cart duplication. Once a quote is duplicated, it is stored under Saved Carts.

Rules and Guidelines of Cart Duplication Feature

Specific rules and guidelines exist for duplicated carts and quotes, as described below.

Implementing Cart Duplication Feature

The cart duplication feature is implemented by default for both B2B and B2C users.

Shopping Cart Items Pricing

This section contains information about the pricing of items in shopping carts.

Automatic Re-pricing of Cart Items

Items in shopping carts get re-priced any time a user updates the cart. This includes, for example, adding items to the cart or changing shipping/billing information. Assuming IBE: Use Price list Associated with Specialty Site profile is Yes (meaning that the site where the user is shopping is using a site-based, assigned price list), if an item has been re-priced on the assigned price list, the pricing engine finds and displays the correct, updated price. In the case where an item in the user's cart has been removed from the price list, then an error message will display in the cart.

If IBE: Use Price list Associated with Specialty Site profile is No, Oracle iStore will be retrieving "best prices" dynamically from the pricing engine, and will not be retrieving prices from a static price list (except for guest users). In this case, if an item has been deleted from available price lists, an error will occur when the user updates the cart. See the chapter, Implementing Pricing, for more information on pricing.

Using Pricing Agreements in Shopping Carts

A B2B user with the IBE_USE_PRICING_AGREEMENT and IBE_VIEW_NET_PRICE permissions in his user role will see the Pricing Agreement action in the Shopping Cart page. Pricing Agreements must first be implemented before they can be selected by a user. See the chapter, Implementing Pricing, for more information.

Cart-level and item-level scenarios are possible with pricing agreements:

Using Promotion Codes in Shopping Carts

The Promotion Codes field in the Shopping Cart page allows both B2C and B2B users to enter promotion codes. Promotion codes are modifiers set up through the Oracle Order Management Pricing module.

To enable the Promotion Code field in the Shopping Cart page, set the profile option, IBE: Use Promotion Code. See the appendix, Profile Options, for more information on the profile option. Note that in addition to any required merchant setups, B2B users must have the IBE_VIEW_NET_PRICE permission in their user roles to access promotion code functionality.

To apply a new promotion to an item, enter a promotion code in the Promotion Code field and click the Apply button. The Promotion Codes table displays the promotion codes that have been applied. To remove a promotion code from the table, click the trash bin icon in the Remove column.

To selectively apply or remove promotion codes at the line level, select Line Promotions from the Actions drop-down list on the Shopping Cart page. The Line Promotions page appears with a list of line items. Users can enter valid promotion codes on the selected line items and click Apply.

See the Oracle Order Management Implementation Manual for additional information.

Using Additional Information (DFFs) in Shopping Carts

Oracle iStore allows you to set up cart- and item-level descriptive flexfields (DFFs) in the shopping cart to capture customer information. The Additional Information menu entry is enabled in the shopping cart actions menu. See the chapter, Advanced Display, for setup details.

Using Attachments in Shopping Carts

A B2B user with the IBE_USE_ATTACHMENT permission in his user role will see the Attachments menu entry in the Shopping Cart Actions menu. The Attachments functionality is not available for B2C users.

To use the Attachments functionality, set the profile option, IBE: Attachment Document Category. See the appendix, Profile Options, for more information on the profile option.

The size of a file to be uploaded with a shopping cart can be controlled by setting the maximum file size value in the Oracle Applications (FND) profile option, Upload File Size Limit. The value should be an integer representing kilobytes (KB). For example, if the value is 100, then files up to 100 KB can be uploaded as attachments. The default value for this profile is 15,000 KB, unless implementers set a different number. If the user attaches multiple files, or one single file that exceeds the maximum size, an error message displays. (This feature requires Oracle Technology Foundation (JTF) 11.5.10.2CU patch as prerequisite.)

After the user selects Attachments and presses Go, the Attachments page shows any previously selected attachments associated with the cart. To add an attachment from the file system, the user selects the Add Attachment button. In the file retrieval page that displays, the user selects the Browse button to select the attachment from the file system. The user also can enter a description for the file in the Description textbox. The user selects the Apply button to save the file selection.

In the Attachments page, users also can remove attachments from the cart. After attaching or removing files and applying the changes, the user selects the Back to Shopping Cart button to return to the cart.

Checking Item Availability in Shopping Carts

Both B2B and B2C users can select the Check Availability menu item from the Actions list in the Shopping Cart page to check whether items in their carts will be available for shipping by a specified date. You must first set up Available to Promise functionality (ATP) before it will be available in the shopping cart. See the chapters, Implementing Products, and Integrating Oracle iStore with Oracle Advanced Supply Chain Planning, for more information.

After the user selects Check Availability and presses Go, the Check Availability page displays a list of cart items, along with a calendar icon to select the date for which the customer would like to check availability. The user selects the date(s), then presses the Check Availability button to display the availability information in the table column labelled, "Availability Information". When finished viewing availability information, the user selects the Back to Shopping Cart button to return to the cart.

Shopping Lists

Shopping lists allow users to save items in shopping carts to lists and then copy the items from these lists into their active carts. Shopping lists have the following main features:

Shopping List Management

Shopping list management enables the iStore user to create a new shopping list, view existing shopping lists, and add an item or product directly to an existing shopping list. The drop-down menu is associated to the Add to Cart button.

  1. The Add to Cart with the drop-down menu is controlled by the IBE: Enable Shopping List Management profile option. See the appendix, Profile Options for more information. If this profile option value is set to No or Null, then the standard Add to Cart button with no drop-down menu is displayed.

  2. The following iStore templates include the drop-down Shopping List Management feature:

    • Single Selection Template: ibeCCtdFSubSctI.jsp

    • Multiple Selection Templates: ibeCCtdFSuStMs2I.jsp and ibeCCtdFSuStMs3I.jsp

    • Item Details Templates: ibeCCtdAddItemBin.jsp, ibeCndSvaSvcList.jsp, ibeCCtdItemDetail.jsp, ibeCCtdItemDtlNoImg.jsp, ibeCCtdSvaItmDtl.jsp, and ibeCCtdSvcItmList.jsp

    • Shopping Cart Page: ibeCScdViewA.jsp

    • Save Shopping List: ibeCSlpOCSave.jsp

The iStore user can click on the Add to Cart button with drop-down menu for a product to create and manage shopping lists without navigating to the Shopping List page. The iStore user must log in to the iStore customer application to view the complete list of drop-down menu options.

Note: The iStore user remains on the Product Catalog page or navigates to the Shopping Cart page based on the IBE: Add To Cart Navigation profile option setting. See the appendix, Profile Options for more information.

The Add to Cart button with drop-down menu enables the iStore user to perform the following actions:

Shopping List Process Flow

Following is the process flow for shopping lists:

  1. A user selects the Save to List action in the Shopping Cart page.

  2. In the Save to Shopping List page, the system prompts the user to:

    • Enter a new, unique list name and some brief comments to associate with the list (comments cannot be updated after saving the list).

    • Merge the items to an existing list (if one exists)

    • Replace the items in an existing list (if one exists)

    The user's current active cart -- including the items in it -- remains the active cart when a shopping list is saved.

  3. The user presses Apply to complete the save operation, and the Shopping Lists page displays, showing the user's saved lists.

  4. To retrieve a shopping list, the user navigates to the Shopping Lists page within the Cart menu, and selects the hyperlink of the desired list name. The Shopping List Details page appears.

  5. To add items to a cart, in the Shopping List Details page, the user selects the appropriate items in the shopping list and presses Add to Cart.

    Note that if the active cart already contains items identical to those added from the list, and the profile option, IBE: Merge Shopping Cart Lines, is enabled, the cart item quantities are added accordingly, not replaced. For example, if the active cart contains 1 quantity of Item A and the list also contains 1 quantity of Item A, when the user adds the list Item A to the cart, the cart quantity for Item A changes to 2 (assuming the merge shopping cart lines profile is on). For more information on the profile option, see the appendix, Profile Options. See also: "Merging Duplicate Items in Cart" within this chapter.

  6. Optionally, in the Shopping List Details page, the user also can:

    • Merge additional items from other lists.

    • Update quantities for items in the list by entering the numerical values in the Quantity field and pressing the Update Quantity button.

    • Delete items in the list by activating an item's Select checkbox and pressing the Delete button (not the Delete List button).

    • Drill down to product details by selecting the hyperlink of an item name. At this point, the user can add the item to a new cart and checkout, including Express Checkout.

    • Delete the entire list by selecting the Delete List button.

  7. Once the user presses Add to Cart from the Shopping List Details page:

    • If an active cart with items is in use by the user, the selected items are added to the existing active cart, the Shopping Cart page. Duplicate items are merged if the profile option, IBE: Merge Shopping Cart Lines, is enabled.

      Note that there are exceptions to the above for specific types of products -- see the section, "Merging Duplicate Items in Cart", within this chapter, for additional details.

    • If no active cart exists, a new cart is created which is the user's active cart.

    • The shopping list still will continue to appear in the Shopping Lists page, with the original items in it.

  8. After the list items are transferred to a cart, the user can perform normal activities with the active cart. For more information on these flows, see the "Working with the Active Cart" section.

Shopping Carts and Shopping Lists Serve Different Purposes

Shopping carts and shopping lists serve different purposes for Customer UI users. The following two sections note some differences and similarities between the use of shopping carts and shopping lists.

Shopping Carts

Shopping carts are transactional entities used to check out with and purchase products from the Customer UI.

Shopping Lists

Shopping lists are non-transactional entities that store products the user may wish to purchase. They help to enable future repeated purchases.

Shopping Cart Security

Oracle iStore uses security authentication to keep different users from accessing each others' shopping carts and shopping lists by manipulating the URL. When a user attempts to retrieve a cart, Oracle iStore verifies that the user is actually the owner of the shopping cart or a user to whom the cart has been shared; if the user is found to be neither the owner nor a recipient of the cart, then access is denied.

Tax Display in Shopping Carts

Oracle iStore supports both cart-level and item-level tax display in the shopping carts.

Tax information is set up in Oracle E-Business Tax. See the Oracle E-Business Tax Implementation Guide for information on how to set up taxes.

Cart-Level Tax Display

Out-of-the-box, Oracle iStore displays cart-level tax only. Cart-level tax display includes the following, applicable to a specific cart:

Item-Level Tax Display

If enabled, item-level taxes applicable to the item are displayed below every item in the shopping cart.

To display item-level taxes, map the logical template, STORE_CART_LINE_TAX, to the JSP page, ibeCScdShowCartLineTax.jsp, appended with the parameter, ibeDisplayLineTax=Y. Map the template for the sites in which you wish to display item-level taxes. Following is the complete syntax that the source file field must contain in order for the mapping to be successful:

ibeCScdShowCartLineTax.jsp?ibeDisplayLineTax=Y

Notice the question mark (?) between the JSP name and the parameter.

Remember that B2B users must have the IBE_VIEW_NET_PRICE permission in their user role to see tax rates.

For information on how to map the template, see the chapter, Implementing the Catalog.

Displaying Amounts for More than One Tax Code

Some countries charge more than one tax (for example: VAT, local tax, provincial tax). In such cases, Oracle iStore will display the applicable amounts for each tax code at the cart level. If item-level tax display is enabled, the applicable amounts for each tax code for the item are displayed.

Shopping Cart Expiration Values

Two profile options control the number of days that active and saved carts are available to users before they expire. Carts expire at the end of the day on the day they are scheduled to expire. Expired carts are no longer accessible to users. The expiration date gets reset every time the cart is updated by the user. Note that when you change the value of the expiration profile options, existing saved carts are not affected. Shopping cart expiration dates are shown on the Shopping Cart and Carts pages.

See the appendix, Profile Options, for more information on these profile options.

Merging Duplicate Items in Cart

You can enable Oracle iStore to merge lines on an order if the items are identical. In this case, Oracle iStore increases the quantity by one for each identical item merged.

This ability is controlled by setting the profile option, IBE: Merge Shopping Cart Lines. See the appendix, Profile Options, for more information on the profile option.

Important: If you set this profile option to Yes, you must set the profile option, IBE: Use Line Level Shipping, to No. You cannot enable shopping cart item merging and item splitting simultaneously. For more information on item level shipping, see the chapter, Implementing Payment Types and Shipping Methods.

Exceptions to and Rules for Merging for Specific Setups

Note the following exceptions and rules for specific setups:

Decimal Quantities for Cart Items

When adding an item or updating quantity in the Oracle iStore shopping cart, the customer can enter a decimal quantity if the item is divisible. Oracle iStore calls the same API used by Oracle Order Management for validating quantity. If an item is marked OM Indivisible, decimal quantities are not allowed for its primary unit of measure (UOM).

To prevent the customer from selecting a decimal quantity of an item, log into Oracle Forms with Inventory responsibility for the master inventory organization, and mark the OM Indivisible flag. See the Oracle Inventory User's Guide for more information.

Direct Item Entry

Oracle iStore's Direct Item Entry functionality allows users to quickly add multiple items to a shopping cart without the need for browsing for items, adding them to cart, and then checking out with them. This functionality is available for B2B users only.

Direct Item Entry Benefits

Direct Item Entry enables users to:

Note: Model bundles, configured items, and serviceable items can be entered through the form; however, after adding to cart, these must be configured separately from the cart. For example, if you add a serviceable item to the form and then add to cart, you must add the service separately from the cart.

In the case where multiple Inventory part numbers are mapped against a single customer part number, only the highest ranked Inventory part number will be displayed.

Additional Information: If there is no active cart, then the only action available in the Shopping Cart page is Direct Item Entry.

Direct Item Entry Process Flow

The process flow for Direct Item Entry is as follows:

  1. A registered B2B user logs into a specialty site, selects the Direct Item Entry action from the Shopping Cart page and clicks Go. The Direct Entry Form appears.

  2. The user enters the following and selects Fill Details:

    • Cross Reference Type: A cross reference type is defined within Oracle Inventory as a group name for classifying the inventory item number. An Oracle Inventory installation (merchant) can define a cross reference type as Industry Standard Item that references the merchant's internal inventory item number with a higher level grouping. This allows the merchant to define a relationship between their own internal item numbers with a cross reference grouping. This functionality requires item mapping in Oracle Inventory. See the Oracle Inventory User's Guide for more information.

    • Cross Reference Part Number:A cross reference part number is defined within Oracle Inventory as an alternate way of referencing the internal inventory item number. This functionality requires item mapping in Oracle Inventory. See the Oracle Inventory User's Guide for more information.

      Note: A customer or a cross reference part number or an Oracle Inventory part number is required at minimum.

    • Customer Part Number: This functionality requires item mapping in Oracle Inventory. See the Oracle Inventory User's Guide for more information.

    • Oracle Inventory Part Number: If only Inventory part number is entered, Oracle iStore does not automatically enter the customer part number.

      Note that either a customer or an Oracle Inventory part number is required at minimum. If the user provides both the customer and Inventory part numbers in a line, customer number takes precedence. If the user enters an invalid part number, the invalid customer or Inventory part number is preserved in the field.

    • Quantity: If no input value is found for the item quantity, the default value of 1 is assumed.

      The following table summarizes the processing rules when the user enters values in the Direct Item Entry page and clicks the Fill Details button.

    Customer Part Number Cross Reference Type Cross Reference Part Number Inventory Part Number Processing Rule
    Entered       Searches for customer part number and displays the inventory part number and item name if the customer part number is found.
    Entered Entered     Searches for customer part number, ignores other entries and displays the inventory part number and item name if the customer part number is found.
    Entered Entered Entered   Search for customer part number, ignores other entries and displays the inventory part number and item name if the customer part number is found.
    Entered Entered Entered Entered Searches for customer part number, ignores other entries and displays the inventory part number and item name if the customer part number is found.
      Entered     Displays an error message indicating that the cross reference part number must also be entered.
      Entered   Entered Displays an error message indicating that the cross reference part number must also be entered.
      Entered Entered   Searches for cross reference part number within the context of the cross reference type, and if found, displays the inventory part number and item name.
      Entered Entered Entered Searches for cross reference part number within the context of the cross reference type and ignores inventory part number. If found, displays the inventory part number and item name.
        Entered Entered Searches for cross reference part number and ignores inventory part number. If found, displays the inventory part number and item name.
          Entered Searches for the inventory part number. If found, displays the inventory part number and item name.
  3. Oracle iStore populates the primary UOMs and item names into the form. (If the user clicks Add to Cart before pressing Fill Details, the primary UOM is defaulted for items.) If the profile option, IBE: Retrieve all Units of Measure for an Item, is set to Yes, the user can select different values for UOMs.

    Note: To increase the default number of rows in the form, set the profile options, IBE: Additional Table Rows and JTF_PROFILE_DEFAULT_NUM_ROWS. See the "Implementing Direct Item Entry" section, below, for details.

  4. For each item to be added to the shopping cart, the user selects the appropriate item check box and clicks Add to Cart. All items selected are added to the user's active cart. Items not selected are not saved into the form. However, if the add-to-cart action fails, the user is returned to the Direct Item Entry form with values intact.

  5. The user proceeds with checkout.

  6. The customer item number or the cross reference part number entered in the Direct Item Entry page is passed to Oracle Order Management.

Process Flow for Uploading Comma Separated Values File

To populate the Direct Item Entry form, users can upload a comma separated values (.csv) file containing relevant values for customer part number, Oracle Inventory part number, UOM, and quantity. The .csv file must contain a customer part number, a cross reference part number, or an inventory part number. If the file contains neither UOM nor quantity, Oracle iStore defaults these values to primary UOM and 1 (for quantity), respectively. If neither the customer part number nor Inventory part number for an item are specified in the file, the Direct Item Entry form ignores the item, and does not upload any data for it.

The process flow for Direct Item Entry using a .csv file is as follows:

  1. A registered B2B user logs into a specialty site, selects the Direct Item Entry action from the Shopping Cart page and clicks Go. The Direct Entry Form appears.

  2. The user clicks Upload to retrieve the Upload Items page. From this page, the user selects the appropriate .csv file from the file system.

    Note: The number of items that can be uploaded at a single given time is determined by the profile option, IBE: Maximum Direct Entry Rows.

  3. The user clicks Apply to upload the file and validate the item information. Oracle iStore addresses common file errors as follows:

    • If the file is corrupted, Oracle iStore displays an error message in the Upload Items page, and the file will not be uploaded.

    • If invalid part numbers are found, Oracle iStore displays an error message in the Direct Item Entry page.

    • If the user specifies an invalid UOM in the .csv upload file, the primary UOM is selected.

  4. For each item to be added to the shopping cart, the user selects the appropriate item checkbox and clicks Add to Cart. Items are added to the user's active cart. Items not selected are not saved into the form. However, if the add-to-cart action fails, the user is returned to the Direct Item Entry form with values intact.

  5. The user proceeds with checkout.

See also: "Set up Comma Separated Values File" section, below

Implementing Direct Item Entry

To set up Direct Item Entry, follow the steps below. These steps assume a site has been implemented and contains valid products -- only items that can be purchased via the site catalog are considered valid items. The steps are:

Step 1 - Set Mandatory Profile Option

Set the following mandatory profile option: IBE: Use Direct Item Entry --- Set to Yes. See the appendix, Profile Options, for more information on the profile option.

Step 2 - Set Optional Profile Options

Set the following profile options according to your business requirements:

Note: The profile option, IBE: Use Price List Associated with Specialty Site, also affects the display of UOMs in the Direct Item Entry. The following table details the behavior.

Using Profile Options to Display UOMs
If IBE: Retrieve All UOMs for an Item is set to... And if IBE: Use Price List Associated with Specialty Site is set to... UOM Display Behavior
Yes No Oracle iStore displays all UOMs defined in Inventory for the item. These UOMs are displayed irrespective of whether they have valid prices or not.
Yes Yes Oracle iStore displays all UOMs defined in Inventory for the item. It verifies whether each UOM has a valid price.
No Yes Oracle iStore displays only primary UOM defined in the price list for the item. It does not check whether UOM has valid price.
No No Oracle iStore displays only primary UOM defined in price list for the item. It does not check whether UOM has valid price.

Caution: Performance issues (slow loading of catalog pages) can occur if IBE: Retrieve All Units of Measure for an Item is Yes. The performance issues can happen because, when the profile is Yes, a pricing call is made for each UOM of each item in the price list.

Step 3 - Set up Item Mapping

Optionally, set up Item Mapping in Oracle Inventory. Before B2B customers can use their companies' internal part numbers for Direct Item Entry, mappings must be established between the customer items and the merchant items in Oracle Inventory. For directions, refer to the Oracle Inventory User's Guide.

Step 4 - Set up Comma Separated Values File

This section contains information regarding the use of the .csv file upload utility.

The format of the .csv file can be defined in two ways:

See also: "Rules for Using Either Format" section, below

Create Header Containing Pre-Defined Codes

When using a header containing pre-defined codes to identify columns, the codes map to the following meanings, as shown in the following table.

Codes and Meanings for .Csv File
Code Description
CUST_NUM Customer part number
CROSS_REFERENCE_TYPE Cross reference type
CROSS_REFERENCE_PART_NUM Cross reference part number
INV_NUM Inventory part number
UOM Unit of Measure
QTY Quantity

The user can create a header row using the codes in the order desired. The codes are case sensitive. If using this method, the header row must contain at least INV_NUM, CROSS_REFERENCE_PART_NUM, or CUST_NUM. The following table shows an example of how these codes could be used in practice in a .csv to populate the Direct Item Entry Form.

Sample Columns for .Csv Upload File
CUST_NUM CROSS_REFERENCE_TYPE CROSS_REFERENCE_PART_NUM INV_NUM UOM QTY
    Corner_desk   Ea 1
CHAIR-STD       Ea 2
  iStore XRef Kitchen_Hutch   Ea 3
      RT50104 Ea 4

Note: The .csv file can be created using Microsoft Excel and saving the file in .csv format.

Utilize Pre-Defined Fixed Format

To utilize the fixed format, the .csv file cannot contain a header row. When using this method, the fixed format must be in the following order:

Rules for Using Either Format

For either format, the following rules apply:

Processing Rules for the Pre-Defined fixed Format .csv File:

Shopping Cart Sharing

This section contains topics related to shopping cart sharing for Oracle iStore's Customer UI.

Cart Sharing Overview

Oracle iStore's shopping cart sharing functionality allows multiple users to shop and purchase products collaboratively, utilizing the same shopping cart. Cart sharing has the following main features:

See the "Shared Cart Behavior" section for additional information.

Shared Cart Behavior

The following points describe shared cart behavior:

Shared Cart Roles

The following are the B2B and B2C share cart roles:

The names and descriptions of these seeded values can be changed. See the chapter, Implementing Messages and Prompts, for details.

Important: Actions that B2B cart administrators can perform in most cases do not apply to B2C cart administrators. For B2C users, only the cart owner has full permissions to perform actions with a shared cart. B2C cart administrators have lesser permissions than B2B cart administrators.

The following table discusses roles and the actions the users can perform.

Share Cart: Roles and Permissions
Role Permissions
Administrator
  • Place order with the cart/quote

  • Remove/modify existing members of the cart/quote *

  • Change roles of members *

  • Add comments/notify members

  • Add new members to the cart/quote *

  • Stop sharing carts/quotes *

  • Re-share cart/quote *

  • Delete carts (but not quotes) *

  • Request sales assistance for carts/quotes *

  • Disagree with terms and conditions

  • Track order placed with cart/quote *

  • Duplicate carts

Participant
  • Update carts/quotes

  • Add comments/notify members

  • Review terms and conditions

  • Duplicate carts

Viewer
  • View carts/quotes

  • Add comments/notify members

  • Review terms and conditions

  • Duplicate carts

  * B2B admins only; B2C must be cart owner

Note that cart owners (the user who initiates the cart sharing) always has at least administrator permissions.

Sharing Carts

The process flow for sharing carts is as follows.

  1. A customer visits a site and adds items to the shopping cart.

  2. The customer selects the Share Cart action to begin the sharing process. This retrieves the Share Cart page. The Share Cart page shows all cart items, customer name and address, and shipping and billing information. In this page, the customer must enter a cart name.

  3. Selecting members and setting member roles is different for B2B and B2C cart owners:

    • B2B Users --- In the Share Cart page, a B2B user selects the Add Member button. Using the Search and Select: Members page, he searches for users within his organization using the same financial account. Oracle iStore automatically adds a wildcard to the end of any criteria entered, and searches on the first name field of Contact Name.

      From the search results, he selects the applicable members, and is returned to the Share Cart page, where he selects roles for each member.

      Important: Other B2B members on the cart also must have access to the same financial account as the owner's session account when he initially shared the cart -- if they do not, they will not be able to update the cart.

    • B2C Users --- The B2C customer will see a different version of the Share Cart page. For the B2C customer, there is no Add Member button -- instead, B2C customers simply enter in textboxes the names and valid e-mail addresses of the members in the Share Cart page, and then select the appropriate roles for the members.

  4. Once the members have been chosen and their roles set, in the Notify column of the Share Cart page, the owner can choose to notify all members on the cart or only specific members. A mark in the Notify checkbox means that the member will receive an e-mail informing him about the shared cart.

  5. In the Comments field of the Share Cart page, the owner can enter comments to include with the e-mail notification. Only members who have had their Notify checkbox marked will receive the e-mail and the comments.

  6. The owner selects the Apply button to complete the share process, and Oracle iStore displays a confirmation message.

All B2B administrators on the cart can subsequently re-share this cart. See the section, "Re-sharing Carts", for more information.

See the section, "Shared Cart Roles", within this chapter, for information about shared cart roles and the permissions allowed by each role.

Re-sharing Carts

After a cart has been shared, B2B members with the administrator role can re-share the cart. Only B2C cart owners can perform this type of action with a shared cart.

The process flow for re-sharing carts is as follows.

  1. An administrator accesses the Edit Member page for a shared cart. This page can be accessed as outlined in the section, "Retrieving Shared Carts", within this chapter.

  2. In the Edit Member page, the administrator selects the Add Member button to access the search screen for users within his organization.

  3. From this point, the flow is identical to sharing a cart for B2B users. See the section, "Sharing Carts", within this chapter.

Retrieving Shared Carts

Following is the shared cart retrieval flow for recipients -- notice that the process is somewhat different for B2C members:

To see examples of the Carts page for B2B and B2C users, see the following figures: "Carts Page - B2B Users" and "Carts Page - B2C Users".

See also:

Shared Cart Details Page Activities

Customers can access the Shared Cart Details page via one of the methods described above. Following are the activities users can perform from these pages (providing their shared cart role allows it and the related functionality has been implemented):

Refer to the "Common Shopping Cart Elements" section earlier in this chapter for more information on the above actions not explained here.

Requesting Assistance or Rejecting T&Cs with Shared Carts

Sales representative assistance is available for shared carts, providing the functionality has been implemented -- see the chapter, Implementing Customer Assistance.

The following points describe the application behavior with this functionality:

Note: Updateable portions of quotes depend on the profile option, IBE: Allow Update for Draft Quotes. See the chapter, Integrating Oracle iStore with Oracle Quoting, for more information.

See also: The section, "Terms and Conditions" in the chapter, Integrating Oracle iStore with Oracle Sales Contracts.

Additional Rules and Guidelines for Cart Sharing

This section contains information about rules and guidelines related to share cart members.

Rules and Guidelines for Recipients

Following are some additional guidelines regarding recipients:

Rules and Guidelines for Administrators

Following are some additional guidelines regarding administrators:

See the section, "Requesting Assistance or Rejecting T&Cs with Shared Carts", within this chapter, for information on this functionality for cart administrators.

Pricing and Payment Rules for All Shared Cart Users

The following table describes pricing/payment modification activities and behavior for all users with shared carts.

Pricing and Payment Rules for All Shared Cart Users
Cart Attribute Modification Rule - B2B Users Modification Rule - B2C Users
Sold-to customer and contact Since a cart can only be shared within the organization, the sold-to customer will never change. The sold-to contact for a shared cart will always be the cart owner, even if a recipient places a shared cart as order. Sold-to customer and contact is always the owner, even if a recipient places a shared cart as an order.
Cart pricing Prices are based on the sold-to customer Cart prices are based on sold-to customer.
Promotion codes During checkout, promotion codes are validated against the sold-to customer. Promotion codes are validated against the sold-to customer.
Pricing agreements During checkout, pricing agreements are validated against the sold-to customer. n/a
Payment information During checkout, recipients can specify payment information from the payment book available to them. Payment information entered by recipients will not be linked to the cart owner Recipients and owners can specify payment information from the payment book available to them. Payment information entered by recipients will not be linked/copied to the cart owner.

Quote Sharing

Quotes are available in the Customer Application under the Quotes subtab within the Cart menu. The Quotes summary page lists all of a user's quotes, including shared quotes. Quotes can originate from shopping carts that become quotes when a customer requests sales assistance or rejects T&Cs. Quotes also can be published to a customer through the quote publishing feature of Oracle Quoting.

Also refer to the chapter, Integrating Oracle iStore with Oracle Quoting.

Shared Quote Behavior

Following are rules and guidelines for shared quotes:

Sharing a Quote

To share a quote, both B2B and B2C users select the Share Quote action from the Quotes or Quote Details pages. After this action, the quote sharing process is identical to cart sharing. Remember, however, that updating quotes is only allowed when the profile option, IBE: Allow Update for Draft Quotes, is Yes.

Retrieving a Shared Quote

Retrieving a shared quote is identical to retrieving a shared cart, except that the Quotes page is used to access the quotes. Quotes also can be retrieved via the Shared Quote e-mail notification.

Shared Quote Details Page Activities

The Shared Quote Details page can be accessed by selecting the hyperlink of a shared quote in the Quotes page, or through access to a Shared Quote e-mail notification, which contains a link to the Shared Quote Details page. Following are the activities the user can perform in this page:

Implementing Shared Carts

Two profile options affect the shared cart functionality, as discussed in the following sections.

Setting the Cart Sharing Profile Option

To enable shopping cart sharing, set the following profile option: IBE: Use Sharecart Functionality. This profile option specifies whether cart sharing is enabled in your specialty sites. Set to Yes to enable the functionality. Set to No to disable the functionality.

Setting the B2B Shared Cart/Quote Backward Compatibility Profile Option

For backward compatibility with the Sharee Number of previous Oracle iStore releases, you can set the following profile option to Yes to enable the Cart Retrieval Number textbox in the Carts and Quotes pages: IBE: Cart Retrieval By Number For B2B. For B2B users, this profile option enables a textbox (labelled Cart Retrieval Number) in the Carts and Quotes pages. B2B users can enter a Sharee Number from previous iStore releases to access carts previously shared.

Note that this profile does not control the cart retrieval textbox for B2C users.

Checkout and Order Placement

The following sections discuss features and functionality related to checkout and order placement.

Checkout and Order Placement Overview

Oracle iStore ships with full checkout and order placement capabilities in the Customer Application. Following are some of the major features of the Customer Application checkout and order placement:

Note: Some of the functionality in this section discussed requires integration with Oracle iStore dependencies and assumes you have performed the required setup tasks.

For business process flows related to checkout and order placement, see the Customer Application Process Flows, chapter.

Checkout Flow Trail

Each step of the checkout flow is identified using a breadcrumb trail. The trail lets the user know where he is in the checkout process. The possible trail steps (depending upon the functionality implemented) are:

If Terms and Conditions and End Customer information (B2B only) are not enabled, the corresponding trail steps are not displayed. The trail steps are not clickable; instead, customers can navigate between the checkout flow pages using the Back/Next buttons in the UI. Each time the user selects a Back or Next button, the information in the page is saved, unless it is sensitive information (credit card numbers are scrambled, except for the last four digits). When the user selects Cancel he is returned to the Shopping Cart page, except in the case of a quote that is not updateable. In this case, the Cancel button takes the user back to the Quote Details page. When the user performs an action that takes him one or more steps off the trail, the step the user is currently in is highlighted, while all the other steps are grayed out.

Whether or not the shipping page is skipped depends on the item type:

Note: The display of Terms and Conditions (T&Cs) content can depend on system variables. Thus, if user changes shipping, billing, end customer, and quantity information in the order review page, the T&Cs can be affected. Users are able to branch out of the checkout flow in the order review page to review and accept T&Cs after they have changed. If the profile option, IBE: Enforce Terms and Conditions Review by User, is Yes and the user branches out from the order review page, the place order button is disabled and the user needs to accept the T&Cs again before he is allowed to place the order.

Shopping Cart Defaulting During Checkout

In the Oracle iStore Customer UI, as the user goes through the checkout process, Oracle iStore defaults certain information into the users' checkout pages. This information includes shipping and billing information related to the user.

Shopping cart defaulting both improves the performance of the checkout flow, and improves the defaulting capabilities of Oracle iStore. The feature defaults in the shipping addresses, billing addresses, primary credit card, and preferred shipping method of the user when the user adds the first item to the cart.

The following are the triggers that activate cart defaulting:

Defaulting for Shipping Data

The following shipping fields are populated when shipping information defaulting occurs:

Defaulting for Billing Data

The following billing fields are populated when billing information defaulting occurs:

If this defaulting does not take place, then New Credit Card is displayed as the payment option on the billing and payment checkout page. If credit card is not enabled by the merchant as a payment type, then Invoice, Cash and Check (in this order) will be chosen, depending on which payment types have been enabled by the merchant. If the user does not have a default credit card in his profile and creates a new credit card, the new credit card is used in the checkout process and becomes the default credit card; this card then will be defaulted the next time.

Deleted (Invalidated) Addresses in Shopping Carts

Once a B2B or B2C user places a shipping or billing address into his shopping cart, Oracle iStore will keep these addresses in the cart even if these addresses get deleted (invalidated) before the user checks out with the cart. This ensures that users never are allowed to checkout without addresses in their shopping carts.

This rule applies to:

The following shopping cart checkout flow examples illustrate the rule:

Standard Checkout:

  1. A user add items to the cart and proceeds to checkout.

  2. The user picks a shipping and a billing address to use in the cart.

  3. The user switches to the Profile menu's Address Book and deletes the shipping and/or billing address used for the cart.

  4. The user returns to checkout with the same cart -- the shipping and/or billing address continue to appear in the shipping and billing section cart-level settings.

Checkout with a Shared Cart:

  1. A user adds items to the cart.

  2. The user proceeds to checkout and shares the cart with another recipient.

  3. The user picks a shipping and a billing address to use in the cart.

  4. The user switches to the Profile menu's Address Book and deletes the shipping and/or billing address, and then logs out.

  5. Recipient of the shared cart retrieves the cart and checks out with it -- the shipping and/or billing addresses continue to appear in the shipping and billing section cart-level settings.

Express Checkout:

  1. A user enters shipping and billing address information in Express Checkout Preferences page.

  2. The user places items in his shopping cart for automatic retrieval by the concurrent program.

  3. The user goes to the Express Checkout Preferences page and deletes his express checkout billing and/or shipping address.

  4. Express Checkout concurrent program submits the order with the previously-deleted shipping and/or billing addresses.

Pricing Calls During Checkout

Because pricing calls to the database are expensive in terms of application performance, during the checkout flow, Oracle iStore only makes calls to the pricing engine under certain conditions. When a user updates some item in a checkout flow page, Oracle iStore always saves the page, but the pricing call is only made under specific conditions, as described in this section. Note that the system makes a distinction between pricing calls occurring at the order (header) level and those occurring at the item (line) level.

Pricing Calls During B2B Checkout

Oracle iStore calls the pricing engine during B2B checkout as follows:

Shipping Information Page

Billing and Payment Information Page

End Customer Information Page

Pricing Calls During B2C Checkout

Oracle iStore calls the pricing engine during B2C checkout as follows:

Shipping and Billing Information Page

Requesting Sales Assistance During Checkout

If a user requests sales assistance in the checkout phase, the cart becomes a quote and the user's sales representative receives an e-mail notification of the request.

Note that a B2B user must have the IBE_ASK_SALES_ASSISTANCE permission in his user role to be able to request sales assistance.

This functionality requires that both Oracle Quoting and the Sales Assistance feature (IBE: Use Sales Assistance Feature = Yes) have been implemented. For more information, see the chapters, Integrating Oracle iStore with Oracle Quoting, and Implementing Customer Assistance.

For information on who can request sales assistance with a shared cart or quote, see the section, "Shopping Cart Sharing".

Rejecting Terms and Conditions During Checkout

If a customer rejects the standard Terms and Conditions (T&Cs) in the checkout phase, the Sales Assistance flow initiates. The cart becomes a quote in Oracle Quoting and also appears for the customer on the Quotes page, Quotes list.

In order to be able to reject T&Cs, a B2B user must have the IBE_ASK_SALES_ASSISTANCE permission in his user role, and the profile option which controls the sales assistance feature, IBE: Use Sales Assistance Feature, must be set to Yes.

For more information, see the chapters, Integrating Oracle iStore with Oracle Sales Contracts, and Implementing Customer Assistance.

For information on who can reject T&Cs with a shared cart or quote, see the section, "Shopping Cart Sharing", within this chapter.

Mandating B2B Contact Information During Checkout

Merchants have the ability to mandate whether B2B users must enter ship to and bill to contact information during checkout. Oracle iStore APIs validate this information against database tables used by Oracle Receivables.

This functionality is enabled by setting the following profile option at the application level for iStore: IBE: Mandate Contacts For Billing and Shipping --- Enter Yes to mandate that B2B users enter contact information before an order will be submitted. Enter No to disable the mandate.

This profile option defaults to No if not set.

A warning message is displayed if the user attempts to continue without providing the required information. The user cannot continue without providing the required information.

Note: B2B users must have the permission, IBE_CHANGE_BILLTO_CONTACT and IBE_CHANGE_SHIPTO_CONTACT, in their user role in order for them to be able to change ship-to and bill-to contact information.

Selection and Creation of Organization Data During Checkout

Organizations can control which users or groups of users are allowed to create and change customers, contacts and addresses (including bill-to and ship-to address usages) during the checkout flow by assigning or removing certain permissions from the B2B user roles assigned to their business users.

Billing Flow Permissions

Following are the permissions which control creating and changing customers, contacts, and addresses from the Checkout: Billing Information page and associated searching and creating pages:

Shipping Flow Permissions

Following are the permissions which control creating and changing customers, contacts, and addresses from the Checkout: Shipping Information page and associated searching and creating pages:

For information on the End Customer permissions, refer to the section, "Capture End Customer Data During Checkout", within this chapter.

End Customer Permissions

Following are the permissions which control creating and changing customers, contacts, and addresses from the Checkout: End Customer Information page and associated searching and creating pages:

How Account Sites Are Generated with Orders

At order creation, Order Capture (iStore's backend API layer) will create a valid account site use for the given party site and account number, if none exists. During this process, if the Oracle Receivables (AR) system parameter auto_site_numbering is No, then the location field when creating an account site use will be concatenated with the site use code, city, and account site use id. If the AR system parameter auto_site_numbering is Yes, then Order Capture APIs (which Oracle iStore uses to pass information to AR) will not populate the field, but instead will let AR generate the value for the Location field (to be the same as the account site use id).

Smart Checkout

Available to B2B and B2C customers, the Smart Checkout feature lets Customer Application users skip the shipping and billing steps in the checkout phase. Instead of entering shipping and billing information during checkout, users navigate directly from the shopping cart to the order review page. The Smart Checkout feature works on basis of shipping and billing information as set up for the sold-to customer in the profile and this information is defaulted into the checkout flow. The customer can set billing preferences in the profile payment page, where only credit card information can be supplied.

Assuming shipping and billing information is set up appropriately for the sold-to customer, this information is defaulted into the checkout flow. If the required information is not populated when the user comes to the Order Review page, an error icon is displayed and the user must enter the required data. If End Customer information is mandated, then end customer data is also required. In a typical flow, the customer reviews the information in the order review page and then places the order; or, the customer can go back to each section and modify the information.

If Terms and Conditions (T&Cs) are enabled with Smart Checkout, the T&Cs page is the first page displayed in the checkout flow (instead of the shipping/billing information page), assuming shipping, billing and end customer information have been populated with default information. When the user agrees with T&Cs, the order review page is displayed.

For newly registered users who likely will not have default address data entered into their profiles, the system will automatically show the shipping or billing page (depending upon which information is lacking), and the user can enter his information into the page before proceeding. Also, the system will pick the first available shipping method (if there is no preferred shipping method for the user) to default into the shipping page.

Smart Checkout is enabled by setting the profile option, IBE: Skip Checkout Steps for Order Placement, to Yes. See the appendix, Profile Options, for more information on the profile option.

Express Checkout

Available for all registered users, Express Checkout allows orders to be submitted as batch jobs by using a concurrent program, iStore - Express Checkout Order Submission. In addition to the concurrent program, the functionality is enabled by setting two profile options.

See the chapter, Concurrent Programs, for more information on the concurrent program.

If the credit card verification number is set up as mandatory, implementers should disable Express Checkout functionality. See the chapter, Implementing Payment Types and Shipping Methods, for more information.

Express Checkout Process Flow

Note that a B2B user must have the IBE_CHECKOUT and IBE_CREATE_ORDER permissions in his user role to use Express Checkout.

Following is the process flow for Express Checkout:

  1. In Oracle Forms, an administrator sets the profile options discussed in the section, "Setting Express Checkout Profile Options", below.

  2. In the Oracle iStore Customer Application, the Express Checkout preferences link appears in the Welcome Bin, and the Express Checkout Preferences page is available through the Profile menu.

  3. Oracle iStore user sets up Express Checkout preferences:

    • The user enters a valid credit card number and contact information in the Express Checkout Preferences page, and saves the data. The Express Checkout Preferences page is available by selecting Profile, Preferences, Orders in the Customer Application. The system checks for valid addresses and credit card information before saving the settings. An error message is returned if the user has entered invalid information.

      Important: For B2B users to create addresses, customers, and contacts, they must have the appropriate permissions (e.g., IBE_CREATE_SHIPTO_CUSTOMER, IBE_CREATE_BILLTO_CUSTOMER, IBE_CREATE_BILLTO_CUSTOMER_ADDRESS, IBE_CREATE_BILLTO_CONTACT_ADDRESS, and/or IBE_CREATE_SHIPTO_CONTACT_ADDRESS). The Create button will not show in the Express Checkout Preferences page next to the appropriate areas if the users do not have the applicable permissions.

    • The user enables Express Checkout in the Express Checkout Preferences page.

  4. Once the user preferences are set up and Express Checkout is enabled, to purchase items through Express Checkout, the user does the following:

    • Selects the Express Checkout button that appears next to products in the catalog pages. This adds the item to the Express Checkout queue.

      Note: Express Checkout does not apply to model bundles that have been enabled in Oracle Bills of Material; hence, the Express Checkout button will not appear next to these items.

    • Selects the Express Checkout button in the Shopping Cart page. This adds all items in the cart to the Express Checkout queue.

  5. The site then forwards the user to the Pending Express Checkout Orders page, where he can cancel the order if desired. If he does nothing, the concurrent program will pick up the order and submit it.

  6. The concurrent program, iStore - Express Checkout Order Submission, automatically picks up the Express Checkout queue and submits the orders.

Setting Express Checkout Profile Options

To use Express Checkout in your Web sites, set the following profile options at the iStore application level.

Enter values for this profile option in minutes. The default value for this profile option is 60 (minutes).

Rules and Guidelines for Express Checkout

Keep the following rules and guidelines in mind for Express Checkout functionality.

Checkout Flow Pages

This section describes the pages within the checkout flow. The flow can vary according to the user type and functionality implemented.

Shipping and Billing Information Pages

Oracle iStore displays different shipping and billing pages depending upon whether the user is a B2B or B2C customer:

B2B Shipping Information Page

The B2B Checkout: Shipping Information page elements and features include:

B2B Billing Information Page

The B2B Checkout: Billing and Payment Information page features and functionality include:

B2C Shipping and Billing Information Page

Shipping and billing information for B2C customers is combined in the Checkout: Shipping and Billing page. If no shippable items are in the cart, the page is named simply Billing Information. Very similar to the B2B versions, the B2C Checkout: Shipping and Billing page has the following main features and functionality:

Shipping Portion of the Page:

Billing Portion of the Page:

Cart Actions:

Splitting Configured Items for Shipping

Customers can split shipping lines for configured items in order to ship to multiple locations. Refer to the chapter, Implementing Payment Types and Shipping Methods, for implementation information about line-level shipping. The line-splitting functionality for configured items creates a copy of the top-level model item and its components, and copies all attributes from the original configuration. This behavior is very similar to the existing behavior of splitting lines with standard items. Here is the business flow:

  1. A customer configure items from catalog or shopping cart, using Oracle Configurator, and proceeds to checkout.

  2. Using the Ship to Multiple Locations area of the shipping page, the user can split configured items that have a quantity greater than one. Following are additional points about the behavior:

    • All service items and line attributes (price list, item-level billing, item-level shipping, item-level flexfields, etc.) are copied as well.

    • When the original item is split, Oracle iStore creates the new line item with following quantity:

      • Model quantity: As input by the user

      • Components quantity: Model quantity times the unit quantity of the component

    • When the top-level model item is split, the new model items and their components are exact duplicates of the original top-level model item and its components.

    • The relationships between the original top-level model item and its components are preserved in the newly created model items and their respective components.

    • During the split, the sum of quantities of the split lines cannot exceed the original quantity.

  3. After selecting the desired split quantities and entering the ship-to details, the customer proceeds through the checkout flow.

B2B End Customer Information Page

The Checkout: End Customer Information page only displays for B2B customers and only if Capture End Customer Data functionality is enabled. See the section, "Capture End Customer Data During Checkout", within this chapter, for more information on the feature.

Following are the main features and functionality of the End Customer Information (note that all information is initially defaulted from the shipping information):

B2B Customer Selection and Entry Pages

From the B2B Checkout: Shipping Information, Checkout: Billing and Payment Information, and Checkout: End Customer Information pages customers can select new customer information and enter new customer data to be related to the order at cart or item level. Selecting and creating customer information in these pages is dependent upon whether or not the B2B customer has certain permissions in his user role. These permissions are listed in the section, "Selection and Creation of Organization Data During Checkout", within this chapter.

The company information defaulted from the lists of values on the shipping, billing, and end customer pages maps to the sold-to organization associated to the logged in user. The My company information defaulting option is available only when the user has appropriate "change customer" and "change contact" permissions (e.g., IBE_CHANGE_SHIPTO_CUSTOMER and IBE_CHANGE_SHIPTO_CONTACT in the Shipping page). When selecting this option, the sold-to contact is defaulted based on the logged in user. The address is defaulted based on the defaulting rules (first using the primary ship-to address for the contact, then using the primary ship-to address of the organization). For more information about the defaulting rules in the checkout phase, see the section, "Shopping Cart Defaulting During Checkout", within this chapter.

Select Customer Page

The Search and Select: Ship To Customer, Bill To Customer, and End Customer pages are available from the checkout information pages to users who have the appropriate "change customer" permissions (e.g., IBE_CHANGE_BILLTO_CUSTOMER, IBE_CHANGE_SHIPTO_CUSTOMER) in the role assigned to them. Users who have these permissions can select the Change button to choose a new ship-to, bill-to or end customer in the selection pages. The selection pages have the following features and functionality:

Select Contact Page

The Search and Select: Ship To Contact, Bill To Contact, and End Customer Contact pages are available from the checkout information pages to users who have the appropriate "change contact" permissions (e.g., IBE_CHANGE_BILLTO_CONTACT, IBE_CHANGE_SHIPTO_CONTACT) in the role assigned to them. Users who have these permissions can select the Change button to choose a new ship-to, bill-to or end customer contact in the selection page. The selection pages have the following features and functionality:

Select Address Page

The Search and Select: Ship To Address, Bill To Address, and End Customer Address pages are available from the checkout information pages to all B2B users. Users can select the Change button to choose a new ship-to, bill-to or end customer address in the selection pages. The selection pages have the following features and functionality:

Create Customer Page

The Create <Ship To/Bill To/End> Customer pages are available from the Search and Select: Customer pages to users who have the appropriate "create customer" permissions (e.g., IBE_CREATE_BILLTO_CUSTOMER, IBE_CREATE_SHIPTO_CUSTOMER) in the role assigned to them. Users who have these permissions can select the Create button in the applicable Search and Select pages and create a new ship-to, bill-to or end customer. The create customer pages have the following features and functionality:

Create Contact Page

The Create <Ship To/Bill To/End Customer> Contact pages are available from the Search and Select pages to users who have the appropriate "create contact" permissions (e.g., IBE_CREATE_BILLTO_CONTACT, IBE_CREATE_SHIPTO_CONTACT) in the role assigned to them. Users who have these permissions can select the Create Contact button in the Search and Select pages to create a new ship-to, bill-to or end customer contact. The create contact pages are organized into two main areas: Contact Information (with company name defaulted and entry fields for contact name, e-mail address, and contact numbers) and Contact Address. The display of the Contact Address section is controlled by the appropriate "create contact" permission (e.g., IBE_CREATE_SHIPTO_CONTACT_ADDRESS). When displayed, the address creation is optional.

Create Address Page

The Create <Ship To/Bill To/End Customer> Address pages are available from the Search and Select Address pages to users who have the appropriate "create address" permissions (e.g., IBE_CREATE_BILLTO_CUSTOMER_ADDRESS, IBE_CREATE_BILLTO_CONTACT_ADDRESS, IBE_CREATE_SHIPTO_CUSTOMER_ADDRESS, IBE_CREATE_SHIPTO_CONTACT_ADDRESS) in the role assigned to them. Users who have these permissions can select the Create Address button in the Search and Select pages to create a new ship-to, bill-to or end customer address. Customers have the option of creating an address associated with the company or associated with the contact (this is controlled by the permissions mentioned in "Create Contact Page", above; for example, if the user only has the IBE_CREATE_BILLTO_CUSTOMER_ADDRESS permission, then he can create the address for the customer). In the create page, the company and contact are defaulted into the page, and the data entry fields are standard address fields.

Terms and Conditions Page

For both B2B and B2C users, Terms and Conditions are displayed in the Checkout: Review Terms and Conditions page, if this functionality has been implemented (see the chapter, Integrating Oracle iStore with Oracle Sales Contracts). Users must agree to the Terms and Conditions on the order before finalizing checkout if the profile option, IBE: Enforce Terms and Conditions Review by User, is Yes. The buttons on this page are:

Terms and Conditions are displayed in the Checkout: Review Terms and Conditions page, and can be shown dynamically based on items in the cart, if required. This functionality requires additional setups detailed in the chapter, Integrating Oracle iStore with Oracle Sales Contracts.

Order Review Page

The Checkout: Review and Place Order page is the final page in the checkout/order placement flow (besides the order confirmation page). It displays the following information:

The order review page allows users to change shipping, billing, and customer data, if the user has the required permissions. If Terms and Conditions (T&Cs) are enforced (IBE: Enforce Terms and Conditions Review by User is Yes) and something about the order has changed that requires a re-review of T&Cs (e.g., quantity, bill-to data, or ship-to data changes), a link to the T&Cs is displayed, allowing user to review them again. In this case the Place Order button is grayed out; only after the user accepts T&Cs will the Place Order button display.

Orders Business Flow

The orders flow is as follows

  1. An order is placed in an Oracle iStore site when the user selects the Place Order button.

    Note that B2B users must have the IBE_CREATE_ORDER permission in their user roles to see the Place Order button.

  2. If the order uses standard checkout, Oracle Order Capture APIs send order data to Oracle Order Management. (The Submit_Quote API passes carts to the Create_Order API, which books the order in OM.) The default order state (Booked or Entered) is determined by the profile option, ASO: Default Order State.

    • Booked orders are ready to move to the next stage in the order process (for example, shipping). Booked orders cannot be deleted or modified (although quantity can be changed) by a sales representative. In addition, a sales representative cannot do a line-level return for a Booked order.

    • Entered orders must then move to the Booked stage before completion.

  3. If the order is placed using Express Checkout, the iStore Express Checkout Order Submission concurrent program loads the order data into the Oracle Order Management tables.

  4. The order is then processed through Oracle Order Management, Oracle Shipping, and Oracle Receivables.

  5. Users can view the order details --- including shipping, invoice, and payment information --- using the Order Tracker functionality in the Web sites.

For more information, see the following resources:

Capture End Customer Data During Checkout

The ability to capture end customer data during checkout is described in the sections that follow.

Overview of Capture End Customer Data Feature

Some vendor organizations require their partners to provide end customer information when placing an order. To address this need, Oracle iStore allows implementers to enable the capturing of end customer data during checkout in the Customer Application.

Vendors are interested in capturing the end customer data for different reasons, such as:

Oracle iStore implementers can enable partners and B2B users to capture end customer information at the cart and item levels during checkout. End customer information consists of:

Capture End Customer Data Key Features

The Capture End Customer Data functionality has the following main features for users in the Customer Application:

The Checkout: End Customer Information page is described in the section, "Checkout Flow Pages" within this chapter.

The ability to capture end customer data functionality has the following main features for implementers of Oracle iStore:

Capture End Customer Data High-Level Process Flow

Following is the high-level process flow for Capture End Customer Data functionality:

  1. A B2B or partner user accesses an Oracle iStore site to place an order for an end customer. The vendor requires the end customer information to validate that the user is actually buying products for an end user.

  2. The user creates a shopping cart with multiple items, which may be shipped to one or multiple end customers. Initially, end customer information is defaulted from the cart-level information stored for the B2B or partner user creating the shopping cart.

  3. If purchasing for one end customer, the user proceeds to checkout and selects or creates end customer data (company name, location, and contact name) in the Checkout: End Customer Information page. If purchasing for multiple end customers, the user proceeds to checkout with the cart, and for each item of the shopping cart, the user selects or creates the end customer data.

  4. In either case, partners and B2B users can use UI flags to specify whether:

    • End customer information is the same as the ship-to, bill-to, or sold-to customer information at the cart level

    • End customer information is the same as the sold-to customer/cart information at item level

To create new end customers, the user must have the proper permissions in his B2B user role, as discussed in the "Rules and Guidelines for Capture End Customer Data Feature" section, below.

Searching for and Selecting End Customer Data

From the Checkout: End Customer Information page, partner and B2B users can select end customer information from the available lists of values (LOVs) in the Search and Select: End Customer Information page. The LOVs display:

In the LOVs, Oracle iStore provides the ability to search for customers by multiple parameters. All data is sourced through Oracle iStore's relationship with Oracle Trading Community Architecture (TCA) customer model.

Rules and Guidelines for Capture End Customer Data Feature

The following rules and guidelines apply to the feature:

Creation of End Customer Data

If assigned the appropriate permissions (shown in the above section), B2B and partner users can create the following end customer data:

If the B2B or partner user is not associated to the appropriate permission, the user can place orders only using customers already existing in the system. In this case, if there is a need to create a new end customer, the process needs to be done using another method (for example, in Oracle Customers Online, Oracle Order Management, or Oracle Quoting). In the LOV, when selecting end customers, the B2B or partner user can access only customers related to his organization. If a customer is associated to multiple organizations, the B2B or partner can only view contacts, accounts, and transactions related to the organization with which he is associated.

Implementing Capture End Customer Data Feature

Implementing the Capture End Customer Data feature involves ensuring that the B2B or partner users have the appropriate permissions in the B2B user roles and setting profile options. Following are the profile options:

If IBE: Mandate End Customer is set to Yes, then IBE: Mandate End Customer Contact can be set either Yes or No, based on implementation requirements. If IBE: Mandate End Customer is set to No, then IBE: Mandate End Customer Contact should not be set and will not take effect.

Order Tracking

Once an order is submitted in an Oracle iStore site, customers can log into the site and access their order details (including invoices, payments, shipping, and returns) in Order Tracker, if the administrator has enabled this functionality.

Order Tracker Overview

In the Customer Application, Order Tracker is available to registered users through the Orders icon. The Order Tracker section consists of the following subtabs:

Note that the specific functionality must be implemented for the relevant subtab to appear.

Searching in Order Tracker

In the Order Tracker screens, all customers can search for orders, invoices, payments, and return orders. For orders, both basic and advanced search are available. Advanced search, enabled through a profile option, is available to only B2B and partner users. In addition, the B2B/partner screens in simple search contain additional search parameters not available to B2C customers.

Note: Not all fields and data display to all users -- Be sure to review the topic, “Rules and Guidelines for Order Tracker Search”, within this section.

Order Tracker Basic Search

Basic search includes the following search options:

The Order Details and Item Details pages display pricing agreement data, end customer information and any additional information defined at order header or line level.

Order Tracker Advanced Search

Using Advanced Search, B2B and partner users can search at order level or item level.

Order Level Advanced Search

When searching at the order level, users can query by:

When a user selects Ship to Customer, Bill to Customer and End Customer, the corresponding Ship to Account, Bill to Account and End Customer Account are displayed as selected values, concatenated to the customer name.

The search results display:

Users must enter at least one search parameter other than the order status, order dates, and pricing agreement to perform the search. An error message displays when the search is performed without entering the search criteria.

Users can navigate from the orders summary table to the Order Details and to the Shipment Details pages. Ship to, Bill to, End Customer and Pricing Agreement are not available in the summary search results. Users can drill down into the order details to view this information.

Item-Level Advanced Search

When searching by items (order lines), users can query by:

The search results display:

Users must enter at least one search parameter other than line status, requested delivery dates, and pricing agreement to perform the search. An error message will be displayed when the search is performed without entering the search criteria.

Users can navigate from the lines summary table to the Order Details and Item Details pages. Ship to, Bill to, End Customer and Pricing Agreement will not be available a search result fields. Users can drill down into the order details to view this information.

Implementing Advanced Search

To implement advanced search, set the profile option, IBE: Use Advanced Search in Order Tracker, to Yes. See the appendix, Profile Options, for more information on the profile.

Copy Prior Order

The Order Details page allows users to select one or more items on the order and copy them to the shopping cart. This allows users to re-order items and have them added directly to the shopping cart. Users must select at least one item when clicking on the existing “Add to Cart” button. An error message is displayed when the Add to Cart function is performed without selecting any of the order line items. When the Add to Cart function is performed, users will be navigated to the shopping with the selected items, UOM and ordered quantities populated in the cart.

Additional Information: Service items and Configured items are not supported in the "Copy Prior Order" feature.

Rules and Guidelines for Order Tracker Search

The following rules and guidelines apply to Order Tracker search (both simple and advanced):

Customizing Order Tracker Search

You can customize the default Number of Days value in Order Tracker Basic Search beyond the customization allowed by changing the lookup values. You do this by modifying JSP code to pass the desired default number in the display template parameter, defaultNoOfDays. The value for the defaultNoOfDays parameter is passed from the container page (e.g., ibeCOtdOrdSumMain.jsp) through the PageContext before including the processing page (e.g., ibeCOtpOrdSum.jsp). If passing the parameter in the display template, the default number of days is retrieved based on the following rules:

If the value for the parameter, defaultNoOfDays, is not passed in the display template, following is the behavior:

For details about the related lookup and default search values, see the chapter, Implementing Messages and Prompts.

Customizing the Code

To pass the parameter from the display template, in the container page, include the following line of code just below the include for the processing page:

//pageContext.setAttribute("defaultNoOfDays", "9", PageContext.REQUEST_SCOPE); %>

For example, in ibeCOtdOrdSumMain.jsp, the code might appear as:

//Include
//pageContext.setAttribute("defaultNoOfDays", "9", PageContext.REQUEST_SCOPE); %>
…
<%@include file="ibeCOtpOrdSum.jsp" %>

Similarly, the default query for Invoices, Payments and Returns can be customized by modifying the respective container JSP pages (ibeCOtdInvSumMain.jsp, ibeCOtdPmtSumMain.jsp and ibeCOtdRetSumMain.jsp),

Examples

In these examples, it is assumed that the values present in the lookup are: 3, 7, 14, 30, and 90.

Orders and Related Pages

The Orders page, accessible to customers by selecting the Orders icon and then the Orders subtab, summarizes a customer's submitted orders. Summarized order information includes:

Note: Customers will be able to see orders billed to their accounts or sold to (default) their accounts, depending upon the setting of the profile option, IBE: View-by Customer Orders in Order Tracker, and if the permissions, IBE_VIEW_BILL_TO_ORDER and IBE_VIEW_ORDER, are associated. For more information, see the section, "IBE_VIEW_BILL_TO_ORDER and IBE_VIEW_ORDER", in the appendix, Seeded User Data, as well as the "IBE: View-By Customer Orders in Order Tracker" section in the appendix, Profile Options.

The Orders page contains search mechanisms which are described in "Searching in Order Tracker", within this chapter.

This section contains descriptions of the Orders page and the sub-pages navigable from it. Unless otherwise specified, information about item types in this section relates to standard items (versus configured items, model bundles, and install base items). See the sections, "Configured Items in Order Tracker" and "Install Base Items in Order Tracker", within this chapter, for details about the display of these types of items in the Order Tracker pages.

The sections that follow describe these pages:

Order Details Page

The Order Details page displays a variety of information about a specific order. To access the Order Details page, customers select the hyperlink of an order number in the Orders summary page. The Order Details page displays the follow sections and related information:

Item Details Page

The Item Details page displays details about individual items in an order. Customers access this page by selecting the Item Details icon in applicable pages. The Item Details page includes the following sections and details:

Pricing Details Page

The Pricing Details page is a pop-up page that displays pricing details for individual items in an order. Customers access this page by selecting a hyperlinked item price in applicable pages (e.g., Order Details). The Pricing Details page includes the following sections and details:

Shipment Details Page

The Shipment Details page displays details about the shipment of items in the order.

When an order line is booked, a Delivery Line is created for each of the lines in Oracle Shipping, followed by the running of the Pick Release program. Once Pick Release is completed successfully, the order lines in status, Awaiting Shipping, and release statuses, change to Picked/Staged. Later, the items are packaged and put into deliveries. Deliveries are assigned to trips, and finally ship confirm is performed. One order can have multiple deliveries and one delivery can have order lines from different orders. Note only shippable items data is shown. Note that the shipping details link/icon will be disabled if the order is in either Entered or Cancelled status.

The Shipment Details page Oracle iStore displays the following sections and details:

Customizable Shipping Information Hook

To enable you to extend shipping details (for example, to link to an carrier's Web site), Oracle iStore provides a customizable user hook. See the section, "Order Tracker Hook for Shipping Lines", below, for details.

Shipment Number Details Page

The Shipment Number Details page, which is accessible by selecting a shipment number hyperlink in applicable pages (e.g., the Shipment Details page), displays information about the actual shipment of specific items in the order. Note that some other Oracle E-Business Suite applications, such as Oracle Order Management, refer to the shipment number field as "delivery". The Shipment Number Details page displays the following:

Pending Express Checkout Page

If Express Checkout is enabled, users will see the details of their express checkout orders in the Pending Express Checkout Orders page accessible by selecting the Orders icon, then the Pending Orders subtab in the Customer Application. This page displays the following:

See the "Express Checkout" section within this chapter for more information on Express Checkout functionality.

Invoices Page

The Invoices page is available by selecting the Orders icon, then the Invoices subtab within the Customer Application. Enabled by default, the display of the Invoices page can be disabled by setting the profile option, IBE: Enable Invoices in Order Tracker, to No. See the appendix, Profile Options, for more information on the profile option settings. The Invoices page displays the following:

Note: A B2B user must have the IBE_VIEW_NET_PRICE permission in his user role to see amounts in the Invoices pages.

Invoice Details Page

The Invoice Details page is available by selecting a hyperlinked Invoice Number in applicable pages (e.g., from the Invoices page). The Invoice Details page displays details about a specific invoice and includes the following information:

Payments Page

The Payments page is available by selecting the Orders icon, then the Payments subtab within the Customer Application. Enabled by default, the display of the Payments page can be disabled by setting the profile option, IBE: Enable Payments in Order Tracker, to No. See the appendix, Profile Options, for more information on the profile option settings. The Payments page displays the following:

Note: A B2B user must have the IBE_VIEW_NET_PRICE permission in his user role to see amounts in the Payments page.

Payment Details Page

The Payment Details page is available by selecting a hyperlinked Payment Number in applicable pages (e.g., from the Payments page). The Payment Details page displays details about a specific payment and includes the following information:

Install Base Items in Order Tracker

Install base items are items previously purchased by customers and instantiated into the install base database. The My Products subtab within the Orders menu of the Customer Application displays install base items. The My Products subtab appearance is controlled through the profile option, IBE: Use Install Base View.

Important: Allowing customers to order and track telecommunications service orders (TSO) products requires the implementation of Oracle TSO functionality. See the Oracle Telecommunications Service Ordering Process Guide for more information.

Searching in My Products Tab

For B2C customers, the search criteria can be turned on or off by setting the profile option, IBE: Autoquery Install Base for B2C User. For B2B customers, the search criteria always is present, and the user must enter some values to retrieve an item. If the search criteria is turned on for B2C customers, the behavior is the same as for B2B customers.

The search criteria includes the following parameters:

For B2B customers: Blind queries are not supported for any search field. For Item Name, the customer must enter at least four characters (then he can use the percent (%) sign as a wildcard). For all other criteria, the customer must enter at least one character (plus the wildcard).

The search results return a table with the following columns:

In the search results, two types of configurations are represented:

For connected-to instances, only instances that belong to the logged-in user's owner_party_ID and the account_ID (of the individual) are retrieved.

Note that for B2B customers, the search retrieves instance(s) that are at any level of the configuration. For B2C customers, only the top-level instances are retrieved.

See also: Oracle Telecommunication Service Ordering Process Guide and the appendix, Profile Options, within this guide.

Rules and Guidelines for My Products and Related Pages

The following rules and guidelines apply to the My Products page and related pages:

Configured Items in Order Tracker

The Order Tracker display of configured items is described in the following sections. (Note that the term configured item is used for any item that has a parent item and subcomponents.)

The following descriptions apply to the display of these items in the Track Orders, Order Details, Shipment Details, and Item Details pages, unless specified otherwise.

General Display of All Configured Items

In the Order Details and Shipment Details pages, parent items are shown without any indentation, while the child items display under the parent, indented slightly. The sections that follow describe additional configured item display characteristics.

Order Details Page

In the Order Details page, non-TSO models show only the top-most parent (root) item, with a Details hyperlink leading to the Configuration Details screen, where in the entire model is exploded. The children items are indented based on their height in the model tree. The price shown is the rolled-up price of the entire model.

Item Details Page

Since the page shows single items, there is no concept of configurations in the Item Details page.

Shipment Details Page

In the Shipment Details page, parent items are shown without any indentation, while the child items display under the parent, indented slightly.

Returns Pages

In the pages that show single order return creation/return review, and in the submit/return confirmation pages, only the parent items are shown, with a Details hyperlink (as in the Order Details page for non-TSO models). Unlike the Order Details page, however, the configuration details display in a new (pop-up) window. In the Return Details page, configured items display similarly to the non-TSO items in the Order Details page.

Assemble-to-Order Items

Oracle iStore shows assemble-to-order (ATO) model items and all components. Following are additional details:

Pick-to-Order and Kit Items

Oracle iStore shows pick-to-order (PTO) model items or kit items with all components. Following are additional details:

Model Bundles

Oracle iStore displays model bundles similarly to PTO and kit items. Following are additional details:

Telecommunications Service Ordering (TSO) Items

For telecommunications service ordering (TSO) items, the shipped quantity field is populated only for shippable child items in a network container. For non-shippable items, the field is blank. In the Order Details page, TSO models show the entire model exploded. The children are indented like the non-TSO models.

Option Classes

Option classes are displayed in Order Tracker if the profile option, IBE: Display Option Classes in the Shopping Cart and Order Tracker, is set to Yes or is null (default value). See the appendix, Profile Options, for more information on the profile option.

Order Tracker for B2C Users

Oracle iStore provides a limited subset of Order Tracker functionality for B2C users. The following bullet points highlight the differences from the B2B Order Tracker pages.

B2C Option for View By Orders

By setting a profile option, implementers can specify for B2C customers whether they are viewing orders where they are the sold-to or bill-to account on the order. To use the functionality, set the profile option, IBE: View-by Customer Orders to Bill-to, Sold-to or All (this setting includes all orders for where the customer is either the bill-to or sold-to on the order). See the appendix, Profile Options, for more information on the profile option settings.

Permission Checking in Order Tracker

You can control whether Oracle iStore checks user permissions in the Order Tracker pages by setting the profile option, IBE: Use Auth Permissions in Order Tracker. See the appendix, Profile Options, for more information.

Setting Number of Invoice/Order Lines to Display

The number of rows to display in Order Tracker when users view their orders, invoice, payment, or returns data is controlled by setting the profile option, IBE: Number of Invoice/Order Lines Displayed. See the appendix, Profile Options, for more information.

Order Tracker Hook for Shipping Lines

By implementing a region item in the Shipment Details page within Order Tracker, you can enable an extra column in the page which links to an additional processing page. Both pages are Oracle iStore Display Templates -- one is a detail template and one is a processing template. For an introduction to Display Templates, see the chapter, Implementing the Catalog.

In the processing template, you can insert custom logic to fulfill your organization's business requirements. For example, in the processing page you could provide additional shipment tracking mechanisms, such as a link to a carrier Web site where users could track the shipment of their purchases.

Following are the implementation steps:

Step 1 - Enable Region Item in Shipment Details Page

The region item, IBE_SD_ADDITIONAL, is disabled by default. After the region is enabled, a column, labelled, "Details", is automatically shown with a icon on the Shipment Details page.

Following are the steps to enable the region item:

Steps

  1. Log in to Oracle Forms with System Administrator responsibility.

  2. Choose Application Developer Common Modules.

  3. From the navigator, choose Define Regions.

  4. From the Region ID field, query for IBE_SHP_DTL_R.

  5. Go to Region Items.

  6. Scroll through the list and locate IBE_SD_ADDITIONAL.

  7. Check Node Display to enable the region item. (Uncheck to disable.)

  8. Save the changes.

  9. Bounce the middle tier server.

Step 2 - Customize Shipping Details Processing JSP

Next, customize the Shipping Details Custom Processing page with your own business logic.

Following are the details about this page and the main Shipping Details page:

Shipping Details Custom Processing Page:

The physical file for this page is an empty page, allowing you to provide your own content. The mapped JSP file and Display Template information for the Shipping Details Custom Processing page are:

Shipping Details Page:

The mapped JSP file and Display Template information for the Shipping Details page are:

Progammatically, the Shipping Details page table is constructed in a loop iterating through all region items. Each column is essentially a region item. Inside this loop, the URL to the Shipping Details custom processing page template is constructed. You can pass additional information to the destination by appending parameters to the URL (detailsURL). For example, you could provide information such as tracking numbers and shipping carriers. Such information can simply be stored in a variable to be used later.

For example:

else if (itemName.equals("IBE_SD_ADDITIONAL"))
{
String tmplName = "STORE_SHIP_DETAIL_CUSTOM_P";
// You can append parameters to detailsURL to pass additional information // to the processing page.
String detailsURL = 
DisplayManager.getTemplate(tmplName).getFileName();
%>
<td class="tableDataCell" valign="top" align="left">
<a href="<%= detailsURL %>">
<img src="/OA_MEDIA/detailsicon_enabled.gif" border="0">
</a>
</td>
<%
}

For sample code, see the Shipping Details Custom Processing page physical file (ibeCOtpShpDtlCustom.jsp). The sample code shows how to retrieve the parameter and process it. At the end of the page, the code simply redirects to Order Tracker; however, you can customize it to redirect to any page you want.

Changing Order Tracker Column Attributes

The columns that display in Order Tracker are retrieved from Oracle Applications AK Region attributes. Oracle iStore supports changing the AK Region Item attributes (for the attributes listed in the following table) for several regions.

Note that region items can have a number of properties associated to them, for example, attribute type, attribute name, sequence, display length, long label, etc. However, Oracle iStore uses only some of these properties (the ones shown in the following table). If a property that is not used by Oracle iStore is changed, there will be no impact to the Order Tracker pages. The following table lists the region item properties used by Oracle iStore. All other properties are not used.

AK Region Attributes Supported in Order Tracker
Property Purpose
Sequence Used to determine the sequence in which the HTML table columns corresponding to the region items are rendered. This can be changed by the merchant to display the Order Tracker columns in the desired order.
Node Display checkbox Used to find out if a region item is intended for display. If it is not, then the column that maps to the region item is not displayed. This can be used by the merchant to selectively turn off the display of columns. For example, on the order summary page, if the Customer Name column is not required to be shown, the merchant can turn off the node display flag for that region item in the region, IBE_ORD_SUM_R.
The Node Display can be programmatically turned on or off as well. Thus, even if the Node Display flag is set in the AK Region, the attribute might not be displayed based on specific business functionality. For example, the attribute corresponding to Order Type in IBE_ORD_HDR_R is enabled to be displayable, but will be hidden from the B2C user programmatically.
Queryable checkbox Used to determine the columns that can be queried on. These columns are then shown in the search drop-down list. For example, on the order summary page, if the Customer Name needs to appear as a field on which the users can query, then this can be accomplished by making the corresponding region item in the region, IBE_ORD_SUM_R, to be queryable.
Display Length Controls the display length for VARCHAR2 fields in the pages. If merchants customize their pages to reduce the Display Length, for example, for Item Description, from 240 to 80 characters, then Order Tracker would truncate the database value to 80 characters and display only 80 characters.
Long Label Used to retrieve the column headings for the columns shown in the HTML table on each Order Tracker page. This can be changed by merchants who have a need to display their own headings.

The following table shows the changeable regions, along with the page where they appear and the JSP file that presents the page.

AK Regions Supported in Order Tracker
Region ID Page JSP
IBE_INV_DTL_R Invoice detail page/Invoice to payment details page ibeCOtpInvDtl.jsp/ibeCOtpInvPmtDtl.jsp
IBE_INV_HDR_R Invoice detail page header section/Invoice to payment detail page header section ibeCOtpInvDtl.jsp/ibeCOtpInvPmtDtl.jsp
IBE_INV_SUM_R Invoice Summary ibeCOtpInvSum.jsp
IBE_ORD_DTL_R Order Details ibeCOtpOrdDtl.jsp
IBE_ORD_HDR_R Order detail page header section ibeCOtpOrdDtl.jsp
IBE_ORD_LINE_DTL_R Item details page ibeCOtpOrdLineDtl.jsp
IBE_ORD_SRL_HDR_R Serial number pop-up page ibeCOtpOrdLineSerialPopup.jsp
IBE_ORD_SUM_R Order Summary ibeCOtpOrdSum.jsp
IBE_PMT_DTL_R Payment detail page ibeCOtpPmtDtl.jsp
IBE_PMT_HDR_R Payment detail page ibeCOtpPmtDtl.jsp
IBE_PMT_SUM_R Payment Summary page ibeCOtpPmtSum.jsp
IBE_REL_RET_DTL_R Order Detail page Related Return section ibeCOtpOrdDtl.jsp
IBE_RET_CONF_DTL_R Return confirmation page Detail section ibeCOtpRetConfirm.jsp
IBE_RET_CONF_HDR_R Return confirmation page header section ibeCOtpRetConfirm.jsp
IBE_RET_CRE_MULT_LINE_DTL_R Return creation page: Multi order flow, display without serial number search ibeCOtpRetCreMultiLine.jsp
IBE_RET_CRE_MULT_LINE_SRL_R Return creation page: Multi order flow, page display with serial number search ibeCOtpRetCreMultiLine.jsp
IBE_RET_CRE_SINGLE_LINE_DTL_R Return creation page: Single order flow ibeCOtpRetCreSingleLine.jsp
IBE_RET_DTL_R Return detail page/Order Detail page Return item section in case of trade-in lines ibeCOtpRetDtl.jsp/ibeCOtpOrdDtl.jsp
IBE_RET_HDR_R Return detail page header section ibeCOtpRetDtl.jsp
IBE_RET_PENDING_DTL_R Pending return section in Create return page (single order flow/multi order flow) ibeCOtpRetPending.jsp
IBE_RET_SUB_AND_REV_DTL_R Return: Review and Submit page detail section ibeCOtpRetReview.jsp
IBE_RET_SUB_AND_REV_HDR_R Return: Review and Submit page header section ibeCOtpRetReview.jsp
IBE_RET_SUM_R Return summary page ibeCOtpRetSum.jsp
IBE_SHP_DTL_R Ship detail for order number page detail section ibeCOtpShpDtl.jsp
IBE_SHP_HDR_R Ship detail for order number page header section ibeCOtpShpDtl.jsp
IBE_DLY_HDR_R Ship detail for shipment number page header section ibeCOtpDlvyDtl.jsp
IBE_DLY_DTL_R Ship detail for shipment number page detail section ibeCOtpDlvyDtl.jsp
IBE_OL_SHIP_TRACK_R Item detail page tracking section ibeCOtpOrdLineDtl.jsp

Steps to Modify Column Attributes

You may use the following quick-steps to modify column attributes in IBE_ORD_SUM_R region. For more information, see the Oracle Self-Service Web Applications Implementation Manual (Web Applications Dictionary chapter).

Steps

  1. Log into Oracle Forms with Application Developer Common Modules responsibility and navigate to Define Regions, Find Regions window.

  2. Find IBE_ORD_SUM_R region.

  3. Edit the Region Items form for the region.

  4. In the list of region items/attributes within IBE_ORD_SUM_R region, find the region item/attribute to be changed.

  5. Edit the attributes shown in the table above as desired.

  6. Save your changes.

  7. Bounce the application server.

Order Cancellation

Oracle iStore allows B2B and B2C users to cancel orders that they have placed in the Customer Application, if the orders are in Booked or Entered status in Oracle Order Management. B2B customers also can cancel orders across organizations.

Order Cancellation Process Flow

The process flow for order cancellation is as follows:

  1. A user accesses the Order Summary or Order Details pages, and initiates the order cancellation process by selecting the Cancel Order button.

    Note: The Cancel Order button displays in the Customer UI only if the profile option, IBE: Enable Order Cancellation in Order Tracker, has been set to Yes, and the order is cancellable (in Entered or Booked status). In addition, B2B users who do not have the IBE_CANCEL_ORDER permission will be unable to access the button. B2B users with the IBE_CANCEL_ORGANIZATION_ORDER permission can cancel orders across operating units for their organization.

    Users who have enabled Express Checkout will be able to cancel Express Checkout orders before they are submitted to Order Management.

  2. Once a user initiates the cancellation request, the system checks to see if the order is cancellable. If it is, the user is taken to the Order Cancellation page.

    If the order is not cancellable, the cancellation process is aborted and a message is presented to the user which informs him that the order is not cancellable online and to contact his sales representative.

  3. In the Order Cancellation page, the user is prompted to select a Cancellation Reason from a drop-list.

  4. Once the cancellation request is submitted and accepted, a confirmation message displays on the UI.

  5. Oracle iStore sends the Cancel Order e-mail to the user confirming that the order has been cancelled.

Implementing Order Cancellation

The cancel order feature is enabled by setting a profile option and ensuring that your B2B users have the appropriate permissions in their user roles. See the following sections for more information:

Set Cancel Order Profile Option

To enable the cancel order feature, set the profile option, IBE: Enable Order Cancellation in Order Tracker, to Yes. See the appendix, Profile Options, for additional details about this profile option.

Verify B2B User Permissions

Verify that the B2B users registering in your sites have the permission, IBE_CANCEL_ORDER, in their user roles. Without this, the Cancel Order button will not display.

Oracle iStore also allows B2B users to view and cancel orders for their current session operating unit and other operating units within their organization. To enable this ability, assign their role the permission, IBE_CANCEL_ORGANIZATION_ORDER.

Order Returns

Oracle iStore's Returns feature allows both B2B and B2C users to return items from orders placed.

Note: This section covers returns processes and implementation tasks related directly to Oracle iStore. For information on setting up integrating applications, refer to the appropriate product documentation.

Returns Overview

In today's e-commerce environment, accepting return items in Web stores is standard functionality. Providing returns functionality both reduces the cost of doing business for merchants, and provides a invaluable step toward a complete customer self-service orientation.

To address this business requirement, Oracle iStore provides Returns functionality in the Customer Application. Using the Orders menu in the Customer Application, customers can initiate returns for orders which are in Booked or Closed status in Oracle Order Management. If an approval process is being used, an administrator can use Oracle Order Management to evaluate the returns, and either approve or reject the returns. Merchants can set up returns with or without Oracle Workflow approval mechanisms in place.

The following is a high-level Returns flow:

  1. To initiate a return (also known as a Return Material Authorization, or RMA), customers select applicable items, specifying the return quantities and return reasons.

  2. After the customer submits the RMA, Oracle iStore automatically sends a confirmation e-mail notification to the customer.

  3. Once Oracle Order Management processes the return order, the appropriate e-mail notification is sent to the user, notifying him whether the RMA has been approved or not (if approvals are being used). For approved RMAs, merchants can set up a return location to be sent in the e-mail notification.

  4. After an RMA is approved, on the back end, Oracle Purchasing and Oracle Accounts Receivable work to complete the RMA processing, by fulfilling the order lines and generating credit memos.

  5. RMAs are then available for the customer to track in Order Tracker.

Returns Functionality With and Without OM Release 11.5.10

This section discusses important differences in the returns functionality provided through Oracle iStore if you are using Oracle Order Management Release 11.5.10 versus earlier releases.

With Oracle Order Management Release 11.5.10

The following functionality exists without Oracle Order Management Release 11.5.10:

  1. Merchants can implement pre-booking approval processes for returns.

  2. The status of pending returns is User Working (regardless of whether pre-booking approval processes are being used). Return orders in Entered/User Working status are always part of a user's pending returns queue. These cannot be tracked as submitted orders in the Returns pages.

  3. When the user submits the return (clicks Submit Return button):

    • If an Approval List has been set up in Order Management:

      --Order status moves from User Working to Pending Internal Approval

      --User will be able to see the returns in Pending Internal Approval status in the Returns subtab

      --Based on the approver's action, the return then moves to Booked or Rejected status.

    • If an Approval List has not been set up in Order Management, then the order status moves to Booked status.

  4. Any errors from validations being done from Oracle iStore will show up in the Oracle iStore UI after the user adds the items to the return order (in the Create Return: Review and Submit page), prior to submission. See the section, "Validations Performed in Returns Process", for more information.

  5. E-mail notifications support --- Since Oracle iStore return orders are created with a transaction type having an order flow of "Order Flow - Return with Submission and Approval", when a return is Booked (irrespective of whether approval is setup or not), Oracle Order Management calls Oracle iStore to send an approval or rejection notification to the customer. Oracle iStore seeds two notifications for this purpose: Return Order Approval and Return Order Rejection. See the chapter, "Integrating Oracle iStore with Oracle Workflow", for details.

Note: If you are using Oracle iStore Release 11.5.10 with Oracle Order Management Release 11.5.10, set the profile option, IBE: Enable Return Pre-booking Approval, to enable the pre-booking approval process in Oracle Order Management.

Without Oracle Order Management Release 11.5.10

The following functionality exists without Oracle Order Management Release 11.5.10:

  1. Merchants cannot implement pre-booking approval processes for returns.

  2. The status of pending returns is Entered. Return orders in Entered status are always part of a user's pending returns queue. These cannot be tracked as submitted orders in the Returns pages.

  3. The status of submitted returns is Booked.

  4. Any errors from validations being done from Oracle iStore will show up in the Oracle iStore UI only after the user presses the Submit Return button. Additionally, the error messages that display are less detailed than Release 11.5.10 versions of Oracle Order Management. See the section, "Validations Performed in Returns Process", for more information.

  5. E-mail notifications support --- When a customer submits a return, the return is immediately Booked and the user receives a confirmation e-mail from Oracle iStore giving him details of the return-order, with a note, "A return order has been created. You will shortly receive an e-mail confirmation for approval of the return items with the return location."

Merchants can customize the Oracle Order Management workflows to hard-code the return location in the workflow message.

Validations Performed in Returns Process

Oracle iStore performs several validations during the returns process. The stage at which errors display from validation failures and the detail to which error messages display depend upon whether the pre-booking approval feature is enabled and which Oracle Order Management version is installed. See the section, "Returns Functionality With and Without OM Release 11.5.10", for details. Also see the Oracle Order Management product documentation.

See also: The section, "Rules and Guidelines for Returns"

Note: The detailed error messages described here apply to implementations running Release 11.5.10 and later versions of Oracle Order Management, with the pre-booking approval feature enabled.

Pending Returns Queue

Pending returns are return items that have been previously selected by a user and added to the pending returns queue by navigating with the items to the Create Return: Review and Submit page. Pending return items have been Entered -- but not yet submitted -- into Oracle Order Management. After submission, the items are no longer part of the pending returns queue.

Return orders in Entered status are always part of a user's pending returns queue. Note that there will always be only one pending return queue per user at a time.

If a pending returns queue doesn't exist, Oracle iStore creates one. If the queue does exist and the user adds an identical item from the same order line, the item is not re-added to the queue. Instead, only the return quantity on the existing return line is incremented by the new return quantity specified by the user. The return reason is retained for the existing return line.

If items are available in the queue, a Pending Returns section will display on the following pages:

Returns Process Flows

Merchants can set up returns with or without Oracle Workflow approval mechanisms. These mechanisms allow -- via automatically generated e-mails and associated processes owned by Oracle Order Management -- one or more people to approve or reject an RMA after the customer submits it, but before it is booked into Oracle Order Management. Functionality provided depends upon the Oracle Order Management version installed.

In addition, the Oracle Order Management version installed determines at what stage Oracle iStore validation errors display, the detail level of the errors, and the status of the returns after submission. See the section, "Returns Functionality With and Without OM Release 11.5.10", for information.

Single-Order Return Flow

The returns process flow for returning a single order is as follows:

  1. A customer logs into a site and selects the Orders button to access the Track Orders page.

  2. The customer selects an order number to access the Order Details page.

  3. The customer selects the Return Items button to access the Create Return: Select Items page. The Return Items button only displays if the profile option, IBE: Use Returns, is set to Yes, and -- for B2B users -- if the user has the IBE_CREATE_RETURN permission in his user role.

    The Create Return: Select Items page shows items from the order just selected, with a zero quantity for each returnable item, and any pending returns.

    In the Create Return: Select Items page, for each item in the order that the user is returning, he selects a return reason and enters a return quantity. A different reason and quantity can be specified for each item. Items which are not returnable will not have updateable Quantity or Return Reason fields, and the Returnable column will display No. Note that return reasons can be changed; see the section, "Step 7 - Customize Returns Lookups".

    Note: If a return policy has been implemented, processing constraints set up in Oracle Order Management will determine whether or not the order line can be returned. See the section, "Step 5 - Set up Returns Policy".

  4. The customer selects Next to continue the returns process.

  5. The Create Return: Review and Submit page appears. At this point, the items are in the pending returns queue. Items that already existed in the queue also are pulled into the page. See the "Pending Returns Queue" section, for more information.

    • For quantity of each item, Oracle iStore defaults differently in a single-order flow versus a multiple-order flow:

      Single-order flow --- The application uses the quantity specified by the user in the previous screen. Oracle iStore will only pick up returnable items with a quantity greater than zero.

      Multiple-order flow --- The quantity is defaulted from the original order, and the user can change the quantity.

    • If an identical item from the same order already exists in the Pending Return queue, the quantities are merged, so that the new quantity reflects the additional product(s).

  6. In the Create Return: Review and Submit page, the customer can:

    • Cancel the return order -- This deletes the return order from the data tables, which is different from canceling an order.

    • Change bill to address -- See the "Customers, Contacts, and Addresses Rules and Guidelines" section, below.

    • Add items to the return order.

    • Remove items from the return order; when the last item from a return order is removed, the return order is deleted.

    • View details of the order in which this item was purchased.

    • Change return reasons. Note that return reasons lookups can be changed; see the section, "Step 7 - Customize Returns Lookups".

    • Change quantities -- In this case, the user should press the Recalculate button to recalculate totals.

    • Recalculate the return total, including line total, taxes, and return fees.

    • View related charges -- If applicable, these are return fees as setup by the merchant to return the goods; value is calculated by the Pricing Engine.

    • Enter a return address (order level for B2C and item level for B2B) where the return goods can be picked by the merchant. Note that the ship-from address will be copied from the original order at the line level. For B2C user, Oracle iStore will show all the valid addresses from the address book in a list, and the address selected by the user will be used for all the line items in the return order. B2B users can specify the ship-from address at the item level. The addresses available to the user are the same as in the checkout process (i.e., the user's own addresses and/or organization addresses). If either a B2C and B2B user does not have a valid address, they can create new addresses in the address book and then use those addresses in the returns flow.

    • Submit the return

    • Navigate to other areas of the Customer UI -- When the customer does this, leaving the Create Return: Review and Submit page, the return becomes part of the pending returns queue. He can return to the Returns tab > Pending Returns button to re-access this page.

  7. The customer selects Submit Return to submit the return. Several validations are performed at this stage -- see the section, "Validations Performed in Returns Process".

    See the section, "Returns Functionality With and Without OM Release 11.5.10", for important information about returns functionality.

  8. Oracle iStore displays a confirmation page with the return order number, and sends a confirmation e-mail notification to the user with the relevant return details.

  9. If the merchant has set up returns to require approvals:

    • As the return moves into the approvals stage, its status changes to Pending Internal Approval.

    • Approver(s) receive e-mail notification that a return order has been submitted for approval. If a hierarchy of approvers has been implemented, a notification is sent to the first approver. If the first approver rejects the return, its status changes to Rejected; if he approves it, the next approver in the hierarchy receives the e-mail notification.

    • If any approver rejects the return order, its status remains Rejected.

    • If the return order is approved, its status changes to Booked and it is processed into Oracle Order Management.

Multiple-Order Return Flow

The returns process flow for returning items from multiple orders is as follows:

  1. A customer logs into a site and selects Orders > Returns. The Returns page only displays if the profile option, IBE: Use Returns, is set to Yes. The Returns page displays all existing returns. A B2B user with the IBE_VIEW_RETURN_ORDER permission can see all of his organization's return orders. If he does not have this permission, he can still see his own return orders.

  2. The customer selects the Return Items button. For B2B users, the Return Items buttons only displays if the user has the IBE_CREATE_RETURN permission in his user role.

  3. The Create Return: Search and Select Items page appears. If applicable, this page displays pending returns in addition to the search utility. See the "Pending Returns Queue" section for more information.

In the Create Return: Search and Select Items page, users can search by serial number, part number, or order number. Only exact matches are allowed, and the search utility does not support wildcard characters. The search utility is case-insensitive.

Serial Number Search:

See also: the section, "Step 9 - Verify Inventory Setup for Items with Serial Numbers"

Order Number or Part Number Search:

Note: If a return policy has been implemented, processing constraints set up in Oracle Order Management will determine whether or not the order line can be returned. See the section, "Step 5 - Set up Returns Policy".

  1. The user selects the items to be returned and selects Add to Return. Oracle iStore displays the Create Return: Review and Submit page. See the section, "Single-Order Return Flow", beginning with step 6, for remaining steps in the flow.

Tracking Returns

Customers can track return orders by selecting either of the following after logging into the Customer UI:

Returns Profile Setting and UI Display

If the profile option, IBE: Use Returns is Yes:

Thus, a Mixed Order with lines of both Line Category Code as ORDER and RETURN can be queried and displayed in both Track Orders and Returns subtabs.

If IBE: Use Returns is No or not set, all types of orders/returns will be displayed in the Track Orders subtab.

Note that users will see all orders which have at least one order line.

Rules and Guidelines for Returns

Following are rules and guidelines for Returns functionality. For additional details related to Oracle Order Management, see the Oracle Order Management Implementation Manual.

General Rules and Guidelines

Following are some general rules and guidelines for Returns.

Rules and Guidelines for Items

Following are rules and guidelines for items.

Rules and Guidelines for Returns Page

Following are rules and guidelines for the Returns subtab and pages.

Rules and Guidelines for Users and Organizations

This section contains Returns rules and guidelines specific to users and organizations.

Customers, Contacts, and Addresses Rules and Guidelines

Following are some rules and guidelines surrounding customer information, contact information, and address information with returns:

See also: the section, "Validations Performed in Returns Process"

Note that order level is also known as header level and cart level. And, line level is interchangeable with item level.

Order-Level Address Behavior:

The following is the behavior for addresses at the order level.

Bill-To Address:

Ship-To Address:

Item-Level Address Behavior:

The following is the behavior for addresses at the line level.

B2B users, Bill-To:

B2B users, Ship-To:

B2C users, Bill-To:

B2C users, Ship-To:

Behavior is the same as B2B line-level ship-to behavior.

Note: No users can change the bill-to customer.

Implementing Returns

Set up Oracle iStore's returns functionality according to the steps detailed in this section.

For Oracle Order Management setup information, see the Oracle Order Management documentation.

Following are the steps to enable returns in Oracle iStore:

Step 1 - Set Profile Options

Set the following profile options (see the appendix, Profile Options, for more information on the profile options):

  1. IBE: Use Returns --- Set to Yes to enable the returns functionality.

  2. IBE: Return Orders Transaction Type --- Set to the transaction type you wish returns to be created under (for example, set to the transaction type created in the section, "Step 3 - Set up Transaction Type"). .

  3. IBE: Enable Return Pre-booking Approval --- Set to Yes only under certain conditions described in the "Profile Options" appendix. Otherwise, leave the profile option set to No, which is its default value.

  4. IBE: Enable Return Policy --- Set to Yes only if implementing additional processing constraints for return policies.

  5. Set the Quoting parameter, Default Salesrep, to the default sales representative for sales assistance. See the "Oracle Quoting Integration Parameters" topic in the appendix, Profile Options, for more information.

See the Oracle Order Management Implementation Manual for setup information related to Oracle Order Management.

Step 2 - Verify B2B User Permissions

Verify that the B2B customers who will be submitting returns have the IBE_CREATE_RETURN permission in their user role. Only B2B users with this permission will be able to access the Return Items button in Order Tracker.

To view returns across their organizations, B2B users must have the permission, IBE_VIEW_RETURN_ORDER.

Step 3 - Set up Transaction Type

You may use the following steps as an example setup for Oracle iStore returns transaction type. See the Oracle Order Management Implementation Manual for additional setup information.

Important: For Oracle iStore returns, only set up transaction types using Order Category = Return. Mixed should not be used and will not work.

  1. As Order Management Superuser, navigate to the Transaction Types window and set up a new Order Type with following attributes:

    • Name/Description – iStore RMA (user definable)

    • Order Category – Return

    • Transaction Type Code – Order

    • Workflow Fulfillment Flow/Order Flow -- Depends on whether the returns pre-booking feature is enabled:

      --If the profile, IBE: Enable Returns Pre-Booking Approval, is set to No, use Order Flow - Return with Approval. If this workflow is used, you can enable an approval process, after the return is Booked in Order Management and if an Approval List has been set up.

      --If the profile, IBE: Enable Returns Pre-Booking Approval, is set to Yes, use Order Flow - Return with Submission and Approval.

      See the section, "Returns Functionality With and Without OM Release 11.5.10", for more details on the returns pre-booking approval feature.

    • Sales Document Type – Sales Order

    • Default Transaction Phase – Fulfillment (applicable only if the returns pre-booking feature is enabled)

  2. Associate a price list with the above transaction type if using return fees, multi-currency price lists, and/or Order Management defaulting rules based on price list.

  3. Enter other required/optional information and Save.

  4. Set the Default Return Line Type in the Main tab to a required value. This line type will be used as the line type for all return lines in a return created through Oracle iStore. The error, "Line type Id Is missing" is seen if this setup is not done. This is a mandatory setup.

  5. For this transaction type, navigate to the Assign Line Flows window. In this window, choose the Line Type selected as Default Line Type in the above step and assign a Process Name to it (for example, "Line Flow - Return for Credit Only"). The error, "No workflow has been assigned to this transaction type" is seen if this setup is not done. This is also a mandatory setup.

  6. Document Sequence Assignment --- Assign the RMA Document Sequence on the newly created, iStore RMA, transaction type.

Step 4 - Set up Returns with Approval

Optionally, merchants can set up returns to use an approval mechanism before they are submitted to Oracle Order Management, if they are using at least Release 11.5.10 of Oracle Order Management (see the section, "Returns Functionality With and Without OM Release 11.5.10").

The approvals use standard Oracle Workflow processes and related e-mail notifications owned by Oracle iStore. The e-mail notifications are: Return Order Approval and Return Order Rejection. See the chapter, Integrating Oracle iStore with Oracle Workflow, for details.

By setting up returns with approval, administrators can approve or reject return orders before they are processed in Oracle Order Management. In addition, merchants can specify a hierarchy of approvers.

To set up returns with approval:

  1. Approver List Setup --- Set up a new Approver List with following attributes:

    • List Name/Description – iStore RMA Approvers/iStore RMA Approvers

    • Transaction Type -- iStore RMA

    • Transaction Phase – Fulfillment

  2. Select one role or responsibility that will be responsible for approvals.

Note that this LOV will display all applicable Oracle Workflow roles or Oracle Applications (FND) responsibilities. Selecting a Workflow role will enable all the people attached to that role to get the e-mail. Similarly, the same behavior will occur with an FND responsibility.

Step 5 - Set up Returns Policy

Optionally, set up a returns policy which utilizes Oracle Order Management processing constraints functionality. Processing constraints allow merchants to control changes to sales orders and returns at all stages of the order or line workflows. Processing constraints provide:

See the Oracle Order Management Implementation Manual for additional setup information.

Step 6 - Verify Oracle Inventory Returns Flag

Customers can select an order line to return only if the item is returnable. This is enabled by selecting the Returnable checkbox in the Oracle Inventory form (under Order Management tab). For more information, see the Oracle Inventory User's Guide.

Step 7 - Customize Returns Lookups

Return Reasons and Returns search query values exposed in the UI are Oracle Applications lookups which can be customized to fit your business needs. See the chapter, Implementing Messages and Prompts, for details.

Step 8 - Set up E-Mail Notification Support

Depending upon which version of Oracle Order Management you are using, you may need to perform additional setups for e-mail notifications, including optionally specifying a return location in the notification messages. See the chapter, Integrating Oracle iStore with Oracle Workflow, for more information.

Step 9 - Verify Inventory Setup for Items with Serial Numbers

In the Oracle Inventory Master Items form, for each applicable product, set the Serial Controlled property to one of the following values:

  1. At Receipt

  2. At Sales Order Issue

  3. Predefined

If the serial-controlled flag is not set for an item, in the Create Return: Search and Select Items page, users cannot search by serial number, nor will the Serial Number column show the serial number pop-up icon.

Until the order is shipped to the customer, the serial number search does not return a record in Oracle iStore.

In addition to the above conditions, for proper setup, the serial numbers should have been generated for the order line in Oracle Inventory.

For more information, see the Oracle Inventory User's Guide.

Oracle iStore and Party/Account Merge

Party Merge and Account Merge functionalities are part of the Data Quality Management tools provided by Oracle Trading Community Architecture (TCA). They allow you to identify and resolve duplicates present in the Trading Community registry. Different applications throughout the Oracle E-Business Suite have data associated with both Parties and Customer accounts. Any references to Party and Accounts should be updated when Parties or Accounts are merged. This ensures data integrity across the Oracle E-Business Suite.

This section discusses Oracle iStore's behavior with TCA's concurrent programs which effect Party/Account Merge operations.

For more information on the TCA functionality discussed in this section, see the Oracle Trading Community Architecture Administration Guide.

Party/Account Merge Overview

Party Merge and Account Merge are TCA utilities which merge or transfer party and account data in the trading partner database. There are important differences between the two operations, as discussed in the following sections:

Party Merge

Party Merge eliminates duplicate data in the registry layer in order to keep the trading partner database accurate and clean. It consolidates duplicate parties after they have been entered in the system. The merging enables users to have a single view of each party.

Party Merge can merge information for:

There are two types of operations performed by Party Merge:

Example:

ABC Company has implemented the Oracle E-Business Suite

While checking the quality of its data, ABC Company determines that duplicate records exist for a party, Vision Corporation. Data for this party were entered into the database under the names Vision Corp. and Vision Inc. Using the Party Merge utility, ABC Company plans to merge the two Vision parties -- Vision Corp. and Vision Inc.

Party Merge will:

  1. Inactivate the Vision Corp. party record

  2. Either merge or transfer the details of Vision Corp., e.g., transfer or merge party sites: 500 Oracle Pkwy. and 600 Vision Pkwy.

  3. Transfer party site 500 Vision Pkwy. to Vision Inc.

Customer Account Merge

Customer Account Merge is a tool that merges transactions from one customer account to another customer account. The merging or transferring of these duplicate records allows the consolidation of customer account transactions --- such as orders, invoices and payments --- into one customer account relationship.

Oracle iStore's Behavior with Party/Account Merge

Oracle iStore supports and treats Party/Account Merge in various ways, as discussed in this section.

In Party/Account Merge operations, Oracle iStore's access to party data is accomplished through foreign keys on the data. These are summarized in the section, "Oracle iStore Foreign Keys Used in Party/Account Merge", below.

Shopping Lists

Account Merge updates both the party and account IDs of the merge-from party to point to the merge-to party. Thus, merge-to party, after the account merge, will see additional shopping lists from the merge-from party.

In addition, with Party or Account Merge:

The Oracle iStore foreign key to the party and account layer for shopping lists data is IBE_SH_SHP_LISTS_ALL.

Express Checkout Preferences

In a Party Merge, Express Checkout preferences do not change in the merge-to party.

The Oracle iStore foreign key to the party layer for Express Checkout is IBE_ORD_ONECLICK_ALL.

Site Access Restrictions

In a Party Merge, merge-to settings override merge-from settings for access restrictions. The following table, Site Access Restrictions - Expected Behavior After Party Merge, shows the expected behavior of these preferences after Party Merge.

Site Access Restrictions - Expected Behavior After Party Merge
Preference Merge-from Merge-to Expected Behavior
No restriction On or Off On or Off Merge-to settings take priority and are not changed.
Only the following organizations can access the site On On Additional organizations are added to the merge-to list from the merge-from list.
Only the following organizations can access the site Off On Merge-to settings take priority and are left On.
Only the following organizations can access the site On or Off Off Merge-to settings take priority and are left Off.
The following organizations cannot access the site On On Additional organizations are added to the merge-to list from the merge-from list.
The following organizations cannot access the site Off On Merge-to settings take priority and are left On.
The following organizations cannot access the site On or Off Off Merge-to setting take priority and are left Off.

The Oracle iStore foreign key to the party layer when dealing with site access is: IBE_MSITE_PRTY_ACCSS.

Shared Carts

In Party Merge, Oracle iStore shared carts have the following rules:

In Account Merge, Oracle iStore shared carts follow these rules:

The Oracle iStore foreign key to the party layer for shared carts is IBE_SH_QUOTE_ACCESS.

Active, Default-Named, and System-Saved Carts

In Party or Account Merge, the following is the behavior for active, default-named, and system-saved carts:

Note: Default-named and system-saved carts are carts that are named by the system. See the section, "System-Saved and Default-Named Shopping Carts", for details, for more information.

The Oracle iStore foreign key to the party layer for active carts is IBE_ACTIVE_QUOTES_ALL.

Running Party and Account Merge

By running Party Merge without Account Merge there is the possibility for a party to have two accounts. To avoid multiple accounts to one party, it is recommended to run Account Merge after Party Merge.

See the following sections for examples on how the accounts are treated in the two scenarios:

Party Merge Only Scenario

In the scenario where only Party Merge is run, the following table, Account Numbers in Party Merge Only Scenario, shows what should be expected:

Account Numbers in Party Merge Only Scenario
Merge Party ID Account ID
Before Party Merge    
To 1000 2000
From 1100 1800
After Party Merge    
To 1000 2000
    1800

Party ID 1000 will have two accounts. At login, the system will pick the account created first. In the example above, account 1800 (from system) will be used at logon.

Run Party Merge Then Account Merge Scenario

In the scenario where Account Merge is run immediately after Party Merge, the following table, Account Numbers in Account Merge After Party Merge Scenario, shows what should be expected:

Account Numbers in Account Merge After Party Merge Scenario
Merge Party ID Account ID
Before Party Merge and Account Merge    
To 1000 2000
From 1000 1800
After Party Merge and Account Merge    
To 1000 2000 (1800 merged)

Oracle iStore Foreign Keys Used in Party/Account Merge

The following table, Oracle iStore Foreign Keys Used in Party/Account Merge, shows the foreign keys used in Party/Account Merge.

Oracle iStore Foreign Keys Used in Party/Account Merge
Entity Name Description
IBE_SH_SHP_LISTS_ALL Shopping lists
IBE_ORD_ONECLICK_ALL Express Checkout preferences
IBE_MSITE_PRTY_ACCSS Store access restrictions
IBE_SH_QUOTE_ACCESS Shared carts
IBE_ACTIVE_QUOTES_ALL Active carts

For more information on the TCA functionality discussed in this section, see the Oracle Trading Community Architecture Administration Guide.

Shopping Cart Purge

Oracle iStore shopping carts can be purged to free up space in the underlying iStore and Quoting tables and improve performance for active shopping carts and quotes. For information on purging shopping carts, see the Purging Quotes section in the Oracle Quoting Implementation Guide and Oracle Quoting User Guide.