Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Konzeptionelles, Technisches, Termine, Fragen zum Hersteller usw.

Moderator: Moderatoren

Peter Schweizer
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 153
Registriert: Do, 06. Apr 2006 10:51
Danksagung erhalten: 3 Mal

Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Peter Schweizer »

Hallo Wissende,
ich habe hier eine branchenspezifisches PC-Kassensystem am laufen (xBase 1.9 SL1),
daß an die, ab 1.1.2020 geltende Gesetzeslage, angepasste werden muß.

Damit ich das Kassensystem weiter betreiben kann, muß ja eine Signatur für die jeden einzelnen Kas-senbon erstellt werden ( Bundesdruckerei Smartcard-TIM ?) .

Da ich momentan nur Wald sehe und keinen Weg in den Wald, bitte ich um Hilfe.
Wie fange ich an?
Wo sind Fallstricke zu erwarten ?
Wo gibts verlässliche Informationen ?

Gruß Peter
Gruss Peter
Volker
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 26
Registriert: Sa, 29. Okt 2005 13:57
Wohnort: Hof
Hat sich bedankt: 14 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Volker »

Hallo Peter,

es gibt einige Dienstleister welche diese Lösung als Cloud-Dienst anbieten (werden).
z.B.https://www.deutsche-fiskal.de oder https://fiskaly.com

Ich bezweifle ob der Termin 01.01.2020 zu halten ist. Aktuell ist noch nicht genau definiert was
die TSE enthalten muss.

Infos findest du auch hier https://kassensichv.com

Gruß
Volker
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Jan »

Volker,

gibt es da nicht auch lokale Lösungen, serverbasiert?

Ich muß gestehen das die beiden Firmen, die Du da verlinkt hast, mir ziemlich suspekt sind. Wer als einzige Kontaktmöglichkeit ein Webformular anbietet, der hat für mich erstmal was zu verbergen. Vor Allem dann wenn die in dem Wust der Seiten nirgends mal mit wirklichen Infos rüber kommen. Das sind bei beiden alles nur Allgemeinplätze.

Ich stehe vor dem Problem, das mein Kunde ein eigenentwickeltes Kassensystem hat, das ich natürlich auch gesetzeskonform umstellen muß. Und bin daher immer dankbar für Infos zu dem Thema.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Peter Schweizer
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 153
Registriert: Do, 06. Apr 2006 10:51
Danksagung erhalten: 3 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Peter Schweizer »

Hallo Jan, Hallo Volker,

bisher habe ich Informationen von:
insika.de und https://dfka.net/taxonomie/ (Deutscher Fachverband für Kassen- und Abrechnungssystemtechnik e.V.)

gesichtet.
Für mich käme also auch nur eine lokale Verarbeitung der Daten in Frage, da die Kassensysteme nicht zwangsläufig einen Internetzugang haben.

In den obigen Info-Quellen wird von Datenschnittstellen zum Finanzamt/Prüfer im JSON Format ? geschrieben.
JSON: wie komm ich von meinen dbf Daten zu JSON ??
und wo und in welcher Form müßen die JSON Daten aufbewahrt/bereitliegen ??

Gibts vielleicht Erfahrungen unsere Österreichischen Kollegen, die da vielleicht schon mehr gemacht haben ?

Peter
Gruss Peter
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Jan »

Peter,

wenn Du mit Xbase++ 2.0 arbeitest ist das total simpel. Einen kompletten Satz bekommst Du mit

Code: Alles auswählen

SCATTER NAME oDo
in ein DataObject, das Du dann mit

Code: Alles auswählen

Var2Json(oDo)
in einen JSON-String überführst.

Wenn das wirklich auch lokal laufen kann, wäre das natürlich eine geniale Vorgehensweise. Da würde ich gerne ansetzen.

Nachtrag: Ich seh gerade, das Du da noch mit der 1.9 arbeitest. Macht das leider etwas komplizierter ... Aber nicht unmöglich, denn JSON ist ja letztendlich "einfach" nur ein korrekt formatierter String.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Jan »

Peter,

aber das ist ja nur ein einheitliches Speicherformat. Die Verschlüsselung bzw. Sicherstellung der Nicht-Manipulation bleibt ja bestehen. Wirklich weiter bin ich damit also auch noch nicht.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Peter Schweizer
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 153
Registriert: Do, 06. Apr 2006 10:51
Danksagung erhalten: 3 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Peter Schweizer »

