Mapping

• 1: Datenfluss
• 2: Stammdaten
• 2.1: Wertelisten aus Business Central übernehmen
• 2.2: Verkäufer aus Business Central übernehmen
• 2.3: Produkte deaktivieren
• 3: Firma
• 3.1: Firmen aus Business Central übernehmen
• 3.2: Neue Firmen nach Business Central übertragen
• 3.3: Rückmeldung aus Business Central
• 3.4: Änderungen nach Business Central übertragen
• 3.5: Löschung in Business Central nachvollziehen
• 4: Kontakt
• 4.1: Kontakte aus Business Central übernehmen
• 4.2: Neue Kontakte nach Business Central übertragen
• 4.3: Rückmeldung aus Business Central
• 4.4: Änderungen nach Business Central übertragen
• 4.5: Löschung in Business Central nachvollziehen
• 5: Verkaufschance
• 5.1: Neue Verkaufschancen nach Business Central übertragen
• 5.2: Rückmeldung aus Business Central
• 5.3: Kalkulationselemente aus Business Central übernehmen
• 5.4: Neue Positionen nach Business Central übertragen
• 5.5: Rückmeldung der Positionen aus Business Central
• 5.6: Positionsänderungen nach Business Central übertragen
• 6: Angebot
• 6.1: Angebote aus Business Central übernehmen
• 6.2: Angebotspositionen aus Business Central übernehmen
• 6.3: Gewonnene Angebote aus Business Central
• 6.4: Angebotspositionen löschen
• 6.5: In BC gelöschte Angebote stornieren
• 7: Abonnement
• 7.1: Abonnements aus Business Central übernehmen
• 7.2: Abonnementzeilen aus Business Central übernehmen
• 8: Technisches Mapping
• 8.1: 110 · countriesfrombc
• 8.2: 115 · languagesfrombc
• 8.3: 120 · salutationsfrombc
• 8.4: 125 · customerdiscountgroupsfrombc
• 8.5: 130 · salespersonsfrombc
• 8.6: 135 · positionsfrombc
• 8.7: 190 · opportunityelementsfrombc
• 8.8: 220 · accountsnewfromce
• 8.9: 221 · accountsresponsefrombc
• 8.10: 240 · contactsnewfromce
• 8.11: 241 · contactsresponsefrombc
• 8.12: 260 · opportunitiesnewfromce
• 8.13: 261 · opportunitiesresponsefrombc
• 8.14: 410 · accountsfrombc
• 8.15: 420 · accountsfrombcdelete
• 8.16: 430 · contactsfrombc
• 8.17: 440 · contactsfrombcdelete
• 8.18: 450 · productsfrombcdelete
• 8.19: 520 · accountupdatesfromce
• 8.20: 530 · contactupdatesfromce
• 8.21: 550 · serviceobjectsfrombc
• 8.22: 560 · servicecommitmentsfrombc
• 8.23: 610 · salesquotesfrombc
• 8.24: 620 · salescalculationelementsfrombc
• 8.25: 621 · salescalculationelementsfrombcdelete
• 8.26: 625 · activatesalesquotesfrombc
• 8.27: 690 · salesquotesfrombcdelete
• 8.28: 710 · opportunityproductsnewfromce
• 8.29: 750 · opportunityproductsupdatesfromce
• 8.30: 760 · opportunityproductsresponsefrombc

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

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.

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 }
  ]
}

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:

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.

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.

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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

Alle übrigen Felder bleiben unverändert.

Was daraus weiter folgt

Das Feld BC Status ist mehr als eine Notiz — an ihm hängt weitere Logik in Customer Engagement:

• Ist die Einstellung wysa_WinQuoteAndOpportunity aktiv, wird zusätzlich die verknüpfte Verkaufschance gewonnen, mit dem Angebotsbetrag als tatsächlichem Umsatz.
• Ohne diese Einstellung bleibt der Abschluss der Verkaufschance eine bewusste Handlung des Vertriebs.

Beschrieben ist das unter Abschluss von Angebot und Verkaufschance und Konfiguration.

Worauf zu achten ist

Zwei Jobs lesen dasselbe Protokoll

Dieser Schritt und Angebote stornieren lesen beide die Protokolleinträge zur BC-Tabelle Verkaufskopf. Sie trennen sich allein über die Art des Vorgangs:

Andere Vorgangsarten werden von keinem der beiden Jobs verarbeitet.

Der Takt weicht ab

