FESTLEGUNGEN DES BMF ZU DETAILFRAGEN DER REGISTRIERKASSENSICHERHEITSVERORDNUNG (RKSV)

Transkript

1 FESTLEGUNGEN DES BMF ZU DETAILFRAGEN DER REGISTRIERKASSENSICHERHEITSVERORDNUNG (RKSV) BUNDESMINISTERIUM FÜR FINANZEN A-SIT PLUS GMBH VERSION Einleitung: Dieses Dkument wurde in Zusammenarbeit zwischen dem BMF und A-SIT Plus erstellt. Es enthält Festlegungen in technischen Detailfragen zur RKSV auf Przessebene und Klarstellungen bzw. Ergänzungen im Bereich der Mustercde-Beispiele. Darüber hinaus werden in diesem Dkument häufig gestellte Fragen der Kassenhersteller und Snderfälle aufgegriffen und geregelt. Mit Versin 1.1. werden Frmate für Testfälle definiert und Basistestfälle für die Überprüfung der Krrektheit vn Kassensystemen integriert. Ausblick: In der nächsten Versin des Dkuments werden die Testfälle für die Überprüfung der Kassenimplementierung erweitert swie eine detaillierte Übersicht über RKSV-knfrme Kassenknfiguratinen bereitgestellt.

2 Inhalt 1 Allgemeine Infrmatinen Definitinen Registrierkasse Kassen-ID AES-Schlüssel Datenerfassungsprtkll Summenspeicher Belegnummer Sichere Signaturerstellungseinheit Relatinen Aufbereitung der Daten für die Signaturerstellung Daten für die Erstellung des maschinenlesbaren Cdes Verarbeitung vn Belegen Verarbeitung eines Standardbelegs Verarbeitung eines Startbelegs Verarbeitung vn Nullbelegen (z.b. Jahresbeleg, Mnatsbeleg...) Verarbeitung vn Strnbelegen Verarbeitung vn Trainingsbelegen Aufbereiten der zu signierenden Daten Detailprzesse für die Verkettung vn Belegen Verkettung beim Startbeleg Verkettung bei allen Belegen außer dem Startbeleg Detailprzesse für die Verarbeitung des Umsatzzählers Aufbereiten/Aktualisieren des Umsatzzählers Aufbereiten der Daten für den Verschlüsselungsprzess Verschlüsselung mit ICM/CTR Mdus Verschlüsselung durch Emulatin des ICM/CTR Mdus über ECB/CFB Mdus Aufbereitung des verschlüsselten Umsatzzählers Signaturerstellung Erstellung der JWS-Signatur (Sichegnaturheitseinrichtung funktinsfähig) Erstellung der JWS-Signatur (Sichegnaturheitseinrichtung ausgefallen) Aufbereitung der maschinenlesbaren Cdes Aufbereitung des maschinenlesbaren Cdes (Basis-Cde) Aufbereitung QR-Cde Aufbereitung OCR-Cde Aufbereitung Link Aufbereitung für DEP Exprt des Datenerfassungsprtklls Autmatisierte Tests Überblick Frmatdefinitinen für Testfälle Testsuite-Frmat Output-Frmat Testfälle Vllständige Testszenarien Realistische Testszenarien Use Cases Inbetriebnahme der Kasse Erstellung vn Standardbelegen Erstellung vn Strnbelegen Erstellen eines Jahresbelegs/Nullbelegs (Jahres- Mnats- Tagesbeleg, Sammelbeleg nach Ausfall, Schlussbeleg etc.) Ausfall der Sichegnaturheitseinrichtung Exprtieren des DEP Prtklls Testfälle Frmatiert: Verzeichnis 2, Tabstpps: 1,55 cm, Links + Nicht an 0,78 cm Seite 2/73

3 Seite 3/73

4 Revisinen Versin Datum Autr Anmerkung BMF, A-SIT Plus Initiale Versin Frmatierte Tabelle BMF, A-SIT Plus Alle Änderungen werden auch als Diff-Dkument zur Verfügung gestellt um einen schnellen Einblick auf Details zu ermöglichen. Es wurde in den Abschnitten, die die Signaturerstellung behandeln, fälschlicherweise die Bezeichnung Signatureinrichtung ausgefallen statt Sicherheitseinrichtung ausgefallen verwendet. Alle Referenzen auf Signatureinrichtung wurden durch Sicherheitseinrichtung ersetzt. In Passagen zu bestimmten Belegtypen wurde durch einen Fehler fälschlicherweise auf Infrmatinen vm Startbeleg verwiesen. Die fehlerhaften Passagen wurden krrigiert. Diverse Typs bzw. Qualitätsmängel wurden behben. Ergänzung einer Anmerkung zu der Verwendung der UTF-8 Kdierung der Kassen-ID bzw. Belegnummer. Hinzufügen der Kapitel die die autmatisierten Tests vn Kassensystemen beschreiben. Seite 4/73

5 1 Allgemeine Infrmatinen Als Grundlage für ein krrektes Verständnis der im vrliegenden Dkument ausgeführten technischen Details werden in diesem einführenden Abschnitt relevante Begriffe definiert und grundlegende Eigenschaften festgelegt. Die in diesem Abschnitt enthaltenen Infrmatinen basieren auf Definitinen der Registrierkassensicherheitsverrdnung (RKSV), sind jedch für ein besseres Verständnis in einem höheren Detailierungsgrad ausgeführt. Ziel ist es, ein gemeinsames Verständnis der für die Umsetzung einer Registrierkassea gemäß RKSV relevanten Kmpnenten und deren Beziehung zueinander zu gewährleisten. Dieser Abschnitt ist in zwei Unterabschnitte gegliedert. Im ersten Unterabschnitt werden Definitinen für relevante Kmpnenten einer Registrierkassea gegeben. Basierend darauf wird im zweiten Unterabschnitt dargelegt, welche Relatinen diese Kmpnenten zueinander haben. 1.1 Definitinen Für die Umsetzung einer Registrierkasse gemäß RKSV sind die flgenden Kmpnenten relevant Registrierkasse Die RKSV definiert den Begriff der Registrierkasse wie flgt: Registrierkasse (auch elektrnische Registrierkasse): verallgemeinerte Frm jedes elektrnischen Datenverarbeitungssystems, das elektrnische Aufzeichnungen zur Lsungsermittlung und Dkumentatin vn einzelnen Barumsätzen erstellt, insbesndere elektrnische Registrierkassen jeglicher Bauart, serverbasierte Aufzeichnungssysteme (auch zur Abwicklung vn Online- Geschäften), Waagen mit Kassenfunktinen und Taxameter. Eine Registrierkasse kann mit Eingabestatinen verbunden sein [RKSV, 2015] Eine Registrierkasse wird im Wesentlichen durch ein Datenerfassungsprtkll (DEP) definiert. Das heißt, jede Registrierkasse hat genau ein DEP. An eine Registrierkasse können beliebig viele Eingabestatinen angeschlssen sein. Für die Signierung vn Belegen gemäß RKSV steht einer Registrierkasse zumindest eine Sichere Signaturerstellungseinheit zur Verfügung Kassen-ID Die RKSV definiert den Begriff der Kassen-ID (Kassenidentifikatinsnummer) wie flgt: Kassenidentifikatinsnummer: über FinanzOnline gemeldetes Kennzeichen einer Registrierkasse, das auch die Unterscheidung verschiedener Registrierkassen mit gleicher Signaturerstellungseinheit ermöglicht [RKSV, 2015] Die Kassen-ID muss innerhalb eines Unternehmens eindeutig sein. Das heißt, ein Unternehmer darf zwei der mehr eigenen Registrierkassen nicht dieselbe Kassen-ID zuweisen. Sehr whl dürfen jedch zwei unterschiedliche Unternehmer dieselbe Kassen-ID verwenden. Prinzipiell gilt, dass die Kassen-ID durch den Unternehmer frei wählbar ist und jeder Registrierkasse genau eine Kassen-ID zugerdnet werden muss AES-Schlüssel AES (Advanced Encryptin Standard) bezeichnet ein symmetrisches Verschlüsselungsverfahren. Mit diesem Verfahren können beliebige Daten mithilfe eines Schlüssels verschlüsselt und wieder entschlüsselt werden. Eine Entschlüsselung der Daten ist nur möglich, wenn der für die Verschlüsselung verwendete Schlüssel bekannt ist. Aus den verschlüsselten Daten alleine kann weder auf die Klartextdaten nch auf den verwendeten Schlüssel geschlssen werden. Die RKSV definiert die Verwendung vn AES für die Verschlüsselung des Summenspeichers der Registrierkassea. Da der Summenspeicher der Registrierkasse Teil jedes erstellten Belegs ist, muss der Summenspeicher vr Aufbringung am Beleg verschlüsselt werden, um die Vertraulichkeit Seite 5/73

