Projekt: Automatisierte Unternehmensbewertung & Lead-Generierung v2.2.1

1. Projektübersicht

Dieses Repository enthält eine Suite von Python-Skripten zur automatisierten Anreicherung und Analyse von Unternehmensdaten. Das System ist modular aufgebaut und für den Betrieb in einem Docker-Container ausgelegt.

• brancheneinstufung.py: Das Kernmodul zur Datenanreicherung (Web, Wikipedia, KI-Analyse).
• duplicate_checker.py: Ein Modul zur intelligenten Duplikatsprüfung.
• generate_marketing_text.py: Eine Engine zur Erstellung personalisierter Marketing-Texte.
• app.py & Docker: Eine fernsteuerbare Schnittstelle via Google Sheets.

2. Aktueller Status: KRITISCHER FEHLER (BLOCKER)

Das gesamte System ist derzeit nicht lauffähig. Ein Inkompatibilitätsproblem zwischen dem bestehenden Code und der installierten Version der openai-Python-Bibliothek führt zu einem ModuleNotFoundError bei jedem Versuch, eine KI-Funktion aufzurufen. Dies verhindert jegliche Weiterentwicklung und Nutzung.

3. Nächster Schritt

Priorität 1: Behebung des openai-Abhängigkeitskonflikts. Die gewählte Strategie ist ein gezieltes Downgrade der openai-Bibliothek auf eine mit dem Code kompatible Version, um die Funktionalität schnellstmöglich wiederherzustellen. planning.md (v2.2.1) code Markdown

Projektplanung v2.2.1

1. Aktueller Stand

• [X] Architektur & Module: Alle Kernmodule sind konzipiert und implementiert.
• [!] System-Blocker: Ein Versionskonflikt der openai-Bibliothek legt das gesamte System lahm. Alle Funktionen, die auf die KI zugreifen, stürzen mit einem ModuleNotFoundError ab.

2. Strategischer Plan

Phase 1: Stabilität wiederherstellen (Hotfix)

• [ ] Schritt 1.1 (Analyse): Überprüfung aller Code-Stellen, die openai-Fehlerklassen importieren oder verwenden, um den Umfang des Problems zu bestätigen.
• [ ] Schritt 1.2 (Downgrade): Modifikation der requirements.txt, um die openai-Bibliothek auf eine stabile, kompatible Version (z.B. 0.28.0) festzuschreiben.
• [ ] Schritt 1.3 (Anwendung): Neubau des Docker-Images (docker build), um die Installation der korrekten Bibliotheksversion zu erzwingen.
• [ ] Schritt 1.4 (Validierung): Durchführung eines Testlaufs (z.B. reclassify_branches), um zu bestätigen, dass der ModuleNotFoundError behoben ist und die KI-Aufrufe wieder funktionieren.

Phase 2: Geplante Weiterentwicklung (nach Hotfix)

• [ ] Finalisierung des Duplikats-Checks.
• [ ] Vervollständigung der Wissensbasis und Generierung aller Marketing-Texte.
• [ ] (Zukünftig) Planung des Code-Refactorings, um die neue openai v1.x API zu unterstützen.

Automatisierte Unternehmensbewertung & Lead-Generierung

Version: 2.1.0 (nach Implementierung des Sync-Moduls)

Projektbeschreibung

Dieses Projekt automatisiert die Anreicherung von Unternehmensdaten aus einem D365-CRM-System. Es nutzt externe APIs (Google, Wikipedia, OpenAI) und Web-Scraping, um Stammdaten zu validieren, zu ergänzen und neue, marketing-relevante Informationen (z.B. FSM-Pitches) zu generieren. Die Verarbeitung und Speicherung der angereicherten Daten erfolgt in einem Google Sheet.

Aktueller Status (August 2025)

• Systemstabilität: Das System ist nach der Behebung von Inkompatibilitäten mit der OpenAI-Bibliothek stabil und voll lauffähig.
• Daten-Import: Ein robuster, intelligenter Synchronisations-Mechanismus (sync_manager.py) wurde implementiert. Er gleicht einen vollständigen D365-Excel-Export mit dem Google Sheet ab, aktualisiert Stammdaten nach definierten Fachregeln und markiert Datensätze für die Neu-Anreicherung.
• Kernfunktionen: Datenanreicherung (Wikipedia, Website-Scraping) und KI-basierte Analysen (Brancheneinstufung, Text-Zusammenfassungen) sind operational.
• Nächster Schritt: Implementierung des Daten-Exports aus dem Google Sheet zur Aktualisierung des D365-Systems.

Duplicate Checker (duplicate_checker_old.py)

Hauptfunktion

