Core 2.0.739

Requirement: valid custom field values​

Any Order that will go through the validation process of the Placing, Paying, Invoicing or Shipping must contain valid values for all the Custom fields of Order or OrderLine type that are configured as Required.

This is a blocking Requirement.

Rest assured however, we can guarantee there are no configurations currently in any Production environments among any of our customers where this will break anything.

Do take into account that the Companion App and older App versions do not support these new requirements.

Lastly, while this won't break any current configurations, please be mindful of creating new required custom fields.

🆕 Deleting multiple users​

We are introducing a new service called DeleteUsers to allow for deleting up to a 1000 users (read: IDs) a time.

This is an async service and will return any IDs of users which could not be deleted (due to visibility groups/functionalities for example).

🆕 PushUserPersonalizedPromotionProducts​

To have a single service capable of creating and overwriting existing personal promotion products, we're introducing PushUserPersonalizedPromotionProducts.

{
  "UserID": "BEID-52390",
  "PersonalizedPromotionID": "LARS1234"
}

{
    "UserID": "BEID-52390",
    "PersonalizedPromotionID": "Promo1234",
    "Products": [
        {
            "ProductID": "9000018",
            "Selected": true
        },
        {
            "ProductID": "9000019",
            "Selected": false
        },
        {
            "ProductID": "9000020"
        }
    ],
    "SkipUnresolvedProducts": false
}

✅ Filtering in ListPurchaseOrderShipments​

The ListPurchaseOrderShipments service now allows for filtering on both multiple ShipmentBackendIDs and PurchaseOrderBackendIDs. This will allow for easier filtering in Admin Suite's Receive goods chapter.

✅ CardBalanceCheck error codes​

When using the CardBalanceCheck for the whitelabel giftcard solution APIGIFTCARD, any errors will now come back with a clearer message as to what went wrong. For example: "An expired card cannot be used."

✅ SearchOrders speed​

The SearchOrders service now sorts by CreationTime instead of ID, which leads to a smoother performance. Mind that this will not impact the display of results in the front end.

✅ ParseBarcode​

We have made the use of ParseBarcode handlers more secure.

🆕 Splitting repair order lines​

To allow for setting order requirements on each individual repair of multiple of the same product, we're introducing the setting Orders:Repairs:SplitAllLines. By enabling this, all order lines on a repair order will be split.

Mind that this will only impact new repair orders.

✅ Cases adhere to VGs​

Cases can now be assigned to an OU and are incorporated in visibility groups.

✅ AssignedOrganizationUnitID in CaseInteractionCreatedEmail template​

The AssignedOrganizationUnitID is now included in the CaseInteractionCreatedEmail, instead of the CurrentOrganizationUnit.

🆕 User agent in PaymentTypeAvailability​

The PaymentTypeAvailability extension point now allows for the specification of a user agent. This will let you disable specific payment types based on the user agent.

extend PaymentTypeAvailability

if UserAgent.Name = 'eva-app-suite-sales' then

set output to false

else set output to true

end

🆕 Discounts based on multiple products and requirements​

We have laid the groundworks for product requirements in product sets. This makes it possible to offer discounts based on one or more product requirements being met while also claiming the products for the discount.

Front end work is underway.

{
  ProductActionFinancialDispersion: 1,
  DiscountAmount: 0.3,
  ProductSets: [
    {
      RequiredQuantityOfProducts: 1,
      IsDiscountableProductSet: true,
      DiscountableQuantityOfProducts: 1,
      ProductRequirements: [ // nullable
        {
          ProductRequirementID: 1, // required, number, ID
          Values: ["New Black"] // required, list
        }
      ]
    },
    {
      RequiredQuantityOfProducts: 1,
      IsDiscountableProductSet: true,
      DiscountableQuantityOfProducts: 1,
      ProductRequirements: [ // nullable
        {
          ProductRequirementID: 2, // required, number, ID
          Values: ["7"] // required, list
        }
      ]
    }
  ]
}

🆕 Displaying product requirements on receipts​

We've made first steps for displaying product requirements on receipts.

🆕 Functionality (permission) for unreferenced return orders​

To limit the potential for fraud with the creation of unreferenced returns, we're adding a new functionality: UnreferencedReturnOrder.

This functionality, which is by default added to all users to keep existing return flows intact, will prevent creating unreferenced return orders when removed from the role.

✅ Triggering stencils/emails in a repair flow​

We've reexamined the trigger moments for sending communications to the customer and implemented them as according to the details.

• Stock will no longer mutate to negative quantities for Unified orders when AllowNegativeStockAutoCorrect is set to true with ResolveNegativeStockDuringPeriodClosing to false.
• Translations for Checkout options will now be displayed correctly.
• We made a fix to the elevation's security check, ensuring the right users can(not) get elevated to perform certain actions.
• The PhoneNumber field for sales orders over 10.000 GBP is no longer required is no longer mandatory.
• The reference to the original order on the Credit Invoice (PDF) for Germany is visible again.
• The selection of a stock label for returned products (as announced in Drop 72) will properly take into account the stock label settings, instead of being limited to Sellable and Damaged.
• Returns without retake will no longer be treated as exchange orders.
• Regardless of the use of an internal or external tax provider, or Orders:UseNewCalculation, tax details will now be properly cleared when cancelling (shipping) cost lines.
• In some cases, ex tax orders had small rounding issues on the InvoiceTotal when Orders:UseNewCalculation was enabled.
• Suppliers in Orchestration sheets will no longer be considered invalid when they have less stock than the order needs when boosting suppliers in the sheet which do have the requisite stock (for example "score add xx when Supplier.HasAvailableStock") - just as "less preferred".

🆕 Introduced​

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

Required​

High​

• High Field UserID is required and will be enforced as such in 2.0.771.
  • CreatePrivacyRemovalRequest.UserID

⚡ Removed from typings​

These deprecations are now halfway through their deprecation timeline. As of now, these services and/or fields will no longer be exposed by our typings.

Deprecated​

High​

• High InitialPageConfig.Filter.UsageType is deprecated and will be removed in 2.0.755: Removed in favor of LoyaltyPointUsageOptions..
  • ListLoyaltyPrograms.InitialPageConfig.Filter.UsageType
• High Results.UsageType is deprecated and will be removed in 2.0.755: Does not reflect listing information correctly because all the new options within loyalty program. Will be removed..
  • ListLoyaltyProgramsResponse.Results.UsageType
• High UsageType is deprecated and will be removed in 2.0.755: Deprecated because it does not reflect all new options from the loyalty program..
  • GetLoyaltyProgramHandlers.UsageType
• High UsageType is deprecated and will be removed in 2.0.755: Replaced by LoyaltyPointUsageOptions..
  • CreateLoyaltyProgram.UsageType
  • GetLoyaltyProgramResponse.UsageType
  • UpdateLoyaltyProgram.UsageType

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.