Wie eindeutige Rechnungsnummer in DB erstellen und speichern?

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

[rokli]

Hier noch mal die Ansicht der Daten in der DB als Bild; das ist da oben nicht wirklich gut zu erkennen!

Und alles natürlich in TSQL ...

[DCoderHH]

Zitat von rokli:

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

Wie würde man die Tabelle in einer Multiuser-Umgebung abfragen und setzen so dass es keine doppelten Nummern gibt? Ein einfaches select und update würde ja nicht funktionieren...

[himitsu]

MultiUser: Man nehme einen Generator (wie bei den AutoInc-Feldern) für den numerischen Anteil.
Und dann baut man sich 'ne DB-Funktion, die einen neuen AutoInc-Wert generieren lässt und dann YYYY, MM, DD mit AutoInc zusammensetzt und als VARCHAR rausgibt.
Diese Funktion könnte man z.B. auch als DEFAULT an ein Feld hängen und von der DB füllen lassen.

Wir haben bei uns 'ne Tabelle und paar Funktionen, wo mehrere solcher "Masken" definiert werden können, auch kundenabhängig, die man dann an irgendwelche Felder hängen kann oder im Programm abfragt.
Teilweise ist dann noch 'ne Lückenprüfung mit drin, welche abgefragte, aber dann doch nicht verwendete Werte findet und erneut nutzen kann.
Bei uns werden diese Werte, sowie die anderen DEFAULT-Werte, meistens nicht erst beim Post von der DB eingetragen, sondern schon von der Query-Komponente im OnAfterInster geladen, damit der User Diese bereits im Grid/den Edits sehen kann, bevor er speichert.