Jan,
danke für deine hinweise.
Ein Umstellung auf xbase 2.0 ist é in arbeit, also von da her kein Hinderniss.

Was mich noch umtreibt, ist auch die Frage, ab wann die Daten kryptograhpiert werden müssen, soll heißen ist das bereits beim eingeben der Daten eines kassenbons, wobei dabei ja noch nicht einmal feststeht ob der kassenvorgang zu ende kommt, oder erst am Schluß, wenn der Bon gedruckt wird und die Daten abgespeichert werden ?

Peter
Gruss Peter
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von ramses »

Hi
in Deutschland muss ab dem ersten Tastendruck mit dem "Sicherstellungsmodul" komuniziert werden, in Österreich erst bei der Totalisierung. Leider kocht hier wieder jedes Land seine eigene Suppe.... eigenes Format, eigne Vorschriften, eigener Standard usw. .... Das hier die EU nicht einschreitet? Wie sonst auch überall.
Valar Morghulis

Gruss Carlo
Volker
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 26
Registriert: Sa, 29. Okt 2005 13:57
Wohnort: Hof
Hat sich bedankt: 14 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Volker »

Hallo,

Ich habe das für Österreich "lokal" umgesetzt. Hier gibt es auch zahlreiche Dienstleister welche DLLs anbieten um
mit den dortigen Speicherkarten und Zertifikaten umzugehen.
z.B. https://www.a-trust.at/

Für die Umsetzung in Deutschland sehe ich mir auf jeden Fall die "Online-Lösungen" an,bevor ich eine Entscheidung treffe.
Die Umsetzung für Österreich war sehr zeitintensiv.

A-Trust scheint auch eine Lösung fürDeutschland in Vorbereitung zu haben.

Gruß
Volker
flanelli
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 151
Registriert: Di, 11. Mai 2010 16:27
Hat sich bedankt: 3 Mal
Danksagung erhalten: 9 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von flanelli »

Hallo Peter,
als Österreicher, der den mehr oder weniger leidvollen Weg der österreichischen RKSV ( Registrierkassenverordnung )
letztendlich doch mit Bravour beschritten habe und bis dato eine fehlerfreie Abhandlung aller Vorgänge samt bereits erfolgter positiver Finanzamtsprüfung erlebt habe, wünsche ich Dir und auch allen anderen Kollegen in Deutschland viel Power und Erfolg bei der Umsetzung mach euren rechtlichen Vorgaben.

Gerne würde ich Dir gegebenfalls mit dem einen oder anderen Tip behilflich sein aber nachdem die deutsche Verordnung bereits in den Grundsätzen ganz anders agiert als die österreichische RKSV, wird sich das wohl oder übel auf allgemeine Betrachtungen beschränken müssen.

Egal wie auch immer eine sogenannte "Sicherheitsverordnung" aussieht, es bleibt IMMER der Umstand bestehen, dass der Hersteller des Kassen-Programmes schon mal grundsätzliches in seiner Applikation adaptieren wird müssen.
Jede wirklich brauchbare und praxisorientierte PC-Kassenlösung wird über beliebeig miteinander kombinierbare Zahlungsmöglichkeiten für einen Verkaufsbelege verfügen wie Bar, Kreditkarte, Gutschrift, Gutschein, Zielrechnung, Teilzahlung ( auch diese in allen Varianten der Zahlungsmittel ), mehrere Steuersätze, Lieferscheine, Eigenverbrauch,
Werbung/Naturalien, Tagesabschlüsse, Monatsabschlüsse, Datenprotokolle aller Verkäufe/Belege inklusive jedem einzelnen verkauften Artikel sowie auch die Aufzeichnungen im Kassabuch, alle Einkaufsbewegungen und letztendlich auch die Inventurerfassungen etc. etc. umfassen. Egal wie auch immer eure Sicherheitsverordnung irgenf wann mal konkret aussehen wird, sie wird in den bisherigen Ablauf einer Kassenlösung zwangsläufig im Grundkonzept manches verändern bzw. zu überdenken geben.

