The "fiscal4brand" service acts as an intermediary between the cash register system and the financial administration. The service processes the data from the POS system and ensures that it is formatted according to the requirements of the financial administration.
In addition, the "fiscal4brand" service offers additional functions such as storing data, creating reports and managing certificates.
Below you'll find schematics in how the clients works via middleware and a signature unit. There are three examples shown here. First the initialization of the API and the fiscal service. Next ist the creation and processing of a fiscal transaction und last but not least, the execution of an exported function is shown.
Country | Fiscal device type |
Fiscal data transmission |
Bulgaria | Fiscal printer |
Online |
Germany | Signature unit |
Offline |
Austria | Signature unit | Online |
France | - | Offline |
Greece | Fiscal printer | Online |
Italy | Fiscal printer | Online |
Poland | Fiscal printer | Online |
Romania | Fiscal printer | Online |
Serbia | Signature unit | Online |
Slovakia | Fiscal printer | Online |
Croatia | Local service |
Online |
Slovenia | Local service |
Online |
StartTransaction
The german fiscal laws require to mark the starting point of a sale transaction. With retail stores this is done, when a new shopping cart is created by the client, as well as when the first PLU item is scanned by the cashier. In our solution this has to be called explicit by the client. The result of calling this function, will result in a transaction ID which is to be used by the client. Date and time of this execution is the used in the fiscal unit mit mark the start of a sale.
For further information, please check out our development guide here:
EndTransaction
When the cashier finishes a sales transaction, let's say by receiving the payment from the customer, the transaction is sent to the fiscal service. Our service then verifies the contents of the transaction, processes it and the relevant fiscal data is sent to the fiscal unit. With a successful processing within the fiscal unit, the transaction is finished and there is no need to call EndTransaction explicitly.
Available exported functions
In the german fiscal solution, there are several exported functions available, which can be called remotely by the client application. We differentiate between country and device specific functions. These are the available functions for germany:
For further information, please check out our development guide here:
Delimitation
UpdateTransaction
Our fiscal service solution is mainly written for retail purposes like selling goods in a store (like fashion retail). If you want to use this solution in gastronomy or hotel industry, additional changes are needed.
In Germany it is mandatory to call StartTransaction on the fiscal device, when you create a new transaction in the cash register software. When you finish the sale of goods, the transaction is sent to the fiscal device (TSE), which automatically finishes the transaction.
In gastronomy or the hotel industry, the transaction is finished when the customer has payed for the service and leaves the location. So it is necessary to update the transaction with the command UpdateTransaction, whenever new services are requested by the customer. This is needed when, for example new food or drinks are ordered. This feature is not yet available in the fiscal service and will be added later.
Transaction splitting
Transaction splitting is regularily used in the gastronomy sector, therefor it is necessary for a fiscal solution to provide transaction splitting, when multiple customers want to pay for a transaction separately. This feature ist not yet available in the fiscal service and will be added later.
Location Group
The location group feature for fiscalization is used in gastronomy, when several restaurant tables are grouped together. This enables transactions to be assigned to a certain location group. This feature ist not yet available in the fiscal service and will be added later.
You can find a detailed developemnt documentation of our fiscal API under the following link. Please note, that the documentation ist still preliminary and is subject zu changes.
There are several requirements for our fiscal service, that should be considered. While the SDK NuGet package works in every Visual Studio 2017 (and higher), the fiscal service itself has some requirements for hard- and software.
Hardware
Minimum |
Recommended |
|
CPU | Dual Core @ 2,0 Ghz AMD Athlon / Intel Celeron |
Quad Core @ 2,0 Ghz AMD Ryzen / Intel Core |
Architecture | 64-Bit (x64) | 64-Bit (x64) |
Memory | 2 GByte | 8 GByte |
Storage * |
HDD | SSD |
* the required storage depends on the used fiscal solution and the amount of transactions generated by the client application.
Software
Microsoft Windows 10 (or higher) with installed Microsoft .NET 6 Hosting Bundle
Debian Linux support is given but needs to be officially approved by acto-soft
Fiscal API | This is the API interface for the Fiscal Service by acto-soft. |
Exported Function | This is a function provided by the fiscal service, which can be run remotely by the client application. |
Text Index | This represends a number which will be converted to a specified text template. This is used acto-soft internally with it's cash register application. |
OID | The short form of "Object ID". This is used in our fiscal database and it is basically a GUID. |
Reaction Advice | Depending on the outcome of a transaction processing, the fiscal service tells the client what to do next. The Reaction advice cout be OK (all fine), Warning (The client should show the error message to the user), Rollback (The last transaction should be undone), RollbackClose (The last transaction should be undone and the client needs to shut down) |
Print Data | On some cases, the fiscal service provides the printed receipt in text form. |
Symbology | This term is unsed in regards to barcode printing. The symbology represents a type of barcode, like QR-Codes. |