PrestaShop-Bestellabläufe: Status, E-Mails und Bearbeitung

Unser Vorgehen

Wir würden zunächst Ihren bestehenden Ablauf erfassen, bevor wir weitere Status hinzufügen: Wer bestätigt Zahlungen, gibt die Kommissionierung frei, bearbeitet Ausnahmen und bestätigt den Versand? Der passende Weg hängt von Ihren Zahlungs- und Versandmodulen, ERP- oder Lagerintegrationen, Theme und Checkout, vorhandenen Bestelldaten, Absatzmärkten, Buchhaltungsanforderungen und Teamberechtigungen ab. Behalten Sie native Status für aussagekräftige kaufmännische Ereignisse bei und nutzen Sie separate interne Schritte, wenn die fehlende Information eine zuständige Person oder die nächste Aufgabe betrifft.

Proben Sie Änderungen auf einer Staging-Kopie mit repräsentativen Bestellungen und denselben Modulen, demselben Theme und denselben Integrationen. Nutzen Sie Sandbox-Zahlungen und abgefangene E-Mails und trennen Sie Lagerexporte und Versandaktionen von Produktivsystemen. Sichern Sie die aktuelle Konfiguration und Statuszuordnungen, testen Sie den normalen Ablauf und die unten beschriebenen Ausnahmen und planen Sie anschließend die Produktivumstellung mit einer benannten verantwortlichen Person, Schritten zur Rücknahme und einem Vorgehen für bereits laufende Bestellungen.

Wenn Sie ein vorhandenes Modul konfigurieren und den vereinbarten Ablauf prüfen lassen möchten, deckt der PrestaShop Module Installation & Configuration Service diese klar abgegrenzte Einrichtung ab; Lizenzen, zusätzliche Module und Entwicklung sind separat.

Tägliche Bestellarbeit organisieren

Öffnen Sie Bestellungen > Bestellungen und filtern Sie die benötigten Vorgänge: zu prüfende unbezahlte Bestellungen, bezahlte Bestellungen zur Abwicklung oder Bestellungen mit Lieferproblemen. Nutzen Sie die in Ihrer Version verfügbaren Spalten und Filter. Wenn Ihre Version Filter in der URL speichert, testen Sie ein Lesezeichen für eine regelmäßig benötigte Warteschlange und prüfen Sie beim erneuten Öffnen den Datumsbereich. Kontrollieren Sie vor einer Massenaktion die ausgewählten Bestellungen.

Moderne Bestellseiten verwenden seit der Migration in PrestaShop 1.7.7 Symfony-Controller, Grids und Command-Handler. AdminOrders bleibt eine nützliche Legacy- und Berechtigungskennung, ist aber nicht in jeder Version der darstellende Controller.

Das native Massenaktionsmenü unterstützt Statuswechsel und Öffnen von Bestellungen in neuen Tabs. Ein Massenwechsel kann je Bestellung Dokumente erzeugen, Bestand aktualisieren und E-Mails senden. Testen Sie kleine Auswahlen und prüfen Sie Fehler vor großen Chargen.

Nutzen Sie Bestellungen > Rechnungen und Bestellungen > Lieferscheine für unterstützte PDF-Stapelerzeugung einschließlich Datumsauswahl. Erwarten Sie keine gemeinsame Rechnungsdruckaktion in jedem Bestelllistenmenü. Prüfen Sie Nummerierung, Dokumenttext, Steuerangaben und Druckzuordnung vor Übergabe ans Lager.

Nutzen Sie private Notizen für Telefonate, Packanweisungen, Prüfentscheidungen und Korrekturen. Prüfen Sie vor dem Senden einer Bestellnachricht, ob sie als privat oder öffentlich eingestellt ist. Halten Sie ausreichend Kontext fest, damit ein anderer Mitarbeiter die Arbeit fortsetzen kann: Entscheidung, zuständige Person, nächste Aktion und Zeitpunkt der erneuten Prüfung. Lassen Sie sensible Kundendaten aus Notizen weg, die diese nicht benötigen.

