STARQstrom Middleware — Masterplan

Version: 1.5 | Datum: 25.02.2026 | Status: CEO-Meeting-Ergebnisse eingearbeitet Änderungen v1.5: CEO-Meeting (25.02.2026): Middleware-Neuaufsetzung bestätigt, ene't-Anbindung von Phase 3 auf sofort vorgezogen, Roadmap-Ownership bei ProcesslyAI, Handelsvertreter-App als neues Ziel, SOLVIT-Preiskalkulator perspektivisch ablösen, Solve-Weekly ab KW 10 Änderungen v1.4: Server-Analyse (25.02.2026): Wattform API existiert bereits (7 Endpoints produktiv), eigene Auftragsstrecke in Livewire vorhanden, SOLVIT-Sektion komplett aktualisiert, Blocker-Liste korrigiert Änderungen v1.3: Website bleibt Statamic (wird NICHT in Rails neu gebaut), Preisberechnung Phase 1 = SOLVIT-Durchleitung (nicht eigene Engine), Pricing Engine + EEX zu Phase 3, Hosting Hetzner, SOLVIT-Produktivgang Q2 Änderungen v1.2: Architekturentscheidung: Neubau in Rails (statt PHP/Laravel), Company-Dedup via E-Mail-Domain, Middleware bekommt Frontend Änderungen v1.1: Lastprofil-Analyse hinzugefügt (Abschnitt 7a), B2B-Datenfluss korrigiert, MatchPoint-Input konkretisiert, HubSpot API-Zugriff verifiziert

1. Zusammenfassung

Heute (verifiziert, Server-Analyse 25.02.2026)

Drei Systeme auf einem Server: Website (Statamic CMS 5.0 + Livewire, eigene 7-Schritte-Auftragsstrecke), Middleware (Pure Laravel 12, HubSpot-Sync only, API-only ohne Frontend), Wattform API (SOLVIT, extern unter wechselprozess.services). Die Website ruft Tarife + Bestellungen direkt bei der Wattform API ab UND sendet Daten parallel an die Middleware → HubSpot. Die Middleware sieht keine Preisdetails, hat kein Dashboard, bietet keine Transparenz.

Morgen (CEO-Meeting 25.02.2026 — bestätigt und erweitert)

Neubau als STARQ Platform (Ruby on Rails 8.1) — Partner Portal, Middleware-Dashboard und Backend-Services in einer App. Die Website (Statamic) bleibt bestehen und kommuniziert über API. Die Plattform wird zur zentralen Datendrehscheibe mit Transparenz über alle Preise und Daten. In Phase 1 nutzt die STARQ Platform die bestehende Wattform API (Tarife + Bestellungen), aber leitet alles über die Middleware — volle Transparenz. Neue SOLVIT-Endpoints (Webhooks, Netzentgelte) werden gemeinsam gebaut. Excel-Export und die alte PHP-Middleware fallen weg.

CEO-Bestätigung (25.02.2026): "Bestehende Middleware macht keinen Sinn weiterzuentwickeln." Neuaufsetzung bestätigt. Priorisierung: Erst Vertrieb/Pricing, dann Belieferung/Beschaffung, dann Erzeugung/Verbrauch. ene't-Daten (Netzentgelte/Umlagen) direkt kaufen, nicht auf SOLVIT warten. Roadmap-Ownership bei ProcesslyAI.

Was sich konkret ändert

HEUTE (IST — verifiziert 25.02.2026)          MORGEN (SOLL)
═══════════════════════════════                ═══════════════════════════════

B2C:                                           B2C:
  Website (Livewire, 7 Steps)                    Website ──→ STARQ Platform ──→ Wattform API
  ├──→ Wattform API (Tarife + Bestellung)                     ├──→ HubSpot (Preise sichtbar)
  └──→ Middleware (DM) ──→ HubSpot                            ├──→ Dashboard (einsehen/editieren)
  (2 parallele Wege, keine Preistransparenz)                  └──→ Status-Webhooks (NEU)

B2B:                                           B2B:
  Website ──→ Middleware (DM) ──→ HubSpot        Website ──→ STARQ Platform ──→ HubSpot
  HubSpot ──→ Excel-Export ──→ SOLVIT ERP                     ├──→ MatchPoint (automatisch)
  MatchPoint ──→ manuell ablesen                               ├──→ Wattform API (erweitert)
  (3 Medienbrüche!)                                            └──→ Dashboard (alle KPIs)
                                                               (0 Medienbrüche)

Kernvorteile

Eine Plattform: Portal + Dashboard + Middleware = eine Rails-App (Website bleibt Statamic, sendet per API)
Eigenes Frontend: Kein "Blackbox"-Backend mehr — Dashboard mit voller Transparenz über alle Daten, KPIs und Preise
Preistransparenz: Phase 1: SOLVIT berechnet weiter, aber alle Preise sind in der Middleware sichtbar + editierbar. Zukunft: Eigene Preisberechnung.
Kein Medienbruch: Kein manueller Excel-Export mehr (B2B)
Kein Blindflug: Website kommuniziert über Middleware mit SOLVIT — nicht mehr direkt
Vollständige Daten: Alle Informationen zentral in der Plattform
Automatisierung: MatchPoint-Analyse läuft vollautomatisch — kein manuelles Hochladen/Ablesen mehr

2. IST-Zustand

2.1 Middleware (Digital Masters GmbH) — wird abgelöst

Eigenschaft	Aktuell (DM)	Neu (STARQ Platform)
Tech-Stack	PHP 8.4, Laravel 12, SQLite, Redis	Ruby 4.0, Rails 8.1, PostgreSQL, Redis
Queue	Laravel Horizon (4 Queues, bis 10 Worker)	Sidekiq + Redis
Frontend	Keins (API-only)	Website + Portal + Dashboard
Server	62.108.57.65 (dediziert)	Hetzner Server
CI/CD	GitLab CI	GitHub Actions / Kamal
Monitoring	Self-hosted Sentry	TBD
Status	Produktiv	In Planung

MIGRATION: Die bestehende PHP/Laravel-Middleware von Digital Masters wird durch einen Rails-Neubau ersetzt. Die Datenflüsse und das HubSpot-Mapping bleiben inhaltlich identisch — nur der Tech-Stack ändert sich. Die DM-Dokumentation dient als Referenz-Spezifikation für den Neubau. Die Website (Statamic) bleibt bestehen und sendet Daten per API an die STARQ Platform. Partner Portal, Middleware-Dashboard und Backend-Services werden in einer Rails-App vereint.

Die aktuelle Middleware ist API-only (kein Frontend) und fungiert als Integrationsschicht zwischen der Website (Statamic, bleibt bestehen) und HubSpot CRM.

Flow A: SLP-Bestellung (B2C) — Asynchron

Website (Statamic, bleibt)                    Middleware                         HubSpot CRM
      │                                │                                   │
      │  POST /api/hubspot/orders/     │                                   │
      │  submit (JSON, Token-Auth)     │                                   │
      ├───────────────────────────────▶│                                   │
      │                                │  Validate Request                 │
      │                                │  Dispatch ProcessOrderJob         │
      │  HTTP 202 Accepted             │  (Queue: orders, tries=3)         │
      │◀───────────────────────────────│                                   │
      │                                │                                   │
      │                          [Queue-Worker verarbeitet asynchron]      │
      │                                │                                   │
      │                                │  marketing_consent = true?        │
      │                                │  → Forms API (DSGVO/DOI)          │
      │                                │  → + Contacts API (Restfelder)    │
      │                                │                                   │
      │                                │  marketing_consent = false?       │
      │                                │  → Contacts API direkt            │
      │                                │──────────────────────────────────▶│ Contact
      │                                │                                   │
      │                                │  [nur bei Gewerbe/B2B]           │
      │                                │──────────────────────────────────▶│ Company
      │                                │                                   │
      │                                │──────────────────────────────────▶│ Deal
      │                                │                                   │ (B2C Pipeline)
      │                                │──────────────────────────────────▶│ Associations
      │                                │                                   │ Contact↔Company
      │                                │                                   │ Deal↔Contact
      │                                │                                   │ Deal↔Company

Daten die gesendet werden (SLP):

Kategorie	Eingangsdaten	HubSpot Property
Person	firstName, lastName, email, phone, salutation	`firstname`, `lastname`, `email`, `phone`, `salutation`
Adresse	street, houseNumber, postalCode, city	`lieferadresse_strae`, `lieferadresse_hausnr`, `lieferadresse_plz`, `lieferadresse_stadt`
Tarif	tarifName, jahresverbrauch, arbeitspreis, grundpreis	`tarif`, `jahresverbrauch__kwh_`, `netto_arbeitspreis`, `grundpreis`
Zähler	meterNumber, zaehlertyp (KME→Analog, MME→Digital, IMS→Smart)	`zahlernummer`, `zahlertyp`, `zahlerart`=slp
Vertrag	orderType (Wechsel/Einzug), desiredDeliveryDate	`auftragsgrund`, `delivery_start`
Zahlung	paymentMethod, accountHolder, iban	`zahlungsart`, `kontoinhaber`, `iban`
Rechnungsadresse	billingStreet, billingPostalCode, billingCity	`rechnungsadresse__stra_e_`, `rechnungsadresse__plz_`, `rechnungsadresse__stadt_`
Meta	discountCode, marketing_consent, customerChannel	`discount_approval`, `kontaktquelle`=Website, `kundentyp`

Flow B: RLM-Lead (B2B) — Synchron

