Legacy platform

Solution

Edit online

This section describes the APIs, user exits, services, and other components involved in the implementation of the feature.

When the application loads, the Theme to be applied on web store UI rule is read by the store application to retrieve the theme set by the administrator for the enterprise and display the UI accordingly. To select a theme for your enterprise, refer to Configuring Display Options. However, you cannot create new themes for the Sterling Store Engagement application from the Sterling Business Center UI.

Therefore, to create the themes that you can select in Sterling Business Center, use the manageCommonCode API with code type as WEB_STORE_THEME. After the administrator selects a theme from available options, the theme is persisted against the rule WSC_STORE_THEME. When the Sterling Store Engagement application loads, the getRuleDetails API is called with rule name as WSC_STORE_THEME to get the theme set up for enterprise.

When a customer comes to a store to return previously purchased products, the store associate can create a return order from the Return Products portlet in one of the following ways:

If a customer comes in with products to return, the store associate can begin a return order from the Return Products portlet. The store associate can search for the products to add to the return order, in one of the following ways:
  • Searching for sales order:

    If the customer has a receipt, the store associate can search by the order number or scan a bar code on the receipt.

    • When the store associate scans the bar code of the receipt, the translatebar code API is called to retrieve the order number. The getOrderList API is called with the order number to retrieve the details of the order.
      • If no translation is returned by the translatebar code API, then the getOrderList API is called with the original input to the translatebar code API, or the store associate can return to the home screen and manually input the order number.
      • If multiple translations are returned by the translatebar code API, an appropriate error message is displayed.
      • If no orders are returned from the getOrderList API, an appropriate error message is displayed.
      • If the getOrderList API returns multiple orders, they are listed and the store associate can select the appropriate order to which the return product belongs.
      • If a single order is returned by the getOrderList API, the Add Products to Return page is displayed.
    • When the store associate manually enters the order number, the getOrderList API is called to retrieve the details of the order.
      • If a single order is returned by the getOrderList API, the Add Products to Return page is displayed.
      • If the getOrderList API returns multiple orders, they are listed and the store associate can select the appropriate order to which the return product belongs.
      • If no orders are returned from the getOrderList API, an appropriate error message is displayed.
    Advanced order search:

    The store associate can perform Advanced Search for orders using additional search criteria such as First name, Last name, Email, Phone Number, Zip Code or Payment Type. For example, if store associate chooses payment method as one of the criteria, the getPaymentTypeList API is called to retrieve all payment types using the CallingEnterpriseCode attribute for the store. The payment type selected by the store associate is passed as input along with other search criteria to the getOrderList API to retrieve the matching orders.

  • The search displays a fixed number of orders. If there are more orders to load, a message is displayed indicating the store associate to refine the search. The store associate can use the filter option to narrow down the search result.
  • The search lists the confirmed and draft orders placed by registered and unregistered customers. The order list provides details like order number, number of products, order channel, store name (in case of store purchase), date, order amount, status, customer name, and so on.
  • The getCompleteOrderLineList API returns images for a maximum of two products along with a count of remaining products in the order.
  • Searching for a customer:

    If the customer does not have a receipt, the store associate can search for a customer with a phone number in the search field after selecting Customer as the entry point in the Return Products portlet. To search for a customer, the store associate can tap the Order icon and select Customer. When Customer is selected as the entry point, the scan option is hidden. The store associate can enter the phone number of the customer and click the Search icon.

    • When the store associate clicks Search, the getCompleteCustomerList API is called to retrieve customers with information that matches the search criteria.
      • If multiple customers are returned, a list is displayed for the store associate to choose from. For each customer listed, an address, phone number, and email address is displayed to help the store associate select the correct customer.

        The store associate selects the correct customer and then select View Orders, and the getOrdersList API is called to retrieve all sales orders that are associated to that customer's account.

      • If a single customer is returned, the Customer Details page is displayed with all orders associated to that customer's account.
      • If no customers are returned, a No Customers Found message is displayed. The store associate can then input a different phone number, or choose to search through Product or Order.
    Advanced customer search:

    The store associate can perform Advanced Search for customers using additional search criteria such as First Name, Last Name, Email, Phone Number, Zip Code, or Last Four Digits of Credit Card.

    When the store associate performs a search, the getCompleteCustomerList API is called to retrieve the matching customers. After the correct customer is identified, the store associate can click View Orders for that customer. The getOrderList API is then called to retrieve the orders associated with that customer. Both draft and confirmed orders are displayed. After the store associate identifies the sales order for which a return order needs to be created, the store associate can select the products that the customer wants to return and create a return order.

  • The getCompleteOrderLineList API returns images for a maximum of two products along with a count of remaining products in the order.
  • Filter option

    The store associate can filter orders while directly searching for orders or through customer's order history. The store associate can filter the order list using criteria like order date range, status and order channel. When the store associate clicks the Filter option, the getCommonCodeList API is called to populate the entry type check boxes. The Order Statuses are picked from a pre-defined list in the OrderStatusList.json file, present in the <WAR>\ngstore\shared\order\ folder. The file is configurable, so you can customize the statuses as required. The store associate can select Search within Store to look for orders created only by the current store.

    When the store associate selects the appropriate filter criteria and applies the filter, the filter criteria is passed to the getOrderList API to retrieve the orders matching the input criteria. Order status, date range, seller organization code, and a complex query with the appropriate EntryType attribute is passed as input to the getOrderList API to retrieve orders. For store channel, the EntryType is Store and for call center channel, the EntryType is CallCenter.

  • Searching for products:

    If a customer does not have a receipt, is not registered with the store, or is registered with the store, but the order cannot be located, the store associate can begin the return process by searching for a product. This is called a blind return. A store associate can create a blind return only if the Allow Blind Return rule is turned on. This rule is turned on by default. In a blind return, the store associate can either scan the bar code of the product that the customer wants to return, or the store associate can enter the product ID or keywords to search for the product.

    • If the store associate scans a product, the getCompleteItemList API is called to translate the bar code and return the product.
      • If a single product is returned by the API, the Add Products to Return page is displayed. The getCompleteItemList API is called to retrieve product details, and the store associate can then add the product to the return order.
        The store associate can click the Share button to share the product details with the customer. On the Share pop-up window, the store associate can share the product details through email by default. The customer's registered email address is automatically populated and if the email address does not exist, the store associate can manually enter an email address. When the store associate clicks the Email button, the product details are sent to the customer. Similarly, the store associate can send product details to multiple email addresses by entering the email addresses manually.
        Note: You can also add multiple sharing options through customization. Similarly, you can customize the default email service as required.
        If the store associate does not have the Email Product details resource permission and the Share button has only the Email option, then the Share button is not seen on the screen.
      • If multiple products are returned by the getCompleteItemList API, an appropriate error message is displayed.
      • If no products are returned by the getCompleteItemList API, the searchCatalogIndex API is called and the Product List page is displayed.
    • If the store associate enters keywords and clicks Search, the searchCatalogIndex API is called to load products that match the keyword, and the Item List page is displayed to show all matching items. The correct item can then be selected to add to the return order.

