=== Kundenverwaltung ===
Tags: crm, customers, internal
Requires at least: 6.6
Requires PHP: 8.1
Stable tag: 1.0.30
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Kundenverwaltung, Pipeline, Dokumentenprüfung und geschützter Kundenbereich.

== Installation ==
1. ZIP in WordPress unter Plugins > Plugin hochladen installieren und aktivieren.
2. Menü Kundenverwaltung oder /?smk_customers=1 öffnen. Administratoren erhalten manage_smk_customers.
3. Einrichtungsassistent durchlaufen. Vor neuer Kundenanlage eine gültige zentrale Empfangsadresse speichern.
4. Optional [smk_kunden_login] auf einer Website-Seite einfügen. Gemeinsame WordPress-Anmeldung leitet Administratoren zur Verwaltung und freigeschaltete Kunden zum eigenen Portal.
5. Kunde anlegen, speichern, anschließend im selben Editor Kundenkonto/Passwort und optional Kundenlogo einrichten. Es werden keine Einladungen automatisch versendet.

== Funktionen ==
Kundenübersicht, Suche, Filter, Anlage und Bearbeitung mit Schutz vor veralteten Änderungen.
Mehrere Verkaufschancen pro Kunde, zehn umbenennbare Pipeline-Phasen.
Dokumentimport: PDF mit Textschicht, EML-Text und TXT. Regelbasierte Erkennung von Rechnung, Mahnung, Bericht und Sonstigem; Vorschläge für Kunde, Referenz, EUR-Betrag und Fälligkeit. Dublettenerkennung und manuelle Korrektur.
Kunden sehen ausschließlich eigene Dokument-Metadaten, die intern geprüft UND ausdrücklich freigegeben wurden. Originaldateien werden nicht gespeichert; daher keine Downloads.
Kundenkonten verwenden native WordPress-Passworthashes und eine eigene eingeschränkte Rolle.
Private Kundenlogos: PNG/JPEG/WebP, maximal 2 MB und 4000 x 4000 Pixel. Kein SVG. Authentifizierte Auslieferung außerhalb der öffentlichen Mediathek.
Dienst-Zugänge: Bezeichnung, Login-URL, Benutzername und verschlüsseltes Secret. Passwortanzeige nur auf gezielten Klick, nach 30 Sekunden verborgen. Entfernung sperrt weiteren Abruf; Datenbankzeile wird als entfernt markiert.
Administrationslogo direkt über die weiße Menü-Kachel „Logo ändern“ oder im Assistenten anpassbar (nur Administratoren); dieses Logo wird auch öffentlich auf der Anmeldung angezeigt.

== Zugangsdaten-Speicher ==
HTTPS und OpenSSL mit AES-256-GCM erforderlich. 32-Byte-Schlüssel in separater Datei außerhalb des WordPress-Verzeichnisses und der Datenbank; Datei 0600, Verzeichnis 0700.
Der Assistent versucht das private Verzeichnis neben WordPress anzulegen. Bei Hosting-Einschränkungen kann die Administration in wp-config.php SMK_VAULT_DIRECTORY auf ein privates, beschreibbares Verzeichnis außerhalb von WordPress UND außerhalb aller öffentlich erreichbaren Webverzeichnisse setzen. Der Hosting-Betreiber muss die fehlende HTTP-Erreichbarkeit dieses Verzeichnisses gewährleisten.
Schlüssel separat und sicher sichern. Datenbank und Schlüssel nur gemeinsam wiederherstellbar. Fehlende Schlüssel werden nicht automatisch ersetzt. Kein Klartext-Fallback.
SMK_CUSTOMERS_LOCAL_PREVIEW ist ausschließlich für eine lokale Loopback-Testumgebung vorgesehen; im Hosting nicht aktivieren.

== Grenzen und Betrieb ==
Das Speichern der zentralen E-Mail-Adresse verbindet kein Postfach. Automatischer Mailabruf und OCR für Bild-/Scan-PDFs sind nicht implementiert. EML-Anhänge separat importieren. Erkennungsvorschläge immer prüfen.
Keine produktiven Kundendaten, Benutzerkonten, Passwörter oder Schlüssel im ZIP. Keine echten Zugangsdaten oder Quellimporte im Auslieferungszustand.
Kein externer Sicherheits-Audit. Vor Produktiveinsatz Hosting-Berechtigungen, HTTPS, Backups und vollständigen Workflow auf Staging prüfen. Caches müssen geschützte Ansichten und AJAX-Endpunkte ausnehmen.
Lokal geprüft mit WordPress 6.8.3, PHP 8.3.33 und SQLite in WordPress Playground. MySQL/MariaDB-Hosting wurde noch nicht separat geprüft.
Deaktivierung bewahrt Daten; keine automatische Löschung bei Deinstallation implementiert.