Website (Statamic, bleibt)                    Middleware                         HubSpot CRM
      │                                │                                   │
      │  POST /api/hubspot/rlm-leads/  │                                   │
      │  submit (multipart/form-data)  │                                   │
      ├───────────────────────────────▶│                                   │
      │                                │  Verarbeitung SYNCHRON            │
      │                                │  (kein Queue!)                    │
      │                                │                                   │
      │                                │──────────────────────────────────▶│ Company
      │                                │                                   │ (Dedup: Name)
      │                                │──────────────────────────────────▶│ Contact
      │                                │                                   │
      │                                │──────────────────────────────────▶│ Deal
      │                                │                                   │ (B2B Pipeline)
      │                                │                                   │
      │                                │  [Falls Dateien/Zusatzinfo]       │
      │                                │──────────────────────────────────▶│ File Upload
      │                                │──────────────────────────────────▶│ Note am Deal
      │                                │                                   │
      │  HTTP 200                      │                                   │
      │  {companyId, contactId, dealId}│                                   │
      │◀───────────────────────────────│                                   │

Daten die gesendet werden (RLM):

Kategorie	Eingangsdaten	HubSpot Property
Firma	company.name	`name` (Company)
Person	salutation, firstName, lastName, email, phone	Contact-Properties
Deal	annualConsumption (bereinigt auf Integer)	`jahresverbrauch__kwh_`, `kundentyp`=rlm
Dateien	Lastprofil (PDF/CSV/XLSX, max 10 MB)	Note + File am Deal
Freitext	additionalInfo	Note am Deal

State Machine (für alle Objekte)

  ┌─────────┐     markAsSyncing()     ┌─────────┐
  │ pending │ ───────────────────────▶ │ syncing │
  └─────────┘                          └────┬────┘
                                            │
                              ┌─────────────┼─────────────┐
                              │ Erfolg      │             │ Fehler
                              ▼             │             ▼
                        ┌──────────┐        │       ┌──────────┐
                        │  synced  │        │       │  failed  │
                        └────┬─────┘        │       └────┬─────┘
                             │              │            │
                             │  needsSync() │            │ markAsSyncing()
                             │  (Retry)     │            │ (Retry)
                             └──────────────┘            └──▶ syncing

Bekanntes Problem + Lösungsansatz

Company-Deduplizierung: Aktuell Upsert nur über Firmennamen. Tippvarianten ("Müller GmbH" vs "Mueller GmbH" vs "Müller Gmbh") erzeugen Duplikate.

Geplante Lösung (3-stufig):

Primär: E-Mail-Domain des Ansprechpartners (z.B. @mueller-gmbh.de) → HubSpot Company Property domain. Eindeutig und tippfehler-resistent.
Fallback: Firmenname mit Normalisierung (GmbH/Gmbh/gmbh → einheitlich) + Fuzzy-Matching
Optional: USt-ID falls vorhanden → zusätzliche Validierung

2.2 HubSpot CRM

Kennzahl	Wert
Account	146570641 (EU1)
Contacts	167
Deals	166
Companies	124
Custom Properties	212 (22 Contact, 182 Deal, 8 Company)
Pipelines	2 (B2C + B2B)
Aktive Workflows	5
Tarife	9

B2C Pipeline (14 Stages):

Neuer Lead → Lead kontaktiert → Lead wiedervorliegend → Lead terminiert
→ Lead beraten → Lead qualifiziert → Angebot angefragt → Angebot erstellt
→ Angebot versendet → Auftrag bestätigt → Auftrag verloren (closed)
                                         → Auftrag gewonnen (closed)
                                         → Auftrag gewonnen (SOLVIT) → Versorgung bestätigt

B2B Pipeline (15 Stages):

Neuer Lead → Lead wiedervorliegend → Lead kontaktiert → Lead terminiert
→ Lead beraten → Lead qualifiziert → Angebot angefragt → Angebot erstellt
→ Angebot versendet → Auftrag bestätigt → Auftrag gewonnen
→ SOLVIT → Klärfall → Versorgung bestätigt (closed)
                     → Lead verloren (closed)

Aktive Workflows:

Workflow	Trigger	Aktion
Lifecycle-Update	Deal wird Kontakt zugeordnet	lifecyclestage = "Opportunity"
Kommunikationssperre	kommunikationssperre = "Ja"	Non-Marketing-Status
E-Sign Status	hs_esign_date gesetzt	e_sign_status = "unterzeichnet"
Angebot versendet	PDF-Link generiert	Stage → "Angebot versendet" + Follow-up Task (7 Tage)
Angebot erstellt	Quote-Status = "DRAFT"	Stage → "Angebot erstellt"

Portant-Integration: Dokumentenerstellung + E-Signaturen direkt in HubSpot.

2.3 SOLVIT GmbH (aktueller Zustand — Server-Analyse 25.02.2026)

Rolle: Full-Service BPO-Partner (Prozessdienstleister für Energieversorger)
Unternehmen: SOLVIT GmbH, Flensburg (~8-11 MA, GF: Benjamin Klink)
Plattform: "wattform" — eigenentwickeltes, modulares Web-System
Tagline: "Die intelligente Lösung für grüne Energieversorger"

SOLVIT-Dienstleistungen für STARQstrom:

Bereich	Beschreibung	wattform-Modul
Marktkommunikation	EDIFACT-Messaging, Lieferantenwechsel (GPKE/GeLi Gas), Ein-/Auszug, Kündigungen, Marktpartner-Verwaltung	.edi
Abrechnung	Energierechnungen, Abschlagsberechnung, Netznutzungsrechnungsprüfung, debitorisches + kreditorisches Nebenbuch, Monatsabschluss	.bil
Zählerstandsmanagement	Zähler-/Gerätemanagement, Lastprofile verarbeiten, Plausibilisierung, Messwerte für Abrechnung	.epm
Kundenservice	Level 1 + Level 2 Support für STARQstrom-Endkunden, Auftragsannahme, Kundenkommunikation	.cpm
Tarifierung	Individuelle Tarifgestaltung (Strom + Gas), HT/NT, modulares Baukastensystem	.tar

Service-Paket: Vermutlich Comfort+ oder Premium (SOLVIT übernimmt Großteil der operativen Prozesse).

CEO-Meeting (25.02.2026): Funktionsverlagerung von SOLVIT zu eigenen Systemen ist strategisches Ziel. SOLVIT bleibt wichtig für GPKE, Abrechnung, Kundenservice — aber Preisdatenhoheit, Preiskalkulation und perspektivisch weitere Funktionen werden in die eigene Middleware verlagert. Partnerschaft aktiv managen trotz abnehmender Abhängigkeit. Der SOLVIT-Preiskalkulator (Website-Snippet für SLP) wird perspektivisch abgelöst, kann temporär weiter genutzt werden.

Wattform API — EXISTIERT bereits!

Server-Analyse 25.02.2026: SOLVIT hat bereits eine REST-API ("Wattform API") unter wechselprozess.services/solvreg/resources. Diese wird aktiv von der bestehenden Website (Statamic/Livewire) genutzt.

Bestehende Endpoints (verifiziert aus Code):

Endpoint	Methode	Zweck	Status
`/tarife/{plz}/{city}`	GET	Tarife abrufen (PLZ, Stadt, Verbrauch, Zählertyp)	Produktiv
`/auftraege`	POST	Bestellung abschicken → `auftragsnummer`	Produktiv
Postleitzahlen	GET	PLZ-Validierung + Stadtliste	Produktiv
Straßen	GET	Straßenliste für PLZ/Stadt	Produktiv
Rabattcode validieren	POST	Gutscheincode prüfen	Produktiv
IBAN validieren	POST	IBAN + Kontoinhaber prüfen	Produktiv
Versorger suchen	POST	Vorversorger-Suche	Produktiv

Auth: Header Mandant: starqstrom + Origin: https://starqstrom.de + Referer: https://starqstrom.de/

Aktueller Datenfluss (Update nach Server-Analyse)

Bereich	Aktueller Prozess	Problem
B2C	~~SOLVIT-Widget~~ Eigene Livewire-Auftragsstrecke → Wattform API (Tarife + Bestellung) + Middleware → HubSpot	Preisdetails/Netzentgelte nicht transparent. Kein Status-Feedback nach Vertragsanlage.
B2B	Vertrieb pflegt Deal in HubSpot → Manueller Excel-Export → Import in SOLVIT ERP	Medienbruch. Fehleranfällig. Zeitverzögerung. Keine Rückmeldung.
Kundenservice	Endkunden kontaktieren SOLVIT direkt bei Fragen/Problemen	STARQstrom hat keinen Überblick über Kundenanfragen und Ticketstatus
Marktkommunikation	SOLVIT verwaltet EDIFACT-Messaging komplett	STARQstrom hat keine Einsicht in laufende Marktprozesse
API	~~Keine API vorhanden~~ Wattform API existiert (7 Endpoints)	Fehlend: Status-Webhooks, Netzentgelt-Export, B2B-Verträge, Klärfall-Management

2.4 MatchPoint (aktueller Zustand)

Rolle: RLM-Preiskalkulations-Tool für Großkunden (B2B). URL: https://starqstrom-rlm-pricingtool.lovable.app/tool Status: Standalone Lovable-App, keine API.

Schritt	Aktueller Prozess
1	Vertriebler öffnet MatchPoint manuell
2	Lädt Lastprofil des Kunden hoch (Excel/CSV/PDF)
3	MatchPoint berechnet PV/Wind-Matching + Preiskalkulation
4	Vertriebler liest Ergebnis ab und trägt Werte manuell in HubSpot Deal ein

