Anleitungen

• 1: Architektur-Überblick
• 2: Datenmodell
• 2.1: Stammdaten aus Business Central
• 2.2: Firma, Kontakt und Lead
• 2.3: Verkaufschance, Angebot und Produkt
• 2.4: Abonnements und externe Stakeholder
• 2.5: Anrede, Titel und Sprache
• 2.6: Wertelisten
• 3: Business-Logik
• 3.1: Freigabe nach Business Central
• 3.2: Anrede und Sprache
• 3.3: Beträge und Margen
• 3.4: Abschluss von Angebot und Verkaufschance
• 3.5: Stammdaten und Anzeige
• 3.6: Konfiguration
• 3.7: Berechtigungen
• 3.8: Meldungen
• 4: Mapping
• 4.1: Datenfluss
• 4.2: Stammdaten
• 4.2.1: Wertelisten aus Business Central übernehmen
• 4.2.2: Verkäufer aus Business Central übernehmen
• 4.2.3: Produkte deaktivieren
• 4.3: Firma
• 4.3.1: Firmen aus Business Central übernehmen
• 4.3.2: Neue Firmen nach Business Central übertragen
• 4.3.3: Rückmeldung aus Business Central
• 4.3.4: Änderungen nach Business Central übertragen
• 4.3.5: Löschung in Business Central nachvollziehen
• 4.4: Kontakt
• 4.4.1: Kontakte aus Business Central übernehmen
• 4.4.2: Neue Kontakte nach Business Central übertragen
• 4.4.3: Rückmeldung aus Business Central
• 4.4.4: Änderungen nach Business Central übertragen
• 4.4.5: Löschung in Business Central nachvollziehen
• 4.5: Verkaufschance
• 4.5.1: Neue Verkaufschancen nach Business Central übertragen
• 4.5.2: Rückmeldung aus Business Central
• 4.5.3: Kalkulationselemente aus Business Central übernehmen
• 4.5.4: Neue Positionen nach Business Central übertragen
• 4.5.5: Rückmeldung der Positionen aus Business Central
• 4.5.6: Positionsänderungen nach Business Central übertragen
• 4.6: Angebot
• 4.6.1: Angebote aus Business Central übernehmen
• 4.6.2: Angebotspositionen aus Business Central übernehmen
• 4.6.3: Gewonnene Angebote aus Business Central
• 4.6.4: Angebotspositionen löschen
• 4.6.5: In BC gelöschte Angebote stornieren
• 4.7: Abonnement
• 4.7.1: Abonnements aus Business Central übernehmen
• 4.7.2: Abonnementzeilen aus Business Central übernehmen
• 4.8: Technisches Mapping
• 4.8.1: 110 · countriesfrombc
• 4.8.2: 115 · languagesfrombc
• 4.8.3: 120 · salutationsfrombc
• 4.8.4: 125 · customerdiscountgroupsfrombc
• 4.8.5: 130 · salespersonsfrombc
• 4.8.6: 135 · positionsfrombc
• 4.8.7: 190 · opportunityelementsfrombc
• 4.8.8: 220 · accountsnewfromce
• 4.8.9: 221 · accountsresponsefrombc
• 4.8.10: 240 · contactsnewfromce
• 4.8.11: 241 · contactsresponsefrombc
• 4.8.12: 260 · opportunitiesnewfromce
• 4.8.13: 261 · opportunitiesresponsefrombc
• 4.8.14: 410 · accountsfrombc
• 4.8.15: 420 · accountsfrombcdelete
• 4.8.16: 430 · contactsfrombc
• 4.8.17: 440 · contactsfrombcdelete
• 4.8.18: 450 · productsfrombcdelete
• 4.8.19: 520 · accountupdatesfromce
• 4.8.20: 530 · contactupdatesfromce
• 4.8.21: 550 · serviceobjectsfrombc
• 4.8.22: 560 · servicecommitmentsfrombc
• 4.8.23: 610 · salesquotesfrombc
• 4.8.24: 620 · salescalculationelementsfrombc
• 4.8.25: 621 · salescalculationelementsfrombcdelete
• 4.8.26: 625 · activatesalesquotesfrombc
• 4.8.27: 690 · salesquotesfrombcdelete
• 4.8.28: 710 · opportunityproductsnewfromce
• 4.8.29: 750 · opportunityproductsupdatesfromce
• 4.8.30: 760 · opportunityproductsresponsefrombc

1 - Architektur-Überblick

Die beteiligten Systeme

dsyr.SalesCentral ist keine eigenständige Anwendung, sondern eine Erweiterung innerhalb von Dynamics 365. Drei Bausteine arbeiten zusammen:

flowchart LR
    subgraph CE["Customer Engagement (Sales)"]
        F["Formularlogik"]
        S["Serverlogik"]
        F --> S
    end
    subgraph BC["Business Central"]
        B["Angebote, Abonnements,<br/>Debitoren, Kontakte, Artikel"]
    end
    S -- "freigegebene Datensätze" --> DB["dsyr.DataBridge"]
    DB -- "Stammdaten und Rückmeldungen" --> S
    DB <--> B

Wer führt welche Daten?

Die Arbeitsteilung ist bewusst eindeutig:

• Aus Business Central nach CE kommen die kaufmännisch verbindlichen Daten: Angebote und Angebotspositionen, Abonnements und Abonnementzeilen sowie die Stammdaten — Länder, Sprachen, Anreden, Verkäufer, Rabattgruppen, Artikel. Dazu die Rückmeldungen zu übertragenen Firmen, Kontakten und Verkaufschancen. Diese Daten werden in CE nicht gepflegt; sie werden bei der nächsten Übertragung überschrieben.
• Aus CE nach Business Central gehen die im Vertrieb neu entstandenen Firmen, Kontakte und Verkaufschancen — aber nur, wenn sie ausdrücklich dafür freigegeben wurden.

Für Angebote und Abonnements heißt das konkret: Sie werden in Business Central kalkuliert, versioniert und abgerechnet. In Customer Engagement stehen sie zur Ansicht bereit, damit der Vertrieb Volumen, Laufzeiten und Kündigungsfristen im Blick hat — geändert werden sie dort nicht.

Die Freigabe steuert das Feld Sync zu BC (wysa_sync2bc). Es ist der zentrale Schalter der Integration und in der Business-Logik ausführlich beschrieben.

Wo die Lösung eingreift

dsyr.SalesCentral wirkt auf vier Ebenen. Die Unterscheidung ist wichtig, um zu verstehen, warum manche Regeln auch dann greifen, wenn nicht über ein Formular gearbeitet wird.

1. Formularlogik — läuft im Browser, während ein Datensatz bearbeitet wird. Sie blendet Felder ein und aus, sperrt Felder, die Business Central führt, und meldet Probleme früh und verständlich. Sie wirkt nur im Formular.
2. Serverlogik — läuft in der Plattform, unabhängig vom Weg des Datensatzes. Sie greift ebenso bei Datenimporten, Massenänderungen, Power Automate und Schnittstellenaufrufen. Alle verbindlichen Regeln liegen hier. Sie laufen synchron: Verstößt ein Datensatz gegen eine Regel, wird das Speichern mit einer Meldung abgebrochen.
3. Konfiguration — Umgebungsvariablen und Einstellungen steuern das Verhalten je Umgebung, ohne dass etwas angepasst werden muss. Siehe Konfiguration.
4. Übertragung — die dsyr.DataBridge liest die freigegebenen Datensätze, überträgt sie und schreibt die Schlüssel aus Business Central zurück.

Formular- und Serverlogik prüfen an einigen Stellen dasselbe. Das ist beabsichtigt: Im Formular soll ein Fehler früh sichtbar werden, verbindlich entschieden wird er auf dem Server.

Einordnung der Lösung

Alle Erweiterungen dieser Lösung — Tabellen, Felder, Wertelisten — tragen das Präfix wysa_. Wo der Standard endet und die Erweiterung beginnt, ist damit an jedem Feld erkennbar.

2 - Datenmodell

Das Datenmodell von dsyr.SalesCentral folgt einem einfachen Grundsatz: Der Standard bleibt Standard. Firma, Kontakt, Lead, Verkaufschance und Angebot sind die bekannten Tabellen aus Dynamics 365 Sales. Ergänzt wurden sie um Felder, die für die Zusammenarbeit mit Business Central und für das Abonnement- und Ausschreibungsgeschäft nötig sind. Zusätzlich kommen eigene Tabellen hinzu, für die es im Standard keine Entsprechung gibt.

Wiederkehrende Muster

Wer die folgenden drei Muster kennt, findet sich in jeder Tabelle zurecht:

• Präfix wysa_ — jedes Feld und jede Tabelle aus dieser Lösung trägt es. Alles ohne Präfix ist unveränderter Microsoft-Standard.
• Schlüsselfelder zu Business Central — wysa_bcSystemId enthält die technische ID des Datensatzes in Business Central, die Felder wysa_bc…Number (etwa wysa_bcCustomerNumber, wysa_bcContactNumber, wysa_bcOpportunityNumber) die fachliche Nummer. Sind sie gefüllt, ist der Datensatz in Business Central angekommen. Genau daran hängt die Freigabelogik.
• Währungsfelder — zu jedem Betragsfeld gehört technisch ein zweites Feld mit der Endung _Base. Es enthält denselben Betrag in der Basiswährung der Organisation und wird von der Plattform automatisch gefüllt.

Aufbau dieses Kapitels

2.1 - Stammdaten aus Business Central

Diese Tabellen sind Nachschlagewerte. Sie stehen als Auswahlfelder auf Firma, Kontakt, Lead, Verkaufschance, Angebot und Produkt zur Verfügung und sorgen dafür, dass beide Systeme dieselben Begriffe verwenden. Jede von ihnen führt das Feld wysa_bcSystemId mit der Herkunfts-ID aus Business Central.

Die Tabellen im Überblick

Ausgewählte Felder

Mandant (BC) — wysa_bcClient

Verkäufer (BC) — wysa_bcSalesPerson

Die Zuordnung zum CRM-Benutzer erfolgt automatisch über die E-Mail-Adresse — siehe Stammdaten und Anzeige.

Land — wysa_Country

Das Land wird auf Firma, Kontakt und Lead als Verweis gepflegt. Weil Business Central an dieser Stelle einen Klartext erwartet, füllt die Serverlogik zusätzlich das Standard-Textfeld address1_country — siehe Stammdaten und Anzeige.

Position (BC) — wysa_bcPosition

2.2 - Firma, Kontakt und Lead

Firma (Account), Kontakt (Contact) und Lead sind unveränderte Standardtabellen. Ergänzt wurden Felder für die Schlüssel aus Business Central, für die Freigabe zur Übertragung und für die Anredebildung.

Firma

Eine Firma entspricht in Business Central je nach Ausprägung einem Debitor, einem Kreditor oder einem Kontakt. Dafür gibt es drei getrennte Nummernfelder.

Name 1 und Name 2 sind die Felder, die die Schnittstelle mit Business Central austauscht. Der einzeilige Firmenname des CRM-Standards wird daraus zusammengesetzt und ist auf dem Formular schreibgeschützt — siehe Stammdaten und Anzeige.

Kontakt

Wie die Anredefelder zusammenwirken, ist unter Anrede, Titel und Sprache und in der Business-Logik beschrieben.

Lead

Der Lead spiegelt bewusst die Felder von Firma und Kontakt. Grund ist die Qualifizierung: Wird aus einem Lead eine Firma, ein Kontakt und eine Verkaufschance, überträgt eine hinterlegte Feldzuordnung die erfassten Werte automatisch in die neuen Datensätze. Ohne die gespiegelten Felder ginge diese Information verloren.

Leadquelle — wysa_LeadSource

Eine eigene Tabelle als Katalog der Herkunftskanäle. Sie steht sowohl am Lead als auch an der Verkaufschance zur Verfügung, sodass die Herkunft über die Qualifizierung hinaus auswertbar bleibt.

2.3 - Verkaufschance, Angebot und Produkt

Verkaufschance

Der Standardwert Voraussichtlicher Umsatz (estimatedvalue) und die Voraussichtliche Marge (wysa_EstimatedMargin) werden je nach Konfiguration manuell erfasst oder automatisch berechnet — aus den Verkaufschancenprodukten oder aus dem führenden Angebot. Beide sind getrennt konfigurierbar. Siehe Beträge und Margen.

Ausschreibungen

Steht der Vertriebsprozess auf Ausschreibung, wird ein zusätzlicher Block sichtbar. Er bildet die Besonderheiten öffentlicher Vergabeverfahren ab.

Verkaufschancenprodukt

Angebot

Angebotsposition

Gesamtbetrag und Marge des Angebots werden aus den Positionen aufsummiert.

Produkt

Produkte werden aus Business Central übertragen — nicht der gesamte Artikelstamm, sondern die dort als Verkaufschancen-Elemente gepflegten Positionen. Übertragen wird bewusst nur ein schmaler Satz identifizierender Felder; die vertriebliche Klassifizierung wird in Customer Engagement gepflegt.

Aus Business Central übertragen

Einheitengruppe und Standardeinheit werden beim Anlegen automatisch gesetzt, damit das Produkt in Customer Engagement verwendbar ist.

In Customer Engagement gepflegt

2.4 - Abonnements und externe Stakeholder

Abonnement — wysa_bcServiceObject

