ZVT - Reversal

[himitsu]

Ach ja,

Code:

CRC_16B    = oBBuffer

-         = $10 // DLE
-         = $02 // STX
6         = $06 // Storno-APDU
48        = $30 // 48
6         = $06 // 6 = APDU-Length ( Password bis lAiBon ??? )
00        = $00 // 000000 = Password
00        = $00 // ...
00        = $00 // ...
135       = $87 // 135 = Bon-Nr.
lAiBon[0] = lAiBon[0]
lAiBon[1] = lAiBon[1]
3         = $10 // DLE  <<<<<<<<<<<<<<<<<<<<<<<<<
-         = $03 // ETX  <<<<<<<<<<<<<<<<<<<<<<<<<
CRC        = StrToInt(osCrcLow)
CRC        = StrToInt(osCrcHigh)

Bei CRC_16B fehlt eine $10 ?


Wieso kopiert man das Array von CRC_16B nicht direkt in oBBuffer?
Da wären dann nur noch die ersten beiden Bytes nötig und anschließend noch das CRC
und alles dazwischen gäbe es nur einmal, ohne Fehler dank doppelter Wuchhaltung.

Und wieso kommt jemand auf die komische Idee ALLES zwanghaft als Hexadezimal zu übergeben, und dann sinnlos als Kommentar nochmal den richtigen Wert,
anstatt gleich den richtgen Wert zu übergeben und so potentielle Übersetzung-/Umrechnungs-/Konvertierungsfehler auszuschließen?

Weshalb sind STX, ETX und DLE keine Konstanten?

Warum sind osCrcLow/High als String?

[TiGü]

Ok, anhand dieses Repository (https://github.com/Portalum/Portalum...c/Portalum.Zvt) komm ich auch auf eine ähnliche Zusammenstellung für Reversal:

Code:

DLE
STX
06
30
06
PW
PW
PW
87
RN
RN
DLE
ETX
CS
CS

Die Länge mit sechs scheint sich tatsächlich nur auf drei Bytes Passwort, $87 als Marker für die Rechnungsnummer und zwei Byte für die Rechnungsnummer zu sein. Da ziehe ich meinen obigen Einwand zurück.
Daher kann es eigentlich nur sein, dass das Password, die Rechnungsnummer oder die Checksumme falsch sind.

EDIT: Oder das schreiben auf dem ComPort, wobei ich hoffentlich davon ausgehe, dass dies korrekt gehandelt wird?

[himitsu]

Zitat von TiGü:

Daher kann es eigentlich nur sein, dass das Password, die Rechnungsnummer oder die Checksumme falsch sind.

Zumindestens scheint sie ja was Anderes zu berechnen ... siehe in #9 die letzten beiden Bytes ... 03 vs 10 03


Ist manchmal etwas unpraktisch, mit einer doppelten Datenhaltung.