Eduardo Rivera Mendoza

After making some change on our e-commerce site using the site builder, there is nothing tool to review those changes.  Right now, to review changes on site builder, use the site copy functionality from UAT to Prod would be the one option to let us ensure that no inadvertent changes have been made in UAT prior to the promotion.

Review more than one site takes a lot of time to users, some customer has more ten sites.

A single page at the domain level listing object changes for all sites in order of date modified would be the most ideal to fulfil our audit requirement. Having it be exportable would be great too.

When the daylight-saving change on different countries some customers need to prevent that your transactions don't be posted on the next day, because the date's logic to post Retail transaction affect the post. Currently time zones don't consider the current daylight-saving offset active for a region and customer operations it´s affected, customer needs Edith and Audit transactions manually or

Especially for companies that have work shifts that are making a switchover around 00:00 it happens that transactions are posted on the wrong day as a result (as a result of the applied offset 01:00 instead of 02:00). It also has its effect on external systems that receive transaction data from F&O.

If customer.

Change the actual logic on Commerce to post transactions, could be a stronger impact, but the Idea is giving a section to customer to they can parametrize their own daylight-saving setups and post their transactions without more manual actions and process stuck.

When Azure process it's enable on Commerce parameters the search process on POS is changed from  SQL search to Azure search and that change the user way to find items o POS screen. With SQL Search users do not need include asterisk in POS screen to find items or customer with partial text, and when Azure search it´s enable, user needs to type asterisk on POS to obtain the partial text results. The expectation is that Aure search include the search text without asterisk in POS.

Out of the box, the functionality profile allows us to set up receipt formats for cash and carry transactions and reset the number sequence. However, we cannot unify the number sequence by store, as it is currently set per device. In some countries, governmental authorities require that cash and carry transactions be identified with a consecutive sequence by store. Therefore, the request is to enable a single consecutive number sequence for cash and carry transactions per store. Thanks

Currently, financial dimensions for inventory transactions such as stock count, inventory movement, or inventory adjustment are derived from the financial dimension's configuration of the store and the product, without considering the dimensions configured in the register. In scenarios where there are different departments within the same store, such as hardware, butchery, or grocery, it is crucial to maintain the dimension per register rather than per store. The request is to include the financial dimensions of the register in the financial dimension record combination in Dynamics 365. Thanks.

Currently, after the checkout process concludes on an e-commerce sale, the system requests sandbox batch jobs at HQ to send the sales order confirmation receipt or another specified receipt to the email address listed in the customer's profile. The new request is to send the sales receipt immediately after the payment is processed during the e-commerce checkout, including all relevant information, without waiting for the HQ process or creating an RTS extension.

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!