Fortlaufende lückenlose Rechnungsnummern

[mkinzler]

Zwischenzeitlich darf man eine Storno-Rechnung aber wieder Gutschrift nennen, auch wenn es umsatzsteuerlich keine ist. ( Eine Gutschrift im umsatzsteuerlichen Sinne ist das Gegenstück zur Rechnung; aber vom Empfänger ausgestellt)

[Lemmy]

Zitat:

Zitat von rapante (Beitrag 1307025)

Siehe BMF Schreiben vom 25.10.2013 auf Seite 3, letzter Absatz:

Im Dezember 2013 sah das wohl schon wieder anders aus...

http://erfolgreich-wirtschaften.de/f...flichtangaben/


Aber ich bin da definitiv auch nicht sattelfest...

[mkinzler]

Schon im Oktober

BMF 25.10.13, IV D 2 – S 7280/12/10002

[Mavarik]

Zitat:

Zitat von Lemmy (Beitrag 1307027)

Im Dezember 2013 sah das wohl schon wieder anders aus...
http://erfolgreich-wirtschaften.de/f...flichtangaben/

Wie geil das wusste ich auch nicht... "Ich sach doch is ne jutschrift"! :-D

[frankyboy1974]

Hallo,

ich habe BWL und Informatik studiert. Meine Frage und zugleich Antwort lautet wie üblich zu solchen Threads:

42

mfg

frank

[Perlsau]

Zitat:

Zitat von frankyboy1974 (Beitrag 1307037)

Hallo, ich habe BWL und Informatik studiert. Meine Frage und zugleich Antwort lautet wie üblich zu solchen Threads: 42

:wiejetzt: :coder2: :thumb: :cheers: :hi: :dancer2:

[Captnemo]

Grundsätzlich halte ich das erneute verwenden einer Rechnungsnummer, wenn die alte Rechnung als nicht bezahlt wird, für keine gute Lösung (ob nun Steuerrechtlich möglich oder nicht). Ich schreibe dafür generell eine Stornorechnung.
Der Grund hierfür liegt im Rechnungsdatum und in der Nachvollziehbarkeit.
Ein Steuerprüfer wird schon hellhörig, wenn innerhalb der fortlaufenden Rechnungsnummern nicht auch das Rechnungsdatum chronologisch fortlaufend ist. Das deutet nämlich auf nachträgliche Veränderungen der Rechnungen hin, und das macht ihn erst mal neugierig. Im Gegenzug dazu sind Rechnungen, die nicht bezahlt werden, und mit Stornorechnung somit nachvollziehbar sind, für einen Prüfer kein Grund für eine Beanstandung. So halte ich es immer in Rücksprache mit meinem Steuerberater, und das ist bisher immer sehr gut gelaufen, und es gab nie Rückfragen oder Beschwerden vom Prüfer.
Zwar will ein Prüfer, aus verständlichen Gründen, immer was finden, aber dazu hat er in den Ausgaben genug Möglichkeiten.

Solange ich nicht wirklich zu unrecht mehr Zahlen muss, als ich Zahlen müsste, gehe ich mit dem FA immer den Weg des geringsten Widerstandes.

Und desweitern kann ich durch ein Storno auch nach Jahren noch selber gut nachvollziehen, was damals gewesen ist.

[bernau]

Zitat:

Zitat von frankyboy1974 (Beitrag 1307037)

42

:cyclops:

Ich finde gerade diese Threads besonders hilfreich und lesenswert. Zeigen sie doch, daß unterschiedliche Auffasungen und Interpretation von Dingen vorhanden sind.

[Captnemo]

Zitat:

Zitat von bernau (Beitrag 1307044)

Zitat:

Zitat von frankyboy1974 (Beitrag 1307037)

42

:cyclops:

Ich finde gerade diese Threads besonders hilfreich und lesenswert. Zeigen sie doch, daß unterschiedliche Auffasungen und Interpretation von Dingen vorhanden sind.

Vor allen Dingen sollte jeder ein solches Vorgehen (in welcher Art auch immer) mit seinem Steuerberater absprechen. Der kennt in der Regel die Sachbearbeiter vom Finanzamt schon und weiß ggf. auch über die Verfahrensweise des FA's bescheid. Obwohl es eigentlich eine einheitliche Gesetzeslage gibt, so interpretiert doch jedes FA in manchen Dingen etwas anders, als andere.

[jaenicke]

Zitat:

Zitat von Sir Rufo (Beitrag 1306982)

Sodele und was hindert die Software es genau so zu handhaben? Also einem Beleg erst dann zu buchen, wenn der Anwender das sagt?

