Core 2.0.761

🆕 Arabic Translation Updates​

We've introduced several updates to the Arabic translations on the CertifiedInvoice thermal and PDF templates. Additionally, we've added a VAT rate breakdown table in the PDF template (United Arab Emirates already included the VAT breakdown table in the certified invoice PDF template).

🆕 Local Mode Support in Spain​

Local Mode is now supported in Spain, enabling offline functionality. For configuration details, see Enabling Local Mode.

✅ Generating JPK Files​

We've improved the performance of generating JPK files in EVA for Poland, which should expedite the process and decrease the likelihood of errors.

EVA will no longer enforce certain checkout options for countries that do not necessarily require them.

These are countries which don't have an auditing provider set or have it set to Default.

The checkout options in question are the following:

• FiscalID
• FiscalRemark
• Tax registration number (VAT number)

Of course these checkout options can still be set voluntarily.

We are changing the current Document output logic for Sweden specifically, to make it more consistent with the logic we have across all countries.

Receipts and Simplified invoices

• The Document output number will be: OU ID - Document Type Code - Sequential number
• For receipts & simplified invoices this will be: 148-01-1
• For credit receipts & credit simplified invoices this will be: 148-03-1
• The simplified invoice treshold is: 4000SEK

Furthermore:

• Only the sequential number is shared with Infrasec, because Infrasec can only handle numeric receipt numbers.

• With the new format, the current sequence remains intact (in other words: we will not start over).

  For example: if we now have receipt number 56, the next one will be 148-01-57.

• The identifier for the invoice chain within the code is based on the OU, so an OU ID and Company ID won’t cause collisions.

Invoices

• The Document output number will be: OU ID - Document Type Code - Sequential number
• For Invoices this will be: 148-02-1
• For credit invoices this will be: 148-04-1

When deleting a layer with an active discount, EVA will return an error, since you can't delete layers with active discounts by default.

You can however override this by setting the new property ArchiveDiscounts to true in the request to the DeleteDiscountLayer service.

The MaxAmountPerOrder is now also available in the AvailablePaymentMethods service. This change makes the property context-aware, practically meaning that EVA remembers what was already paid on that payment method, ensuring the max amount of a cash handler is upheld even when a payment gets split.

Furthermore, we've changed the create and update services for the MaxAmountPerOrder of a cash handler to not accept unrounded values, preventing possible edge cases where a rounded payment would trigger the max amount's limit

• New Property: A new enum property, SubscriptionConfirmation, has been added with the following options:
  • none
  • email
  • webhook
• Service Updates: Users can set the SubscriptionConfirmation property via the following services:
  • CreateSubscriptionOrganisationUnitSet
  • GetSubscriptionOrganisationUnitSet
  • UpdateSubscriptionOrganisationUnitSet
• Deprecated Property: The ConfirmationRequired property is now deprecated and replaced by the email option in SubscriptionConfirmation.
• Webhook Option: A new webhook event, subscription_confirmation, is available for the webhook option. It includes a confirmation token and user ID.
• Email Option: The existing email confirmation process remains unchanged.
• Event Notification: Users will receive an event export notification when a subscription confirmation is sent out, categorized under “Target”: Customer and “EventType”: subscription_changed.
• Subscription Confirmation: Users can confirm a subscription using a token retrieved from the NewsLetterSubscription stencil with the ConfirmSubscription function.

The service, named GetFieldValidatorsForEntity, accepts an EntityType and returns all configured validators for that entity. It considers the context of the logged-in user to determine applicable validations.

Supported entity types include PriceList and PriceListAdjustment.

Key Features:

• Retrieves multiple validation rules for fields such as BackendID and BackendSystemID.
• Validations include requirements like whether a field is mandatory, specific length constraints, and regex patterns.

Example Usage:

  { "EntityType": 1 } // PriceList

 {
   "Validators": [
     {
       "EntityFieldName": "BackendID",
       "ValidatorType": 0,
       "ValidatorData": { "Required": true }
     },
     {
       "EntityFieldName": "BackendSystemID",
       "ValidatorType": 1,
       "ValidatorData": { "MaxLength": 15 }
     }
   ]
 }

