CURE Onboarding

Onboarding- und Monitoring-Plattform für Apotheken im Auftrag der CURE Group GmbH.

Ziel

Apotheken möchten ihre Produkte über Lieferdienste wie Lieferando verkaufen. Dafür müssen die Lieferplattformen wissen, welche Artikel die Apotheke aktuell auf Lager hat.

Die CURE Group GmbH stellt diese Verbindung her: Sie verbindet Apotheken mit Lieferdiensten. Damit das funktioniert, muss auf dem Server jeder Apotheke eine Software installiert werden, die stündlich die aktuellen Lagerbestände aus der Warenwirtschaft „Prokas" ausliest und per SCP an CURE übermittelt.

CURE führt diese Installation nicht selbst durch — sie wird an die b.net GmbH ausgelagert. Sobald CURE eine neue Apotheke unter Vertrag nimmt, meldet sie diese bei b.net an. b.net kontaktiert die Apotheke, installiert die Software per Fernzugriff (TeamViewer) und überwacht den laufenden Betrieb.

Diese Webanwendung ist das System, das diesen gesamten Prozess abbildet — von der Beauftragung durch CURE bis zur laufenden Überwachung.

---

Beteiligte

Partei	Rolle	Zugang zum System
CURE Group GmbH	Auftraggeber. Meldet neue Apotheken an.	Webformular (nur Eingabe)
b.net GmbH	Dienstleister. Installiert Software, überwacht Betrieb, erstellt Rechnungen.	Internes Dashboard + API
Apotheke	Endkunde. Betreibt den Prokas-Server, auf dem die Software läuft.	Indirekt — über die installierte Software, die unsere API aufruft

---

Systemkomponenten

1a. CURE-Beauftragungsformular

Zweck: CURE-Mitarbeiter melden eine neue Apotheke zur Einrichtung an.

Benutzer: Nur CURE-Mitarbeiter.

Funktionsweise:

• Erfasst alle für das Onboarding notwendigen Daten:
  • Name und Anschrift der Apotheke
  • Ansprechpartner (Name, Telefon, E-Mail)
  • CURE-Zugangsdaten der Apotheke (Benutzername + Kennwort)
  • TeamViewer-ID des Prokas-Servers
  • Prokas-Berichtsnummer
  • Ob b.net den Prokas-Bericht einrichten soll (Zusatzleistung)
• Speichert den Datensatz mit Status „Neu".
• Löst eine Benachrichtigung an b.net aus.

Wichtig: Die Aufgabe von CURE endet hier. Sie melden an, wir übernehmen.

1b. CURE-Statusverwaltung (Deaktivierung / Kündigung)

Zweck: CURE kann den Status bestehender Apotheken ändern — z. B. bei Vertragskündigung oder Kontosperrung.

Benutzer: Nur CURE-Mitarbeiter.

Funktionsweise:

• Übersicht der eigenen gemeldeten Apotheken mit aktuellem Status.
• Möglichkeit, eine Apotheke zu deaktivieren oder zu sperren.
• Statusänderung wird in der Datenbank gespeichert und bei der nächsten Lizenzprüfung berücksichtigt (Skript erhält deaktiviert).
• Löst eine Benachrichtigung an b.net aus.

Hinweis: Die vertraglichen Regelungen zur Kündigung einzelner Apotheken sind noch zu klären. Möglicherweise erfolgt die Kündigung zunächst schriftlich, und b.net passt den Status manuell an.

Künftige Automatisierung (API für CURE)

Sowohl die Beauftragung (1a) als auch die Deaktivierung (1b) sind in V1 als Webformulare umgesetzt. Parallel werden API-Endpunkte bereitgestellt, die dieselben Daten entgegennehmen. Sobald CURE bereit ist, ihre Systeme anzubinden, können sie vom Formular auf die API umsteigen — ohne Änderung am b.net-Backend.

---

2. Benachrichtigungssystem

Zweck: Informiert das b.net-Team über neue Aufträge.

