Fortlaufende lückenlose Rechnungsnummern

[IBExpert]

Moin,

ich war heute beim Delphitreff in Köln eingeladen und da gab es neben diversen anderen hochinteressanten Diskussionsthemen auch ein Thema, was sicherlich auch viele hier in der dp interessiert.

Es geht um das leidige Thema fortlaufende lückenlose Rechnungsnummern. Das einzige Problem bei der Vergabe fortlaufender lückenloser Rechnungsnummern ist wohl in erster Linie die fehlende Fortbildung der Finanzamtsprüfer bezgl. Entscheidungen im eigenen Haus und das Steuerberater auch nicht immer alles wissen.

Eine solche Regel, das Rechnungsnummern fortlaufend lückenlos sein müssen, gibt es nämlich nicht.

Da aber ein Prüfer, der einfach das Gegenteil behauptet, sich nicht so einfach mit Behauptungen oder Einträgen in irgenwelchen Internetforen überzeigen lässt, hier eine konkrete Quelle, mit der jeder Eurer Kunden das Diskussionsthama umgehend beenden kann. Auch die Aussagen von irgendwelchen Steuerberatern könnt Ihr damit abschmettern und Ihr könnt die Arbeit in sinnvolle Programmfunktionen investieren. Das gilt schon seit 2011, wurde erstmalig aber schon 2008 in Koblenz von der Oberfinanzdirektion schriftlich festgelegt.

bundesfinanzministerium Umsatzsteuer-Anwendungserlass Stand-31-12-2011

Seite 506:

