Fortlaufende lückenlose Rechnungsnummern

**p80286**

Zitat von frankyboy1974:

Hallo,

ich möchte hier nun mal auf "Nathan der Weise" von Lessing verweisen, von 42 die Quersumme ist 6 und die Hälft von 6 ist 3.

mfg

Frank

Ergibt das im Zusammenhang hier einen Sinn, oder wolltest du nur auch mal was schreiben?

Der Klartext ist wohl, "Ihr wälzt hier ein Problem, daß keines ist".

Gruß
K-H

**bernau**

Zitat von frankyboy1974:

Hallo,

ich möchte hier nun mal auf "Nathan der Weise" von Lessing verweisen, von 42 die Quersumme ist 6 und die Hälft von 6 ist 3.

Du wiederholst dich! Wenn dir die Diskussion nicht gefällt, dann musst du die nicht lesen. Es zwingt dich keiner.

**IBExpert**

Zitat von bernau:

Zitat von mkinzler:

Bei Einnahmen-/Überschuß-Rechnung ist die Zahlung massgebend.

Das zweifelt keiner an.

Genau, und das Problem ist aber bei EÜR keineswegs verschwunden, denn ob der Rechnungsempfänger auch EÜR macht, ist unklar.

Wenn du unter einer identischen Rechnungsnummer einfach mal so 20 Rechnungen über je 1000 Euro netto=1190 Euro brutto an verschiedene Kunden versendest, die alle nicht bezahlen, weil du vielleicht ein unseriöser Abmahnanwalt bist, dann werden alle Rechnungsempfänger, die nicht nach EÜR buchen, sondern bilanzieren, genau diese Rechnung für den Vorsteuerabzug nutzen.

Ob die das bezahlen wollen oder nicht, ist dabei erst mal egal. Das Finanzamt wird dann also 20*190 Euro =3800 Euro Vorsteuer ggf sogar an die Rechnungsempfänge auszahlen und spätestens jetzt hättest du bei Kontrollmitteilungen aufgrund deiner Rechnungen eine sehr schlechte Position gegenüber einem Betriebsprüfer.

Man sollte nicht vergessen, das im Rahmen der GDPdU ein Prüfer im Rahmen seiner Prüfungen Zugriff auf die einzelnen Buchungsdatensätze in der Buchhaltung deiner Kunden hat und ob die Daten da irgendwann mal in einer großen Datenbank für mehrere deiner Kunden konsolidiert werden darf, weiss im Moment noch keiner so genau. Zu erwarten ist das auf jeden Fall, weil man damit offensichtlichen Betrug, der nach o.a. Masche oder ähnlich läuft, ziemlich schnell erkennen und verhindern kann ...

Ich finde den Thread aber auch sehr spannend, da zeigt sich eine große Bandbreite von subjektiven Interpretationen, die mal mehr oder weniger zutreffend sind. Was lernt man da: Wenn man als Programmierer kein Bock hat, sich ständig weiterzubilden, sollte man den Beruf wechseln ....

Früher nutzte man dafür in erster Linie Bücher, heute wesentlich häufiger Quellen im Internet. Nur weil etwas in einem Buch geschrieben steht, ist es noch lange nicht wahr, denn Buchautoren sind auch nur Menschen und viele sogenannte Fachbücher taugen oft gerade mal für Basics und viele strtzen sgar vor Fehler. Viele Informationen aus dem Internet, gerade aus weniger professionell besetzten Foren (wovon ich die DP explizit ausnehme), sind da aber weit kritischer zu betrachten.

Das macht mir mal wieder deutlich, wie wichtig so eine Community wie die DP für unser Berufsbild ist. Man sollte aber dabei durchaus immer Wert drauf legen, das seriöse aussagekräftige Quellenangaben weiterhin wichtig sind.

Und wie schon einige das auch festgestellt haben: Der Thread hatte als Thema ursprünglich den Hinweis, das Lücken in Rechnungsnummern uneingeschränkt erlaubt sind.

