Dynamics 365 Commerce

To harmonize the was D365 POS and D365 Call Center and using currency rounding rules. In Call Center the Price Rounding Rule set up at currency level is used for rounding of unit price and the General Rounding Rule is used for amounts rounding. In POS the Price Rounding Rule only is used for both /unit prices and amounts) and also the number of decimals displayed on POS forms for prices and amounts is drivev by the number of decimals in the Price Rounding Rule. This is creating an inconsistant behavior within the D365 Commerce (Call Center and POS) solution expecially for customer who wants to extend (by EDT extension) the number of decimals used for unit prices (e.g. from 2 to 4) but keep amounts with 2 decimals and apply a rounding rule for the unit price which is different from the one for the amounts.

When the receipt print prompt appears, the focus is currently set to the toggle on/off button instead of the "Print" button.

To improve efficiency, it is recommended to set the default focus on the "Print" button. This adjustment will allow the user to press "Enter" to print the receipt automatically, without needing to click the button manually.

Implementing this change will enhance the cashier's performance by streamlining the transaction process and receipt printing.

Currently it's not possible to make a partial payment on the remaining amount of an invoiced sales order through POS. We should have the ability to conclude an invoice after making a partial payment on POS while leaving an unpaid amount to be paid at a later time.

Currently, it is possible to select which POS user profile has permission to create a transfer. If the user has permission, they can create, send and receive transfers related to their store. It would be interesting to have separate permissions for each of these actions, so that a user can create transfers but not send them, for example.

According to the official documentation: https://learn.microsoft.com/en-us/dynamics365/commerce/price-change-tracking#how-price-change-tracking-works

Retail Price Change Tracking should already support tracking the changes made to trade agreements in general. Unfortunately, MS pleads to "design limitation" or "reduced performance" and only tracks trade agreements that are posted for "ALL" (party code relation). As in many cases, prices are specific to a customer or maybe even just a group (e.g. B2C prices vs. B2B prices) and therefore, the standard price tracking feature becomes useless and there is no other way in a standard environment to track price changes for those use cases without interfering in MS code with a customization.

This idea is not about tracking actual price changes on the PriceDiscTable but only require MS to run existing methods to update the UpdatedDateTime field in the RetailPriceChangeTracking table for all items in the currently posted trade agreement. I'd understand if they fear a performance risk, if there was a line with party code type = Group and item code type = Group as well (or even ALL). But a party code type = group and a specific item number should be tracked in my opinion.

There's already other cases, where multiple products will receive an update on the table, like when publishing a discount for a number of products or even a product hierarchy node which can hold plenty of products itself. Therefore, I don't see any issue with implementing the price change tracking for party code type = Group and party code type = Table.

I'd appreciate your vote on this idea.

Hello,

When DOM runs, it assigns GPS coordinates to address in order to calculate closest fulfillment location.

It turns out, the GPS coordinates assigned to address are NOT the coordinates of the address but instead are the coordinates of the postal code. This is confirmed by Microsoft here https://fix.lcs.dynamics.com/Issue/Details?bugId=976780&dbType=3&qc=2a3ef6689b475bbd2d23006f8ae5ae48cef467f0f242f6563e644bc8a55179a0

This causes the discrepancy when sales tax is calculated as the gps coordinates take priority over address.

The logic should be changed to assign the gps coordinates of the address.

Thanks.

When a item go out of stock , it takes time in removing from PLP of ecommerce website. Take 5-7 minutes.

Coupon codes cannot be manually added to return orders for an unlinked return where the customer used a coupon. The parameter "Manual entry of coupon codes for return without receipt" only works on POS. Call center orders can only receive discounts either automatically for all existing coupons (regardless of activation or validity period) or not at all because the Coupons button is disabled for returns.

Call center returns should be capable to selectively apply coupons to return orders without an all or nothing approach that doesn't fit standard business practice.

At a lot of retailers (especially self checkout) an option is prompted at the end asking if the customer would like to donate their change

we can partially acheive this functionality by using an info code linked to a payment type to prompt if you would like to donate change and link it to a service item being added to the basket.

however this could be vastly improved by calculating the round up amounts for card, or change being given for cash

Currently, financial dimensions for inventory transactions such as stock count, inventory movement, or inventory adjustment are derived from the financial dimension's configuration of the store and the product, without considering the dimensions configured in the register. In scenarios where there are different departments within the same store, such as hardware, butchery, or grocery, it is crucial to maintain the dimension per register rather than per store. The request is to include the financial dimensions of the register in the financial dimension record combination in Dynamics 365. Thanks.