Eine wachsende Warteschlange wegen fehlender Ware erfordert möglicherweise eine bessere Nachbestellung oder Regeln für nicht verfügbare Artikel statt eines weiteren Status. Prüfen Sie Bestand, Lieferzeiten der Lieferanten und Vorbestellbedingungen zusammen mit der Bestellabwicklung. Der Leitfaden zur Bestandsverwaltung behandelt die Bestandsentscheidungen, die diese Warteschlange beeinflussen.

Bestellstatus und ihre Flags verstehen

Konfigurieren Sie moderne Bestellstatus unter Shop-Einstellungen > Bestellungen > Status. PrestaShop 1.6 verwendete Bestellungen > Status. Namen wie Vorbereitung oder In Prüfung definieren kein Verhalten; prüfen Sie die Flags.

Beim Beispielpräfix ps_ enthält ps_order_state die Flags, ps_order_state_lang die übersetzten Namen und E-Mail-Template-Namen, ps_orders.current_state den aktuellen Status und ps_order_history die normalen Übergänge. Nutzen Sie das tatsächliche Präfix Ihrer Installation.

Ändern Sie Status über unterstützte Bestellverwaltung oder Core-APIs. Direktes Aktualisieren von current_state umgeht übliche Historien-, Dokument-, E-Mail- und Bestandslogik. Eine Statusdefinition zu ändern ist nochmals etwas anderes: Es ändert die Definition künftiger Übergänge.

Einen konzeptionellen Ablauf beschreibt die Dokumentation zum Bestelllebenszyklus. Dokumentieren Sie zuständiges Team je Status und maßgebliches System für Zahlung und Versand.

Standardlebenszyklus vor Anpassungen prüfen

Bestehende Shops und Zahlungsmodule können Standards verändern. Die üblichen Installationsvorgaben bieten den folgenden Ausgangspunkt; vergleichen Sie sie mit Ihren eigenen Einstellungen.

Diese etablierten Standards stehen in den Installations-Statusdefinitionen. Zahlungsfehler ohne Bestellerstellung haben keine Bestellhistorie für Benachrichtigungen; Gateway-Verhalten ist separat.

Ein möglicher normaler Ablauf ist Warten auf Zahlung, Zahlungsbestätigung, Vorbereitung, Versand und Zustellung. Er wird nicht universell automatisch erzwungen. Ein Bezahlt-Flag ist eine Buchhaltungs-/Workflow-Entscheidung; nutzen Sie es nicht bequem zum Verschieben unbezahlter Bestellungen in die Lagerwarteschlange.

Erstellen Sie eigene Status nur für nützliche Entscheidungen: Warten auf Lieferanten, abholbereit, in Prüfung, Warten auf Kundenantwort, Retoure beantragt oder eingegangen. Vergeben Sie klare Namen und konsistente Farben und wählen Sie Flags unabhängig. Eine rein interne Bezeichnung sollte nicht mailen, nur weil ein ähnlich benannter Status das tut.

Verfolgen Sie bei B2B-Zahlungszielen Abwicklung getrennt vom Geldeinzug. Angebotsfreigabe, Bestellaufträge und Fälligkeiten benötigen einen definierten Ablauf; ein Status erzeugt kein Angebots- oder Kreditkontrollsystem. Setzen Sie Rechnungszeitpunkte nach Transaktion, Zahlungsbedingungen und geltenden Regeln, statt jede Rechnung erst nach Zahlung anzunehmen. Siehe den EU-Leitfaden zur VAT-Rechnungsstellung und Ihre nationalen Anforderungen.

Bezahlte Bestellung mit Adressprüfung durchspielen

Ein Kunde bezahlt einen vorrätigen Artikel und bittet den Support anschließend, die Lieferadresse vor dem Verpacken zu prüfen. Weisen Sie mit diesem Staging-Szenario nach, dass eine bezahlte Bestellung auf eine Aufgabe warten kann, ohne als unbezahlt oder versendet behandelt zu werden.

Setzen Sie die Sperre nicht durch zwischenzeitliche Wechsel zu Storniert oder Zahlungsfehler um: Diese Status wirken sich auf den Bestand aus. Legen Sie fest, wer eine Sperre aufheben darf und wie ein Versandlauf gesperrte Bestellungen ausschließt; eine interne Kennzeichnung allein beweist nicht, dass das Lager den Stopp beachtet.

Bestand und Geld konsistent halten

