DSFinV_K - Belegnummer & Export

[gross_friedrich]

Hallo,

ich habe hier ein paar Diskussionen über TSE, DSFinV_K und ähnliche Themen gelesen.
Daher hoffe ich, dass man mir bei der folgenden Frage helfen könnte:


DFKA Taxonomie:
Cash_point_closing/transactions/head/number (= Belegnummer = Bonnummer)

DSFinV_K V2.0:
Datei: Bonkopf -> BON_NR (Numerisch, 0 Dezimalstellen, Bonnummer)
lt. Anhang_G_Uebersicht.xlsx ist das Feld "BON_NR" ein Mussfeld (dunkel hinterlegt).

Kurzbeschreibung: Die Belegnummer ist die von der eingesetzten
Kasse vergebene eindeutige Nummerierung innerhalb eines Kassenabschlusses
und entspricht der auf dem Bon gedruckten Nummer.

d.h. das Feld "BON_NR", also die Belegnummer, ist ein Mussfeld (REQUIRED) und muss einen eindeutigen Wert haben.

Was wenn ein Vorgang abgebrochen wird?
Soweit ich verstanden habe, wenn ein Vorgang abgebrochen wird, wird für ("Cash_point_closing/transactions/head/type" = "Bonkopf -> BON_TYP") dann "AVBelegabbruch" angegeben.
Aber die Belegnummer (Bonnummer, Rechnungsnummer) wird doch erst vergeben, wenn ein Vorgang beendet ist, und die Rechnung/Bon erstellt wird.

Was wenn ein Vorgang abgebrochen wird, muss noch eine Beleg-/Rechnungsnummer vergeben werden? Und obwohl keine Rechnung erstellt wurde?
Wenn NEIN, was muss in das Feld "BON_NR"?

Die Frage gilt eigentlich auch für "AVTraining"!

Haben die Vorgangstypen "Beleg", "AVBelegabbruch" und "AVTraining" vielleicht verschiedene Nummernkreise?


Danke

[hhcm]

Hallo.

Zitat:

Aber die Belegnummer (Bonnummer, Rechnungsnummer) wird doch erst vergeben, wenn ein Vorgang beendet ist, und die Rechnung/Bon erstellt wird.

Wie identifizierst du denn deine Belege? Da gibt es doch sicherlich eine Serial, Autoincrement Spalte, GUID o.ä. Ich würde im Falle eines Abbruchs diese nutzen. Oder beim ersten hinzufügen eines Artikels direkt die "richtige" Belegnummer vergeben, auch wenn dieser Beleg später abgebrochen wird. Es geht sich schliesslich nur um die lückenlose Dokumentation. Belegnr. 1000 (Normaler Beleg) Beleg 1001 (Wurde abgebrochen)

[Neumann]

Gute Frage, ich mache das auch so das die Bonnummer erst am Ende des Vorgang generiert wird. Alles andere währe extrem schwierig.

Wenn jemand einen Bon abbricht wird er bei mir mit Wert in eine entsprechende Tabelle geschrieben. Denke ich nehme dann den Indexwert dieser Tabelle.

[gross_friedrich]

Danke, das hat mir geholfen.


@Neumann
Kurzbeschreibung: Die Belegnummer ist die von der eingesetzten
Kasse vergebene eindeutige Nummerierung innerhalb eines Kassenabschlusses
und entspricht der auf dem Bon gedruckten Nummer.

Innerhalb eines Kassenabschlusses sollte die Nummerierung also eindeutig sein.
Ich bin mir nicht sicher, aber darunter verstehe ich, dass die Belegnummern innerhalb eines Kassenabschlusses [Unique] sein sollten.

d.h. wenn die Indexwerte zweier Tabellen für die Nummerierung verwendet werden, dann ist es nicht mehr [Unique].

@hhcm
In der Richtung habe ich auch gedacht. d.h. wenn der Z-Abschlag erstellt wird, dann muss zwischen den Belegtypen differenziert werden:
z.B.
Bisher:
Anzahl Rechnungen 19
Letzte Rech-Nr. 19

