Dynamics 365 Commerce

Loyalty card entity includes card type, but not blocked date or replacement card number. Adding these fields to the loyalty card entity would inform enrolment and card maintenance reporting over time and assist in fraud behaviour reporting.

With self-checkout being all the rage, many retailers with loyalty programs will want to make it simpler for a customer checking themselves out to add their loyalty information to a transaction.

With current functionality, the customer would need to add themselves to the transaction, and remember to do so. The only standard function that could be done is an info code that prompts the customer to add themselves.

A more streamlined approach to this would be to allow an operation to be triggered from an info code subcode (where we can currently trigger another info code or a product). This would allow the following scenario:

• Info code prompt: Are you a loyalty customer?
• Subcode 1 = Yes, trigger function = Operation, Operation = Add customer

Many other possibilities are opened with this functionality, but from an SCO perspective this will be extremely helpful to have customer-prompted operations.

Some customer wants to send to a Third Party all sales transactions that are made at the POS including void transactions, but all these sales transactions have to have a ReceiptId including void transactions because they need to control all sales transactions that are made at the POS with ReceiptId including void transactions

Expectation is that a new receipt ID should be automatically generated during the void of the transaction

On the POS there is the option to set up the buttons "View available discounts" and "View all discounts".

If you scan an item that is part of a currently valid promotion and then tap on the "View available discounts" button, the appropriate discount for the item is displayed, but only the name from the "Name" field of the discount from the settings in the back office. 

Although this can be freely selected, it does not usually contain the conditions of the discount described in detail.

On the discount itself, in the "Details" fast tab the "Description" and "Disclaimer" fields, among others, can be filled out.

It would be great if the contents of these fields were also displayed on the POS when a cashier displays a discount.

In the practical example, one of our customers has a big product portfolio. Up to 100 different discount campaigns are active at the same time. These are difficult for a cashier to remember. 

It is helpful here to at least be able to access the discount information.

This would also create a form of communication transfer from the marketing department to the store.

When creating a new customer in POS, or when checking out an existing customer, enable the sales associate to opt the customer into future marketing campaigns, if they consent to do so. This would update the customer record to denote that the customer has opted in. The POS should also be able to opt a customer out of future marketing campaigns if a sales associate is asked to do so.

When creating a sales quote at the point of sale, the sales quote should sync with F&O in real-time, should the POS be online. If the POS is offline there should be the fallback of the order being created in async.

There is currently this feature for customer orders, where a sales order is created in real-time, with async as a fallback, when offline. This feature is governed by a parameter on the functionality profile but only relates to customer orders.

In retail stores with a one-shift system, it would be helpful if there were a systemic routine that checks whether the "start amount" at day start matches the "declare tender" amount at day end of the previous day or whether there is a discrepancy.

In many retail stores, it is common for only one cash register with one cash drawer to be used. This is stored in the safe at the end of the day and used again the following day in the morning. If money goes missing during this time (theft, for example), it can be quickly detected by such a function.

I would locate this function in the functionality profile, where it can be activated and deactivated as required.

Would like to have attach images & videos as a reviews for the product .

Folks kindly vote this idea if you feel its useful for retailers.

Thank you

If we do price override after set quantity of weighted products, the override price is considered for quantity before set quantity and is then recaculated accordingly for the units in the basket. The right behaviour should be to override price based on the quantity in basket.

The above applies to some low value low weighted products like Ginger, are purchased in Kilo(Kgs) and sold in Grams (g) in the stores on POS.

But as these products are so low value low weight, we cannot keep the sales unit as grams as it's diffcult to define price per gram.

So the sell trade agreement is defined in KGs and hence,the product is added to POS in KGs...1KG = £9.95

Then we set quantity to the req quantity customer has purchased like 0.3Kg (300 grams) .. 0.3 KG = £2.99

Sometimes these products are on one off markdown to clear stock towards their best before date and we sell these for a giveaway price like £1.

When user overrides the price after setting quantity, the overriden price is considered for the 1Kg instead of 0.3 KG and instead of 0.3 KG being £1, it calculates 1kg = £1 and hence 0.3 KG = £0.3, which is incorrect, we wanted to override 0.3 KG = £1.

It's difficult to calculate how much percentage it is during peak hours to be able to use line discount % function as is prone to manual error.

We did raise this as a bug with Microsoft (2404150050004828), but we were told to raise an IDEA instead.

we propose a modification to the 'Change Due' functionality. Currently, the 'Change Due' dialog can be hidden when there is no change due by selecting 'Skip when zero'. However, this setting is overridden if gift receipts are configured to print 'As required'. We suggest a feature enhancement that allows the 'Skip when zero' setting to persist, even when gift receipts are set to print 'As required', thus suppressing the gift receipt prompt during transactions while still allowing gift receipts to be printed from the journal.