Add products to return

Note:

You may notice screen flickering issues while viewing Add Products to Return screen on Windows™ version 8.1.

After the order to be returned is identified, the store associate is taken to the Add Products to Return page. The getCompleteOrderDetails API is called to fetch the order details and the getCompleteOrderLineList API is called to fetch the product details. The following logic is executed:
  • The details of each product are displayed, including whether the product is returnable. If no products in the order are returnable, the store associate cannot create a return order.
  • While fetching items, if the YCD_SHOW_RESHIP_ON_RETURN_ENTRY rule is turned off, only products with the ReshipParentLineKey attribute set to null are fetched. To ensure that reship products are not fetched, the ReshipParentLineKeyQryType is set to ISNULL.
  • The store associate can click the Search icon to change the search method for an order, and can then search for a customer, an order, or a product. The store associate can add products from multiple sales orders to single return order by searching for other sales orders.
  • The fulfillment method for a return product is set to CARRY.

In the Add Products to Return screen, the products are sorted by returnable and non-returnable. The products that can be returned are listed first, followed by products that cannot be returned. Each product has all of the details, including the description, an image, how many can be returned and how many have already been returned, and so on. Products can be non-returnable for several reasons, either the product's status does not allow for a return, the product violates a return policy, or all quantities of the product are already returned. Return policies are set in Sterling Business Center, and can be modified to suit your business needs.

