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)

[t2000]

Ich wäre auch dabei. Auch bei uns ist Eile angesagt.
Ist denn auch geplant, Bundesdruckerei TSE mit dazuzunehmen? An Epson arbeiten wir auch gerade noch.

[dummzeuch]

Bis auf "Im fertigen Programm muss die Bibliothek nicht erwähnt werden." hört sich die gesuchte Lizenz nach guter alter MPL an.

Meiner Meinung nach sollte jemand, der eine Bibliothek unter einer Open Source Lizenz verwendet, das auch erwähnen. Es tut schließlich nicht weh.

[himitsu]

"muss nicht" heißt ja nicht, dass man es nicht darf, aber es wäre dann für den Verwendenden nicht "tragisch" falls er es "vergisst".

[bernau]

Kurzer Hinweis, da ich grade per PM darauf angesprochen wurde.

In der Klasse TccSwissbitTse ist folgendes Event implementiert

Delphi-Quellcode:

Property OnGetDateTime: TccSwisBitTseGetDateTimeEvent read fOnGetDateTime write fOnGetDateTime;

Wenn dieses Event nicht genutzt wird, dann wird zur Einstellung der TSE-Zeit die aktuelle Zeit des Computers verwendet.

Mit diesem Event kann man, wenn man es wünscht, anhand einer anderen Zeitquelle (z.B eines NTP-Zeitservers) die Zeit abfragen und diese wird verwendet.

Im Beispielprogramm habe ich folgendes implementiert:

Delphi-Quellcode:

procedure TFormSwissBitGui.DoGetDatetime(Sender: TObject; var aDateTime: TDatetime);
begin
  aDateTime := now - 500;
end;

Dies habe ich gemacht, weil das Zertifikat meiner Test-TSE am 14.7.2020 abgelaufen ist. Diese TSE funktioniert also nicht mehr mit der aktuelle Zeit. Zum Testen solltet Ihr also dieses Event ändern oder entfernen.

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1469976)

"muss nicht" heißt ja nicht, dass man es nicht darf, aber es wäre dann für den Verwendenden nicht "tragisch" falls er es "vergisst".

Ist halt nur blöd, dass man dann nicht einfach die MPL als Lizenz verwenden kann.

[michaelg]

Ich bin auch dabei, bin schon fleissig am Testen. Bisher funktioniert alles aalglatt, ich bin begeistert.

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


Ich hab da mal eine generelle Frage zu den Abläufen. Für mich ist Gastronomie eher uninteressant. Ich muss Kassen im Einzelhandel bedienen können. Hier wird von Swissbit geschrieben, dass man für "kurze" Geschäftsvorfälle den ProcessType "Beleg" nehmen sollte. Dieser beinhaltet ja nur Bruttobeträge mit Steuersätzen und Zahlungen mit Zahlungsart. Es gibt keinerlei Information, was da verkauft wurde.

Beim Processtype "Bestellung" (langer Geschäftsvorfall), der für Gastro empfohlen ist, kann man (oder muss) die Bestellpositionen angeben. Wenn jemand ein Glas Cola bestellt, wird das Glas Cola im TSE vermerkt.

Und nun die Frage: Wenn ich einen "Beleg" erstelle und alle Positionen haben dieselbe Mehrwertsteuer, macht Ihr dann eine Transaktion mit nur einem Gesamtbruttobetrag des Bons? Oder gebt Ihr jede Position mit ihrem Betrag an? Der Geschäftsvorfall selbst ist ja nur ein Bruttobetrag, alles geht letztlich auf dasselbe Fibukonto.

Und dann noch eine kurze Frage hinterher: Nehmt Ihr bei Barentnahmen/-einlagen den "Sonstigen Vorfall"?

[jaenicke]

Zitat:

Zitat von michaelg (Beitrag 1470073)

Und nun die Frage: Wenn ich einen "Beleg" erstelle und alle Positionen haben dieselbe Mehrwertsteuer, macht Ihr dann eine Transaktion mit nur einem Gesamtbruttobetrag des Bons?

