Cloud Readiness / Oracle CX Commerce
What's New
Expand All


  1. UPDATE 20A WEEK 12
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Search Admin
        1. Dynamic Content
        2. Site-Specific Rules
    2. Catalog
        1. Price Group Inheritance
  1. UPDATE 20A WEEK 11
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Loyalty
        1. Pay an Order with Points and Currency (API Only)
    2. Integrations
        1. Cancel In-Flight Order
        2. Shipping Group Assignment
  1. UPDATE 20A WEEK 10
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Integrations
        1. Calculate Tax Refunds Based on Date of Original Order
  1. UPDATE 20A WEEK 9
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Audiences
        1. Behavorial Audiences: Current Session Page Views
  1. UPDATE 20A WEEK 8
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Wish Lists
        1. Support for /ccstore Context Root
  1. UPDATE 20A WEEK 4
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Extensibility
        1. Item Back in Stock Event Webhook
  1. Update 20A
  1. Revision History
  2. Overview
  3. Feature Summary
    1. Payments
        1. Additional Properties for Payment Webhook Requests
    2. Reporting
        1. Near Real-Time Dashboard
    3. Integrations
        1. Telco/Services: Direct Configuration (Bypass Iframe) API Only
        2. Telco/Services: Upgrade Assets
        3. Telco/Services: Direct Configuration (Bypass iFrame) Asset Operations (API Only)
    4. Catalog
        1. Catalog Export – Improved Filtering
        2. Dynamic Properties on Collections (API Only)
    5. Inventory
        1. Search for a SKU Within Inventory
    6. Storefront
        1. Shopper Profile Registration Completion with Secure Email Link

Update 20A Week 12

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
07 MAY 2020 Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20A Week 12 (20.1.12) in the body or title of the email.

Feature Summary

Column Definitions:

