Dynamics 365 Commerce

When voiding product lines when using a compact view on a mobile device, the items with the strikethrough can obscure the view for the POS user. There could be a toggle to hide the voided product lines vs showing them, or the ability to sort voided product lines to the bottom of the transaction screen.

There should be the ability to limit the recalling and editing of customer orders to a specific store. There is a risk that a POS user can recall an incorrect order from a different store and edit that order. Some businesses would like transactions in POS to be specific to one store and not available to view or edit across stores.

The ability to edit the customer panel for compact screen layouts should be available. This will allow for additional customer information, such as the customer credit limit, to be able to be seen when using a compact mobile device (such as when using Store Commerce for Android). This functionality is available when editing the normal screen layout.

When creating a new customer from the form Retail and Commerce > Customers > Customer Service, you are returned to the Customer Service screen instead of the newly created Customer record. If you didn't make note of the Customer Account Id in the New Customer popout, it's very difficult to find the account you just created.

Suggestion: when creating a new customer within the Customer Service screen, you should be brought to the newly created customer record.

Manual loyalty adjustments gives the ability for the user to add in comments when making a loyalty points adjustment on a customer loyalty ID. This produces data quality issues, inconsistencies with reasons & potential fraud risks. By including a 'reason for adjustment' picklist in addition to the comment field, this allows for the user to select from a defined list of reasons why the loyalty points were manually added or removed, based on business scenarios / requirements list.

The reason code field could then be on all default views and extended to Loyalty reward point transaction : RetailTransactionLoyalty & Loyalty transaction : RetailLoyaltyCardRewardPointTransacti entities enabling further points and reason code reporting allowing for follow on process, training and program improvements.

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.