Ja, so steht es in der Doku soweit ich es verstanden habe.

Auch bei Bestellungen schickt man nicht was konkret bestellt wurde, sondern nur Summen.

Zitat:

Zitat von michaelg (Beitrag 1470073)

Und dann noch eine kurze Frage hinterher: Nehmt Ihr bei Barentnahmen/-einlagen den "Sonstigen Vorfall"?

Einzahlung, Auszahlung, Anfangsbestand, ... hielte ich da für passender.

[michaelg]

Zitat:

Auch bei Bestellungen schickt man nicht was konkret bestellt wurde, sondern nur Summen.

https://support.gastro-mis.de/suppor...nd-processdata

In dem Link steht: Die Processdata "Bestellung" besteht dann aus einer Liste von <Menge>;”<Bezeichnung>”;<Preis>

Und da stehen Wiener Schnitzel und Himbeereis als Beispiele, was mit in die Transaktion geschrieben wird.

[bernau]

Zitat:

Zitat von jaenicke (Beitrag 1470074)

Auch bei Bestellungen schickt man nicht was konkret bestellt wurde, sondern nur Summen.

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

[bernau]

Zitat:

Zitat von michaelg (Beitrag 1470073)

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

Beim Testprogramm. Gerne. Gute Idee. :thumb:

[jaenicke]

Zitat:

Zitat von bernau (Beitrag 1470083)

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:

Zitat von jaenicke (Beitrag 1470146)

Zitat:

Zitat von bernau (Beitrag 1470083)

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:

Zitat von bernau (Beitrag 1470173)

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:

Zitat von jaenicke (Beitrag 1470177)

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:

Zitat von bernau (Beitrag 1470173)

"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 :thumb:

[jaenicke]

Zitat:

Zitat von bernau (Beitrag 1470179)

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... :stupid:

Zitat:

Zitat von bernau (Beitrag 1470179)

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:

Zitat von noisy_master (Beitrag 1470178)

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:

Zitat von noisy_master (Beitrag 1470178)

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:

Zitat von herbstrot (Beitrag 1470190)

Zitat:

Zitat von bernau (Beitrag 1470173)

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

[jaenicke]

Zitat:

Zitat von bernau (Beitrag 1470260)

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

- Der Kunde hat nicht genug Geld dabei und geht schnell etwas holen.
- Der Kunde hat einen falschen Artikel mitgenommen und geht diesen schnell umtauschen.
...

Dann braucht man nicht alles neu eingeben, sondern parkt den Beleg und setzt ihn fort, wenn der Kunde wieder da ist.

[michaelg]

In der Datatypes-Unit habe ich beim Hinzufügen einer Bestellung eine Zeile hinzugefügt, pflegst Du die mit ein?

Code:

procedure TccDsFinVkProcessDataBestellung.AddBestellung(const aMenge: Double; const aBezeichnung: String; const aPreis: Double);
var
  lBestellung: TBestellung;
begin
  lBestellung.Menge := aMenge;
  lBestellung.Bezeichnung := aBezeichnung;
  lBestellung.Preis := aPreis;

  Bestellungen:=Bestellungen+[lBestellung];   //Michael Groß: 24.07.2020 sonst wird die Bestellung dem Array nicht hinzugefügt.
end;

[bernau]

Zitat:

Zitat von michaelg (Beitrag 1470270)

Code:

  Bestellungen:=Bestellungen+[lBestellung];   //Michael Groß: 24.07.2020 sonst wird die Bestellung dem Array nicht hinzugefügt.

Danke :thumb:

Habe die Zeile zugefügt.

[bernau]

Zitat:

Zitat von jaenicke (Beitrag 1470266)

Dann braucht man nicht alles neu eingeben, sondern parkt den Beleg und setzt ihn fort, wenn der Kunde wieder da ist.

Das ist ein Argument! :-D

