Bestellstatus-Workflow in PrestaShop: Anpassung und Automatisierung

Es gibt einen Teil von PrestaShop, der still und leise Ihr gesamtes Backoffice steuert und den trotzdem fast niemand bewusst einrichtet: den Bestellstatus. Jede Bestellung befindet sich zu jedem Zeitpunkt in genau einem Status, und dieser eine Wert entscheidet, was der Kunde in seinem Konto sieht, ob Lagerbestand abgezogen wurde, ob eine Rechnung existiert und welche E-Mail gerade in seinem Posteingang landet. Lassen Sie die Standardwerte unangetastet, arbeitet ein geschäftiger Shop schnell mit Bauchgefühl und Improvisation. Richten Sie die Status dagegen an Ihrem tatsächlichen Fulfillment-Prozess aus, sagt dasselbe Backoffice Ihrem Team plötzlich, was als Nächstes zu tun ist - und informiert Ihre Kunden, was passiert, bevor sie überhaupt nachfragen müssen. In diesem Leitfaden geht es konkret um PrestaShop: was jeder Standardstatus tatsächlich auslöst, wie Sie eigene Status unter Shop-Parameter → Status anlegen, was darunter in der Tabelle ps_order_state steckt und wie Sie Übergänge automatisieren, damit Ihr Team nicht länger als Datenbank-Trigger mit Puls arbeiten muss.

Zuletzt aktualisiert: Juni 2026.

Was ein Bestellstatus in PrestaShop wirklich ist

Ein Bestellstatus in PrestaShop ist nicht nur eine Beschriftung. Jeder Status ist eine Zeile in der Tabelle ps_order_state (mit seinem übersetzbaren Namen in ps_order_state_lang), und diese Zeile enthält eine Reihe boolescher Flags, die dem Core sagen, was er tun soll, wenn eine Bestellung diesen Status erreicht: eine Rechnung erzeugen oder nicht, die Bestellung als bezahlt markieren, sie als versendet markieren, den Lieferschein-PDF freigeben, eine E-Mail senden. (Der Lagerabzug gehört nicht zu diesen Flags - PrestaShop reduziert den verfügbaren Bestand, wenn die Bestellung validiert/erstellt wird, nicht wenn ein Status-Flag ausgelöst wird; dazu weiter unten mehr.) Der aktuelle Status einer Bestellung steht in ps_orders.current_state. Zusätzlich schreibt PrestaShop bei jeder Statusänderung eine neue Zeile in ps_order_history, sodass die Bestellung eine vollständige, zeitgestempelte Historie aller Stationen behält. Der „aktuelle Status“, den Sie im Adminbereich sehen, ist der Wert in current_state; ps_order_history hält fest, wie die Bestellung dorthin gekommen ist.

Die praktische Konsequenz für Shopbetreiber: In der Statusliste steckt Ihre operative Logik. Setzen Sie die Flags einmal korrekt, und PrestaShop wendet sie künftig auf jede Bestellung an - niemand im Team muss sich merken: „Die Rechnung erzeugen wir erst, wenn die Zahlung eingegangen ist, nicht vorher.“ Setzen Sie sie falsch, erzeugen Sie im Hintergrund möglicherweise Rechnungen für Bestellungen, die noch niemand bezahlt hat. Auf diese Falle kommen wir weiter unten zurück.

Die Standard-Bestellstatus - und was jeder davon tatsächlich auslöst

PrestaShop wird mit einer vordefinierten Statusliste ausgeliefert. Viele Händler betrachten sie als reine Dekoration; tatsächlich löst jeder Status in dem Moment echte Aktionen in der Datenbank aus, in dem eine Bestellung ihn erreicht. Das passiert unter der Haube.

Wartet auf Scheckzahlung

