Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

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

[nahpets]

Naja, statt i nimmst Du in dem Teil hier Rechnungsnummer := Format('%.4d-%.2d-%.3d',[YearOf(Now),MonthOf(Now),i]); 'ne Datenbanksequenz.

Ggfls. könnte diesen Job aber auch ein Datenbanktrigger übernehmen?

[DCoderHH]

Zitat von nahpets:

Naja, statt i nimmst Du in dem Teil hier Rechnungsnummer := Format('%.4d-%.2d-%.3d',[YearOf(Now),MonthOf(Now),i]); 'ne Datenbanksequenz.

Ggfls. könnte diesen Job aber auch ein Datenbanktrigger übernehmen?

Datenbanksequenz = Generator in Firebird? Und wie setze ich den dann jeden Monat wieder auf 1? Und zwar so, dass er nur genau ein mal pro Monat auf 1 gesetzt wird?

[jobo]

Code:

insert into mytable 
values (1,                                                                        -- id
        'rn#_'||CAST(Extract(year  FROM cast('NOW' as date))*10000 +
                     Extract(month FROM cast('NOW' as date))*100 +
                     Extract(day   FROM cast('NOW' as date)) AS VARCHAR(8))||
        LPAD (gen_id(gen_rn,1), 6, '0'),                                          -- rechnungsnummer 
        cast('Now' as date));                                                     -- date

und reset

Code:

set generator gen_rn to 0;

[DCoderHH]

Zitat von jobo:

und reset

Code:

set generator gen_rn to 0;

Und wann und wie rufst Du das auf und zwar so dass es genau ein mal pro Monat ausgeführt wird?

[jobo]

naja, einmal im Monat
Mitternacht, am letzten Tag des Monats.

Ok, also ernst:
Eine lazy Variante wäre, das auf dem Server durch einen (Cron)Job durchführen zu lassen.
Dabei besteht leider die Gefahr, dass der Job fehlschlägt, das müsste man absichern.

Ich würde es wohl eher so machen, den gesamten Ausdruck, der die Nummer generiert, als Funktion abzurufen. Darin wird die Datumsgrenze geprüft und der Reset gemacht.
Dabei besteht leider das Problem, den Wechsel festzustellen, dafür eignet sich wohl am besten eine Hilfstabelle mit einer Zeile, die sich das Datum bei jedem Aufruf zum Vergleichen merkt.

Im übrigen muss man sich vielleicht noch überlegen, was das Rechnungsdatum wird. Tag der Erstellung, Tag des Versandes, ..
Je nach dem würde die Rechnungsnummer dann unterschiedlich generiert.

[rokli]

Moin,

es gibt auch die Möglichkeit, eine Tabelle anzulegen, in der die Nummern verwaltet werden z. B.:

SQL-Code:

CREATE TABLE [dbo].[Nummernkreise](
   [IdNo] [int] IDENTITY(1,1) NOT NULL,
   [Mandant] [tinyint] NULL,
   [BelegArt] [char](10) NULL,
   [BelegNr] [int] NULL,
   [BelegPrefix] [char](20) NULL,
 CONSTRAINT [PK_Nummernkreise] PRIMARY KEY CLUSTERED 
(
   [IdNo] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

Und der Inhalt sieht dann so aus:

Code:

IdNo   Mandant   BelegArt   BelegNr   BelegPrefix
1   1   RE           123   2016-12             
2   1   LS           17   2016-12             
3   2   RE           17   KDNR                
4   1   AB           500   2016-16

Dann hast Du für alle möglichen Belegarten einen Speicher, in dem Du hochzählen kannst, in dem Du Startwerte setzen kannst etc.; und natürlich sind weitere Felder in der Tabelle denkbar, wie Monat und / oder Jahr, wenn das nötig wäre.

Gruß