-
Change the Manager Privileges logic for user permissions
Currently, when the Manager privileges are activated in the user permissions form, all permissions are granted no matter how the setup is in the operations form. For EPOS you could define individually which operation should be connected to the Manager Privileges option by attaching the ID 1002 to the wanted operation. Since the current design is kind of unflexible, kindly implement that functionality again so that Manager Privileges can again be defined per project. In addition, please do implement a mechanism that all options in the permission form do show the defined setup by de-/activating the operations and hence give a visual feedback showing, what the real and current setup is for this user. Currently, just all options should switch no "Yes" - but hopefully in the future, only the operations defined in the operations form should then switch to "Yes" -
Use extended logon for Manager override
When a certain operation requires a Manager Approval, this user always needs to login with user ID and password - the existing extended logon feature cannot be used here. It would be good if the Manager approval could use this feature, as it would speed up such scenarios tremendously. Swiping a card takes less than a second, whereas logging in takes a couple of seconds. -
Support product attributes in sales quotations (like in sales orders)
It is possible to extend the POS(call center to handle attributes in a sales order. Related docs article regarding this particular feature: https://docs.microsoft.com/en-us/dynamics365/unified-operations/retail/dev-itpro/order-attributes Unfortuantely those retail attributes are not available for sales quotations. The method of real-time service = GetCustomerQuote does not have logic to fetch and return retail attributes. This is due to the fact that attributes are not supported in sales quotations, which is breaking the consistent user experience of the supply chain here. Hence requesting to also support attributes in sales quotations in the near future so they are part of the whole sales process. -
Implement parameter to control whether voided transactions can be printed or not
Currently it is possible to print receipts for voided transactions from the "Show journal" form. As this might be confusing for users, who are not interested in keeping voided transactions, it would be good if it would be possible to control this behavior. In addition, this is (unnecessarily) increasing the items shown in the "show journal"-form. Please implement a parameter to disable/control this functionality for voided transactions.
-
Export/Import of Loyalty points (into adjustment journal)
It would be great to be able to import (and export) loyalty points using a standard data entity of the data management workspace. This entity is currently missing, hence it requires a custom entity in order to be able to import starting balances or if you'd wish to adjust/grant points in one go using data from a third party system or Excel. For example to create points as part of a special incentive program (earn points on christmas/holidays, on your birthday etc.). -
Remove SysDatabaseTransDelete-class from the standard repository
Hi, Still a lot of customers do use the SysDatabaseTransDelete-class to remove test data. Unfortunately many of them do this because they think, they do reset the environment into a state, where it is like "clean and new" - and then start to use such a resetted environment as a PRO environment. Since this class does not completely remove ALL transactions, it is causing data corruption and will lead to problems later on while using the environment. In addition, using this class is not a supported scenario, which is causing big problems throughout the lifecyle of the product in the end. Hence I'd suggest to completely remove that class from the standard code (and later on replace it with a working class that is removing ALL data, performing a complete and supported reset of the transactional data).
-
Add predefined values/denominations to issue gift card operation
In many cases retailers do sell gift cards with a pre-defined amount that is printed on the card. Ideally it should be possible to scan the barcode of such an item and by doing that, the gift card id AND the amount should be entered and the gift card process should be completed. In addition, if this item is stock controlled, retailers would have an overview of how many gift cards are on hand in their stores. As a second best solution to this scenario, it would be great if it would be possible to define denominations when issuing a gift card. This way, typing errors can be reduced and the whole sales process is way faster. -
Implement a toggle to turn on or off the duplicate validation (RetailTransactionService -> findDuplicateSalesOrder)
Currently, some customers do experience issues because the prevention logic does not create sales orders for the same custmer with the same item created shortly after each other. Hence it would be good if there was a parameter to turn off this method or to be able to fine-tune this functionality so it only kicks-in when needed. -
Auto-select sales order header when a sales line without a sales order header is selected in the return order form
While performing a return order in the Customer Service form, it is possible to select sales order lines and process the return order without selecting a sales order head. This leads to a scenario, where the default RMA values from the call center parameters -> RMA are not applied to the return order. Hence it would be good, if there was a switch in the RMA parameters to implement a functionality to "auto select" a sales order header. Maybe controlled through a drop-down to auto-select the a. corresponding sales order header from the first sales line b. corresponding sales order header from the last sales line or c. prompt for selection -
Add flexibility to the address capturing form in POS
Currently, the address capturing in POS is straight-forward, but also not very flexible. Hence it would be great, if this form could also meet additional needs like: 1. Define whether or not a field should be displayed as a drop-down or not -> Counties e.g. cannot be displayed as a drop-down field, although it throws an error when a county is entered that does not exist in HQ. Hence it would be good to have the opportunity to elimiate this issue through parametrization. 2. Re-sorting of the input fields -> If you enter a zip-code, city and county can be pre-populated with the data from HQ, but unfortunately the ZIP-code field is not the first one, but the last field in the form. 3. Use the address format defined for the country in HQ to display the fields in POS -> This way, cashiers can enter an address using the field sorting they are used to
You’re offline. This is a read only version of the page.
