---
title: MZ4 — Konsolidiertes Datenmodell (Entitäten & Beziehungen)
date: 2026-06-30
status: aktiv
type: project
tags: [reverse-engineering, vsm, mz4, datenmodell]
---

# MZ4 — Konsolidiertes Datenmodell

Abgeleitet aus allen Modul-Notes (modules/01–08). IDs/Werte aus dem Live-System extrahiert.
Detaillierte Feldlisten der Formulare: siehe `modules/08-formulare-subpages.md`.

## Kern-Entitäten

### Mitarbeiter / Berater (Consultant / User)
- IDs ~570–1318. Felder (aus User-Anlegen-Formular): `uid`, `benutzername`, `benutzerpasswort`,
  `vorname`, `nachname`, `email`, `telefon`, `mobil`, `telefax`, `strasse`, `plz`, `ort`, `land`,
  `department`, `functioncode`, `bgrp` (Rolle), `image`.
- **Rolle (`bgrp`, 8 Gruppen):** Admin (1), Berater (10), Hauptabteilungsleiter (11),
  Abteilungsleiter (12), Backoffice (13), Diplomant/Doktorant (14), Praktikant (15), Archiv (99).
  Flaches RBAC, alle „Germany -"-präfixiert → Mehr-Region-fähig.
- **Funktion (8 Typen)** inkl. Doktorand/Diplomand. Aktiv/Inaktiv-Flag + Rolle „Archiv".

### Abteilung / Team (MO-Organisation)
- Werte: MO-2, MO-2 UK, MO-22, MO-23, MO-24, MC-14, MN-14, MN-90 …
- **KPI-Boards:** DE (5 Boards, z. B. MO-2 WSM) + Ausland (China/USA/Mexiko). Multi-Region.

### Termin / Einsatz (Appointment) — Herz der Einsatzplanung
- Felder: Mitarbeiter, Terminart, Projekt (optional, Autocomplete), Lieferant (optional),
  Datumsbereich (von/bis), Kommentar, Ort (Homeoffice/Vor Ort/Remote), Status (fix/geplant).
- CRUD via AJAX `ajaxloader.php?modul=calendar`: showAppointment, createAppointment, editAppointment,
  removeAppointment, duplicateAppointment, updateStatusAppointment, reloadCalendar, calendar_ac_projects.

### Terminart (AppointmentType)
- 5 Typen (IDs 11/12/14/16/17): 1. Kundenauftrag Durchführung, 2. Kundenauftrag Vor-/Nachbereitung,
  3. Methoden/Prozesse/Standards, 4. Weiterbildung, 5. Persönliche Abwesenheit. Je eigene Farbe.

### Projekt (Auftrag)
- `Nummer` (Format YYYY_NNN). `Status` (6-stufig: 10→40→70→80→100, 20 = storniert).
- `Auftragstyp`/`Beauftragungstyp` (13 Typen: 360-Grad-Workshop … ZDSC Campus; geteilt mit KuZu/Capacity).
- Beziehungen: `Lieferant` (Nr NNNNNN - NN) + Standort, `Projektverantwortung`/`Projektleiter`
  (43 Personen, PL/Referent-Rollen), `Jahr`.
- Sub-Views: `overview`, `projectdata` (Edit, inkl. XLS-Import `loadFromFile`), `kpi`.
- Verknüpfte **Kundenzufriedenheit** (Kontaktperson `prj_contact_person_customer_staisfaction`).
- `abgeschlossen`-Flag.

### Lieferant / Händler / Werk (Supplier)
- `haendlernummer` (interne PK ~291–2367), `Lieferantennummer` (Business-ID NNNNNN - NN bzw. DNNNNN - NN),
  `Name`, `Stadt`, `Land` (~50 ISO-Länder).
- Suffix -00/-10/-11/-12 ≈ Werk/Standort innerhalb einer Lieferantengruppe (ANNAHME).
- 360001-xx = interne „360°-Workshop"-Container (keine echten Lieferanten).
- Detailansicht (`haendlerportal`) mit Tabs (u. a. `haendlerportal_stammdaten`).

### Kundenzufriedenheit (KuZu)
- Je Projekt 3 Prozess-Daten: Abfrage versendet am / Erinnerung versendet am / Ergebnisse erhalten am.
- KuZu-Auswertung = Tracking-Liste über alle 2460 Projekte (2014–2026).

### KPI / Kapazität
- KPI-Boards je Abteilung; KPI 1 = Auslastung mit Zielband **55–65 %**, Abwesenheitskategorien 1–5.
- Kapazität: Arbeitstage (14 Projektkategorien × 12 Monate, Sub-Zeilen Berater/Abteilungsleiter/Praktikant)
  und Mitarbeiter-Auslastung (Monate × 42 Mitarbeiter). Aggregation über Termine/Projekte je Abteilung/Jahr/Monat.

### Commodity (Kurzzeichen)
- Config-Tabelle (Warengruppen-Kurzzeichen), gepflegt unter `mz4_config?config=commodity`.

## Beziehungs-Skizze (abgeleitet)
- Mitarbeiter *—belongs_to—* Abteilung; *—has—* Rolle/Funktion.
- Termin *—belongs_to—* Mitarbeiter, Terminart; *—optional—* Projekt, Lieferant.
- Projekt *—belongs_to—* Lieferant, Projektleiter(Mitarbeiter); *—has—* Auftragstyp, Status, KuZu, KPIs.
- Lieferant *—has_many—* Projekte.
- KPI/Kapazität = Aggregation über Termine/Projekte nach Abteilung/Board/Jahr/Monat.

## Offene Punkte
- Exakte POST-Formate (createAppointment, Projekt-Create) — in 08 / Folge-Pass.
- DB-Schema nur abgeleitet (vermutlich MySQL/MariaDB).
- haendlerportal-Tabs (außer Stammdaten) im Detail noch zu erfassen.