Aber genau da stolpern einige Anwendungen. Da wird die Belegnummer vergeben, wenn einfach nur ein neuer Beleg angefangen wird oder zwischengeparkt oder mal eben in der Vorschau angezeigt werden soll.

Nur wieso das so passiert und nicht wie es eigentlich korrekt wäre ...

weil es einfacher zu programmieren ist. Das ist der Grund.

Leider müssen wir die Rechnungsnummer zum Beispiel an Kartenterminals schon vorab übertragen um dort die Zahlung hinterher zuzuordnen. Wenn die Zahlung abgebrochen wird, ist die Rechnungsnummer trotzdem vergeben.
Oder wir schicken die Rechnung in Italien oder Griechenland an Fiskaldrucker bzw. Fiskalbox. Nur leider hat der Bediener diese ausgeschaltet, so dass die Rechnung offen bleiben muss, aber eine Rechnungsnummer hat.

Theoretisch könnte man die Rechnung bei der Vergabe der Rechnungsnummer auch unveränderbar machen. Aber wenn diese dann nicht abgeschlossen werden kann, bliebe nur ein Rechnungsstorno. Dumm nur, wenn der Bediener z.B. das Recht nicht hat. Zumal ein Storno einer nicht abgerechneten Rechnung auch irgendwie komisch ist.

Das sind nur Beispiele. Es gibt noch eine ganze Reihe von Fällen, in denen es eben einfach nicht anders möglich ist.

Damit sich niemand über die Lücken wundert, braucht man aber in der Rechnungsübersicht nur einen Platzhalter zu hinterlegen, damit ersichtlich ist, dass die Rechnung z.B. wieder leer storniert und nie abgerechnet wurde.

[Captnemo]

Zitat:

Zitat von jaenicke (Beitrag 1307051)

Leider müssen wir die Rechnungsnummer zum Beispiel an Kartenterminals schon vorab übertragen um dort die Zahlung hinterher zuzuordnen. Wenn die Zahlung abgebrochen wird, ist die Rechnungsnummer trotzdem vergeben.

Ich will das nicht in Frage stellen, aber wie kann eine Zahlung dokumentiert werden, wenn sie gar nicht stattgefunden hat?
Okay, ich weiß jetzt nicht, von was für einer Art Kartenterminals du redest. Aber nehmen wir mal Fahrkartenterminals o.ä., da erfolgt der Ausdruck doch erst nach der Zahlung. Da dann ein Betrag geflossen ist, ist die Rechnungsnummer auch notwendigerweise vergeben.

In meinen Rechnungsprogrammen halte ich das so: dann z.B. während der Erfassung wird eine vorläufige Rechnungsnummer vergeben, die aber aus einem anderen Nummernkreis stammt. Solange die Rechnung nicht fakturiert ist, bleibt diese auf allen Ausdrucken bestehen. Wird nun fakturiert, so wird dann aus dem regulären Nummernkreis die endgültige Rechnungsnummer vergeben. Die Zuordnung zur vorläufigen Nummer bleibt aber in der DB und man kann sie ggf. noch mal abfragen. Damit bleibe ich im offiziellen Nummernkreis lückenlos, andererseits sind Lücken im vorläufigen Nummernkreis ohne Relevanz. Nicht fakturierte Rechnungen können gelöscht werden.

[jaenicke]

Zitat:

Zitat von Captnemo (Beitrag 1307054)

Ich will das nicht in Frage stellen, aber wie kann eine Zahlung dokumentiert werden, wenn sie gar nicht stattgefunden hat?
Okay, ich weiß jetzt nicht, von was für einer Art Kartenterminals du redest.

Das sind Kreditkartenterminals. Dort gibt es keine andere Möglichkeit. Eine temporäre Rechnungsnummer scheidet auch aus, weil sich diese bei einer erfolgreichen Zahlung nicht mehr korrigieren lässt.

Und dazu kommen eben auch noch die Fiskalgeschichten, Hotelsysteme, ... die es ebenfalls teilweise erforderlich machen eine fertige Rechnungsnummer zu schicken ohne zu wissen, ob die Transaktion erfolgreich sein wird.

[p80286]

Zitat:

Zitat von Perlsau (Beitrag 1306997)

Ich kann jederzeit nachweisen, daß die Rechnung nicht bezahlt und daher storniert wurde.

