Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[himitsu]

Zitat von nahpets:

Und gibt es irgendeine zwingende Erfordernis, dass Rechnungsnummern zwingend lückenlos aufsteigend nummeriert sein müssen?

Das kann manchmal als Anforderung im Raum stehen, quasi als Beweissicherung.

Wenn irgendwo eine Lücke ist, dann fehlt etwas
und wenn was fehlt, dann könnte sich z.B. ein Wirtschaftsprüfer denken was da denn fehlen mag.
'ne hinterzogene Eingangsrechnung? Steuerhinterziehung? Ein Datenfehler/verlorener Datensatz? ...?

[EmWieMichael]

Zitat von nahpets:

...
Und gibt es irgendeine zwingende Erfordernis, dass Rechnungsnummern zwingend lückenlos aufsteigend nummeriert sein müssen?
...

Der Gesetzgeber fordert fortlaufende Rechnungsnummern, die allerdings keineswegs lückenlos sein müssen; wichtig ist ihre Eindeutigkeit.

[jobo]

Also von Lückenlosigkeit war seitens des TE keine Rede. Dazu müssen wir uns in diesem Thread nicht den Kopf zerbrechen (es gibt dazu genug eigene Threads).

Datumsteile dagegen als Bestandteil der Rechnungsnummer und die fortlaufende Nummer mit Reset und Eindeutigkeit war eine Anforderung.
Da ist ein Hinweis zur Sinnhaftigkeit sicher nicht verkehrt. Aber zu sagen ~"..diese Anforderung brauchst Du nicht..", ist aus der Ferne m.E. nicht vertretbar. Denn tatsächlich kennt niemand die Vorgänge vor Ort, Ablage und Suchverfahren in der Buchhaltung usw. usf.

Wenn man mal die fachliche Schiene an Seite lässt:
Eine aufsteigende, eindeutige Sequenz in einer Wertegruppe zu erzeugen, sowas gibt es als Anforderung sicher nicht nur in der Buha.
Mich interessiert insofern eigentlich nur, ob das vorgeschlagene Verfahren praxistauglich ist, also robust und zuverlässig.

[himitsu]

Wenn man den "eindeutigen" Teil nicht kürzt (falls zu lang) und auch nicht mit einem potentiellen Überlauf in andere Teile einrechnet, bzw. wenn es keine "längenunterschiede" in direkt angrenzenden anderen "Zifferngruppen" gibt, dann kann es keine Probleme mit doppelten "Nummern" geben.
Unter Berücksichtigung, dass auch eine zuverlässige Sequenz/Generator verwendet wird.

Solange der Sequenz-Teil, inkl. direkt anliegender Ziffern, immer eindeutig ist, ist alles Andere egal, was man da noch dran hängt.

[IBExpert]

Vielleicht mal wieder zurück zur ursprünglichen Frage: Wie kann man so was machen, wenn man es
aus welchen Gründen auch immer braucht (und ein sehr guter Grund ist das der Kunde dafür Geld
bezahlt)

Wir machen das so:

Es gibt eine Tabelle, in der werden z.B. 100 fortlaufende Nummern auf Vorrat eingetragen. Dafür
sorgt ein On Delete Trigger, der auf dieser Tabelle einfach zählt wie viele noch drin sind und zB
bei weniger als 50 Einträgen einfach wieder auf 100 auffüllt, die jeweils das Maximum um 1 erhöhen.
Die erzeugte Nr ist unique indiziert.

Sollte dieser Trigger von 2 Clients gleichzeitg aufgerufen werden, kommt es zu einer Exception und
durch eine "when any do begin end" Anweisung am Ende des Triggers wird diese Exception von einem der
beiden dann ignoriert, der andere wird dann aber dafür gesorgt haben, das ausreichend Vorrat existiert.

Abgerufen wird die Nummer über eine Prozedur, z.B. GETNR, diese liefert ein Result, varchar oder
Integer oder was auch immer.

Diese Prozedur wiederum nutzt eine 2. Prozedur Getnrx. In dieser wird
die kleinste Nummer abgerufen und mit dem delete gelöscht
NR ist ein RETURN Parameter dieser SP. N ist ein Input Parameter, der als Default 0 hat.