Die Vorschläge, wie man die Lücken füllen könnte oder gar nicht erst entstehen lässt, stammen dabei meistens von Leuten mit einem Erfahrungsschatz auf relativ einfachen Installationen und wurden ja hier schon durch diverse Gegenbeispiele, warum das erstens in komplexeren Umgebungen nicht so einfach ist und zweitens in einigen Fällen sogar rechtlich bedenklich ist, was da vorgeschlagen wurde, durchaus klar widerlegt.

Wer will kann also nun den Schluss ziehen, das man weiterhin entweder lückenlose Nummerkreise sicherstellen möchte oder alternativ generell lücken fest einplant, damit kein Betriebsprüfer sich daran festbeissen kann. Beide Wege sind legitim und denkbar. Und in erster Linie galt dieser Thread dem Hinweis, das die zweite Variante (Lücken sind unproblematisch) erlaubt ist und die Urban Legend "Rechnungsnummern müssen lückenlos sein" entkräftet ist.

**Sir Rufo**

Zitat von bernau:

Zitat von mkinzler:

Bei Einnahmen-/Überschuß-Rechnung ist die Zahlung massgebend.

Das zweifelt keiner an.

So, so, und ich dachte immer das hängt davon ab, was man beim Finanzamt beantragt hat.

Ohne irgendwas gilt die Versteuerung nach vereinbarten Umsätzen (=bei Rechnungsstellung).
Beantragen muss man die Versteuerung nach vereinnahmten Umsätzen (=bei Zahlungseingang).

Und es ist dabei wurscht ob EÜR oder nicht.

**TRomano**

@Sir Rufo: das ist wohl so richtig und hat man eventuell Kunden, die nicht oder schleppend zahlen sollte man schleunigst beim FA beantragen nach vereinnahmten Entgelten zu versteuern, weil man sonst Steuern (Umsatz-,Einkommens- und Gewerbesteuer) auf etwas bezahlen muss, was man noch gar nicht hat oder nie bekommt ... und das ist echt blöd !

Zitat von IBExpert:

Wenn man als Programmierer kein Bock hat, sich ständig weiterzubilden, sollte man den Beruf wechseln ....

Blödsinn. Wie wäre es mit dem Spiel: "Frag einen Spezialisten"? Ich muss doch nicht alles wissen. Ich bin Softwareentwickler, kein Steuer- oder Bilanzexperte. Es gibt Steuerberater und das Finanzamt. Beide können umfassend helfen und Vorgaben machen.

Zitat:

stammen dabei meistens von Leuten mit einem Erfahrungsschatz auf relativ einfachen Installationen

Wusste gar nicht, das Du derartige Bemerkungen nötig hast.

Zitat:

Und in erster Linie galt dieser Thread dem Hinweis, das die zweite Variante (Lücken sind unproblematisch) erlaubt ist und die Urban Legend "Rechnungsnummern müssen lückenlos sein" entkräftet ist.

Na ja... So falsch ist das ja nicht. 'Müssen' ist eben ein dehnbarer Begriff. Wieso diese 'urban legend' so weit verbreitet ist, wurde ja bereits eingangs erklärt.

Trotzdem ganz interessant.

**jobo**

Als Blödsinn würde ich das nicht bezeichnen. Man muss immerhin noch auf die Idee kommen, dass man eine Sichtweise auf eine Thematik hat, die fragwürdig ist. Ok, beim deutschen Steuerrecht ist dieser Gedanke grundsätzlich naheliegend, das ist mehr "Literatur" als irgendwo sonst auf der Welt (Ist aber vielleicht auch nur eine Legende).
Die Weiterbildungsproblematik gilt m.E. tatsächlich im Bereich Informatik sehr ausgeprägt, wobei hier noch zwischen Entwicklungsknowhow und fachlichem zu unterscheiden ist.

Wie auch immer, ich finde derartige Beiträge super, weil sie weit über die Fragen des einfachen Programmiereralltags hinaus gehen, auch mit der entfachten Diskussion und auch, wenn ich es grad nicht brauche.

**IBExpert**

Zitat von Dejan Vu:

Zitat von IBExpert:

Wenn man als Programmierer kein Bock hat, sich ständig weiterzubilden, sollte man den Beruf wechseln ....