Wird angewendet, wenn ein Kunde an der Kasse Scheckzahlung wählt. Die Bestellung existiert, aber Geld ist noch nicht eingegangen. Die Bestellung wird beim Absenden validiert, der verfügbare Bestand wird also gemäß Ihren Lagereinstellungen zu diesem Zeitpunkt behandelt - nicht separat durch diesen Status „reserviert“ -, es wird keine Rechnung erzeugt, und die Bestellung bleibt hier stehen, bis Sie manuell bestätigen, dass der Scheck eingelöst wurde. Von selbst bewegt sich nichts weiter - genau so ist es gedacht.

Wartet auf Überweisung

Das Gegenstück für Banküberweisungen. Dem Kunden werden IBAN/BIC und Bestellreferenz angezeigt, der verfügbare Bestand wird bei der Bestellvalidierung gemäß Ihren Lagereinstellungen behandelt, und die Bestellung wartet hier, bis Sie sie als bezahlt markieren - meist ein bis drei Werktage später, wenn die Überweisung eingeht. Das ist der Status, dessen Automatisierung sich am meisten lohnt (mehr dazu im Abschnitt zur Automatisierung), denn Überweisungen von Hand abzugleichen ist reine Wiederholungsarbeit im Adminbereich.

Zahlung eingegangen

Das ist der zentrale Status. Wenn eine Bestellung Zahlung eingegangen erreicht, tut PrestaShop Folgendes:

• Es erzeugt die Rechnung (wenn der Status das Rechnungs-Flag trägt - standardmäßig tut er das);
• es markiert die Bestellung in der Datenbank als bezahlt;
• es sendet die Status-E-Mail an den Kunden.

Achten Sie darauf, was dieser Status nicht tut: Er zieht keinen Lagerbestand ab. Der verfügbare Bestand wird reduziert, wenn die Bestellung an der Kasse erstellt/validiert wird - und das passiert auch bei Bestellungen, die noch in Wartet auf Zahlung stehen. Die Lagerbewegung ist also normalerweise bereits erfolgt, bevor die Bestellung jemals Zahlung eingegangen erreicht.

Bei Gateway-Zahlungen - PayPal, Stripe, Mollie - setzt das Zahlungsmodul diesen Status automatisch, sobald das Gateway die Belastung bestätigt. Sie müssen nichts anfassen. Genau diesen automatischen, codegesteuerten Übergang sollten Sie für Ihre manuellen Zahlungsarten nachbilden.

In Bearbeitung / In Vorbereitung

Ein optionaler Zwischenstatus, der sagt: „Das Lager kommissioniert und verpackt gerade.“ Er löst keine automatischen Aktionen aus - sein ganzer Wert liegt in der Koordination im Team. Manche Shops überspringen ihn; Shops mit hohem Bestellvolumen halten ihn für unverzichtbar, weil sich die Packliste auf einen Blick von der Warteschlange unbezahlter Bestellungen unterscheiden lässt.

Versendet

Wird angewendet, wenn das Paket Ihr Lager verlässt. Er löst eine Versandbestätigungs-E-Mail aus (inklusive Sendungsnummer, falls vorhanden) und macht den Lieferschein verfügbar. Die Reihenfolge ist wichtig: Tragen Sie die Sendungsnummer im Abschnitt Versanddienstleister der Bestellung ein, bevor Sie den Status auf Versendet umstellen. Sonst geht die E-Mail ohne Tracking-Link hinaus, und die „Wo ist mein Paket?“-Nachricht kommt trotzdem.

Zugestellt

Markiert, dass der Kunde die Ware erhalten hat - manuell gesetzt oder durch eine Versanddienstleister-API-Integration. In der EU beginnt in diesem Moment die 14-tägige Widerrufsfrist im Fernabsatz. Exakte Zustelldaten sind also keine Kosmetik; sie sind die Uhr, nach der Ihre Retourenregeln laufen.

Storniert

Das Stornieren einer Bestellung kann den verfügbaren Bestand der bestellten Produkte wieder erhöhen (über das normale Lagerverwaltungsverhalten von PrestaShop, da der Bestand bereits bei Aufgabe der Bestellung reduziert wurde), und der Kunde erhält eine Stornierungs-E-Mail. Zwei Dinge erledigt dieser Status nicht automatisch: das Geld erstatten (das machen Sie separat) und eine bereits erzeugte Rechnung löschen. Wenn eine Rechnung existiert, erstellen Sie eine Gutschrift, statt so zu tun, als hätte es die Rechnung nie gegeben - Ihre Buchhaltung wird es Ihnen danken.

