Lücken in Bon Nummern, Kassenabschluss Nummern etc.

[TurboMagic]

Hallo,

amngenommen man benutzt in einer Firebird Datenbank Generatoren die mittels Trigger
aktiviert werden um eindeutige IDs für sowas wie BON_ID eines Kassenzettels oder
die Kassenabschlussnummer eines Kassenabschlusses zu generieren.

Und angenommen die Anwendung stürzt irgendwo ab oder man kammt in eine Situation
wo man einen Rollback der Transaktion durchführt (sollte in der Anwendung nicht
passieren, aber Teufel ist ein Eichörnchen...) dann ist die generierte Nummer ja
verloren und man hat bei der nächsten Buchung eine Lücke in den Nummern, was so Leute
vom Finanzamt gar nicht gerne sehen dürften...

Wie mit sowas umgehen? Für diese Felder dann doch immer erst einen Select mit
Max(Spalte) durchführen und +1 machen? Damit nach einem Absturz bei der nächsten Bcuhung
die mit der anderen methodik "verbummelte ID" wieder benutzt wird?

Das würde in dem Fall sogar funktionieren, da die jeweiligen Tabellen i.d.R-. noch ein wie
oben beschriebenes Schlüsselfeld haben, was wieder eindeutig wäre und für jede Kasse immer
nur eine Buchung zu einem Zeitpunkt stattfindet, selbst wenn dieselbe Datenbank für mehrere
Kassen benutzt würde.

Grüße

TurbnoMagic

[himitsu]

Tja, dann eben nicht den Generator direkt benutzen, sondern in eine Funktion packen, welche nachsieht, ob die letzte Nummer doch nicht benutzt wurde.
Ob dann dennnoch mit Generator oder einfach nur Max(Spalte)+1 ist erstmal egal.


Wir haben an einigen Stellen eine Lückensuchfunktion, welche auch nach Lücken zwischen den letzten X Datensätzen sucht (mit einer zusätzlichen ReserviertTabelle),
aber da sind es auch mehrere/hunderte Clients beteiligs, die Nummern müssen nicht aufeinanderfolgend sein und die Nummer und andere Defauts werden bereits beim "DataSet-Insert" geholt, damit der User es schon bei der Eingabe sieht.


Du kannst es auch wie bei einer Blockchain machen.
im nächsten/neuen Datensatz irgendwie den Vorherigen mit erwähnen, bzw. den letzten/vorherrigen oder aktuellen Kassenstand,
dann ist erkenntlich, dass diese Nummer richtigerweise fehlt, weil es ja nachvollziehbar ist, dass es dennoch aufeinanderfolgt.

[josef-b]

Zitat:

Wie mit sowas umgehen? Für diese Felder dann doch immer erst einen Select mit
Max(Spalte) durchführen und +1 machen? Damit nach einem Absturz bei der nächsten Bcuhung
die mit der anderen methodik "verbummelte ID" wieder benutzt wird?

genau

Wir arbeiten auch mit Firebird, früher haben wir es auch mit Triggern und Generatoren für jede Tabelle gemacht.

Mittlerweile haben wir nur noch einen einzigen Generator für die ganze Datenbank, nämlich für das Feld "ID".
Das Feld "ID" hat jede Tabelle als Primary Key, ohne jede Ausnahme.

Also Felder für tbl Kasse...ID, Bonnummer, Betrag etc...
Felder für tbl Aufträge... ID, AUftragsnummer, Artikel etc
Felder für tbl Bestellung ... ID, Bestellnummer, Artikel etc.

Da die ID über die ganze Datenbank nur einmal vorkommt, kannst du jede Tabelle mit jeder über Parent und Child Tabellen verknüpfen..
Das ist z.B. super wenn du einen Beleg als Dokumment dem Auftrag, der Kasse und der Bestellung zuordnen möchtest..

Die "Tabellen-Generatoren" speichern wir in einer normalen Datenbank Tabelle ab..Hat den Vorteil, dass du da
vielleicht noch speichern kannst, wer zuletzt wann da was gemacht hat..oder so

[jaenicke]

Du kannst das auch einfach z.B. in einer Tabelle mit Erklärung loggen. Das sollte ja nicht oft vorkommen und wenn sich diese Fälle dann erklären lassen, passt alles.

Nebenbei gibt es keine Regel, meines Wissens gilt das nach wie vor, dass die Nummern fortlaufend sein müssen. Sie müssen lediglich eindeutig sein und dafür ist fortlaufende Nummerierung natürlich gut geeignet. In der Praxis verlangen es aber viele Prüfer und wer hat schon Lust auf den Ärger, auch wenn man im Recht ist?

[josef-b]

Zitat von jaenicke:

Du kannst das auch einfach z.B. in einer Tabelle mit Erklärung loggen. Das sollte ja nicht oft vorkommen und wenn sich diese Fälle dann erklären lassen, passt alles.

Nebenbei gibt es keine Regel, meines Wissens gilt das nach wie vor, dass die Nummern fortlaufend sein müssen. Sie müssen lediglich eindeutig sein und dafür ist fortlaufende Nummerierung natürlich gut geeignet. In der Praxis verlangen es aber viele Prüfer und wer hat schon Lust auf den Ärger, auch wenn man im Recht ist?

Ja das stimmt absolut.

Wenn man sich z.B. die Rechnungen von Amazon anschaut, da sind die Nummern Alpha-Numerisch, ja dann auch keiner Nachvollziehen, ob die lückenlos vergeben wurden..auch das ist, soweit ich weiss, erlaubt.

[himitsu]

Grund, warum z.B. bei Amazon, Post und Anderen das nicht fortlaufend ist, damit Hacker nicht einfach auf Nummern schließen können,
also aktuelle Nummer besorgen und dann weiß man welche andere Rechnungsnummern, bzw. Trackingnummern es somit gibt.

Und sie könnten ja dennoch intern zusätzlich noch eine weitere fortlaufende Nummer haben, für den mürrischen Prüfer.

[TurboMagic]

Danke für diese Anregungen.
Ich hab's jetzt jeweils auf eine Max(Nummer)+1 Lösung geändert.

[TBx]

Zitat von TurboMagic:

Danke für diese Anregungen.
Ich hab's jetzt jeweils auf eine Max(Nummer)+1 Lösung geändert.

Ich hoffe, Du hast auf der Spalte einen entsprechenden Index (absteigend sortiert). Sonst wartest Du Dir bei großen Tabellen irgendwann den Wolf.

[MyRealName]

MaxNr + 1 ist aber nicht mehr transaktionssicher. Das heisst, in einem von x Fällen kommt es leider doch vor, dass 2 Clients sich versuchen, diese Nummer zu krallen.

[TurboMagic]

Zitat von MyRealName:

MaxNr + 1 ist aber nicht mehr transaktionssicher. Das heisst, in einem von x Fällen kommt es leider doch vor, dass 2 Clients sich versuchen, diese Nummer zu krallen.

Ja und nein: da ein und die selbe Kasse nichts parallel verbucht, passt das, denn es gibt eine
where Klausel mit eindeutiger KassenID.