1 Introduction

Welcome to Intershop Order Management 2.15!

Intershop Order Management (IOM) is an Intershop Commerce Suite application that is designed to combine omni-channel commerce processes into one system. It automates and streamlines the life cycle of orders and payments. Intershop Order Management processes orders from multiple touch points (web shop, mobile shop, call center and more), allocates them to multiple fulfillment solutions (fulfillment centers, drop-ship distributors, physical stores and more), and tracks all order and payment transactions.

Intershop Order Management offers a centralized platform for managing distributed inventory, order, invoice and payment life cycles, and provides call center functionality, enabling real-time visibility into customers' purchasing behavior, stock levels, payments, and more. As part of Intershop Commerce Suite, it utilizes the suite's transaction, PIM and merchandising features.

Intershop Order Management offers the possibility to tailor your business models as flexible and free as you need and depict them in your e-commerce environment. The order management system adjusts the order processing for various sales channels and suppliers and can be seamlessly integrated with existing components of your IT environment.

1.1 Dependency Version Information

1.2 Glossary

2 General Information

• Feature List - Intershop Order Management 2.15
• System Requirements - Intershop Order Management 2.15
• Guide - Intershop Order Management - Technical Overview
• Guide - Setup Intershop Order Management 2.15
• Guide - IOM Database Migration (2.0 - 2.17)
• Overview - IOM 2.14 - 2.15 Migration

3 Additional References

• Public Release Note - IOM Connector 6.0
  
• Overview - IOM Interfaces
• Overview - Ansible4IOM
  and
• Overview - Intershop Order Management REST API
• Reference - IOM Transmission Statuses
• Reference - IOM Order Statuses
• Reference - IOM Schedule Jobs

4 New Features and Enhancements

Enhancements of the User Interface OMT

Run Actions on Transmissions

Next, to the search for transmissions, processes on transmissions can be triggered now. I.e., to send information to another system, that wasn't available for a certain time.

The first picture is showing two selected transmissions of type MAIL (e-mail), that should be resent to the customer. The second picture is showing the status of the bulk action that triggered the resend of the selected transmissions.

Also, see Reference - IOM Transmission Statuses, to find out which processing statuses could be reached for the different transmission types. For more details about the transmission's REST-API see IOM REST API - Transmissions.

Resend Invoice Transmissions

To resend transmissions of type invoice, the status model was enhanced. Please see IOM Invoice Transmission Status Model.

Stuck Order Count - Orders that have to be checked manually

As an important number, the count of orders that are in status Order has to be checked manually, was added to the overview widget. This status will be reached for several reasons and stops the processing of the order.
Reasons could be i.g. faulty order data, wrong product references, missing stock or/and a failed supplier assignment or others.

With this number, it's possible to identify stuck orders faster and easier, before the customer calls because of a problem.

Also, see Reference - IOM Order Statuses.

Enhancements in Setup and Operations

Upgraded the Postgres JDBC-driver to 42.2.6

The Postgres JDBC-driver was updated to 42.2.6.

Also, see https://jdbc.postgresql.org/download.html.

Extend ScheduleDO with an "internal" flag

Triggers prevent the deletion of core-schedules, but you can deactivate non-required ones.

An additional flag isCoreSchedule has been added to the table ScheduleDO. It is set to true for all these core-schedules.

You may adjust your queries using the flag.

Also, see Reference - IOM Schedule Jobs.

Interfaces

Extended REST-API for RMA

The REST-API for RMA-process was extended by two new endpoints:

• /shops/{shopName}/orders/{shopOrderNumber}>/return-requests/returnables, which returns all positions which can still be returned back.
• /shops/{shopName}/return-reasons, which returns all return reasons that are allowed for the related shop.
  Both endpoints are required to create (POST) new return requests using the existing endpoint /shops/{shopName}/orders/{shopOrderNumber}/return-requests.
  The specification can be found in the delivery doc/REST/intershop-order-management-rma-2.10.yaml.

For more information also see Overview - Intershop Order Management REST API.

New REST-API for Order State

A new REST-API for order states is available. The API can be used, e.g., to search orders of a specific state. It can be seen as an enhanced replacement for the existing SOAP-service.

The specification can be found in the delivery doc/REST/intershop-order-management-order-state-1.0.yaml.

For more information also see Overview - Intershop Order Management REST API.

Resend Invoice Transmissions and Issues when using generated Clients  for Transmission Updates

To resend transmissions of type invoice, the status model was enhanced. Please see IOM Invoice Transmission Status Model.

As the specification contains a small typo it wasn't possible to update transmissions using generated clients. This was fixed with doc/REST/intershop-order-management-transmission-1.1.yaml.

Please also see above for transmission enhancements at the user interface (OMT).

5 Setup & Configuration

For installation instructions please see:

• System Requirements - Intershop Order Management 2.15
• Guide - Intershop Order Management - Technical Overview
• Guide - Setup Intershop Order Management 2.15

Please note that the installation requires installed and preconfigured:

• JDK 11
• WildFly 17
• Postgres 11

6 Interfaces

For a complete list of all interfaces please see Overview - IOM Interfaces and Overview - Intershop Order Management REST API.

6.1 Deprecations

6.2 Removals

7 Fixed Defects