Verfügbarer Bestand wird bei aktiver Bestandsverwaltung normalerweise während der Bestellerstellung im Zahlungs-/Validierungsablauf reduziert. Der Wechsel einer gewöhnlichen auf Zahlung wartenden Bestellung zu Zahlung akzeptiert zieht diese Einheiten nicht erneut ab.

Übergänge mit Storniert oder Zahlungsfehler können Bestand wiederherstellen oder erneut abziehen. Wechsel zwischen versendet und nicht versendet beeinflussen ebenfalls Bestandsbewegungen. Packs, retournierte Mengen und Produkteinstellungen zählen. Testen Sie tatsächliche Übergänge statt jeden Status nur als Bezeichnung zu behandeln.

• Stornierung: Kann Bestand über den Statuswechsel beeinflussen, erstattet aber keine eingezogene Zahlung automatisch und löscht keine Rechnung.
• Direkte Mengenreduzierung oder Positionslöschung: Nutzt eigene Bestandsdifferenzbehandlung. Das ist nicht derselbe Vorgang wie die Wiedereinlagerungsoption einer Erstattung.
• Erstattung: Nutzen Sie den passenden Standard- oder Teilerstattungsablauf und entscheiden Sie über Gutschrift sowie Rückkehr in verkaufbaren Bestand.
• Wiederaufnahme nach Stornierung/Fehler: Bestätigen Sie Verfügbarkeit und Zahlung vor Rückkehr zu gültigem Status. Bestand kann erneut abgezogen werden.

Gleichen Sie Gateway-Transaktionen und gespeicherte Zahlungen ab. Bestellbetragsänderung oder Bezahlt-Status zieht kein zusätzliches Geld ein, und Erstattet beweist keine Gateway-Rückzahlung. Erfassen Sie tatsächlichen Einzug oder Erstattung samt Referenz und offenem Betrag.

Belassen Sie Testbestellungen mit Sandbox-Zahlungen und abgefangenen E-Mails im Staging. Löschen Sie keine echten Buchhaltungsdaten, um die produktive Bestellliste aufzuräumen. Für das gezielte Entfernen von Tests vor dem Start nutzen Sie die Hilfeseite zu Delete Orders und bewahren Sie erforderliche Aufzeichnungen auf.

Nützliche Status-E-Mails und Tracking senden

Wählen Sie Kundenmeldungen für relevante Ereignisse wie bestätigte Zahlung, wesentliche Verzögerung, Abholbereitschaft oder Versand. Eine Versandnachricht sollte korrekte Trackingdaten enthalten, eine Abholnachricht Ort, Öffnungszeiten und nötigen Identitätsnachweis.

1. Aktivieren Sie die Benachrichtigung des gewünschten Status und wählen Sie das Template der Kundensprache.
2. Prüfen Sie den Mailtyp. Zusammengehörige HTML-/TXT-Dateien ermöglichen beide Formate; Anforderungen hängen von der Mailkonfiguration ab.
3. Prüfen Sie Template-Auflösung über aktives Mail-/Shoptheme und Modul-Overrides. Dateien unter mails/ im Stammverzeichnis sind nicht der einzige mögliche Ort.
4. Nutzen Sie die Variablen dieses Benachrichtigungspfads. Testen Sie ausgegebenen Kundennamen, Bestellreferenz, Links, Tracking und Anhänge statt universelle Platzhalterverfügbarkeit anzunehmen.
5. Erstellen Sie eine Staging-Bestellung, wenden Sie den Übergang an und prüfen Sie abgefangene Post sowie Anwendungs-/Mailserverprotokolle. Ein Versandereignis beweist keine Posteingangszustellung.

Design > E-Mail-Theme verwaltet in unterstützten modernen Versionen den E-Mail-Designablauf. Halten Sie Übersetzungen und generierte Templates bei Anpassungen konsistent.

Tragen Sie Sendungsnummer und korrekte Versanddienst-URL vor Versandmeldung ein. Tracking speichern und zu Versendet wechseln sind im Core separate Aktionen; eine Integration kann eigene Tracking-E-Mails senden. Prüfen Sie Duplikate. Ein gedrucktes Etikett beweist kein Verlassen des Lagers.

