Wichtige Dokumente:Dokumentation der fiskaltrust.Middleware (Schnittstelle), englisch► fiskaltrust-interface-doc (Version 1.3.20030.26184, 30.01.2020)
Beispiele Geschäftsvorfälle (Sammlung JSON-Aufrufe)► fiskaltrust Business Cases in JSON (English, 02-19-2020)► fiskaltrust Geschäftsvorfälle in JSON (deutsch, 17.03.2020) |
Um sich einführend zu informieren empfehlen wir folgende Quellen:
Auf unserer Web-Site https://fiskaltrust.de/faq/
Interface Doku unter https://github.com/fiskaltrust/interface-doc/releases/tag/v1.3-preview.2/fiskaltrust-interface-doc.pdf
https://github.com/fiskaltrust/interface-doc/releases/tag/v1.3-preview.2
Demos unter https://github.com/fiskaltrust/demo/tree/dev/1.3
Libraries/Binaries sobald released unter https://www.nuget.org/packages?q=fiskaltrust
Step by Step Videos: https://www.youtube.com/channel/UCmMlqO4L3AzkEhh6WYA8BJg
Technischer Überblick: https://github.com/fiskaltrust/interface-doc/blob/item/6456/doc/general/general.md
Handbuch zum Portal: https://github.com/fiskaltrust/portal-manual-doc/tree/master/doc/handbook-general
Nach einer kostenfreien Registrierung in unserem Portal können Sie weitergehende Informationen erhalten:
Erstellen einer fiskaltrust.CashBox für Deutschland https://portal.fiskaltrust.de/KBArticle/Show/KBA-01000
CashBox für REST erweitern https://portal.fiskaltrust.de/KBArticle/Show/KBA-01001
Senden eines einfachen REST Request https://portal.fiskaltrust.de/KBArticle/Show/KBA-01003
Da die technischen Sicherheitseinrichtungen (TSE) voraussichtlich nicht vor 1.1.2020 zu kaufen sein werden, kann die Erweiterung nicht zeitgerecht durchgeführt werden.
AKTUELLE INFORMATION per 5.7.2019
Die bisherige Richtlinie des BSI beinhaltet die Sicherung folgender Vorgangs-Elemente:
Der Begriff des Vorgangs i. S. d. KassenSichV ist nachfolgend als ein zusammengehörender Aufzeichnungsprozess zu verstehen, der bei Nutzung oder Konfiguration eines elektronischen Aufzeichnungssystems eine Protokollierung durch die zertifizierte technische Sicherheitseinrichtung auslösen muss (vgl. § 2 KassenSichV). Ein Vorgang kann einen oder mehrere Geschäftsvorfälle sowie andere Vorgänge umfassen (vgl. AEAO zu § 146a, Nr. 1.7 und Nr. 1.8). Aus Gründen der besseren Lesbarkeit wird der Begriff „Vorgang“ im Folgenden als Oberbegriff für Geschäftsvorfälle und andere abzusichernde Vorgänge genutzt.
Im Rahmen der Protokollierung eines Vorgangs (vgl. AEAO zu § 146a, Nr. 3.3) muss nach § 2 KassenSichV innerhalb der zertifizierten technischen Sicherheitseinrichtung mindestens eine Transaktion erzeugt werden.
Wichtige Zusatzprodukte:
*) Diese Funktionen und Komponenten werden von fiskaltrust dauerhaft kostenfrei zur Verfügung gestellt. (Freemium)
Siehe dazu https://portal.fiskaltrust.de (unter Portal).
Aktuell (Stand 1.3.2020) wird noch immer darüber diskutiert, ob die Richtlinien des BSI eine TSE zulassen deren Komponenten
Relevante Komponenten einer TSE welche vom Hersteller gesondert zertifiziert werden müssen:
CSP (cryptographic service provider):
Der CSP wird voraussichtlich nicht ohne Hardware auskommen. Diese Hardware kann jedoch in Form eines HSM (hardware security module; Kosten voraussichtlich > EUR 20.000) in der sicheren Umgebung eines Rechenzentrums zertifiziert und daher online (in der Cloud) betrieben werden. An den Kriterien der Zertifizierung wird vom BSI aktuell noch etwas geändert, daher wird die Zertifizierung in dieser Variante noch nicht abgeschlossen. (Stand 1.3.2020)
Der CSP könnte demnach
a) in einem Rechenzentrum eines Dienstleisters (fiskaltrust) oder
b) in der Infrastruktur des Unternehmens betrieben werden.
SMA (security module application):
Die SMA (SMEARS) kann voraussichtlich ohne Hardware und ausschließlich als Software betrieben werden. Sie kann jedoch auch als lokale Hardware (z.B. in einem Hardware-Bauteil (Chip-Karte) oder als Software-Komponente) betrieben werden.
Jedoch soll die SMA nach Meinung des BSI bzw. BMF in der lokalen Infrastruktur am Standort des Unternehmens betrieben werden.
Warum? Die Kommunikation zwischen der Kasse und der TSE würde über das Internet laufen und die hierbei verwendete Verschlüsselung ist nach Meinung des BSI nicht ausreichend.
Varianten:
1. Cloud-TSE – Online-CSP+Online-SMAERS:
CSP (cryptographic service provider) und SMAERS (security module application) werden in einem Rechenzentrum eines Dienstleisters betrieben.
Vorteil: Keine Software oder Hardware – daher die perfekte Lösung für
2. Hybrid-TSE – Online-CSP+Lokale-SMAERS:
Dies würde bedeuten, dass die SMAERS am Standort des Unternehmens betrieben werden muss. Hierfür gibt es wiederum die zwei Optionen, dass eine Hardware oder eine Software lokal notwendig ist.
Nachteil ist, dass jedenfalls eine „fremde“ (Software-)Komponente bei der Einrichtung der TSE in der lokalen Infrastruktur installiert werden muss. Diese Installation ist vom jeweiligen Betriebssystem (inkl. Stand der Service-Packs) abhängig und führt in der Praxis dazu, dass es keine Standardisierung gibt und mit sehr hohen Service-Kosten zu rechnen ist.
Fazit:
Liebes BSI und BMF. Bitte treten Sie den sicheren Möglichkeiten der 100%-igen Cloud-TSE näher. Die Sicherheit wird dadurch eher erhöht und nicht gefährdet.
Die Fiskaltrust-Lösung unterstützt mit der einheitlichen Schnittstelle die Gesetzesanforderungen in Frankreich, Österreich und nun auch in Deutschland.
Mit unserer einheitlichen Middleware Lösung unterstützen wir eine Vielzahl von aktuellen TSE-Anbietern, sowohl als Cloud-Lösung als auch bei lokaler Anbindung:
Abhängig von der Marktentwicklung ist es nicht ausgeschlossen, dass wir zukünftig auch weitere Hersteller mit unserer Middleware unterstützen.
Unsere universelle Middleware zur Anbindung einer TSE ist kostenfrei und kann von Kassenherstellern lizenzfrei in beliebig vielen Kassensystemen integriert werden. Auch die mögliche Online-Verwaltung einer Kasse ist und bleibt für Hersteller, Händler und Kassennutzer kostenfrei.
Sollten Sie über unser „Freemium“-Model noch weitere Funktionalitäten wünschen, dann könnten Sie diese optional dazu buchen:
fiskaltrust.Middleware |
inkl. DSFINV-K Export (gesetzlich vorgeschriebenes Format) | EUR 0 |
POS Archiv |
Speicherung der Kassendaten inkl. einer Konformitätserklärung und einer Schnittstelle zur DATEV | EUR 48,00 p.a./Queue |
Kassenanmeldung |
An- und Abmeldung von Kassen (sobald von Finanzverwaltung gefordert) | EUR 20,00 je Meldung |
fiskaltrust.Carefree |
DSFINV-K Export + TAR-File & DSFINV-K Speicher + Audicon Kassenarchiv Online + POS Archiv + Finanzamtmeldungen | EUR 360,00 p.a. |
fiskaltrust.Carefree Hardware TSE |
HardwareTSE + DSFINV-K Export + TAR-File & DSFINV-K Speicher + Audicon Kassenarchiv Online + POS Archiv + Finanzamtmeldungen | EUR 398,00 p.a. |
fiskaltrust.Carefree Online TSE |
Cloud TSE + DSFinV-K Export + TAR-File & DSFinV-K Speicher + Audicon Kassenarchiv Online (AKO) + POS Archiv + Finanzamtmeldungen | EUR 398,00 p.a. |
AKO |
Audicon Kassenarchiv Online (AKO: GoBD-konforme Archivierung Ihrer Kassendaten) | EUR 299,00 p.a. |
Eine Auflistung möglicher TSEs und Services und deren aktuellen Preise finden Sie in unserem Portal https://portal.fiskaltrust.de
Kassenhersteller können im Portal frühzeitig Händler einladen, deren Kunden dann vorgefertigt und vereinfacht Ihre Kasse in Betrieb nehmen können (z.B. Online/Cloud-TSE).
Nach der Registrierung im Portal können Sie sich unter Werkzeuge/Download eine Bescheinigung zur Zusammenarbeit mit fiskaltrust bzgl. des frühzeitigen Einsatzes einer TSE herunterladen.
Hersteller und Händler haben im Portal die Möglichkeit, eigene Produkte für Ihre Kunden anzubieten/bereitzustellen.
Eingeladene Kassenhändler und -betreiber haben frühzeitig Zugriff auf die aktuellen TSE-Angebote.
Nach der Registrierung im Portal https://portal.fiskaltrust.de können Sie sich unter Werkzeuge/Download eine Bescheinigung zur Zusammenarbeit mit Fiskaltrust bzgl. des frühzeitigen Einsatzes einer TSE herunterladen.
Ja, beispielsweise bieten wir mit unserem „Sorglos Paket“ eine einfache Anbindung einer wahlfreien TSE in der Cloud an.
Im Normalbetrieb ist es rechtlich nicht zulässig, eine Kasse mit zwei TSE zu betrieben.
Dies wäre sinnvoll, um die Performance der Fiskalisierung – daher die Anzahl der Vorgänge pro Sekunde – zu erhöhen.
Anmerkung: Für die österreichische Fiskalisierung konnten sowohl mit den lokalen Sicherheitseinrichtungen als auch in unserem Cloud-System – in unseren zwei Rechenzentren – derartige redundante und mit load-balancing ausgestattete Systeme schaffen und die Performance erzielen.
1. Die Kasse erreicht die fiskaltrust.Middleware,
2. die TSE ist jedoch ausgefallen,
– Die Kasse kann im „Ausfallmodus“ weiter betrieben werden.
– Die fiskaltrust.Middleware speichert alle Daten und kann somit alle Funktionen (DSFinV-K-Export, PosArchiv, AKO, usw.) anbieten.
Zu Details siehe Punkt 7 des AEAO zu § 146a: https://www.bundesfinanzministerium.de/Content/DE/FAQ/2020-02-18-steuergerechtigkeit-belegpflicht.html
„7. Ausfall der zertifizierten technischen Sicherheitseinrichtung
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.“
Siehe auch „Orientierungshilfe“ des BMF, Seite 1:
https://fiskaltrust.de/orientierungshilfe
„Thema: Anwendungsbereich und Übergangsvorschrift
Frage: Kann man bei Ausfall oder Nichterreichbarkeit einer TSE (z.B. bei einer Cloud-Lösung oder einer zentralen TSE im eigenen Rechenzentrum) auf eine zweite TSE zugreifen?
Antwort: Nach Nr. 1.3 des AEAO zu § 146a muss ein elektronisches Aufzeichnungssystem oder eine Gruppe elektronischer Aufzeichnungssysteme bei störungsfreier Verwendung genau einer zertifizierten technischen Sicherheitseinrichtung zugeordnet sein. Im Falle einer Störung darf also auf eine zweite TSE zugegriffen werde.„
1. Die Kasse erreicht die fiskaltrust.Middleware nicht,
2. die TSE ist daher ebenso ausgefallen ist.
– Die Kasse kann im „Ausfallmodus“ weiter betrieben werden.
– Die fiskaltrust.Middleware kann durch das Nacherfassungs-Szenario alle Daten alle Daten nacherfassen und somit alle Funktionen (DSFinV-K-Export, PosArchiv, AKO, usw.) anbieten.
Die Behandlung des Ausfalls wird in unserer Interface-Dokumentation in www.github.com/fiskaltrust beschrieben.
Ja, fiskaltrust bietet unter https://Portal-Sandbox.fiskaltrust.de (Portal-Button) eine vollständige „Sandbox“ Umgebung an, in der Sie ohne Auswirkung den vollständigen Funktionsumfang einschließlich einer eigenen Kassenkonfiguration erstellen und testen können.
Wir exportieren das DSFinV-K im CSV Format und „RAW“ in einem TAR-File.
Beide Exporte können sowohl im Portal als auch über unsere Middleware-API bezogen werden.
Für Kunden aus Frankreich und Österreich sind die Daten in den Niederlanden gespeichert, für deutsche Kunden in Deutschland.
In unserem Portal https://portal.fiskaltrust.de kann eine Signatureinheit/TSE erstellt und direkt genutzt werden.
Die API für Kassenhersteller ist immer gleich (mit REST/SOAP), die Eigenschaft für den online/offline Betrieb wird lediglich konfiguriert.
Ist die Kasse fiskaltrust-tauglich, können beliebige TSEs direkt (auch offline) angeschlossen werden.
fiskaltrust stellt mit den Demo-Tagen am 05. und 06. Februar einen Fiskaly-TSE online Zugang bereit, um sie mit der fiskaltrust Middleware testen zu können.
Die Zugangsdaten sind bei unserem Support unter info@fiskaltrust.de zu erhalten.
Es gibt einen Launcher der auf Linux funktioniert. Dieser wird ab Mai auch für den deutschen Markt verfügbar sein.
Die Usabiltiy des Portals ist absolut verbesserungswürdig. Konfiguration einer CashBox wird in Zukunft über einen Produktionsprozess abgewickelt wodurch die gezeigten Schritte automatisiert durchgeführt werden.
Nein. Wir sind ein reiner Middleware Anbieter, dadurch dass wir alle gängigen TSEs implementiert haben liegt die Entscheidung beim Kunden ob die TSE implementiert wird oder unser POSInterface. Grundsätzlich bringt die Middleware außerdem den Vorteil, eine gewisse technische und architektonische Unabhängigkeit von der TSE zu haben, da es über den Konfigurationsprozess einfach möglich ist eine andere TSE zu verwenden (unter Beachtung der rechtlichen Anforderungen)
Die Komponenten der Middleware sind grundsätzlich lauffähig auf Linux. Insofern auch eine Linxu Implementierung der SMA vom Hersteller der TSE angeboten wird kann die Middleware auf allen gängein Betriebssystemen eingsetzt werden.
SignaturCloud wird in Deutschland auf Grund der gesetzlichen Lage nicht so möglich sein wie in Österreich. Auf Grund der Anforderungen an den sicheren Kommunikationskanal muss es Kassenseitig ein SMA geben. Wir arbeiten gerade an einer Lösung dafür wie wir die Integrierung einer SaaS Cashbox implementieren können. Für Web-Kassen gibt es außerdem die Möglichket der direkten Integration in die Webapplikation. Es gibt dafür einen Prototypen und hier wäre es super wenn wir uns dazu noch mit dem Kunden abstimmen können und evtl. ein extra Meeting ansetzen um mögliche Szenarien zu besprechen.
Konfiguration kann durch Produktionsprozess ersetzt werden. Aktuell ist in der Sandbox ausschließlich die manuelle Konfiguration möglich.
Stornieren nach Belegausgabe geht aufgrund manipulationsgeschützter Speicherung nur durch (negative) Gegenbelege (auch teilweise für einzelne Positionen des Ursprungsbelegs); cbPreviousReceiptReference dient dabei dem Verweis auf den Ursprungsbeleg. Für Gutscheine gibt es entsprechende ftChargeItemCase Variablen (z.B. Mehrzweckgutschein nicht steuerbar oder Gutschein je nach USt-Steuertarif)
Man kann jede Bestellung mit eigener Referenz versehen (und einen Vorgang dann über cbPreviousReceiptReference -> z.B. als Zeiger auf die erste Bestellung, d.h. deren cbReceiptReference, als Vorgangsbeginn richten)
Wenn das Abrechnungssystem/Kassensystem über die Möglichkeit der Barzahlung verfügt, dann sind diese Bestellungen ebenfalls über die TSE abzuschließen. Unsere Schnittstelle bietet hierfür
geeignete cbReceiptCase Definitionen (Beleg, Rechnung) und entsprechende cbPayItemCases (Bar, EC-Karte, usw.) .
Als ChargeItem wird ein Pseudo-Umsatz gebucht, den wir als Anzahlungseinstellung/Forderung je nach Steuer mit 0x4445000000000081 bzw. 82 oder 85 senden.
Es muss keine Rechnung erstellt werden sondern ein Beleg; B2C/B2B Invoice wenn der Kunde nicht zugegen ist.
Für Anzahlungen gibt es das ChargeItem „down payment“ in Varianten je nach Steuersatz.
Fiskaltrust bietet in seiner Middleware eine Vereinfachung, den sogenannten „impliziten Workflow“ an.
Hier stellen Sie einen Beleg zusammen (z.B. normalen Kassenbeleg mit ChargeItems und PayItem) und setzen beim ftReceiptCase ein Flag (z.B. durch Hinzudaddieren):
Aus POS Receipt (0x4445000000000001), für den im expliziten Flow zunächst ein Vorgang eröffnet werden müsste, wird:
frReceiptCase 0x4445000000000001 + implizit Flag 0x100000000 = 0x4445000100000001 => POS Receipt implicit work flow (EIN Aufruf, „hit and run“)
Vorherige Bestellungen können Sie ebenso per implizitem Workflow aufrufen, wenn Sie cbReceiptReference als gemeinsame Referenz (alle Aufrufe zugehörig zu einem Vorgang) verwenden [Lars Mach]
cbCustomer ist optional; wenn dort Name und Daten des Leistungsempfängers gespeichert werden, ist ein untergeordnetes JSON Script empfohlen, um Variablen zu definieren („Name“, „Firma“, „Anschrift“, „USt“ usw.).
Wenn der Beleg als Rechnung definiert wird, dann muss der Leistungsempfänger hier abgespeichert werden – diese Forderung besteht gesetzlich; nicht durch die Schnittstelle.
QR Code ist optional, die lt. DSFin-VK definierten SignaturItems MÜSSEN auf den Beleg gedruckt werden. Es gibt einen neuen SingaturType der im Textformat zurückgegeben wird. Alle diese Signaturen müssen auf den Beleg. Zusätzlich empfehlen wir alle im ReceiptResponse enthaltenen Signaturen auf den Belege zu drücken.
Wegen des Prinzips der „manipulationsgeschützten Speicherung“ im Rahmen der Fiskalisierung per TSE können Daten (Aufrufe) nur in chronologisch richtiger Reihenfolge geschehen; je nach vorliegendem Fall ließen sich jedoch separate Bestellungen über cbPreviousReceiptReference verknüpfen, außerdem gibt es Datenfehler für branchenrelevante Daten des Kunden (z.B. durch untergeordnete eigene JSON Scripts). Sollen Bestellungen NACHTRÄGLICH ein einen Vorgang neu eingetragen werden, so wäre an eine Gegenbuchung und die Übertragung von Buchungen in einen neu zu öffnenden Vorgang zu denken.
Tatsächlich liefern durch das BSI zu zertifizierende TSE Prüfsummen, welche die manipulationssichere Speicherung von Belegen erlaubt. Ohne TSE kann in regulärem (nicht TEST-)Betrieb keine Fiskalisierung erfolgen.
Unsere Middleware läuft als Dienst auf allen Windows Plattformen ab einschließlich Windows 7 bis zum aktuellen Windows 10 und dies in beiden Varianten 32 + 64 Bit.
Darüber hinaus auf verschiedenen Linux-Varianten als Deamon.
Besondere Mindestanforderungen für die Kassen gibt es nicht, sofern das jeweilige Betriebsystem darauf läuft und eine Verbindung zu einer TSE hergestellt werden kann z.B. per USB, microSD, SD, LAN, RS232, WLAN, Cloud.
Windows XP wird von unserer Middleware nicht mehr unterstützt.
Stand Februar 2020. Alle Informationen und Preise vorbehaltlich Irrtum und Änderungen.