Ein Abonnement bildet eine wiederkehrend abgerechnete Leistung ab: eine Lizenz, einen Cloud-Service, einen Wartungsvertrag. Die Datensätze entstehen in Business Central und werden nach Customer Engagement übertragen, damit der Vertrieb Bestand, Laufzeiten und Kündigungsfristen im Blick hat.

Bemerkenswert ist die Trennung zweier Rollen: Rechnungsempfänger ist, wer bezahlt, Leistungsnehmer, wer die Leistung nutzt. In Konzernstrukturen sind das unterschiedliche Firmen.

Abonnements können automatisch Leads erzeugen — etwa vor Ablauf einer Laufzeit. Der Lead trägt dann im Feld wysa_Abonnement den Verweis auf sein Ursprungsabonnement.

Abonnementzeile — wysa_bcServiceObjectCommitment

Die Zeile trägt die kaufmännischen Details. Ein Abonnement kann mehrere Zeilen mit unterschiedlichen Laufzeiten und Abrechnungsrhythmen haben.

Externer Stakeholder — wysa_OpportunityStakeholder

Der Standard kennt Stakeholder als Verbindungen zu Kontakten des Kunden. Diese Tabelle ergänzt bewusst eine zweite, davon getrennte Sicht: externe Beteiligte, die weder zum Kunden noch zum eigenen Unternehmen gehören — Implementierungspartner, beratende Systemhäuser, externe Projektleiter oder die Vergabestelle einer Ausschreibung.

Der Anzeigename des Datensatzes wird automatisch aus Kontakt und Firma gebildet. Wird ein Kontakt gewählt, füllt das Formular die Firma vor.

2.5 - Anrede, Titel und Sprache

Korrekte Anreden sind in der Korrespondenz kein Detail, sondern eine Frage der Verlässlichkeit — und in mehrsprachigen Kundenbeziehungen nicht trivial. Die Lösung erzeugt Anredetexte deshalb regelbasiert aus vier Bestandteilen: Geschlecht, Titel, Sprache und einer Anredevorlage.

flowchart LR
    G["Geschlecht<br/>(wysa_gender)"] --> V["Anredevorlage<br/>(wysa_salutation)"]
    T["Titel<br/>(wysa_title)"] --> V
    S["Sprache<br/>(wysa_language)"] --> V
    V --> A["Formelle / informelle /<br/>persönliche Anrede"]
    A --> P["Bevorzugte Anrede"]

Anredevorlage — wysa_salutation

Die Vorlage bestimmt, wie ein Anredetext aufgebaut wird. Pro Sprache und Geschlecht gibt es je eine Vorlage für die formelle, informelle und persönliche Form.

Titel — wysa_title

Sprache — wysa_language

Die Sprache wird an Kontakt und Lead gepflegt. Ist keine gesetzt, kann je Anwendung eine Standardsprache konfiguriert werden — siehe Konfiguration.

Anrede (BC) — wysa_bcSalutation

Business Central führt eine eigene Anredetabelle. Sie wird nach Customer Engagement übertragen und am Kontakt im Feld wysa_SalutationBcId gesetzt.

Geschlecht und BC-Anrede werden in beide Richtungen synchron gehalten: Wird das eine gesetzt, ergänzt die Serverlogik das andere. Details unter Anrede und Sprache.

2.6 - Wertelisten

Auswahlfelder (Optionssets) legen fest, welche Werte erfasst werden können. Die folgenden Listen sind global definiert und werden an mehreren Stellen verwendet. Änderungen an ihnen wirken sich überall aus, wo das Feld eingesetzt wird.

Integration und Klassifizierung

Person und Anrede

Vertriebsprozess und Ausschreibung

Produkt und Abrechnung

Zusätzlich gibt es am Abonnement das tabellenbezogene Auswahlfeld Abonnementart (wysa_SubscriptionType). Es steuert, welche Felder auf dem Formular sichtbar sind, und ist nur dort verwendbar.

3 - Business-Logik

dsyr.SalesCentral nimmt Anwendern Arbeit ab und verhindert Zustände, die in Business Central zu Fehlern führen würden. Dieses Kapitel beschreibt, was automatisch passiert.

Zwei Ebenen, ein Ergebnis

Beide prüfen an einigen Stellen dasselbe. Der Unterschied ist die Reichweite: Die Formularlogik hilft im Formular, die Serverlogik gilt immer — auch bei Datenimporten, Massenänderungen, Power Automate und Schnittstellenaufrufen. Alles, was verbindlich sein muss, liegt deshalb auf dem Server.

Die Serverregeln laufen synchron. Verstößt eine Änderung gegen eine Regel, wird der Speichervorgang mit einer Meldung abgebrochen; es entsteht kein halb gültiger Zustand. Die Meldungen sind unter Meldungen erklärt.

Die Themen

3.1 - Freigabe nach Business Central

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:

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

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. 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:

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.

3.2 - Anrede und Sprache

Anredetexte entstehen automatisch

Sobald Vorname, Nachname, Geschlecht, Titel oder Sprache eines Kontakts oder Leads gesetzt oder geändert werden, erzeugt die Lösung die Anredetexte neu:

• Formelle Anrede — für offizielle Korrespondenz
• Informelle Anrede — für den vertrauten Schriftverkehr
• Persönliche Anrede — für die direkte Ansprache

Welche dieser Formen tatsächlich verwendet wird, bestimmt das Feld Bevorzugte Anredeform (wysa_PreferredSalutationType). Der gewählte Text wird in das Feld Bevorzugte Anrede übernommen — dieses eine Feld ist es, das in Vorlagen und Serienbriefen verwendet wird.

Wird als Anredeform Individuell gewählt, tritt die Automatik zurück: Das Feld Individuelle Anrede wird eingeblendet, der dort erfasste Text hat Vorrang. Das ist der Ausweg für Sonderfälle, die keine Regel abbilden kann.

Grundlage der Textbildung sind die Anredevorlagen je Sprache und Geschlecht — siehe Anrede, Titel und Sprache.

Geschlecht und BC-Anrede halten sich gegenseitig aktuell

Customer Engagement arbeitet mit dem Feld Geschlecht, Business Central mit einem Anredeschlüssel. Beide beschreiben dasselbe, und beide Systeme dürfen die Information liefern. Deshalb wird sie in beide Richtungen abgeglichen:

• Wird das Geschlecht gesetzt oder geändert, ermittelt die Lösung den passenden BC-Anredeschlüssel und trägt ihn ein.
• Kommt aus Business Central ein Anredeschlüssel, wird daraus das Geschlecht abgeleitet.

Der Anwender pflegt also nur eine der beiden Angaben; die andere ergibt sich. Findet sich zu einem Wert keine Entsprechung, wird die Verarbeitung mit einer Meldung abgebrochen, statt einen falschen Wert zu setzen.

Standardsprache bei neuen Kontakten und Leads

Wird ein Kontakt oder Lead ohne Sprache angelegt, kann automatisch eine Standardsprache gesetzt werden. Das erspart die Pflege im Regelfall, ohne die manuelle Auswahl zu verhindern.

Die Standardsprache wird über die Einstellung wysa_DefaultLanguageGUID konfiguriert und lässt sich je Anwendung unterschiedlich festlegen. Ein Vertriebsteam, das ausschließlich im deutschsprachigen Raum arbeitet, kann so eine andere Vorbelegung erhalten als ein international arbeitendes. Der Wert 0 schaltet die Vorbelegung ab. Details unter Konfiguration.

3.3 - Beträge und Margen

Angebotssumme und Marge

Die Beträge eines Angebots werden nicht erfasst, sondern aus den Positionen berechnet. Sobald eine Angebotsposition angelegt, geändert oder gelöscht wird, aktualisiert die Lösung am Angebot:

Weil die Berechnung serverseitig läuft, stimmen die Summen auch dann, wenn Positionen über die Übertragung aus Business Central entstehen — nicht nur bei manueller Erfassung.

Voraussichtlicher Umsatz und voraussichtliche Marge

An der Verkaufschance gibt es zwei berechenbare Kennzahlen, die getrennt voneinander konfiguriert werden:

Die Trennung erlaubt unterschiedliche Arbeitsweisen: Der Umsatz kann bewusst Vertriebsschätzung bleiben, während die Marge aus den Positionen gerechnet wird.

Aufbau des Einstellungswerts

Beide Einstellungen erwarten eine Liste erlaubter Quellen, mit Semikolon getrennt. Jede zusätzlich aufgeführte Quelle erweitert die vorhergehende — sie ist keine Alternative, sondern eine höhere Priorität.

Welche Werte konkret herangezogen werden:

Wann neu gerechnet wird

Die Berechnung läuft serverseitig, sobald sich eine der Grundlagen ändert:

Im Formular

Ist eine Kennzahl berechnet, sperrt das Formular das zugehörige Feld — sowohl im Formularkörper als auch in der Kopfzeile der Verkaufschance. So ist erkennbar, dass der Wert abgeleitet und nicht verhandelbar eingetragen ist.

Umsatz und Marge werden dabei einzeln bewertet: Je nach Konfiguration kann das eine Feld gesperrt und das andere frei sein. Die Prüfung läuft beim Öffnen des Formulars, beim Wechsel des führenden Angebots und bei Änderungen im Produkt-Unterraster.

Das führende Angebot

Zu einer Verkaufschance können mehrere Angebote gehören — Nachverhandlungen, Alternativvarianten, korrigierte Fassungen. Kaufmännisch maßgeblich ist aber nur eines. Die Lösung setzt das Feld Führendes Angebot (wysa_LeadingQuoteId) automatisch: Es verweist auf das älteste der verknüpften Angebote.

Wird ein Angebot einer anderen Verkaufschance zugeordnet, wird auch die zuvor zugeordnete Verkaufschance korrigiert — sie erhält ihr nächstes gültiges führendes Angebot oder keins. So bleibt bei jeder Umhängeaktion auf beiden Seiten ein stimmiger Stand.

3.4 - Abschluss von Angebot und Verkaufschance

Gewinnen: Business Central gibt das Signal

Ein Angebot gilt als gewonnen, wenn es in Business Central in einen Auftrag überführt wurde. Diese Rückmeldung kommt über das Feld BC Status (wysa_BCStatus). Meldet Business Central den Wert TRANSFERRED, setzt die Lösung das Angebot in Customer Engagement automatisch auf Gewonnen.

Der Vertrieb muss den Abschluss also nicht doppelt pflegen — das führende System für den Auftrag ist Business Central, und Customer Engagement folgt.

Optional geht die Automatik einen Schritt weiter: Ist die Einstellung wysa_WinQuoteAndOpportunity aktiv, wird zusätzlich die verknüpfte Verkaufschance gewonnen. Als tatsächlicher Umsatz wird dabei der Gesamtbetrag des Angebots übernommen. Ohne diese Einstellung bleibt der Abschluss der Verkaufschance eine bewusste Handlung des Vertriebs. Siehe Konfiguration.

Verlieren: verbundene Angebote werden mitgeschlossen

Wird eine Verkaufschance auf Verloren gesetzt, schließt die Lösung alle zugehörigen Angebote ebenfalls als verloren — mit dem Grund „Automatisch geschlossen (Verloren)". Angebote im Entwurfsstatus werden dafür zunächst aktiviert, da nur aktive Angebote geschlossen werden können.

Der Zweck ist Sauberkeit der Auswertung: Ohne diesen Schritt blieben offene Angebote zu einer bereits verlorenen Verkaufschance in der Pipeline stehen und würden die Prognose verfälschen.

Die Verarbeitung erfolgt, bevor der Verlust festgeschrieben wird. Schlägt das Schließen eines Angebots fehl, wird der gesamte Vorgang abgebrochen — es entsteht kein Zustand mit verlorener Verkaufschance und offen gebliebenen Angeboten.

Angebotsklassifizierung

Beim Anlegen eines Angebots wird automatisch bestimmt, ob es sich um das Erstangebot zu einer Verkaufschance handelt oder um ein weiteres Angebot (wysa_bcQuoteClassification). Die Angabe erlaubt Auswertungen darüber, wie häufig nachverhandelt wird.

Angebots-PDF aus Business Central

Auf dem Angebotsformular steht eine Schaltfläche im Menüband bereit, die das Angebotsdokument aus Business Central anfordert und als Anlage am Angebot in Customer Engagement ablegt. Der Vertrieb erhält damit dasselbe PDF, das der Kunde bekommt, ohne das System zu wechseln.

Technisch wird dabei eine eigene Aktion (wysa_TriggerUploadQuoteDocument) aufgerufen, die den Datensatz in beiden Systemen adressiert und den Abruf anstößt.

3.5 - Stammdaten und Anzeige

Firmenname aus Name 1 und Name 2

Business Central führt Firmennamen zweizeilig, in den Feldern Name und Name 2. Genau diese beiden Felder beschreibt die Schnittstelle in beide Richtungen — sie sind in Customer Engagement als Name 1 (BC) (wysa_bcName1) und Name 2 (BC) (wysa_bcName2) abgebildet. Der einzeilige Firmenname des CRM-Standards ist an der Übertragung nicht beteiligt.

Damit er trotzdem stimmt, setzt ihn die Serverlogik zusammen: Name 1, ein Leerzeichen, Name 2 — führende und nachfolgende Leerzeichen werden entfernt, ist nur eines der beiden Felder gefüllt, steht auch nur dieses im Namen. Die Berechnung läuft, sobald eines der beiden Quellfelder angelegt oder geändert wird.