??????
Ich hab Buchhaltung noch von der Pike auf gelernt. Wenn Du damals eine Rechnung ausgestellt hast, dann war die Rechnungsnummer die Nummer des Vorgangs. Wurde die Rechnung storniert, gab es eine entsprechende Gegenbuchung, aber der Vorgang blieb erhalten. Was Du machst ist "radieren" und das ist nicht so gerne gesehen!
Darum hat auch jeder Vorgang eine eigene Buchungsnummer.
(der PK ist nun mal keine Erfindung der DB Leute:stupid:)

Gruß
K-H

[Perlsau]

Posting gelöscht wegen eben via anonymer Email erhaltener Drohung vermutlich von einem hiesigen User, mich bei meinem zuständigen Finanzamt anzuzeigen.

[baumina]

Was passiert, wenn der Kunde überraschenderweise ein Jahr später doch noch bezahlt?

[rokli]

Hallo!

Das ist der Punkt. Wenn der Kunde nach einem Jahr zahlt, weil er z. B. nach der Leistungserbringung für 12 Monate in den Urlaub gefahren ist, dann ist bei einer stornierten Rechnung kein offener Posten mehr da.

Wenn ein Kunde endgültig nicht zahlt, dann muss der offene Posten irgendwann in der Buchhaltung ausgebucht werden, und nicht über einen Storno / Gutschrift etc. (Ertragsminderung, Korrektur der MwSt.... )

LG

[p80286]

Es kommt darauf an.
Zum Ende des Berichtsjahres werden die offenen Posten in die Rechnungsabgrenzung "verschoben". Je nach Gesetzeslage kannst Du dann offene Forderungen abschreiben. Sollte wider Erwarten doch noch ein Zahlungseingang erfolgen, kommt der in die sog. A(usser)O(rdentlichen)-Erträge.

(sofern das betrachtete Unternehmen groß genug ist)

Merke: in einer ordentlichen Buchhaltung geht nichts verloren!

Gruß
K-H

[Rollo62]

@Phoenix

Zitat:

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

Schöner hätte ich das nicht schreiben können.
Ich mache das Gleiche und fahre sehr gut damit.

Ich denke es geht den Behörden um Eindeutigkeit, und was gibt es Eindeutigeres als einen Timestamp.
Manchmal benutze ich Timestamps als Simple-GUUID, denn die haben auch den Vorteil das es schön lesbar ist
und auch effektiv suchbar.

Jaja, ich weiss das es Probleme geben kann wenn verschiedene Rechner verschiedene Zeiten haben,
dann muss man eben einen Timeserver nehmen.
Für meine Aufgaben, auch als Rechnungsnummer reicht das völlig.

Rollo

[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.:roll:

mfg

Frank

[Captnemo]

Zitat:

Zitat von frankyboy1974 (Beitrag 1307104)

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.:roll:

mfg

Frank

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

[p80286]

Zitat:

Zitat von Captnemo (Beitrag 1307109)

Zitat:

Zitat von frankyboy1974 (Beitrag 1307104)

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.:roll:

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:

Zitat von frankyboy1974 (Beitrag 1307104)

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.:roll:

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

[IBExpert]

Zitat:

Zitat von bernau (Beitrag 1307017)

Zitat:

Zitat von mkinzler (Beitrag 1307013)

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:

Zitat von bernau (Beitrag 1307017)

Zitat:

Zitat von mkinzler (Beitrag 1307013)

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 !

[Dejan Vu]

Zitat:

Zitat von IBExpert (Beitrag 1307128)

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:

Zitat von Dejan Vu (Beitrag 1307140)

Zitat:

Zitat von IBExpert (Beitrag 1307128)

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:

Zitat von Dejan Vu (Beitrag 1307140)

Zitat:

Zitat von IBExpert (Beitrag 1307128)

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:

Zitat von IBExpert (Beitrag 1307150)

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.

[IBExpert]

Zitat:

Zitat von Captnemo (Beitrag 1307154)

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.

Genau das ist eine Stärke in unserer Branche, nämlich das für seine Zielgruppe softwaretechnisch so umzusetzen, das der Anwender damit klar kommt. Nicht jeder braucht SAP.

Dabei muss man aber bis zu einem gewissen Grad rechtliche Grundlagen kennen und die unterschiedliche Bedeutung vom Begriff Gutschrift und Rechnungskorrektur oder auch europäische Umsatzsteuerberechnung für digital gelieferte Produkte zum Bespiel ist ein sehr gutes Beispiel, bei dem man sich durch Unwissen gewaltig in die Nesseln setzen kann.

Steuerberater sind qualitativ sehr unterschiedlich einzuordnen. Wenn der nur Landwirte und kleine lokale Einzelhändler als Kunden hat, wird der dich aktiv niemals auf solche Problematiken hinweisen, weil der davon noch weniger Ahnung hat als man selber.

[Phoenix]

Jungs, so interessant die Diskussion um Fachwissen jetzt auch sein mag, irgendwie hat sie ehrlich gesagt mit der konkreten Thematik ob Rechnungsnummern jetzt lückenlos sein müssen oder nicht nicht mehr viel am Hut.

Wenn Bedarf besteht (könnte ja sein ;-) ), verschieben wir die Offtopic-Diskussion gerne in einen separaten Thread, wo es dann dort mit einem neuen Topic bezogen auf Fachwissen etc. weitergeht. Wenn das gewünscht ist, bitte grad nochmal melden.

