Neues Problem Prüftool mit 16 Bytes AES Umsatzzähler?

[SEHellFire]

1.) Alte Versionen des Prüftools haben mir damals keine Fehler ausgeworfen. 2.) Die Start- und Jahresbelege lassen sich einwandfrei mit FON Prüfen. 3.) Ich verschlüssele den 16 Byte Umsatzzähler komplett in 16 Byte.

Und nun prüfe ich mit dem aktuellem Prüftool (was ja nun per default nur 8 Bytes verwendet) und bekomme Fehlermeldungen.

Ein Parameter "-l 16" wird vom Tool folgendermaßen quittiert: Error while parsing the input files. Detailed error-stacktrace:

org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -l at org.apache.commons.cli.DefaultParser.handleUnknownToken(DefaultParser.java:347) at org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:484) at org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:243) at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:120) at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:76) at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:60) at at.asitplus.regkassen.verification.cmdline.Prueftool.parseCommands(Prueftool.java:322) at at.asitplus.regkassen.verification.cmdline.CheckDEPExportFormat.main(CheckDEPExportFormat.java:48)

Wie gesagt die FON-Prüfungen der Belege funktionieren.

Wir haben mehrere tausend Installationen mit dem 16 Byte Umsatzzähler laufen. Was tun?

[ztp-mino]

Soweit ich weiß hat das Prüftool nie eine -l Option gehabt. Die Demo Kassa hatte die, das Prüftool sollte automatisch erkennen wie lang der Umsatzzähler ist. Ich hab jetzt auch grad bei der Version 1.0.0 nachgeschaut, die gibt den gleichen Fehler aus.

[SEHellFire]

Als ich das alles programmiert habe gab es eine Version 0.6 oder so und da war auch kein -l Schalter nötig es ging einfach so fehlerfrei durch.

Da auch die Startbelege dann in FO mit PASS durch gingen und die Monatsbelege auch mit "PASS" geprüft werden konnten war das Thema für mich eigentlich durch.

Nun ist aber einer vom Finanzamt an einen Kunden herangetreten und hat geschrieben das es da fachliche Mängel gibt, die der Kunde selbst(!) korrigieren kann. Und das der Kunde sich mit dem Kassenlieferanten /Softwarehersteller zur Mängelbehebung kurzschließen soll.

Ich habe diesen Finanzbeamten dann angerufen und gefragt um welche Mängel es sich denn handelt.

Die Antwort: "Das darf ich Ihnen nicht sagen." Und: "Man hat mir gesagt das Sie die selben Tools zur Prüfung haben". Ich sagte: "Ok, dann schicken Sie mir doch bitte die Daten, die ich testen kann." Er: "Das darf ich nicht."

Naja, wie dem auch sei. Sehr wahrscheinlich laufen nun draußen massig Kassen, die mit dem aktuellem Tool nicht geprüft werden können. Und möglicherweise sind in der AES-Implementierung dann auch noch weitere Fehler drinnen, die Finanz-Online aber auch nicht anmeckert.

Inzwischen habe ich das Kunden-DEP7 und auch die nötigen Daten, die das Tool sonst noch so braucht (Seriennummer der Signatureinheit, Zertifikatsdaten, KassenID). Das Tool wirft aus das die DEP-Sturktur OK ist aber wirft am Ende dann doch Fail aus weil die Total-Summen nicht entschlüsselt werden können bzw. falsche Werte bei rauskommen.

[ckvsoft]

Soweit ich mich erinnern kann Stand in der Anforderung 5-8 Byte. Daran hab ich mich 2015 gehalten und hatte bis jetzt auch keine Probleme. Könnt mich an 16 Byte nicht erinnern. LG chris

[SEHellFire]

In den Detailfragen (2016-03-11-Detailfragen-RKSV-V1.1.pdf) unter

2.5.2 Aufbereiten der Daten für den Verschlüsselungsprozess

Bei der Prozessbeschreibung steht:

