> [← open.SERVICE](<open.SERVICE Plugin Overview.md>) # Stammdaten Stammdaten sind die Daten, auf die Wartungspläne und Tickets gemeinsam verweisen: die Maschinen, die Personen, der Materialkatalog. Sie werden an einer Stelle gepflegt und von beiden Bereichen genutzt. Sie finden sie im Administrationsbereich in der Gruppe **Allgemein**. Für den Zugang genügt `openservice-core:can-access-admin`; Anlegen und Archivieren erfordert bei einigen Seiten zusätzlich `openservice-core:can-manage-masterdata`. | Seite | Adresse | „Stammdaten verwalten" nötig | | ----------------- | ------------------------------------ | ---------------------------- | | **Anlagen** | `/admin/OD3_Service_Equipment` | zum Anlegen und Archivieren | | **Tags** | `/admin/OD3_Service_Tag` | zum Anlegen und Archivieren | | **Projekte** | `/admin/OD3_Service_Project` | zum Anlegen und Archivieren | | **Firmen** | `/admin/OD3_Company` | — | | **Kontakte** | `/admin/OD3_Contact` | — | | **Artikel** | `/admin/OD3_BDE_Article` | — | | **Ersatzteile** | `/admin/OD3_BDE_Article/spare-parts` | — | | **Dienstleister** | `/admin/service/providers` | **für die ganze Seite** | ## Anlagen Die Maschinen. Jede Anlage hat eine **Bezeichnung**, kann einer **übergeordneten Anlage** untergeordnet werden und trägt **Tags**. Die Hierarchie bildet ab, was zusammengehört — Werk, Halle, Linie, Maschine. Sie trägt den Hierarchie-Filter der Wartungsübersicht und das Maschinenbuch. > [!note] Die Maschinenauswahl im Kopfbereich wirkt exakt > Wählt jemand oben eine Anlage aus, zeigen Kalender, Hierarchie und Datenansicht > nur die Pläne **genau dieser** Anlage. Untergeordnete Anlagen sind nicht > automatisch dabei. Über **Datenquellen-Tags** lässt sich eine Anlage mit Sensordaten verknüpfen — die Grundlage dafür, dass ein Alarm auf einen Sensor einen Wartungstermin an der richtigen Maschine erzeugt. Archivieren statt Löschen: eine Anlage wird als gelöscht markiert und bleibt für bestehende Pläne und Protokolle auflösbar. ## Tags Tags gliedern Objekte nach eigenen Merkmalen — Baugruppe, Kritikalität, Standort, was immer Sie brauchen. Zwei Eigenschaften sind wichtig: **Tags sind je Objekttyp getrennt.** Ein Tag gehört immer zu genau einer Objektart; Anlagen-Tags und Ticket-Tags sind zwei getrennte Bäume. Der Typ wird beim Anlegen gewählt und bestimmt, welcher Elterntag überhaupt zur Auswahl steht. **Tags sind hierarchisch, und die Suche wirkt nach unten.** Wird einem Objekt ein untergeordneter Tag zugewiesen, speichert das System die ganze Kette bis zur Wurzel mit. Ein Filter auf einen Elterntag findet deshalb auch alles, was unter ihm hängt. Angezeigt wird jeweils nur der tiefste Tag — die Eltern ergeben sich daraus. Ein Ast anzuhaken wählt **nicht** automatisch alles darunter aus; jeder Knoten ist einzeln wählbar. > [!tip] Tags ohne Stammdatenrechte anlegen lassen > Mit `openservice-core:can-create-tag` darf jemand direkt aus einem Tag-Feld > heraus einen neuen Tag anlegen, ohne Zugang zur Stammdatenverwaltung. Praktisch > für Ticket-Bearbeiter. Ein so angelegter Tag wird immer Wurzel seines Typs; > Umhängen bleibt Sache der Administration. > [!warning] Tags umhängen wirkt nicht rückwirkend > Weil die Kette beim Zuweisen mitgespeichert wird, tragen bereits zugewiesene > Objekte weiterhin die alte Kette, wenn Sie einen Tag später an eine andere > Stelle im Baum verschieben. Planen Sie die Struktur deshalb möglichst früh, > oder weisen Sie betroffene Objekte nach einem Umbau neu zu. ## Projekte Gliedern Tickets nach Vorhaben. Ein Projekt hat **Bezeichnung** und **Kürzel**, kann einem übergeordneten Projekt untergeordnet werden und trägt einen **Verantwortlichen** sowie einen **Standardstatus** für neue Tickets. Beginn und Ende sind optional. ## Firmen und Kontakte **Firmen** haben einen Namen und können mit Anlagen verknüpft werden — etwa der Hersteller einer Maschine. **Kontakte** sind Personen: Vorname, Nachname, E-Mail, Anschrift und die zugehörige **Firma**. Kein Feld ist Pflicht; angezeigt wird der Name, ersatzweise die E-Mail. Kontakte sind zugleich die Grundlage der Dienstleister: ein Kontakt bekommt ein Benutzerkonto und wird Wartungsplänen zugewiesen. > [!warning] Firmen und Kontakte werden wirklich gelöscht > Anders als Anlagen, Tags und Projekte kennen diese beiden kein Archivieren — > gelöscht ist gelöscht. Prüfen Sie vorher, ob der Kontakt als Dienstleister an > Plänen hängt. ## Artikel und Ersatzteile Der Materialkatalog. Beide Seiten arbeiten auf **demselben Bestand**: „Ersatzteile" ist die gefilterte Sicht auf alles vom Typ Ersatzteil, „Artikel" zeigt alles. Felder: **Bezeichnung** (der Anzeigename), **Artikelnummer**, **Typ**, **Einheit**, **Bestand**, **Meldebestand**, dazu Lagerort, Lieferant, Bestellnummer, Preis, Währung und Gebindegröße. > [!warning] Der Bestand wird nicht automatisch gebucht > **Bestand** ist ein von Hand gepflegter Zählstand — lesen Sie ihn als „zuletzt > gezählt". Material, das bei einer Wartung verbraucht wird, steht im Protokoll, > verringert den Bestand aber nicht. Auch der **Meldebestand** löst keine Warnung > aus; er ist eine Notiz für den, der die Liste ansieht. ## Dienstleister Eine eigene Seite unter `/admin/service/providers`, die zeigt, welcher Kontakt ein Konto hat und welchen Plänen er zugewiesen ist. Sie liegt in der allgemeinen Administration und nicht beim Wartungsmodul, weil das Konto zum **Kontakt** gehört. Siehe [[End-User/Modules/open.SERVICE/features/Dienstleister|Dienstleister]]. ## Eigene Felder ergänzen Reichen die mitgelieferten Felder nicht, ergänzen Sie eigene — ohne Schema-Änderung. In der Werkzeugleiste jeder Stammdatenseite stehen dafür **Kopfdaten konfigurieren** und **Spalten**. Siehe [[End-User/Modules/open.SERVICE/Administration/Kopfdaten und Erfassungsfelder|Kopfdaten und Erfassungsfelder]]. Für Anlagen gibt es dazu eine eigene Suchseite über alle Maschinen hinweg: [[End-User/Modules/open.SERVICE/features/Maschinendaten|Maschinendaten]].