Vielleicht sollte jetzt so sein:
Anzahl Beleg 10
Anzahl Belegabbruch 5
Anzahl Training 4
Belege ingesamt 19
Letzte Belegnummer 19

[jaenicke]

Man kann auch problemlos mehrere Nummernkreise verwenden. Man muss nicht für alle Kassen und für alle Funktionen die gleiche Nummerierung verwenden.

Theoretisch ist streng nach Gesetz noch nicht einmal eine fortlaufende Nummerierung erforderlich, sondern nur eine eindeutige. In der Praxis scheren sich die Prüfer allerdings nicht um das Gesetz und verlangen oft, dass die Belegnummern usw. fortlaufend sein sollen. Von daher lohnt sich der Ärger nicht, wenn man nicht fortlaufend nummeriert...
Es steht aber sogar noch einmal in der entsprechenden Ausführungsverordnung explizit drin, dass die fortlaufende Nummerierung nur ein Beispiel ist um das Ziel der Eindeutigkeit zu erreichen.

[Neumann]

Bonabbrüche zeichnen sich ja dadurch aus, dass kein Bon erzeugt wird. Also sollte ein Nummerkreis für diesen Vorgang unabhängig von den eigentlichen Bonnummern logisch sein.

Wir habe auch noch weitere Nummernkreise, wie Lieferscheine, Rechnungen, Kassenbuch. Sehe da kein Problem.

[gross_friedrich]

Die Frage habe ich an das Bundesministerium der Finanzen geschickt. Nun die Antwort:

vielen Dank für Ihre Anfrage hinsichtlich der DSFinV-K.

Dem Bundesministerium der Finanzen obliegen in erster Linie die Vorbereitung und Mitwirkung bei gesetzgeberischen Maßnahmen, Rechtsverordnungen und allgemeinen Verwaltungsvorschriften. Diese Aufgabenstellung macht es vom Umfang her leider nicht möglich, detaillierte Auskunfts- und Beratungsersuchen zu steuerlichen Sachverhalten und Fragestellungen zu beantworten.

Im Übrigen ist es mir durch die Gemeinsame Geschäftsordnung der Bundesministerien ausdrücklich verwehrt, Auskünfte zu Rechtfragen zu erteilen, die in einem Einzelfall von Bedeutung sein können und zu deren Entscheidung eine andere Behörde berufen ist. Nach dem Grundgesetz (Artikel 108 Absatz 2 GG) sind die Landesfinanzbehörden für die Durchführung der Steuergesetze und damit für die Beurteilung des Einzelfalls zuständig.

Allgemein bemerke ich Folgendes:

Eine Belegnummer muss nur für Vorgänge erstellt werden, die innerhalb eines bestimmten Zeitabschnitts des Gewinn bzw. den Verlust oder die Vermögenszusammensetzung in einem Unternehmen verändern. Hierzu zählen nicht Trainingsbuchungen, Sofort-Stornierung eines unmittelbar zuvor erfassten Vorgangs oder Belegabbrüche.

Ich hoffe, Ihnen damit geholfen zu haben.

[arnof]

Zitat:

Zitat von gross_friedrich (Beitrag 1456560)

Die Frage habe ich an das Bundesministerium der Finanzen geschickt. Nun die Antwort:

vielen Dank für Ihre Anfrage hinsichtlich der DSFinV-K.

Dem Bundesministerium der Finanzen obliegen in erster Linie die Vorbereitung und Mitwirkung bei gesetzgeberischen Maßnahmen, Rechtsverordnungen und allgemeinen Verwaltungsvorschriften. Diese Aufgabenstellung macht es vom Umfang her leider nicht möglich, detaillierte Auskunfts- und Beratungsersuchen zu steuerlichen Sachverhalten und Fragestellungen zu beantworten.

