Phase 3 Plan aktualisiert: kein Dolibarr-Sandbox verfuegbar
Kunde hat nur eine produktive Dolibarr-Instanz. Testansatz angepasst: rechtebeschraenkter API-Key, Test ueber Entwurfs-Rechnungen gegen einen dedizierten Test-Kunden statt Sandbox-Vorabtest.
This commit is contained in:
+31
-5
@@ -149,9 +149,29 @@ klicken, wenn `billing_check_tenant()` einen höheren Bedarf anzeigt).
|
||||
|
||||
## Phase 3: Dolibarr-Anbindung (noch offen)
|
||||
|
||||
Wartet auf Zugang zu einer Dolibarr-Sandbox/Testinstanz (bewusst nicht
|
||||
direkt gegen die produktive Instanz des Kunden, um deren bestehende
|
||||
Buchhaltungsdaten nicht zu gefährden). Geplanter Umfang:
|
||||
**Korrektur (2026-07-16):** Der Kunde betreibt nur eine einzige
|
||||
Dolibarr-Instanz, und das ist die produktive für sein anderes Business –
|
||||
keine separate Sandbox verfügbar. Der ursprüngliche Plan „erst gegen
|
||||
Sandbox testen" ist damit hinfällig; stattdessen wird sicher **innerhalb**
|
||||
der einen produktiven Instanz getestet:
|
||||
|
||||
- **Eigener, rechtebeschränkter API-Key**: Der Kunde legt einen
|
||||
dedizierten Dolibarr-Benutzer/API-Key nur mit den für die Integration
|
||||
nötigen Rechten an (Thirdparty + Invoice lesen/erstellen), statt seinen
|
||||
bestehenden Admin-Key zu nutzen. Begrenzt den Schaden, falls der Key
|
||||
je kompromittiert wird.
|
||||
- **Test nur über Entwurfs-Rechnungen (Draft)**: Dolibarr-Rechnungen im
|
||||
Entwurfsstatus haben noch keine fortlaufende, GoBD-relevante
|
||||
Rechnungsnummer und lassen sich rückstandsfrei löschen. Die
|
||||
Integration wird gegen einen eindeutig benannten Test-Kunden
|
||||
(z. B. „TEST – Kaffeeliste Integration") getestet; die dabei erzeugte
|
||||
Entwurfs-Rechnung wird **nicht validiert**, sondern nach Prüfung der
|
||||
Feldinhalte über die API wieder gelöscht.
|
||||
- Erst wenn dieser Test erfolgreich war, wird der Live-Betrieb
|
||||
freigeschaltet (echte Stripe-`invoice.paid`-Events lösen dann echte
|
||||
Rechnungserstellung bei echten Kunden aus).
|
||||
|
||||
Geplanter Umfang der Anbindung selbst bleibt unverändert:
|
||||
|
||||
- Bei jedem erfolgreichen Stripe-Zahlungsereignis (`invoice.paid`) über
|
||||
die Dolibarr-REST-API eine Rechnung im bestehenden Dolibarr des Kunden
|
||||
@@ -159,5 +179,11 @@ Buchhaltungsdaten nicht zu gefährden). Geplanter Umfang:
|
||||
Dolibarr-Kunden).
|
||||
- Stripe bleibt alleiniger Zahlungsweg; Dolibarr wird nur als Buchhaltungs-
|
||||
Spiegel befüllt, nicht selbst zum Auslösen von Zahlungen verwendet.
|
||||
- Erst nach erfolgreichem Test gegen die Sandbox gegen die produktive
|
||||
Dolibarr-Instanz freigeben.
|
||||
|
||||
**Offen, bevor programmiert werden kann:**
|
||||
|
||||
- Dolibarr-Basis-URL und der neue, rechtebeschränkte API-Key.
|
||||
- Dolibarr-Version (API-Feldnamen unterscheiden sich leicht je Version).
|
||||
- Ob pro Kaffeeliste-Tarif ein eigenes Dolibarr-Produkt angelegt wird
|
||||
oder eine einzelne generische Rechnungsposition mit Freitext-
|
||||
Beschreibung + Betrag aus Stripe genügt.
|
||||
|
||||
Reference in New Issue
Block a user