Dieser Job läuft alle 3 Minuten, die übrigen Angebots-Jobs alle 2. Zwischen der Auftragserstellung in BC und dem gewonnenen Angebot in CE können damit einige Minuten liegen.

Ein Rückweg existiert nicht

Wird der Auftrag in BC storniert, gibt es keinen Job, der das Angebot in CE wieder öffnet. Der Vorgang ist einseitig.

Verlieren funktioniert anders

Der Verlust kommt nicht aus BC, sondern wird in Customer Engagement entschieden: Wird eine Verkaufschance auf Verloren gesetzt, schließt die Lösung ihre Angebote mit — siehe Abschluss. Ein Mapping ist daran nicht beteiligt.

Technische Details

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

6.4 - Angebotspositionen löschen

Was passiert hier?

Wird in Business Central eine Kalkulationszeile aus einem Angebot entfernt, wird die zugehörige Angebotsposition in Customer Engagement gelöscht.

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

Der Weg über das Änderungsprotokoll ist nötig, weil eine gelöschte Zeile in der normalen Schnittstelle nicht mehr auftaucht und durch Abgleich nicht gefunden werden könnte.

Hier wird wirklich gelöscht

Anders als bei Firma, Kontakt und Produkt wird nicht deaktiviert, sondern gelöscht:

Das ist folgerichtig. Eine Angebotsposition in CE ist eine reine Kopie der BC-Zeile — sie trägt keine eigene Information, an ihr hängt keine Historie, und eine inaktive Position würde die Summenbildung des Angebots nur verfälschen. Ohne Löschen bliebe eine in BC gestrichene Leistung im CE-Angebot stehen.

Worauf zu achten ist

Das Angebot wird neu summiert

Gesamtbetrag und Marge eines Angebots werden in CE aus den Positionen aufsummiert. Nach dem Löschen einer Position ändern sich diese Summen — siehe Beträge und Margen.

Ein Wiederherstellen gibt es nicht

Die Position ist in CE endgültig entfernt. Wird die Zeile in BC erneut angelegt, kommt sie über Positionen aus BC als neue Position mit neuer BC System-ID zurück.

Beim Löschen des ganzen Angebots

Wird in BC nicht eine Zeile, sondern das ganze Angebot gelöscht, greift Angebote stornieren (690). Das Angebot wird in CE nicht gelöscht, sondern geschlossen — seine Positionen bleiben daher erhalten, sofern BC nicht für jede Zeile einen eigenen Protokolleintrag schreibt und dieser Job anspringt.

Technische Details

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

6.5 - In BC gelöschte Angebote stornieren

Was passiert hier?

Wird ein Angebot in Business Central gelöscht, bleibt es in Customer Engagement erhalten, wird aber geschlossen und bekommt den Statusgrund Storniert. Es ist danach schreibgeschützt und taucht in keiner Auswertung offener Angebote mehr auf.

flowchart LR
  A["Angebot in BC gelöscht"] --> B["Eintrag im Änderungsprotokoll<br/>Vorgang <b>DELETE</b>"]
  B --> C["Angebot in CE über die<br/>BC System-ID gefunden"]
  C --> D["Angebot wird <b>geschlossen</b><br/>Statusgrund <b>Storniert</b>"]

Stornieren statt Löschen

Früher wurde das Angebot in CE hart gelöscht. Jetzt bleibt es als stornierter Datensatz stehen: Man sieht an der Verkaufschance weiterhin, dass es ein Angebot gab und dass es in BC verworfen wurde. Weil das Angebot geschlossen ist, zählt es in der Pipeline nicht mehr als offen.

Worauf zu achten ist

Die Positionen bleiben am Angebot

Da das Angebot nicht mehr gelöscht wird, werden seine Positionen auch nicht mehr automatisch mit entfernt. Löscht BC beim Löschen des Angebots auch die Kalkulationszeilen einzeln, greift zusätzlich Positionen löschen; sonst bleiben die Positionen am stornierten Angebot sichtbar.

Was mit der Verkaufschance passiert

Die Verkaufschance bleibt unberührt. Das stornierte Angebot bleibt mit ihr verknüpft.

Kein Wiederöffnen aus BC

Ein in BC gelöschtes Angebot kommt nicht zurück. Wird in BC ein neues Angebot angelegt, kommt es mit neuer Nummer und neuer BC System-ID als eigenständiger Datensatz nach CE.

Zwei Jobs lesen dasselbe Protokoll

