3. ‼️ Benötigte Daten vor dem Import der Szenarien (Credential) und ein Gesamtüberblick ‼️

3. ‼️ Benötigte Daten vor dem Import der Szenarien (Credential) und ein Gesamtüberblick ‼️

Warning
Folgende Daten werden vor dem Import der Szenarien benötigt:

1. Professional Works 

Benutzername
Passwort

2. NETZWERKZEUG

Domain NETZWERKZEUG-Portal
Benutzername (nicht E-Mail-Adresse)
Passwort
Warning
API-Key (über Formular)

3. Google Sheet

Zugriff auf das Google Drive Konto mit diesen beiden Sheets :
    1. mapping_insurance_pw_nwzVorlage.xlsx
    2. PW-IDInitial-ExportVorlage.xlsx

NotesZum besseren Verständnis

Verbindungen je Szenario

Diese Übersicht zeigt, in welchem Szenario welche Verbindung (Credential) hinterlegt werden muss und in welchem Modul. Die Modulnummern sind fester Bestandteil des Blueprints und bei jedem Anwender identisch, solange derselbe Blueprint importiert wird. Es ändern sich nur die Szenario-ID sowie die Verbindungs- und DataStore-IDs.

Diese Übersicht zeigt, in welchem Szenario welche Verbindung (Credential) hinterlegt werden muss und in welchem Modul. Die Modulnummern sind fester Bestandteil des Blueprints und bei jedem Anwender identisch, solange derselbe Blueprint importiert wird. Es ändern sich nur die Szenario-ID sowie die Verbindungs- und DataStore-IDs.

CredentialSzenarioModul im Szenario
PW1.0 Main1 (getClients), 9 (vertraege)
2.0 Contact1 (GetClient)
3.0.1 Insurance2 (GetContract)
3.0.2 Capital2 (GetContract)
3.4 Resolve Company3 (ListInsuranceCompanys)
3.4.1 Populate Company Map1 (ListInsuranceCompanys)
3.5.1 Insurance Docs3 (ListClientFiles), 10 (DownloadClientFile2)
3.5.2 Capital Docs3 (ListClientFiles), 10 (DownloadClientFile2)
9.0 nicht eindeutige Verträge2 (getClients), 50 (GetClient), 303 (vertraege), 308 (GetClient), 400 (vertraege)
NWZ2.0 Contact2 (CONTACTcrm), 13 (CONTACTupdate), 37 (CONTACTcreate)
3.0.1 Insurance5 (INSURANCEcrm), 9 (INSURANCEupdate), 12 (INSURANCEcreate)
3.0.2 Capital83 (CAPITALcrm), 88 (CAPITALupdate), 93 (CAPITALcreate)
3.1 Resolve Customer2 (CONTACTcrm)
3.5.1 Insurance Docs4 (DOCUMENTlist), 13 (DOCUMENTcreate)
3.5.2 Capital Docs4 (DOCUMENTlist), 13 (DOCUMENTcreate)
9.0 nicht eindeutige Verträge1 (CONTACTlist), 5 (CONTACTread), 12 (INSURANCElist), 13 (INSURANCEread), 87 (DOCUMENTlist), 300 (INSURANCElist), 301 (INSURANCEread)
Google0.9.1 Insurance Map → DataStore1 (filterRows), 4 (updateRow)
0.9.2 Capital Map → DataStore1 (filterRows), 4 (updateRow)
9.0 nicht eindeutige Verträge9, 85, 88, 304 (jeweils addRow)
SMTP1.0 Main22, 78, 107, 108
2.0 Contact87
3.0.1 Insurance50, 51
3.0.2 Capital50, 51

Szenarien ohne Credential

Diese Szenarien greifen ausschließlich auf DataStores zu und benötigen keine PW-, NWZ-, Google- oder SMTP-Verbindung. Hier nur den passenden DataStore zuweisen: 3.0.0, 3.2.1, 3.2.2, 3.3, 3.6, 3.7, 3.8.

Achtung: nicht neutralisierte Dateien