Soweit ich aus den deutschen Dokumenten für die 2020-er Umstellung entnehmen kann, gibt es mehr oder weniger bei euch im Prinzip noch GAR NICHTS KONKRETES, außer die Vorgabe, dass bereits beim Beginn der Erstellung eines Beleges, die Sicherheitseinrichtung aktiv anzusprechen ist und somit bis zum Druck und Abschluss des Beleges alle Vorgänge sozusagen unter dem "Schirm der Kontrolle" abläuft.
Rein sicherheitstechnisch betrachtet ja keine schlechte Idee aber aufgrund einer weiteren, höchst befremdlichen deutschen Regelung stellt diese Vorgangsweise ein wahres Pulverfass für den Hersteller und somit auch bis zu einem gewissen Grad haftbaren Softwarelieferanten dar.
Eure Verordnung besagt nämlich, dass eine Registrierkasse, die, egal aus welchem Grund auch immer, einmal bzgl. eurer Sicherheitsverordnung nicht funktioniert, SOFORT deaktiviert werden muss und mit dieser kasse darf auch NICHT weiter gearbeitet werden.

Selbstredend, dass schon alleine aus diesem Grund eine ONLINE-Lösung in Deutschland ( nach der derzeitgen Lage ) völlig unverantwortlich wäre und unter Garantie den Todesstoß für den kassensoftwarehersteller mit sich bringt.

Eine lokale Lösung mittels der Signatur über eine Smartcard in einem Kartenlesegerät oder einen Chíp in einem USB-Stick ( da gibt es ja sicher auch in der BRD einige namhafte, zertifzierte Hersteller ) reduziert schon mal das Risiko erheblich auf eine reine Fehlfunktion des Kartenlesegerätes bzw. eines Stromausfalles oder Hardwaredefektes.

In Österreich kann eine Kassa auch weiter betrieben werden, wenn die Sicherheitseinrichtung ausgefallen ist, dann wird mit einem gesetzlich vorgebenem Text der Signaturvorgang durchgeführt und nach der "Reparatur" der Kassa der gesamte zwischenzeitliche Umsatz in einem einzigen Beleg nachträglich erfasst und wiederum signiert. Dadurch gibt es auch bei einer ausgefallenen Sicherheitseinrichtung letztendlich ein recht dichtes System.
Dauer der Ausfall länger als 48 Stunden, muss dieser dem Finanzamt gemeldet werden aber die Kassa darf dennoch weiter verwendet werden.

Letztlich bleibt auch immerhin noch die "unbekannte Größe" eines eventuell irgendwo lauernden kleinen Bugs in der Programmierung, die dann auch zu einem Absturz und somit einer Fehlfunktion der Kassa führt - samt nachfolgender Außerbetriebahme.
Ich denke, es wird jedem klar sein, dass selbst bei noch so akribischer Programmierung und Qaulitätssicherung es immer wieder mal vorkommen kann, dass ein DAU es locker schafft durch seine Intelligenzbefreiung auch das perfekteste Programm zum Absturz zu bringen.

Hinsichtlich der Verschlüsselung und der Signiervorgänge der Belege gibt es neben der Möglichkeit sich das auch selbst zu coden ( ist nicht so dramatsoch wie viele glauben ) aber es gibt etliche LIB's und DLL's mit denen man in XBASE via Activex sogar auch mit Version 1.90.331 ohne ein nennenswertes Problem sowohl die Umsatzzählerverschlüsselung, die Base64-Codierung und die Signaturerstellung generieren kann.

Bzgl. JSON solltest Du Dir allerdings wirklich absolut keine großen Gedanken machen. Eure Behörden müssen ohnhin mal zuvor ganz klar und eindeutig festlegen wie der Aufbau und Inhalt der jeweils gefürderten Datenerfassungsprotokolle
aussieht, der Rest ist simpelste Erstellung von zeilenweisen Strings mit den, von eurem Gesetzgeber definierten Texten und den realen Werten im simplen JSON-Format.


Signiertes, verschlüsseltes DEP7 lt. RKSV-Österreich
{
"Belege-Gruppe": [
{
"Signaturzertifikat": "",
"Zertifizierungsstellen": [""
],
"Belege-kompakt": [
"eyJhbGciOi........................oPzW6yc0GHrDnGXA",
"eyJhbGciOi........................_0lPTe_SakX5LZjQ"
]
}
]
}

oder/und

