4.1 Enhancements of the User Interface OMT

4.1.1 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.

4.1.2 Resend Invoice Transmissions

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

4.1.3 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.

4.2 Enhancements in Setup and Operations

4.2.1 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.

4.2.2 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.

4.3 Interfaces

4.3.1 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.

4.3.2 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.

4.3.3 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).