# Freigabe nach Business Central

> Wann ein Datensatz nach Business Central übertragen werden darf — und warum die Reihenfolge zählt.

---

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

---

## Das Feld „Sync zu BC"

Nicht jede Firma und nicht jeder Kontakt gehört nach Business Central. Ein Interessent,
der nie zum Kunden wird, hat dort nichts verloren. Deshalb ist die Übertragung kein
Automatismus, sondern eine bewusste Entscheidung: Das Feld **Sync zu BC**
(`wysa_sync2bc`) gibt einen Datensatz frei. Erst dann liest die dsyr.DataBridge ihn und
überträgt ihn.

Das Feld steht auf Firma, Kontakt, Verkaufschance und Verkaufschancenprodukt.

## Die Grundregel: erst der Vater, dann das Kind

Business Central kann einen Kontakt nur anlegen, wenn dessen Firma dort bereits
existiert. Genauso wenig kann eine Verkaufschance ohne ihren Kontakt übertragen werden.
Daraus folgt die zentrale Regel der Integration:

> Ein untergeordneter Datensatz darf erst freigegeben werden, wenn der übergeordnete
> **nachweislich** in Business Central angekommen ist.

„Nachweislich" heißt: Business Central hat den Schlüssel zurückgemeldet. Der Nachweis ist
also nicht das gesetzte Häkchen, sondern ein gefülltes Rückmeldefeld:

| Übergeordneter Datensatz | Nachweis der Ankunft |
|---|---|
| Firma | `wysa_bcSystemId` bzw. `wysa_bcCustomerNumber` |
| Kontakt | `wysa_bcContactNumber` |
| Verkaufschance | `wysa_bcOpportunityNumber` |

Diese Unterscheidung ist der Kern: Ein Häkchen bedeutet nur „soll übertragen werden", ein
gefülltes Nummernfeld bedeutet „ist übertragen".

```mermaid
flowchart TD
    A["Firma freigeben<br/>(Sync zu BC = Ja)"] --> B{"BC-Nummer<br/>zurückgemeldet?"}
    B -- nein --> C["Kontakt kann noch nicht<br/>freigegeben werden"]
    B -- ja --> D["Kontakt freigeben"]
    D --> E{"BC-Kontaktnummer<br/>zurückgemeldet?"}
    E -- nein --> F["Verkaufschance kann noch nicht<br/>freigegeben werden"]
    E -- ja --> G["Verkaufschance freigeben"]
```

## Was das im Alltag bedeutet

**Kontakt an eine andere Firma hängen.** Wird die übergeordnete Firma eines freigegebenen
Kontakts gewechselt, prüft die Lösung, ob die neue Firma bereits in Business Central
existiert. Ist sie es nicht, wird die Änderung abgelehnt — sonst entstünde dort ein
Kontakt ohne Firma.

**Verkaufschance ohne Kontakt.** Eine Verkaufschance kann nicht ohne Kontakt übertragen
werden. Fehlt er, wird die Freigabe abgelehnt. Ist er vorhanden, aber selbst noch nicht
in Business Central angekommen, ebenfalls.

**Vererbung von der Firma auf ihre Kontakte.** Wird eine Firma freigegeben und ist ihre
Übertragung bestätigt, können die zugehörigen Kontakte automatisch mit freigegeben
werden. Das erspart die Einzelpflege. Gesteuert wird das über die Umgebungsvariable
`wysa_AutomaticContactSyncBC` — siehe [Konfiguration](../konfiguration/). Ist sie
deaktiviert, bleibt die Freigabe je Kontakt eine manuelle Entscheidung.

**Verkaufschancenprodukte.** Positionen einer Verkaufschance folgen ihrer
Verkaufschance. Das funktioniert in beiden Entstehungsreihenfolgen: Wird eine Position zu
einer bereits übertragenen Verkaufschance hinzugefügt, wird sie sofort freigegeben; wird
die Verkaufschance nachträglich übertragen, werden die bestehenden Positionen
nachgezogen.

## Kopieren einer Verkaufschance

Wird eine Verkaufschance samt Positionen kopiert, würde die Kopie die BC-Nummer des
Originals mittragen — in Business Central entstünde ein doppelter Schlüssel. Deshalb
erkennt die Lösung eine Kopie daran, dass die BC-Nummer bereits bei einem anderen
Datensatz vergeben ist, und löscht dann die BC-Informationen der Kopie:

| Datensatz | Geleert / zurückgesetzt |
|---|---|
| Verkaufschance | BC-Verkaufschancennummer, BC-System-ID, Führendes Angebot; **Sync zu BC = Nein** |
| Verkaufschancenprodukt | BC-System-ID; **Sync zu BC = Nein** |

Die Kopie gilt damit als neue, noch nicht übertragene Verkaufschance und muss bewusst
erneut freigegeben werden.

## Im Formular

Ergänzend zur Serverprüfung verhält sich das Formular vorausschauend:

- **Sync zu BC ist nur änderbar, solange es sinnvoll ist.** Ist ein Datensatz bereits
  übertragen, wird das Feld gesperrt.
- **Von Business Central geführte Felder sind gesperrt.** Sobald ein Datensatz dort
  existiert, lassen sich Nummern und Stammdatenfelder in Customer Engagement nicht mehr
  ändern — sie würden ohnehin überschrieben.
- **Speichern wird blockiert, bevor der Server ablehnt.** Beim Kontakt prüft das Formular
  die Freigabesituation direkt beim Speichern und meldet das Problem sofort. Auch das
  automatische Zwischenspeichern wird in diesem Fall unterdrückt, damit keine
  Fehlermeldung ohne erkennbaren Anlass erscheint.

Sämtliche dieser Prüfungen gibt es zusätzlich auf dem Server. Wer Daten importiert oder
über eine Schnittstelle schreibt, unterliegt denselben Regeln.