Dynamics 365 Commerce

Description:

This feature aims to ensure that the cost amount is consistently updated for customer orders in the store transaction form, similar to how it is updated for cash and carry transactions. This will help maintain accuracy in cost reporting and streamline the process for users who need to generate reports and analyze the cost of goods sold.

Currently, the cost amount is not updated for customer orders in the store transaction form, causing significant issues for users. They are unable to retrieve cost details from sales transactions, even after the sales order is invoiced. This inconsistency affects the ability to generate accurate reports and determine the cost of goods sold, leading to substantial business impact.

Business Impact:

• Users cannot determine the cost of goods sold from the retail front.
• Inability to generate accurate sales reports.
• Manual effort required to dig into InventTrans to view cost details.
• Significant disruption in financial reporting and value recognition.

Request:

We propose to ensure that the cost amount is updated for customer orders in the store transaction form, similar to cash and carry transactions.

1. Implement logic to fetch and display the cost amount for customer orders once the sales order is invoiced.
2. Consistency Across Transaction Types: Maintain consistency in how cost amounts are handled across different transaction types (cash and carry, customer orders) and ensure that the cost amount is visible and accurate in the store transaction form for all types of transactions.
3. Automated Updates:

• Automate the process of updating the cost amount for customer orders to reduce manual effort and errors.
• Implement checks to ensure that the cost amount is correctly updated and displayed in the store transaction form.

Benefits:

• Improved accuracy in cost reporting.
• Streamlined process for generating sales reports.
• Reduced manual effort and errors.
• Enhanced financial reporting and value recognition.

On the POS there is the option to set up the buttons "View available discounts" and "View all discounts".

If you scan an item that is part of a currently valid promotion and then tap on the "View available discounts" button, the appropriate discount for the item is displayed, but only the name from the "Name" field of the discount from the settings in the back office. 

Although this can be freely selected, it does not usually contain the conditions of the discount described in detail.

On the discount itself, in the "Details" fast tab the "Description" and "Disclaimer" fields, among others, can be filled out.

It would be great if the contents of these fields were also displayed on the POS when a cashier displays a discount.

In the practical example, one of our customers has a big product portfolio. Up to 100 different discount campaigns are active at the same time. These are difficult for a cashier to remember. 

It is helpful here to at least be able to access the discount information.

This would also create a form of communication transfer from the marketing department to the store.

The sealed hardware installation requires the .exe to be run from a terminal with all the data needed whereas the self service installer used a UI to receive the data. The self service installer downloaded IIS and created the necessary Registry keys such as TLS 1.0 Client and Server and TLS 1.1 Client and Server, with the necessary DWORD values. The sealed installer does not do this thus requiring manual addition of the keys and the installation of IIS. Can the sealed installer not be made to do this as well similar to the self service installer.

Payment methods are configured per call centre channel to allow processing sales order and take customer payments.

Navigate to

1. All call centre (Retail and Commerce > Channels > Call centres > All call centres)
2. In action pane, Under setup tab and setup group, click Payment methods
3. In the payment methods screen, select a payment method and click Payment transactions.

Notice, that the payment transaction only shows all the payment transactions from store, but it doesnt show sales orders created via call centre thought they are also called Retail sales (Retail sales checkbox is marked yes for such orders).

It would be great if we can see sales orders per payment method used in call centre (like we can see store payment transactions) or have a way to filter out orders paid via certain payment method.

Current situation:

At the POS in the SCA during the checkout there is a step called "Do you want to email the receipt?"".

In this step you need to enter your email address and there is also a boolean field that must be switched from “off” (default) to “on” to activate the "receipt per email" function.

However, there are two additional buttons in the step: “Send” and “Don't send”.

Both buttons are active and clickable, regardless of whether the Boolean field is set to “Off” or “On”.

Possible outcomes are:

1. Boolean "Off" + "Send" = no email receipt is sent
2. Boolean "On" + "Send" = email receipt is sent
3. Boolean "Off" + "Don't send" = no email receipt is sent
4. Boolean "On" + "Don't send" = no email receipt is sent

One step is redundant here.

Idea:

Remove boolean field.

Leave the “Send” button inactive as long as no valid email address has been entered.

If a valid email address has been entered then the “Send” button can also be clicked.

A format validation is sufficient to validate the email address - anything@something.TLD

Background & Business Need

