Prüftool PASS - FON Fail - Bei Startbeleg

[rksvHackler]

Interessanterweise gibt es immer wieder Startbelege, die vollkommen unerklärlicherweise vom FON Service abgelehnt werden. Ein Gegencheck mit dem Prüftool ergibt keine Probleme.

Der Vorgang ist folgender: (vielleicht ist der ja relevant und mir fehlt der größere Zusammenhang, jedenfalls passiert das alles direkt hintereinander) FON: Abfrage: Status Kasse mit KassenId => B32 (nicht registriert) daraufhin: Registrierung Kasse mit KassenId und Benutzerschlüssel => 0 (OK) Abfrage Status See mit Seriennummer => IN_BETRIEB Belegprüfung mit Startbeleg => FAIL (43) VerificationResult Id List: VERIFICATION_FROM_CASHBOX (FAIL) -RECEIPT_FULL (FAIL) --TYPE_OF_RECEIPT (FAIL) ---TYPE_OF_RECEIPT_START (FAIL) ---TYPE_OF_RECEIPT_STANDARD (FAIL) ---TYPE_OF_RECEIPT_TRA (FAIL) ---TYPE_OF_RECEIPT_STO (FAIL) ---TYPE_OF_RECEIPT_NULL (FAIL)

Wie gesagt, das Prüftool sagt OK zum dem Beleg... (sollte ein FON Mitarbeiter mitlesen, Die Session Id war kwtfbEdwBnL050fWzaiKqWmE)

Beim TypeOfReceiptStart steht noch dabei (ich fürchte aber, das ist ein Standardtext)

Verkettung mit Kassenidentifikationsnummer / Umsatzzähler = 0,00 / Belegbeträge = 0,00 / Signatur-Siegelerstellungseinheit nicht ausgefallen

Hat jemand vielleicht eine Idee zu diesem Thema?

[ErichFreitag]

Darauf schauen, wo die Unterschiede zwischen Prüftool und übermittelten Belegdaten sind. AES-Schlüssel, Fehler im QR-Code, ...

[rksvHackler]

Ich hab das erneut exakt geprüft. im 0000_cashbox_full.json finde ich nach einer QR-Code Prüfung

    "verificationId" : "TYPE_OF_RECEIPT_START",
    "version" : 1,
    "verificationName" : "Belegtyp: Startbeleg",
    "verificationTextualDescription" : "Es werden folgende Eigenschaften überprüft: Entschlüsselter Umsatzzähler gleich 0, Verkettungswert zeigt auf die Kassen-ID, alle Werte der Steuersätze sind 0, Signatureinrichtung darf nicht ausgefallen sein.",
    "verificationState" : "PASS",
    "verificationTimestamp" : "2017-03-30T16:37:29.266+02:00"