Erstattet

Wird angewendet, sobald eine Erstattung verarbeitet wurde. Eine Gutschrift entsteht nicht allein dadurch, dass Sie dieses Statusetikett setzen - sie wird über den Erstattungs-Workflow erzeugt (das Panel Standarderstattung / Teilerstattung / Produkte zurücksenden), wenn Sie die Option zur Erstellung auswählen. Ob die Artikel wieder in den verkaufbaren Bestand zurückgebucht werden, hängt ebenfalls davon ab, wie Sie die Erstattung in diesem Panel abgewickelt haben.

Zahlungsfehler

Wird gesetzt, wenn ein Zahlungsversuch fehlschlägt - abgelehnte Karte, unzureichende Deckung, fehlgeschrittener 3-D-Secure-Schritt. Es wird kein Bestand abgezogen und keine Rechnung erzeugt. Ob der Kunde darüber informiert wird, hängt vollständig vom Zahlungsmodul ab.

Im Lieferrückstand (bezahlt / nicht bezahlt)

Für Shops, die Bestellungen annehmen, obwohl sie noch nicht versenden können. Die Bestellung wird erfasst, aber die Erfüllung wartet auf Nachschub. Die Varianten „bezahlt“ und „nicht bezahlt“ helfen dabei, den Zahlungsstatus ehrlich abzubilden, während die Ware noch auf dem Weg zu Ihnen ist.

Status in der Datenbank lesen

Sie müssen nie SQL anfassen, um einen Shop zu betreiben. Aber wer die Datenstruktur kennt, versteht die Adminmasken besser - und genau daran hängt jede Automatisierung. Diese drei Tabellen sind entscheidend:

Weil jede Statusänderung eine neue Zeile in ps_order_history anhängt (und zugleich current_state an der Bestellung aktualisiert), ist die Historie kein zerstörerisches Überschreiben, sondern ein Audit-Trail. Deshalb können Sie jederzeit sehen, welche Stationen eine Bestellung durchlaufen hat. Und deshalb ist ein unbedachtes Bulk-SQL-Update auf Bestellstatus gefährlich: Schreiben Sie direkt in die Tabellen, umgehen Sie jedes Flag, jede E-Mail und jede Lagerbewegung, die der Core normalerweise auslösen würde. Der unterstützte Weg, eine Bestellung im Code zu verschieben, läuft über das Bestellobjekt, nicht über rohe UPDATEs. Die passenden Hooks behandeln wir im Entwicklerabschnitt.

Eigene Bestellstatus anlegen

Gehen Sie zu Shop-Parameter → Status (in PrestaShop 1.6 lag diese Ansicht unter Bestellungen → Status). Klicken Sie auf Neuen Bestellstatus hinzufügen, und Sie konfigurieren über die Oberfläche eine dieser Zeilen in ps_order_state. Diese Felder sind wichtig:

• Statusname: das, was Ihr Team in der Bestellliste liest. „Wartet auf Lieferant“ schlägt „Status 7“ jedes Mal - klare Namen beseitigen eine ganze Kategorie von „Was bedeutet der noch mal?“-Fragen.
• Symbol und Farbe: der visuelle Hinweis in der Bestellliste. Legen Sie eine Konvention fest und halten Sie sich daran: Grün für gut, Orange für ausstehend, Rot für Probleme. Ein Händler sollte die Bestellliste auch aus ein paar Metern Entfernung nach Farbe vorsortieren können.
• Verhaltens-Flags - das ist der eigentliche Motor:
  • Zugehörige Bestellung als validiert betrachten: zählt die Bestellung in Ihren Verkaufsstatistiken.
  • Kunden erlauben, PDF-Versionen ihrer Rechnungen herunterzuladen und anzusehen: steuert die Sichtbarkeit der Rechnung im Kundenkonto.
  • Bestellung als bezahlt markieren: teilt dem Rest von PrestaShop mit, dass Geld eingegangen ist.
  • Liefer-PDF anzeigen / Bestellung als versendet markieren: markiert die Ware als versendet und gibt den Lieferschein frei.
  • Rechnung erzeugen: erzeugt bei diesem Übergang das Rechnungs-PDF.
  • E-Mail an den Kunden senden, wenn sich der Bestellstatus geändert hat: der Auslöser, der aus einem Status eine Kundenbenachrichtigung macht.
