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 theGetBundleProductsForProduct
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
},
// ...
]
}
// ...
]
}
// ...
]
}
Success: [{
UserBackendID: "B123",
UserID: 123,
UserBoughtProducts: [{
UserBoughtProductID: 123,
ProductBackendID: "teacup123",
SerialNumber: "123" // this is a nullable property
},
....]
},
....]
β 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.
- Itβs now a
- 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
}
]
}
]
}
{
ID: 7
}
π 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.
- Defaulted to false - Had to be enabled to make use of the above
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.
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.