Kundenverwaltung 1.0.25 — Schritt für Schritt

1. Bei einem Update zuerst WordPress-Datenbank und private Schlüssel sichern. ZIP unter Plugins > Installieren > Plugin hochladen auswählen. Die vorhandene Plugin-Version ersetzen; bestehende Kundendaten bleiben erhalten.
2. Kundenverwaltung öffnen. Einstellungen ist der letzte Menüpunkt. Der Einrichtungsassistent erscheint nur während der offenen Ersteinrichtung; Organisationsname und optional eigenes Verwaltungslogo festlegen. Ohne Logo wird die neutrale Wortmarke verwendet. Die weiße Logo-Kachel oben links ist für Administratoren direkt über „Logo ändern“ anklickbar. Dort PNG/JPG/WebP hochladen oder das neutrale Standardlogo wiederherstellen; das Bild wird proportional ohne Beschnitt angezeigt.
3. Geschützten Website-Login prüfen. Kundenzugänge erhalten nur Zugriff auf ihre eigenen freigegebenen Informationen. Kundenlogos sind getrennt im Kundeneditor oder im eigenen Portal unter Einstellungen pflegbar.
4. Zentrale Empfangsadresse eintragen. Dies verbindet noch kein Postfach. Optional Testbeleg importieren und Erkennung/Zuordnung kontrollieren.
5. Zehn Pipeline-Phasen prüfen. Weitere Pipelines später über „Neue Pipeline“ anlegen. Gebuchte Leistungen in der Kundenübersicht auswählen; eigene Leistungsnamen unter Einstellungen > Leistungskatalog hinzufügen. Eigene Kundenstatus unter Einstellungen > Kundenstatus anlegen; anschließend beim Kunden auswählen und im Statusfilter verwenden.
6. OPTIONAL Lexware Office: https://app.lexware.de/addons/public-api öffnen. Eigenen API-Schlüssel mit Leseberechtigung für Kontakte erstellen. Unter Einstellungen > Lexware Office geschützt speichern, Verbindung prüfen, dann automatische Kundenübernahme bewusst einschalten und speichern. Ohne Zugang „Überspringen / weiter“ wählen.
7. OPTIONAL awork: Eigenen API-Schlüssel nach https://support.awork.com/en/articles/client-applications-and-api-keys-7UhbRvR23vP7 erstellen, Berechtigung company-master-data:read. Unter Einstellungen > awork geschützt speichern, prüfen, danach bewusst aktivieren. Ohne Zugang überspringen.
8. OPTIONAL XOVI: „Sichtbarkeit prüfen“ öffnen, eigenen XOVI-Schlüssel im geschützten API-Feld speichern, Domain eingeben und Ranking-Bericht abrufen. Ergebnisse erscheinen direkt in der Verwaltung. Kein automatischer Kundenimport. Ohne Zugang überspringen.
9. Grundsetup abschließen. Dieser Abschluss aktiviert keinen Dienst. Schlüssel gehören ausschließlich in die dafür vorgesehenen Admin-Felder, niemals in Chat oder Anleitung. Leeres Feld behält den bestehenden Schlüssel.

Lexware und awork: Vollabgleich einschließlich bestehender Quellkunden, stündlich. Rückgaben sind separat optional und standardmäßig ausgeschaltet; siehe Rücksynchronisation unten. WordPress-Cron braucht Website-Aufrufe oder einen Server-Zeitplan. Hier lokal ist Cron ausgeschaltet; nach Aktivierung arbeitet „Jetzt synchronisieren“ bei offener Ansicht weiter. Weitere Seiten werden in kleinen Schritten verarbeitet. Bei möglichen Dubletten angezeigte Kunden prüfen und bewusst verknüpfen oder ausdrücklich getrennt anlegen. Lokale Leistungen, Notizen und Pipelines bleiben erhalten. Die erste Quelle führt die gemeinsamen Stammdaten; bei Verknüpfung mit einem lokalen Kunden bleibt lokale Pflege führend.

Auslieferungsstand: Beide Kundenintegrationen ausgeschaltet, keine Schlüssel und keine echten Importdaten im ZIP. XOVI ohne eigenen Zugang ebenfalls ungeprüft. Lokale Tests ersetzen keinen echten Verbindungstest auf dem späteren Hosting. HTTPS und OpenSSL benötigt; Datenbank UND WordPress-Salts sichern. Details, Feldzuordnung, Wiederholungen und sonstige Funktionsgrenzen stehen in readme.txt.