== Gestaltung / Quellen ==
Neutrales Standardlogo. Ein eigenes Verwaltungslogo ist optional; Kundenlogos bleiben separat und geschützt.
React, Lucide und PDF.js: Lizenzdateien und BUILD.txt im assets-Verzeichnis.

Kontaktquelle ist in Liste und Editor ausgeblendet. Vorhandene Quellangaben und externe Kennungen bleiben in Bestandsdatensätzen erhalten.

Pipeline direkt im gespeicherten Kundeneditor: erste Verkaufschance mit Phase anlegen, bestehende Chancen umstufen und zugehörige Pipeline öffnen.

Pipeline-Karten mit der Maus zwischen Phasen ziehen. Zielspalte wird hervorgehoben; Speicherung verwendet dieselbe Versionsprüfung wie die Stufenauswahl. Bei Fehler bleibt die bisherige Phase erhalten.

Verkaufschancen: Nächster Schritt (500 Zeichen) und Nächster Termin mit optionaler Uhrzeit. Lokale Terminangaben in der konfigurierten Zeitzone; leere Bestandswerte bleiben leer.

== Terminerinnerungen und Pipeline-Summen ==
Hinweis in der internen Verwaltung ab 30 Minuten vor Termin, Aktualisierung bei geöffneter Seite alle 60 Sekunden; Anzeige bis 24 Stunden nach Termin. Nur mit Datum UND Uhrzeit. Zeitzone zunächst Europe/Berlin. Termine an einer nicht existierenden Sommerzeit-Uhrzeit werden abgewiesen; doppelte Herbst-Uhrzeiten folgen der PHP-Zeitzonenauflösung.
Kein voreingestellter E-Mail-Empfänger. Unter Pipeline > Erinnerungen änderbar, leeres Feld deaktiviert E-Mail. Niemals automatische Verwendung einer Kundenadresse.
WordPress-Cron prüft jede Minute. Ohne echten serverseitigen Minutenaufruf hängt die Ausführung von Website-Aufrufen ab. In der lokalen Vorschau ist WP-Cron deaktiviert und echter E-Mail-Versand zusätzlich ausdrücklich unterdrückt. Kein Versand ohne laufenden Server. Für produktiven Betrieb: Hosting-Zeitgeber jede Minute wp-cron.php oder WP-CLI cron event run --due-now ausführen lassen; zuverlässigen WordPress-Mailtransport einrichten. Wurde der Terminbeginn bereits verpasst, wird keine verspätete Vorab-Mail gesendet; Hinweis bleibt sichtbar.
Ein eindeutiger Schlüssel aus Verkaufschance, Termin und Zeitzone verhindert wiederholte Übergaben. Geänderte/entfernte Termine werden vor Versand erneut geprüft. Fehlgeschlagene, unterbrochene oder unklare Übergaben werden nicht automatisch wiederholt, um doppelte Nachrichten zu vermeiden. Eine erfolgreiche wp_mail-Rückgabe ist nur Mailübergabe, kein Zustellnachweis. Kein externer Kalendertermin wird angelegt.
Gewonnen/Verloren summieren die jeweiligen Dealwerte in EUR für die ausgewählte Pipeline. Leere Werte werden separat gezählt und nicht in den Betrag eingerechnet. Summen aktualisieren sich nach erfolgreicher Änderung; Beträge werden in Cent addiert.

Ringgrafiken zeigen den jeweiligen Anteil an gewonnenen und verlorenen Dealwerten, passend zur ausgewählten Pipeline. Keine historischen Trenddaten werden dargestellt.

== Optionale Kundenübernahme: Lexware Office und awork (1.0.18) ==
Beide Dienste getrennt unter Einstellungen einrichten; standardmäßig AUS. Kein vorhandener Connector und keine fremde Schlüsseldatei wird übernommen. Der Assistent enthält überspringbare Schritte 6, 7 und 8 (XOVI); Abschluss ist Schritt 9. Alle Grundfunktionen sind ohne API-Zugang nutzbar.

