Business-Logik

• 1: Freigabe nach Business Central
• 2: Anrede und Sprache
• 3: Beträge und Margen
• 4: Abschluss von Angebot und Verkaufschance
• 5: Stammdaten und Anzeige
• 6: Konfiguration
• 7: Berechtigungen
• 8: Meldungen

1 - Freigabe nach Business Central

Das Feld „Sync zu BC"

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

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

Die Grundregel: erst der Vater, dann das Kind

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

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

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

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

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

Was das im Alltag bedeutet

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

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

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

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

Kopieren einer Verkaufschance

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

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

Im Formular

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

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

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

2 - Anrede und Sprache

Anredetexte entstehen automatisch

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

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

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

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

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

Geschlecht und BC-Anrede halten sich gegenseitig aktuell

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

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

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

Standardsprache bei neuen Kontakten und Leads

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

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

3 - Beträge und Margen

Angebotssumme und Marge

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

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

Voraussichtlicher Umsatz und voraussichtliche Marge

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

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

Aufbau des Einstellungswerts

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

Welche Werte konkret herangezogen werden:

Wann neu gerechnet wird

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

Im Formular

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

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

Das führende Angebot

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

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

4 - Abschluss von Angebot und Verkaufschance

Gewinnen: Business Central gibt das Signal

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

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

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

Verlieren: verbundene Angebote werden mitgeschlossen

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

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

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

Angebotsklassifizierung

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

Angebots-PDF aus Business Central

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

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

5 - Stammdaten und Anzeige

Firmenname aus Name 1 und Name 2

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

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

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

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

Land als Verweis und als Text

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

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

Verkäufer und Benutzer

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

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

Weitere Automatismen

Sichtbarkeiten im Formular

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

6 - Konfiguration

Umgebungsvariablen

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

Verbindung zu Business Central

Verhalten

Einstellungen

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

Quellen für Umsatz und Marge

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

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

Kennung der Standardsprache ermitteln

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

Vorrangregel

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

Standardwert  <  organisationsweite Einstellung  <  Einstellung je Anwendung

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

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

7 - Berechtigungen

Drei Rollen, ein Prinzip

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

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

SalesConnect Reader

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

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

SalesConnect Admin

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

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

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

SalesConnect DataBridge

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

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

Zuweisung in der Praxis

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

8 - Meldungen

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

Meldungen bei der Freigabe nach Business Central

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

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

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

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

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

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

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

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

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

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

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

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

Meldungen zu Anrede und Sprache

„Value for gender has not found!"

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

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

Meldungen zur Konfiguration

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

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

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

„Found more than 1 setting!"

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

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