• E-Mail-Vorlage: welche Nachricht verschickt wird, wenn das E-Mail-Flag aktiv ist.

Der praktische Unterschied dieser Flags: Sie entscheiden, ob ein Status nur eine Farbe ist oder im Hintergrund Ihre Buchhaltung erledigt. Setzen Sie sie bewusst, und PrestaShop macht bei jeder künftigen Bestellung das Richtige, ohne dass jemand danebenstehen muss.

Eigene Status, die wir am häufigsten sehen

Aus der täglichen Arbeit mit PrestaShop-Shops wissen wir: Diese eigenen Status verdienen ihren Platz:

• Wartet auf Lieferant: bezahlt, aber ein Artikel muss nachbestellt werden. Keine Kunden-E-Mail - das ist ein interner Hinweis, keine Nachricht, die der Kunde braucht.
• Abholbereit: für Click-and-Collect. E-Mail aktiv, mit Adresse, Öffnungszeiten und dem Hinweis, was der Kunde mitbringen soll.
• Teilweise versendet: einige Artikel sind versendet, andere kommen noch. Informieren Sie den Kunden, was verschickt wurde und was noch offen ist.
• In Prüfung: hochpreisige oder wegen Betrugsverdacht markierte Bestellungen, die manuell geprüft werden. Keine Kunden-E-Mail.
• Wartet auf Kundenantwort: Sie haben den Kunden kontaktiert (Adresskorrektur, Produktfrage), und die Bestellung wartet auf seine Antwort.
• Rücksendung angefragt / Rücksendung eingegangen: die zwei Hälften eines RMA-Prozesses - der Kunde hat eine Rücksendung angefragt, später ist das Paket zur Prüfung wieder bei Ihnen eingetroffen.

E-Mail-Auslöser für jeden Status

Wenn bei einem Status das E-Mail-Flag aktiv ist, sendet PrestaShop dem Kunden die Vorlage, die diesem Status zugeordnet ist. Die Vorlagen liegen in /mails/LANGUAGE_CODE/ als zusammengehörige HTML- und TXT-Dateien (die Plain-Text-Version ist der Fallback für Clients, die HTML blockieren, daher müssen beide existieren).

Eine E-Mail für einen eigenen Status korrekt verbinden

Aktivieren Sie E-Mail für einen eigenen Status, sind Sie auch für die Vorlage verantwortlich - sonst schlägt der Versand stillschweigend fehl und landet nur in den Logs. So verbinden Sie sie sauber:

• Legen Sie die passenden HTML- und TXT-Dateien in jedem Sprachordner unter /mails/ an - der Vorlagenname muss zu dem passen, was der Status erwartet.
• Verwenden Sie die Platzhalter, die der Core bereits bereitstellt: {firstname}, {lastname}, {order_name}, {id_order}, {shipping_number} für die Sendungsverfolgung und die übrigen.
• Gestalten Sie das Aussehen einmal unter Design → Email Theme, statt jede Datei von Hand zu bearbeiten.

Wenn Sie gar keine Vorlagen schreiben möchten: Der wirklich häufige Fall ist schlicht, dass ein Kunde eine Bestell-E-Mail verloren hat. PrestaShop kann die vorhandene Bestätigung direkt von der Bestellseite erneut senden - wo genau diese Schaltfläche sitzt, zeigen wir in So senden Sie eine Bestellbestätigung erneut.

Die richtigen E-Mails senden, nicht alle

