Einleitung
Die Systembeschreibung nach § 131 BAO – E131 richtet sich an Finanzbehörden, Steuerberater und interessierte Gastronomen. Es wird beschrieben, wie das Kassensystem Amadeus II Buchungsdaten speichert und welche Auswertungen den oben genannten Zielgruppen aus diesen Daten zur Verfügung gestellt werden.
Beschreibung des technischen Aufbaus
Das Kassensystem Amadeus II setzt sich aus mehreren Komponenten zusammen. Laut der Einteilung des BMF (Österreich) für Kassensysteme (gemäß Schreiben vom 28.12.2011, BMF, MF-010102/0007-IV/2/2011) ist Amadeus II ein Kassensystem des Typs 3 (Kassensysteme bzw. PC-Kassen). Die Hauptbestandteile sind:
- Apache Tomcat als Anwendungsserver
- MySQL als Datenbankserver
- Einem oder mehreren ACF (Amadeus Communication Framework).
- Optional einem Dienst (SOL-Service)
- Optional einer oder mehrerer Instanzen der Anwendung „ATouch“.
- Optional einem Apache Webserver.
Dabei ist die gesamte Businesslogik in einer Anwendung (Amadeus II Server) implementiert, die über den Tomcat-Server bereitgestellt wird. Über diese Anwendung werden alle Interaktionen mit der Datenbank gesteuert, nur diese Anwendung hat schreibenden Zugriff auf die Datenbank.
Die Kommunikation mit dem Amadeus II Server (Tomcat Anwendung) ist nur über das integrierte Webfrontend zu Konfiguration der Amadeus II möglich, oder über das ACF mittels einer eigens entwickelten Scriptsprache (ASQL, Amadeus Structured Query Language). Alle Treiber für Endgeräte wie Drucker, Orderman Handhelds, Touchkassen oder Hotel-Schnittstellen sind Bestandteil des ACFs.
Alle Anwendungen für Kellner oder Gastronomen wiederum kommunizieren nur über das ACF mit dem Anwendungsserver. Dadurch wird sichergestellt, dass nur über die in ASQL definierten Befehle auf den Anwendungsserver und somit auf die Datenbank zugegriffen werden kann. Ein direktes Bearbeiten der Datenbank ist somit ausgeschlossen.
Der gesamte technische Aufbau der Amadeus II ist in Abbildung 1 dargestellt.
Erzeugen von Datensätzen
Jede Eingabe eines Kellners (Nutzers) an einem Endgerät erzeugt in Amadeus II einen auf den Eingaben basierenden Datensatz. Dabei werden die folgenden Eingaben unterschieden:
Bonieren
Unter dem „Bonieren“ versteht man den Vorgang, mit dem ein Kellner einen in der Kasse angelegten Verkaufsartikel auf einen zuvor geöffneten Tisch boniert. Jeder dieser Vorgänge wird in den Tabellen tabledata und tableheader fortlaufend nummeriert abgelegt. Dabei bekommen sowohl die Kopfdaten des Tisches (Nummer des Tisches, Z-Zähler, Geschäftsdatum, Kellnerzuordnung, …) eine fortlaufende Nummer, als auch jeder Datensatz eines bonierten Artikels eine fortlaufende Nummer. Für jeden Artikel werden alle steuerlich relevanten Daten direkt mit jedem Artikel gespeichert: Artikelnummer, Artikelname, Steuersatz, Originalpreis des Artikels, Verkaufspreis des Artikels, Anzahl der verkauften Artikel, verantwortlicher Kellner, Bondruck. Zusätzlich erhält jede dieser Buchungen eine Signatur, die sicherstellt, dass keine Artikeldaten nachträglich verändert werden können. Alle bonierten Artikel erhalten den Finanzweg 1.
Stornieren und Sofortstornos
Amadeus II unterschiedet zwei Arten von Stornos: Sofortstornos und nachträgliche Stornos. Sofortstornos werden erzeugt, wenn der Kellner einen Boniervorgang durchgeführt hat, die aktuelle Aufrechnung aber noch nicht abgeschlossen hat, also die entsprechenden Bons noch nicht gedruckt wurden. Ein Sofortstorno entspricht also der „Korrektur nach vertippen“. Jeder Sofortstorno wird wie jeder Boniervorgang in der Datenbank mit einer fortlaufenden Nummer versehen und mit allen Daten des Artikels gespeichert (Siehe „Bonieren“), aber mit dem Finanzweg 10 versehen.
Nachträgliche Stornos werden erzeugt, wenn ein Artikel nach dem Absenden der Aufrechnung storniert wird. Dies kann zum Beispiel durch eine Reklamation des Gastes, einer zu spät aufgefallenen Fehlbonierung oder dem Bonieren eines Artikels, der nicht mehr in ausreichender Stückzahl verfügbar ist nötig werden. Nachträgliche Stornos werden ebenfalls in der Datenbank als zusätzlicher Datensatz abgelegt (siehe „Bonieren“), aber mit dem Finanzweg 11.
Rechnungsabschluss
Beim Rechnungsabschluss wird nach Auswählen eines Finanzweges (Bar, Kreditkarte, EC, Gutschein) ebenfalls ein Datensatz mit fortlaufender Nummer in der Datenbank erzeugt. Dieser enthält den Finanzweg, auf den der Tisch abgeschlossen wurde. Beim Rechnungsabschluss wird ebenfalls eine Signatur der Rechnungsdaten erzeugt und in der Datenbank abgelegt, außerdem wird die Signatur auf dem Rechnungsbeleg ausgegeben.
Optional kann eine Signatur über das INSIKA-Verfahren (www.insika.org) erzeugt werden und sowohl auf der Smartcard (TIM) als auch in der Amadeus II Datenbank abgelegt werden. Diese Signierung zielt final auf die Unveränderbarkeit der Daten ab. Eine über das INSIKA-Verfahren signierter Rechnungsdatensatz ist unveränderbar auf der Smartcard und in der Amadeus II Datenbank gespeichert und kann jederzeit über die von INSIKA angebotenen Tools verifiziert werden.
Rabattierung
Rabattierung wird in Amadeus II über sogenannte „interne Rabattartikel“ abgebildet. Wird ein bereits bonierter Artikel rabattiert, so wird ein Rabattartikel erzeugt, der eine Referenz auf den zu rabattierenden Artikel enthält. Der ursprüngliche Artikel bleibt also erhalten. Der Datensatz des Rabattartikels weißt alle Daten des Artikels auf, enthält als „Balance“ aber den Rabattbetrag sowie die Kennzeichnung „Captive_Supply“.
Tagesabschluss
Beim Tagesabschluss, der entweder manuell oder automatisch durchgeführt werden kann, werden alle Daten aus den beiden oben genannten Tabellen in Archivtabellen verschoben und der Z-Zähler um eins erhöht. Das Geschäftsdatum kann, muss aber zwangsläufig geändert werden. Auch das Abschließen aller offenen Tische ist optional. Werden oder sind alle Tische abgeschlossen, so müssen sich alle Soll-Buchungen (Boniert, Storno, Sofortstorno) mit den Haben-Buchungen (Rechnungsabschluss) eines Z-Zählers auf Null auflösen.
Die Unveränderbarkeit der einzelnen Buchungsdaten wir in Echtzeit sichergestellt (jeder Geschäftsvorfall wird direkt in der Datenbank abgelegt) und kann somit unabhängig vom Zeitpunkt des Tagesabschlusses garantiert werden.
Sicherung der Datensätze und Unveränderbarkeit
Amadeus II stellt die Unveränderbarkeit der in der Datenbank abgelegten Datensätze in mehreren Stufen sicher:
Technische Voraussetzungen: Die Zugangsdaten für den eingesetzten MySQL-Server sind nur dem Hersteller bekannt. Diese werden weder an Kassenfachhändler, Techniker noch Endkunden (Gastronomen, Kellner) herausgegeben. Lediglich ein „Nur-Lesender“ Zugriff kann von Finanzbehörden erfragt werden. Der Zugriff auf die Datenbank kann also nur über die oben beschriebene Architektur erfolgen, vom Endgerät über das ACF und den Anwendungsserver. Manipulationsmöglichkeiten sind über diesen Weg nicht gegeben. Amadeus II verfügt nur über die beiden oben beschrieben Tabellen zum Speichern von Umsatzdaten, sind nicht vorhanden. Auch können über diesen Weg keine Daten aus den Tabellen gelöscht werden, Stornos oder Rabatte sind zusätzliche Buchungen und werden nicht durch das Ändern vorhandener Daten abgebildet.
Datenbankintegrität: Die von Amadeus II verwandten Datenbankstrukturen basieren, wie bei jeder relationalen Datenbank, auf internen eindeutigen IDs. Das Verändern einzelner Datensätze würde die Integrität dieser Daten gefährden, wodurch es für eine Person, die im Umfeld von relationalen Datenbanken nicht sehr spezifisches Fachwissen aufweist unmöglich ist, einzelne Datensätze zu manipulieren, ohne die Integrität der Daten zu gefährden. Außerdem würde eine solche Manipulation beim Auswerten der Daten sehr schnell auffallen.
Signaturen und Hashes: Amadeus II bildet für jeden Boniervorgang einen Hashwert und speichert diesen in der Datenbank ab. Ein nachträgliches Ändern einzelner Werte würde beim Überprüfen der Hashwerte sofort auffallen. Beim Ausstellen einer Rechnung wird außerdem eine Signatur erstellt, in der alle relevanten Rechnungsdaten aufgeführt werden. Diese Signatur wird in der Datenbank abgelegt und auf dem Rechnungsbelegt mit ausgegeben. Sowohl über den Rechnungsbeleg als auch über das Überprüfen der Signatur mit den in der Datenbank gespeicherten Werten kann eine nachträgliche Manipulation der Rechnungsdaten ausgeschlossen werden.
INSIKA-Verfahren: Durch Einbinden des INSIKA-Verfahren wie oben beschrieben kann eine weitere Signatur eingeführt werden, die durch das Ablegen auf einem Drittsystem (Smartcard) die Unveränderbarkeit zu 100% sicherstellt.
Durch die oben beschriebenen Sicherungsmaßnahmen wird der manipulative Eingriff in die Journaldaten des Kassensystems Amadeus II so weit erschwert, dass der Nutzen eines solchen Eingriffs in keinem Verhältnis zum Aufwand steht. Durch die unterschiedlichen Signatur- und Hash-Wert-Verfahren ist eine Manipulation der Journaldaten in nahezu allen Fällen nachvollziehbar oder erkennbar.
Datensicherung
Da handelsübliche Festplatten (oder andere Massenspeicher) Defekte aufweisen können, die das Auslesen der Daten unmöglich machen, ist der Anwender der Amadeus II Kassensoftware dazu verpflichtet, regelmäßige Backups der Datenbank durchzuführen. Es wird empfohlen, tägliche Backups der Datenbank durchzuführen und auf ein externes Medium (außerhalb des Kassenservers) zu speichern. Eine Monatssicherung sollte über einen längeren Zeitraum hinweg aufbewahrt werden (z.B.: 4 Jahre, Prüfungszeitraum). Um alle prüfungsrelevanten Daten des Amadeus II Kassensystems zu sichern ist das Sichern der Datenbank ausreichend, da alle anderen Komponenten keine Datenbestände enthalten.
Vorbereitung auf eine Prüfung durch die Finanzbehörden.
Diese Dokumentation dient als Ablaufdokumentation des Kassensystems Amadeus II. Um einen reibungslosen Ablauf einer Betriebsprüfung zu gewährleisten sollten die folgenden Punkte durch den Endkunden beachtet werden.
- Täglicher Ausdruck des Z-Berichtes und Archivierung dieses Ausdrucks.
- Täglicher Ausdruck des Finanzwegeberichtes, der Finanzwegeberichte pro Kellner sowie der Hausparten- oder Feinspartenberichte.
- Tägliches Backup der Datenbank, monatliches Backup der Datenbank aufbewahren.
- Monatlicher GDPdU-Export (Beschreibungsstandard) der Daten aus der Kasse und überprüfen der Vollständigkeit der Daten. Dieser Export sollte in regelmäßigen Abständen auch mit dem Steuerberater besprochen werden, da dieser die Daten auf Vollständigkeit und ordnungsgemäße Formatierung prüfen kann.
Die LINA Softwareentwicklung passt alle Softwarekomponenten ständig den gesetzlichen Vorgaben an. Sollten dennoch besondere Anforderungen während einer Prüfung oder während der Vorbereitung auf eine Prüfung auftreten hilft die Support-Team der LINA Software Entwicklung gerne weiter.