APRO Systembeschreibung (Verfahrensdokumentation)

Zielgruppe: Finanzbehörden, Steuerberater, Prüfer und technisch Interessierte
Typische Nutzung: Nachweis der ordnungsgemäßen Aufzeichnung bei Betriebs-/Kassenprüfung
Gilt für: APRO Kassensystem ab Version 10.x (PC-Kassensystem auf Basis einer SQL-Datenbank)
Hersteller: APRO Kassensysteme GmbH

Zweck

Dieses Dokument richtet sich an Finanzbehörden, Steuerberater und Interessierte. Es beschreibt die in der Kassensoftware umgesetzten Maßnahmen zur Sicherstellung der gesetzlichen und steuerrechtlichen Anforderungen an eine korrekte und ordnungsgemäße Aufzeichnung und Verarbeitung von Kassentransaktionsdaten. Es dient als Verfahrensdokumentation im Sinne der GoBD bzw. der landesspezifischen Vorgaben.

Präambel

Das Bundesministerium für Finanzen in Deutschland (BMF) spezifiziert in den GoBD, der KassenSichV (inkl. TSE) und durch den §146 AO (inkl. DSFinV-K) die Anforderungen an Kassensysteme am umfassendsten.

Diese Vorgaben, als auch die gesetzlichen und steuerrechtlichen Vorgaben für Kassensysteme in Österreich, der Schweiz und in Italien, wurden im APRO Kassensystem nach bestem Wissen und Gewissen umgesetzt. Aktualisierungen in diesen Spezifikationen werden im Zuge der laufenden Weiterentwicklung des Kassensystems umgesetzt.

Unabhängig davon, in welchem Land (mit welchem Fiskalsystem) das Kassensystem eingesetzt wird, laufen die internen technischen Prozesse im Kassensystem immer gleich ab. Die folgenden Informationen beschreiben diese kassensysteminternen technischen Prozesse. Weiters werden nachfolgend länderspezifische Erfordernisse behandelt.

Datenstruktur Kassentransaktion / Kassengeschäftsfall

Die einzelnen Aktivitäten im Kassensystem (Bonieren, Abrechnen …) werden als Transaktionen abgebildet und in der Datenbank in den Tabellen Transaktion, Geschaeftsfall, GeschaeftsfallArtikel, BonierterArtikel und GeschaeftsfallZahlung gespeichert.

In der Tabelle Transaktion gibt es die Spalte Nummer und in der Tabelle BonierterArtikel die Spalte Finanzindex. Die Werte für diese Spalten werden jeweils beim Schreiben in die Tabelle von der Datenbank als fortlaufende Nummer vergeben und gespeichert.

Jede Tabelle hat eine Spalte Id bzw. Guid, die einen Datensatz in der Tabelle eindeutig identifiziert. Diese Id- bzw. Guid-Spalte einer Tabelle wird als Primärschlüssel bezeichnet. Über sogenannte Fremdschlüssel stehen diese Tabellen zueinander in Beziehung. Der Fremdschlüssel ist jener Spaltenwert, der in einer anderen Tabelle der Primärschlüssel ist (beispielsweise die TransaktionId in der Tabelle Geschaeftsfall).

Die einzelnen Datensätze sind also über ihre Fremdschlüsselwerte logisch miteinander verknüpft. Bereits beim Schreiben der Daten in die Datenbank wird dadurch sichergestellt, dass die Daten vollständig sind. Ein Geschäftsfall kann beispielsweise ohne Transaktion nicht gespeichert werden.

Einmal in der Datenbank gespeichert, können die Daten durch diese logische Verknüpfung nicht beliebig gelöscht werden. Das Löschen eines Geschaeftsfall-Datensatzes ist nicht möglich, weil dessen Primärschlüsselwert in der Tabelle GeschaeftsfallArtikel als Fremdschlüssel verwendet wird. In der Datenbank werden dadurch die Datenkonsistenz und Datenintegrität gewährleistet.

