The entities

To push sales from the external shop to the invoicesystem data is first pushed to Wisteria. The data needed to be able to push sales can be divided into two groups:

• Data related to the shop: This is data that is used for every sale. It is added once and only updated when the data in the external shop is update. The entities are Categories so that POS turnover can be grouped per productcategory, Taxes for the VAT calculation in the externalshop and Paymentmethods used in the externalshop.
• Data related to the sales: Sales data changes frequently. Every day there are possibly new sales that can be pushed to Wisteria and from there pushed to the invoicesystem. Sales contain privacy details and are therefore only stored in Wisteria for a limited amount. Depending on the type of externalshop there is order / invoice / refund data - mostly used of online sales in webshops - and receipts - closures for POS. Receipts and closures can be used for daily turnover bookings. The entities are Customers, Orders, Invoices, Receipts and Closures.

Individual bookings versus daily bookings
Most shops will work with individual bookings. With individual bookings every sale in the external shop is pushed to one transaction in the invoicesystem. Customer- and productdetails are also pushed. Payment-details are not pushed.
Sometimes a daily booking is preferred. With a daily booking all sales of one day are gathered and are pused as one transaction to the invoicesystem. We see this happening often for POSes, since for POSes customer data is not required. Therefore we only have the daily bookings available for the entity Receipts. The entity Closure can be used if the external system provides the dailybooking instead of separate receipts.
Many invoicesystems have the option to add a daily booking, but not all of them. Some invoicesystems allow a hybride option. You can choose per paymentmethod whether the receipt should be part of a daily booking or should be pushed separately to the invoicesystem.
We advise to use only daily bookings when the external has good, built-in day-reporting, so that mismatches can be easily found.

Categories
Categories are used in dailybookings to the invoicesystem. It is possible to assign different ledgercodes to categories so that the turnover in a daily booking is assigned to different ledgercodes in the invoicesystem. Otherwise the ledgercode depends on the VAT of the turnover.
We advise a maximum of 70 categories. With more categories the connection is real hard to maintain and support.

Paymentmethods
Paymentmethods can appear online shops and in POSes. For the pushing of individual sales it is possible to assign a default debtor to the paymentmethod. This means that a sale is not booked on the real debtor in the invoicesystem but on a specified payment-debtor. It may make the processing easier in the invoicesystem.
For daily bookings the payments are booked on separate ledgeraccounts.

Taxes and Ledgercodes
Taxes are tax percentages, possibly assigned with a country code. So you get 21% for NL and 21% for BE. The country codes are important. It makes it possible to book turnover per country. Also for countries different VAT percentages may exist. The shop may use 19% for Germany for instance.
Wisteria only accepts country codes in the EU plus GB, NO and CH. International sales, i.e. sales outside the EU, has 0% VAT and will use a default VAT assignment. The same holds for ICP sales within the EU.
This restriction is enforced to keep the VAT processing easy and maintainable.

Taxes are used for both the shops and the accounting systems connected via Wisteria. The ledgercodes are only used for the accounting systems connected via Wisteria. Als the taxcode-field in Taxes is only used for the accounting systems. With the taxcodes and ledgercodes it is possible to create financial transactions with the taxcodes and ledgercodes correctly set.

Orders, Invoices and Refunds
In shops there is a huge difference between orders and invoices. An order is the registration of the actual sales, the invoice is the request or proof of the payment. An order can get cancelled which may result in a refund, an invoice cannot be cancelled but can get credited. Before connecting to Wisteria you must decide whether you want to push orders and refunds or you want to push invoices (and credit-invoices). You cannot do both for one merchant since doing both will result in double turnover bookings. For both Orders, Invoices and Refunds Wisteria expects customer data.

Receipts and closures
POSes use receipts and very often receipts do not have customerdata. Also in POSes good dayreports are available. The reason is that a POS uses closures to end a day. This means that there is an option for many invoicesystems (not all) to push a daily booking to the invoicesystem. It is always possible to push individual receipts to invoicesystems.
If preferred it is also possible to add the daily closure to Wisteria. The daily closure will then be pushed to the invoicesystem.