Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[jobo]

Zitat von nahpets:

Sagen wir mal so, 'ne Sequenz wird aufgerufen und gibt 'nen Wert zurück.
..

Das sehe ich im Prinzip alles haargenauso.
Ohne Not muss man nicht rumzaubern mit solchen Nummern.
Eine Sequenz ist eine Sequenz.
Transaktionssicherheit ist Transkationsicherheit.
Ein DB, die das nicht kann, sollte man nicht nutzen.

Die Sequenz wird also immer(!) fortlaufende Nummern produzieren, auch im Multiuserbetrieb. Das sollte vollkommen klar sein.
Und der Reset mit dem drangeflickten Datum, da bin ich der Meinung, dass es genauso geht, aber das sehen die Leute hier teilweise offenbar kritisch- auch wenn noch niemand gesagt hat warum.

Letztlich ist es Sache des TE, das abzuwägen und ggF. zu testen.

Vielleicht hätte ich nicht sagen sollen, dass ich mir nicht sicher bin, ob das Vorgehen wasserdicht ist für fb.

Am Ende ist es ja so- ich traue mich kaum, es zu sagen:
Falls der Mechnismus selbst fehlschlagen würde (das wäre entgegen meiner Implementierung nicht einmal pro Tag ab Mitternacht, sondern einmal im Monat ab Mitternacht laut Anforderung) würde eine doppelte Rechnungsnummer immernoch durch einen Unique Constraint abgewiesen. Es werden also keine falschen Daten gespeichert. Auch dafür sind moderne DB gemacht.

[p80286]

Was vielleicht für Irritationen sorgt, ist, daß es Sequenzer gibt, die z.B 10 Nummern auf Vorrat erzeugen, und unter widrigen Umständen ist dieser Vorrat dann verloren.
Das ist aber letztlich egal, da es darum geht eine eindeutige Nummer zu erzeugen.

Gruß
k-H

[nahpets]

Wir hatten mal in 'nem Projekt bei den Sequenzen ein "Schrittweite" von 128.

Man holte sich also von der Sequenz einen Wert und konnte dann diesen, plus die nächsten 127 fortlaufenden Werte, "verbraten".

Wenn das nicht reicht, holte man sich den nächsten 128 Wertebereich.

Und wenn man sie nicht alle brauchte, dann gab's halt Lücken, ja und? Ist (zumindest) bei technischen Schlüsseln vollkommen wurscht.

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

Ob große Unternehmen, die täglich hunderte oder tausende von Rechnungen erstellen, wirklich darauf achten, dass die Nummer garantiert lückenlos vergeben wurde.

Es kann nun mal bei der Erstellung einer Rechnung passieren, dass der Vorgang abgebrochen werden muss. Dann ist diese Rechnungsnummer halt vergeben, obwohl diese Rechnung letztlich nie erstellt wurde.

Die "zwingende Lückenlosigkeit der Rechnungsnummer" ist nur was zur Befriedigung des persönlichen Ergeizes des vor dem Rechnersitzenden oder irgendeines "Verwaltungstieres", aber für den Kunden oder die weiter interne Verarbeitung vollkommen Irrelevantes.

Habe heute eine Rechnung mit der Nummer 21750094056 bekommen. Mir ist es doch sowas von wurscht, ob es die Nummern 21750094055 und 21750094057 gibt oder nicht. Und für den Rechnungsersteller dürfte das auch absolut egal sein, die Buchhaltung will nur irgendwann wissen, ob für jede erstellte Rechnung irgendwann (möglichst vor dem letztmöglichen Zahlungstermin) ein Geldeingang zu verbuchen ist.
Aber niemand wird die Rechnungen nach lückenlos aufsteigender Rechnungsnummer ablegen und irgendein Problem dabei bekommen, wenn da mal 'ne Nummer fehlt.

Meiner Meinung nach werden hier oft "fachliche Anforderungen" gestellt, die für die tatsächliche Verarbeitung völlig überflüssig sind. Man könnte für die Rechnungsnummer auch einfach die Millisekunden seit dem 1.1.1970 nehmen, man darf nur nicht auf die Idee kommen, die Uhr zurück zu stellen. Die Verarbeitung der Rechnungen im weiteren Geschäftsablauf dürfte dadurch in keiner Weise nachteilig beeinflusst werden.

Mit Anforderungen wie: "Die Rechnungsnummer muss aus Jahr, Monat und einer fortlaufenden Nummer bestehen." sorgen bei der Implementierung eigentlich nur für Probleme, ohne dass im eigentlichen Arbeitsablauf dadurch ein wesentlicher Nutzen entsteht.

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

[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