[michaelg]

Ich habe im Testfenster eine Transaktion für eine Beispielbestellung eingebaut. Ein paar Artikel mit verschiedenen Steuersätzen werden dort an das TSE-Modul übergeben.

Hinweis: Bei der Processdata von Bestellungen sollte man sich nicht wundern, dass die einzelnen Artikel im Protokoll direkt nebeneinander kleben. Das vorgebenene Trennzeichen ist nur ein Wagenrücklauf (CR, \n oder auch#13), und das wird im Protokoll-Memofeld nicht angezeigt. Ich dachte erst es wäre ein Fehler, das CR ist aber definitiv mit drin.

[michaelg]

Ich mache mir gerade Gedanken darüber, wie ein Anwender unserer Software das TSE-Modul möglichst einfach selbst einrichten kann. Wenn ich mir die Anleitung ansehe, scheint das für einen normalen Menschen doch recht komplex.

https://support.gastro-mis.de/suppor...-der-anbindung

Der Idealfall wäre, wenn er nur noch den Laufwerksbuchstabe in der Konfiguration der Kasse hinterlegen müsste, und der Rest geht von selbst. Aber so einfach wird es wohl nicht werden.

Welche Mittel stellt Ihr bei Euren Anwendern softwareseitig zu Verfügung?

1.Laufwerksbuchstabe
2. ClientID der Kasse
3. PIN und PUK von User und TimeAdmin eintragen und ggf. auch noch eine Set-Methode, um die individuell anpassen zu können?

Was ist, wenn ein Zertifikat mal abläuft? Stellt Ihr eine Möglichkeit bereit, um die PEM zu aktualisieren? Kann das überhaupt gehen, wenn die bisher erfassten Daten mit dem alten Zertifikat erstellt wurden?

[himitsu]

Zitat:

Zitat von bernau (Beitrag 1470275)

Das ist ein Argument! :-D

Ist also immer das Selbe, wie Überall und bei Allem...

Man hat was angefangen und dann kommt was Anderes mal eben kurz dazwischen. :lol:

[bernau]

Zitat:

Zitat von michaelg (Beitrag 1470303)

Welche Mittel stellt Ihr bei Euren Anwendern softwareseitig zu Verfügung?

1.Laufwerksbuchstabe
2. ClientID der Kasse
3. PIN und PUK von User und TimeAdmin eintragen und ggf. auch noch eine Set-Methode, um die individuell anpassen zu können?

Wir haben uns für folgendes entschieden:

• Die erste Einrichtung der TSE wird durch uns "bei uns" durchgeführt.
• Der Anwender erhält mit der TSE die Admin-Pin und die TimeAdmin-Pin. Die PUK erhält er nur auf ausdrücklichen Wunsch.
• In der Konfiguration wird der Laufwerksbuchstabe und die TimeAdmin-Pin hinterlegt. Für alle Funktionen, die den Admin-Pin benötigen, muss dieser über ein Passwortdialog vom Anwender eingegeben werden.
• Sollte die PUK-Benötigt werden, dann geben wir diese per Fernwartung ein. Vorher lesen wir alle Parameter der TSE aus. Die Parameter der TSE werden regelmäßig protokolliert.

Zitat:

Zitat von michaelg (Beitrag 1470303)

Was ist, wenn ein Zertifikat mal abläuft? Stellt Ihr eine Möglichkeit bereit, um die PEM zu aktualisieren? Kann das überhaupt gehen, wenn die bisher erfassten Daten mit dem alten Zertifikat erstellt wurden?

Das Zertifikat läuft in der Regel in 5 Jahren aus. Eine Verlängerung für die TSE ist nicht möglich. Die Frage ist, was hat sich die BMF neues einfallen lassen. In fünf Jahren diskutieren wir wahrscheinlich wieder hier, die "neue" TSE mit neuen Technischen Funktionen angesprochen wird.

[herbstrot]

Moin,

Kunde hat z.B. was vergessen. Bon Parken und nächsten Kunden bedienen. Im Suppermarkt wird man soetwas eher weniger nutzen. In Boutiquen wird das schon des öfteren genutzt.

[herbstrot]

Zitat:

Zitat von michaelg (Beitrag 1470303)

Welche Mittel stellt Ihr bei Euren Anwendern softwareseitig zu Verfügung?

1.Laufwerksbuchstabe
2. ClientID der Kasse
3. PIN und PUK von User und TimeAdmin eintragen und ggf. auch noch eine Set-Methode, um die individuell anpassen zu können?

Was ist, wenn ein Zertifikat mal abläuft? Stellt Ihr eine Möglichkeit bereit, um die PEM zu aktualisieren? Kann das überhaupt gehen, wenn die bisher erfassten Daten mit dem alten Zertifikat erstellt wurden?

Bei uns muss der Anweder den Laufwerksbuchstabe selbst angeben, PIN und PUK ist bei der Ersteinrichtung zu vergeben.
ClientId geben wir vor.

Das Ablaufen des Zertifikats hab ich mit 2 Entwickler-TSE nachgestellt (bei einer TSE war das Zertifikat abgelaufen). Da die Kasse bei jedem Start und bei jeder Aktion - Position buchen, Bezahlen, etc. - die TSE einbindet, kann man darauf reagieren das das Zertifikat abgelaufen ist.
Was allerdings in 5 Jahren ist wird man dann sehen.

[michaelg]

Ich bin auf der Seite von Gastro-MIS auf ein Fallbeispiel gestossen, welches mir nicht klar ist. Es geht dabei um eine Zahlung auf eine Kundenrechnung, d. h. der Kunde kommt in den Laden und begleicht seine Rechnung bar:

Zitat:

100€ Umsatz 19%, Kunde nimmt Rechnung mit, bzw. Abschluss auf Debitor...

Beleg^100.00_0.00_0.00_0.00_-100.00^


... Der Kunde kommt 2 Tage später wieder und bezahlt die mitgenommene Rechnung Bar.

Beleg^0.00_0.00_0.00_0.00_100.00^100.00:Bar

Ich verstehe dabei nicht, warum dort im Beleg 100 € auf den Regelsteuersatz gebucht werden und -100 € auf den Null-Steuersatz.


Die Zahlung mit 100.00 als Null-Prozent-Betrag und die 100.00 als Zahlung in Bar sind für mich dagegen einleuchtend.

Hat jemand eine Idee, warum das in dem Beispiel so ist? Wenn jemand eine Kundenrechnung mitnimmt, ist doch in der Kasse gar kein "bestandsändernder Vorfall" gelaufen. Wozu dann überhaupt der erste Beleg, der ja steuertechnisch sowieso Blödsinn wäre?

[bernau]

Zitat:

Zitat von michaelg (Beitrag 1470578)

Ich bin auf der Seite von Gastro-MIS auf ein Fallbeispiel gestossen, welches mir nicht klar ist.

Kannst du den Link hier posten?

Zitat:

Zitat von michaelg (Beitrag 1470578)

Es geht dabei um eine Zahlung auf eine Kundenrechnung, d. h. der Kunde kommt in den Laden und begleicht seine Rechnung bar:

Genauer gesagt, der Kunde kommt in den Laden und nimmt seine Produkte und die Rechnung mit. Zwei Tage später (vieleicht im nächsten Monat) bezahlt er die Rechnung.

Das Ganze hat was mit der Wertstellung der Umsatzsteuer zu tun. Umsatzsteuer wird mit Aushändigung der Ware oder mit der Leistungserbringung fällig egal ob gezahlt wird oder nicht (Bei den meisten Unternehmen, aber nicht bei allen. Stichwort Sollbesteuerung und Istbesteuerung)

Das Beispiel interpretiere ich so: Wenn Ware abgeholt wird und kein (Bar-)Geld fließt, dann haben wir einen Brutto-Umsatz von 100€ und bei den Zahlungsmitteln haben wir 0€. Bruttoumsatz 100€ und Zahlungsmittel 0€ passt nicht zusammen.

Es gibt zwei Möglichkeiten Brutto-Umsatz und Zahlungsmittel auf einen Nenner zu bekommen.

1) Wie im Beispiel den Bruttoumsatz auf 0€ bringen. Dazu wird 100€ für die Ware mit Regelsteuersatz angegeben und ein Kredit von 100€ (angegeben mit -100€) mit 0% Steuersatz. Damit müssen 100€ versteuert werden. Wenn ein paar Tage tatsächlich das Geld fließt, dann gibt es einen neuen Bon mit Einzahlung von 100€ auf das Kreditkonto. Dazu gibt es dann einen Bruttoumsatz von 100€ zu 0% und einen Geldfluss von 100€ in Bar. Hier sind Bruttoumsatz und Zahlungsmittel wieder gleich, was wir ja wollen. In Summe heben sich die 0%-Umsätze auf. Wichtig ist, dass im dem ersten Kassiervorgang die MwSt ausgewiesen wird.

