07ABLÄUFE & KANÄLE

Der Reifen ist die Linie.Alle Systeme folgen.

Die UI darf den Prozess vereinfachen, aber niemals seine Wahrheit erfinden. Ein physischer Reifen bleibt vom ersten Code bis zu Rechnung, Paket und Historie einzeln nachvollziehbar.

07.1VIER PERSPEKTIVEN

Dasselbe System.
Vier verschiedene Ziele.

Ein Ablauf ist erst verstanden, wenn er aus Sicht der Person lesbar ist, die ihn gerade erlebt. Die Oberfläche zeigt deshalb nur ihren nächsten sicheren Schritt – Übergaben und Nachweise bleiben trotzdem durchgehend verbunden.

LIVE PATTERNPerspective journeyONE GOAL · FIVE MOMENTS

ERFOLG AUS DIESER SICHTPassenden realen Bestand ohne Umweg sicher kaufen.

01Größe + Saison

Dimension zuerst; Nutzung entscheidet den Filter.

Bestand

02Konkrete Auswahl

1/2/4 Reifen, Endpreis, Profil und DOT vergleichen.

Produktbeweis

03Vertrauen

Originalbilder und einzelne Units prüfen.

Reserve

04Sicher bezahlen

Frist, Adresse, Recht und Gesamtpreis bleiben sichtbar.

Auftrag

05Status erhalten

Rechnung, Pakete und Tracking aus demselben Auftrag.

Lieferung

PHYSISCHER FAKT SERVER-COMMIT KANAL-IST GELD-IST NACHWEIS AUDIT

07.2ABLAUFKATEGORIEN

Übergaben sichtbar.
Verantwortung eindeutig.

Aufnahme, Online-Kauf, Vor-Ort-Verkauf, Erfüllung und Ausnahme verwenden dieselben vier Rollenbahnen. Inaktive Perspektiven bleiben bewusst ruhig; niemand bekommt künstliche Schritte nur für ein vollständiges Diagramm.

LIVE PATTERNCross-channel swimlaneROLE → HANDOFF → PROOF

FACHLICHES EREIGNISKonkrete Units wechseln kontrolliert von live zu verkauft

bezahlter Auftrag mit Bestandssicherheit

01Kunde online

1Größe2Auswahl3Reserve4Zahlung

02Kunde vor Ort

1nicht beteiligt

03Scanner

1erst bei Pick2keine Checkout-Wirkung

04Admin / System

1Preis-Snapshot2Payment-Prüfung3Unit-Besitz4Rechnung

WHO

Rolle klar

Jede Handlung hat genau einen primären Akteur. Systemautomatik wird als System benannt, nicht dem Mitarbeiter zugerechnet.

WHAT

Objekt klar

Unit, Satz, Auftrag, Zahlung, Paket oder Beleg bleibt in jeder Übergabe benannt und verlinkt.

PROOF

Erfolg klar

Eine Übergabe endet mit bestätigtem Zustand, Zeitpunkt und Wirkung – nicht mit „Anfrage gesendet“.

07.3REIFEN-LIFECYCLE

Ein Objekt.
Zwölf klare Übergaben.

Screens werden nicht nach Abteilungen entworfen, sondern nach dem nächsten sicheren Zustandswechsel des realen Reifens. Jede Übergabe benennt Objekt, Besitzer, Wirkung und Rückweg.

Ankunftphysischer Reifen

IdentitätIdentifier / Code

ProduktTyreSpec

ExemplarStockUnit

PrüfungQC + Fotos

Verkaufseinheit1 / 2 / 4 Reifen

FreigabePreis + Gates

KanalShop oder eBay

VerkaufReserve + Zahlung

ErfüllungRechnung + Labels

Versandphysisch bestätigt

NachweisAudit + Reporting

SOURCE

Backend entscheidet

Browser, Scanner und Provider liefern Absichten oder Fakten. Erst der bestätigte Serverzustand darf grün werden.

UNIT

Ein Reifen bleibt einer

Auch im 2er-/4er-Satz, Warenkorb, Auftrag und Paket bleibt jede StockUnit mit Profil, DOT, Lager und Code sichtbar.

FAIL CLOSED

Unklar heißt gesperrt

Zahlung, Providerwrite, Listing oder Versand ohne eindeutigen Ausgang erzeugt eine Aufgabe – keine optimistische Freigabe.