Die native Aktion zum erneuten Senden in der Bestellhistorie versendet eine Status-E-Mail erneut. Sie ist von der ursprünglichen Bestätigung order_conf mit der Bestellübersicht getrennt. Für diesen speziellen Ablauf zum erneuten Versand nutzen Sie die Hilfeseite zu Resend Order Confirmation.

Nur überprüfbare Ereignisse automatisieren

Definieren Sie Ereignis und maßgebliche Quelle vor Automatisierung. Ein Zahlungs-Callback muss authentifiziert und zur richtigen Bestellung samt Betrag zugeordnet sein. Überweisung benötigt echten Abgleich. Ein Zustellereignis ist etwas anderes als Etikettenerstellung oder Sendungsnummerneingabe.

Mögliche eigene Anforderungen sind eine Bestandsprüfung nach Zahlung, das Zurückhalten hochwertiger Bestellungen zur Prüfung, das Kennzeichnen vollständig gepackter Bestellungen als übergabebereit oder die Stornierung unbezahlter Bestellungen nach einem definierten Zeitraum. Diese brauchen geeignete Integration und explizite Tests; eine Workflow-Erweiterung implementiert nicht automatisch jede Bedingung.

Für Verknüpfungen nativer Statuswechsel oder Aktualisierungen der Sendungsnummer mit internen Workflow-Status nutzen Sie die Hilfeseite zu Advanced Order Fulfilment; interne Status sind von nativen Bestellstatus getrennt und bieten keine beliebigen Bedingungen zu Zahlung, Betrag, Bestand oder Dauer ausstehender Zahlungen. Teams, zulässige Übergänge, Rollenberechtigungen und Erinnerungen organisieren die interne Zuständigkeit; vereinbaren Sie vor der Automatisierung, welche Warteschlange jedes Team bearbeitet.

Für Überweisungen importiert Bank Transfer Revolution Kontoauszüge in CAMT.053, MT940 oder CSV und ordnet passende Gutschriften geeigneten Bestellungen zu. Unklare Einträge bleiben zur Prüfung offen. Proben Sie einen Teileingang und eine nicht zuordenbare Referenz, bevor zugeordnete Eingänge Bestellungen als bezahlt markieren dürfen; einen Fehlbetrag zu akzeptieren ist eine andere Entscheidung als erhaltenes Geld zu erfassen.

Entwickler-Hooks für Übergänge

• actionOrderStatusUpdate läuft während des Übergangs. Behandeln Sie ihn als Benachrichtigungs-Hook, nicht als allgemeines Vetorecht.
• actionOrderStatusPostUpdate läuft nach Core-Statusaktualisierungen innerhalb von changeIdOrderState(). Das garantiert keinen Transaktions-Commit.
• actionOrderHistoryAddAfter folgt auf Einfügung des Historieneintrags. Im normalen setCurrentState()-Ablauf wird die Historie nach der Statusaktualisierung hinzugefügt.

Nutzen Sie unterstützte Bestelldienste oder die passende API Ihrer Version statt rohem SQL. Stellen Sie für externe Arbeit dauerhafte Aufgaben mit Idempotenzschlüssel und Wiederholungsrichtlinie in eine Queue. Ein Post-Update-Hook bedeutet nicht, dass alle späteren Vorgänge oder E-Mails erfolgreich waren. Behandeln Sie doppelte Callbacks, Teilfehler und vertauschte Ereignisreihenfolge.

Testen Sie, dass wiederholte Zahlungs- oder Zustellmeldungen keine doppelte Abwicklung, Zahlungen oder Nachrichten erzeugen. Alarmieren Sie bei Fehlern statt Bestellungen still zwischen Systemen hängen zu lassen.

Sendungen, Dokumente und Referenzen bearbeiten