Etwas was ich Online nicht finden kann. Und ja, AES-Schlüssel und QR-Code wurden aus den XML Logs der FON Kommunikation exakt herauskopiert. Ist mir unverständlich :-(

[ErichFreitag]

Welches Prüftool verwenden sie - das für das DEP oder für die Belege?

Schauen sie systematisch nach. Irgendwo muss der Fehler sein.

Liefern beide Prüftools OK? Das DEP-Export-Format ist geringfügig anders als der QR-Code.

Scannen sie den QR-Code und prüfen sie den gescannten Text. Manchmal gibt es in der Grafik Fehler.

Nehmen sie einen neuen AES-Schlüssel und gehen von diesem, nicht von Logs aus.

Haben sie nicht-sichtbare Sonderzeichen in den übermittelten Daten? Schauen sie sich das mit einem Editor an, der auch alle Sonderzeichen darstellen kann.

[rksvHackler]

Prüftool in erster Linie das QR Tool, da ja auch die FON Schnittstelle genau diesen Text verlangt.

java -jar regkassen-verification-receipts-1.0.0.jar -v -f -i qr-code-rep.json -c cryptographicMaterialContainer.json -o result

Auch eine DEP-Format wurde mittlerweile zur Kontrolle durchgeführt. Und ja, auch im DEP-Format funktionierts. Ich gehe nur von dem String aus, der im FON Webservice übermittelt wird. Also keine Grafik im Spiel. Ein neuer AES-Schlüssel würde eine neue Inbetriebnahme bedingen, was mich weg führt vom aktuellen Problem und in der Masse für mehrere Kunden kaum tragbar ist. Der AES-Schlüssel wurde auch 1:1 kopiert. Auch das mit den Sonderzeichen hab ich kontrolliert. Die Logs sind auch nicht die von irgendeiner Kasse, sondern von der XML-Basierten SOAP Kommunikation mit dem FON Webservice.

[ErichFreitag]

Ich denke nur laut, was mir einfällt was anders sein könnte.

Haben sie den AES-Schlüssel aus dem Log oder aus dem tatsächlichen Eintrag in Finanz-Online? Haben sie den AES-Schlüssel in Finanz-Online mit Prüfziffer ausprobiert?

Posten sie bitte mal die gesamte Fehlermeldung.

Welchen Status hat die Kasse tatsächlich in Finanz-Online?

Es gibt hier im Forum auch einige Einträge, sie sich auf wenn auch nur geringfügige Zeitdifferenzen beziehen, die ich aber im Detail nicht nachverfolgt habe. Lesen sie da mal nach.

[rksvHackler]

Ich bin Ihnen auch recht dankbar für die Inputs und verfolge alle weiter. Ein Anruf bei der FON-Hotline ergab dass der Status der Kasse registriert aber ohne Startbeleg ist. (Exakt das was die FON Webservice Aufrufe auch zurückgeben). Der Herr dort hat mich an die Email Hotline verwiesen (mal sehen ,was dort rauskommt) Den AES-Schlüssel habe ich aus dem Log, genau von dort, die Registrierung der Kasse mit einem positiven ErrorCode (0) bestätigt wird. Mit den RK-Webservice Credentials kann man ja nicht den Schlüssel einsehen. (wir werden das morgen mit dem Kunden prüfen)

Ein Muster, das über mehrere Kunden auftaucht, ist dass wenn eine Kasse mehrfach ab und angemeldet wird, ab dem dritten Startbeleg eine Inbetriebnahme unwahrscheinlich bis unmöglich wird.

Anbei der erneute Versuch der Aktivierung heute. github.txt

Den Beleg möchte ich hier nicht posten, sende ihn Ihnen ggf. gerne zu.

[ErichFreitag]

Sie können sich auch pro Kunden einen FON-Zugang, der read-only ist, anlegen/freischalten lassen. Dann sehen sie den Kassenstatus, können aber nichts verändern. Das hilft zumindest beim Nachsehen.

Es mag sein, dass es ein Muster bei der Anmeldung etc. gibt - ich hatte heute auch einen seltsamen Fall. Ihr Prüfergebnis deutet aber nicht darauf hin, sondern auf einen nicht erkannten Startbeleg. Da ist die Verkettung ein Thema (unwahrscheinlich wenn nur manchmal und auch, weil nicht als Standardbeleg erkannt), die einzelnen Beträge (alle 0), der Umsatzzähler (Null und ein korrekter AES-Schlüssel) und Signaturerstellungseinheit nicht ausgefallen.

Im Moment kann ich nur vorschlagen, beim AES-Schlüssel hartnäckig zu sein, eventuell auch mit dem Prüfwert.

[rksvHackler]

Aus Verzweiflung :-) wurde jetzt die Kasse abgemeldet, der AES Schlüssel geändert und danach wieder neu begonnen. Jetzt akzeptiert die Finanz den Startbeleg. Obwohl das konkrete Problem gelöst ist, ist da irgendwo der Wurm drinnen. Und aus meiner Sicht auf Seite der Finanzonline Webservices.

[Phoniexk]

sollte ein FON Mitarbeiter mitlesen

Selbst wenn die mitlesen, wirds hier keinen Support geben. Ich weiß nicht warum fast niemand das WKO-Kassenforum kennt: im WKO-Forum der "UBIT" gibt es Rubriken für das FON-Webservice (man muss sich freischalten lassen von der ubit), dort gibt das BMF (FON-Mitarbeiter) direkten Support für solche Probleme. Dort mit der jeweiligen Session-ID posten und sie bekommen eine klare Aussage warum es nicht funktioniert.

Auf de Hotline hat es gar keinen Sinn, dort ist nur First Level Support. Email dauert viel zu lange. Dort gehts meistens innerhalb von einem Werktag.

[SEHellFire]

Selbes Problem (Fehler 43) gibt es scheinbar noch immer.

Der Fehlertext meckert den "Status der Kasse" an. Die Kassenregistrierung meldet [B1]: Ist bereits registriert.

Hier die Rückmeldung aus FON (FAIL FinanzOnline (2018-02-08T11:15:26) ):

ERROR:[43] Der übermittelte Beleg ist fehlerhaft. <Prüfergebnis - Kasse> Der vorliegende Startbeleg passt nicht zum aktuellen Stand der Registrierung Ihrer Registrierkasse im FinanzOnline. Für eine erfolgreiche Startbelegprüfung verwenden Sie bitte den korrekten Startbeleg oder erstellen Sie einen Neuen. Bei der Belegprüfung wird untersucht, ob die Vorgaben der RKSV in Bezug auf den maschinenlesbaren Code am Beleg und auf die meldepflichtigen Metadaten der Sicherheitseinrichtung befolgt werden. Im Fehlerfall sind die genauen Fehlerinformationen nachfolgend angeführt. <Detailprüfung des maschinenlesbaren Codes>

