# Kontakt

> Wie Kontakte zwischen Customer Engagement und Business Central abgeglichen werden — Gesamtbild und die fünf Schritte im Detail.

---

LLMS index: [llms.txt](/llms.txt)

---

Kontakte werden nach demselben Muster abgeglichen wie [Firmen](../firma/): in beide
Richtungen, im Zwei-Minuten-Takt, gesteuert über die Freigabe **Sync zu BC** und die
**BC System-ID**.

Ein Unterschied ist aber grundlegend: **Ein Kontakt hängt an seiner Firma.** Business
Central kann einen Kontakt nur anlegen, wenn dessen Firma dort bereits existiert.
Das prägt den gesamten Ablauf.

| Schritt | Was passiert | Wann |
|---|---|---|
| [Aus BC übernehmen](bccontacts/) | BC-Kontakte kommen nach CE | alle 2 Minuten |
| [Neu nach BC](cecontacts/) | in CE angelegte, freigegebene Kontakte werden in BC angelegt | alle 2 Minuten |
| [Rückmeldung aus BC](bccontactsresponse/) | BC meldet Nummer, Id und Adressdaten zurück | direkt nach der Anlage |
| [Änderungen nach BC](cecontactsupdates/) | Änderungen in CE gehen nach BC | alle 2 Minuten |
| [Löschung aus BC](bccontactsdelete/) | in BC gelöschte Kontakte werden in CE deaktiviert | alle 2 Minuten |

## Der Kreislauf

```mermaid
flowchart TB
  START(["Kontakt entsteht"]) --> Q{"Wo?"}

  Q -->|"in CE angelegt"| C0{"Firma bereits<br/>in BC?"}
  Q -->|"in BC angelegt"| B1["<b>Aus BC übernehmen</b><br/>Kontakt erscheint in CE"]

  C0 -->|nein| BLOCK["Freigabe wird abgelehnt —<br/>erst die Firma übertragen"]
  C0 -->|ja| C1["Feld <b>BC System-ID</b><br/>ist noch leer"]

  C1 --> C2{"<b>Sync zu BC</b><br/>freigegeben?"}
  C2 -->|nein| WAIT["Kontakt bleibt in CE"]
  C2 -->|ja| C3["<b>Neu nach BC</b><br/>Kontakt wird in BC angelegt"]

  C3 --> C4["<b>Rückmeldung aus BC</b><br/>BC Kontaktnummer, BC System-ID<br/>und Adressdaten kommen zurück"]

  B1 --> SYNC["Kontakt existiert in beiden Systemen"]
  C4 --> SYNC

  SYNC --> U1["Änderung in CE<br/><b>Änderungen nach BC</b>"]
  SYNC --> U2["Änderung in BC<br/><b>Aus BC übernehmen</b>"]
  U1 --> SYNC
  U2 --> SYNC

  SYNC --> D1["Kontakt in BC gelöscht"]
  D1 --> D2["<b>Löschung aus BC</b><br/>Kontakt in CE wird deaktiviert"]
```

## Erst die Firma, dann der Kontakt

Das ist die zentrale Regel — und der wichtigste Unterschied zur Firma:

> Ein Kontakt darf erst freigegeben werden, wenn die **BC System-ID seiner Firma**
> gefüllt ist.

Ein gesetztes Häkchen bei *Sync zu BC* an der Firma genügt nicht. Es bedeutet nur
„soll übertragen werden". Erst die gefüllte BC System-ID beweist, dass die Firma im ERP
angekommen ist. Die Lösung setzt das aktiv durch: Die Freigabe eines Kontakts wird
abgelehnt, solange die Firma nicht nachweislich in BC existiert. Dasselbe gilt beim
Umhängen eines Kontakts an eine andere Firma.

Ausführlich beschrieben ist die Regel unter
[Freigabe nach Business Central](../../business-logik/sync-nach-bc/).

## Die Weiche: das Feld „BC System-ID"

Wie bei der Firma entscheidet die BC System-ID, welcher Schritt greift:

| Feld ist … | Bedeutung | Es greift |
|---|---|---|
| **leer** | BC kennt den Kontakt noch nicht | [Neu nach BC](cecontacts/) |
| **gefüllt** | BC kennt den Kontakt | [Änderungen nach BC](cecontactsupdates/) |

