# Abonnement

> Wie wiederkehrend abgerechnete Leistungen und ihre Vertragsdetails aus Business Central nach Customer Engagement kommen.

---

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

---

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:

| Schritt | Was passiert | Wann |
|---|---|---|
| [Abonnements aus BC](bcserviceobjects/) | die abonnierte Leistung selbst | alle 2 Minuten |
| [Abonnementzeilen aus BC](bcservicecommitments/) | Laufzeiten, Preise, Kündigungsfristen | alle 2 Minuten |

## Zwei Ebenen

```mermaid
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.

| Rolle | Bedeutung | Kommt aus BC von |
|---|---|---|
| **Rechnungsempfänger** | wer bezahlt | Rechnungsadresse des Belegs |
| **Leistungsnehmer** | wer die Leistung nutzt | Lieferadresse des Belegs |

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.

> **Aufgelöst wird über die BC Kontaktnummer**
>
> Alle vier Zuordnungen laufen über die **BC Kontaktnummer** — auch die auf Firmen. Das
> unterscheidet diesen Bereich vom [Angebot](../angebot/bcsalesquotes/), das die Firma über
> die BC Debitorennummer sucht.
> 
> Praktisch ist das die günstigere Variante: Die BC Kontaktnummer ist an jeder nach BC
> übertragenen Firma vorhanden, die Debitorennummer erst, wenn die Firma im ERP zum
> Debitor gemacht wurde.



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

| Feld | Tabelle | Bemerkung |
|---|---|---|
| Verkaufschance | Abonnement | Ursprung des Abonnements — Zuordnung in CE |
| Mitbewerber | Abonnement | aktueller Anbieter, falls die Leistung abgelöst werden soll |
| Leaderstellung | Abonnement | Stichtag der Leadgenerierung |
| Anzahl Zeilen | Abonnement | Anzahl der zugehörigen Abonnementzeilen |
| Produkt *(Verweis)* | Abonnement | siehe unten |
| Abzurechnendes Produkt | Abonnementzeile | — |
| Währung | Abonnementzeile | — |

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.

> **Der Produktverweis wird nicht gesetzt**
>
> Das Abonnement führt **Produktnummer** und **Produktbeschreibung** als Text. Der Verweis
> auf einen Produktdatensatz (*Produkt*) wird nicht befüllt, weil Artikel nicht aus
> Business Central übernommen werden — siehe [Stammdaten](../stammdaten/).



## Worauf zu achten ist

> **Keine Löschverarbeitung**
>
> Für Abonnements und Abonnementzeilen gibt es keinen Löschjob. Wird ein Abonnement in
> Business Central gelöscht, bleibt es in Customer Engagement mit dem letzten übertragenen
> Stand erhalten.



### 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

<details>
<summary>Jobs und Mappings dieser Kette</summary>

| Order | Job | Mapping | Zieltabelle | Felder | Seite |
|---|---|---|---|---|---|
| 550 | `serviceobjectsfrombc` | `BCServiceObjects` | `wysa_bcserviceobject` | 17 | [Abonnements aus BC](bcserviceobjects/) |
| 560 | `servicecommitmentsfrombc` | `BCServiceCommitments` | `wysa_bcserviceobjectcommitment` | 27 | [Abonnementzeilen aus BC](bcservicecommitments/) |

Mit 44 Feldzuordnungen ist das der umfangreichste Datenbereich der Integration.

Quellen: `serviceObjects` und `serviceCommitments` — **nicht** unter
`singhammerITConsulting/dyce/v2.0/` wie alle übrigen Abgleiche.

</details>

<details>
<summary>Schlüssel je Schritt</summary>

| Schritt | Schlüssel im Ziel | Alternate Key |
|---|---|---|
| Abonnements aus BC | `wysa_number` ← BC `no` | `wysa_numberkey` |
| Abonnementzeilen aus BC | `wysa_bcsystemid` ← BC `systemId` | `wysa_bcsystemidkey` |

Auffällig ist die Uneinheitlichkeit: Das Abonnement wird über seine **fachliche Nummer**
adressiert — wie das [Angebot](../angebot/bcsalesquotes/) —, die Zeile über die
**BC System-ID**, wie die Angebotsposition. Beide Konventionen kommen also innerhalb
desselben Bereichs vor.

</details>

<details>
<summary>Auflösung von Referenzen</summary>

| Feld | Zieltabelle | Nachschlagefeld | Alternate Key |
|---|---|---|---|
| Rechnungsempfänger Kontakt | `contact` | `wysa_bccontactnumber` | `wysa_bccodekey` |
| Rechnungsempfänger Firma | `account` | `wysa_bccontactnumber` | `wysa_bccodekey` |
| Leistungsnehmer Kontakt | `contact` | `wysa_bccontactnumber` | `wysa_bccodekey` |
| Leistungsnehmer Firma | `account` | `wysa_bccontactnumber` | `wysa_bccodekey` |
| Abonnement *(an der Zeile)* | `wysa_bcserviceobject` | `wysa_number` | `wysa_numberkey` |

Damit setzen die Abonnements voraus, dass Firmen und Kontakte bereits abgeglichen sind.
Die Ordnungsnummern 550 und 560 liegen hinter den Kontakt-Jobs (430 / 440), sodass das
innerhalb desselben Durchlaufs zusammenfindet.

</details>

<details>
<summary>Feldnamen im Datenmodell</summary>

Das [Datenmodell](../../datenmodell/abonnements/) schreibt Logical Names in einer
lesefreundlichen Schreibweise (z. B. `wysa_NextBilling` für `wysa_nextbillingdate`). Die
folgende Übersicht ordnet die Felder dieses Mappings den Bezeichnungen im Datenmodell zu —
getrennt nach Abonnementzeile und dem übergeordneten Abonnement, da beide Entitäten hier
zusammenkommen.

Felder der Abonnementzeile (`wysa_bcServiceObjectCommitment`, dieses Mapping):

| Feld | Im Mapping | Im Datenmodell |
|---|---|---|
| Zeilennummer | `wysa_contractlinenumber` | `wysa_LineNumber` |
| Verlängerungslaufzeit | `wysa_extensionterm` | `wysa_RenewalTerm` |
| Leistungsbeginn / -ende | `wysa_servicestartdate` / `wysa_serviceenddate` | `wysa_ServiceStart` / `wysa_ServiceEnd` |
| Nächste Berechnung | `wysa_nextbillingdate` | `wysa_NextBilling` |
| Abrechnungszeitraum | `wysa_billingbaseperiod` | `wysa_BillingPeriod` |
| Berechnungsbasis | `wysa_calculationbaseamount` | `wysa_CalculationBase` |

Felder des übergeordneten Abonnements (`wysa_bcServiceObject`, aus
[Abonnements aus BC übernehmen](bcserviceobjects/)):

| Feld | Im Mapping | Im Datenmodell |
|---|---|---|
| Einheit | `wysa_uom` | `wysa_Uom` |
| Bereitstellung von | `wysa_provisionstartdate` | `wysa_ProvisioningStart` |
| Bereitstellung bis | `wysa_provisionenddate` | `wysa_ProvisioningEnd` |
| Rechnungsempfänger Firma | `wysa_billtocustomerid` | `wysa_BillToAccountId` |
| Leistungsnehmer Firma | `wysa_endusercustomerid` | `wysa_EndUserAccountId` |

**Einheit** ist ein reines Textfeld, kein Verweis auf einen Einheiten-Datensatz.

Zusätzlich schreibt das Mapping ein Feld `wysa_entrynumber` an der Abonnementzeile, das
im Datenmodell nicht aufgeführt ist.

</details>

---

Section pages:

- [Abonnements aus Business Central übernehmen](/docs/mapping/abonnement/bcserviceobjects/): Die abonnierten Leistungen kommen aus der Abonnementverwaltung des ERP nach Customer Engagement.
- [Abonnementzeilen aus Business Central übernehmen](/docs/mapping/abonnement/bcservicecommitments/): Laufzeiten, Preise, Rabatte und Kündigungsfristen der Abonnements kommen nach Customer Engagement.