CoeveraBlueprints

Blueprint 006 · Nummerierung

Wie richten Sie eine Dokumentnummerierung ein, die den Produktivbetrieb übersteht?

Rechnungsnummern, Fallreferenzen, Belegnummern. Eine erzeugen zu lassen, ist eine Sache von fünf Minuten. Sicherzustellen, dass sie in achtzehn Monaten noch stimmt, nachdem jemand das Muster bearbeitet hat, ist das eigentliche Problem.

Geschrieben von Veröffentlicht 2026-09-23Geprüft in einem Live-Coevera-SpaceÜbersetzt aus dem englischen OriginalMarkdown-Fassung ↓

Die kurze Antwort

Verwenden Sie ein Auto number-Feld. Sein Muster ist ein Baukasten aus Segmenten – Literaltext, ein Year (YYYY)-Token, ein Autocount –, und das Autocount-Segment hat eine Auswahl zwischen „Reset count every year“ und „Don't reset count“. Der jährliche Reset ist eine native Option, und es ist keine Automatisierung nötig. Dass der Zähler an einem echten Jahreswechsel auf 1 zurückkehrt, wurde nicht beobachtet (siehe §7).

Wenn Sie das Muster später über die API ändern, lassen Sie die angehängte Zahl weg. Das Hilfecenter beschreibt diesen Weg nicht; dort heißt es, dass sich die Optionen nach Save nicht mehr ändern lassen. Das ,1 in {#Number4,1} ist ein Startindex, keine Verzierung: Es bedeutet diese Serie bei 1 beginnen, und genau das tut es jedes Mal, wenn es gesendet wird – auch bei einem Feld, das seit zwei Jahren Nummern vergibt. Schreiben Sie {#Number4}, und der Zähler läuft dort weiter, wo er stand.

Das Geschäftsproblem

Ein Geschäftsdokument braucht eine Referenz für Menschen – eine Rechnungsnummer, eine Fallnummer, eine Belegnummer, die auf Papieren erscheint und in E-Mails und Telefonaten zitiert wird. Die Anforderungen sind unspektakulär und streng:

  • Eindeutig, dauerhaft. Zwei Dokumente mit derselben Nummer sind kein kosmetisches Problem.
  • Lesbar und aussprechbar – jemand liest sie am Telefon vor.
  • Auf das Jahr bezogen, in den meisten Rechtsordnungen und in der meisten Buchhaltungspraxis: Die Sequenz beginnt jeden Januar neu, sodass die Nummer ihren eigenen Zeitraum trägt.
  • Stabil – einmal vergeben, ändert sie sich nie, weil sie auf Dokumenten gedruckt ist, die das Haus verlassen haben.

In der Buchhaltung ist das nicht bloß Konvention. Eine Belegnummernserie, die einen Wert wiederholt, ist ein Prüfungsbefund und in mehreren Rechtsordnungen ein Compliance-Problem statt einer Unannehmlichkeit.

Warum der naheliegende Ansatz scheitert

Die Nummer selbst bauen, weil es heißt, man müsse das

Sie werden Ratschläge finden, die Ihnen sagen, Sie müssten die Nummer selbst bauen. Sie besagen, dass sich Sequenzfelder nicht pro Jahr zurücksetzen lassen und dass eine Belegnummer mit Jahrespräfix daher in einem Automatisierungsprozess zusammengesetzt werden muss – ein einfacher Zähler für die laufende Nummer und ein Prozess, der das Jahr davorsetzt.

Dieser Rat ist falsch, und er wird so häufig wiederholt, dass es sich lohnt, ihn zu benennen. Die Plattform hat eine ausdrückliche Option „Reset count every year“ direkt im Mustereditor. Bevor Sie einen Prozess zum Zusammensetzen bauen, öffnen Sie den Feldeditor und sehen Sie nach.

Es lohnt sich, konkret zu benennen, was die unnötige Umgehung kostet, denn dieselbe Überlegung gilt immer, wenn Sie einen nativen Mechanismus durch Automatisierung ersetzen:

  • Eine zweite Quelle der Wahrheit. Der echte Zähler und das zusammengesetzte Textfeld können voneinander abweichen, und nichts gleicht sie ab.
  • Eine Race Condition. Zwei Datensätze, die im selben Augenblick angelegt werden, können mit derselben Nummer zusammengesetzt werden, weil nicht das Zusammensetzen die Eindeutigkeit erzwingt.
  • Ein Fehlerbild ohne Signal. Wenn der Prozess deaktiviert ist, fehlschlägt oder herausgefiltert wird, entstehen Datensätze mit leerer Belegnummer, und niemand bemerkt es, bis jemand nachsieht.
  • Laufende Pflege einer Logik, die die Plattform für Sie gepflegt hätte.

Die Datensatz-ID verwenden

Technisch eindeutig und nutzlos. Sie ist eine UUID: nicht lesbar, nicht aussprechbar, nicht auf das Jahr bezogen, und einem Kunden sagt sie nichts.

Der Musterbaukasten

Der Feldtyp heißt in der Oberfläche Auto number. Sein Muster wird aus geordneten Segmenten zusammengesetzt, statt als String eingetippt zu werden:

SegmentZweck
TextEin wörtliches Präfix oder Trennzeichen – ein Dokumenttyp-Code, ein Firmenkürzel.
Year (YYYY)Das vierstellige Jahr, ermittelt bei der Anlage des Datensatzes.
AutocountDie laufende Nummer mit ihrer Stellenzahl. Dieses Segment trägt die Reset-Auswahl.
TextWeitere wörtliche Segmente, vor oder nach einem der obigen.

Am Autocount-Segment gibt es zwei sich gegenseitig ausschließende Optionen: Reset count every year und Don't reset count. Diese eine Auswahl ist die Antwort auf die Frage, nach der dieser Blueprint benannt ist.

Der Editor zeigt beim Aufbauen ein Live-Beispiel des nächsten Werts – Example: TST20260004 –, was beim Konfigurieren nützlich ist. Behandeln Sie es als Prüfung der Formatierung, nicht als Beleg für den Zähler; darüber gibt nur ein angelegter Datensatz Auskunft.

Konfiguration und die Form in der API

Programmatisch anlegen

Das Muster wird als Token-String ausgedrückt, und das Feld trägt ein Objekt sequence:

sequence: {
  defaultItem: { pattern: "TST{#Year}{#Number4,1}" },
  items: []
}

Der erste Datensatz aus diesem Muster: TST20260001. Der vierstellige Zähler wurde über die API akzeptiert; für ein in der Oberfläche festgelegtes Muster gibt das Hilfecenter für die Zahl mindestens fünf Stellen vor.

Anlageform und Leseform unterscheiden sich. Das ,1 ist der Startindex – „diese Serie bei 1 beginnen“ –, und er wird nach der Veröffentlichung des Felds herausnormalisiert, sodass das Zurücklesen des Felds das bereinigte {#Number4} liefert.

Das ist die Regel für eine spätere Musteränderung über die API: Senden Sie das Muster ohne die angehängte Zahl. Das Hilfecenter beschreibt diesen Weg nicht; dort heißt es, dass sich die Optionen nach Save nicht mehr ändern lassen. Der Startindex ist eine Anweisung, und sie wird jedes Mal befolgt, wenn sie ankommt. Ändern Sie TST{#Year}{#Number4,1} in INV{#Year}{#Number4,1} – eine Präfixänderung, scheinbar harmlos –, und die Serie startet bei 1 neu und vergibt Nummern ein zweites Mal, die sie bereits ausgegeben hat. Ändern Sie es in INV{#Year}{#Number4}, und der Zähler läuft unberührt weiter.

Das sichere Vorgehen und der Grund, warum sich die beiden Formen unterscheiden: Lesen Sie das Feld, übernehmen Sie sein pattern wörtlich, ändern Sie nur, was Sie ändern wollten, und senden Sie das zurück. Was das Feld meldet, ist bereits normalisiert und trägt daher nie einen Startindex. Wenn Sie Nutzlasten aus einer gespeicherten Vorlage statt aus einem Lesevorgang erzeugen, entfernen Sie ,<n> aus dem Zähler-Token bei allem, was kein brandneues Feld ist.

Zwei API-Fallen bei der Anlage. Eine Eigenschaft sequence_pattern am REST-Feld-Endpunkt ist veraltet – die API lehnt sie mit einer Meldung ab, die Sie auffordert, stattdessen die Eigenschaft sequence zu verwenden. Aber das neue Objekt sequence über denselben REST-Endpunkt zu senden, liefert einen 500. Das Anlegen des Felds über die Administrations-API funktionierte; der REST-Weg nicht.

Der Zähler ist ein dreiteiliger Zustand

Das Feld stellt seinen Zähler als last_particle bereit, und das ist keine einzelne Ganzzahl:

last_particle: { year: 2026, month: 0, sequence_number: 2 }

Daraus folgen zwei Dinge. Die Monatskomponente bleibt bei null, wenn das Muster kein Monats-Token enthält; ihr Vorhandensein bedeutet also kein monatliches Verhalten. Und die Jahreskomponente ist der Mechanismus hinter dem jährlichen Reset – die Engine hält das Jahr fest, zu dem der Zähler gehört, und genau das lässt sie ein neues Jahr erkennen und neu beginnen.

Segmentierte Zähler

Das Array items neben defaultItem nimmt Einträge auf, die jeweils ihr eigenes pattern und ihren eigenen Filter tragen. Das ist die Form eines Mechanismus für mehrere unabhängige Zähler auf einem Feld, ausgewählt über eine Bedingung am Datensatz – eine eigene Serie pro Dokumenttyp oder pro Organisationseinheit.

Seine Semantik ist nicht verifiziert – siehe §6.

Wann Sie doch Automatisierung brauchen

Meistens nicht – das ist der Kern von §2. Es gibt einen echten Fall, in dem das native Feld die Aufgabe nicht erfüllen kann.

Das Year-Token wird aus der Datensatzanlage ermittelt. Wenn das Jahr Ihrer Belegnummer aus einem anderen Datum stammen muss – einem Rechnungsdatum, einem Belegdatum, einem Leistungszeitraum, der in ein anderes Jahr fallen kann als die Erfassung des Datensatzes –, kann das Auto-number-Feld das nicht ausdrücken. Der Zähler läuft außerdem in der Reihenfolge der Anlage weiter, nicht in der Reihenfolge dieses Datums.

Dort, und nur dort, ist der Ansatz des Zusammensetzens richtig: ein natives Auto-number-Feld liefert den garantiert eindeutigen laufenden Teil, und ein Prozess setzt die sichtbare Belegnummer aus dem Jahr des gewählten Datums plus dieser Nummer zusammen. Akzeptieren Sie ausdrücklich, dass Anlagereihenfolge und Reihenfolge nach Belegdatum dann auseinanderlaufen können, und entscheiden Sie vorab, welche das Unternehmen als maßgeblich betrachtet – diese Frage ist vor dem Go-live viel leichter zu beantworten als danach. Es ist außerdem ein weiterer Prozess, für den jemand zuständig sein muss, also bauen Sie ihn nach den Konventionen in Blueprint 011 dazu, wie Automatisierungen wartbar bleiben.

Grenzen & Kompromisse

Lückenlose Nummerierung ist nicht erreichbar

Eine Nummer wird vergeben, wenn der Datensatz angelegt wird. Legen Sie einen Datensatz an und löschen ihn, ist die Nummer verbraucht – die Serie hat eine Lücke, und keine Konfiguration verhindert das. Wenn Ihre Rechtsordnung oder Ihr Prüfer eine ununterbrochene Serie verlangt, sprechen Sie das vor dem Go-live an, denn die Antwort wird ein Abstimmungsverfahren sein, keine Einstellung.

Quelle. Coevera-Hilfecenter, Advanced fields & forms — Autonumber fields: „Eine neue Nummer wird jedes Mal erzeugt, wenn ein neuer Datensatz gespeichert wird. Eine automatische Nummer lässt sich zum Beispiel nicht auslösen, wenn eine Opportunity verschoben wird, sondern nur bei der Anlage des Datensatzes.“

Das Jahr stammt aus dem Anlagedatum, und nur von dort

Das Year-Token wird bei der Anlage des Datensatzes ermittelt, und der Zähler läuft in der Reihenfolge der Anlage weiter. Eine Nummer, deren Jahr aus einem anderen Datum stammen muss – einem Rechnungsdatum, einem Belegdatum, einem Leistungszeitraum –, kann das Feld nicht ausdrücken, und §5 beschreibt die Zusammensetzung, die Sie stattdessen brauchen. Die Folge, die vorab zu entscheiden ist: Anlagereihenfolge und Reihenfolge nach Belegdatum können dann voneinander abweichen.

Eine Serie, die sich mehrere Arten von Datensätzen teilen, ist der übliche Grund, warum ein einziges Feld das gesamte Geschäft tragen muss – siehe Blueprint 001, in dem fünf Anfragetypen über eine einzige Referenznummernserie laufen.

Mehrere Zähler auf einem Feld sind nicht verifiziert

Das in §4 beschriebene Array items hat die Form eines Mechanismus für unabhängige Serien auf einem Feld. Wir haben es nicht getestet und sagen das, statt ein Verhalten zu beschreiben, das wir nicht beobachtet haben. Behandeln Sie eine Serie pro Typ oder pro Einheit als Designrisiko, bis Sie gesehen haben, dass sie funktioniert.

Was Sie sonst noch wissen sollten

  • Die gemeldete Anzahl der Veröffentlichungsoperation ist kein Erfolgssignal. Sie lieferte in unseren Tests bei jedem Aufruf null, während nachweislich veröffentlicht wurde.
  • Die Feldanlage wird uneinheitlich veröffentlicht. Derselbe Anlageaufruf lieferte einmal ein bereits veröffentlichtes Feld und ein andermal einen unveröffentlichten Entwurf. Prüfen Sie den Veröffentlichungsstatus; nehmen Sie ihn nicht an.

Verifizierung

Nummerierung gehört zu den Funktionen, die korrekt aussehen, bis sie geprüft werden; die Prüfungen betreffen daher vergebene Werte statt der Konfiguration.

  • Lesen Sie Nummern von angelegten Datensätzen, nicht aus der Feldkonfiguration. Die Konfiguration sagt Ihnen, was die Engine vorhat; nur eine vergebene Nummer sagt Ihnen, was sie getan hat.
  • Legen Sie mindestens drei Datensätze an und bestätigen Sie die Erhöhung, statt einen anzulegen und den Rest anzunehmen.
  • Lesen Sie den Zähler zurück nach jeder Konfigurationsänderung – die Jahres- und Zählerkomponente sollten zur zuletzt vergebenen Nummer passen. Lesen Sie gleichzeitig das Muster zurück: Das ist der String, den Sie für die nächste Bearbeitung wiederverwenden müssen.
  • Veröffentlichen Sie nach jeder Musteränderung und legen Sie dann einen Datensatz an, und prüfen Sie seine Nummer gegen die höchste bereits vergebene. Das dauert Sekunden und ist die Prüfung, die einen Zähler erkennt, der nicht übernommen wurde.
  • Testen Sie Eindeutigkeit als Abfrage, nicht als Annahme: Gruppieren Sie nach dem Nummernfeld und bestätigen Sie, dass kein Wert doppelt vorkommt. Tun Sie das nach jeder Konfigurationsänderung und zusätzlich als geplante Prüfung, wenn die Nummern für das Audit relevant sind.
  • Wenn der jährliche Reset aktiviert ist, prüfen Sie ihn an einem echten Jahreswechsel, bevor Sie sich darauf verlassen. Das konnten wir nicht, und wir sagen das, statt ein Verhalten zu behaupten, das wir nicht haben eintreten sehen.

Was auf eine Regression hindeuten würde: jeder doppelte Wert im Nummernfeld; ein Zähler, dessen Jahreskomponente nicht zu den vergebenen Nummern passt; ein Datensatz, der mit leerer Nummer angelegt wurde – was bedeutet, dass ein Prozess zum Zusammensetzen fehlgeschlagen ist und nicht das native Feld.

Häufige Fragen

Kann ein CRM eine Referenznummer erzeugen, die jedes Jahr wieder bei 1 beginnt?

Ja. In Coevera CRM wird ein Auto-number-Feld aus einem Muster von Segmenten aufgebaut – Literaltext, ein Year-Token und ein Autocount-Segment –, und das Autocount-Segment bietet eine ausdrückliche Wahl zwischen dem Zurücksetzen des Zählers in jedem Jahr und dem Verzicht darauf. Es ist keine Automatisierung nötig. Ein Muster aus Text plus Year plus einem vierstelligen Zähler erzeugt Werte wie TST20260001; der vierstellige Zähler wurde über die API akzeptiert, während das Hilfecenter für ein in der Oberfläche festgelegtes Muster mindestens fünf Stellen für die Zahl vorgibt. Die Option für den jährlichen Reset existiert; dass der Zähler an einem echten Jahreswechsel auf 1 zurückkehrt, wurde nicht beobachtet.

Wie wird der Zähler einer automatisch erzeugten Nummer gespeichert?

Als dreiteiliger Zustand: Jahr, Monat und laufende Nummer. In Coevera ist das am Feld als last_particle sichtbar. Nach zwei Datensätzen unter einem Muster mit Year-Token, aber ohne Monats-Token, lautet er Jahr 2026, Monat 0, laufende Nummer 2 – die Monatskomponente bleibt bei null, wenn das Muster sie nicht verwendet. Die Jahreskomponente ist das, was den jährlichen Reset möglich macht: Die Engine vergleicht das gespeicherte Jahr mit dem aktuellen.

Wie ändern Sie das Muster eines bestehenden Felds mit automatischer Nummerierung?

Über die API, die das Hilfecenter nicht beschreibt: Dort heißt es, dass sich die Optionen nach Save nicht mehr ändern lassen. Senden Sie das neue Muster ohne den Startindex. Das Zähler-Token kann einen tragen – geschrieben als Komma und Zahl innerhalb des Tokens, zum Beispiel Number4, gefolgt von einem Komma und 1 –, und er weist die Engine an, die Serie bei diesem Wert zu beginnen. Er wird jedes Mal befolgt, wenn er gesendet wird, auch bei einem Feld, das bereits Tausende von Nummern vergeben hat; eine Musteränderung, die den Startindex beibehält, startet die Serie also bei dieser Zahl neu und vergibt Werte, die bereits in Gebrauch sind, ein zweites Mal. Wird das Zähler-Token ohne Komma und Zahl geschrieben, bleibt der Zähler unberührt, und es ändert sich nur, was Sie ändern wollten. Der Startindex wird außerdem nach der Veröffentlichung eines Felds herausnormalisiert, sodass das Muster, das ein Feld zurückmeldet, nicht das Muster ist, mit dem es angelegt wurde: Das sichere Vorgehen ist, das Feld zu lesen, sein Muster wörtlich zu übernehmen, nur den Teil zu bearbeiten, den Sie ändern wollen, und das zu senden. Prüfen Sie das Ergebnis anhand einer vergebenen Nummer auf einem neu angelegten Datensatz statt anhand der Feldkonfiguration.

Kann das Jahr in einer Dokumentnummer aus einem Rechnungsdatum statt aus dem Anlagedatum stammen?

Nicht aus dem Auto-number-Feld selbst. Sein Year-Token wird aus dem Zeitpunkt der Datensatzanlage ermittelt, und der Zähler läuft in der Reihenfolge der Anlage weiter; eine Nummer, deren Jahr aus einem separaten Datumsfeld abgeleitet werden muss – einem Rechnungs- oder Belegdatum, das vom Anlagedatum abweichen kann –, lässt sich also nicht nativ erzeugen. Dieser Fall verlangt, die sichtbare Nummer in einem Automatisierungsprozess aus einem einfachen Zähler plus dem Jahr des gewählten Datumsfelds zusammenzusetzen, und zu akzeptieren, dass beides auseinanderlaufen kann.

Herausgegeben von Coevera · auf das Muster abstrahiert, keine KundendatenBlueprint 006 · veröffentlicht 2026-09-23