2) Das oben angegebene Szenario kommt bei meinen Kunden auch vor, ich habe es aber etwas anders (schon vor Jahren) gelößt. Es gibt bei mir das (Unbare) Zahlungsmittel Kredit. Wenn ein Kunde die Ware ohne Zahlung mitnimmt, dann wird mit dem Zahlungsmittel "Kredit" kassiert. Damit haben wir dann einen Bruttoumsatz von 100€ und verwendete Zahlungsmittel von 100€. Wenn der Kunde später wieder kommt um zu zahlen, dann gibt es eine Position "Einzahlung Kredit". Dazu wird das dann verwendete Zahlungsmittel angegeben. Somit sind Bruttoumsatz und Zahlungsmittel wieder gleich. In er Auswertung für das Finanzamt werden gegebene Kredite und eingezahlte Kredite separat aufgelistet. Hat bisher jedes Finanzamt bei einer Steuerprüfung das so akzeptiert.

Für die TSE verwende ich dann das Zahlungsmittel Kredit als Unbar.

Meine Einträge würden dann so aussehen:

Zahlung 1:Beleg^100.00_0.00_0.00_0.00_0.00^100.00:Unbar
Zahlung 2:Beleg^0.00_0.00_0.00_0.00_0.00^100.00:Bar_-100.00:Unbar

