Document Properties
Kbid
3H0664
Last Modified
11-Nov-2022
Added to KB
11-Nov-2022
Public Access
Everyone
Status
Online
Doc Type
References
Product
  • IOM 4.0
  • IOM 4.1
  • IOM 4.2
  • IOM 4.3
  • IOM 4.4
  • IOM 4.5
  • IOM 4.6
  • IOM 4.7
  • IOM 5.0
Reference - IOM Return and Cancelation Business Process

Introduction

This document is part of the IOM Business Processes and is aimed at project developers.

It explains in detail the IOM Return and Cancelation Business Process and its included sub-processes.

References

The Return and Cancelation Business Process

Introduction

The Return and Cancelation Business Process controls the entire processes to manage rescissions or return of orders, order positions, or units of an order.

Starting with capturing a return or cancelation, sent by a sales channel or fulfilment solution, the return or cancelation will be validated and stored. (Sales channels normally just send cancelation requests, but no cancelations or returns.) Next, approvals may be processed and notifications about approvals are sent to 3rd party systems. Finally, documents are re-created if necessary and notifications are sent to 3rd party systems about finalized returns or cancelations.

A return is the general envelope for different kinds of rescission and is tracked by the following return types:

  • CANCEL: A cancelation of an order, order positions, or units before the order is passed to the fulfillment locations.

  • RECALL: A cancelation of an order, order positions, or units after the order is passed to the fulfillment locations.

  • RETURN: A return of an order, order positions, or units by the customer that was shipped before.

  • INVERSION: A refusal of shipping(s) by the customer or non-executability during the delivery to the customer.

  • SERVICE: Guarantee or service case. The product will be exchanged by the fulfillment location.

To differentiate the different reasons why a cancelation or return was issued, it is possible to define a list of dedicated return reasons for each return type which can be extended based on the requirements of the order capture channel and the fulfillment location.

Boundaries

The Return and Cancelation Business Process starts with a return or cancelation being captured by the standard API and normally ends with (a) canceled or returned order, order position(s), or unit(s).
The process ends by reaching the return status CLOSED. Refer to IOM Return Status Model.

Process Flow

  1. Send cancelation. The commerce management system sends a cancelation to cancel an order, order position(s), or unit(s).

  2. Order cancelation process. The IOM receives the cancelation and initiates the cancelation process. Depending on the state of the order (passed to the fulfillment location or not) the order is canceled or a cancelation process involving the assigned fulfillment location is initiated.

  3. Receive and process cancelation request. The fulfillment location receives the cancelation request. Depending on the fulfillment state the fulfillment location is able to cancel the order or not. When a cancelation is possible the fulfillment locations sends a return notification of type CANCEL to approve the cancelation request. If a cancelation is not possible, the fulfillment location sends a delivery notification to the IOM. The delivery notification also cancels the related cancelation request done before by the IOM.

  4. Receive return. The customer returns a product to the fulfillment location and the fulfillment location captures and processes the return.

  5. Cancel order or submit return. The fulfilment location initiates the cancelation or submits a service return.

  6. Send return notification. The fulfillment location sends a return notification of the corresponding type (CANCEL, RETURN, INVERSION, SERVICE).

  7. Return capture, validation, and approval process. The return is captured from the fulfillment location and validated according to predefined business rules. Next, a return approval process for the return type and return reason is initiated with the assigned order capture channel.

  8. Approve return. The order capture channel approves the return.

  9. Receive approval notification. The fulfillment location receives the approval notification to identify if the return is accepted or it must be sent back to the customer.

  10. Process return notification. The return notification will be processed and the return will be announced to the order.

  11. The Finalize return process initiates the corresponding processes if documents must be (re)created and if an order response notification must be sent to the order capture channel.

  12. Receive order response notification. The order capture channel receives an order response notification with the updates/cancelations performed on the order.

  13. Receive updated delivery documents. The fulfillment location receives the updated delivery documents.

Return Capture, Validation, and Approval Process

Introduction

The Return Capture, Validation, and Approval Process captures return notifications from 3rd party systems, e.g., fulfillment locations. The process validates and checks the return to ensure the data integrity and declines it if necessary. The process also manages the approval process for a return, based on the approval configuration for a return reason of the order capture channel.

Boundaries

