Introduction

The Order Business Process mainly controls the order capture and validation, the routing of orders to fulfillment locations, and the order approval.

Starting with capturing an order, the order will be validated and stored. Next, for the order, one or more fulfillment locations will be selected by defined rules. If approval rules are defined, the order will be checked according to these rules and must be approved in case the rule applies. If successfully approved, temporary responses and documents can be created, and the selected fulfillment locations will be informed about the new order.

Boundaries

The Order Business Process starts with an order being captured by the standard API and normally ends with the order being placed at the selected fulfillment location(s).
The process ends by reaching one of the order statuses COMMISSIONED, PARTLY_COMMISIONED or CANCELED. Refer to IOM Order Status Model.

Flow diagram

1. The Order Capture and Validation Process captures an order from a 3rd party system and validates the order synchronously or asynchronously.

2. The Order Routing Process determines possible fulfillment locations for an order position, evaluates the fulfillment location according to certain business rules to determine the best-suited location for fulfillment. If no fulfillment location can be identified, the order is canceled in case an automatic cancelation is configured.

3. The Order Approval Process identifies whether an approval process for the order should be started or not. By defined business rules, the approval process for an order is started by the IOM. If the order was denied, the order is automatically canceled by the IOM.

4. The Temporary Order Response Process sends a temporary order response to the 3rd party system, to inform the system about the assigned fulfillment location and the corresponding data. It is configurable in the IOM whether this message should be sent or not.

5. The Create Order Documents Process creates - if configured for the fulfillment location - the delivery slip, the return document, or the return label for a selected fulfillment location as a PDF document, and transfers the document to the fulfillment location.

6. The Order Submission Process submits the order to the selected fulfillment locations in the IOM standard API or in the API of the fulfillment location.

7. The Initiate Cancel Order Process initializes the return process to cancel an order or an order position.

Introduction

The Order Capture and Validation Process captures orders from 3rd party systems. It determines when orders are further processed by the IOM and it validates orders against certain business rules. Furthermore, configurable order validation rules will be executed synchronously or asynchronously.
For more information about configuring order validation rules, refer to Guide - IOM Shop Onboarding | Order Validation and Guide - IOM Order Business Process | Validate an Order.

Boundaries

The Order Capture and Validation Process starts with an INITIAL order captured by API and normally ends with a validated order.
The process ends by reaching one of the order statuses CHECKED or NOT_CHECKED. Refer to IOM Order Status Model .

Flow diagram

1. Submit order passes an order to the standard API for order capture.

2. Validate order against synchronous order validation rule validates an order according to the configured synchronous order validation business rules of the order capture channel.

   1. OK: The validation was successful.

   2. FAILED: The validation failed. A synchronous error acknowledgment is passed back to the order capture source.

3. Store order in INITIAL status stores an order with status INITIAL.

4. Check whether order should be processed with a delay checks whether the order should be set on hold for a defined time period or not.

   1. YES: The order is set on hold for later processing.

   2. NO: The processing of the order will continue.

5. Validate order against asynchronous order validation rules validates an order according to the configured asynchronous order validation business rules of the order capture channel.

   1. OK: The validation was successful.

   2. ERROR: The validation failed. The order is set into the status NOT_CHECKED and the errors must be handled manually.

6. Send customer e-mail notification sends an e-mail notification of the transmission type SEND_CUSTOMER_MAIL_ORDER to the customer to inform that the order was placed successfully .

7. In case validation fails the auto cancel cancels an order automatically if configured on the order capture channel.

   1. YES: The order cancel process is initiated.

   2. NO: The order is not canceled automatically. The errors must be handled manually.

8. Handle errors. If an order is in the status NOT_CHECKED, the order must be edited manually to resolve the validation errors.

   1. The validation error is resolved. The order is set to the status DO_CHECK, and the validation process will be called again.

   2. The validation error is not resolved. The order cancel process is initiated.

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: CheckOrderQueue

• Statuses: INITIAL, NOT_CHECKED, CHECKED, DO_CHECK (refer to IOM Order Status Model)

Related processes

• Subsequent Order Routing Process

• On error Initiate Cancel Order Process

