Vorgangs- und Bestellnummern: Was sollte Ihre Geschäfts-App zusagen?

Jeder Auftrag und jede Bestellung braucht eine verlässliche Referenz, mit der Mitarbeitende und Kunden denselben Vorgang wiederfinden. Legen Sie vor der Entwicklung fest, wann diese Referenz endgültig vergeben wird, in welchem Bereich sie eindeutig sein muss, ob Lücken zulässig sind und wie importierte Vorgänge behandelt werden. Eine automatisch hochgezählte Nummer beantwortet diese Fragen nicht von selbst.

Hier geht es um betriebliche Vorgangs- und Bestellreferenzen, nicht um rechtskonforme Rechnungsnummern. Für gesetzlich geregelte Dokumente lassen Sie die geltenden Anforderungen fachkundig klären und beschreiben das Nummerierungsverfahren gesondert.

Wofür wird die Referenz im Alltag gebraucht?

Eine brauchbare Referenz ermöglicht den Satz „Ich rufe wegen dieser Bestellung an“, ohne dass jemand den ganzen Vorgang erklären muss. Wählen Sie ein Format, das Ihr Team vorlesen, suchen und von der kundenseitigen Bestellnummer unterscheiden kann.

Halten Sie beide Angaben getrennt. Die Referenz eines Kunden kann bei einem anderen Kunden ebenfalls vorkommen, falsch eingegeben oder auf Wunsch geändert werden. Sie ersetzt deshalb nicht ohne Weiteres die stabile Zuordnung, die Ihre Anwendung benötigt.

Schreiben Sie auf, wo die Nummer eindeutig sein muss: im ganzen Unternehmen, innerhalb einer Niederlassung oder in einer Jahresserie. Können unterschiedliche Serien dieselbe Kurznummer enthalten, brauchen Suchergebnisse und Exporte genügend Kontext. Ein Präfix hilft nur, wenn die Empfänger es verstehen.

Eindeutig ist nicht dasselbe wie lückenlos

Die PostgreSQL-Dokumentation zu Sequenzen erläutert, dass gleichzeitige Aufrufe der Funktion für den nächsten Wert jeweils unterschiedliche Sequenzwerte erhalten. Sie warnt außerdem vor Lücken durch abgebrochene Transaktionen und Abstürze und hält ausdrücklich fest, dass Sequenzobjekte keine lückenlosen Folgen liefern. Das beschreibt einen bestimmten Datenbankmechanismus, nicht jede denkbare Nummerierung.

Für eine gewöhnliche Auftragsliste sollten Sie entscheiden, ob Eindeutigkeit ausreicht. Lassen Sie bestehende Vorgänge nicht neu nummerieren, nur damit eine sichtbare Lücke verschwindet. Eine bereits versendete Referenz würde dann nicht mehr denselben Auftrag bezeichnen.

Eine Lücke allein beweist auch nicht, dass jemand einen Auftrag gelöscht hat. Fragen Sie, wie der Support einen fehlenden Verweis anhand des tatsächlichen Ablaufs untersucht, statt aus der Zahlenfolge zu schließen. Brauchen Sie wirklich eine lückenlose Serie, erklären Sie den fachlichen Grund und lassen Sie dafür einen eigenen Prozess planen.

Wann wird aus einer Nummer eine verbindliche Referenz?

Hat ein Entwurf zunächst eine vorläufige Kennung? Wird die endgültige Nummer beim Anlegen, Freigeben oder Bestätigen vergeben? Halten Sie den gewählten Zeitpunkt fest und klären Sie, was Kunden vorher sehen.

Für Sequenzwerte, die dauerhaft außerhalb der Datenbank verwendet werden sollen, verlangt die PostgreSQL-Dokumentation, zunächst den erfolgreichen Abschluss der Transaktion mit dem Aufruf für den nächsten Wert sicherzustellen. Für Ihr Briefing lautet die Frage: Gehört die Nummer in einer Bestätigung tatsächlich zu einem gespeicherten Vorgang? Lassen Sie einen Fehler zwischen Speichern und Ergebnisanzeige vorführen.

Beschreiben Sie außerdem das erneute Absenden. Ein zweiter Klick soll nach Ihrer vereinbarten Regel für doppelte Anfragen behandelt werden und nicht ungewollt zwei Bestellungen erzeugen. Nummernvergabe und Schutz vor Doppelverarbeitung hängen zusammen, sind aber getrennte Anforderungen.

Die Referenz bleibt bei ihrem Vorgang

Vereinbaren Sie, dass eine Namensänderung des Kunden, eine neue Zuständigkeit oder ein Wechsel der Niederlassung nicht stillschweigend die bereits mitgeteilte Referenz ersetzt. Muss eine sichtbare Nummer geändert werden, legen Sie fest, wie Berechtigte über die alte Nummer weiterhin den richtigen Vorgang finden und die Änderung nachvollziehen.

Bei einem Datenimport kann die Nummer des Altsystems als eigenes Suchfeld erhalten bleiben. Klären Sie Kollisionen vor dem Import. Ein Vorgang darf nicht allein deshalb überschrieben werden, weil ein anderes System dieselbe Nummer verwendet hat.

Für stornierte Arbeit braucht es den vereinbarten Status und eine Erklärung. Eine alte Nummer für einen anderen Auftrag wiederzuverwenden, kann Leser früherer Bestätigungen verwirren. Als Ausgangspunkt empfiehlt sich deshalb, auf diese Wiederverwendung zu verzichten.

Schwer zu erraten heißt nicht zugriffsgeschützt

Die OWASP-Empfehlungen gegen unsichere direkte Objektreferenzen betonen, dass Zugriffsprüfungen auch bei komplexen Kennungen notwendig bleiben. Wer eine Auftragsnummer kennt, soll dadurch nicht automatisch die Auftragsdetails sehen dürfen.

Lassen Sie mit Testkonten verschiedener Kunden in einer isolierten Umgebung zeigen, dass eine geänderte Referenz keinen fremden Vorgang offenlegt oder verändert. Das ist eine gezielte Prüfung, keine vollständige Sicherheitsbewertung.

Was vor der Übergabe feststehen sollte

Notieren Sie Format, Eindeutigkeitsbereich, Vergabezeitpunkt, Umgang mit Lücken und Stornierungen, Importzuordnung sowie Suche nach alten Referenzen. Prüfen Sie danach gleichzeitiges Anlegen, einen abgebrochenen Speichervorgang, eine wiederholte Anfrage und eine Kollision beim Import. Bildschirm, Bestätigung und Export müssen dieselbe vereinbarte Referenz zeigen.

Machen Sie daraus Akzeptanzkriterien. Bringen Sie in das Gespräch über eine individuelle Geschäfts-App Beispiele aus Ihrem bisherigen Ablauf mit, ohne vertrauliche Angaben. Ziel ist eine zuverlässige Zuordnung von Arbeit, nicht ein hübsches Nummernmuster.

Quellen und Grenzen

• PostgreSQL, Sequence Manipulation Functions: https://www.postgresql.org/docs/current/functions-sequence.html
• OWASP, Insecure Direct Object Reference Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

Die Quellen belegen die konkreten Aussagen zu Sequenzen und Zugriffsprüfungen. Format, Beständigkeit, Stornierungen und Importregeln sind Empfehlungen für Ihr Briefing, keine rechtlichen Nummerierungsvorschriften.