Dynamics 365 Commerce

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.

Our local currency is CHF, and we have payments in CHF and EUR. We wanted to create an expense account entry which was paid out in 100 EUR. We performed the following steps to create the entry:

·      Clicked on Expense Account

·      Selected the Account

·      Entered the amount 100 and saved

·      The line got added to the cart

·      Initiated payment in EUR, the currency conversion took place, and the amount was updated as 102.87

From the above behavior of the system we understood that the amount provided for the income/expense account is always in local currency and when initiating the payment in foreign currency system would apply the conversion.

So, to create the entry we tried the following workaround:

·      We calculated the currency conversion manually for 100 EUR to CHF which would be 97.21

·      Created the expense account for 97.21

·      Initiated the payment in EUR system applied the currency conversion and updated the amount as 100 EUR and the transaction was completed.

The above workaround is not feasible as it is time consuming and there are always room for error. We have lot of stores in Europe region and there are mostly payments in local currency and EUR. It would make life simple if system could support to key in the amount in foreign currency or provide the currency conversion in the screen where the amount is entered before processing the payment.

P.S. We are also using the Income account (for cash-in) and Expense account (for cash-out) for recording cash transfers between the stores. As the tender removal and float entry operations out of the box doesn’t create any financial voucher entries in the system. So this functionality is really needed for the business for recording the day to day cash transfer transactions between the stores.

Currently, we have a product limitation where we're unable to issue internal gift cards through POS if the gift card is set as a "Product Master". They can only be issued through e-commerce and call center.

This is preventing customers from using the internal gift cards to their full potential if they need to sell pre-defined amount gift card variants out of the box through POS.

Note that this limitation doesn't seem to be mentioned in Microsoft's public documentation on internal gift cards, which can cause further confusion. Therefore, updating the public documentation to reflect the current limitation would be appreciated in the meantime.

We try to integrate 3rd party POS through standard entities. We have an entity for most of what we need, but one thing is missing - the tender declaration transactions (=counting of money in till at the end of the day).

The entity RetailTransactionTenderDeclarationTrans does exist, but cannot be used for data import. It looks like it can only be used for updating existing transactions, as part of the Retail auditable transaction composite entity (https://learn.microsoft.com/en-us/dynamics365/commerce/edit-cash-trans).

It should be possible to import the whole dataset from a store using standard entities and there should be an entity for the tender declaration. I have heard that it might have been possible before, but was later deprecated.

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.

In few scenarios, a single serial number is used for the same product but with more than 1 item.

In some scenarios, it is needed to sell 50 units of each item in a single transaction at the POS.

However, this requires excessive scanning, which is not ideal for a retail environment.

As per "Work with serialized items in the POS - Commerce | Dynamics 365 | Microsoft Learn" document:

“When selling or fulfilling serialized products through the POS application, a quantity of "1" is enforced for the serialized items on the sales transaction. This is a result of how the serial number information is tracked on the sales line. When selling or fulfilling a transaction for multiple serialized items through POS, each sales line must be only configured with a quantity of "1".”.

This is a feature request to have a feature to allow customers to increase the quantity of serialized items in the POS cart if the feature is enabled.

The customer wants to Add a price checker as the customer is capable of scanning the items through a barcode scanner and then the price of this item appears to him and the screen returns to its original view without needing any customer efforts as clicking or choosing certain options to minimize customer efforts and save time for customers to check for prices from the staff side. this will help for a better customer experience and time saving from both sides rewrite this in a better way.

Customer wants to use excel add in when he is looking for data entity to use to use DMF projects to import the data instead of the add in.

We checked the data entity the excel add-in uses RetailTmpBulkProductAttributeValueEntity and data management is set to no.

Can we change the behavior of this entity to be set to yes? Or add any other entity that supports DMF projects?

Issue:

Call Center sales order is created with Automatic reservation, when the sales order line is updated in Excel, the field “Quantity Reserved” added to the Sales order line is not updated with the quantity value. The reservation however has been made.

Issue_Ref#796047

Idea:

SalesOrderLineV2Entity to support updating creating/editing retail sales line fields.

Thanks!

If an order has two lines, the first one the product was delivered to the customer after the purchase (carry out) but the other is not delivered yet, it's currently not possible to cancel that line. The only way to achieve this scenario from POS is voiding the line, however, this is not desirable process considering a fraud perspective.

This functionality is available for call center, so the experience should be the same at POS, allow to cancel a customer order which status is partially invoiced status.