Introduction

The Order Routing Process identifies and assigns fulfillment locations for an order. This process is also known as the Dynamic Order Supplier Evaluation (DOSE) process.

First, a rule-based identification of fulfillment locations is executed to identify which fulfillment locations are able to deliver one or more positions of an order. In the second step, certain fulfillment locations are assigned to the order positions by business rules.

If no fulfillment location can be assigned automatically by the business rules, a task is raised to manually assign a fulfillment location or to cancel the order in the back office. If no manual task should be raised, the order can be canceled automatically by the IOM.

Boundaries

The Order Routing Process starts when the order is placed and validated (statuses DO_ANNOUNCE, CHECK_ANNOUNCED), and normally ends with assigned fulfillment locations for each order position.
The process ends by reaching one of the order statuses OPTIMIZED or NOT_ANNOUNCED_DO_CANCEL. Refer to IOM Order Status Model and IOM Order Position Status Model.

Flow diagram

Get possible fulfillment locations

1. Get possible fulfillment locations for order positions. In this step all fulfillment locations where the product is listed are loaded and assigned to the sales channel for each order position.

2. Mark or add user selected fulfillment location. In the list of the loaded fulfillment locations, the fulfillment location that is passed in the order position is marked.

3. Mark or add preferred fulfillment locations. In the list of the loaded fulfillment locations, the preferred fulfillment locations that are configured in the IOM for the sales channel are marked.

Evaluate and select fulfillment locations

1. One or more fulfillment locations are found for each of the order positions? As a precondition for further processing at least one fulfillment location must be identified for the order positions.

   1. NO: No fulfillment location is available. The order position is set to the status NOT_ANNOUNCED. The order or order position is canceled or must be reviewed manually.

   2. YES: At least one fulfillment location is available. The process continues to evaluate the fulfillment location.

2. Process fulfillment location evaluation. The fulfillment location evaluation rules are executed to evaluate the conditions under which the fulfillment location is able to deliver.

3. Evaluate the result of the fulfillment evaluation rules. The result of the fulfillment location evaluation rules are evaluated to determine if the location is valid, must be approved manually in the back office, or if it is invalid.

   1. ANNOUNCED: The fulfillment location is valid and can be used during the order optimization process of the fulfillment locations. The order position status is set to DO_OPTIMIZE and the optimization process is started.

   2. NOT_ANNOUNCED: The fulfillment location is invalid (e.g. the product is end of life at the location). The location cannot be used by further processes. For one or more order positions no fulfillment location is found. The order position status is set to NOT_ANNOUNCED.

   3. CHECK_ANNOUNCED: The fulfillment location is invalid because the conditions under which the location is able to deliver are outside the defined scope of the tolerances. The order position status is set to CHECK_ANNOUCED. The order must be reviewed in the back office.

4. Automatic cancelation configured for sales channel. If the order or order position is in status NOT_ACCOUNCED and the automatic cancelation is configured for the sales channel, the order cancelation process is started for the order or order positions.

   1. YES: The automatic cancelation process for the order or order position is started.

   2. NO: The order must be reviewed in the back office.

5. Select fulfillment location¹ or cancel order position manually in the back office. If all fulfillment locations for one or more order positions are in the status CHECK_ANNOUNCED, the fulfillment location must be selected or approved manually in the back office. If an order or order positions are in the NOT_ANNOUNCED status and the order or order position is not canceled automatically, the order must be reviewed in the back office and canceled manually.

   1. CANCEL: The order or order position is canceled manually. This applies to orders that are in the status CHECK_ANNOUNCED and NOT_ANNOUNCED.

   2. Manual fulfillment selection: The fulfillment location for an order position is selected manually.¹

6. Start revalidation process to validate whether the data from the selected fulfillment location is still valid / have not deteriorated. This step is necessary because there could be a time gap between the manual selection of a fulfillment location and the last evaluation of that fulfillment location. Therefore, the data may have changed and the conditions under which the location is able to deliver could have deteriorated.

   1. NO: The conditions are deteriorated and the assignment must be reviewed.

   2. YES: The conditions are still the same or within the scope of the defined tolerances.