6 des Summenspeichers zu gewährleisten. Der für diese Verschlüsselung verwendete Schlüssel wird in Flge als AES-Schlüssel bezeichnet. Der AES-Schlüssel kann vm Unternehmer frei gewählt werden und muss im Zuge der Registrierung der Registrierkasse über FinanzOnline bekanntgegeben werden. Einer Registrierkasse ist genau ein AES-Schlüssel zugerdnet. Mehrere Registrierkassen können innerhalb eines Unternehmens auch denselben AES-Schlüssel verwenden. Ein Wechsel des AES- Schlüssels im laufenden Betrieb ist nicht möglich Datenerfassungsprtkll Die RKSV definiert den Begriff des Datenerfassungsprtklls (DEP) wie flgt: Datenerfassungsprtkll (DEP): eine im Speicher der Registrierkasse der in einem externen Speicher mitlaufende Ereignisprtklldatei, die in Echtzeit jeweils mit Belegerstellung vllständig, frtlaufend chrnlgisch die Barumsätze mit Beleginhalten dkumentiert [RKSV, 2015] Jede Registrierkasse besitzt genau ein DEP. Das heißt die Entität Registrierkasse ist über die Existenz eines eigenen DEP definiert. Dies unterscheidet zum Beispiel Registrierkassen vn an eine Registrierkasse angeschlssenen Eingabestatinen, die selbst über kein DEP verfügen Summenspeicher Die RKSV definiert den Begriff des Summenspeichers wie flgt: Summenspeicher: Speicher in der Registrierkasse, die Zwischen- der einen aktuellen Endstand aufsummierter Beträge wiedergeben [RKSV, 2015] Wie das DEP ist auch der Summenspeicher eindeutig einer Registrierkasse zugerdnet. Das heißt, jede Registrierkasse verfügt über genau einen Summenspeicher Belegnummer Jeder vn einer Registrierkasse erstellte Beleg muss über die Belegnummer des Barumsatzes eindeutig pr Kassen-ID und AES-Schlüssel unterscheidbar gemacht werden. Die Belegnummer eines Belegs ist innerhalb eines Unternehmens für Kassen-ID und AES-Schlüssel eindeutig. Wird beispielsweise nach Stilllegung einer Registrierkasse A eine neue Registrierkasse B mit der gleichen Kassen-ID und dem gleichen AES-Schlüssel in Betrieb genmmen, darf Registrierkasse B keine Belegnummern vergeben, die bereits zuvr vn Registrierkasse A vergeben wurden. Ändert sich im Zuge der Inbetriebnahme vn Registrierkasse B die Kassen-ID und/der der AES- Schlüssel, dürfen Belegnummern, die bereits vn Registrierkasse A vergeben wurden, auch vn Registrierkasse B nchmal vergeben werden Sichere Signaturerstellungseinheit Die RKSV definiert den Begriff der Sicheren Signaturerstellungseinheit wie flgt: Sichere Signaturerstellungseinheit: knfigurierte Sftware der Hardware, die zur Verarbeitung der Signaturerstellungsdaten verwendet wird und die den Sicherheitsanfrderungen des SigG swie den dazu erlassenen Verrdnungen entspricht ( 2 Z 5 SigG) [RKSV, 2015] Die Signaturerstellungseinheit wird vn der Registrierkasse verwendet, um Belege zu signieren. Die Kmmunikatin zwischen Registrierkasse und Sicherer Signaturerstellungseinheit hängt auch vn der jeweiligen Implementierung ab. Im Speziellen können sich in Bezug auf die Sichere Signaturerstellungseinheit Unterschiede zwischen herkömmlichen Kassensystemen und Geschlssenen Gesamtsystemen gemäß RKSV ergeben. Seite 6/73

7 Eine Registrierkasse kann beliebig viele Sichere Signaturerstellungseinheiten für die Belegsignierung verwenden. Eine Sichere Signaturerstellungseinheit kann auch vn mehreren Registrierkassen eines Unternehmers verwendet werden. Eine gemeinsame Verwendung einer Sicheren Signaturerstellungseinheit durch mehrere Unternehmer ist nicht zulässig. 1.2 Relatinen Im vrangegangenen Unterabschnitt wurden jene Kmpnenten, die für die Umsetzung einer Registrierkasse gemäß RKSV relevant sind, definiert und kurz beschrieben. Punktuell wurde auch bereits auf die Relatinen der einzelnen Kmpnenten zueinander eingegangen. Diese Relatinen sind in flgender Abbildung anhand zweier Registrierkassen nchmal exemplarisch dargestellt. Seite 7/73

8 Belegnummer 1 Belegnummer 2 Belegnummer 1 Belegnummer 2 Belegnummer X Belegnummer Y Registrierkasse 1 Registrierkasse N Kassen-ID DEP Kassen-ID DEP Summenspeicher Summenspeicher Zugewiesener AES-Schlüssel Zugewiesener AES-Schlüssel Sichere Zugewiesene Sichere Signaturerstellungseinheit Signaturerstellungseinheit Sichere Sichere Zugewiesene Signaturerstellungseinheit Sichere Signaturerstellungseinheit Signaturerstellungseinheit AES-Schlüssel 1 AES-Schlüssel 2... AES-Schlüssel N Unternehmer-Pl für AES-Schlüssel Sichere Signaturerstellungseinheit 1 Sichere Signaturerstellungseinheit 2... Sichere Signaturerstellungseinheit M Unternehmer-Pl Sicherer Signaturerstellungseinheiten Seite 8/73

9 Belegnummer 1 Belegnummer 2 Belegnummer 1 Belegnummer 2 Belegnummer X Belegnummer Y Registrierkasse 1 Registrierkasse N Kassen-ID DEP Kassen-ID DEP Summenspeicher Summenspeicher Zugewiesener AES-Schlüssel Zugewiesener AES-Schlüssel Sichere Zugewiesene Sichere Signaturerstellungseinheit Signaturerstellungseinheit Sichere Sichere Zugewiesene Signaturerstellungseinheit Sichere Signaturerstellungseinheit Signaturerstellungseinheit AES-Schlüssel 1 AES-Schlüssel 2... AES-Schlüssel N Unternehmer-Pl für AES-Schlüssel Sichere Signaturerstellungseinheit 1 Sichere Signaturerstellungseinheit 2... Sichere Signaturerstellungseinheit M Unternehmer-Pl Sicherer Signaturerstellungseinheiten Abbildung 1. Beispiel-Setup für zwei Registrierkassen. Abbildung 1 illustriert die Relatinen der einzelnen für die Umsetzung einer RKSV-knfrmen Registrierkasse ntwendigen Kmpnenten. Knkret werden aus Abbildung 1 flgende Sachverhalte ersichtlich: Knzeptinell betrachtet verfügt ein Unternehmer über N Registrierkassen. Neben diesen verfügt der Unternehmer über einen Pl vn AES-Schlüsseln und einen Pl vn Sicheren Signaturerstellungseinheiten. Aus diesen beiden Pls verwenden die N Registrierkassen des Unternehmers jeweils genau einen AES-Schlüssel und eine der verfügbaren Sicheren Signaturerstellungseinheiten. Das heißt, einer Registrierkasse wird genau ein verfügbarer AES-Schlüssel statisch zugewiesen. Dieser AES-Schlüssel wird während des Betriebs der Registrierkasse verwendet und kann nicht geändert werden. Die Verwendung der Sicheren Signaturerstellungseinheiten ist hingegen dynamisch, sdass die Registrierkasse im laufenden Betrieb für jeden Beleg neu entscheiden kann, welche registrierte Sichere Signaturerstellungseinheit verwendet werden sll. Frmatiert: Schriftart: Curier, Muster: Transparent (Hintergrund 1) Seite 9/73

