Word in advance
🔑 Core drop notes structure
In our continuous effort to make our Core Drop more easily digestible, we've made the following changes to its format:
- We try to categorize all drop entries as best we can by the closest common denominator, e.g. Extension point entries, or Services. This will make it a little easier for you to discern what's important to you.
- Although the difference can be subtle, we try and categorize the entries on whether they're new additions 🆕 or improvements ✅
- The introductory text for each entry will be more concise, with Detailed information available via the Expansion bar.
No breaking changes.
🆕 Properties in EventExport extension point
The extension point EventExport now has two additional properties available for use in its script:
By using these properties you can indicate to export the event or not based on if an order was shipped from store.
set export to false
if Order.SoldToOrganizationUnit.Type = 'Shop'
then set export to true
🆕 Properties to differentiate orders in extension points
We have introduced two new properties to specific extension points to help differentiate between the two:
By using these properties, you can indicate whether it is a store order or a webshop order.
These properties are autocompleted in scripts extending types ReturnableStatus, OrdersMonitor, OrganizationUnitCustomFieldEligibility, OrderCustomFieldEligibility, and StockNotification.
if Order.SoldFromOrganizationUnit.IsWebShop then
🆕 ShowMessage in BarcodeResult extension point
We've added an additional action to the possible results when parsing barcodes via the BarcodeResult extension point.
This action, called ShowMessage, will allow you to display a custom message upon scanning a specific barcode format.
For samples, please see Sample scripts.
✅ Handling conflicting outputs in ReturnableStatus extension point
The ReturnableStatus script now better handles conflicting results.
The ReturnableStatus script, which is used to indicate whether an order can be returned (read: refunded) with or without its products, theoretically allows you to configure both order lines which need the product to be returned and lines which do not need to be returned.
Since it's not possible to differentiate this between order lines in EVA (either all products are returned, or none), this means we have to override some of the outputs configured on order line.
EVA will do this according to the following logic:
- Both a return with and without products can always be created by employees, but it will be overwritten by EVA if ReturnWithoutProducts is set to a conflicting value;
- if one order line in the script has ReturnWithoutProducts: 1 (without products), while another has ReturnWithoutProducts: 2 (with products), EVA will override and the order will force products to be returned (regardless of which line is being refunded).
🆕 Repair task sub type: Pickup
We've added a new sub type for the Repair task: Pickup. This new type will only be created when the setting called
UserTasks:EnablePickupRepairUserTasks is specifically set to true.
For more information, see Pickup.
🆕 Repair is ready: templates
We've added two new templates for messaging your customer the repair is ready and will either be shipped or can be picked up. You can use RepairShipped and RepairReadyForPickup respectively.
The former is triggered whenever a shipping method is not pickup and its open amount is zero, while the latter is sent whenever a repair is ready and indicated to be picked up (see also the entry above).
🆕 Foreign currency and auto confirm
A few payment parameters, namely ForeignCurrencyID, ForeignAmount, and AutoConfirm have been added to the PushSalesOrder service under the order Payments object.
🆕 Color coding for custom statuses
We've done the back-end work for assigning a color to a custom order status by adding the Color property to
The available options will be: grey, green, yellow, blue, red and white. You will soon be able to specify these colors when creating or updating custom order statuses in Admin Suite.
🆕 Currency on purchase order lines
A new property Currency has been added to the
The addition has been made to accomodate scenarios where the currency of the organization unit receiving the purchase order is different from the sender i.e. resulting in proper cost calculations. The applied conversion rate will be based on the currency conversion rate specified in the OU if configured. Alternatively, the rate applied will be based on the real time rate pulled from Fixer.io.
🆕 LayerID of the attached discount
The PrefigureDiscountResult, available on the response of both
PrefigureDiscounts, will now return the LayerID of the attached discount.
This will allow you to check at a glance if a discount's requirements were met, but when the discount wasn't applied because of another discount's application within the same layer.
✅ Showing products affected by discounts
The property EligibleProductIDs in the response of the
PrefigureDiscounts call now shows the affected products.
✅ TotalAmountInTax in invoices
Invoices now use the TotalAmount from the invoice lines instead of the order lines.
This means the TotalAmountInTax now matches the UnitPriceInTax * QuantityInvoiced on (non-certified) invoices
🆕 List settlements service
We've added a new service called
This will be used to replace
ListBlobs (which is slated for deprecation in C2.0.722 (2024-01-02)) and will filter on blobs with the category "template_media".
PushUsers_Async can now optionally accept any user entries which are correct, while displaying those entries resulting in errors. Set IgnoreErrors to true to make use of this.
✅ Promotion visibility for partners/franchisers
We now ensure stores cannot see/interact with discounts from stores they don't have rights to. This is based on users' visibility groups and their edit rights on the OUs connected to the discount.
For more information, expand the following section.
Detailed changes to corresponding CRUD services
- Users can only see discounts they have rights to according to their visibility group;
- Users can only edit discounts if they have edit rights on all the OUs that are part of the set that is connected to the discount;
- Layers is free for all however: they aren't set-bound, so if you have privileges, then you can go wild.
The discount itself doesn't (and will never) care about VG's; if your OU is within the set that is connected to the discount, it will be included in the calculation and applied when possible.
This is all achieved by adding visibility checks to the discount management services (
duplicate) based on the OrganizationUnitSet on the discount.
✅ Fallback destination for certain templates
Even when you have no AsyncRequestCompleted templates configured on your environment, EVA will now send you the necessary (standard) email messages regardless. These are emails for Stock replenishment downloads for example.
✅ Handling deleted users with async processing
We now impersonate deleted users in edge cases where async processing would fail due to a user having been deleted in the meantime.
🆕 Asynchronous calls to RT server in Italy
In Italy, the option to perform asynchronous calls to the RT server during the checkout process is now available by means of a setting called
UseAsyncSigning. More on this here
This is an experimental setting that should only be used in cases where the RT servers are hosted outside the physical stores in a server farm, and upon New Black's advisory. If not handled correctly, there are risks of being not compliant.
✅ Logic for preselecting OU for returns
We've altered the logic for prefilling the return OU field in Admin Suite: EVA can now optionally prefill the field with the OU the employee is currently logged into.
The return order's Return on original OU checkbox can be preconfigured for its users based on the following App setting:
- true - the checkbox will be preselected (to return on the original OU);
- false - the checkbox will be unselected;
- current - it will be unselected with the dropdown prefilled with the OU you are currently signed into.
Additionally, the filtering of the list of available return OUs will now depend on the RequireLoginFunctionality parameter. When it is set to true, the property StockOrganizationUnits will be filtered based on the user's login rights. When set to false, it remains unfiltered. If your currently logged-in OU is on that list, it can be pre-filled (based on the App setting).
✅ Pincode synchronization
We've improved the way the setting
LoginWithIdentificationPin:Method handles your chosen PIN method. This will solve an issue where the pincode would be forgotten when restarting the Suite Apps.
Now, when the LoginWithIdentificationPin:Method is set to 3 (IP-method + Secure token), we will first attempt to match an OU based on the IP address.
If no match is found, we will then try matching using an app token. This ensures that when you log in again, the pincode is retained between apps.
- The recent changes to prettify (return) order export responses from Arvato needed a fix to work properly.
CreateZonedCycleCountswould not return a result in
Updatedwhenever this was called through the async-message process.
- Fix broken
ListUserRequirementsquery with UserType filter.
- Properly allow for deleting an unused role set.
- Filtering stations by DeviceType should only show stations with a non-deleted device of that type.
- Creating a Cash expense will no longer lead to the event exports sending out an event with ID 0.
- We fixed an issue where
AvailableShippingMethodswould sometimes respond that a customer would have to pay a shipping cost, while they shouldn't.
- We fixed an issue where employees did not receive the assigned functionalities when they logged in at stores within Visibility Groups through SSO.
PrintFullStockCountLabelswill no longer return "Unable to find a device".
this was due to
ListStationsForOrganizationUnitreturning stations without a thermal printer
ListPriceListOrganizationUnitswill now properly return the OUs for the price list.
⚡ Removed from typings
These deprecations and requirements are halfway to coming into effect. With these deprecations, the following services and/or fields are no longer be exposed by our typings. Failing to enter the mentioned required fields after the specified core release, will mean the services will no longer work.
- Medium ID is deprecated and will be removed in 2.0.721: Replaced by
InvoiceExportIDsso that multiple invoice exports can be retried at once..
- Medium Field InvoiceExportIDs is required and will be enforced as such in 2.0.721.
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.