# Mobile-Konzept 3: Buchungsseite fuer datenlastige Sammelerfassung

## Zielbild

Dieses dritte Mobile-Konzept priorisiert nicht die klassische Audit-Ansicht,
sondern den operativen Erfassungsmodus fuer viele Buchungen in kurzer Zeit.
Die Buchungsseite wird auf Mobilgeraeten als Arbeitsoberflaeche fuer
Sammelerfassung, schnelle Filterung und kompaktes Nacharbeiten gedacht.

Ausgangspunkt:

- Die Legacy-Seite `stricheintragen.php` war auf hohe Eingabedichte optimiert.
- Die aktuelle SaaS-Seite `ledger/index.blade.php` ist vor allem lesend und
  audit-orientiert.
- Fuer mobile SaaS-Workflows braucht die Buchungsseite einen eigenen
  Erfassungsmodus statt einer nur umgebrochenen Tabelle.

## Priorisierung

### P0: Muss im ersten mobilen Konzeptionsschnitt sitzen

- Sammelerfassung als primaerer Einstieg
- Filter direkt ueber der Erfassung statt in einem separaten Report-Kontext
- Sticky Header mit wenigen, stabilen Aktionen
- Eingabedichte ueber Listenzeilen statt ueber Karten
- Einhand-Bedienung fuer Auswahl, Mengenanpassung und Speichern
- Kontrolliertes Scrollverhalten ohne horizontales Tabellen-Scrolling

### P1: Sollte im naechsten Ausbauschritt folgen

- Batch-Aktionen fuer markierte Mitglieder
- Zuletzt verwendete Filter und letzte Auswahl merken
- Segmentierte Sichten fuer `Erfassen`, `Pruefen`, `Historie`
- Undo-Snackbar fuer lokale Ruecknahme vor finalem Commit

### P2: Spaeter sinnvoll

- Barcode- oder QR-gestuetzte Mitgliedsauswahl
- Offline-Zwischenspeicher fuer kurze Netzabbrueche
- Vorlagen fuer wiederkehrende Buchungssaetze

## Kernprinzip

Mobile bekommt keine verkleinerte Ledger-Tabelle. Mobile bekommt zwei klar
getrennte Modi auf derselben Seite:

1. `Erfassen`
2. `Journal`

`Erfassen` ist der Default auf Smartphones. `Journal` bleibt wichtig, aber
sekundaer und ueber ein Segment oder Bottom-Sheet erreichbar.

## Informationsarchitektur der Buchungsseite

### 1. Header

Der Header bleibt sticky und reduziert sich beim Scrollen auf eine kompakte
Arbeitsleiste.

Inhalt im initialen Zustand:

- Seitentitel `Buchungen`
- Tenant- oder Kontextlabel
- globale Suche
- primaere Aktion `Speichern`
- Menue-Trigger `Mehr`

Inhalt im kompakten Scroll-Zustand:

- nur Titel oder aktiver Modus
- Such-Trigger
- Counter fuer offene Aenderungen, zum Beispiel `12 offen`
- `Speichern`

Bewusste Entscheidung:

- keine KPI-Karten im mobilen Header
- keine langen Audit-Erklaerungen oberhalb der Erfassung
- keine zweite Navigationszeile unter dem Header

### 2. Modusumschalter direkt unter dem Header

Segmented Control mit:

- `Erfassen`
- `Journal`

Optional spaeter:

- `Pruefen`

Der Umschalter bleibt waehrend kurzer Scrollwege sticky unter dem Header, damit
der Wechsel zwischen Arbeits- und Kontrollsicht ohne Ruecksprung nach oben
funktioniert.

### 3. Filterleiste

Die Filterleiste sitzt direkt unter dem Modusumschalter und ist horizontal
scrollbar, aber aus klaren Chips aufgebaut.

Pflichtfilter:

- Bereich: `Alle`, `Vorderseite`, `Rueckseite`, `Favoriten`
- Buchungstyp: `Striche`, `Einzahlung`, `Korrektur`
- Status: `Nur geaendert`, `Nur offen`, `Mit Aktivitaet`
- Suche nach Mitglied

Verhalten:

- ein aktiver Filter ist immer visuell sichtbar
- Filter oeffnen keine Vollseiten, sondern ein Bottom-Sheet
- zuletzt genutzte Filter bleiben fuer die Session erhalten

## Sammelerfassung als Hauptinteraktion

### Listenmodell statt Tabelle

Jede Mitgliederzeile wird zu einer kompakten Erfassungszeile mit fester
Interaktionslogik:

- Name
- optional Sekundaerinfo wie Team oder letzter Stand
- Mengensteuerung fuer Striche
- Shortcut fuer `+1`, `+2`, `+5`
- optional numerisches Direktfeld

Empfohlener Zeilenaufbau:

- links: Identitaet
- mitte: Schnellaktionen
- rechts: aktueller Entwurf oder Betrag

Die Zeile darf auf Mobile maximal zwei Hoehen haben:

- Standardzustand fuer schnelles Durchscrollen
- expandierter Zustand fuer seltene Details

### Eingabedichte

Die Seite muss 6 bis 8 bearbeitbare Zeilen gleichzeitig auf typischen
Smartphones zeigen koennen. Das spricht gegen hohe Cards, ausufernde Labels und
sekundaere Erklaertexte in jeder Zeile.

Deshalb:

- Zeilenhoehe kompakt halten
- Stepper und Zahlenwert auf Daumenreichweite unten rechts ausrichten
- Sekundaerdetails erst auf Expand oder Long-Press zeigen
- Inline-Validierung nur bei Konflikten anzeigen

