Legacy platform

Return products without order information

Sometimes, a customer may want to return a product and might not have order information associated with the product due to some reason like loss of receipt. In such cases, a user can create a return order for a product by capturing the product information first followed by other order fulfillment details. This process is referred as creating a blind return.

Solution

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

Add products to return order
On the Add Products screen of the return order creation wizard, the user can choose to create a return order with order information or without order information. However, if the user does not have the resource permission to create a blind return, the options will not be visible.
  • If the user chooses to create a return order without order information, the panel to capture product information is displayed. When the user enters a Product ID and clicks Add, the getCompleteItemList API is called to list the product. Alternatively, when the user clicks Browse to search for products, the Product Browsing screen is displayed. When the user clicks Add to Order for a given product, the product is added to the return order. However, when multiple draft orders are open and the user clicks Add to Order, a window prompts the user to select the order to which the product must be added. If the user has not chosen the Blind Return option on the Add Products screen, the user is prompted to select the option for adding the product.
  • To continue to add the product to the return order, the user must enter the quantity and select the appropriate reason for returning a product. The reasons for returning a product can be configured in the RETURN_REASON common code.
  • Once the user chooses a Return Reason and clicks Save, the return order is updated with the product information and the processReturnOrder API is called.
  • If the order line is not valid for return, then the user can delete the order line and start adding again.
  • When the user adds products to the draft return order, the relevant attributes such as OrderLineKey, ReturnReason along with DocumentType are passed to the changeOrder API. After adding a product to the return order, the user can view or modify the return order lines. The getCompleteOrderLineList API is called to display the return order lines that the user can edit.
Notes:
  • Configurable bundle products cannot be added to a blind return order.
  • While creating a blind return order, the order lines added from a sales order are not displayed.
  • Validation of return policy violations is currently not supported.
Customer identification

After adding return lines to the order, the user can click Next to proceed with return order creation. If one or more return lines are added from sales order, then customer information from sales order is copied to return order and customer identification screen is not displayed even if there are blind return lines added to the order.

The user cannot proceed without identifying a customer. The user can either create a new consumer customer or search for customer and only then it is possible to navigate to the next page.

Once the customer is identified, the user can proceed to view return fulfillment summary.

Return fulfillment summary
  • On the Return Fulfillment Summary screen, the getCompleteOrderDetails API is called to display the "Refund To" and "Return From" addresses. However, if the customer has been identified, the "Bill to" and "Ship to" addresses are used as the "Refund To" and "Return From" addresses respectively. After capturing the addresses, the user can proceed to view or change the return fulfillment details.
  • The getReturnMethod API is called to retrieve the return fulfillment details such as the allowed delivery methods and store address. The YCDGetReturnMethodUE user exit can be implemented for additional handling to determine the return method. The getReturnFulfillmentSummaryDetails API is called to retrieve the order lines, which are grouped based on delivery methods.
    Note: For bundle products, the components are not displayed.
    Based on the value set for the "Show availability if number of order lines in the order is less than" rule in Sterling™ Business Center, the IsLargeOrder attribute is passed appropriately to the getReturnFulfillmentSummaryDetails API. If the IsLargeOrder attribute is Y, then the panels that display the order lines are collapsed by default. When the user clicks to expand a panel, the getCompleteOrderLineList API is called to retrieve the appropriate return order lines in a paginated manner.
  • The user has options to change the delivery method of the order lines and the address of pickup order lines. The order lines are regrouped based on the changes applied. Certain validations are performed to allow a user to change delivery methods.
    • If the IsReturnToStoreAllowed attribute value is Y, the user can change the return method to 'Shipping' for an order line. If the value is N, the button to change the delivery method is disabled and when the user selects an order line, an appropriate error message is displayed.
    • If the IsSchedulePickupAllowed attribute value is Y, the user can change the return method to Pick up' for an order line. If the value is N, the button to change the delivery method is disabled and when the user selects an order line, an appropriate error message is displayed.
    • If the IsCustomerKeepAllowed is Y, the user can change the return method to 'Customer can Keep' for an order line. If the value is N, the button to change the delivery method is disabled and when the user selects an order line, an appropriate error message is displayed.

    Similarly, if the 'Change Delivery Method' status modification rule is disabled at the order line level, an error message is displayed.

  • When the user changes either the fulfillment methods or the address of the pickup return order lines, the changeOrder API is called to update the fulfillment details on the return order. The order lines for which the 'Customer Can Keep' return method is applied, the LineType = Credit is set in the changeOrder API call. Similarly, if the "Refund To" or "Return From" addresses are modified, the changeOrder API is called to update the order accordingly.
  • A pipeline determines whether a return should be received for the order lines or not before processing the return order or the refund. By default, the IBM Sterling Call Center and Store Reverse Logistics Pipeline handles this scenario through a condition called Return Required?. Customers can implement pipeline determination to use this pipeline for return fulfillment process.