Dieses Modul und die dazugehörigen Submodule überprüfen die Gültigkeit des Belegs. Dabei werden sowohl Formatprüfungen, kryptographische Prüfungen (verschlüsselter Umsatzzähler, Signatur) als auch Prüfungen im Zusammenhang mit dem Status der Kasse bzw. der Signatur-/Siegelerstellungseinheit durchgeführt. <Statusprüfung der Kasse und Signatur-/Siegelerstellungseinheit>

In diesem Modul und den dazugehörigen Submodulen werden die Zustände der Kasse und der verwendeten Signatur-/Siegelerstellungseinheit und die Ergebnisse der zuvor durchgeführten Prüfungen (vor allem der Belegtyp) ausgewertet. Handelt es sich um einen Startbeleg, wird überprüft ob eine Inbetriebnahme der Kasse möglich ist. <Statusprüfung der Kasse> Bei der Überprüfung des Status der Kasse zum Belegerstellungszeitpunkt bzw. Prüfzeitpunkt wurde ein Fehler festgestellt. Es wird der Status der Kasse zum Belegerstellungszeitpunkt und zum Prüfzeitpunkt ausgewertet. Die extrahierten Informationen werden im Zusammenhang mit weiteren Beleginformationen betrachtet.

[Phoniexk]

Die Fehlermeldung ist eindeutig

Der vorliegende Startbeleg passt nicht zum aktuellen Stand der Registrierung Ihrer Registrierkasse im FinanzOnline.

Was sagt FinanzOnline zum aktuellen Status der Kasse?

EDIT: Auch die zeitliche Abfolge (bzw. das angegebene Datum/Uhrzeit) nochmal kontrollieren.

[SEHellFire]

Als Registrierkasse habe ich nur die Logindaten für den Registrierkassenbenutzer.

Schön wäre ja gewesen wenn der Kassenstatus in der Fehlermeldung steht. Oder wenn in der Fehlermeldung wenigstens stehen würde was am Kassenstatus nicht stimmt.

Die Kasse wurde ein paar Sekunden vor der Belegerstellung registriert. Meiner Erfahrung nach einfach ein bisschen zu kurz vor der Uhrzeit, die nun im Beleg drinnen steht.

In das FinanzOnline kann ich leider momentan nicht schauen.

[SEHellFire]

Habe den selben Beleg nochmal versucht - selber Fehler.

Dann nun eine Totalnullstellung gefahren und einen neuen Startbeleg erzeugt und den getestet. Selber Fehler:

Jetzt Belege prüfen:

Backup_BEL_V5\RKSV_Beleg_000000000001.txt Prüfmodus: Live Belegname: Startbeleg Belegnummer: 1 BelegDatumZeit: 2018-02-08T11:50:57 Prüfergebnis: FAIL FinanzOnline (2018-02-08T11:51:14) ERROR:[43] Der übermittelte Beleg ist fehlerhaft. <Prüfergebnis - Kasse> Der vorliegende Startbeleg passt nicht zum aktuellen Stand der Registrierung Ihrer Registrierkasse im FinanzOnline. Für eine erfolgreiche Startbelegprüfung verwenden Sie bitte den korrekten Startbeleg oder erstellen Sie einen Neuen. Bei der Belegprüfung wird untersucht, ob die Vorgaben der RKSV in Bezug auf den maschinenlesbaren Code am Beleg und auf die meldepflichtigen Metadaten der Sicherheitseinrichtung befolgt werden. Im Fehlerfall sind die genauen Fehlerinformationen nachfolgend angeführt. <Detailprüfung des maschinenlesbaren Codes>

Dieses Modul und die dazugehörigen Submodule überprüfen die Gültigkeit des Belegs. Dabei werden sowohl Formatprüfungen, kryptographische Prüfungen (verschlüsselter Umsatzzähler, Signatur) als auch Prüfungen im Zusammenhang mit dem Status der Kasse bzw. der Signatur-/Siegelerstellungseinheit durchgeführt. <Statusprüfung der Kasse und Signatur-/Siegelerstellungseinheit>