Der Firmenname lässt sich deshalb nicht frei vergeben: Auf dem Firmenformular ist er schreibgeschützt. Geändert wird an Name 1 und Name 2; der angezeigte Name folgt automatisch. Das hält CE und Business Central dauerhaft identisch.

Am Lead greift dieselbe Regel für den Firmennamen — damit der Name die Qualifizierung unverändert übersteht. Dort ist das Feld allerdings nicht schreibgeschützt: Ein manuell eingetragener Name bleibt stehen, bis Name 1 oder Name 2 geändert wird; dann wird er überschrieben.

Land als Verweis und als Text

Das Land wird auf Firma, Kontakt und Lead als Verweis auf die Ländertabelle gepflegt — das verhindert Schreibweisenvielfalt und erlaubt saubere Auswertungen. Business Central erwartet an dieser Stelle jedoch einen Klartext.

Die Lösung füllt deshalb bei jeder Änderung des Landverweises zusätzlich das Standard-Textfeld der Adresse mit dem Ländernamen. Der Anwender pflegt eine Angabe, beide Systeme erhalten die für sie passende Form.

Verkäufer und Benutzer

Kommt ein Verkäufer aus Business Central, wird er über seine E-Mail-Adresse dem passenden Benutzer in Customer Engagement zugeordnet. Die Zuordnung ist damit selbstpflegend: Neue Verkäufer erscheinen nach der nächsten Übertragung korrekt verknüpft, ohne dass jemand eine Zuordnungstabelle nachziehen muss.

Ergänzend kann der Besitzer von Firma, Verkaufschance und Angebot mit dem zugeordneten Verkäufer abgeglichen werden; gesteuert über wysa_SyncAccountOwnerWithSalesPerson.

Weitere Automatismen

Sichtbarkeiten im Formular

Formulare zeigen nur, was im jeweiligen Fall relevant ist. Das hält die Erfassungsmaske schlank, ohne Informationen zu verlieren.

3.6 - Konfiguration

Umgebungsvariablen

Umgebungsvariablen werden in der Power Platform verwaltet und unterscheiden sich typischerweise zwischen Test- und Produktivumgebung.

Verbindung zu Business Central

Verhalten

Einstellungen

Einstellungen (Settings) sind feiner steuerbar als Umgebungsvariablen: Sie können organisationsweit und abweichend je Anwendung gesetzt werden.

Quellen für Umsatz und Marge

wysa_EstimatedRevenueSource und wysa_EstimatedMarginSource sind unabhängig voneinander und erwarten dieselbe Schreibweise: eine mit Semikolon getrennte Liste erlaubter Quellen, von der niedrigsten zur höchsten Priorität.

Ausgeliefert wird der Umsatz als reine Vertriebsschätzung (UserProvided), die Marge berechnet aus den Positionen. Details unter Beträge und Margen.

Kennung der Standardsprache ermitteln

wysa_DefaultLanguageGUID erwartet die GUID eines Sprachdatensatzes. Sie lässt sich ablesen, indem der gewünschte Eintrag — etwa „Deutsch" — in der Sprachtabelle geöffnet und die GUID aus der Adresszeile des Browsers übernommen wird.

Vorrangregel

Für jede Einstellung gilt dieselbe Rangfolge — der zuletzt genannte Wert gewinnt:

Standardwert  <  organisationsweite Einstellung  <  Einstellung je Anwendung

Damit lässt sich ein organisationsweites Verhalten festlegen und für einzelne Anwendungen gezielt abweichend definieren. Genutzt wird das etwa bei der Standardsprache: Ein international arbeitendes Team erhält eine andere Vorbelegung als ein rein deutschsprachiges.

Die Rangfolge gilt gleichermaßen für die Serverlogik und für die Formularlogik — beide lesen die Einstellungen auf demselben Weg. Ein Wert, der im Formular wirkt, wirkt auch serverseitig.

3.7 - Berechtigungen

Drei Rollen, ein Prinzip

dsyr.SalesCentral liefert drei Sicherheitsrollen mit. Zwei davon sind Ergänzungsrollen, eine ist für ein technisches Konto gedacht.

Die Rollen tragen noch den historischen Produktnamen SalesConnect — das ist dieselbe Lösung wie dsyr.SalesCentral, nur die Rollennamen wurden bei der Umbenennung nicht mitgezogen.

SalesConnect Reader

Die Rolle gibt lesenden Zugriff auf sämtliche Tabellen der Lösung: die Stammdaten aus Business Central, Abonnements und Abonnementzeilen, Leadquellen sowie Anreden, Titel und Sprachen. Dazu kommt Leserecht auf die App, die Weboberflächen-Bestandteile und die Organisationseinstellungen — nötig, damit Formularlogik und Konfiguration funktionieren.

Eine bewusste Ausnahme vom reinen Lesen: Externe Stakeholder dürfen angelegt, geändert und zugewiesen werden. Sie entstehen im Tagesgeschäft an der Verkaufschance und wären als reine Administratorenaufgabe unpraktikabel. Das Löschen ist auf eigene Datensätze beschränkt.

SalesConnect Admin

Die Rolle erweitert den Lesezugriff um volle Pflegerechte — Anlegen, Ändern, Löschen, Zuweisen und Freigeben — auf den Tabellen der Lösung:

• Stammdaten aus Business Central: Verkäufer, Anreden, Positionen, Rabattgruppen, Länder, Sprachen
• Abonnements und Abonnementzeilen
• Leadquellen, externe Stakeholder
• Anredevorlagen und Titel

Eine Einschränkung besteht beim Mandanten (BC): Er ist auch für Administratoren nur lesbar. Mandanten spiegeln die Buchungskreise in Business Central; sie dort und hier auseinanderlaufen zu lassen, hätte Folgen für jede Zuordnung.

SalesConnect DataBridge

Diese Rolle gehört dem Dienstkonto, mit dem die dsyr.DataBridge auf Customer Engagement zugreift — nicht einer natürlichen Person.

Anders als die beiden Ergänzungsrollen umfasst sie auch die Standardtabellen: Firma, Kontakt, Verkaufschance, Angebot und Produkt, jeweils mit vollem Zugriff auf Organisationsebene. Das ist erforderlich, weil die Übertragung Datensätze unabhängig von deren Besitzer anlegen, aktualisieren und zuordnen muss.

Zuweisung in der Praxis

Reader und Admin schließen einander nicht aus; wird beides zugewiesen, gilt in Dynamics 365 die jeweils weitergehende Berechtigung.

3.8 - Meldungen

Die Regeln der Lösung laufen synchron: Wird eine Regel verletzt, bricht der Speichervorgang mit einer Meldung ab. Die folgende Übersicht erklärt, was dahintersteht.

Meldungen bei der Freigabe nach Business Central

„Die Änderung kann nicht durchgeführt werden, da die neue Firma noch nicht nach BC übertragen wurde."

Ursache — Ein für die Übertragung freigegebener Kontakt soll einer Firma zugeordnet werden, die in Business Central noch nicht existiert.

Lösung — Zunächst die Firma freigeben und die Übertragung abwarten. Sie ist abgeschlossen, sobald an der Firma die BC-Nummer gefüllt ist. Danach lässt sich der Kontakt umhängen. Alternativ die Freigabe des Kontakts vorübergehend zurücknehmen.

„Der Kontakt kann nicht geändert werden, da die neue Firma noch nicht nach BC übertragen wurde."

Ursache — Wie zuvor, ausgelöst beim Speichern des Kontakts.

Lösung — Übertragung der Firma abwarten, erkennbar an der gefüllten BC-Nummer.

„Eine Verkaufschance kann nicht ohne Kontakt nach BC übertragen werden."

Ursache — Eine Verkaufschance wurde freigegeben, es ist aber kein Kontakt hinterlegt. Business Central benötigt einen Ansprechpartner.

Lösung — Den zuständigen Kontakt an der Verkaufschance eintragen.

„Der Kontakt kann nicht geändert werden, da der neue Kontakt noch nicht nach BC übertragen wurde."

Ursache — Der an einer freigegebenen Verkaufschance gesetzte Kontakt existiert in Business Central noch nicht.

Lösung — Den Kontakt freigeben und die Übertragung abwarten; sie ist abgeschlossen, sobald die BC-Kontaktnummer gefüllt ist.

Meldungen zu Anrede und Sprache

„Value for gender has not found!"

Ursache — Zum gesetzten Geschlecht bzw. zum gemeldeten BC-Anredeschlüssel existiert keine Entsprechung. Meist fehlt ein Anrededatensatz für die betreffende Sprache oder das betreffende Geschlecht.

Lösung — Die Anredestammdaten prüfen: Gibt es für die Sprache des Kontakts eine Anrede zum gewählten Geschlecht? Fehlende Datensätze in Business Central ergänzen und übertragen lassen.

Meldungen zur Konfiguration

„Value of the setting wysa_DefaultLanguageGuid has to be a valid guid or ‘0’."

Ursache — Die Einstellung für die Standardsprache enthält einen ungültigen Wert.

Lösung — Entweder die Kennung eines vorhandenen Sprachdatensatzes eintragen oder 0 setzen, um die Vorbelegung abzuschalten. Siehe Konfiguration.

„Found more than 1 setting!"

Ursache — Eine Einstellung ist mehrfach hinterlegt, sodass nicht eindeutig ist, welcher Wert gilt.

Lösung — Die betroffene Einstellung in der Umgebung prüfen und den doppelten Eintrag entfernen. Eine Aufgabe für die IT-Administration.

4 - Mapping

Der Datenaustausch zwischen Business Central (BC) und Customer Engagement (CE / Dataverse) läuft vollständig über die DataBridge. Sie besteht aus zwei Konfigurationsebenen:

• Job — wann und unter welcher Bedingung etwas übertragen wird (Zeitplan, Filter, Reihenfolge, Watermark, Quell-/Zielverbindung)
• Mapping — was übertragen wird (Feldzuordnung Quelle → Ziel inkl. Key-Auflösung und Transformationen)

Aktuell sind 38 Jobs mit 38 Mappings und insgesamt 290 Feldzuordnungen konfiguriert. Zu jedem Job gehört genau ein Mapping.

Übersicht — welche Daten werden ausgetauscht?

Auf oberster Ebene lassen sich die Daten in vier Gruppen einteilen:

flowchart LR
  subgraph BC["Business Central"]
    direction TB
    BC1["Stammdaten<br/>Länder · Sprachen · Anreden<br/>Verkäufer · Positionen · Rabattgruppen"]
    BC2["Produkte<br/>Verkaufschancen-Elemente"]
    BC3["Belege<br/>Angebote · Angebotspositionen<br/>Kalkulationselemente"]
    BC4["Abonnements<br/>Serviceobjekte · Servicevereinbarungen"]
    BC5["Geschäftspartner<br/>Firmen · Kontakte"]
    BC6["Verkaufschancen"]
  end

  subgraph CE["Customer Engagement"]
    direction TB
    CE1["Wertelisten<br/>wysa_country · wysa_language · …"]
    CE2["Produkte<br/>product"]
    CE3["Angebote<br/>quote · quotedetail"]
    CE4["Abonnements<br/>wysa_bcserviceobject(commitment)"]
    CE5["Firma / Kontakt<br/>account · contact"]
    CE6["Verkaufschance<br/>opportunity · opportunityproduct"]
  end

  BC1 -->|Referenzdaten| CE1
  BC2 -->|Produkte| CE2
  BC3 -->|Angebote & Preise| CE3
  BC4 -->|Abo-Bestand| CE4
  BC5 <-->|in beide Richtungen| CE5
  CE6 -->|nur CE → BC| BC6

Daraus ergeben sich vier grundsätzliche Muster:

Der Detailfluss inklusive Response-Jobs und Löschverarbeitung steht unter Datenfluss.

Vollständige Liste der Mappings

Sortiert nach der Ausführungsreihenfolge (Order) des zugehörigen Jobs. „Felder" = Anzahl der Feldzuordnungen, „Ops" = davon mit Transformation (Lookup, OptionSet, Concat, …).

Stammdaten und Produkte (BC → CE)

Geschäftspartner und Verkaufschancen (CE → BC, mit Response)

Geschäftspartner (BC → CE)

Abonnements (BC → CE)

Angebote (BC → CE)

Löschungen (BC → CE, Quelle immer das Änderungsprotokoll acdlogentries)

Detailseiten

Die Detailseiten sind nach Datenbereich gegliedert, nicht nach Job. Jeder Bereich hat eine Übersichtsseite mit dem Gesamtbild und darunter je eine Seite pro Schritt.

Grundlage aller Belegketten sind die Stammdaten — die Wertelisten aus Business Central, aus denen die Belege ihre Verknüpfungen bilden:

Vollständig dokumentiert sind bisher Firma und Kontakt:

Das Angebot läuft ausschließlich von Business Central nach Customer Engagement und schließt damit den Kreis zur Verkaufschance:

Das Abonnement ist ein eigenständiger Bereich, ebenfalls nur von Business Central nach Customer Engagement:

Eine rein technische, tabellarische Sicht auf alle Jobs in Ausführungsreihenfolge bietet die Sektion Technisches Mapping.

