Apply a price match

Edit online

A customer can find out that a product is available at a cheaper price with a different retailer. In such situations, the call center representative can investigate the customer's claims and price match the products.

Solution

The following section describes APIs, user exits, services, and other components.

A user can price match a product in an order by using the "Price Match a Product" related task in the Order Summary screen.

The YCDCanPriceMatchBePerformedOnLinesUE user exit is called to determine which product can be price matched. The logic that is implemented in the user exit considers the price match window beyond which the price match cannot be applied. However, you can implement a different validation logic for this user exit.

The getCompleteOrderLineList API is called to display the order lines that can be price matched.

In case of bundle products, only the parent product can be price matched if the Bundle Pricing Strategy is configured appropriately for the application. Individual components of a bundle product cannot be price matched.

The user can select an order line and proceed to the next screen to apply a price match. The getRuleDetails API is called to get the value of the YCD_PRICE_MATCH_CHARGE_NAME rule, which is passed in the getChargeNameList API to retrieve the charge name and category that must be used to apply the price match.

When the user selects the competitor, enters the minimum quantity, and does a search, the system checks for prior price matches done for that product. The getPriceMatchList API is called to get the list of prior price matches.
  • If prior price matches are found, the user can select from a list of approved price matches. This allows the user to apply the price match conveniently. The worksheet is defaulted with the details of the price match selected.
  • If the user cannot find an approved price match or if the user wants to manually enter the price, the user can enter the competitor's unit price, adjustment, shipping charges in the worksheet.
Based on the competitor's total price, the different scenarios that are involved in applying a price match are as follows:
  • If the total matches an approved price match, the user is allowed to proceed to Payment Confirmation screen.
  • If the total is greater than an approved price match, the user is notified that the enterprise is offering a better price and hence the price match in not applied.
  • If the total is less than a rejected price match, the user is prompted to enter a description and cancel or accept the change. If the user accepts the change, a price match record is created in the "Rejected" status.
  • If the total matches a pending price match, the price match is applied in the following ways:
    • The user with the appropriate permission can approve or reject the price match. The user is prompted to enter a price match description. The managePriceMatch API is called to save the price match and update the order by calling the changeOrder API.
    • If the user does not have appropriate permissions, the user cannot approve or reject the price match. The user is prompted to enter a price match description. The changeOrder API is called to set notes on the order line.
  • If none of the prior price matches can be used to approve or disapprove the customer's requested price match, the system does a "No Hassle" price match check to verify if the price match can be provided to the customer without a call center representative having to investigate the price match claims manually. The checkNoHasslePriceMatch API is called to do the "No Hassle" price check by considering the following "No Hassle" rules:
    • Maximum No Hassle Unit Price Difference: The price match action is allowed for products whose price difference falls within the configured range.
    • Maximum No Hassle Unit Price Difference Percentage: The maximum percentage difference between the current product's price and the competitor's price, beyond which the price match is not allowed.
    • Maximum No Hassle Line Quantity: The maximum ordered product quantity beyond which price match is not allowed.
    • If the system determines that the requested price complies with the No Hassle criteria, the user is allowed to approve the price match.
    • If the system determines that the requested price does not comply with the No Hassle criteria, the user with the appropriate permission is allowed to approve or reject the price match based on one of the following options:
      • Approve the price match until the selected expiration date.
      • Approve the price match but not on future orders.
      • Deny the price match for all orders.

      The user must enter a price match description and apply the changes.

      If the user does not have appropriate permission, the price match is placed in "Pending" status, and an alert is raised. The managePriceMatch API is called to create a price match record. The createException API is used to create an alert of the type YCD_PRICE_MATCH. The alert is assigned to the YCD_PRICE_MATCH queue. The price match must be approved before the user can resolve the alert. For more information about managing alerts, see Manage Alerts.

Alternatively, you can implement a different "No Hassle" logic in the checkNoHasslePriceMatchUE user exit.

The "Refund Amount Per Unit" is calculated by applying the price match percentage to the difference between the competitor's total price and order line total price.

When the user confirms a price match, the changeOrder API is called to apply the price match. For approved order lines, the YCD_PRICE_MATCH_RECORDED_AS enterprise rule is used to determine whether the price difference is applied to the order line by changing the unit price itself or by adding a charge to the order line.

When a price match is saved, the description is passed in the PriceMatchDescription attribute to the managePriceMatch API. The changeOrder API is called to save changes to the order and apply the new unit price. For rejected or pending price matches, the changeOrder API call is made only to set the notes on the order line. Changes to the price only happen when the price match is in Approved status. For more information about automatic notes logging, see Automatic notes logging.

When the user attempts to price match the same products again, the newly created price matches are listed as previously attempts.

Implementation

The following section describes the rules that you must configure.

You must configure price match rules appropriately. For more information, see the Sterling Business Center System Configuration.

To apply a price match to the parent of a bundle product, you must select the Bundle Pricing Strategy as "Only include parent" or "Include both parent and components". For more information, see the Sterling Business Center Product Administration.

Applying or rejecting a price match is a permission-controlled task. For more information about administering user group permissions, see the Administering user group permissions.

For more information about the APIs, see the Javadoc.

You can configure a default note to be logged automatically when a price match is successfully applied. For more information, see Automatic notes logging.

End-user impact

The user can select an existing price match or manually enter the price to apply to the selected order lines.