Nach der Fertigstellung einer Kassentransaktion / eines Kassengeschäftsfalls wird auf die Datensätze ausschließlich lesend zugegriffen.

Kassenfunktionen im Detail

Bonierung

Vom Bediener wird ein Tisch ausgewählt und Verkaufsartikel, die zuvor im Kassensystem angelegt und konfiguriert wurden, werden in der Bestellung (Bonierung) erfasst. Mit einem Klick auf „OK" werden die bonierten Artikel als Kassentransaktion / Kassengeschäftsfall in der Datenbank der Zeitfolge nach geordnet, vollständig, richtig und zeitgerecht gespeichert.

Es wird je ein Datensatz in den Tabellen Transaktion und Geschaeftsfall erstellt und für jeden Artikel ein Datensatz in den Tabellen GeschaeftsfallArtikel und BonierterArtikel. In der Tabelle BonierterArtikel bekommt jeder Datensatz eine fortlaufende Nummer (Finanzindex). Zusätzlich zur Referenz auf den Verkaufsartikel werden alle steuerlich relevanten Daten eines bonierten Artikels (Artikelnummer, ArtikelName, OriginalPreis, Sparte, MwSt …) in der Tabelle BonierterArtikel redundant gespeichert. Auch Informationen zum Tisch und Bediener werden redundant gespeichert.

In der Tabelle Geschaeftsfall wird für jede Bonierung in der Spalte Belegnr eine fortlaufende Nummer gespeichert, die mit dem Tagesabschluss wieder bei 1 beginnt. Die Spalte ZahlungsmittelgruppeId bleibt leer. In der Tabelle Transaktion wird für die TransaktionsTypId der Wert 1 (Bonieren) gespeichert. Die bonierten Artikel sind als offene Artikel nun am Tisch für die Weiterverarbeitung verfügbar.

Abrechnung

Vom Bediener wird die Funktion „Abrechnen" aktiviert und ein abzurechnender offener Vorgang (z. B. Tisch) ausgewählt. Offene Artikel werden für die Abrechnung erfasst und es werden ein oder mehrere Zahlungsmittel (Bar, Kreditkarte, Gutschein …) ausgewählt. Mit einem Klick auf „OK" werden die Artikel und Zahlungsmittel als Kassentransaktion / Kassengeschäftsfall in der Datenbank gespeichert.

Die ursprüngliche(n) Bonierung(en) wird/werden nicht verändert. Für jede Abrechnung wird in der Tabelle Geschaeftsfall eine fortlaufende Rechnungsnummer gespeichert und als Wert für die ZahlungsmittelgruppeId wird aufgrund des gewählten Zahlungsmittels der Wert 1 (Umsatzwirksam) gespeichert. In der Tabelle Transaktion wird für die TransaktionsTypId der Wert 3 (Abrechnen) gespeichert. Wichtig ist die VorgaengerId in der Tabelle GeschaeftsfallArtikel: Die Artikeldatensätze werden beginnend mit der Bonierung in dieser Tabelle bei jeder Verarbeitung miteinander verkettet.

Rabattierung

Werden bei der Abrechnung Rabatte gewährt, bleiben die ursprünglichen Artikeldaten erhalten. Der gewährte Rabatt wird als %-Satz (Rabattfaktor) in der Tabelle GeschaeftsfallArtikel gespeichert. Sämtliche Rabatte des Geschäftsfalls werden summiert in der Tabelle Geschaeftsfall in der Spalte RabattBetrag gespeichert und sind in der Spalte Betrag bereits abgezogen.

Werden direkt bei der Bonierung Rabatte gewährt, wird der gewährte Rabatt-%-Satz in den Tabellen BonierterArtikel und GeschaeftsfallArtikel jeweils in der Spalte Rabattfaktor gespeichert und für die Weiterverarbeitung herangezogen. Beispiel: 5 % Rabatt ⇒ Rabattfaktor 0,95.

Trinkgeld

