Breaking
No breaking changes.
Specific topics
✅ UserAgent in ReturnableStatus extension point
EVA now takes the UserAgent property into account in the ReturnableStatus extension point, allowing you to exclude certain order types from being returned for user agents such as a return portal.
Sample
extend ReturnableStatus
# This script checks if returns are being created in the context of a return portal, and if so can check to make sure Carry out, Ship From Store or Click and Collect orders can not be returned via the portal.
if Context.UserAgent in ('eva-return-portal', 'eva-rituals-return-portal') and
Order.SoldFromOrganizationUnit.IsWebShop and Order.ShipFromFromOrganizationUnit.IsShop
set output.IsReturnable to false
set output.ChildrenAreReturnable to false
set output.Reason to '(Returning SFS or C&C is not allowed)'
else if Context.UserAgent in ('eva-return-portal')
and Order.HasCarryOut
set output.IsReturnable to false
set output.ChildrenAreReturnable to false
set output.Reason to 'returning Carry out is not allowed'
else if Context.UserAgent in ('eva-return-portal')
set output.IsReturnable to true
set output.Reason to 'you can return this to the warehouse ➡️ 🏭'
end
🆕 Preventing certain return types between companies
To ensure compliancy, some types of returns have to be handled differently.
For example when a transaction was made with a non-autorefundable payment type which would have to be transferred between different companies.
In such a case, where regulations come into play, store associates have to be limited in what kind of refunds they can offer a customer. This requires a new way of handling them in the back end.
Note that this is laying the groundwork for the altered return process - no actual blocking is yet in place.
Details
To accomplish this, we have altered the GetReturnableStatusForOrder
service by adding the RequiresSpecialInStoreReturn property.
EVA will add this property to the response of the service in all cases where the return using the regular POS flow should be blocked, and display the corresponding reason to the in-store employees.
Such returns will then be processed via the newly created service CreateInStoreReturn
, which will then lead to a different return flow in the POS. This same service will in the future be able to process all returns.
✅ Correct EOD reports
Period closing reports now exclude transfer orders, to ensure only totals of actual sales (and returns) orders of the SoldFromOU are displayed.
Properties
🆕 Extending properties in InvoiceBlobs
The InvoiceBlobs, downloaded via ListBlobsForInvoiceService
, has been extended with several properties.
List of properties
- Invoice date
- File name
- Document number
- Document type
🆕 ID and ProductID in GetOrderSummary
We have added both ID and Product to the response of GetOrderSummary
to make it easier to display bundle products in external shipment overviews.
Services
🆕 OU BackendIDs for Watchtowers
The services ListWatchtowers
and WatchtowerGetDeviceDetails
now return the BackendID for Organization Units they are attached to.
✅ UserBoughtProducts
The various UserBoughtProducts
services no longer need to have a SystemBackendID header specified. Instead, the first matching entity with the given BackendID will be selected.
🆕 ListAvailableUserTasks
We've changed the response of ListAvailableUserTasks
to include the AllowStockMutationsDuringCount property, to ensure the Tasks App can remain open during a FSC if the count allows for stock mutations while it runs.
Settings
🆕 Settings on RootLevelOnly
To make it possible to indicate to users when a setting is to be set on root level only, we've added the RootLevelOnly property to the following services:
ListSettings
GetSetting
GetAvailableSettings
Note that there are no settings yet at this time which are marked as being root level only.
✅ Deprecating Orders:ReturnToSupplier:AllowConcurrentTasks
The setting Orders:ReturnToSupplier:AllowConcurrentTasks is seeing little to no use in practice and, taking into account the complexity and maintenance the setting brings with it, will be scheduled for removal from EVA in the coming months.
🆕 Changing of invoice moment for order line type order
It is now possible to change the moment of invoicing for orders with line types Order by setting Orders:OrderInvoiceStrategy
to true. In this case the invoicing moment will move from shipping to the moment it's paid.
Fixes
- We've fixed a bug in the functionality regarding returning used coupons on returned order lines added in Core Drop 2.0.728.
- We've made a small fix to the functionality behind parsing barcodes/QR codes for the sake of printing order receipts while in local mode.
- There was an issue with printing multiple documents in the RTS flow.
- BackendID will now be specified on case-related webhooks.
- Customers can be added at a later moment to cases pushed in via the
CreateCase
API. Create
andUpdatePriceList
can be performed again without specifying a BackendID.
Deprecations
⚡ Removed from typings
These deprecations and settings are halfway to coming into effect. With these deprecations, the following services and/or fields are no longer be exposed by our typings.
Setting
Highest
- Orders:Lines:UnitPriceCorrections:CreateSeperateLine is deprecated and will be enforced to False from 2.0.764: Seperate lines for price corrections are obsolete and will break all kinds of things.
Deprecated
High
- PageConfig.Filter.StatusID is deprecated and will be removed in 2.0.748: This is the old way of providing a status, use the enum property Status instead.. ListRevisions.PageConfig.Filter.StatusID
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.