Damit sind alle aktiven Mappings der Integration dokumentiert.

Die Verkaufschance weicht vom Muster ab — sie läuft nur in eine Richtung und hat eine zweite Kette für die Positionen:

Aufbau einer Detailseite

Jede Schrittseite ist zweigeteilt: zuerst die fachliche Sicht, danach die technische.

1. Steckbrief — Richtung, Takt, Betroffene, technische Zuordnung
2. Was passiert hier? — der Vorgang in Prosa
3. Welche Felder? — Feldtabelle mit Anzeigenamen beider Systeme
4. Worauf zu achten ist — fachliche Besonderheiten und Stolperfallen
5. Technische Details — aufklappbar: Job-Konfiguration, Key-Auflösung, technische Feldnamen, Transformationen als JSON

Wer die Lösung anwendet, liest die ersten vier Punkte. Wer sie wartet oder erweitert, klappt den fünften auf.

Die technischen Grundlagen (Jobs, Konnektoren, Transformationen) stehen in der DataBridge-Dokumentation.

4.1 - Datenfluss

Diese Seite zeigt, wie die Daten fließen. Welche Felder dabei zugeordnet werden, steht auf den Mapping-Detailseiten.

Grundprinzip

Jeder Job der DataBridge ist ein eigenständiger, zeitgesteuerter Lauf:

flowchart LR
  A["Zeitplan<br/><code>Schedule</code>"] --> B["Quelle lesen<br/><code>SourceConnection</code>"]
  B --> C["Filter anwenden<br/><code>Filter</code> + <code>%watermark%</code>"]
  C --> D["Mapping ausführen<br/>Feldzuordnung + Transformation"]
  D --> E["Key-Auflösung<br/>Datensatz im Ziel finden"]
  E --> F["Schreiben<br/><code>TargetConnection</code>"]
  F --> G["Watermark fortschreiben<br/><code>WatermarkField</code>"]
  G -.->|falls gesetzt| H["Response-Job starten<br/><code>ResponseJob</code>"]

Die Reihenfolge innerhalb eines Laufs steuert das Feld Order (110 – 760). Stammdaten laufen zuerst (110 – 190), damit die Lookups der späteren Jobs (Firma, Angebot, Abo) ihre Referenzdatensätze bereits vorfinden.

Die meisten Jobs laufen alle 2 Minuten (0 */2 * * * *), die Jobs rund um Verkaufschancen und Angebotsaktivierung alle 3 Minuten (0 */3 * * * *).

Gesamtfluss

flowchart TB
  subgraph S1["1 · Stammdaten  (Order 110–190)"]
    direction LR
    ST["BC Referenztabellen<br/>Länder · Sprachen · Anreden<br/>Verkäufer · Positionen<br/>Rabattgruppen"] --> STC["CE Wertelisten<br/><code>wysa_country</code>, <code>wysa_language</code>,<br/><code>wysa_bcsalutation</code>, <code>wysa_salesperson</code>, …"]
    IT["BC Verkaufschancen-Elemente<br/><code>acdopportunityelements</code>"] --> ITC["CE <code>product</code>"]
  end

  subgraph S2["2 · Geschäftspartner &nbsp;(Order 220–241, 410–440, 520–530)"]
    direction LR
    CEA["CE <code>account</code> / <code>contact</code>"] -->|"neu: <code>CEAccounts</code>, <code>CEContacts</code>"| BCA["BC <code>acdcontactscomp</code> / <code>acdcontacts</code>"]
    CEA -->|"geändert: <code>CEAccountUpdates</code>, <code>CEContactsUpdates</code>"| BCA
    BCA -->|"Response: Nummer zurück"| CEA
    BCA -->|"<code>BCAccounts</code>, <code>BCContacts</code>"| CEA
  end

  subgraph S3["3 · Verkaufschancen &nbsp;(Order 260–261, 710–760)"]
    direction LR
    CEO["CE <code>opportunity</code><br/><code>opportunityproduct</code>"] -->|"<code>CEOpportunities</code><br/><code>CEOpportunityProducts</code>"| BCO["BC <code>acdopportunities</code><br/><code>acdopportunitycalculationelements</code>"]
    BCO -->|"Response"| CEO
  end

  subgraph S4["4 · Angebote &amp; Abos &nbsp;(Order 550–625)"]
    direction LR
    BCQ["BC <code>acdsalesheaders</code><br/><code>acdsalescalculationelements</code><br/><code>serviceObjects</code> / <code>serviceCommitments</code>"] --> CEQ["CE <code>quote</code> / <code>quotedetail</code><br/><code>wysa_bcserviceobject(commitment)</code>"]
  end

  subgraph S5["5 · Löschungen &nbsp;(Order 420–690)"]
    direction LR
    LOG["BC Änderungsprotokoll<br/><code>acdlogentries</code>"] --> DEL["CE: Datensatz löschen<br/><code>account</code>, <code>contact</code>, <code>product</code>,<br/><code>quote</code> deaktivieren/schließen,<br/><code>quotedetail</code> löschen"]
  end

  S1 --> S2 --> S3 --> S4 --> S5

Muster 1 — Referenzdaten BC → CE

Der einfachste Fall: BC ist führendes System, CE liest nur mit.

sequenceDiagram
  participant BC as Business Central
  participant DB as DataBridge
  participant CE as Customer Engagement
  DB->>BC: GET api page<br/>?$filter=lastModifiedDateTime gt %watermark%
  BC-->>DB: geänderte Datensätze
  DB->>DB: Mapping + Lookup auf CE-Key
  DB->>CE: Upsert (anlegen oder aktualisieren)
  DB->>DB: Watermark = höchstes lastModifiedDateTime

Die Abgrenzung erfolgt über das Watermark: der Job merkt sich den höchsten Wert von WatermarkField (lastModifiedDateTime, Typ datetime) des letzten Laufs und liest beim nächsten Mal nur, was seitdem geändert wurde.

Betroffene Mappings: alle BC*-Mappings außer den Delete- und Response-Varianten.

Die Jobs in Gegenrichtung (CE*-Mappings) brauchen kein Watermark-Feld: Für Dataverse-Quellen nutzt die DataBridge das Change Tracking der Plattform und erhält damit nur die seit dem letzten Lauf geänderten Datensätze.

Muster 2 — CE → BC mit Response-Job

Legt der Vertrieb in CE eine Firma, einen Kontakt oder eine Verkaufschance an, existiert diese in BC noch nicht. BC vergibt beim Anlegen die Nummer und die SystemId — diese müssen zurück nach CE. Genau dafür gibt es den Response-Job:

sequenceDiagram
  participant CE as Customer Engagement
  participant DB as DataBridge
  participant BC as Business Central

  Note over DB: Job "accountsnewfromce" (Order 220)
  DB->>CE: lies account
  Note right of DB: Filter:<br/>wysa_bcsystemid IS NULL<br/>UND wysa_sync2bc = "Freigegeben"
  CE-->>DB: neue, freigegebene Firmen
  DB->>BC: POST acdcontactscomp
  BC-->>DB: number, id (SystemId)

  Note over DB: ResponseJob "accountsresponsefrombc" (Order 221)
  DB->>BC: lies acdcontactscomp
  BC-->>DB: number, id
  DB->>CE: schreibe wysa_bccontactnumber, wysa_bcsystemid
  Note right of CE: Ab jetzt greift<br/>"accountupdatesfromce" (Order 520)

Der entscheidende Mechanismus ist das Feld wysa_bcsystemid:

• leer → der Datensatz ist BC noch unbekannt → der Neu-Job greift (CEAccounts, CEContacts, CEOpportunities, CEOpportunityProducts)
• gefüllt → der Datensatz existiert in BC → der Update-Job greift (CEAccountUpdates, CEContactsUpdates, CEOpportunityProductsUpdates)

Zusätzlich muss wysa_sync2bc auf „Freigegeben" stehen — siehe Freigabe nach Business Central.

Response-Jobs sind bewusst mit IsActive = false konfiguriert. Sie werden nicht über den eigenen Zeitplan gestartet, sondern ausschließlich vom vorgelagerten Job über dessen Feld ResponseJob aufgerufen.

Muster 3 — Löschungen über das Änderungsprotokoll

Ein gelöschter Datensatz taucht in der normalen API Page nicht mehr auf — er kann also nicht per Abgleich erkannt werden. Stattdessen liest die DataBridge das BC-Änderungsprotokoll acdlogentries:

flowchart LR
  DEL["Löschung in BC"] --> LOG["Eintrag in<br/><code>acdlogentries</code><br/>tableId + operation"]
  LOG --> F{"Filter je Job"}
  F -->|"tableId 5050 (Kontakt)"| A["<code>BCAccountsDelete</code><br/><code>BCContactsDelete</code>"]
  F -->|"tableId 72077781 (Artikel)"| P["<code>BCProductsDelete</code>"]
  F -->|"tableId 36 (Angebot)"| Q["<code>BCSalesQuotesDelete</code>"]
  F -->|"tableId 72077783 (Kalkulation)"| K["<code>BCSalesCalculationElementsDelete</code>"]
  A --> X["Mapping setzt<br/><code>statecode</code> / <code>statuscode</code><br/>→ Datensatz wird <b>deaktiviert</b>"]
  P --> X
  Q --> Y["Job-Feld <code>Action = Delete</code><br/>→ Datensatz wird <b>gelöscht</b>"]
  K --> Y

Diese Jobs unterscheiden sich in zwei Punkten von den übrigen:

• Die Quelle ist immer acdlogentries, nie die Fachtabelle. Der Filter grenzt über tableId die betroffene BC-Tabelle ab, z. B. {{lastModifiedDateTime gt %watermark%}} and tableId eq 5050 für Kontakte/Firmen. Als Schlüssel dient recordId → wysa_bcsystemid.
• Es gibt zwei Varianten, wie im Ziel reagiert wird:

Stammdaten wie Firma, Kontakt und Produkt werden also nie hart gelöscht — für Historie und referenzielle Integrität in CE ist das wichtig. Angebote werden storniert, nur Angebotspositionen werden entfernt.

Sonderfall — Angebot aktivieren

BCSalesQuotesActivate (Order 625) ist kein Datenabgleich, sondern eine Statusänderung. Der Job liest ebenfalls acdlogentries, filtert aber auf tableId eq 36 and operation eq 'TRANSFERRED' — also auf den Moment, in dem in BC aus einem Angebot ein Auftrag wird — und setzt daraufhin den Status des zugehörigen quote in CE.

Ausführungsreihenfolge und Takt

Die Jobs tragen eine Ordnungsnummer (Order), die festlegt, in welcher Folge sie innerhalb eines Durchlaufs abgearbeitet werden. Darauf beruhen die Reihenfolgeabhängigkeiten der Integration: Stammdaten vor Belegen, Firma vor Kontakt, Kontakt vor Verkaufschance.

Mit ↳ gekennzeichnet sind die vier Response-Jobs. Sie haben keinen eigenen Zeitplan, sondern werden unmittelbar von ihrem auslösenden Job gestartet und folgen damit dessen Takt.

Die Ordnungsnummer sortiert nur innerhalb eines Takts

Das ist die wichtigste Einschränkung an der Tabelle oben: Es gibt zwei Zeitpläne. 23 Jobs laufen alle zwei Minuten, drei alle drei Minuten — und diese drei sind fett hervorgehoben.

flowchart TB
  subgraph M0["Minute 0, 6, 12, 18 …"]
    A0["<b>alle</b> Jobs<br/>2-Minuten- und 3-Minuten-Gruppe<br/>→ Ordnungsnummer gilt durchgehend"]
  end
  subgraph M2["Minute 2, 4, 8, 10 …"]
    A2["nur die 23 Jobs der<br/><b>2-Minuten-Gruppe</b>"]
  end
  subgraph M3["Minute 3, 9, 15, 21 …"]
    A3["nur die 3 Jobs der<br/><b>3-Minuten-Gruppe</b><br/>625, 710, 750"]
  end

Die Ordnungsnummer legt also nur die Folge der Jobs fest, die im selben Tick laufen. Die beiden Gruppen treffen sich alle sechs Minuten.

Praktisch bedeutet das für die drei Jobs im Drei-Minuten-Takt:

Weil die Vorgänger-Jobs häufiger laufen als die abhängigen, ist die Vorarbeit in der Praxis immer schon erledigt — nur eben aus einem früheren Durchlauf, nicht aus demselben. Wer eine Reihenfolgeabhängigkeit prüft, sollte deshalb nicht allein auf die Ordnungsnummer schauen, sondern auch auf den Takt.

Die Operationen im Überblick

Sieben Operationen kommen in den Mappings vor. Sie sind das eigentliche Werkzeug der DataBridge — alles, was über eine reine Feld-zu-Feld-Zuordnung hinausgeht, ist eine dieser Operationen.

Die letzten drei sind Einzelfälle — jede kommt in genau einem Mapping vor. Wer die Konfiguration erweitert, findet dort das jeweilige Muster.

Nächster Schritt

Die Feldzuordnungen der einzelnen Mappings sind in der Mapping-Übersicht gelistet. Die Detailseiten sind nach Datenbereich gegliedert: Stammdaten, Firma, Kontakt, Verkaufschance, Angebot und Abonnement.

4.2 - Stammdaten