The Order Capture and Validation Process starts with a return notification order in status INITIAL for an existing and delivered order and normally ends with a validated and approved/declined return.
The process ends by reaching one of the return statuses CHECKED, NOT_CHECKED, APPROVE_MANUAL, APPROVED, or APPROVAL_REJECTED. Refer to IOM Return Status Model.

Process Flow

Intershop Order Management

  1. Receive return notification. The fulfillment location passes a return notification which will be stored by the IOM in status INITIAL.

  2. Process return in status INITIAL. The processing for all returns in the status INITIAL is initiated. This includes returns that are created by the fulfillment location or cancelations that are created by the IOM during related business processes.

  3. Assign order to return notification. The order is assigned to the return notification. The shop order number will be added, if it is missing in the return.

    1. OK: The assignment is successful and the process continues.

    2. FAILED: No matching order is found for the order return notification. Initiate the escalation workflow to solve the error.

  4. Unprocessed return notifications available? For the order from the fulfillment location.

    1. YES: The return notification is set to wait state until the older return notifications are processed.

    2. NO: There are no older return notifications in the system and the process continues.

  5. Prepare return and add missing data. The process tries to add missing data to the return.

    1. Missing IOM product ID will be added.

    2. Missing IOM order position reference number will be added.

    3. And more (in preparation).

  6. Validate return according to return validation rules. The order return is validated according to the defined order return validation rules.

    1. OK: Validated without errors. The return has been successfully validated and the process continues.

    2. ERROR: Validated with errors. The validation detects errors (e.g., required fields are missing). Initiate the escalation workflow to solve the error.

  7. Set the return CHECKED.

  8. Set the return NOT_CHECKED to indicate that the return must be corrected.

  9. Return must be approved manually? Checks if an approval is necessary for the return reason of the return. 

    1. YES: The return must be approved.

    2. NO: The return must not be approved .

  10. Set return APPROVE_MANUAL to indicate that the return must be approved manually.

  11. Approve or decline returns. A return is approved or declined.

    1. APPROVED: The return is approved.

    2. DECLINED: The return is declined.

  12. Set return APPROVED to indicate that the return has been successfully approved and can be processed by the IOM and the fulfillment location.

  13. Set return APPROVAL_REJECTED to indicate that the return has been declined.

  14. Notify the fulfillment location about the approval status?

    1. YES: The fulfillment location must be notified about the approval status of the return.

    2. NO: The fulfillment location must be not notified about the approval status of the return.

  15. Create and process return transmission to inform the fulfillment location.

The IOM processes only return positions with a valid order position reference.

Fulfillment Location

  1. Send return notification. The fulfillment location captures the return and sends a return message to the IOM.

  2. Receive approval notification and check next process step. The fulfillment location is informed about the approval status of the return.

    1. Approved: The return has been approved.

    2. Declined: The return has been declined.

  3. Process return. The return is processed by the fulfillment location.

  4. Send back to the customer. The return is declined and will be returned to the customer.

Order Capture Channel

  1. Retrieve returns to approve. The list of returns to be approved will be retrieved.

  2. Approve or decline returns. Returns are approved or declined by the order capture channel.

Exceptions

In case of exceptions, the processing stops and the errors must be solved. After the errors have been solved, the process is continued automatically by the control app.

More

Extension points

  • Queues: CheckReturnQueue

  • Statuses: INITIAL, CHECKED, NOT_CHECKED, FAILED, APPROVE_MANUAL, APPROVED, APPROVAL_REJECTED (refer to IOM Return Status Model)

Related processes

Return Notification Process

Introduction

The Return Notification Process announces a return notification in the status CHECKED or APPROVED to the related order and issues a response notification to the order capture channel if necessary.

Boundaries

The Return Notification Process starts with a validated and approved return notification in status CHECKED, APPROVED, or DO_PROCESS and normally ends with an announced order return notification and an updated order position. The process ends by reaching the return status PROCESSED. Refer to IOM Return Status Model.

