AVS - Einrichtung § 131 Abs. 2 und 3 BAO (1.7.7)

1.  Allgemeines

Gemäß der Kassenrichtlinie 2012 ist das AVS als 'Kasse Typ 3 - Kassensysteme bzw. PC-Kassen' zu klassifizieren.

Geschäftsfälle wurden im AVS schon immer - wie es die Bundesabgabenordnung verlangt - chronologisch, vollständig und korrekt gespeichert. Nachträgliche Änderungen (= Korrekturen) waren und sind nicht bzw. nur eingeschränkt mit entsprechender Protokollierung möglich.

Die Geschäftsfälle werden unmittelbar bei der Abwicklung in der Datenbank festgehalten und nach Abschluss erfolgt die automatische Belegerteilung.

Ein Kassatagesprotokoll als Dokumentation der Tageslosung kann jederzeit erstellt werden. Kassatagesprotokolle enthalten sämtliche Geschäftsfälle eines Tages (von 00:00:00 bis 23:59:59) und sind in einer eigenen Tabelle (redundant) gespeichert. Kassensalden pro Tag und Kasse sind ebenfalls in einer eigenen Tabelle (redundant) gespeichert. Sämtliche Tagesabschlüsse (auch Zwischenabschlüsse) sind aus der Datenbank rechenbar.

Eine Ermittlung und Überprüfung des aktuellen Kassastandes ('Kassasturzfähigkeit') ist jederzeit auf Knopfdruck möglich. Anzumerken ist, dass sonstige Kassaein-/-ausgänge in der Praxis nicht immer im AVS erfasst werden, sondern von den Apotheken mehrheitlich die beim Tagesabschluss ermittelte Tageslosung zusammen mit den sonstigen Kassaein-/-ausgängen in einem externen - manuell oder elektronisch geführten - Kassabuch eingetragen wird.

Details zur Erfassung von Geschäftsfällen und zur Erstellung von Tagesabschlüssen sind im Dokument 'AVS - Bedienung Taraarbeitsplatz' beschrieben. Dieses Dokument umfasst folgende Kapitel:

• Aufbau Arbeitsoberfläche
• Beschreibung Funktionsbereiche
• Abwicklung von Geschäftsfällen
• Behandlung von Rezepten
• Tarafunktionen
• Zusatzfunktionen
• Durchführung Tagesabschluss

Die für einen Beleg relevanten Kunden- und Artikelstammdaten werden bei den Belegen redundant gespeichert, eine Änderung dieser Stammdaten ist daher direkt aus den Belegdaten nachvollziehbar.

Die Speicherung der Daten erfolgt in einer Oracle-Datenbank (Version 9.2, 10.2 oder 11.2.). Aufgrund der komplexen Datenstrukturen ist es für den Anwender nicht möglich, gespeicherte Geschäftsfälle in der Datenbank nachträglich zu verändern. Für Listen und Auswertungen werden die Daten mittels SQL-Statements aus der Datenbank ausgelesen.

Zwecks Datensicherung erstellt der AVS-Applikationsserver mindestens 2 Mal täglich im Ordner \avs\export\dmp ein Dumpfile, welches sämtliche AVS-Daten enthält. Die letzten beiden Dumpfiles liegen in komprimierter Form vor und können mit einer Standardsicherungssoftware auf externe Datenträger kopiert werden.

Das AVS enthält keinen 'Demo-' bzw. 'Trainingsmodus', eine Erfassung von 'Testgeschäftsfällen' ist nicht vorgesehen.

Beim Ausfall des Servers oder des Netzwerks können Geschäftsfälle mittels lokal installiertem 'Notbetrieb' erfasst werden. Beim nächsten Starten des Normalbetriebs werden die im Notbetrieb erfassten Belege nach Rückfrage in die zentrale Datenbank übernommen. Im Datenerfassungsprotokoll werden solche Belege in der Kopfzeile mit der jeweiligen Notbetriebsbelegnummer ergänzt.

Kassabons, die im Notbetrieb erstellt wurden, sind mit 'NB' vor der Belegnummer gekennzeichnet.

Der Notbetrieb erlaubt lediglich eine einfache Erfassung von Tarageschäftsfällen ohne diverse Zuatzfunktionen wie z.B. Einsatz, Abholer, Reservierungen, Artikel-Bestellung, Artikel-Info, SIS/NEM-Info, Interaktions-Check, Kunden-Info, magistrale Taxierung usw.