Lexware: Schlüssel unter https://app.lexware.de/addons/public-api erstellen, Leseberechtigung für Kontakte wählen. Nur Kundenrollen werden übernommen, auch Kontakte mit zusätzlicher Lieferantenrolle und archivierte Kunden. Keine bloßen Lieferanten, keine Rechnungsintegration.
awork: eigenen API-Zugang laut https://support.awork.com/en/articles/client-applications-and-api-keys-7UhbRvR23vP7 erstellen; company-master-data:read benötigt. Nur Companies (Kunden), keine Projekte/Benutzer. Dieser neue Vollabgleich umfasst auch den Altbestand; frühere Importbeginn-Beschränkung entfällt. Ein altes Datei-Token wird nicht automatisch verwendet.

Für jeden Dienst: Schlüssel im eigenen passwortmaskierten Admin-Feld speichern, zunächst Schalter AUS lassen. Verbindung prüfen. Erst danach automatische Kundenübernahme bewusst einschalten und speichern. Aktivierung prüft den Zugang erneut; der erste Import wird eingeplant. Alternativ nach Aktivierung „Jetzt synchronisieren“ wählen und die Ansicht bis zum Abschluss offen lassen. Leeres Schlüsselfeld erhält den gespeicherten Schlüssel. Ein neuer Schlüssel ersetzt ihn und beendet einen alten Lauf.
Schlüssel AES-256-GCM-verschlüsselt in nicht automatisch geladenen WordPress-Optionen; getrennte Schlüsselableitung je Dienst aus wp_salt(auth), Kontext an Website-ID gebunden. HTTPS nötig, außer ausdrücklich erlaubter lokaler Loopback-Vorschau. Keine Klartextantwort, keine Schlüssel- oder Antwort-Logs. WordPress-Salts sicher zusammen mit Datenbank sichern: bei Änderung müssen Zugänge neu eingerichtet oder ursprüngliche Salts wiederhergestellt werden.

Automatik für BEIDE Dienste: stündlicher vollständiger Abgleich über WP-Cron. Pro Arbeitsschritt eine Seite (Lexware 250 / awork 100), weitere Seiten frühestens nach 10 Sekunden. Große Bestände und Cron-Latenz verlängern einen Lauf. WordPress-Aufrufe treiben Cron an; zuverlässiger Betrieb benötigt einen Server-Zeitplan, z.B. minütlich WP-Cron ausführen. Bei DISABLE_WP_CRON ohne Server-Zeitplan läuft keine Automatik. Die manuelle Ansicht setzt einen gestarteten Lauf über Folgeschritte fort, solange sie geöffnet bleibt.
Für den Import nur feste HTTPS-GET-Endpunkte mit Zertifikatsprüfung, ohne Weiterleitung. Mindestens zwei Sekunden zwischen Dienstanfragen. 429/5xx/Netzfehler führen zu dauerhaft gespeicherter Wartezeit und bis zu fünf Wiederholungen mit exponentieller Pause; Retry-After und awork RateLimit-Reset werden berücksichtigt. Danach bleibt der Lauf als unvollständig gemeldet; die stündliche Prüfung kann neu beginnen. 401/403 schaltet den Dienst aus. Gemeinsame atomare Sperre verhindert parallele Importe beider Quellen; abgestürzte Sperren verfallen nach fünf Minuten.

Zuordnung: Lexware organizationId+contactId bzw. awork company id sind eindeutig gespeichert. Wiederholte Läufe aktualisieren denselben Datensatz. Identischer Firmenname (ohne äußere Leerzeichen, Groß-/Kleinschreibung ignoriert) ODER identische E-Mail führt bei noch fehlender Quell-ID zu einem angehaltenen Konflikt. Alle Kandidaten werden angezeigt; Admin verknüpft ausdrücklich oder bestätigt „Andere Firma: separat anlegen“. Keine automatische Zusammenführung. Abweichende Namen ohne gemeinsame E-Mail sind nicht zuverlässig erkennbar und können getrennt erscheinen.
Die erste importierende Quelle führt Unternehmen und E-Mail; Lexware zusätzlich Kontaktname. Die zweite ausdrücklich verknüpfte Quelle aktualisiert nur ihren getrennten Datenstand. Bei Verknüpfung mit einem lokal angelegten Kunden bleiben die lokalen Stammdaten führend. Die Quelle ist in der Kundenübersicht sichtbar. Lokal geänderte quellgeführte Felder können beim nächsten Abgleich wieder aus ihrer Quelle aktualisiert werden.
Leistungen, interne Notizen, Kundenstatus, Leadquelle, Zugänge, Logos und Pipelinezuordnungen bleiben erhalten. Fehlende/archivierte Quellkunden führen niemals zu lokaler Löschung. Zusätzliche Quelladressen/Telefonangaben werden getrennt gespeichert; es wird keine zusätzliche Adresseingabemaske erzeugt. awork-E-Mail wird nur bei genau einer eindeutigen Adresse übernommen; kein erfundener Ansprechpartner. Ungültige Datensätze/Feldüberlängen stoppen den Lauf mit Hinweis, statt still Informationen abzuschneiden.
Neue Kunden erhalten keine gebuchte Leistung. Keine automatischen Konten, Mails, Rechnungen oder Deals.
Offizielle Referenzen, geprüft 07.10.2026: https://developers.lexware.io/docs/#contacts-endpoint ; https://developers.awork.com/apiv1/companies/get-companies ; https://developers.awork.com/pagination ; https://developers.awork.com/rate-limits
Isolierte HTTP-Mocktests bestanden; kein echter Schlüssel hinterlegt und kein Liveabgleich nachgewiesen.

