Introduction

The Response Business Process captures and processes response notifications from a 3rd party system. In general, this process is used to exchange, confirm or update order related data, which can include multiple response notifications for the same order. This process covers the response capture, validation and processing according to the standard processes.

Boundaries

The Response Business Process starts with an order response captured by the standard API and ends normally with an order response notification announced to the order. Optionally, delivery and/or return documents are recreated and the order response is submitted to the order capture channel.
The process ends by reaching the status CLOSED. Refer to Response State Model.

Process Flow

1. The Response Capture and Validation Process captures the response notification from a 3rd party system. After the response is captured, the missing fields are added by this process and the response is validated against pre-defined business rules to determine technical errors or deviations in purchase or sales prices, shipping dates or positions.

2. The Response Notification Process processes the approved response notification and announces the response notification to the corresponding order and order lines. If products are canceled in the response notification, it also initiates the cancelation process for the corresponding products.

3. The Finalize Response Process validates if delivery or return documents should be re-created because of the cancelation of certain products and initiates the submission of the recreated delivery- or return documents to the fulfillment location. The process also validates if response notifications should be sent to the order-capture channel and initiates the submission of the response notification. Finally, the process sets the response notification to the CLOSED status.

Introduction

The Response Capture and Validation Process captures a response notification from a 3rd party system, validates and checks the order response to ensure data integrity. Additionally, the process manages deviations between the order response and the order, e.g. changed purchase prices or cancellation of certain order positions.

This is necessary to check, because the fulfillment location can cancel positions by itself (missing stock, etc.) and, after all, approve the order response according to the predefined business rules.

Boundaries

The Response Capture and Validation Process starts with an order response captured by API and ends normally with a validated response in status INITIAL.
The process ends by reaching one of the responses statuses CHECKED or NOT_CHECKED. Refer to Reference - Response State Model.

Process Flow

1. Receive and store response notification in status INITIAL or CONTINUOUS. A 3rd party system passes a response notification in the status INITIAL or CONTINOUS via standard API.

2. Assign response notification to order by adding the shop order number to the response.

   1. OK: corresponding shop order number was found and assigned.

   2. FAILED: no corresponding shop order number was found. Initiate the escalation workflow to handle the error.

3. Unprocessed response notifications available?

   1. YES: the current response is set to the wait status until older responses are processed.

   2. NO: there are no older response(s), the process continues.

4. Prepare response and add missing data using the related order.

   • If the IOM product ID is missing, add the IOM product ID to the response.

   • If the order position reference number is missing, add the order position reference number to the response.
     Only response positions with a valid order position reference will be processed. Additional response positions without a valid reference will not be processed.

   • If the quantity is missing, add the quantity from the order position to the response position. This is the case when the 3rd party system is unable to send the quantity to the response.

   • If the shop is sending the same product in more than one order line and the 3rd party system is unable to process orders with the same product in more than one order line, the IOM will merge these order positions in one order position in the supplier order. If the 3rd party system provides a response notification to these merged order positions, the IOM must split the merged positions again to match the original order.

5. Processing sequence for response type available? Ensure that INITIAL responses are processed before a CONTINOUS response and older CONTINOUS responses are processed first.

   1. FALSE: there are other response notifications that must be processed before the current one. The response is set to the wait status until all previous response notifications are processed.

   2. TRUE: there are no older responses. The current one can be processed.

6. Validate response according to the defined business rules.

   1. NO ERRORS: the response was validated successfully.

   2. ERRORS: the validation detected errors (e.g. required fields are missing). Initiate the escalation workflow to handle the errors. The response must be handled manually to resolve the validation errors and will be ignored until the status is changed to CHECKED.

   3. PRICE OR SHIPPING DEVIATION: deviations in prices or shipping information are found.

7. Set the response to CHECKED and continue with Response Notification Process.

8. Error message should be sent to the fulfillment location?
   YES: a notification will be sent.
   NO: no notification will be sent.

9. Set response to NOT_CHECKED. This response must be handled manually and will be ignored until the status is changed to CHECKED.

10. Create and process e-mail notification — Set response to IN_EXTERNAL_PROCESSING. This response must be handled manually and will be ignored until the status is changed to CHECKED. Response transmission REQUEST_NEW_RESPONSE will be created and sent to the fulfillment location.

11. Handle errors ? (and set status). Errors are handled manually and the status must be set to DO_CHECK and will be picked up for validation again. Otherwise the status must be set to FAILED and end.

12. Manual response approval — Set response to NOT_CHECKED_DO_APPROVE. According to the response validation rules, the response must be approved manually by the order capture channel. Response transmission CONFIRM_RESPONSE will be created and an e-mail will be sent to the order capture channel to approve the response notification.

13. Approve response. The response will be approved, the order will be declined.

    1. Approved, the status must be set to CHECKED. The process continues with Response Notification Process.

    2. Declined, the status must be set to FAILED.

