Description Actual behavior After creating a shop recall (e.g. RCL010) via ReverseService.cancelOrder, if the order is in transition between supplier assignment and transmission, the cancellation is processed immediately. This can lead to the situation that orders are canceled but still exported to the

Description Current Behavior: Address with country code of Åland Islands (AX) isn’t accepted by OMS on order export from shop Expected Behavior: Åland Islands is known to OMS and export is successful Steps to repeat: Select “<ns7:Country>AX</ns7:Country>” for shipping address in storeOrder request Export

Description Current Behaviour: When sending an invoice mail, the currency symbol is always null and it can't be used. Instead, I need to hard-code it or use the locale (which is btw. also not so useful often) Expected Behaviour: When printing prices I want to add always the currency symbol from userMailLO

Description TODO: ... when testing multiple currencies OrderStateSales.currency was not returned/ is null when debugging. No new version is required for the API/ yaml. Repro Steps TODO: ... when testing multiple currencies OrderStateSales.currency was not returned/ is null when debugging. No new version

Description current behavior some enum fields are allowed to be null, for example ExpandedDocumentTypeDefDO.rightDefRef. When changing such field to set them null in java, the next synchronization with the db, taking place on deployment, will ignore that change, letting the oldvalue within the DB. affected

Description Steps to repeat Create an order with one line item (quantity 1) and a 100% discount code on the line item. Send that order to the IOM Order Service (v1.2). or Create an order with a 100% discount on the order level. Send that order to the IOM Order Service (v1.2). Expected behavior: The order

Actual Behavior Trying to set an illegal cron expression result in a 200 or 500 response. (by PATCH). It should rather be a 400 , and it would be nice to have a hint in the error message... e.g.: PATCH http://{{server}}/rest/schedules/schedulestates/10072 Authorization: {{authorization}} Accept: {{schedulev1}}

Description Current behavior: some REST request with missing body get a response with an internal error statusr instead of a "bad request". relates to https://github.com/dropwizard/dropwizard/issues/232 Expected behavior: return a bad request status code Repro Steps Current behavior: some REST request

Description Current Behaviour: The tax summary used in the default invoice_credit_note_pdf.xslt corresponds only to the taxes of the order positions and do not include charge taxes. (A wrong variable is used in the template). Expected Behaviour: Correct tax summary. Example: Delivery charge incl. 1.07

Description Actual behavior When configuring SupplierDO.ignoreAdditionalPositions to "true", Dispatches, Returns and Responses with unknown orderlines can be persisted but the further processing of those objects will fail with exceptions Expected behavior Unknown positions are not processed Business

Description Current Behaviour: The current sql in getOrderIdListByPosState leads in most when not all cases to a full scan of OrderDO, which can result in performance issues. Repro Steps Current Behaviour: The current sql in getOrderIdListByPosState leads in most when not all cases to a full scan of

Description Current Behavior: Depending on the configuration, addresses contained in an order should be stored as CustomerAddressDO too. Only addresses not yet known are copied as CustomerAddressDO, but the check ignores some attributes (phone numbers, ShopAddress reference, night shipping-flag). Expected

Description Current Behavior Depending on the configuration, addresses contained in an order should be stored as CustomerAddressDO too. This doessn't happen when the addresses do not contain a first or last name. Steps to Repeat Place an order with no last or first name in the addresses. Check the order

Description Current Behaviour: Some REST yaml-files are hosting the x-vendor version. It's always a SNAPSHOT and not useful to show this to the users, because this can differ even for the same API-version. It's confusing. Expected Behaviour: Don't have the x-vendor version. Note, that this is not an

Description Actual behavior When importing inventory for the parent and child shops, the ATP service / function get_article_ref_and_offering_shop returns the parent shop as offering shop. Expected behavior The "first" (lowest hierarchy level) shop offering the article should be returned (i.e. the child

Description Current Behaviour: Test runs produces appr. 1.5k of such messages, which lead to issues with JMS. {"timestamp":"2020-04-24T06:44:43.816Z","sequence":984063,"loggerClassName":"org.apache.activemq.artemis.ra.ActiveMQRALogger_$logger","loggerName":"org.apache.activemq.artemis.ra","level":"WARN"

Description Current Behavior: The method getSalesSumTaxDiscounted is mapped to the Postgres column salesSumTax and inverserly getSalesSumTax map to salesSumTaxDiscounted As a curious side effect, the tax value switch between these 2 columns at each time a credit note iis created during retours. There

Description Current Behavior: Some database columns that have been added using a migration scripts and later removed by another migration scripts have been reintroduced by the older scripts in a latter run. This is an idempotency issues over different scripts: in some case, older scripts should be modified

Description Actual Behavior There are no summaries provided in the API specifications 'Health Service' and 'Cache Management'. Although the summary field is optional according to the Open API specification, it is still displayed by tools such as Swagger UI and Redoc. Since the summary is missing in both

Description Current Behaviour: As product ids of a shop and one or more suppliers that have a relation can overlap it's required to differ the ids. Otherwise, there's a risk that a wrong product can be linked during message processing. Expected Behaviour: Prevent from wrong linking of product id when