Das Skript duplicate_checker_old.py (Version 2.15) ist ein spezialisiertes Werkzeug zur Identifizierung von potenziellen Duplikaten zwischen zwei Unternehmenslisten in Google Sheets: einer Matching-Liste (Matching_Accounts) und einer Referenz-CRM-Liste (CRM_Accounts). Es verwendet einen gewichteten, heuristischen Algorithmus, um für jeden Eintrag in der Matching-Liste den wahrscheinlichsten Treffer im CRM-Bestand zu finden und bewertet diesen mit einem numerischen Score.

Abhängigkeiten

• pandas: Zur Datenmanipulation und -analyse.
• thefuzz: Für Fuzzy-String-Vergleiche zur Bewertung der Namensähnlichkeit.
• gspread, oauth2client: Für die Interaktion mit der Google Sheets API.
• Lokale Module:
  • helpers.py: Stellt Normalisierungsfunktionen (normalize_company_name, simple_normalize_url) und eine optionale Web-Suche (serp_website_lookup) bereit.
  • config.py: Zentralisiert Konfigurationswerte und API-Schlüssel.
  • google_sheet_handler.py: Kapselt die Logik für den Zugriff auf Google Sheets.

Konfiguration

Die Logik des Skripts wird durch mehrere Konstanten am Anfang der Datei gesteuert:

• Sheet-Namen: CRM_SHEET_NAME und MATCHING_SHEET_NAME.
• Score-Schwellenwerte: SCORE_THRESHOLD (Standard: 80) und SCORE_THRESHOLD_WEAK (95), ein strengerer Wert für Treffer ohne starke Indikatoren wie Domain- oder Standortübereinstimmung.
• Penalties: CITY_MISMATCH_PENALTY (30) und COUNTRY_MISMATCH_PENALTY (40) werden vom Score abgezogen, wenn Standorte voneinander abweichen.
• Prefiltering: PREFILTER_MIN_PARTIAL (70) und PREFILTER_LIMIT (30) zur Vorauswahl potenzieller Kandidaten, um die Performance zu verbessern.
• Stop-Wörter: STOP_TOKENS_BASE und CITY_TOKENS (dynamisch generiert) enthalten Begriffe, die bei Namensvergleichen ignoriert werden, um die Signalqualität zu erhöhen.

Ablauf-Logik

1. Initialisierung: Das Skript richtet das Logging ein, lädt API-Schlüssel (optional für SerpAPI) und initialisiert den GoogleSheetHandler.
2. Daten laden: Die Daten aus den beiden Google Sheets (CRM_Accounts und Matching_Accounts) werden in Pandas DataFrames geladen.
3. SerpAPI-Fallback (Optional): Für Einträge in der Matching-Liste ohne Website wird versucht, über die SerpAPI eine URL zu finden. Das Vertrauen in die gefundene URL wird bewertet (hoch, mittel, niedrig).
4. Normalisierung: Unternehmensnamen, Domains, Orte und Länder in beiden DataFrames werden standardisiert (z.B. Kleinschreibung, Entfernung von Rechtsformzusätzen).
5. Index-Erstellung: Zur Optimierung der Suche werden mehrere "Blocking"-Indizes aus den CRM-Daten erstellt:
   • Ein domain_index für schnelle Suchen über die Website-Domain.
   • Ein token_index für die Suche nach einzelnen Namensbestandteilen.
   • Eine token_freq Zählung, um seltene und damit aussagekräftige Namensbestandteile zu identifizieren.
6. Iteratives Matching: Das Skript durchläuft jeden Datensatz der Matching-Liste: a. Kandidatenauswahl: Anstatt jeden Eintrag mit der gesamten CRM-Liste zu vergleichen, wird eine kleine, relevante Untergruppe von Kandidaten ausgewählt. Die Auswahl erfolgt priorisiert: zuerst über Domain-Übereinstimmung, dann über den seltensten Namens-Token und zuletzt über einen allgemeinen Prefilter. b. Scoring: Jeder Kandidat wird mit dem aktuellen Matching-Datensatz verglichen. Die Funktion calculate_similarity berechnet einen Score basierend auf einer gewichteten Formel, die Namensähnlichkeit, Domain-Match, Standortübereinstimmung, Boni und Strafen berücksichtigt. c. Bester Treffer: Der Kandidat mit dem höchsten Score wird als potenzielles Duplikat ausgewählt.
7. Ergebnis-Aggregation: Die Ergebnisse (bester Treffer, Score, Begründung der Bewertung) werden gesammelt.
8. Daten zurückschreiben: Die Matching-Liste wird um die Ergebnisspalten (Match, Score, Match_Grund) erweitert und vollständig in das Google Sheet Matching_Accounts zurückgeschrieben. Ein lokales CSV-Backup wird ebenfalls erstellt.