Vier Blueprints tragen noch echte Verbindungs-IDs (Dateien ohne „NEUTRAL" im Namen). Vor einem Partner-Rollout müssen dort die __IMTCONN__-Werte geleert werden, sonst zeigt der Import auf die Quell-Verbindungen:
  • 3.4.1 Populate PW Company Map → PW-Verbindung 9151356
  • 9.0 nicht eindeutige Verträge → PW 14455289, NWZ 14455304, Google 14455305
  • 0.9.1 und 0.9.2 → Google 14455305

Szenarien ohne Credential

Diese Szenarien greifen ausschließlich auf DataStores zu und benötigen keine PW-, NWZ-, Google- oder SMTP-Verbindung. Hier nur den passenden DataStore zuweisen: 3.0.0, 3.2.1, 3.2.2, 3.3, 3.6, 3.7, 3.8.

Stand: Blueprint-Build 20260731


Aufgabe des Szenarios "1.0 Main"

Idea
1.0 Main: Full Sync ist das zentrale Taktgeber-Szenario.
Es ist das einzige Szenario, das eigenständig (regelmäßig) läuft — alle übrigen Szenarien (2.0, 3.0.x) werden von hier als Sub-Szenarien aufgerufen.

Idea
Aufgabe: Kunden und deren Verträge aus ProfessionalWorks (PW) nach NETZWERKZEUG (NWZ) übertragen und anschließend eine Zusammenfassung per E-Mail versenden.
Kurz gesagt: PW-Kunden mit der Kategorie „Notfallplanung" werden nach NWZ gespiegelt, ihre Verträge nach Typ (Versicherung/Kapital) sortiert und angelegt, und der Lauf wird per Tagesmail dokumentiert.

Ablauf Schritt für Schritt

  1. [80] Sync-Konfiguration lesen — liest den DataStore „1.0.1 Sync Config" aus (u. a. den Zeitstempel des letzten Laufs).
  2. [1] getClients (PW) — holt die Kundenliste aus ProfessionalWorks.
  3. [7] → 2.0 Synch Contact — nur für Kunden, deren custom_id den Begriff „Notfallplanung" enthält. 2.0 legt den Kunden in NWZ an oder aktualisiert ihn und liefert die NWZ-Kontakt-ID sowie den Status (Neu angelegt / Aktualisiert / Unverändert) zurück. Schlägt es fehl, geht Fehlermail [78] „Fehler bei Kundenanlage" raus.
  4. [9] vertraege (PW) — zieht pro Kunde dessen Verträge (max. 100).
  5. [18] Verzweigung „Vertrag vorhanden?" — nur wenn ein Vertrag existiert, geht es weiter:
    • [11] → 3.0.0 Resolve Contract Type — bestimmt, ob es sich um einen INSURANCE- oder CAPITAL-Vertrag handelt.
    • [87] Typ = INSURANCE? → [89] 3.0.1 Synch Insurance Contract (inkl. Dokumente über 3.5.1). Fehler → Mail [107].
    • [88] Typ = CAPITAL? → [91] 3.0.2 Synch Capital Contract (inkl. Dokumente über 3.5.2). Fehler → Mail [108].
    • Passt keiner der Typen, wird der Vertrag stillschweigend übersprungen (Placeholder [90]).
  6. [71]/[84] Bericht bauen — erzeugt je Kunde/Vertrag eine HTML-Zeile mit Name, Geburtsdatum und Status-Symbol (🔵 Neu / 🟢 Aktualisiert / ⚪ Unverändert).
  7. [81] Zeitstempel schreiben — setzt last_sync_at = jetzt im DataStore „1.0.1 Sync Config".
  8. [201] Bericht zusammenführen — fügt alle Kundenblöcke zum Gesamtbericht zusammen.
  9. [22] Zusammenfassungs-Mail — versendet „Zusammenfassung – TT.MM.JJJJ" an Makler + QM.


Flussdiagramm




Wichtig zu wissen

Notfallplanung als Filter: Kunden ohne die Kategorie „Notfallplanung" werden übersprungen — das ist gewollt und die zentrale Steuerung, welche Datensätze überhaupt synchronisiert werden.

Typ-Weiche hängt an 3.0.0: Liefert 3.0.0 eine falsche Kategorie, landet der Vertrag im Placeholder und wird ohne Meldung übergangen. Bei fehlenden Verträgen lohnt der Blick zuerst hierhin.
Nach jedem Import neu verdrahten: Die vier Sub-Aufrufe zeigen auf die Szenario-IDs des Quellkontos. Nach dem Import beim Partner müssen die Verweise auf 2.0, 3.0.0, 3.0.1 und 3.0.2 neu gesetzt werden, sonst laufen sie ins Leere.

Stand: Blueprint-Build 20260731

Aufgabe des Szenarios "2.0 Synch Contact"

IdeaDieses Szenario synchronisiert einen einzelnen Kunden von ProfessionalWorks (PW) nach NETZWERKZEUG (NWZ). Das Szenario wird von 1.0 pro Kunde aufgerufen und bekommt die PW-Kunden-ID übergeben.
Kurz gesagt: Ist der Kunde in NWZ noch nicht vorhanden, wird er angelegt (samt Aufgaben-Mail); ist er vorhanden und in PW neuer geändert, wird er aktualisiert – sonst bleibt er unverändert.

Ablauf Schritt für Schritt

  1. [1] GetClient (PW) – lädt den Kunden anhand der übergebenen client_id.
  2. [2] CONTACTcrm (NWZ) – sucht den Kunden in NWZ über die CRM-ID. Dieser Aufruf entscheidet, ob es sich um einen neuen oder bestehenden Kunden handelt.
  3. Nicht gefunden (404) → [37] CONTACTcreate legt den Kontakt in NWZ neu an, [87] versendet die Aufgaben-Mail „Neuer Kunde angelegt“. Ergebnis: Neu angelegt.
  4. Gefunden → Verzweigung [15] „PW neuer & Felder geändert?“: Nur wenn der PW-Datensatz jünger ist als der NWZ-Stand und sich tatsächlich Felder geändert haben, aktualisiert [13] CONTACTupdate den Kontakt (Ergebnis Aktualisiert). Andernfalls Unverändert.
  5. [34] Return – gibt die NWZ-Kontakt-ID und den Status (Neu angelegt / Aktualisiert / Unverändert) an 1.0 zurück.

Flussdiagramm

Wichtig zu wissen

Datumsvergleich schützt NWZ-Änderungen: Die Prüfung „PW neuer“ verhindert, dass in NWZ vorgenommene, aktuellere Änderungen von älteren PW-Daten überschrieben werden.
Aufgaben-Mail: Bei Neuanlage geht eine Mail mit manuellen To-dos raus (z. B. Benutzerkonto anlegen, Modul Versicherungen freigeben).
Nach Import: 2.0 wird von 1.0 per Call-Subscenario aufgerufen – nach einem Import muss dieser Verweis in 1.0 auf die neue Szenario-ID von 2.0 zeigen.

Stand: Blueprint-Build 202607031



Aufgabe des Szenarios 3.0.1

3.0.1 Synch Insurance Contract überträgt einen einzelnen Versicherungsvertrag von ProfessionalWorks (PW) nach NETZWERKZEUG (NWZ). Aufgerufen wird es von 1.0, nachdem 3.0.0 den Vertragstyp bestimmt hat. Übergeben werden Vertrags-ID, das Flag sync_docs und die NWZ-Kunden-ID.

Kurz gesagt: Der PW-Vertrag wird über Mapping-Tabellen aufbereitet und in NWZ angelegt oder – falls schon vorhanden und in PW neuer – aktualisiert. Optional werden die zugehörigen Dokumente mitsynchronisiert.

Ablauf Schritt für Schritt

  1. [2] GetContract (PW) – lädt den Vertrag anhand der Vertrags-ID.
  2. [3/4/23] Mapping-Lookups (DataStores) – schlägt Vertragstyp (3.2.1), Zahlweise (3.3.1) und Gesellschaft (3.4.1) nach, um die PW-Werte auf die NWZ-Werte zu übersetzen.
  3. [5] INSURANCEcrm – sucht den Vertrag in NWZ. Entscheidet über anlegen oder aktualisieren.
  4. Nicht gefunden → [15] → 3.1 Resolve Customer ermittelt den NWZ-Kunden, dann legt [12] INSURANCEcreate den Vertrag an. Ist sync_docs = true, werden über 3.5.1 Insurance Documents die Dokumente übertragen (Fehler → Mail [50]). Ergebnis: Neu angelegt.
  5. Gefunden → Verzweigung [6] „PW neuer & geändert?“: nur bei jüngerem PW-Stand und tatsächlicher Änderung aktualisiert [9] INSURANCEupdate den Vertrag (Aktualisiert), sonst Unverändert. Anschließend optionaler Dokument-Sync über 3.5.1 Insurance Documents (Fehler → Mail [51]).
  6. [34] Return – gibt Status, Produktname, Gesellschaft und die NWZ-Vertrags-ID zurück.

Flussdiagramm

Wichtig zu wissen

Mapping-Tabellen müssen gefüllt sein: Fehlt ein Eintrag in der Typ-, Zahlweise- oder Company-Map, bleiben die entsprechenden NWZ-Felder leer. Die Maps werden separat (0.9.x / 3.4.1) befüllt.
Dokument-Sync ist optional: Nur bei sync_docs = true. Ein Fehler dabei löst eine Mail aus, bricht die Vertragssynchronisation aber nicht ab.
Nach Import: Die Call-Subscenario-Verweise auf 3.1 (Resolve Customer) und 3.5.1 (Dokumente) sowie die drei DataStore-Zuordnungen müssen neu gesetzt werden.

Stand: Blueprint-Build 20260731

Aufgabe des Szenarios 3.0.2

3.0.2 Synch Capital Contract überträgt einen einzelnen Kapitalvertrag von ProfessionalWorks (PW) nach NETZWERKZEUG (NWZ). Aufgerufen wird es von 1.0, nachdem 3.0.0 den Vertragstyp bestimmt hat. Übergeben werden Vertrags-ID, das Flag sync_docs und die NWZ-Kunden-ID.

Kurz gesagt: Der PW-Vertrag wird über Mapping-Tabellen aufbereitet und in NWZ angelegt oder – falls schon vorhanden und in PW neuer – aktualisiert. Optional werden die zugehörigen Dokumente mitsynchronisiert.

Ablauf Schritt für Schritt

  1. [2] GetContract (PW) – lädt den Vertrag anhand der Vertrags-ID.
  2. [3/4/23] Mapping-Lookups (DataStores) – schlägt Vertragstyp (3.2.2), Zahlweise (3.3.1) und Gesellschaft (3.4.1) nach, um die PW-Werte auf die NWZ-Werte zu übersetzen.
  3. [83] CAPITALcrm – sucht den Vertrag in NWZ. Entscheidet über anlegen oder aktualisieren.
  4. Nicht gefunden → [15] → 3.1 Resolve Customer ermittelt den NWZ-Kunden, dann legt [93] CAPITALcreate den Vertrag an. Ist sync_docs = true, werden über 3.5.2 Capital Documents die Dokumente übertragen (Fehler → Mail [50]). Ergebnis: Neu angelegt.
  5. Gefunden → Verzweigung [6] „PW neuer & geändert?“: nur bei jüngerem PW-Stand und tatsächlicher Änderung aktualisiert [88] CAPITALupdate den Vertrag (Aktualisiert), sonst Unverändert. Anschließend optionaler Dokument-Sync über 3.5.2 Capital Documents (Fehler → Mail [51]).
  6. [34] Return – gibt Status, Produktname, Gesellschaft und die NWZ-Vertrags-ID zurück.

Flussdiagramm

Wichtig zu wissen

Mapping-Tabellen müssen gefüllt sein: Fehlt ein Eintrag in der Typ-, Zahlweise- oder Company-Map, bleiben die entsprechenden NWZ-Felder leer. Die Maps werden separat (0.9.x / 3.4.1) befüllt.
Dokument-Sync ist optional: Nur bei sync_docs = true. Ein Fehler dabei löst eine Mail aus, bricht die Vertragssynchronisation aber nicht ab.
Baugleich zu 3.0.1 – nur für Kapitalverträge (Capital-Map 3.2.2, CAPITAL-Module, Dokumente 3.5.2). Nach Import ebenso 3.1, 3.5.2 und die DataStores neu zuordnen.

Stand: Blueprint-Build 20260706.