Core 2.0.735

Context: We intend for each setting to be linked to a specific functionality within EVA. This ensures that only designated roles will have the ability to modify certain settings, allowing for more precise control over your environments.

Example: For instance, the setting APIGiftCard:BaseUrl will be associated with the functionality named GiftCardConfiguration.

Implementation Plan: Given the extensive nature of EVA's settings (approximately 1500 in total), we will be rolling these out in batches, once every EVA Drop - effectively once every four weeks. The first and second batch of these adjustments have already been included in EVA Core drop 2.0.726 and 2.0.730.

Timeline: This new batch of changes is now available on your Test and Acceptance environments. These changes will be deployed to Production environments next week with EVA Core drop 2.0.736 (May 7). We anticipate completing this process over approximately 6 more EVA Drops until all settings are included.

Action Required: We encourage you to review this batch of settings, which are already documented on our Docs. Ensure that the roles assigned within your organization align appropriately with the functionalities necessary for access to these settings.

By setting DataLake:ExportAssortments explicitly to true, you will be able to export assortments to your data lake.

Additionally, the following cron taksk must be set: EVA.DataLake.Tasks.ExportAssortments (see Scheduled tasks).

You can expect the consequent file path to look as follows: EVA.DataLake.Tasks.ExportAssortments.

{
    "GenerationTime": "2024-04-24T14:50:07.550575Z",
    "OrganizationUnits": [
        {
            "ID": "c750d885-c05a-586a-b43c-f367bd3afc2e",
            "Name": "EVA",
            "BackendID": "EVA"
        },
        {
            "ID": "0442007b-4703-5cb5-add4-be50558480d9",
            "Name": "Webshop NL",
            "BackendID": "WEBSHOP_NL"
        }
    ],
    "Products": [
        {
            "ProductID": 1,
            "ProductBackendID": "PRODUCT_1",
            "Start": null,
            "End": null,
            "ProductStatus": ["DisableDelivery", "UseUp"]
        },
        {
            "ProductID": 987,
            "ProductBackendID": null,
            "Start": "2024-04-01T00:00:00.000",
            "End": null,
            "ProductStatus": []
        }
    ]
}

This extension point will trigger when return orders are paid/refunded.

The extension point exposes the return order details in the same generic structure as we do throughout the scripting functionality.

The expected output of the script is a discount BackendID that will be used to generate a coupon. The discount is required to be of trigger type Coupon(2) and have CouponsGeneratedByOtherDiscount: true.

extend GenerateUserCouponOnOrderReturn

set discountBackendID to ''

if Order.TotalAmountInTax < 0 and Order.TotalAmountInTax > -10 then
  set discountBackendID to 'discount-coupons-from-return-script'
end

output discountBackendID

Current flow​

When you log in as employee, and you have not selected a specific store to log in to, EVA will search for stores in your subnet and auto-select these if found. However, if none were found, then EVA will search for stores that you have the ExternalLogin functionality for and auto-select these if found. When this also yields nothing, EVA will either reject your login call, or will attempt to downgrade your login attempt and proceed as customer.

Optional flow​

With this ticket, a new setting Security:RequireExternalLoginFunctionality is introduced, which does not modify the above, but adds an additional check when true (false by default). This check will reject your login with a NotAuthorized when all of these conditions are met:

• You log in as employee
• You log in to a store
• Your IP address is not in the subnet of the store
• (You are not on a watchtower)
• You do not have the ExternalLogin functionality in this store

The “store” in these conditions can either be a store submitted with the Login call explicitly, or auto-selected by any of the automatic rules (like these above).

All Login calls are governed by this (e.g. username/password logins, but also PIN logins).

Not enabled by default​

To reiterate: we are not enforcing this extra layer of security, because it does limit your employees in how they can use EVA. For example in case of 4G failovers when your store's internet connection is failing and you have no Watchtower to catch that.

But it's something you can opt in for, so employees can only log in to stores when they are connected to that very store's WIFI connection, limiting the attack surface for outsiders.

The EventExport extension point now includes the following data to increase scripting options:

• Status
• Topic
• Related items
• Custom fields
• Originating OU
• and more.

Moreover, these options are not limited to the EventExport extension point, but apply to all scripts that hold a Case variable.

Keep in mind that you can check all available variables of extension points via the ParseScript service.

We are increasing the events that trigger the Updated type of the Cases target webhook:

• Adding/removing products from cases
• Adding/removing blobs from cases

To prevent customers from receiving multiple mails, such as a "Your case is updated" email, we will now only send out communication after 1 minute of no activity has passed.

Additionally, the CaseUpdatedEmail stencil now includes a condition to prevent it from being sent based on activity in the first minute after the case has been created.

