psa-orderform/docs/ORDER_PROCESS.md

Order Process

Überblick

Das System bildet keinen klassischen E-Commerce-Checkout ab, sondern einen internen PSA-Anforderungsprozess mit direkter interner Weiterleitung nach dem Absenden.

• Einstieg: index.php -> product.php -> cart.php -> checkout.php
• Persistenz: data/orders.json
• Kernlogik: includes/functions.php
• Interne Bearbeitung: admin/orders.php
• Nachbestellungen: admin/backorders.php
• Einstellungen für 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 werden interne Admin-Benachrichtigung und Kunden-Eingangsbestätigung per E-Mail versendet, der Warenkorb geleert und auf order-success.php weitergeleitet.

Vorbedingungen

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

Es gibt keinen separaten Admin-Freigabeschritt vor dem Eingang einer Bestellung.

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

Regeln:

• 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.

Nachbestellungen (nur Admin)

Wenn Artikel nicht auf Lager sind, können Admins Positionen als Nachbestellung markieren. Der Vorgang ist nur im Admin-Bereich sichtbar, nicht im Frontend.

Daten pro Position

Jede Bestellposition kann optional folgende Felder haben:

• backorder_status: "" (keine), to_be_backordered, ordered
• backordered_at, ordered_at (Zeitstempel)

Zustände

1. Nachzubestellen (to_be_backordered): Position ist als Nachbestellung markiert, externe Bestellung steht noch aus.
2. Wartet auf Lieferung (ordered): Extern bestellt, Lieferung ausstehend.

Aktionen

Aktion	Ort	Wirkung
Als Nachbestellung markieren	admin/orders.php (pro Position)	Setzt to_be_backordered
Nachbestellung aufheben	admin/orders.php	Setzt backorder_status zurück auf "" (nur aus Zustand 1)
Als bestellt markieren	admin/backorders.php	Verschiebt N Positionen von to_be_backordered nach ordered (FIFO)
Lieferung eingetroffen	admin/backorders.php	Setzt N Positionen von ordered zurück auf "" (FIFO); Position bleibt offen zur normalen Abarbeitung

In admin/backorders.php werden Positionen nach Produkt und Größe gruppiert. Die Spalten Nachzubestellen und Wartet auf Lieferung werden getrennt gezählt, damit neu markierte Artikel nicht mit bereits bestellten vermischt werden.

Positionen mit Nachbestell-Status (Nachzubestellen oder Wartet auf Lieferung) erscheinen nicht in Offene Positionen auf dem Dashboard; sie werden über Nachbestellungen verwaltet.

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.
• Bearbeitung ist positionsbasiert im Admin (operativer Abarbeitungsstatus statt klassischer Versandstatus).
• Legacy-Routen reservation.php und orders.php (Frontend) sowie admin/reservations.php leiten auf die Bestellverwaltung um.