Kein automatischer Datenfluss zwischen MatchPoint und HubSpot/Middleware.

3. SOLL-Zustand — Zielarchitektur

STARQ Platform (Rails-Monolith)

Architekturentscheidung: Die PHP/Laravel-Middleware wird durch eine Rails-App ersetzt — Partner Portal, Middleware-Dashboard und die gesamte Backend-Logik. Die Website (Statamic) bleibt bestehen und sendet Daten per API.

┌─────────────────────────────────────┐
│  starqstrom.de (Statamic)           │  ← BLEIBT UNVERÄNDERT
│  Livewire, Alpine.js, Tailwind      │
│  /bestellung/ (SLP, 6-Step)         │
│  /gewerbekunden-rlm (RLM + Upload)  │
└──────────┬──────────────────────────┘
           │ API (POST JSON / multipart)
           ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                     STARQ PLATFORM (Ruby on Rails 8.1)                       │
│                     Hetzner Server                                           │
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐ │
│  │  FRONTENDS (integriert — Tailwind CSS, Stimulus, ERB, Turbo)           │ │
│  │                                                                         │ │
│  │  • STARQ Partner Portal (NEU)     → Dashboard, Kunden, Provisionen     │ │
│  │  • Middleware-Dashboard (NEU)      → Sync-Status, KPIs, Preisdaten     │ │
│  │                                      einsehen + editieren, Logs        │ │
│  │  • Kunden-Portal (Zukunft)                                             │ │
│  └─────────────────────────────────────────────────────────────────────────┘ │
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────────┐ │
│  │  BACKEND / SERVICES (Service Objects)                                   │ │
│  │                                                                         │ │
│  │  VON DM-CODE PORTIERT:                        NEU:                     │ │
│  │  • HubSpot::OrderSync (SLP→HubSpot)           • SolvitProxy (Phase 1) │ │
│  │  • HubSpot::RlmLeadSync (RLM→HubSpot)         • MatchPointConnector   │ │
│  │  • HubSpot::CompanyDedup (E-Mail-Domain!)      • WebsiteApi (SLP/RLM) │ │
│  │  • HubSpot::ReverseSync (HubSpot→App)                                  │ │
│  │                                                                         │ │
│  │  ZUKUNFT (Phase 3):                                                    │ │
│  │  • PricingEngine (eigene Preisberechnung)                              │ │
│  │  • EexMarketDataService (Börsenpreise)                                 │ │
│  │                                                                         │ │
│  │  Sidekiq (async Jobs) │ Action Cable (Realtime) │ Active Job            │ │
│  └─────────────────────────────────────────────────────────────────────────┘ │
│                                                                              │
│  Ruby 4.0 │ Rails 8.1 │ PostgreSQL │ Redis │ Sidekiq │ Kamal (Deploy)       │
│                                                                              │
└───┬──────────────────┬──────────────────┬──────────────────┬─────────────────┘
    │                  │                  │                  │
    ▼                  ▼                  ▼                  ▼
┌────────────┐   ┌──────────┐   ┌──────────────┐   ┌─────────────────┐
│ HubSpot    │   │ SOLVIT   │   │  MatchPoint  │   │  EEX/EPEX       │
│ CRM        │   │ (Preise  │   │  (Analyse)   │   │  (Börsenpreise) │
│ (bidirekt.)│   │ +Abrech.)│   │              │   │  (Phase 3)      │
└────────────┘   └──────────┘   └──────────────┘   └─────────────────┘
                                                    ┌─────────────────┐
                                                    │ PARQ/Odoo │     │
                                                    │ in.Power  │     │
                                                    │ (Zukunft) │     │
                                                    └─────────────────┘

Komponenten — Übersicht

Komponente	Richtung	Was sie tut	Priorität	Abhängigkeit
Rails-App Skeleton	—	Grundgerüst: Auth, PostgreSQL, Sidekiq, Kamal-Setup (Hetzner)	Phase 1	—
API-Endpunkte für Website	Website → App	Empfängt SLP + RLM Daten von Statamic-Website per API	Phase 1	Rails-Skeleton
HubSpot-Sync (portiert)	App ↔ HubSpot	DM-Flows portieren: SLP + RLM → HubSpot, Company-Dedup via E-Mail-Domain	Phase 1	DM-Doku als Referenz
SOLVIT-Connector	App ↔ SOLVIT	Phase 1: Wattform API (7 bestehende Endpoints) über Middleware leiten. Preisdaten einsehen + editieren im Dashboard. Erweiterungen (Webhooks, Netzentgelte) mit SOLVIT abstimmen.	Phase 1	Basis-Endpoints existieren. Erweiterungen mit SOLVIT besprechen.
Middleware-Dashboard	App-intern	Sync-Status, KPIs, Preisdaten einsehen/editieren, Logs, Klärfälle	Phase 1	Rails-Skeleton
HubSpot Reverse Sync	HubSpot → App	Deal-Stage-Änderungen empfangen, Daten zurücklesen	Phase 1	Webhook-Setup in HubSpot
MatchPoint-Connector	App ↔ MatchPoint	Lastprofil automatisch senden, PV/Wind/Spot-Faktoren empfangen	Phase 2	MatchPoint-API oder Logik-Extraktion
Partner Portal	App-intern	Dashboard, Kunden, Provisionen, Messdaten	Phase 2	Phase 1
Pricing Engine	Intern	Eigene B2C + B2B Preisberechnung (löst SOLVIT-Preisberechnung ab)	Phase 3	MatchPoint + EEX
EEX/EPEX-Service	EEX → App	Täglicher Import von Spot-Marktpreisen	Phase 3	API-Zugang

4. B2C — Vollständiger Datenfluss (Zukunft)

Übersicht

              HEUTE                                    MORGEN
    ┌─────────────────────────┐             ┌─────────────────────────┐
    │ Website                 │             │ Website                 │
    │  ├→ SOLVIT-Snippet ─→ ERP            │  └→ Middleware           │
    │  └→ Middleware ─→ HubSpot│             │      ├→ HubSpot        │
    │     (getrennte Wege)    │             │      ├→ Pricing Engine  │
    └─────────────────────────┘             │      └→ SOLVIT API     │
                                            │         (ein Weg)       │
                                            └─────────────────────────┘

Detaillierter Flow

#	System	Aktion	Daten / HubSpot Properties	Status
1	Website	Kunde füllt SLP-Formular aus (Tarif, Verbrauch, Region, Adresse, Zähler)	Formulardaten	EXISTIERT
2	Middleware	`POST /api/hubspot/orders/submit` — Validierung + Queue (ProcessOrderJob, async)	—	EXISTIERT
3	Middleware → HubSpot	Contact erstellen (Forms API bei Marketing-Consent, sonst Contacts API)	`firstname`, `lastname`, `email`, `phone`, `salutation`, `kontaktquelle`=Website	EXISTIERT
4	Middleware → HubSpot	Company erstellen (nur bei Gewerbe, Dedup über Name)	`name`, `domain`, `e_mail_company`	EXISTIERT
5	Middleware → HubSpot	Deal erstellen in B2C Pipeline, Stage "Neuer Lead"	`tarif`, `kundentyp`=SLP, `jahresverbrauch__kwh_`, `netto_arbeitspreis`, `grundpreis`, `delivery_start`, `zahlernummer`, `marktlokationsid`, `zahlungsart`, `iban`, alle `lieferadresse_*`	EXISTIERT
6	~~SOLVIT-Snippet~~	~~Kunde berechnet Preis über SOLVIT-Widget~~ → Bereits ersetzt durch eigene Livewire-Auftragsstrecke (7 Steps), die Wattform API direkt aufruft	~~Widget~~ → Eigener Flow via Wattform API	BEREITS ERSETZT
6'	STARQ Platform → Wattform API	Phase 1: Bestehende Wattform API (`GET /tarife`, `POST /auftraege`) über STARQ Platform leiten statt direkt von Website. Middleware speichert alle Preisdaten, zeigt sie im Dashboard an, erlaubt Editieren. Erweiterung: Netzentgelt-Aufschlüsselung anfordern.	`netto_arbeitspreis`, `grundpreis` (kommen von Wattform API, werden in Middleware + HubSpot gespeichert)	NEU
6''	[Zukunft] Middleware	Phase 3: Eigene Pricing Engine berechnet Preis: Tarif × Region × Verbrauch + Netzentgelte (direkt abrufen). SOLVIT nur noch für Abrechnung.	`netto_arbeitspreis`, `grundpreis` (von Middleware selbst berechnet)	ZUKUNFT
7	HubSpot	Vertrieb/Automatisierung: Pipeline-Stages durchlaufen. Workflows: Lifecycle-Update, Angebotserstellung (Portant), E-Sign	`lifecyclestage`, `portant_*`, `e_sign_status`	EXISTIERT
8	HubSpot	Stage "Auftrag bestätigt" → "Auftrag gewonnen"	`deal_status`=Freigegeben	EXISTIERT
9	HubSpot → Middleware	Webhook/Trigger: Deal erreicht "Auftrag gewonnen" → Middleware wird benachrichtigt	Deal-ID, Stage-ID	NEU
10	Middleware → SOLVIT API	Vertragsdaten übermitteln: Kundendaten, Zähler, Marktlokation, Tarif, Lieferbeginn, Verbrauch, Netzgebiet	Alle relevanten Deal + Contact + Company Properties	NEU (ersetzt Snippet)
11	SOLVIT → Middleware	Bestätigung: Belieferung eingerichtet, Netzentgelte berechnet, ERP-Vertragsnummer	`erp_contract_number`, `energy_identification_code`	NEU
12	Middleware → HubSpot	Stage aktualisieren: "Auftrag gewonnen (SOLVIT)" → "Versorgung bestätigt"	`dealstage`	NEU

