cc.KassenSichV.* - Die Unitsammlung zur Kassensicherungverordnung des BMF

[bernau]

In einen anderen Thread hier in der Delphi-Praxis hatte ich wegen einem Gemeinschaftsprojekt zur Ansteuerung der SwissBit-TSE angefragt. Da es nicht wirklich ein bestehendes Projekt gab, habe ich einfach mal angefangen. Ist stehe etwas unter Zeitdruck, deshalb wollte ich nicht erst ein Gemeinschaftsprojekt organisieren. Zwischenzeitlich habe ich einige Anfragen von Personen erhalten, die auch noch am Anfang der Entwicklung stehen. Die KassenSichV ist ein heikles Thema und ich denke mehrere Augen sehen mehr als Zwei. Deshalb möchte ich hiermit meine Unit-Sammlung, die ich in den letzten Tagen geschrieben habe, der Allgemeinheit zur Verfügung stellen.

Etwas zur Lizenz:

Es wird die Beerware-Lizenz verwendet. https://de.wikipedia.org/wiki/Beerware

Kurz gesagt, mach mit der Unitsammlung was du willst. Wenn es möglich ich, dann sende mir einfach eine Flasche Bier aus deiner Region zu. Vielleicht noch einen zugehörigen Bierdeckel.

Es kann auf einem gemeinsammen Delphi-Event (z.B. die Foren-Tage https://forentage.de) auch gerne ein Bier ausgegeben werden.

Gegen einen Leckeren Single-Malt-Whiskey hätte ich auch nichts einzuwenden

Grundsätzlich erfolgt die Nutzung dieser Unitsammlung auf eigenes Risiko. Ich weise ausdrücklich darauf hin, dass bei falscher Nutzung die Hardware (TSE) unbrauchbar gemacht werden kann.

SwissBit-TSE / DsFinV-K

Ursprünglich wollte ich nur einen kleinen Wrapper für die DLL der SwissBit-TSE. Nun ist noch eine Klasse hinzugekommen, mit der die DLL noch etwas komfortabler angesprochen werden kann. Eine Kassenbeleg in mit wenigen Zeilen Quellcode erstellt und die benötigten Rückgabewerte für den Kassenbon werden in einem einfachen Record inkl. dem Inhalt des QR-Codes zurückgegeben. Da aber auch vieles davon in die DsFinV-K übergeht, werde ich ziemlich zügig noch weitere Klassen erstellen, die einen ordentlichen Export für die DsFinV-K ermöglicht. Die entsprechenden Units werde ich nachreichen.

Demo-Programm

Damit die Units von Interessenten einfach getestet werden können, habe ich ein kleines VCL-Programm beigefügt. Nichts besonderes. Soll nur zeigen, wie Funktionen angesprochen werden. Hier zwei Screenshots:

Version 0.2

Die DLL kann nun dynamisch geladen werden. Informationen dazu stehen in der Datei "cc.KassenSichV.License"

Diverse Fehler behoben.

Version 0.4

Event OnSelftestNotify zugefügt.

Automatisch Steuersatzzuordnung.

Kontrolle ob Bruttoumsatz und Zahlungen stimmig sind.

Compilerdirective WORMAPIDLL_STATIC zugefügt.

Verschiedene Hilfsfunktionen

Singleton-Funktion

Version 1.0

Neue Funktionen neuerer SDK > 5.7.1

keepalive_configure

LAN-TSE (von Uwe Koch)

Log-Funktionen

Weitere Events

Details stehen in der Datei "cc.KassensichV.ChangeLog.pas"

Erweiterung der SwissbitGui. (Siehe Bilder)

[bernau]

Zitat von michaelg:

@Bernau: Kann ich bei irgendwas mithelfen? Das Testprogramm um bestimmte Vorfälle erweitern oder ähnliches?

Beim Testprogramm. Gerne. Gute Idee.

[jaenicke]

Zitat von bernau:

Bei Bestellung wird jeder einzelne Artikel aufgelistet mit Menge, Bezeichnung und Betrag.

Ja, ok, das war falsch ausgedrückt. Aber wenn du z.B. den Artikel zwei mal stornierst, dann einmal mit einem erhöhten Preis buchst, dann schickst du das nicht einzeln, sondern eine Summe pro Artikel.

[bernau]

Zitat von jaenicke:

Zitat von bernau:

Bei Bestellung wird jeder einzelne Artikel aufgelistet mit Menge, Bezeichnung und Betrag.

Ja, ok, das war falsch ausgedrückt. Aber wenn du z.B. den Artikel zwei mal stornierst, dann einmal mit einem erhöhten Preis buchst, dann schickst du das nicht einzeln, sondern eine Summe pro Artikel.

Aber du schreibst es ja selber, bei der Stornierung gibst du die Menge, den Artikel und den Stornopreis an. Nur aufsummiert mit dem zusätzlich verkaufen Artikel mit dem erhöhen Preis. Das Sind die Werte (Menge, BEzeichnung, Preis) die in "Bestellung-V1" angegeben werden müssen.

Artikel Stornieren und dann den gleichen Artikel zu einem höheren Preis würde ich allerdings nicht aufsummieren, sondern in zwei Datensätzen (Einmal Storno und einmal Neuverkauf) angeben. Das aufsummierte wird ein Steuerprüfer nicht verstehen.

Grundsätzlich gilt. Bei ProcessType "Bestellung-V1" werden die einzelnen Artikel angegeben. Am Schluss wird "Kassenbeleg-V1" verwendet, in dem die Bruttosummen und die Zahlungsmittel angegeben werden.

"Bestellung-V1" wird aber Hauptsächlich in der Gastronomie angewendet. Nicht meine Branche und ich werden diesen ProcessType wahrscheinlich nie verwenden. Beim normalem Abkassieren (Kunde kommt an die Kasse und bezahlt mehrere Artikel) wird immer nur "Kassenbeleg-V1" mit den Entsprechenden Summen verwendet. Einzelne Artikel werden nicht angegeben.

[jaenicke]

Zitat von bernau:

Artikel Stornieren und dann den gleichen Artikel zu einem höheren Preis würde ich allerdings nicht aufsummieren, sondern in zwei Datensätzen (Einmal Storno und einmal Neuverkauf) angeben. Das aufsummierte wird ein Steuerprüfer nicht verstehen.

So haben wir es gelesen und in Präsentationen gehört. Vor allem in Bezug auf Rabatte. Man kann ja leider nicht angeben um was es sich handelt. Sprich wenn ein Artikel vorher mit 10,00€ gebucht war und nun 10% Rabatt gegeben werden, dann kann man ja nur schicken einmal Artikelname zu -1,00€. Schön und sinnvoll finde ich das auch nicht...

[noisy_master]

Ich muss erstmal ein GANZ GROßES Lob loswerden:
Ich finde es absolut super, dass du eine "freie" Implementierung eines so häufig diskutierten Themas zur Verfügung stellst.

Da ich auch sehr interessiert an dem Thema bin möchte ich auch gerne meine Mithilfe anbieten.(Wenn du etwas konkretes hast schreib mich doch einfach per PN an).

Aber: einen kleinen Kritikpunkt habe ich doch: Du hast die Implementierung auf aktuelle Delphi Versionen ausgelegt (TArray<x> := TArray<x> + [x], Base64encoding) und diese Teile "könnten" vielleicht noch für ältere Delphi Versionen angepasst werden...

Gruß

[bernau]

Zitat von jaenicke:

So haben wir es gelesen und in Präsentationen gehört. Vor allem in Bezug auf Rabatte. Man kann ja leider nicht angeben um was es sich handelt. Sprich wenn ein Artikel vorher mit 10,00€ gebucht war und nun 10% Rabatt gegeben werden, dann kann man ja nur schicken einmal Artikelname zu -1,00€. Schön und sinnvoll finde ich das auch nicht...

Leider lässt die Doku dazu viele Fragen offen.

Was ist z.B. wenn auf alle Artikel ein Rabatt von 10% gewährt wird. Da kann man doch nicht jeden einzelnen Artikel noch mal mit einem geringeren Preis auflisten. Ich würde dann den Artikel Rabatt verwenden (Menge 1, Bezeichnung Rabatt, Preis -3.20).

Klar ist auch nicht, ob bei den Zahlungsmitteln gegebenes Geld (100€) und Rückgeld (15€) getrennt als einzelne Position als Zahlungsmittel angegeben werden, oder ob diese als Summe (85€) in einer Position angegeben werden.

[herbstrot]

Moin,

Zitat von bernau:

"Bestellung-V1" wird aber Hauptsächlich in der Gastronomie angewendet. Nicht meine Branche....

Muss nicht zwingend nur Gastronomie sein. Wir nutzen z.B. die Möglichkeit einen Bon zu parken und bilden das über "Bestellung-V1" ab.

Im übrigen gut, dass es eine freie Implementierung gibt

[jaenicke]

Zitat von bernau:

Was ist z.B. wenn auf alle Artikel ein Rabatt von 10% gewährt wird. Da kann man doch nicht jeden einzelnen Artikel noch mal mit einem geringeren Preis auflisten. Ich würde dann den Artikel Rabatt verwenden (Menge 1, Bezeichnung Rabatt, Preis -3.20).

Ja, klar ist nur, dass es unklar ist. Wir machen den Rabatt tatsächlich auch einzeln, fassen aber pro Artikel zusammen. Die Stelle im Quelltext ist aber bewusst von der restlichen Logik getrennt um dies ggf. leicht anpassen zu können...

Zitat von bernau:

Klar ist auch nicht, ob bei den Zahlungsmitteln gegebenes Geld (100€) und Rückgeld (15€) getrennt als einzelne Position als Zahlungsmittel angegeben werden, oder ob diese als Summe (85€) in einer Position angegeben werden.

Hier soll ja nach Bar und Unbar unterschieden werden und so fassen wir es auch zusammen.

Zitat von noisy_master:

Aber: einen kleinen Kritikpunkt habe ich doch: Du hast die Implementierung auf aktuelle Delphi Versionen ausgelegt (TArray<x> := TArray<x> + [x], Base64encoding) und diese Teile "könnten" vielleicht noch für ältere Delphi Versionen angepasst werden...

Das Thema ist bei uns auch aufgetaucht, weil wir ältere Versionen noch auf XE6 pflegen. Leider hat die Unterstützung für XE6 den Quelltext signifikant aufgebläht... schön ist das nicht.

[bernau]

Zitat von noisy_master:

Aber: einen kleinen Kritikpunkt habe ich doch: Du hast die Implementierung auf aktuelle Delphi Versionen ausgelegt (TArray<x> := TArray<x> + [x], Base64encoding) und diese Teile "könnten" vielleicht noch für ältere Delphi Versionen angepasst werden...

Ich bin da mal ganz egoistisch. Ich stehe etwas unter Zeitdruck und da mache ich mir dann weniger Gedanken darüber, ob ältere Versionen mit dem Code nicht zurech kommen. Das betrifft ja auch nur ein paar Wenige Funktionen.

Aber die neuen Sprachelemente von Delphi habe ich schon sehr lieb gewonnen. Generics, Exit mit Parametern etc. Ich freue mich schon auf den Umstieg auf die neuste Delphiversion. Managed Records finde ich klasse. Will aber "wegen dem Zeitdruck" keine Experimente machen.

[bernau]

Zitat von herbstrot:

Zitat von bernau:

"Bestellung-V1" wird aber Hauptsächlich in der Gastronomie angewendet. Nicht meine Branche....

Muss nicht zwingend nur Gastronomie sein. Wir nutzen z.B. die Möglichkeit einen Bon zu parken und bilden das über "Bestellung-V1" ab.

Aha? So rein Interesse halber, in welcher Situation muss man denn einen Bon parken?