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

[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

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 von 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".

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 von michaelg:

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 von michaelg:

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 von jaenicke:

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.

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

[bernau]

Zitat von michaelg:

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

Beim Testprogramm. Gerne. Gute Idee.