Core 2.0.740

By introducing the IsPromptSuppressed property to bundle products, the front end will be able to suppress the modal that allows users to select a matching bundle for the scanned product.

• The property has been added on the CRUD-Bundle services and the GetBundleProductsForProduct service.
• Added IsPromptSuppressed to ProductBundles table through migration.

The new service PushBoughtProductsForUsers works similarly to the existing PushUserBoughtProduct with the main difference being the ability to specify multiple users at once. This is currently limited to 10.000 users at a time.

{
  BoughtProductsForUsers: [
    {
      UserID: 1,
      BoughtProducts: [
        {
          ProductID: 1,
          SerialNumber: "123", // nullable
          IsUnderWarranty: true,
          WarrantyExpiryDate: "2024-08-01", // nullable
          Archive: false,
          Details: [
            {
              BackendID: "reg1.1", // nullable
              OrderID: 6, // nullable
              OrderLineID: 36, // nullable
              PurchaseDate: 2026-08-01, // nullable
              PurchasedQuantity: 1, // nullable
            },
            // ...
          ]
        }
        // ...
      ]
    }
    // ...
  ]
}

Success: [{
  UserBackendID: "B123",
  UserID: 123,
  UserBoughtProducts: [{
    UserBoughtProductID: 123,
    ProductBackendID: "teacup123",
    SerialNumber: "123" // this is a nullable property
  },
  ....]
},
....]

• PushCase now allows updates to a case based on BackendIDs instead of EVAIDs.
• A new consumer can be imported, while an existing consumer will only be attached to the case.
  • It’s now a Maybe<T>, meaning it can be omitted to ignore or explicitly cleared to be detached from the case.
• Case interactions now also work based on BackendIDs and are optional. A new Delete property on an interaction can be used to remove it.
• Case related items can now optionally be pushed. A new Delete property on an interaction can be used to remove it.

There are a few new optional properties:

• DisableEventExports will prevent events from being triggered.
• Update is a boolean that indicates whether the case should be updated if it exists (otherwise, it will throw an error as it did previously).
• AssignedOrganizationUnitBackendID is the OU assigned to the case and now supported in the Push service as well.

Furthermore: the BackendSystemID property is entering deprecation mode - we are generally moving away from those.

{
  BackendID: "test-case",
  Topic: "test-topic",
  Status: "test-status",
  Title: "test-push-case",
  Description: "Test push case",
  Summary: "Test push case", // optional
  Solution: "Solution" // optional
  OriginatingOrganizationUnitBackendID: "test-originating-ou", // optional
  AssignedOrganizationUnitBackendID: "test-assigned-ou", // optional
  DisableEventExports: true, // optional
  Update: true, // optional
  Customer: {
    BackendID: "test-customer",
    EmailAddress: "john.doe@gmail.com",
    // ...
  },
  Assignee: {
    ID: 36,
    CustomID: "assignee-custom-id",
    Remove: true
  },
  AssignedOn: null,
  Priority: 1,
  Interactions: [
    {
      BackendID: "test-interaction-1",
      Type: 0,
      Text: "First interaction"
    },
    {
      BackendID: "test-interaction-2",
      Type: 1,
      Delete: true,
      Text: "Deleted interaction"
    },
    // ...
  ],
  CaseRelatedItems: [
    {
      OrderID: "case-order",
      Items: [
        {
          OrderLineID: "case-order-line",
          ProductID: "case-product",
          SerialNumber: "123",
          IsWarranty: true,
          WarrantyExpiration: "2025-08-01",
          Delete: true
        }
      ]
    }
  ]
}

{
  ID: 7
}

While we already have a dedicated service for performing privacy removal requests (ScheduleRemovalRequest), it isn't particularly useful when it comes to debugging due to how it processes the request and, notably, only informs the user via mail when it's been done successfully.

To that end, we've created ExecuteRemovalRequest which performs a single request directly and delivers a service response with the result. This makes it especially useful for debugging.

The following settings will be removed.

• ListReturnableSuppliersForOrderLegacyMode - standard RTS functionality will see this as false.
  • Was already defaulting to false - When set to true, it would force the the configuration of suppliers to not go fully down the relation tree. If the supplier was Netherlands (which is a container OU) for example, this would be returned, instead of the returnable OUs that are "under" this container OU.
• Orders:ReturnToSupplier:EnableTasks - standard RTS functionality will see this as true.
  • Defaulted to false - When set to true, the HQ's RTS request will no longer just generate an RTS order, but accompanying RTS user tasks as well.
• Orders:ReturnToSupplier:UseStockMovement - standard RTS functionality will see this as true.
  • Defaulted to to false - When set to true, the RTS user tasks is split up into two sub-types. This is essential to allow for generating corresponding tasks when HQ makes changes to a store's RMA request.
  • RTS create order task: generated when either the store or HQ makes an RMA/RTS request.
  • RTS stock movement task: generated when HQ makes changes to the RMA request and goods have to be moved back.
• Orders:ReturnToSupplier:UseTypedRtsTasks - standard RTS functionality will see this as true.
  • Defaulted to false - Had to be enabled to make use of the above UseStockMovement tasks.
• Orders:ReturnToSupplier:AllowConcurrentTasks - while performing tasks concurrently will no longer be possible, tasks can be taken over by other employees.
  • Defaulted to true - This would allow your employees to work together on an RTS task by duplicating the parent task everytime it would be started by another employee.
• Orders:ReturnToSupplier:AllowEaches - standard RTS functionality will see this as true.
  • Already defaulted to true - this would allow your stores to choose between sending back individual items, or complete boxes only. See also Unit of Measure

The following sample can be used to trigger when there are 'Endless Aisle' orders created on a kiosk device which are now returned in cash:

extend OrdersMonitor

  set includeInResult to false
  
  if Order.HasReturnLines and Order.OrderCustomType = 'Endless_Aisle_KIOSK'

   then for each item in PaymentTransactions 
   do if item.Description = 'Cash'
   then set includeInResult to true 
    end 
  end

end 

output includeInResult

The following sample triggers when there’s completed orders without a custom type.

extend OrdersMonitor

  set includeInResult to false
  
  if Order.IsCompleted and Order.OrderCustomType has no value
   then set includeInResult to true 
  end


output includeInResult