Some return policies cannot be overridden for any reason, and the product displays Cannot be returned. Some return policies can be overridden by the store associate with the appropriate permissions. The product displays Override required. If a product is scanned and has any return policy violations, the Product outside return policy window opens. If the return violation can be overridden, the manager can enter the override code. The assumption is that there is a single approver for the approval plan and the approval plan is the same for all return policy violations. Refer to Override Return Policy Violations for more information. When the override is successful, the product displays Add to Return and an override is not required for that product again unless the return order is canceled and the store associate creates a new return order with the same product.

For products that can be returned, the store associate can click Add to Return or scan the bar code of the product. The translatebar code API is called when the store associate scans a product. If a valid translation is returned, then the matching order line is fetched for the product by using the getCompleteOrderLineList API. If the matching order line is a returnable line, then the createOrder API is called to create a draft return order. This API is called only for the first time. If a product is being added for the second time onwards, the changeOrder API is called to update the draft return order. When the store associate chooses to add a product to the return, one unit of the product is added. To return multiple quantities of the same product, the store associate clicks Add to Return repeatedly for each individual product.

The following logic is executed:
  • The EntryType attribute in the createOrder API is set to Store.
  • The getCompleteOrderDetails API is called to fetch the customer information from the sales order. The customer information is passed either to the createOrder or changeOrder API to be stamped on the return order.
  • The getCompleteOrderDetails API fetches the OrderLineKey attribute of the sales order, and that is then passed either to the createOrder or changeOrder API in the DerivedFrom element to the return order.

A store associate can view the products in a return order at any time by clicking the Mini Cart. The Mini Cart displays the products that are in the cart and the quantity. A store associate can remove the products from the return order in the Mini Cart, but cannot individually increase or decrease the quantity of the product.

Add products to blind return

If the customer does not have a receipt and is not a registered customer, then the store associate searches for the product. When the correct product is identified, the store associate can click Add to Return. The following logic is executed:
  • In a blind return, the getLowestPrice API is called to fetch the lowest unit price for a product. The lowest price is based on the PRICING_BLIND_RETURN_DAYS rule, which is used to configure the NumberOfDaysInPast attribute to find the lowest price for the product. If the rule is not set, the default value is set to 90 days. The lowest price between the date the store associate creates the return order and the number of days in the past that is configured is displayed as the return product price.
  • The createOrder API is called to create the return order if it is not yet created. The changeOrder API is called to add products to a return order that is created.
Only manual bundle products are supported for blind returns. If configurable bundle products are added, an error message is displayed.

A store associate can view what products are in the return order at any time by clicking the Mini Cart. The getCompleteOrderLineList API is called to get the list of products in the cart. Next to each product is an X icon, which a store associate can click to delete the product.

If the store associate clicks the X icon, the modifyFulfillmentOptions API is called with the Action attribute set to REMOVE to delete the product. After the product is deleted, the mini cart is refreshed.

Returns list

After all products are added to a return, the store associate can continue to the next screen to add return reasons for products. After adding all products, the store associate clicks Continue. The getCompleteOrderDetails API is called to fetch the header information and the order total information, and the getCompleteOrderLineList API is called to display the order line information on the Returns List screen. The processReturnOrder API is called to copy the discounts and charges from the sales order to the return order, if any.

Each item that is being returned must have a return reason. Return reasons are configured in Sterling Business Center and the getCommonCodeList API is called with the CodeType attribute set to RETURN_REASON to fetch the return reasons. The Add reason for return pop-up window is displayed when the Returns List screen loads, and the store associate must enter return reasons. Returned products can have different return reasons or the store associate can apply the same return reason for all of the products. If the return reasons are different, then each product is displayed and the store associate can add an individual return reason for each product. If the store associate chooses to select the return reasons later, the store can click Add reason for return for each product. The Add reason for return pop-up window is displayed. The store associate can select the Reason for return.

After the store associate enters all required details in the Add reason for return window and clicks OK, the changeOrder API is called to update the order with the return reasons.

If a product needs to be removed from the return order, the store associate can click the Delete icon and the changeOrder API is called to remove the product from the return order.

