• Redemption Rule Minimum Treshold

    When configuring and applying the Loyalty scheme, the system does not take into account a minimum treshold when redeeming earned loyalty points. Instead, it takes the ratio between the points and the currency. For example, let's say you define that 1000 reward points gives you $10. EXPECTED RESULT: Would be that for each tranch of 1000 points you'll get $10. ACTUAL RESULT: Is that you can even pay with a couple of cents and the system will calculate the ratio between points/currency and deduct the points. So you are allowed to pay with $1 and the system will redeem 100 points. Given the fact that there are already 4 decimals available in the redemption rules allows you to specify it on a really low quantity/currency level. So that should never be an issue. The REQUEST is to make the functionality of the redemption rules similar to the earning rules where the amount/currency is seen as the minimum treshold.
  • "Allow on account" parameter also applicable from the POS

    Today a parameter exists on the customer details form to enable or to disable payments with the payment method "Customer" so that it's booked on the customer balance. However, this parameter only applies on call center sales orders, not on sales made via the POS. As this is an inconsistency from an omni channel perspective. The request is to apply this parameter accross the board, meanig also in the POS. The business scenario is stores where both B2C as well as B2B customer are allowed to purchase goods and where B2B customers are allowed to pay on account but B2C customers aren't.

  • Inventory statuses for store return scenarios (Return locations)

    When doing a return scenario on the POS it is possible to use the RETURN LOCATIONS functionality to steer whether or not the inventory needs to be blocked based on the location. This applies to both retail transactions as well as order returns. Today, the return locations form only support Inventory Blocking. The Inventory status is not supported on this form and in the process. In case you implement Advanced WHS, this is not desirable. The ask is to implement the Inventory status for return locations so that this can be used in a Advanced WHS context.

  • POS Stock counting journal useability improvements

    The current usage of the stock counting journals is somewhat tedious. You have to select every line and put them in edit mode before being able to enter the counted quantity. It would be more efficient to have a numpas available on the screen, similar to the picking and receiving screen so that the user can enter counted quantities more fluent.
  • Apply number sequence based on customer group on the POS

    Today, it's possible to configure a number sequence per customer group in D365 FinOps. This results in a specific logic that applies when creating new customers and selecting a particular customer group. You would expect that the same logic applies on the POS, but this is not the case. Creating a discrepancy between de D365 back office and the POS. The ASK is to foresee this business logic in the retail components so that it applies in a similar fashion to the back office operations.