Vorgehensweise für Rechnungsnummernvergabe im Multi-User Betrieb

[haentschman]

Hallo...

welches DBMS ist im Einsatz ? Persönlich würde ich folgenden Ablauf bevorzugen:
1. RE speichern
2. DBMS vergibt eine Nummer über einen Generator (Firebird)... ist damit eindeutig und fortlaufend
3. Die Query enthält als Rückgabewert die Nummer
4. Mit dieser Nummer können dann die Positionen gespeichert werden (Zuordnung)

[Bummi]

@haentschman
so kenn ich es auch, unter Berücksichtigung der Vorgaben finde ich die Implementierung von Neumann am interessantesten.

[Furtbichler]

Zitat von haentschman:

...
2. DBMS vergibt eine Nummer über einen Generator (Firebird)... ist damit eindeutig und fortlaufend
...

Man muss aufpassen, das es beim Speichern kein Rollback geben kann, das ist Alles.

[haentschman]

Klar, in diesem Ausnahmefall (bei fehlerhaftem Eintragen in die DB) wäre dann die Nummer verbraucht. Mit diesem Sonderfall hätten wahrscheinlich alle Lösungen ein Problem und sollte seperat behandelt werden.

[TBx]

Zitat von haentschman:

Klar, in diesem Ausnahmefall (bei fehlerhaftem Eintragen in die DB) wäre dann die Nummer verbraucht. Mit diesem Sonderfall hätten wahrscheinlich alle Lösungen ein Problem und sollte seperat behandelt werden.

Und genau dafür kann man die vorgeschlagene Möglichkeit mit der Rechnungsnummerntabelle verwenden!

[hoika]

Hallo,

die Sache mit dem Generator hat aber mit der Rechnungsnummer nichts zu tun (?).
Es gibt 2 Felder, RechnungsID (PrimKey,über Generator) und RechnungsNr(über eigene Logik, z.B. Sperrtabelle).


Heiko

[Furtbichler]

Na, die Idee stand im Raum, das man für die Rechnungs-Nr auch einen Generator verwendet.
Ich halte aber die Tabelle mit allen Rechnungsnummern (der nächsten 100 Jahre ) für den einzig richtigen Weg, um Lücken zu vermeiden.

Es ist ja schwer, dem Finanzamt zu vermitteln, weshalb Rechnung Nr.: 12345 nicht eingereicht wurde. Die interessiert dann nicht, wenn man dann die DB-Logdatei vorzeigt, der belegt, das eine Transaktion aufgrund was-weiss-ich fehlschlug.

Allerdings muss man bei der Lösung sicherstellen, das zu Ultimo (z.B. Monatsende) keine Lücken vorhanden sind.

[MGC]

Das Finanzamt sollte mittlerweile aber Erfahrung im Einsatz von DBMS haben udn wissen, dass es immer wieder mal zu Fehlern kommen kann.

Aufgrund der beschriebenen Architektur würde ich persönlich auch noch immer dabei bleiben die Re-Nr. erst zu vergeben, wenn die Rechnung tatsächlich gespeichert wird.
Bei der Rechnungsspeicherung darf es dann, wie bereits erwähnt, kein Rollback geben.

Man kann natürlich auch darauf vertrauen, dass es, aufgrund weniger Rechnungsstellungen pro Tag, hoffentlich niemals zu einem zeitgleichen Speichervorgang in der DB kommt, aber das wäre mir zu wage.