Bevor eine Firma, ein Kontakt oder ein Angebot abgeglichen werden kann, müssen die Wertelisten stimmen. Business Central schickt in seinen Belegen keine Klartexte, sondern Kürzel: DE für Deutschland, DEU für die Sprache, HERR für die Anrede, MM für den Verkäufer. Aus diesen Kürzeln macht die Integration in Customer Engagement echte Verknüpfungen — und das kann sie nur, wenn die passende Werteliste dort schon vorhanden ist.

Genau dafür gibt es die Stammdaten-Abgleiche. Sie laufen mit den Ordnungsnummern 110 – 190 und damit vor allen Belegketten.

Die Kalkulationselemente sind fachlich ebenfalls ein Stammdaten-Abgleich, stehen aber bei der Verkaufschance, weil sie nur dort und im Angebot verwendet werden.

Warum die Reihenfolge zählt

flowchart LR
  subgraph S["Stammdaten · 110 – 190"]
    A["Länder"]
    B["Sprachen"]
    C["Anreden"]
    D["Rabattgruppen"]
    E["Verkäufer"]
    F["Organisationsebenen"]
  end
  subgraph B1["Belegketten · ab 220"]
    G["Firma"]
    H["Kontakt"]
    I["Verkaufschance"]
    J["Angebot"]
  end
  S ==>|"Kürzel werden zu<br/>Verknüpfungen"| B1

Alle Stammdaten-Jobs laufen im selben Zwei-Minuten-Takt wie die Belegketten, aber mit niedrigerer Ordnungsnummer — sie sind innerhalb eines Durchlaufs also immer zuerst dran.

Alle Abgleiche folgen demselben Muster

Die sechs Wertelisten-Jobs sind bemerkenswert einheitlich aufgebaut:

Es gibt keinen Rückweg: Wertelisten werden in Business Central gepflegt, Customer Engagement folgt. Ein in CE angelegter Ländereintrag bleibt dort und wird von keinem Job nach BC übertragen.

Zwei Namenskonventionen für dasselbe Feld

Beim Feld für das BC-Kürzel gibt es zwei Schreibweisen — je nach Werteliste:

Das ist keine Kleinigkeit, denn die Belegketten müssen diese Unterscheidung mitmachen. Jeder Lookup nennt das Nachschlagefeld ausdrücklich:

Was nicht abgeglichen wird

Nicht jede Tabelle des Datenmodells hat einen Abgleich. Diese hier werden von keinem aktiven Job gefüllt:

Der Mandant (BC) ist dabei der auffälligste Fall: Er wird an Firma, Kontakt, Verkaufschance und Angebot verwendet, kommt aber nicht aus Business Central. Da ihn auch kein Beleg-Mapping schreibt, bleibt das Feld an den übertragenen Datensätzen leer, wenn es nicht in CE gesetzt wird.

Die Produkttabelle wird nur teilweise gefüllt

Technische Zuordnung

{
  "KeyType": "CustomKey",
  "KeyName": "wysa_bcsystemidkey",
  "KeyValues": [
    { "keyName": "wysa_bcsystemid", "attributeName": "id", "rank": 1 }
  ]
}

4.2.1 - Wertelisten aus Business Central übernehmen

Der sechste Wertelisten-Abgleich, der Verkäufer (130), hat wegen einer Besonderheit eine eigene Seite.

Was passiert hier?

Jeder dieser fünf Abgleiche holt eine Werteliste aus Business Central nach Customer Engagement — Kürzel und Bezeichnung. Danach kann die Integration in den Belegketten aus einem BC-Kürzel eine echte Verknüpfung machen.

Alle fünf sind gleich aufgebaut: Sie kommen mit drei bis vier Feldern aus, erkennen Einträge über die BC System-ID, laufen im Zwei-Minuten-Takt und übertragen nur, was sich seit dem letzten Lauf geändert hat. Es gibt keinen Rückweg und keine Löschverarbeitung.

Länder

Job countriesfrombc (110) · Zieltabelle Land (wysa_country)

Die einzige Werteliste mit einem vierten Feld: Neben dem BC-Kürzel kommt der ISO-Code mit. Damit lassen sich Länder in CE auch dort korrekt darstellen, wo eine normierte Kennung gebraucht wird — etwa in Serienbriefen oder Exporten.

Gebraucht wird die Liste für das Feld Land an Firma, Kontakt und Lead.

Sprachen

Job languagesfrombc (115) · Zieltabelle Sprache (wysa_language)

Gebraucht wird die Liste für das Feld Sprache am Kontakt und am Lead — und darüber hinaus für die Anredebildung: Anredevorlagen und Titel hängen jeweils an einer Sprache.

Anreden

Job salutationsfrombc (120) · Zieltabelle Anrede (BC) (wysa_bcsalutation)

Gebraucht wird die Liste für das Feld Anrede (BC) am Kontakt.

Debitorrabattgruppen

Job customerdiscountgroupsfrombc (125) · Zieltabelle Debitorrabattgruppe (BC) (wysa_bccustomerdiscountgroup)

Gebraucht wird die Liste für das Feld Debitorrabattgruppe an der Firma. Dieses Feld gehört zu denen, die nur aus BC kommen und nie zurückgeschrieben werden — siehe Firma.

Organisationsebenen

Job positionsfrombc (135) · Zieltabelle Position (BC) (wysa_bcposition)

Gebraucht wird die Liste für das Feld Position (BC) am Kontakt und am Lead — die Entscheidungsebene eines Ansprechpartners.

Worauf zu achten ist

Gelöschte Einträge bleiben in CE stehen

Keiner dieser Abgleiche hat eine Löschverarbeitung. Wird eine Anrede oder ein Land in Business Central gelöscht, bleibt der Eintrag in Customer Engagement bestehen und weiterhin auswählbar. Bei Firma, Kontakt und Produkt gibt es dafür eigene Löschjobs — bei den Wertelisten nicht.

Änderungen am Kürzel sind unkritisch

Weil die Zuordnung über die BC System-ID läuft und nicht über das Kürzel, überlebt ein Eintrag eine Umbenennung in BC: Beim nächsten Lauf wird derselbe CE-Datensatz gefunden und sein Codefeld aktualisiert.

Die Belegketten lösen allerdings über das Kürzel auf. Wird ein Code in BC geändert, zeigen bestehende CE-Datensätze also weiter auf den richtigen Eintrag — neue Belege aus BC bringen aber das neue Kürzel mit, das nach dem Wertelisten-Abgleich ebenfalls stimmt. Weil die Wertelisten vor den Belegen laufen, greift das innerhalb desselben Durchlaufs.

Zwei Schreibweisen für das Codefeld

Länder, Sprachen und Debitorrabattgruppen legen das Kürzel in wysa_bccode ab, Anreden und Organisationsebenen in wysa_code. Die Lookups in den Belegketten berücksichtigen das — siehe Stammdaten.

Technische Details

Die vollständigen technischen Mapping-Tabellen mit Feldzuordnungen, Key-Auflösung und Transformationen stehen auf den technischen Seiten der einzelnen Jobs:

4.2.2 - Verkäufer aus Business Central übernehmen

Was passiert hier?

Business Central kennt Verkäufer als Kürzel — MM, SK, LB. Dieser Abgleich holt sie nach Customer Engagement, damit die Belegketten aus dem Kürzel eine echte Verknüpfung machen können.

Der Verkäufer ist die meistgenutzte Werteliste der Integration: Er wird an Firma, Kontakt, Verkaufschance und Angebot aufgelöst — und bei Firma und Kontakt sogar in beide Richtungen.

Die E-Mail-Adresse ist mehr als ein Datenfeld

Neben Kürzel und Bezeichnung überträgt dieser Abgleich die E-Mail-Adresse des Verkäufers. Sie ist der Schlüssel zu einer Automatik in Customer Engagement: Über die E-Mail-Adresse wird der BC-Verkäufer dem passenden CRM-Benutzer zugeordnet.

flowchart LR
  A["Verkäufer in BC<br/>Code + E-Mail"] --> B["Verkäufer (BC) in CE"]
  B -->|"Zuordnung über<br/>die E-Mail-Adresse"| C["CRM-Benutzer<br/>oder Team"]
  C --> D["Besitzer von Firma,<br/>Kontakt, Verkaufschance"]

Das ist der Grund, warum dieser Abgleich fachlich mehr Gewicht hat als die übrigen Wertelisten: Aus ihm folgt, wem ein Datensatz in CE gehört. Beschrieben ist die Automatik unter Stammdaten und Anzeige.

Welche Felder kommen an?

Die E-Mail-Adresse landet im Feld wysa_emailaddress. An diesem Feld hängt die automatische Benutzerzuordnung, siehe Datenmodell.

Die Telefonnummer wird nicht übertragen

Das Feld Telefon am Verkäufer (BC) ist nicht Teil dieses Mappings. Es kann in CE gepflegt werden und wird vom Abgleich nicht überschrieben.

Gelöschte Verkäufer bleiben stehen

Wie bei allen Wertelisten gibt es keine Löschverarbeitung. Ein in Business Central gelöschter Verkäufer bleibt in CE bestehen und weiterhin auswählbar.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → salespersonsfrombc.

4.2.3 - Produkte deaktivieren

Was passiert hier?

Wird in Business Central ein Artikel gelöscht, wird das zugehörige Produkt in Customer Engagement deaktiviert — es bleibt erhalten und wird nur inaktiv gesetzt.

Der Weg führt über das Änderungsprotokoll von BC, weil ein gelöschter Artikel in der normalen Schnittstelle nicht mehr auftaucht. Wiedererkannt wird das Produkt über die BC System-ID.

flowchart LR
  A["Artikel in BC gelöscht"] --> B["Eintrag im<br/>Änderungsprotokoll"]
  B --> C["Produkt in CE über die<br/>BC System-ID gefunden"]
  C --> D["Produkt wird <b>deaktiviert</b>"]

Damit folgt das Produkt dem Muster von Firma und Kontakt: deaktivieren, nicht löschen. An einem Produkt hängen Angebotspositionen und Verkaufschancenpositionen — ein hartes Löschen würde diese Historie zerstören.

Was sich am Produkt ändert

Artikel werden nicht übernommen

Artikel aus Business Central werden nicht nach Customer Engagement übertragen. Die Produkttabelle wird ausschließlich über die Kalkulationselemente aus BC (190) gefüllt; alles andere ist manuell erfasst. Dieser Schritt betrifft deshalb nur Produkte, die eine BC System-ID aus der Artikeltabelle tragen — in der Praxis also keine manuell erfassten Produkte und keine Kalkulationselemente.

Worauf zu achten ist

Reaktivieren erfolgt in CE

Ein in CE deaktiviertes Produkt wird vom Abgleich nicht wieder aktiviert. Soll es weiter verwendet werden, wird es in CE manuell reaktiviert.

Deaktivierte Produkte in bestehenden Positionen

Ein inaktives Produkt bleibt in bereits erfassten Verkaufschancen- und Angebotspositionen verknüpft. Es lässt sich nur nicht mehr neu auswählen. Das ist der Zweck des Deaktivierens gegenüber dem Löschen.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → productsfrombcdelete.

4.3 - Firma

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):

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.

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

Technische Zuordnung

4.3.1 - Firmen aus Business Central übernehmen

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?

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.

4.3.2 - Neue Firmen nach Business Central übertragen

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:

1. Sync zu BC steht auf „Ja"
2. 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?

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.

4.3.3 - Rückmeldung aus Business Central

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:

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?

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.3.4 - Änderungen nach Business Central übertragen

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:

1. Sync zu BC steht auf „Ja"
2. 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?

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.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → accountupdatesfromce.

4.3.5 - Löschung in Business Central nachvollziehen

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

Alle übrigen Felder bleiben unverändert — auch Sync zu BC und die BC System-ID.

Worauf zu achten ist

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.

4.4 - Kontakt

Kontakte werden nach demselben Muster abgeglichen wie Firmen: 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.

Der Kreislauf

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.

Die Weiche: das Feld „BC System-ID"

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

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

Welche Felder laufen in welche Richtung?

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

Was in der Praxis zu beachten ist

Unterschiede zur Firma auf einen Blick

Technische Zuordnung

4.4.1 - Kontakte aus Business Central übernehmen

Was passiert hier?

Wird in Business Central ein Kontakt angelegt oder geändert, erscheint er kurz darauf in Customer Engagement. Existiert der Kontakt dort schon, werden seine Felder aktualisiert; existiert er noch nicht, wird er neu angelegt.

Wiedererkannt wird ein Kontakt an seiner BC Kontaktnummer — nicht am Namen.

Der Abgleich holt bei jedem Lauf nur, was sich seit dem letzten Mal geändert hat.

Welche Felder kommen an?

Worauf zu achten ist

Die Firma muss zuerst da sein

Die Zuordnung zur Firma wird über deren BC Kontaktnummer hergestellt. Ist die Firma in CE noch nicht vorhanden — etwa weil der Firmen-Abgleich noch nicht gelaufen ist —, bleibt das Feld Firmenname am Kontakt leer. Da die Firmen-Jobs (410) vor den Kontakt-Jobs (430) laufen, findet das normalerweise innerhalb desselben Laufs zusammen.

Der Verkäufer wird nicht mitgeholt

