# Order Process

## Überblick

Das System bildet keinen klassischen E-Commerce-Checkout ab, sondern einen internen PSA-Anforderungsprozess mit optionaler E-Mail-Bestätigung vor der internen Weiterleitung.

- Einstieg: `index.php` -> `product.php` -> `cart.php` -> `checkout.php`
- Persistenz: `data/orders.json`
- Kernlogik: `includes/functions.php`
- Interne Bearbeitung: `admin/orders.php`
- Einstellungen für Bestätigung/Weiterleitung: `admin/settings.php`

Hinweis:

- `config.php` liefert Startwerte, wirksam im Betrieb sind die normalisierten Einstellungen aus `data/settings.json` (über `getSystemSettings()`).

## Ablauf (Endnutzer)

1. Produkt wird in `product.php` in den Warenkorb gelegt (optional mit Größe).
2. Der Warenkorb (`cart.php`) enthält pro Produkt nur einen Eintrag; erneutes Hinzufügen aktualisiert ggf. die Größe statt eine Menge zu erhöhen.
3. Checkout (`checkout.php`) erfasst:
   - Name
   - E-Mail
   - Organisation (Pflicht, muss aktiv sein)
   - Kommentar (optional)
4. `createOrder(...)` erzeugt eine Bestellnummer (`ORDER_PREFIX-JAHR-LFDNR`, z. B. `FWFS-2026-001`) und speichert die Bestellung.
5. Nach dem Speichern wird der Warenkorb geleert und auf `order-success.php` weitergeleitet.

## Potenzielle Freigaben / Bestätigungen

### 1) Organisation als Vorbedingung

Eine Bestellung ist nur möglich, wenn die gewählte Organisation existiert und als aktiv markiert ist. Inaktive/ungültige Organisationen blockieren den Abschluss.

### 2) Optionale E-Mail-Bestätigung durch Besteller

Die Einstellung `order_confirmation_required` steuert, ob eine Bestätigung nötig ist:

- **Aktiviert**:
  - Status beim Anlegen: `confirmation_status = pending`
  - Es wird eine Bestätigungs-Mail mit Token-Link (`order-confirm.php?token=...`) versendet.
  - Interne Weiterleitung an die Empfängeradresse erfolgt erst nach erfolgreicher Bestätigung.
  - Frist über `order_confirmation_expiry_days`; danach `confirmation_status = expired`.
- **Deaktiviert**:
  - Status beim Anlegen: `confirmation_status = not_required`
  - Bestellung wird direkt intern weitergeleitet.

### 3) Keine separate Admin-Freigabe vor Eingang

Es gibt keinen expliziten Admin-Approve-Schritt, der den Eingang einer Bestellung freischaltet. Die formale Freigabelogik ist die optionale E-Mail-Bestätigung durch den Besteller.

## Interner Prozess nach Eingang

In `admin/orders.php` werden Bestellungen nach Status geführt und manuell bearbeitet:

- `open`: keine Position bearbeitet
- `partial`: mindestens eine Position bearbeitet
- `processed`: alle Positionen bearbeitet
- `cancelled`: Bestellung storniert
- zusätzlich `pending`/`expired` über `confirmation_status`

Regeln:

- Positionsbearbeitung ist gesperrt, solange Bestellung `pending` oder `expired` ist.
- Stornierung ist jederzeit möglich (solange noch nicht storniert).
- Zeitstempel für interne Weiterleitung (`admin_notified_at`) wird gesetzt, wenn die Admin-Benachrichtigungsmail erfolgreich versendet wurde.

## Abweichungen zum Standard-Webshop

- Kein Payment-Schritt (kein Warenwert, keine Zahlungsarten, keine Zahlungsfreigabe).
- Keine Mengenlogik im Warenkorb (pro Produkt nur ein Eintrag, keine Stückzahl).
- Keine Lieferadresse / kein Versandprozess / kein Fulfillment-Tracking.
- Keine Endnutzer-Bestellhistorie oder Kundenkonto-Workflow.
- Optionaler Double-Opt-in-ähnlicher Schritt per E-Mail-Bestätigung vor interner Weiterleitung.
- Bearbeitung ist positionsbasiert im Admin (operativer Abarbeitungsstatus statt klassischer Versandstatus).
- Legacy-Routen `reservation.php` und `orders.php` (Frontend) sowie `admin/reservations.php` und `admin/backorders.php` leiten auf die Bestellverwaltung um und sind kein eigener Prozess mehr.