Beide setzen zusätzlich die Freigabe über **Sync zu BC** voraus.

## Welche Felder laufen in welche Richtung?

| Feld in CE | Aus BC übernehmen | Neu nach BC | Änderungen nach BC |
|---|:--:|:--:|:--:|
| Vorname, Zweiter Vorname, Nachname | ✓ | ✓ | ✓ |
| Anrede (BC) | ✓ | ✓ | ✓ |
| Sprache | ✓ | ✓ | ✓ |
| Straße 1 / Straße 2 | ✓ | ✓ | ✓ |
| Postleitzahl / Ort | ✓ | ✓ | ✓ |
| Land | ✓ | ✓ | ✓ |
| Geschäftlich (Telefon) | ✓ | ✓ | ✓ |
| Mobiltelefon | ✓ | ✓ | ✓ |
| E-Mail | ✓ | ✓ | ✓ |
| **Firmenname** (übergeordnete Firma) | ✓ | ✓ | ✓ |
| **Position (BC)** | ✓ | – | – |
| **Verkäufer (BC)** | – | ✓ | ✓ |
| Sync zu BC | ✓ | – | – |
| BC Kontaktnummer | ✓ | – | – |
| BC System-ID | ✓ | – | – |

Zwölf Felder laufen glatt in beide Richtungen. Die drei hervorgehobenen verdienen einen
zweiten Blick.

### Die übergeordnete Firma ist hier bidirektional

Beim Kontakt wird die Zuordnung zur Firma **in beide Richtungen** abgeglichen — anders
als bei der Firma, wo die übergeordnete Firma nur aus BC kommt. Wird ein Kontakt in CE
an eine andere Firma gehängt, geht das nach BC; und umgekehrt.

Aufgelöst wird über die **BC Kontaktnummer der Firma**. Fehlt sie — weil die Firma noch
nicht in BC ist —, kann die Zuordnung nicht gebildet werden. Genau deshalb greift die
Freigaberegel oben.

### Zwei Felder laufen nur in eine Richtung

| Feld | Richtung | Konsequenz |
|---|---|---|
| **Position (BC)** — die Organisationsebene aus BC | nur BC → CE | Eine Änderung in CE geht nicht nach BC und wird beim nächsten Abgleich überschrieben |
| **Verkäufer (BC)** | nur CE → BC | Der in BC hinterlegte Verkäufer wird beim Übernehmen nicht nach CE geholt |

> **Die Funktion (Position) wird nicht übertragen**
>
> Das Standardfeld **Position** (die Funktion als Freitext) ist in keinem der Kontakt-Schritte
> gemappt. Es bleibt in Customer Engagement und wird weder angelegt noch geändert nach BC
> geschickt.



## Was in der Praxis zu beachten ist

> **Zwei Felder heißen fast gleich**
>
> Am Kontakt gibt es **Position** (Standardfeld, freier Text, die Funktion im Unternehmen)
> und **Position (BC)** (Verweis auf die Organisationsebenen aus Business Central). Nur
> **Position (BC)** wird abgeglichen (BC → CE); die Funktion als Freitext bleibt in CE.
> Beim Prüfen eines Kontakts also genau hinsehen, welches der beiden gemeint ist.



> **Aus BC übernommene Kontakte sind automatisch freigegeben**
>
> Wie bei der Firma wird **Sync zu BC** beim Übernehmen aus BC auf „Ja" gesetzt. Für diese
> Kontakte gibt es also keine bewusste Freigabeentscheidung mehr.



> **Deaktivierte Kontakte bleiben im Abgleich**
>
> Wird ein Kontakt in BC gelöscht, wird er in CE nur deaktiviert — Freigabe und
> BC System-ID bleiben stehen. [Änderungen nach BC](cecontactsupdates/) prüft nur diese
> beiden Felder und erfasst den Datensatz deshalb weiterhin.



## Unterschiede zur Firma auf einen Blick

| | Firma | Kontakt |
|---|---|---|
| Kontaktart in BC | `Company` | `Person` |
| Übergeordnete Firma | nur BC → CE | **bidirektional** |
| Name | Name 1 / Name 2 (BC), Firmenname bleibt unberührt | Vorname / Zweiter Vorname / Nachname, Standardfelder |
| Rückmeldung aus BC | 2 Felder (Nummer, Id) | **9 Felder** — zusätzlich Adressdaten |
| Freigabe abhängig von | — | **BC System-ID der Firma** |
| Anrede | fester Vorgabewert `MANDANT` | Verweis auf die BC-Anredeschlüssel |