Kodierung des Umsatzzählers: Die Block-Größe von AES-256 entspricht einem Byte-Array der Länge 16 (128 Bits). Für die Kodierung des Umsatzzählers im Klartext wird dabei ein Byte-Array der Länge 16 erstellt. Jedes Element des Byte-Arrays wird mit 0 initialisiert.. usw.

Weiter unten steht dann das MINDESTENS 5 Bytes verwendet werden müssen.

[ckvsoft]

Ok Danke. Das ist dann an mir vorbeigegangen. Als ich damit angefangen habe ist da sicher 5-8 gestanden. Hätte mir in c mit little endian etwas erspart.

Wurde vielleicht im Prüftool auch übersehen wenn es nicht mit 16Byte funktioniert. Auch im java Democode wurde immer auf 8 gekürzt.

[SEHellFire]

Da die Startbelege nun seit vielen Monaten ohne Fehler mit der 16 Byte Version akzeptiert werden kann ich ja nicht so viel falsch gemacht haben. Unschön ist dabei nur das es bei der 0 Summe im Startbeleg egal sein dürfte ob Big Endian verwendet wird oder nicht.

[ckvsoft]

Ja, bei 0 ists egal ;-)

Hab ich noch gefunden Beschreibung 5.9.2016 Version 0.7 Der optionale Parameter -l TURNOVER-COUNTER-LENGTH gibt an, wieviele Bytes für die Kodierung des Umsatzzählers verwendet werden sollen. Wird der Parameter nicht angegeben, oder wird ein Wert kleiner 5 oder größer 8 angegeben, so werden 8 Bytes für die Kodierung des Umsatzzählers verwendet.

[SEHellFire]

Das mit "Wird der Parameter nicht angegeben, oder wird ein Wert kleiner 5 oder größer 8 angegeben, so werden 8 Bytes für die Kodierung des Umsatzzählers verwendet."

Steht da nur für den Registrierkassenbeispielcode in JAVA!

Die Vorgaben für die RKSV sprechen von 256BIT verschlüsselung mit 16 Bytes (256 BIT). Das in JAVA dann mit nur 8 Byte und 128 BIT gearbeitet wird verringert die angestrebte Sicherheit der 256 BIT Verschlüsselung, die in der RKSV vorgegeben wird..

Das mit den 8 Bytes war keine Empfehlung in der RKSV.

[ztp-mino]

Sie verwechseln hier Blockgröße und Schlüssellänge. AES hat eine Blöckgröße von 16 Byte (128 Bit) und in der RKSV wird eine Schlüssellänge von 256 Bit (32 Byte) verwendet. Das Maximum von 16 Byte für den Umsatzzähler ergibt sich aus der Blockgröße, weil bei < 16 Bytes die Verschlüsselung relativ einfach zu implementieren ist. Mit der Sicherheit hat das absolut nichts zu tun.

[SEHellFire]

Bei nur einem Bit an Daten hätte ich ne Chance von 1:2 das richtige Ergebnis zu erraten. Bei 8 Bits an Daten gäbe es schon 256 verschiedene Möglichkeiten.

Und dabei spielt die Schlüssellänge noch überhaupt keine Rolle.

Aber darum geht es ja auch nicht. Ich habe die vollen 16 Bytes verwendet und das Prüftool der Finanz kommt damit aber nicht klar.

[ztp-mino]

1. realistisch sind die ersten 11-13 bytes sowieso 0x00 (oder 0xff bei negativen Zahlen), nur weil Sie mehr verschlüsseln heißt das nicht, dass es schwieriger zu erraten ist was der Plaintext ist.
2. Sie haben noch immer keine Möglichkeit zu überprüfen ob das was Sie geraten haben stimmt.
3. Stimmt, darum gehts eigentlich nicht.

[SEHellFire]

Und da beim Startbeleg der Plaintext zu 100% bekannt ist lässt mit dem Startbeleg allein evtl. schon der Key ausrechnen. Auch das ist wohl wahr.

Aber lassen wir das mit der Sicherheit mal besser weg hier :-) Es geht ja nur um den Gesamtumsatz und den hat ja eh niemand zu verbergen.

[ztp-mino]