Offenes, variables DEP mit Mindestinhalten ( und auch gerne mehr ) lt. genereller Kassenverordnung Österreich
{
"Belege-Detail": [
"Belegnummer": "100092",
"Kassen-ID": "KASSA1",
"Status SE": "OK",
"Bezug-POS": "117130",
"Beleg-Datum-Uhrzeit": "2017-03-23T09:45:26",
"Beleg-Summe": 169.90,
"Beleg-Inhalte": [
{
"Artikel": "16012741 PULLI LG. A. 36 ",
"Menge": 1.00,
"Preis": 119.95
},
{
"Artikel": "18022437 SHIRT 3/4 A. 38 ",
"Menge": 1.00,
"Preis": 49.95
}
]
}
]
}

Zusätzlich zu den "normalen" Verkaufsvorgängen wollen die deutschen Gesetzegeber ja auch alle anderen Vorgänge
die in irgendeiner anderen Art und Weise Waren, Dienstleistungen, Kassavorgänge etc. etc mit der Sicherheitseinrichtung
gekoppelt haben, das sag dann auch ich nur mehr .... Prost - Mahlzeit :(

Zum Abschluß kann ich nur sagen, dass die schriftlichen Vorgaben in Österreich zwar sehr umfangreich und teilweise sogar erstaunlich leicht lesbar und verständlich waren aber wie es nun mal so mit Behörden und
Tintenburgen ist, war und ist auch bei uns manches absolut nicht korrekt beschrieben worden und es gab zig-fache Korrekturen und manches ist auch heute noch nicht wirklich korrekt.
Zumindest aber hatten und haben wir in österreich die Möglichkeit, die Korrektheit des Datenerfassungsprotokolles und des QR-Codes mit einer staatlich freigegebenen Prüfsoftware auf Java basierend ( gääääääääähn ) auf Korrektheit zu checken. Das wünsche ich Euch in der BRD jedenfalls auch.

Einstweilen mal genug und liebe Grüße aus Österreich
Ahoile aus dem Süden
Peter Schweizer
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 153
Registriert: Do, 06. Apr 2006 10:51
Danksagung erhalten: 3 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Peter Schweizer »

Hallo flanelli,
vielen dank für deinen Beitrag, der wie es schein aus der Praxis heraus kommt.
Er verdeutlicht mir erst richtig, vor welchem Berg ich stehe.

Auf welche LIB's und DLL's bis Du konkret gestoßen, oder mit welchen arbeitest Du ?

Gruß Peter
Gruss Peter
flanelli
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 151
Registriert: Di, 11. Mai 2010 16:27
Hat sich bedankt: 3 Mal
Danksagung erhalten: 9 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von flanelli »

Hallo Peter,
dass Du noch vor einem "Berg" stehst liegt meines Erachtens weniger an Dir sondern an der
offensichtlich völllig desaströsen Vorgangsweise eures Gesetzgebers bzgl. klarer und
vor allem auch wirklich nachvollziehbarer, praxisorientierten Dokumentationen.

Abgesehen davon, könntest Du u.B. mittles https://www.chilkatsoft.com/crypt-activex.asp
einige grundlegende Lösungsansätze für Dich finden.

Bzgl. des Andruckes bzw. der Generierung des QR-Codes auf den Belegen gibt es eine
sehr simple Möglichkeit über die QRCodeLib.Dl
Die kannst du unter http://www.sait.com.mx/download/qrcodelib.dll downloaden
Beispiel wie einfach das damit läuft:

qr_Inhalt:="i love Xbase++"
qr_file:="MeinQRPic.BMP"
qr_done:=DllCall("QRCODELIB.DLL", DLL_STDCALL, "FastQRCode",qr_Inhalt,qr_file)

Aufpassen musst Du lediglich bzgl. der diversen Belegdruckerproblematiken.
Manche haben ein totales Problem mit Pics die mehr als nur ein 1PP aufweisen
aber das konnte ich dank der Hilfe von Werner sehr schnell lösen.
siehe Re: Bondrucker Grafikdruck Absturz
Post by Werner_Bayern » Sat, 12. Nov 2016 0:03

Mir ist schon klar, dass ich Dir nicht wirklich in Form einer fertigen Lösung helfen kann
aber Du schaffst das garabtiert auch nach dem Motto aller Xbase-Veteranen, das da lautet
"we don't know why, but we can" :-)
Ahoile aus dem Süden
miwe-pos
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 28
Registriert: Mi, 26. Dez 2018 18:13

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von miwe-pos »

