> ## Documentation Index
> Fetch the complete documentation index at: https://developers.jobhandy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Divisionshierarchien verwalten

> Erstellen und aktualisieren Sie Tenant-eigene organisatorische Divisionen ohne tenantübergreifende Verschiebungen, Hierarchiezyklen oder Namenskonflikte unter Geschwistern.

Divisionen bilden eine Hierarchie innerhalb genau eines Tenants. Eine Division besitzt einen Namen, optional einen Parent, eine Anzeigereihenfolge unter Geschwistern, optional eine Kostenstelle und serverseitig vergebene Zeitstempel.

## Hierarchiemodell

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TD
    T[Tenant] --> R1[Vertrieb]
    T --> R2[Operations]
    R1 --> C1[Enterprise]
    R1 --> C2[SMB]
```

`parentId: null` erstellt eine Division auf Root-Ebene des Tenants oder verschiebt sie dorthin.

## Create-Ablauf

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TD
    A[Tenant auswählen] --> B[Parent oder Root auswählen]
    B --> C[Eindeutigen Geschwisternamen wählen]
    C --> D[Reihenfolge und Kostenstelle festlegen]
    D --> E[POST ?dryRun=true]
    E --> F{Gültig?}
    F -- Nein --> G[Scope, Name, Parent oder Reihenfolge korrigieren]
    F -- Ja --> H[POST ohne Dry Run]
    H --> I[Reale Divisions-ID speichern]
```

Wenn `X-Tenant-ID` fehlt, kann die Create-Operation den Tenant aus `parentId` oder einem eindeutigen Key-Scope ableiten. Senden Sie den Header, wenn mehr als ein Tenant möglich ist.

## Root-Division erstellen

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "name": "Sales",
  "parentId": null,
  "order": 1,
  "costCenter": "CC-SALES"
}
```

## Untergeordnete Division erstellen

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "name": "Enterprise",
  "parentId": "68920e08eeaea4f2301eecb3",
  "order": 1,
  "costCenter": "CC-SALES-ENT"
}
```

## Parent sicher ändern

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart TD
    A[parentId patchen] --> B{Parent im selben Tenant und Scope?}
    B -- Nein --> X[INVALID_REFERENCE oder TENANT_NOT_IN_SCOPE]
    B -- Ja --> C{Würde ein Zyklus entstehen?}
    C -- Ja --> Y[DIVISION_CYCLE]
    C -- Nein --> D{Geschwistername eindeutig?}
    D -- Nein --> Z[DIVISION_NAME_NOT_UNIQUE_ON_SAME_LEVEL]
    D -- Ja --> E[Parent und Reihenfolge anwenden]
```

Eine Division kann über den öffentlichen Update-Endpoint nicht in einen anderen Tenant verschoben werden.

## Patch-Verhalten

* Lassen Sie Eigenschaften weg, die unverändert bleiben sollen.
* Setzen Sie `parentId: null`, um die Division auf Root-Ebene zu verschieben.
* Setzen Sie die nullable Eigenschaft `costCenter: null`, um die Kostenstelle zu entfernen.
* Verwenden Sie vor Hierarchieänderungen einen Dry Run.
* Speichern Sie nach dem realen Patch den zurückgegebenen Zustand.

## Reihenfolge

`order` ist eine numerische Anzeigereihenfolge unter Geschwisterdivisionen. Das aktualisierte Anbieter-Schema verwendet den OpenAPI-Typ `number` und enthält die bisherige Integer-Beschränkung `multipleOf: 1` nicht mehr. Die Create-Operation dokumentiert bei fehlendem Wert einen serverseitigen Standardwert hinter dem letzten Geschwister. Der öffentliche Vertrag garantiert weder eindeutige Reihenfolgewerte noch eine automatische Neunummerierung. Lesen Sie die resultierende Hierarchie und verwenden Sie die zurückgegebenen Werte.

## Öffentliche Einschränkungen

Der öffentliche v1-Vertrag stellt keine Löschoperation für Divisionen bereit. Er definiert außerdem weder eine maximale Hierarchietiefe noch eine garantierte automatische Neunummerierung nach jeder Reihenfolgeänderung. Stimmen Sie Entfernung und Mitarbeiter-Neuzuordnung über den zuständigen Fachprozess ab, halten Sie Hierarchien angemessen begrenzt und lesen Sie die resultierenden Reihenfolgewerte, statt Annahmen zu treffen.