SQL-Code:

create procedure getnrx
(n integer=0)
returns
(nr varchar(20))
as
begin
  nr='';
  select first 1 nr skip (:n) from nrtbl order by nr into :nr;
  delete from nrtbl where nr=:nr; 
  suspend;
  when any do begin nr=''; suspend; end;
end

Wenn es beim Aufruf nun zu einer exception kommt weil 2 Transaktionen zeitnah konkurrierend
die selbe Nummer löschen wollen, wird die SP beim zweiten kein Ergebnis liefern. In der
aufrufenden SP GETNR arbeiten wir daher so

SQL-Code:

create procedure getnr
returns
(nr varchar(20))
as
declare variable n integer
begin
  n=0;
  nr='';
  while (nr='') do
  begin
    select nr from getnrx(:n) into :nr;
    if (nr='') then n=n+1;
    if (n>100) then exception err 'irgendwas stimmt hier nicht';
  end
  suspend;
end

Wer nun auf Kundenwunsch auch gerne Nummern recyclen möchte, kann das problemlos machen, in dem er auf jeder Tabellen,
in der die Nummer benutzt wird, mit einem OnDelete Trigger diese wieder in die nrtbl einträgt, denn die werden dann
automatisch wieder benutzt. Die SP kann dabei ggf auch selber dafür sorgen, das die eingetragenen Nummern
noch den gewünschten Präfix haben, wie zB extract(year from current_date) usw. Falls da noch alte Nummern drin
sind, kann die GetNR SP diese selber löschen und neue für die aktuelle Periode anlegen usw.

Der o.a. code ist nicht getestet sondern enfach so runtergetippt, sollte aber den meisten weiterhelfen und
verdeutlicht viele hier schon geschilderte Ideen, ergänzt aber das interne zweistufige Exception Handling.

Das Verfahren nutzen wir in mehreren Projekten es es funktioniert konfliktfrei, so das sich der FrontEnd
darum keine Kopf machen muss. Wenn der eine Nummer braucht kann er die SP aufrufen oder noch besser lässt das
durch einen Insert Trigger auch die DB machen, damit das auch gespeichert ist und ggf durch den delete Trigger
wieder freigegen wird. Wer Lücken akzeptiert nimmmt einfach keine delete trigger oder holt sich das aus einem
Generator, den man mit einem execute statement 'set generator ....' auch jederzeit am monatsanfang resetten
kann.

Viele Weg führen zum Ziel aber geht nicht gibts nicht und als Softwaredienstleister dem Kunden seine etablierten
Prozessstrukturen auszureden ist ein sehr gefährliches Spiel. Wenn er die Nummer so haben will, why not ....

Wir arbeiten hier fast alle im ältesten Gewerbe der Welt: Wir machen Kunden für Geld glücklich .....

[jobo]

danke sehr!

[rokli]

Zitat von IBExpert:

Viele Weg führen zum Ziel aber geht nicht gibts nicht und als Softwaredienstleister dem Kunden seine etablierten
Prozessstrukturen auszureden ist ein sehr gefährliches Spiel. Wenn er die Nummer so haben will, why not ....

Wir arbeiten hier fast alle im ältesten Gewerbe der Welt: Wir machen Kunden für Geld glücklich .....

Du hast ja so recht

Gruß

[nahpets]

Prinzipiell habt ihr ja recht, wenn man reiner Softwareentwickler ist, dann hat man nach der Vorgabe des Kunden umzusetzen. Punkt.

Wenn man aber vom Kunden den Auftrag bekommt, mit ihm zusammen seine Fachlichkeit zu analysieren und dann in Software umzusetzen, dann ist die Hinterfragung von Vorhandenem erlaubt und erwünscht.

Unter dieser Prämisse halte ich die Hinterfragung von irgendwelchen Strukturen in Schlüsselwerten, Rechnungsnummern ... für zulässig. Kommt dabei heraus, dass das erforderlich ist (nicht nur, weil es schon immer so war, sondern eine plausible fachliche, rechtliche ... Begründung), dann ist das so und wird umgesetzt. Ebenfalls: Punkt.