== Testphase und eigene Lizenz ==
Jede Testphase dauert genau 14 Tage ab ihrer ursprünglichen ersten Aktivierung. Ab Version 1.0.23 gilt dies auch für bestehende Testphasen: gespeicherte Enddaten werden auf ursprünglicher Start plus 14 Tage korrigiert. Der Start wird nicht zurückgesetzt. Bereits abgelaufene Testphasen bleiben gesperrt; gültige Lizenzen und Kundendaten bleiben unverändert. Normales Deaktivieren, Reaktivieren und Aktualisieren setzt sie nicht zurück. Oben steht während der Testphase „Testphase · noch N Tage“; Resttage werden aufgerundet aus dem tatsächlichen Ende berechnet. Nach Aktivierung einer gültigen Lizenz verschwinden Restzeit-Anzeige und „Jetzt kaufen“ vollständig.
Unter Einstellungen steht die Website-Bindung und die Eingabe für eine vom Betreiber ausgestellte Lizenz. Prüfung offline mit RSA-SHA256, Produktkennung, exakter Website-Domain einschließlich Port und Ablaufdatum. Nur der öffentliche Prüfschlüssel ist im Plugin. PHP OpenSSL und korrekte Serverzeit sind erforderlich. Beliebige Zeichenfolgen, geänderte Signaturen, andere Domains und abgelaufene Lizenzen werden abgewiesen. Keine automatische Verlängerung, Fernsperrung oder Kaufabwicklung.
Nach Ablauf: vollständige Sperransicht „Testphase abgelaufen“ bzw. „Lizenz abgelaufen“, bei manipuliertem gespeicherten Code „Lizenz ungültig“. Plugin-AJAX einschließlich Kundenportal, Webhooks und Hintergrundabgleiche sind serverseitig gesperrt. Lizenzaktivierung bleibt für berechtigte Administratoren erreichbar, übriges WordPress bleibt nutzbar. Keine Datenlöschung. Neue gültige Aktivierung schaltet wieder frei. Bei bereits offenen Seiten entfernt ein Ablauf-Neuladen die Arbeitsoberfläche; der Server entscheidet unabhängig vom Browser.
Das separat gelieferte lokale Betreiberwerkzeug erzeugt befristete oder unbefristete Lizenzen. Dieses Werkzeug und sein privater Signierschlüssel gehören niemals in das Kundenpaket. Grenzen: kein fernwirksamer Widerruf; Administratoren mit Zugriff auf Code, Datenbank und Sicherungen können eine rein offline geprüfte quelloffene Software verändern. Eine Installation pro Website, keine getrennte Zählung mehrerer Installationen auf demselben Host.

