Cloud TSS implementation
Implementation
On this page we have compiled an overview of the implementation of the fiskaly Cloud TSS in five steps.
Here you find the points you need to consider. These make the implementation easier and show possible mistakes that can be easily avoided.
First steps
Go to the fiskaly Dashboard. You can log in to fiskaly with your Google, LinkedIn, Microsoft account as well as your email address. Following registration, you will receive an email to activate your account.
When you log in for the first time, you will be asked to create a (test) organisation. To do this, fill in the name of the organisation (step 1) and the address fields (step 2). In the last step, the address of the organisation is stored by default. For testing purposes, you can also create the organisation without entering the billing address.
Click on 'Create' to finish. Now you can test the fiskaly system for free. The fiskaly Dashboard User Manual can be found at developer.fiskaly.com.
Postman is a popular tool for testing APIs. An intuitive, graphical user interface and little prior programming knowledge are advantages of testing with Postman. In addition, tests that have been carried out are saved and can be repeated.
This gives you the opportunity to test our APIs in detail and gives you a good overview of the interrelationships and processes. Therefore, fiskaly also provides Postman Environment and Postman Collection for testing the fiskaly API. Make sure that you always test with the latest Environment and Collection. This ensures that the latest updates are mapped.
The creation of organisational management in the fiskaly system is an important building block in the integration of the fiskaly Cloud TSS. As a first step, consider how you can best map your organisational structure with us. Note that in this phase you determine the future management effort in business.
Since the organisational and customer structures of our customers are very diverse, we have developed a very flexible and intuitive system that allows you to map a clean separation of customers, locations and hierarchies.
On the fiskademy page Organisations in the fiskaly system we also provide best practice examples.
Further steps
The first priority in implementation is to keep the POS system running! fiskaly provides comprehensive information and resources to help you with implementation. We present the fiskaly online resources in detail on the fiskademy page 'Resources'. Furthermore, it is important to understand that in addition to the technical requirements, the legal framework plays an overriding role.
In the optimal case, our API is implemented in such a way that the smooth operation of the cash register can be guaranteed at all times. In doing so, there are a few things that need to be considered. In general, this depends heavily on the cash register architecture, the frequency of use and the area of application of the cash register. Another point is that a missing signature on the receipt does not mean that the receipt is not compliant (see point 7 AEAO to § 146a). However, the fiskaly API must be implemented in such a way that each transaction requests a signature. We have briefly summarised important information for you in the infobox Tips from practice.
In the fiskaly system, the default setting is test mode and the initial activation of the main organisations into live mode is done manually. To do this, follow the steps in the dashboard or contact sales@fiskaly.com. Sub-organisations can be switched live independently. The resources of the test and live systems are not linked. Changes in the test system are therefore not transferred to the live system and you can continue to use the test system as a sandbox.
You do not have to create any new organisations when switching from V1 to V2. However, you should deactivate the V1 resources in any case to avoid multiple billing. Of course, you can still access the data of the V1 resources. Under this link you will find more information on the changeover to V2.
We have compiled the following practical tips for you:
Set timeouts
These depend heavily on the frequency of the checkout. As a manufacturer, you should decide for yourself which timeout length you consider reasonable. In no case should a request be open so long that the smooth operation of the cash register is endangered.
Please note that in the event that the TSS is unavailable, the checkout process will not be disrupted.
Authorisation
The authorisation is initially carried out via API Key and API Secret. You will receive an "access token" and a "refresh token" which you can use to reauthorise yourself on an ongoing basis. If you run into a "401" response, simply reauthorise yourself via API Key and Secret.
Infobox. Management API
The first priority in implementation is to keep the POS system running! fiskaly provides comprehensive information and resources to help you with an implementation. We present the fiskaly online resources in detail on the fiskademy resources page. Furthermore, it is important to understand that in addition to the technical requirements, the legal framework plays an overriding role.
In the optimal case, our API is implemented in such a way that the smooth operation of the cash register can be guaranteed at all times. There are a few things to consider here. In general, this depends heavily on the cash register architecture, the frequency of use and the area of application of the cash register. Another point is that a missing signature on the receipt does not mean that the receipt is not compliant (see point 7 AEAO to § 146a). However, the fiskaly API must be implemented in such a way that each transaction requests a signature. We have briefly summarised important information for you in the Infobox Tips from Practice.
The fiskaly SIGN DE - API is a RESTful API that implements a cloud-based, virtual TSS (Technical Security System) in terms of the German KassenSichV (Cash Security Ordinance).
7.1 Ausfallzeiten und –grund einer zertifizierten technischen Sicherheitseinrichtung sind zu dokumentieren (vgl. AEAO zu § 146a, Nr. 2.1.6). Diese Dokumentation kann auch automatisiert durch das elektronische Aufzeichnungssystem erfolgen.
7.2 Kann das elektronische Aufzeichnungssystem ohne die funktionsfähige zertifizierte technische Sicherheitseinrichtung weiterbetrieben werden, muss dieser Ausfall auf dem Beleg ersichtlich sein. Dies kann durch die fehlende Transaktionsnummer oder durch eine sonstige eindeutige Kennzeichnung erfolgen.
7.3 Soweit der Ausfall lediglich die zertifizierte technische Sicherheitseinrichtung betrifft, wird es nicht beanstandet, wenn das elektronische Aufzeichnungssystem bis zur Beseitigung des Ausfallgrundes weiterhin genutzt wird. Die grundsätzliche Belegausgabepflicht bleibt von dem Ausfall unberührt, auch wenn nicht alle für den Beleg erforderlichen Werte (vgl. AEAO zu § 146a, Nr. 5.8) durch die zertifizierte technische Sicherheitseinrichtung zur Verfügung gestellt werden. Die Belegangaben zu Datum und Uhrzeit müssen in diesem Fall von dem elektronischen Aufzeichnungssystem bereitgestellt werden.
7.4 Die Belegausgabepflicht nach § 146a Abs. 2 AO entfällt lediglich bei einem vollumfänglichen Ausfall des Aufzeichnungssystems oder bei Ausfall der Druck- oder Übertragungseinheit. Bei Ausfall der Druck- oder Übertragungseinheit für den elektronischen Beleg muss das Aufzeichnungssystem i. S. d. § 146a Abs. 1 Satz 1 AO i.V.m. § 1 Satz 1 KassenSichV weiterhin genutzt werden.
7.5 Der Unternehmer hat unverzüglich die jeweilige Ausfallursache zu beheben, Maßnahmen zu deren Beseitigung zu treffen und dadurch sicherzustellen, dass die Anforderungen des § 146a AO schnellstmöglich wieder eingehalten werden.
* Haftungsausschluss: Die enthaltenen Informationen auf dieser Website dienen allgemeinen Informationszwecken und beziehen sich nicht auf die spezielle Situation einer Einzelperson oder einer juristischen Person. Sie stellen keine rechtliche oder steuerliche Beratung dar. Im konkreten Einzelfall kann der vorliegende Inhalt keine individuelle Beratung durch fachkundige Personen ersetzen.