Dieser Schritt und Gewonnene Angebote aus BC lesen beide die Protokolleinträge zur BC-Tabelle Verkaufskopf und trennen sich über die Art des Vorgangs:

Technische Details

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

7 - Abonnement

Ein Abonnement bildet eine wiederkehrend abgerechnete Leistung ab: eine Lizenz, einen Cloud-Service, einen Wartungsvertrag. Diese Daten entstehen in der Abonnementverwaltung von Business Central — Customer Engagement führt sie mit, damit der Vertrieb Bestand, Laufzeiten und Kündigungsfristen im Blick hat.

Abonnements laufen ausschließlich von Business Central nach Customer Engagement.

Es gibt keinen Rückweg und keine Löschverarbeitung. Der Bereich besteht aus zwei Schritten, die aufeinander aufbauen:

Zwei Ebenen

flowchart TB
  BC["Abonnementverwaltung<br/>in Business Central"]
  BC -->|"550 · <b>Abonnements aus BC</b>"| A["<b>Abonnement</b><br/>Was ist abonniert?<br/>Produkt, Menge, Seriennummer,<br/>Bereitstellungszeitraum"]
  BC -->|"560 · <b>Abonnementzeilen aus BC</b>"| Z["<b>Abonnementzeile</b><br/>Zu welchen Bedingungen?<br/>Laufzeit, Preis, Rabatt,<br/>Kündigungsfrist"]
  Z -->|"über die<br/>Abonnementnummer"| A

Ein Abonnement kann mehrere Zeilen mit unterschiedlichen Laufzeiten und Abrechnungsrhythmen haben. Die Zeile findet ihr Abonnement über die Abonnementnummer — deshalb muss Schritt 550 vor Schritt 560 laufen, was die Ordnungsnummern sicherstellen.

Rechnungsempfänger und Leistungsnehmer

Die fachlich interessanteste Eigenschaft dieses Bereichs: Das Abonnement trennt zwei Rollen, die in Konzernstrukturen auseinanderfallen.

Beide werden je als Firma und Kontakt übertragen — vier Verknüpfungen pro Abonnement. Business Central liefert dafür vier Kontaktnummern, die in CE aufgelöst werden.

Was in Customer Engagement bleibt

Nicht alle Felder der beiden Tabellen kommen aus Business Central. Diese werden CE-seitig gepflegt oder durch Automatik gefüllt:

Das passt zum Zweck des Bereichs: Business Central liefert den Vertragsbestand, Customer Engagement ergänzt die Vertriebssicht — aus einem auslaufenden Abonnement kann ein Lead entstehen, und dazu gehören Verkaufschance und Mitbewerber.

Worauf zu achten ist

Die Abonnementart wird fest gesetzt

Das Feld Abonnementart wird bei jedem Lauf auf einen festen Vorgabewert gesetzt — Business Central liefert dazu nichts. Eine Unterscheidung nach Ausprägung findet über diesen Abgleich also nicht statt; eine in CE geänderte Abonnementart wird beim nächsten Lauf überschrieben.

Die Quellen liegen außerhalb der dyce-Schnittstelle

Alle übrigen Abgleiche lesen API Pages der Singhammer-Erweiterung unter singhammerITConsulting/dyce/v2.0/. Die beiden Abonnement-Jobs lesen stattdessen serviceObjects und serviceCommitments — die Schnittstelle der Abonnementverwaltung von Business Central selbst.

Praktische Folge: Dieser Bereich hängt an einer anderen Erweiterung als der Rest der Integration. Wird sie in BC nicht bereitgestellt, laufen die beiden Jobs ins Leere, während alles andere weiterarbeitet.

Kündigung möglich bis ist das wichtigste Datum

Von den 27 Feldern der Abonnementzeile ist eines für den Vertrieb entscheidend: Kündigung möglich bis. Es nennt den konkreten Stichtag, bis zu dem der Kunde kündigen kann — und damit den Zeitpunkt, an dem eine Verlängerung spätestens verhandelt sein muss. Alle übrigen Laufzeit- und Fristenfelder sind die Herleitung dazu.

Technische Zuordnung

7.1 - Abonnements aus Business Central übernehmen

Was passiert hier?

Dieser Schritt holt die abonnierten Leistungen aus Business Central: was abonniert ist, in welcher Menge, mit welcher Seriennummer, für welchen Bereitstellungszeitraum — und für wen.

