- Print
- DarkLight
- PDF
Tab 'General.
Customer number range | When a customer is created in RetailVista, a unique number will be suggested within this range |
Address format | An address indication can be displayed as street followed by house number or vice versa |
Customer address required | Is providing an address mandatory when creating a customer |
Email address required | Is providing an email address mandatory when creating a customer |
Email address or phone number required | Is providing at least an email address or a phone number mandatory when creating a customer |
Force email address uniqueness | An email address should be unique, meaning it can only occur once across all customers |
Pickup point customer type | From specified pickup points in webshop orders, new customers are automatically created. Such customers can be distinguished from regular customers by assigning them a separate customer type. The advice is to add a 'Pickup point' type to the customer types table and specify that customer type here as a setting. |
Tab 'Debtors'.
Debtor number range | When a debtor is created in RetailVista, a unique number will be suggested within this range |
Default payment condition | A new customer will receive this default payment condition |
Unique VAT code | By default, a specified VAT code for a customer must be unique. The idea behind this is that if the same VAT number were to be used elsewhere, it means that the customer already exists and you would want to prevent creating the customer again. With this setting, that behavior can be adjusted and it is allowed to use a VAT number multiple times. |
'Suppliers' tab.
Supplier number range | When a supplier is created in RetailVista, a unique number will be suggested within this range |
'Default values' tab.
This tab is about the suggestion of values when creating a new relationship and/or customer. It is only a suggestion, as these values can be deviated from directly during creation. However, if no adjustments are made, these are the default values for new relationships and/or customers.
Private relationship revenue type | When creating a private relationship, this revenue type will be assigned by default |
Company relationship revenue type | When a company relationship is created, it is automatically assigned this revenue type |
Default relationship type | A new relationship is automatically assigned this default relationship type |
Default discount agreement | A new relationship is automatically assigned this default discount agreement type |
VAT liable debtor | A new debtor is automatically VAT liable by default. |
Merge deliveries | Deliveries to a new debtor are automatically merged into one invoice instead of separate deliveries and corresponding separate invoices |
Pay deliveries immediately | A new debtor must pay a delivery in full immediately by default and is not allowed to make 'on account' purchases |
Always sell on account | A new debtor is automatically assigned all sales on account in RetailVista POS, even if payment is made in cash. This means that revenue always goes through 'sales' (invoicing) and not through 'cash' (cash sales). |
Auto print invoice in POS | For a new debtor, a invoice is automatically printed in POS when a sale on account takes place. This means that RetailVista POS will request the cloud environment to generate an invoice directly from the sale on account. |
Tab 'Newsletter'.
Newsletter integration active | |
Active newsletter provider | RetailVista has an integration with newsletter systems. This number of integrations can be expanded in the future. |
Email addresses automatically... | When an email address is added in RetailVista, it is automatically registered with the set newsletter provider. |
Tab 'RFM'.
RFM stands for 'Recency, Frequency, Money' and is related to categorizing customers into customer groups. This is based on recency (last visit), frequency (how often a customer visits), and monetary value (how much a customer spends).
Calculation months | How many of the past months should an RFM calculation be performed on |
Segment change delay days | If a customer moves to a different segment in terms of RFM calculation, after how many days can that change be made. By specifying a slightly larger number of days, erratic behavior is prevented where the customer falls into one segment one day and immediately into another segment the next day after a purchase. |
Unknown segment | If a customer does not fall into any segment in terms of RFM calculation, which segment can be assigned to such customers |
Out of scope segment | If a customer has not made any purchases in the specified past months, which segment can be assigned to such customers |