FAQ

Hier finden Sie Antworten auf 18 häufig gestellte Fragen rund um SIGN AT, organisiert nach Themenbereichen.

Quittungen (6)

Welche Daten müssen auf einem österreichischen Kassenbeleg abgebildet sein?

Gemäß RKSV (Registrierkassensicherungsverordnung) müssen zumindest folgende Angaben auf dem Kassenbeleg abgebildet werden:

• Kassenidentifikationsnummer - (entspricht dem Feld cash_register_serial_number)

Datum und Uhrzeit der Belegausstellung - (entspricht dem Feld time_signature)

Betrag der Barzahlung getrennt nach Steuersätzen - (entspricht je nach Steuersatz z.B. dem Feld gross_amount_standard)

Inhalt des maschinenlesbaren Code - (entspricht dem Feld qr_code_data)

Alle diese Daten kommen direkt über die SIGN AT API und sind am folgenden Beispielbeleg anschaulich gekennzeichnet:

Zusätzlich dazu sollten gemäß § 132a (3) BAO auch folgende Angaben abgebildet werden:

• Eine eindeutige Bezeichnung des liefernden oder leistenden Unternehmens

• Eine fortlaufende Nummer mit einer oder mehreren Zahlenreihen, die zur Identifizierung des Geschäftsvorfalls einmalig vergeben wird

• Tag der Belegausstellung

• Menge und die handelsübliche Bezeichnung der gelieferten Gegenstände bzw. Art und Umfang der Dienstleistungen

• Betrag der Barzahlung

 

Bitte beachten Sie: fiskaly darf keine steuerrechtliche Beratung anbieten. Kontaktieren Sie bitte Ihren Steuerberater, Wirtschaftsprüfer oder Anwalt für steuerrechtliche Fragen.

Welche Bedeutung hat der receipt_type DECOMMISSION?

Der receipt_type “DECOMMISSION” wird seitens fiskaly erstellt, nachdem eine Kasse stillgelegt, also in den Status DECOMMISSIONED, gesetzt wurde.  Hat eine Kasse das Ende ihrer Nutzungsdauer erreicht muss dies erkenntlich gemacht werden, indem sie auf DECOMMISSIONED gesetzt wird. Durch diese Stilllegung der Kasse wird ein sogenannter “Schlussbeleg” erstellt und es erfolgt eine Mitteilung an FinanzOnline (FON) über die Stilllegung der Kasse.

Was ist ein Nullbeleg und wann wird dieser erstellt?

Ein Nullbeleg ist ein Beleg ohne Artikel mit der Summe null (0) und kann im Zuge einer Prüfung verlangt werden.

Dieser Beleg muss wie jeder andere signiert und ausgedruckt werden.

Als receipt_type sollte "NORMAL" verwendet werden.

Woher kommen die Beleg-Typen (receipt_type) MONTHLY_CLOSE und YEARLY_CLOSE?

In den List-Endpunkten der SIGN AT API (listAllReceipts und listReceipts) kann über Query-Parameter nach unterschiedlichen Beleg-Typen (receipt_type) gefiltert werden. 

Monatsbelege (MONTHLY_CLOSE) und Jahresbelege (YEARLY_CLOSE) werden automatisiert erzeugt. 

Sobald eine neue Transaktion erstellt wird, prüft das System das Datum der vorherigen Transaktion, und im Falle einer Abweichung von Monat/Jahr wird vor der Transaktion ein MONTHLY_CLOSE/YEARLY_CLOSE Beleg erstellt.

Wie kann ich einen Beleg (receipt) stornieren?

Ein SIGN AT receipt (Beleg) besitzt keinen Status und kann daher nicht abgebrochen werden.

Im Falle eines Fehlers oder einer falschen Eingabe bei einem Beleg kann der Prozess mittels Stornobeleg korrigiert werden.

Ein Beispiel: Wird in der Kasse eine fehlerhafte Summe von 500 Euro eingegeben, so sollte ein Beleg*** ***des Typs CANCELLATION mit der Bruttosumme von -500 erstellt werden. Dies korrigiert den zuvor fälschlich ausgestellten Beleg. Danach kann der korrekte Beleg erstellt werden.

 