Wird bei der Abrechnung ein Trinkgeld erfasst, wird dieses in der Tabelle Geschaeftsfall in der Spalte TipBetrag gespeichert und ist im Geschäftsfallbetrag (Spalte Betrag) bereits enthalten.

Verschiebung

Offene Artikel auf einem Tisch können auf einen anderen Tisch übertragen (verschoben) werden. Wie bei der Abrechnung beschrieben, wird dabei die ursprüngliche Bonierung nicht verändert. Es wird je ein neuer Datensatz in den Tabellen Transaktion und Geschaeftsfall erzeugt und für jeden Artikel ein Datensatz in der Tabelle GeschaeftsfallArtikel. Diese werden über die VorgaengerId verkettet. In der Tabelle Transaktion wird für die TransaktionsTypId der Wert 2 (Verschiebung) gespeichert; in der Tabelle Geschaeftsfall bleibt die Spalte ZahlungsmittelGruppeId leer.

Nicht umsatzwirksame Abrechnung

Artikel, die im Kassensystem durch Bonierung erfasst wurden, können aus diesem nicht mehr entfernt werden. Neben der „normalen" umsatzrelevanten Abrechnung können Artikel „nicht umsatzwirksam" auf Werbung, Eigenverbrauch, Schwund, Kaputt … abgerechnet werden.

Vom Bediener wird die Funktion „Storno / Werbung" aktiviert, die Artikel und das entsprechende Zahlungsmittel werden ausgewählt und mit Klick auf „OK" als Kassentransaktion / Kassengeschäftsfall gespeichert. Auch für nicht umsatzwirksame Abrechnungen wird die fortlaufende Rechnungsnummer in der Tabelle Geschaeftsfall gespeichert. In der Tabelle Transaktion wird für die TransaktionsTypId der Wert 24 (Abrechnen HSK) gespeichert und in der Tabelle Geschaeftsfall für die ZahlungsmittelgruppeId aufgrund des gewählten Zahlungsmittels der Wert 2 (nicht Umsatzwirksam).

Storno

Sollen Artikel ohne weitere buchhalterische Relevanz „ausgebucht" werden, steht dem Bediener die Abrechnung auf das Zahlungsmittel Storno zur Verfügung. Auch in diesem Fall wird eine entsprechende Kassentransaktion in der Datenbank gespeichert, die fortlaufende Rechnungsnummer wird vergeben und die Artikel werden mit ihren Vorgängern verkettet. TransaktionsTypId 4 (Stornieren), ZahlungsmittelGruppeId 4 (Storno).

Transfer

Artikel, die in einem externen System (Hotel, WaWi …) weiterverarbeitet werden, können auf entsprechende Zahlungsmittel abgerechnet werden. In Abstimmung mit dem Betreiber bzw. dessen steuerlicher Vertretung wird das Zahlungsmittel als umsatzwirksam bzw. nicht umsatzwirksam eingestuft.

• Umsatzwirksam: TransaktionsTypId 3 (Abrechnen), ZahlungsmittelGruppeId 8 (Transfer Umsatzwirksam).
• Nicht umsatzwirksam: TransaktionsTypId 3 (Abrechnen), ZahlungsmittelgruppeId 3 (Transfer nicht Umsatzwirksam).

In der Tabelle Geschaeftsfall wird in der Spalte BelegNr eine fortlaufende Transfer-Belegnummer gespeichert.

Lieferschein

Offene Artikel, die der Kunde/Gast erst zu einem späteren Zeitpunkt fakturiert bekommen möchte (Monatssammelrechnung, Rechnung an die Firma …), werden als Lieferschein abgerechnet. In der Tabelle Geschaeftsfall wird in der Spalte BelegNr die fortlaufende Lieferscheinnummer gespeichert. TransaktionsTypId 3 (Abrechnen), ZahlungsmittelgruppeId 5 (Lieferschein). Unmittelbar nach der Abrechnung ist der Lieferschein zur Weiterverarbeitung im Fakturamodul verfügbar.

