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

[bernau]

Zitat von michaelg:

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

Kannst du den Link hier posten?

Zitat von michaelg:

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

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

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

Super Danke.

Ich werde es einarbeiten.

[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