In diesem Modul und den dazugehörigen Submodulen werden die Zustände der Kasse und der verwendeten Signatur-/Siegelerstellungseinheit und die Ergebnisse der zuvor durchgeführten Prüfungen (vor allem der Belegtyp) ausgewertet. Handelt es sich um einen Startbeleg, wird überprüft ob eine Inbetriebnahme der Kasse möglich ist. <Statusprüfung der Kasse> Bei der Überprüfung des Status der Kasse zum Belegerstellungszeitpunkt bzw. Prüfzeitpunkt wurde ein Fehler festgestellt. Es wird der Status der Kasse zum Belegerstellungszeitpunkt und zum Prüfzeitpunkt ausgewertet. Die extrahierten Informationen werden im Zusammenhang mit weiteren Beleginformationen betrachtet.

--- Fertig, mit Fehlern! ---

[Phoniexk]

Seite 8 - Statusabfrage einer Registrierkasse: https://www.bmf.gv.at/egovernment/fon/fuer-softwarehersteller/BMF_Registrierkassen_Webservice.pdf?67rvm4

Dort sieht man dann auch zu welchem Zeitpunkt welcher Status gesetzt wurde. Für die SEE gibt es ebenfalls eine Statusabfrage.

[rksvHackler]

Ich habs auf die harte Tour im letzten Jahr so gelernt: Es darf grundsätzlich pro "Lebensdauer" der Registrierkasse nur einen Startbeleg geben darf. Und dieser muss (Belegdatum) auch dort drinnen liegen. Die Lebensdauer beginnt mit der Registrierung und endet mit der Außerbetriebnahme. Das gilt für jede Außerbetriebnahme und Wiederanmeldung. Ausnahmen gibts nur für die erste Inbetriebnahme. Da ist das Startbelegsdatum relativ egal. Das Hauptproblem ist, wenn FON den Startbeleg entsprechend oben ablehnt, dann sagt es uns nicht genau, ob für die Lebensdauer bereits ein Startbeleg existiert, oder ob der neue Beleg aus anderen Gründen abgelehnt wird (außerhalb der Lebensdauer, AKA nicht angemeldet, schon abgemeldet,...)

[Phoniexk]

@rksvHackler: Das Verhalten bezüglich "Lebensdauer" ist per Definition aber auch so zu erwarten.

Aber ja, nur aus der Fehlermeldung wird man nicht schlau. Entweder den Status via Webservice abfragen und wenn das keine Erkenntnis bringt, hilft nur der Blick ins FinanzOnline.

[SEHellFire]

Habe das mit dem status mal versucht zu implementieren:

ERROR:-1 Beim Generieren des XML-Dokuments ist ein Fehler aufgetreten. Der Typ RKSV.at.gv.bmf.finanzonline.status_kasse wurde nicht erwartet. Verwenden Sie das XmlInclude- oder das SoapInclude-Attribut, um Typen anzugeben, die nicht statisch sind.

Einen Tipp was ich ändern muss?

[Phoniexk]

Ist jetzt so ohne mehr Info / Code schwer zu sagen. Möglicherweise hast du übersehen, dass die Statusabfrage eine andere Auswahl als bei den bisherigen Requests benötigt.

https://finanzonline.bmf.gv.at/fonws/ws/regKasseWs.xsd

root-element "rkdbRequest" :

Bisher wurde alles unter "rkdb" übermittelt, jetzt wird "status_kasse" benötigt.

[AxelKutschera]

@rksvHackler zu "Ausnahmen gibts nur für die erste Inbetriebnahme. Da ist das Startbelegsdatum relativ egal." Achtung: Da gibt es nach RKSV die Meldefrist von einer Woche.

[SEHellFire]

Habe eine Rückmeldung:

IN_BETRIEB , registrierung 08.02.2018 10:26:01 , status 08.02.2018 10:27:04

[SEHellFire]

Insgesamt passt es also nicht wirklich zusammen:

Kassenstatus von ID V5:

PASS: [0] Kassenstatus für ID V5 = IN_BETRIEB , registrierung 08.02.2018 10:26:01 , status 08.02.2018 10:27:04

Belegcheck:

Backup_BEL_V5\RKSV_Beleg_000000000001.txt Prüfmodus: Live Belegname: Startbeleg Belegnummer: 1 BelegDatumZeit: 2018-02-08T11:50:57 Prüfergebnis: FAIL FinanzOnline (2018-02-08T14:07:12) ERROR:[43] Der übermittelte Beleg ist fehlerhaft. <Prüfergebnis - Kasse> Der vorliegende Startbeleg passt nicht zum aktuellen Stand der Registrierung Ihrer Registrierkasse im FinanzOnline. Für eine erfolgreiche Startbelegprüfung verwenden Sie bitte den korrekten Startbeleg oder erstellen Sie einen Neuen. Bei der Belegprüfung wird untersucht, ob die Vorgaben der RKSV in Bezug auf den maschinenlesbaren Code am Beleg und auf die meldepflichtigen Metadaten der Sicherheitseinrichtung befolgt werden. Im Fehlerfall sind die genauen Fehlerinformationen nachfolgend angeführt. <Detailprüfung des maschinenlesbaren Codes>