10 Jede Registrierkasse eines Unternehmers verfügt über eine eigene Kassen-ID, ein eigenes DEP und einen eigenen Summenspeicher. Für N Registrierkassen eines Unternehmers ergeben sich daher N unterschiedliche Kassen-IDs, DEPs und Summenspeicher. Jede Registrierkasse eines Unternehmers verfügt über genau einen AES-Schlüssel. Prinzipiell kann jeder Registrierkasse ein anderer AES-Schlüssel zugewiesen werden. Zwei der mehr Registrierkassen können sich aber auch einen AES-Schlüssel teilen. Bei N Registrierkassen verfügt der Unternehmer daher über einen Pl vn 1 bis N AES- Schlüssel. Jeder Registrierkasse steht zumindest eine Sichere Signaturerstellungseinheit zur Verfügung. Einer Registrierkasse können auch mehrere Sichere Signaturerstellungseinheiten zur Verfügung stehen. All diese Sicheren Signaturerstellungseinheiten müssen jedch dem Unternehmer zugerdnet und in FinanzOnline registriert sein. Eine Sichere Signaturerstellungseinheit kann auch vn mehreren Registrierkassen verwendet werden. Im Zuge der Belegerstellung kann die Registrierkasse eine beliebige ihr zur Verfügung stehende Sichere Signaturerstellungseinheiten für die Beleg-Signierung verwenden. Die Möglichkeit der dynamischen Wahl der zu verwendenden Sicheren Signaturerstellungseinheit ist ntwendig, um beispielsweise den Zugriff auf zentrale Sichere Signaturerstellungseinheiten über Lad-Balancing-Mechanismen zu ermöglichen, der auch um Registrierkassen die Möglichkeit zu geben, im Fehlerfall dynamisch auf vrhandene Ersatzeinheiten zur sicheren Signaturerstellung zu wechseln. Frmatiert: Schriftart: Curier, Muster: Transparent (Hintergrund 1) Frmatiert: Schriftart: Curier, Muster: Transparent (Hintergrund 1) Frmatiert: Schriftart: Curier, Muster: Transparent (Hintergrund 1) Frmatiert: Schriftart: Curier, Muster: Transparent (Hintergrund 1) Frmatiert: Schriftart: Curier, Muster: Transparent (Hintergrund 1) Anmerkung zu Lad-Balancing: Bei der Verwendung vn mehreren Sicheren Signaturerstellungseinheiten pr Kasse muss darauf geachtet werden, dass der Signaturvrgang und die Erstellung des maschinenlesbaren Cdes abgeschlssen ist bevr der nächste Beleg erstellt wird, bzw. signiert werden kann. Der Ntwendigkeit für die Einhaltung dieser Reihenflge ist die kryptgraphische Verkettung der Belege. Im Zusammenhang mit Lad Balancing kann als nicht die Belegerstellung mit beliebigen Signatureinheiten parallelisiert werden, es kann aber vr der Signaturerstellung aus der Menge der zur Verfügung stehenden Signatureinheiten eine nicht verwendete gewählt werden. Gerade beim Einsatz vn mehreren Karten kann smit eine Verteilung der Last auf mehrere Signatureinheiten erzielt werden und vr allem dynamisch bei höherer Auslastung beliebige weitere Signatureinheiten zu dieser Menge hinzugefügt werden der entfernt werden (entweder aufgrund einer niedrigeren Last der durch den Ausfall vn Signatureinrichtungen). Jede Registrierkasse erzeugt signierte Belege mit einer in Bezug auf Kassen-ID und AES- Schlüssel eindeutigen Belegnummer. Abbildung 1 zeigt ein Beispiel-Setup für einen Unternehmer. Zwischen verschiedenen Unternehmern ergeben sich nur wenige Abhängigkeiten. Dennch sei an dieser Stelle auf flgende Punkte hingewiesen: Zwei der mehrere Unternehmer können sich weder eine Registrierkasse nch eine Sichere Signaturerstellungseinheit 1 teilen. Theretisch können zwei der mehrere Unternehmer zufällig den gleichen AES-Schlüssel wählen. Werden AES-Schlüssel zufällig generiert, ist dies in der Praxis jedch äußerst unwahrscheinlich. 1 Hier ist gemeint, dass zwei Unternehmen nicht das gleiche Signaturzertifikat verwenden können. Das Teilen einer Signaturerstellungseinheit ist im weiteren Sinne schn möglich, da auch zentrale HSM- Lösungen der Remte-Signature Lösungen verwendet werden können. Diese können je nach Knfiguratin vn mehreren Unternehmen gleichzeitig eingesetzt werden. Seite 10/73

11 Kassen-IDs können vn Unternehmern frei gewählt werden. Es kann und muss daher nicht davn ausgegangen werden, dass eine gewählte Kassen-ID, die innerhalb des Unternehmens eindeutig ist, auch unternehmerübergreifend eindeutig ist. Vn Signaturerstellungseinheiten verwendete Signaturschlüssel und zugehörige Signatur- Zertifikate können als glbal eindeutig betrachtet werden. Belegnummern sind nur innerhalb eines Unternehmens pr Kassen-ID und AES-Schlüssel eindeutig. Verwenden zwei der mehrere Unternehmer ein ähnliches Nummerierungs- Schema, kann nicht ausgeschlssen werden, dass Belege unterschiedlicher Unternehmer die gleiche Belegnummer aufweisen. Auch innerhalb eines Unternehmens können Belegnummern mehrfach vergeben werden, sfern sich Kassen-ID und/der AES- Schlüssel der belegerstellenden Registrierkassen unterscheiden. Seite 11/73

12 2 Aufbereitung der Daten für die Signaturerstellung 2.1 Daten für die Erstellung des maschinenlesbaren Cdes 2.2 Verarbeitung vn Belegen Verarbeitung eines Standardbelegs Verarbeitung eines Startbelegs Verarbeitung vn Nullbelegen (z.b. Jahresbeleg, Mnatsbeleg...) Verarbeitung vn Strnbelegen Verarbeitung vn Trainingsbelegen 2.3 Aufbereiten der zu signierenden Daten 2.4 Detailprzesse für die Verkettung vn Belegen Verkettung beim Startbeleg Verkettung bei allen Belegen außer dem Startbeleg 2.5 Detailprzesse für die Verarbeitung des Umsatzzählers Aufbereiten/Aktualisieren des Umsatzzählers Aufbereiten der Daten für den Verschlüsselungsprzess Verschlüsselung mit ICM/CTR Mdus Verschlüsselung durch Emulatin des ICM/CTR Mdus über ECB/CFB Mdus Aufbereitung des verschlüsselten Umsatzzählers Seite 12/73

