Retail best practice in relation to return receipt in many countries:
- When a return transaction processed.
- Two receipts are printed in one go.
- Receipt design are different than normal sales transaction receipts. Clearly stating return transaction receipt.
- Receipt copy 1. Customers copy. Customer keep.
- Receipt copy 2. Retailers copy. Dotted line. Customer sign name and phone number. This copy saved/archived by the retailer.
Provide a general parameter to say whether the deposit amount should include shipping charge.
If you now would have 50% desposit and the customer orders something with a shipping charge of 40. He deposit will include 20 for shipping. If the customer cancels his order in time/or later decides to do pickup in store, then you charged him 20 for nothing an a complete refund policy needs to start.
with this parameter our customers can decide themselves how they handle deposits on shipping charges
When creating a sales order in the POS, you cannot add a gift card with delivery method: cash and carry.
Allow that when placing an order, a customer can also buy a gift card at the same time as cash and carry.
the suspended transaction operations now shows only time, operator id and amount.
On a bussy day some sales persons walk around with the customers and already enters the items. The customer then goes to the register to pay for the products (there might be a queue here). as sales is mostly registered on customer name, it would be good to see customer name in the suspended transaction screen so at the register they can easily find the suspended order.
Currently, for Dynamics 365 MPOS Offline SQL Server 2014 Express Edition is being deployed for the Offline DB.
The suggestion received from a partner is to offer a functionality to use SQL Server 2016 Express instead. This would provide the following benefits:
- Leveraging data compession feature included in SQL Express from 2016 SP1 onwards (=> 10GB .mdf size limit)
- Having the latest stack technology in place (=> product lifecycle)
It should be pointed out with such an option thst the core components of SQL Server 2016 can be installed on a target machine having x64 OS only.
Please upvote this if you would like Retail capability to be enabled as part of on-prem deployment (LBD).
Please add comments to explain specific need and/or data points to add more justification for prioritizing this feature.
We have today received confirmation though the support that the POS Search functionalities do not support search on the new configuration drive extensions, customer attribute functionality introduced in the 2017-07 release.
We would like to suggest this functionality to be implemented, and that it is controlled by the existing check box "Searchable" in the attribute configuration.
Many retailers are moving away from physical loyalty cards but because a number sequence does not flow from D365 to the POS, Retailers using Dynamics will NOT be able to operate successfully with or without physical loyalty cards at the store.
With Physical Loyalty Cards
The OOB Loyalty program in Dynamics 365 does not allow a number sequence to flow from D365 to the POS. What this means is that OOB you have to scan in or key in a loyalty card number from a physical card. Any number can be entered and no number sequence allocation is respected. If you normally have a 10 digit loyalty card number and you key in 9 or11 digits the system will not stop you. The card this happens to becomes useless because the printed number will not match the system number. This physical card could never be used to link up with a customer.
Without Physical Loyalty Cards
When no physical loyalty cards are used by the buisness the card number still needs to be filled in at the POS. This means that a cashier could key in any unique number which is not something you would expect a cashier to do. If a number sequence could flow to the POS, you could configure the sequence to auto-generate a card number such that a cashier does not have to manually guess at what it should be.