== Rücksynchronisation (optional) ==
Je Dienst in Einstellungen bzw. optionalem Einrichtungsschritt „Lokale Änderungen zurückgeben (Schreibzugriff)“ einschalten. Benötigt aktivierte Übernahme und eigenen Zugang; ein Verbindungstest prüft Leserechte, Schreibrechte werden erst bei einer tatsächlichen Rückgabe bestätigt. Lexware: Kontakte lesen und schreiben; awork: company-master-data:write. Alle Schalter sind zunächst aus. Kein rückwirkender Massenexport beim Einschalten.
Nur neue lokale Änderungen an Unternehmen und E-Mail bereits verknüpfter Kunden erzeugen eine dauerhafte Rückgabe. IDs werden nicht erfunden; niemals POST zur Kontaktanlage oder DELETE. Keine internen Notizen, Ansprechpartnernamen, Leistungen, Pipelines, Status, Zugangsdaten oder Lizenzen in ausgehenden Stammdaten. Originale externe Zusatzfelder bleiben erhalten. Lexware-Firmennamen werden ausschließlich bei Firmenkontakten geändert; Personennamen werden nicht geraten/geteilt. E-Mail nur in einem eindeutig vorhandenen Feld, keine Neuanlage/Entfernung von E-Mail-Kontaktinfos. Mehrfacheinträge und nicht sicher zuordenbare Fälle werden zur Prüfung angehalten.
Vor jedem PUT frischer GET und feldweiser Vergleich von früherem externen Stand, lokalem Wunsch und aktuellem externen Stand. Beidseitige Änderungen werden angehalten. Einstellungen zeigen Werte und Entscheidung: erneut prüfen, nach Prüfung lokalen Stand freigeben oder Rückgabe anhalten. Eine Freigabe prüft beim nächsten Lauf erneut. Ausstehende/angehaltene Felder sind gegen Importüberschreiben geschützt. Nur die feste führende Quelle aktualisiert sonst gemeinsame Stammdaten; eine zweite Quelle kann sie nicht abwechselnd überschreiben. Imports lösen keine Exports aus.
Lexware nutzt dessen aktuelle version für atomaren Versionsschutz; 409/412 werden angehalten. Bei awork ist resourceVersion nur lesbar, kein atomarer If-Match-/Versionsschutz für die verwendeten PUT-Endpunkte dokumentiert. Frischer Abruf, minimale Änderung und anschließender Kontrollabruf begrenzen Konflikte; eine Änderung im schmalen Zeitfenster dazwischen kann nicht zuverlässig verhindert werden. Gemeinsame Felder deshalb möglichst nicht zeitgleich bearbeiten.
Unklare Schreibantworten werden zuerst nachgelesen; bereits übernommene Werte lösen keinen doppelten PUT aus. Rate-Limits und vorübergehende Fehler werden zeitversetzt wiederholt, nach begrenzten Versuchen zur Prüfung angehalten. Erfolg erscheint erst nach Kontrollabruf. Die lokale Speicherung und die Rückgabevormerkung erfolgen gemeinsam in einer Datenbanktransaktion. Auf dem Hosting transaktionsfähige Tabellen (InnoDB) verwenden. Aus-/Einschalten löscht keine Rückgaben; nach erneutem Einschalten werden offene Rückgaben wieder geprüft. Bei Lizenzablauf keine neuen HTTP-Aufrufe oder Änderungen; bereits beim Anbieter angenommene Anfragen sind nicht rückrufbar.
Referenzen: https://developers.lexware.io/docs/#contacts-endpoint ; https://developers.lexware.io/docs/#optimistic-locking ; https://developers.awork.com/companies ; https://developers.awork.com/apiv1/companies/put-company-by-id ; https://developers.awork.com/apiv1/companies/put-company-contact-info-by-company-id-and-contact-info-id

== Sicher speichern und wiederherstellen ==
Kunden, Notizen und Leistungen verwenden Versionsvergleiche. Dienst-Zugänge, API-Einstellungen und Lizenzen weisen veraltete Speicherstände ab. Rollen, Kundenzuordnung und Nonces werden auf dem Server geprüft. Texte werden validiert und bereinigt; Datenbankzugriffe verwenden gebundene Werte. Die Oberfläche gibt Kundentexte als Text aus. API-Schlüssel verschlüsselt mit AES-256-GCM und aus WordPress-Salts abgeleitetem Schlüssel. Vault-Schlüssel separat außerhalb des Webverzeichnisses; Listen geben keine Secrets zurück, ausdrückliches Anzeigen ist nur für Berechtigte möglich. Signierte Lizenzcodes sind keine privaten Signierschlüssel; sie werden lokal zur erneuten Prüfung gespeichert.
Vor Updates vollständige Datenbank, WordPress-Dateien einschließlich wp-config.php/Salts, Uploads und private Vault-Dateien gemeinsam sichern. Sicherungen verschlüsselt und mit eingeschränkten Dateirechten aufbewahren; Wiederherstellung regelmäßig in getrenntem Staging testen. Ohne ursprüngliche Schlüssel/Salts bleiben zugehörige verschlüsselte Secrets unlesbar. Datenrettung nach Lizenzablauf über berechtigte Hosting-/Datenbankverwaltung bleibt möglich, ohne die gesperrte Plugin-Oberfläche freizuschalten.
Frischinstallation enthält leere Kundentabellen, keine Testkonten, keine Beispieldaten, keine aktivierten Verbindungen oder privaten Schlüssel. Die lokale Entwicklungsansicht ist getrennt und darf fiktive Daten enthalten. Geprüft in lokalem WordPress/PHP mit SQLite und simulierten Anbieterantworten; reale Anbieterrechte, reale Synchronisation und MySQL-/MariaDB-Hosting müssen mit den eigenen Zugängen vor Produktivbetrieb geprüft werden.