13 2.1 Daten für die Erstellung des maschinenlesbaren Cdes Eingabewerte Daten für Belegerstellung Daten aus der Kasse Rhbelegdaten Przessbeschreibung Im Flgenden werden die Felder und deren Frmate beschrieben, die für die Belegerstellung im Sinne der RKSV benötigt werden. Dazu sind flgende Anmerkungen relevant: Längenbeschränkung: Für einige der in der weiteren Flge definierten Felder ist keine Längenbeschränkung vrgesehen, dennch muss berücksichtigt werden, dass der aufbereitete maschinenlesbare Cde zu kurz wie möglich gehalten werden sll, um die QR/OCR Repräsentatin am Beleg s einfach wie möglich zu halten. Lediglich bei der LINK-Repräsentatin hat die Länge des maschinenlesbaren Cdes keinen Einfluss für die Darstellung am Beleg. Reihenflge: Die flgende Reihenflge entspricht auch der Reihenflge die für die Aufbereitung der zu signierenden Daten relevant ist. Anmerkung zu UTF-8 Kdierung: Diese Anmerkung betrifft vr allem die Elemente Kassen-ID und Belegnummer: Um hier keine wesentlichen Einschränkungen zu haben, wird UTF-8 für die Kdierung dieser Elemente verwendet. Es sllte dennch beachtet werden, dass diese Daten vr allem bei der manuellen Registrierung einer Kasse vm Unternehmer eingegeben werden müssen. Es empfiehlt sich daher eine für den Unternehmer möglichst benutzerfreundliche Zeichenmenge zu verwenden, die z.b. UTF-8 Escape Sequenzen vermeidet. Felder und deren Werte: Kassen-ID: Beschreibung: Hierbei handelt es sich um die Kassenidentifikatinsnummer die für die Registrierung der Kasse in Finanznline verwendet wird. Die Bezeichnung entspricht einer beliebigen Zeichenkette die UTF-8 kdiert wird. Referenz RKSV: 9 Abs. 2 Z 1 Frmat: JSON-Frmat string, UTF-8 kdiert Länge: Keine Einschränkung Snderfälle: Keine. Es wird bei allen möglichen Varianten der Belegerstellung die tatsächliche Kassenidentifikatinsnummer verwendet. Belegnummer: Beschreibung: Hierbei handelt es sich um die Belegnummer des Belegs. Die Belegnummer entspricht einer alphanumerischen Zeichenkette die UTF-8 kdiert wird. Referenz RKSV: 9 Abs. 2 Z 2 Frmat: JSON-Frmat string, UTF-8 kdiert Länge: Keine Einschränkung Snderfälle: Keine. Es muss immer eine Belegnummer vergeben werden für die garantiert ist, dass sie bei gleicher Kassen-ID und gleichem AES Schlüssel nimmer nur einmal verwendet wird. Beleg-Datum-Uhrzeit: Beschreibung: Das Datum und die Uhrzeit wird im ISO 8601 Frmat hne der Angabe der Zeitzne angegeben (JJJJ-MM-TT T hh:mm:ss, z. B T14:23:34). Es wird immer vn österreichischer Lkalzeit (CET/MEZ) ausgegangen. Referenz RKSV: 9 Abs. 2 Z 3 Frmat: JSON-Frmat string, UTF-8 kdiert Länge: Aufgrund des Frmats festgelegt. Snderfälle: Keine. Es wird bei allen möglichen Varianten der Belegerstellung der tatsächliche Zeitpunkt der Belegerstellung angegeben. Betrag-Satz-Nrmal: Beschreibung: Summe der Brutt-Werte der Belegpsitinen des zu Seite 13/73

14 verarbeitenden Belegs mit dem Steuersatz Nrmal. Ist keine Psitin mit diesem Steuersatz im Beleg vrhanden, s wird der Wert 0,00 eingetragen. Referenz RKSV: 9 Abs. 2 Z 4 Frmat: JSON-Frmat number mit 2 Kmmastellen. Dezimaltrennzeichen entspricht, Länge: Aufgrund des Frmats und des gegebenen Werts festgelegt. Snderfälle: Bei Standardbelegen, Strnbelegen und Trainingsbelegen entspricht der Wert dem tatsächlichem Wert. Bei Nullbelegen und dem Startbeleg wird der Wert per Definitin auf 0,00 gesetzt. Betrag-Satz-Ermaessigt-1: Beschreibung: Summe der Brutt-Werte der Belegpsitinen des zu verarbeitenden Belegs mit dem Steuersatz Ermaessigt-1. Ist keine Psitin mit diesem Steuersatz im Beleg vrhanden, s wird der Wert 0,00 eingetragen. Referenz RKSV: 9 Abs. 2 Z 4 RKSV Frmat: JSON-Frmat number mit 2 Kmmastellen. Dezimaltrennzeichen entspricht, Länge: Aufgrund des Frmats und des gegebenen Werts festgelegt. Snderfälle: Bei Standardbelegen, Strnbelegen und Trainingsbelegen entspricht der Wert dem tatsächlichem Wert. Bei Nullbelegen und dem Startbeleg wird der Wert per Definitin auf 0,00 gesetzt. Betrag-Satz-Ermaessigt-2: Beschreibung: Summe der Brutt-Werte der Belegpsitinen des zu verarbeitenden Belegs mit dem Steuersatz Ermaessigt-2. Ist keine Psitin mit diesem Steuersatz im Beleg vrhanden, s wird der Wert 0,00 eingetragen. Referenz RKSV: 9 Abs. 2 Z 4 RKSV Frmat: JSON-Frmat number mit 2 Kmmastellen. Dezimaltrennzeichen entspricht, Länge: Aufgrund des Frmats und des gegebenen Werts festgelegt. Snderfälle: Bei Standardbelegen, Strnbelegen und Trainingsbelegen entspricht der Wert dem tatsächlichem Wert. Bei Nullbelegen und dem Startbeleg wird der Wert per Definitin auf 0,00 gesetzt. Betrag-Satz-Null: Beschreibung: Summe der Brutt-Werte der Belegpsitinen des zu verarbeitenden Belegs mit dem Steuersatz Null. Ist keine Psitin mit diesem Steuersatz im Beleg vrhanden, s wird der Wert 0,00 eingetragen. Referenz RKSV: 9 Abs. 2 Z 4 RKSV Frmat: JSON-Frmat number mit 2 Kmmastellen. Dezimaltrennzeichen entspricht, Länge: Aufgrund des Frmats und des gegebenen Werts festgelegt. Snderfälle: Bei Standardbelegen, Strnbelegen und Trainingsbelegen entspricht der Wert dem tatsächlichem Wert. Bei Nullbelegen und dem Startbeleg wird der Wert per Definitin auf 0,00 gesetzt. Betrag-Satz-Besnders: Beschreibung: Summe der Brutt-Werte der Belegpsitinen des zu verarbeitenden Belegs mit dem Steuersatz Besnders. Ist keine Psitin mit diesem Steuersatz im Beleg vrhanden, s wird der Wert 0,00 eingetragen. Referenz RKSV: 9 Abs. 2 Z 4 RKSV Frmat: JSON-Frmat number mit 2 Kmmastellen. Dezimaltrennzeichen entspricht, Länge: Aufgrund des Frmats und des gegebenen Werts festgelegt. Snderfälle: Bei Standardbelegen, Strnbelegen und Trainingsbelegen entspricht der Wert dem tatsächlichem Wert. Bei Nullbelegen und dem Startbeleg wird der Wert per Definitin auf 0,00 gesetzt. Stand-Umsatz-Zaehler-AES256-ICM: Beschreibung: Hierbei handelt es sich um den verschlüsselten Umsatzzähler der jeweiligen Kasse. Für die Verarbeitung dieses Felds wird auf Przess 2.5 verwiesen. Seite 14/73