🆕 Time zone and timestamp on thermal receipts​

The thermal receipt stencils has been updated to accomodate the different time zones across Spain, including Canary Islands). Further, the new timestamp format is DD.MM.YYYY - HH:mm:ss, replacing the previous format, DD.MM.YYYY, HH:mm:ss.

Until now EVA had no automatic ways of retrying failed privacy removal requests, which is why we've added a new task mechanism which will retry a failed request based on the following interval:

• 1 hour
• 3 hours
• following day - this goes up to 5 days.

If the request still fails after these 5 days, the request will have a new status called Failed (3) to indicate it could not be processed.

Whenever a change is made to the InvoiceUserData a new entry is added to the InvoiceLedgers.

An entry in the InvoiceLedgers table looks as follows:

      {
        "InvoiceID": 10141,
        "TypeID": 35,
        "TypeName": "UserEmailAddress",
        "OldValue": "[email protected]",
        "NewValue": "[email protected]",
        "CreatedByID": 224,
        "CreatedByFullName": "Pedro Pascal",
        "CreationTime": "2024-04-26T10:54:02.283Z"
      }

As a first step to have EVA handle these situations, we have:

• Added 2 new booleans in the PrefigureDiscounts service
  • HasMoreDiscountPickProductOptions
  • HasMoreLineDiscountProductOptions

These allow us to indicate if there are more options available than loaded in DiscountPickProductOptions and LineDiscountProductOptions respectively.

• SetPickProductDiscountOptionsForOrderLine and SetDiscountProductOption now accept a boolean called DisallowSelectionOutsideProductOptions.

We currently allow employees to overwrite the selection with any product (when you need a replacement because no available option is in stock for example). With the new boolean, it’s possible to opt out of that and enforce that the selection always needs to be within the options.

The next steps will be to enforce a lower limit on the options in PrefigureDiscounts and introduce new services for fetching the options paginated.

The DataLakeBackfill service now includes UserBatches (6), which allows you to manually re-export users based on a From and To property.

You can now change the default way in which users are exported in the Data lake exports by using these two settings:

• The DataLake:ExportUsersInBatches setting - which defaults to false - lets you start exporting regular user changes as batches instead.
  • This batch time is currently set to 5 seconds.
• The DataLake:ExportUsersIndividually setting - which defaults to true - lets you disable exporting of regular user changes individually (which is helpful if you rely on the above).

By having these two settings you can first test the batched users and then move to batched users exclusively.

Lastly: we have added both CreationTime LastModificationTime to users which goes for both the individually exported users as well as the batched ones.

The new service PushPriceList_Async will be used for processing price lists in an async manner, which will replace (and allow for deprecation of) the current PushPriceList's WaitForCompletion property.

This service will return an async result ID, which can then be used in the new PushPriceList_AsyncResult service. This service's response will give you the PriceListID and any unresolved products.

{
  "PriceListID": 75,
  "UnknownProducts": [
    "935353000011",
    "9035300013",
    "3535",
    "DTEASLFLSA",
    "XXXSDFSF"
  ],
  "Metadata": {
    "ExternalIDs": {},
    "IsAsyncResultAvailable": true
  }
}

Currently, service products are shipped with the last shipment of an order. While this works well in case of orders consisting out of just carry-out and service products, it can cause confusing situations when it comes to more mixed orders.

When the order consists of carry-out, delivery and service products, the service products will not be shipped until the delivery products are. In that case, a receipt will state these service products as To be shipped, even though the services have already been rendered.

By setting Shipment:ShipRemainingLinesWithLastInStoreShipment to false, the current behavior will change to ship these kinds of products with the first shipment - in this case the carry-out.

• By setting Orders:Reservations:UseStockReservationTasksOnReceipt to true, a reservation task is created automatically once you receive the PO which was created on behalf of the order (type) order in question.
• By setting StockReservation:ReactivateReservationTasksOnSufficientStock to true on the pickup OU, a reservation task will be triggered automatically when enough stock is available to fulfill the reservation task for the order in question - even when the PO created for that order is not yet received.

The latter process runs based on a nightly background task, but can be triggered/scheduled as well through the ActivateReservationTasksWithAvailableStock task.

When set to true, previous replenishment orders (last 14 days) will be cancelled before the new orders are created for a new replenishment proposal. This is because replenishment takes incoming orders into account - so old replenishment orders influence your new replenishment.

The flow when set to false:

• Replenishment creates order to order 6 products
• 1 product gets sold
• Next day: replenishment creates order to order 1 product

When set to true:

• Replenishment creates order to order 6 products
• 1 product gets sold
• Next day: previous order gets cancelled (if not placed) and replenishment creates order to order 7 products