### Batch-Logik

Die Sammelerfassung braucht lokale Entwurfsdaten vor dem finalen Speichern.

Empfohlenes Verhalten:

- jede Aenderung landet sofort in einem lokalen Batch
- der Header zeigt die Anzahl offener Aenderungen
- `Speichern` commitet alle geaenderten Zeilen gemeinsam
- `Verwerfen` liegt im `Mehr`-Menue

Das reduziert Server-Roundtrips und verhindert Unterbrechungen im
Erfassungsfluss.

## Scrollverhalten

### Vertikales Scrollen

Die Seite hat genau einen primaeren Scroll-Container: die Inhaltsflaeche unter
dem Header. Keine verschachtelten Scrollbereiche fuer Tabelle, Sidebar oder
Filterpanel.

Regeln:

- Header sticky
- Modusumschalter sticky
- Filterleiste sticky, aber visuell leichter als der Header
- Erfassungszeilen scrollen normal im Hauptflow

### Horizontales Scrollen

Horizontaler Tabellen-Scroll wird fuer Mobile bewusst vermieden. Er ist fuer
Massenerfassung zu langsam, fehleranfaellig und verdeckt Bedienelemente.

Nur die Filterchips duerfen horizontal scrollen.

### Scroll-Feedback

Beim Herunterscrollen:

- Header komprimiert
- sekundare Meta-Infos verschwinden
- `Speichern` bleibt immer erreichbar

Beim Zurueckscrollen nach oben:

- voller Seitentitel kommt zurueck
- kontextuelle Hilfe darf wieder sichtbar werden

## Mobile Bedienbarkeit

### Einhand-Nutzung

Die haeufigsten Aktionen muessen im unteren rechten Bereich erreichbar sein:

- Menge erhoehen
- Menge reduzieren
- Zeile markieren
- Speichern

Suche und seltene Menuepunkte duerfen oben liegen. Die eigentliche
Massenerfassung nicht.

### Touch-Ziele

- Schnellaktionen mindestens 44 px hoch
- Zeilen interaktiv ueber die ganze Breite
- kein kleiner Linktext fuer Kernaktionen

### Tastaturverhalten

Wenn ein numerisches Feld direkt bearbeitet wird:

- numerische Tastatur oeffnen
- Fokus springt nach Speichern des Werts auf die naechste sinnvolle Zeile
- der Header bleibt sichtbar, aber kompakter, um vertikalen Platz zu sparen

## Header- und Menueverhalten

### Header

Der mobile Header ist arbeitsorientiert, nicht report-orientiert.

Pflichtinhalte:

- Seitentitel oder Modus
- Such-Trigger
- offener Batch-Counter
- `Speichern`
- `Mehr`

Nicht in den Header:

- Metriken wie Saldo, Anzahl Einzahlungen, Anzahl Korrekturen
- lange Badge-Reihen
- Vollnavigation mit vielen Primaerlinks

### Menue

Das Menue verlagert selten genutzte oder sekundare Aktionen in ein Bottom-Sheet
oder Slide-over.

Menueeintraege mobil:

- `Journal oeffnen`
- `Filter zuruecksetzen`
- `Entwurf verwerfen`
- `Nur geaenderte zeigen`
- `Korrekturregeln`
- `Export` nur falls fachlich noetig

Die globale App-Navigation sollte mobil nicht als volle Top-Navigation laufen,
sondern als kompaktes App-Menue oder Bottom-Navigation mit maximal 4 bis 5
Punkten. Fuer diese Seite wichtig:

- `Dashboard`
- `Mitglieder`
- `Buchungen`
- `Einzahlungen`
- `Mehr`

`Buchungen` bleibt als fester Hauptpunkt sichtbar.

## Konkrete Empfehlung fuer die Buchungsseite

### Empfohlene Reihenfolge auf Mobile

1. Sticky Header mit `Buchungen`, Suche, offenem Batch-Counter, `Speichern`
2. Segment `Erfassen | Journal`
3. Sticky Filterchips
4. Kompakte Erfassungsliste als Default
5. Optionaler Sammel-Footer fuer Batch-Aktionen bei markierten Zeilen

### Was aus der aktuellen Seite nach unten oder raus sollte

- Hero-Bereich
- KPI-Karten
- lange Korrekturregel-Panels oberhalb der eigentlichen Buchungsliste
- breite Ledger-Tabelle als primaere Mobile-Darstellung

Diese Inhalte gehoeren auf Mobile in:

- `Journal`
- `Mehr`
- separate Detail- oder Hilfesheets

## Warum dieses Konzept priorisiert werden sollte

Dieses Konzept passt am besten zu datenlastigen SaaS-Workflows, weil es nicht
versucht, Desktop-Audit und Mobile-Erfassung in einer einzigen Darstellungsform
zu vereinen. Es trennt operative Geschwindigkeit von auditierbarer Historie,
haelt die Eingabedichte hoch und macht die Buchungsseite auf dem Smartphone zu
einem echten Arbeitswerkzeug.

## Umsetzungsleitplanke fuer Design und Frontend

- Mobile first fuer `Erfassen`, nicht fuer `Journal`
- keine horizontale Datentabelle als Kernmuster
- lokale Batch-Verwaltung vor Persistierung
- sticky, kompakter Header mit dauerhaftem Save-Pfad
- Filter als Chips plus Bottom-Sheet
- Audit- und Regeltexte nur kontextuell, nicht dauerhaft im Sichtfeld