15 Referenz RKSV: 9 Abs. 2 Z 5 RKSV Frmat: JSON-Frmat string. BASE64-kdierter Wert des verschlüsselten Gesamtumsatzes. Länge: Aufgrund des Auswahl des Parameters Länge des Umsatzzählers in Przess festgelegt. Snderfälle: Startbeleg (siehe 2.2.2): Bei Startbelegen wird der Umsatzzähler auf den Wert 0 gesetzt und verschlüsselt. Strnbelege (siehe 2.2.4): Bei Strnbelegen wird anstelle des verschlüsselten Umsatzzählers der BASE64-kdierte Wert der Zeichenkette STO eingetragen. Dies entspricht der Zeichenkette U1RP. Trainingsbelege (siehe 2.2.5): Bei Trainingsbelegen wird anstelle des verschlüsselten Umsatzzählers der BASE64-kdierte Wert der Zeichenkette TRA eingetragen. Dies entspricht der Zeichenkette VFJB. Zertifikat-Seriennummer: Beschreibung: Offene Systeme: In diesem Fall wird die Seriennummer des Zertifikats eingetragen. Es wird dazu die Hexadezimal-Kdierung 2 der Seriennummer verwendet. Der Präfix 0x wird nicht angegeben. Beispiel: a431623bedf der A431623BEDF Geschlssene Systeme: Bei geschlssenen Gesamtsystemen wird der Ordnungsbegriff des Unternehmens ergänzt um die Kennung des jeweiligen ffenen Schlüssels eingetragen. Der Ordnungsbegriff des Unternehmens wird wie flgt aufbereitet: {S U G}:ID. Diese Kennung wird mit dem Trennzeichen - durch die Identifikatinsnummer des jeweiligen Schlüssels ergänzt. Dies ergibt {S U G}:ID-KID. Dabei entspricht S dem Ordnungsbegriff Steuernummer, U dem Ordnungsbegriff UID und G dem Ordnungsbegriff GLN. ID ist die jeweilige Identifikatinsnummer. KID ist die Identifikatinsnummer des Schlüssels. Im Detail ergibt sich daraus: Steuernummer Länge: immer 9 Stellen Typ: numerisch (keine Trennzeichen, Snderzeichen) Beispiel: S: UID Länge: max. 14 Stellen (abhängig vm Land) Typ: alphanumerisch (Grßbuchstaben) Beispiel: U:ATU ATU GLN Länge: immer 13 Stellen Typ: numerisch Beispiel: G: KID: Die Identifikatinsnummer des jeweiligen Schlüssels entspricht einer möglichst kurz gehaltenen Zeichenkette. Gültige Zeichen sind Kleinbuchstaben (a-z, kein ü,ö etc.), Grßbuchstaben (A-Z, kein ö,ü etc.), Ziffern (0-9). Es ergeben sich smit =62 Möglichkeiten pr Zeichen. Mit 3 Zeichen können damit bereits Schlüssel pr Unternehmen identifiziert werden. Man wird daher in der Realität in vielen Fällen bereits mit 1-2 Zeichen auskmmen. Beispiel: Gegeben kdierter Ordnungsbegriff des Unternehmens (Steuernummer): S: und Identifikatinsnummer des Schlüssels gleich A1b. 2 Hexadezimal wurde gewählt, da viele Biblitheken, die für die Verarbeitung vn Zertifikaten verwendet werden, diese Kdierung wählen. Seite 15/73

16 Damit ergibt sich für den Beleg die Zeichenkette: S: A1b Referenz RKSV: 9 Abs. 2 Z 6 RKSV Frmat: JSON-Frmat string, UTF-8 kdiert Länge: Abhängig vm Zertifikat des ZDAs bzw. des Ordnungsbegriffs des Unternehmens. Snderfälle: Bei geschlssenen Gesamtsystemen wird der jeweilige Ordnungsbegriff des Unternehmens ergänzt um die Identifikatinsnummer des Schlüssels anstelle der Seriennummer des Zertifikats verwendet. Sig-Vriger-Beleg: Beschreibung: Verkettungswert der die Bindung zum vrigen Beleg herstellt. Für die Berechnung dieses Werts wird auf Przess 2.4 verwiesen. Referenz RKSV: 9 Abs. 2 Z 7 RKSV Frmat: JSON-Frmat string, UTF-8 kdiert Länge: Vrgegeben durch die im Registrierkassenalgrithmuskennzeichen definierten Algrithmen. Snderfälle: Beim Startbeleg wird der Verkettungswert über die Kassen-ID gebildet. Beispiele Relevante Beispiele werden in den nachflgenden Przessen gezeigt. Referenzen Muster-Cde Relevante Referenzen zum Muster-Cde werden in den jeweiligen Detailprzessen genannt. Referenzen RKSV Z 4 zur Anlage der RKSV Seite 16/73

17 2.2 Verarbeitung vn Belegen Verarbeitung eines Standardbelegs Verarbeitung eines Startbelegs Verarbeitung vn Nullbelegen (z.b. Jahresbeleg, Mnatsbeleg...) Verarbeitung vn Strnbelegen Verarbeitung vn Trainingsbelegen Seite 17/73

18 2.2.1 Verarbeitung eines Standardbelegs Eingabewerte Eingabewerte für Felder laut Przess 2.1, die aus Belegdaten aufbereitet werden: Beleg-Satz-Nrmal Beleg-Satz-Ermaessigt-1 Beleg-Satz-Ermaessigt-2 Beleg-Satz-Null Beleg-Satz-Besnders Eingabewerte die aus der Kasse extrahiert werden: Felder laut Przess 2.1: Kassen-ID Belegnummer Beleg-Datum-Uhrzeit Zertifikat-Seriennummer Weitere Daten: Umsatzzähler der Kasse AES-Schlüssel der Kasse Przessbeschreibung Dieser Przess ist für die Erstellung vn Standardbelegen relevant. Werte für Felder laut Przess 2.1, die berechnet werden müssen: Stand-Umsatz-Zaehler-AES256-ICM Sig-Vriger-Beleg Es werden nun flgende Przesse durchgeführt: Aufbereiten/Aktualisieren/Verschlüsseln des Umsatzzählers: siehe Przess 2.5. Als Ergebnis der drt beschriebenen Detailprzesse erhält man den Wert des Felds Stand- Umsatz-Zaehler-AES256-ICM. Berechnung des Verkettungswerts: Für den Verkettungswert wird der vrhergehende Beleg herangezgen. Siehe Przess 2.4.2: Als Ergebnis erhält man den Wert des Felds Sig-Vriger-Beleg. Beispiele Beispiele für die unterschiedliche Behandlung der Belegtypen werden in den jeweiligen Detailprzessen gezeigt. Referenzen Muster-Cde Klasse: at.asitplus.regkassen.cre.demcashbx Methde: createstreandsignreceiptpackagewird im Zuge der Integratin der Testfälle adaptiert. Referenzen RKSV Relevante Referenzen werden bei den jeweiligen Detailprzessen genannt. Ausgabewerte Daten für die Erstellung der Signatur (Eingabewert für Przess 2.3) Seite 18/73