Process Flow

  1. Return announcement required? Checks if the return of a specific return reason must be announced to the order. The announcement of a specific return reason can be configured for each fulfillment location and order capture channel combination. Returns of the type SERVICE are not announced to the order.

    1. YES: The return must be announced to the order.

    2. NO: The return must not be announced to the order.

  2. Announce return to the order. The quantity of the return notifications in the status DO_PROCESS is announced to the order and the corresponding order positions. The return position's quantities of a return of the type CANCEL and RECALL are copied to the quantity canceled of the corresponding order positions. The return position's quantities of a return of the type RETURN and INVERSION are copied to the quantity returned of the corresponding order positions. Afterward, the new statuses are set for the order positions and the order to reflect the current status of the order with an announced return (e.g., DISPATCHED to RETURNED). If the transition fails because the order position is not in one of the mentioned statuses, the announcement process fails and the order return notification is set to status NOT_ANNOUNCED.

    1. Allowed order/order positions status transitions for completely returned orders (refer to Order Status Model and IOM Order Position Status Model)

      1. COMMISSIONED or before → CANCELED

      2. COMMISSIONED or
        *_PARTLY_COMMISSIONED* or
        COMMISSIONED_PARTLY_* or
        DISPATCHED or DISPATCHED_PARTYLY_RETURNED → RETURNED

    2. Allowed order/order positions status transitions for partly returned orders (refer to Order Status Model and IOM Order Position Status Model)

      1. COMMISSIONED → COMMISSIONED_PARTYLY_RETURNED

      2. PARTLY_COMMISSIONED → PARTLY_COMMISSIONED_PARLY_RETURNED

      3. PARTLY_COMMISSIONED_PARTLY_DISPATCHED → PARTLY_COMMISSIONED_PARTLY_DISPATCHED_PARTLY_RETURNED or PARTLY_COMMISSIONED_PARTLY_RETURNED

      4. PARTLY_COMMISSIONED_PARTLY_RETURNED → n/a

      5. PARTLY_COMMISSIONED_PARTLY_DISPATCHED_PARTLY_RETURNED → n/a

      6. COMMISSIONED_PARTLY_DISPATCHED → COMMISSIONED_PARTLY_RETURNED

      7. COMMISSIONED_PARTLY_DISPATCHED_PARTLY_RETURNED → n/a

      8. DISPATCHED → DISPATCHED_PARTLY_RETURNED

      9. DISPATCHED_PARTLY_RETURNED → n/a

  3. Create response notification? This is always the case if the return type is CANCEL or RECALL and an INITIAL response has been sent to the order capture channel before.

    1. YES: A new order response notification must be created.

    2. NO: No order response must be created.

  4. Create response of type INITIAL or CONTINUOUS. A new response of the type CONTINUOUS will be created to inform the order capture channel about changes (cancelation or recall) of an existing order. If no INITIAL response has been sent to the order capture channel before, the process evaluates if all responses are available from the fulfillment locations. If yes, a new response notification of the type INITIAL will be created.

  5. Cancel outstanding recall and backlog requests. If a recall has been sent to the fulfillment location and the return of type CANCEL or RECALL approves the recall, the status of the open order recall transmission is set to CONFIRMED. If a backlog request has been sent to the fulfillment location and the backlog is canceled due to a return of the type CANCEL or RECALL, the status of the open backlog request will be set to CANCELED.

  6. Cancel open response processes. In the case that a response notification is in approval status and one or more positions out of the open response are canceled by a return of type CANCEL or RECALL, the response notification will be set to FAILED because it is not valid anymore.

  7. Close open order cancelations. Check if there is an order cancelation in status ANNOUNCED or RETURNED. If yes, the order cancelation will be set to CLOSED. Refer to Order Cancel State Model.

Exceptions

In case of exceptions, the processing stops and the errors must be solved. After the errors have been solved, the process is continued automatically by the control app.

More

Extension points

  • Queues: ProcessReturnQueue

  • Statuses: DO_PROCESS, DO_ANNOUNCE, NOT_ANNOUNCED, ANNOUNCED, DO_COMPOSE_RESPONSE, COMPOSED, and PROCESSED (refer to IOM Response Status Model)

Related processes

Finalize Return Process

Introduction

The Finalize Return Process determines if documents should be (re)created during the return processes and submits a return message to a 3rd party system in order to inform about new returns (or cancelations).

Boundaries

The Finalize Return Process starts with a return in status PROCESSED and closes the return that optionally includes recreated delivery/return notes and optionally sends a return notification.
The process ends by reaching the return status CLOSED. Refer to IOM Return Status Model.

