Skip to main content
Arrow Backward IconBack to Overview

Core 2.0.740

June 4, 2024

Released on all test and acceptance environments on June 4, 2024

Will be released to production in EUW and ASE on June 10, 2024*

Will be released to production in CUS on June 11, 2024*


release notes image

Breaking‍

No breaking changes.

Properties‍

πŸ†• OrganizationUnitSetBackendID in GetDiscountByID​

We now expose the OrganizationUnitSetBackendID property in GetDiscountByID to allow for OU set selection in discount pages.

πŸ†• IsPromptSuppressed in bundles​

In order to allow the front end to deviate from the normal product bundle flows and suppress prompts in specific situations, we're introducing a new property on specific services: IsPromptSuppressed

Details

By introducing the IsPromptSuppressed property to bundle products, the front end will be able to suppress the modal that allows users to select a matching bundle for the scanned product.

  • The property has been added on the CRUD-Bundle services and the GetBundleProductsForProduct service.
  • Added IsPromptSuppressed to ProductBundles table through migration.

πŸ†• OrderLine.FulfillmentOrganizationUnitID in Cookbook​

We have added the OrderLine.FulfillmentOrganizationUnitID property to both Cookbook 1.0 and 2.0.

This will allow you to identify orders that have been fulfilled using Orchestration.

βœ… AssignedOrganizationUnitID in more templates​

The AssignedOrganizationUnitID is now included in the CaseClosedEmail, CaseCreatedEmail and CaseUpdatedEmail stencil templates.

Services‍

πŸ†• PushBoughtProductsForUsers​

We are introducing a new async-only service to facilitate pushing previously purchased products for multiple users at the same time: PushBoughtProductsForUsers.

Details

The new service PushBoughtProductsForUsers works similarly to the existing PushUserBoughtProduct with the main difference being the ability to specify multiple users at once. This is currently limited to 10.000 users at a time.

{
BoughtProductsForUsers: [
{
UserID: 1,
BoughtProducts: [
{
ProductID: 1,
SerialNumber: "123", // nullable
IsUnderWarranty: true,
WarrantyExpiryDate: "2024-08-01", // nullable
Archive: false,
Details: [
{
BackendID: "reg1.1", // nullable
OrderID: 6, // nullable
OrderLineID: 36, // nullable
PurchaseDate: 2026-08-01, // nullable
PurchasedQuantity: 1, // nullable
},
// ...
]
}
// ...
]
}
// ...
]
}

βœ… PushCase​

The PushCase service has seen several improvements and additions.

Details
  • PushCase now allows updates to a case based on BackendIDs instead of EVAIDs.
  • A new consumer can be imported, while an existing consumer will only be attached to the case.
    • It’s now a Maybe<T>, meaning it can be omitted to ignore or explicitly cleared to be detached from the case.
  • Case interactions now also work based on BackendIDs and are optional. A new Delete property on an interaction can be used to remove it.
  • Case related items can now optionally be pushed. A new Delete property on an interaction can be used to remove it.

There are a few new optional properties:

  • DisableEventExports will prevent events from being triggered.
  • Update is a boolean that indicates whether the case should be updated if it exists (otherwise, it will throw an error as it did previously).
  • AssignedOrganizationUnitBackendID is the OU assigned to the case and now supported in the Push service as well.

Furthermore: the BackendSystemID property is entering deprecation mode - we are generally moving away from those.

{
BackendID: "test-case",
Topic: "test-topic",
Status: "test-status",
Title: "test-push-case",
Description: "Test push case",
Summary: "Test push case", // optional
Solution: "Solution" // optional
OriginatingOrganizationUnitBackendID: "test-originating-ou", // optional
AssignedOrganizationUnitBackendID: "test-assigned-ou", // optional
DisableEventExports: true, // optional
Update: true, // optional
Customer: {
BackendID: "test-customer",
EmailAddress: "john.doe@gmail.com",
// ...
},
Assignee: {
ID: 36,
CustomID: "assignee-custom-id",
Remove: true
},
AssignedOn: null,
Priority: 1,
Interactions: [
{
BackendID: "test-interaction-1",
Type: 0,
Text: "First interaction"
},
{
BackendID: "test-interaction-2",
Type: 1,
Delete: true,
Text: "Deleted interaction"
},
// ...
],
CaseRelatedItems: [
{
OrderID: "case-order",
Items: [
{
OrderLineID: "case-order-line",
ProductID: "case-product",
SerialNumber: "123",
IsWarranty: true,
WarrantyExpiration: "2025-08-01",
Delete: true
}
]
}
]
}