Was ist der Unterschied zwischen den Kassenbon-Schemas?

ekabs_v0 adaptiert den deutschen Standard für elektronische Kassenbelege EKaBS (Einheitlicher Standard für elektronische Kassenbelege) für die österreichischen Gesetze.

standard_v1 ist besonders praktisch für KundInnen, die auch unsere Lösung für Deutschland verwenden, da es mit standard_v1 Schema der SIGN DE kompatibel ist.

raw enthält das Minimum an Kassenbon-Daten, die für die Signatur benötigt werden.

Exporte (2)

Was ist ein DEP7 Export und wann sollte dieser angestoßen werden?

Das sogenannte DEP7 (Datenerfassungsprotokoll gemäß § 7 RKSV) ist eine Protokolldatei, in der alle Transaktionen und der Inhalt der Belege in Echtzeit, bei jeder Belegerstellung, in fortlaufender Reihenfolge aufgezeichnet werden.

 

DEP7 Exporte können über den Endpunkt exportCashRegister der SIGN AT API getriggert werden. DEP7 Exporte werden im Zuge einer Prüfung verlangt.

 

DEP7 Exporte werden nicht automatisch erstellt. Wir empfehlen diesen Export mindestens einmal alle 3 Monate anzustoßen.

Wann muss ich einen DEP7 (RKSV-Datenerfassungsprotokol) Export erstellen?

Während einer Steuerprüfung, wenn der Steuerprüfer diesen verlangt.

Allgemein (3)

Warum erhalte ich auf die gleichen Anfragen immer die gleiche Antwort?

Die fiskaly fiskaly SIGN AT API ist idempotent. Idempotenz bedeutet, dass Sie die gleiche Anfrage mehrmals ohne Bedenken senden können. Das Ergebnis wird dasselbe sein, als wenn Sie es nur einmal gesendet hätten.

Wenn Sie z. B. eine Quittung signieren wollen, aber keine Antwort erhalten, können Sie die Anforderung mit demselben Request-Body erneut senden. Die Quittung wird so garantiert nur einmal signiert.

LIVE vs. TEST Umgebung

SIGN AT bietet zwei verschiedene Umgebungen: test und live.

 

Die live Umgebung muss für die Produktionsumgebung verwendet werden. Wenn sich Ihr System in der live Umgebung befindet, werden echte Zertifikate erstellt und Berichte werden auch tatsächlich an das Finanzamt (FON) übermittelt.

Die in der live Umgebung erstellten Zertifikate sind kostenpflichtig und Berichte an die Finanzbehörden sind amtlich (!).

 

Die test Umgebung ermöglicht Ihnen, Ihre Integration in einem simulierten Umfeld zu testen. Die API verhält sich hierbei gleich wie in der live Umgebung, es werden jedoch keine echten Ressourcen angelegt. Drittanbieter-Systeme werden durch Testinstanzen (Fake-Implementierungen) ersetzt. Sie können somit in Ihr System in einer sicheren Umgebung testen, ohne das Risiko einzugehen falsche Berichte zu versenden oder Zertifikat in Rechnung gestellt zu bekommen.

Müssen Kunden immer eine Quittung erhalten?

Ja, Kunden sollten immer eine Quittung erhalten. Folgende Fälle sind außerdem zu beachten:

• Wenn fiskaly von der Kasse (PoS=Point of Sale) erreicht werden kann und fiskaly sich mit dem Trusted Service Provider verbinden kann, erhält der Kunde eine signierte Quittung. 

• Sollte fiskaly von dem PoS aus erreichbar sein, es fiskaly jedoch nicht möglich ist sich mit dem trust service provider zu verbinden, so erhält der Kunde eine Quittung mit einer Ersatz-Signatur.

• Sollte fiskaly von dem PoS aus nicht erreichbar sein, so muss der Kunde eine unsignierte Quittung erhalten.

Signaturerstellungseinheiten (2)

