Description Actual behavior When you're having a lot of backoffice users registered in IOM, creating new suppliers via SQL configuration becomes extremely slow. The runtime seems to increase exponentially. Expected behavior Lower performance impact - linear increase in runtime Business impact Increased

Description Steps to repeat: Create an order that has the following properties via the Order API 2.1: Shipping charge (or any other charge) with value > zero so that the subtotal and total tax amounts are different. Expected behavior The subtotal tax values are stored as passed to the API. Actual behavior

Description When creating a manual credit note for a B2C order that has an order charge, e.g. shipping fees, the net values of the order charge are updated incorrectly and potentially end up showing negative values. Steps to Repeat Preconditions: Shop with invoice creation. The below will focus on invoices

Description We are trying to set up a process where all returns are going to a dedicated returns warehouse/supplier. The supplier is not necessarily connected to the order, meaning it did not ship the items etc. When a document (return label in this case) is created for the return warehouse it does not

Repro Steps 1) can be reproduced by adding a custom job with a long runtime (Thread.sleep) 2) can be reproduced by stopping the database or terminating the connections Actual Behavior 1) When a scheduled job runs longer than the time configured at "expectedRuntime", JobHandlerBean will log warnings and

Description When trying to import "fixed" product data after importing "wrong" product data, these updates may lead to completely inconsistent product data when said products are delivered by multiple suppliers. Repro Steps Products: First batch PROPER_PRODUCT_SUPPLIER_A: manufacturerArticleNo = 'MAN_A'

Description Supplier may theoretically be allowed to see only part of the position, but currently they get a permission denied when they try to access/view positions from such orders. ticket 65515 has fix a 'permission leak'; before it user could have more permission then actually defined: The old trigger

Description When a job takes a lot of time, bakery.control.job.Timer is stuck in a blocking call awaiting the job to finish. Due to the singleton pattern / EJB scheduler the Timer is not fired anymore which basically prevents all other jobs from firing until the blocking call has finished. Repro Steps

Description There are multiple performance issues when handling large orders (e.g. 700-1000 items). So far these issues have been identified in a testorder with > 700 items: Order creation (REST) is slow -> 30s opening order details page in OMT --> 120s-180s Order history (REST) -> 30s RMA (REST) ->

Description [No Description]Actual Behavior After switching from self-hosted to a managed postgres instance in Azure, import performance dropped significantly for *small* files. Example: on a local environment it takes about 300ms to import an inventory file with 2 products, on a managed instance small

Description Order withh 1000 positions cannot be dispathed from the OMT : org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.RuntimeException: io.undertow.util.ParameterLimitException: UT000047: The number of parameters exceeded the maximum of

Description [No Description]Actual Behavior An Exception can occure during the order calculation due to a wrong usage of BigDecimal.setScale: ArithmeticException: Rounding necessary at OrderCalculationLogicBean.calculateOrderPosItemPromotions(OrderCalculationLogicBean.java:260) Expected Behavior Add

Description [No Description] null Bug null Verified Closed Major AdoWorkItem 65744 Continous Integration (CI) Products Intershop Order Management Fixed in Commit iom/3.4.6.0 iom/3.4.7.0

Description The issue has been found while analzing severe performance issues on a production system. Those indexes have been addded: CREATE INDEX IF NOT EXISTS "index_OrderPosTaxDO_orderPosRef" on oms."OrderPosTaxDO"("orderPosRef"); CREATE INDEX IF NOT EXISTS "index_OrderChargeTaxDO_orderChargeRef"

Description [No Description]Actual Behavior Opening the details of a given order position within the OMT is very slow. Expected Behavior Fix the underlying query and remove the method call if these data are really unused. null Bug null Verified Closed Major AdoWorkItem 65559 Products Intershop Order

Description [No Description]Actual Behavior 1) When required, an order position is splitted in sub quantities (aka OrderPosItemDOs) with slighly different price information in order to allow partial returns or cancellations without getting price differences in the sum, due to rounding issues. 2) Order

Description Steps to repeat: Create an order that has the following properties via the Order API 2.1: Shipping charge (or any other charge) with value > zero. The charge needs to have two or more tax lines attached to it. Both tax lines need to have a value > zero. Expected behavior The charge taxes

Description current behavior The order-level promotion prices are not distributed on the orderPosDOs, but directly on the OrderPosItemDO as item price and with a rounding on cent values (no handling of possible rest amount). e.g 2.747 /2 -> 1.37 as item amount, and 1.37*2 = 2.74 although 2.747 should

Description Actual behavior: REST API returns StatusCode 400 (Bad Request). An exception can be found in the log file as shown below. Expected behavior: Order is created in IOM. Steps to repeat: Setup IOM environment with version 3.4.3.0 Try to import order that has two or more different taxes on any

Description Actual behavior When creating an order via order rest API and a default ICM address model you'll get the following data in OrderAddressDO street: NULL streetName: street + houseNo houseNumber: NULL Expected behavior street is always present if streetName/houseNo are not both filled Impact