Hallo an alle, die mit Kassenproblemen und die neuen Forderungen zu tun haben,
ich arbeite auch daran. Zwei Dinge sind wichtig; einmal die Einbindung eines TSR-Moduls(Swissbit, Bundesdruckerei, Epson) und zum anderen die Schaffung der einheitlichen Schnittstelle der Finanzverwaltung (DSFinV-K), ein bürokratisches Monster von 117 Seiten.
Mit der EXTERN-Funktion von Alaska 2 konnte ich schon mit der Swissbit-API kommunizieren. Morgen(27.1.) erhalte ich meine Entwicklungs-TSE.
Mal sehem, wie es weiter geht?
Die Behauptung QR-Code wäre Pflicht, stimmt so nicht. Er ist gem. Seite 109 der DSFinV-K gesetzlich nicht vorgeschrieben. er kann, wie dort beschrieben, u.U. die Kassennachschau vereinfachen!
Von einer Cloudlösung würde ich abraten, da erstens die Versorgungssicherheit des Internets nicht immer gewährleistet ist (alle Kommunikation mit der TSE hat zeitnah zu erfolgen, was wenn es Störungen gibt?) und zweitens, zumindestens bei meinen Kunden, online Lösungen generell abgelehnt werden.

Mein Vorschlag - alle sollten sich regelmäßig zum Stand der Einbindung in die jeweilige Software und ggf. Problemen regelmäßig austauschen.
Benutzeravatar
ssemleit
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 123
Registriert: Di, 08. Mär 2016 11:32
Hat sich bedankt: 19 Mal
Danksagung erhalten: 8 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von ssemleit »

Hallo zusammen,

auch wir müssen die Anbindung einer TSE und den Taxomomie-Export gemäß DSFinV-K für unser Kassenmodul umsetzen.
Unser aktueller Stand ist folgender.

TSE:
Gestern hatte ich Kontakt mit dem Support von Alaska. Im November letzten Jahres haben sie ja in ihrem Newsletter
Unterstützung bei der Anbindung einer TSE in Aussicht gestellt.
Stand der Dinge seitens Alaska ist, dass sie einen API Wrapper für den Zugriff auf die WormAPI.dll von Swissbit in einem der
nächsten Updates zur Verfügung stellen wollen. Warten wir also mal ab.

Taxonomie DSFinV-K:
Wir setzen den Export bereits im JSON Format der DFKA um. Für die Finanzverwaltung müssen die Daten (gemäß aktuellem Stand)
jedoch in mehreren verknüpften CSV-Dateien bereitgestellt werden. Hier hoffen wir darauf, dass es irgendwann, irgendwo ein Tool gibt,
welches aus der JSON-Datei die CSV-Dateien erzeugt.

QR-Code:
Den QR-Code mit den Daten der TSE auf dem Bon zu drucken ist keine Pflicht.
Die Daten aus der TSE für den Bon müssen in für den Menschen lesbarer Form angedruckt werden.
D.h. wenn der QR-Code gedruckt wird, muss trotzdem der Klartext zusätzlich angedruckt werden.
Das soll eventuell in Zukunft entfallen. Dafür muss aber der Gesetzgeber die KassenSichV ändern.

Ende September letzten Jahres war ich in Berlin zur DFKA-Schulung "Taxonomie und Integration eine TSE".
Da gab es noch eine Unmenge von Unklarheiten.
Der ganze "Zirkus" wurde aufgrund div. Unklarheiten durch eine Nichtbeanstandungsregelung bis zum 30. September 2020 ausgesetzt.
Ich gehe mal davon aus, dass das nochmal verlängert wird.

Grüße aus Oberfranken
Stefan
Gruß
Stefan
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Jan »

Ich arbeite inzwischen mit Epson - die haben einen TSE-Server, an den ich bis zu 8 TSE einstecken kann. Das ist bei meinem Kunden, bei dem alle Kassen im Netz hängen, die beste Lösung. SDCards oder USB-Sticks im Kassenrechner finde ich nicht so prickelnd, die bekommen da so leicht Füße.

