14
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
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
STATUS DETAILS
Declined
Comments
Can this be revisited please. Suggestions above make complete sense
Category: Customer and Loyalty
Administrator
Thank you for your feedback. Declining due to the low number of votes.
Best regards,
Maria Shneerson,
Senior PM