Dynamics 365 Commerce

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, Dynamics 365 provides an option to mandate starting and declaring amounts. However, we propose adding a new parameter in the functional profile to block sales transactions until a starting amount is entered.

Business Justification:

Store personnel sometimes forget to enter the starting amount at the beginning of the day and proceed with sales. As a result:

• When performing the end-of-day process, the initial cash amount is unknown or estimated, leading to inaccuracies.
• This causes discrepancies in the daily statement, requiring finance teams to manually investigate and correct errors—an inefficient and time-consuming task.

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.

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

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.

In eCommerce, it would be nice to have a "alert me when back on stock" feature, where the eCommerce user can receive an email when the goods are back on-hand. We see this feature available in many other eCommerce solution, and this is a requested feature.

Separate form requires for delete privilege in transfer journal/ Movement journal; this is the common requirement.

Add support for shared cache across CSUs. This would help prevent many real-time service calls into back office. Services like Azure cache for Redis, this could help performance in many scenarios.

There are often times where products are only available during certain periods in time.

For example during the Summer season an assortment of summer products are available. During the Winter something different. It's cumbersome to constantly have to set expirations on assortments that are going to be re-used again and again.

We would like to setup Assortment Periods where the expiration is based on a reoccuring timeline instead of static dates. For example I would like to assign a Period called 'Summer' with a static date range (no year) so that from 5/1-8/31 yearly this assortment of products are available. The same for each season etc.

While using kit product it could be interesting to be able to create a transfert order from the main warehouse to the store when there is no kit stock at store level.

This process is useful when the assembling order is only done at main warehouse level and not at store level. It means that when creating a sale order in the POS for a kit without stock in store, it should create a transfer order and then an assembling order at warehouse level.

thanks