Fortlaufende lückenlose Rechnungsnummern

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

[IBExpert]

Zitat von Captnemo:

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

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