Um die Epson-Lösungen anzusprechen kann ich per Socket direkt die ePOS-Schnittstelle ansprechen, einfach Datenaustausch per XML. Der Einstieg war extrem heftig für mich, weil der Support dort absolut überlastet ist. Klar, jeder will das jetzt fertig bekommen, und zwar sofort.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
ssemleit
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 123
Registriert: Di, 08. Mär 2016 11:32
Hat sich bedankt: 19 Mal
Danksagung erhalten: 8 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von ssemleit »

Hallo Jan,

die Anbindung der Epson TSE klingt auf den ersten Blick einfacher (da XML und Socket) als die von Swissbit (da habe gerade mal einen Blick in Doku für die SDK geworfen).
Wie lange hast Du für die Anbindung der TSE benötigt und was für Funktionen triggerst Du an?
Gibt es z.B. für die Archivierung der Daten im TAR-Format ein Dienstprogramm von Epson, oder machst Du das direkt vom XBase Programm aus?

Auch wenn ich nicht Deine mühsam erarbeiteten Ergebnisse abgreifen möchte, kannst Du mal einen Code-Schnipsel posten,
wie das aussieht, wenn Du z.B. die Uhrzeit setzt oder einen Selftest machst, damit ich mir ein Bild von der Anbindung machen kann?

Gruß
Stefan
Gruß
Stefan
miwe-pos
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 28
Registriert: Mi, 26. Dez 2018 18:13

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von miwe-pos »

Ich arbeite mit der wormApi von Swissbit. Es ist ja schön wenn ALASKA irgendwann ein Update für dies TSE erstellt, ist leider nur für die abgreifbar, die noch den Service bezahlen.
Das Problem von XBASE ist, dass es keine Pointervariablen ,insbesondere auf char** also String, kennt, die man allerdings für manche Funktionen der WormApi benötigt.
Dazu habe ich einen Hilfeaufruf an anderer Stelle hier im Forum geschrieben. Auch der Hinweis auf Grap und ot4xb hat mir nicht wirklich geholfen. Ich bin an einen Austausch mit allen, die auch mit Swissbit arbeiten wollen, echt interessiert. Das wäre mal ein Thema für eine Zusammenarbeit!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von brandelh »

Das Problem von XBASE ist, dass es keine Pointervariablen ,insbesondere auf char** also String, kennt, die man allerdings für manche Funktionen der WormApi benötigt.
das ist nicht richtig !!!

Jeder String wurde von dllcall schon immer als Stringpointer (char oder char*) behandelt, ist also einfach zu übergeben, ab der 2.0 kann man diese auch empfangen (Parameter habe ich im Beitrag zu Windows API erklärt).
Mit der 1.90 benötigt man für letzteres ot4xb, diese habe ich z.B. für die Anbindung von QuickPDF genutzt (HBPrintPDF), welche alle arten von Parametertypen und Rückgabewerte benötigt und auch verwendet.
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von brandelh »

Wenn man Probleme mit einer API hat und eine andere Sprache wie C, Delphi oder PowerBasic etc. kann, welche selbst DLLs erzeugen kann,
kann man dort die Zugriffe machen und die Schnittstelle zu Xbase selbst sehr einfach halten.
Gruß
Hubert
Udo
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 46
Registriert: Do, 18. Okt 2007 15:37

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Udo »

Hallo Stefan,

- Zur Epson TSE -

Ich habe mir auch die Epson TSE angesehen und das Beispiel Programm zum Abfragen der Storage nachprogrammiert. Da gibt es schon ein paar Klippen zu umschiffen. Wie lange man dafür braucht ist wohl davon abhängig, wie fit man ist.
Thread Klasse um den Port zu belauschen. XML für die Kommunikation mit der Gegenstelle. Json in XML verpakt zur Rückgabe der Daten. Für mich ist das alles "spannend" und solange man keinen Zeitdruck hat ein lohnendes Thema, um sich die gerade in den letzten Jahren entstanden Werkzeuge von Alaska (Socket/XML/Json) mal genauer anzusehen. Man lernt ja nie aus. Insgesamt hat es mich 21 Stunden gekostet, um die Storage des Druckers abzufragen.
Es gibt jetzt eine Klasse "RedeMitEpson" mit der ich eine TCP Verbindung zum Drucker herstelle, ankommende Nachrichten einlese, speichere und mit einem userdefinierten Ereignis "melde". Rein- und rausgehenden Nachrichten sind mit denen im Epson Demoprogramm identisch. Läuft.