19 2.2.2 Verarbeitung eines Startbelegs Eingabewerte Eingabewerte für Felder laut Przess 2.1, die beim Startbeleg einen festgelegten Wert haben: Beleg-Satz-Nrmal: 0,00 Beleg-Satz-Ermaessigt-1: 0,00 Beleg-Satz-Ermaessigt-2: 0,00 Beleg-Satz-Null: 0,00 Beleg-Satz-Besnders: 0,00 Eingabewerte die aus der Kasse extrahiert werden: Felder laut Przess 2.1: Kassen-ID Belegnummer Beleg-Datum-Uhrzeit Zertifikat-Seriennummer Weitere Daten: Umsatzzähler der Kasse: Dieser ist beim Startbeleg per Definitin 0. AES-Schlüssel der Kasse Przessbeschreibung Der Startbeleg stellt den zu erstellenden ersten Beleg einer Kasse dar. Es gibt daher keinen vrigen Beleg, der für die Berechnung des Verkettungswerts herangezgen werden kann. Stattdessen wirdwir die das Feld Kassen-ID für die Berechnung verwendet. Werte für Felder laut Przess 2.1, die berechnet werden müssen: Stand-Umsatz-Zaehler-AES256-ICM Sig-Vriger-Beleg Es werden nun flgende Przesse durchgeführt: Aufbereiten/Aktualisieren/Verschlüsseln des Umsatzzählers: Der Umsatzzähler ist beim Starbeleg per Definitin 0. Siehe Przess 2.5: Als Ergebnis der drt beschriebenen Przesse erhält man den Wert des Felds Stand-Umsatz-Zaehler-AES256-ICM. Berechnung des Verkettungswerts: Für den Verkettungswert wird das Feld Kassen-ID verwendet. Siehe Przess 2.4.1: Als Ergebnis erhält man den Wert des Felds Sig- Vriger-Beleg. Beispiele Beispiele für die unterschiedliche Behandlung der Belegtypen werden in den jeweiligen Detailprzessen gegeben. Referenzen Muster-Cde Klasse: at.asitplus.regkassen.cre.demcashbx Methde: createstreandsignreceiptpackagewird im Zuge der Integratin der Testfälle adaptiert. Referenzen RKSV Relevante Referenzen werden bei den jeweiligen Detailprzessen genannt. Ausgabewerte Daten für die Erstellung der Signatur (Eingabewert für Przess 2.3) Seite 19/73

20 2.2.3 Verarbeitung vn Nullbelegen (z.b. Jahresbeleg, Mnatsbeleg...) Eingabewerte Eingabewerte für Felder laut Przess 2.1, die beim NullbelegStartbeleg einen festgelegten Wert haben: Beleg-Satz-Nrmal: 0,00 Beleg-Satz-Ermaessigt-1: 0,00 Beleg-Satz-Ermaessigt-2: 0,00 Beleg-Satz-Null: 0,00 Beleg-Satz-Besnders: 0,00 Eingabewerte die aus der Kasse extrahiert werden: Felder laut Przess 2.1: Kassen-ID Belegnummer Beleg-Datum-Uhrzeit Zertifikat-Seriennummer Weitere Daten: Umsatzzähler der Kasse AES-Schlüssel der Kasse Przessbeschreibung Die flgenden Belege entsprechen Nullbelegen: Jahresbelege bzw. alle weiteren Belege die einen bestimmten Zeitraum beschreiben und dabei keine Buchungen vrnehmen (Mnatsbelege etc.). Schlussbelege, die bei der Außerbetriebnahme einer Kasse erstellt werden. Belege die nach der Wiederinbetriebnahme einer beschädigten Sichegnaturheitseinrichtung erstellt werden. Werte für Felder laut Przess 2.1, die berechnet werden müssen: Stand-Umsatz-Zaehler-AES256-ICM Sig-Vriger-Beleg Beispiele für die unterschiedliche Behandlung der Belegtypen werden in den jeweiligen Detailprzessen gegeben. Referenzen Muster-Cde Es werden nun flgende Przesse durchgeführt: Aufbereiten/Aktualisieren des Umsatzzählers: Der Umsatzzähler der Kasse wird bei der Erstellung eines Nullbelegs nicht verändert. Verschlüsseln des Umsatzzählers: siehe Przesse 2.5.2, 2.5.3, 2.5.4, Als Ergebnis der drt beschriebenen Przesse erhält man den Wert des Felds Stand- Umsatz-Zaehler-AES256-ICM. Berechnung des Verkettungswerts: Für den Verkettungswert wird der vrhergehende Beleg herangezgen. Siehe Przess 2.4.2: Als Ergebnis erhält man den Wert des Felds Sig-Vriger-Beleg. Beispiele Klasse: at.asitplus.regkassen.cre.demcashbx Methde: createstreandsignreceiptpackagewird im Zuge der Integratin der Testfälle adaptiert. Referenzen RKSV Relevante Referenzen werden bei den jeweiligen Detailprzessen genannt. Ausgabewerte Seite 20/73

21 Daten für die Erstellung der Signatur (Eingabewert für Przess 2.3) Seite 21/73

22 2.2.4 Verarbeitung vn Strnbelegen Eingabewerte Eingabewerte für Felder laut Przess 2.1, die aus Belegdaten aufbereitet werden: Beleg-Satz-Nrmal Beleg-Satz-Ermaessigt-1 Beleg-Satz-Ermaessigt-2 Beleg-Satz-Null Beleg-Satz-Besnders Eingabewerte die aus der Kasse extrahiert werden: Felder laut Przess 2.1: Kassen-ID Belegnummer Beleg-Datum-Uhrzeit Zertifikat-Seriennummer Weitere Daten: Umsatzzähler der Kasse Przessbeschreibung Ein Strnbeleg wird erstellt, wenn einzelne der mehrere Belegpsitinen, die vrher im Rahmen der Erstellung eines Standardbelegs falsch bniert wurden, strniert werden müssen. Strnbelege dürfen nur strnierte Belegpsitinen enthalten, da andernfalls die Bezeichnung im maschinenlesbaren Cde (STO im Umsatzzähler) nicht eindeutig wäre. In den meisten Fällen werden Strnbelege negative Werte erhalten (diese Strns bewirken eine Verkleinerung des Umsatzzählers). Allerdings müssen auch negative Beträge einer Gutschrift strniert werden können. In diesem Fall wäre der strnierte Wert psitiv (diese Strns bewirken eine Vergrößerung des Umsatzzählers). Die Beträge der einzelnen Psitinen des Strnbeleges sind gleich wie beim Standardbeleg nach Steuersätzen getrennt für die Signaturerstellung und für die Ausgabe auf dem Beleg aufzubereiten. Werte für Felder laut Przess 2.1, die berechnet werden müssen: Sig-Vriger-Beleg Es werden nun flgende Przesse durchgeführt: Aufbereiten/Aktualisieren des Umsatzzählers: Dies erflgt gleich wie bei der Verarbeitung eines Standardbelegs anhand vn Przess Verschlüsselung des Umsatzzählers: Beim Strnbeleg wird anstelle des verschlüsselten Umsatzzählers die BASE64-Kdierung der Zeichenkette STO, welche der Zeichenkette U1RP entspricht, im Feld Stand-Umsatz-Zaehler-AES256-ICM ablegt. Berechnung des Verkettungswerts: Für den Verkettungswert wird der vrhergehende Beleg herangezgen. Siehe Przess Als Ergebnis erhält man den Wert des Felds Sig-Vriger-Beleg. Beispiele Beispiele für die unterschiedliche Behandlung der Belegtypen werden in den jeweiligen Detailprzessen gegeben. Referenzen Muster-Cde Klasse: at.asitplus.regkassen.cre.demcashbx Methde: createstreandsignreceiptpackagewird im Zuge der Integratin der Testfälle adaptiert. Referenzen RKSV Relevante Referenzen werden bei den jeweiligen Detailprzessen genannt. Seite 22/73

23 Ausgabewerte Daten für die Erstellung der Signatur (Eingabewert für Przess 2.3) Seite 23/73