Benutzer: b.net-Mitarbeiter (Empfänger).

Funktionsweise:

• Wird ausgelöst, sobald eine neue Apotheke über das CURE-Formular eingereicht wird.
• V1: E-Mail an ein b.net-Postfach mit Apothekenname, Kontaktdaten und Direktlink zum internen Datensatz.
• Später: Rocket.Chat-Webhook oder Planner-Aufgabe.

---

3. Internes b.net-Dashboard

Zweck: Zentrales Werkzeug für das b.net-Team zur Verwaltung aller Apotheken.

Benutzer: Nur b.net-Mitarbeiter (hinter Authentifizierung).

Funktionsweise:

• Listenansicht: Alle Apotheken mit aktuellem Status, filter- und sortierbar.
• Detailansicht pro Apotheke:
  • Alle von CURE übermittelten Daten (schreibgeschützt).
  • Bearbeitbare Felder für fehlende Daten (TeamViewer-ID, Berichtsnummer etc.).
  • Kontaktprotokoll — Zeitleiste aller Kontaktversuche mit der Apotheke (Datum, Uhrzeit, Notizen).
  • Installationsstatus und -datum.
  • HWID und Hostname (automatisch vom Installer über die API befüllt).
• Status-Workflow: Jede Apotheke durchläuft folgende Stufen:
  • Neu → CURE hat gemeldet, noch keine Aktion.
  • Kontaktiert → b.net hat die Apotheke kontaktiert.
  • Installiert → Software installiert, Überprüfung ausstehend.
  • Aktiv → Alles läuft, stündliche Übertragung bestätigt.
  • Fehler → Störung, Handlungsbedarf.
  • Deaktiviert → Apotheke abgemeldet / Vertrag beendet.
• Abrechnungsliste: Gefilterte Ansicht aller „Aktiv"-Apotheken, exportierbar als CSV für das Rechnungswesen (30 €/Monat pro aktive Apotheke). Später: Lex-Office-Anbindung.

---

4. API (Registrierung & Lizenzprüfung)

Zweck: Schnittstelle zwischen der installierten Software auf dem Apotheken-Server und unserem System.

Benutzer: Svens PowerShell-Skript auf dem Windows-Server der Apotheke.

Funktionsweise:

• Registrierung (action=register):

  • Einmalig bei der Installation aufgerufen.
  • Empfängt HWID (Hardware-ID) und Hostnamen vom Installer.
  • Speichert die Daten und verknüpft sie mit dem Apotheken-Datensatz.
  • Erfordert einen API-Key zur Authentifizierung.

• Statusabfrage (Standard, per HWID):

  • Wird stündlich vom Skript aufgerufen, bevor die Datenübertragung startet.
  • Gibt zurück, ob die Lizenz aktiviert oder deaktiviert ist.
  • Künftig: liefert auch die aktuelle Softwareversion für Auto-Updates.

Wichtig: Diese API überträgt KEINE Apothekendaten. Der Datenfluss (Lagerbestände) geht direkt von der Apotheke zu CURE per SCP. b.net ist an dieser Übertragung nicht beteiligt.

---

5. Fehlerüberwachung

Zweck: Störungen bei der stündlichen Datenübertragung erkennen und melden.

Benutzer: b.net-Mitarbeiter.

Funktionsweise:

• Die installierte Software meldet sich stündlich bei unserer API und übermittelt den Status des letzten Durchlaufs (Erfolg/Fehler).
• Jeder Status wird in einer Log-Tabelle in der Datenbank gespeichert — kein E-Mail-Versand bei Erfolg.
• Nur im Fehlerfall wird eine Benachrichtigung ausgelöst (E-Mail oder Rocket.Chat-Kanal).
• Betroffene Apotheken werden im Dashboard markiert.
• Apotheken, die sich nicht mehr melden, werden ebenfalls erkannt (fehlender Heartbeat).
• Später optional: Anbindung an Grafana für erweiterte Überwachung und Alerting.