Ausgangsrechnung

Im Fakturamodul werden offene Lieferscheine in Ausgangsrechnungen überführt — einzeln, als Sammelrechnung oder auf mehrere Rechnungen aufgeteilt. Es wird ein neuer Kassengeschäftsfall erzeugt und in der Datenbank gespeichert; die Artikel werden auf ihren Vorgänger (LieferscheinGeschaeftsfallArtikel) verkettet. In der Tabelle Geschaeftsfall wird eine fortlaufende Ausgangsrechnungsnummer gespeichert. TransaktionsTypId 14 (ARAusstellen), ZahlungsmittelgruppeId 6 (Ausgangsrechnung).

Ausgangsrechnung Zahlung

Die Bezahlung einer Ausgangsrechnung wird im Normalfall per Überweisung getätigt und in der Buchhaltung ausgeziffert. Diese Auszifferung kann auch im Kassensystem vorgenommen werden. Dabei wird für eine Ausgangsrechnung ein weiterer Kassengeschäftsfall erzeugt, der über die VorgaengerId mit dem Geschäftsfall der Ausgangsrechnung verkettet ist. TransaktionsTypId 25 (Abrechnen AR), ZahlungsmittelGruppeId 7 (Konto).

Nachdruck

Soll ein Geschäftsfall nochmalig ausgedruckt werden, wird auch diese Aktion als eigener Geschäftsfall gespeichert. Die originalen Geschäftsfalldaten werden dupliziert und als neue Kassentransaktion gespeichert. TransaktionsTypId 21 (AbrechnenNachdruck). Der neue Geschäftsfall wird mit dem originalen über die VorgaengerId verknüpft. Am Ausdruck wird die Tatsache des Nachdruckes kenntlich gemacht.

Rückabwicklung

Das Kassensystem bietet keine Möglichkeit, Geschäftsfälle nachträglich zu bearbeiten. Um Korrekturen zu erreichen, müssen Kompensationsgeschäftsfälle erstellt werden:

• Falscher Tisch boniert ⇒ Artikel auf den richtigen Tisch verschieben.
• Falsch verschoben ⇒ erneute Verschiebung auf den richtigen Tisch.
• Zu viele/falsche Artikel boniert ⇒ stornieren oder auf ein nicht umsatzwirksames Zahlungsmittel abrechnen.
• Abrechnung Bar erfasst, Gast zahlt doch mit Karte + Trinkgeld ⇒ originalen Geschäftsfall „zurückholen" und neu abrechnen.

Die Rückholung wird als neuer Geschäftsfall erfasst und über die Spalte VorgaengerId mit dem originalen Geschäftsfall verkettet. Für den Rückholungsgeschäftsfall werden die originalen Daten dupliziert, die Zahlenwerte (Betrag, TipBetrag, RabattBetrag, GeschaeftsfallZahlung.Betrag, GeschaeftsfallArtikel.Preis) werden mit -1 multipliziert und gespeichert. TransaktionsTypId 5 (RechnungZurückholen). Nach der Rückholung sind die Artikel wieder offen am Tisch.

Tagesabschluss

Ein Tagesabschluss kann automatisiert oder manuell erzeugt werden. Über einen Parameter kann gesteuert werden, ob ein Tagesabschluss erstellt werden kann, wenn es noch offene Artikel gibt. Es wird ein Datensatz in die Tabelle Transaktion mit TransaktionsTypId 16 (Tagesabschluss) gespeichert. In der Tabelle Tagesabschluss (über die TransaktionId mit Transaktion verknüpft) werden die Detaildaten gespeichert: eine fortlaufende Tagesabschlussnummer und der abgedeckte Transaktionsnummernbereich (Bsp. 1–10, 11–50, 51–300 …). Sind beim Abschluss noch offene Artikel vorhanden (sofern erlaubt), werden diese in TagesabschlussOffeneArtikel gesichert.