Die kaufmännischen Bedingungen dazu, also Laufzeiten, Preise und Kündigungsfristen, kommen im zweiten Schritt: Abonnementzeilen aus BC.

Wiedererkannt wird ein Abonnement über die Abonnementnummer.

Welche Felder kommen an?

Worauf zu achten ist

Vier Verknüpfungen für zwei Rollen

Das Abonnement trennt, wer bezahlt und wer nutzt — in Konzernstrukturen sind das verschiedene Firmen. Business Central liefert dafür die Rechnungs- und die Lieferadresse des Belegs, jeweils als Kontakt- und als Unternehmenskontaktnummer:

flowchart LR
  BC["Abonnement in BC"] -->|"Rechnung an<br/>Kontaktnr."| A["Rechnungsempfänger<br/>Kontakt"]
  BC -->|"Rechnung an<br/>Unternehmenskontaktnr."| B["Rechnungsempfänger<br/>Firma"]
  BC -->|"Liefern an<br/>Kontaktnr."| C["Leistungsnehmer<br/>Kontakt"]
  BC -->|"Liefern an<br/>Unternehmenskontaktnr."| D["Leistungsnehmer<br/>Firma"]

Alle vier werden über die BC Kontaktnummer aufgelöst — auch die beiden auf Firmen. Das ist die zuverlässigere Variante gegenüber der Debitorennummer, die das Angebot verwendet: Die Kontaktnummer ist an jeder nach BC übertragenen Firma vorhanden.

Ist eine Firma oder ein Kontakt in CE nicht auffindbar, bleibt die entsprechende Verknüpfung leer — das Abonnement wird trotzdem angelegt. Da die Kontakt-Jobs (430) vor diesem Schritt laufen, findet das normalerweise innerhalb desselben Durchlaufs zusammen.

Die Produktnummer kommt als Text, nicht als Verweis

Produktnummer und Produktbeschreibung werden als Text übertragen. Das Feld Produkt — der eigentliche Verweis auf den Produktdatensatz — bleibt leer.

Die Nummer steht in zwei Feldern

Die Abonnementnummer wird doppelt geschrieben: einmal in das Fachfeld Nummer, über das auch die Zuordnung läuft, und einmal in das Namensfeld des Datensatzes. Damit erscheint in Listen und Verknüpfungen die Nummer als Bezeichnung — das Abonnement hat keinen sprechenden Namen.

Die Abonnementart wird bei jedem Lauf gesetzt

Das Feld Abonnementart wird mit einem festen Vorgabewert befüllt; Business Central liefert dazu nichts. Eine in CE geänderte Abonnementart wird beim nächsten Abgleich wieder überschrieben.

Vier Felder kommen nicht aus BC

Verkaufschance, Mitbewerber, Leaderstellung und Anzahl Zeilen sind nicht Teil dieses Mappings — sie werden in Customer Engagement gepflegt oder durch Automatik gefüllt. Das ist der Vertriebsteil des Abonnements: Aus einem auslaufenden Vertrag kann ein Lead entstehen, und dazu gehört, wer der aktuelle Anbieter ist.

Keine Löschverarbeitung

Wird ein Abonnement in Business Central gelöscht, bleibt es in CE stehen — ohne Kennzeichnung. Siehe die Warnung auf der Übersicht.

Technische Details

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

7.2 - Abonnementzeilen aus Business Central übernehmen

Was passiert hier?

Während das Abonnement sagt, was abonniert ist, sagt die Abonnementzeile, zu welchen Bedingungen: Laufzeit, Kündigungsfrist, Preis, Rabatt und Abrechnungsturnus.

Ein Abonnement kann mehrere Zeilen haben — etwa eine Grundlizenz mit Zweijahreslaufzeit und einen Support-Baustein mit jährlicher Verlängerung.

Mit 27 Feldzuordnungen ist das das umfangreichste Mapping der ganzen Integration. Wiedererkannt wird eine Zeile über die BC System-ID.

Welche Felder kommen an?

Zuordnung

Laufzeit und Fristen

Abrechnung

Preis und Rabatt

Worauf zu achten ist

Kündigung möglich bis ist das entscheidende Feld

Von allen 27 Feldern ist dieses das wichtigste für den Vertrieb: Es nennt den konkreten Stichtag, bis zu dem der Kunde kündigen kann — und damit den Zeitpunkt, an dem eine Verlängerung spätestens verhandelt sein muss.

