TRANSACTION
Transaction
Transaction is the main unit in the system and it most often is used to represent a single POS receipt produced after a sale or after a return, etc.
Structure
Transactions in the repository are stored in the form of PosLogv6 format as an XML file. You can see the schema of the transactions in the POSLogV6.0.0.xsd file. To provide the search functionality, the repository use an internal representation of the transactions in form of vital fields of the main transaction record. The important fields that differ from the format are covered in the following sections. To learn more about the Transaction Search, please refer to the Transaction Search part of the documentation.
All the stored transactions can be retrieved as they are processed using webhooks subscribed to the Transaction Event Source.
Sub transactions
The transaction itself holds information about workstation, operator, etc. that were used to produce the transaction. Each transaction may then consist of multiple sub transactions that hold information about what actually happened during the transaction. These are represented in form of following transaction types:
- ControlTransaction
- TenderControlTransaction
- RetailTransaction
- OrderTransaction
- CustomerOrderTransaction
- FoodServiceTransaction
- ForeCourtTransaction
- InventoryControlTransaction
Events
The transaction also holds information about events that happened during the transaction. These are represented in form of free text strings that describe the actions that were taken during the transactions. Events are a more detailed descriptors of the transaction, and the service does not put a hard limit on what is considered to be event, so this allows for a flexibility in the search. Examples of events are:
- sale
- return
- cashdraweropen
- cashdrawerclose
Transaction links
Any of the transactions can be linked to other transactions. The most common example is a sale and a return: return transaction will be linked to the sale transaction, as they are connected. The repository implements the links between the transactions the both ways, and also store all the transaction in the chain , if there are any. When retrieving the transaction, the service returns the transaction itself, and also all the transactions in the chain , that are linked to it.
Retention
Transactions are stored in accordance with the fiscal policies of the countries that they are produced in. The repository will check the provided transaction's country code and stores it accordingly. These are the current retentions specified in the service:
| Country | Retention |
|---|---|
| Denmark | 5 years |
| Germany | 10 years |
| France | 10 years |
| Netherlands | 7 years |
| Norway | 10 years |
| Portugal | 10 years |
| Spain | 4 years |
| Sweden | 10 years |
| United Kingdom | 6 years |
For countries that are not specified, the repository will store the transaction for 5 years.