• Nicht zu viele E-Mails senden. Kunden möchten nicht bei jedem internen Zwischenschritt eine Nachricht bekommen. „In Vorbereitung“ ist für Ihr Team gedacht, nicht für den Posteingang des Kunden. Reservieren Sie E-Mails für die Momente, die wirklich relevant sind: Zahlung bestätigt, versendet (mit Tracking), zugestellt.
• Jede E-Mail muss handlungsrelevant sein. Die Versand-E-Mail enthält Sendungsnummer und Link; die Abholbereit-E-Mail enthält Adresse, Öffnungszeiten und was mitzubringen ist. Eine E-Mail ohne nächsten Schritt erzeugt nur eine Antwort.
• Erwartungen setzen. Bei Rückstand sagen Sie, wie lange es voraussichtlich dauert. Ein vages „Ihr Bestellstatus hat sich geändert“ ohne Details ist praktisch ein vorbereitetes Support-Ticket.

Statusänderungen automatisieren

Status manuell zu verwalten ist bei zehn oder zwanzig Bestellungen pro Tag in Ordnung. Danach ist jeder manuelle Übergang bezahlte Arbeitszeit - und eine Gelegenheit, einen Schritt zu vergessen. Die Chancen zur Automatisierung, grob nach Nutzen sortiert:

Zahlungsbestätigung

Kartenzahlungs-Gateways automatisieren das bereits - PayPal, Stripe und Mollie setzen die Bestellung bei Bestätigung ohne menschliches Zutun auf Zahlung eingegangen. Die Lücke sind Banküberweisungen und Schecks: Hier bleiben manuelle Bestätigung, eine Bankdaten-Integration, die eingehende Überweisungen anhand der Referenz Bestellungen zuordnet, oder eine geplante Prüfung gegen einen Gateway-Webhook. Diese Lücke zu schließen ist meist der größte Zeitgewinn im gesamten Bestellfluss.

Versand

Ein Versanddienstleister-Integrationsmodul (Colissimo, DHL, Mondial Relay und ähnliche) sollte die Bestellung auf Versendet setzen und die Sendungsnummer eintragen, sobald Sie das Versandetikett drucken. Wenn Ihr Modul das nicht tut, gibt es fast immer eine Einstellung dafür - sie ist nur standardmäßig deaktiviert.

Zustellbestätigung

Versanddienstleister-APIs können die Zustellung melden. Ein geplanter Job, der die API täglich abfragt und bestätigte Pakete auf Zugestellt setzt, hält die EU-Retourenfrist korrekt, ohne dass jemand Tracking-Seiten beobachten muss. Das ist klassisches Cronjob-Terrain - einmal einrichten, dann läuft es, während Sie schlafen.

Regelbasierte Workflow-Automatisierung

Für die „wenn dies, dann das“-Logik, die der Core nicht abdeckt - wenn die Zahlungsart Banküberweisung ist und der Gesamtwert über 500 EUR liegt, setze In Prüfung und benachrichtige den Admin -, brauchen Sie regelbasierte Statusautomatisierung statt individuellen Code, der beim nächsten Upgrade bricht. Genau für solche bedingten Workflows baut unser Team Module bei mypresta.rocks: Bedingungen und Aktionen im Backoffice definieren, und PrestaShop leitet jede Bestellung selbstständig auf den richtigen Weg. Der Nutzen ist nicht „Automatisierung“ als Schlagwort - sondern dass der Engpass nicht länger eine Person ist, die am Schreibtisch sitzen muss.

Bestellstatus-Hooks für Entwickler

Wenn Sie die Automatisierung selbst bauen, feuert PrestaShop rund um jede Statusänderung Hooks, damit Sie nie direkt in die Tabellen schreiben müssen:

