Skip to main content

🌏 General concepts

This document describes various concepts that apply to most countries.

note

This is not an inclusive list i.e. some concepts are described and covered at the time of application or in the respective country compliance documentation.

Invoice behavior on exchange orders​

note

The requirement to allow for exchange orders can be toggled via a setting called Auditing:AllowExchangeOrders. Default value is false.

In countries where exchange orders are allowed, two invoices are always created. An invoice for the credit and another for the debit. This would also mean that at the end of a checkout flow, once all transaction impacting points have occurred, user would be able to retrieve two invoices in the orders overview documents tab. Further, any print consequent invoice print requests, would result in two invoices being printed automatically.

For a better understanding, let's look at some scenarios. All scenarios covered assume that an initial sales transaction of two items has occurred. Item no. 1 had a sales price of €15.00 and item no. 2 had a sales value of €60.00. The customer here ends up with the usual invoice, depicting the two purchased items with a total of €75.00. For one reason or another, the customer wants to return item no. 2 which had a sales price of €60.00 and exchange it for something else (an exchange order). This leads us to the following three possible scenarios:

Scenario 1​

For the exchange, the customer opts for a more expensive item (price €80.00)

Invoice 1 - Credit invoice​

Lines

  • 60 EUR (returned)

Payments

  • 60 EUR (exchange voucher)

Invoice 2 - Debit invoice​

Lines

  • 80 EUR (new item)

Payments

  • 60 EUR (exchange voucher)
  • 20 EUR (new payment)

Scenario 2​

For the exchange, the customer opts for a cheaper item (price €45.00)

Invoice 1 - Credit invoice​

Lines

  • 60 EUR (returned)

Payments

  • 60 EUR (exchange voucher)

Invoice 2 - Debit invoice​

Lines

  • 45 EUR (new item)

Payments

  • 60 EUR (exchange voucher)
  • -15 EUR (new payment)

Scenario 3​

For the exchange, the customer opts for an item of same value (price €60.00)

Invoice 1 - Credit invoice​

Lines

  • 60 EUR (returned)

Payments

  • 60 EUR (exchange voucher)

Invoice 2 - Debit invoice​

Lines

  • 60 EUR (new item)

Payments

  • 60 EUR (exchange voucher)

SAFT countries mixed orders​

Mixed orders are not allowed in SAFT countries. As per regulations, it is not allowed to have both return and sales lines in the same order in SAFT audited countries. In turn, the user will be notified with an error modal "You cannot create a combined sale- and return order, due to the regulation within your country" in scenarios where it applies.

Invoice product line description display​

If for some reason you would like to override the default product Description property on an invoice order line, you can do so by using a setting called InvoiceLineDescriptionProperty. The value of this setting should be a product property. The description of that product property would replace the default product Desxription property.

VAT and FiscalID​

There are 2 services GetShoppingCart and GetOrder where VAT and FiscalID are present. It could get confusing as to which one the system chooses at various scenarios.

Lets clear that confusion:

VAT Number​

The VAT number on the order object is leading. When a VAT number on an order is present, that would be the one shown on the invoice. If it's not present, then the VAT number under the customer object becomes the one shown.

Fiscal ID​

At POS checkout, having a Fiscal ID tile for user input of a fiscal ID is possible. If a customer with an existing fiscal ID available i.e. under customer object, and is already attached to an order, then that fiscal ID is prefilled.

If there is no customer attached, or if the fiscal ID field on customer object was empty, a manual input would then be possible using the Fiscal ID tile. The filled in Fiscal ID in this scenario would then be set on the order object and not the customer object. Meaning that if you attach that same customer to another order, the Fiscal ID input which was made on his previous order would not autopopulate.

In another scenario, if a POS user overwrittes the prefilled fiscal ID picked up form the customer object, the fiscal ID field on the order object would be the one updated and the one that would be shown on the invoice for that order. The fiscal ID on the customer object will remain the same. Again, giving the same meaning as mentioned above if that same customer is added to another order.