Im Übrigen ist es mir durch die Gemeinsame Geschäftsordnung der Bundesministerien ausdrücklich verwehrt, Auskünfte zu Rechtfragen zu erteilen, die in einem Einzelfall von Bedeutung sein können und zu deren Entscheidung eine andere Behörde berufen ist. Nach dem Grundgesetz (Artikel 108 Absatz 2 GG) sind die Landesfinanzbehörden für die Durchführung der Steuergesetze und damit für die Beurteilung des Einzelfalls zuständig.

Allgemein bemerke ich Folgendes:

Eine Belegnummer muss nur für Vorgänge erstellt werden, die innerhalb eines bestimmten Zeitabschnitts des Gewinn bzw. den Verlust oder die Vermögenszusammensetzung in einem Unternehmen verändern. Hierzu zählen nicht Trainingsbuchungen, Sofort-Stornierung eines unmittelbar zuvor erfassten Vorgangs oder Belegabbrüche.

Ich hoffe, Ihnen damit geholfen zu haben.

Danke für deine Info, ist hatte meine Stornofunktion schon in Beleg Abbruch umbenannt, damit man nicht mehr diskutieren muss ...

Die DSFinV-K macht mir echt zu schaffen:

Nach mehrfachem Lesen der zum Thema Stornieren und was DIE unter Stornieren verstehen bin ich zur folgenden Deutung gekommen:

"Sofortige Stornierung" ist mit TSE verboten: was ist das ? Meine Stornofunktion habe ich nun in Belegabbruch umbenannt (ist deine Antwort)

Beleg Storno(Seite 33 oben) wäre bei mir Storno vor dem Z-Bericht (Feld BON_STORNO = 1)

4.2.2 Nachträglich Stornierung: Deute ich als Stornierung nach dem Z-Bericht, so das eine Kopie als Stornobeleg angelegt werden muss und der Originalbeleg unverändert bleibt.

4.2.3 Postenstorno: im Bereich Handel, gibt es das normalerweise eigentlich nicht, wenn man sich vertan hat oder der Kunde sagt vor dem zahlen "das will ich nicht" ist das keine Stornierung. Mir fällt hier nur die Anwendung nach der Bestellung ein, d.h. Orderbon und dann wird das Bier wieder Storniert

Ob das richtig gedeutet ist weis man nicht ...

Was ist wenn man als Hersteller hier ein Sachverhalt anders umgesetzt hat (d.h. ein Prüfer sagt das ist Falsch)?
Noch ein Beispiel: wir bieten an Auftragsbestätigungen, Lieferscheine und Rechnungen aus der Kasse zu erstellen.

An der Stelle 4.2.7 steht Lieferschein ist als Beleg abzubilden, bei Erklärung zu AVTransfer steht, hiermit können Lieferscheine abgebildet werden .... Wo wird der Lieferschein weiterverarbeitetet, das kann man als Kassenhersteller nicht wissen ....

[herbstrot]

Moin,

ja man kann an manchen Stellen der DSFinV-K verzweifeln. Das beim Belegabbruch keine Belegnummer vorhanden sein muss, steht so auch nicht darin. Aber gut zu wissen ;)

Zitat:

"Sofortige Stornierung" ist mit TSE verboten: was ist das ? Meine Stornofunktion habe ich nun in Belegabbruch umbenannt (ist deine Antwort)

Beleg Storno(Seite 33 oben) wäre bei mir Storno vor dem Z-Bericht (Feld BON_STORNO = 1)

4.2.2 Nachträglich Stornierung: Deute ich als Stornierung nach dem Z-Bericht, so das eine Kopie als Stornobeleg angelegt werden muss und der Originalbeleg unverändert bleibt.

4.2.3 Postenstorno: im Bereich Handel, gibt es das normalerweise eigentlich nicht, wenn man sich vertan hat oder der Kunde sagt vor dem zahlen "das will ich nicht" ist das keine Stornierung. Mir fällt hier nur die Anwendung nach der Bestellung ein, d.h. Orderbon und dann wird das Bier wieder Storniert