07.4DATENOBJEKTE

Daten haben Besitzer.
UI zeigt ihre Beziehung.

Ein Formular darf Felder gruppieren, aber keine fachlich verschiedenen Objekte vermischen. Das verhindert widersprüchliche Masken und macht spätere Änderungen gezielt statt riskant.

Identifier

Code → genau ein Exemplar

PFLEGE: Scanner / Backend
SCHUTZ: nie still neu zuordnen

TyreSpec

gemeinsame Produktdaten

PFLEGE: Admin / Aufnahme
SCHUTZ: Dimension und Modell exakt

StockUnit

der eine echte Reifen

PFLEGE: Backend
SCHUTZ: DOT, Profil, Status, Lager

TirePhoto

prüfbarer Medienbeleg

PFLEGE: Scanner / Admin
SCHUTZ: Slot, Verarbeitung, Freigabe

TyreSet

Verkaufsgruppe aus 2 oder 4

PFLEGE: Backend / Admin
SCHUTZ: Mitglieder bleiben einzeln

SaleOffer

Preis und Kanalabsicht

PFLEGE: Admin
SCHUTZ: Historie statt Überschreiben

ShopOrder

unveränderlicher Verkaufssnapshot

PFLEGE: Checkout / eBay / Kasse
SCHUTZ: jede Unit bleibt referenziert

Invoice

kaufmännischer Snapshot

PFLEGE: Backend
SCHUTZ: idempotent und fortlaufend

IDENTITÄT PHYSISCHER FAKT VERKAUFSFORM GELDSNAPSHOT NACHWEIS

07.5KANALVERTRÄGE

Jeder Kanal darf etwas.
Keiner darf alles.

Die Oberfläche zeigt nicht nur Status, sondern auch Zuständigkeit und Sicherheitsgrenze. So ist erkennbar, wo gehandelt werden kann und wo erst ein externer Zustand geklärt werden muss.

SCANNERPhysische Wahrheit erfassen

Code, QC, Fotos, Lager, Inventur, Packprüfung. Keine grüne Buchung ohne Server.

SCHREIBT FAKTEN

ADMINAusnahmen lösen & freigeben

Preis, Gates, Sätze, Kanalwahl, Rechnungen, Provider- und Zahlungsabgleich.

STEUERT ENTSCHEIDUNGEN

STOREFRONTNur verkaufbare Wahrheit zeigen

Serverpreis, konkrete Units/Sätze, Session-Reserve, unverlängerliche Deadline und Checkout-Key.

LIEST GEGATET

EBAYExterner Soll-/Ist-Zustand

Durable Outbox, Revisionen und Reconciliation. Bei Unklarheit bleibt das Unikat gehalten.

PROVIDER MIT ABGLEICH

MOLLIEZahlung melden, nicht erfinden

Intent, Betrag, Währung, Zeitpunkt und Besitz werden serverseitig geprüft; Zweifel werden Critical Issue.

EVENT ≠ BESTAND

HERMESLabel pro physischem Reifen

Labels müssen vollständig sein. Erst Scan aller Reifen plus zweite Bestätigung bucht gemeinsam aus.

LABEL ≠ VERSAND

LIVE PATTERNOperative priorityCONSEQUENCE BEFORE COUNT

01 · SOFORT STOPPENZahlung bestätigt – Bestand nicht sicher übernommen

Provider, Betrag, Zeitpunkt und Ownership prüfen. Kein manueller grüner Status.

CRITICAL

02 · ARBEIT BLOCKIERTeBay-Job tot · Reifen weiterhin gehalten

Providerzustand klären, kontrolliert retryen oder Listing beenden.

BLOCKED

03 · FREIGABE FEHLT4 Reifen ohne Preis · 3 DOT-Fotos offen

Direkt zum betroffenen Gate, Kontext und Filter bleiben erhalten.

ACTION

04 · BEOBACHTENMarktpreis oder Kostenbeleg unvollständig

Keine Verkaufsblockade, aber sichtbar bis fachlich geprüft.

NOTICE

07.6SCANNER-POLICY

Die Kamera sieht viel.
Sie bucht genau eins.

Das heutige ZXing-Scanning entprellt Wiederholungen und schützt Requests, akzeptiert aber den ersten gelieferten Code. Der Zielvertrag ergänzt zentrale Zielzone, stabile Wiederholung, Mehrfachcode-Stopp und einen sichtbaren Decoder-Lock.

