# Karte 10 – QR-Code / Barcode

**Status:** Roadmap-Feature, Datenmodell-Vorbereitung schon in V1 nötig

## Entscheidung
QR/Barcode-Scan ist gewünschte spätere Funktion:
- Objekt-Code (Rucksack/Fahrzeug) → Direktsprung ins Kontroll-Screen (statt Portal → Standort → Fahrzeug → Rucksack suchen).
- Geräte-Code (Einzelgerät) → automatische Seriennummer-Erkennung.

## Konsequenz für V1 (jetzt schon vorsehen)
- Prompt 06 (Datenmodell): Objekt (Rucksack/Fahrzeug) und Einzelgerät bekommen je ein eindeutiges Code-/ID-Feld, auch wenn Scan-UI erst später kommt.
- Kein Schema-Umbau später nötig, nur Scan-Funktion (Kamera/Reader) ergänzen.

## Umsetzung
- Eigentliche Scan-Funktion → Prompt 24 (Roadmap), nicht MVP.

## Barcode-Format (Nutzerentscheidung)
- Standard: **Code128**, eindimensional, weit verbreitet.
- Bewusste Wahl statt proprietärem/2D-Format, um Geräteauswahl offen zu halten.
- Konsequenz Datenmodell: Code-Feld (Objekt/Gerät) muss Code128-kompatiblen Zeichensatz aufnehmen können (alphanumerisch, keine Sonderzeichen-Einschränkung nötig, Code128 deckt ASCII ab).
- Zusatzanforderung: Code muss per Tablet-/Smartphone-Kamera lesbar sein (Software-Scan). Code128 ist per Kamera grundsätzlich lesbar, aber empfindlicher gegenüber Druckqualität/Abstand/Winkel als 2D-Codes wie QR. Konsequenz: Drucklayout (Größe, Kontrast) muss auf Kamera-Scan getestet werden.

## Label-Design (offener Punkt, Prompt 24 vertiefend)
- Physisches Label-Design (Größe, Material, Kontrast, Schriftgröße Klartext unter Code, Anbringungsort am Objekt) muss mit aufgenommen werden, nicht nur der Code-Inhalt selbst.
- Anforderungen an Label aus Einsatzumfeld: witterungsbeständig/abriebfest (Rucksäcke/Fahrzeuge im Rettungsdiensteinsatz), Kontrast/Größe für zuverlässigen Kamera-Scan (siehe oben).
- Klartext-Fallback auf Label empfohlen (Code + lesbare Objekt-ID), falls Scan mal ausfällt.
- Konkretes Layout/Material erst bei Umsetzung (Prompt 24) final festlegen, hier nur als Anforderung vermerkt.

## Umsetzungsstand (2026-09-04)
- Backend: `objektposition.code`-Feld, Lookup-/Vorschlag-Endpunkte, PDF-Label-Erzeugung (`app/services/label.py`) fertig.
- Frontend/Flutter: Kamera-Scan (Objekt-Code, Scan-First) fertig.
- **Offen: Label-Druck-Test mit echten Geräten** (physischer Schritt, nicht per Code erledigbar). Test-PDF erzeugen: `python -m scripts.test_label_erzeugen` im Backend-venv.

### Test-Checkliste (pro Labelgröße/-material einmal durchgehen)
1. Test-Label drucken (`test_label_erzeugen.py`, mind. eine Größe pro geplantes Labelformat).
2. Auf Ziel-Untergrund kleben/befestigen (Rucksack-Stoff, Fahrzeuglack o. Ä. – reale Anbringung testen, nicht nur Tisch/Papier).
3. Mit jedem vorgesehenen Scan-Gerät testen (PWA im Handy-/Tablet-Browser, Flutter-App auf Android):
   - Normalabstand (~15–20 cm) und Winkel 0°
   - Schräger Winkel (~30°)
   - Schwaches Licht / Gegenlicht
4. Bei Fehlschlag: Modulbreite/Ruhezone in `_BARCODE_OPTIONEN` (`app/services/label.py`) erhöhen, neues Test-Label drucken, erneut testen.
5. Ergebnis (Gerät, Abstand/Winkel, Erfolg/Fehlschlag) hier oder in einer neuen Notiz festhalten, bevor Seriendruck freigegeben wird.