Optimize and select fulfillment locations

1. More than one fulfillment location is identified for one or more order positions. If more than one fulfillment location are valid for the order position, the order optimization process must be started to assign one fulfillment location to the order position.

   1. NO: Unique fulfillment locations are valid for each of the order positions. The order and the order positions are set to the status OPTIMIZED. The next process step is initiated.

   2. YES: Several fulfillment locations are valid for one or more order positions. The optimization process must be started.

2. Select fulfillment location according to the fulfillment location optimization rules. The optimization process is started to select a unique fulfillment location for the order position.

¹ _{Manual selection of a fulfillment location in the back office is not yet implemented.}

Exceptions

If the automatic assignment of a fulfillment location fails because there are no fulfillment locations available that are able to deliver the order position in the predefined tolerances, the order and order position status is set to CHECK_ANNOUNCED. In this case, the identified suppliers must be checked and assigned manually in the back office. This is also the case when no fulfillment locations can be identified for the order or individual order positions. In this case the order or order position is set to the status NOT_ANNOUNCED and the order must be canceled or edited manually in the back office. If the order or order position is in the status NOT_ACCOUNCED and an automatic cancelation is set for the sales channel, the order or order position is canceled automatically.

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: AnnounceOrderQueue, OptimizeOrderQueue

• Statuses: DO_ANNOUNCE, CHECK_ANNOUNCED, NOT_ANNOUNCED, NOT_ANNOUNCED_DO_CANCEL, ANNOUNCED, DO_OPTIMIZE, OPTIMIZED (refer to IOM Order Status Model and IOM Order Position Status Model)

Related processes

• Subsequent: Order Approval Process

• Previous: Order Capture and Validation Process

• On error: Initiate Cancel Order Process

Introduction

The Order Approval Process manages the approval process for an order. Based on the configuration for the sales channel, fulfillment locations, and the defined order approval rules, the process validates whether approval is necessary for the order and, if necessary, initiates the transfer of an approval request to 3rd party systems. The approval is able to handle sequential or parallel approval workflows.

The approval process is processed after the Order Routing Process. This is necessary because some information that is relevant for approval depend on the identified fulfillment location (e.g. sales prices or purchase prices). It is possible that the conditions under which a certain fulfillment location has been selected during the Order Routing Process have changed by the time the order is approved. For that reason, it is possible to define for each approval reason whether the order routing process should be processed again.

In a sequential approval workflow, the approval is processed step by step. The next approval step is only initiated when the prior step was approved. If approval was declined in one step, the process stops and the approval for the order is declined even when prior steps of the approval process are approved.

In a parallel approval workflow, the approval process waits until all approval messages have been received. If several external systems have to approve the order, the approval request is sent to all of them at the same time. As soon as all approval messages have been received, the approval process finally evaluates the result. If one of the approvers declined the approval, the complete approval of the order is declined.

The overall approval process is managed by approval reasons. IOM comes with a predefined set of approval reasons, but they can be extended as part of the customization of a project. To define an approval process for a sales channel, the approval reasons are assigned to the sales channel and the approver. The sequence in which the approval reasons must be processed is set by a rank of the approval reason. Refer to Guide - IOM Order Business Process. The approvers can be ranked in ascending order for a sequence flow. For a parallel flow, all approvers of that parallel flow will have the same rank. It is also possible to combine both types. To determine whether approval is necessary, it is possible to add an additional business rule to an approval reason. With the business rule, it is possible to start the approval process only for certain payment methods, for example. If no business rule is defined, the approval is initiated without any special conditions. It is also configurable for each approval reason whether an approval request must be sent to a 3rd party system. Each approval reason can be approved or declined in the back office.

Boundaries

The Order Approval Process starts when the order passed the Order Routing Process and is in the status DO_CHECK_ORDER_APPROVAL_REQUIRED. It ends with an approved or declined order.
The process ends by reaching one of the order statuses DO_PREPARE_RESPONSE or NOT_APPROVED. Refer to IOM Order Status Model.

Flow diagram

Initiate order approval

