MABEA/arbeitskacheln/02_identity.md

Epic 02 — Identity

Details zu IDENT-001, 002, 004, 005–010. IDENT-003 (Nummernschemata) noch nicht detailliert, siehe 00_index.md-Tabelle.

---

IDENT-001 — Objekt-ID-Schema

• Ziel: Jede Ressource ist technisch eindeutig identifizierbar, unabhängig von Fachfeldern.
• Beschreibung: Primärschlüssel-Strategie für alle Ressourcentypen festlegen (UUID vs. fortlaufende ID je Tabelle), Konvention dokumentieren.
• Benutzerwert: Grundlage für QR-Code/Verknüpfungen — ohne stabile ID keine verlässliche digitale Identität.
• Abhängigkeiten: FOUND-002
• Datenmodell: Konvention (kein neues Feld, sondern Festlegung für alle künftigen Tabellen)
• Backend/Frontend/Mobile: —
• QR-Code: Grundlage für spätere QR-Kacheln
• Seriennummer/Inventarnummer: getrennt davon, siehe IDENT-002/004
• Akte: die ID ist der Aufhänger der Akte
• Rechte: keine
• Audit: nein
• Akzeptanzkriterien: dokumentierte Entscheidung (ADR), mind. ein Beispiel-Modell nutzt sie.
• Tests: keine (reine Konvention)
• DoD: ADR verabschiedet, in FOUND-002-Migrationsvorlage verankert.

IDENT-002 — Inventarnummer (manuell)

• Ziel: Organisationseigene, menschenlesbare Kennzeichnung neben der technischen ID.
• Beschreibung: Freitextfeld, Eindeutigkeit je Organisation erzwingen.
• Benutzerwert: Materialwart kann Ressourcen anhand vertrauter Nummern wiederfinden (Etiketten, Inventarlisten).
• Abhängigkeiten: IDENT-001
• Datenmodell: inventarnummer (Textfeld, UNIQUE je Organisation) an Asset-Tabelle (folgt ab ASSET-003)
• Backend: Validierung Eindeutigkeit bei Anlage/Änderung
• Frontend: Eingabefeld bei Ressourcenanlage
• Mobile: Anzeige in der Akte
• QR-Code: kann Teil des gedruckten Labels sein (Klartext-Fallback)
• Seriennummer: getrennt, siehe IDENT-004
• Akte: Kernfeld der Identität
• Rechte: Ändern nur Materialwart/Administrator
• Audit: Änderung der Inventarnummer wird geloggt
• Akzeptanzkriterien: doppelte Inventarnummer wird abgelehnt (409), Änderung wird protokolliert.
• Tests: Konflikt-Test, Erfolgstest.
• DoD: funktioniert für mind. einen Ressourcentyp (Vorgriff auf ASSET-003, kann testweise an Dummy-Tabelle validiert werden).

IDENT-004 — Seriennummer + Eindeutigkeitsprüfung

• Ziel: Herstellerseitige eindeutige Kennzeichnung erfassen.
• Beschreibung: Seriennummernfeld, Eindeutigkeit optional je Materialtyp konfigurierbar (manche Ressourcen brauchen keine SN-Eindeutigkeit global, sondern nur je Objektposition — Lehre aus MABEA: SN ist nur innerhalb einer Position eindeutig, nicht global).
• Benutzerwert: Rückverfolgbarkeit bei Rückrufaktionen/Garantiefällen/Diebstahl.
• Abhängigkeiten: IDENT-001
• Datenmodell: seriennummer (Text) an Asset-Instanz
• Backend: Eindeutigkeitsprüfung im konfigurierten Scope
• Frontend: Eingabefeld, ggf. Scan-Unterstützung (Kamera, spätere Mobile-Kachel)
• Mobile: Anzeige/Erfassung
• QR-Code: SN kann im gedruckten Label als Klartext stehen, nicht im QR-Inhalt selbst
• Inventarnummer: getrennt, siehe IDENT-002
• Akte: Kernfeld
• Rechte: Ändern nur Materialwart/Administrator
• Audit: Änderung wird geloggt
• Akzeptanzkriterien: doppelte SN im gleichen Scope wird abgelehnt, in unterschiedlichem Scope erlaubt.
• Tests: beide Fälle abgedeckt.
• DoD: wie IDENT-002, funktioniert an Dummy-/Vorgriffs-Tabelle.