Diese Angabe klingt für mich etwas logischer, weil die Bruttoumsätze und die zu entrichtende Steuer zusammenpassen.

Ob ich nun die Version von Gastro-Mis oder meine Version für die TSE verwende, muss ich mir noch überlegen. Gut das du dieses Thema angesprochen hast :wink:

na ja... Mal sehen

[michaelg]

@Bernau: Es ist wohl genauso, wie Du es erklärt hast. Da die Leistung schon erbracht wurde, wird das so gemacht, denn die MwSt. ist dann fällig (auch wenn noch kein Geld geflossen ist.)

Hier ist der Link:
https://support.gastro-mis.de/suppor...sichert-werden

Ich hatte bei Gastro-MIS auch nachgefragt und habe schnell eine Antwort bekommen:

Zitat:

die Vermögenszusammensetzung ändert sich schon, die Leistung wurde ja erbracht (Ware an Kunden übergeben). Somit ist auch zu diesem Zeitpunkt die Umsatzsteuer fällig - und die 100€ auf 19% korrekt. Da aber keine Zahlung erfolgt, wird der Vorgang als Forderungsentstehung abgeschlossen, mit -100€ auf 0% Steuer. Anders wäre der Ausgleich Summe Steuercontainer = Summe Zahlungen auch gar nicht möglich.

[u2020]

Hallo zusammen