• actionOrderStatusUpdate: wird ausgelöst, während eine Statusänderung angewendet wird. Es ist ein Hook im Benachrichtigungsstil; behandeln Sie ihn daher als Ort für eigene Validierung und Modullogik rund um einen Übergang, nicht als garantiert core-unterstützten Weg, einen Übergang sauber zu blockieren.
• actionOrderStatusPostUpdate: wird nach dem Commit der Änderung ausgelöst - der richtige Ort für Folgearbeiten wie die Synchronisierung der Bestellung mit einem ERP oder einer Versandplattform.
• actionOrderHistoryAddAfter: wird ausgelöst, nachdem eine neue Zeile in ps_order_history geschrieben wurde - praktisch für eigenes Logging und Audit-Trails.

Ein typisches Muster: Beim Wechsel zu Versendet senden Sie einen Webhook an die API Ihres Fulfillment-Partners; beim Wechsel zu Zugestellt planen Sie eine Bewertungsanfrage per E-Mail für sieben Tage später ein. Weil Sie die Bestellung über ihr Objekt bewegen und auf diese Hooks hören, werden alle Flags, E-Mails und Lagerbewegungen, die der Core verantwortet, weiterhin korrekt ausgelöst - genau deshalb verwenden Sie Hooks statt eines rohen SQL UPDATE auf ps_order_state.

Bestellungen unterwegs bearbeiten und korrigieren

Status beschreiben, wo eine Bestellung gerade ist; genauso oft müssen Sie ändern, was in ihr steckt - eine Menge korrigieren, eine Adresse austauschen, nachträglich einen Rabatt anwenden. PrestaShop erlaubt das Bearbeiten einer aufgegebenen Bestellung auf der Detailseite, allerdings mit echten Grenzen, sobald eine Rechnung existiert. Die vollständige Anleitung dazu, was wann gefahrlos geändert werden kann, finden Sie in So bearbeiten Sie eine Bestellung, nachdem sie aufgegeben wurde. Den breiteren Alltag mit der Bestellliste - Filtern, Massenaktionen, Status im Kontext - behandeln wir in unserem vollständigen Leitfaden zur Bestellverwaltung in PrestaShop.

Teillieferungen handhaben

Teillieferungen sind der schwierigste Workflow, den die PrestaShop-Standards noch abdecken. Der Core geht stillschweigend davon aus: eine Bestellung entspricht einer Lieferung. Native Unterstützung für Teillieferungen ist begrenzt, und Lieferscheine sind Dokumente auf Bestellungsebene - PrestaShop modelliert artikelbezogene Teillieferungen von Haus aus nicht sauber. Ein praktikabler manueller Ansatz sieht so aus:

• Legen Sie einen eigenen Status Teilweise versendet an;
• tragen Sie die Sendungsnummer für die Artikel ein, die jetzt hinausgehen;
• wenn der Rest bereit ist, versenden Sie ihn unter einer neuen Sendungsnummer;
• setzen Sie die Bestellung erst auf Versendet, wenn alles versendet wurde.

Der Reibungspunkt: Die Standard-Bestelldetailseite verfolgt nicht nativ, welche Artikel in welchem Paket gelandet sind. Auch ein Lieferschein pro Sendung nur für die Artikel in diesem Paket ist keine native Operation. Shops, die regelmäßig Bestellungen aufteilen, brauchen einen eigenen Workflow oder ein Modul für echtes artikelbezogenes Versand-Tracking und entsprechende Dokumente zusätzlich zum Core - sonst sagt Ihnen die Bestellhistorie nur, dass etwas versendet wurde, aber nicht was.

B2B-Bestellworkflows

B2B-Fulfillment folgt nicht dem B2C-Pfad, und in der Statusliste bilden Sie diesen Unterschied ab:

• Angebot und Freigabe: Bestellungen, die vor der Zahlung freigegeben werden müssen, modelliert als „Angebot gesendet“ → „Angebot freigegeben“ → „Wartet auf Zahlung“ → „Zahlung eingegangen“.
• Bestellungen per Bestellauftrag: Zahlungsziele wie netto 30/60/90 bedeuten, dass Fulfillment und Zahlungseingang zwei getrennte Zeitachsen sind; Ihre Status müssen beide verfolgen, ohne sie zu vermischen.
• Teillieferungen: B2B-Bestellungen mit mehreren Artikeln und unterschiedlichen Lieferzeiten nutzen den oben beschriebenen Teillieferungsaufbau routinemäßig, nicht als Ausnahme.
• Mindestbestellwert-Prüfung: Bestellungen unter Mindestwert können über „In Prüfung“ laufen, bevor jemand sie kommissioniert.