Die Stellen, die für mich schwierig waren.
1. Das Öffnen des Socket erzeugt sofort eine Antwort vom Drucker in der eine Client_Id zugeteilt wird. Erst danach geht der Dialog hin und her.
Öffnen des Socket:

Code: Alles auswählen

METHOD RedeMitEpson:atStart
   ::nSocket := SocketNew(AF_INET, SOCK_STREAM, 0, @::nError)
   IF SocketConnect(::nSocket,, ::cAddress, ::nPort, @::nError)
      ::setInterval(0)
      SocketSetBlockingMode(::nSocket, .F.)
   ELSE
     /* hier irgendwas nuetzliches mit nError anfangen FIXME */
     msg("Socket Open - Error: " + tostring(::nError),"")
   ENDIF
RETURN self
2. Die Antwort von der TSE enthält am Ende ein chr(0) das ich zuerst mit eingelesen habe. Das mag aber der XMLSimpleParser() gar nicht. Jetzt sieht das ungefähr so aus

Code: Alles auswählen

cRsp := oTSE:cResponse
oXML := XmlSimpleParser(cRsp)

IF !empty(oXML)
   IF oXML:getname() == "connect"
      oData := oXML:getChild("data")
      IF oData:isElement("client_id")
        cClientId  := oData:client_id
        IF !empty(cClientId)
           scClientId := cClientId
        ENDIF
     ENDIF
    ....
3. Der Drucker schickt Nachrichten mit mehreren Tausend Byte
Erst habe ich cBuffer für SocketRecv() entsprechend groß gemacht.
z.B. cBuffer := space(4096)
nRead := SocketRecv(::nSocket, @cBuffer, len(cBuffer),, @::nError)
if nRead <> 0 ...

Bei 1460 Zeichen reisst (zumindest bei mir) der Einlesevorgang ab.
Es hat einiges gedauert bis ich gemerkt habe, dass es nur eine kurze Unterbrechung gibt und dann der Rest nach kommt.
Jetzt lese ich brav zeichenweise - Epson schickt am Ende der Nachricht immer chr(0).
Sieht nicht elegant aus, aber tut. (Über Verbesserungsvorschläge würde ich mich freuen)

Code: Alles auswählen

METHOD RedeMitEpson:execute
   LOCAL cBuffer := " "
   LOCAL nRead

   IF ::nSocket <> 0
      nRead   := 0

      nRead := SocketRecv(::nSocket, @cBuffer, 1,, @::nError)
      IF nRead > 0                           // da kam ein Zeichen

        DO WHILE .T.               // ab 1. Zeichen hier lesen. Neuer Threadaufruf zu langsam
          IF nRead > 0
            IF asc(cBuffer) == 0                 // wenn 0x00  Ende der Daten
              IF ::nByte > 0
                *  memowrit("LastEpsMsg.TXT", ::cData)   // der will doch nur gucken
                ::TSEsagt( ::cData )
                ::cData  := ""
                ::nByte  := 0
                exit
              ENDIF
            ELSE
              ::cData += cBuffer
              ::nByte++
            ENDIF
          ENDIF
          nRead := SocketRecv(::nSocket, @cBuffer, 1,, @::nError)
        ENDDO

      ENDIF

   ENDIF
RETURN self
Tip: Letzten Freitag - 06.03.2020 - gab es ein TSE Webinar, das ganz informativ war. Den Link dazu kann man von Epson bestimmt noch bekommen. (Ich bin nicht sicher, ob ich den hier veröffentlichen darf)
Dort wurde eine Windows DLL angekündigt, die vielleicht eine weitere Option für den Zugang zur TSE ist.

Glück Auf!
Udo
Benutzeravatar
HaPe
1000 working lines a day
1000 working lines a day
Beiträge: 995
Registriert: So, 15. Nov 2015 17:44
Wohnort: 71665 Vaihingen-Enz
Hat sich bedankt: 17 Mal
Danksagung erhalten: 15 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von HaPe »

