Dynamics 365 Commerce

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.

During a recent project, this request was made by the customer.

Unfortunately, there is no easy way to set a register to a training mode, e.g. to train employees without making inventory and financial postings.

To do this, a new store with the corresponding setups must first be created at considerable expense in order to then set up a demo register.

I would like to have two simple functionalities here:

1. the possibility to put an existing register in the Store Commerce app into training mode by clicking on a corresponding training mode button to be able to perform training there. Ideally, the visual appearance of Store commerce app should change during training mode so that the training mode is easily recognizable.
2. the possibility to switch a register in the D365 setup to a test mode / training mode via a boolean switch. This allows HQ staff to test their settings on the PROD environment and use an identical POS as the stores (without the detour via the UAT).

In my estimation, all customers with whom I have worked on retail projects with D365 so far would want to use these functions.

So MS, make it happen 8-)

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.

Actually, in POS when customer makes a return order in the screen on the POS all products are shows in the transaction and is necessary select one by one quantity and reason code. If the lines in transaction are too much, users lost the trace that items selected because not are market in the screen.

Customers want to see all items selected in the return screen to can be more efficiently the process.

avoid using Person-type Customer accounts. We’re requesting your input on the feasibility of an alternate solution that leverages GAB contacts.

We proposed an approach where each user accessing the Online Store would be associated with a Customer account (Type = Person). These Person-type accounts are linked to their respective Invoice Accounts (Type = Organization) via the Customer hierarchy. Delivery address, lead time, and auto-charge logic are driven by values defined on the Organization-type Customer account.

We do not want to create separate Person-type Customer accounts, as they believe this would:

• Introduce data clutter and confusion in their CRM
• Conflict with their existing customer/contact structure

They are proposing an alternative:

• Use contacts from the Global Address Book (GAB) linked to Organization-type customers
• Map these contacts to Commerce identities (based on email)
• Let users select a delivery address during checkout, and base lead time/charge logic on that selection rather than the user’s customer record

Idea:

1. Commerce Identity Mapping
2. Can GAB contacts be authenticated in D365 Commerce as B2B users without being Person-type Customer accounts?
3. Lead Time & Pricing Logic
4. Is it technically feasible to:

• Use delivery address selection at checkout (regardless of user record)
• Drive lead time and charges logic based on the selected address, not the logged-in entity

1. Commerce Limitations
2. What, if any, limitations would we face in using contacts instead of customer accounts for:

• Storefront login and access
• Order history visibility
• Address validation and delivery charge logic