14. Create order recall transmission. To cancel an order with declined response notifications, the IOM sends a recall e-mail to the fulfillment location. Therefore, a transmission of type SEND_ORDER_RECALL will be created and sent.

Fulfillment Location

1. Send response notification INITIAL or CONTINIOUS to the IOM.

2. Receive notification and handle errors of the response (REQUEST_NEW_RESPONSE). The errors can be handled by sending a corrected Updated response or handling errors directly in IOM.

3. Cancel order and send notification (SEND_ORDER_RECALL). The fulfillment location tries to cancel the order and sends a cancelation notification to the OMS.

Order Capture Channel

1. Receive approval request (CONFIRM_RESPONSE). The order channel receives the approval request and accepts or declines the variations in the IOM.

More

Extension Points

• Queues: CheckResponseQueue

• Statuses

  • INITIAL, NOT_CHECKED, NOT_CHECKED_DO_APPROVE, IN_EXTERNAL_PROCESSING, CHECKED, FAILED (refer to Reference - Response State Model)

  • REQUEST_NEW_RESPONSE, CONFIRM_RESPONSE (refer to IOM Response Transmission Status Model)

  • SEND_ORDER_RECALL (refer to IOM Order Transmission Status Model)

Related processes

• subsequent Response Notification Process

Introduction

The Response Notification Process announces the response to the associated order and enriches this order with the confirmed values from the fulfillment location. Additionally, the process checks if the response contains canceled positions to trigger further processing.

Boundaries

The Response Notification Process starts with a validated response notification in status CHECKED and ends normally with an announced response notification and updated order position(s).
The process ends by reaching the status PROCESSED. Refer to IOM Response Status Model .

Process Flow

1. Announce response notification to order announces the response in status DO_PROCESS to the order. Selected information (quantityConfirmed, quantityBackordered, confirmedDeliveryDate, backorderedDeliveryDate, supplierConfirmedPurchaseItemNet (only for approved order response notifications) will be copied from the response notification to the corresponding order positions.

   1. ANNOUNCED: the announcement was successful.

   2. NOT_ANNOUNCED: the announcement failed.

2. Handle errors. Errors that lead to the erroneous announcement will be handled.

   1. FAILED: handling of errors failed. The process ends until the status will be set to DO_ANNCOUNCE.

   2. DO_ANNOUNCE: errors are handled, announcement repeats.

3. Response contains cancelations?

   1. YES: the response notification contains canceled positions.

   2. NO: the response notification does not contain canceled positions.

4. Create return with cancelation reason RCL020 (end of life). Refer to Overview - IOM Database Documentation, ReturnReasonDefDO

5. Response should be created for order capture channel? By configuration.

   1. YES: a response must be created for the order capture channel.

   2. NO: no response must be created for the order capture channel. Continue with Finalize Response Process.

6. Create response of type INITIAL or CONTINUOUS and continue with Finalize Response 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

Extension points

• Queues: ProcessResponseQueue

• Statuses: DO_PROCESS, DO_ANNOUNCE, ANNOUNCED, NOT_ANNOUNCE, FAILED, DO_RETURN, RETURNED, DO_COMPOSE_RESPONSE, COMPOSED, PROCESSED. For statuses refer to IOM Response Status Model

Related Processes

• subsequent Finalize Response Process

• on error Initiate Cancel Order Process

Introduction

The Finalize Response Process submits/exports an order response message to a 3rd party system. E.g. the shop has to be informed that the response is processed, or purchase prices have changed.

Boundaries

The Final Response Process starts with a response in status PROCESSED and ends normally with a closed response notification. In addition, order notifications may have been sent and/or delivery papers updated.
The process ends by reaching the status CLOSED. Refer to Reference - Response State Model.

Process Flow

1. Documents should be recreated? Based on the configuration processes.

   1. YES: the document creation process will be initiated

   2. NO: no documents must be created

2. Create response transmission CREATE_DOCUMENTS to initiate the document recreation process. Refer to Create Document Process.

3. Response notifications should be sent to the order capture channel? By configuration.

   1. YES: the created response notification must be sent to the order capture channel

   2. NO: none of the created response notifications must be sent to the order capture channel

4. Create response transmission to INITIAL or CONTINUOUS of type SEND_RESPONSE_INITIAL or SEND_RESPONSE_CONTINIOUS for the created response notifications to initiate the submission of the response messages.

5. Send response transmission to the order capture channel.

6. Set response to the status CLOSED to indicate that the response processes are finished.

Order Capture Channel

1. Receive response notification

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: PrepareDocumentResponseQueue, CloseResponseQueue

• Statuses: DO_PREPARE_DOCUMENT, PREPARED_DOCUMENT, DO_CLOSE, CLOSED. For statuses refer to Reference - Response State Model.

Related processes

• in addition Reference - IOM Document Creation Business Process