Die laufende Nummer des Mandanten

Die laufende Nummer des Mandanten dient in Syncler als Mandanten-/Kontexttrennung für Syncs.
Sie strukturiert Datenflüsse logisch, steuert Zugriffs- und Zielsteuerung pro Datensatz und beeinflusst sowohl Statusfelder in Drittsystemen als auch die Datensatz-Abbildungen (Mappings).

Zweck & Wirkung

• Isolation von Datenflüssen: Syncs mit unterschiedlicher Mandantennummer arbeiten logisch getrennt – auch dann, wenn Quelle/Ziel identisch sind.
• Statusfelder in Zielsystemen: Systeme wie Sage CRM, CAS oder Salesforce können nummerierte Sync-Statusfelder führen (z. B. sis_status1, sis_status2). Diese beziehen sich jeweils auf die konfigurierte Mandantennummer des Syncs.
• Zugriffssteuerung: Nur Syncs mit passender Nummer dürfen einen Datensatz lesen/aktualisieren – damit wird auch das Zielrouting bestimmt.
• Mapping-Sichtbarkeit: Ein Sync sucht, erzeugt und aktualisiert ausschließlich Datensatz-Abbildungen seiner eigenen Mandantennummer.

Regeln im Betrieb

1. Statusfelder

   • Pro Mandantennummer werden (falls vorgesehen) eigene Statusindikatoren im Fremdsystem gepflegt.
   • Ein Sync verändert nicht die Statusfelder anderer Mandantennummern.

2. Datensatz-Abbildungen (Mappings)

   • Lookup, Anlage und Aktualisierung erfolgen nur innerhalb derselben Mandantennummer.
   • Abbildungen anderer Mandantennummern werden ignoriert (keine Kollisionen, keine Vermischung).

3. Doppelte Anlage (bewusst gesteuert)

   • Durch unterschiedliche Mandantennummern können gezielt Duplikate (separate Ziel-Datensätze) für unterschiedliche Zwecke/Instanzen erzeugt werden – mit getrennten Lebenszyklen.

Konfiguration (Kurz)

• Ort: Pro Sync in den Einstellungen (Mandant/Kontext).
• Wertbereich: Ganzzahl > 0 (Namenskonvention/Belegungsplan festlegen).
• Konsistenz: In bidirektionalen Setups müssen beide Richtungen dieselbe Mandantennummer verwenden, sofern kein bewusstes Duplizieren gewünscht ist.

Beispiel 1

Szenario: Zwei Datensätze aus verschiedenen ERP-Mandanten sollen auf einen Firmen-Datensatz im CRM komprimiert werden.

• Sync A (Mandant 1): Sage 100 -> Sage CRM
• Sync B (Mandant 2): Sage 100 -> Sage CRM
• Sync C (Mandant 1): Sage CRM -> Sage 100
• Sync D (Mandant 2): Sage CRM -> Sage 100

Effekte:

• CRM führt SyncStatus_1 und SyncStatus_2.
• Es existieren eigene Datensatz-Abbildungen für Mandant 1 und Mandant 2.
• komprimierte Feldzuordnungen (z.B. Firmenname oder Adresse) werden auf die Mandanten verteilt; Mandant 1 -> CRM -> Mandant 2

flowchart LR
  A[ERP Mandant A]:::erp --> L1[Sync A<br/>Nummer 1]:::step
  B[ERP Mandant B]:::erp --> L2[Sync B<br/>Nummer 2]:::step
  L1 --> K[CRM<br/>1 Ziel-Datensatz - Status1, Status2]:::crm
  L2 --> K
  K --> L3[Sync C<br/>Nummer 1]:::step
  K --> L4[Sync D<br/>Nummer 2]:::step
  L3 --> C[ERP Mandant A]:::erp
  L4 --> D[ERP Mandant B]:::erp 

  classDef erp fill:#eef,stroke:#88f,color:#000;
  classDef step fill:#ffd,stroke:#cc3,color:#000;
  classDef crm fill:#efe,stroke:#4a4,color:#000;

Beispiel 2

Szenario: Ein Firmen-Datensatz soll in zwei getrennten Integrationspfaden verarbeitet werden.

• Sync A (Mandant 1): Sage CRM ↔ ERP (operativer Datenfluss)
• Sync B (Mandant 2): Sage CRM ↔ Data Warehouse (analytischer Datenfluss)

Effekte:

• CRM führt SyncStatus_1 und SyncStatus_2.
• Es existieren eigene Datensatz-Abbildungen für Mandant 1 und Mandant 2.
• Änderungen in Pfad A beeinflussen nicht die Mappings/Status von Pfad B.
• Bei Bedarf können in Pfad B separate Zielobjekte angelegt werden, ohne Pfad A zu berühren.

Beispiel 3

Szenario: Ein ERP-Datensatz soll in zwei getrennten Integrationspfaden verarbeitet werden und zwei Datensätze im CRM erzeugen.

• Sync A (Mandant 1): Sage 100 -> Sage CRM
• Sync B (Mandant 2): Sage 100 -> Sage CRM
• Sync C (Mandant 1): Sage CRM -> Sage 100
• Sync D (Mandant 2): Sage CRM -> Sage 100

Effekte:

• CRM führt SyncStatus_1 oder SyncStatus_2.
• Es existieren eigene Datensatz-Abbildungen für Mandant 1 und Mandant 2.
• komprimierte Feldzuordnungen (z.B. Firmenname oder Adresse) werden auf die Mandanten verteilt; CRM 1 -> ERP -> CRM 2

flowchart LR
    A[ERP Mandant A]:::erp
  subgraph CRM
    C1[CRM Account 1]:::crm
    C2[CRM Account 2]:::crm
  end
    B[ERP Mandant A]:::erp

  A --> C[Sync A<br/>Mandant 1]:::step --> C1
  A --> D[Sync B<br/>Mandant 2]:::step --> C2
  C1 --> E[Sync C<br/>Mandant 1]:::step --> B
  C2 --> F[Sync D<br/>Mandant 2]:::step --> B
  
  classDef erp fill:#eef,stroke:#88f,color:#000;
  classDef crm fill:#efe,stroke:#4a4,color:#000;
  classDef step fill:#ffd,stroke:#cc3,color:#000;

Best Practices

• Bidirektionale Flüsse angleichen: Beide Richtungen mit derselben Nummer betreiben, um Doppelerstellungen zu vermeiden – außer sie sind ausdrücklich gewünscht.
• Migration: Beim Wechsel der Mandantennummer entstehen neue Mappings. Altes Setup sauber stilllegen (Statusfelder/Mappings bereinigen), um Inkonsistenzen zu vermeiden.
• Tests trennen: Für Testläufe eigene Nummer verwenden, damit produktive Mappings/Status unberührt bleiben.

Häufige Stolpersteine

• Gemischte Nummern in einer Kette: Unterschiedliche Mandantennummern in aufeinanderfolgenden Syncs verhindern Mapping-Wiederverwendung.
• Unbeabsichtigte Duplikate: Abweichende Nummern in (scheinbar) identischen Flüssen führen zu doppelten Ziel-Datensätzen.
• Konfliktmanagement greift anders: Konflikte werden mandantenweise bewertet – fehlende Abstimmung der Nummern kann Diagnosen erschweren.