Der Angebots-Lebenszyklus

Ein Angebot hat ein eigenes Leben, bevor es eine Bestellung wird. Dieser Artikel beschreibt dieses Leben als Zustandsmaschine: was jeder Zustand bedeutet, wer ihn bewegen darf und was in dem Moment einfriert, in dem Sie auf Senden drücken.

Das Szenario

Ein Instandhaltungseinkäufer bei einem Maschinenbauer braucht 500 Meter Hydraulikschlauch in DN 12, geliefert an zwei Standorte, dazu 40 Verschraubungen. Ihr Katalog bepreist alles davon. Er fragt trotzdem ein Angebot an, weil seine Einkaufsrichtlinie über 5.000 € zwei schriftliche Angebote verlangt — und weil er die Lieferaufteilung schwarz auf weiß will.

Ihr Innendienst kalkuliert: Schlauch zu 4,80 € statt der 5,60 €-Staffel, Verschraubungen zum Listenpreis, Fracht separat angeboten. Das Angebot geht an einem Dienstag raus, vier Wochen gültig. Am Donnerstag fragt der Einkäufer, ob 600 Meter die Zahl ändern. Tun sie. Sie senden eine zweite Version. Elf Tage später legt sein ERP eine Bestellung gegen Version 2 an.

Diese ganze Abfolge — von der Anfrage bis zur Bestellung — ist der Angebots-Lebenszyklus. Jeder Zustand unten existiert, weil ihn jemand in dieser Geschichte gebraucht hat.

Die Zustände

Vier davon sind endgültig: declined, expired, cancelled und converted. Die übrigen können sich noch bewegen.

Die zwei Übergänge, auf die es ankommt

Alles andere ist Buchführung. Diese zwei ändern, was die Plattform tun darf.

draft → sent friert die Preise ein

Ein Angebot in draft zeigt lebende Preise. Öffnen Sie es morgen, können sich die Zahlen bewegt haben, denn sie werden aufgelöst wie jeder andere Preis der Plattform; siehe So funktioniert die Preisfindung.

Mit dem Senden hört das auf. Jede Zeile speichert den für sie aufgelösten Einzelpreis, die Mengenstufe, aus der er kam, die Währung, die Netto/Brutto-Basis und den Steuersatz — und löst nie wieder auf. Ein Angebot ist ein Snapshot, keine Live-Ansicht.

Das ist keine Bequemlichkeit. Es ist der Unterschied zwischen einem Angebot und einer Preisauskunft. Ein Käufer, der ein schriftliches Angebot erhält und auf der Auftragsbestätigung eine andere Zahl findet, hat einen Grund bekommen, anzurufen statt zu klicken — und genau diesen Fehlerfall soll die ganze Plattform vermeiden.

accepted → converted erzeugt eine Bestellung

Die Annahme ist ein kaufmännischer Fakt. Die Umwandlung ist ein Systemereignis, und die Trennung ist Absicht: Die entstehende Bestellung unterliegt denselben Freigaberegeln wie jede andere. Ein Käufer mit orders.request, aber ohne orders.create nimmt ein Angebot an und bekommt eine Bestellung in pending, die auf seinen eigenen Freigeber wartet; die zwei Türen in diesen Zustand stehen in Angebote, Freigaben und Verhandlung.

Was „eingefroren“ tatsächlich umfasst

Der Einzelpreis ist der offensichtliche Teil. Ein Angebot, über das sich später streiten lässt, ist eines, bei dem diese Dinge nicht eingefroren waren:

Eine angebotene Zeile hält genug fest, um aus sich selbst nachgerechnet zu werden. Können Sie die Summe eines gesendeten Angebots nicht aus dem Angebot selbst reproduzieren, ohne die Preisfindung irgendetwas zu fragen, ist der Snapshot unvollständig.

Gültigkeit und Ablauf

valid_until ist ein Zeitstempel, kein Datum. Er wird in der Zeitzone des Tenants ausgewertet: Ein „bis 30. April“ gültiges Angebot läuft am Ende des 30. April Ortszeit ab — nicht um Mitternacht UTC, was für einen deutschen Tenant im Sommer zwei Stunden zu früh wäre und Leute schon Abschlüsse gekostet hat.

Der Ablauf ist passiv. Nichts wird gelöscht, kein Preis neu berechnet, und der Käufer kann das Dokument weiter öffnen. Was sich ändert: Die Aktion Annehmen ist weg. Ein abgelaufenes Angebot lässt sich nicht umwandeln, denn die Preise darin waren ein Angebot für einen Zeitraum, der geendet hat.

Setzen Sie eine Standard-Gültigkeit in den Angebotseinstellungen und übersteuern Sie sie je Angebot. Dreißig Tage sind im Mittelstand ein üblicher Standard. Wählen Sie bewusst: Eine Gültigkeit, die länger ist als die Stabilität Ihrer eigenen Einkaufspreise, ist ein Versprechen, das Sie womöglich nicht halten können — und eine, die kürzer ist als der Freigabezyklus des Käufers, garantiert den Ablauf.

Was umgewandelt wird, und was nicht

Die Annahme kann teilweise sein. Der Käufer nimmt den Schlauch und nicht die Verschraubungen. Zwei ehrliche Arten, das zu modellieren, und eine davon müssen Sie als Regel festlegen:

• Alles oder nichts. Das Angebot ist ein kaufmännisches Paket; eine Teilannahme ist ein Gegenangebot und wird eine neue Version. Richtig, wo der Preis am ganzen Warenkorb hing.
• Annahme je Zeile. Der Käufer nimmt Zeilen einzeln an. Die Bestellung trägt die angenommenen Zeilen; der Rest des Angebots schließt als declined.

Die zweite ist freundlicher, die erste sicherer. Haben Sie einen Bündelrabatt wegen des Gesamtvolumens gegeben, verschenkt die Annahme je Zeile den Rabatt ohne das Volumen dahinter.

So wird das in der Revenue Cloud aussehen

Angebote leben unter Sales › Angebote. Die Tabelle zeigt Nummer, Konto, Wert, Zustand, Version und die Tage bis zum Ablauf — sortiert nach Ablauf, sodass der Kopf der Liste die Nachfassliste ist. Anfragen kommen unter Sales › Angebote › Anfragen an und bleiben dort, bis jemand daraus entwirft.

Eine Angebotsnummer kommt aus einem Nummernkreis derselben Form wie Ihre Bestellnummern (Präfix, Auffüllung, Zähler, Schritt), konfiguriert unter Configuration › Nummernkreise. Geben Sie Angeboten einen eigenen Kreis — AN-000412 neben SO-000198 sagt jedem, welches Dokument er in der Hand hält.

Weiter

• Angebote, Verträge und Rahmenverträge: die drei Dinge, die alle „vereinbarter Preis“ heißen.
• Eine Angebotsanfrage bearbeiten: die Tagesaufgabe, die dieser Lebenszyklus beschreibt.