Über Ihre Status berichten

Weil jeder Übergang als zeitgestempelte Zeile in ps_order_history steht, sind Ihre Statusdaten bereits Ihr operatives Reporting - kostenlos, wenn Sie hinschauen:

• Zeit in jedem Status: Wie lange Bestellungen in Zahlung eingegangen bleiben, bevor sie Versendet werden, ist buchstäblich Ihre Fulfillment-Geschwindigkeit.
• Statusverteilung: Ein wachsender Stapel in „Wartet auf Lieferant“ ist ein Beschaffungsproblem, das sichtbar wird, bevor Ihr Lieferant es zugibt.
• Stornierung nach Phase: Wenn Bestellungen in einem Status überproportional abbrechen, hat diese Prozessphase ein Leck.
• Vollständiger Lebenszyklus: Von Bestellung bis Zustellung, über die Zeit verfolgt, zeigt Ihnen, ob Sie schneller werden oder unbemerkt langsamer.

Häufige Fehler, die Sie vermeiden sollten

• Zu viele Status. Ab etwa einem Dutzend merkt sie sich niemand mehr, und die Liste hilft nicht mehr bei der Priorisierung. Wenn Ihr Team sie nicht aus dem Kopf aufzählen kann, sind es zu viele.
• Unklare Namen. „Status A“ und „Status B“ sagen niemandem etwas. Benennen Sie Status nach ihrer Bedeutung.
• Eigener Status mit E-Mail aktiv, aber ohne Vorlage. Das ist der Fall des stillen Fehlers - der Versand stirbt in den Logs, und der Kunde hört nichts.
• Ungeschultes Personal. Der sauberste Workflow ist nutzlos, wenn das Team nicht weiß, wann welcher Status zu setzen ist. Eine einseitige Referenztabelle macht sich schnell bezahlt.
• Die Falle mit dem Rechnungs-Flag. Aktivieren Sie Rechnung erzeugen für einen Status, der keine bestätigte Zahlung bedeutet, erzeugen Sie Rechnungen für Bestellungen, die niemand bezahlt hat - ein echtes Buchhaltungs- und Steuerproblem. Prüfen Sie dieses Flag doppelt, bevor Sie speichern.

Ein Hinweis zu Testbestellungen

Während Sie all das aufbauen, werden Sie Testbestellungen anlegen, um Status und E-Mails auszulösen - und jede einzelne davon verschmutzt Ihre Statistiken, Ihre Rechnungsnummernfolge und Ihre ps_order_history, wenn Sie sie stehen lassen. Räumen Sie sie auf, bevor Sie live gehen; wie Sie sie sicher entfernen (und warum Sie die Zeilen nicht einfach per DELETE löschen sollten), erklären wir in So löschen Sie Testbestellungen in PrestaShop.

Häufig gestellte Fragen

Wo füge ich in PrestaShop einen eigenen Bestellstatus hinzu?

Gehen Sie zu Shop-Parameter → Status und klicken Sie dann auf Neuen Bestellstatus hinzufügen. In PrestaShop 1.6 lag dieselbe Ansicht unter Bestellungen → Status. Jeder Status, den Sie anlegen, ist eine Zeile in der Tabelle ps_order_state, und die Checkboxen in diesem Formular (bezahlt, versendet, Rechnung erzeugen, E-Mail senden) sind die Verhaltens-Flags, die der Core auslöst, sobald eine Bestellung diesen Status erreicht.

Zieht der Wechsel einer Bestellung auf „Zahlung eingegangen“ Lagerbestand ab?