Blödsinn. Wie wäre es mit dem Spiel: "Frag einen Spezialisten"? Ich muss doch nicht alles wissen. Ich bin Softwareentwickler, kein Steuer- oder Bilanzexperte. Es gibt Steuerberater und das Finanzamt. Beide können umfassend helfen und Vorgaben machen.

Das wird aber nicht reichen, um eine Software zu konzipieren. Natürlich kann man jemanden fragen, der sich damit auskennt, aber wer sagt dir, ob der sich wirklch damit auskennt und ob der dir nicht irgendwelchen Stuss erzählt, damit der seine Ruhe hat. Solche Leute sind mir schon oft über den Weg gelaufen, insbesondere bei Kundenprojekten, wo eine neue Software eingeführt werden soll und der einzige, der die bisherigen Prozesse kennt, das bisher mit Excel und Access selbst gebastelt hat und das neue Projekt evtl. sogar seinen Arbeitsplatz gefährdet. Im ERP Umfeld bin ich gegenüber meinen Kunden mindestens 50% Unternehmensberater und bespreche mit dem Kunden sein Wünsche und ordne die in mein Prozesswissen ein, gebe aber oft Vorschläge, wie man das besser machen kann. Wenn du im Bereich Fertigung und Logistik einen Fachmann suchst, dann mal viel Spaß, da gibt es noch viel mehr unterschiedliche Meinungen, wie hier im Forum zum Thema Lückenlose Rechnungsnummern.

Dann brauchst du selber Fachwissen und das musst du dir erarbeiten. Ob du das als Programmierer dann prozedural umsetzt, weil das vor 20 Jahren auch schon gut ging, oder mit neueren Techniken umsetzt, ist dann dein Ding. Aber auch das ist Weiterbildung. Ein Delphi Programmierer hat mir mal auf einer Messe erzählt, das sein Chef sich seit 15 Jahren konsequent geweigert hat, die Entwickler mal auf Schulungen oder Konferenzen zu schicken, geschweige denn mal eine Inhouse Schulung zu organisieren, obwohl mehr als genug Bedarf da ist. Wer mal deren Code gesehen hat, weiß wovon ich rede. Unter Wartungsaspekten eher diffizil würde ich das nennen.

Zitat von Dejan Vu:

Zitat von IBExpert:

stammen dabei meistens von Leuten mit einem Erfahrungsschatz auf relativ einfachen Installationen

Wusste gar nicht, das Du derartige Bemerkungen nötig hast.

Das war nicht irgendwie arrogant gemeint, sondern einfach nur als Fakt. Frank Lauter macht ja zum Beispiel Software für Gerichtsvollzieher, das ist von den Prozessen sicherlich komplett rätselhaft für alle Leute, die nicht seine Branchenkenntnisse haben, aber es gibt nach meiner Kenntnis keine Gerichtsvollzieherbüros mit 100 oder noch mehr Mitarbeiter. Für Ihn ist die Datenbankproblematik eine völlig andere als zum Beispiel für jemand, der eine Firebird basierenden Terminverwaltung gebaut hat, die in einer deutschen Klinik mit 2000 Benutzern auf einem Datenbankserver arbeitet.

Gerd Bernau sagte uns ja, das er sich bevorzugt auf kleiner Kunden im Bereich Optiker konzentriert und Konzerne eher meidet, aber was machst du wenn dein Kunde erfolgreich ist und nach und nach diverse andere Firmen aufkauft und sich nach un nach zum Konzern entwickelt? Dann bist du schnell zwangsweise dabei, dich mit den neuen Anforderungen auseinanderzusetzen. Wenn deine Datenbankarchitektur dann schon bei kleineren Installationen den Anwender mit Wartezeiten nervt, wird es schwierig, für den Kunden mit einer wesentlich größeren Benutzeranzahl eine benutzbare Lösung anzubieten. Wer sich da nicht rechtzeitig weiterbildet, wird dann meist unter Druck keine brauchbare Lösung finden.

**Captnemo**

Zitat von IBExpert:

Das war nicht irgendwie arrogant gemeint, sondern einfach nur als Fakt. Frank Lauter macht ja zum Beispiel Software für Gerichtsvollzieher, das ist von den Prozessen sicherlich komplett rätselhaft für alle Leute, die nicht seine Branchenkenntnisse haben, aber es gibt nach meiner Kenntnis keine Gerichtsvollzieherbüros mit 100 oder noch mehr Mitarbeiter. Für Ihn ist die Datenbankproblematik eine völlig andere als zum Beispiel für jemand, der eine Firebird basierenden Terminverwaltung gebaut hat, die in einer deutschen Klinik mit 2000 Benutzern auf einem Datenbankserver arbeitet.

Gerd Bernau sagte uns ja, das er sich bevorzugt auf kleiner Kunden im Bereich Optiker konzentriert und Konzerne eher meidet, aber was machst du wenn dein Kunde erfolgreich ist und nach und nach diverse andere Firmen aufkauft und sich nach un nach zum Konzern entwickelt? Dann bist du schnell zwangsweise dabei, dich mit den neuen Anforderungen auseinanderzusetzen. Wenn deine Datenbankarchitektur dann schon bei kleineren Installationen den Anwender mit Wartezeiten nervt, wird es schwierig, für den Kunden mit einer wesentlich größeren Benutzeranzahl eine benutzbare Lösung anzubieten. Wer sich da nicht rechtzeitig weiterbildet, wird dann meist unter Druck keine brauchbare Lösung finden.

Bei der ganzen Argumentation musst du aber auch im Auge behalten, dass nicht jeder finanziell in der Lage ist, sich auf irgendein spezifisches Thema ellenlang weiterzubilden, bis er mal nach deine Argumentation in der Lage wäre, eine branchenspezifisches Software zu entwickeln. Teilweise betreffen solche Fachfragen auch nur Randbereiche, die man auch mit Abdecken möchte, aber eben auch nur Randbereiche sind. Und da will man es halt nur richtig machen, aber nicht unbedingt eine andere Software komplett ersetzen.

Ich zum Beispiel habe mich auf die Termin- und Ablauforganisation in Kfz-Werkstätten spezialisiert. Da habe ich oft Randbereiche, die vom Kunden als Hilfsmittel gefordert werden, aber nicht ein Stützpfeiler der Software darstellen. In solchen Fällen hole ich mir Rat bei denen, die in der Praxis mit diesen Dingen zu tun habe, oder frage mal rum, wie etwas allgemein gehandhabt wird.
Das mag jetzt oberflächlich klingen, aber in der Praxis hat das bisher immer zu sehr gut angenommenen Ergebnissen geführt. Das Fachwissen benötigt man sicherlich, aber halt auch nicht immer bis zum letzten Quentchen, und ein Erfahrungsschatz von einem Fachmann, der in einer Branche schon lange arbeitet, kann durch selbst erworbenes Fachwissen auch schlecht ersetzen.

Natürlich kann eine Weiterentwicklung eines Kunden einen vor Probleme stellen. Aber demnach müsste ja Frank seine Software auch für 1000 User vorbereiten, auch wenn es zur Zeit noch keinen Gerichtsvollzieher mit so vielen Angestellten gibt, aber es "könnte" ja passieren.
Jeder designt seine Software so, wie es die aktuellen Gegebenheiten oder der Auftrag seines Kunden erfordert. Evtl. Veränderungen des Kunden oder der Branche sind schwer vorhersehbar, außer es zeichnet sich etwas schon ganz deutlich ab. Ob man dann darauf angemessen reagieren kann, hängt letztlich von dem Möglichkeiten ab, die jeder Entwickler hat. Aber das muss man nun mal so nehmen wie es kommt. Im schlechtesten Fall muss man tatsächlich mal einen Kunden einbüßen, wenn nicht anders machbar ist.

**mquadrat**

Wir machen auch viel Prozessberatung bei ner ERP Einführung. Gerade diese Geschichte mit wann darf auf einem Zettel Gutschrift stehen und wann nicht, wird immer noch von vielen Steuerberatern falsch erklärt. Das gleiche gilt für die Bankberater, die in ihrer SEPA Schulung nicht aufgepasst haben.

Ich denke mal, je mehr Projekte man in einem bestimmten Bereich macht, desto mehr Wissen häuft man da automatisch an. Irgendwann erreicht man den Status, an dem man halt keine Steuerberater mehr braucht um die Rechtslage zu kennen und zu verstehen.