Was ein Konfigurator mit 41 Optionen erfordert
Bei einem Konfigurator steckt die Arbeit in den Regeln: Welche Optionen schließen sich aus, und welche Kombinationen verändern den Preis? Wir haben einen für einen Fertiggaragen-Hersteller gebaut, mit 41 Optionen. In dieser Größe müssen Abhängigkeiten als Daten abgebildet werden, denn fest einprogrammierte Wenn-dann-Abfragen brechen, sobald eine neue Option dazukommt.
Abhängigkeiten als Daten
Bei einigen Dutzend Optionen gibt es zu viele Kombinationen, um sie aufzulisten, deshalb werden sie geprüft. Jede Option wird mit ihren Abhängigkeiten und Ausschlüssen als Daten gespeichert und bei jeder Änderung gegen die aktuelle Auswahl geprüft.
Das wichtigste Problem ist eine veraltete Auswahl. Eine Option blendet ein zweites Feld ein, dort wird etwas gewählt, dann ändert sich die erste Option, und die zweite Wahl ist nicht mehr gültig. Prüft die Validierung nur vorwärts, bleibt die alte Wahl in der Bestellung und wird mitberechnet. Deshalb wird nach jeder Änderung die gesamte Konfiguration neu geprüft, und was nicht mehr gültig ist, fällt sichtbar aus der Summe, damit der Kunde sieht, warum sich der Preis geändert hat.
Die Validierung läuft außerdem an zwei Stellen: im Browser, damit das Formular sofort reagiert, und auf dem Server, weil Besucher den Code im Browser ändern können. Das ist ein Regelwerk, das zweimal geprüft wird, und die beiden Prüfungen können auseinanderlaufen. Ein Serveraufruf bei jedem Klick würde das vermeiden, macht das Formular bei schwacher Verbindung aber träge. Beide Prüfungen bei Regeländerungen in Übereinstimmung zu halten, ist der schwierige Teil; stimmen sie nicht überein, springt die Summe beim Absenden.
Preisbildung nach Kombination
Die meisten Optionen addieren einen festen Betrag. Manche Preise hängen aber von einer Kombination von Optionen ab, deshalb hat eine Preisregel ein eigenes Modell: eine Bedingung über die gesamte Konfiguration und ihre Wirkung auf den Preis.
Die Rechnung muss exakt und reproduzierbar sein. Geld wird in Cent als Ganzzahl berechnet, und das Ergebnis wird mit Netto- und Bruttobetrag sowie dem Mehrwertsteuersatz gespeichert. Dieselbe Konfiguration muss beim zweiten Absenden denselben Preis ergeben, auch nachdem eine Regel geändert wurde. Deshalb werden Preisregeln versioniert, und jedes Angebot speichert die Version, mit der es berechnet wurde. Sonst würde eine normale Preisanpassung die Geschichte aller bereits verschickten Angebote verändern.
Die Regeln müssen auch für den lesbar bleiben, der sie pflegt. Ein Editor, der jede Regel abbilden kann, lässt auch widersprüchliche Regeln zu, deshalb beschränken wir ihn auf die Regeltypen, die die Engine kennt. Ein neuer Regeltyp ist eine Codeänderung.
Das Angebot als Dokument
Die zweite Anforderung, die gern unterschätzt wird, ist die Dokumenterzeugung. Käufer leiten das Angebot an ihre eigenen Kunden weiter oder legen es einer Ausschreibung bei, deshalb ist es ein PDF im Corporate Design mit Referenznummer, gewählter Spezifikation, Preis und Konditionen. Dieses PDF wird auf dem Server erzeugt.
Aus dem Browser zu drucken macht die Ausgabe von der Maschine abhängig, die gedruckt hat: Schriften, Seitenformat, was auch immer das Betriebssystem ersetzt. Ein weitergeleitetes Dokument muss in jeder Kopie identisch sein, also muss es serverseitig gerendert werden, wo die Schriften feststehen. Eine zweisprachige Website fügt eine Einschränkung hinzu: Das Layout muss in beiden Sprachen tragen.
Auch Referenznummern brauchen Sorgfalt. Ein Doppelklick oder ein erneuter Versuch nach einem Timeout darf für dieselbe Konfiguration keine zweite Referenznummer erzeugen, deshalb liefert eine wiederholte Anfrage das bestehende Angebot zurück. Ein gespeichertes Angebot enthält:
die vollständige gewählte Konfiguration
die Version der Preisregeln, unter der bepreist wurde
Währung und Mehrwertsteuersatz als gespeicherte Werte
die Referenznummer mit Zeitstempel und das erzeugte Dokument
Wir speichern Konfiguration und PDF zusammen. Wenn ein Kunde ein Angebot ein Jahr später infrage stellt, zeigt die Konfiguration, wie der Preis entstanden ist, und das PDF, was verschickt wurde.
Nutzen und Kosten
Sobald er läuft, müssen Mitarbeiter nicht mehr jede Anfrage von Hand bepreisen, und Angebote gehen ohne Preisrunde dazwischen raus. Der Hersteller kann Preise ändern und Optionen eines Typs hinzufügen, den die Engine schon kennt; neue Regeltypen bauen wir ein.
Der Preis dafür: Das ist eine Anwendung. Sie braucht ein relationales Modell der Optionen und der Regeln zwischen ihnen sowie Berechnungen auf einem Server. Gehostete Website-Werkzeuge erzeugen Seiten und haben für dieses Modell keinen Platz, deshalb läuft es auf unserem eigenen Stack: Next.js, Spring Boot, PostgreSQL, Flyway-Migrationen und Docker-Images. Das ist mehr Wartung als bei einer gehosteten Website.
Das heißt auch: Der Umfang wird vor Arbeitsbeginn schriftlich festgelegt. Die Abnahmekriterien sind die Zahl der Optionen, die Regeltypen der Engine, der Inhalt des PDFs und was danach bearbeitbar bleibt. Wir arbeiten mit schriftlichem Umfang zum Festpreis und den vereinbarten Korrekturrunden, und das funktioniert nur, wenn diese Grenze zuerst gezogen wird.
Wer das erst nachrüstet, wenn die ersten Angebote verschickt sind, muss Preislogik und gespeicherte PDFs noch einmal anfassen.
Wie wir solche Projekte abgrenzen und bepreisen, steht unter Leistungen.