Nein. Der verfügbare Bestand wird reduziert, wenn die Bestellung an der Kasse validiert/erstellt wird - und das passiert auch, während die Bestellung noch in „Wartet auf Zahlung“ steht -, nicht wenn das Bezahlt-Flag feuert. Bis eine Bestellung Zahlung eingegangen erreicht, ist die Lagerbewegung normalerweise bereits erfolgt. Der Bezahlt-Status erzeugt die Rechnung, markiert die Bestellung als bezahlt und sendet die Status-E-Mail; er fasst den Lagerbestand nicht an.

Warum wurde meine E-Mail für einen eigenen Status nie gesendet?

Fast immer fehlt eine Vorlage. Wenn Sie das E-Mail-Flag für einen Status aktivieren, sucht PrestaShop in jedem Sprachordner unter /mails/LANGUAGE_CODE/ nach passend benannten HTML- und TXT-Dateien. Existieren diese Dateien nicht, schlägt der Versand stillschweigend fehl und landet nur in den Logs; der Kunde hört nichts. Legen Sie die zusammengehörigen HTML/TXT-Vorlagen für jede Sprache an, bevor Sie sich auf die E-Mail verlassen.

Kann ich den Status einer Bestellung aus Code ändern, ohne SQL zu schreiben?

Ja - und genau so sollten Sie es tun. Bewegen Sie die Bestellung über ihr Bestellobjekt, damit alle Flags, E-Mails und Lagerbewegungen weiterhin ausgelöst werden, und hören Sie auf die Hooks, die PrestaShop bereitstellt: actionOrderStatusUpdate (während die Änderung angewendet wird), actionOrderStatusPostUpdate (nach dem Commit - gut für ERP-/Versandsynchronisierung) und actionOrderHistoryAddAfter (nachdem die Historienzeile geschrieben wurde). Ein rohes UPDATE auf ps_order_state umgeht all das - genau so entstehen Rechnungen und E-Mails, die nicht mehr zusammenpassen.

Wie vermeide ich Rechnungen für unbezahlte Bestellungen?

Achten Sie auf das Flag Rechnung erzeugen. Wenn Sie es für einen Status aktivieren, der keine bestätigte Zahlung bedeutet, erzeugt PrestaShop Rechnungen für Bestellungen, die niemand bezahlt hat - ein echtes Buchhaltungs- und Steuerproblem. Binden Sie die Rechnungserzeugung ausschließlich an Ihren zahlungsbestätigten Status, und prüfen Sie die Checkbox doppelt, bevor Sie einen neuen Status speichern.

Kann ich Statusänderungen für Banküberweisungen und bedingte Regeln automatisieren?

Kartenzahlungs-Gateways setzen Bestellungen bereits automatisch auf Zahlung eingegangen; die Lücke sind Banküberweisungen, Schecks und bedingte Logik wie „wenn Banküberweisung und Gesamtwert über 500 EUR, dann In Prüfung setzen“. Genau diese Art regelbasierten Workflows übernimmt unser Modul für Bestellworkflow-Automatisierung aus dem Backoffice heraus, damit der Engpass nicht länger eine Person ist, die am Schreibtisch sitzen muss, um Status umzuschalten.

Ein gut geformter Bestellstatus-Workflow ist das Rückgrat eines ruhigen Backoffice: Das Team weiß, was als Nächstes zu tun ist, der Kunde erhält im richtigen Moment die richtige Information, und die Buchhaltung bleibt sauber, weil die Flags - nicht ein müder Mensch um 18 Uhr - entscheiden, wann eine Rechnung existiert und wann Lagerbestand bewegt wird. Planen Sie den Workflow, bevor Sie ihn verdrahten, denn sobald Bestellungen durch Ihre Status laufen, ist eine Änderung mitten im Betrieb deutlich störender, als es gleich beim ersten Mal richtig zu machen. Wenn Sie über manuelle Übergänge hinauswachsen, nimmt Ihnen regelbasierte Automatisierung von mypresta.rocks das repetitive Status-Umschalten ab, damit jede Bestellung denselben Weg von Aufgabe bis Zustellung nimmt - jedes Mal, ob gerade jemand zusieht oder nicht.