Auf Basis des Tagesabschlussdatensatzes wird ein Bericht aufgerufen, der ein PDF erzeugt, das am Datensatz gespeichert wird (optional auch automatisiert ausgedruckt). Das PDF enthält mindestens:

• Firmenname und -anschrift
• Erstellungsdatum
• Bediener
• Transaktionsnummer
• erste und letzte Buchung des Tagesabschlusses
• Steuerbelastung und Nettoumsätze
• Finanzwege
• Offene Buchungen
• Rechnungsänderungen

Auswertung, Kassabuch und Kassasturz

Berichte

Das Modul Berichte ermöglicht die Auswertung der gespeicherten Kassengeschäftsfälle. Zur Datenübertragung in die Buchhaltung stehen Spartenbericht, Artikelbericht und Zahlartenbericht zur Verfügung; alternativ kann auch der Tagesabschluss verwendet werden. Es wird empfohlen, die jeweilige Buchungsgrundlage (Berichte bzw. Tagesabschluss) auszudrucken und in der Buchhaltung abzulegen.

Virtueller Tag

Umsätze nach Mitternacht sollen in Berichten und Buchhaltung oft noch dem Vortag zugerechnet werden. Dafür kann ein Zeitpunkt für einen „virtuellen Tageswechsel" definiert werden. In den Tabellen Transaktion und Geschaeftsfall wird der VirtuellerTag zusätzlich zum tatsächlichen Buchdatum gespeichert und kann für die zeitliche Filterung in Reports verwendet werden.

Kassabuch

Optional kann das Kassabuchmodul aktiviert werden. Dann werden sämtliche Geschäftsfälle mit BAR-Zahlung zusätzlich als Kassen-(Kassabuch-)Transaktion erfasst und auf „Bargeldorte" gebucht. Zusätzliche Bargeldverschiebungen (Wechselgeld, Abschöpfung …) werden jeweils als eigene Kassentransaktion gespeichert und sind über Berichte bzw. die Journalfunktion jederzeit nachvollziehbar.

Kassasturzfähigkeit

Bei aktiviertem Kassabuchmodul kann für jeden Bargeldort jederzeit der aktuelle Barbestand abgefragt werden. Ohne aktiviertes Kassabuch ist extern ein Kassabuch zu führen. Am Tagesabschluss (Abschnitt Finanzwege) werden die laufenden Umsätze seit dem letzten Tagesabschluss je Bezahlart dargestellt. Unter Berücksichtigung externer Kassabuchaufzeichnungen kann somit mit dem Tagesabschluss jederzeit ein Kassasturz gemacht werden.

Datensicherheit und Datenintegrität

Datensicherheit

Schutz der Daten vor Verlust, unberechtigtem Zugriff und Manipulation. Die generierten Daten werden in einer SQL-Server-Datenbank gespeichert. Die Zugangsdaten zum SQL-Server und zur Datenbank sind dem Benutzer unbekannt, wodurch die Daten vor direktem Zugriff geschützt sind. Regelmäßige (empfohlen: tägliche) Backups auf ein externes Medium oder in die Cloud stellen sicher, dass bei Hardwaredefekten Datenverluste weitestgehend vermieden werden. Da sämtliche gesetzlich und steuerrechtlich relevanten Daten in der Datenbank liegen, kann die zusätzliche Sicherung von Kassensystemkomponenten entfallen. In den Benutzeroberflächen ist ein Berechtigungssystem umgesetzt, das je Bediener steuert, welche Aktivitäten ausgeführt werden dürfen.

Datenintegrität

Schutz der Daten vor nachträglichen Änderungen ohne entsprechende Kennzeichnung bzw. Protokollierung. Kassengeschäftsfälle werden vom System erfasst und in der Datenbank festgeschrieben; Weiterverarbeitungen verändern diese nicht, sondern erfassen zusätzliche, zum Vorgänger verkettete Geschäftsfälle.