Im etablierten Bestellmodell erfasst die Bezeichnung Teilweise versendet nicht, welche Positionen in welchem Paket enthalten sind. Dokumentieren Sie bei gelegentlicher Teillieferung die versendeten Artikel und Sendungsverfolgung je Versand, erläutern Sie die noch offenen Positionen und kennzeichnen Sie den Abschluss erst zum passenden Zeitpunkt. Enthält eine Bestellung eine verfügbare Tasse und ein nachzulieferndes Etui, ordnen Sie die Tasse ihrem Paket zu und lassen Sie das Etui ausdrücklich offen. Bietet Ihr installierter Shop keine Datensätze je Paket, erfassen Sie Artikel, Mengen und Sendungsverfolgung jedes Versands in privaten Bestellnotizen oder Ihrem Lagersystem und bewahren Sie die Angaben des ersten Versands auf, wenn das zweite Paket das Lager verlässt; das Überschreiben des ursprünglichen Sendungsverfolgungsfelds hebt diese Unterscheidung auf. Prüfen Sie, dass das Packdokument jedes Pakets nur dessen Inhalt aufführt: Ein Lieferschein für die gesamte Bestellung kann auch noch offene Artikel enthalten.

PrestaShop 9.1 führte eine Versandfunktion hinter einem experimentellen Flag ein. Prüfen Sie Version, aktive Funktionen und Versandintegration, bevor Sie alte Einschränkungen oder volle Sendungsunterstützung annehmen. Testen Sie bei geändertem Versandablauf Paketpositionen, Tracking, Dokumente und Zahlungsmodulkompatibilität. Siehe die Versandänderungen in 9.1.

Rechnungsnummern und für Kunden sichtbare Bestellreferenzen sind unterschiedliche Kennungen. Der Core liefert fortlaufende Rechnungsnummern. Die Standard-Bestellreferenz nutzt als Rückfall neun alphabetische Großbuchstaben, abhängig von Referenz-Hooks oder Modulen. Eine Referenz wie ORD-2026-00142 ist ein individuelles Format, kein Standardzufallsgenerator.

Wählen Sie Nummerierungs- und Korrekturverfahren entsprechend Ihren Buchhaltungsanforderungen. Eine Erweiterung zur Formatierung kann die Einhaltung der Vorschriften nicht für jeden Rechtsraum gewährleisten. Für Formatierungsoptionen nutzen Sie die Hilfeseite zu Custom Invoice Numbering oder die Hilfeseite zu Custom Order Numbering.

Definieren Sie bei Bestell-/Rechnungsexporten Datumsbasis, berücksichtigte Status, Steuern, Erstattungen und Kodierung und gleichen Sie Summen mit der Buchhaltungsperiode ab. Siehe den Leitfaden zu Buchhaltung und Rechnungen.

Aufgegebene Bestellungen gezielt korrigieren

Öffnen Sie die einzelne Bestellung unter Bestellungen > Bestellungen. Prüfen Sie zuerst Mitarbeiterberechtigung, Zahlung, Abwicklung, Erstattungen und Dokumente. Es gibt kein universelles Kontrollkästchen für bearbeitbare Status. Native Positionspreisbearbeitung bestand vor 1.7.6; genaue Aktionen und Lebenszyklusprüfungen variieren nach Version.

Beim Größenwechsel von M zu L handelt es sich um unterschiedliche Produktvarianten mit jeweils eigenem Bestand und eigener Referenz. Ohne direkten Austausch entfernen Sie die alte Position, ergänzen die korrekte Variante und gleichen Bestand, Preise und Zahlungen ab. Setzen Sie keine einzelne Austauschfunktion einer Editor-Erweiterung voraus.

Core-Bearbeitung kann bestehende Rechnungsbeträge aktualisieren und später neu erzeugte PDFs verändern. Eine bestehende Rechnung ist keine universelle technische Bearbeitungssperre. Bestimmen Sie rechtmäßiges Gutschrift-/Korrekturverfahren vor Änderung ausgestellter Dokumente und erhalten Sie erforderliche Originale. Historie zugestellter Bestellungen kann strengere native Produktbearbeitungsgrenzen bewirken.

Für unterstützte Bestelländerungen nutzen Sie die Hilfeseite zu Order Editor; prüfen Sie vor der Bestätigung die Vorschau des Vorgangs und seine Auswirkungen auf Bestand, Steuern, Rabatte, Zahlung und Rechnung. Aktivieren Sie nur die von Mitarbeitern benötigten Vorgangsarten, verlangen Sie einen Korrekturgrund und bewahren Sie den Verlauf mit ursprünglichen und geänderten Werten auf.

