How is the revenue type of a transaction determined?

Every transaction in RetailVista (cash and on account) is always assigned a revenue type. This document explains how this revenue type is determined. To explain this properly, an important distinction is made between transactions originating from RetailVista POS, RetailVista ERP, and the packaging application. These are the 3 systems in which transactions are created.

Starting from the January 2024 update, it is no longer mandatory to specify a revenue type for a debtor relationship. In fact, it is advised to remove the existing assigned revenue types from relationships. Several new settings have been added since that update, including a setting for the default revenue type for on account transactions and a default revenue type for webshop transactions. When creating a delivery on account, the default revenue type for on account transactions is used.

It has been decided not to fall back on the default revenue type setting for on account deliveries if the on account revenue type setting is not specified. The reason for this is that in the past, a revenue type was always enforced on relationships with a debtor. If no revenue type is specified for the relationship now and the default revenue type would be used as a fallback, on account sales would suddenly fall under the default revenue type, which is almost always 'Cash sales'. Therefore, if the decision is made not to specify a revenue type for relationships with debtors anymore, it is highly recommended (actually mandatory) to set the default revenue type for on account sales.

RetailVista POS

In RetailVista settings, a default revenue type is specified to which all 'Anonymous cash sales' are assigned. An alternative revenue type can optionally be set for each individual POS terminal.

If that is set, then that turnover type takes precedence over the general setting.

For payment methods of the type 'On account', a turnover type can optionally be specified. If this is the case and such a payment method is used, then that turnover type is always applied.

When importing a reservation, the turnover type of the relationship of that reservation is taken into account. It is possible to assign a specific turnover type to a relationship. If this is the case, then that turnover type takes precedence over the turnover type of the POS terminal and/or the general turnover type setting. It is advised not to use a turnover type at the relationship level anymore, as it exists for backward compatibility. It is better to let the different mechanisms (RetailVista POS, ERP versus pack&ship application) do their own work and result in a correct turnover type.

In all the above situations, it does not matter whether a cash delivery or an on-account delivery is created in RetailVista POS.

The determination of the turnover type per type of action is summarized as follows:

Start transaction: POS terminal turnover type > Standard turnover type

Import reservation: Relationship turnover type > Webshop turnover type (if webshop order) > Standard webshop turnover type (if webshop order)

Pay transaction: Payment method turnover type (if specified)

From this list, it is clear that the turnover type settings for 'On account' are no longer used. If it is important that on-account sales are booked on a separate turnover type, it is advised to link that turnover type to the corresponding payment method.

RetailVista ERP

In the backoffice of RetailVista, only on-account deliveries can be created. When creating an on-account delivery, it is always mandatory to enter a debtor. The turnover type specified for the relationship of that debtor is adopted for the on-account delivery.

The revenue type determination is summarized as follows:

Revenue type relationship of customer (if specified) > Webshop revenue type (if webshop order) > Default webshop revenue type (if webshop order) > Default on account revenue type

Pack & Ship application

The Pack & Ship application generates on account deliveries from reservations. The revenue type for an on account delivery is based on the specified revenue type for the customer relationship. A reservation is always linked to 1 sales order, and the sales order may have a customer specified. If that is the case, the on account delivery is linked to that customer and the revenue type of that customer is taken over.

For webshop-linked sales orders where no customer is assigned to the sales order, a collective customer is applied. This is specified in the webshop maintenance. If no webshop is linked to the sales order and no customer is specified, the packing application cannot handle it.

Starting from the January 2024 update, new settings exist for the revenue type of on account transactions and webshop transactions. A revenue type can also be specified for each webshop. When the packing application handles a webshop reservation, it first looks at the revenue type for the webshop. If it is not specified, the default webshop revenue type is applied. If that is also not specified, it falls back to the new setting with the default revenue type for on account transactions.

The revenue type determination is summarized as follows:

Revenue type relationship of customer > Webshop revenue type (if specified) > Default webshop revenue type (if specified) > Default on account revenue type