Dieses Modul und die dazugehörigen Submodule überprüfen die Gültigkeit des Belegs. Dabei werden sowohl Formatprüfungen, kryptographische Prüfungen (verschlüsselter Umsatzzähler, Signatur) als auch Prüfungen im Zusammenhang mit dem Status der Kasse bzw. der Signatur-/Siegelerstellungseinheit durchgeführt. <Statusprüfung der Kasse und Signatur-/Siegelerstellungseinheit>

In diesem Modul und den dazugehörigen Submodulen werden die Zustände der Kasse und der verwendeten Signatur-/Siegelerstellungseinheit und die Ergebnisse der zuvor durchgeführten Prüfungen (vor allem der Belegtyp) ausgewertet. Handelt es sich um einen Startbeleg, wird überprüft ob eine Inbetriebnahme der Kasse möglich ist. <Statusprüfung der Kasse> Bei der Überprüfung des Status der Kasse zum Belegerstellungszeitpunkt bzw. Prüfzeitpunkt wurde ein Fehler festgestellt. Es wird der Status der Kasse zum Belegerstellungszeitpunkt und zum Prüfzeitpunkt ausgewertet. Die extrahierten Informationen werden im Zusammenhang mit weiteren Beleginformationen betrachtet.

--- Fertig, mit Fehlern! ---

[ErichFreitag]

Ich kenne die Meldungen und den Ablauf nicht auf dieser Ebene im Detail, aber ist laut obigen Meldungen nicht die Kasse bereits - nach erfolgter Registrierung - bereits auch in Betrieb, also mit Startbeleg in Betrieb genommen? Dann ist vielleicht die Fehlermeldung nicht ganz passend, aber mit einem nochmaligen Startbeleg gelingt auch keine nochmalige Inbetriebnahme?

[SEHellFire]

Laut automatisch generiertem Abfrageergebnis gibt es wohl:

Public Enum abfrage_ergebnisStatus

    '''<remarks/>
    AKTIVIERT

    '''<remarks/>
    REGISTRIERT

    '''<remarks/>
    IN_BETRIEB

    '''<remarks/>
    AUSFALL
End Enum

Leider fehlen die Remarks. Und in

https://www.bmf.gv.at/egovernment/fon/fuer-softwarehersteller/BMF_Registrierkassen_Webservice.pdf?67rvm4

Seite 8 steht leider auch nicht was die 4 Werte dann bedeuten.

[Phoniexk]

JA so wie ich vermutet habe und @ErichFreitag bereits geschrieben hat: Die Kasse wurde bereits am "08.02.2018 10:26:01" bzw. "08.02.2018 10:27:04" (ist nicht ganz klar welche Uhrzeit zugehörig ist) erfolgreich in Betrieb genommen.

Es ist nicht möglich für eine bereits in Betrieb genommen Kasse nochmals den Startbeleg zu prüfen. Das sagt auch die gezeigte Fehlermeldung aus.

Der vorliegende Startbeleg passt nicht zum aktuellen Stand der Registrierung Ihrer Registrierkasse im FinanzOnline.

Der Status ist "In Betrieb" und bei diesem Status kann kein Startbeleg übermittelt werden, deshalb ist auch die Fehlermeldung korrekt. Der Startbeleg kann nur im Status "Registriert" übermittelt werden.Der erste von Ihnen gepostete Beleg war um 2018-02-08T11:15:26, der Startbeleg wurde aber schon einmal erfolgreich um 10:26 / 10:27 übermittelt. Es bringt jetzt auch nichst den nochmals zu prüfen, weil die Kasse schon in Betrieb ist.

Der Startbeleg kann erst wieder übermittelt werden, wenn die Kasse abgemeldet wurde: Kasse "außer Betrieb nehmen" > Kasse nochmal neu registrieren > Startbeleg prüfen. Wenn es sich jetzt um ein "Livesystem" handelt, dann würde ich - aufgrund der vielen Fehlversuche - empfehlen die Kasse abzumelden und keine komplett neue Kasse mit neuer KASSEN-ID anzumelden + alles sauber dokumentieren. Weil man das bei einer Prüfung sonst nie mehr nachvollziehen kann.

[ErichFreitag]

Ja, aber sie schreiben doch "PASS: [0] Kassenstatus für ID V5 = IN_BETRIEB" - also "eh" in Betrieb?

