Dynamics 365 Commerce

I would like to have the ability to be able to exclude Brands at the line level under Category when setting up discounts. Our company is very SKU intensive so excluding by SKU would be very daunting. If we could exclude by Brand like we can exclude under Category by Class or Sub-Class, this would be very beneficial to our business.

Today when a receipt is printed out, then code is run to query and create the receipts based on a setup. If the receipt setup is changed then the original receipt will not be shown but the receipt based on the new setup.

Would it be possible to save the receipt information as JSON document to keep a copy of the receipt that is printed and thereby avoid re-creating the same receipt each time it is displayed or re-printed.

This could save some RetailServer - CPU time in the long run although it will use some extra disc space to store the information..

Not sure how this will fit with future plans on archiving old Retail transaction data.

After trying to use the attributes to extend some products data, we gave up due to slow performance in POS. The attribute code in Retailserver was/is complex and slow.

As SQL Server has some great support for querying and using JSON data, would it be possible to handle the attribute data or extended data for products as JSON documents?

So when a POS solution needs to extend the product information a JSON document could be a field in the product table. That JSON information could then be handeld by extension code to display it or use in it any extension logic.

This could open up a very flexible and fast way of extending product information were no new ext.InventTable is needed and replication does not need to be extended as the extended information is all in one JSON document column.

Same thing could be done around customers if needed..

The performance should be much faster than the current attribute solution.

In version 10.0.36 a new feature was introduced were "Product data is now cached in POS" to improve the scanning performance.

It would be great if the Commerce SDK would have general caching support to cache some frequently used data that does not change often to imporve the prerformance.

But this framework would have to be able to make sure it does not eat up all memory on the servers and thereby make everything slow down. And it would have to be some configuration on when to update the cache and how many objects a cache could hold.

The idea is a framwork, that developers could create a cache for data that they feel could benefit being cahced in extensions they build..

There is a setting "Allow manual card numbers" on the card setup that will open the card number field for all the issue, redeem and balance check operations on the POS. Ideally, we'd be able to isolate these operations and only enable manual entry on redemptions and balance check, but not on issue. This would force store staff to use the MSR or scanner to issue the card (and prevent bad data), but would still allow them to redeem against the card later if the MSR/scanner is no longer able to read the card after some wear and tear.

At the moment, when having two different parties of the Role "Customer Person", which are assigned to the same Customer hierarchy (necessary for the access to the Microsoft eCommerce / Online shop) and one of this Customer Person (= Party) is removed from the Hierarchy (the other one is remaining there) a merging of the Parties leads to the error "Cannot edit a record in Customer hierarchy nodes (CustHierarchyNode)”

This behavior has also been raised as issue but not been accepted as it is by design due to the soft delete mechanism of CustHierarchyNode table.

It should be possible to merge these parties to avoid duplicate records in the system. The soft delete function of the CustomerHieraryNode can remain but it must be possible to merge records with this.

I have discovered that when setting up a mix and match offer and establishing the line groups along with the number of items needed in those line groups, that this field acts as a minimum and a maximum. This limits the ability to offer a discount where a customer buys one item at full price and also can receive a % off discount on associated categories with that purchase. I believe there should be a way to have a minimum number of items specified as well as a maximum number of items specified (2 different fields) and they should be independent of one another. This way you don't limit the number of discountable items a customer can purchase.

This would also simplify having to set up multiple mix and match offers where you change the line group number to continuously be greater than the first line group. When you have over 10 items you want a discount to be applied (i.e. 247 items in the category you want to discount), this isn't possible to maintain and would take a great deal of time to setup. It would also be hard to even average the number of items a customer may buy that would be discounted.

The Manage Shifts screen in POS, needs be redesign from the usability point of view.

From version 10.0.35 the user now selects a shift then clicks the "Drawer icon" to declare either start amount, bank drop or tenders.

When the user finishes entering for example the start amount, it ends up again in the "Manage Shifts" screen were the line highlight follows the mouse cursor. The user gets often confused about what shift it was working with when it goes back the "Manage shift" form, as shift line is no longer selected.

Following changes could make things easier for the user:

• The user goes from the "Manage Shifts" screen to a "Drawer" screen where the user can enter all the different information for the drawer instead of having to go back and forth between "Manage Shift" and three different screens for the drawer. So, one screen instead of three.
• Would be nice to have some amount information in the "Manage Shifts" form, so the user can get an overview of the all the different total amounts for the drawer for each shift in the list. Thereby making it easier for the user to see what has been done.

The "transaction time" is not available on the SalesTransactionsV2 entity and the RetailTransactionSalesLineV2 table. It is an important information that is needed for analysis when checking out sales per item with relation to the transaction time each sales occur,

In order to track salespeople on the POS, we are required to create a commission sales group and attach the sales representative by linking a worker.

There is a data entity available to upload the list of commission sales groups, however the linking of workers has to be done manually. This is a gargantuan task for customers having an excess of 1000 employees across their stores.

Additionally, the default sales group has to be mapped on the workers form so the salesperson is automatically fetched on the POS for the cashier account. This is also being done manually for each individual worker.

A data entity needs to be made available to upload this data via Excel on Data Management.