Process Flow

  1. Documents should be re-created? Based on the configuration the processes identifies if documents should be created for the fulfillment location(s) or web shop of an order.

    1. YES: The process initiates the Reference - IOM Document Creation Business Process.

    2. NO: No documents must be created.

  2. Create return transmission of type CREATE_DOCUMENT to initiate Reference - IOM Document Creation Business Process. Also, refer to IOM Document Transmission Status Model.

  3. Return notification should be sent to the order capture channel? According to the configuration of the order capture channel, this processes determines if a return notification should be sent to the order capture channel.

    1. YES: A return notification will be sent to the order capture channel.

    2. NO: No return notification will be sent to the order capture channel.

  4. Create return transmission creates a return transmission of type SEND_RETURN.

  5. Send return notification. The return notification will be sent to the order capture channel.

  6. Receive return notification. The return notification will be captured and processed by the order capture channel.

  7. Set return CLOSED. Finally, the return is set to the status CLOSED to indicate that the return processes are finished.

Exceptions

In case of exceptions, the processing stops and the errors must be solved. After the errors have been solved, the process is continued automatically by the control app.

More

Extension points

  • Queues: CloseReturnQueue, ReturnTransmissionRequiredQueue

  • Statuses: DO_PREPARE_DOCUMENT, PREPARED_DOCUMENT, DO_CLOSE, CLOSED (refer to IOM Return Status Model)

Related processes

Order Cancelation Process

Introduction

The Order Cancelation Process captures cancelation requests for an order, order position(s), or units, e.g., from the commerce management system, determines if the order is still cancelable, and initiates further processing based on the state of commissioning of the order. If already commissioned to fulfillment location(s), a recall will be created, otherwise the order will be canceled directly in IOM.

Boundaries

The Order Cancelation Process starts with a cancelation request via API and normally ends with a canceled order (IOM or fulfillment location). If not, the order will be shipped to the customer and the customer should deny the shipment.
The process ends by a created return message (refer to IOM Return Status Model) or an order transmission of type SEND_ORDER_RECALL in status PROCESSED. Refer to IOM Order Transmission Status Model.

Process Flow

Commerce Management System

  1. The order cancelation call will be initiated by the user of the commerce management to cancel an order, position, or unit.

  2. Receive cancelation response

Intershop Order Management

  1. Receive order cancelation. The IOM receives the order cancelation call and initiates the cancelation process for the canceled order lines.

  2. Order positions already passed to fulfillment location(s)? Initiate the proper cancelation process based on the fulfillment state of the order position(s).

    1. YES: The order position is already passed to the fulfillment location. A recall request must be created and forwarded to the fulfilment location.

    2. NO: The order position has not been passed to the fulfillment location yet. The positions can be canceled in IOM.

  3. Create new return. A new return will be created of type RECALL. The newly created return will be processed by Return Capture, Validation and Approval Process.

  4. Create recall transmission. A new transmission of type SEND_ORDER_RECALL is created and processed by the transmission process.

  5. Send cancelation response. The response of the cancelation will be sent to the order capture channel to inform which position is canceled directly and which position must be recalled from the fulfillment locations.

Fulfillment Location

  1. Check fulfillment status of the order - order is cancelable?

    1. YES: The order can be canceled.

    2. NO: The order cannot be canceled because it is shipped or currently in the pick and pack process.

  2. Send dispatch notification. A dispatch notification will be sent and processed by the Dispatch Capture, Validation and Announce Process.

  3. Send return message of type RECALL. A return message of the type RECALL will be sent by the fulfillment location for the canceled items and processed by the Return Capture, Validation and Approval Process.

Exceptions

In case of exceptions, the processing stops and the errors must be solved. After the errors have been solved, the process is continued automatically by the control app.

More

Related processes

Disclaimer
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.
The Intershop Knowledge Portal uses only technically necessary cookies. We do not track visitors or have visitors tracked by 3rd parties. Please find further information on privacy in the Intershop Privacy Policy and Legal Notice.
Home
Knowledge Base
Product Releases
Log on to continue
This Knowledge Base document is reserved for registered customers.
Log on with your Intershop Entra ID to continue.
Write an email to supportadmin@intershop.de if you experience login issues,
or if you want to register as customer.