[Phoniexk]

Seite 8 steht leider auch nicht was die 4 Werte dann bedeuten.

REGISTRIERT = Kasse angemeldet IN_BETRIEB = bereits registrierte Kasse wurde mit Startbeleg in Betrieb genommen AUSFALL = Ausfall wurde gemeldet

Wann "aktiviert" zutrifft weiß ich jetzt auch nicht.

Edit: Möglicherweise kommt "aktiviert" wenn eine SEE einmal als Ausfall gemeldet war und dann wieder "aktiv" gemeldet wird, ist jetzt aber nur blind geraten.

[SEHellFire]

Alles klar. Vielen Dank für die Tips!

Bei einer Statusabfrage für die Zertifikatseinheit kommen die selben kurzen Antworten?

--> Ich habe es wohl geschafft den ersten Startbeleg mit einer Totalnullstellung zu "vernichten" und kann nun mit der Kasse auch nicht mehr mit einem neuem Startbeleg neu starten weil da schon ein anderer Startbeleg beim BMF auf dem Server liegt. Nun muss ich die Kasse mit einer neuen ID neu anlegen?

Wenn ich die ID aber behalten möchte geht das mit Abmelden und neu Anmelden?

[Phoniexk]

Ja es kommen die selben "Antworten" für Zertifikate, sind ja auch völlig ausreichend.

Grundsätzlich wäre das mit Ab- und Neuanmeldung möglich. Ich würde aber dringend davon abraten. Der Originalbeleg ist zerstört wie Sie schreiben. Im FinanzOnline scheint er aber auf und auch die vielen Fehlversuche. Auch bei Ab- und Neuanmeldung scheinen alle Versuche weiterhin auf. Weder der Kunde, noch Sie, noch der Prüfer kann hier noch etwas nachvollziehen. Wenn Sie jetzt mit der selben ID nochmals eine funktionierende Kasse anmelden, ist das Chaos perfekt.

Die Abmeldung können Sie ja einfach mit dem Webservice durchführen. Eine neue Kassen-ID stellt ja auch überhaupt kein Problem dar.

Auf jeden Fall: Unbedingt "dokumentieren, dokumentierten und nochmals dokumentieren" (so ausführlich wie möglich), damit Sie ggf. auch in 10 Jahren oder mehr Auskunft geben können und das derzeitige DEP sichern, auch wenn es fehlerhaft ist.

[SEHellFire]

Ich habe nun die Implementierung der Statusabfrage für die SEE auch fertig und zusätzlich dann noch die Wiederinbetriebnahme einer SEE per Button erlaubt.

Leider Sagt die (erneute) Registrierung nur das die Karte (SEE) bereits in der Datenbank ist und der Status so wie die Wiederinbetriebnahme geben Fehlermeldungen zurück.

Da der Status einen Fehler wirft sehe ich auch kein Registrierungsdatum und kein Statusdatum der Karte:

Die Registrierung der Karte sagt:

[B10] Die angegebene Signaturerstellungseinheit ist mit dem angegebenen Vertrauensdiensteanbieter und der Seriennummer des Zertifikates bereits in der Datenbank gespeichert.

Aber der Status sagt:

SEE-Status von FO abrufen...

ERROR: [B33] Die Seriennummer ist nicht registriert oder bereits außer Betrieb genommen.

Und noch schlimmer - die Wiederinbetriebnahme sagt das auch!

SEE-Wiederinbetriebnahme an FO senden..

SEE-Snr.: 0198B43E5CA5793937D7E6E457 Kundeninfo: PC-CASH SE Station 1 (HolgerTestV5), Kasse 1

ERROR: [B33] Die Seriennummer ist nicht registriert oder bereits außer Betrieb genommen.

Vorgang abgeschlossen.

Leider habe ich momentan keinen Zugang zum FinanzOnline um dort zu schauen ob die Karte registriert ist und was dort angezeigt wird. Ich habe nur den Registrierkassen-Benutzer.

Besonders unschön finde ich das die erneute Registrierung der SEE nicht auch schon den B33 wirft. Weil mit dem B10 sieht es ja so aus als ob alles ok ist.

[Phoniexk]

Es ist anhand der Beschreibung nicht ganz eindeutig zu erkennen, welche Webservice-Befehle Sie jetzt im Detail verwendet haben.

Die Funktion / der Befehl "wiederinbetriebnahme_se" nimmt eine SEE nach einem Ausfall wieder in Betrieb. Da bei Ihnen der Status "B33" ist, kann "wiederinbetriebnahme_se" nicht funktionieren. Eine neue Registrierung ist hier notwendig. Seltsam ist dass Sie B33 erhalten und bei der Registrierung aber trotzdem B10... irgendwas stimmt hier im FON nicht.

