Customers registered at system.
In mode ECOMMERCE is the user that log in to the application. All documents generated are linked to him.
In mode POS could belong to ticket.
Used in reporting and dashboards filters.
The most important parameters of the customers are:
- The status of the customer (allow to activate or deny access).
- The payment status of the customer (allow to activate alerts during ticket generation).
- The rate of the customer. (allow to specify specific prices for the customer).
- Locations. Adresses of the customer, where send the products purchased at mode ecommerce.
The tickets contains the customer who belongs to the document.
Application UI let edit and create new customers in mode POS. The employee must have an specific role to do that.
|Customer ID||Customer Identifier|
|Customer code||Customer code|
|CIF||CIF (VAT identification number) of customer|
|Mobile number||Customer's mobile phone number|
|Phone number||Customer's secondary phone number|
|Customer email address|
|Rate||Price rate identifier|
|Loyalty card||Customer's loyalty card(s)|
|Customer card||Card of customer|
|Payment status||Status of customer's payments
|Password||Ecom password validation
POS application UI example:
Ticket with flag customer, display selector of customer or set a new one.
Editing customer iinformation.
1.1 Customer status
The customer status is a flag that helps identify those customers that have pending payments or have never paid a product.
This flag can be activated from the Customer Object. This option can take three different values:
- 0 : No pending payments
- 1 : Pending payments
- 2 : Defauler customer
In the UI, these three status are seen as follows:
These warnings help the employee easily identify those customers that have a flag activated, and proceed accordingly. Please notice that by default this status is only used as an indicator. It does not alter any of the processes (sale, return, print ticket, generate pdf, etc.). If one wants to alter the processes depending on this status, this must be done manually.
Furthermore, they can be used in the processing of tickets in order to block a transaction or print warnings in the tickets.
As it has been mentioned before, this option is not automatically changed by default, and in order to be changed, it must be done manually, from the customer object seen before (upper right corner).
2 Customer rates
The application allows you to create rates of prices different from the sale price to the public and assign them to the different customers.
In this way, a price list can be established for each client or group of clients.
The most important parameters of the rates are:
If don't keep the retail price and let the price to 0 at rate, only inform the discount.
System will use the retail price of the product.
- In any case system use the best price. when retail price is lower than rate or specific prices are lower than rate.
|Header ID||Header identifier|
|Rate code||Rate code
|Name||Name of the rate|
|Starting date||Starting date
|Ending date||Ending date|
|Creation user||User Created
|Creation date||Creation date
|Update by||User who updated the record
|Update date||Update date
3 Price of product flow
* If exist a customer rate don't check for specific prices. Gets better than retail price or customer rate.
* Speceific rate also is compare with retail price to get the better one.
* All of this logic calculation it's at procedure: pos_ticketl_open_set_price