Anders als bei der Firma holt dieser Schritt den Verkäufer (BC) nicht aus BC ab — obwohl er in der Gegenrichtung übertragen wird. Was in CE im Feld Verkäufer (BC) steht, stammt also aus CE selbst, nicht aus dem ERP.

Die Funktion wird nicht mitgeholt

Auch das Standardfeld Position (die Funktion als Freitext) wird nicht aus BC geholt. Übertragen wird nur Position (BC), die Organisationsebene — das ist ein anderes Feld. Siehe die Warnung in der Kontakt-Übersicht.

Der Kontakt wird automatisch für BC freigegeben

Das Feld Sync zu BC wird auf „Ja" gesetzt. Ab sofort werden also auch Änderungen aus CE zurück nach BC übertragen.

Verknüpfungen brauchen aktuelle Stammdaten

Anrede, Sprache, Organisationsebene und Land kommen aus BC als Kürzel und werden in CE zu Verknüpfungen aufgelöst. Fehlt das passende Stammdatum, bleibt das Feld leer. Die Stammdatenlisten werden vorher abgeglichen.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → contactsfrombc.

4.4.2 - Neue Kontakte nach Business Central übertragen

Was passiert hier?

Der Vertrieb legt einen Kontakt in Customer Engagement an. Sobald das Feld Sync zu BC auf „Ja" gesetzt ist, wird er beim nächsten Lauf in Business Central angelegt — als Personenkontakt, zugeordnet zu seiner Firma.

Zwei Bedingungen müssen erfüllt sein:

1. Sync zu BC steht auf „Ja"
2. das Feld BC System-ID ist noch leer

Ist die BC System-ID bereits gefüllt, greift stattdessen Änderungen nach BC.

Vorher: die Firma muss in BC sein

Business Central kann einen Kontakt nur anlegen, wenn dessen Firma dort schon existiert. Deshalb lässt sich ein Kontakt gar nicht erst freigeben, solange die BC System-ID seiner Firma leer ist — die Lösung lehnt die Freigabe ab.

flowchart LR
  A["Kontakt in CE angelegt"] --> B{"BC System-ID<br/>der <b>Firma</b> gefüllt?"}
  B -->|nein| C["Freigabe wird abgelehnt"]
  B -->|ja| D{"Sync zu BC<br/>= Ja?"}
  D -->|nein| E["nichts passiert"]
  D -->|ja| F["Kontakt wird in BC angelegt"]
  F --> G["Rückmeldung aus BC"]

Wird die Firma freigegeben und sind ihre Kontakte ebenfalls freigegeben, ordnet sich das über die Ausführungsreihenfolge von selbst: Die Firma wird in Durchlauf 1 angelegt und zurückgemeldet, die Kontakte folgen im nächsten Durchlauf. Siehe Freigabe nach Business Central.

Welche Felder gehen nach BC?

Worauf zu achten ist

Die Funktion wird nicht mitgeschickt

Das Standardfeld Position (die Funktion als Freitext) ist weder bei der Neuanlage noch beim Ändern Teil der Übertragung. Die Funktion bleibt in CE.

Die Organisationsebene wird nicht mitgeschickt

Position (BC) — die Organisationsebene — läuft nur von BC nach CE. Was in CE in diesem Feld steht, hat auf BC keine Wirkung.

Ohne Firma keine Zuordnung

Die Zuordnung zur Firma wird über deren BC Kontaktnummer aufgelöst. Ist sie leer, kommt der Kontakt ohne Firmenzuordnung in BC an. Die Freigaberegel verhindert das normalerweise — beim Umhängen an eine noch nicht übertragene Firma ist aber Vorsicht geboten.

Doppelte Anlage ist ausgeschlossen

Läuft der Abgleich zweimal, bevor die Rückmeldung eingetroffen ist, entsteht in BC trotzdem kein zweiter Kontakt. Der Datensatz wird über die in BC hinterlegte Dataverse Id wiedererkannt.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → contactsnewfromce.

4.4.3 - Rückmeldung aus Business Central

Was passiert hier?

Wenn ein Kontakt neu nach BC übertragen wird, vergibt Business Central 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

Beim Kontakt kommt aber noch etwas hinzu: Business Central schickt auch die Adressdaten zurück.

Warum Adressdaten zurückkommen

Legt man in Business Central einen Personenkontakt an und ordnet ihn einem Unternehmen zu, übernimmt BC dessen Adresse, sofern der Kontakt keine eigene hat. Der Datensatz in BC sieht danach also anders aus, als CE ihn abgeschickt hat.

Damit beide Systeme übereinstimmen, holt dieser Schritt die Adressdaten in dem Zustand zurück, den BC ihnen gegeben hat, und schreibt sie in CE.

sequenceDiagram
  participant CE as Customer Engagement
  participant BC as Business Central
  CE->>BC: neuer Kontakt (ggf. ohne Adresse)
  Note over BC: BC ergänzt die Adresse<br/>aus dem Unternehmen
  BC-->>CE: Nummer, System-ID<br/>und die ergänzte Adresse
  Note over CE: Kontakt wird nachgezogen

Bei der Firma ist das nicht nötig — dort kommen nur Nummer und Id zurück.

Welche Felder kommen zurück?

Warum das der wichtigste Schritt der Kette ist

Die BC System-ID ist der Nachweis, dass der Kontakt im ERP angekommen ist. Erst wenn sie gefüllt ist, ändert sich das Verhalten der Kette:

Worauf zu achten ist

In CE erfasste Adressdaten können überschrieben werden

Da BC die Adresse ergänzt und zurückschickt, kann eine in CE erfasste abweichende Adresse durch die BC-Fassung ersetzt werden. Wer eine vom Firmensitz abweichende Kontaktadresse pflegt, sollte nach der ersten Übertragung prüfen, ob sie erhalten geblieben ist.

Es dauert zwei Durchläufe

Anlage und Rückmeldung laufen nacheinander. Bis BC Kontaktnummer und System-ID in CE stehen, vergeht ein weiterer Durchlauf.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → contactsresponsefrombc.

4.4.4 - Änderungen nach Business Central übertragen

Was passiert hier?

Sobald ein Kontakt in beiden Systemen existiert, hält dieser Schritt Business Central auf dem Stand von Customer Engagement.

Erfasst werden Kontakte, bei denen beides zutrifft:

1. Sync zu BC steht auf „Ja"
2. das Feld BC System-ID ist gefüllt

Ist die BC System-ID leer, greift stattdessen Neu nach BC. Die beiden Schritte schließen sich gegenseitig aus.

Welche Felder gehen nach BC?

Worauf zu achten ist

Die Funktion wird nicht übertragen

Position (die Funktion als Freitext) ist weder Teil der Neuanlage noch dieses Schritts. Die Funktion eines Kontakts wird also in keine Richtung abgeglichen — in BC gepflegte Werte bleiben dort, in CE gepflegte bleiben in CE.

Umhängen an eine andere Firma geht nach BC

Anders als bei der Firma ist die Zuordnung zur übergeordneten Firma beim Kontakt bidirektional. Wird ein Kontakt in CE an eine andere Firma gehängt, wird das nach BC übertragen — aufgelöst über die BC Kontaktnummer der neuen Firma.

Ist die neue Firma noch nicht in BC, kann die Zuordnung nicht gebildet werden. Die Lösung lehnt das Umhängen deshalb ab, solange die BC System-ID der neuen Firma leer ist — siehe Freigabe nach Business Central.

Die Organisationsebene bleibt unberührt

Position (BC) — die Organisationsebene — wird nicht zurückgeschrieben. Sie kommt nur aus BC. Eine Änderung in CE hat keine Wirkung und wird beim nächsten Abgleich überschrieben.

Die Kontaktart wird bewusst nicht überschrieben

Anders als beim Anlegen schickt dieser Schritt die Kontaktart nicht mit. Eine in BC vorgenommene Anpassung bleibt erhalten.

Es gibt keine Konfliktauflösung

Die fachlichen Felder werden in beide Richtungen abgeglichen. Wird derselbe Kontakt gleichzeitig in CE und BC geändert, gewinnt der spätere Schreibvorgang.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → contactupdatesfromce.

4.4.5 - Löschung in Business Central nachvollziehen

Was passiert hier?

Wird ein Kontakt in Business Central gelöscht, wird er in Customer Engagement deaktiviert — er bleibt also erhalten und wird nur inaktiv gesetzt.

Der Weg führt über das Änderungsprotokoll von BC: Ein gelöschter Kontakt taucht in der normalen Schnittstelle nicht mehr auf und könnte durch Abgleich gar nicht gefunden werden. Das Protokoll hält dagegen fest, dass etwas gelöscht wurde.

Wiedererkannt wird der Kontakt ü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.

Firma und Kontakt teilen sich dieselbe BC-Tabelle

In Business Central liegen Firmenkontakte und Personenkontakte in derselben Tabelle. Das Änderungsprotokoll unterscheidet sie nicht — beim Löschen entsteht in beiden Fällen derselbe Eintragstyp.

Deshalb lesen zwei Jobs dieselben Protokolleinträge und sortieren sie über die BC System-ID selbst auseinander:

flowchart LR
  A["Kontakt oder Firma<br/>in BC gelöscht"] --> B["Eintrag im<br/>Änderungsprotokoll"]
  B --> C["<b>Löschung aus BC (Firma)</b><br/>sucht in den Firmen"]
  B --> D["<b>Löschung aus BC (Kontakt)</b><br/>sucht in den Kontakten"]
  C --> E["gefunden → deaktivieren"]
  C --> F["nicht gefunden →<br/>nichts passiert"]
  D --> G["gefunden → deaktivieren"]
  D --> H["nicht gefunden →<br/>nichts passiert"]

Ein gelöschter Personenkontakt wird nur vom Kontakt-Job gefunden, eine gelöschte Firma nur vom Firmen-Job. Der jeweils andere läuft ins Leere und tut nichts. Das ist kein Fehler, sondern der Mechanismus.

Warum nicht gelöscht wird

An einem Kontakt hängen Verkaufschancen, Angebote und Aktivitäten. Ein hartes Löschen würde diese Historie zerstören. Den Kontakt inaktiv zu setzen erhält den Zusammenhang und macht zugleich sichtbar, dass er im ERP nicht mehr existiert.

Was sich am Kontakt ändert

Alle übrigen Felder bleiben unverändert — auch Sync zu BC und die BC System-ID.

Der Kontakt bleibt im Abgleich nach BC

Da Freigabe und BC System-ID stehen bleiben, fällt der deaktivierte Kontakt 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 der Kontakt in BC erneut angelegt, bekommt er dort eine neue System-ID und Kontaktnummer. Er kommt dann als neuer Kontakt nach CE — der deaktivierte bleibt daneben stehen. Eine automatische Zusammenführung gibt es nicht.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → contactsfrombcdelete.

4.5 - Verkaufschance

Die Verkaufschance ist die dritte Stufe der Freigabekette: Firma → Kontakt → Verkaufschance. Und sie ist der erste Datenbereich, der grundlegend anders funktioniert als Firma und Kontakt:

Die Verkaufschance läuft nur von Customer Engagement nach Business Central.

Es gibt keine Übernahme aus BC und keine Löschverarbeitung. Verkaufschancen entstehen im Vertrieb, nicht im ERP — Business Central braucht sie nur, um daraus Angebote zu erzeugen.

Dazu kommt eine zweite, eigene Kette für die Positionen (Verkaufschancenprodukte), die anders getaktet ist und ein anderes Freigabefeld nutzt.

Der Ablauf

flowchart TB
  subgraph VC["Verkaufschance"]
    A["Verkaufschance in CE angelegt"] --> B{"Kontakt bereits<br/>in BC?"}
    B -->|nein| BLOCK["Freigabe wird abgelehnt"]
    B -->|ja| C{"<b>Sync zu BC</b><br/>freigegeben?"}
    C -->|nein| WAIT["bleibt in CE"]
    C -->|ja| D["<b>Neu nach BC</b><br/>Verkaufschance wird angelegt"]
    D --> E["<b>Rückmeldung aus BC</b><br/>BC Verkaufschancennummer<br/>und BC System-ID"]
  end

  subgraph POS["Positionen"]
    E --> F{"<b>Sync zu BC</b> an der<br/>Position freigegeben?"}
    F -->|ja| G["<b>Positionen neu nach BC</b>"]
    G --> H["<b>Rückmeldung Positionen</b><br/>BC System-ID der Position"]
    H --> I["<b>Positionsänderungen nach BC</b><br/>Menge und Beträge"]
  end

  ELEM["<b>Kalkulationselemente aus BC</b><br/>füllen die Produktliste"] -.->|"Voraussetzung"| G

Erst Firma, dann Kontakt, dann Verkaufschance

Business Central kann eine Verkaufschance nur anlegen, wenn ihr Kontakt dort existiert — und den Kontakt nur, wenn dessen Firma existiert. Die Freigaberegel setzt das in beiden Stufen durch:

Eine Verkaufschance ohne Kontakt kann gar nicht übertragen werden — die Freigabe wird abgelehnt. Ausführlich unter Freigabe nach Business Central.

Was nach der Anlage passiert — und was nicht

Zwei Freigabefelder mit unterschiedlichem Namen

Verkaufschance und Position tragen jeweils ein eigenes Feld Sync zu BC — technisch sind es aber zwei verschieden benannte Felder:

