Dynamics 365 Commerce

It is often necessary to search for the paid amount in the search transaction operation. This is because the customer only has the bank transcript as documentation. If a paid amount filter in combination with a date is possible, there would be a much easier task to find the correct transaction.

Purge Commerce transactions feature does include the RetailEODStatementEventLog and RetailEODStatementControllerLog tables, but these tables grow so rapidity with each Commerce Transactional statement and do not get removed after the statement is posted, there are customers with over 3 billion records in the RetailEODStatementEventLog alone.

The Purge Commerce transaction feature does not allow you to purge sales transactions newer than the previous calendar year. I have seen over 24 million records in the RetailEODStatementEventLog for 6 months of data. If you have 1 year of data is the RetailEOD log files, the files are still very large.

There needs to be a purge just for the log tables alone. This way customers who do not want to purge Commerce sales transactions, can still purge the RetailEOD log tables if they want.

During a recent Adyen EU outage, it was determined that Dynamics 365 Payment Connector for Adyen was utilizing the EU-based Adyen Datacenters. We have learned that this is hardcoded within the platform and not configurable. Merchants need the ability to control the Geo of the Datacenter they are connecting to for performance and privacy regulations. Adyen documentation on current endpoints -https://docs.adyen.com/development-resources/live-endpoints/?tab=v5.x.x_or_earlier_1_2

When paying invoices in Channel (POS or another channel), the customer payment transaction is not taking into account the method of payment configuration, and it is using the ledger account configured in "Commerce Parameters > Invoice" instead of the ledger account configured in the store payment methods.

Can we have a feature or flight that changes this behavior so that paying a sales invoice through POS will use the ledger account number specified in the store payment methods instead of the account specified in commerce parameters?

I would like to propose the idea to allow the customer number sequence creation in Manual for B2B Ecommerce prospects creation. Right now, according to Microsoft documentation this has to be set to Automatic, while setting this to Manual is returning an error with the following message: "Customer number sequence set to Manual. Customer could not be created"

We prefer to keep in control the customer creation process, our AR team has been doing this for a while but for B2B scenarios is not possible.

Thanks!

It's quite common in a retail environment to allow the sale of an item, but not a return.

We need a method on the product or elsewhere that will allow us to allow sales but no returns.

For example if I sell a promotional item at ALL SALES FINAL I don't want the cashiers to have to remember which items are returnable and which are not. This can be a VERY lengthy list and is impossible to manage without some blocking mechanism.

To enable reporting and automation of customer updates, it would be helpful if the Customer V3 data entity could be extended by Microsoft to include the 'Block customer for loyalty enrollment' boolean.

I would like to provide feedback regarding the Order-On-Behalf (OBO) functionality. Currently, a customer can only be assigned to a single Sales Group, but there are scenarios where customers need to be part of multiple Sales Groups. This arises from the requirement for an n:n relationship in OBO, where there is an overlap between Sales Groups. In certain cases, businesses may have specific product assortments available through separate eCommerce platforms, where vendors/importers log in to place orders on behalf of customers. However, vendors should only have access to selected customers assigned to their OBO account. The issue is that multiple vendors may share overlapping customer lists, and the current limitation of assigning a customer to only one Sales Group makes it difficult to properly manage these restrictions.

I hope this can be considered as an additional requirement in future updates to the B2B2B functionality.

Inquiry regarding the ability to prevent price overrides on specific SKUs/items within the Retail and Commerce module. The customer wants to have the ability to stop the register from allowing price overrides on certain SKUs/items, plus the process to set it up. Basically, a way to enforce pricing rules at the product level to prevent unauthorized price changes.

We need a unfolded comment field in the check-out process.

We believe that having the comment field always visible would enhance the user experience.

There is a huge disadvantage of hiding the field - our customers will not see that a comment field is existing when hitting the checkout and, if the customers discovered that there is a hidden field, he/she has additionally do one more click to open the field.

In an eCommerce world aiming for fewer clicks, the hidden comment field is not really an advantage.

Can you please configure this comment field module as unfolded instead of being hidden for the customer.