Stammdatenänderungen werden in den Kassenbewegungsdaten sichtbar: Mit jeder Bonierung werden viele Stammdatenwerte (Artikel, Sparte, Tisch, Kellner …) denormalisiert in den Bewegungsdaten gespeichert, sodass Stammdatenänderungen seit der Erstprogrammierung nachvollziehbar sind. Zusätzlich wurde für diverse Stammdaten (Betrieb, Artikel, Tisch, Sparte, Zahlungsmittel …) ein Änderungsverlauf umgesetzt.

Datenzugriff und Datenbereitstellung

Der unmittelbare lesende Zugriff auf Kassensystemdaten ist über die Berichte möglich. Für viele Reports gibt es neben PDF/Ausdruck zusätzlich den CSV-Export. Zur Weitergabe an Dritte gibt es viele Schnittstellen, die — wie die Reports — ausschließlich lesend auf die Kassentransaktionen zugreifen. Datenexporte an externe Systeme werden als eigene Transaktion (TransaktionsTypId 26) erfasst und in der Tabelle Export protokolliert.

Datenzugriff Außenprüfung

Ein Export der Kassensystemdaten an sachverständige Dritte zum Zweck der Außenprüfung kann jederzeit erstellt werden. Dieser Finanzexport besteht aus 5 CSV-Dateien (Transaktion, Geschaeftsfall, GeschaeftsfallArtikel, GeschaeftsfallZahlungen und Bonierjournal), die mit den im Datenmodell beschriebenen Tabellen gleichzusetzen sind. Die Feldbeschreibungen finden sich am Ende dieses Dokuments.

Verfahrensdokumentation

Als Verfahrensdokumentation dient die Online-Hilfe sowie dieses Dokument. Die Online-Hilfe ist unter apro.at/hilfe aufrufbar und öffentlich zugänglich.

Fiskalisierung

Für die Erfüllung länderspezifischer rechtlicher Erfordernisse hinsichtlich der Absicherung von Kassengeschäftsfällen (Fiskalisierung) arbeitet APRO mit der Fa. fiskaltrust zusammen und nutzt die fiskaltrust.Middleware. Die Kassengeschäftsfälle werden unmittelbar nach der Erfassung gespeichert, noch vor dem Ausdruck von Belegen an die fiskaltrust.Middleware übergeben, von dieser signiert; die zurückgelieferten Signaturdaten werden in Tabellen der Kassendatenbank in logischer Verbindung zur Kassentransaktion gespeichert.

Konformität

Alle beschriebenen Funktionen können nur von Benutzern mit der dafür notwendigen Berechtigung getätigt werden. Sämtliche Funktionen werden in der Verantwortung des berechtigten Benutzers, in letzter Konsequenz des Kassensystembetreibers (Unternehmers), ausgeführt. Aufgrund des geschilderten Programmablaufs wird der Nachweis der vollständigen, richtigen und lückenlosen Erfassung aller Geschäftsvorfälle und allfälliger nachträglicher Änderungen gewährleistet.

Länderspezifische Erfordernisse: Deutschland

GoBD

GoBD = „Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff". Festgelegt vom BMF mit Schreiben vom 14.11.2014 (wirksam ab 01.01.2015), Neufassung 28.11.2019 (gültig ab 01.01.2020), weitere Aktualisierung 11.03.2024 (gültig ab 01.04.2024). Diese Grundsätze werden im APRO Kassensystem nach bestem Wissen und Gewissen umgesetzt.

KassenSichV

Durch die KassenSichV werden zusätzliche Standards zur Verhinderung von Manipulationen verbindlich vorgeschrieben. Basis ist das „Gesetz zum Schutz vor Manipulationen an digitalen Grundaufzeichnungen" vom 16.12.2016 sowie die Kassensicherheitsverordnung vom 26.09.2017 (in Kraft ab 01.01.2020). Kassensysteme müssen mit einer zertifizierten Technischen Sicherheitseinrichtung (zTSE) vor Manipulation geschützt werden. APRO nutzt dafür die fiskaltrust.Middleware; hauptsächlich verwendet wird die Swissbit-TSE als USB-TSE.

