Die Berechnung ist als TypeScript hinterlegt. Dazu kommen Produktvariablen mit Gültigkeitszeiträumen, Datenquellen für Tariftabellen sowie Snippets und globale Helferfunktionen für wiederkehrenden Code. Auf diese Weise lässt sich jede Kompositsparte als Produkt abbilden.

In den Datenquellen. Dort werden die Spalten angelegt und die Werte als CSV importiert, die Berechnung greift darauf zu. Mehrere Produkte können dieselbe Datenquelle nutzen. Neue Werte erfordern daher keine Codeänderung.

Nein. Eine Tarifänderung wird in Studio gespeichert und gilt ohne Entwicklungsprojekt und ohne Release. Über Gültigkeitszeiträume lässt sich festlegen, ab wann neue Werte rechnen. Der Versionsverlauf dokumentiert jede Änderung.

Mit Testfällen. Ein Testfall enthält Kundendaten, Eingaben und Zahlungsmethode. Damit lässt sich die Strecke als Vorschau durchgehen, Dokumente erzeugen und die Berechnung prüfen. Trigger lassen sich mit Testdaten ausführen, inklusive Logs. Die Fehlerübersicht zeigt alle offenen Validierungsfehler und Warnungen des Produkts.

Versicherungsschein, Angebot, Antrag und Nachtrag als dynamische Dokumente, die je Produkt benannt und gestaltet werden. Ein neues Dokument startet leer oder aus einer Vorlage. Nummernkreise vergeben Versicherungsschein-, Angebots-, Anfrage- und Schadennummern nach eigenen Regeln.

Ja, mit Triggern je Produkt für Verträge, Angebote, Nachträge, Entwürfe und Anfragen. Für jeden Trigger werden Zeitpunkt, Priorität und Fehlerverhalten festgelegt. Remote Functions führen zusätzlich eigene Logik aus, etwa als Datenquelle für Autocomplete-Felder in der Strecke.

Strecken, Fragebögen, Dokumente, Nummernkreise und Datenquellen lassen sich ohne Programmierung konfigurieren. Für Berechnung und Trigger sind TypeScript-Grundkenntnisse nötig. Entwicklerteams können Produkte mit der Studio CLI lokal bearbeiten. Alternativ übernehmen wir die Produktmodellierung als Dienstleistung oder binden das Produkt per Schnittstelle (z.B. BiPRO) an den Rechenkern des Versicherers an.