Bei Klärfall (SOLVIT meldet Problem)

#	System	Aktion
11a	SOLVIT → Middleware	Fehlermeldung: z.B. Zähler nicht gefunden, Marktlokation ungültig, Netzgebiet-Konflikt
11b	Middleware → HubSpot	Stage bleibt bei "Auftrag gewonnen (SOLVIT)", Notiz/Aufgabe erstellen mit Klärfall-Grund
11c	Vertrieb	Manuell klären, dann erneut an SOLVIT übergeben

5. B2B — Vollständiger Datenfluss (Zukunft)

Übersicht

              HEUTE                                    MORGEN
    ┌─────────────────────────┐             ┌─────────────────────────┐
    │ Website → Middleware    │             │ Website → Middleware     │
    │          → HubSpot     │             │          → HubSpot      │
    │                        │             │                         │
    │ MatchPoint → manuell   │             │ HubSpot ──trigger──→    │
    │   ablesen → HubSpot    │             │   Middleware             │
    │                        │             │     → MatchPoint (auto)  │
    │ HubSpot → Excel-Export │             │     → Pricing Engine     │
    │         → SOLVIT ERP   │             │     → HubSpot (Preise)   │
    │                        │             │     → SOLVIT API (auto)  │
    └─────────────────────────┘             └─────────────────────────┘
       3 Medienbrüche                          0 Medienbrüche

Detaillierter Flow

#	System	Aktion	Daten / HubSpot Properties	Status
Phase 1: Lead-Erfassung
1	Website	RLM-Kunde füllt Anfrage-Formular aus + lädt Lastprofil hoch	Firmendaten, Kontakt, Verbrauch, Dateien	EXISTIERT
2	Middleware	`POST /api/hubspot/rlm-leads/submit` — Synchrone Verarbeitung (kein Queue)	—	EXISTIERT
3	Middleware → HubSpot	Company erstellen (Dedup nur über Name!)	`name`	EXISTIERT
4	Middleware → HubSpot	Contact erstellen	`firstname`, `lastname`, `email`, `phone`, `consent`, `kontaktquelle`=Website	EXISTIERT
5	Middleware → HubSpot	Deal erstellen: B2B Pipeline, Stage "Neuer Lead"	`kundentyp`=RLM, `jahresverbrauch__kwh_`, Dealname: "RLM Anfrage {Firma}"	EXISTIERT
6	Middleware → HubSpot	Lastprofil hochladen (File Manager) + Note am Deal	Dateien + `additionalInfo` als Note	EXISTIERT

Phase 2: Vertriebsprozess
7	HubSpot (manuell)	Vertrieb kontaktiert und berät Kunden	Stages: Lead kontaktiert → beraten → qualifiziert	EXISTIERT
8	HubSpot	Vertriebler ergänzt Deal-Daten	`branche`, `vorversorger`, `aktuelles_beschaffungsmodell`, `aktueller_energiepreis_in_ctkwh`, `anzahl_zahler`, `beratungstermin`, `entscheidungsfindungsprozess`	EXISTIERT

Phase 3: Preisermittlung + MatchPoint (NEU — ersetzt manuellen MatchPoint + Excel)
9	HubSpot	Deal erreicht Stage "Angebot angefragt"	—	EXISTIERT (Stage)
10	HubSpot → Middleware	Webhook/Trigger: "Angebot angefragt" → Middleware wird benachrichtigt	Deal-ID	NEU
11	Middleware → MatchPoint	Lastprofil aus HubSpot Files API laden (CSV/Excel/PDF, ~35.000 Zeilen, 15-Min-Intervall) und an MatchPoint senden. MatchPoint analysiert Lastabdeckung durch eigene PV/Wind-Anlagen. ⚠️ Das Lastprofil geht NUR an MatchPoint, nicht an SOLVIT!	Input: Lastprofil-Datei (Format: Datum;Uhrzeit;kW;Status), Anlagendaten (PV kWp, Wind kW)	NEU
12	MatchPoint → Middleware	Matching-Ergebnis zurück: Wie viel % der Kundenlast decken PV/Wind ab, wie viel muss am Spotmarkt zugekauft werden	PV-Faktor, Wind-Faktor, Spot-Faktor, Erneuerbare-Anteil (%), 24h-Matching-Daten	NEU
13	Middleware → SOLVIT	Phase 1: SOLVIT berechnet Preis auf Basis der MatchPoint-Faktoren + Kundendaten. Middleware speichert alle Preisdaten, zeigt sie im Dashboard an. Phase 3 (Zukunft): Eigene Pricing Engine berechnet Netto-Arbeitspreis (siehe Formel unten).	Alle Pricing-Komponenten	NEU
14	Middleware → HubSpot	Alle Pricing-Properties auf Deal schreiben	`preis_solar_in_ctkwh`, `preis_windanteil_in_ctkwh`, `preis_spot_in_ctkwh`, `preis_herkunftsnachweise_in_ctkwh`, `preis_risiken_in_ctkwh`, `preis_fur_overhead_in_ctkwh`, `provision_in_ctkwh`, `netto_arbeitspreis`, `fixierte_liefermenge`, `liefermenge_flex_in`, `energiepreis_flex_in_ctkwh`	NEU
15	Middleware → HubSpot	Stage aktualisieren: "Angebot erstellt"	`dealstage`	NEU

Phase 4: Angebot + Unterschrift
16	HubSpot / Portant	PDF-Angebot generiert → Workflow: Stage "Angebot versendet" + Follow-up Task	`portant_document_link`, `hs_pdf_download_link`	EXISTIERT
17	HubSpot / Portant	E-Signatur → Workflow: e_sign_status = "unterzeichnet"	`hs_esign_date`, `e_sign_status`	EXISTIERT
18	HubSpot (manuell)	Stage "Auftrag bestätigt" → "Auftrag gewonnen"	`deal_status`=Freigegeben	EXISTIERT

Phase 5: SOLVIT-Übergabe (NEU — ersetzt Excel-Export)
19	HubSpot → Middleware	Webhook/Trigger: Deal erreicht "Auftrag gewonnen"	Deal-ID	NEU
20	Middleware → SOLVIT API	Vertragsdaten übermitteln: Kundendaten, Firma, alle Zähler (bis 10), Marktlokationen, Netzgebiet, Tarif, Verbrauch, Lieferbeginn, Zahlungsart	Alle relevanten Deal + Contact + Company Properties	NEU (ersetzt Excel)
21	SOLVIT → Middleware	Bestätigung oder Klärfall	`erp_contract_number`, `energy_identification_code`	NEU
22	Middleware → HubSpot	Stage: "SOLVIT" → ggf. "Klärfall" → "Versorgung bestätigt" (closed)	`dealstage`	NEU

Preisberechnungsformel (B2B) — Phase 3 / Zukunft

Hinweis: In Phase 1 berechnet SOLVIT die Preise. Die folgende Formel beschreibt die Zukunft (Phase 3), wenn STARQstrom die Preise selbst berechnet.

NETTO-ARBEITSPREIS (ct/kWh)
═══════════════════════════════════════════════════════════════

BESCHAFFUNG
  PV (PARQ-Anlagen):
    PV-Faktor × Preis Solar PARQ            0,37 × 7,50  =  2,775 ct
  + Wind (PARQ-Anlagen):
    Wind-Faktor × Preis Wind PPA            0,14 × 8,50  =  1,190 ct
  + Spotmarkt:
    Spot-Faktor × Preis SPOT                0,50 × 9,50  =  4,750 ct
  + Beschaffungsgebühren                                     0,400 ct
                                            ─────────────────────────
                                            Beschaffung  =  9,115 ct

HKN (HERKUNFTSNACHWEISE)
  + Preis HKN                                                0,010 ct

RISIKEN FÜR STARQSTROM
  + Ausgleichsenergie-Risiko                                 0,600 ct
  + Mengen-Risiko                                            0,100 ct
  + Marktpreis-Risiko                                        0,200 ct
  + Kredit-Risiko                                            0,500 ct
                                            ─────────────────────────
                                            Risiken      =  1,400 ct

KOSTEN FÜR STARQSTROM
  + Overhead-Kosten                                          1,500 ct
  + Vertriebsprovision                                       0,150 ct
  - Laufzeitrabatt                                    (verhandlungsabh.)
                                            ─────────────────────────
                                            Kosten       =  1,650 ct

═══════════════════════════════════════════════════════════════
NETTO-ARBEITSPREIS                                     ≈ 12,18 ct/kWh
═══════════════════════════════════════════════════════════════

Zuordnung der Faktoren:
  PV-Faktor + Wind-Faktor + Spot-Faktor = 1,00 (100% Lastabdeckung)
  Beispiel: 37% Solar + 14% Wind + 50% Spotmarkt (Börsenzukauf)

Zuordnung zu HubSpot Deal Properties:

Formel-Komponente	HubSpot Property	Quelle
PV-Faktor	(neues Property oder Berechnung)	MatchPoint
Preis Solar PARQ	`preis_solar_in_ctkwh`	STARQ-intern
Wind-Faktor	(neues Property oder Berechnung)	MatchPoint
Preis Wind PPA	`preis_windanteil_in_ctkwh`	STARQ-intern
Spot-Faktor	(neues Property oder Berechnung)	MatchPoint
Preis SPOT	`preis_spot_in_ctkwh`	EEX/EPEX
Beschaffungsgebühren	(in `preis_spot_in_ctkwh` enthalten?)	STARQ-intern
HKN	`preis_herkunftsnachweise_in_ctkwh`	STARQ-intern
Risiken gesamt	`preis_risiken_in_ctkwh`	STARQ-intern
Overhead	`preis_fur_overhead_in_ctkwh`	STARQ-intern
Provision	`provision_in_ctkwh`	STARQ-intern
Netto-Arbeitspreis	`netto_arbeitspreis`	Berechnet
Summe Provision (EUR)	`summe_provision_in_eur`	Berechnet (calculation_equation)

6. SOLVIT-Integration — Detailspezifikation

Über SOLVIT

SOLVIT GmbH (Flensburg) ist ein spezialisierter Prozessdienstleister für grüne Energieversorger. Mit der Plattform wattform bietet SOLVIT Full-Service BPO: Marktkommunikation, Abrechnung, Zählerstandsmanagement, Kundenservice und Tarifierung. SOLVIT ist nicht nur ein Preisrechner — sie betreiben das gesamte regulierte Back-Office für STARQstrom.

wattform-Module:

Modul	Name	Funktion
.cpm	Kunden- & Vertragsmanagement	Kundendaten, Verträge, Aufgabenverwaltung (inkl. Kundenservice L1+L2)
.epm	Zähler-/Gerätemanagement	Zähler, Lastprofile, Plausibilisierung, abrechnungsrelevante Messwerte
.edi	Marktkommunikation	EDIFACT-Messaging (ein-/ausgehend), Zertifikate, Marktpartner, GPKE/GeLi Gas
.bil	Abrechnung	Energierechnungen, Abschläge, Netznutzungsrechnungsprüfung, Nebenbuch, Monatsabschluss
.tar	Tarifgestaltung	Individuelle Tarife (Strom + Gas), HT/NT, modulares Baukastensystem

Ausgangslage: Wattform API existiert bereits (Update 25.02.2026)

Server-Analyse: SOLVIT hat bereits eine REST-API ("Wattform API") unter wechselprozess.services/solvreg/resources mit 7 produktiven Endpoints (Tarife, Bestellungen, PLZ-Validierung, IBAN-Check, Rabattcodes, Vorversorger-Suche).

Was bereits funktioniert (→ muss in STARQ Platform portiert werden):

B2C-Tarifabfrage: GET /tarife/{plz}/{city} mit Verbrauch, Zählertyp, Kanal
B2C-Bestellung: POST /auftraege mit Stammdaten, Bankverbindung, Tarif → gibt auftragsnummer zurück
Hilfs-Endpoints: PLZ-Validierung, Straßenliste, IBAN-Validierung, Rabattcode-Check, Vorversorger-Suche

Was noch fehlt (→ muss gemeinsam mit SOLVIT gebaut werden):

Status-Webhooks: Keine Rückmeldung nach Vertragsanlage (Bestätigung/Klärfall)
Netzentgelt-Export: Keine API für Netzentgelte/Umlagen pro PLZ/MaLo
B2B-Verträge: Kein Endpoint für RLM mit mehreren Zählern/Lieferstellen
Vertragsstatus: Kein GET-Endpoint für bestehende Aufträge
Kundenservice-Tickets: Keine API für Ticketübersicht
Marktkommunikation: Keine Einsicht in EDIFACT-Prozesse

Die fehlenden Endpoints müssen gemeinsam mit SOLVIT definiert und gebaut werden. Siehe docs/solvit-api-anforderungen.html für das vollständige Anforderungsdokument.

Drei-Stufen-Modell (aktualisiert nach CEO-Meeting 25.02.2026)

	Phase 1 (MVP)	Phase 1b (Pricing)	Phase 3 (Zukunft)
