# Firma

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

---

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

---

Firmen werden zwischen Customer Engagement und Business Central **in beide Richtungen**
abgeglichen. Der Vertrieb legt eine Firma in CE an, gibt sie frei, und sie erscheint im
ERP — oder ein Debitor entsteht in BC und taucht kurz darauf in CE auf. Beides ist
möglich, und beides greift ineinander.

Diese Seite zeigt das Gesamtbild. Die fünf Schritte, aus denen der Abgleich besteht,
sind je auf einer eigenen Seite beschrieben:

| Schritt | Was passiert | Wann |
|---|---|---|
| [Aus BC übernehmen](bcaccounts/) | BC-Firmen kommen nach CE | alle 2 Minuten |
| [Neu nach BC](ceaccounts/) | in CE angelegte, freigegebene Firmen werden in BC angelegt | alle 2 Minuten |
| [Rückmeldung aus BC](bcaccountsresponse/) | BC meldet Nummer und Id zurück | direkt nach der Anlage |
| [Änderungen nach BC](ceaccountupdates/) | Änderungen in CE gehen nach BC | alle 2 Minuten |
| [Löschung aus BC](bcaccountsdelete/) | in BC gelöschte Firmen werden in CE deaktiviert | alle 2 Minuten |

Kontakt und Verkaufschance funktionieren nach demselben Muster.