War halt nie als reiner Softwareentwickler tätig, sondern immer als einer, der zuerst bei der Analyse der vorhandenen Gegebenheiten "mit dabei war" und anschließend "die Umsetzung der Software machen durfte". Eventuell führt dies ja zu deutlich unterschiedlichen Sichtweisen auf die auszuübende Tätigkeit und den Umsetzungsprozeß der Fachlichkeit in Software.

Letzlich ist wesentlich, dass der Kunde mit der neuen Software besser arbeiten kann, als mit dem bisher Vorhandenen.
Dabei ist natürlich sicherzustellen, dass er sein Unternehmen mit möglichst wenigen Anpassungen weiterführen kann. Neue Software darf natürlich nicht dazu führen, dass die ganze Unternehmensstruktur umgekrämpelt werden muss, nur weil mir als Dienstleister gerade danach ist oder ich nicht in der Lage bin, etwas gefordertes umzusetzen. In dem Fall bin ich der Falsche und sollte den Auftrag einem besser Qualifizierten überlassen.

[p80286]

Zitat von IBExpert:

Wir arbeiten hier fast alle im ältesten Gewerbe der Welt: Wir machen Kunden für Geld glücklich .....

Der ist gut.....
aber man muß ja nicht jede Praktik akzeptieren

Gruß
K-H

[IBExpert]

Zitat von nahpets:

Prinzipiell habt ihr ja recht, wenn man reiner Softwareentwickler ist, dann hat man nach der Vorgabe des Kunden umzusetzen. Punkt.

Wenn man aber vom Kunden den Auftrag bekommt, mit ihm zusammen seine Fachlichkeit zu analysieren und dann in Software umzusetzen, dann ist die Hinterfragung von Vorhandenem erlaubt und erwünscht.

Unter dieser Prämisse halte ich die Hinterfragung von irgendwelchen Strukturen in Schlüsselwerten, Rechnungsnummern ... für zulässig. Kommt dabei heraus, dass das erforderlich ist (nicht nur, weil es schon immer so war, sondern eine plausible fachliche, rechtliche ... Begründung), dann ist das so und wird umgesetzt. Ebenfalls: Punkt.

War halt nie als reiner Softwareentwickler tätig, sondern immer als einer, der zuerst bei der Analyse der vorhandenen Gegebenheiten "mit dabei war" und anschließend "die Umsetzung der Software machen durfte". Eventuell führt dies ja zu deutlich unterschiedlichen Sichtweisen auf die auszuübende Tätigkeit und den Umsetzungsprozeß der Fachlichkeit in Software.

Letzlich ist wesentlich, dass der Kunde mit der neuen Software besser arbeiten kann, als mit dem bisher Vorhandenen.
Dabei ist natürlich sicherzustellen, dass er sein Unternehmen mit möglichst wenigen Anpassungen weiterführen kann. Neue Software darf natürlich nicht dazu führen, dass die ganze Unternehmensstruktur umgekrämpelt werden muss, nur weil mir als Dienstleister gerade danach ist oder ich nicht in der Lage bin, etwas gefordertes umzusetzen. In dem Fall bin ich der Falsche und sollte den Auftrag einem besser Qualifizierten überlassen.

Die gesamten Punkte kann ich voll unterschreiben, sehe ich auch so. Es ist für einen Softwarearchitekten und -entwickler in diesem Bereich auch ein extremer Glücksfall, beim Kunden dabei auf kompetente und diskussionswillige Ansprechpartner zu treffen, mit denen man dann schnell Entscheidungen treffen kann. Je größer der Laden, desto seltener wird man so ein Umfeld finden. Bei ganz kleinen Unternehmen ist da meistens auch nicht so viel Luft.

Ich bevorzuge in dem Umfeld individueller Softwareentwicklung daher den inhabergeführten Mittelstand, bei dem man gute Chancen hat, solche Strukturen vorzufinden. Wir haben ja auch Projekterfahrungen mit ganz großen Konzernen und da sieht man die Abrechnung am Ende auch gerne als Schmerzensgeld an. Auf Dauer wäre für mich die Arbeit für einen Konzern als externer Dienstleister nicht interessant, vom finanziellen Aspekt mal abgesehen.