DSFinV-K Export

Ein Datenexport im DSFinV-K-Format kann jederzeit abgerufen werden. Der Bediener erfasst den Zeitbereich; als Ergebnis werden im ausgewählten Exportpfad eine ZIP-Datei mit den DSFinV-K-Daten sowie eine TAR-Datei mit den TSE-TAR-Files erzeugt.

GoBD-Export

Zusätzlich können die Kassensystemdaten wie im allgemeinen Teil beschrieben bereitgestellt werden. Im Export sind dann zusätzlich eine index.xml mit den Feldbeschreibungen der CSV-Dateien und die gdpdu-01-09-2004.dtd enthalten. Diese sind für den Import in die Prüfsoftware IDEA notwendig.

Länderspezifische Erfordernisse: Österreich

RKSV

In der Registrierkassensicherheitsverordnung wird die technische Umsetzung der Manipulationssicherheit elektronischer Aufzeichnungssysteme geregelt. APRO nutzt die fiskaltrust.Middleware; es stehen alle am Markt verfügbaren Vertrauensdiensteanbieter und deren RKSV-Produkte zur Verfügung. Hauptsächlich verwendet wird die ATRUST-SmartCard als USB-Stick; in virtualisierten Umgebungen kommt häufig ein Hardware-Sicherheitsmodul (HSM) von PRIMESIGN zum Einsatz.

Kassennachschau Null-Beleg, DEP7

Wie in der RKSV vorgesehen, kann jederzeit ein Nullbeleg erstellt werden. Auf mobilen Eingabegeräten (Orderman, Handy) gibt es keine explizite Null-Beleg-Funktion; da jede Abrechnung auf Bar mit Betrag 0 einen Null-Beleg darstellt, kann auch dort durch Bonierung und Abrechnung eines Artikels mit Preis 0 auf BAR ein Nullbeleg ausgehändigt werden. Berechtigte Benutzer können jederzeit das in der RKSV spezifizierte DEP7-Protokoll abrufen und den Prüfungsorganen bereitstellen.

E131-Datenexport

Zusätzlich zum allgemeinen Datenexport können die Kassendaten zu Prüfungszwecken in einem vereinfachten Format bereitgestellt werden (FinanzArtikelJournal und FinanzZahlungJournal), umgesetzt als Berichte mit CSV-Ausgabe. Das FinanzArtikelJournal beinhaltet die Geschäftsfalldaten inkl. Artikeldaten, das FinanzZahlungJournal die Zahlungsdaten der Abrechnungsgeschäftsfälle. Beide Exporte können in die Prüfsoftware ACL importiert werden (dokumentierte Vorlage vorhanden).

Länderspezifische Erfordernisse: Italien

Fiskaldrucker (RT-Drucker)

Umsatzrelevante Geschäftsfälle müssen über den Fiskaldrucker gedruckt werden. APRO nutzt die fiskaltrust.Middleware, um die Geschäftsfälle an den Fiskaldrucker zu übergeben. Für die einzelnen Fiskaldrucker müssen Tagesabschlüsse erzeugt werden; dafür werden im Kassensystem die Geräteabschläge genutzt und an die Middleware übergeben.

Elektronische Rechnung

Rechnungen an Unternehmen (B2B) müssen als elektronische Rechnung übermittelt werden — sowohl direkt bezahlte Geschäftsfälle als auch Rechnungen auf Ziel. Aus den kassensysteminternen Daten wird die elektronische Rechnung als XML erzeugt und in der Datenbank gespeichert. Das XML wird per API in ein Portal übertragen, das die Zustellung und Weiterleitung an die Sistema di Interscambio (SDI) abwickelt. Alternativ kann das XML in einen konfigurierten Pfad exportiert und manuell hochgeladen werden.

Transaktionen (Transaktionstypen)