Note: The delivery method of return order lines always defaults to Shipping.

If the customer does not want to return the product in exchange for another product, the user can proceed to the Payment Confirmation screen.

Creating an exchange order

If the customer wants to purchase a product in exchange for the original product, the user can proceed to add the products to the exchange order. The createOrder API is called to create the exchange order. An exchange order follows the same flow as a sales order.

For an exchange order, the getCompleteOrderDetails API retrieves the amount that is transferred from the return order, the amount to be refunded, or the additional amount to be paid, as applicable. When the user chooses to change the exchange type, the getCompleteOrderDetails API is called to display the exchange types. After the user selects the exchange type and applies the changes, the ExchangeType is passed to the changeOrder API and applied to the order. The details of the exchange order can be viewed on the Exchange Fulfillment Summary screen and any fulfillment preferences for the exchange order can be captured.

Note: If Sterling Call Center is integrated with Commerce and customer records are not maintained in Sterling Call Center, the BuyerUserID attribute is passed to the processReturnOrder API when creating a return order for a customer. However, when the return order is created for a gift recipient, the BuyerUserID is not passed to the processReturnOrder API. When the user wants to create an exchange order for a customer, the BuyerUserID attribute is passed to the createOrder API to retrieve the products and pricing details for the customer.
Return payment summary

On the Return Payment Summary screen, the computeRefundPayments API is called internally to set the right payment methods on the return order, which is based on the associated sales order. The maximum refund amount on a payment method is also decided by the API based on the previous transaction that is made on the sales order.

When the screen loads, the getCompleteOrderDetails API is called to retrieve the amount to refund, breakup of the return order total, and the applicable payment methods. If there are no payment methods on the order, the user can continue to add payment methods to either provide a refund or collect balance amount, in applicable.

Implementation

The following section describes the rules that you must configure.
  • You must define the return reasons appropriately. For more information, see Configuring return reasons.
  • You can set a default exchange type and also prevent users from modifying the exchange type by configuring the return entry rules appropriately.
  • The payment type to which the amount is refunded can be configured. For more information, see the Modifying the refund-related configurations of a payment type.
  • For the processReturnOrder API to calculate the refund amount, you must disable the Allow Price Calculation For Draft Orders rule for return orders. Otherwise, the refund amount is calculated by considering the unit price of the product from the pricing engine, which ignores changes in the product price due to price override and discounts applied. For more information, see Defining a process type's primary information.
  • You must configure the charge names and charge categories for a return order appropriately. For more information, see Defining charge categories and names.
  • The user should have the "Blind Return" resource permission to create a blind return.
  • The user should have the "Override Exchange Type" resource permission to change the exchange type.
  • The user should have the "Change Return Method" resource permission to change the fulfillment method for a return order.
  • The user should have the "Customer Keep" resource permission to apply the 'Customer Can Keep' delivery method.

    For more information about Administering User Group Permissions, see Administering user group permissions.

  • You must enable the "Exchange Type Modifications" status modification rule to change the exchange type on an exchange order.
  • The "Change Delivery Method" order modification rule must be enabled at the order line level.

    For more information about configuring the status modification rules, see .Defining modification rules.

  • For more information about APIs, see the Javadoc.