Um die Darstellbarkeit der Ordnungsmäßigkeit der Aufzeichnungen gegenüber Dritten weiter zu verbessern, wurden - beginnend mit Version 1.7.4 (Herbst 2011) zusätzlich folgende Maßnahmen implementiert:

• fortlaufende Nummerierung der Belegköpfe und Einzelpositionen beim Speichern von Tarageschäftsfällen (= Kennzeichnung jeder Zeile mit einer Sequenznummer); Ausdruck der Kopf-Sequenznummer am Kassabon

• Generierung und Speicherung eines Hash-Wertes aus den Geschäftsfalldaten (samt Einbeziehung eines geheimen Schlüssels); Prüfung des Hash-Wertes bei der Anzeige der Bearbeitungsdaten eines Geschäftsfalls

• Implementierung eines Datenerfassungs- bzw. Ereignisprotokolls: komplette Protokollierung Erfassung/Bearbeitung/Storno von Geschäftsfällen, (Teil-)Zahlungen, Kundenreservierungen und offenen Abgaben in einer eigenen Tabelle

• neue fortlaufende Nummerierung (Sequenznummer) der Einträge im Warenjournal

• erweiterte Protokollierung von Transaktionen mit Warenbewegungen (z.B. Speichern Tarageschäftsfall), die aus technischen Gründen (z.B. Stromausfall) nicht abgeschlossen werden konnten

2.  Beschreibung der Maßnahmen im Detail

o  fortlaufende Nummerierung der Belegköpfe (Tarabelege) und Einzelpositionen

Zusätzlich zur Belegnummer (Bonnummer) werden ab Version 1.7.4 Belegköpfe und Einzelpositionen über eine interne ID beginnend mit 20000001 durchnummeriert. Damit kann die Vollständigkeit der über den Menüpunkt 'Verkauf - Tara' erfassten Geschäftsfälle wie folgt dargestellt werden:

Die interne ID der Belegköpfe wird am jeweiligen Kassabon zusätzlich zur Belegnummer (Bonnummer) angedruckt (ganz unten):
 

Sowohl die Bonnummer als auch die interne ID sind vom Benutzer nicht beeinflussbar und können auch nicht zurückgesetzt werden.

Die Bonnummer wird in der Datenbank programmtechnisch über eine eigene Tabelle verwaltet. Wenn eine Transaktion aufgrund technischer Probleme nicht beendet werden kann, entsteht keine Lücke in der Nummerierung, weil für die gesamte Transaktion (inkl. der bereits vergebenen Bonnumemr) ein 'Rollback' erfolgt und der gesamte Geschäftsfall inkl. der Bonnummer nicht gespeichert wird.

Im Gegensatz dazu wird die interne ID über eine 'Oracle-Sequence' (= Datenbankobjekt, mit dem eindeutige Nummern erzeugt werden) vergeben. Eine Oracle-Sequence wird bei einem Rollback nicht zurückgesetzt, d.h. es entstehen Lücken in der Nummerierung über die interne ID, wenn das Schreiben eines Geschäftsfalls in die Datenbank aus technischen Gründen nicht abgeschlossen werden kann.

Die unterschiedliche Behandlung von Bonnummer und interner ID wurde bewusst gewählt, um über Lücken in der internen ID das Scheitern von Geschäftsfall-Transaktionen dokumentieren zu können (siehe dazu auch die Ausführungen zur Nummerierung der Einträge im Warenjournal bzw. zur erweiterten Protokollierung von gescheiterten Transaktionen mit Warenbewegungen weiter unten in diesem Dokument).

o  Generierung und Speicherung eines Hash- Wertes aus den Geschäftsfalldaten

Zur Gewährleistung der Integrität gespeicherter Geschäftsfalldaten wird - ebenfalls seit Version 1.7.4 - aus den relevanten Kopf- und Positionsdaten unter Einbeziehung eines geheimen Schlüssels (Länge > 100 Bit) ein Hash-Wert (Länge 64 Byte) errechnet und in einer eigenen Datenbanktabelle abgelegt.

Der Hash-Wert für den auf Seite 2 dargestellten Beleg sieht z.B. wie folgt aus:
 

Eine Überprüfung, ob der gespeicherte Hash-Wert zu den Geschäftsfalldaten passt, kann direkt in der Taramaske durch Klick auf die Schaltfläche [Personal] erfolgen:
 

