# Stammdaten
> Die Wertelisten aus Business Central — Grundlage für fast jede Zuordnung in den Belegketten.
---
LLMS index: [llms.txt](/llms.txt)
---
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**.
| Order | Was kommt an | Wird gebraucht für |
|---|---|---|
| 110 | [Länder](wertelisten/#länder) | Firma, Kontakt |
| 115 | [Sprachen](wertelisten/#sprachen) | Kontakt |
| 120 | [Anreden](wertelisten/#anreden) | Kontakt |
| 125 | [Debitorrabattgruppen](wertelisten/#debitorrabattgruppen) | Firma |
| 130 | [Verkäufer](bcsalespersons/) | Firma, Kontakt, Verkaufschance, Angebot |
| 135 | [Organisationsebenen](wertelisten/#organisationsebenen) | Kontakt |
| 190 | [Kalkulationselemente](../verkaufschance/bcopportunityelements/) | Verkaufschance, Angebot |
| 450 | [Löschung von Produkten](bcproductsdelete/) | Produkt |
Die Kalkulationselemente sind fachlich ebenfalls ein Stammdaten-Abgleich, stehen aber
bei der [Verkaufschance](../verkaufschance/), weil sie nur dort und im Angebot verwendet
werden.
## Warum die Reihenfolge zählt
```mermaid
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
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.
> **Fehlt ein Stammdatum, bleibt das Feld leer**
>
> Findet ein Abgleich das passende Stammdatum nicht, wird der Beleg trotzdem übertragen —
> nur bleibt das betroffene Feld leer. Es gibt keine Fehlermeldung und keinen Abbruch.
>
> Ein neu in BC angelegter Verkäufer erscheint deshalb innerhalb desselben Durchlaufs auch
> an der Firma. Wird ein Stammdatum dagegen in BC **nie** angelegt, bleiben die
> zugehörigen Felder dauerhaft leer, ohne dass es auffällt.
## Alle Abgleiche folgen demselben Muster
Die sechs Wertelisten-Jobs sind bemerkenswert einheitlich aufgebaut:
| | |
|---|---|
| **Richtung** | immer Business Central → Customer Engagement |
| **Takt** | immer alle 2 Minuten |
| **Abgrenzung** | immer über den Änderungszeitstempel `lastModifiedDateTime` |
| **Erkennungsmerkmal** | immer die **BC System-ID** |
| **Felder** | drei bis vier: System-ID, Kürzel, Bezeichnung |
| **Löschverarbeitung** | keine — in BC gelöschte Wertelisteneinträge bleiben in CE stehen |
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:
| Feld für das BC-Kürzel | Wertelisten |
|---|---|
| `wysa_bccode` | Länder, Sprachen, Debitorrabattgruppen |
| `wysa_code` | Anreden, Verkäufer, Organisationsebenen |
Das ist keine Kleinigkeit, denn die Belegketten müssen diese Unterscheidung mitmachen.
Jeder Lookup nennt das Nachschlagefeld ausdrücklich:
| Auflösung in der Belegkette | Nachschlagefeld |
|---|---|
| Land | `wysa_bccode` |
| Sprache | `wysa_bccode` |
| Debitorrabattgruppe | `wysa_bccode` |
| Anrede (BC) | `wysa_code` |
| Verkäufer (BC) | `wysa_code` |
| Position (BC) | `wysa_code` |
> **Beim Anlegen weiterer Wertelisten beachten**
>
> Wer eine neue Werteliste ergänzt, muss die Schreibweise des Codefelds und den Lookup im
> Mapping aufeinander abstimmen. Ein `wysa_bccode` in der Tabelle und ein `wysa_code` im
> Mapping führt nicht zu einem Fehler, sondern zu einem stillschweigend leeren Feld.
## Was nicht abgeglichen wird
Nicht jede Tabelle des Datenmodells hat einen Abgleich. Diese hier werden von keinem
aktiven Job gefüllt:
| Tabelle | Anzeigename | Zustand |
|---|---|---|
| `wysa_bcClient` | Mandant (BC) | **kein Job vorhanden** — wird manuell gepflegt |
| `wysa_bcProducer` | Hersteller (BC) | kein Abgleich — bleibt am Produkt leer |
| `wysa_bcProductCategory` | Produktkategorie (BC) | kein Abgleich — bleibt am Produkt leer |
| `product` | Produkt | **keine Artikel aus BC** — nur Kalkulationselemente, siehe unten |
| `wysa_title` | Titel | kein Abgleich — reine CE-Stammdaten |
| `wysa_salutation` | Anredevorlage | kein Abgleich — reine CE-Stammdaten |
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
> **Artikel werden nicht aus BC übernommen**
>
> Es gibt keinen Abgleich, der Artikel aus Business Central nach CE bringt. Die
> Produkttabelle wird ausschließlich über die
> [Kalkulationselemente](../verkaufschance/bcopportunityelements/) (190) gefüllt; alles
> andere darin ist manuell erfasst. Die Felder *Hersteller (BC)* und *Produktkategorie (BC)*
> werden entsprechend in CE gepflegt. Die
> [Löschverarbeitung für Produkte](bcproductsdelete/) (450) betrifft nur Produkte mit einer
> BC System-ID aus der Artikeltabelle.
## Technische Zuordnung
Jobs und Mappings
| Order | Job | Mapping | Zieltabelle | Felder |
|---|---|---|---|---|
| 110 | `countriesfrombc` | `BCCountries` | `wysa_country` | 4 |
| 115 | `languagesfrombc` | `BCLanguages` | `wysa_language` | 3 |
| 120 | `salutationsfrombc` | `BCSalutations` | `wysa_bcsalutation` | 3 |
| 125 | `customerdiscountgroupsfrombc` | `BCCustomerDiscountGroups` | `wysa_bccustomerdiscountgroup` | 3 |
| 130 | `salespersonsfrombc` | `BCSalesPersons` | `wysa_bcsalesperson`, `wysa_salesperson` | 4 |
| 135 | `positionsfrombc` | `BCPositions` | `wysa_bcposition` | 3 |
| 190 | `opportunityelementsfrombc` | `BCOpportunityElements` | `product` | 10 |
| 450 | `productsfrombcdelete` | `BCProductsDelete` | `product` | 3 |
Alle Quellen sind API Pages unter `singhammerITConsulting/dyce/v2.0/`; die
Löschverarbeitung liest `acdlogentries`.
Key-Auflösung — einheitlich über die BC System-ID
Alle sechs Wertelisten-Jobs verwenden denselben Schlüssel:
```json
{
"KeyType": "CustomKey",
"KeyName": "wysa_bcsystemidkey",
"KeyValues": [
{ "keyName": "wysa_bcsystemid", "attributeName": "id", "rank": 1 }
]
}
```
Das unterscheidet sie von den Belegketten: Firma und Kontakt werden über die
BC Kontaktnummer gefunden, das Angebot über die Angebotsnummer. Bei den Wertelisten ist
der Schlüssel immer die technische System-ID — das Kürzel selbst ist nur ein Datenfeld
und könnte sich in BC theoretisch ändern, ohne dass die Zuordnung verloren geht.
Ausnahme ist der Kalkulationselemente-Abgleich (190), der über den Code auflöst.
---
Section pages:
- [Wertelisten aus Business Central übernehmen](/docs/mapping/stammdaten/wertelisten/): Länder, Sprachen, Anreden, Debitorrabattgruppen und Organisationsebenen kommen aus dem ERP nach Customer Engagement.
- [Verkäufer aus Business Central übernehmen](/docs/mapping/stammdaten/bcsalespersons/): Die Verkäufer aus dem ERP kommen nach Customer Engagement und werden dort automatisch CRM-Benutzern zugeordnet.
- [Produkte deaktivieren](/docs/mapping/stammdaten/bcproductsdelete/): In Business Central gelöschte Artikel werden in Customer Engagement inaktiv gesetzt.