ich bin neu in diesem Forum und auch neu in Delphi (habe erst Delphi Rio angefangen.

@Bernau: Vielen Dank für dein Testprogramm.

Für das korrekte erzeugen des QR-Codes musste ich in deinem Testprogramm ein paar Änderungen vornehmen:
Unit: cc.KassenSichV.DsFinVK.ProcessTypeData.types;

Code:

   Function TDsFinVKFormatProcs.ProcessDataBetragAsString(const aBetrag: Double): string;
  begin
      ...
   //  Result := FloatToStrF(aBetrag, ffGeneral, 15, 2, lFormatSettings);
       Result := FloatToStrF(aBetrag, ffFixed, 15, 2, lFormatSettings);   // Udo  31.07.2020  ffGeneral durch ffFixed ersetzt
  end;
                     

Function TDsFinVKFormatProcs.TransactionDateTimeAsString(const aDateTime: TDatetime): string;
begin
//Result := FormatDateTime('YYYY-MM-DDThh:mm:ss:fffZ', aDateTime);
  Result := FormatDateTime('yyyy-mm-dd"T"hh:nn:ss.zzz"Z"', aDateTime);       // udo 31.07.2020
end;

function TccDsFinVkTransactionData.QrCode: string;
begin
  Result :=
    'V0;' + // qr-code-version
    KassenSeriennummer + ';' +
    TccDsFinVkProcessTypeProc.EnumAsString(ProcessType) + ';' +
    ProcessData + ';' +
    IntToStr(TransaktionsNummer) + ';' +
    IntToStr(SignaturZaehler) + ';' +
    //IntToStr(TransaktionsNummer) + ';' +     // udo 31.07.2020               <---  diese Zeile muss raus 
    TDsFinVKFormatProcs.TransactionDateTimeAsString(StartZeit) + ';' +
    TDsFinVKFormatProcs.TransactionDateTimeAsString(LogTime) + ';' +
    SigAlg + ';' +
    LogTimeFormat + ';' +
    Signatur + ';' +
    PublicKey;
end;

Nach diesen Änderungen war die Prüfung des QR-Code OK.

Gruß
Udo

[bernau]

Zitat:

Zitat von u2020 (Beitrag 1470947)

Für das korrekte erzeugen des QR-Codes musste ich in deinem Testprogramm ein paar Änderungen vornehmen:

Super Danke.

Ich werde es einarbeiten.:thumb:

[michaelg]

Die WormAPI.DLL benutzt die VCRuntime140.dll, die Bestandteil des "Visual C++ Redistributable für Visual Studio 2015" ist.

95% unserer Anwender haben gar nicht das Kassenmodul. Es wäre blöd, wenn alle Anwender das nachinstallieren müssten, damit ihre Software weiter ordnungsgemäß startet.

Ich sehe bei der Art der DLL-Anbindung jedoch keine Chance, die DLL erst zu laden, wenn sie benötigt wird. Sehe ich das richtig oder gibt es einen Trick?

[bernau]

Da mein Kassenprogramm ein eigenständiges Programm, abgetrennt von unserer anderen Software ist, habe ich die Implementation mit der statischen Bindung einfach gemacht. Das setzt natürlich das vorhanden sein der DLL voraus. Es gibt auch die Möglichkeit mit LoadLibrary die DLL Dynamisch zu laden, dann muss aber viel umgeschrieben werden. Dafür fehlt mir leider die Zeit. Wobei mir das Dynamische Laden auch lieber ist.

[bernau]

Das Ganze dynamisch einzubinden war doch nicht so zeitaufwändig, wie ich dachte.

Es gibt jetzt Sie Version 0.2

[michaelg]

Meio mio, bist Du schnell...ich hatte vorhin einen DLL-Konverter angefangen, der war auch schon fast fertig...egal, was solls, wenigstens mal wieder was dazugelernt über die Unterschiede der DLL-Deklarationen.

Vielen Dank für Deine Mühe!!!!

[danielgrant007]

yes
we are in a hurry as well.
Are you trying to add or include Bundesdruckerei TSE?
It'd be much helpful.