1. Order approval process should be initiated? It is evaluated whether an order approval is defined for that sales channel and the order matches an order approval rule of the current rank.

   1. YES: The order approval process for that order is initiated.

   2. NO: No order approval process is necessary. The order is passed to the next process step.

2. Start or continue approval process according to the order approval configuration. The order approval process is initiated for the current approval rank.

3. Approval request must be sent to 3rd party system? It is evaluated whether an approval request message must be sent to an external system.

   1. YES: The transmission of the approval message is initiated and the message is passed to the 3rd party system for approval. The process initiates the order transmission process to send the approval request to the 3rd party system.

   2. NO: No external approval is required. The order will be approved manually in the back office, or an approval message will be received from an external system (e.g., the payment service provider or fraud manager). An approval can also be initiated by a 3rd party system (e.g., the web shop). In this case, no approval response is sent by the IOM, but an appropriate approval process is initiated.

Order approval sources

• Business User. The order is approved by a business user in the back office of the IOM.

• 3rd Party System

  • Receive and process approval request. The 3rd party system receives the approval notification. The 3rd party system approves or declines the approval request.

  • Send approval message. The 3rd party system sends an approval message to approve or decline the order to the IOM. It is also possible that the 3rd party system sends an approval message without a prior approval request received by the IOM. In this case, the approval process is initiated via 3rd party system (e.g., web shop). If this process is used, the order approval rules in both systems (IOM and 3rd party) must be synchronized to ensure that an approval process is initiated in both systems accordingly.

Process order approval

1. Receive and store approval message. The approval message is received by the IOM. The approval message is validated and stored.

2. Check whether all approval messages are available for the current rank. The process checks whether all approval messages are valid and available. The next process step is initiated only in case all approval messages of a certain rank are available.

   1. NO: There are outstanding approval messages. The process waits until all approval messages of a certain rank are available.

   2. YES: All approval messages of a certain rank are available. The next process step is initiated.

3. Check approval status for the current approval rank. The process checks the approval stage of all approval messages of the current rank.

   1. APPROVED: All approval messages of the current approval rank are approving the order. The approval process continues.

   2. NOT_APPROVED: One or several approval message of the currents rank are declining the order. The approval process of the order will be interrupted and the cancelation of the order will be initiated.

4. Check whether the assigned fulfillment locations must be revalidated. During an approval process, the conditions under which a certain fulfillment location was selected during the order routing processes may have deteriorated. This process checks if the assigned fulfillment locations should be reprocessed to ensure that the assignments are still valid. It is possible to configure for each approval reason whether this process should be initiated or not.

   1. YES: The feature is enabled for the approval reason. The order routing process is initiated to revalidate the assigned fulfillment locations.

   2. NO: The feature is disabled for the approval reason. The approval process continues.

5. Check whether further approval ranks must be processed. This process checks if further approval ranks have to be processed during the approval process of the order.

   1. YES: The order approval process continues and the process step Order approval process should be initiated? is called again.

   2. NO: The approval process is finished. The order response process is called.

Exceptions

In case that the order will be approved by fulfillment locations, a complete cancelation of an order may not be possible, especially when more than one fulfillment location is involved in the processes. This is, for example, the case when only the positions assigned to a certain fulfillment location are rejected while another fulfillment location has approved other positions of that order.

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: CheckOrderApprovalRequiredQueue, OrderApprovalRequiredQueue, ApproveOrderQueue, CancelOrderApprovalQueue, ProcessOrderApprovalQueue

• Statuses: DO_CHECK_ORDER_APPROVAL_REQUIRED, ORDER_APPROVAL_REQUIRED, DO_CREATE_APPROVAL_TRANSMISSION, DO_APPROVE, APPROVED, NOT_APPROVED (refer to IOM Order Status Model)

Related processes

• Subsequent: Temporary Order Response Process

• Previous: Order Routing Process

• On error: Initiate Cancel Order Process

Introduction

The Temporary Order Response Process sends a temporary order response to the web shop or a 3rd party system to inform them about the current but temporary assignment of a fulfillment location. This response may also contain information regarding product availability, planned shipping date, purchase price, and the sales price for each order line item of an order.

