Einführung

Eine Ladeeinheit (in Datenmodell und UI auch als „Container" bezeichnet, Tabelle unit) ist ein physisch geführter Behälter, in dem Bestände transportiert oder zwischengelagert werden. Typische Beispiele sind Absetzmulden, Wechselbrücken oder Rollcontainer. Ladeeinheiten haben einen aktuellen Standort (current_unit_location) — Lagerort, Adresse, Fahrzeug oder eine andere Ladeeinheit (Verschachtelung) — und können als Aufnahme von Beständen dienen.

Diese Seite beschreibt die Stammdatenverwaltung der Ladeeinheiten in rocklog Edge: das Anlegen und Bearbeiten einzelner Datensätze, die Power-Suche über die Stammdatenliste, die fachliche Sonderfunktion UVV-Prüfung und das zugrunde liegende Datenmodell.

1. CRUD-Funktionalität

Die Stammdatenliste der Ladeeinheiten ist über Stammdaten → Ladeeinheit (Container) erreichbar. Sie zeigt eine spaltenbasierte Übersicht; die Spalte UVV-Prüfung gültig bis ist nur im Anwendungsprofil container sichtbar.

Anlegen einer neuen Ladeeinheit

Über die Schaltfläche Neu in der Kopfzeile öffnet sich ein seitlicher Dialog (SideOver) Neue Ladeeinheit anlegen. Erfasst werden:

Das Speichern legt den Datensatz an und schließt den SideOver; eine Benachrichtigung mit der vergebenen id erscheint und die Liste wird neu geladen.

Bearbeiten und Archivieren

Über die Spaltenaktion Bearbeiten je Zeile gelangen Anwender:innen auf die Detailseite /master/unit/<id>. Dort können dieselben Felder wie im Anlege-Dialog gepflegt werden, ergänzt um den Schalter Archiviert im Reiter Identifikation. Ein Setzen des Schalters füllt die Spalte archived mit dem aktuellen Zeitstempel; archivierte Einheiten bleiben in der Datenbank, werden aber in der Liste ausgeblendet (sofern keine entsprechende Schnellsuche aktiv ist).

2. Power-Suche

Die Liste bietet zwei Sucheebenen:

• Schnellsuche (Tastenkürzel Ctrl K): freier Text, der gegen barcode (startsWith), hostsystem_reference (contains), article.ident und article.description matcht. Numerische Eingaben werden zusätzlich gegen article.net_volume_per_unit getestet.
• Erweiterte Suche (im Schnellsuche-Dialog aufklappbar): kombinierbare Filter je Attributgruppe.

In der Erweiterten Suche der Gruppe Ladeeinheit (Container) sind folgende Attribute verfügbar:

Mehrere Felder werden mit UND verknüpft. Das Trivalent-Feld ist ephemer: es geht nicht über den generischen buildQuickSearchWhere-Pfad in das Prisma-Where ein, sondern wird im Where-Builder buildUnitsWhere.ts ausgewertet (siehe Datenmodell-Hinweis weiter unten).

3. Besondere Funktionen

3.1 UVV-Prüfung

UVV steht für Unfallverhütungsvorschrift. Behälter unterliegen wiederkehrenden Sicherheitsprüfungen: Neu-Container werden nach 5 Jahren erstmalig geprüft, anschließend folgt eine Folgeprüfung alle 2,5 Jahre. Die nächste fällige Prüfung wird in der Spalte uvv_clearance_valid_until (Datentyp DATE, optional) hinterlegt. Die Spalte ist nur sichtbar, wenn das Anwendungsprofil container aktiv ist.

Status „UVV-Prüfung gültig" (Trivalent)

Der Filter UVV-Prüfung gültig in der erweiterten Suche kennt drei Zustände:

Wichtig: NULL zählt als „unbekannt". Einheiten ohne hinterlegtes UVV-Datum werden weder von ja noch von nein erfasst — sie tauchen ausschließlich im Default-Zustand beliebig auf. So erkennt das Team gezielt entweder Einheiten mit gültiger Prüfung, mit überfälliger Prüfung oder solche, für die noch nie ein Datum erfasst wurde.

Massenmodus „UVV-Prüftermin setzen"

Wählt man in der Liste über die Zeilen-Checkboxen mehrere Ladeeinheiten aus, erscheint in der Werkzeugleiste die Schaltfläche UVV-Prüftermin setzen.

Der Massendialog kennt drei sich gegenseitig ausschließende Modi:

Konkretes Datum

Setzt für alle gewählten Einheiten das gleiche Datum.

Tage zum aktuellen Datum addieren

Addiert pro Einheit eine konfigurierbare Anzahl Tage. Das Basisdatum ist je Einheit coalesce(unit.uvv_clearance_valid_until, heute) — Einheiten mit bereits gesetztem Datum werden also relativ zu ihrem aktuellen Wert verschoben, Einheiten ohne Datum starten bei „heute". Zwei Schnellschalter spiegeln die UVV-Cadence wider:

• +5 Jahre (Erstprüfung) — addiert 1825 Tage (≈ 5 Jahre).
• +2,5 Jahre (Folgeprüfung) — addiert 913 Tage (≈ 2,5 Jahre).

Datum löschen (auf leer setzen)

Setzt uvv_clearance_valid_until für alle selektierten Einheiten auf NULL. Sinnvoll, wenn ein Eintrag rückgängig gemacht oder eine Einheit aus dem Prüfplan genommen werden soll.

Alle drei Modi laufen serverseitig in einer Prisma-$transaction, damit entweder alle gewählten Einheiten aktualisiert werden oder keine.

4. Datenmodell

Tabelle unit

Jede Ladeeinheit ist genau eine Zeile in der Tabelle unit. Die für die Stammdatenpflege relevanten Spalten:

UVV-Spalte und partieller Index

Die Spalte uvv_clearance_valid_until wird durch das Migrationsskript 20260505_3_ext_unit_uvv.sql angelegt. Zur Beschleunigung der Filter „UVV-Prüfung gültig" und „UVV-Prüfung gültig bis" wird ein partieller Index auf den Nicht-NULL-Bereich der Spalte erzeugt:

CREATE INDEX IF NOT EXISTS idx_unit_uvv_clearance_valid_until
    ON unit (uvv_clearance_valid_until)
    WHERE uvv_clearance_valid_until IS NOT NULL;

Damit fließen nur die tatsächlich datierten Einheiten in den Index ein — typischerweise eine Minderheit, was den Index klein und das Filtern preiswert hält.

Aktueller Standort current_unit_location

Der aktuelle Standort einer Ladeeinheit wird über die Spalte current_unit_location_id referenziert. Die Tabelle current_unit_location ist eine Diskriminator-Zeile, die genau einen der folgenden Fremdschlüssel trägt:

In der Stammdatenliste rendert die Spalte AKTUELLER STANDORT den Standort über die gemeinsame Komponente LocationReferenceSummary: die Variante mit der höchsten Priorität gewinnt (Lagerort > Adresse > Fahrzeug > Container) und wird mit passendem Symbol und Klick-zu-kopieren-Handle dargestellt.

Anwendungsprofil-Steuerung

Die UVV-bezogenen Bestandteile (Spalte in der Liste, Felder im Anlege- und Bearbeiten-Dialog, Filter in der Erweiterten Suche) sind über applicationProfiles: ["container"] an das Anwendungsprofil container gebunden. In Profilen ohne diese Markierung (z. B. library, intralogistics) sind UVV-Felder unsichtbar; das Datenmodell selbst bleibt aber identisch — uvv_clearance_valid_until existiert in jeder Installation.