Jede - auch noch so geringfügige - nicht vom Programm erlaubte und dokumentierte Änderung der in der Datenbank gespeicherten Geschäftsfalldaten ist bei den angezeigten Bearbeitungsdaten sichtbar, z.B. Änderung des Preises (und damit der Summe) von EUR 5,40 auf 5,39:
 

o  Datenerfassungs-/Ereignisprotokoll (Tara-Erfassungsprotokoll)

Ebenfalls seit Version 1.7.4 werden die Erfassung der Geschäftsfälle und die damit im Zusammenhang stehenden Aktionen in einer eigenen Tabelle, dem Tara-Erfassungs-protokoll aufgezeichnet.

Das Tara-Erfassungprotokoll dokumentiert neben der Erfassung von Geschäftsfällen auch alle vom Programm erlaubten nachträglichen Änderungen (diese werden und wurden zusätzlich auch in eigenen Protokolltabellen gespeichert), die Vorerfassung von Geschäftsfalldaten (z.B. Reservierungen), buchhalterisch relevante Zusatzfunktionen (z.B. Ausbuchen offener Beträge) sowie sonstige Ereignisse, die mit einem Geschäftsfall in Zusammenhang stehen (z.B. Ausdruck Beleg). Bei jedem Eintrag ist angegeben, ob es sich um eine Neuanlage, Änderung oder Löschung von Daten in der Datenbank handelt.

Konkret gibt es folgende Typen von Eintragungen:

• Kassabeleg: Speichern von Kassabelegen (inkl. Stornobelege)
• Zahlung: Zahlungsein-/ausgänge (auch Teilzahlungen) zu Kassabelegen
• Zahlung offener Betrag: Zahlungseingänge durch Teil-/Restzahlungen zu Kassabelegen
• Lieferschein: Speichern von Lieferscheinen in der Taramaske
• Ändern Zahlart/Kunde: nachträgliche Änderung von Zahlart und/oder Kunde von Kassabelegen/Lieferscheinen
• Offene Abgabe/Kundenreservierung: Vorerfassung von Geschäftsfalldaten durch Erstellung/Eiinlösung von offenen Abgaben (z.B. in Zentralkassensystemen) bzw. Kundenreservierungen
• Ändern Status Abholer/Einsatz: offene Abholer/Einsätze auf 'eingelöst' setzen oder eingelöste Abholer/Einsätze auf 'offen' setzen, ohne dabei eine Geschäftsfall zu erzeugen
• Ändern Preis Abholer: Änderung des Preises eines offenen Abholers vor der Einlösung
• Taxierung Platzhalter mag. Zub.: Taxierung (= Preisberechnung) von Platzhaltern für magistrale Zubereitungen, die auf Rezept oder als Abholer (im Privatverkauf) erfasst wurden
• Ausbuchen offener Betrag: Ausgleich offener Posten ohne Zahlungseingang
• Ausdruck Beleg: Ausdruck Kassabon/Lieferschein

Das Tara-Erfassungsprotokoll kann - ebenso wie die Tarabelege - über einen entsprechen-den Menüpunkt im CSV-Format exportiert werden (siehe unten).

o  fortlaufende Nummerierung (Sequenznummer) der Einträge im Warenjournal

Seit Version 1.7.5 werden sämtliche Einträge im Warenjournal (= Summe der Artikelkonten) über eine interne ID beginnend mit 20000001 durchnummeriert. Damit kann die Vollständigkeit der gespeicherten Warenbewegungen (Verkäufe, Einkäufe, Korrekturen) dokumentiert werden:

Beim Export der Artikelkonten kann diese ID bei Zeiträumen ab 2012 zusätzlich berücksichtigt werden (als Spalte und/oder als Sortierkriterium).

Analog zu den Tara-Belegen wird die interne ID auch im Warenjournal über eine 'Oracle-Sequence' vergeben, d.h. es entstehen Lücken, wenn eine Transaktion, bei der (auch) ins Warenjournal geschrieben wird, aus technischen Gründen nicht abgeschlossen werden kann.

o  Protokollierung nicht abgeschlossener Transaktionen mit Warenbewegungen

Interne ID's werden im AVS generell über Datenbank-Sequences versorgt. Da eine Oracle-Sequence bei einem Rollback nicht zurückgesetzt wird, entstehen beim Scheitern von Transaktionen Lücken in Nummerierungen auf Basis interner ID's.

Im AVS wurden bewusst keine programmtechnischen Vorkehrungen getroffen, das Entstehen solcher Lücken zu verhindern. Bei extensiver Auslegung tragen solche Lücken sogar indirekt zur Erfüllung das elektronischen Radierverbots bei, weil einmal begonnene Speichervorgänge damit erkennbar bleiben und nicht unkenntlich gemacht werden.