IDENT-005 — Hersteller/Modell-Stammdaten

• Ziel: Herstellerangaben strukturiert statt als Freitext im Namen.
• Beschreibung: Stammdatentabelle Hersteller, Modellfeld am AssetType, Verknüpfung.
• Benutzerwert: Ersatzteilsuche/Rückrufabgleich nach Hersteller möglich, saubere Filterung.
• Abhängigkeiten: IDENT-004
• Datenmodell: hersteller (id, name), asset_type.hersteller_id, asset_type.modell
• Backend: CRUD Hersteller, Modellfeld in AssetType-Endpunkten
• Frontend: Herstellerauswahl im AssetType-Formular
• Mobile: Anzeige in Akte
• QR-Code: nein
• Seriennummer/Inventarnummer: nein
• Akte: Stammdatenbereich
• Rechte: Ändern nur Materialwart/Administrator
• Audit: Änderung wird geloggt
• Akzeptanzkriterien: Hersteller anlegen, AssetType damit verknüpfen, Anzeige in Akte korrekt.
• Tests: CRUD-Test, Verknüpfungstest.
• DoD: funktioniert für mind. einen AssetType.

IDENT-006 — QR-Code-Erzeugung

• Ziel: Jede Ressource bekommt einen QR-Code, der auf ihre Identität verweist.
• Beschreibung: QR-Inhalt = URL-Pfad (/akte/{ressourcentyp}/{id}), nicht Volldaten (Decision Required #3 in 00_index.md — entschieden: URL-Pfad).
• Benutzerwert: Grundlage für schnelles Scannen statt manueller Suche.
• Abhängigkeiten: IDENT-001
• Datenmodell: kein neues Feld — QR wird aus der Objekt-ID zur Laufzeit generiert, nicht gespeichert
• Backend: Funktion/Endpoint, das QR-Payload (PNG/SVG) für eine ID liefert
• Frontend: QR-Vorschau-Komponente
• Mobile: gleiche Erzeugung
• QR-Code: ist diese Kachel
• Seriennummer/Inventarnummer: stehen NICHT im QR-Inhalt (nur Klartext-Fallback auf dem Label, siehe IDENT-007)
• Akte: Ziel des QR-Verweises
• Rechte: Erzeugen wie Lese-Recht der Ressource
• Audit: nein (reine Generierung, kein Datenzustand)
• Akzeptanzkriterien: QR-Code für existierende ID erzeugt, für unbekannte ID Fehler.
• Tests: Erzeugungstest, Dekodier-Test (Payload ergibt korrekte URL).
• DoD: QR-Bild lässt sich mit Standard-Scanner lesen und ergibt korrekten Pfad.

IDENT-007 — QR-Code-Druck (Label)

• Ziel: Druckfertiges Etikett mit QR + Klartext-Fallback.
• Beschreibung: PDF-Label-Generierung (Vektor, skaliert verlustfrei), Klartext = Name + Inventarnummer/Seriennummer.
• Benutzerwert: Materialwart kann Etiketten für neue Ressourcen direkt drucken.
• Abhängigkeiten: IDENT-006
• Datenmodell: keins
• Backend: GET-Endpoint liefert PDF
• Frontend: Druckbutton in der Akte/Ressourcenliste
• Mobile: eher Desktop-Funktion (Etikettendrucker), Mobile nur Anzeige
• QR-Code: wird hier eingebettet
• Seriennummer/Inventarnummer: als Klartext auf dem Label
• Akte: Aktion aus der Akte heraus auslösbar
• Rechte: wie Lese-Recht
• Audit: nein
• Akzeptanzkriterien: PDF enthält scanbaren QR + korrekten Klartext.
• Tests: Label-Erzeugungstest (Snapshot/Struktur, nicht Pixel).
• DoD: auf echtem Etikettendrucker test-gedruckt und scanbar.

IDENT-008 — QR-Scan → Akte öffnen

• Ziel: Zentraler Einstiegspunkt „scannen → sofort alle Infos sehen".
• Beschreibung: Frontend-Route, die den QR-Pfad auflöst und direkt FILE-006 lädt.
• Benutzerwert: Kernnutzen des ganzen Identity-Konzepts — ohne das bleibt QR nur Deko.
• Abhängigkeiten: IDENT-006, FILE-006
• Datenmodell: keins
• Backend: keins zusätzlich (nutzt FILE-001-Aggregations-Endpoint)
• Frontend: Scan-Route + Kamera-Komponente
• Mobile: zentraler mobiler Workflow-Einstieg (siehe MOBILE-002)
• QR-Code: ist diese Kachel
• Seriennummer/Inventarnummer: nur Anzeige
• Akte: Zielseite
• Rechte: wie Akte-Lese-Recht, 404 falls Ressourcen-ID unbekannt/kein Zugriff
• Audit: nein
• Akzeptanzkriterien: Scan eines gültigen QR öffnet korrekt die Akte; ungültiger Code zeigt Fehlermeldung, keinen Absturz.
• Tests: Routing-Test mit gültiger/ungültiger ID.
• DoD: funktioniert auf echtem Smartphone im Feldtest.

IDENT-009 — QR-Neuvergabe & QR-Historie

• Ziel: Verlorenes/beschädigtes Etikett ersetzen, ohne die Ressourcen-ID zu verlieren.
• Beschreibung: Da QR nur die ID referenziert (IDENT-006), ist „neu vergeben" technisch nur ein neuer Druck — Kachel deckt aber den Sonderfall ab, dass zwischenzeitlich ALTE gedruckte Etiketten im Umlauf sein können und das nachvollziehbar bleiben muss.
• Benutzerwert: Klarheit, welches physische Etikett aktuell gültig ist.
• Abhängigkeiten: IDENT-006
• Datenmodell: qr_druck_ereignis (ressourcen_id, zeitpunkt, benutzer_id) — nur Protokoll, kein Zustand am Objekt selbst
• Backend: Log-Eintrag bei jedem Label-Druck (Kopplung an IDENT-007)
• Frontend: „zuletzt gedruckt am" in der Akte anzeigen
• Mobile: nur Anzeige
• QR-Code: Kernthema
• Seriennummer/Inventarnummer: nein
• Akte: Historienbereich
• Rechte: wie Lese-Recht
• Audit: ist selbst ein Audit-Protokoll
• Akzeptanzkriterien: jeder Druckvorgang erzeugt einen Eintrag, in der Akte sichtbar.
• Tests: Protokoll-Test bei Druckaufruf.
• DoD: funktioniert an mind. einer Ressource nachweisbar.

IDENT-010 — Barcode/GTIN (optional, P3)

• Ziel: Handelsübliche Verbrauchsgüter über Hersteller-Barcode statt eigener Nummer erfassen.
• Beschreibung: Zusatzfeld GTIN/EAN, optionale Barcode-Scan-Unterstützung neben QR.
• Benutzerwert: Schnellere Ersterfassung bei Standard-Verbrauchsmaterial (z.B. Verbandsmaterial mit Herstellerbarcode).
• Abhängigkeiten: IDENT-001
• Datenmodell: gtin (Text, optional) an Asset/Consumable
• Backend: Validierung Format (EAN-13/GTIN-Prüfsumme)
• Frontend: Barcode-Scan-Eingabehilfe
• Mobile: Scan-Unterstützung
• QR-Code: eigenständig daneben, kein Ersatz
• Seriennummer/Inventarnummer: ergänzend, nicht Ersatz
• Akte: Stammdatenbereich
• Rechte: wie Materialwart-Schreibrecht
• Audit: Änderung wird geloggt
• Akzeptanzkriterien: gültige GTIN wird angenommen, ungültige abgelehnt.
• Tests: Prüfsummen-Test.
• DoD: funktioniert für mind. ein Verbrauchsmaterial-Beispiel. Priorität P3 — kann grundsätzlich zurückgestellt werden.

---

MABEA-Ist-Stand-Abgleich: IDENT-001 (Code/UUID), 002/003 (objekt.code/ objektposition.code, Nummernschema mit Präfix), 004 (Seriennummer je Objektposition/ GeraetInstanz, Eindeutigkeit korrekt scope-begrenzt), 006/007/008 (Code128-Label + PDF + Scan→Kontrolle-Route) sind vorhanden, allerdings Code128 statt QR und ohne Digital-File-Zielseite (die gibt es noch nicht, siehe FILE-Epic). IDENT-005 (Hersteller/Modell), IDENT-009 (QR-Historie), IDENT-010 (Barcode/GTIN) fehlen komplett.