Welcome to Intershop Order Management 4
Intershop Order Management (IOM) is an application of the Intershop Commerce Platform that is designed to combine omnichannel commerce processes into one system. It automates and streamlines the life cycle of orders and payments. IOM processes orders from multiple touchpoints (webshop, mobile shop, call center, etc.), allocates them to multiple fulfillment solutions (fulfillment centers, drop-ship distributors, physical stores, etc.), and tracks all orders and payment transactions.
IOM offers a centralized platform for managing distributed inventory, order, invoice, and payment life cycles, and provides call center functionality, enabling real-time visibility for customers' purchasing behavior, stock levels, payments, etc. As part of the Intershop Commerce Platform, it utilizes the platform's transaction, PIM, and merchandising features.
IOM 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.
Overview - IOM Interfaces and Overview - Intershop Order Management REST API
Overview - IOM Connector to connect Intershop Commerce Management with IOM
Setup Operate Intershop Order Management (GitHub)
Docker images iom:4.4.0 (Harbor) and iom-dbaccount:1.6.0 (Harbor)
Helm charts Release iom-2.3.0 · intershop/helm-charts
Intershop Order Management 4.4 is based on WildFly 27.
Besides support of Jakarta EE 10, WilfFly 27 comes with a lot of additional component updates. For required migrations refer to Guide - IOM 4.3 - 4.4 Migration.
One or more contact persons can be added to a return request now. Additionally, ContactPerson
was refined in attributes lastName
, emailAddress
, and language
. For details, refer to Reference - IOM REST API - RMA 2.11
In the back office, the contact persons on the related return request are shown now too.
A new database job that deletes old entries from JobRunHistoryDO
is available now. It is enabled by default. See Reference - Database Jobs.
A partial cancelation of an order in initial state prevents further processing (82046)
Back office: address edit has no prefilled correct country (required) if not configured for the shop (63522)
Back office: broken design in role management - edit permission assignment (81508)
Back office: customerNo/shop not populated in invoice details for deleted customers (77980)
Back office: editing product details page - shopArticleNo has a limitation of 30 characters (79794)
Back office: inconsistent alignment of payment notification data on the order details page (58374)
Back office: names of documents are interspersed with blanks (77077)
Back office: unable to save inventory level without pricing per unit selection on product detail page, but UI gives no hint (81539)
CheckReturnPCBean fails during processing of manually approved cancellations/returns (81449)
Choosing position items upon cancellation and return is not done in proportion to the canceled tax amount (75234)
Embedded Initiator/InitiatorDefDO persisted as ordinal value instead of id (82044)
Initial dump cannot be loaded (80870)
Invoice aggregation job is too slow (81093)
Log level ERROR is too high for authorization failures (79581)
Logical error in SalesPricePosCalculatorBean (81323)
Missing discounted value in SubTotal is not calculated correctly (81158)
Order level promotion must not lead to negative prices during order position item splitting (81809)
REST API order: creating an order with unknown SKU and syncr. SKU validation misses error message in HTTP 400 (79793)
REST API order: order-states operation raises NullPointerException if reduce reason is not configured (80908)
REST API RMA: approval has undocumented constraint - comment is required when declining a return request (78323)
REST API RMA: no option to add contact persons (but to retrieve them) (81312)
REST API RMA: undocumented contraints in ContactPerson (lastName, emailAddress, language) (81347)
REST API RMA: YAML example values mixing type RETURN + pickupAddress (78213)
Unintended initial value in PromotionLO (80980)
User session breaks in application server restart (80538)
Rounding errors expected when computing totals from tax rate if not given on order creation (80799)
Setup Operate Intershop Order Management (GitHub)
Docker images iom:4.3.1 (Harbor) and iom-dbaccount:1.6.0 (Harbor)
Helm charts Release iom-2.3.0 · intershop/helm-charts
The IOM back office now supports the login using an identity provider (Azure Active Directory or Keycloak). If configured, the login page shows a button that connects the user with the identity provider. For more information refer to Concept - IOM Single Sign-on and Cookbook - IOM Global Business Configurations.
Additionally, there were several adjustments on the user profile and user detail pages related to the new authentication method single sign-on. Also, refer to the online help Intershop Documentation Center | IOM 4.3.
The configuration of the export of SalesOrders and PurchaseOrders XML files for debtor management systems has been split to be more flexible. Please refer to Guide - IOM 4.2 - 4.3 Migration.
For custom RMA approval rules, decision beans are now supported. Please refer to Concept - IOM RMA Business Process and Cookbook - IOM RMA Business Process.
Migration Scripts for IOM versions < 3.0 should not be required anymore and have been moved to the archive folder.
Shop2Supplier2ApprovalTypeDefDO doesn't consider decision beans for return announcements (78651)
Deployment impossible due to unpersisted enum (79691)
Invalid SQL trigger functions (has_invoicing2orderdo_order_trf, has_invoicing2orderdo_invoice_trf) (79813)
Transmission search for invoice emails by invoice number fails (80091)
Reservation API does not work when the shop hierarchy is more than two levels (80101)
Order level discounts on the positions are different in the back-office/PDF when using SOAP vs REST order creation (80529)
User session breaks in application server restart (80538)
Rounding errors expected when computing totals from tax rate if not given on order creation (80799)
InitiatorDefDO persisted with ID but retrieved via the ordinal number (82008)
Attention: Due to a bug in IOM versions >= 3.5.0.0 < 4.3.4 it is possible that some database entries have a wrong reference to the Table InitiatorDefDO
. To prevent lengthy downtimes during the upgrade, the script necessary to fix this data has not been included in the automatic DBMigrate process. Instead, it has to be executed manually after the deployment of IOM >= 4.3.4.
There is no need to execute this script immediately after the deployment. It can be executed the next day or during a low-traffic period. Please execute the script using a tool of your choice (e.g. psql, DBeaver):
create or replace procedure admin.fix_initiator(tablename varchar, ts_column varchar, ts_lower timestamp without time zone, ts_upper timestamp without time zone) as $$ DECLARE step_identifier varchar; BEGIN step_identifier = '#82044: fix values in table ' || tablename; IF NOT admin.dbmigrate_is_step_applied(step_identifier) THEN raise notice 'fixing values on table %', tablename; execute 'update "' || tablename || '" set "initiatorDefRef" = case "initiatorDefRef" when 4 then 5 when 5 then 7 when 6 then 8 when 7 then 9 else "initiatorDefRef" end WHERE "' || ts_column || '" > ''' || ts_lower || ''' and "' || ts_column || '" < ''' || ts_upper || ''' and "initiatorDefRef" in (4, 5, 6, 7)'; PERFORM admin.dbmigrate_register_step(step_identifier); ELSE raise notice 'skipping table %, already registered migration step.', tablename; END IF; COMMIT; END; $$ language plpgsql; DO $$ DECLARE ts_column varchar; ts_lower timestamp; ts_upper timestamp; tbl varchar; idx_stmt varchar; tables_to_fix varchar[] := ARRAY['ApprovalResponseStateHistoryDO', 'DispatchStateHistoryDO', 'DispatchTransmissionStateHistoryDO', 'DocumentStateHistoryDO', 'DocumentTransmissionStateHistoryDO', 'EventControlStateHistoryDO', 'InvoicingStateHistoryDO', 'InvoicingTransmissionStateHistoryDO', 'OrderCancelStateHistoryDO', 'OrderChangeRequestStateHistoryDO', 'OrderNoteDO', 'OrderPosStateHistoryDO', 'OrderStateHistoryDO', 'OrderSupplierEvaluationStateHistoryDO', 'OrderTransmissionStateHistoryDO', 'PaymentNotificationStateHistoryDO', 'PaymentNotificationTransmissionStateHistoryDO', 'ProcessControlStateHistoryDO', 'ResponseStateHistoryDO', 'ResponseTransmissionStateHistoryDO', 'ReturnAnnouncementTransmissionStateHistoryDO', 'ReturnRequestStateHistoryDO', 'ReturnRequestTransmissionStateHistoryDO', 'ReturnStateHistoryDO', 'ReturnTransmissionStateHistoryDO', 'ShopCustomerMailTransmissionStateHistoryDO']; BEGIN ts_lower = (SELECT COALESCE((select ((logtime at time zone (SELECT current_setting('TIMEZONE')))::timestamp without time zone)::varchar FROM admin.migration_log WHERE script LIKE '%3.5.0.0_001.sql' ORDER BY logtime ASC LIMIT 1), '1999-01-01 00:00:00.000')); ts_upper = ((select ((logtime at time zone (SELECT current_setting('TIMEZONE')))::timestamp without time zone)::varchar FROM admin.migration_log WHERE script LIKE '%4.3.4_001_82044.sql' ORDER BY logtime ASC LIMIT 1)); raise notice 'selected timeframe: % to %', ts_lower, ts_upper; if ts_upper is null then raise exception 'did not find *4.3.4_001_82044.sql in migration log - did you already deploy IOM > 4.3.4 before running this script?'; end if; FOREACH tbl IN ARRAY tables_to_fix LOOP call admin.fix_initiator(tbl, 'timestamp', ts_lower, ts_upper); END LOOP; -- separate step for CustomerContactDO due to different column name tbl = 'CustomerContactDO'; call admin.fix_initiator(tbl, 'contactDate', ts_lower, ts_upper); END $$; drop procedure admin.fix_initiator(varchar, varchar, timestamp, timestamp);
Getting HTTP timeout when sending certain orders (81574)
Invoice aggregation job is too slow (81093)
Initial dump cannot be loaded (80870)
Setup Operate Intershop Order Management (GitHub)
Docker images iom:4.1.0 (Harbor) and iom-dbaccount:1.5.0 (Harbor)
Helm charts https://github.com/intershop/helm-charts/releases/tag/iom-2.2.0
A new version of the transmission REST API is available, which introduces improved search and update options. Refer to Reference - IOM REST API - Transmissions 2.0 and Overview - Intershop Order Management REST API.
Based on this new version, the back office has been enhanced and supports the same options in the transmissions section too.
To show existing change requests and their status, the list of order change requests of an order is now shown on the order details page. Also, refer to Concept - IOM Feature Toggles of OMT.
In order to better support monitoring of the application, the IOM now supports over 20.000 metrics of the WildFly application server in the Prometheus format. For more detail see iom/helm-charts/Metrics.rst.
The following infrastructure components were updated:
WildFly was updated to version 26.1.2.Final
IOM now uses Adoptium OpenJDK 17.0.4.1+1
OrderMapperOutBean_v1_1.java
now offers the static constant OrderMapperOut.LOGIC_ORDERMAPPEROUT_V1_1
to support the JNDI lookup more easily.
Due to the fact that approval preconditions (e.g. credit limit) may change over time, this has led to inconsistent behavior in the approval process in some rare cases.
With IOM 4.2 approval rules will not be executed for the second time again. IOM will only consider existing OrderApprovalReasonDOs
/ApprovalResponseDOs
and respect the selected approval/rejection accordingly.
Manual credit note requests fail due to too many order positions in the back office (76748)
Commodity group search is broken in the back office (76992)
Manual credit note on aggregated invoices: the credit note is mapped to all invoice's orders (77348)
Warning log full with: bakery.logic.job.file.FTPFileTransferBean finished successfully, but the success wasn't registered at JobStateDefDO (77413)
CloseInvoicingPCBean repeatedly failing but unable to analyze because it does not tell which row is affected (77835)
Race conditions + suppressed exceptions in invoice calculation (78002)
OrderMapperOut's JNDI binding does only supports StoreOrder 1.0, but not 1.1 (78363)
ShopDO.getEventRegistryEntryList() is not thread-safe (78501)
Rejecting an order approval may lead to an order being approved anyways (78613)
Stock import can't handle empty files despite ImportConfigurationDO.canDatapackBeEmpty being set to true (78734)
Missing unique constraint on Supplier2ReturnReasonDefDO (78957)
Deployment impossible due to unpersisted enum (79691)
Setup Operate Intershop Order Management (GitHub)
Docker images iom:4.1.5 (Harbor) and iom-dbaccount:1.5.0 (Harbor)
Helm charts Release iom-2.1.0 · intershop/helm-charts
IOM 4.1. supports the usage of Azure PostgreSQL Flexible Server. These changes require the usage of iom:4.1.0 (Harbor) and iom-dbaccount:1.5.0 (Harbor).
The following infrastructure components were updated:
Wildfly was updated to version 26.1.0.Final
IOM now uses Adoptium OpenJDK 11.0.15+10
IOM Docker images are now based on Ubuntu 22.04
Exports to accounting/debtor management systems can now be enabled for specific use cases instead of using a “global” switch. See migration notes for details.
"Returns"-tab in the back office might break in case of invalid/unprocessed returns (71213)
Setting root certificate for db is failing (75373)
Potential vulnerability in the back office needs to update spring framework to version to 5.3.18 (75697)
In back office, sorting orders on customer details page by date does not work (75763)
Copyright on start page is outdated (75786)
In back office, it's not possible to edit and save product data within the channel tab (75982)
In back office, it is not possible to modify the shop or supplier articleNo within the channel tab (75995)
Empty positions tab after a supplier action (75998)
Wrong treatment of fields street, streetName and houseNumber leads to repetition of house number in emails (76319)
Cancellation comment is not visible in back office anywhere (76380)
The creation user not shown for credit note (76384)
Logic to reduce stock on order export ignores canceled items (76496)
Accepting orders via SOAP API fails with promotion rounding error (79366)
Accepting orders via SOAP API fails with promotion rounding error (79366)
Support (optional) minimum date to consider when aggregating invoices (77851)
Database error during the migration from older versions (commenting on trigger) (77545)
InvoiceAggregationIntervalDefDO is not prepared with migration scripts (77579)
The database function process_article_aggregation fails after migrated to iom/4.1.2 (77708)
CloseInvoicingPCBean repeatedly failing but unable to analyze because it does not tell which row is affected (77835)
Race conditions + suppressed exceptions in invoice calculation (78002)
Manual credit note on aggregated invoices: the credit note is mapped to all invoice's orders (77348)
Warning log full with: bakery.logic.job.file.FTPFileTransferBean finished successfully, but the success wasn't registered at JobStateDefDO (77413)
java.lang.ArithmeticException: Rounding necessary when trying to view invoice (77212)
LazyInitializationException when trying to transmit an order (77230)
REST ReservationService.createReservation raises 500 if configured OrderSupplierEvaluationRuleDefDO #6 (Delivery due date) for a shop (77231)
Setup Operate Intershop Order Management (GitHub)
Docker images docker.intershop.de/intershophub/iom:4.0.0 and docker.intershop.de/intershophub/iom-dbaccount:1.4.0
Helm charts 2.0 helm/iom (JFrog)
From now on IOM consists of a single Docker image only. The IOM application- and config images were merged into a single image. This change reduces operational efforts in the Intershop Commerce Platform since it becomes possible to trigger deployments by simply pushing an image. These changes require the usage of IOM Helm charts 2.0.0 and devenv-4-iom 2.0.0
Beginning with IOM version 4, execution of database initialization steps is tracked internally in granularity of:
execution of stored procedures
execution of migration scripts
execution of configuration scripts
If one of these steps has already been executed, it will be automatically skipped unless changed according to the SQL code. This will result in a shorter upgrade time in many cases, especially when rolling out new project versions.
The following infrastructure components were updated:
Wildfly was updated to version 26.0.1.Final
IOM now uses Adoptium OpenJDK 11.0.14+9
Project2docker, the successor of caas2docker (see migration notes), is now upgrading the base OS of project images whenever a new project image is built. This ensures, that project images always include the latest changes on OS level. Especially for security fixes, this is very important.
Project2docker now provides the configuration variable UBUNTU_MIRROR_X86
to define a mirror server for Ubuntu distribution and ports. Since default Ubuntu servers are sometimes overloaded and slow, the definition of a mirror makes the image-building process faster and more reliable.
The usage of JRE instead of JDK by IOM Docker images decreases the image size by about 150MB. A decreased image size leads to decreased resource consumption when running IOM in Intershop Commerce Platform or locally in devenv-4-iom.
Using the custom-block in order position row breaks the left alignment of common-block (71959)
"<" and "!=" used for object comparison in SalesPriceCalculatorUtilBean (72348)
RMA uses wrong shop-name in back office #2 (72901)
HTTP-201 is incorrectly documented a the return code for update transmissions endpoint (73604)
Email functionality broken when using alphanumeric bucket identifiers (73792)
User management + transmissions API unusable (74244)
RMA, Dispatch and Response Transmissions broken (74245)
Product import fails because of ArticleDO with same supplierArticleNo (74484)
PromotionDO recalculated values are not updated on cancellations (75117)
It is possible to register a same tax and location with overlapping time limits in TaxDO (75186)
Dispatch validation with unknown items causes NPE (75204)
Order REST API deliveryDate mapping mismatch. (75213)
Random shipping address assigned to invoice documents - intermediate fix (75321)
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.