Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

[DCoderHH]

In unser Inhouse-Kunden-DB hatten wir bisher die Rechnungsnummer als Interger-Feld (Primärschlüssel), fortlaufend von 1 bis 2 erzeugt über einen Generator.

Nun soll eine Tochterfirma von uns auch die Software nutzen. Diese vergibt die Rechnungsnummer aber nach dem Schema YYYY-MM-N. Y=Aktuelles Jahr, M=Aktueller Monat, N=Fortlaufende Nummer von 1 bis n im aktuellen Monat.

Wie kann ich solche Rechnungsnummern eindeutig erzeugen? (Löcher sind in beiden Fällen erlaubt. Nur fortlaufend soll es sein.) Anmerkung: Die Datenbestände beider Firmen sind vollständig getrennt und werden nicht vermischt. Es gibt also immer die eine Art der Rechnungsnummer oder die andere Art. Nie beide gleichzeitig.

Wie sollen die Rechnungsnummern am jetzt am Besten gespeichert werden? Ein VarChar-Feld, dass dann für uns eine numerische Kundennumer enthält und für die Tocherfirma das Format YYYY-MM-N? Das ganze dann immer noch als Primärschlüssel? Ein Kollege meinte, das macht man nicht (hat aber keine Begründung). Er würde zusätzlich zur VarChar-Kundennummer noch ein ID-Feld (Integer) einführen, das nur programmintern als Primärschlüssel genutzt wird und andere Tabellen darüber verknüpft werden. Sollte man das machen? Vor-/Nachteile davon?

[sh17]

Ich würde eine Spalte ID für den Primärschlüssel und die zweite Spalte für die Rechnungsnummer mit Index drüber machen.

[sakura]

Erste Gegenfrage:

Werden Rechnungen für einen Monat X eventuell erstellt, wenn ein für den folgenden Monat bereits Rechnungen in der Datenbank existieren?

......

[FrankJ28]

Hallo,
was ist denn das für eine Branche? Werden denn da die Monate betriebswirtschaftlich "abgeschlossen"? Sonst hättet ihr Probleme mit dem lückenlosen Rechnungsnummernkreis innerhalb des Wirtschaftsjahres. Wenn ihr die Monate buchhalterisch abschließen würdet, dann wäre das doch der richtige Zeitpunkt den Nummernkreis entsprechend neu starten zu lassen.
Ciao
Frank

[jobo]

Eine Rechnungsnummer ist eine fachliche Anforderung, deshalb würde man keinen PK dafür einsetzen. Wie Du an dem Problem "Tochterfirma" mit anderer Handhabung der Rechnungsnummer sehen kannst, ist ein PK eine sehr eingeschränkt nutzbare Implementierungsform für dieses Problem.
Wenn es eine einheitliche Software ist, die mit diesen beiden verschiedenen Anforderungen umgehen muss würde ich es so machen:
- Ein neues, autarkes Feld für die Implementierung der Rechnungsnr ala Tochterfirma.
- Dafür einen Mechnismus implementieren, der es per Angabe einer Formatmaske erlaubt, die Rechnungsnummer nach Bedarf auszusteuern
- Und damit eine (zunächst) 2-gleisige Lösung schaffen
- Um- /Erstellung aller Reports, Ausdrucke, Templates für die Tochter auf Basis des neuen Verfahrens (Das dürfte im Wesentlichen die Verwendung des neuen Feldes sein)

- Dann die bestehende Lösung (altes/jetziges Verfahren) so adaptieren, dass sie in einer neuen Version auch in der Lage ist, das neue Feld zu nutzen, inkl. der bereits angepassten Reports usw.

- Die 2gleisigkeit ist m.E. eine sinnvolle Sicherheitsmaßnahme für Dich, damit Dir mittendrin nichts im Bestandssystem um die Ohren fliegt.

Zukünftig können dann neue, geänderte Rechnungsnummerverfahren unproblematisch angepasst werden.

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