1. Dokumentieren Sie den Kundenwunsch und aktuelle Bestellbeträge.
2. Nutzen Sie für eine zulässige Adress- oder Mengenkorrektur vor dem Versand die unterstützte Bearbeitung. Vergleichen Sie bei einem wesentlich anderen Warenkorb die Bearbeitung mit Stornierung und Neubestellung, einschließlich Bestand, möglicher Erstattung und Korrekturen ausgestellter Dokumente, und bearbeiten Sie versendete Ware über den Retouren- oder Ersatzablauf. Umgehen Sie Beschränkungen für zugestellte Bestellungen nicht durch Umbenennen ihres Status.
3. Wenden Sie die unterstützte Aktion an und vergleichen Sie Mengen, verfügbaren Bestand, Steuerdaten, Rabatte, Versand und Rechnungssummen.
4. Ziehen Sie die Differenz über den passenden Zahlungsweg ein oder erstatten Sie sie und erfassen Sie die Transaktion.
5. Teilen Sie dem Kunden genaue Änderung, neue Summe und Zahlungs-/Erstattungsfolgen mit. Stellen Sie passende korrigierte Dokumente oder Bestätigung bereit.

Routinemäßige Adresskorrekturen durch Kunden begrenzen

Order Address Change: Customer Self-Service ermöglicht angemeldeten Kunden, innerhalb konfigurierter Status-, Zeit- und Versandbeschränkungen eine andere Adresse aus ihrem eigenen Adressbuch auszuwählen. Produkte, Zahlung, Versanddienstleister, Preise, Steuern, Versandkosten und Gesamtsummen bleiben unverändert. Ausgestellte Rechnungen sperren beide erfassten Adressen; Sendungsverfolgung oder Versandfortschritt schließen Lieferadressänderungen aus, und aufgeteilte Bestellungen oder mehrere Sendungen liegen außerhalb dieses Ablaufs.

Testen Sie die Kundenfunktionen im aktiven Theme. Ein geändertes Lieferziel, das eine andere steuerliche Behandlung, einen anderen Versanddienstleister oder Lieferpreis erfordert, gehört in die Hände Ihrer Mitarbeiter. Diese müssen die Auswirkungen prüfen, statt die Selbstbedienungsfunktion zur Neuberechnung des Verkaufs zu verwenden.

Korrektur vor dem Verpacken proben

Ein Kunde wünscht nach der Zahlung ein zusätzliches passendes Zubehörteil, solange die Bestellung noch bearbeitet werden darf. Pausieren Sie die Kommissionierung, dokumentieren Sie ursprüngliche Mengen und Gesamtsumme, fügen Sie das richtige Produkt über den unterstützten Editor hinzu und vergleichen Sie dann Bestand, Rabatte, Steuern und die neue Gesamtsumme. Ziehen Sie den Restbetrag über den Zahlungsablauf ein und erfassen Sie ihn, bevor Sie die Bestellung zu den vereinbarten Bedingungen freigeben. Bestätigen Sie, dass das Lager die aktualisierten Positionen erhält und der Kunde die passende Mitteilung und Dokumente bekommt.

Erhalten Sie bei Teilversand die versandten Positionen und behandeln Sie Restartikel oder Retouren explizit. Eine Stornierung allein macht weder Zahlungen noch ausgestellte Dokumente rückgängig. Bessere Größeninformationen, Adressprüfungen und klare Abschlussübersicht können spätere Korrekturanfragen reduzieren.

Ablauf testen und prüfen

Erstellen Sie eine kurze Mitarbeiterreferenz: Statusbedeutung, Verantwortlicher, Eintrittsbedingung, Benachrichtigung und nächste Aktion. Halten Sie die Liste konsistent nutzbar, ohne eine feste Statuszahl vorzuschreiben.

Testen Sie auf Staging jede Zahlungsart, normale Abwicklung, Zahlungsfehler vor/nach Bestellerstellung, Stornierung, Wiederaufnahme, Teilerstattung, Wiedereinlagerung, Adress- und Positionsänderung. Erfassen Sie Historie, E-Mails, Zahlungen, Bestand und Dokumente vor/nach jeder Aktion.

Fehler vor dem nächsten Verarbeitungslauf erkennen

Umstellung und Übergabe an Mitarbeiter planen