πŸ†• ExecuteRemovalRequest​

We are introducing a new service: ExecuteRemovalRequest. This is mostly meant for use in debugging.

Details

While we already have a dedicated service for performing privacy removal requests (ScheduleRemovalRequest), it isn't particularly useful when it comes to debugging due to how it processes the request and, notably, only informs the user via mail when it's been done successfully.

To that end, we've created ExecuteRemovalRequest which performs a single request directly and delivers a service response with the result. This makes it especially useful for debugging.

Settings‍

βœ… Simplifying RTS settings​

We are simplifying the settings configuration for RTS by removing several settings and making them standard functionality (or removing them from EVA altogether).

Details

The following settings will be removed.

  • ListReturnableSuppliersForOrderLegacyMode - standard RTS functionality will see this as false.
    • Was already defaulting to false - When set to true, it would force the the configuration of suppliers to not go fully down the relation tree. If the supplier was Netherlands (which is a container OU) for example, this would be returned, instead of the returnable OUs that are "under" this container OU.
  • Orders:ReturnToSupplier:EnableTasks - standard RTS functionality will see this as true.
    • Defaulted to false - When set to true, the HQ's RTS request will no longer just generate an RTS order, but accompanying RTS user tasks as well.
  • Orders:ReturnToSupplier:UseStockMovement - standard RTS functionality will see this as true.
    • Defaulted to to false - When set to true, the RTS user tasks is split up into two sub-types. This is essential to allow for generating corresponding tasks when HQ makes changes to a store's RMA request.
    • RTS create order task: generated when either the store or HQ makes an RMA/RTS request.
    • RTS stock movement task: generated when HQ makes changes to the RMA request and goods have to be moved back.
  • Orders:ReturnToSupplier:UseTypedRtsTasks - standard RTS functionality will see this as true.
    • Defaulted to false - Had to be enabled to make use of the above UseStockMovement tasks.
  • Orders:ReturnToSupplier:AllowConcurrentTasks - while performing tasks concurrently will no longer be possible, tasks can be taken over by other employees.
    • Defaulted to true - This would allow your employees to work together on an RTS task by duplicating the parent task everytime it would be started by another employee.
  • Orders:ReturnToSupplier:AllowEaches - standard RTS functionality will see this as true.
    • Already defaulted to true - this would allow your stores to choose between sending back individual items, or complete boxes only. See also Unit of Measure

βœ… Removing irrelevant ElasticSearch setting​

We've removed the ElasticOrderSearch:SyncOrderWithoutLines setting since it had become redundant.

Other topics‍

πŸ†• OrderCustomType in the OrderMonitor extension point​

We have made the OrderCustomType property available on the Order variable in the OrderMonitor extension point.

This will allow you to create a monitor that triggers on specific types - or the absence of them.

Samples

The following sample can be used to trigger when there are 'Endless Aisle' orders created on a kiosk device which are now returned in cash:


extend OrdersMonitor

set includeInResult to false

if Order.HasReturnLines and Order.OrderCustomType = 'Endless_Aisle_KIOSK'

then for each item in PaymentTransactions
do if item.Description = 'Cash'
then set includeInResult to true
end
end

end

output includeInResult

The following sample triggers when there’s completed orders without a custom type.

extend OrdersMonitor

set includeInResult to false

if Order.IsCompleted and Order.OrderCustomType has no value
then set includeInResult to true
end


output includeInResult

βœ… Maximum discount amounts in Local mode​

Manual discounts created while in Local mode will now be limited to the total amount (including tax) of the current order.

βœ… Discounts on return fees​

It's now possible to apply discounts to return fees, paving the way for increased consumer autonomy on return portals.

Fixes‍

  • Birthday coupons will now properly trigger again.
  • Privacy removal requests can no longer be made for user type System and Anonymous can no longer be created.
  • Pagination for ListCustomFields now takes into account the Limit again.
  • Fixed an issue with the Exchange_Voucher payment method.
  • Searching stock mutations with immense date ranges will no longer cause issues.
  • Fixed an issue with Interstore orders not always using the cost price like they should.

Deprecations‍

πŸ†• Introduced​

These deprecations are now announced for the first time. Usage of these services and/or fields will return the appropriate EVA-Warnings header.

Deprecated​

Medium​

  • Field BackendSystemID on service PushCase will enter deprecation as of 2.0.740, the BackendID itself should be unique throughout the application landscape.
Impact descriptions

For more details on the impact categories, please see When are changes communicated?.





Release dates may vary​

The exact date for deploying a Core release to production environments may vary. See How we handle Core releases for more details.