ZVT - Reversal

[BerTa]

Hallo,

ich habe versucht einen BON-Storno (ZVT-Reversal Hex 06 30) an einem Verifone V400c über Com-Schnittstelle auszulösen und bin kläglich gescheitert.
Bei Kassenanschluss ist beim V400c keine Aktivierung der Softkeys mehr möglich. Darüber konnte man sonst einen Storno am Gerät erzeugen.

Bisher habe ich die Anmeldung, Betragsübergaben und Kassenschnitt hinbekommen, aber nun bin ich mit meinem Latein am Ende.
Mein letzter Versuch:

lBcdWert:=IntegerToBcd(liBonNr);
lAiBon[0] := lBCDWert.Fraction[0];
lAiBon[1] := lBCDWert.Fraction[1];
CRC_16B([6,48,6,00,00,00,135,(lAiBon[0]),(lAiBon[1]),3]);

oBBuffer[0] := Char($10); //DLE
oBBuffer[1] := Char($02); //STX
oBBuffer[2] := Char($06); //Reversal = Storno ---------- APDU
oBBuffer[3] := Char($30); // " Hex(30) = 48 "
oBBuffer[4] := Char($06); // Länge = 6 (für APDU nach Länge) "
oBBuffer[5] := Char($00); //Passwort (=000000) "
oBBuffer[6] := Char($00); // " "
oBBuffer[7] := char($00); // " "
oBBuffer[8] := char($87); // Hex(87) = Bon-Nr. folgend = 135 "
oBBuffer[9] := char(lAiBon[0]); // "
oBBuffer[10] := char(lAiBon[1]); // "
oBBuffer[11] := Char($10); //DLE
oBBuffer[12] := Char($03); //ETX
oBBuffer[13] := Char(StrToInt(osCrcLow));
oBBuffer[14] := Char(StrToInt(osCrcHigh));

ComPort.Write(oBBuffer,15);

Leider bekomme ich nur ein NAK (Hex 15) zurück, das ist alles!
Hat jemand eine Idee?

Gruß,
Bernd

[TiGü]

Möchte behaupten, dass man dem ZVT-Terminal von Verifone per COM-Schnittstelle ein Array von Bytes schicken soll (array of byte oder TBytes) und kein Array mit einzelnen Zeichen/Chars.

Ab Delphi 2009 ist Char auch 2 Byte groß. Vorher 1 Byte. Mögliche Fehlerquelle!!! Red Flag!!!!!!^1^111!elf

[BerTa]

Ich arbeite noch mit Delphi 7; da ist Char 1 Byte.
Wie gesagt, Betragsübergaben usw. funktionieren ja auch...

[TurboMagic]

Die mögliche Fehlerquelle trifft aber bestimmt nur dann zu, wenn er das nicht mit dem in seinem Benutzerprofil
angegebenen D7 entwickelt hat sondern D2009+ ;-)

[TiGü]

Zitat:

Zitat von TurboMagic (Beitrag 1509767)

Die mögliche Fehlerquelle trifft aber bestimmt nur dann zu, wenn er das nicht mit dem in seinem Benutzerprofil
angegebenen D7 entwickelt hat sondern D2009+ ;-)

Na danke für den unnötigen Beitrag! "Hast du das schon ins QP eingetragen?" :roll:

Wir wissen doch beide, dass der TE oder sein Nachfolger irgendwann mal wechseln wird und dann der Code sowas von gegen die Wand fährt.
Am Ende ist der Ansatz mit Char/Strings etc. falsch, weil:

Zitat:

Bei der ZVT Kassenschnittstelle handelt es sich um ein klassisches Byte-basiertes Kommunikationsprotokoll. In den Anfängen der Kassenschnittstelle wurde eine Liste von Feldern definiert. Einige müssen bei jedem Aufruf verbindlich übergeben werden, andere können optional transferiert werden.

https://www.treibauf.ch/kassenschnittstelle-zvt/

Wenn ich mir den Punkt Reversal (06 30) auf PDF-Seite 41/42 (https://www.terminalhersteller.de/do...9_final_en.pdf) anschaue, vermute ich, dass hier mit der Länge von sechs zu kurz gedacht ist.
Ich vermute die Length XX beziehen sich nicht nur auf das Password, sondern auch auf receipt-no, amount und restliche Elemente des Data block.
Also mindestens 10 statt 6, oder? Insofern bis zum Ende vom Array der Data block ist.
Und ob der Data block richtig gebaut ist, bedarf auch einer näheren Untersuchung. Da stecke ich nicht genug drin.

[Redeemer]

Muss man das nicht als

Delphi-Quellcode:

ComPort.Write(oBBuffer[0],15);

übergeben?

[PaPaNi]

Zitat:

Zitat von Redeemer (Beitrag 1509777)

Muss man das nicht als

Delphi-Quellcode:

ComPort.Write(oBBuffer[0],15);

übergeben?

Das würde ich auch als erstes ausprobieren.

[himitsu]

Mit [0] ist es nie falsch.

Ohne ginge eventuell auch, aber nur wenn oBBuffer ein statisches Array ist.


Natürlich kann man hier auch ein Array of AnsiChar, bzw. einen AnsiString (oder besser RawByteString, in Delphi's ab 2009) verwenden.
Oder eben eine Array of Byte, bzw. TBytes.



Was genau ist denn nun oBBuffer?
Es scheint ja irgendwas mit Char zu sein.




Ach ja, es sieht so aus, als wenn in oBBuffer[2] bis [12] das "Selbe" drin sterhen sollte, wie in dem Aray an bei CRC_16B?

Wieso ist es denn nicht das "Gleiche", bzw. besser sogar das "Selbe" ?

[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?