24 2.2.5 Verarbeitung vn Trainingsbelegen Eingabewerte Eingabewerte für Felder laut Przess 2.1, die aus Belegdaten aufbereitet werden: Beleg-Satz-Nrmal Beleg-Satz-Ermaessigt-1 Beleg-Satz-Ermaessigt-2 Beleg-Satz-Null Beleg-Satz-Besnders Eingabewerte die aus der Kasse extrahiert werden: Felder laut Przess 2.1: Kassen-ID Belegnummer Beleg-Datum-Uhrzeit Zertifikat-Seriennummer Przessbeschreibung Diese Belege können zu Trainings- der Testzwecken beliebig erstellt werden hne den Umsatzzähler der Kasse zu beeinflussen. Werte für Felder laut Przess 2.1, die berechnet werden müssen: Sig-Vriger-Beleg Es werden nun flgende Przesse durchgeführt: Aufbereiten/Aktualisieren des Umsatzzählers: Der Umsatzzähler der Kasse wird vn Trainingsbelegen nicht beeinflusst. Verschlüsselung des Umsatzzählers: Beim Trainingsbeleg wird anstelle des verschlüsselten Umsatzzählers die BASE64-Kdierung der Zeichenkette TRA, welche der Zeichenkette VFJB entspricht im Feld Stand-Umsatz-Zaehler-AES256-ICM ablegt. Berechnung des Verkettungswerts: Für den Verkettungswert wir der vrhergehende Beleg herangezgen. Siehe Przess 2.4.2, als Ergebnis erhält man den Wert des Felds Sig-Vriger-Beleg. Beispiele Beispiele für die unterschiedliche Behandlung der Belegtypen werden in den jeweiligen Detailprzessen gegeben. Referenzen Muster-Cde Klasse: at.asitplus.regkassen.cre.demcashbx Methde: createstreandsignreceiptpackagewird im Zuge der Integratin der Testfälle adaptiert. Referenzen RKSV Relevante Referenzen werden bei den jeweiligen Detailprzessen genannt. Ausgabewerte Daten für die Erstellung der Signatur (Eingabewert für Przess 2.3) Seite 24/73

25 2.3 Aufbereiten der zu signierenden Daten Eingabewerte Daten für die Erstellung der Signatur (Ausgabewert je nach verarbeitetem Beleg: siehe Przess 2.2) Przessbeschreibung Die im vrigen Przess aufbereiteten Belegdaten stellen die Basis für die Erstellung der zu signierenden Daten dar, die dann anhand des JWS-Standards signiert werden. Für die Aufbereitung der zu signierenden Daten wird wie flgt vrgegangen: Zusammenfügen der Belegdaten: Die Werte, der im vrigen Schritt definierten Belegdaten, werden über das Zeichen _ zusammengefügt (Die Zeilenumbrüche wurden zur besseren Lesbarkeit eingefügt): Kassen-ID _Belegnummer _Beleg-Datum-Uhrzeit _Betrag-Satz-Nrmal _Betrag-Satz-Ermaessigt-1 _Betrag-Satz-Ermaessigt-2 _Betrag-Satz-Null _Betrag-Satz-Besnders _Stand-Umsatz-Zaehler-AES256-ICM _Zertifikat-Seriennummer _Sig-Vriger-Beleg Hinzufügen des Registrierkassenalgrithmuskennzeichen als Präfix: Die resultierende Zeichenkette wird anschließend mit dem Präfix _RKA_ ergänzt. RKA stellt in dieser Beschreibung einen Platzhalter für das Registrierkassenalgrithmuskennzeichen dar. Beispiel Standardbeleg (siehe Przess 2.2.1) Aufbereitete Daten: Kassen-ID: DEMO-CASH-BOX524 Belegnummer: AB Beleg-Datum-Uhrzeit: T11:23:43 Betrag-Satz-Nrmal: 10,50 Betrag-Satz-Ermaessigt-1: 0,00 Betrag-Satz-Ermaessigt-2: 0,00 Betrag-Satz-Null: 0,78 Betrag-Satz-Besnders: 0,00 Stand-Umsatz-Zaehler-AES256-ICM: Für das Beispiel wurde ein 8-Bytes langer Umsatzzähler verwendet. Ein Beispiel für einen möglichen Umsatzzähler in BASE64 Kdierung wäre (abhängig vn Schlüssel und Umsatzwert): Q+dTEnSc Zertifikat-Seriennummer: Bsp. Seriennummer eines Zertifikats in Hexadezimaldarstellung 245abcde Sig-Vriger-Beleg: Es wird ein Beispiel für einen möglichen Verkettungswert gegeben. Dabei entsprechen die BASE64-Kdierung und Länge einem echten Verkettungswert. Der tatsächliche Wert hängt vm vrigen Beleg ab, der für dieses Beispiel nicht angegeben wird. Bsp. Wert: OJ16FcqeA7s Aufbereitung der zu signierenden Daten Zusammenfügen der Belegdaten: (Für die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): DEMO-CASH-BOX524_366585AB _366585AB _ T11:23:43 _10,50 _0,78 _Q+dTEnSc Seite 25/73

26 _245abcde _OJ16FcqeA7s Aufbereitung der zu signierenden Daten Hinzufügen des Registrierkassenalgrithmuskennzeichen als Präfix: Zu der im vrigen Schritt erstellten Zeichenkette wird das jeweilige Registrierkassenalgrithmuskennzeichen hinzugefügt. In diesem Beispiel wird R1-AT75 verwendet. R1 entspricht dem zum Zeitpunkt der Erstellung dieses Dkuments einzig verfügbaren Kennzeichen. AT75 steht für einen fiktiven österreichischen ZDA. Daraus ergibt sich (ffür die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): _R1-AT75 _DEMO-CASH-BOX524 _366585AB _ T11:23:43 _10,50 _0,78 _Q+dTEnSc _245abcde _OJ16FcqeA7s Beispiel Startbeleg (siehe Przess 2.2.2) Aufbereitete Daten: Kassen-ID: DEMO-CASH-BOX524 Belegnummer: AB Beleg-Datum-Uhrzeit: T11:23:43 Betrag-Satz-Nrmal: beim Startbeleg per Definitin 0,00 Betrag-Satz-Ermaessigt-1: beim Startbeleg per Definitin 0,00 Betrag-Satz-Ermaessigt-2: beim Startbeleg per Definitin 0,00 Betrag-Satz-Null: beim Startbeleg per Definitin 0,00 Betrag-Satz-Besnders: beim Startbeleg per Definitin 0,00 Stand-Umsatz-Zaehler-AES256-ICM: Für das Beispiel wurde ein 8-Bytes langer Umsatzzähler verwendet, der aufgrund des Startbelegs auf 0 gesetzt wurde. Ein Beispiel für einen möglichen Umsatzzähler in BASE64 Kdierung wäre (abhängig vn Schlüssel und Umsatzwert): 5/4fWv5/uhI= Zertifikat-Seriennummer: Bsp. Seriennummer eines Zertifikats in Hexadezimaldarstellung 245abcde Sig-Vriger-Beleg: Der Verkettungswert wird beim Startbeleg anhand der Kassen-ID berechnet. Für die in diesem Beispiel verwendeten Kassen-ID mit dem Wert DEMO- CASH-BOX524 entspricht dies dem Verkettungswert: lduknheejky= Aufbereitung der zu signierenden Daten Zusammenfügen der Belegdaten: (Für die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): DEMO-CASH-BOX524_366585AB _366585AB _ T11:23:43 _5/4fWv5/uhI= _=_245abcde _lduknheejky= Aufbereitung der zu signierenden Daten Hinzufügen des Registrierkassenalgrithmuskennzeichen als Präfix: Seite 26/73