Wer berechnet Preise?	SOLVIT (via wattform, SLP)	STARQstrom (eigene Daten via ene't, RLM)	STARQstrom (eigene Pricing Engine, SLP + RLM)
Netzentgelte/Umlagen	Noch nicht verfügbar	ene't-API direkt anbinden (CEO: sofort kaufen!)	ene't vollintegriert in Pricing Engine
Middleware-Rolle	Connector zu wattform + Dashboard (einsehen + editieren)	+ ene't-Daten speichern + Preise in HubSpot pushen	Pricing Engine + SOLVIT nur Abrechnung
Kundenservice	Tickets von SOLVIT in STARQ Platform einsehen	—	Eigenes Ticketsystem integriert
Vorteil	Keine blinde Kommunikation mehr.	Preisdatenhoheit für RLM. Vertrieb befähigt.	Volle Preishoheit + volle Prozesskontrolle.

CEO-Entscheidung: ene't-Daten (Netzentgelte, Umlagen, Steuern, Messentgelte) werden sofort direkt eingekauft — nicht auf SOLVIT-API-Erweiterungen warten. Kontakt: Speaker 5 → ene't + Janis. Anja kontaktieren für Datenbankzugang. Preis: "Wann brauchen wir das? Gestern."

Unsere Anforderungen an die SOLVIT-API

Anforderung 1: Vertragsdaten übermitteln (Middleware → SOLVIT)

Wir müssen folgende Daten an SOLVIT senden können:

Datenkategorie	Felder die wir liefern	HubSpot Properties (Quelle)
Kundendaten	Name, Adresse, E-Mail, Telefon, Kundentyp (Privat/Gewerbe)	`firstname`, `lastname`, `email`, `geschaftsart`
Firmendaten	Firmenname, Handelsregister-Nr, Steuer-Nr, USt-ID, Rechtsform	`name`, `hr_nr`, `steuer_nr`, `ust_id___hr_nr`, `rechtsform`
Zählerdaten (bis 10 Stück)	Zählernummer, Zählerart (SLP/RLM), Zählertyp (Digital/Analog/Smart), Jahresverbrauch pro Zähler	`zahlernummer`..`zahlernummer10`, `zahlerart`..`zahlerart10`, `zahlertyp`..`zahlertyp10`, `jahresverbrauch_zahler1_in_kwh`..10
Marktlokation (bis 10 Stück)	Marktlokations-ID pro Zähler	`marktlokationsid`..`marktlokation10`
Lieferstellen (bis 9 Stück)	Straße, Hausnr, PLZ, Stadt pro Lieferstelle	`lieferadresse_strae`..9, `lieferadresse_plz`..9, `lieferadresse_stadt`..9
Vertragsdaten	Tarif, Lieferbeginn, Vertragslaufzeit, Auftragsgrund (Wechsel/Einzug), Netznutzung, Messstellenbetrieb	`tarif`, `delivery_start`, `mindestvertragslaufzeit_in_monaten`, `auftragsgrund`, `netznutzung`, `messstellenbetrieb`
Preisdaten	Netto-Arbeitspreis, Grundpreis, Abschlagszahlung	`netto_arbeitspreis`, `grundpreis`, `vorauszahlungshohe`
Zahlungsdaten	IBAN, Kontoinhaber, Zahlungsart	`iban`, `kontoinhaber`, `zahlungsart`
Netzgebiet	Netzgebiet / Netzbetreiber	`netzgebiet` (Company)
Billing	Alternative Rechnungsadresse, Rechnungsadresse komplett	`alternative_rechnungsadresse`, `rechnungsadresse__*`

Anforderung 2: Netzentgelte & Umlagen abrufen (SOLVIT → Middleware)

Wir brauchen von SOLVIT folgende Rückgabedaten:

Datenkategorie	Erwartete Felder	Zweck
Netzentgelte	Netznutzungsentgelt (ct/kWh), Messstellenbetrieb (EUR/a)	Phase 1: Einsehen im Dashboard. Phase 3: In eigener Pricing Engine verwendet
Umlagen & Abgaben	KWK-Umlage, §19 StromNEV-Umlage, Offshore-Umlage, Konzessionsabgabe, Stromsteuer	Preisbestandteile für Endkundenpreis
Regionale Daten	Netzgebiet-spezifische Kosten (TenneT, 50Hertz, Amprion, TransnetBW)	Regionaler Preisbestandteil

Anforderung 3: Vertragsbestätigung / Klärfall (SOLVIT → Middleware)

Datenkategorie	Erwartete Felder	Zweck
Vertragsreferenz	ERP-Vertragsnummer, Bestätigung	Tracking + HubSpot Property `erp_contract_number`
Status	Belieferung bestätigt / Klärfall	Pipeline-Stage-Steuerung
Klärfall-Details	Fehlergrund, betroffene Marktlokation	Problemlösung durch Vertrieb

Anforderung 4: Technische API-Anforderungen

Anforderung	Unsere Empfehlung	Begründung
Format	REST API mit JSON	Standard, einfach zu implementieren
Authentifizierung	API-Key oder OAuth 2.0	Sicher, industrieüblich
Kommunikation	HTTPS (TLS 1.2+)	Pflichtdaten, Verschlüsselung notwendig
Rückmeldung	Webhooks (SOLVIT → Middleware)	Für Status-Updates (bestätigt/Klärfall) ohne Polling
Testumgebung	Sandbox mit Testdaten	Für Entwicklung und QA vor Produktivgang
Dokumentation	OpenAPI/Swagger-Spezifikation	Standardisiert, maschinenlesbar

Nächster Schritt: Anforderungsdokument an SOLVIT

Aus diesem Middleware-Plan sollte ein konkretes Anforderungsdokument an SOLVIT erstellt werden mit:

Use Cases: B2C-Preisberechnung via API (statt blind), B2B-Vertrag anlegen, Netzentgelte + Preisdaten abrufen, Status-Rückmeldung
Datenfelder: Vollständige Liste (siehe Tabellen oben)
Technische Anforderungen: REST/JSON, Auth, Webhooks, Sandbox
Zeitplan: API-Definition Q1, Entwicklung Q1-Q2, Testphase Q2, Produktivgang Q2
Was sich ändert: Website → Middleware → SOLVIT (statt Website → SOLVIT blind). Phase 1: SOLVIT berechnet weiter, aber Middleware hat Transparenz. Phase 3: Eigene Preisberechnung.

→ Aktionspunkt: Anforderungsdokument für SOLVIT-API erstellen und an SOLVIT übergeben. Dies ist der wichtigste nächste Schritt für Phase 1.

7. MatchPoint-Integration — Detailspezifikation

Aktueller Zustand

Standalone Lovable-App (Frontend-only)
Keine API, keine Datenbank
Wird manuell von Vertrieblern bedient

Zielzustand

Zwei Optionen:

Option A: MatchPoint-Logik in Middleware extrahieren

Matching-Algorithmus (PV/Wind vs. Kundenlast) wird als Service in der Middleware implementiert
Volle Kontrolle, keine externe Abhängigkeit
Aufwand: Mittel (Algorithmus muss verstanden und reimplementiert werden)

Option B: API-Layer um MatchPoint bauen

MatchPoint (Lovable) bekommt API-Endpunkte
Middleware ruft MatchPoint-API auf
Geringerer Umbau, aber Abhängigkeit von Lovable-Plattform

Empfehlung: Option A (langfristig robuster), zunächst aber mit dem bestehenden MatchPoint-Tool als Referenz arbeiten.

Daten-Spezifikation

Input (Middleware → MatchPoint):

Daten	Quelle	Format	Beispielwert (aus Referenzdatensatz)
Lastprofil	HubSpot Files API (Note am Deal)	CSV (15-Min-Intervalle, ~35.000 Zeilen/Jahr)	`lastprofil-LG_2025_PSA_50522423206.csv`
Jahresverbrauch	HubSpot Deal (`jahresverbrauch__kwh_`)	Integer (kWh)	121.352 kWh
Lastspitze	Berechnet aus Lastprofil	Number (kW)	87,5 kW
Benutzungsstunden	Berechnet: Verbrauch / Lastspitze	h/a	1.387 h/a
Verfügbare PV-Anlagen	PARQ/interne Daten	Kapazität (kWp), Standort	—
Verfügbare Wind-Anlagen	PARQ/interne Daten	Kapazität (kW), Standort	—

Lastprofil-CSV Format (aus realem Datensatz):

Header: # Schlüssel;;Wert;;
  Relevante Header: Marktlokation, Zählpunktbezeichnung, OBIS-Kennzeichen, Einheit, Periode

Daten: Datum;Uhrzeit;Leistung(kW);Status;
  Beispiel: 16.01.2025;10:00:00;87,520000;W;
  Status W = gemessener Wert
  Dezimaltrennzeichen: Komma
  ~96 Einträge pro Tag × 365 Tage = ~35.040 Zeilen/Jahr

Output (MatchPoint → Middleware):

Daten	Beschreibung	Beispielwert
PV-Faktor	Anteil der Last, der durch PV abgedeckt wird	0,37 (37%)
Wind-Faktor	Anteil der Last, der durch Wind abgedeckt wird	0,14 (14%)
Spot-Faktor	Restanteil (Börsenzukauf) = 1 - PV - Wind	0,50 (50%)
Erneuerbare-Anteil	PV + Wind zusammen	51%
Börsenzukauf-Anteil	= Spot-Faktor	50% (gerundet)
24h-Matching-Profil	Stundenwerte: Last vs. PV vs. Wind vs. Spot	Array[24]

7a. Lastprofil-Analyse (Referenzdatensatz)

In HubSpot wurden 2 echte Lastprofile gefunden, die von RLM-Kunden über das Website-Formular hochgeladen wurden. Die CSV-Datei dient als Referenz für die Middleware-Entwicklung.

Fundstelle

Datei	Typ	Größe	Datum	HubSpot File ID
`lastprofil-LG_2025_PSA_50522423206`	CSV	1.140 KB	03.02.2026	357685944516
`lastprofil-WBG Plauen`	PDF	188 KB	16.12.2025	324683228394

Beide liegen im Ordner form-uploads/ → wurden über das RLM-Formular hochgeladen.

Metadaten (CSV-Header)

Feld	Wert	Bedeutung
Zählpunkt-ID	`SWF_SST_1163255`	Interne Kennung des Zählpunkts
Zählpunktbezeichnung	`DE0001815463400000201700000064974`	33-stelliger DE-Identifikator
Marktlokation	`50522423206`	Schlüssel für SOLVIT + Netzbetreiber
OBIS-Kennzeichen	`1-1:1.29.0`	Wirkarbeit Lieferung
Einheit	kW	Leistung pro 15-Min-Intervall
Netzanschluss	`0030241857`	Für Netzentgelt-Zuordnung
Adresse	Am Tower 6, 54634 Bitburg	Lieferstellenadresse
Periode	15 Minuten	Messintervall

Analyseergebnisse

KPI	Wert
Zeitraum	01.01.2025 – 01.01.2026 (365 Tage)
Datenpunkte	35.040 (15-Min-Intervalle)
Jahresverbrauch	121.352 kWh
Durchschnittsleistung	13,85 kW
Lastspitze	87,5 kW (16.01.2025, 10:00 Uhr)
Benutzungsstunden	1.387 h/a
Datenqualität	100% gemessene Werte (Status "W")

Verbrauchsmuster

Durchschnittliches Tageslastprofil (kW):
  00:00  |  4,35 kW  ##
  06:00  |  8,44 kW  ####
  07:00  | 24,35 kW  ###########
  08:00  | 30,59 kW  ##############
  09:00  | 31,72 kW  ##############
  10:00  | 33,06 kW  ###############   ← Spitze
  11:00  | 30,72 kW  ##############
  12:00  | 26,92 kW  ############
  13:00  | 28,98 kW  #############
  14:00  | 27,13 kW  ############
  15:00  | 22,59 kW  ##########
  16:00  |  9,26 kW  ####
  17:00  |  4,90 kW  ##
  23:00  |  4,40 kW  ##

Klarer Gewerbebetrieb: Mo-Fr 07:00-16:00 hoher Verbrauch
  Werktag:    ~425 kWh/Tag
  Wochenende: ~ 99 kWh/Tag (nur Grundlast)

Datenformat (CSV)

# Zählpunkt-ID;;SWF_SST_1163255;;
# Zählpunkbezeichnung;;DE0001815463400000201700000064974;;
# Marktlokation;;50522423206;;
# OBIS-Kennzeichen;;1-1:1.29.0;;
# Einheit (Originaleinheit);;kW;;
# Periode;;15 Minuten;;
# ... weitere Header-Zeilen
01.01.2025;00:15:00;4,528000;W;
01.01.2025;00:30:00;4,344000;W;
...
31.12.2025;23:45:00;3,320000;W;

Format-Regeln:

Zeilen mit # = Header-Metadaten (Key;;Value;;)
Datenzeilen: Datum;Uhrzeit;Leistung(kW);Status;
Dezimaltrennzeichen: Komma (deutsch)
Status: W = gemessener Wert
~35.000 Zeilen pro Jahr (96 Intervalle × 365 Tage)

Wo das Lastprofil im Datenfluss steht

⚠️  WICHTIG: Das Lastprofil geht an MatchPoint, NICHT an SOLVIT!

Lastprofil (CSV/Excel/PDF)
    │  Upload durch Kunde über RLM-Formular auf Website
    │  Gespeichert: HubSpot Files API + Note am Deal
    ▼
MatchPoint (B2B Schritt 11-12)
    │  Analysiert: Wie viel PV/Wind deckt die Kundenlast ab?
    │  Output: PV-Faktor, Wind-Faktor, Spot-Faktor
    ▼
Pricing Engine (B2B Schritt 13)
    │  Berechnet: Faktoren × Preise + Risiken + Overhead
    │  Output: Netto-Arbeitspreis (ct/kWh)
    ▼
HubSpot Deal (B2B Schritt 14-15)
    │  Schreibt: Alle Pricing-Properties + Stage "Angebot erstellt"
    ▼
[Angebot → E-Sign → Auftrag gewonnen]
    ▼
SOLVIT API (B2B Schritt 19-22)
    │  Bekommt: Vertragsdaten (Kunde, Marktlokation, Tarif, Preis, Laufzeit)
    │  NICHT den rohen Lastgang — nur die fertigen Konditionen!
    ▼
Versorgung bestätigt

8. HubSpot Property-Stage-Mapping

B2C Pipeline — Wer schreibt was, wann?

Stage	Middleware	HubSpot Workflows	Vertriebler (manuell)
Neuer Lead	SCHREIBT: Alle Contact + Deal Properties (30+)	WF: lifecyclestage=Opportunity	—
Lead kontaktiert	—	—	Stage manuell setzen
Lead wiedervorliegend	—	—	Stage manuell setzen
Lead terminiert	—	—	Stage manuell setzen
Lead beraten	—	—	Stage manuell setzen
Lead qualifiziert	—	—	Stage manuell setzen
Angebot angefragt	—	—	Stage manuell setzen
Angebot erstellt	—	WF: quote_status=DRAFT → Stage	Portant-Dokument erstellen
Angebot versendet	—	WF: PDF-Link → Stage + Follow-up Task	—
Auftrag bestätigt	—	WF: E-Sign → e_sign_status	Stage manuell setzen
Auftrag verloren	—	—	Stage manuell setzen
Auftrag gewonnen	—	—	Stage manuell setzen
Auftrag gew. (SOLVIT)	NEU: LIEST Deal-Daten, SCHREIBT an SOLVIT API, SCHREIBT erp_contract_number	—	—
Versorgung bestätigt	NEU: SCHREIBT dealstage (nach SOLVIT-Bestätigung)	—	—

B2B Pipeline — Wer schreibt was, wann?

Stage	Middleware	HubSpot Workflows	Vertriebler (manuell)
Neuer Lead	SCHREIBT: Contact + Company + Deal + Notes/Files	WF: lifecyclestage=Opportunity	—
Lead wiedervorliegend	—	—	Stage manuell
Lead kontaktiert	—	—	Stage manuell
Lead terminiert	—	—	Stage manuell
Lead beraten	—	—	Stage manuell, Deal-Daten ergänzen
Lead qualifiziert	—	—	Stage manuell
Angebot angefragt	NEU: LIEST Lastprofil + Deal-Daten → MatchPoint → Pricing Engine → SCHREIBT 13+ Pricing Properties	—	Stage manuell setzen (Trigger!)
Angebot erstellt	NEU: SCHREIBT dealstage	WF: Stage-Automatisierung	—
Angebot versendet	—	WF: PDF-Link → Stage + Task	—
Auftrag bestätigt	—	WF: E-Sign	Stage manuell
Auftrag gewonnen	NEU: LIEST alle Deal-Daten → SOLVIT API (ersetzt Excel!)	—	Stage manuell (Trigger!)
SOLVIT	NEU: SCHREIBT erp_contract_number, Wartet auf SOLVIT	—	—
Klärfall	NEU: SCHREIBT Klärfall-Grund, erstellt Aufgabe	—	Manuell klären
Versorgung bestätigt	NEU: SCHREIBT dealstage nach SOLVIT-Bestätigung	—	—
Lead verloren	—	—	Stage manuell

9. Offene Punkte & Abhängigkeiten

Blocker (müssen vor Implementierung gelöst werden)

#	Thema	Was muss passieren	Wer	Impact
1	~~SOLVIT API gibt es noch nicht~~ SOLVIT API-Erweiterungen	ERLEDIGT (teilweise): Wattform API existiert (7 Endpoints). Fehlend: Status-Webhooks, Netzentgelte, B2B-Verträge. → Anforderungsdokument erstellt (`docs/solvit-api-anforderungen.html`), muss mit SOLVIT besprochen werden. CEO-Meeting: Fabio bringt Team mit SOLVIT zusammen. Solve-Weekly Mo 13:00 ab KW 10. Fragenkatalog vorbereitet (`docs/solvit-fragenkatalog.md`).	STARQstrom + ProcesslyAI → SOLVIT	B2C-Basis funktioniert. Erweiterungen in Arbeit.
2	~~SOLVIT-Snippet analysieren~~	ERLEDIGT	—	—
3	~~EEX/EPEX API-Zugang~~ ene't + EEX Datenzugang	CEO-Entscheidung: Netzentgelte/Umlagen direkt von ene't kaufen (nicht auf SOLVIT warten). Speaker 5 kontaktiert ene't, Janis einbeziehen. ProcesslyAI kontaktiert Anja für Datenbankzugang. EEX abhängig von Handels-/Produktstrategie.	Speaker 5 (ene't), ProcesslyAI (Anja), STARQstrom (Strategie)	Vorgezogen auf sofort! Vertriebsbefähigung.