Ab 1.0.23: Die Ersteinrichtung erscheint nur solange ihr gespeicherter Abschlussstatus offen ist. Beim nächsten Laden öffnet die noch offene Einrichtung automatisch den zuletzt gespeicherten Schritt; einen separaten Menüpunkt gibt es nicht. Einstellungen enthält dauerhaft Lizenz, Integrationen, Kataloge und allgemeine Einstellungen; kein eingebetteter Assistent. Nach Grundsetup abschließen startet die Kundenübersicht.

== Oberfläche und Kaufhinweis (1.0.25) ==
Oben stehen „Zurück zu WordPress“ und „Jetzt kaufen“ als dezente Schaltflächen. Der WordPress-Rücklink steht zusätzlich unten in der Seitenleiste. „Jetzt kaufen“ und die Resttage sind während der Testphase sichtbar. Nach Aktivierung einer gültigen Lizenz verschwinden beide automatisch. In der Sperransicht nach Ablauf bleibt „Jetzt kaufen“ erreichbar. Der Shop folgt später: Ohne Kauflink zeigt der Button nur einen Hinweis und startet keinen Kauf. Ein späterer Kauflink kann über die WordPress-Option smk_license_purchase_url oder den gleichnamigen Filter hinterlegt werden; unterstützt werden HTTP und HTTPS.
Der zusätzliche Organisationsblock, die Arbeitsbereich-Beschriftungen, der Profilname mit Initialen und „Interner Bereich“ sind entfernt. Abmelden bleibt erreichbar. Die Anmeldeseite ist neutral: zentriertes „Willkommen zurück.“, „Melde dich mit deinem Kundenkonto an.“, Anmeldefelder und Passwort-Hilfe, ohne Logo oder Kundenverwaltung-Titel.
„Ersteinrichtung fortsetzen“ ist kein Menüpunkt mehr. Solange die Einrichtung offen ist, öffnet sie sich beim nächsten Laden automatisch am gespeicherten Schritt. Nach Abschluss öffnet sich die Kundenübersicht. Die Einstellungen enthalten keinen eingebetteten Einrichtungsassistenten.


== Datenschutzwerkzeuge (1.0.25) ==
Unter WordPress > Werkzeuge > Personenbezogene Daten exportieren bzw. löschen stehen die Kundenverwaltung-Daten zur Verfügung. Nur berechtigte Administratoren können Anfragen bearbeiten. Identität und Rechte Dritter vor Herausgabe prüfen. Export und Löschung bleiben bei abgelaufener Lizenz verfügbar.
Erfasst werden Datensätze über die Kunden-E-Mail: Stammdaten, zugeordnete Dokumenttexte, Verkaufschancen, Erinnerungen, Tresor-Metadaten, Logos, Synchronisationsaufträge und Social-Nachrichten mit genau übereinstimmender Absender-E-Mail. Passwörter, Verschlüsselungsschlüssel und verschlüsselte Passwortinhalte werden nicht exportiert.
Vor endgültiger Löschung Aufbewahrungspflichten prüfen und awork/Lexware ausschalten. Bei laufender Synchronisation wird zurückgestellt. Dokumente werden bei bestätigter Löschanfrage ebenfalls endgültig entfernt. Früher ausgeblendete Tresor-Einträge werden dabei mit gelöscht. Das Entfernen eines Dienst-Zugangs löscht seinen Datenbankeintrag einschließlich verschlüsseltem Passwort nach Bestätigung.
WordPress-Konten werden nicht automatisch gelöscht; die Kundenzuordnung wird entfernt. Abweichende Konto-Adressen, Erwähnungen in fremden Freitexten, Social-IDs ohne E-Mail, globale Benachrichtigungsadressen, externe Dienste und Backups müssen separat geprüft werden. Externe Synchronisation erst nach dortiger Bereinigung reaktivieren, damit gelöschte Kontakte nicht erneut importiert werden. Dies ist keine DSGVO-Zertifizierung; Rechtsgrundlagen, Aufbewahrung und Hosting sind Betreiberaufgaben.
