Dynamics 365 Commerce

Orders paid via on-account payment method from call center, when returned in POS, do not show any refundable payment methods.

This is addressed in LCS issue 866741:

https://fix.lcs.dynamics.com/Issue/Details?bugId=866741&dbType=3.

However it is marked as Postponed, with workaround that the end user can use the Manager override option to see all the refund options.

In some scenarios, retailer doesn't want to grant manager privilege to store users which would cause more concerns.

Please support this scenario and allow POS user to refund the call center order which paid by customer account.

Accurate Financial Reporting: Ensures that the difference amount accurately reflects the bank drop, improving financial transparency.

Simplified Reconciliation: Makes it easier to reconcile bank drops with counted amounts, reducing errors and discrepancies.

There should be a link between the method of payment defined in the accounts receivable module vs the payment methods defined in the commerce module. This would allow for automatic banking fees to be posted for specific payment methods at POS.

Currently, when paying a "deposit" for a customer order, a customer payment journal is posted but the method of payment field on that form is blank.

An example where this will be able to be used will be if a specific payment method charges a bank fees to the business on each transaction. With a link to the AR method of payment, this should populated on the customer payment journal. During the posting process the fees for the payment can automatically be posted in the correct account so that the business does not have to do manual journals and reconciliations on each of the transactions.

Submitting a new copy of this request as Boyce Zhu declined the original Idea with a comment that does not address the original suggestion.

"DOM gives preference to shipping orders completely from one location. Therefore, if a whole order and its lines aren't available from a location that has a priority of 1, DOM will try to fulfill it from a location that has a priority of 2."

In certain cases, the business would prefer that the order split ship between a priority 1 and priority 2 location instead of consolidating the entire order to a priority 2 location but there's no option to configure DOM this way. In our business-case, priority 1 is our DC and priority 2 contain our brick-and-mortar stores.

Take for example an order for 10 items. 9 out of the 10 items are available at a priority 1 DC location. All 10 items are available at a priority 2 store location. DOM will route all 10 items to the priority 2 store location. But we would prefer that the DC location fulfills 9 of the 10 items and the store location fulfills the last item. We'd prefer the store not wipe out that inventory that could have shipped from the DC.