1. Listen Sie jede Integration auf, die einen Status liest oder schreibt, einschließlich geplanter Aufgaben. Dokumentieren Sie die tatsächlichen Status-IDs und Zuordnungen, nicht nur übersetzte Namen.
2. Vereinbaren Sie, wie Bestellungen ihren laufenden Ablauf abschließen, wenn sie bereits auf Zahlung warten, gesperrt, teilweise versendet oder in Erstattung sind.
3. Bewahren Sie einen wiederherstellbaren Konfigurationsstand und ein Backup mit getesteter Wiederherstellung auf. Stimmen Sie die Umstellung auf die Lageraktivitäten ab und benennen Sie die Person, die die Verarbeitung stoppen darf.
4. Übernehmen Sie die erprobten Einstellungen, prüfen Sie repräsentative produktive Bestellungen und beobachten Sie die nächsten Integrations- und Versandläufe. Wenn Sie eine Einstellung zurücknehmen, gleichen Sie bereits entstandene Auswirkungen ab: Versendete E-Mails, Bestandsbewegungen, ausgestellte Dokumente und externe Aufgaben verschwinden dadurch nicht.

Fragen an Ihren Entwickler oder Ihre Agentur

• Welche genaue Shopinstallation, Modulversionen, welches Theme und welche Integrationszuordnungen wurden getestet, und wo liegen die Nachweise?
• Welches System ist für Entscheidungen zu Zahlung, Sperren, Versand und Zustellung maßgeblich, und wer bearbeitet Ausnahmen?
• Wie erreichen Wiederholungsversuche, teilweise fehlgeschlagene Vorgänge und Korrekturen das Lager ohne doppelte Arbeit oder veraltete Daten?
• Welche Vorgänge darf jeder Mitarbeiter ausführen, und wo werden Gründe sowie Vorher-Nachher-Aufzeichnungen aufbewahrt?
• Was passiert bei der Umstellung mit offenen Bestellungen, und welche Auswirkungen müssen wir bei einer Rücknahme abgleichen?

Aktualisieren Sie anhand der Ergebnisse die Mitarbeiterdokumentation, bevor der neue Ablauf zur Routine wird.

Berechnen Sie mit Historienzeitstempeln Zeit bis Versand, Bestandswartezeit und Stornierungen nach Phase. Definieren Sie Zählung wiederholter Status und wiederaufgenommener Bestellungen. Eine Statusverteilung zeigt eine Warteschlange, erklärt aber nicht selbst deren Ursache.

Prüfen Sie fehlgeschlagene Übergänge, fehlendes Tracking, Dokumentdifferenzen und Kundenfragen regelmäßig. Passen Sie Prozess und Integration gemeinsam an, damit Status echte Arbeit sinnvoll beschreiben.

Fragen von Shopbetreibern

Soll ich einen Status umbenennen oder einen neuen erstellen?

Benennen Sie ihn um, wenn Bedeutung und Verhalten gleich bleiben, und prüfen Sie dabei jede Shopsprache und jede Integration, die Namen abgleicht. Ändert sich die Bedeutung, prüfen Sie zunächst einen separaten Status, damit historische Einträge nicht irreführend werden. Dokumentieren Sie die ursprünglichen Namen und Zuordnungen.

Kann ich alte Status entfernen, sobald der Ersatz bereitsteht?

Prüfen Sie zuerst offene Bestellungen, Historie, Einstellungen der Zahlungsmodule und Integrationszuordnungen. Unterbinden Sie die neue Verwendung über den vereinbarten Ablauf und lassen Sie bestehende Vorgänge abschließen, bevor Sie eine Entfernung erwägen; ein Status, der heute in keiner Warteschlange auftaucht, kann an anderer Stelle weiterhin referenziert sein.

Wer sollte Bestellungen korrigieren dürfen?

Geben Sie Mitarbeitern individuelle Konten und Berechtigungen für ihre zugewiesenen Aufgaben. Beschränken Sie Preisänderungen, Zahlungserfassung, Erstattungen und routinemäßige Adresskorrekturen auf die vereinbarten Rollen und testen Sie, dass eingeschränkte Benutzer diese Vorgänge nicht ausführen können. Ein Statusname ist keine Zugriffskontrolle.