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

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