Die einzelnen Aktivitäten im Kassensystem sind als Transaktionen abgebildet. In den bereitgestellten Daten eines Finanzexports sind sie in den Dateien FinanzArtikelJournal und FinanzZahlungJournal in den ersten beiden Spalten ersichtlich. Eine Transaktion ist über ihre ID eindeutig identifizierbar.

Code-Abgleich: ID 41 wurde gegenüber dem ursprünglichen Doku-Stand von CardCompleteKassenschnitt in TerminalKassenschnitt umbenannt (ab Version 9.8.24). In der Datenbank-Tabelle TransaktionTyp bestehen einzelne Schreibvarianten (z. B. ID 10 BestallmanagerUndo, ID 18 Kellneruebergabe, ID 31 GaesteanzahlKorrigieren). Maßgeblich (SSOT) ist die Tabelle dbo.TransaktionTyp (suite/Executeables/DbScripts/Stammdaten/TransaktionTyp.sql + UpdateScripts).

Gerätetypen

Transaktionen können über verschiedene Eingabesysteme erstellt werden. Die folgende, fachlich-konzeptionelle Übersicht stammt aus dem ursprünglichen Doku-Stand:

Code-Abgleich (Tabelle GeraetTyp): Die tatsächliche Stammdaten-Tabelle dbo.GeraetTyp (suite/Executeables/DbScripts/Stammdaten/GeraetTyp.sql + UpdateScripts) verwendet eine abweichende Nummerierung und Benennung gegenüber der konzeptionellen Übersicht oben. Maßgeblich für Transaktion.GeraetId ist diese Tabelle:

Zahlungsmittelgruppen

Für die Ermittlung der Tageslosung sind die Transaktionen 3 (Abrechnen) und 5 (Rechnung Zurückholen) in Kombination mit den Zahlungsmittelgruppen 1 (Umsatzwirksam) und 8 (Transfer Umsatzwirksam — sofern verwendet) maßgeblich.

Belegnummernerstellung

Belegnummern werden in unterschiedlichen Nummernkreisen geführt:

In der Datei FinanzArtikelJournal kann es Datensätze mit gleicher Belegnr geben — einerseits durch Überschneidungen der Belegnummernkreise, vor allem aber, weil eine Transaktion mehrere Artikel beinhalten kann.

Feldbeschreibungen der Exportdateien

Transaktion.csv

Geschaeftsfall.csv

GeschaeftsfallArtikel.csv

BonierterArtikel.csv (Bonierjournal)

GeschaeftsfallZahlungen.csv

Code-Abgleich: Die Spalten ab ExternerZahlungsmitteltypeId (externe Zahlungsmittel, Gutschein- und Hotelschnittstellen-Felder HMS*) sind im aktuellen Export enthalten, im ursprünglichen Doku-Stand jedoch nicht aufgeführt (GDPdU/index.xml, ExportGeschaeftsfallZahlungDto).

Vereinfachtes Format — FinanzArtikelJournal.csv

Vereinfachtes Format — FinanzZahlungJournal.csv

Code-Abgleich: Die Spalte BelegNrFiskalisierung (Belegnummer aus der Signatur-/Fiskalisierungstabelle) ist im aktuellen Bericht enthalten, im ursprünglichen Doku-Stand jedoch nicht aufgeführt.

Quelle

Inhaltlich basierend auf der APRO Systembeschreibung (PDF, 19 Seiten), die der Fiskus in Österreich als Verfahrensdokumentation verlangt. Dieses Dokument wird über die Online-Hilfe apro.at/hilfe sowie über den „Verfahrensdokumentation"-Link im Finanz-Bereich von my.apro bereitgestellt (Story — Finanzprüfungsexport & RKSV).

Siehe auch

• finanzpruefung-at.md — Ablauf einer österreichischen Finanz-/Kassenprüfung (Prozesssicht)
• fiskaltrust-einrichtung-at.md — Basis der RKSV-Konformität
• tse-deutschland-einrichten.md — KassenSichV/TSE für Deutschland
• null-beleg.md — Nullbeleg im Bon