Fortlaufende Nummer (Rechnungsnummer)
(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.
5 Es ist auch zulässig, im Rahmen eines weltweiten Abrechnungssystems verschiedener, in unterschiedlichen Ländern
angesiedelter Konzerngesellschaften nur einen fortlaufenden Nummernkreis zu verwenden.
(11) 1 Bei der Erstellung der Rechnungsnummer bleibt es dem Rechnungsaussteller überlassen, wie viele und
welche separaten Nummernkreise geschaffen werden, in denen eine Rechnungsnummer jeweils einmalig
vergeben wird. 2 Dabei sind Nummernkreise für zeitlich, geographisch oder organisatorisch abgegrenzte Bereiche
zulässig, z.B. für Zeiträume (Monate, Wochen, Tage), verschiedene Filialen, Betriebsstätten einschließlich
Organgesellschaften oder Bestandsobjekte.
3 Die einzelnen Nummernkreise müssen dabei nicht zwingend
lückenlos sein.
4 Es muss jedoch gewährleistet sein (z.B. durch Vergabe einer bestimmten Klassifizierung für
einen Nummernkreis), dass die jeweilige Rechnung leicht und eindeutig dem jeweiligen Nummernkreis
zugeordnet werden kann und die Rechnungsnummer einmalig ist.

Wem damit geholfen ist, der darf mir auf den Delphi Tagen ein Bier ausgeben

[mm1256]

Zitat von IBExpert:

Wem damit geholfen ist, der darf mir auf den Delphi Tagen ein Bier ausgeben

Das mit dem Bier können wir so machen. Ich werde auch da sein.

Allerdings ist die Angelegenheit nicht ganz so rund wie es den Anschein hat. Wenn ein Betriebsprüfer Lücken in den Rechnungsnummernkreisen findet (ich verwende bewusst den Plural, weil sich bei nicht lückenlosen Rechnungsnummern zwangsläufig mehrere Nummernkreise ergeben) dann läuten bei ihm erst mal die Alarmglocken. Die Glocken klingen erst dann langsam aus, wenn für mehrere Nummernkreise ein offensichtlicher Anlass gegeben ist, z.B. das Ausstellungsjahr als Präfix.

Sind die Nummern innerhalb eines Nummernkreises fortlaufend und lückenlos, ist das i.d.R. nicht verdächtig. Fehlen aber Nummern, schauen die Betriebsprüfer sehr genau nach, was die Ursachen sind. Spätestens dann werfen die Betriebsprüfer auch einen Blick auf die verwendete Software. Stellt diese die Möglichkeit lückenloser Belegnummernvergabe zur Verfügung, zerlegen die Betriebsprüfer die komplette Buchhaltung. Dabei kommt es auch zu vollständigem Einblick in alle beteiligten Programme. Was die Prüfer dabei alles prüfen, kontrollieren, nachrechnen usw. übersteigt oftmals das Vorstellungsvermögen der Anwender.

Und, sie werden in der Regel auch fündig. Klar, die Daseinsberechtigung muss abgegeben werden. Er muss etwas finden und die Frage ist lediglich, wo er beginnt, und welchen Aufwand er betreiben muss

Lückenhafte Nummernkreise sind darum geradezu eine Einladung an dieser Stelle mit der Suche zu beginnen. Die Frage aus Sicht des Anwenders ist also, wie halte ich es mit lückenhaften Nummernkreisen und dem sich daraus ergebenden "Generalverdacht"?

Aus rein rechtlicher Sicht stimme ich deinen Ausführungen vollständig zu. Die Praxis zeigt aber, dass es gute, vernünftige, und aus Anwendersicht auch lohnende Argumente für die Verwendung lückenloser Belegnummern gibt. Darum habe ich beispielsweise ungeachtet der Rechtslage in meiner SW ein eingebautes "Warnsystem" das den Anwender vor Lücken in den Belegnummern warnt. Wobei ich hier bewusst den Begriff "Belegnummern" verwende, und nicht "Rechnungsnummern", denn man ist aufgrund der Rechtslage (Stichwort "Stornierung von Belegen") gut beraten, wenn man für den Belegausgang (Rechnungen, Gutschriften, Abschlagsrechnungen, Stornierungen...) einen einzigen lückenlosen Nummernkreis generiert.

Aus datenbanktechnischer Sicht sind lückenlose Belegnummern kein Problem und darum sollte vielleicht die Frage erlaubt sein, warum man es als Entwickler/Programmierer/SW-Hersteller nicht tun sollte?

[haentschman]

Moin...
Eigentlich mußt du mir ein Bier ausgeben. Du hast meine Lüge an meine Frau auffliegen lassen. Vor ein paar Tagen hatten wir das Thema. Schon erstaunlich, dieses "Gerücht" philosophiere ich schon seit Jahren.
Nachtrag:
Das "Generalverdacht" Argument hat auch seine Berechtigung.

[IBExpert]

Zitat:

Sind die Nummern innerhalb eines Nummernkreises fortlaufend und lückenlos, ist das i.d.R. nicht verdächtig. Fehlen aber Nummern, schauen die Betriebsprüfer sehr genau nach, was die Ursachen sind.

Und wie wehrt man sich dagegen? Ganz einfach, es sind immer ungleiche Lücken zwischen den Rechnungsnummern, weil zum Beispiel jede neue Rechnungsnummer um random(xxx) erhöht wird.

Da es keiner verbietet, seine Rechnung auch mit word oder excel zu schreiben und sich die "Rechnungsnummer" auch komplett auszdenken, muss man dem Prüfer, der entgegen der Anweisung von seiner eigenen Behörde handelt, ja kein Ansatzpunkt bieten.

Warum sollte ein kleiner freiberuflicher Programmierer mit wenigen Kunden seinem Kunden durch die lückenlose Rechnungsnummer direkt klar machen, das er gar keine anderen Kunden hat und von Ihm als einzige Einnahmequelle abhängig ist?

Also schreibt man auf die Rechnung gar keine Rechnungsnummer, sondern nutzt als eindeutige Identifikation zum Beispiel das Tagesdatum mit einem suffix -01 oder so. Da viele Freiberufler gar nicht täglich eine Rechnung schreiben, bleiben da reichlich Lücken.

Aber auch als Onlinehändler schafft das nicht gerade vertrauen, wenn du Mitte des Jahres die Rechnungsnummer *00099 erzeugst. Daraus würde ich direkt den Schluss ziehen, das es im ganzen Jahr nicht mehr als 99 Verkäufe gab. Bei dem Verkäufer würde ich nicht noch mal kaufen, da er aufgrund der geringen Verkaufszahl sicherlich in ein paar Wochen seinen Shop dicht machen muss, also ich auf Gewährleistungsansprüche sitzen bleibe, weil man davon nicht leben kann. Ob der überhaupt davon leben muss oder einen Laden betreibt, in dem er deutlich mehr als online verkauft, aber andere Nummernkreise benutzt, kann man nicht erkennen.

Wenn du die Erfahrung mit Betriebsprüfern hast, das die entegen der Anweisung vom Finanzministerium trotzdem irgendwelche Interpretationen in kückenhafte Nummernkreise haben, sollte man den einfach den Wind aus den Segeln nehmen und konsequent für nicht nachvollziehbare Lücken sorgen, denn das ist explizit erlaubt!

[Mavarik]

Zitat von mm1256:

Aus datenbanktechnischer Sicht sind lückenlose Belegnummern kein Problem und darum sollte vielleicht die Frage erlaubt sein, warum man es als Entwickler/Programmierer/SW-Hersteller nicht tun sollte?

Doch genau das ist es... Daher resultiert auch der Einwurf von IBExpert

Zitat von IBExpert:

ich war heute beim Delphitreff in Köln eingeladen und da gab es neben diversen anderen hochinteressanten Diskussionsthemen auch ein Thema, was sicherlich auch viele hier in der dp interessiert.

Danke für Dein kommen!

Wo liegt das Problem? Ganz Einfach.

Gegeben Sei Büro A und Büro B... Bei Büros verbinden sich mit dem gleichen Server auf dem die Rechnungsdatenbank liegt.

Natürlich muss sicher gestellt werden, dass die Büros arbeiten können, auch wenn keine Internetverbindung besteht... Hierfür wird ein lokaler Server verwendet der sich mit dem zentralen Server synchronisiert...

Wenn also die Internetverbindung fehlt, gibt es keine Vergabestelle für die zentrale Rechnungsnummer.

Daher getrennte Rechnungsnummernkreise...

Mavarik

[IBExpert]

Zitat:

Aus datenbanktechnischer Sicht sind lückenlose Belegnummern kein Problem und darum sollte vielleicht die Frage erlaubt sein, warum man es als Entwickler/Programmierer/SW-Hersteller nicht tun sollte?

Sogar wenn du nur eine Quelle für deine Nummernvergabe hast, entsteht bei Installationen mit mehreren Clients eine gewisse Wahrscheinlichkeit, das irgendwann mal 2 Clients gleichzeitig eine neue Rechnung erzeugen und in beiden Programmen der Wert der letzten Rechnungsnummer auf Basis des aktuellen Werts +1 ermittelt wird.

Beide haben aber vielelicht schon erfolgreich per update den letzten Wert je um 1 erhöht, abermindestens einer bekommt beim Speichern wegen einem Unique Index auf der Rechnungsnummer in der Datenbank eine Exception.

Wenn der durch die Exception dann den Vorgang einfach noch mal macht, ist eine Lücke in den Rechnungsnummern. Diese dann generell wieder aufzufüllen mit der noch fehlenden Rechnungssnummer ist zwar eine nette Idee, aber spätestens bei Jahreswechsel eine sehr blöde Idee. Ob das durch deine Datenbank serialisiert wird und durch Transaktionen sauber abgearbeitet wird oder du andere Techniken eingebaut hast, sei hier jetzt mal offen, natürlich lässt sich so was pro Server mehr oder weniger sauber realisieren, insbesondere wenn der Transaktionen unterstützt. Es bleibt aber dabei, das die bewusste Einplanung von Lücken da eine Menge Arbeit einspart.

Und es gibt durchaus Systeme, da reden wir nicht über 2 oder 3 Rechner, an denen Rechnungen geschrieben werden, sondern wo dutzende Abteilungen im Unternehmen verteilt das machen. Die Chance, das es dann knallt, steigt sehr schnell an. Und wenn die dann noch an unterschiedlichen Standorten verteilt sind, sind Nummerkreise pro Standort sowieso erforderlich, um die Forderung nach Eindeutigkeit erfüllen zu können. Eine Forderung der Lückenlosigkeit gibt es aber nicht.

[Phoenix]

Sagen wir es mal so:

Seit Jahren vergebe ich Rechnungsnummern immer yyyymmdd/xxx wobei xxx meist 001 ist, und falls ich doch mal mehrere Rechnungen an einem Tag schreibe habe ich für 998 andere Platz

Noch nie hat ein Prüfer darüber gemeckert.

[mkinzler]

Dann hast Du für jeden Tag einen Nummernkreis, und der ist wieder lückenlos.

[Dejan Vu]

Also rein technisch sollte sich das durch den entsprechenden Isolation Level lösen lassen. Aber darum geht es ja nicht, sondern darum, ob man sich die Mühe machen sollte. Denn entweder bekommt man es 100% hin (dann schadet es nicht und erleichtert die Arbeit des Prüfers), oder man bekommt es nicht hin. Dann sollte man es aber auch nicht versuchen, weil dann der Prüfer ins Grübeln kommt.

Ich habe immer das Tagesdatum genommen. Eine GUID hätte aber auch etwas sehr charmantes. Man könnte sich auch z.B. die Liste aller Top-10 Hits der letzten 50 Jahre aus Indien nehmen und vergeben, das wäre doch lustig: "Bitte überweisen Sie den Betrag unter Angabe der Rechnungsnummer:"Phir Se Ud Chala / Mohit Cauhan" bis zum 29.6.2015...

[Sir Rufo]

Lückenlose Rechnungsnummern sind kein Problem, wenn man sich vorher Gedanken macht.

Auch bei unterschiedlichen Standorte die nur zeitweise Kontakt zum Haupt-Server haben ist das realisierbar. Indem jeder Standort seinen eigenen Nummernkreis hat. Dieses wird tagtäglich auf der ganzen Welt benutzt und jeder ist damit schon in Berührung gekommen.

Einfach mal in eine Tankstelle (oder wo auch immer) und eine Packung Kaugummis (oder was auch immer) kaufen.

Dann einen Blick auf die Bon-Nummer werfen.

Wer glaubt denn jetzt, dass die Kassen erst eine Verbindung mit irgendeinem Server herstellen um die korrekte Bon-Nummer zu erzeugen?

Gut - ich auch nicht.

Zum Dilemma fortlaufende Nummer - Information an den Kunden - Betriebsprüfer:

Auch dieses Problem ist einfach zu lösen:

Da die Rechnungsnummer nicht zwangsläufig numerisch sein muss, kann man also die echte (fortlaufende) Nummer dadurch verstecken, dass man aus der Nummer und der Uhrzeit eine neue Nummer bildet und diese dann entsprechend kodiert. Die Rechnungsnummern sehen dann so aus, wie auf den amazon Rechnungen. (Eine Prüfziffer kann man auch noch implementieren)

Dem Betriebsprüfer gibt man dann den Algorithmus an die Hand, mit dem er nachprüfen kann, dass es keine Lücken gibt. Der Kunde kann aber anhand der ihm mitgeteilten Rechnungsnummer nicht auf die Anzahl der bisher geschriebenen Rechnungen schliessen.

Eindeutig sind diese Rechnungsnummern auch, selbst wenn zum gleichen Zeitpunkt mehrere Rechnungen geschrieben werden.