Das ist eine für den Ausdruck optimierte Ansicht des gesamten Kapitels inkl. Unterseiten.
Druckvorgang starten.
Zur Standardansicht zurückkehren.
Firma
Wie Firmen zwischen Customer Engagement und Business Central abgeglichen werden — Gesamtbild und die fünf Schritte im Detail.
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:
Kontakt und Verkaufschance funktionieren nach demselben Muster.
Der Kreislauf
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 — die Firma wird angelegt |
| gefüllt | BC kennt die Firma | Änderungen nach BC — 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.
Gefüllt wird die BC System-ID nur durch die Rückmeldung aus BC
oder beim Übernehmen aus BC. 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 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 prüft nur
diese beiden Felder und erfasst den Datensatz deshalb weiterhin.
Technische Zuordnung
Jobs und Mappings dieser Kette
Beteiligte Tabellen: Dataverse account ⇄ BC API Page
singhammerITConsulting/dyce/v2.0/acdcontactscomp; Löschungen über
singhammerITConsulting/dyce/v2.0/acdlogentries.
Schlüssel je Schritt
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.
Auflösung von Referenzen (Land, Verkäufer, Rabattgruppe)
| 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.
1 - Firmen aus Business Central übernehmen
Neue und geänderte Firmen aus dem ERP erscheinen in Customer Engagement.
| |
|---|
| Richtung | Business Central → Customer Engagement |
| Wann | alle 2 Minuten |
| Betrifft | alle Firmenkontakte, die in BC seit dem letzten Lauf geändert wurden |
| Technisch | Job accountsfrombc (410), Mapping BCAccounts |
Was passiert hier?
Wird in Business Central ein Firmenkontakt angelegt oder geändert, erscheint er kurz
darauf in Customer Engagement. Existiert die Firma dort schon, werden ihre Felder
aktualisiert; existiert sie noch nicht, wird sie neu angelegt.
Wiedererkannt wird eine Firma an ihrer BC Kontaktnummer. Sie ist die Klammer
zwischen beiden Systemen — nicht der Firmenname.
Der Abgleich holt bei jedem Lauf nur, was sich seit dem letzten Mal geändert hat.
Ein Vollabgleich findet nicht statt.
Welche Felder kommen an?
| Feld in Business Central | Feld in Customer Engagement | Anmerkung |
|---|
| Nr. | BC Kontaktnummer | Erkennungsmerkmal — verbindet beide Systeme |
| id | BC System-ID | technischer Schlüssel des ERP |
| Name | Name 1 (BC) | nicht das Feld Firmenname — siehe unten |
| Name 2 | Name 2 (BC) | |
| Adresse | Straße 1 | |
| Adresse 2 | Straße 2 | |
| PLZ | Postleitzahl | |
| Ort | Ort | |
| Länder-/Regionscode | Land | wird zur Verknüpfung auf die Länderliste aufgelöst |
| Telefonnr. | Telefon | |
| E-Mail | E-Mail | |
| Homepage | Website | |
| Debitor Nr. | BC Debitorennummer | nur aus BC — CE ändert das nie |
| Kreditor Nr. | BC Kreditorennummer | nur aus BC |
| Debitorrabattgruppe | Debitorrabattgruppe | nur aus BC, als Verknüpfung |
| Verkäufercode | Verkäufer (BC) | wird zur Verknüpfung auf den Verkäufer aufgelöst |
| Unternehmensname | Übergeordnete Firma | als Verknüpfung, siehe unten |
| — | Sync zu BC | wird automatisch auf „Ja" gesetzt |
Worauf zu achten ist
Der Firmenname wird nicht überschrieben
Der Name aus BC landet im Feld Name 1 (BC) — nicht im Standardfeld Firmenname.
Was in CE als Firmenname gepflegt ist, bleibt also unangetastet. Das ist gewollt: In CE
darf der geläufige Marktname stehen, in BC der vollständige Name aus dem
Handelsregister.
Die Firma wird automatisch für BC freigegeben
Das Feld Sync zu BC wird auf „Ja" gesetzt. Das ist folgerichtig — die Firma
existiert im ERP ja bereits — hat aber eine Konsequenz: Ab sofort werden auch
Änderungen aus CE zurück nach BC übertragen, und die Kontakte dieser Firma dürfen
freigegeben werden.
Vier Felder kommen nur aus BC
Debitornummer, Kreditornummer, Debitorrabattgruppe und die übergeordnete Firma sind
ERP-Daten. Sie werden nie von CE nach BC zurückgeschrieben. Eine Änderung in CE hat
keine Wirkung und wird beim nächsten Abgleich überschrieben.
Verknüpfungen brauchen aktuelle Stammdaten
Land, Verkäufer und Debitorrabattgruppe kommen aus BC als Kürzel und werden in CE zu
echten Verknüpfungen aufgelöst. Fehlt das passende Stammdatum in CE — etwa ein neu in
BC angelegter Verkäufer —, bleibt das Feld an der Firma leer. Die Stammdatenlisten
werden vor den Firmen abgeglichen, sodass das normalerweise innerhalb desselben Laufs
zusammenfindet.
Firmen sind nie ihre eigene übergeordnete Firma
In Business Central trägt ein Firmenkontakt sich selbst als Unternehmen ein. Ohne
Sonderbehandlung entstünde in CE eine Firma, die auf sich selbst verweist. Der Abgleich
erkennt diesen Fall und lässt das Feld Übergeordnete Firma dann leer.
Technische Details
Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und
Transformationen steht unter
Technisches Mapping → accountsfrombc.
2 - Neue Firmen nach Business Central übertragen
In Customer Engagement angelegte und freigegebene Firmen werden im ERP angelegt.
| |
|---|
| Richtung | Customer Engagement → Business Central |
| Wann | alle 2 Minuten |
| Betrifft | Firmen, die freigegeben sind und in BC noch nicht existieren |
| Technisch | Job accountsnewfromce (220), Mapping CEAccounts |
Was passiert hier?
Der Vertrieb legt eine Firma in Customer Engagement an. Zunächst bleibt sie dort — das
ERP erfährt nichts davon. Erst wenn das Feld Sync zu BC auf „Ja" gesetzt wird, wird
die Firma beim nächsten Lauf in Business Central angelegt.
Zwei Bedingungen müssen gleichzeitig erfüllt sein:
- Sync zu BC steht auf „Ja"
- das Feld BC System-ID ist noch leer — BC kennt die Firma also noch nicht
Ist die BC System-ID bereits gefüllt, greift stattdessen
Änderungen nach BC.
Unmittelbar nach dem Anlegen läuft die Rückmeldung aus BC und
trägt Kontaktnummer und BC System-ID in CE nach. Erst danach gilt die Firma als
„in BC angekommen".
flowchart LR
A["Firma in CE angelegt"] --> B{"Sync zu BC<br/>= Ja?"}
B -->|nein| C["nichts passiert"]
B -->|ja| D{"BC System-ID<br/>leer?"}
D -->|nein| E["Änderungen nach BC<br/>greift stattdessen"]
D -->|ja| F["Firma wird in BC angelegt"]
F --> G["Rückmeldung aus BC<br/>füllt Kontaktnummer<br/>und BC System-ID"]Welche Felder gehen nach BC?
| Feld in Customer Engagement | Feld in Business Central | Anmerkung |
|---|
| Name 1 (BC) | Name | nicht das Feld Firmenname |
| Name 2 (BC) | Name 2 | |
| Straße 1 | Adresse | |
| Straße 2 | Adresse 2 | |
| Postleitzahl | PLZ | |
| Ort | Ort | |
| Land | Länder-/Regionscode | die Verknüpfung wird zum BC-Kürzel aufgelöst |
| Telefon | Telefonnr. | |
| E-Mail | E-Mail | |
| Website | Homepage | |
| Verkäufer (BC) | Verkäufercode | die Verknüpfung wird zum BC-Kürzel aufgelöst |
| (Firma-Datensatz) | Dataverse Id | technische Klammer, siehe unten |
| — | Kontaktart | fest auf „Company" |
| — | Anredecode | fest auf „MANDANT" |
Worauf zu achten ist
Der Name muss in „Name 1 (BC)" stehen
Übertragen wird Name 1 (BC), nicht das Standardfeld Firmenname. Ist Name 1 (BC)
leer, kommt die Firma ohne Namen in BC an. Wer eine Firma für BC freigibt, sollte dieses
Feld also gefüllt haben.
Debitornummer und Rabattgruppe werden nicht mitgeschickt
Debitornummer, Kreditornummer, Debitorrabattgruppe und die übergeordnete Firma werden
nicht nach BC übertragen. Diese Daten entstehen im ERP und fließen nur von dort nach
CE zurück. Was in CE in diesen Feldern steht, spielt für die Übertragung keine Rolle.
Kontaktart und Anrede werden nur einmal gesetzt
Beim Anlegen wird die Kontaktart fest auf „Company" gesetzt, damit BC den Datensatz als
Firmenkontakt und nicht als Person führt; der Anredecode wird auf „MANDANT" gesetzt.
Beide Felder werden später nie wieder angefasst — eine spätere Änderung in BC bleibt
also erhalten.
Doppelte Anlage ist ausgeschlossen
Läuft der Abgleich zweimal, bevor die Rückmeldung eingetroffen ist, entsteht in BC
trotzdem keine zweite Firma. Der Datensatz wird über die in BC hinterlegte Dataverse Id
wiedererkannt.
Erst die Firma, dann der Kontakt
Ein Kontakt kann in BC nur angelegt werden, wenn seine Firma dort bereits existiert.
Die Freigabe eines Kontakts wird deshalb abgelehnt, solange die BC System-ID seiner Firma
leer ist — siehe Freigabe nach Business Central.
Technische Details
Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und
Transformationen steht unter
Technisches Mapping → accountsnewfromce.
3 - Rückmeldung aus Business Central
Nach der Anlage im ERP kommen Kontaktnummer und BC System-ID zurück nach Customer Engagement.
| |
|---|
| Richtung | Business Central → Customer Engagement |
| Wann | unmittelbar nach jeder Neuanlage — kein eigener Zeitplan |
| Betrifft | genau die Firmen, die gerade in BC angelegt wurden |
| Technisch | Job accountsresponsefrombc (221), Mapping BCAccountsResponse |
Was passiert hier?
Wenn eine Firma neu nach BC übertragen wird, vergibt Business Central
dabei zwei Werte, die Customer Engagement noch nicht kennen kann:
- die BC Kontaktnummer aus dem Nummernkreis des ERP
- die BC System-ID, den technischen Schlüssel des Datensatzes
Dieser Schritt trägt beides in CE nach. Er läuft direkt im Anschluss an die Anlage und
wertet dabei die Antwort von Business Central aus — es ist keine erneute Abfrage.
sequenceDiagram
participant CE as Customer Engagement
participant BC as Business Central
CE->>BC: neue Firma anlegen
BC-->>CE: Antwort mit Kontaktnummer und BC System-ID
Note over CE: Rückmeldung trägt beides<br/>an der Firma nach
Warum das der wichtigste Schritt der Kette ist
Die BC System-ID ist mehr als eine technische Kennung — sie ist der Nachweis, dass die
Firma im ERP angekommen ist. Solange sie leer ist, gilt die Firma als „noch nicht in
BC". Erst wenn sie gefüllt ist, ändert sich das Verhalten der gesamten Kette:
| vorher | nachher |
|---|
| BC Kontaktnummer | leer | gefüllt |
| BC System-ID | leer | gefüllt |
| Zuständig für Übertragungen | Neu nach BC | Änderungen nach BC |
| Kontakte dieser Firma | dürfen nicht freigegeben werden | dürfen freigegeben werden |
Genau darauf baut die Freigaberegel auf: Ein gesetztes Häkchen bei Sync zu BC bedeutet
nur „soll übertragen werden". Eine gefüllte BC System-ID bedeutet „ist übertragen".
Siehe Freigabe nach Business Central.
Welche Felder kommen zurück?
| Feld in Business Central | Feld in Customer Engagement |
|---|
| Nr. | BC Kontaktnummer |
| id | BC System-ID |
Mehr nicht. Alle fachlichen Daten hat CE ja bereits — sie wurden gerade erst
dorthin übertragen.
Worauf zu achten ist
Es dauert zwei Durchläufe
Anlage und Rückmeldung gehören zusammen, laufen aber nacheinander. Wer eine Firma
freigibt und gleich danach in CE nachsieht, findet die BC System-ID unter Umständen noch
nicht — und kann die zugehörigen Kontakte deshalb noch nicht freigeben. Nach spätestens
zwei Durchläufen ist der Zustand stabil.
Bleibt die Rückmeldung aus, hängt die Firma fest
Ohne gefüllte BC System-ID gilt die Firma weiterhin als „nicht in BC vorhanden". Sie
würde beim nächsten Lauf erneut zur Anlage angeboten — dass dabei keine Dublette
entsteht, verhindert die Wiedererkennung über die Dataverse Id. Bleibt der Zustand über
mehrere Läufe bestehen, ist das ein Hinweis auf einen Fehler bei der Übertragung und
sollte geprüft werden.
Technische Details
Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und
Transformationen steht unter
Technisches Mapping → accountsresponsefrombc.
4 - Änderungen nach Business Central übertragen
Änderungen an bereits im ERP bekannten Firmen werden von Customer Engagement nach Business Central übertragen.
| |
|---|
| Richtung | Customer Engagement → Business Central |
| Wann | alle 2 Minuten |
| Betrifft | freigegebene Firmen, die in BC bereits existieren |
| Technisch | Job accountupdatesfromce (520), Mapping CEAccountUpdates |
Was passiert hier?
Sobald eine Firma in beiden Systemen existiert, hält dieser Schritt Business Central auf
dem Stand von Customer Engagement. Er ist das Gegenstück zu
Aus BC übernehmen — dieselben Felder, nur andersherum.
Erfasst werden Firmen, bei denen beides zutrifft:
- Sync zu BC steht auf „Ja"
- das Feld BC System-ID ist gefüllt — BC kennt die Firma also
Ist die BC System-ID leer, greift stattdessen Neu nach BC. Die beiden
Schritte schließen sich gegenseitig aus.
Welche Felder gehen nach BC?
| Feld in Customer Engagement | Feld in Business Central |
|---|
| Name 1 (BC) | Name |
| Name 2 (BC) | Name 2 |
| Straße 1 | Adresse |
| Straße 2 | Adresse 2 |
| Postleitzahl | PLZ |
| Ort | Ort |
| Land | Länder-/Regionscode |
| Telefon | Telefonnr. |
| E-Mail | E-Mail |
| Website | Homepage |
| Verkäufer (BC) | Verkäufercode |
Elf fachliche Felder — dieselben, die auch in die Gegenrichtung laufen.
Worauf zu achten ist
Es gibt keine Konfliktauflösung
Diese elf Felder werden in beide Richtungen abgeglichen. Wird dieselbe Firma
gleichzeitig in CE und in BC geändert, gewinnt schlicht der spätere Schreibvorgang. Ein
Abgleich Feld für Feld oder eine Warnung findet nicht statt.
Anrede und Kontaktart werden bewusst nicht überschrieben
Anders als beim Anlegen schickt dieser Schritt Kontaktart und Anredecode nicht mit.
Wird die Anrede in BC angepasst, bleibt sie erhalten. Würde sie mitgeschickt, würde sie
bei jedem Lauf wieder auf den Vorgabewert zurückgesetzt.
ERP-Felder bleiben unberührt
Debitornummer, Kreditornummer, Debitorrabattgruppe und übergeordnete Firma werden nicht
zurückgeschrieben. Wer diese Felder in CE ändert, ändert nichts in BC — und die
Änderung wird beim nächsten Abgleich aus BC überschrieben.
Deaktivierte Firmen bleiben erfasst
Wurde eine Firma in BC gelöscht und daraufhin in CE
deaktiviert, bleiben Freigabe und BC System-ID stehen. Da dieser
Schritt nur diese beiden Felder prüft, fällt der Datensatz weiterhin in seinen
Zuständigkeitsbereich.
Änderungserkennung über Change Tracking
Anders als die Schritte aus BC arbeitet dieser Schritt nicht mit einem Watermark-Feld,
sondern mit dem Change Tracking von Dataverse: Er erhält von der Plattform nur die
seit dem letzten Lauf geänderten Datensätze und filtert diese zusätzlich über Freigabe
und BC System-ID.
Technische Details
Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und
Transformationen steht unter
Technisches Mapping → accountupdatesfromce.
5 - Löschung in Business Central nachvollziehen
Wird eine Firma im ERP gelöscht, wird sie in Customer Engagement deaktiviert — nicht gelöscht.
| |
|---|
| Richtung | Business Central → Customer Engagement |
| Wann | alle 2 Minuten |
| Betrifft | Firmen, die in BC gelöscht wurden |
| Technisch | Job accountsfrombcdelete (420), Mapping BCAccountsDelete |
Was passiert hier?
Wird eine Firma in Business Central gelöscht, wird sie in Customer Engagement
deaktiviert — sie bleibt also erhalten und wird nur inaktiv gesetzt. Als Statusgrund
wird festgehalten, dass die Löschung aus BC kam.
flowchart LR
A["Firma in BC gelöscht"] --> B["Eintrag im<br/>Änderungsprotokoll von BC"]
B --> C["Abgleich liest das Protokoll"]
C --> D["Firma in CE wird<br/><b>deaktiviert</b>"]
Der Weg über das Änderungsprotokoll ist notwendig, weil eine gelöschte Firma in der
normalen Schnittstelle nicht mehr auftaucht — sie könnte durch Abgleich gar nicht mehr
gefunden werden. Das Protokoll hält dagegen fest, dass etwas gelöscht wurde.
Wiedererkannt wird die Firma über die BC System-ID — anders als beim
Übernehmen aus BC, das über die BC Kontaktnummer geht. Das Protokoll
kennt nur die System-ID des gelöschten Datensatzes.
Warum nicht gelöscht wird
An einer Firma hängen Kontakte, Verkaufschancen, Angebote und Aktivitäten. Ein hartes
Löschen würde diese Historie zerstören oder von Dataverse ohnehin abgelehnt. Die Firma
inaktiv zu setzen erhält den Zusammenhang und macht zugleich sichtbar, dass sie im ERP
nicht mehr existiert.
Anders verhalten sich Angebotspositionen: Sie werden tatsächlich gelöscht, weil sie
vollständig aus BC nachgeführt werden. Angebote selbst werden storniert. Siehe
Datenfluss.
Was sich an der Firma ändert
| Feld | Wert danach |
|---|
| Status | Inaktiv |
| Statusgrund | „in Business Central gelöscht" |
Alle übrigen Felder bleiben unverändert — auch Sync zu BC und die
BC System-ID.
Worauf zu achten ist
Die Firma bleibt im Abgleich nach BC
Da Freigabe und BC System-ID stehen bleiben, fällt die deaktivierte Firma weiterhin in
den Zuständigkeitsbereich von Änderungen nach BC — dieser Schritt
prüft nur diese beiden Felder, nicht den Status.
Reaktivieren geht nicht automatisch
Wird die Firma in BC erneut angelegt, bekommt sie dort eine neue System-ID und
Kontaktnummer. Sie kommt dann als neue Firma nach CE — die deaktivierte bleibt
daneben stehen. Eine automatische Zusammenführung gibt es nicht.
Dasselbe Verhalten bei Kontakt und Produkt
Kontakte (contactsfrombcdelete, 440) und Produkte (productsfrombcdelete, 450) werden
nach demselben Muster deaktiviert statt gelöscht.
Technische Details
Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und
Transformationen steht unter
Technisches Mapping → accountsfrombcdelete.