The PushCase API has been updated to allow cases to be associated with existing customers based on their BackendID. If a customer with the specified BackendID exists, the case will be attached to that customer instead of creating a new one. This update helps prevent duplicate customer entries in the system.

• If a customer does not exist with the given BackendID, a new customer will be created when you use PushCase.
• If a customer does exist, they will be attached to the case without updating their existing information.
• This change applies to both Basic and Standard account types.

{
  "Description": "Template request for PushCase.",
  "Title": "PushCase Template 002",
  "CaseTopic": {
    "Name": "Fix Lining",
    "BackendID": "PUSHCASETOPIC-001"
  },
  "Status": "New",
  "BackendID": "PUSH-003520932",
  "Customer": {
    "BackendID": "LE-ACCOUNTTYPE1",
    "EmailAddress": "pushcase001@case.com",
    "Gender": "M",
    "Initials": "P",
    "FirstName": "Pedro",
    "LastName": "Pascal",
    "ShippingAddress": {
      "Address1": "Lelylaan",
      "HouseNumber": "1",
      "FirstName": "Pedro",
      "LastName": "Pascal",
      "ZipCode": "1423DE",
      "City": "Almere",
      "State": "FL",
      "CountryID": "NL"
    }
  },
  "Priority": 2,
  "OriginatingOrganizationUnitID": 60
}

Previously, if a PushUser or PushUser_Async request was sent without the DateOfBirth field, it would nullify the existing DoB on the user's profile. With this update, the system now uses a Maybe<> implementation, allowing you to selectively update user fields. To intentionally clear a field, you must explicitly set its value to null.

Example Usage:

{
  "Users": [
    {
      "BackendID": "325423523",
      "Nickname": "LE_PushUser_00051",
      "FiscalID": 52573323,
      "CompanyID": "C-309521",
      "SocialSecurityNumber": "6263099032",
      "PhoneNumber": "0629522214",
      "Title": "Mr.",
      "Salutation": "Sally",
      "EmailAddress": "lars+pushuser00041@newblack.io",
      "Password": "Testing1234",
      "Initials": "LE",
      "FirstName": "Lars Test",
      "LastName": "PushUser",
      "Gender": "M"
    },
    {
      "BackendID": "32542352325",
      "DateOfBirth": null
    }
  ]
}

In this example, the second user object explicitly sets DateOfBirth to null, which will clear the DoB field in the user's profile. If the DateOfBirth field is omitted, the existing DoB will remain unchanged.

This service, introduced in Core 2.0.753 and used to push multiple serial numbers into EVA, requires the following properties:

• The ProductID is always required
• Either both, or neither of StockLabelID and OrganizationUnitID

We recommend to keep the JSON request size limit to 10 MB, which will result in somewhere between 100.000 and 200.000 serials per call when using solely a SerialNumber and a ProductID.

Important to note

• When a product belongs to a Serial Number Configuration that is configured with a validation regex, serial numbers pushed for that product must match this regex.
• The service skips over errors and attempts to persist as many serial numbers as possible.
• Gathers any error encountered and returns (up to 1.000 of) them, allowing you to fix & retry.

Ignored serial numbers