## Der Kreislauf

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

  Q -->|"in CE angelegt"| C1["Feld <b>BC System-ID</b><br/>ist noch leer"]
  Q -->|"in BC angelegt"| B1["<b>Aus BC übernehmen</b><br/>Firma erscheint in CE"]

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

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

  B1 --> SYNC["Firma 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["Firma in BC gelöscht"]
  D1 --> D2["<b>Löschung aus BC</b><br/>Firma in CE wird deaktiviert"]
```

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

Zwei Schritte übertragen Firmen von CE nach BC — welcher greift, entscheidet allein die
Frage, ob Business Central die Firma schon kennt. Erkennbar ist das am Feld
**BC System-ID** (`wysa_bcsystemid`):

| Feld ist … | Bedeutung | Es greift |
|---|---|---|
| **leer** | BC kennt die Firma noch nicht | [Neu nach BC](ceaccounts/) — die Firma wird angelegt |
| **gefüllt** | BC kennt die Firma | [Änderungen nach BC](ceaccountupdates/) — die Firma wird aktualisiert |

Beide Schritte setzen zusätzlich voraus, dass **Sync zu BC** auf „Ja" steht. Ohne diese
Freigabe passiert gar nichts — siehe
[Freigabe nach Business Central](../../business-logik/sync-nach-bc/).

Gefüllt wird die BC System-ID nur durch die [Rückmeldung aus BC](bcaccountsresponse/)
oder beim [Übernehmen aus BC](bcaccounts/). Genau deshalb ist sie der verlässliche
Nachweis, dass eine Firma im ERP angekommen ist — und genau darauf baut die
Freigaberegel für Kontakte auf: Ein Kontakt darf erst freigegeben werden, wenn die
BC System-ID seiner Firma gefüllt ist.

## Welche Felder laufen in welche Richtung?

Der Abgleich ist **nicht symmetrisch**. Einige Felder gehören fachlich ins ERP und
kommen nur von dort; zwei werden nur beim ersten Anlegen gesetzt.

| Feld in CE | Aus BC übernehmen | Neu nach BC | Änderungen nach BC |
|---|:--:|:--:|:--:|
| Name 1 (BC) | ✓ | ✓ | ✓ |
| Name 2 (BC) | ✓ | ✓ | ✓ |
| Straße 1 / Straße 2 | ✓ | ✓ | ✓ |
| Postleitzahl / Ort | ✓ | ✓ | ✓ |
| Land | ✓ | ✓ | ✓ |
| Telefon | ✓ | ✓ | ✓ |
| E-Mail | ✓ | ✓ | ✓ |
| Website | ✓ | ✓ | ✓ |
| Verkäufer (BC) | ✓ | ✓ | ✓ |
| BC Debitorennummer | ✓ | – | – |
| BC Kreditorennummer | ✓ | – | – |
| Debitorrabattgruppe | ✓ | – | – |
| Übergeordnete Firma | ✓ | – | – |
| Sync zu BC | ✓ | – | – |
| BC Kontaktnummer | ✓ | – | – |
| BC System-ID | ✓ | – | – |

Vier Aussagen lassen sich daraus ableiten:

**Adresse, Kommunikation, Name und Verkäufer laufen in beide Richtungen.** Wer zuletzt
speichert, gewinnt. Es gibt keine Konfliktauflösung.

**Debitornummer, Kreditornummer, Debitorrabattgruppe und übergeordnete Firma gehören
Business Central.** Sie entstehen im ERP und werden nur nach CE übertragen. Wer sie in
CE ändert, ändert nichts in BC — und die Änderung wird beim nächsten Abgleich wieder
überschrieben.

**Der Firmenname in CE wird nicht abgeglichen.** Der BC-Name landet im Feld
**Name 1 (BC)**, nicht im Standardfeld *Firmenname*. Beide dürfen also voneinander
abweichen — in CE kann ein Marketingname stehen, in BC der Handelsregistername.

**Kontaktart und Anrede werden nur beim Anlegen gesetzt.** Werden sie später in BC
geändert, bleibt die Änderung erhalten — der Schritt
[Änderungen nach BC](ceaccountupdates/) fasst diese Felder nicht an.

## Was in der Praxis zu beachten ist

> **Änderungen brauchen bis zu zwei Minuten**
>
> Alle Schritte laufen im Zwei-Minuten-Takt. Wer eine Firma freigibt und sofort in BC
> nachsieht, findet sie noch nicht. Bei einer Neuanlage sind es faktisch zwei Durchläufe,
> bis auch Kontaktnummer und BC System-ID zurückgemeldet sind.



> **Aus BC übernommene Firmen sind automatisch freigegeben**
>
> Kommt eine Firma aus Business Central, setzt der Abgleich **Sync zu BC** direkt auf
> „Ja". Das ist folgerichtig — die Firma existiert im ERP ja bereits — bedeutet aber, dass
> für diese Firmen keine bewusste Freigabeentscheidung mehr getroffen wird. Ihre Kontakte
> können sofort freigegeben werden.



> **Deaktivierte Firmen bleiben im Abgleich**
>
> Wird eine Firma in BC gelöscht, wird sie in CE nur deaktiviert — die BC System-ID und die
> Freigabe bleiben stehen. Der Schritt [Änderungen nach BC](ceaccountupdates/) prüft nur
> diese beiden Felder und erfasst den Datensatz deshalb weiterhin.



## Technische Zuordnung

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

| Order | Job | Mapping | Seite |
|---|---|---|---|
| 220 | `accountsnewfromce` | `CEAccounts` | [Neu nach BC](ceaccounts/) |
| 221 | `accountsresponsefrombc` | `BCAccountsResponse` | [Rückmeldung aus BC](bcaccountsresponse/) |
| 410 | `accountsfrombc` | `BCAccounts` | [Aus BC übernehmen](bcaccounts/) |
| 420 | `accountsfrombcdelete` | `BCAccountsDelete` | [Löschung aus BC](bcaccountsdelete/) |
| 520 | `accountupdatesfromce` | `CEAccountUpdates` | [Änderungen nach BC](ceaccountupdates/) |

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

</details>

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

Jeder Schritt findet den Zieldatensatz über einen anderen Schlüssel:

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

Der Wechsel der Schlüsselstrategie hat einen Grund: Beim ersten Übertragen aus CE gibt
es noch keine BC-Id. Deshalb legt der Anlage-Schritt die CE-GUID im BC-Feld
`dataverseId` ab und findet den Datensatz darüber wieder — das macht ihn wiederholbar,
ohne Dubletten zu erzeugen. Sobald die `wysa_bcsystemid` zurückgemeldet ist, wird
direkt über sie adressiert.

</details>

<details>
<summary>Auflösung von Referenzen (Land, Verkäufer, Rabattgruppe)</summary>

| Richtung | Operation | Wirkung |
|---|---|---|
| BC → CE | `Lookup` | BC-Code (z. B. `DE`) wird zur Dataverse-Referenz auf `wysa_country` |
| CE → BC | `LookupValue` | Dataverse-Referenz wird über `wysa_bccode` zum BC-Code aufgelöst |

Beide arbeiten über den Alternate Key `wysa_bccodekey` bzw. das Feld `wysa_bccode` der
jeweiligen Werteliste. Der Verkäufer bildet die Ausnahme: dort heißt das Codefeld
`wysa_code`.

Daraus folgt eine harte Reihenfolgeabhängigkeit: Die Stammdaten-Jobs für Länder (110),
Rabattgruppen (125) und Verkäufer (130) müssen **vor** den Firmen-Jobs laufen — sonst
läuft der Lookup ins Leere und das Feld bleibt in CE leer.

</details>

---

Section pages:

- [Firmen aus Business Central übernehmen](/docs/mapping/firma/bcaccounts/): Neue und geänderte Firmen aus dem ERP erscheinen in Customer Engagement.
- [Neue Firmen nach Business Central übertragen](/docs/mapping/firma/ceaccounts/): In Customer Engagement angelegte und freigegebene Firmen werden im ERP angelegt.
- [Rückmeldung aus Business Central](/docs/mapping/firma/bcaccountsresponse/): Nach der Anlage im ERP kommen Kontaktnummer und BC System-ID zurück nach Customer Engagement.
- [Änderungen nach Business Central übertragen](/docs/mapping/firma/ceaccountupdates/): Änderungen an bereits im ERP bekannten Firmen werden von Customer Engagement nach Business Central übertragen.
- [Löschung in Business Central nachvollziehen](/docs/mapping/firma/bcaccountsdelete/): Wird eine Firma im ERP gelöscht, wird sie in Customer Engagement deaktiviert — nicht gelöscht.