== Social Media und Benachrichtigungen (1.0.10) ==
Eigener Menüpunkt, gemeinsamer Posteingang, In-App-Hinweis auf allen internen Ansichten, konsistenter Ungelesen-Zähler und gemeinsamer Team-Lesestatus beim ausdrücklichen Öffnen einer Nachricht. Prüfung bei geöffneter Oberfläche alle 15 Sekunden; keine System-/Browser-Push-Erlaubnis nötig. Ältere Nachrichten seitenweise ladbar. Duplikatschutz pro Kanal und SHA-256 des originalen Provider-Nachrichten-Identifiers.
Optionale interne E-Mail ohne voreingestellten Empfänger; in Social Media > Benachrichtigungen änderbar/deaktivierbar. Neue Nachrichten erzeugen genau einen Warteschlangeneintrag. WordPress-Cron übergibt bis zu 20 Hinweise je Lauf an wp_mail; atomarer Status verhindert Doppelversand. Kein Nachrichteninhalt in der Hinweis-E-Mail, nur Link zum geschützten Bereich. handed_off ist nur Transportübergabe, keine bestätigte Zustellung; failed/sending/uncertain werden nicht blind wiederholt. Hosting muss Cron und Mailtransport sicherstellen. LOCAL_PREVIEW unterdrückt echten Mailversand. Keine Antworten an Kunden.

Meta-Empfang (Instagram, Facebook Messenger, WhatsApp): signaturgeprüfter receive-only Webhook-Adapter für Text, Nachrichten-ID, Absenderkennung und Zeit. Medien erscheinen als Hinweis; keine Downloads. Echo-Nachrichten werden ignoriert. Kein OAuth- oder Konto-Zugang im Paket, keine öffentliche Verbindung aktiv. Lokale Testfixtures wurden nach Prüfung entfernt.
Spätere technische Einrichtung, aktuell NICHT durchgeführt:
- Eigene Meta-App/Business-Assets und nötige Messaging-Freigaben autorisieren. Instagram Professional, Facebook-Seite bzw. WhatsApp Business Platform/WABA/Telefonnummer, keine privaten Browser-Session-Verknüpfungen.
- Private JSON-Datei außerhalb aller öffentlichen Verzeichnisse, 0600, Verzeichnis 0700. In wp-config.php nur Pfadkonstante SMK_SOCIAL_META_CONFIG_FILE hinterlegen. Struktur: enabled (bool), channels (Objekt; Schlüssel: selbst generierte Kanal-UUID); pro Kanal enabled, platform (instagram/facebook/whatsapp), account_id (IG-ID/Seiten-ID/WhatsApp phone_number_id), label, app_secret und verify_token. App Secret und Verify Token nie im Chat oder Plugin hinterlegen. Keine wiederverwendeten IDs beim Kontowechsel.
- Pro Kanal HTTPS-Callback /wp-json/smk/v1/social/meta/KANAL-UUID. Nur bei externer Konfiguration enabled=true, HTTPS und ausgeschaltetem lokalen Vorschaumodus nimmt er Ereignisse an. GET-Prüfung hub.mode, hub.verify_token, hub.challenge. POST X-Hub-Signature-256 HMAC-SHA256 über exakten Rohbody; Grenze 1 MiB; feste Konto-ID-Zuordnung. Keine Tokens oder Rohpayloads protokollieren. Hosting muss Verify-Token aus URL-Zugriffslogs ausblenden. Proxy muss HTTPS korrekt an WordPress melden.
- Webhook-Subscriptions, App-Review/Advanced Access je Kontosituation und ein kontrollierter echter Eingangs-/Mailtest sind noch offen. Funktionstests hier sind lokal/simuliert, kein Nachweis einer Meta-App-Freigabe.
- LinkedIn: Messages-API nur für genehmigte Partner, kein normaler frei verfügbarer privater Inbox-Zugang; Adapter bleibt aus.
- TikTok: Business Messaging API für autorisierte Business Accounts existiert; App-Zugang, Kontoeignung, regionale Verfügbarkeit und konkrete freigegebene Payloads müssen geprüft werden. Kein aktiver TikTok-Empfangsadapter.