• Ignores serial numbers that already exist in EVA.
• Ignores duplicates within the same call (but it's undefined which serial number is used).
• Ignores duplicates within multiple simultaneous calls (but it's undefined which serial number is used).

These services facilitate uploading special opening hours in bulk. You can then assign the templates to your OU (sets).

The DownloadSpecialOpeningHoursExcelTemplate service gives you a template which you can fill in with your new hours, while UploadSpecialOpeningHoursExcel is used to upload the same Excel file. You can use this functionality to overwrite existing values for special opening hours.

Note that EVA supports two opening hours per open day in general.

For a sample of how this works, please see the below table, which would match one of your Excel files. After uploading, it will result in the following overview in Admin Suite.

Example

• A GetOrder call can be used with: { "ID": "my-pretty-backend-identifier" } to use a BackendID to match the order
• Or { "ID": "eva:123" } to request an order that is matched on the ID with the value 123

Take note that when using this header, the response will also return the ID property as a string, as if the user used the String-IDs as the header value.

With the new functionality, users can ensure that order orchestration calculates the most optimal fulfillment when an elevated product is included in the order.

•   Recognition of Elevated Products: The system now identifies elevated products that require specific fulfillment handling.
•   Assortment and Allocation Rules: Only products that match the **SoldFromOrganizationUnit** and have an existing supplier relationship can be used. Products must also have proper allocation (practically meaning > 1).
•   Product Preference: Priority is given to products with a 'use up' status, selecting those with the closest end date or earliest start date.
•   SKU Validation: The App now supports scanning all related SKUs for an order line, with manual additions possible to the **StockProductIds**.
•   Task Completion: Upon task completion, shipped **ProductIDs** are updated in the **StockProductIds** array on the order line.

This can be achieved by using the HTTP stencil destination.

All available properties in the template will be sent towards the endpoint, whcih includes the new property: MailTo.

This new property is to be used by a 3rd party for sending the email towards the email address attached to the anonymous order.

Additionally, the template will include a new object: ‘body’: ‘attachments’. This will ensure any attachments are rendered and supplied as a blob to the configured HTTP endpoint.

{
    "TemplateName": "ElectronicReceipt",
    "OrganizationUnit": "Almere_store",
    "Customer": "Jenny Mera", //null for anonymous orders
    "InvoiceNumber": "1547",
    "AssetsUrl": "https://assets.fg4r.on-eva.io",
    "LanguageID": "en",
    "CountryID": "NL",
    "TimeZone": "Etc/UTC",
    "IsTestEnvironment": true,
    "IsSentinel": false,
    "RunningOnWatchtower": false,
    "CurrentOrganizationUnit":
    {
        "Name": "Almere_store",
        "Description": null,
        "BackendID": "almerestore",
        "EmailAddress": "Storealmere@newblack.io",
        "PhoneNumber": "+31 6 12234402",
        "HouseNumber": "35",
        "Address1": "Fien de la mar straat",
        "Address2": null,
        "ZipCodeAndCity": "2331HM Almere",
        "State": null,
        "ZipCode": "2331HM",
        "City": "Almere",
        "BankAccount": null,
        "VatNumber": null,
        "RegistrationNumber": null,
        "BranchNumber": null,
        "Website": null,
        "BIC": null,
        "OpeningHours":
        [],
        "CocNumber": null,
        "StreetAndHouseNumber": "Fien de la mar straat 35"
    }
}

{
    "context":
    {
        "id": "2l0xUtt8SMyf37noLLZE9cKDT",
        "ts": "2024-08-22T12:46:53.941Z",
        "pipeline_id": null,
        "workflow_id": "p_13C56Y",
        "deployment_id": "d_5ZskN8R",
        "source_type": "TRACE",
        "verified": false,
        "hops": null,
        "test": true,
        "replay": false,
        "owner_id": "o_API",
        "platform_version": "3.50.2",
        "workflow_name": "ElectronicReceipt",
        "resume": null,
        "emitter_id": "hi_a1Om",
        "trace_id": "2l0xUtt8SMyfoMkLLZE9cKDT"
    },
    "event":
    {
        "body":
        {
            "BccTo": null,
            "CcTo": null,
            "Content":
            {
                "Customer": null,
                "InvoiceNumber": "1545",
                "OrganizationUnit": "Almere_Store",
                "TemplateName": "ElectronicReceipt"
            },
            "Context":
            {
                "ApplicationID": 1,
                "CountryID": "NL",
                "CountrySubdivisionID": null,
                "CreationTime": "2024-08-22T12:44:49.844277Z",
                "CurrencyID": "EUR",
                "LanguageID": "en",
                "MessageQueueErrorID": null,
                "OrganizationUnitID": 123,
                "RetryCount": null,
                "TimeZone": "Etc/UTC",
                "UserID": 1041,
                "UserType": 4097
            },
            "MailTo": null,
            "OrganizationUnitID": 123,
            "Subject": null
        },
        "client_ip": "51.105.219.80",
        "headers":
        {
            "accept-encoding": "gzip, deflate",
            "content-length": "480",
            "content-type": "application/json; charset=utf-8",
            "host": "eso6.m.pipedream.net"
        },
        "method": "POST",
        "path": "/",
        "query":
        {},
        "url": "https://eso6.m.pipedream.net/"
    }
}