In retail environments, especially at the Point of Sale (POS), predictable credit memo number sequences can pose a significant fraud risk. As highlighted by a customer in a recent support interaction, if credit memo numbers follow a sequential pattern, a cashier could potentially guess and manually enter the next number in the sequence. This opens the door to unauthorized or fraudulent returns.

Proposed Enhancement

To mitigate this risk, we propose enhancing the credit memo number generation logic by introducing a randomized component. 

Benefits

• Reduces the risk of fraudulent returns by making memo numbers non-predictable.
• Enhances security and auditability at the POS.

Customer Impact

This request stems from a real-world concern raised by a customer actively using D365 Retail and Commerce. Addressing this would not only improve security but also demonstrate responsiveness to customer feedback and operational realities.

When a customer uses an Adyen connector on POS and needs to identify the relationship between cash and carry transactions and the Adyen reference, they must search through HQ transactions for each payment individually. This involves navigating to Store Transactions > Payment Transactions > Payment Authorization Token and sorting through 25,000 characters to find the tender reference. This reference is then used to match the transaction with the Adyen tender reference field, confirming that the transaction is the same on both Dynamics and the Adyen portal.

Another issue is that this search only works one way. If a customer requests the receipt number or sales order number, they can retrieve the relevant information. However, if they only have the tender reference number, they cannot search D365 for this number. This is particularly relevant in chargeback cases, where a charge appears in Adyen but no corresponding transaction is found in D365. Without manually reviewing every sale record for the store on that day, the customer cannot confirm whether this was a problematic transaction. This is similar to the situation with ECOM, where the data sent to Adyen includes an authorization number for the payment in D365.

The request is to implement a quicker way to identify the Adyen reference in the Dynamics user interface, ideally in an individual field, using the receipt or transaction ID.

Thanks!

Objective: To enhance the security, efficiency, and customer service of return transactions in cash-and-carry stores by requiring valid customer details (contact number and email) for all return orders.

Feature Description: Implement a feature in the Dynamics 365 Commerce Point of Sale (POS) application that mandates the collection of valid customer details (contact number and email) for all return order transactions in cash-and-carry stores. This feature will ensure that every return transaction is associated with a verified customer, thereby improving the overall return process.

Justification:

1. Customer Verification: Ensures the identity of the customer making the return, reducing the risk of fraudulent returns.
2. Return Tracking: Maintains a detailed record of returns associated with specific customers, aiding in inventory management and return pattern analysis.
3. Enhanced Customer Service: Enables the store to provide better customer service by notifying customers about the status of their return or any issues that may arise.
4. Marketing and Communication: Allows the store to use the collected contact information for marketing purposes, such as sending promotional offers or updates about new products and services.
5. Compliance and Reporting: Helps in complying with legal requirements for collecting customer information for returns, ensuring adherence to consumer protection laws.

Implementation Details:

• Modify the return order workflow in the POS application to include mandatory fields for customer contact number and email.
• Validate the entered customer details to ensure they are in the correct format.
• Store the customer details securely and associate them with the return transaction record.

Impact: This feature will enhance the security and efficiency of return transactions, improve customer service, and provide valuable data for marketing and compliance purposes.

When using a MediaServers created through IIS for all self-hosted environments.

After installing the latest version or any version update, we see that the MediaServer is deleted from the IIS during upgrade. Can you add a way or any workaround to avoid this situation?

The current workaround is to go to each CSU server and manually recreate it, but this is time consuming and isn't very efficient overall.

Considering many business get their product master data into D365 from other PIM-systems, it can sometimes be hard to track the completeness of all your products - especially when you have a lot of them. One thing that can be hard to track is if products have been included in any assortment or not. The reason could be that product(s) are missing a category assignment and wont be included in the processing of the assortment since many businesses create their base assortment to include 'All products' (top node of the commerce hierarchy).

This means that products in-store can sometimes not be sold at that point in time and we only find out which products are faulty at this point too in order to assign a category and re-process the assortment. A view/report similar to 'products by category', but instead 'products without category' or 'non-assortment products' that will clearly filter out any products that do not belong to any assortment or category node in the commerce hierarchy. With this report, businesses could easier be proactive in correcting the faulty products and minimize the risk for lost revenue and bad customer experience in the stores.

DMF doesn't fulfill this as it can't export the ProductsV2 entity with filter criteria "" (or 0) for the Retail Category-field (this only leads to a completed export with 0 records even though there are items that do have a null category assignment). And exporting a full list of released products and comparing a full push of the category assignment-entity doesnt work either when the amount of records are passed 1 million.

Best regards,

Victor