During the lifecycle of an order, several order response messages are sent to the web shop or 3rd party systems. In general, two separated order responses are distinguished by the IOM processes: the temporary order response that is sent immediately after the order passes the order routing and order approval process, and fulfillment location-specific order responses. Refer to Reference - IOM Order Response Business Process.

The order response is temporary because the order response from the fulfillment location is still pending. The calculation of the planned shipping date is based on the availability provided by the fulfillment location. If the product is immediately available at the shipping location, but the cut-off time of the shipping at the fulfillment location is reached for that day, the next day is communicated as planned shipping date in the temporary order response.

It can be determined in the IOM sales channel configuration whether a temporary order response should be sent to the web shop, or to a 3rd party system.

Boundaries

The Temporary Order Response Process starts when the order is approved and is in the status DO_PREPARE_RESPONSE. Depending on the configuration a temporary order response message is sent.
The process ends by reaching the order status DO_PREPARE_DOCUMENT. Refer to IOM Order Status Model.

Flow diagram

1. Create temporary order response. The temporary order response is created by the IOM. During the creation, a new response object is created and filled with the data from the assigned fulfillment location, and some extra tasks are processed (e.g., the calculation of the planned shipping date).

2. Send temporary order response? Based on the configuration, it is determined if an order response should be sent to the 3rd party system.

   1. YES: The transmission process for the temporary order response is initiated.

   2. NO: The process ends by calling the next process step.

3. Send customer e-mail notification. An e-mail notification of the transmission type SEND_CUSTOMER_MAIL_RESPONSE_TEMPORARY is sent to the customer to inform that the order will be routed to the assigned fulfillment locations.

4. Process temporary order response message. The temporary order response message is processed by the 3rd party system.

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: PrepareOrderResponseQueue

• Statuses: DO_PREPARE_RESPONSE (refer to IOM Order Status Model)

Related processes

• Subsequent: Create Order Documents Process

• Previous: Order Approval Process

Introduction

The Create Order Documents Process identifies whether a delivery note, a return note, or a return label should be created for each of the fulfillment locations that are assigned to an order. After the identification of which documents are required, the Document Creation Business Process will be triggered.

Boundaries

The Create Order Documents Process is immediately started once the temporary order response is created and the order is in the status DO_PREPARE_DOCUMENT.
The process ends by reaching the order status PREPARED_DOCUMENT. Refer to IOM Order Status Model.

Flow diagram

1. Documents to be created for the assigned fulfillment locations or the web shop? Based on the configuration the process identifies whether documents should be created for the fulfillment location(s) or web shop of an order.

   1. YES: The process initiates the document creation process by creating an order transmission of type CREATE_DOCUMENT.

   2. NO: No documents have to be created.

2. Create order transmission of type CREATE_DOCUMENT. A new order transmission of type CREATE_DOCUMENT is created to initiate the document creation 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: PrepareDocumentOrderQueue

• Statuses: DO_PREPARE_DOCUMENT, PREPARED_DOCUMENT (refer to IOM Order Status Model)

Related processes

• Subsequent: Reference - IOM Order Business Process | Order Submission Process

• Subsequent: Reference - IOM Document Creation Business Process

• Previous: Reference - IOM Order Business Process | Temporary Order Response Process

Introduction

The Order Submission Process submits/exports an order to the selected fulfillment location(s) or a 3rd party system to inform them about an order to be fulfilled.

Boundaries

The Order Submission Process starts after the order has passed the document creation process and has the status DO_CREATE_TRANSMISSION. It ends normally with an approved or declined order.
The process ends by reaching one of the order statuses COMMISSIONED or PARTLY_COMMISSIONED. At least one order position has the COMMISSIONED status. The order will remain in the PARTLY_COMMISSIONED status until all positions are successfully submitted to the 3rd party system. Refer to IOM Order Status Model and IOM Order Position Status Model.

Flow diagram

1. Order is completely approved? This process counterchecks if an approval process is configured and the order is completely approved.

   1. YES: The process continues.

   2. NO: The process stops until the order is completely approved.