Anfangslaufzeit, Verlängerungslaufzeit und Kündigungsfrist sind die Regelwerke dahinter; Business Central rechnet daraus das Datum aus und liefert es fertig. Customer Engagement muss nichts nachrechnen.

Die Zeile hängt an der Abonnementnummer

Die Verknüpfung zum Abonnement wird über die Abonnementnummer aufgelöst. Ist das Abonnement in CE noch nicht vorhanden, bleibt die Verknüpfung leer — die Zeile wird trotzdem angelegt und stünde dann ohne Bezug da.

Da Abonnements aus BC mit Order 550 vor diesem Schritt (560) läuft, findet das normalerweise innerhalb desselben Durchlaufs zusammen.

Drei Felder werden von Text in Auswahlwerte übersetzt

Business Central liefert Abrechnung über, Partner und Rabatt als Text. In Customer Engagement sind das Auswahlfelder, weshalb hier die Operation OptionMapping zum Einsatz kommt — die es sonst nirgends in der Integration gibt:

Zwei Felder für die Berechnungsbasis, gekreuzt benannt

Hier ist beim Lesen der Konfiguration Vorsicht geboten: Das BC-Feld Berechnungsbasisbetrag geht in das CE-Feld Berechnungsbasis, das BC-Feld Berechnungsbasis dagegen in Berechnungsbasis Prozent. Die Namen kreuzen sich also. Fachlich passt es — BC führt unter Berechnungsbasis einen Prozentsatz —, beim Prüfen eines Datensatzes ist es aber leicht zu verwechseln.

Drei Nummernfelder

Die Zeile bringt drei verschiedene Nummern mit: Vertragsnummer, Zeilennummer (aus der Vertragszeile) und Eintragsnummer (aus der Zeilennummer des Belegs). Für die Zuordnung ist keine davon relevant — die läuft über die BC System-ID.

Währung und abzurechnendes Produkt fehlen

Die Felder Währung und Abzurechnendes Produkt sind nicht Teil dieses Mappings. Preis, Rabattbetrag und Leistungsbetrag kommen also ohne Währungsangabe an; in CE gilt dann, was am Datensatz voreingestellt ist.

Keine Löschverarbeitung

Wird eine Abonnementzeile in Business Central gelöscht, bleibt sie in CE stehen. Siehe die Warnung auf der Übersicht.

Technische Details

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

8 - Technisches Mapping

Diese Sektion ist die technische Referenz zur DataBridge-Integration zwischen Business Central und Customer Engagement — für alle, die die Konfiguration warten, erweitern oder im Fehlerfall nachvollziehen müssen. Sie ergänzt die fachliche Doku der anderen Bereiche um eine vollständige, tabellarische Sicht auf Jobs und Feldzuordnungen, ohne die fachlichen Zusammenhänge zu erklären.

Sortiert nach der Ausführungsreihenfolge (Order) des jeweiligen Jobs. Response-Jobs laufen ohne eigenen Zeitplan; sie werden vom auslösenden Job über das Feld ResponseJob unmittelbar danach aufgerufen und stehen deshalb an ihrer Order-Position in der Kette.

8.1 - 110 · countriesfrombc

Feldzuordnung

Alternate Key

{
  "keyType": "CustomKey",
  "keyName": "wysa_bcsystemidkey",
  "keyValues": [
    {
      "attributeName": "id",
      "keyName": "wysa_bcsystemid",
      "rank": 1
    }
  ],
  "ignoreEmptySourceKey": false,
  "keyRank": 0
}

Weitere technische Details

Vergleich mit anderen Wertelisten-Jobs

Alle fünf Wertelisten-Jobs (countriesfrombc, languagesfrombc, salutationsfrombc, customerdiscountgroupsfrombc, positionsfrombc) teilen dieselbe Konfiguration — Zeitplan, Quell- und Zielverbindung, Watermark und Basisfilter — und unterscheiden sich nur in Quelltabelle, Zieltabelle und Filter-Zusatz:

countriesfrombc ist der einzige der fünf Jobs mit einem Filter-Zusatz (code ne ''). Keines der fünf Mappings enthält eine Transformation.

Auflösung in den Belegketten

wysa_country wird über wysa_bccode aufgelöst — in Firma und Kontakt, je in beide Richtungen. Die BC→CE-Auflösung verwendet die Operation Lookup über den Alternate Key wysa_bccodekey, die CE→BC-Auflösung die Operation LookupValue mit UseCache: true.