Hallo Udo !
Bei 1460 Zeichen reisst (zumindest bei mir) der Einlesevorgang ab.
Es hat einiges gedauert bis ich gemerkt habe, dass es nur eine kurze Unterbrechung gibt und dann der Rest nach kommt.
Das liegt an der MTU-Size https://de.wikipedia.org/wiki/Maximum_Transmission_Unit, also der maximalen Größe eines Datenpakets.

Die beim Ethernet-Treiber der genutzten Netzwerk-Karte eingestellte Größe, lässt sich mit DrTCP bestimmen und zur Not anpassen:
https://www.heise.de/download/product/dr.-tcp-10693
--
Hans-Peter
Udo
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 46
Registriert: Do, 18. Okt 2007 15:37

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Udo »

Hallo Hans-Peter,

danke für das Hintergrundwissen.
Die Möglichkeit die Größe der Datenpakete einzustellen ist "nett", aber will ich das bei allen Kunden machen?
Eher nicht.
Schöner wäre gewesen, wenn SocketRecv() darauf eigenständig reagiert.
Einen Hinweis auf das Problem habe ich in der Doku nicht ge- oder übersehen.

Glück Auf!
Udo
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Jan »

Ich mach das mit einer Schleife:

Code: Alles auswählen

DO WHILE cBuffer <> Chr(0)
   cBuffer := SocketRecvStr(snSocket, 1, @nError)
   cRueckgabeTse += cBuffer
ENDDO
Das klappt (bislang) auch bei den Epson-TSE reibungslos. Da kümmer ich mich überhaupt nicht um die Größe des Strings, der da kommt/kommen soll.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
ssemleit
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 123
Registriert: Di, 08. Mär 2016 11:32
Hat sich bedankt: 19 Mal
Danksagung erhalten: 8 Mal

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von ssemleit »

Was natürlich auch beachtet werden muss, wenn man sich für eine TSE entscheidet, sind die Kosten für den Endkunden.

Unseren Recherchen nach, sind die wie folgt:
Preise stammen von Jartech.com zzgl. Mwst.

#Epson:
1. Neuer Drucker 379€ + TSE-SD 169 € (für 3 Jahre) = 548€
2. Aufrüsten eines Druckers 179€ + TSE-SD: 169 € (3 Jahre) = 348 €
3. TSE-Server 3, 379 € + TSE-USB 229 € (5 Jahre) = 608 €

# Swissbit:
219€ (5 Jahre) = 219€

#Diebold Nixdorf (seit kurzem zertifiziert)
TSE (7 Jahre) = 290€

Wie man sieht, ist da EPSON schon deutlich teurer. Und ein Drucker/zusätzliche Hardware kann auch mal kaputt gehen.
Vorteil meiner Meinung nach Swissbit oder Diebold Nixdorf.

Ich war zu Beginn eigentlich gegen eine Cloud-Lösung, aber die sind von der Anbindung wohl einfacher und der Kunde hat nix im Haus.
Und wenn die irgendwann mal zertifiziert sind, spricht auch nix wirklich dagegen.

Wir haben unsere Entscheidung nocht nicht getroffen, welche TSE wir anbinden.
Werden es aber auch so machen, dass wir das mehstufig entwickeln.
Die TSE-Klasse wird von der eigentlichen Kassesoftware immer gleich angesprochen,
egal welcher Hersteller eingesetzt wird.

Zur Info, die Liste der aktuell zertifizierten TSEs:
https://www.bsi.bund.de/DE/Themen/Zerti ... _node.html

Gruß
Stefan
Gruß
Stefan
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen

Beitrag von Jan »

Stefan,

Deine Rechnung berücksichtigt aber eines nicht: Bei Epson hat man den gravierenden Vorteil, das die TSE nicht offen sichtbar in einem Rechner steckt. Wo das Teil auch mal Füße bekommen könnte. Ob das ein unbeobachteter Kunde ist, Servicepersonal, Reinigungskraft, wer auch immer. Mal eben nebenbei einen schicken kleinen USB-Stick abzuziehen ist immer ein gewisser Reiz für manche Leute.

Und da man ohnehin einen Bondrucker benötigt, ist das für mich ein sehr guter Weg. Mein Kunde wird sogar den Server 8 nehmen. Dann sind die TSE sogar raus aus den Druckern, sondern noch sicherer im Rechenzentrum untergebracht.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Antworten