Angebots-Engine: Kalkulation als Konfiguration

Ausgangslage

Angebotskalkulation steckt in vielen Betrieben in einer gewachsenen Excel-Datei. Die Formeln liegen in den Zellen, die Preise auf einem zweiten Blatt, und die Sonderfälle stehen als Notiz daneben. Das funktioniert, solange die Person greifbar ist, die die Datei gebaut hat.

Jede Änderung an der Logik ist ein Eingriff in die Datei selbst, und wer sie nicht gebaut hat, fasst sie nicht an. Kommen mehrere Fachbereiche mit unterschiedlichen Regeln dazu, wird daraus ein Wartungsproblem, das mit jeder Kopie größer wird.

Die Frage hinter diesem Projekt war deshalb: Lässt sich Kalkulation so bauen, dass sie konfiguriert wird statt programmiert?

Wie die Engine arbeitet

1. Fachbereich anlegen. Photovoltaik, Fenster, Dach: jeder Bereich ist eine eigenständige Konfiguration mit eigenen Feldern, Regeln und Preislisten. Die Bereiche stören sich gegenseitig nicht.

2. Felder definieren. Zahlen, Text, Auswahllisten und Wahrheitswerte, dazu Formelfelder, die aus anderen Feldern rechnen, und Ausgabefelder für das Ergebnis.

3. Regeln und Prüfungen hinterlegen. Bedingungsbasierte Regeln mit UND- und ODER-Verknüpfung weisen Werte zu. Validierungen melden Fehler und Warnungen, auch im Vergleich zweier Felder.

4. Preise anbinden. Rechenergebnisse werden mit Artikeln aus einer Preisliste verknüpft, sodass Kosten automatisch entstehen. Preislisten lassen sich per CSV einlesen.

5. Testen, dann verkaufen. Der Simulator rechnet jede Konfiguration live durch, ohne ein echtes Angebot anzulegen. Erst wenn die Logik stimmt, arbeitet der Vertrieb im Konfigurator damit.

Was die Anwendung mitbringt

Regel- und Formel-Engine. Bedingungen, Formeln und Validierungen sind Daten und nicht Code. Eine neue Kalkulationslogik braucht kein Deployment.

Versionierte REST-API. Die gesamte Funktionalität ist auch headless erreichbar, mit CRUD und Ausführung der Engine, damit Fremdsysteme sie nutzen können.

API-Keys mit Protokollierung. Zugriff über Bearer-Token, ausgestellt im Adminbereich. Jeder Aufruf wird protokolliert.

Rollenmodell. Drei Rollen mit klar getrennten Rechten: Super Admin, Bereichsadministrator und Vertrieb. Der Vertrieb sieht ausschließlich den Konfigurator.

Simulator. Fehler in der Logik fallen vor dem ersten echten Angebot auf und nicht danach.

Nachvollziehbare Ausführung. Läufe der Engine und API-Zugriffe werden protokolliert. Bei einem unerwarteten Ergebnis lässt sich rekonstruieren, welche Regel gegriffen hat.

Warum das über dieses Projekt hinaus zählt

Der eigentliche Ertrag ist die Erfahrung damit, fachliche Logik konfigurierbar zu machen, statt sie fest zu verdrahten. Diese Frage stellt sich in fast jeder Fachanwendung: Was gehört in den Code, und was muss sich später ändern lassen, ohne dass jemand einen Entwickler ruft?

Die Antwort darauf ist selten eindeutig, aber sie sollte bewusst getroffen werden und nicht dadurch entstehen, dass es beim Bauen gerade schneller ging.