Beide arbeiten mit demselben Wert für „Ja". Beim Erstellen von Auswertungen oder Automatisierungen ist die abweichende Schreibweise zu beachten — siehe Datenmodell.

Positionen verweisen nicht auf Artikel, sondern auf Kalkulationselemente

Eine Verkaufschancenposition zeigt in CE auf einen Datensatz der Produkttabelle. Gefüllt wird diese Tabelle über die Kalkulationselemente aus BC (190).

Für Positionen sind nur diese Elemente verwendbar — Business Central erwartet in der Position einen Elementcode, keine Artikelnummer. Am Produkt kennzeichnet das Feld Verkaufschancen-Element (wysa_OppElement), welche Datensätze dafür zulässig sind.

Welche Felder gehen nach BC?

Verkaufschance

Acht Felder — deutlich weniger als bei Firma und Kontakt. Business Central braucht von einer Verkaufschance nur das Nötigste, um daraus ein Angebot zu erzeugen.

Position

Beide Schritte übertragen denselben Feldsatz; auch Beschreibung und Marge gehen bei späteren Änderungen mit nach BC.

Unterschiede zu Firma und Kontakt

Technische Zuordnung

4.5.1 - Neue Verkaufschancen nach Business Central übertragen

Was passiert hier?

Der Vertrieb arbeitet die Verkaufschance in Customer Engagement aus. Sobald sie kaufmännisch tragfähig ist und ein Angebot entstehen soll, wird Sync zu BC auf „Ja" gesetzt — und die Verkaufschance beim nächsten Lauf in Business Central angelegt.

Zwei Bedingungen müssen erfüllt sein:

1. Sync zu BC steht auf „Ja"
2. das Feld BC System-ID ist noch leer

Unmittelbar danach läuft die Rückmeldung aus BC und trägt BC Verkaufschancennummer und BC System-ID nach.

Vorher: der Kontakt muss in BC sein

Business Central hängt eine Verkaufschance an einen Kontakt. Existiert der dort nicht, kann die Verkaufschance nicht angelegt werden. Die Lösung lehnt die Freigabe deshalb ab, solange die BC Kontaktnummer des Kontakts leer ist — und ganz ohne Kontakt ohnehin.

flowchart LR
  A["Verkaufschance in CE"] --> B{"Kontakt vorhanden?"}
  B -->|nein| X["Freigabe wird abgelehnt"]
  B -->|ja| C{"BC Kontaktnummer<br/>des Kontakts gefüllt?"}
  C -->|nein| X
  C -->|ja| D{"Sync zu BC = Ja?"}
  D -->|nein| E["nichts passiert"]
  D -->|ja| F["Verkaufschance wird<br/>in BC angelegt"]

Das ist die dritte Stufe der Kette Firma → Kontakt → Verkaufschance, beschrieben unter Freigabe nach Business Central.

Welche Felder gehen nach BC?

Neun Zuordnungen — die schlankste Übertragung der ganzen Integration. Business Central braucht von einer Verkaufschance nur, was es zur Angebotserstellung benötigt.

Worauf zu achten ist

Business Central erhält einen Link zurück ins CRM

Die Übertragung baut aus der Datensatz-GUID einen vollständigen Deep Link auf die Verkaufschance in Customer Engagement und legt ihn in BC im Feld Dynamics-Sales-Link ab. Wer im ERP an der Verkaufschance arbeitet, springt damit direkt in den CRM-Datensatz.

Nach der Anlage stehen die Daten in BC still

Es gibt keinen aktiven Änderungspfad für die Verkaufschance. Wird das Thema, die Firma, der Kontakt oder der Verkäufer nachträglich in CE geändert, kommt das nicht in Business Central an. Der dortige Stand bleibt auf dem Zeitpunkt der Anlage.

Die zugehörigen Positionen werden dagegen laufend abgeglichen.

Der voraussichtliche Umsatz kann berechnet sein

Das übertragene Feld Voraussichtlicher Umsatz wird in CE je nach Konfiguration manuell erfasst oder aus den Positionen bzw. dem führenden Angebot berechnet — siehe Beträge und Margen. Übertragen wird der Wert, der beim Lauf im Feld steht.

Doppelte Anlage ist ausgeschlossen

Läuft der Abgleich zweimal, bevor die Rückmeldung eingetroffen ist, entsteht in BC trotzdem keine zweite Verkaufschance — der Datensatz wird über die in BC hinterlegte Dataverse Id wiedererkannt.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → opportunitiesnewfromce.

4.5.2 - Rückmeldung aus Business Central

Was passiert hier?

Wenn eine Verkaufschance neu nach BC übertragen wird, vergibt Business Central zwei Werte, die Customer Engagement noch nicht kennen kann:

• die BC Verkaufschancennummer aus dem Nummernkreis des ERP
• die BC System-ID, den technischen Schlüssel des Datensatzes

Dieser Schritt trägt beides in CE nach. Er 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 Verkaufschance anlegen
  BC-->>CE: Antwort mit Verkaufschancennummer<br/>und BC System-ID
  Note over CE: Rückmeldung trägt beides<br/>an der Verkaufschance nach

Welche Felder kommen zurück?

Warum dieser Schritt die Positionen erst möglich macht

Bei Firma und Kontakt ist die Rückmeldung vor allem der Nachweis, dass der Datensatz im ERP angekommen ist. Bei der Verkaufschance hat sie darüber hinaus eine ganz konkrete Funktion: Ohne die BC Verkaufschancennummer lässt sich keine Position übertragen.

Business Central adressiert eine Verkaufschancenposition über die Nummer ihrer Verkaufschance. Der Schritt Positionen neu nach BC löst dazu das Feld BC Verkaufschancennummer auf. Ist es leer, findet die Position ihr Ziel nicht.

Da die Positions-Jobs mit Order 710 – 760 deutlich hinter der Verkaufschance (260 / 261) laufen, greift das innerhalb desselben Durchlaufs.

Worauf zu achten ist

Bleibt die Rückmeldung aus, hängt die ganze Kette

Ohne BC System-ID gilt die Verkaufschance als „nicht in BC vorhanden" und würde beim nächsten Lauf erneut zur Anlage angeboten — dass dabei keine Dublette entsteht, verhindert die Wiedererkennung über die Dataverse Id. Gleichzeitig bleibt die BC Verkaufschancennummer leer, sodass auch keine Position übertragen werden kann. Bleibt der Zustand über mehrere Läufe bestehen, sollte das geprüft werden.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → opportunitiesresponsefrombc.

4.5.3 - Kalkulationselemente aus Business Central übernehmen

Was passiert hier?

Business Central kalkuliert eine Verkaufschance nicht aus Artikeln, sondern aus Verkaufschancen-Elementen — gröberen Bausteinen wie „Lizenzen", „Einführung" oder „Betrieb", die jeweils eigene buchhalterische Dimensionen tragen.

Dieser Schritt holt diese Elemente nach Customer Engagement, damit sie dort in Verkaufschancenpositionen ausgewählt werden können.

Sie landen in der Produkttabelle

Das ist die Besonderheit dieses Schritts:

Die Kalkulationselemente werden in CE als Produkte angelegt — in der Standard-Produkttabelle.

Am Produkt kennzeichnet das Feld Verkaufschancen-Element (wysa_OppElement), welche Datensätze in einer Verkaufschancenposition verwendet werden dürfen. Der Abgleich schreibt dieses Feld nicht selbst; eine Geschäftsregel am Produkt setzt es auf „Ja", sobald der BC Dimension 1 Wert gefüllt ist — also bei jedem aus BC übernommenen Element.

Welche Felder kommen an?

Wiedererkannt wird ein Element über den BC Code.

Worauf zu achten ist

Die Dimensionen wandern mit

Jedes Element bringt bis zu zwei buchhalterische Dimensionen samt Werten mit. Sie werden am Produkt gespeichert und laufen später mit der Position nach BC zurück — so bleibt die Kalkulation kontierbar.

Ohne diesen Schritt keine Positionen

Eine Verkaufschancenposition wird nach BC über den Elementcode übertragen, den sie aus dem verknüpften Produkt zieht. Fehlt das Element in CE, kann die Position nicht angelegt werden. Dieser Schritt läuft alle zwei Minuten, die Positions-Jobs alle drei — die Elemente sind also stets vorab verarbeitet, siehe Ausführungsreihenfolge und Takt.

Warum dieser Schritt hier steht

Fachlich ist er ein Stammdaten-Abgleich und läuft im Stammdatenblock. Dokumentiert ist er hier, weil die Elemente, die er liefert, ausschließlich in Verkaufschancenpositionen und Angebotspositionen verwendet werden. Die übrigen Stammdaten-Abgleiche stehen unter Stammdaten.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → opportunityelementsfrombc.

4.5.4 - Neue Positionen nach Business Central übertragen

Was passiert hier?

Die Positionen einer Verkaufschance — in CE die Verkaufschancenprodukte — werden in Business Central als Kalkulationszeilen der Verkaufschance angelegt. Aus ihnen entsteht dort später das Angebot.

Zwei Bedingungen müssen erfüllt sein:

1. Sync zu BC an der Position steht auf „Ja"
2. das Feld BC System-ID der Position ist noch leer

Zwei Voraussetzungen an anderen Datensätzen

Eine Position adressiert ihr Ziel in BC über zwei Werte, die sie sich aus verknüpften Datensätzen holt:

flowchart LR
  P["Position in CE"] --> A["Verkaufschance<br/><b>BC Verkaufschancennummer</b>"]
  P --> B["Produkt<br/><b>BC Code</b>"]
  A --> Z["Kalkulationszeile in BC"]
  B --> Z

Fehlt einer der beiden, findet die Position ihr Ziel nicht.

Sichergestellt ist das über den Takt: Verkaufschance und Kalkulationselemente laufen alle zwei Minuten, dieser Schritt alle drei. Die Vorarbeit ist also stets erledigt — allerdings aus einem früheren Durchlauf, nicht aus demselben. Siehe Ausführungsreihenfolge und Takt.

Welche Felder gehen nach BC?

„LW" steht für Landeswährung — Business Central führt diese Beträge in der Währung des Buchungskreises.

Worauf zu achten ist

Beschreibung und Marge gehen auch bei Änderungen mit

Beschreibung und Marge sind sowohl Teil dieses Schritts als auch des Schritts Positionsänderungen nach BC. Werden sie später in CE geändert, kommt das in Business Central an.

Wiedererkennung über die BC System-ID

Anders als Firma, Kontakt und Verkaufschance schickt dieser Schritt keine Dataverse Id mit. Die Position wird in Business Central über die BC System-ID adressiert, die anschließend über die Rückmeldung nach CE kommt.

Die Freigabe folgt der Verkaufschance

Das Feld Sync zu BC an der Position (wysa_SynctoBC) folgt der Freigabe der Verkaufschance — es muss nicht je Position einzeln gesetzt werden. Zu beachten ist der abweichende technische Feldname gegenüber der Verkaufschance (wysa_sync2bc), siehe Übersicht.

Anderer Takt als die übrigen Schritte

Die Positions-Jobs laufen alle 3 Minuten, nicht alle 2 wie der Rest der Integration. Zusammen mit der Reihenfolge bedeutet das: Zwischen der Freigabe einer Verkaufschance und dem Ankommen ihrer Positionen in BC können einige Minuten liegen.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → opportunityproductsnewfromce.

4.5.5 - Rückmeldung der Positionen aus Business Central

Was passiert hier?

Wenn eine Position neu nach BC übertragen wird, vergibt Business Central für die entstandene Kalkulationszeile eine System-ID. Dieser Schritt trägt sie an der Position in Customer Engagement nach.

sequenceDiagram
  participant CE as Customer Engagement
  participant BC as Business Central
  CE->>BC: neue Kalkulationszeile anlegen
  BC-->>CE: Antwort mit System-ID
  Note over CE: Rückmeldung trägt die<br/>BC System-ID an der Position nach

Welche Felder kommen zurück?

Nur ein Feld — die knappste Rückmeldung der ganzen Integration. Eine eigene Nummer vergibt Business Central für Kalkulationszeilen nicht; sie sind über ihre Verkaufschancennummer und den Elementcode adressierbar.

Warum dieser Schritt entscheidend ist

Die BC System-ID ist die Weiche zwischen Anlegen und Ändern:

Solange sie leer bleibt, gilt die Position als „nicht in BC vorhanden" und wird beim nächsten Lauf erneut zur Anlage angeboten. Da die Positionen — anders als Firma, Kontakt und Verkaufschance — keine Wiedererkennung über eine mitgeschickte CE-GUID haben, ist diese Rückmeldung ihre einzige Absicherung gegen wiederholtes Anlegen. Siehe die Hinweise auf Positionen neu nach BC.

Worauf zu achten ist

Der Änderungsjob läuft vor dem Anlagejob

Ein Blick auf die Reihenfolge lohnt: Der Änderungsjob trägt Order 750, der Anlagejob 710 und dieser Rückmeldeschritt 760.

Alle drei liegen im Drei-Minuten-Takt, laufen also tatsächlich im selben Tick — hier greift die Ordnungsnummer. Innerhalb eines Durchlaufs wird demnach erst angelegt, dann geändert, dann die System-ID nachgetragen.

