Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[p80286]

Zitat von DCoderHH:

Wie sollen die Rechnungsnummern am jetzt am Besten gespeichert werden? Ein VarChar-Feld, dass dann für uns eine numerische Kundennumer enthält...

Einwurf am Rande, auch wenn Eure Rechnungsnummer aus Ziffern besteht, ist sie nicht Numerisch sprich eine Zahl, mit der man Rechnen kann.
Da es immer noch viele Schwergewichter gibt, die hemmungslos mit diesen und anderen Nummern rechnen, der Hinweis: "Nicht alles was wie eine Zahl aussieht, ist auch eine Zahl"

Gruß
K-H

[mm1256]

Zitat von p80286:

...die hemmungslos mit diesen und anderen Nummern rechnen, der Hinweis: "Nicht alles was wie eine Zahl aussieht, ist auch eine Zahl"

In diesem Fall würde ich aber eine Zahl bevorzugen, einen Integer im Format YYYMMnnn wobei nnn dann die fortlaufende Nummer im Monat wäre. Wie man den Integer dann formatiert ausgibt, bleibt Ermessenssache. So nebenbei wird das dann auch noch kompatibel mit manchen Fibus die nur rein numerische Belegnummern verarbeiten können.

[p80286]

Ich hab da so meine Bedenken!
die Generierung der Nummer YYYYMMnnn aus einer Zahl, kein Problem, aber danach ist sie ein string aus 9Ziffern, wobei hat nnn führende Nullen?
In meiner Praxis habe ich des Öfteren mit Personalnummern zu tun, 6Stellig nur Ziffern. Access hat es schon einmal fertig gebracht, daraus Datumsdaten zu machen. Standard ist es die führende 0 zu streichen und selbst die Berechnung der Prüfziffer erfolgt ja nicht von einem numerischen wert sondern vom numerischen Wert einzelner Ziffern bzw. Ziffernkombinationen.

Gruß
K-H

[jobo]

Ich würde einen String nehmen, dann ist mir alles andere egal (außer die maximale Länge, die für eine unbeschwerte Zukunft doch noch irgendwie bestimmt/"geraten" werden müsste). Damit hätte ich dann mit einer beliebigen Formatmaske pro Mandant / Konfiguration dann alle Freiheiten.

[nahpets]

Also sagen wir mal so:

Prinzipiell kann man das mit der Nummer so ala ((Jahreszahl * 100) + Monat) * 1000 machen.

Das klappt soweit auch ganz gut.

Per wie auch immer gearteter Datenbanklogik kann mein eine Sequenz zum Monatsbeginn auf eben diesen Wert setzen.

Und richtig gut wird das Ganze dann, wenn irgend so ein "bekloppter Kunde" dafür sorgt, dass er in einem Monat mal die 999 plus 1. Rechnung verursacht.

Dann sind wir in dem Nummernkreis wunderbar z. B. bei

2017 * 100 wird zu 201700 plus Monat (Januar) ist dann 201701.
Das mal 1000 ergibt 201701000.
plus 999 ergibt 201701999 (für die 999. Rechnung)
plus 1 wird zu 201702000 (für die 1000. Rechnung)
plus noch eins wird dann 201702001 (für die 1001. Rechnung)

Und am 1. Februar setzen wir dann die Sequenz auf 201702000.

Und die erste Rechnung im Februar macht uns dann eine "wunderbare" Rechnungsdublette.

Delphitechnisch könnte man das z. B. ungefähr so umsetzen:

Delphi-Quellcode:

var
  i : Integer;
  Rechnungsnummer : String; 
begin
  for i := 0 to 1001 do begin
    Rechnungsnummer := Format('%.4d-%.2d-%.3d',[YearOf(Now),MonthOf(Now),i]);
  end;
end.

Pech, wenn man in der Datenbank dann nur 11 Zeichen für die so formatierte Rechnungsnummer reserviert hat.

Und nein, die 1000. Rechnung in einem Monat können wir für immer und alle Zeiten ganz ganz ganz absolut sicher ausschließen.

Nene, sprechende Schlüssel sind ein Graus
Irgendwann gehen sie schief und alle rätseln: Wie konnte sowas nur passieren

Ok, genug geblödelt.