Offizielle Quellen, geprüft 06.10.2026:
Instagram: https://www.postman.com/meta/instagram/folder/1z5vxzu/instagram-api-with-instagram-login
Messenger: https://www.postman.com/meta/messenger-platform-api/documentation/iyp204x/messenger-platform-api
WhatsApp: https://www.postman.com/meta/whatsapp-business-platform/folder/tduohwq/webhook-payload-reference
WhatsApp Felder: https://www.postman.com/meta/whatsapp-business-platform/folder/1dtuocp/messages-object
LinkedIn: https://learn.microsoft.com/en-us/linkedin/shared/integrations/communications/messages
TikTok: https://business-api.tiktok.com/portal/bm-api/education-hub

== Änderungen 1.0.11 ==
Kundenportal: Übersicht, Dokumente, Rechnungen, Berichte, Dienst-Zugänge und Einstellungen (Firmenlogo). Einstellungen zuletzt. Freigaben bleiben unverändert.
Pipeline: zehn Phasen nach der vereinbarten Vorlage. Alte Kennungen bleiben erhalten; frühere Namen werden in smk_pipeline_stages_before_v2 gesichert. Pro Phase Summen der gefilterten Deal-Werte, kompakte Karten, sechs vollständige Spalten ab 1000 Pixel Fensterbreite und einzeilige gleich hohe Kopfbereiche. Weitere Phasen horizontal erreichbar, mobile Spalten bleiben lesbar.
Sichtbarkeit prüfen: interner XOVI-Abruf für Google Deutschland, direkte Ranking-Tabelle mit Positionen, Suchvolumen und Zielseiten. Kein Mail-/SMS-Versand, keine automatische Kundenfreigabe. Echter XOVI-API-Zugang erforderlich. Weitere Ergebnisse seitenweise laden; Kennzahlen beziehen sich auf geladene Ergebnisse.
API-Einstellung: nur Administratoren können Schlüssel speichern. AES-256-GCM-verschlüsselte Datenbankoption mit aus WordPress-Authentifizierungsschlüsseln abgeleitetem Schlüssel. Keine Klartext-Rückgabe; leere Eingaben erhalten den bestehenden Zugang. HTTPS und OpenSSL erforderlich. Bei Migration/Backup ursprüngliche WordPress-Schlüssel und Datenbank gemeinsam sichern. Speichern bedeutet keine bestätigte Provider-Verbindung.
Ein fest gesetztes SMK_AUDIT_XOVI_KEY hat Vorrang. Danach eigener verschlüsselter Eintrag, danach vorhandene smk_audit_config()-Anbindung. Keine Zugangsdaten im ZIP.
Keine öffentliche Installation oder Anbindung mit diesem Paket vorgenommen. Echte Provider-Verbindungen bleiben separat einzurichten. XOVI-Liveabruf bislang nicht mit echtem Schlüssel geprüft.