Äh, nein, der AES Key lässt sich nicht ausrechnen nur weil Sie den Plaintext kennen. Der Keystream mit dem der Umsatzzähler verschlüsselt wurde lässt sich berechnen und der ist bei jedem Beleg anders, das bringt Ihnen also genau nix. AES (und alle anderen modernen Cipher) sind so designed dass selbst wenn jemand den Plaintext und den Ciphertext kennt der Schlüssel sicher bleibt.

Zu Ihrem Problem: Ich habe ein DEP mit 16 Byte Umsatzzähler erstellt und geprüft, das Prüftool 1.1.1 akzeptiert das problemlos. Wenn Ihre Startbelege gehen, liegt die Vermutung nahe, dass mit den Endians was nicht passt.

[SEHellFire]

<<>> Zu Ihrem Problem: Ich habe ein DEP mit 16 Byte Umsatzzähler erstellt und geprüft, das Prüftool 1.1.1 akzeptiert das problemlos. Wenn Ihre Startbelege gehen, liegt die Vermutung nahe, dass mit den Endians was nicht passt. <<>>

Vielen lieben Dank für den Test. Ich werde das am Montag dann genauer untersuchen. Jetzt ist hier gleich Feierabend und WE.

[SEHellFire]

So, habe es näher angeschaut und festgestellt:

Das aktuelle Prüftool wirft bei 694 von 5655 Buchungen den Fehler mit dem falschem Turnover-Value aus:

In 9 von 10 Fällen tritt der Fehler auf wenn eine negative Buchung aktuell passiert oder direkt vorher passiert ist. Einmal trat der Fehler auch bei einem NULL-Beleg auf!

Darstellen tut sich das dann so:

"verificationId" : "DEP_TURNOVER_COMPARE",
"version" : 1,
"verificationName" : "Entwicklung des Umsatzzählers",
"verificationTextualDescription" : "In diesem Modul wird überprüft, ob die Entwicklung des verschlüsselten Umsatzzählers mit den Belegbeträgen übereinstimmt.",
"verificationState" : "FAIL",
"verificationResultDetailedMessage" : "Der berechnete Umsatzzähler entspricht nicht dem verschlüsselten Umsatzzähler (siehe Parameter DECRYPTED_TURNOVER_VALUE). Bitte überprüfen Sie die Kodierung des Umsatzzählers (BIG-Endian, Zweierkomplement), oder den verwendeten AES-Schlüssel.",
"input" : {
  "DECRYPTED_TURNOVER_VALUE" : "-1992053593",
  "TURNOVER_SUM" : "181651",
  "SUM_TAX_SET_ERMAESSIGT2" : "0,00",
  "SUM_TAX_SET_ERMAESSIGT1" : "0,00",
  "SUM_TAX_SET_NORMAL" : "0,00",
  "TYPE_RECEIPT" : "NULL_BELEG",
  "SUM_TAX_SET_NULL" : "0,00",
  "SUM_TAX_SET_BESONDERS" : "0,00"
},
"output" : {
  "TURNOVER_SUM" : "-1992053593"
},

Sehr komisch dabei ist halt das die meisten Buchungen Fehlerfrei sind!

In den ersten 113 Buchungen tritt der Fehler bei folgenden Buchungsnummern auf: 7-9, 42-45, 75-78, 85, 86, 97, 98 und 113

Auch komisch ist das bei der Buchung 112 (auch ein Null-Beleg) kein Fehler auftrat und bei 113 dann (ebenso Null-Beleg mit selber Summe aber anderem IV) der obige Fehler kommt!?

[SEHellFire]

Die 114 wirft auch wieder einen Fehler:

"DECRYPTED_TURNOVER_VALUE" : "183751", "CASHBOX_ID_INITIAL" : "CRGK1", "SIGNED_PENULT" : "true", "SIGNED_PREV" : "true", "STATE_SIGDEVICE_AUSFALL_MARKER" : "NULL", "RECEIPT" : "R1-AT1...._0,00_21,00_0,00_0,00_0,00 . . "input" : { "DECRYPTED_TURNOVER_VALUE" : "183751", "TURNOVER_SUM" : "-1992053593", "SUM_TAX_SET_ERMAESSIGT2" : "0,00", "SUM_TAX_SET_ERMAESSIGT1" : "21,00", "SUM_TAX_SET_NORMAL" : "0,00", "TYPE_RECEIPT" : "STANDARD_BELEG", "SUM_TAX_SET_NULL" : "0,00", "SUM_TAX_SET_BESONDERS" : "0,00" }, "output" : { "TURNOVER_SUM" : "183751"

