DSFinV_K - Belegnummer & Export

[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 von hhcm:

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

Zitat von hhcm:

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

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

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

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

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

[hhcm]

Zitat von arnof:

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.