Features Delivered Enabled

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Features Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Action is Needed BEFORE Use by End Users
(Features Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

Search Admin

Dynamic Content

Site-Specific Rules

Catalog

Price Group Inheritance

Search Admin

Dynamic Content

Dynamic Content allows merchants to display relevant content based on shopper behavior (via navigation location and search), allowing merchants to capture and focus the shopper’s attention, convey a message specific to shopper intent, and direct the shopper to a desired location.

For example, a merchant may want to display collection-specific seasonal images on collection pages, or may want shoppers who search for a trending product to see a banner inviting them to go to a landing page featuring the latest promotional deals.

Capability highlights:

  • Display an image from the Media Library along with the product listing when the shopper enters specific search terms or navigates to a specific collection page
  • Display promotional images targeted to specific searches or collections
  • Make the image a clickable link taking the shopper to a relevant landing page
  • Preview the results of your rule

To use the feature, two key steps must be completed. One is to create a Dynamic Content rule. The other is to create a custom widget to display the content and place the widget on the Search Results and/or Collection layouts – including the Agent layout.

A Dynamic Content rule applies to a collection page regardless of whether the page is driven from the catalog or from search. As with other rules in the Search area, a Dynamic Content rule takes effect in Production after the next publish occurs.

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

The feature supports one image per rule and the same image will be displayed regardless of locale. Different images for different locales are not currently supported.

Site-Specific Rules

New in Search Administration is the ability to create site-specific rules.  This feature allows the merchant to tailor the results for a given search term or collection to meet different requirements on different sites.

Capability highlights:

  • Create a Dynamic Curation, Facet Ordering, or Dynamic Content rule that applies to one or more specific sites.
  • Use rule editor to select one more sites, or select “Global.”
    • By default, a rule is global (applies to all sites).
  • Tailor the results for a given search term or collection to meet different requirements on different sites.
  • Define a rule for all destinations on a specific site.
  • Filter each list view by site.
  • See when and by whom a rule was last edited.

The key benefit of this feature is that it allows merchants to refine their product listings to support the business goals of specific sites. The feature addresses situations where, for example, different sites have different sales goals, marketing approaches, or target audiences.

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

You cannot preview a site-specific rule with one click from Search Admin. To preview a site-specific rule, use the Preview button on the toolbar to preview by the desired site and enter the search term or navigate to the collection.

Catalog

Price Group Inheritance

Merchants can now define specific prices for particular products and SKUs, while the rest of the prices are inherited from its parent price list group. This allows them to define the relationship between price list groups and customer-specific prices at the child price list level, as well as define price list groups that are applicable for a specific purpose (e.g. pricing for select promotional products, special pricing for a particular customer or multiple accounts). Not only does this provide increased flexibility and targeting, but it helps improve maintenance and management of price list groups.

This feature is useful in a number of instances, for example, where:

  1.  A merchant has negotiated special pricing for a subset of products in a price group to accommodate a particular B2B customer account (or multiple accounts) and wants that special pricing to override the default pricing. The products with negotiated prices can be defined in a new child price list and associated to the base price list, eliminating the need to define prices for every customer separately.
  1. Regional sites need to have pricing of select items be different from their parent. This new feature allows special child price list groups to be created that still keep the parent relationship with the base price list group.
  1. A merchant wants to define a price list group that has prices applicable only for a select group of promotional products during a promotion period. This can now be done by defining a child price list group and associating it to the parent. Once the promotion is over, the merchant can remove the associated child price list group.

With the release of the Price Group Inheritance feature, changes can be done directly in the new price group, resulting in faster pricing calls, faster publishing and search, and improved performance.

This feature is applicable for both consumer-based (B2C) and account-based environments (B2B).

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

Time-based pricing, defining the effective dates for Price List Groups, is not yet available. Merchants should track the dates manually and assign to Price List Groups accordingly.

Update 20A Week 11

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
30 APR 2020   Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20A Week 11 (20.1.11) in the body or title of the email.

Feature Summary

Column Definitions:

Features Delivered Enabled

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Features Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Action is Needed BEFORE Use by End Users
(Features Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

Loyalty

Pay an Order with Points and Currency (API Only)

Integrations

Cancel In-Flight Order

Shipping Group Assignment

Loyalty

Pay an Order with Points and Currency (API Only)

With the latest release, merchants using our generic loyalty framework may now offer product redemption in loyalty points (points as a pricelist group) with payment for the full order in points or a mix of points and monetary currency. This allows shoppers to pay in a mix of loyalty points and currency or monetary currency by itself, so that they do not have to limit what they buy based solely on their available points. Loyalty shopper cards can also now be used.

Merchants may launch a separate site to offer products to be sold in points only, with taxes and shipping payment separated by points or currency.

Capability Highlights:

  • Allows the shopper to pay for an order with loyalty points and currency.
  • An order can be priced in points or currency.
  • Shipping and taxes can be handled separately.
  • Enables integration with payment gateways and loyalty engines in parallel.

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

The feature is available to everyone. There is a requirement for the merchant to integrate with a loyalty engine. This is an API only feature with no out-of-the-box widgets included.

Tips And Considerations

  • The configuration to offer mix of points and currency is at a site level. 
  • Products cannot be offered in a mix of points and currency. The price remains in one currency.

Integrations

Cancel In-Flight Order

With this release, CX Commerce provides functionality that allows the shoppers to initiate cancellations, returns or exchanges on orders placed through their account. This feature builds on the previously introduced concept of cancel in-flight, the process of cancelling an order after it has been submitted to fulfilment.

Capability Highlights:

  • Cancels orders when items have passed the ‘point of no return’ in fulfillment.
  • Automatically generates return requests and service terminations.
  • Executes cancel/return/terminate as required for each element of a configured item.

In the Admin settings, merchants can enable the Extended Remorse Period, specifying the number of days from the date of submission during which orders can be cancelled. Unlike with Remorse Period, there will be no delay in the order process and orders will be sent to fulfillment immediately on submission.

Within the extended remorse period, shoppers can choose to cancel the order and the system will automatically evaluate:

  • Goods and services within the order that can be cancelled by passing the instruction downstream. These are items that have not passed the point of no return in the fulfillment process.
  • Goods that must be returned and refunded
  • Goods that must be refunded
  • Upfront payment for services that must be refunded
  • Services that have already been installed (fulfillment complete) that must be terminated

Merchants can have both Remorse Period and Extended Remorse Period enabled. For example, if a merchant knows that order cancellations occur within 6 hours of confirmation, the merchant can implement a 6-hour remorse period and a 30-day extended remorse period.  This would ensure that the order will not actually be submitted to fulfillment for 6 hours enabling a simple cancel operation for most cancelled orders and the more complex cancel in-flight operation may only be required in a small number of cases.

Steps to Enable

To implement this feature merchants will be required to download and install some new and some updated Server Side Extensions:

  • New - Terminate Order App
  • New - Terminate Order Lib
  • Update - Validate Cancel App - Store (provided as part of phase 1)
  • Update - Validate Cancel App - Agent (provided as part of phase 1)
  • Update - Validate Cancel Lib
  • Update - Order Qualification Pipeline

Additionally, to implement, merchants can use the pre-built Order Details Cancel widget.

Shipping Group Assignment

With this release, when a shopper purchases a non-shippable item such as a download or warranty, the item will now automatically be assigned to a virtual shipping group thereby ensuring no shipping charges are applied to the purchase at checkout time.  This new feature provides for a flexible structure for selling services, allowing merchants to decide how and when shoppers pay for shipping for physical items.

The ability to assign items to the virtual shipping group and assign each item in a configuration hierarchy to a shipping group enables CX Commerce to implement the new ‘Cancel In-flight Order’ feature.

Capability Highlights:

  • Automatically assign items to the correct shipping group
    • For example, a merchant selling communications bundles may choose to incorporate the cost of shipping a handset or router in the overall monthly charge.
  • Sell configured items as a package
    • When a shopper purchases a configured item that is ‘sold as package’ this means that the item will be purchased, shipped, returned and exchanged as a single item.
  • Assign shipping groups to sub-items.
    • For example, when a shopper purchases a telecommunications multi-play bundle, separate shipping groups may be required:
      • Handset (office – priority mail)
      • Router (home – standard mail)
      • Set top box (vacation house – standard mail)

The adjustments to tax calculation and shipping charge calculations work out-of-the-box.

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

To implement the assignment of shipping groups at the sub item level, customers will be required to build their own ‘Shipping Options Sub-item Widget.’

Update 20A Week 10

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
20 APR 2020 Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20A Week 10 (20.1.10) in the body or title of the email.

Feature Summary

Column Definitions:

Features Delivered Enabled

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Features Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Action is Needed BEFORE Use by End Users
(Features Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

Integrations

Calculate Tax Refunds Based on Date of Original Order

Integrations

Calculate Tax Refunds Based on Date of Original Order

This feature is used to calculate tax refund amounts for returns and exchanges using the order submit date instead of the current date. Tax refund amounts can now be calculated more accurately based on the actual tax rate charged for an item. The date of the original order can be used to calculate tax refunds for returns and exchanges. This ensures that the tax refund amount corresponds to the actual tax amount charged instead of a potentially different current rate.

A new merchant setting – useOrderSubmittedDateForTax – has been introduced to control this behavior.

  1. The setting is enabled for new customer implementations and disabled by default for existing customers. 
  2. The setting applies to all sites.
  3. The setting can be updated using the Admin merchantSettings endpoint.
  4. The setting affects tax calculation for out-of-the-box Avalara and Vertex integrations as well as custom tax integrations implemented using the External Tax Webhook.

For example:

An order is placed on June 15 for $100.00 with $5.00 in tax (5% tax).

The order is then returned on July 4 which happens to be a tax-free holiday.

  • If useOrder SubmittedDateForTax is enabled, then $5.00 in tax will be refunded.
  • If useOrderSubmittedDateForTax is disabled, then $0 for tax will be refunded since July 4 is a tax-free day.

When useOrderSubmittedDateForTax setting is enabled, the native Avalara and Vertex integrations will ensure that the original submit date is sent to the tax processors and the tax rate on the submit date is used to calculate refund amounts.

Custom tax integrations implemented using the External Tax Webhook must check the value of the property in the request payload and calculate tax accordingly. 

Steps to Enable

New customer implementations will default to using the date of the original order for tax refund calculations rather than the current date. Existing customers must enable the useOrderSubmittedDateForTax setting using the Admin merchantSettings endpoint.

Update 20A Week 9

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
10 APR 2020 Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20A Week 9 (20.1.9) in the body or title of the email.

Feature Summary

Column Definitions:

Features Delivered Enabled

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Features Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Action is Needed BEFORE Use by End Users
(Features Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

Audiences

Behavorial Audiences: Current Session Page Views

Audiences

Behavorial Audiences: Current Session Page Views

With this release, powerful new Behavioral Audience rules can now be used to drive improved personalized experiences for shoppers. Merchants can build audience rules based on a shopper’s current session page views to collection or product pages and combine those with other criteria. This is useful for providing a more contextual experience for shoppers in terms of the content, promotions, and tests they see, as well as contributing to driving increased conversions and sales.

Behavioral Audiences are an important part of Commerce personalization strategies and while they are powerful on their own, they are even more effective when used in conjunction with the other audience and personalization capabilities available in CX Commerce.

We currently support product and collection page views from a shopper’s current session and specifically the following behavioral audience types:

  • Collection name (e.g. Collection name contains “Men's”)
  • Product name (e.g. Product Name starts with “Running”)
  • Collection page (e.g. Collection is “Accessories”)
  • Product page (e.g. Product is “Trail Men's Running Shorts”)
  • Product criteria (e.g. x products in “[camera brand name]”, “Cameras” collection, and “Camera” product type)

Examples of how you can use Behavioral Audiences effectively:

  1. Create a rule that shows products a shopper has shown clear interest in (e.g. viewed a specific product page over three times in the current session) and show in a different part of the shopping experience (e.g. cart page).
  2. Highlight a specific brand on a collection page when a shopper has shown clear brand preference (e.g. viewed three or more products in a specific brand) or, going even further, offer a promotion or highlight items on sale from a particular brand where a shopper has shown clear brand preference.
  3. Promote a specific collection or merchandise particular products based on a shopper showing interest in a particular one.
  4. Present targeted content, offer, bundle, or promotion on products a shopper has shown clear interest in based on product criteria (e.g. viewed four or more products in a bestselling camera brand, the "Cameras" collection, and “camera” product type.

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

NOTE: Only product and collection page views from the current session are currently supported.

Update 20A Week 8

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
03 APR 2020   Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20A Week 8 (20.1.8) in the body or title of the email.

Feature Summary

Column Definitions:

Features Delivered Enabled

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Features Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Action is Needed BEFORE Use by End Users
(Features Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

Wish Lists

Support for /ccstore Context Root

Wish Lists

Support for /ccstore Context Root

Previously, wish lists only supported /ccstoreui API. We now support /ccstore context root, particularly useful for implementing CX Commerce wish lists using a headless approach where our out-of-the-box Storefront is not the client. When a JWT token created by the /ccstore REST API is sent to the wish list (SWM) server, verification will be successful.

Steps to Enable

You don't need to do anything to enable this feature.

Update 20A Week 4

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
11 MAR 2020   Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20A Week 4 (20.1.4) in the body or title of the email.

Feature Summary

Column Definitions:

Features Delivered Enabled

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Features Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Action is Needed BEFORE Use by End Users
(Features Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

Extensibility

Item Back in Stock Event Webhook

Extensibility

Item Back in Stock Event Webhook

Back in stock notifications were previously available, but now, merchants can leverage our new Item Back in Stock event webhook to customize their website when notifying shoppers that an item they are interested in has come back into stock. This webhook allows the back in stock notification to be sent by an external system.

Merchants would first customize their storefront to allow shoppers to opt in to a notification when an out of stock item comes back into stock (e.g. updating the product detail page with an email capture box and a message, such as “notify me when this item comes back into stock”). This list of subscriptions can be tracked externally — through an email service provider, for example, or whatever system owns subscription preferences.

Merchants would then enable and listen for Item Back in Stock events. Each event will contain a list of items that have come back into stock. Merchants can then cross reference the list of items that are back in stock with the list of subscriptions, and notify shoppers using email, text, or another method of choice. Sending the notification would be a customization using external systems.

The Item Back in Stock event webhook fires whenever a previously out of stock item comes “back into stock.” An item is “back in stock” when inventory is added using admin UI, admin inventory API, csv import, or bulk import.

To implement this feature, merchants can notify shoppers when items are back in stock by:

  • Customizing the storefront to allow shoppers to choose “notify me when this item comes back into stock”.
  • Tracking the list of subscriptions externally.
  • Listening for the Item Back in Stock event webhook.
  • Implementing a service to notify subscribed shoppers when their item of interest is back in stock.

Steps to Enable

The new webhook can be enabled in the Oracle CX Commerce Admin and the end to end process developed as a customization.

Tips And Considerations

NOTE: This feature provides the webhook only, so that a back in stock notification can be sent by an external system. Does not include the user experience for shoppers to opt in to notifications, ability to track the list of shopper subscriptions,  or the ability to send the email itself.

Update 20A

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Feature Notes
11 FEB 2020 Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in Oracle CX Commerce 20A Update and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at oracle_fusion_applications_help_ww_grp@oracle.com. Please indicate you are inquiring or providing feedback regarding the Oracle CX Commerce What’s New for 20A Update in the body or title of the email.

Feature Summary

Column Definitions:

Features Delivered Enabled

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Features Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Action is Needed BEFORE Use by End Users
(Features Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

Payments

Additional Properties for Payment Webhook Requests

Reporting

Near Real-Time Dashboard

Integrations

Telco/Services: Direct Configuration (Bypass Iframe) API Only

Telco/Services: Upgrade Assets

Telco/Services: Direct Configuration (Bypass iFrame) Asset Operations (API Only)

Catalog

Catalog Export – Improved Filtering

Dynamic Properties on Collections (API Only)

Inventory

Search for a SKU Within Inventory

Storefront

Shopper Profile Registration Completion with Secure Email Link

Payments

Additional Properties for Payment Webhook Requests

Additional properties are now included in payment webhook requests. This helps with improved robustness of integrated payment fraud solutions and enhanced capability in support of the Payment Service Directive 2 (PSD 2).

The Credit Card Payment and Generic Payment webhook requests have been extended to include:

  • The full order, including item numbers, item descriptions, quantities, prices, currency, custom properties 
  • Shopper information, including shopper profile properties, such as custom profile properties, shopper authentication method, registration date, modification date, password change date

The added information is commonly used to perform risk assessment. The service that receives the webhook request can use this information or pass it to external services. For example, it is common to integrate payment fraud detection services into the payment authorization flow. When the webhook service receives the payment authorization request, it can forward this request to a payment fraud detection service prior to requesting authorization. The additional data can now be used by the fraud detection service to assess risk.

Similarly, the information can be used to enhance PSD 2 user experience. The PSD 2 standard – in effect in Europe and other places around the world, requires strong customer authentication which is achieved using 3DS authentication. PSD 2 attempts to improve user experience by identifying low risk orders and allowing the shopper to complete the order without additional authentication. Many payment providers recommend sending extended data about the order, such as the contents of the order and shopper information. Payment Providers use this information to assess risk and determine whether to prompt the shopper for additional authentication. The additional information improves the robustness of this risk assessment and improves the likelihood of “frictionless flow.”

Steps to Enable

This feature is enabled using a new payment gateway extension property. The ability to include the full order is enabled by setting the flag on the payment extension. Upload the modified payment extension for the change to take effect.

Tips And Considerations

NOTE: Enable this option only if you need the additional information, as it increases the size of the payload and could affect performance.

Reporting

Near Real-Time Dashboard

The reporting homepage is now based upon data updated in near real time, enabling merchants to:

  • Review key sales and traffic figures from the last twenty four hours, broken down by hour
  • Review product and promotion sales performance from the last twenty four hours
  • Refresh the data for the homepage report from a settings menu option

This feature is especially useful for reviewing performance of a promotion or sales and orders in conjunction with other marketing and merchandising events that require more-real-time analysis, and quick response adjustments and optimizations to a campaign.

Reporting Dashboard

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

NOTE: Only the homepage of reporting is based on real-time data.  All other sections of reporting continue to be based on data that is updated daily.

Integrations

Telco/Services: Direct Configuration (Bypass Iframe) API Only

Shoppers can now configure complex customizable products seamlessly in Oracle CX Commerce without being redirected to an Oracle CPQ hosted iframe.

For Oracle CX Commerce customers using Oracle CPQ and selling configurable products, this new feature allows merchants to implement a direct API configuration using new Storefront and Agent endpoints and removes the need to include an iframe in the shopper flow, thereby improving the overall user experience.

By creating ‘Configure’ and ‘Reconfigure’ UI elements, merchants can deliver a seamless, consistent user experience even when customizing complex products or services. The Configuration UI experience is derived from existing themes and styles. And merchants can customize the UI experience by adding their own UI controls.

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

  1. Download and install Server-Side Extensions
  • New - CpqConfiguratorStoreApp
  • New - CpqConfiguratorAgentApp
  1. Create any necessary UI elements
  • Create UI ‘Configure’ element which can be dropped on to the PDP widget, which is elementized.
  • Create UI ‘Reconfigure’ element which can be coded into the cart widget, which is not elementized.

Full guidance on implementing the Direct API Configuration feature will be included as part of the 20A Help docs and an updated version of the integratingOracleCommerceCloudandOracleCPQCloud.pdf  in the Oracle Support Document 2214316.1 (Integrating Oracle Commerce Cloud Service and CPQ Cloud Service) MOS article will also be published.

Tips And Considerations

NOTE: Current feature is API only and requires the merchant to build their own UI elements to invoke the new endpoints.

Telco/Services: Upgrade Assets

For Oracle CX Commerce customers using Oracle CPQ (or another asset master system), merchants can now define and display all of the available upgrade options for any existing service.

Shoppers can take advantage of the upgrade and check out, as well as be alerted to and prompted about upgrades as soon as they are available. Upgrades can be pushed out to customers right away and the upgraded asset is ready to be added to the cart with a single click.

This feature is especially useful in presenting better upgrade options for customers and getting those in front of them in the shopper experience in a more effective way. And it makes it easier for shoppers to take advantage of those upgrades as well.

Steps to Enable

  1. Create the upgrade table in CPQ.
  2. Update Layouts
  • Assets Layout - Upgrade
  • Asset Details Layout - Upgrade
  1. Update Widgets
  • Update - Asset List
  • Update - Asset Details
  1. Download and install Server-Side Extensions
  • Updated version of - Services-store
  • Updated version of - Services-agent
  • New - Services-products-lib
  • New - Services-actions-access-checker
  • New - cpq-assets-punchin-url-lib
  1. Implement OIC Flows
  • New- OCC_CPQ_Get_Asset_Upgrade_Options

Key Resources

Full guidance on implementing the upgrade feature will be included as part of the 20A Help docs and an updated version of the integratingOracleCommerceCloudandOracleCPQCloud.pdf in the Oracle Support Document 2214316.1 (Integrating Oracle Commerce Cloud Service and CPQ Cloud Service). MOS article will also be published.

Telco/Services: Direct Configuration (Bypass iFrame) Asset Operations (API Only)

For Oracle CX Commerce customers using Oracle CPQ and selling configurable products, we’ve made available new Storefront and Agent endpoints that enable asset modifications and upgrades — modification or upgrades to a shopper’s current service — via direct calls to Oracle CPQ, removing the need to include an iFrame in the shopper experience. This feature is limited to API support and customers need to build their own UI elements to invoke the new endpoints.

We previously released the ability to create ‘Configure’ and ‘Reconfigure’ UI elements and bypass using iFrame. This feature takes the next step by allowing the ability to create ‘Modify’ and ‘Upgrade’ UI elements as well, so merchants can deliver seamless and consistent user experience even when allowing shoppers to modify or upgrade complex products or services. The Configuration UI experience is derived from existing themes and styles. And merchants can customize the UI experience by adding their own UI controls.

This feature allows merchants to choose to move away from the iframe UI experience and instead implement direct API which enables shoppers to execute configuration of complex customizable services seamlessly in CX Commerce without being redirected to an Oracle CPQ hosted iFrame which may have a separate and distinct look and feel, and potentially present a disjointed user experience. The UI experience owned by CX Commerce can now be customized both at the global level (e.g. brand-specific configuration UIs and controls) and at the product level (e.g. a specific UI experience for individual customizable products).

Steps to Enable

1. Download and install Server-Side Extensions:

  • New - CpqConfiguratorStoreApp
  • New - CpqConfiguratorAgentApp

2. Create any necessary UI elements:

  • Create UI ‘Modify’ element which can be be coded into the asset details widget, which is not elementized. 
  • Create UI ‘Upgrade’ element which can be be coded into the asset details widget. 

Full guidance on implementing the Direct API Configuration feature will be included as part of the 20A Help docs and an updated version of the integratingOracleCommerceCloudandOracleCPQCloud.pdf  in the Oracle Support Document 2214316.1 (Integrating Oracle Commerce Cloud Service and CPQ Cloud Service) MOS article will also be published.

Tips And Considerations

NOTE: Current feature is API only and requires the merchant to build their own UI elements to invoke the new endpoints.

Catalog

Catalog Export – Improved Filtering

The filter on the catalog export dialog has been replaced with a new and improved rule builder enabling users to export a specific set of products quickly using custom rules. This allows merchants to work on a more targeted set of catalog items in export. It provides a number of new capabilities, including:

  • Ability to filter products and SKUs being exported by all base properties, including any dynamic properties of the base type
  • Ability to create single/multiple rules which are grouped together with ("AND"/ "OR" ) also known as ("ALL"/ "ANY")
  • Ability to find and return products based on the following additional properties:
    • Parent collections (parentCategories)
    • Ancestor collections (ancestorCategories): For example, filtering by "Ancestor collections contains women" brings back everything in the collections under the women's collection.
    • Creation date (creationDate): Creation date > 24th Oct
  • Ability to find and export recently added items, as well as export based on specific or missing values, such as the following examples:
    • Return products with no product images across all catalogs --> Filter by: Product Images does not exist
    • Return products with certain brand names across all catalogs: --> Filter by: Brand is one of [brand name X], [brand name Y]
    • Return all inactive products across all catalogs --> Filter by: Active = False
    • Return all products that don’t have a brand name --> Filter by: Brand does not exist

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

NOTE: We currently do not support the ability to filter by a specific catalog, search on dynamic properties of a collection, search across subtypes (e.g. product type = tables), or create nested rules.

Dynamic Properties on Collections (API Only)

Merchants can now define collection-specific data by extending collection attributes to include dynamic properties. They can create the following dynamic property types via API:

  • Checkbox (boolean)
  • Date
  • Number
  • Rich Text
  • Short Text
  • Long Text

Merchants can view and update these dynamic property values in the collection editor in the Catalog section of the Admin UI once they have been populated via API. API supports ability to create and update dynamic properties on collections.

Dynamic properties can be used individually or in combination. Using dynamic properties on collections provides flexibility and enables the ability to drive a number of merchandising enhancements, including property-based messaging and promotional content on collection landing pages, inclusion of media from a third party data asset manager, ability to display selected SKUs on selected collections (e.g. display only online-only colors of a product), excluding certain collections from typeahead search, and Shop the Look.

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

Tips And Considerations

NOTE: This is an API only feature in that the values must be populated via API first before being able to view or update them via the UI. There is currently no UI support for creating or deleting dynamic properties on a collection.

Inventory

Search for a SKU Within Inventory

Merchants can now search for SKUs within catalog Inventory based on product name and/or SKU ID. Searching enables merchandisers to find a specific SKU quickly, so that they can view the current state of a SKU and check its accuracy, as well as modify the inventory level if necessary. (Just double-click on the inventory count or stock threshold fields to update inventory values.)

The search box supports the following:

  • Ability to search for a specific SKU ID or a list of SKU IDs (comma separated)
  • Ability to search by product name or a list of product names (comma separated) 
  • Ability to search using a mixed list of product names and SKU IDs (comma separated)

Steps to Enable

You don't need to do anything to enable this feature.

Tips And Considerations

NOTE: Pagination is no longer supported. Merchants can further refine results by typing into the search box.

Storefront

Shopper Profile Registration Completion with Secure Email Link

We’re now including an optional new shopper registration flow that makes the account registration process even more secure and helps avoid malicious profile registrations. It applies to both individual Storefront shopper profile registrations and creation of new B2B users and organizations as well. In this new flow:

  • The shopper enters Name and Email Address and submits registration request.
  • Our system creates shopper profile with an auto-generated password.
  • Our system sends the shopper a New Account email that includes a secure tokenized reset password link.
  • The shopper selects link and enters new password details to complete registration.

If the email address entered is already in use, the shopper will receive a New Account email advising the shopper that there was an attempt to register with the email address entered on the site and if s/he has forgotten the password, it needs to be reset. The email will include the forgotten password link, so the shopper can reset the password.

If shopper selects to create an account at Checkout:

  • The shopper will enter registration details (Name and Email Address) and submit registration request.
  • Our system will display a message informing shopper that s/he will receive account activation details via email.
  • Our system will display a login form with pre-populated email address and message advising shopper to check his or her email to complete registration and enter login details.
  • The shopper can either complete registration using the email link and login or select to continue checking out as a Guest.

When this flow is enabled, shoppers will no longer automatically be logged in after registration, as the shopper must complete the registration via email and then actively log in.

Steps to Enable

To implement this feature, we’ve added a new site level shopper setting called EnableProfileRegistrationEmailCheck on the merchant/profilePolicies API to enable/disable this new secure shopper profile registration process, as well as a New Account email in Admin settings and updated header and login-checkout widgets.

Tips And Considerations

NOTE: To comply with security requirements, this feature is enabled by default for new customers. To ensure backwards compatibility, feature is *not* enabled for existing customers. Merchants have the option to enable/disable as desired.