# Architektur-Überblick

> Welche Systeme beteiligt sind, wer welche Daten führt und wo dsyr.SalesCentral eingreift.

---

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

---

## Die beteiligten Systeme

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

| Baustein | Rolle |
|---|---|
| **Customer Engagement (Dynamics 365 Sales)** | Führendes System für den Vertriebsprozess: Leads, Verkaufschancen, Ausschreibungen, Aktivitäten und Beziehungspflege. |
| **Business Central** | Führendes System für kaufmännische Stammdaten und Belege — insbesondere für **Angebote** und **Abonnements** — sowie für Debitoren, Kontakte, Artikel und Fakturierung. |
| **dsyr.DataBridge** | Transportschicht: überträgt Datensätze getaktet in beide Richtungen. |

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

## Wer führt welche Daten?

Die Arbeitsteilung ist bewusst eindeutig:

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

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

Die Freigabe steuert das Feld **Sync zu BC** (`wysa_sync2bc`). Es ist der zentrale
Schalter der Integration und in der [Business-Logik](../business-logik/sync-nach-bc/)
ausführlich beschrieben.

## Wo die Lösung eingreift

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

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

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

## Einordnung der Lösung

| Merkmal | Wert |
|---|---|
| Modellgesteuerte App | dsyr.SalesCentral |
| Lösung | `WYSABCSales` |
| Herausgeber / Präfix | WYSA GmbH / `wysa` |
| Sprachen | Deutsch (Basis), Englisch |

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