== Änderungen 1.0.12 ==
Mehrere benannte Pipelines: Auswahl und Neuanlage im Adminbereich, auch im Kundeneditor. Neue Pipelines starten leer mit zehn Phasen. Bestehende Vorgänge werden über pipeline_id=1 verlustfrei der ersten Pipeline „Vertrieb“ zugeordnet. Phasenbezeichnungen werden pro Pipeline gespeichert. Karten, Wechsel und Summen sind auf die ausgewählte Pipeline begrenzt. Keine Lösch-/Verschiebefunktion zwischen Pipelines; vorhandene Vorgänge bleiben zugeordnet.
Gebuchte Leistungen: Mehrfachauswahl direkt in der Kundenübersicht, bestehender Katalog SEO & Content, Google Ads, Webdesign, Local SEO, Sonstiges. Vorhandene Einzelwerte bleiben als Auswahl sichtbar. Leere Auswahl möglich; keine Buchungen automatisch ergänzt. Leistungsfilter berücksichtigt alle ausgewählten Leistungen. Änderungen mit Versionsprüfung gegen Überschreiben paralleler Bearbeitung.
Die bisherige einzelne Leistung im Kundeneditor ist die erste Auswahl; Änderung ersetzt diese erste Leistung und erhält zusätzliche Auswahlen. Keine Bestellung, Rechnung oder Nachricht ausgelöst.
Migration und Rechte, zwei getrennte Pipelines mit Karten/Summen, Neuanlage, kundenbezogene Mehrfachauswahl und Neuladen geprüft. Installierbarkeit des tatsächlichen ZIP separat getestet. Paket enthält keine API-Schlüssel, Benutzer-/Testdaten oder lokale Datenbank.

== Mehrere Pipelines und Leistungen (1.0.18) ==
Bestehende Chancen und zehn Phasen bleiben in der ersten Pipeline „Vertrieb“. Weitere benannte Pipelines sind getrennt auswählbar, mit eigenen Karten, Phasenbezeichnungen und Summen. Desktop zeigt sechs kompakte Spalten; weitere Phasen sind horizontal erreichbar.
In der Kundenübersicht mehrere gebuchte Leistungen auswählen und speichern. Einstellungen > Leistungskatalog ergänzt eigene Namen ohne bestehende Zuordnungen zu entfernen. Neue Katalognamen stehen unmittelbar zur Auswahl. Neue Kunden starten ohne automatisch gebuchte Leistung.
Einstellungen steht im Verwaltungsmenü als letzter, unten abgesetzter Eintrag; auch das Kundenmenü behält Einstellungen am Ende.

Der allgemeine Kundenfilter entfällt aus der Pipeline-Ansicht. Alle Karten der ausgewählten Pipeline bleiben sichtbar; die Kundenzuordnung an Karten bleibt erhalten.

== Eigene Kundenstatus (1.0.18) ==
Unter Einstellungen > Kundenstatus eigene Namen mit bis zu 24 Zeichen hinzufügen. Aktiv, Onboarding und Pausiert bleiben erhalten. Neue Namen stehen beim Kunden und in den Statusfiltern zur Auswahl. Es werden keine Kunden automatisch umgestellt. Leere, doppelte und reservierte Namen werden abgewiesen; es gibt keine Löschfunktion.

== Interne Kundennotizen (1.0.18) ==
Kontaktquelle wird in der Kundenübersicht und im Editor nicht mehr angezeigt; gespeicherte Angaben und Importkennungen bleiben erhalten. Interne Notizen sind direkt in der Übersicht über „Notizen öffnen“ erreichbar, mehrzeilig bearbeitbar und bis 12.000 Zeichen speicherbar. Bestehende Notizen werden unverändert wiederverwendet. Keine Freigabe im Kundenportal.

== 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.

== Kundendaten-Anleitung (1.0.30) ==
Popup mit acht Schritten über „Schritt-für-Schritt-Anleitung“ in der Kundenübersicht und „Hilfe zu Kundendaten“ im Editor. Navigation vor/zurück und direkte Schrittwahl, per Escape oder Schließen beendbar. Die Hilfe verändert oder speichert keine Kundendaten. E-Mail-Felder und Social-Media-Benachrichtigungen werden erklärt; noch fehlende Konto- und Postfachverbindungen sind ausdrücklich gekennzeichnet.

E-Mail-Anleitung: Anbieter-Postfach, zentrale Empfangsadresse, Kundenkontakt, Social-Media-Hinweise und Pipeline-Erinnerungen mit Feldnamen und Speicheraktionen.

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.30) ==
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.30) ==
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.

== Sprachauswahl (1.0.30) ==
Lokale Oberflaechentexte in Deutsch, Englisch, Spanisch, Franzoesisch, vereinfachtem Chinesisch, Portugiesisch, Arabisch, Hindi, Russisch und Italienisch. Landesflaggen in der Auswahl; Deutsch heisst German. Arabisch verwendet Rechts-nach-links-Darstellung. Umschalter ganz rechts oben und unter Einstellungen. Sprache wird nur in diesem Browser gespeichert; kein externer Uebersetzungsdienst. Eigene Inhalte, Katalogbezeichnungen und dynamische Servermeldungen bleiben in ihrer Originalsprache. Offene Formulare bleiben beim Sprachwechsel erhalten.