Meiner Meinung nach sollte man hier für das Tochterunternehmen einfach mal folgende Regel einführen:

Ok, Ihr könnt ab 1.1.2017 mit unserer Software arbeiten, wir werden euch das alles einrichten. Die erste Rechnung die Ihr im Jahr 2017 erstellt, bekommt die Nr. 1. Jede weitere Rechnung bekommt eine um 1 höhere Rechnungsnummer.

Punkt.

Die Leute werden sich sehr schnell daran gewöhnen, dass die Rechnungsnummer eine Nummer ist.

Praktische Erfahrung: Am Häufigsten bestehen die Leute auf irgendwelche Formalismen beim Erstellen von Nummern ..., die in der Praxis am Wenigsten damit in Berührung kommen.

Wenn's denn sein muss: Formal (also optisch) erstellt Ihr die Rechnungsnummer weiterhin mit JJJJ-MM-n.
Aber die n beginnt nicht mehr jeden Monat bei 1, sondern wird für alle Zeiten jeweils um 1 weitergezählt.

Teilt jetzt ein Kunde bei 'ner Nachfrage seine Rechnungsnummer mit, weiß man immernoch, aus welchem Jahr und Monat sie ist, aber halt nicht mehr, die wievielte es aus dem Monat ist. Für irgendwelche praktischen Abläufe dürfte diese "Information" eh irrelevant sein.

[p80286]

langsam aber sicher[OT]
Wir bekommen jetzt eine DB bei der die Aktennummern nach dem Schema YYYYMMDDnnn aufgebaut sind, angeblich geht es nicht anders, und der Hersteller ist seit einigen Jahren im Geschäft.

Was soll man rauchen um das zu ertragen?

[/OT]

[jobo]

Ja, meinetwegen, ist ein wenig schwarz gemalt, aber wie auch immer.
Diese Anforderungen ergeben sich ja nicht primär daraus, dass der verantwortliche Buchhalter Nummerologe ist. Oft sind es eher Sachzwänge aus irgendwelcher Legacy Software, was weis ich. Die Anforderung hat der TE gesetzt oder das Tochterunternehmen, ...
Ich würde an der Stelle keine Sachzwänge durch einen Datentyp in Kauf nehmen, geschweige durch Regularien, die sich aus der Verwendung Nutzung einer DB Funktion ergeben, die nicht dafür gedacht ist, ein Primärschlüssel und die DB Hilfskonstrukkte dazu sind halt was anderes als eine Rechnungsnummer.
Speicherplatz kostet auch nicht mehr so viel, dass man hier mit Bits rechnen muss.

Ob oder welche Arbeitsabläufe (Aktensortierung) hinter solchen Dingen stecken, kann man aus der Ferne auch nicht sagen.

Und eine 20 stellige Rechnungsnummer ist doch irgendwie auch .. beeindruckend.. oder nicht

[Ghostwalker]

Ich persönlich würde wie folgt verfahren:

- Primarykey abtrennen....der hat nix mit ner Rechnungsnummer zu tun
- Einheitliches Format für Rechnungsnummer generieren:

z.B.
Mit dem Datum der Rechnung
Der Kundennummer
und ggf. einer lfd. Nummer


Das ganze als Varchar mit Index in die DB klatschen feddich.

Wenn ggf. die Anforderung besteht, das der Aufbau der Rechnungsnummer nicht ersichtlich sein soll,
kann man noch drüber nachdenken den o.g. String durch eine Hash-Routine zu jagen und den Hash als Rechnungsnummer zu nutzen. Damit wäre die Eindeutigkeit auch gesichert.

[DCoderHH]

OK, ihr hab micht überzeugt. Ich werde 2 Felder nutzen: Ein ID-Feld als Primärschlüssel und die Rechnungsnummer im VarChar-Feld. Nun ist noch offen:

Wie erzeuge ich die Rechnungsnummer nach dem Schema YYYY-MM-NNNNNN? Y=Aktuelles Jahr, M=Aktueller Monat, N=Fortlaufende Nummer von 1 bis n im aktuellen Monat?

nahpets hat in Post #10 schon Code dazu genannt. Der sieht aber nicht so aus, als ob man dem mit einer DB im Multiuser-Zugriff nutzen könnte... Wer hat da eine gute Idee? Danke!