Dynamics 365 Commerce

implement the ability to cancel a Purchase order line or the entire purchase order from store commerce.

This is because in some businesses it is the store commerce user who placed the order and knows whether that line will ever be received or not and not the HQ user.

Currently there is just one parameter to control the number of days an authorization is valid for all card types and all payment connectors. We would like the ability to be able to specify PayPal with a 14 day Authorization and Adyen/Credit Card at 30 days or the ability to set Visa & MasterCard at 21 days and Amex at 7 days, etc.

As more customers adopt omnichannel commerce - including Store Commerce (Retail Channel), E-Commerce, and Customer Service (Call Center App) - it would be beneficial to integrate the Media Library / Omnichannel Media Management feature with D365 F&O Call Center. This integration would ensure that product images uploaded in the standard CMS system are also visible to Call Center users when they query products in F&O.

Pain Point:

Currently, for Call Center users to see product images, the images must be manually imported into D365 F&O using Data Management Framework (DMF). This adds an extra step, especially when the same product is already being used across POS and E-Commerce channels.

Advantage:

By integrating the Media Library / Omnichannel Media Management with F&O, it can also serve as a centralized workspace to assign product media, ensuring a seamless and efficient media management process across all channels.

Product images should be shown in the body of emails sent to customers. This was possible to do before Omnichannel Media was released by Microsoft.

The method was to add a HTML string to the email template and use to use the search file name API or the legacy file name convention.

The Omnichannel Media feature changes the URL structure for product images which means we are not able to pull product images into the body of any email (Order conf, order shipped etc)

In D365 F&O we can define for each online store if prices include taxes or not. Both of these functionalities don't work for our client because he needs the way how prices are calculated when prices not include taxes (same subtotal for all countries), but also need to show prices with taxes in the site's pages.

The taxes that apply by default should be the taxes defined for the specific LE.

The "Store hours" feature allows user to configure working hours for each day.

However, for stores running 24 hours or closing past midnight, D365 does not allow user to input the closing time due to the error "

The store hours range cannot be saved because the close time must be greater than the open time".

Please allow configuration of store hours for timings that cross 12:00 AM.

After a eCommerce order or a Customer order is placed in POS, when you go to Retail and Commerce > Inquiries and Reposts > Store sales, populate a date range and mark all transactions, the Category has no data.

Cash and Carry transactions for the same item does have a Category populated. This is true even when you added the item to the cart by navigating to the navigation hierarchy and add the item.

Because the Category is not populated, you cannot filter the report on Category.

In our experience there were multiple Features (marked as non-mandatory) enabled automatically after an Environment (Microsoft) Update. After further investigation and support from Microsoft, we were advised that these Features were enabled automatically in relation to Copilot. In other words, in order for Copilot to work as expected, these Features needed to be enabled.

As end-customer had not given their consent, nor were features marked as Mandatory - we were all very surprised how this happened. What we understood from Microsoft Support was that the Product Group manages how the Features for Copilot are enabled and it's not decided by end-customer.

In our experience the Features were enabled after a Proactive Quality Update, they did not cause any issues (at least to our knowledge). However in the same period we had a huge Performance degradation, probably not related to enabled Features, however we were non the less very surprised and at the time we looked at this as a root cause for the performance issues.

Our concern is that by this logic, we can get a lot of features enabled by default after an Update, without them being marked as Mandatory and we believe that this will cause a lot of confusion, the least.

Since (in our case) the features were linked and are required for Copilot - would it be possible to mark these Features as "Mandatory for Copilot" for example, or mandatory for anything else that requires the feature as a prerequisite.

Or, at least add these details in the Update release notes - this way, it's clear and customers are notified of this.

When looking at the performance for CPOS here in Norway, I can see that it can take a bit of a time to complete a transaction.

After the last payment is registered then the following happens:

• HardwareStation/LineDisplay/DisplayText
• RetailServer/Commerce/GetFiscalIntegrationTechnicalProfilesBySearchCriteria is called from the POS
• RetailServer/Commerce/GetFiscalIntegrationServiceStatus is called from the POS
• RetailServer/Commerce/Carts()/Checkout is called from the POS
• HardwareStation/PaymentTerminal/Unlock
• RetailServer/Commerce/GetFiscalIntegrationFiscalDocument is called from the POS
• RetailServer/Commerce/SubmitFiscalIntegrationDocument is called from the POS
• RetailServer/Commerce/SaveFiscalIntegrationRegistrationResult is called from the POS
• RetailServer/Commerce/SalesOrders()/GetReceipts

Would it be possible to avoid all this ping <-> pong and make it more like this?

• HardwareStation/LineDisplay/DisplayText
• RetailServer/Commerce/Carts()/Checkout is called from the POS
• HardwareStation/PaymentTerminal/Unlock

Where the "Checkout" does all the heavy lifting and returns the cart info and also the receipt info. So, one call instead of seven (1 instead of 7).

Benefits:

• Fewer web calls and less data flowing over the wire
• Less code needed to run in the client.
• Better checkout performance times

The ability to be able to edit the "additional information" section of the screen layout is required, especially for compact devices. When using a mobile device for point of sale, the width of the information that can be captured is limited, Item / Quantity / Price, etc. There are instances where clients require the ability to see more information regarding the product line in the cart. This would be able to be managed by adding additional information to the lines. The setup exists on the screen layout where the information can be selected, however, it does not update the information that reflects at POS. It tends to only display the item barcode and a dimension, such as colour.