If the store associate is creating a blind return, the customer must be identified on the Returns List screen. The store associate can click Identify Customer. If the customer exists in the system, the store associate can search for the customer. If not, the store associate can create a new customer profile.
  • Existing customer
    • Existing customers can be searched by first name, last name, email, or phone number. The getCompleteCustomerList API is called to search for all existing customers.
    • For existing customers, if there are any associated addresses such as Bill to and Ship to created, they are displayed when the store associate searches for a customer.
    • After the store associate finds the correct customer and clicks OK, the changeOrder API is called to add the customer details to the order. If an address is associated with the customer account, that address is automatically made the shipping address for the order.
  • New customer
    • If no record is found for a customer, or if a customer is new, the store associate can select the New Customer tab to create a consumer customer.
    • When the store associate enters any of the address details for the customer and tabs out, the following logic is executed:
      • After the store associate clicks OK, the verifyAddress API is called. If the YCDVerifyAddressWithAVSUE user exit is configured, then the address if validated. If the address is not valid, or multiple addresses are found that match the input address, then the user is prompted to either modify the invalid address or select the correct address from the list of matching addresses.
      • After a valid address is selected, the manageCustomer API is called to create the customer.
      • The changeOrder API is called to add the customer details to the return order.
  • To change the customer information, the store associate can click Change Customer in the customer panel, and the API calls are similar to that of creating a new customer. The store associate can also modify the address that is selected for the order by clicking the Edit icon. The Edit Shipping Address pop-up window is displayed, the store associate enters the address, and clicks OK. The modifyFulfillmentOptions API is called to update the address on the order. If the store associate edits the address, the change is made only to the order and not saved to the customer account.

Override Return Policy Violations

If a product is not returnable, but the store associate wants to proceed adding the product to the return, the policy violation must be overridden. Override return policies for return products are set in Sterling Business Center. The return policy that is set determines the rules for return products.
  • If the override policy is set to Allow Override, then the product violation is automatically overridden by the application.
  • If the override policy is set to Do Not Allow Override, then the policy cannot be overridden. The store associate can view the return policy to explain the violation to the customer.
  • If the return policy is set to Allow Return Based on Approval Plan, then overrides are allowed with the appropriate approval code. When the store associate clicks Override for the product that violates the return policy, the Override window is displayed.
    • The getCommonCodeList API is called with the CodeType attribute set to WSC_RETURN_OVERRIDE to fetch the override reason.
    • The store associate must enter a manager override code.
    • The store associate can click OK to save the return reason and the override code to the order. The createOrder API is called for the first item that is being added to the return order. The changeOrder API is called for all products after the first product that are added to the return order.
    • Override codes cannot be entered for individual products. All products with return policy violations are overridden when an override code is entered. If a store associate does not want to override all of the products in the return order with return policy violations, the store associate must delete the products that should not be overridden from the return order before overriding the remaining products.
  • Upon the success of the createOrder or changeOrder API, the YCD_ValidateReturnOverrideCode service is invoked. The order object, selected product, return reason, and override code are input to the service to validate the override code.
    • After the service is invoked, the processReturnOrder API is called to fetch the violations against the order line.
  • When the service successfully executes, any violations against the product are fetched. The recordApprovals API is called for each violation. The violation ID is passed to the API and the API either approves or rejects the override.
    • If the API approves the override code, the status of the product is changed to 1200. If the approval is accepted, the createOrder or changeOrder API is called to record the override reason.
    • If the API rejects the override code, the status of the product remains unchanged and the override is not added to the order.

The return and override policies validation both must be set for the store associate to be notified of violations.

If the return and override policies conflict for a product, an appropriate error message is displayed and the product is not added to the return order.

Add exchange products

A customer might want to purchase different products in exchange for the products that are being returned. The store associate can add exchange products either by scanning an item or entering keywords in the Exchanges panel. When a keyword is entered or a product is scanned, the following logic is executed:
  • When the store associate scans a product to be exchanged, the getCompleteItemList API is called to retrieve the product and the Product Details page is displayed. If there are no results found, the searchCatalogIndex API is called to list products.
  • If the store associate enters keywords and clicks the Search icon, the searchCatalogIndex API is called to list matching products. The correct product can then be selected from the list.
The store associate can click the Share button to share the product details with the customer. On the Share pop-up window, the store associate can share the product details through email by default. The customer's registered email address is automatically populated and if the email address does not exist, the store associate can manually enter an email address. When the store associate clicks the Email button, the product details are sent to the customer. Similarly, the store associate can send product details to multiple email addresses by entering the email addresses manually.
Note: You can also add multiple sharing options through customization. Similarly, you can customize the default email service as required.
If the store associate does not have the Email Product details resource permission and the Share button has only the Email option, then the Share button is not seen on the screen.

When the correct product is located, the store associate can click Add as Exchange to add the product to the exchange order.