Hohe Priorität (CEO-Meeting-Updates)

#	Thema	Was fehlt / Status	Wer
4	~~Company-Deduplizierung~~	ENTSCHIEDEN: E-Mail-Domain als primärer Identifier	ProcesslyAI
5	MatchPoint-Zukunft	CEO bestätigt: Erst Middleware, dann MatchPoint-Anbindung (Phase 2)	STARQstrom + ProcesslyAI
6	Webhook vs. Polling	HubSpot-Tier prüfen (Webhooks benötigen ggf. Operations Hub)	STARQstrom
7	~~Preisparameter-Pflege~~	CEO-Meeting: Preisparameter werden Backend-seitig bei Marktänderungen angepasst (z.B. Wind-PPA von 8,5 auf 7,5 ct). Aktuell im MatchPoint-Backend. Zukünftig in Middleware-Dashboard.	STARQstrom (Vertrieb)
7a	Wind-PPA Fixierung	Wind-Preis noch nicht fixiert. PPA-Fixierung in 1-2 Monaten geplant. Danach Terminmarkt für weitere Mengen.	STARQstrom
7b	Partner Operations ab 01.03	Partner-Zugang zu HubSpot, Vertriebs-Automatisierung dringend. Partnerzugang bereitstellen.	STARQstrom/HubSpot-Admin
7c	Handelsvertreter-App	Schnelle Bereitstellung einer einfachen App mit Angebotsfunktion basierend auf Pricing-Grundlagen. Scope: noch zu definieren (PWA? HubSpot-basiert? Partnerportal-Reiter?)	ProcesslyAI + STARQstrom
7d	Roadmap-Ownership	ProcesslyAI übernimmt eigenständige Priorisierung. Fabio gibt Kontext, Team erarbeitet Vorschläge.	ProcesslyAI
7e	Backend-Zugang Longeville	ProcesslyAI braucht Berechtigungen für den bestehenden Server. Finn soll das klären.	Finn
7f	Solve-Weekly Teilnahme	Montag 13:00 mit Janin — ProcesslyAI nimmt ab KW 10 teil. Fragenkatalog vorab senden.	ProcesslyAI + Jan

Gut zu klären (vor Phase 2/3)

#	Thema	Was fehlt
8	~~SQLite → PostgreSQL Migration~~	ENTSCHIEDEN: Neubau in Rails mit PostgreSQL von Anfang an (kein SQLite)
9	~~Beispiel-Messdaten (RLM)~~	ERLEDIGT: RLM-Lastprofil in HubSpot gefunden
9a	SLP-Referenzdaten	Noch ausstehend: Referenz-Kundendaten für B2C-Test-Flow
10	Genaue Preisberechnungsformeln	CEO bestätigt: PV ~7,5 ct, Wind ~8 ct (noch nicht fixiert), Börse ~11,5 ct. Mix 40/40/20 typisch. Beispiel: 9,14 ct Angebot.
11	Partner Portal Auth	JWT? OAuth? API-Keys?
12	in.Power Integration	InPower = Bilanzkreismanagement/Direktvermarktung. Keine Kundendaten. Liefert aggregierte Beschaffungswerte monatlich → SOLVIT ordnet Kunden zu.
13	Kisters-Workshop	Zeitreihen/Trading-System. Erst nach interner Sortierung, dann externer Workshop.
14	STARQstrom-Portal vs. Partnerportal	CEO prüft, ob eigenes Portal als Frontend (ggf. Reiter im Partnerportal). Middleware-Interface mit Logins konzipieren.

10. Roadmap (aktualisiert nach CEO-Meeting 25.02.2026)

CEO-Priorität: "Wann brauchen wir das? Gestern." — Vertrieb + Pricing zuerst, dann schrittweise erweitern.

Phase 0: SOFORT (KW 9-10, diese + nächste Woche)

Aufgabe	Status	Wer
~~Server-Analyse~~	ERLEDIGT	ProcesslyAI
~~SOLVIT API-Anforderungen~~	ERLEDIGT	ProcesslyAI
~~HubSpot Audit~~	ERLEDIGT	ProcesslyAI
~~Meeting-Protokoll~~	ERLEDIGT → `docs/meeting-25-02-2026.md`	ProcesslyAI
~~Fragenkatalog für SOLVIT~~	ERLEDIGT → `docs/solvit-fragenkatalog.md`	ProcesslyAI
Anja kontaktieren für ene't-Datenzugang	OFFEN	ProcesslyAI
Speaker 5: ene't kontaktieren, Termin + Janis	OFFEN	Speaker 5
Finn: Backend-Zugang Longeville	OFFEN	Finn
Solve-Weekly Mo 13:00 teilnehmen, Fragenkatalog vorab an Janin	OFFEN	ProcesslyAI + Jan
Roadmap-Priorisierungsvorschlag erarbeiten	OFFEN	ProcesslyAI

Phase 1: Foundation + Pricing (CEO-Priorität 1)

Ziel: Rails-App aufsetzen, HubSpot-Sync portieren, SOLVIT als transparenter Proxy, Middleware-Dashboard, ene't-Daten sofort anbinden

