psa-orderform/docs/ORDER_PROCESS.md

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.