When the product for exchange is added for the first time, the createOrder API is called to create the exchange order. The following logic is executed:
  • The getCompleteOrderDetails API is called to fetch the OrderHeaderKey attribute from the return order, and that is then passed as the ReturnOrderHeaderKeyForExchange attribute in the createOrder API.
  • The ExchangeType attribute in the createOrder API of the exchange order is set based on the YCD_DEFAULT_EXCHANGE_TYPE rule.

After a product is added to an exchange order, the Returns list screen is displayed with the added exchange products. The store associate can make any necessary modifications to an exchange product, including making a product a gift, applying a coupon, changing the delivery method, and so on.

To override the price of an exchange product, the store associate can select the edit icon. When the store associate selects the edit icon next to the unit price of the exchange product, the Override Price window is displayed. The store associate can enter the new price and the reason for the price override, and apply the change.

To fetch the override reasons, the getCommonCodeList API is called with the CodeType attribute set to YCD_PRICEOVERRIDE. When the store associate clicks Apply, the modifyFulfillmentOptions API is called to override the list price of the product. The original price and the new price of the product are displayed.

To override the price of a product, the store associate must have resource permission to the Override Price action. If the store associate does not have the resource permission, the Override price icon is not displayed.

Gift options might be available for exchange products. A Make this product a gift message is displayed for all products.

A store associate must be able to apply coupons to individual exchange products or the entire exchange order while completing the exchange order flow. A store associate can either scan a coupon or enter the coupon code and then press the Enter key to apply the coupon to the order. The translatebar code API is called to identify the coupon. Once the coupon is identified, the changeOrder API is called to apply the coupon to the order.
  • If the coupon is successfully applied to the order, the getCompleteOrderDetails API is called to refresh the order panel with the updated price. If the coupon is not successfully applied, an error message is displayed.
  • A store associate can delete a coupon by clicking the X icon next to the coupon. To remove a coupon, the changeOrder API is called with the ACTION attribute set to REMOVE in the Promotion element. The getCompleteOrderDetails API is called to refresh the page with the updated information.
Note: The following types of coupons are not supported:
  • Coupons applicable on shipping charges
  • Coupons applicable on specific payment types

After all products are added and the customer is identified, if necessary, the store associate can click Refund. The processReturnOrder API is called with the ExecuteReturnPolicy attribute set to Y to validate the return products. If violations occur, the Product outside return policy pop-up window opens and the store associate must call a manager to input a Manager override code to allow the return. Alternatively, the store associate can remove the product from the return order. If the policy violation cannot be overridden, the store associate must remove the product from the return order before proceeding to payments. If no violations occur, the Payments screen is displayed.

Payments

When the store associate moves from the Returns List screen to the Payments screen, the processReturnOrder API is called to compute the refund amount. If any payment methods were saved with the original sales order, the processReturnOrder API populates the default payment methods for the return order. The default payment methods for return orders and the refund amount on those payment methods is dependent on the payment type configurations.

If the Default for Return rule is turned on, the following logic is executed:
  • Only one payment type can be made as a default payment type for the return process at a given time.
  • If a payment type is made the default for return, then during a blind return, the amount is refunded to that payment type.
  • If a payment type that was used in sales order is not valid for return, then the amount is refunded to the default payment type.
If the Valid for Return rule is turned on, the following logic is executed:
  • If the payment types that were used for sales order are valid for return, then on returning the products, the amount is refunded to the same payment types. If more than one payment type is used in the sales order, then the return sequence is taken into consideration, and the amount is refunded based upon the return sequence.
  • If the payment types that were used for sales order are not valid for return, then on returning the products, the return refund screen does not display the invalid payment types in the payment panel. However, the user can select the payment types which are not valid for return via the Add New Payment Method link and complete the refund process.
If the Credit Card Valid For Return rule is turned on, the amount is refunded to a credit card. If the Credit Card Valid For Return rule is off, then the return is refunded to any default payment methods. If the customer requests the refund to be a payment method other than the default payment method, then the store associate can add a new payment method. The PlannedRefundAmount attribute is populated for the return order payment methods if the sales order has done the shipment invoice generation.
If no exchange products are in the order, the following logic is executed:
  • The refund amount for the return order is displayed with the default payment methods and the corresponding PlannedRefundAmount for every payment method.
  • The GrandRefundTotal attribute in the processReturnOrder API is called to display the refund owed to the customer.
  • The getCompleteOrderDetails API is used to retrieve the details of the return order.
