TOPIC:

Hallo,
ich werde von meinen Kassenkunden immer wieder mal gefragt, ob man ein Bankomatterminal direkt an den PC und an die VO Kassensoftware anbinden könnte. Ich habe mich damit bisher noch gar nicht beschäftigt, hätte dazu ein paar Fragen:

• Muss man für jeden Hersteller eine eigene Schnittstelle programmieren oder gibt es einen Standard?
• Über welchen Anschluss werden die Terminals angebunden (USB, LAN, ...)?
• Welches Softwareprotokoll wird dabei verwendet?
• Muss eine Schnittstelle beim Hersteller dann zertifiziert werden?
• Gibt es für VO bereits ein Modul das man einsetzen/kaufen kann?

Moin!

Die meisten moderneren Kartenterminals bieten die Option per LAN/WLAN angebunden zu werden. Die Kommunikation erfolgt dann meistens über HTTPS an eine API vom Hersteller die auf dem Terminal via WebServer bereitgestellt wird. Eine extra Zertifizierung braucht man m.W. nach nicht, denn die Schnittstelle ersetzt ja eigentlich nur die Bedienung per Tastatur/Touchscreen.
Ein VO Modul ist mir nicht bekannt, würde ich auch nicht mit VO programmieren wollen, die Möglichkeiten sind einfach zu beschränkt. Was ich machen würde, eine solche Schnittstelle per .Net mit X# oder C# programmieren und dann dem VO Programm per COM zur Verfügung stellen. Wie sowas geht zeige ich nächsten Monat in Memmingen.

Regards
Meinhard

Hallo Franz,

ich hatte von verschieden Anbietern DLL's, die eingebunden wurden, dann kam irgendwann das ZVT Protokoll, und die Arbeit wollte ich mir nicht machen. Ich habe dann www.easyzvt.de/ eingebunden, damit konnten bis jetzt die Kunden alle Ihre Terminals verwenden, und die Pflege der Schnittstellen übernimmt der Anbieter. Vielleicht einen Blick wert.
Grüße Frank

Meinhard: Das Terminal direkt ansprechen für einen einzelnen Kunden wird sich wohl bei weitem nicht rechnen, dazu müßten schon mehrere Kunden die Anbindung finanzieren und dann stellt sich aber das Problem, dass diese Kunden verschiedene Terminals haben und dadurch auch verschiedene Schnittstellen.

Frank: Das schaut nicht so schlecht aus, allerdings habe ich beim Durchsuchen im Netz gelesen, dass es auch einen zweiten Quasistandard namens Pepper gibt. Auch soll schon an einer weltweiten Standardisierung gearbeitet worden sein, die aber nie so richtig ins Laufen kam. Weißt du welches Protokoll verbreiteter ist: Pepper oder ZVT?

Hallo Franz,

Pepper habe ich noch nie gelesen. Und über EasyZVT muss ich mir ja auch keine Gedanken darüber machen, was der Kunde am Ende hat.

Ich habe inzwischen eine Testapp mit VO erstellt, welche mit EasyZVT kommuniziert. Dann habe ich eine EMail an meine Kassenkunden verschickt, welche Kosten eine Einbindung von EasyZVT verursachen würde und gefragt, wer daran interessiert wäre.
Nun warte ich mal ab, ob und wie viele Interesse zeigen.

Wenn es etwas kostet, wollen die Kunden dann doch lieber von Hand den Betrag ins EC Gerät eingeben

Das ist dann aber deren Problem! Angeboten hab ichs, alles andere liegt nicht mehr in meiner Hand.

Frank, eine Frage noch zu deiner Einbindung von EasyZVT:
Startest du den Prozess synchron und gibst ihm eine gewisse Zeit (5 Sek oder mehr) oder startest du ihn asynchron und schaust im Sekundentakt in der Registry, ob die Rückantwort da ist?
LG Franz

Ich habe EasyZVT jetzt in meine Kassenprogramme eingebunden und bei einem Kunden läufts auch schon produktiv. Allerdings ist mir Folgendes dabei aufgefallen:

Wenn EasyZVT.exe per RunPiped gestartet wird, bringt es einen Fortschrittsdialog über meinem DataWindow Kassenfenster. Ist die Zahlung fertig und EasyZVT.exe beendet sich und damit seinen Fortschrittsdialog, dann minimalisiert es mein Kassenfenster als Icon auf die Taskleiste. Ich habe zwar mittlerweile nach dem Aufruf von EasyZVT ein Show() eingebaut, damit es wieder hochgeklappt wird, aber das Runter- und Raufklappen sieht man natürlich, ist nicht wirklich schön. Nun meine Fragen dazu:

• Kann man das Runterklappen, das nicht von meinem Prog ausgelöst wird, verhindern?
• Oder kann man die Anzeige meines Kassenfensters sozusagen suspenden bis der Show() durch ist und dann wieder aktivieren?

Frank,

evtl. klappt das mit diesen Funktionen:

FUNCTION LockWindow (hWnd AS PTR) AS LONG PASCAL
// Setzt eine Fenstersperrung

// Das Neuzeichnen von Elementen in diesem Fenster unterbinden
RETURN SendMessage(hWnd, WM_SETREDRAW, 0, 0L)

FUNCTION UnlockWindow (hWnd AS PTR) AS LOGIC PASCAL
// Hebt eine Fenstersperrung auf und zeichnet das Fenster aktuell neu.
LOCAL lReturn AS LOGIC

// Das Neuzeichnen von Elementen in diesem Fenster wieder zulassen
SendMessage(hWnd, WM_SETREDRAW, 1, 0L)

// Die Fensterdarstellung aktualisieren
lReturn := RedrawWindow(hWnd, NULL, NULL, _OR(RDW_ERASE, RDW_INVALIDATE, RDW_ALLCHILDREN, RDW_UPDATENOW))

RETURN lReturn


In Windows gibt es dazu diese Funktion:
learn.microsoft.com/en-us/windows/win32/...ser-lockwindowupdate

HTH

Gerhard Bunzel

Hallo Franz,

sorry für die späte Antwort, war im Urlaub

Ich rufe nur EasyZVT auf und warte auf Beendigung, allerdings fällt mir ein, klappte das nur mit der Standalone Version, nicht mit der Clickonce Version von EasyZVT. Aber damit hatte ich noch keine Probleme gemeldet bekommen.

Grüße Frank

Gerhard:
Ich habe die beiden Funktionen eingebaut, nun müssen wir abwarten, ob sich dadurch etwas verbessert. Das Problem dabei ist nämlich, dass es lt. dem Kunden nicht jedesmal auftritt, sondern nur sporadisch.