2. Create and process the order transmission for each of the assigned fulfillment locations. Creates and initiates the transmission of the order positions for the assigned fulfillment locations. This process looks up the transmission configuration and creates the transmissions for the configured partner. A partner could be the fulfillment location or any other defined 3rd party system. It is possible to define several transmissions for one transmission type for different partners, to create transmission to several 3rd party systems (e.g. the fulfillment location and one or several ERP or external systems). After the transmission for the target system is created, the processing of the transmission is initiated.

3. Push or pull messages? Checks according to the configuration how the order message is passed to the 3rd party system.

   1. PUSH: The order message is pushed to the external system using the configured message protocol and message type.

   2. PULL: The order message is pulled from the IOM by the external system via the configured message type.

   3. CANCEL: No order message is transferred.

4. Push synchronous or asynchronous? Determines if the message should be pushed synchronously or asynchronously to the external system.

   1. SYNCHRONOUS: The order message is pushed using synchronous communication (e.g. REST).

   2. ASYNCHRONOUS: The order message is pushed using asynchronous communication (e.g. sFTP).

5. Submit order to 3rd party system. The order will be pushed to a 3rd party system using a message transmitter that can be connected to the API of the 3rd party system.

6. Successfully submitted? Checks if the transmission was successfully submitted to the 3rd party system.

   1. YES: The process continues.

   2. NO: The transmission has not been successful and the message will be sent again.

7. Set order positions COMMISSIONED. After the order message has been successfully sent to the 3rd party system the status of the order positions is set to COMMISSIONED.

8. Store order on file system. The order is stored in the local file system to be processed by the job framework.

9. (PULL) Store order on sFTP. The order is transferred/stored on sFTP of the IOM to be pulled by a 3rd party system.
   If required, a file transformer can be configured in the job framework to transform the IOM message format into the 3rd party message format.

10. PUSH order to 3rd party system. The job framework pushes the order to the defined 3rd party system.

11. 3rd Party System (e.g. Fulfillment location or ERP)

12. Consume order synchronously. The order will be consumed synchronously.

13. Consume order asynchronously. The order will be consumed asynchronously.

14. Pull order from sFTP. The order will be pulled from sFTP of IOM.

Exceptions

• If the synchronous PUSH transfer fails, the transmission will be sent again for a certain time period over a number of attempts. If the submission still fails, the transmission is set to error status.

• If an asynchronous transfer job fails, the job is set to an error status.

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: TransmitOrderQueue

• Statuses: DO_CREATE_TRANSMISSION, CREATED_TRANSMISSION, COMMISSIONED, PARTLY_COMMISIONED (refer to IOM Order Status Model and IOM Order Position Status Model)

Related processes

• Previous: Create Order Documents Process

• On error: Initiate Cancel Order Process

Introduction

The Order Cancelation Process initializes the return process to cancel an order or an order position.

To cancel an order, the corresponding business process creates a cancelation object with the units or positions to cancel and the desired cancelation reason. The Order Cancelation Process prepares the true cancelation by the Order Return Process by creating a return object out of the cancelation object with the return type CANCEL. After the return object has been created, the Return Business Process is responsible for processing the return for the cancelation.

Boundaries

The Order Cancelation Process starts when an order cancelation is created in the status INITIAL and ends normally with a created return in the return status CANCEL.
The process ends by reaching one of the order cancel status RETURNED. Refer to IOM Order Cancel Status Model.

Flow diagram

1. Create cancelation. An order cancelation is created by the corresponding business process to initiate the order cancelation process.

2. Validate cancelation object. This process validates if the order cancelation is valid. This also includes the evaluation of the order status to determine if cancelation is still possible.

   1. OK: The process continues with the next step.

   2. FAILED: The process stops and the cancelation is set to the FAILED status.

3. Process order cancelation and create return in status CANCEL. A return to the status of CANCEL has been created because of the cancelation.

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: CancelOrderQueue

• Statuses: INITIAL, CANCEL, FAILED, RETURNED (refer to IOM Order Cancel Status Model, IOM Order Status Model, and IOM Return Status Model)

Related processes

• Subsequent: Reference - IOM Return and Cancelation Business Process is in preparation

• Previous: Order Capture and Validation Process

• Previous: Order Routing Process

• Previous: Order Approval Process