27 Zu der im vrigen Schritt erstellten Zeichenkette wird das jeweilige Registrierkassenalgrithmuskennzeichen hinzugefügt. In diesem Beispiel wird R1-AT75 verwendet. R1 entspricht dem zum Zeitpunkt der Erstellung dieses Dkuments einzig verfügbaren Kennzeichen. AT75 steht für einen fiktiven österreichischen ZDA. Daraus ergibt sich (für die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): _R1-AT75 _DEMO-CASH-BOX524_366585AB _366585AB _ T11:23:43 _5/4fWv5/uhI= _=_245abcde _lduknheejky= Beispiel Nullbeleg (siehe Przess 2.2.3) Aufbereitete Daten: Kassen-ID: DEMO-CASH-BOX524 Belegnummer: AB Beleg-Datum-Uhrzeit: T11:23:43 Betrag-Satz-Nrmal: beim Nullbeleg per Definitin 0,00 Betrag-Satz-Ermaessigt-1: beim Nullbeleg per Definitin 0,00 Betrag-Satz-Ermaessigt-2: beim Nullbeleg per Definitin 0,00 Betrag-Satz-Null: beim Nullbeleg per Definitin 0,00 Betrag-Satz-Besnders: beim Nullbeleg per Definitin 0,00 Stand-Umsatz-Zaehler-AES256-ICM: Für das Beispiel wurde ein 8-Bytes langer Umsatzzähler verwendet. Ein Beispiel für einen möglichen Umsatzzähler in BASE64 Kdierung wäre (abhängig vn Schlüssel und Umsatzwert): Q+dTEnSc Zertifikat-Seriennummer: Bsp. Seriennummer eines Zertifikats in Hexadezimaldarstellung 245abcde Sig-Vriger-Beleg: Es wird ein Beispiel für einen möglichen Verkettungswert gegeben. Dabei entsprechen die BASE64-Kdierung und Länge einem echten Verkettungswert. Der tatsächliche Wert hängt vm vrigen Beleg ab, der für dieses Beispiel nicht angegeben wird. Bsp. Wert: OJ16FcqeA7s Aufbereitung der zu signierenden Daten Zusammenfügen der Belegdaten: (Für die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): DEMO-CASH-BOX524_366585AB _366585AB _ T11:23:43 _Q+dTEnSc _245abcde _OJ16FcqeA7s Aufbereitung der zu signierenden Daten Hinzufügen des Registrierkassenalgrithmuskennzeichen als Präfix: Zu der im vrigen Schritt erstellten Zeichenkette wird das jeweilige Registrierkassenalgrithmuskennzeichen hinzugefügt. In diesem Beispiel wird R1-AT75 verwendet. R1 entspricht dem zum Zeitpunkt der Erstellung dieses Dkuments einzig verfügbaren Kennzeichen. AT75 steht für einen fiktiven österreichischen ZDA. Daraus ergibt sich (ffür die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): Seite 27/73

28 _R1-AT75 _DEMO-CASH-BOX524 _366585AB _ T11:23:43 _Q+dTEnSc _245abcde _OJ16FcqeA7s Beispiel Strnbeleg (siehe Przess 2.2.4) Aufbereitete Daten: Kassen-ID: DEMO-CASH-BOX524 Belegnummer: AB Beleg-Datum-Uhrzeit: T11:23:43 Betrag-Satz-Nrmal: beim Startbeleg per Definitin -5,00 Betrag-Satz-Ermaessigt-1: beim Startbeleg per Definitin 0,00 Betrag-Satz-Ermaessigt-2: beim Startbeleg per Definitin 0,00 Betrag-Satz-Null: beim Startbeleg per Definitin 0,00 Betrag-Satz-Besnders: beim Startbeleg per Definitin 0,00 Stand-Umsatz-Zaehler-AES256-ICM: Beim Strnbeleg wird der Umsatzzähler in der Kasse adaptiert, der verschlüsselter Wert wird aber nicht im Beleg gespeichert. Stattdessen wird der Wert U1RP (Ergebnis BASE64-Kdierung STO) im Feld gespeichert. Zertifikat-Seriennummer: Bsp. Seriennummer eines Zertifikats in Hexadezimaldarstellung 245abcde Sig-Vriger-Beleg: Es wird ein Beispiel für einen möglichen Verkettungswert gegeben. Dabei entsprechen die BASE64-Kdierung und Länge einem echten Verkettungswert. Der tatsächliche Wert hängt vm vrigen Beleg ab, der für dieses Beispiel nicht angegeben wird. Bsp. Wert: OJ16FcqeA7s Aufbereitung der zu signierenden Daten Zusammenfügen der Belegdaten: (Für die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): DEMO-CASH-BOX524_366585AB _366585AB _ T11:23:43 _-5,00 _U1RP _245abcde _OJ16FcqeA7s Aufbereitung der zu signierenden Daten Hinzufügen des Registrierkassenalgrithmuskennzeichen als Präfix: Zu der im vrigen Schritt erstellten Zeichenkette wird das jeweilige Registrierkassenalgrithmuskennzeichen hinzugefügt. In diesem Beispiel wird R1-AT75 verwendet. R1 entspricht dem zum Zeitpunkt der Erstellung dieses Dkuments einzig verfügbaren Kennzeichen. AT75 steht für einen fiktiven österreichischen ZDA. Daraus ergibt sich (ffür die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): _R1-AT75 _DEMO-CASH-BOX524 _366585AB _ T11:23:43 _-5,00 Seite 28/73

29 _U1RP _245abcde _OJ16FcqeA7s Beispiel Trainingsbeleg (siehe Przess 2.2.5) Aufbereitete Daten: Kassen-ID: DEMO-CASH-BOX524 Belegnummer: AB Beleg-Datum-Uhrzeit: T11:23:43 Betrag-Satz-Nrmal: 5,00beim Startbeleg per Definitin 5,00 Betrag-Satz-Ermaessigt-1: beim Startbeleg per Definitin 0,00 Betrag-Satz-Ermaessigt-2: beim Startbeleg per Definitin 9,00 Betrag-Satz-Null: beim Startbeleg per Definitin 13,30 Betrag-Satz-Besnders: beim Startbeleg per Definitin 0,00 Stand-Umsatz-Zaehler-AES256-ICM: Beim Trainingsbeleg wird weder der Umsatzzähler der Kasse adaptiert, nch ein verschlüsselter Wert im Beleg abgelegt. Stattdessen wird der Wert VFJB (Ergebnis BASE64-Kdierung TRA) im Feld gespeichert. Zertifikat-Seriennummer: Bsp. Seriennummer eines Zertifikats in Hexadezimaldarstellung 245abcde Sig-Vriger-Beleg: Es wird ein Beispiel für einen möglichen Verkettungswert gegeben. Dabei entsprechen die BASE64-Kdierung und Länge einem echten Verkettungswert. Der tatsächliche Wert hängt vm vrigen Beleg ab, der für dieses Beispiel nicht angegeben wird. Bsp. Wert: OJ16FcqeA7s Aufbereitung der zu signierenden Daten Zusammenfügen der Belegdaten: (Für die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): DEMO-CASH-BOX524_366585AB _366585AB _ T11:23:43 _5,00 _9,00 _13,30 _VFJB _245abcde _OJ16FcqeA7s Aufbereitung der zu signierenden Daten Hinzufügen des Registrierkassenalgrithmuskennzeichen als Präfix: Zu der im vrigen Schritt erstellten Zeichenkette wird das jeweilige Registrierkassenalgrithmuskennzeichen hinzugefügt. In diesem Beispiel wird R1-AT75 verwendet. R1 entspricht dem zum Zeitpunkt der Erstellung dieses Dkuments einzig verfügbaren Kennzeichen. AT75 steht für einen fiktiven österreichischen ZDA. Daraus ergibt sich (ffür die bessere Lesbarkeit wurden Zeilenumbrüche eingefügt): _R1-AT75 _DEMO-CASH-BOX524 _366585AB _ T11:23:43 _5,00 _9,00 _13,30 _VFJB _245abcde _OJ16FcqeA7s Seite 29/73

30 Referenzen Muster-Cde Aufbereitung der zu signierenden Daten Klasse: at.asitplus.regkassen.cre.base.receiptdata. ReceiptRepresentatinFrSignature tinfrsignature.java Methde: getdatatbesigned Referenzen RKSV Z 5 zur Anlage der RKSV Ausgabewerte Aufbereitete Daten für die Erstellung der Signatur anhand des JWS-Standards (Eingabewert für Przess 3). Seite 30/73