8.2 - 115 · languagesfrombc

Feldzuordnung

Alternate Key

{
  "keyType": "CustomKey",
  "keyName": "wysa_bcsystemidkey",
  "keyValues": [
    {
      "attributeName": "id",
      "keyName": "wysa_bcsystemid",
      "rank": 1
    }
  ],
  "ignoreEmptySourceKey": false,
  "keyRank": 0
}

Weitere technische Details

Vergleich mit anderen Wertelisten-Jobs

Alle fünf Wertelisten-Jobs (countriesfrombc, languagesfrombc, salutationsfrombc, customerdiscountgroupsfrombc, positionsfrombc) teilen dieselbe Konfiguration — Zeitplan, Quell- und Zielverbindung, Watermark und Basisfilter — und unterscheiden sich nur in Quelltabelle, Zieltabelle und Filter-Zusatz:

Keines der fünf Mappings enthält eine Transformation.

Auflösung in den Belegketten

wysa_language wird über wysa_bccode aufgelöst — am Kontakt, in beide Richtungen. Die BC→CE-Auflösung verwendet die Operation Lookup über den Alternate Key wysa_bccodekey, die CE→BC-Auflösung die Operation LookupValue mit UseCache: true.

8.3 - 120 · salutationsfrombc

Feldzuordnung

Alternate Key

{
  "keyType": "CustomKey",
  "keyName": "wysa_bcsystemidkey",
  "keyValues": [
    {
      "attributeName": "id",
      "keyName": "wysa_bcsystemid",
      "rank": 1
    }
  ],
  "ignoreEmptySourceKey": false,
  "keyRank": 0
}

Weitere technische Details

Vergleich mit anderen Wertelisten-Jobs

Alle fünf Wertelisten-Jobs (countriesfrombc, languagesfrombc, salutationsfrombc, customerdiscountgroupsfrombc, positionsfrombc) teilen dieselbe Konfiguration — Zeitplan, Quell- und Zielverbindung, Watermark und Basisfilter — und unterscheiden sich nur in Quelltabelle, Zieltabelle und Filter-Zusatz:

Keines der fünf Mappings enthält eine Transformation.

Auflösung in den Belegketten

wysa_bcsalutation wird über wysa_code aufgelöst — am Kontakt, in beide Richtungen. Die BC→CE-Auflösung verwendet die Operation Lookup über den Alternate Key wysa_bccodekey, die CE→BC-Auflösung die Operation LookupValue mit UseCache: true.

8.4 - 125 · customerdiscountgroupsfrombc

Feldzuordnung

Alternate Key

{
  "keyType": "CustomKey",
  "keyName": "wysa_bcsystemidkey",
  "keyValues": [
    {
      "attributeName": "id",
      "keyName": "wysa_bcsystemid",
      "rank": 1
    }
  ],
  "ignoreEmptySourceKey": false,
  "keyRank": 0
}

Weitere technische Details

Vergleich mit anderen Wertelisten-Jobs

Alle fünf Wertelisten-Jobs (countriesfrombc, languagesfrombc, salutationsfrombc, customerdiscountgroupsfrombc, positionsfrombc) teilen dieselbe Konfiguration — Zeitplan, Quell- und Zielverbindung, Watermark und Basisfilter — und unterscheiden sich nur in Quelltabelle, Zieltabelle und Filter-Zusatz:

Keines der fünf Mappings enthält eine Transformation.

Auflösung in den Belegketten

wysa_bccustomerdiscountgroup wird über wysa_bccode aufgelöst — an der Firma, nur BC → CE, über die Operation Lookup mit dem Alternate Key wysa_bccodekey. Dieses Feld gehört zu denen, die nur aus BC kommen und nie zurückgeschrieben werden.

8.5 - 130 · salespersonsfrombc

Feldzuordnung

Alternate Key

{
  "keyType": "CustomKey",
  "keyName": "wysa_bcsystemidkey",
  "keyValues": [
    {
      "attributeName": "id",
      "keyName": "wysa_bcsystemid",
      "rank": 1
    }
  ],
  "ignoreEmptySourceKey": false,
  "keyRank": 0
}

Weitere technische Details

Auflösung in den Belegketten

Das Nachschlagefeld ist stets wysa_code, nicht wysa_bccode:

Beobachtungen

Auffällig ist, dass BCContacts den Verkäufer nicht aus BC abholt, obwohl beide CE→BC-Mappings des Kontakts ihn senden.