Versuchen Sie nochmals die Karte neu zu registrieren (https://www.bmf.gv.at/egovernment/fon/fuer-softwarehersteller/Muster_Signaturerstellungseinheit_Registrierung.xml?67rvn0). Achten Sie auch darauf dass sie den Parameter "hex="true"" angeben. Im .NET-Framework ist hier noch ein zweiter Parameter notwendig.

Wenn hier wieder B10 erscheint, dann versuchen Sie nochmals die SEE mittels Außerbetriebnahme zu deaktivieren und dann nochmals eine Registrierung versuchen... auch wenn das vermutlich nicht funktionieren wird.

Das Einzige was mir sonst einfällt, dass Sie eventuell die "Außerbetriebnahme" mit Code 7 (Außerbetriebnahme aufgrund eines irreparablen Ausfalls) durchgeführt haben. Es ist zwar nirgends dokumentiert, aber möglicherweise ist bei diesem Code eine erneute Registrierung unmöglich - weil die SEE ja mit einem "irreparablen Ausfall" abgemeldet wurde. Ich habe Code 7 noch nie verwendet, immer nur Code 6 - auch beim Testen.

Ansonsten können Sie nur schauen dass Sie zu FON Zugang bekommen, oder alternativ im WKO-Forum die Frage stellen, dort erhalten Sie technische Auskunft vom BMF warum diese Fehler erscheint.

[SEHellFire]

Eigentlich habe ich die GlobalTrust RKS-CARD frisch vom Zettel abgenommen als ich vor paar Tagen die Testkasse neu registriert habe. Und ich glaube nicht das der Kassenhändler, dessen Zugang ich benutzen muss, da wir selbst hier in Deutschland ja keinen haben, die Karte zwischenzeitlich deaktiviert hat.

Karte (nochmals) registrieren wirft bei mir folgendes aus:

*** Register SEE ***

FO-Art der Übermittlung: BMF-Echtbetrieb
FO-Login: OK
[B10] Die angegebene Signaturerstellungseinheit ist mit dem angegebenen Vertrauensdiensteanbieter und der Seriennummer des Zertifikates bereits in der Datenbank gespeichert.

*** FO-RegisterSE: OK ***
FO-Logout: OK

Kundeninfo: PC-CASH SE Station 1 (HolgerTestV5), Kasse 1 VDA ID: AT2 Zertifikatsseriennummer: 0198B43E5CA5793937D7E6E457

*** FO-RegisterSE: Fertig, OK ***

---

Die Funtion status_se wirft dann aus:

ERROR: [B33] Die Seriennummer ist nicht registriert oder bereits außer Betrieb genommen.

Und die Funtion wiederinbetriebnahme_se wirft auch:

ERROR: [B33] Die Seriennummer ist nicht registriert oder bereits außer Betrieb genommen.

[SEHellFire]

Was denn nun - ist sie nicht registriert oder ist sie außer Betrieb genommen beides zeitgleich geht doch nicht!

Zudem fehlt Aufgrund der Fehlermeldung [B33] nun die Information, die die Status_se eigentlich bringen sollte: Registrierungsdatum und Statusänderungsdatum!

[Phoniexk]

Ja beim FON war man, was eindeutige und logische Meldungen angeht, leider etwas sparsam. Gleichzeitig geht nicht - das stimmt, aber hier macht man im FON offensichtlich keinen Unterschied, was funktionell auch keinen macht, da sie SEE in beiden Fällen nicht zur Verfügung steht. Für uns wäre eine Unterscheidung jetzt hilfreich.

Denkbar wäre auch ein Fehler seitens FON, dass die SEE in der DB in einem undefinierten Zustand ist, aus dem sie nicht mehr rauskommt.

Am besten den Händler kontaktieren, um ein Einblick ins FON zu bekommen. Ich würde erstmal prüfen ob beim Testen (unabsichtlich) eine Außerbetriebnahme mit Code 7 erfolgt ist bzw. ob in den FON-Logs etwas steht. Wenn Sie in Deutschland sind, werden sie wahrscheinlich auch für das WKO-Forum keinen Zugang bekommen, läuft dann wohl auch nur über den Händler.

Ich befürchte dass Ihnen hier auf Github niemand helfen können wird, aber vielleicht hat ja jemand anders noch eine Idee.

[SEHellFire]

ja, wie vermutet bringt die Ausfall-Meldung mit Grund 99 (Sonstiger) die gleiche Fehlermeldung:

SEE-Ausfall an FO senden..

SEE-Snr.: 0198B43E5CA5793937D7E6E457 Kundeninfo: PC-CASH SE Station 1 (HolgerTestV5), Kasse 1

ERROR: [B33] Die Seriennummer ist nicht registriert oder bereits außer Betrieb genommen.

Vorgang abgeschlossen.

[Phoniexk]

Ja das ist aber zu erwarten, weil laut B33 die Kasse nicht in Betrieb ist / nicht registriert ist > deshalb können Sie auch keinen Ausfall melden.

[SEHellFire]

Nein es geht um die SEE - die Kasse ist IN_BETRIEB

[Phoniexk]

Sorry Tippfehler... ich meinte auch die SEE. Die ist laut B33 nicht in Betrieb / nicht registriert > keine Ausfallsmeldung möglich.

[SEHellFire]

Ja, nur wenn ich diese registriere kommt halt [B10] - ist bereits in der Datenbank..

[SEHellFire]

Nun habe ich endlich den Zugang zum Webinterface:

Serien­nummer	Art	Vertrauens­dienste­anbieter	regist­riert am	Status
0198B43E5CA5793937D7E6E457 (hex)126487785150385438390888096855 (dez)	Signaturkarte	AT2 GLOBALTRUST	08.02.2018 10:25	In Betrieb seit 08.02.2018 10:25

[SEHellFire]

Im Webinterface steht also das die im Betrieb ist.

[Phoniexk]

Hmm irgendwie ergibt das alles keinen Sinn...

Haben Sie irgendwo vielleicht den Parameter "art_uebermittlung" versehentlich auf "Testübermittlung" gesetzt? Sie haben ja geschrieben dass Sie die Statusabfrage und die Wiederinbetriebnahme jetzt neu implementiert haben, ist hier eventuell bezüglich "Testübermittlung" ein Fehler unterlaufen? Falls Sie noch Zugang zum FON haben, können Sie in den Logs prüfen, ob "Produktiv" oder "Test" übermittelt wurde.

Wenn es das nicht war, dann bleibt eventuell nur eine E-Mail an hotline.finanzonline@bmf.gv.at, mit der Anmerkung dass Sie aus D sind und nicht ins WKO-Forum kommen.

[SEHellFire]

Ich bin im WKO-Forum und habe da bereits gepostet.

https://communities.wko.at/Kassensoftware/Lists/oFinanzOnline%20%20Webservice%20und%20File%20Upload/Flat.aspx?RootFolder=%2FKassensoftware%2FLists%2FoFinanzOnline%20%20Webservice%20und%20File%20Upload%2FWebService%20status_see%20%5BB33%5D%20Fehler&FolderCTID=0x01200200AA7B428ECA41804780249F7ABB8512F7

Bisher noch keine Antwort.

[SEHellFire]

Der Fehler ist gefunden.

Es muss nicht nur das Feld .hex auf True stehen sondern zusätzlich noch das Feld .hexSpecified auch auf True, weil der WebService sonst nicht von HEX Seriennummer auf DEC umrechnet um das Zertifikat in der Datenbank zu suchen.

Value: "0198B43E5CA5793937D7E6E457" hex: True hexField: True hexFieldSpecified: False hexSpecified: False valueField: "0198B43E5CA5793937D7E6E457"

geändert in

Value: "0198B43E5CA5793937D7E6E457" hex: True hexField: True hexFieldSpecified: True hexSpecified: True valueField: "0198B43E5CA5793937D7E6E457"

und nun funktioniert es :-D

[Phoniexk]

Ich weiß nicht welche Umgebung sie verwenden, aber vor 2 Tagen habe ich geschrieben:

Achten Sie auch darauf dass sie den Parameter "hex="true"" angeben. Im .NET-Framework ist hier noch ein zweiter Parameter notwendig

Dabei handelt es sich nämlich eben um „hexspecified“.... aber ist ja auch egal wenn es jetzt funktioniert.

[SEHellFire]

Ja, Vielen Dank für den Einsatz.

Da hatte ich wohl den Hinweiss mit dem zweitem Parameter auf was anderes bezogen oder so.

Trotzdem könnte man mal eine sinnvolle Fehlermeldung wie z.B.:

"Seriennummer 0198B43E5CA5793937D7E6E457 konnte nicht als dezimal angegebene Zertifikatsseriennummer in der Datenbank gefunden werden."

Oder wenn eben Hex gesetzt ist aber Dezimal angegeben wurde:

"Seriennummer 126487785150385438390888096855 konnte nicht als hexadezimal angegebene Zertifikatsseriennummer in der Datenbank gefunden werden."

einbauen.