## Technische Zuordnung

<details>
<summary>Jobs und Mappings dieser Kette</summary>

| Order | Job | Mapping | Seite |
|---|---|---|---|
| 240 | `contactsnewfromce` | `CEContacts` | [Neu nach BC](cecontacts/) |
| 241 | `contactsresponsefrombc` | `BCContactsResponse` | [Rückmeldung aus BC](bccontactsresponse/) |
| 430 | `contactsfrombc` | `BCContacts` | [Aus BC übernehmen](bccontacts/) |
| 440 | `contactsfrombcdelete` | `BCContactsDelete` | [Löschung aus BC](bccontactsdelete/) |
| 530 | `contactupdatesfromce` | `CEContactsUpdates` | [Änderungen nach BC](cecontactsupdates/) |

Beteiligte Tabellen: Dataverse `contact` ⇄ BC API Page
`singhammerITConsulting/dyce/v2.0/acdcontacts`; Löschungen über
`singhammerITConsulting/dyce/v2.0/acdlogentries`.

</details>

<details>
<summary>Schlüssel je Schritt</summary>

| Schritt | Schlüssel im Ziel | Typ |
|---|---|---|
| Aus BC übernehmen | `wysa_bccontactnumber` ← BC `number` | `CustomKey` `wysa_bccodekey` |
| Neu nach BC | BC `dataverseId` ← CE `contactid` | `Filter` |
| Rückmeldung aus BC | CE `contactid` aus der Antwortnachricht | `PrimaryKey` |
| Änderungen nach BC | BC `id` ← CE `wysa_bcsystemid` | `Id` |
| Löschung aus BC | `wysa_bcsystemid` ← Log `recordId` | `CustomKey` `wysa_bcsystemidkey` |

Identisch zur [Firma](../firma/).

</details>

<details>
<summary>Auflösung von Referenzen</summary>

Der Kontakt löst mehr Referenzen auf als die Firma — fünf statt drei:

| CE-Feld | Werteliste | Codefeld | Stammdaten-Job |
|---|---|---|---|
| Land (`wysa_address1_countryid`) | `wysa_country` | `wysa_bccode` | `countriesfrombc` (110) |
| Sprache (`wysa_language`) | `wysa_language` | `wysa_bccode` | `languagesfrombc` (115) |
| Anrede BC (`wysa_salutationbcid`) | `wysa_bcsalutation` | `wysa_code` | `salutationsfrombc` (120) |
| Verkäufer BC (`wysa_bcsalespersonid`) | `wysa_bcsalesperson` | `wysa_code` | `salespersonsfrombc` (130) |
| Position BC (`wysa_bcpositionid`) | `wysa_bcposition` | `wysa_code` | `positionsfrombc` (135) |
| Firma (`parentcustomerid`) | `account` | `wysa_bccontactnumber` | — |

Die Stammdaten-Jobs 110 – 135 laufen vor den Kontakt-Jobs (240 / 430), sodass die
Wertelisten innerhalb desselben Laufs aktuell sind.

</details>

---

Section pages:

- [Kontakte aus Business Central übernehmen](/docs/mapping/kontakt/bccontacts/): Neue und geänderte Kontakte aus dem ERP erscheinen in Customer Engagement.
- [Neue Kontakte nach Business Central übertragen](/docs/mapping/kontakt/cecontacts/): In Customer Engagement angelegte und freigegebene Kontakte werden im ERP angelegt.
- [Rückmeldung aus Business Central](/docs/mapping/kontakt/bccontactsresponse/): Nach der Anlage im ERP kommen Kontaktnummer, BC System-ID und die von BC ergänzten Adressdaten zurück.
- [Änderungen nach Business Central übertragen](/docs/mapping/kontakt/cecontactsupdates/): Änderungen an bereits im ERP bekannten Kontakten werden von Customer Engagement nach Business Central übertragen.
- [Löschung in Business Central nachvollziehen](/docs/mapping/kontakt/bccontactsdelete/): Wird ein Kontakt im ERP gelöscht, wird er in Customer Engagement deaktiviert — nicht gelöscht.