Dynamics 365 Commerce

We would like to request the availability of an AI-powered product recommendation feature in Dynamics 365 Commerce POS. This functionality would suggest additional or complementary products based on the items currently in the customer's basket during checkout.

Such a feature would support upselling strategies, increase the average transaction value, and enhance the in-store shopping experience. As there is currently no available solution offering this capability, we believe this is a valuable opportunity to bring intelligent product suggestions to POS and help retailers boost sales performance.

If there has only been a login on a store's POS, a transactional statement is created for the store. This statement is empty, and the posting of statements always show 'error' if an empty statement is included in the posting process. These empty statements must be manually deleted, and shouldn't be created at all.

There is a need for smart rounding functionality when adjusting prices through 'Margin Component Price Adjustment' for at least 2 reasons:

• The "Get active price" data entity holds both ordinary prices and alternative prices, where 'alternative price' is populated by the result of the 'Margin Component Price Adjustment' functionality. If ordinary prices (i.e. trade agreements) are rounded off, alternative prices should also be rounded off.
• 'Margin Component Price Adjustment' can only be applied with 'Percentage' calculations. Calculating an adjusted price with a percentage will always create decimals. External sales prices with random decimals is not something retailers (or any business) can work with. Calculationg with 'Amount' is a work around on individual prices. But when calculating price adjustments on multiple (hundreds or thousands) of SKU's, this option is not feasible in the same way.

For retailers to work with 'Margin Component Price Adjustment' as a tool for campaigns, smart rounding is essential.

Currently, self-checkout on Store Commerce does not support changing the UI language. In countries such as Spain, France, or Germany, many customers are monolingual native speakers, while a significant number are tourists or non-native speakers. This creates a major business challenge, as many self-checkout users may be unable to understand the UI or on-screen instructions.

To address this, we require a self-checkout feature that allows customers to select their preferred UI language directly at the terminal. This capability is essential to provide an inclusive and user-friendly experience for all customers, regardless of their language background.

In the current Dynamics 365 Commerce loyalty functionality, loyalty points redemption is treated as a payment method, reducing the balance due on the transaction. While this may align with U.S. tax practices, it creates a serious compliance issue in EU and Nordic markets.

In many jurisdictions – including Norway – VAT is calculated before payments are applied. Therefore, when loyalty points are used as "payment," the system calculates VAT based on the full sales amount, even though the customer has effectively received a discount. This leads to:

• Incorrect VAT reporting (VAT is overstated).
• Reduced margins for the retailer (VAT paid on value not received).
• Possible compliance risk during audits.

Requested feature:

Introduce a configurable option (via loyalty setup or Commerce functionality) to allow redeemed loyalty points to be applied as a discount, either:

• As a manual order-level discount; or
• As a calculated loyalty discount line item before VAT calculation.

This would:

• Ensure VAT is calculated on the actual revenue received.
• Align D365 Commerce with EU tax requirements.
• Offer greater flexibility for international retailers.

Current workaround:

This requires custom development using POS triggers or CRT extensions to convert loyalty redemption to order discounts. Such workarounds introduce maintenance overhead and inconsistent behavior across channels.

Business impact:

For retailers operating in the EU, this is not just a feature request – it is essential for correct financial reporting and compliance.

We used MPOS with a Windows Kiosk account locked down to just run MPOS. When we upgraded to Store Commerce, we lost the option to add the Store Commerce App in the Windows Kiosk mode drop down set up. Can we get this re-added so we can move away from everyone having to log into Windows with their AAD account? We manage 850 registers.

When recalling a quote at POS, there should be the ability to filter on quotes by the status of the quote, for example "Sent" to identify quotes that have been sent, but not yet confirmed. There is currently the functionality to only search by the status of customer orders.

When using EntraId single signon for Store Commerce in combination with shared installation (Multi user, --UseCommonApplicationData) there are two main challenges we need to handle:

- Adding users to the local security group RetailChannelUsers is a challenge when installing in userspace since we cannot easily add all users that need to use the computer to that local security group. Using group policy is not always possible due to security setup so a way to add users centrally in HQ and allow for replication to the local group or similar using Entra ID groups would be preferred.

- Automatically killing or otherwise handling the requirement to have only one instance of the Store Commerce application running is a challenge since users are not always clear that they need to shut down the application when locking the screen temporarily. Either allowing users to terminate the running instance or otherwise allowing multiple users to use the same device using entraid without needing to reboot the computer would be needed.

CST is requesting to have the ability in the system to allow a default descriptions for Customer - Payment, Ledger

While creating a customer in store commerce app these constraints needs to be added:

Phone numbers: It allows adding characters and special characters -> Customers wants the phone number field to only add numbers.

Customer Name: It allows adding numbers and special characters -> Customer wants the name to only allow characters.

Customer Email: It allows adding anything if it has these two sympols "@", "." -> Customer wants it to validate if the email is correct