Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
Moderator: Moderatoren
-
- Rekursionen-Architekt
- Beiträge: 153
- Registriert: Do, 06. Apr 2006 10:51
- Danksagung erhalten: 3 Mal
Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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
-
- 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
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
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
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- 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
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
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
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
Peter,
wenn Du mit Xbase++ 2.0 arbeitest ist das total simpel. Einen kompletten Satz bekommst Du mit in ein DataObject, das Du dann mit 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
wenn Du mit Xbase++ 2.0 arbeitest ist das total simpel. Einen kompletten Satz bekommst Du mit
Code: Alles auswählen
SCATTER NAME oDo
Code: Alles auswählen
Var2Json(oDo)
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.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- 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
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
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
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- 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
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.
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
Gruss Carlo
-
- 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
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
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
-
- 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
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
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
-
- 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
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
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
-
- 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
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"
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
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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.
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.
- ssemleit
- Rekursionen-Architekt
- Beiträge: 132
- Registriert: Di, 08. Mär 2016 11:32
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 9 Mal
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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
Stefan
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- ssemleit
- Rekursionen-Architekt
- Beiträge: 132
- Registriert: Di, 08. Mär 2016 11:32
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 9 Mal
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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
Stefan
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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!
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!
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
das ist nicht richtig !!!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.
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
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15699
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 68 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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.
kann man dort die Zugriffe machen und die Schnittstelle zu Xbase selbst sehr einfach halten.
Gruß
Hubert
Hubert
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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:
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
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)
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
- 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
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
....
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
Dort wurde eine Windows DLL angekündigt, die vielleicht eine weitere Option für den Zugang zur TSE ist.
Glück Auf!
Udo
- HaPe
- 1000 working lines a day
- Beiträge: 996
- 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
Hallo Udo !
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
Das liegt an der MTU-Size https://de.wikipedia.org/wiki/Maximum_Transmission_Unit, also der maximalen Größe eines Datenpakets.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.
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
Hans-Peter
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
Ich mach das mit einer Schleife:
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
Code: Alles auswählen
DO WHILE cBuffer <> Chr(0)
cBuffer := SocketRecvStr(snSocket, 1, @nError)
cRueckgabeTse += cBuffer
ENDDO
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- ssemleit
- Rekursionen-Architekt
- Beiträge: 132
- Registriert: Di, 08. Mär 2016 11:32
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 9 Mal
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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
Stefan
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Kassensystem auf Gesetzeslage ab 1.1.20 anpassen
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
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.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.