Hintergrund: Svens aktuelle Lösung sendet stündlich eine Status-E-Mail pro Apotheke. Bei 2 Apotheken ist das überschaubar — bei Hunderten nicht mehr sinnvoll. Daher wird auf DB-Logging mit Benachrichtigung nur im Fehlerfall umgestellt.

---

Gesamtablauf

CURE meldet an          b.net bearbeitet         Installation              Laufender Betrieb
neue Apotheke           den Auftrag              (per TeamViewer)          (automatisch, stündlich)
─────────────          ──────────────           ──────────────           ──────────────────

┌─────────────┐        ┌─────────────┐         ┌──────────────┐         ┌──────────────────┐
│ CURE füllt   │──────▶│ Datensatz    │───────▶│ b.net nimmt   │───────▶│ Skript läuft      │
│ Webformular  │       │ gespeichert  │        │ Kontakt zur   │        │ stündlich auf dem  │
│ aus          │       │ Status: Neu  │        │ Apotheke auf, │        │ Apotheken-Server   │
└─────────────┘        │              │        │ plant         │        │                    │
                       │ Benachrich-  │        │ TeamViewer-   │        │ 1. Lizenzprüfung   │
                       │ tigung an    │        │ Sitzung       │        │    über unsere API  │
                       │ b.net        │        │               │        │                    │
                       └─────────────┘        │ Installer     │        │ 2. Prokas-Bericht   │
                                               │ ausführen     │        │    abfragen         │
                                               │ ─▶ API-Aufruf │        │                    │
                                               │    (Register) │        │ 3. CSV an CURE per  │
                                               │               │        │    SCP senden       │
                                               │ Status: Aktiv │        │    (direkt, nicht   │
                                               └──────────────┘        │    über b.net)      │
                                                                        │                    │
                                                                        │ 4. Status an b.net  │
                                                                        │    API melden       │
                                                                        │    (DB-Log, nur bei │
                                                                        │    Fehler: Alarm)   │
                                                                        └──────────────────┘

---

Abgrenzung

• Wir übertragen keine Apothekendaten. Die Lagerbestände gehen direkt von der Apotheke zu CURE per SCP. b.net ist an diesem Datenfluss nicht beteiligt.
• Wir verwalten nicht die CURE-Plattform. Wir verantworten ausschließlich das Onboarding und Monitoring auf unserer Seite.
• Das Übertragungsskript wurde ursprünglich von Sven Reinhardt entwickelt. b.net übernimmt die Weiterentwicklung, Installation, Überwachung und Update-Verteilung. Geplante Weiterentwicklungen: Optimierung der SCP-Übertragung (PSCP statt WinSCP, SSH-Keys statt Passwort), Anpassung der Statusmeldungen (API statt E-Mail) und Erweiterung um eine Auto-Update-Funktion.

---

Tech-Stack

• Backend: PHP + MySQL
• Frontend: HTML, CSS, JavaScript (über das PHP-Backend ausgeliefert)
• Bestehender Code: api.php von Sven Reinhardt (Registrierung + Lizenzprüfung) — wird in die Webapp integriert
• Infrastruktur: b.net-Server
• Kommunikation: Rocket.Chat (intern), E-Mail (Benachrichtigungen + Fehlerüberwachung)

---

Phasen

Phase	Umfang	Abhängigkeit
Phase 1	Webapp: CURE-Formular, internes Dashboard, Benachrichtigung, Abrechnungsliste, Datenbank	Keine — kann sofort beginnen
Phase 2	API-Integration: Svens api.php erweitern, Lizenzprüfung, HWID-Speicherung	Svens Skript + Abstimmung mit Sven
Phase 3	Auto-Update: Versionsprüfung, Git-basierte Update-Verteilung, CI/CD	Svens Skript im b.net-Git

---

Vergütung (laut Dienstleistungsvertrag)

Leistung	Betrag
Installation (einmalig, pro Apotheke)	80,00 € zzgl. MwSt.
Monitoring (monatlich, pro Apotheke)	30,00 € zzgl. MwSt.