Sofortige Stornierung gibt es nicht für Kassen mit TSE. Das gilt laut meinem Verständnis nur für Kassen mit Übergangsfrit die nicht aufrüstbar sind.
Beleg Storno wäre die Nachträgliche Vorgangs-Stornierung (4.2.2). Das kann unabhängig von Z-Bericht vorkommen.
Postenstorno machen wir mit dem Dublizieren der Position mit negativen Vorzeichen. Laut 4.2.3 darf die Position nicht einfach aus dem Bon verschwinden.
Sofern der Kunde sich entscheidet doch nicht zu kaufen machen wir einen Belegabruch. Vorgangsdaten können dann nach belieben definiert werden. Wir schreiben die Vorgangsdaten mit den Bruttobeträgen und stellen AVBelegabbruch^ vorran.

Ob das alle so richtig ist, da streiten sich die Gelehrten...

[arnof]

Laut 4.2.3 darf die Position nicht einfach aus dem Bon verschwinden.

Ja aber: bei Belegabbruch verschwinden doch alle Positionen ...

Abbruchbelege werden definitiv nicht in der DSFinV-K ausgegeben, da Sie keine Bonnummern haben ....

[herbstrot]

Moin,

Zitat:

Zitat von arnof (Beitrag 1456570)

Ja aber: bei Belegabbruch verschwinden doch alle Positionen ...

Bei einem Belegabruch bleibt der Belege erhalten und wird entsprechend markiert, so das er in der Kasse nicht berechnet wird.
Laut der Definition zu AVBelegabruch bleibt der Beleg erhalten, so zumindest verstehe ich das. Und da die Finanz sämtliche Vorgänge per TSE abgesichert haben will kann man den Beleg ja nicht einfach löschen.

[arnof]

Eine Belegnummer muss nur für Vorgänge erstellt werden, die innerhalb eines bestimmten Zeitabschnitts des Gewinn bzw. den Verlust oder die Vermögenszusammensetzung in einem Unternehmen verändern. Hierzu zählen nicht Trainingsbuchungen, Sofort-Stornierung eines unmittelbar zuvor erfassten Vorgangs oder Belegabbrüche.


Hier sind wir wieder auf Anfang.

Belegabbrüche müssen ja der TSE übergeben werden, sonst bekommt man offene Transaktionen.

Der DSFinV-K kann man diese aber nicht ausgeben, da die BONNummer ein Pflichtfeld ist

[jaenicke]

Der Wortlaut ist ja nur "muss nicht erzeugt werden", nicht "darf nicht erzeugt werden". Von daher machen wir es so wie vorher auch und buchen alles sauber mit entsprechender neuer Rechnungsnummer gegen. Nur die Nummerierung müssen wir evtl. noch ändern.

Zitat:

Zitat von herbstrot (Beitrag 1456568)

Postenstorno machen wir mit dem Dublizieren der Position mit negativen Vorzeichen. Laut 4.2.3 darf die Position nicht einfach aus dem Bon verschwinden.

Das ist ja auch schon seit vielen Jahren so. Verschwinden darf gar nichts, weder ein Sofortstorno, noch ein normaler Zeilenstorno, noch eine Trainingsbuchung, usw.
Und das muss auch mit DSFinVK so gehen... ob das richtig interpretiert ist, wird sich in den nächsten Jahren herausstellen...

[hhcm]

Zitat:

Zitat von arnof (Beitrag 1456570)

Abbruchbelege werden definitiv nicht in der DSFinV-K ausgegeben, da Sie keine Bonnummern haben ....

Das lese ich aber anders.
Bzw. finde ich nichts darüber das es nicht ausgegeben werden muss.

[arnof]

Ja ja, war heute Nachmittag bei einer IHK Veranstaltung zum Thema: Vortagender ein GF eines "großen" Kassenherstellers und DateV. Dem Kassenhersteller musste ich mal sagen, das seine App (self Checkout, da würde man keine TSE brauchen) komplett gegen die Kassenrichtlinie verstößt , zum Thema hatte er keine Ahnung, aber eine TSE hat er schon gesehen .... Die Software muss noch angepasst werden :lol:

Der DateV Mann wusste einiger massen Bescheid, ich musste aber auch einige male Widersprechen.

Fazit: die Verunsicherung ist noch sehr groß

[arnof]

Zitat:

Zitat von hhcm (Beitrag 1456577)

Zitat:

Zitat von arnof (Beitrag 1456570)

Abbruchbelege werden definitiv nicht in der DSFinV-K ausgegeben, da Sie keine Bonnummern haben ....

Das lese ich aber anders.
Bzw. finde ich nichts darüber das es nicht ausgegeben werden muss.

Ich habe nochmals nachgelesen und Zitire aus der DSFinV-K

4 Inhaltliche Vorgaben der DSFinV-K Gliederungsebenen für Kassenabschluss-Summen Der Kassenabschluss ist die aggregierende Zusammenfassung einer Kasse über alle Einzelbewegungen mit dem Vorgangstyp „Beleg“ (Geschäftsvorfall) für einen bestimmten Zeitraum (vgl. Anhang B). Dadurch werden ausschließlich Geschäftsvorfälle aggregiert, die für die umsatzsteuerliche und/oder ertragsteuerliche Weiterverarbeitung Relevanz besitzen


4.1.1 Gliederung 1: BON_TYP (Vorgangstyp) Geschäftsvorfälle und andere Vorgänge sind einzeln, vollständig, richtig, zeitgerecht und geordnet aufzuzeichnen (§ 146a Abs. 1 Satz 1 AO). Um dies zu gewährleisten, unterscheidet die DSFinV-K zwischen den Vorgangstypen „Beleg“ und mehreren „Anderen Vorgängen“ (vgl. Anhang B). Der Unterschied zwischen „Beleg“ und „Anderen Vorgängen“ besteht in der Weiterverarbeitung und der Relevanz für den Kassenabschluss. Alle Vorgänge mit der Kennzeichnung „Beleg“ stellen für die Weiterverarbeitung vorzusehende Vorgänge dar. Alles andere wird nicht im Kassenabschluss berücksichtigt und beginnt mit dem Präfix „AV“.

Also wie soll man einen AVBelegabbruch ausgeben, die komplette DSFinV-K bezieht sich auf den Kassenabschluss ?!

[hhcm]

Zitat:

Zitat von arnof (Beitrag 1456627)

Also wie soll man einen AVBelegabbruch ausgeben, die komplette DSFinV-K bezieht sich auf den Kassenabschluss ?!

Du Zitierst es doch selbst. Es wird nicht aggregiert.
Was hat aber der Kassenabschluss mit dem Export ansich zu tun?

Beim Kassenabschluss kann es doch Stornierte oder abgebrochene Belege geben. Diese sollen nur nicht in die Summen eingerechnet werden. d.H in UMS_BRUTTO des Bonkopfes werden Belegabbrüche ausgenommen. Trotzdem werden diese Belege exportiert. Sonst wäre der Bontyp AVBelegabbruch ziemlich sinnfrei.

[arnof]

Das sind die Fragen:

was muss man tun, damit es passt?

Zum Thema Export:

Der Export ist in der DSFinV-K geregelt und nur da! Ausser den Stammdaten bezieht sich das alles auf den Kassenabschluss: in jeder Datei steht im Kopf die Angabe des Kassenabschlusses auf den sich die weiteren Angaben beziehen.

Jetzt zitiere ich nochmals von Seite 38:

Unter anderen Vorgängen sind Aufzeichnungsprozesse zu verstehen, die nicht durch
einen Geschäftsvorfall, sondern durch andere Ereignisse im Rahmen der Nutzung des
elektronischen Aufzeichnungssystems ausgelöst werden und zur nachprüfbaren Doku-
mentation der zutreffenden und vollständigen Erfassung der Geschäftsvorfälle notwen-
dig sind. Hierunter fallen beispielsweise Trainingsbuchungen, Sofort-Stornierung eines
unmittelbar zuvor erfassten Vorgangs, Belegabbrüche, erstellte Angebote, nicht abge-
schlossene Geschäftsvorfälle (z.B. Bestellungen).
Nicht alle in einer Kasse verwalteten Vorgänge sind für die Erreichung der Schutzziele
erforderlich. Für die Erreichung der Schutzziele nicht erforderliche Vorgänge müssen
nicht abgesichert werden (z.B. Bildschirmeinstellung heller/dunkler; Überwachung der
Prozessor-Temperatur etc.).
Abzusichernde Funktionsaufrufe (Systemfunktionen) und Ereignisse innerhalb der tech-
nischen Sicherheitseinrichtung (Audit-Daten) werden in der BSI TR-03153 definiert (vgl.
AEAO zu § 146a Nr.

[hhcm]

Da steht auch eher das es Exportiert werden muss.

[ISMIRSCHLECHT]

Moin,

stellt ein Kunde fest, daß er kein Geld mithat oder so, d.h. wird der Kassenbildschirm geleert, ist bei und eine Bonnummer leider schon erzeugt.
Die Posten werden aber gelöscht, so daß jetzt eine begonnenene Transaktion in der Kasse rimhängt.
Laut Hlpdesk Kann man diese mit dem Fnish
'AVBelegabbruch^0.00_0.00_0.00_0.00_0.00^' der TSE mitteilen.

Vielleicht hilfts...

ism

[hhcm]

Ich würde mal sagen "Posten löschen" darf auf keine Fall passieren. Als gelöscht/storniert markieren ja, löschen auf keinen Fall.

[Frickler]

Zitat:

Zitat von hhcm (Beitrag 1456640)

Da steht auch eher das es Exportiert werden muss.

Genau. Es wird exportiert, aber nicht summiert.

Soweit mir bekannt, ist eine Neufassung der DSFinV-K in Arbeit. Zumindest wurde sie im Dezember 2019 inoffiziell angekündigt. Dabei werden angeblich hauptsächlich Unsauberkeiten ausgebügelt. Ich hoffe mal, dass dort so Unschönheiten dabei sind wie dass der Anfangsbestand (was nach dem Abschluss noch in der Kasse ist) ein Beleg ist, statt was eigentlich richtig wäre, ein sonstiger Vorgang. Oder das Handling BON_NR vs BON_ID: Alle AVDingsbums haben eine BON_ID, sollten aber eigentlich keine BON_NR haben. Denn BON_NR ist die Nummer, die man auf den Bon druckt.

[himitsu]

Warum doppelt und nicht gleich BON_ID=BON_NR?

Was auf dem Bon steht, entspicht dann auch intern direkt dem Bon.

[arnof]

Zitat:

Zitat von Frickler (Beitrag 1456647)

Zitat:

Zitat von hhcm (Beitrag 1456640)

Da steht auch eher das es Exportiert werden muss.

Genau. Es wird exportiert, aber nicht summiert.

Soweit mir bekannt, ist eine Neufassung der DSFinV-K in Arbeit. Zumindest wurde sie im Dezember 2019 inoffiziell angekündigt. Dabei werden angeblich hauptsächlich Unsauberkeiten ausgebügelt. Ich hoffe mal, dass dort so Unschönheiten dabei sind wie dass der Anfangsbestand (was nach dem Abschluss noch in der Kasse ist) ein Beleg ist, statt was eigentlich richtig wäre, ein sonstiger Vorgang. Oder das Handling BON_NR vs BON_ID: Alle AVDingsbums haben eine BON_ID, sollten aber eigentlich keine BON_NR haben. Denn BON_NR ist die Nummer, die man auf den Bon druckt.

Neufassung würde Sinn machen, vom Dr. Till hatte vorgetragen, das der DFKA mit dem BSI die endgültige Fassung in einer Nachtkonferenz zusammen "gekloppt" haben. Problem, der ist ein Gastro Kassen Mann, der sicher manches anders sieht als Retail .....

[Frickler]

Zitat:

Zitat von himitsu (Beitrag 1456664)

Warum doppelt und nicht gleich BON_ID=BON_NR?

Was auf dem Bon steht, entspicht dann auch intern direkt dem Bon.

Die BON_ID ist mehr so ein Primary Key für jeglichen Vorgang, beispielsweise auch für einen Bonabbruch. Ein abgebrochener Bon wird ja nicht gedruckt. Wenn ich dafür eine BON_NR verbrate, hat die Liste der Bonnummern eine Lücke...

[Frickler]

Zitat:

Zitat von arnof (Beitrag 1456666)

Neufassung würde Sinn machen, vom Dr. Till hatte vorgetragen, das der DFKA mit dem BSI die endgültige Fassung in einer Nachtkonferenz zusammen "gekloppt" haben. Problem, der ist ein Gastro Kassen Mann, der sicher manches anders sieht als Retail .....

Leider gibt es auch viel zu wenig Beispiele in der DSFinV-K, beispielsweise gibt es nicht ein Beispiel zu einem "anderen Vorgang". Ich würde mir auch mal einen kompletten Kassenabschluss mit allen, was am Tag so passiert als Beispiel wünschen.
Ich schätze ja, dass es das alles bereits gibt. Nur halt ausschließlich für Mitglieder des DFKA, nicht für die Allgemeinheit...

[Neumann]

Für die Sachen, die keine Bonnummer haben, könnte man folgendes machen:

a: 0
b: Zufallszahl
c: Eine aus Datum und Uhrzeit generierte Zahl wie int(now*1000)

Ich denke c ist die beste Wahl.

Kassenbonnummern kann man 12-stellig machen, dann kollidieren diese nicht mit Kassenbuch-Belegnummern.

Einen Kassenbestand gibt es bei mir als Buchung nicht, der wird immer aktuell berechnet. Muss der einen Eintrag im Kassenbuch haben?

[Frickler]

Zitat:

Zitat von Neumann (Beitrag 1456685)

Einen Kassenbestand gibt es bei mir als Buchung nicht, der wird immer aktuell berechnet. Muss der einen Eintrag im Kassenbuch haben?

DSFinV-K Seite 51, "Anfangsbestand".

[arnof]

Zitat:

Zitat von Neumann (Beitrag 1456685)

Für die Sachen, die keine Bonnummer haben, könnte man folgendes machen:

a: 0
b: Zufallszahl
c: Eine aus Datum und Uhrzeit generierte Zahl wie int(now*1000)

Ich denke c ist die beste Wahl.

Kassenbonnummern kann man 12-stellig machen, dann kollidieren diese nicht mit Kassenbuch-Belegnummern.

Einen Kassenbestand gibt es bei mir als Buchung nicht, der wird immer aktuell berechnet. Muss der einen Eintrag im Kassenbuch haben?

Echt jetzt; das widerspricht ja allem: Eindeutig und Fortlaufen, alles andere ist Steuerschätzung mit Schadensersatz vom Kunden .....

[hhcm]

Zitat:

Zitat von arnof (Beitrag 1456768)

Echt jetzt; das widerspricht ja allem: Eindeutig und Fortlaufen, alles andere ist Steuerschätzung mit Schadensersatz vom Kunden .....

DA muss ich auch "Echt jetzt" sagen.

Es ist hilfreich fortlaufende Nummern zu haben. Gesetzlich ist das m.E nach nicht geregelt.
Ich war mal wegen der GoBD auf einem Seminar, da wurde lediglich die Nachvollziehbarkeit angesprochen.
Ich kann eine Bonnummer 1 und danach eine Bonnummer 560 haben. Ich muss nur erklären bzw. niederschreiben warum das so ist.

Im Prinzip geht es nur um die Nachvollziehbarkeit. Egal ob KassenSichV, GoBD, RKSV etc. pp.

Wir nutzen hier für alles einen eigenen Nummernkreis. Sei es für Rechnungen, Angebote, Kassenbelege.
Sollte es mal zu keinem Vorgang kommen, wird dafür die Autoincrement-ID des SQL Servers genommen. Der Vorgang ist schließlich bereits angelegt. Das ist Nachvollziehbar und schlüssig - Selbst für einen Steuerprüfer.

[arnof]

Nummerierung muss Fortlaufend und Lückenlos sein. Pro Vorgangsart kann man einen eigenen Nummernkreis haben.

Aber

a: 0
b: Zufallszahl
c: Eine aus Datum und Uhrzeit generierte Zahl wie int(now*1000)

das ist ein völliges KO Kriterium, ich weiß nicht ob Du schon mal eine Betriebsprüfung hattest (bei euch bzw Kunden), bei der digitalen Betriebsprüfung ist das das erste was geprüft wird. Fehlt da was (Lücken), dann ist die Prüfung beendet und die Schätzung läuft.

[hhcm]

Zitat:

Zitat von arnof (Beitrag 1456781)

ich weiß nicht ob Du schon mal eine Betriebsprüfung hattest (bei euch bzw Kunden), bei der digitalen Betriebsprüfung ist das das erste was geprüft wird. Fehlt da was (Lücken), dann ist die Prüfung beendet und die Schätzung läuft.

Ja, wir hatten selbst schon eine Betriebsprüfung und auch bei den Kunden gab es diese.
Fehlt da was muss geklärt werden WARUM.
Da wurde nichts geschätzt wenn es Plausibel ist.

Es bleibt bei der Nachvollziehbarkeit. Fehlt eine Nummer und man kann diese durch ein Storno belegen, interessiert es niemanden.

[jaenicke]

Zitat:

Zitat von arnof (Beitrag 1456781)

Nummerierung muss Fortlaufend und Lückenlos sein.

Das ist eine Legende, die sich schon ewig hält. Vor den neuen Regeln heute (wo ich nicht geschaut habe wie es da ist, weil wir ohnehin fortlaufend nummerieren, aber da der unten genannte Text auch aktuell noch so als Erlass aufgeführt wird...) gab es extra noch einmal eine Klarstellung vom BMF, dass eine fortlaufende Nummerierung nicht gefordert wird. Sie ist nur ein Weg um die (vorgeschriebene) Eindeutigkeit zu gewährleisten.

Ich weiß allerdings, dass man selbst vielen Prüfern und Steuerberatern den entsprechenden Text erst zeigen muss bevor sie es glauben...

Zitat:

(10) 1
Durch die fortlaufende Nummer (Rechnungsnummer) soll sichergestellt werden, dass die vom
Unternehmer erstellte Rechnung einmalig ist. 2
Bei der Erstellung der Rechnungsnummer ist es zulässig, eine
oder mehrere Zahlen- oder Buchstabenreihen zu verwenden. 3
Auch eine Kombination von Ziffern mit
Buchstaben ist möglich. 4
Eine lückenlose Abfolge der ausgestellten Rechnungsnummern ist nicht zwingend.

Quelle:
Umsatzsteuer-Anwendungserlass vom 1. Oktober 2010, BStBl I S. 846 – aktuelle Version
(Stand 19. Dezember 2019) – nach dem Stand zum 31. Dezember 2018
https://www.bundesfinanzministerium....ationFile&v=12
Seite 478

[arnof]

@jaenicke: das ist doch klar, lese doch mal was er schreibt:

Zufallfszahl oder Datum mit Uhrzeit als Nummer mit fortlaufend und nachvollziehbar hat das nichts zu tun. Aber jeder der es besser weiß kann gerne tun was er will, sowas ist aber zu 100% falsch. Ich diskutiere auch nicht mehr darüber da viele vieles meinen aber keiner was weiß :wink:

[Neumann]

Es geht mir nicht um Kassenbon- oder Rechnungsnummern, sondern um sonstige Vorgänge.

[arnof]

Zitat:

Zitat von Neumann (Beitrag 1456812)

Es geht mir nicht um Kassenbon- oder Rechnungsnummern, sondern um sonstige Vorgänge.

da bekommst Du eine eindeutige Nummer von der TSE ist auf alle Fälle besser als Zufallszahlen