Wobei aber 183751 (der Wert, der in der vorherigen tatsächlich drinnen steht) - 181651 (dieser Wert) = 2100 (Buchungswert dieser Buchung) ist. Also alles völlig korrekt!

[SEHellFire]

Der Fehler in der 114 wird nur ausgeworfen weil sich das Prüftool den aus 113 falsch dekodierten Summenwert gemerkt hat und nun wieder den korrekten wert dekodiert hat.

[SEHellFire]

Ach nochwas: Das Prüftool zeigt einen negativen Wert an. Das kann nicht sein da es sich um einen UNSIGNED ULTRA LONG handelt (ohne Vorzeichen).

[SEHellFire]

Den Fall mit dem Beleg "113" habe ich mal Entschlüsselt. Es geht um:

"TURNOVER_SUM" : "181651", "SYSTEM_TYPE_INITIAL" : "OPEN", "TIMEOFRECEIPT" : "2017-10-04T12:00:45.000", "RECEIPT_PREV" : "_R1-AT1_CRGK1_71_2017-10-04T12:00:36_0,00_0,00_0,00_0,00_0,00_0xKUEGbKo/63PSgK5P/qLA==_28373EAE_GfrbTkQ9KMk=_0kOvsbk8bsGZ19RyjFUbJXcG4OtHd6tWeyK9iE82Ynx7CPuAfb+3sx6WjnD7/51J1N95FpGhTXHF09sVF3ZYlA==", "RECEIPT_SIGNED" : "true", "DECRYPTED_TURNOVER_VALUE" : "-1992053593",

Der Verschlüsselte Wert steht also BASE64 Kodiert hier: "0xKUEGbKo/63PSgK5P/qLA==" Die KassenID ist: "CRGK1" Und die Belegnummer 113 ist in HEX: "71" Der AES-Key mit dem verschlüsselt wurde ist in BASE64url: "LnYFtz0F2JwZVKls78xYyGJBhwvvhGnRpLCI2U/Jll4="

Und wenn ich meine Entschlüsselungsroutine damit füttere kommt das korrekte "181651" raus.

Kann das bitte jemand überprüfen?

[ErichFreitag]

Ob es sie beruhigt weiß ich nicht - wenn ich ihre Daten verwende, erhalte ich auch einen Umsatzzähler von 1.816,51 EUR.

Mich würde dennoch beunruhigen, dass das Prüftool einen Fehler produziert. Sie haben ja selbst darauf hingewiesen, dass das irgendetwas mit negativen Zahlen zu tun hat/haben kann. Dem würde ich nachgehen - ganz grundlos ist das meistens nicht.

Sie können auch gerne noch 2, 3 andere Codes (oder eine kurze DEP-Sequenz) posten - speziell jenen Bereich, wo sie Probleme mit negativen Umsätzen vermuten.

[SEHellFire]

Ich habe mal eine Prüfroutine geschrieben, die bei mir nun das auswirft:

KassenID: CRGK1 aesKey: LnYFtz0F2JwZVKls78xYyGJBhwvvhGnRpLCI2U_Jll4 InFile: d:\DEP\DEP_2017_CRGK1_31.01.2018_von_28-37-3E-AE_20171002_bis_28-37-3E-AE_20171219.json OutFile: d:\DEP\DEP_2017_CRGK1_OUT.txt DEP-Total-Start-SUM: 0 { "Belege-Gruppe": [ { "Signaturzertifikat":"MIIFPjCCAyagAwIBAgIEKDc+rjANBgkqhkiG9w0BAQsFADCBoTELMAkGA1UEBhMCQVQxSDBGBgNVBAoMP0EtVHJ1c3QgR2VzLiBmLiBTaWNoZXJoZWl0c3N5c3RlbWUgaW0gZWxla3RyLiBEYXRlbnZlcmtlaHIgR21iSDEjMCEGA1UECwwaQS1UcnVzdCBSZWdpc3RyaWVya2Fzc2UuQ0ExIzAhBgNVBAMMGkEtVHJ1c3QgUmVnaXN0cmllcmthc3NlLkNBMB4XDTE3MDkyMTA4MDYzN1oXDTIyMDkyMTA2MDYzN1owPjELMAkGA1UEBhMCQVQxGDAWBgNVBAMMD1VJRCBBVFU3MjMxNDcyOTEVMBMGA1UEBRMMMzkxMTA2MDk4MzIzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEdxEdaAX84wjc2gB/Z6vkDefGJF3vvSDPw3QAMbuI2CGSQfSknVnAJKxi8aDjnA96djSK3MT9+pCSRl237arl66OCAakwggGlMH8GCCsGAQUFBwEBBHMwcTBGBggrBgEFBQcwAoY6aHR0cDovL3d3dy5hLXRydXN0LmF0L2NlcnRzL0EtVHJ1c3QtUmVnaXN0cmllcmthc3NlLUNBLmNlcjAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AuYS10cnVzdC5hdC9vY3NwMBMGA1UdIwQMMAqACEBHnq7jkN+2MCAGA1UdEQQZMBeBFWMucmVpY2hsQGNyLWdhc3Ryby5hdDARBgNVHQ4ECgQISz7PiedcY1MwDgYDVR0PAQH/BAQDAgbAMBwGByooAAoBCwEEEQwPVUlEIEFUVTcyMzE0NzI5MAkGA1UdEwQCMAAwWAYDVR0gBFEwTzBNBgYqKAARARgwQzBBBggrBgEFBQcCARY1aHR0cDovL3d3dy5hLXRydXN0LmF0L2RvY3MvY3AvQS1UcnVzdC1SZWdpc3RyaWVya2Fzc2UwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybC5hLXRydXN0LmF0L2NybC9BLVRydXN0LVJlZ2lzdHJpZXJrYXNzZS5DQTANBgkqhkiG9w0BAQsFAAOCAgEAyt4HResWuJr7LRLFleAa6lmp9VkhwNYIsRA8O7eTvXH5S2CSS6nZIXe3vNtSHDVjk6rfYeu8eQc56JoxNkb90KJ4+sAJsQrpYGirGDBLxstG9+6fM3iyFGnrExV9RSM22IegT2zN2/H5ch9p6YfpANuz/kAObLnDrNZB/uMl5vD7zoxmvw3A6DzrN7h8YKF8tG6pXr5NTVn051ILN8yC9ul5QgwZFj5PLc+AfPLcOZyZ6fc+fWfVFEWK/n4fc2K1SZzm7/oc0XK6WSSMgvcjXuQKu/ofB/kU1sjvPdjzvNcW9VSPZAkE74fg/lH/Sgov2LLJfwbv9+09IMvSllWv9cU09cEDuX7sfguA7mm8yHELUW3f/C4jrk0w+UbxrpHGemaukkm5fnhjrAGW4G0qDoT9tO6+FDupxmTHVmvAFxmSujX2XoYs+v++25ZQueH4HeaZ5t3iQUbwchNt9Ex9Xs5YtEOt2hcpfZpCbWHnkmMD+TPH/Ecnkzz9ExbFUy3KvfNibV6GXFYlb1V8Em0fy3aY4rc6C7qHYzTOIixGt79QieFiOSq/nTLqc6kfVDwSsFYUOPBHDpqNKuPF6H0nORTZjzhd++pedAD7huFEexUDWwqZg8a0rIepxe1PTwRTu4U5rAHvlOhpvJ+2+lH05SJF0EVgCA7GsDZMFniLK5I=", "Zertifizierungsstellen": [], "Belege-kompakt": [ "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV8xXzIwMTctMTAtMDJUMjA6NTE6MzJfMCwwMF8wLDAwXzAsMDBfMCwwMF8wLDAwXzZUaHNGbzJ1RUZnQnVYT1NDQ2JQMUE9PV8yODM3M0VBRV9ZcE10ZzQ5TC9UND0.MNat-zcUSQBGD2xrG0bIWUPjRoXs2fm3FpJa2prTV2ScwWHUZo1WGx7hg3GBCBdCEH4B5cm7YGWR9Oa1ljZwlQ", _R1-AT1_CRGK1_1_2017-10-02T20:51:32_0,00_0,00_0,00_0,00_0,00_6ThsFo2uEFgBuXOSCCbP1A==_28373EAE_YpMtg49L/T4= DeCrypt("6ThsFo2uEFgBuXOSCCbP1A==") = 0 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV8yXzIwMTctMTAtMDJUMjE6MDc6MzNfMCwwMF8wLDAwXzAsMDBfMCwwMF8wLDAwX2oxRWpReEdjN09zaldsY3JMc29VN0E9PV8yODM3M0VBRV94VWo3TUEyQjV5dz0.NYJWTbPJAWdA6nfsHlhzbEQlsy-4LdX-Toh6a99N2kdgayJG0PCiNF9uzUTIikdpKImZBj6YJdbcu6w1M_Vf3A", _R1-AT1_CRGK1_2_2017-10-02T21:07:33_0,00_0,00_0,00_0,00_0,00_j1EjQxGc7OsjWlcrLsoU7A==_28373EAE_xUj7MA2B5yw= DeCrypt("j1EjQxGc7OsjWlcrLsoU7A==") = 0 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV8zXzIwMTctMTAtMDJUMjE6Mzk6NTZfMCwwMF8wLDAwXzAsMDBfMCwwMF8wLDAwX2RpRHY2QjBsZFh0aDZTYUNQQW10cFE9PV8yODM3M0VBRV96MlZ4UTd4TFpxbz0.-ykQPm4wnwHWDVaWh5l5nsK4De0_o9pSFeeecz7rNtbJT8pu0Yatl1wrRSUZOYsEu-Ftzx2wZk1GK4DPZv6uMA", _R1-AT1_CRGK1_3_2017-10-02T21:39:56_0,00_0,00_0,00_0,00_0,00_diDv6B0ldXth6SaCPAmtpQ==_28373EAE_z2VxQ7xLZqo= DeCrypt("diDv6B0ldXth6SaCPAmtpQ==") = 0 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV80XzIwMTctMTAtMDJUMjM6MjY6NTBfMjEsMDBfNTUsOTBfMCwwMF8wLDAwXzAsMDBfd2FUUThCR2RZN2YvRTd0OEJHS3R4Zz09XzI4MzczRUFFX01DTzQ4dVpSRGNnPQ.34beo7JTKljzcSLMXkj2YpG_uJJ8txp_GIz6EbZttl36dOw5xDsMgnveoepQtxiGAfetAMVvvz221ejlwqGv9g", _R1-AT1_CRGK1_4_2017-10-02T23:26:50_21,00_55,90_0,00_0,00_0,00_waTQ8BGdY7f/E7t8BGKtxg==_28373EAE_MCO48uZRDcg= DeCrypt("waTQ8BGdY7f/E7t8BGKtxg==") = 7690 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV81XzIwMTctMTAtMDJUMjM6NTc6NDlfMTIsNzBfNywyMF8wLDAwXzAsMDBfMCwwMF9mUVlEaEpKS0pVUTZ4K2h1K2kxM0J3PT1fMjgzNzNFQUVfUlRoV0FTU0ZSWDg9.N7f1ljBqPXK0IMroASHzl6nxKNJ1p23GRsjwSyCPYgS1rakWLhgmp2qUaGvrUGo51tsgeftoNG49EOtt737YhA", _R1-AT1_CRGK1_5_2017-10-02T23:57:49_12,70_7,20_0,00_0,00_0,00_fQYDhJJKJUQ6x+hu+i13Bw==_28373EAE_RThWASSFRX8= DeCrypt("fQYDhJJKJUQ6x+hu+i13Bw==") = 9680 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV82XzIwMTctMTAtMDNUMDA6MDQ6MjFfMTksNzBfNDksNDFfMCwwMF8wLDAwXzAsMDBfQlcwR0JNd09QZy8wbmRRYkFvVmt3QT09XzI4MzczRUFFX21LMkVDSERQdmhBPQ.5DtZrOO69xggHiLupIYCDOECWido_oN0ChT-HdyVKQJwbmLBaXtcSC4_Y0PS06Rg5Y_XxPDfARacvQsl9m4iDg", _R1-AT1_CRGK1_6_2017-10-03T00:04:21_19,70_49,41_0,00_0,00_0,00_BW0GBMwOPg/0ndQbAoVkwA==_28373EAE_mK2ECHDPvhA= DeCrypt("BW0GBMwOPg/0ndQbAoVkwA==") = 16591 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV83XzIwMTctMTAtMDNUMDA6MDQ6MjRfMTksMDBfMzAsMTBfMCwwMF8wLDAwXzAsMDBfdDhjTWlqcHJISXdyN0xJUG5KMnFsUT09XzI4MzczRUFFXzN1cG5rMXNCcXRFPQ.EPk_864s-iipqR9_1QEPisgc0tRW2KBLpGWTFZAbE-Y8nUKXG-fFzdbTlIicW5vYWn25mQCOmc8JxY97M5zBaQ", _R1-AT1_CRGK1_7_2017-10-03T00:04:24_19,00_30,10_0,00_0,00_0,00_t8cMijprHIwr7LIPnJ2qlQ==28373EAE_3upnk1sBqtE= DeCrypt("t8cMijprHIwr7LIPnJ2qlQ==") = 21501 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV84XzIwMTctMTAtMDNUMDA6MDY6MDZfLTE5LDcwXy00OSw0MV8wLDAwXzAsMDBfMCwwMF9WVEZTVUE9PV8yODM3M0VBRV9IdXdhUlVrSFE4cz0.SYEjVxAvFO1upldZrn78FllvJvQCvsMn1-XaYD1ZhCF5JthtqAuE6KGsrM-kPPhk1dmu6e7P0C5oB1sAY0B7iQ", R1-AT1_CRGK1_8_2017-10-03T00:06:06-19,70-49,41_0,00_0,00_0,00_VTFSUA==_28373EAE_HuwaRUkHQ8s= DoubleBase64Decode("VTFSUA==") = "STO" --> Storno-Buchung! "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV85XzIwMTctMTAtMDNUMDA6MDY6MThfLTE5LDAwXy0zMCwxMF8wLDAwXzAsMDBfMCwwMF9WVEZTVUE9PV8yODM3M0VBRV91ckVrdVdiczkrdz0.JR7baQzdT9NOljGk58foBXFn5-FjIMXFUbTVZXzu7TQJl4KAbKs4lTHTppIX4nmy48WA-cxhhzILveRyWOOxA", R1-AT1_CRGK1_9_2017-10-03T00:06:18-19,00-30,10_0,00_0,00_0,00_VTFSUA==_28373EAE_urEkuWbs9+w= DoubleBase64Decode("VTFSUA==") = "STO" --> Storno-Buchung! "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV9BXzIwMTctMTAtMDNUMDA6MDg6MDhfMTksNzBfNTEsOTBfMCwwMF8wLDAwXzAsMDBfSjNIVmhmM2JKZjdWY09sUjdzK0hvdz09XzI4MzczRUFFX2hmaDJIT0tCT3Z3PQ.aNk4gUyI7V4LIdeBN8XTSdCm_ND58I0q6ExptghaS4u1JBW7B4yAgGjDK2ylmiR4xRXDro2EFzZ4EaexxbImGA", _R1-AT1_CRGK1_A_2017-10-03T00:08:08_19,70_51,90_0,00_0,00_0,00_J3HVhf3bJf7VcOlR7s+How==_28373EAE_hfh2HOKBOvw= DeCrypt("J3HVhf3bJf7VcOlR7s+How==") = 16840 "eyJhbGciOiJFUzI1NiJ9.X1IxLUFUMV9DUkdLMV9CXzIwMTctMTAtMDNUMDA6MDg6MTNfMTksMDBfMjcsNjFfMCwwMF8wLDAwXzAsMDBfOUtsS3k3VDZxbXFMa1RwMnp1MlFEQT09XzI4MzczRUFFXzRVNFNZeDlObmk4PQ.cg909OFupFEr_7Mk1QV86KdK1qFbhTfkZbTUlyL3BxEpQGc58SZd7uNaCLo8WS9YhOo041Tg6g__DG206cKH2g", _R1-AT1_CRGK1_B_2017-10-03T00:08:13_19,00_27,61_0,00_0,00_0,00_9KlKy7T6qmqLkTp2zu2QDA==_28373EAE_4U4SYx9Nni8= DeCrypt("9KlKy7T6qmqLkTp2zu2QDA==") = 21501

Ist das mit "VTFSUA==" bei einem Storno so richtig oder hätte es nur einmal "STO" in Base64 = "U1RP" sein müssen?

[ErichFreitag]

Base64("STO")=U1RP, also nicht VTFSUA. Prüfroutine - OK - gibt es etwas (zusätzlich) herauszulesen?

[SEHellFire]

Die Summen scheinen korrekt durchgerechnet zu sein. Aber das mit dem falschem Eintrag für Storno und dann wohl auch für Training ist fatal...

[ErichFreitag]

Jein. Formal ist es falsch. Da aber der Umsatzzähler richtig weitergeführt wird (werden dürfte) ist das unschön, aber nicht tragisch. Es gehört einfach behoben.

[SEHellFire]

Nur um sicher zu sein:

Stornos haben dann U1RP und Trainings-Buchungen VFJB statt der Summe da stehen.

Die Buchungen mit Storno VTFSUA== und Training VkZKQg== müssen so in den alten Einträgen bleiben weil die QR-Codes ja auch so raus gingen und alles so verkettet ist.

Updates bei allen Kunden einspielen wird recht viel Zeit und Nerven kosten.

[ErichFreitag]

Ja, so ist es. Übrigens: die Ersatzcodierung ist auch ein Grund, warum in einem Vorgang Storno und Verkauf nicht gemischt werden dürfen. Vielleicht werfen sie im Zuge dessen auch noch einen Blick darauf.

Die Buchungen müssen drinnen bleiben, korrekt. Ist halt ein Fehler passiert, das darf ja sein.

Updates einspielen - kann man wohl nichts machen. Wahrscheinlich aktiv besser als reaktiv.

Ich würde auch die alten Kassen außer Betrieb nehmen und mit einer neuen Kassen-ID neu in Betrieb nehmen. Einfach, um die Lebenszyklen sauber zu trennen. Und/oder gleich mal die DEP-Sicherung und -Aufbewahrung "auszuprobieren".

[SEHellFire]

Bei so vielen Kunden, die das inzwischen im Einsatz haben, werden die Kassenhändler mit Sicherheit nicht auch noch Kassen im FO ab- und anmelden. Und auch nicht die Zeit haben da alles zu Sichern und dann zu leeren. Da wird die neue Version wohl nur einen Nullbeleg auslösen, speichern und normal weiter machen. Weil für mehr einfach keine Zeit ist.

[ErichFreitag]

Mir ist das egal - es war nur ein Typ, damit man sich auch noch in einigen Jahren auskennt, was da los war.

Den Fehler bei einer DEP-Prüfung schleppen sie ansonsten "ewig" mit. Sie bekommen dann halt die Rückfragen in 5, 8, 10, ... Jahren.

[hannesLP]

gibt es einen parameter um im DEP den turnover detailiert auszugeben? besten dank hannes ledl

[ErichFreitag]

a) für neue Themen bitte neue Issues erstellen

b) den Umsatzzähler haben sie ja in den pro Beleg generierten Logdaten detailliert angeführt. Eine andere Ausgabemöglichkeit ist mir nicht bekannt.

[AxelKutschera]

Wobei der Umsatzzähler nicht jedenfalls mit dem Umsatz (turnover) übereinstimmen muss.