LIVE PATTERNScanner acceptance gateONE CODE · ONE REQUEST

KAMERABEREIT

BEREIT

Ein Label zentrieren

Nur ein ausreichend großer Code innerhalb der Zielzone darf Kandidat werden.

01Öffnen
Nur nach eindeutiger Aufgabe.
02Begrenzen
Zentrale ROI statt ganzer Reifenstapel.
03Stabilisieren
Gleicher Wert in zwei Treffern.
04Locken
Decoder vor dem Netzaufruf sperren.
05Bestätigen
Erfolg ausschließlich vom Server.

MOMENTKAMERAVERTRAG

Menü / VorbereitungAUSKein Stream im Hintergrund. Aufgabe, Satzgröße, Kanal und Lagerplatz zuerst festlegen.

Aufnahme / StatusAN NACH TASK-TAPDie gewählte Aufgabe gilt als Einwilligung. Nach akzeptiertem Code stoppt der Decoder vor Datenblatt und QC. Mehrere rückwärtige Linsen bleiben sichtbar wechselbar.

UmlagernAN NACH LAGERPLATZOhne angepinnten Zielplatz kein Scan. Nach Serverantwort kontrolliert für den nächsten Reifen rearmen.

InventurAN NACH SOLLBESTANDErst Lagerplatz frisch laden, dann Serienmodus. Abweichungen werden gezeigt, niemals still korrigiert.

VersandAN IM AUFTRAGZuerst Auftrags-QR, danach Reifencodes. Vor der finalen Ausbuchung Kamera sperren und bewusst bestätigen.

Vor-Ort-VerkaufNUR AUF ANFORDERUNGBarcode-Button öffnet den Stream. Angebotssheet, Kasse und Zahlungsbestätigung schließen ihn.

Einzelreifen-FotostreckeHOCHKANT / DECODER AUSNur die Hauptansicht erhält eine geschlossene Frontkontur. Genau den gebuchten Reifen vollständig und ohne weitere Reifen im Bild aufnehmen; Kamera auf Reifenmitte, mit Abstand statt Nahwinkel, konkrete Rücklinse wählbar und lokal gemerkt.

Satz-GruppenfotoFREIE AUFNAHMEGruppenbilder besitzen keine Reifenschablone. Der einzelne physische Reifen wird zuvor jeweils über seine eigene Frontaufnahme normiert.

Offline / HintergrundPAUSIERTKein lokaler Erfolgsstapel. Wert behalten, Verbindung herstellen und serverbestätigt wiederholen.

Kein Code in der Zielzone

Weiter zielen. Kein Ton, kein Request, kein flackernder Fehler.

Ein Code · zweimal stabil

Normalisieren, Decoder sofort sperren, Scanfeedback geben und exakt einen Request senden.

Mehrere Kandidaten sichtbar

Nichts auswählen. „Nur ein Label in den Rahmen“ anzeigen; außerhalb der zentralen Zone ignorieren.

✓

Server hat bestätigt

Erfolg zeigen; im Serienmodus nach kurzer Ruhe rearmen, vor Formular/Bestätigung Stream schließen.

07.7UPDATE-VERTRAG

Neu lackieren.
Wahrheit behalten.

Die spätere Übertragung modernisiert Masken und Wege, ohne die fachlich erprobten Locks, Idempotency-Keys, Gate-Prüfungen oder Auditpfade neu zu erfinden.

BEHALTEN

API-Verträge, Statusketten, Serverautorität, Idempotenz, Audit und Rollen.

VERBESSERN

Informationshierarchie, Masken, Defaults, Fokus, Laufwege und sichere Serienbedienung.

NICHT TARNEN

Providerunsicherheit, Offlinezustand, Teilfehler, fremden Besitz und externe Restgrenzen.

ABNEHMEN

Reales Gerät, Handschuhe, Hallenlicht/-lärm, 200 % Zoom, Dark/Light und lange deutsche Daten.

Reihenfolge nach CI-Freigabe: Scanner-Task für Task, Admin-Modul für Modul, Storefront-Journey für Journey. Jede Änderung wird gegen echte DTOs und Fehlerzustände geprüft – kein paralleler Komplettumbau.