Transparion – Prüfbeleg zum Ereignismodell für Widget, Kalender und CRM
Prüfstand: 2. Oktober 2026

Art des Belegs: vollständig synthetisches lokales Funktionsbeispiel. Keine Kundendaten, kein verbundenes Kalenderkonto und kein produktiver CRM-Abgleich. Der gespeicherte Anfangsbestand enthält genau eine künstliche Scan-Anfrage A. Ihre Anlage über das eigentliche Scan-Formular ist nicht Gegenstand dieser Prüfung.

Geprüfte Zähleinheiten
- Anfrage: eine gespeicherte Widget-Scan-Anfrage, im Export über lead.id identifiziert.
- Buchung: separat identifizierter Termin mit Status und möglicher Vorgängerbuchung.
- Ereignis/Übergabe: einzelne Meldung oder ausdrücklich ausgelöster Export.
- Person: mit diesem Versuch nicht bestimmt. Mehrere Anfragen können zu derselben Person gehören.

Geprüfter Ablauf (jeweils Zustand nach der Aktion)
01. Eine synthetische Scan-Anfrage A ist gespeichert.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 0; aktive zugeordnete Kalenderbuchungen: 0; unzugeordnete Buchungen: 0.
02. Terminlink im Bericht geklickt; noch keine Bestätigung.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 0; aktive zugeordnete Kalenderbuchungen: 0; unzugeordnete Buchungen: 0.
03. Buchung B bestätigt.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 1; aktive zugeordnete Kalenderbuchungen: 1; unzugeordnete Buchungen: 0.
04. Identische Buchungsmeldung B erneut zugestellt.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 1; aktive zugeordnete Kalenderbuchungen: 1; unzugeordnete Buchungen: 0.
05. Umbuchung C ersetzt B; Zuordnung über die Vorgänger-UID.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 1; aktive zugeordnete Kalenderbuchungen: 1; unzugeordnete Buchungen: 0.
06. Verspätete Absage von B lässt C bestätigt.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 1; aktive zugeordnete Kalenderbuchungen: 1; unzugeordnete Buchungen: 0.
07. C abgesagt; Anfrage bleibt erhalten, keine aktive zugeordnete Buchung.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 0; aktive zugeordnete Kalenderbuchungen: 0; unzugeordnete Buchungen: 0.
08. Separater Prüfschritt: manuelle Bestätigung hält den gemeinsamen Buchungsstand aktiv.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 1; aktive zugeordnete Kalenderbuchungen: 0; unzugeordnete Buchungen: 0.
09. Manuelle Bestätigung zurückgenommen.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 0; aktive zugeordnete Kalenderbuchungen: 0; unzugeordnete Buchungen: 0.
10. Bestätigung D ohne Scan-Verweis oder bekannte Vorgängerbuchung bleibt unzugeordnet.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 0; aktive zugeordnete Kalenderbuchungen: 0; unzugeordnete Buchungen: 1.
11. Zwei manuelle CRM-Übergaben derselben Anfrage.
    Anfragen: 1; Anfragen mit aktueller Bestätigung: 0; aktive zugeordnete Kalenderbuchungen: 0; unzugeordnete Buchungen: 1.

CRM-Beispiel
Zwei ausdrücklich ausgelöste Exporte erzeugten zwei verschiedene eventIds für dieselbe lead.id. Der Versand wurde durch einen lokalen Testempfänger ersetzt; es gab keine HTTP-Übertragung an ein CRM.
Zusätzlich wurde dieselbe erste Exportmeldung im simulierten Empfänger zweimal verarbeitet: drei simulierte Zustellversuche, zwei verschiedene Exportereignisse, ein Anfrage-Datensatz. Die Beispielregel prüft eventId und aktualisiert anhand lead.id, jeweils im Kontext derselben vertrauenswürdig bestimmten Agentur. Diese Empfangslogik ist eine Demonstration und kein Nachweis einer bereits eingerichteten CRM-Funktion.

Technischer Prüfumfang
Die Prüfung verwendet den aktuellen Transparion-Kalenderparser, die tatsächliche Cal.com-Datenbankmigration in einer isolierten PostgreSQL-Instanz (PGlite), den vorhandenen Bericht-Terminlink und die vorhandene Exportfunktion mit kontrolliertem Datenzugriff. Elf gespeicherte Zwischenstände wurden gegen vorher festgelegte Sollwerte geprüft.
Zusätzlich bestanden alle 47 vom Node-Testläufer ausgewiesenen Fälle aus vier bestehenden Testdateien (einschließlich zweier übergeordneter Fälle; 45 einzelne Unter-/Einzelfälle). Sie prüfen unter anderem Signaturen, Agenturgrenzen, verspätete und doppelte Meldungen, Umbuchungen, mehrere Buchungen, manuelle Bestätigung, Datenschutzgrenzen, Exportverhalten und aktuelle Terminziele historischer Berichte.

Grenzen
- Lokale Tests ersetzen keinen Ende-zu-Ende-Test Ihrer eingerichteten Anbieter und Berechtigungen.
- Eine unzugeordnete Buchung ist eine offene Zuordnung, kein Beweis gegen eine Buchung.
- Ein Terminlink-Klick belegt keine bestätigte Buchung; bestätigt bedeutet nicht automatisch als gewonnen markiert.
- Aktuelle Bestätigung und historisch jemals bestätigte Buchung sind verschiedene Berichtsfragen. Der Versuch belegt keine vollständige Historientabelle aller Zustellversuche.
- Eine erfolgreiche HTTP-Annahme belegt allein keine Anlage eines Kontakts, Deals oder Auftrags im Zielsystem. Bei unklarem Eingang muss vor einer erneuten Übergabe der Empfänger geprüft werden.
- Anfragekennung, Ereigniskennung und Person dürfen bei der Auswertung nicht gleichgesetzt werden. Automatische Wiederholungen oder fortlaufende CRM-Synchronisation werden hier nicht behauptet.

Untersuchte lokale Referenzen
apps/backend/src/services/widgetCalendarService.ts
apps/backend/src/services/widgetLeadService.ts
supabase/migrations/202609090001_widget_calcom_bookings.sql
apps/backend/test/widget-calendar.test.ts
apps/backend/test/widget-calendar-sql.test.ts
apps/backend/test/widget-leads.test.ts
apps/backend/test/widget-report-booking.test.ts
docs/widget-calcom-bookings-2026-09-09.md
docs/agency-widget-growth-2026-09-08.md