Eine frisch angelegte Position hat beim Änderungsjob desselben Durchlaufs noch keine System-ID und fällt dort nicht in den Filter — sie wird erst im nächsten Durchlauf für Änderungen erfasst. Für die Praxis ist das ohne Folgen, weil die Anlage alle Werte bereits mitgeschickt hat.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → opportunityproductsresponsefrombc.

4.5.6 - Positionsänderungen nach Business Central übertragen

Was passiert hier?

Ändert sich an einer Position die Menge, die Beschreibung oder ein Betrag, geht das nach Business Central. Dieser Schritt ist damit der einzige aktive Änderungspfad im Bereich Verkaufschance — für die Verkaufschance selbst gibt es keinen, siehe Übersicht.

Erfasst werden Positionen, bei denen beides zutrifft:

1. Sync zu BC an der Position steht auf „Ja"
2. das Feld BC System-ID der Position ist gefüllt

Ist die BC System-ID leer, greift stattdessen Positionen neu nach BC.

Welche Felder gehen nach BC?

Sieben fachliche Felder — dieselben wie bei der Anlage.

Worauf zu achten ist

Beschreibung und Marge gehen auch bei Änderungen mit

Anlage (710) und Änderung (750) übertragen denselben Feldsatz — inklusive Beschreibung und Marge. Wird eine davon später in CE geändert, kommt das in Business Central an.

Die Zuordnung wird bei jedem Lauf neu aufgelöst

Verkaufschancennummer und Elementcode sind Teil jeder Übertragung — sie werden also bei jeder Änderung erneut aus Verkaufschance und Produkt aufgelöst. Wird eine Position in CE auf ein anderes Produkt umgestellt, geht das damit auch nach BC.

Der Änderungsjob läuft vor der Rückmeldung

Innerhalb eines Durchlaufs ist die Reihenfolge: anlegen (710) → ändern (750) → System-ID zurückmelden (760). Da alle drei im Drei-Minuten-Takt liegen, greift die Ordnungsnummer hier wirklich.

Eine frisch angelegte Position hat beim Änderungsjob desselben Durchlaufs noch keine System-ID und fällt dort nicht in den Filter. Sie wird erst im nächsten Durchlauf für Änderungen erfasst — ohne praktische Folge, weil die Anlage alle Werte bereits mitgeschickt hat.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → opportunityproductsupdatesfromce.

4.6 - Angebot

Das Angebot schließt den großen Kreis der Integration. Die Verkaufschance geht von Customer Engagement nach Business Central — dort entsteht daraus das kaufmännische Dokument, und dieses kommt zurück:

Das Angebot läuft ausschließlich von Business Central nach Customer Engagement.

In CE wird kein Angebot erfasst und keines nach BC übertragen. Kalkulation, Preise, Rabatte und Belegnummern gehören ins ERP; Customer Engagement führt das Angebot nur mit, damit der Vertrieb Pipeline und Abschluss im CRM sieht.

flowchart LR
  A["Verkaufschance in CE"] -->|"Verkaufschance<br/>nach BC"| B["Verkaufschance in BC"]
  B -->|"Angebot erstellen<br/>(in BC)"| C["Angebot in BC"]
  C -->|"<b>Angebot nach CE</b>"| D["Angebot in CE"]
  D -.->|"verknüpft mit"| A

Der Ablauf

flowchart TB
  Q["Angebot in BC angelegt<br/>oder geändert"] --> S1["<b>Angebote aus BC</b><br/>Angebotskopf nach CE"]
  S1 --> V{"Verkaufschance<br/>über BC-Nummer<br/>gefunden?"}
  V -->|ja| VK["Angebot hängt an<br/>der Verkaufschance"]
  V -->|nein| FREI["Angebot ohne<br/>Verkaufschance"]

  S1 --> S2["<b>Positionen aus BC</b><br/>Kalkulationszeilen nach CE"]

  VK --> T{"In BC in einen<br/>Auftrag überführt?"}
  FREI --> T
  T -->|"ja — Status TRANSFERRED"| W["<b>Gewonnene Angebote aus BC</b><br/>Angebot wird <b>Gewonnen</b>"]

  Q --> DEL["Angebot in BC gelöscht"]
  DEL --> D1["<b>Stornierung</b><br/>Angebot wird in CE<br/><b>geschlossen / storniert</b>"]
  Q --> DELP["Position in BC gelöscht"]
  DELP --> D2["<b>Löschung</b><br/>Position wird in CE<br/><b>gelöscht</b>"]

Zwei Besonderheiten gegenüber den anderen Bereichen

Positionen werden wirklich gelöscht

Firma, Kontakt und Produkt werden bei einer Löschung in BC nur deaktiviert — an ihnen hängt Historie. Angebote werden geschlossen und storniert, Angebotspositionen dagegen tatsächlich gelöscht:

Das stornierte Angebot bleibt an der Verkaufschance nachvollziehbar, zählt aber nicht mehr als offen. Eine Position ist dagegen eine reine Kopie der BC-Kalkulationszeile; existiert sie in BC nicht mehr, hat sie keinen Wert. Technisch trägt nur der Positions-Job Action = Delete — siehe Datenfluss.

Der Abschluss kommt aus dem ERP

Ob ein Angebot gewonnen ist, entscheidet Business Central: Wird der Beleg dort in einen Auftrag überführt, meldet das Änderungsprotokoll den Vorgang TRANSFERRED. Der Schritt Gewonnene Angebote aus BC setzt das Angebot in CE daraufhin auf Gewonnen.

Der Vertrieb muss den Abschluss also nicht doppelt pflegen. Was daraus weiter folgt — etwa das optionale Gewinnen der verknüpften Verkaufschance — steht unter Abschluss von Angebot und Verkaufschance.

Wie ein Angebot seine Zuordnungen findet

Ein Angebotskopf bringt aus BC nur Nummern und Codes mit. Drei davon werden in CE zu Verknüpfungen aufgelöst:

flowchart LR
  Q["Angebot aus BC"] -->|"Verkaufschancennummer"| O["Verkaufschance"]
  Q -->|"<b>Kontaktnummer</b>"| A["Firma"]
  Q -->|"Verkäufercode"| S["Verkäufer (BC)"]

Positionen enthalten Kalkulationselemente, keine Artikel

Die Angebotspositionen in CE werden aus den Kalkulationselementen des BC-Belegs gefüllt — denselben Bausteinen, die auch die Verkaufschancenpositionen verwenden.

Die eigentlichen Artikelzeilen eines BC-Angebots werden nicht übertragen. Angebote in CE zeigen also die Kalkulation, nicht die Artikelaufstellung.

Welche Felder kommen an?

Angebotskopf

Angebotsposition

Was der Abgleich nicht liefert

Mehrere Felder des Datenmodells werden von diesen Schritten nicht gefüllt. Sie entstehen in Customer Engagement selbst:

Die ersten drei sind unter Beträge und Margen und Abschluss beschrieben.

Technische Zuordnung

4.6.1 - Angebote aus Business Central übernehmen

Was passiert hier?

Sobald in Business Central ein Angebot angelegt oder geändert wird, erscheint es in Customer Engagement — mit Nummer, Betrag, Gültigkeit und Zuordnung zu Verkaufschance und Kunde. Existiert das Angebot in CE schon, werden seine Felder aktualisiert.

Wiedererkannt wird ein Angebot über die Angebotsnummer. Sie ist in beiden Systemen dieselbe — das Angebot ist damit der einzige Datensatz der Integration, der über eine fachliche Belegnummer verbunden ist und nicht über einen technischen Schlüssel.

Der Job liest ausschließlich Belege der Art Angebot; Aufträge und Rechnungen bleiben außen vor.

Welche Felder kommen an?

Worauf zu achten ist

So schließt sich der Kreis zur Verkaufschance

Das Angebot findet seine Verkaufschance über die BC Verkaufschancennummer — genau jenes Feld, das die Rückmeldung aus BC an der Verkaufschance gefüllt hat.

Damit ist der Weg vollständig: Die Verkaufschance geht von CE nach BC, bekommt dort eine Nummer, aus ihr entsteht ein Angebot, und das Angebot kommt über dieselbe Nummer zurück und hängt sich an die richtige Verkaufschance.

Wird in Business Central ein Angebot ohne Bezug zu einer Verkaufschance erstellt, kommt es in CE ohne diese Verknüpfung an — es ist dann ein freistehendes Angebot.

Der Kunde wird über die BC Kontaktnummer gefunden

Der Nettobetrag kommt nicht mit

Übertragen wird nur der Bruttobetrag (BC Gesamtbetrag inkl. MwSt.). Das Feld BC Gesamtbetrag (netto) und die Marge werden in CE aus den Angebotspositionen aufsummiert — siehe Beträge und Margen.

Der Status entscheidet über den Abschluss

Das Feld BC Status trägt den Bearbeitungsstand des Belegs aus BC. Meldet Business Central den Wert TRANSFERRED — das Angebot wurde in einen Auftrag überführt —, wird das Angebot in CE gewonnen. Das erledigt der Schritt Gewonnene Angebote aus BC; die Folgewirkungen sind unter Abschluss von Angebot und Verkaufschance beschrieben.

Angebote werden nicht nach BC zurückgeschrieben

Es gibt keinen Weg von CE nach BC. Was am Angebot in CE geändert wird, bleibt dort und wird beim nächsten Abgleich aus BC überschrieben. Das Angebot ist eine Kopie des BC-Belegs.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → salesquotesfrombc.

4.6.2 - Angebotspositionen aus Business Central übernehmen

Was passiert hier?

Ein Angebot in Business Central wird aus Kalkulationselementen aufgebaut — Bausteinen wie „Lizenzen", „Einführung" oder „Betrieb", die jeweils Menge und Betrag tragen. Dieser Schritt holt sie als Angebotspositionen nach Customer Engagement.

Wiedererkannt wird eine Position über die BC System-ID der Kalkulationszeile.

Es sind Kalkulationselemente, keine Artikelzeilen

Das ist der wichtigste Punkt zum Verständnis:

In Customer Engagement zeigt ein Angebot die Kalkulation des BC-Belegs, nicht seine Artikelaufstellung.

Ein BC-Angebot hat beides: Verkaufszeilen mit Artikeln und darüber die Kalkulation aus Elementen. Übertragen wird nur die Kalkulation.

Die Elemente sind dieselben, die auch die Verkaufschancenpositionen verwenden. Sie kommen über Kalkulationselemente aus BC (Job 190) als Produkte nach CE. Damit ist die Kalkulation über die gesamte Kette hinweg vergleichbar: dieselben Bausteine in der Verkaufschance wie später im Angebot.

Welche Felder kommen an?

„LW" steht für Landeswährung.

Worauf zu achten ist

Zwei Zuordnungen müssen gelingen

flowchart LR
  P["Kalkulationszeile aus BC"] -->|"Belegnummer"| Q["Angebot in CE"]
  P -->|"Elementcode"| E["Produkt in CE"]

Beide Vorgänger-Jobs laufen früher (190 und 610 gegenüber 620), sodass das innerhalb desselben Durchlaufs zusammenfindet. Fehlt eines der beiden Ziele, kann die Position nicht korrekt eingehängt werden.

Der Deckungsbeitrag kommt nicht mit

Das Datenmodell führt an der Angebotsposition ein Feld BC Deckungsbeitrag (wysa_bcProfit). Dieser Abgleich füllt es nicht — die Position kommt nur mit Netto- und Bruttobetrag an.

Eine feste Einheiten-GUID

Die Einheit der Position wird mit einem fest hinterlegten Wert gesetzt.

Löschungen laufen über einen eigenen Job

Wird eine Kalkulationszeile in BC gelöscht, verschwindet sie aus dieser Schnittstelle und kann durch Abgleich nicht mehr gefunden werden. Das erledigt Positionen löschen (621) über das Änderungsprotokoll — und zwar durch echtes Löschen, nicht durch Deaktivieren.

Technische Details

Die vollständige technische Mapping-Tabelle mit Feldzuordnungen, Key-Auflösung und Transformationen steht unter Technisches Mapping → salescalculationelementsfrombc.

4.6.3 - Gewonnene Angebote aus Business Central

Was passiert hier?

Wird ein Angebot in Business Central in einen Auftrag überführt, ist es kaufmännisch gewonnen. Business Central schreibt diesen Vorgang in sein Änderungsprotokoll — als Vorgang TRANSFERRED. Dieser Schritt liest das Protokoll und setzt das Angebot in Customer Engagement auf Gewonnen.

flowchart LR
  A["Angebot in BC<br/>in Auftrag überführt"] --> B["Eintrag im Änderungsprotokoll<br/>Vorgang <b>TRANSFERRED</b>"]
  B --> C["Angebot in CE über die<br/>BC System-ID gefunden"]
  C --> D["<b>BC Status</b> = TRANSFERRED<br/>Angebot wird <b>Gewonnen</b>"]

Der Abschluss wird nicht doppelt gepflegt

Das ist die fachliche Kernaussage dieses Schritts:

Führendes System für den Auftrag ist Business Central. Customer Engagement folgt.

Der Vertrieb muss ein gewonnenes Angebot in CE nicht von Hand abschließen. Der Abschluss im ERP genügt — und weil er dort an die Auftragserstellung gebunden ist, kann in CE kein Angebot als gewonnen gelten, dem im ERP kein Auftrag gegenübersteht.

Was sich am Angebot ändert