Ansonsten wäre es echt zuckersüß von Euch, hier bitte beim original-Thema zu bleiben. Vielen Dank :thumb:

[p80286]

Zitat:

Zitat von jobo (Beitrag 1307149)

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.

Dem kann ich nur zustimmen!
Ein wenig über den Tellerrand derr Bitsuppe zu schauen hat eigentlich noch nie geschadet, und ohne Hintergrundwissen ist es nicht weit bis zu Lukas 23/34

Gruß
K-H

Vergessen:
Es ist auch angenehm endlich einmal Ausführungen in einem vernünftigen Sprachstil zu lesen, der auch noch mit Fachwissen unterlegt ist.

[mm1256]

Hallo,

also dann "zuckersüß" :-D zurück zum Thema. Dass es nicht zwingend vorgeschrieben ist, lückenlose Rechnungsnummernkreise zu generieren, ist bzw. war für einige wohl neu. Nichts desto trotz ist man immer gut beraten, wenn man die gesetzlichen Möglichkeiten hier nicht ausschöpft. Und warum? Weil Software nun mal dazu da ist, dem Kunden seine Arbeit zu erleichtern. So steht es doch in den Hochglanzprospekten. Und wie die Verantwortlichen (was nicht zwangsläufig aber manchmal auch die Programmierer sind) damit umgehen, kann man ja nachlesen.

Welche Betriebe werden geprüft, und aus welchem Anlass? Dazu muss man wissen, dass ein Betriebsprüfer ein Vielfaches seines Einkommens an Steuernachzahlungen generiert. Demzufolge stehen nicht die Kleinbetriebe im Terminplan an erster Stelle, sondern die größeren Betriebe. Die exakten Zahlen kann jeder selber googeln.

Ich kenne z.B. sehr viele Kleinunternehmer die ihren Betrieb schon zig Jahre führen, und noch nie geprüft wurden. Solange die nicht irgendwie negativ auffallen, wird das auch noch in den nächsten Jahren so sein. Aber dieses "negativ auffallen" ist der kritische Punkt. Ich hab z.B. in den 90-er Jahren als ich noch mehr Umsatz mit Hardware-Handel gemacht habe, einige Notebooks an eine große Firma geliefert. Bei denen gab es irgendwann mal Unregelmäßigkeiten und im Zuge der darauf folgenden Betriebsprüfung wurden natürlich Querprüfungen (ordnungsgemäße Abführung der Umsatzsteuer) gemacht, auch bei mir, und dann wird man als Kleinbetrieb auch "durchleuchtet". Die Sicherheit nicht geprüft zu werden gibt es also auch für Kleinbetriebe nicht.

Ich habe mittlerweile eine hohe zweistellige Zahl (genau mitgezählt hab ich natürlich nicht) an Betriebsprüfungen bei meinen Kunden (die meine SW einsetzen) hinter mir. Von daher weiß ich, Lücken in den Rechnungsnummernkreisen sind für die Betriebsprüfer immer ein Grund genauer hin zu sehen. Bei diesem "genaueren Hinsehen" kann es natürlich passieren, dass der Prüfer Sachverhalte findet, die er sonst vielleicht übersehen hätte. Und warum? Weil irgend ein Verantwortlicher bei seinem Softwarelieferanten zu faul, zu bequem oder zu dumm war, einen anständigen und logischen Nummernkreis aufzubauen und zu pflegen.

Aus Sicht des Anwenders kann es das doch nicht sein, oder? Und wer als Softwarehersteller die Interessen seiner Kunden - oder als angestellter Programmierer die Interessen seines Arbeitgebers - nicht im Auge hat, sollte sich vielleicht mal Gedanken machen...

Mangelndes oder mangelhaftes Fachwissen ist jedenfalls finde ich kein gutes Argument.