Schedule: Timing Topic 115 minutes Lecture 245 minutes Practice 360 minutes Total
Features and Benefits Oracle i Store provides merchants with a complete end-to-end solution for building, deploying, and managing online storefronts. These storefronts will give your company access to new customers and new markets around the world, and can be set up for use in both business-to-business (B2B) and business-to-consumer (B2C) scenarios. Either way, i Store allows you to give your customers a dynamic and personalized shopping experience which will keep them returning to your Web site frequently. And because i Store integrates with Oracle’s CRM and ERP product suites, it can be used to give your customers access to business-critical information, such as availability of inventory, order status, shipment information, and more. Instructor Note Other points which can be covered if time permits: Robust, scaleable architecture: Built on the industry standard Oracle8 database Customizable look and feel: Supports company branding Configurable product support Sales processes across multiple channels Globalization: Currency, language Special interest stores Notifications
Performing This Practice For detailed instructions, see Practice 5-1 in Appendix D, “Practices and Solutions.”
Performing This Practice For detailed instructions, see Practice 5-2 in Appendix D, “Practices and Solutions.”
Performing This Practice For detailed instructions, see Practice 5-3 in Appendix D, “Practices and Solutions.”
Performing This Practice For detailed instructions, see Practice 5-4 in Appendix D, “Practices and Solutions.”
Performing This Practice For detailed instructions, see Practice 5-5 in Appendix D, “Practices and Solutions.”
Performing This Practice For detailed instructions, see Practice 5-6 in Appendix D, “Practices and Solutions.”
Performing This Practice For detailed instructions, see Practice 5-7 in Appendix D, “Practices and Solutions.”
Product Catalog and Navigation: Cataloging Products This section deals with how i Store imports, organizes, and displays products. Product items are loaded into Inventory and made available to the i Store administrator on the basis of a publish flag set in Inventory. The administrator then has the task of organizing the catalog and preparing it for display. Catalog Organization The three major components of the i Store hierarchy are: The product item, or the leaf in the organizational tree The section or grouping of product items or sections. There is also a special kind of section, known as a featured section, which consists only of product items. The specialty store, which is a view of the catalog. There can be multiple specialty stores or views of the same catalog for different customers. Note: The section is different from the category as defined in Inventory. These two terms cannot be used interchangeably. While a product item can belong to only one category in Inventory, it can belong to multiple i Store sections.
Product Catalog and Navigation: Catalog Display A product can be displayed in multiple ways depending on its location in the product catalog. For example, the same product may need to be displayed in one way in section A and another way in section B. Therefore, every node in the catalog that has products to display specifies a display context to be used by the products under that given section. A display style, or a logical template, is used to vary the appearance of the product, because it can be associated with a product at a specialty store, section, or product level. This enables the merchant to display products very differently. For example, when displaying the products for a selected section, some featured products will be displayed as blocks, but the others will be displayed as line items depending on the display style associated with the product or section. A default style should be associated with the entire store and set in the profile options.
Product Catalog and Navigation: Display Styles A style is nothing but a JSP template that has a logical name and certain parameters that characterize it. Each style sheet ultimately maps to a file that contains the actual presentation instructions. Notice that so far, mention has been made of logical templates, not physical templates. Logical templates are handles that point to physical template files, depending on the language and specialty store used. Resolution rules are used at run time to identify the logical and physical templates that will be used for display.
Product Catalog and Navigation: Search i Store uses the interMedia search engine, which is a part of the Oracle 8.1.6 platform. The customer can search based on the name and description of products. Because i Store runs off the inventory tables, Search uses the description and long description columns of the MTL_SYSTEM_ITEMS_T1 table. Once the inventory has been set up, the concurrent program called ibevcsmv.sql must be run to populate the table which contains the searchable data. If the merchant wants to enable searching on additional criteria, the concurrent program must be modified to add the relevant columns and run again. To keep the search data current, the concurrent program must be run at frequent intervals.
What Is Catalog Search in i Store 11 i ? Ability to find products in Inventory Customer UI, not Merchant UI Components Intermedia, Inventory, OEM Web Status flag What Can You Search On? Name, description of products Stored in MTL_SYSTEM_ITEMS_TL Web status = ENABLED Available in minisite Stored as CLOB, extensible Instructor Note i Store section-level search functionality may be available in later releases. Check the latest version of the Oracle iStore and Oracle iMarketing Implementation Guide on MetaLink for implementation guidelines.
Performing This Practice For detailed instructions, see Practice 5-8 in Appendix D, “Practices and Solutions.”
Customer Account Management The term “customer” refers to the end user of i Store. A customer may be a person who has registered with the store (account customer) or a person who has literally walked into the store (walk-in or anonymous customer). i Store “recognizes” returning account customers by using cookies. Most e-commerce sites encourage customers to register because this increases the probability that they will return to the site.
Customer Account Management The customer account functionality uses the common customer model of the trading community architecture. Whereas registered customers have their own accounts, anonymous users are automatically assigned to a common account. The customer model comprises six major subject areas: Party: Defined as people, organizations, groups, or relationships Account: Defined as a financial roll-up point Contact point: Defined as any electronic point that you could use as a contact, such as telephones, URLs, e-mail addresses, and so on Location: A physical place Relationship: Establishes the relationship between any two parties Participation: Describes the interaction of a party with other parties, including internal organizations
Customer Account Management CRM Foundation manages customer accounts. Using the login name, password, e-mail address, and account type, an account is created. There are only two types of accounts: B2C: Users are granted a default role that allows them to access the entire store functionality. B2B: Users are granted a default role, defined by merchant, and restricted to certain operations until the merchant reviews and approves the account. For example, they may browse and add items to the shopping cart, but may not check out until the account is approved. With respect to B2B users, the concept of party must be explained. A party can be a person, a group of persons, or an organization. Relationships exist between parties such that party A can be a representative of party B. Seen in this light, a B2B account may be a corporate account that can further be associated into accounts belonging to multiple individuals, each with his or her own login and password. A person ordering something from a corporate account is actually ordering on behalf of the corporation.
Customer Account Management: Merchant Approval Merchant approval is a process in which the merchant can review and verify users’ information and set up accounts. The merchant can choose to approve or to decline an application at any point during the process. If approved, the new user is associated with the company and accounts, with either an administrator role or a user role as chosen by the merchant. If declined, the user is removed from the registration pool.
Customer Account Management: Customer Profile The following information is associated with the customer profile. Password and password hint: These are set when the customer registers and can be updated later. i Store performs these functions using APIs exposed by the CRM foundation. Billing and shipping address: The user can have multiple billing and shipping addresses, each associated with a nickname. A B2B user can choose to update both addresses associated with his or her persona and addresses associated with the B2B account. Primary billing and shipping addresses are identified for the purpose of one-click checkout. Payment information: A primary payment method is associated with the customer’s account. For this purpose, a list of payment methods are provided from i Payment. Information about payment instruments is also stored associated with the account. A primary payment instrument is also chosen for one-click shopping. Shipping method: A primary shipping method is associated with the account and is used for one-click shopping. The list of shipping methods is imported from Oracle Shipping. E-mail address: The customer can set and update this information. Because much of this information is of a sensitive nature, the user needs to be authenticated before he or she can access it. The distinction between sensitive information and public information can be made at the JSP level, where a directive requiring authentication can be inserted. Once the user is authenticated, he or she is allowed to access other sensitive pages.
Customer Account Management: Cookies Cookies are used to recognize returning customers and are of two types: Browser cookie: Sits on the customer’s machine URL cookie: Is generated by i Store on login and relayed in the URL from page to page In either case, the cookie is used by i Store to identify the user and relay other frequently needed information in the form of name-value pairs. Under the following circumstances, however, a returning user cannot be identified: (For URL cookie) The customer arrives at an i Store page from an external site (For URL cookie) The page times out (For browser cookie) The browser does not carry cookies (For browser cookie) The cookie expires As mentioned earlier, all anonymous customers share the same customer account. In such a case, how does the site differentiate among multiple anonymous users using the site? As long as the anonymous customer is only browsing the site, he or she does not need any special identifier. However, once he or she adds something to a cart, the cart ID is loaded into the cookie and will become the distinguishing factor between two anonymous customers. The main disadvantage with using cookies is that they may become invalid at any time. For example, once an account is deleted, the cookie associated with that account will become invalid. Therefore, before an item of information stored in the cookie is used, a validation check is conducted.
Available to Promise (ATP) i Store will allow merchants to set up a specialty store–specific default Inventory lookup mechanism that can be set to look up either locally or in real time, and either in Inventory itself or using i Store templates. An Available to Promise (ATP) API is provided by Inventory and used by i Store at the time of checkout. i Store can keep a count of local inventory. The local inventory will include watermark levels and will be updateable at regular intervals by a scheduled concurrent manager program in the ERP applications. This concurrent manager program will calculate product availability against the actual inventory and update the local inventory numbers. Alternatively, i Store can keep track of shipability days for products (“Product usually ships in X days”). This approach is used by Amazon.com and other e-commerce stores. Note that the product is not reserved in real time. This may be an issue for clients who sell one-of-a-kind items such as art or refurbished goods.
Practice 5-9 Performing This Practice For detailed instructions, see Practice 5-9 in Appendix D, “Practices and Solutions.”
Order Management Order Management deals with all the processes and functions that relate to the actual buying process. For example, when an item is added to the shopping cart, a quote is created or modified in Order Capture. Order Capture makes a call to the pricing engine using the contents of the shopping cart as qualifiers and receives the list of offers from the pricing engine. The quote is priced using these modifiers. The contents of the shopping cart can be used by TeleSales to generate leads.
Order Management: Checkout This process deals with converting the contents of the shopping cart into an order. The following information is processed during checkout: Customer’s Account Type The customer is required to login or register before continuing with the checkout process. Shipping and Billing Addresses In i Store 11 i , multiple billing and shipping addresses can be applied to an order. Further, multiple billing and shipping addresses can be applied to a single line item. i Store also keeps track of addresses used with previous orders, forming an address book from which the customer can easily select frequently used addresses. These addresses are pulled from Accounts Receivable. The addresses entered by the customer are verified through Order Capture. The customer is asked to correct any errors in the addresses.
i Store Integration Points: CRM and ERP 1. i Store–Inventory : Inventory schemas are used to store items and create product categories. Those items will be pulled into the i Store’s Merchant UI to publish them on a speciality store and display them in the catalog. 2. i Store– i Marketing : i Store exposes certain APIs to i Marketing about relationships between products. For example, the cross-sell relationship between two products is available to i Marketing in this way. In 11 i , i Store and i Marketing are tightly coupled. Advertisements, recommendations, and other personalized content are made available to i Store from i Marketing. To be able to push a marketing campaign through the store those campaigns and their offer codes (discounts) need to be set up in Marketing Online. 3. i Store–Pricing : All pricing-related information displayed on the catalog is derived using Pricing APIs. 4. i Store–EcFoundation : Roles and privileges are created using EcFoundation. For example, i Store uses JTF APIs to perform user registration. The customer data will be pushed to TCA through JTFs integration with Accounts Receivables. i Store–Configurator : An API is used to integrate i Store and Configurator on the shopping cart. 6. i Store - A/R: When a user views the status of his or her order in the “order tracker” functionality, invoices as well as payments are pulled directly from A/R. 7. i Store - Oracle Shipping: Shipping methods (shown on the checkout pages) are configured in Oracle Shipping. 8. i Store - Order Capture: Orders are placed through Order Capture. i Store also uses Order Capture’s integration to various other modules for functionality used on the shopping cart. When a shopping cart is saved, a quote is created in the Order Capture schema. The quote can be viewed through Order Capture in any CRM application that has an integration point to Order Capture (Oracle Telesales, CallCenter, Contracts). 9. i Store - Order Capture - Order Management: . Orders are sent from i Store to Order Capture to Order Management for fulfillment. Payment authorization for an order can be done online (see above integration with i Payment) or offline after the order is sent to Order Management for fulfillment (by integration of i Payment into A/R). 10. i Store - Order Capture - A/R: Tax calculation is done using A/R APIs through Order Capture. 11. i Store - Order Capture - Shipping: Shipping fulfillment related processing is done using Shipping APIs through Order Capture. 12. i Store - Order Capture – i Payment: Connection to i Payment for credit card authorization is done using Order Capture itself or using APIs exposed by it. In other words, unlike in version 3 i , there is no direct connection to i Payment. 13. i Store - Order Caputre - MRP: ATP inventory check is performed using MRP’s APIs through Order Capture. 14. i Store - Price Engine: i Marketing writes offers to the price engine. i Store accesses these offers by sending known information about the customer to the price engine.
Integration Architecture Messaging interfaces replace interface tables that were used in 3 i . The need to push and pull data is no longer there. With the shared schema, you access these tables directly.
i Store Dependencies: Mandatory Oracle i Store leverages other Oracle Applications modules to provide extended functionality. The mandatory modules must be set up before i Store can run.
i Store ERP Dependencies: Optional i Store is natively integrated to Oracle ERP and CRM applications; they share the same business objects and schemas. Consulting services are available to enhance the following: Sales functionality Shipping and handling charges calculations Defining product relationships and categories (information presentation structure) Setting up the optional modules is not required; however, if they are not set up, then the additional functionality provided by these modules will not be available.
Configurator Integration A product item may be identified as configurable or not based on whether it has a bill of materials associated with it of the type known as “Model.” If it does, then a Configure button will appear alongside it. On clicking the button, control is transferred to the Configurator user interface so that the customer can configure the product. After this, control is transferred back to i Store.
Performing This Practice For detailed instructions, see Practice 5-10 in Appendix D, “Practices and Solutions.”
Practice 5-11 Refer to Practice 5-11 in the Practices chapter.
Note Also see the Oracle Order Management User’s Guide and the Oracle Accounts Receivable User’s Guide for additional setups required for i Payment.
Performing This Practice For detailed instructions, see Practice 5-12 in Appendix D, “Practices and Solutions.”
i Store Partners and Third-Party Products Oracle has developed strategic partnerships with third-party development companies in order to provide its customers with a complete, end-to-end e-commerce solution. Partners vary by product. Note that taxation in 11 i is done through Accounts Receivable (AR), which in turn integrates with Taxware/Vertex. Similarly, shipping is integrated through Order Capture and Oracle Shipping. Net Perceptions is not shipped with the product, but Oracle does provide the integration hooks.
Integration Points Authoring Module: Module that initiates the integration scenario Receiving Module: Module that receives data in the integration scenario Integration Method: Method used to achieve integration: API, read/update of common schema, and so forth APIs are used at the middleware level. JSPs are used at deeper-than-middleware level. Instructor Note Don’t spend a great deal of time going through the detail of the next few slides. Simply highlight the i Store integrations and indicate that participants may want to review this information for the activities.
Performing This Practice For detailed instructions, see Practice 5-13 in Appendix D, “Practices and Solutions.”