Aufgabe	Abhängigkeit
Rails-App Skeleton aufsetzen (Auth, PostgreSQL, Sidekiq, Kamal-Setup auf Hetzner, Tailwind CSS)	—
~~Anforderungsdokument für SOLVIT-API erstellen~~	ERLEDIGT: `docs/solvit-api-anforderungen.html` (v1.1)
~~Aktuelle SOLVIT-Integration analysieren~~	ERLEDIGT: `docs/server-analyse.md`
API-Endpunkte für Website (empfängt SLP + RLM Daten von Statamic per POST)	Rails-Skeleton
HubSpot-Sync portieren (DM-Code → Rails Service Objects: OrderSync, RlmLeadSync)	Rails-Skeleton
Company-Dedup implementieren (E-Mail-Domain als primärer Identifier)	Rails-Skeleton
HubSpot Reverse Sync: Webhook-Empfänger + 2 neue HubSpot-Workflows	HubSpot Webhook-Fähigkeit prüfen
SOLVIT-Anbindung (Website → Middleware → SOLVIT, Preisdaten speichern + anzeigen). B2C-Basis via Wattform API. Erweiterungen mit SOLVIT abstimmen (Solve-Weekly ab KW 10).	Wattform API existiert.
ene't-Anbindung — Netzentgelte, Umlagen, Steuern, Messentgelte direkt von ene't API beziehen. In PostgreSQL speichern (versioniert). Im Dashboard anzeigen. In HubSpot-Deals pushen.	ene't-Vertrag (Speaker 5 + Anja)
Middleware-Dashboard/Interface mit Logins (Sync-Status, KPIs, Preisdaten einsehen/editieren, Mess-/Börsendaten, Logs) — CEO: "Sichtbarkeit aller DB-Daten, fachliche Prüfungen ermöglichen"	Rails-Skeleton
Preisdaten automatisch in HubSpot pushen — Börsenpreise, Preis-Tabellen → HubSpot-Deal-Objekte	ene't + Rails-Skeleton
Handelsvertreter-App — Einfache Angebotsfunktion basierend auf Pricing-Grundlagen (Scope noch zu definieren)	Pricing-Daten verfügbar
Datenmodell: Sync-State, SOLVIT-Handovers, Lastprofile, Preisdaten, ene't-Daten	—

Phase 2: MatchPoint + Partner Portal (CEO bestätigt: nach Middleware)

Ziel: MatchPoint-Automatisierung, kein manuelles Ablesen mehr. Partner Portal mit KPIs.

Aufgabe	Abhängigkeit
MatchPoint-Logik in Rails implementieren (PV/Wind/Spot-Matching, Service Object)	MatchPoint-Algorithmus verstehen
MatchPoint-Connector: Lastprofil automatisch → Analyse → Faktoren → HubSpot	Phase 1
Partner Portal: Dashboard mit KPIs (Turbo Frames, Chartkick + Chart.js)	Phase 1
Partner Portal: Kundenliste + Messdaten-Übersicht (Ransack, Pagy)	Phase 1
End-to-End Test: RLM-Lead → MatchPoint → SOLVIT → HubSpot → Portant PDF	—
SOLVIT-Integration Produktivgang	SOLVIT API-Erweiterungen fertig
Datenimporte aus SOLVIT/InPower etablieren (mindestens monatlich)	SOLVIT-Schnittstelle

Phase 3: Eigene Pricing Engine + EEX

Ziel: Volle Preishoheit — eigene Preisberechnung, SOLVIT nur noch für Abrechnung

Datenstrategie (aktualisiert 25.02.2026): ene't-Anbindung wird auf Phase 1 vorgezogen (CEO-Entscheidung). Die Pricing Engine nutzt ene't-Daten + MatchPoint-Faktoren + eigene Preisparameter. EPEX-Datenstrategie abhängig von Handels-/Produktstrategie. Wind-PPA wird in 1-2 Monaten fixiert.

Aufgabe	Abhängigkeit
EEX/EPEX Spot-Preis-Import (Sidekiq Cron-Job, PostgreSQL)	EEX API-Zugang (Strategie klären!)
Pricing Engine: B2B-Kalkulator (MatchPoint-Faktoren × Preise + Risiken + Overhead)	Phase 2 + ene't
Pricing Engine: B2C-Kalkulator (Tarif + Region + Verbrauch + Netzentgelte via ene't)	Phase 1 ene't-Anbindung
Marktpreise + Pricing-Screens im Partner Portal	Phase 2 Portal
SOLVIT-Preiskalkulator ablösen (SLP — bisher Website-Snippet)	Eigene Preisberechnung funktioniert
Kisters-Workshop — Zeitreihen/Trading-System evaluieren (erst nach interner Sortierung)	Interne Grundlage geschaffen

Phase 4: Vollbetrieb

Belieferungs- und Beschaffungsdaten (SOLVIT/InPower — 15-Min-Daten für RLM)
Erzeugungs- und Verbrauchsdaten (MeteoControl, PARQ/Odoo)
in.Power-Integration (Bilanzkreismanagement, Fahrplandaten)
Lastganganalyse (erweiterte Messdaten-Auswertung)
Provisionsberechnung (Partner Portal)
Abrechnungsdaten (SOLVIT → Middleware, retrospektiv)
ERP (CPM) Integration
PHP-Middleware (Digital Masters) abschalten (sobald Rails-App alle Flows übernommen hat)

Anhang: Referenzen

Dokument	Pfad	Inhalt
HubSpot Audit	`docs/hubspot-audit.md`	Alle 212 Custom Properties, Pipeline-Stage-IDs, Workflows
Middleware-Doku (Digital Masters)	`reference/Technische Dokumentation...pdf`	Vollständiges Daten-Mapping, State Machine, Infrastruktur
Projektdokumentation	`CLAUDE.md`	MatchPoint-Pricing, Tarife, Systemlandschaft, Roadmap
Partner Portal Plan	`claude-context/plans/partner-portal-projektplan.md`	Portal-Screens, Tech-Stack, Architektur
Server-Analyse	`docs/server-analyse.md`	3-System-Architektur, Wattform API Endpoints, HubSpot Property Mappings
SOLVIT API-Anforderungen	`docs/solvit-api-anforderungen.html`	7 bestehende + 5 neue Endpoints
CEO-Meeting Protokoll	`docs/meeting-25-02-2026.md`	Strategische Entscheidungen, Action Items, Roadmap-Updates (25.02.2026)
SOLVIT-Fragenkatalog	`docs/solvit-fragenkatalog.md`	Vorbereitete Fragen für Solve-Weekly (Mo 03.03.2026)
Lastprofil-Referenzdaten	HubSpot Files API, ID `357685944516`	RLM-Lastgang CSV, 35.040 Zeilen, Gewerbekunde Bitburg
HubSpot Scope-Check	`scripts/check-scopes.js`	Verifizierung aller 7 API-Endpunkte
HubSpot Files Übersicht	`scripts/list-files.js`	184 Dateien inventarisiert

Inhaltsverzeichnis

STARQstrom Middleware — Masterplan

1. Zusammenfassung

Heute (verifiziert, Server-Analyse 25.02.2026)

Morgen (CEO-Meeting 25.02.2026 — bestätigt und erweitert)

Was sich konkret ändert

Kernvorteile

2. IST-Zustand

2.1 Middleware (Digital Masters GmbH) — wird abgelöst

Flow A: SLP-Bestellung (B2C) — Asynchron

Flow B: RLM-Lead (B2B) — Synchron

State Machine (für alle Objekte)

Bekanntes Problem + Lösungsansatz

2.2 HubSpot CRM

2.3 SOLVIT GmbH (aktueller Zustand — Server-Analyse 25.02.2026)

Wattform API — EXISTIERT bereits!

Aktueller Datenfluss (Update nach Server-Analyse)

2.4 MatchPoint (aktueller Zustand)

3. SOLL-Zustand — Zielarchitektur

STARQ Platform (Rails-Monolith)

Komponenten — Übersicht

4. B2C — Vollständiger Datenfluss (Zukunft)

Übersicht

Detaillierter Flow

Bei Klärfall (SOLVIT meldet Problem)

5. B2B — Vollständiger Datenfluss (Zukunft)

Übersicht

Detaillierter Flow

Preisberechnungsformel (B2B) — Phase 3 / Zukunft

6. SOLVIT-Integration — Detailspezifikation

Über SOLVIT

Ausgangslage: Wattform API existiert bereits (Update 25.02.2026)

Drei-Stufen-Modell (aktualisiert nach CEO-Meeting 25.02.2026)

Unsere Anforderungen an die SOLVIT-API

Anforderung 1: Vertragsdaten übermitteln (Middleware → SOLVIT)

Anforderung 2: Netzentgelte & Umlagen abrufen (SOLVIT → Middleware)

Anforderung 3: Vertragsbestätigung / Klärfall (SOLVIT → Middleware)

Anforderung 4: Technische API-Anforderungen

Nächster Schritt: Anforderungsdokument an SOLVIT

7. MatchPoint-Integration — Detailspezifikation

Aktueller Zustand

Zielzustand

Daten-Spezifikation

7a. Lastprofil-Analyse (Referenzdatensatz)

Fundstelle

Metadaten (CSV-Header)

Analyseergebnisse

Verbrauchsmuster

Datenformat (CSV)

Wo das Lastprofil im Datenfluss steht

8. HubSpot Property-Stage-Mapping

B2C Pipeline — Wer schreibt was, wann?

B2B Pipeline — Wer schreibt was, wann?

9. Offene Punkte & Abhängigkeiten

Blocker (müssen vor Implementierung gelöst werden)

Hohe Priorität (CEO-Meeting-Updates)

Gut zu klären (vor Phase 2/3)

10. Roadmap (aktualisiert nach CEO-Meeting 25.02.2026)

Phase 0: SOFORT (KW 9-10, diese + nächste Woche)

Phase 1: Foundation + Pricing (CEO-Priorität 1)

Phase 2: MatchPoint + Partner Portal (CEO bestätigt: nach Middleware)

Phase 3: Eigene Pricing Engine + EEX

Phase 4: Vollbetrieb

Anhang: Referenzen