1 Customers

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.

Label Description
Customer ID Customer Identifier
Customer code
Name Customer name
CIF CIF (VAT identification number) of customer
CIF type

  • Default: 0
  • Values:
    • 0: Person.
    • 1: Company.
    • 2: Company no UE.
    • 3: Passport.
    • 4: NIE.
    • 5: Other.
Mobile number Customer's mobile phone number
Phone number Customer's secondary phone number
Contact Contact person
Email 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

  • Default: 0
  • Values:
    • 0: Valid.
    • 1: Pending payments.
    • 2: Defaulter.
Password Ecom password validation

No paper Indiccative to don't print ticket during TPV sale. will be send by mail.

  • Default: 0
  • Values:
    • 0: No.
    • 1: Yes.
Status Client status

  • Default: 0
  • Values:
    • 0: Open. Open
    • 1: Closed. Closed
Created by

  • Default: USER
Date created

  • Default: CURRENT
Updated by

  • Default: USER
Date updated

  • Default: CURRENT

Mode 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:

Example of customer list with the three types of status (pending payments, defauler, none)
View of a customer with pending payments in the Sale View
View of a defauler customer in the Sale View

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.

Label Description
Header ID Header identifier
Rate code

  • Case: Upshift
Name Name of the rate
Starting date

  • Default: CURRENT
Ending date
Status Rate status

  • Default: 1
  • Values:
    • 0: Disabled.
    • 1: Active.
Creation user User Created

  • Default: USER
Creation date

  • Default: CURRENT
Update by User who updated the record

  • Default: USER
Update date

  • Default: CURRENT

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