Bezüglich der internen ID's für das Warenjournal wurde mit Version 1.7.5 eine erweiterte Protokollierung vergebener Sequenznummern implementiert. Auf Basis dieser Daten kann man feststellen, wann eine Transaktion nicht beendet werden konnte und um welche Art von Transaktion es sich dabei gehandelt hat.

Konkret könnte das z.B. bei einem Stromausfall beim Speichern eines Kassabons wie folgt aussehen:

Warenjournal:

Sequenznummernprotokoll (nicht abgeschlossene Transaktionen):

           AVS_SEQ_WAJO       20000005        Kassabon KDE 947

Das Schreiben ins Warenjournal beim Speichern des Kassabons 947 konnte nicht abgeschlossen werden. Da die Lücke insgesamt 3 Nummern umfasst, enthielt der - nicht gespeicherte - Geschäftsfall 3 Positionen.

Damit lassen sich also nicht nur Lücken direkt im Warenjournal besser erklären, sondern auch fehlende interne ID's bei Tarabelegen oder beim Tara-Erfassungsprotokoll, weil das Speichern von Geschäftsfällen in der Regel auch mit einem Schreiben ins Warenjournal verbunden ist.

o  Datenexport im CSV-Format

Unter 'Verwaltung - Import/Export' stehen folgende Menüpunkte zur Auswahl (patientenbezogene Daten werden aufgrund der geltenden Verschwiegenheitspflichten anonymisiert):

• Export Tarabelege
• Export Tara-Erfassungsprotokoll (Daten ab 2012)
• Export Rechnungen
• Export Artikelkonten
• Export AVS-Versionshistorie (Menüpunkt verfügbar ab Version 1.7.7)
• Export Sequenznummernprotokoll (Menüpunkt verfügbar ab Version 1.7.7, Daten ab 2012)

Details zum Aufbau der Exportdateien sind im Dokument 'AVS - Datenexport für Betriebsprüfung' beschrieben

o  Listen und Auswertungen

Unter 'Verkauf - Listen' stehen folgende Menüpunkte zur Verfügung:

• Kassajournal
• Kassabonaufstellung
• Tagesprotokollliste
• Kassabuch
• Sonstige Kassaein-/-ausgänge
• Ausgebuchte offene Beträge
• Sondergeschäftsfälle
• Nachträgliche Änderungen

Für interne Kontrollzwecke existieren zahlreiche zusätzliche Auswertungen, diese enthalten jedoch (auch) patientenbezogene Arzneimitteldaten und dürfen daher nicht an Dritte weitergegeben werden.

Tagesprotokolle werden mit dem Menüpunkt 'Verkauf - Tagesabschluss Tara' erstellt und ausgedruckt.

o  Ermittlung des aktuellen Kassastandes

Der aktuelle Kassastand (für jede einzelne oder für alle Kassen) kann jederzeit direkt in der Taramaske durch Aufruf der Sonderfunktion [akt. Kassastand] bzw. Betätigung von [Strg+Z] ermittelt werden.

Über eine Mandanteneinstellung im Karteireiter 'Tara II' wird festgelegt, ob der Kassastand über den Tagesabschluss hinaus mitgeführt wird.
 

Bei deaktiviertem Kontrollkästchen wird der Kassastand am Beginn jedes Tages auf 0,00 zurückgesetzt, das Kassabuch wird extern geführt. Bei aktivierter Einstellungen müssen alle sonstigen Kassaein-/-ausgänge im AVS erfasst werden, das Kassabuch ist somit im AVS integriert.

o  Belegerteilung

Über diverse Mandanteneinstellungen im Karteireiter 'Tara I' wird festgelegt, wie viele Belege bei bestimmten Geschäftsfällen gedruckt werden sollen.
 

Falls gewünscht, kann bei Geschäftsfällen mit 0-Beträgen der Ausdruck eines Belegs unterdrückt werden.

Das Drucken eines Beleges wird in der Datenbank im Belegkopf gespeichert.

o  Personalisierung der Belegerfassung

Der Abschluss eines Geschäftsfalls kann auch durch Scannen eines individuellen Personalcodes erfolgen. Über eine Mandanteneinstellung im Karteireiter 'Tara II' kann das System so konfiguriert werden, dass ein Abschluss von Geschäftsfällen nur durch Erfassung eines Personalcodes möglich ist.