If there is an exchange order for the return order, the following logic is executed:
  • The getCompleteOrderDetails API is called to retrieve the GrandExchangeTotal attribute to display the exchange order total and the GrandTotal attribute to display the total for the return and exchange orders.
  • If the GrandRefundTotal amount is greater than $0, the customer receives a refund. The default payment methods are displayed from the planned refund amount.
  • If the GrandRefundTotal amount is less than $0, the customer owes money on the exchange order. When the customer owes money on the order, the getCompleteOrderDetails API is called to fetch the RemainingAmountToAuth attribute from ChargeTransactionDetails attribute, to display the remaining amount that the customer must pay. There are no default payment methods when the customer owes a balance on the exchange order.
  • To capture the payment, the following logic is executed:
    • The capturePayment API is called to capture the payment for the exchange order.
    • The getPaymentList API is called to fetch the accepted payment types.
    • The getCommonCodeList API is called with the CodeType attribute set to YCD_CREDIT_CARD_TYPE to fetch the accepted credit card types. The information is then passed to the getPaymentCardTypeList API to fetch the list of payment card types.
    • For credit card payments, the SecureAuthenticationCode attribute is passed in the processOrderPayments API to capture the CVV code on all credit cards.
    • For security purposes, the credit card numbers are not provided in the application, instead the payment is captured by the Sterling Sensitive Data Capture Server to encrypt the card numbers. The store associate receives the CVV code on the credit card, which is passed to the processOrderPayments API for authorization as transactional information, but is never stored in the system or system logs.
    • If any errors occur when the payment is processed, the ChargeTransactionDetails element in the output of either the capturePayment or the processOrderPayments API is called to display an appropriate error message.
    • If the payment is successfully processed, the confirmDraftOrder API is called to confirm the payment.

If the If Refund Amount is constraint is set for a payment type for a certain refund amount, then the refund is given to the payment type that is specified in the Refund Using Payment Type constraint. For example, if the sales order is associated with a credit card payment type, then a constraint can be set so that on return of the order, the refund amount must be refunded to a check if the order total is greater than $1,000. If the order total is not greater than $1000, the constraint can be set to refund to a store value card. For this setup, the Refund to new payment type constraint must be set as SVC (store value card) in the credit card payment type and the constraint must be set that order total is less than $1000 in the SVC payment type. If the Default for Return and Refund to a new payment type rules are ON for a payment type, then the payment type that is set as Refund to new payment type is taken into consideration when the store associate performs a blind return.

The processOrderPayments API is called to process the refund to the customer in real-time. If errors occur while processing the payment, the chargeTransactionDetails element in the output of either the capturePayment or the processOrderPayments API is called to display an appropriate error message. If no errors occur while processing the payment, the confirmDraftOrder API is called to confirm the order.

Note: While entering payment information, if the store associate returns to the Returns list page, any payment information entered is lost. Payments are not saved on draft orders.

View return or exchange order summary

Upon successful payment completion, the store associate can view the Return Summary or the Exchange Summary. The getCompleteOrderDetails API is called to get all return and exchange order details. The getCompleteOrderLineList API is called to retrieve return product and exchange product details.

The store associate can print a receipt for the customer. When the store associate chooses to print the receipt, the StoreReturnReceipt_95 service is invoked to send the details of the return order to be printed.

Alternatively, the customer might ask to have the return receipt sent to an e-mail address. The YCD_StoreReturnEmail service is invoked to get the return order details and send the email.

When the store associate clicks Done, the Record Return Location window is displayed. The getReturnDispositionList API is called to fetch the return locations. The store associate selects whether all returned products should be sent to the same return location. The following logic is executed:
  • If all products should be sent to the same return location, then the window displays a menu to choose the return location. The store associate must select the return location.
  • If the products must be sent to different return locations, then the window displays a return location menu for each product. The store associate must select a return location for each product.
  • To save the return locations for the products, the store associate clicks OK. The changeOrder API is called to save the changes to the return order.
After the return locations are selected by the store associate and saved to the return order, the Home page is displayed.

Cancel return or exchange order

If the store associate chooses to cancel a return or exchange order, the deleteOrder API is called with the OrderHeaderKey attribute to delete the order. If the store associate needs to return any of the products after canceling the order, a new return order must be created. If any override code was required, the override code must be input again.