Welche Validierung erfolgt bei der Erstellung einer SCU (Signature Creation Unit)?

Beim Erstellen einer SCU wird die VAT ID mittels VIES VAT number validation verifiziert. Andere Werte werden syntaktisch mittels regular expressions oder ähnlichen Mechanismen überprüft.

Wie viele SCUs (Signature Creation Units) kann eine (verwaltete) Organisation haben?

Es ist nicht möglich mehr als eine SCU pro (verwalteter) Organisation zu erstellen.

Authentifizierung (1)

Benötige ich einen FON (FinanzOnline) Login für die Testumgebung?

In der TEST-Umgebung der SIGN AT API (RKSV), benötigen Sie keinen speziellen FON (FinanzOnline) Account, da die Kommunikation zwischen FON und fiskaly hier nur simuliert wird.

In den Feldern fon_participant_id, fon_user_id, fon_user_pin können beliebige Daten angegeben werden, diese werden nicht gegen FON (FinanzOnline) validiert. 

Bitte lesen Sie dazu auch unseren Artikel über die Unterschiede zwischen der LIVE- und der TEST-Umgebung.

FON (1)

Was ist FON?

FinanzOnline (FON) ist das offizielle Informationssystem, das vom österreichischen “Finanzamt” zur Verfügung gestellt wird.

Viele Aktionen im Kontext der RKSV benötigen die Erstellung und den korrekten Transfer zu FON.

fiskaly bietet mit seiner SIGN AT Lösung eine Vereinfachung dieser Aktionen durch die direkte Verbindung zum FON.

Fehler und Statuscodes (2)

Was passiert wenn die SIGN AT API nicht erreichbar ist?

Da wir das Archiv DEP7 zur Verfügung stellen und somit Teil der Registrierkasse sind, (inkl. turnover counter, receipt numbers, etc.)  können Sie diesen Fall als Ausfall der Registrierkasse selbst betrachten. Die folgenden Szenarien sind daher zu betrachten:

• Versuch die Quittung zu fiskalisieren

• Fiskalisierung fehlgeschlagen (z.B. Fehlermeldung 5xx als Antwort empfangen, API unerreichbar, …)

• Anfrage lokal abspeichern (request payload inklusive der UUID vom receipt (!) ) 

• Erstellen Sie für den Kunden einen Kassenbon auf dem die Kassenbon-Nummer und die Registrierkassen ID fehlen. Vermerken Sie jedoch stattdessen Sicherheitseinrichtung ausgefallen auf dem Kassenbon und fügen Sie zusätzlich auch einen QR-Code mit dieser Information hinzu.

• Bewahren Sie eine Kopie des Kassenbons auf.

Wenn die Verbindung zu SIGN AT wieder aufgebaut werden kann, kann eine Nacherfassung mit den receipt UUIDs der originalen Kassenbons erfolgen. Dadurch wird sichergestellt, dass Sie nicht versehentlich Belege doppelt fiskalisieren.

Da es in einem solchen Szenario nicht unwahrscheinlich ist, dass viele Belege in der Warteschlange landen, während neue Transaktionen erfolgen, können Sie die Nacherfassung auch beispielsweise am Ende einer Schicht durchführen.

Was passiert, wenn der Trust Service Provider (TSP) fiskaly keine Signaturen zur Verfügung stellen kann?

Wenn SIGN AT keine Signaturen des certified trust service provider (TSP) anfragen kann werden die Kassenbons mittels einer Ersatz-Signatur signiert. Die Kassenbons müssen dann den Hinweis  Sicherheitseinrichtung ausgefallen  enthalten. Diese Kassenbons sind gültig und im DEP7 Export beinhaltet. Wenn der TSP wieder erreichbar ist, dann erstellt SIGN AT automatisch einen Null-Summen Kassenbon, der das Ende des Ausfalls markiert.

Registrierkassen (1)

Wie viele Cash Registers (Kassen) können einer SCU (Signature Creation Unit) zugeordnet werden?

Die Anzahl der Cash Registers pro SCU ist nicht beschränkt.