Bestellstau nach Aktionstagen: Mehrfachänderung in Shopware

Für Black Friday und Cyber Monday 2025 rechnete der Handelsverband Deutschland mit einem Umsatz von 5,8 Milliarden Euro (HDE). Für den Shop heißt das: Nach den Aktionstagen steht eine lange Liste von Bestellungen, die als bezahlt oder versandt markiert, mit Rechnung und Lieferschein versehen und den Kunden gemeldet werden müssen. Die Mehrfachänderung in Shopware erledigt das direkt in der Administration, für bis zu 1.000 Bestellungen je Auswahl (Shopware-Dokumentation). Sie hat aber Eigenheiten, die in der Spitze teuer werden: Flows können doppelt laufen, Statusmails gehen in großer Zahl hinaus, und Belege kommen als ein zusammengeführtes PDF. Dieser Leitfaden zeigt die Abfolge von Filter bis Beleg, die Entscheidung über Flows und Mails und die Grenze, ab der eine Statusrückmeldung aus dem ERP oder ein Lauf über die Admin-API sinnvoller ist. Er ist als Vorbereitung gedacht: Wer die Abläufe vor der Black Week in einer Testumgebung durchspielt, muss sie am Tag danach nicht unter Zeitdruck lernen. Bei Einrichtung und Test unterstützt unsere Shopware-Agentur.

Warum sich nach Aktionstagen Bestellungen stauen

Aktionstage verdichten den Bestelleingang auf wenige Tage, und ein großer Teil dieser Bestellungen hat eine Frist, die der Shop nicht selbst setzt. Laut Verbandsprognose entfielen 2025 rund 1,6 Milliarden Euro der Ausgaben an Black Friday und Cyber Monday auf Weihnachtseinkäufe (HDE). Wer an diesen Tagen ein Geschenk bestellt, erwartet die Ware vor dem Fest und eine Nachricht, sobald sie unterwegs ist. Die Arbeit verlagert sich damit vom Verkauf in die Abwicklung: Zahlungseingänge zuordnen, Lieferscheine drucken, Pakete übergeben, Status setzen, Rechnungen erzeugen und verschicken.

In vielen Shops läuft ein Teil davon automatisch, etwa über eine Zahlungsart, die den Zahlungsstatus selbst meldet, oder über eine Warenwirtschaft, die den Versand zurückmeldet. Ein anderer Teil bleibt Handarbeit in der Administration: Vorkasse-Zahlungen, die nach dem Kontoabgleich als bezahlt markiert werden, der Sammelversand am Nachmittag, die Stornierung unbezahlter Bestellungen nach Ablauf der Zahlungsfrist. Solange es wenige Bestellungen am Tag sind, reicht die Detailansicht. Bei einer Spitze nach Aktionstagen wird dieselbe Handarbeit zum Engpass, und genau dafür ist die Mehrfachänderung gedacht.

Wie der Shop die Lastspitze selbst übersteht, behandelt unser Beitrag zum Warteraum für den Black Friday. Hier geht es um die Tage danach, wenn die Bestellungen da sind und in geordneter Reihenfolge abgearbeitet werden müssen, ohne dass Kunden doppelte Mails oder fehlende Rechnungen erhalten.

Was die Mehrfachänderung in Shopware kann

Die Mehrfachänderung sitzt in der Bestellübersicht der Administration. Die Dokumentation beschreibt sie als einfache und schnelle Möglichkeit, mehrere Bestellungen gleichzeitig zu ändern (Shopware-Dokumentation). Beschrieben ist sie dort ab der Fassung für Shopware 6.4.5.0; die Fassung für 6.4.0.0 bis 6.4.4.1 enthält den Abschnitt noch nicht (Shopware-Dokumentation). Ihr Quelltext liegt im quelloffenen Kern der Administration, sie steht also ohne zusätzliche Erweiterung zur Verfügung (Shopware-Quelltext). Im Kern deckt sie drei Arbeitsschritte ab:

Daneben setzt dieselbe Maske laut Quelltext auch Tags für die ausgewählten Bestellungen (Shopware-Quelltext). Das ist nach Aktionstagen nützlicher, als es klingt: Ein Tag wie „Black Week“ markiert einen Stapel, und die Bestellübersicht filtert danach. Was die Mehrfachänderung nicht abdeckt, steht ebenfalls in der Dokumentation, nur an anderer Stelle: Sendungsnummern trägt das Team in den Bestelldetails im Bereich Versand ein, Positionen und Lieferadresse ändert es je Bestellung (Shopware-Dokumentation). Für Bestellungen, die das Team selbst anlegt, etwa nach einem Anruf, gilt der Weg aus unserem Beitrag zu Telefon- und Mailbestellungen im Shopware-Admin.

Die Abfolge: Filter, Auswahl, Status, Belege

Die Reihenfolge der Schritte ist nicht beliebig. Wer zuerst Belege erzeugt und dann den Status mit Mailversand setzt, verschickt andere Anhänge als umgekehrt, und wer eine gemischte Auswahl öffnet, findet im Statusfeld weniger Optionen als erwartet. Als Arbeitsreihenfolge empfiehlt sich diese Abfolge:

1. Filtern: Bestelldatum auf den Aktionszeitraum, dazu Zahlungs- und Lieferstatus, Zahlungsart, Versandart oder Verkaufskanal. Der Filter bestimmt, welche Bestellungen überhaupt in die Auswahl kommen.
2. Auswählen: einzelne Bestellungen oder alle auf der Seite, bei Bedarf über mehrere Seiten. Den Zähler über der Liste mit der erwarteten Menge abgleichen.
3. Mehrfachänderung öffnen: Das Pop-up zeigt die Auswahl noch einmal. Ausreißer lassen sich hier entfernen, bevor etwas geändert wird.
4. Status wählen: nur die Statusart ändern, um die es in diesem Durchgang geht, etwa den Lieferstatus „Versandt“.
5. Mails entscheiden: Status-E-Mails ein- oder ausschalten und festlegen, ob vorhandene Belege angehängt werden.
6. Belege erzeugen: Rechnung oder Lieferschein mit Datum und optionalem Kommentar; bereits vorhandene Belege werden nicht erneut erstellt.
7. Anwenden: Das Pop-up nennt die Zahl der Bestellungen, die geändert werden. Hier fällt auch die Entscheidung über „Flows auslösen“.
8. Herunterladen und prüfen: das zusammengeführte PDF laden und mit einem Filter auf Bestellungen ohne Dokumente gegenprüfen, ob jede Bestellung ihren Beleg hat.

Filtern und auswählen, ohne die Grenze zu reißen

Der Filter der Bestellübersicht ist das eigentliche Werkzeug der Mehrfachänderung. Er kombiniert unter anderem Bestelldatum, Bestellstatus, Zahlungsstatus, Lieferstatus, Zahlungsart, Versandart, Verkaufskanal, Tags, Produkte und die Frage, ob schon Dokumente an der Bestellung hängen; jede weitere Angabe verkleinert die Liste (Shopware-Dokumentation). Wer nach Aktionstagen versandte Pakete abhaken will, filtert also nicht auf „alle Bestellungen der Woche“, sondern auf bezahlte Bestellungen mit offenem Lieferstatus aus dem Aktionszeitraum und einer bestimmten Versandart.

Ausgewählt wird per Checkbox: einzelne Bestellungen oder alle auf der aktuellen Seite, und die Auswahl lässt sich über mehrere Seiten fortsetzen. Höchstens 1.000 Bestellungen lassen sich auf einmal auswählen (Shopware-Dokumentation). Die Zahl der ausgewählten Bestellungen steht über der Liste, und sobald Bestellungen von mehreren Seiten gewählt sind, erscheint die Option, die ganze Auswahl wieder aufzuheben (Shopware-Dokumentation). Liegt der Stapel über der Grenze, wird er geteilt, sinnvollerweise entlang eines Filters wie Versandart oder Bestelldatum, damit sich später nachvollziehen lässt, welcher Durchgang welche Bestellungen betraf. Hilfreich ist dafür der Tag aus dem vorigen Abschnitt: Wer jeden bearbeiteten Stapel markiert, sieht im Filter sofort, was noch offen ist.

Statusübergänge: welcher Status für die Auswahl zulässig ist

Eine Bestellung in Shopware trägt drei Status: den Bestellstatus, den Status der Zahlung und den Status der Lieferung (Shopware-Entwicklerdokumentation). Zwischen den Werten springt man nicht beliebig hin und her. Die Statusmaschine erlaubt nur festgelegte Übergänge; eine Zahlung lässt sich zum Beispiel nicht auf „Erstattet“ setzen, solange sie nicht bezahlt war (Shopware-Entwicklerdokumentation). Für die Mehrfachänderung hat das eine praktische Folge, die auf den ersten Blick wie ein Fehler aussieht.

In der Mehrfachänderung lässt sich der Bestellstatus nur auf einen Wert ändern, der für alle ausgewählten Bestellungen gültig ist. Die Dokumentation nennt das Beispiel selbst: Eine offene Bestellung kann auf „In Bearbeitung“ oder „Abgebrochen“ wechseln, eine Bestellung in Bearbeitung auf „Abgeschlossen“ oder „Abgebrochen“. Wählt man beide zusammen aus, bleibt nur „Abgebrochen“ übrig (Shopware-Dokumentation). Wer also im Statusfeld den erwarteten Wert vermisst, hat in der Regel eine gemischte Auswahl. Abhilfe schafft der Filter auf den aktuellen Status, bevor ausgewählt wird.

Statusmails und Flows: doppelte Auslösung vermeiden

Zwei Schalter entscheiden, was eine Mehrfachänderung außerhalb der Datenbank bewirkt. Der erste heißt in der Maske „Status-E-Mails“: Sobald mindestens ein Status geändert wird, legt er fest, ob Kunden eine Mail über die Änderung erhalten. Ist er aus, werden laut Dokumentation grundsätzlich keine Mails versendet, auch nicht über einen Flow, der durch den Statuswechsel ausgelöst wird und trotzdem laufen kann (Shopware-Dokumentation). Der Schalter wirkt also auf Mails, nicht auf die übrigen Aktionen eines Flows.

Der zweite Schalter heißt „Flows auslösen“ und steht beim Anwenden der Änderungen. Die Dokumentation begründet ihn mit einem Verhalten, das in der Spitze teuer wird: Werden bei der Mehrfachänderung Status-E-Mails verschickt, können alle im Flow Builder angelegten Trigger für alle Änderungen ausgeführt werden.

Dies kann unter Umständen dazu führen, dass Flows doppelt ausgeführt werden.

Shopware-Dokumentation, Bestellungen: Übersicht, Abschnitt Flows auslösen

Im Quelltext der Administration ist zu sehen, wie der Schalter wirkt: Ist er aus, schickt die Mehrfachänderung jeden Statuswechsel mit der Kopfzeile sw-skip-trigger-flow, und die Flows für diese Wechsel laufen nicht (Shopware-Quelltext). Ob das gewünscht ist, hängt davon ab, was an den Triggern hängt. Ein Flow auf „Lieferung wechselt zu Versandt“ kann eine Versandmail senden, einen Beleg erzeugen, einen Tag setzen oder einen weiteren Status zuweisen (Shopware-Dokumentation). Wer Flows abschaltet, schaltet all das ab, nicht nur die Mail. Was der Flow Builder sonst leistet, fasst unser Beitrag zum Shopware Flow Builder zusammen.

• Trigger erfassen: Welche Flows hängen an den Triggern für die Status, die nach Aktionstagen gesetzt werden, etwa Zahlung „Bezahlt“, Lieferung „Versandt“, Bestellung „Abgeschlossen“?
• Aktionen lesen: Senden diese Flows Mails, erzeugen sie Dokumente, setzen sie Tags oder rufen sie eine Adresse außerhalb des Shops auf?
• Doppelte Wege finden: Schickt ein Flow dieselbe Information, die auch der Schalter „Status-E-Mails“ verschickt? Dann erhält der Kunde zwei Mails oder zwei Anhänge.
• Reihenfolge festlegen: Bei mehreren Flows auf demselben Trigger bestimmt die Priorität, welcher zuerst läuft (Shopware-Dokumentation).
• Entscheidung notieren: Je Durchgang festhalten, ob Status-E-Mails und Flows an oder aus waren. Das spart später die Suche, warum ein Kunde keine Versandmail bekam.

Auch die Menge der Mails gehört in die Vorbereitung. Laut Entwicklerdokumentation versendet Shopware Mails standardmäßig synchron; per Konfiguration lassen sie sich über die Message Queue schicken (Shopware-Entwicklerdokumentation). Wer nach Aktionstagen eine große Zahl von Statusmails in einem Durchgang auslöst, sollte vorher wissen, welcher Weg im eigenen Shop aktiv ist und ob die Worker im Hintergrund laufen. Unser Beitrag zur Message Queue im Produktivbetrieb beschreibt die Einrichtung. Wie die Mails selbst aufgebaut sein sollten, steht im Beitrag zu Transaktionsmails und Bestellbestätigung.

Belege in Serie: Rechnung, Lieferschein, Sammel-PDF

Für Rechnung, Stornorechnung, Lieferschein und Gutschrift kann die Mehrfachänderung Dokumente für die ganze Auswahl erzeugen, auch mehrere Dokumentarten auf einmal. Existiert ein Dokument schon, legt die Mehrfachänderung es nicht noch einmal an (Shopware-Dokumentation). Für eine Rechnung ist ein Datum Pflicht, ein Kommentar optional, und der zugehörige Nummernkreis zählt automatisch weiter. Die Stornorechnung übernimmt die Nummer der letzten Referenzrechnung, die Gutschrift entsteht nur, wenn die Bestellung eine Gutschriftposition enthält (Shopware-Dokumentation).

Zum Drucken bietet die Maske einen Download: Die einzelnen Dokumente werden in einer zusammengeführten PDF-Datei bereitgestellt, und dafür müssen nicht einmal neue Dokumente erzeugt werden; verwendet werden die jeweils aktuellsten Belege der Bestellungen (Shopware-Dokumentation). Das Sammel-PDF ist eine Arbeitsdatei für den Packtisch. Die Belege selbst bleiben an der jeweiligen Bestellung; versendete Belege sieht der Kunde zusätzlich in seinem Konto, sofern die Dokumentvorlage das vorsieht (Shopware-Dokumentation).

Beim Versand der Belege mit der Status-Mail gilt eine Eigenheit: Vorhandene Belege gehen automatisch als Anhang mit, aber es wird nur der jeweils aktuellste verwendet. Wer per Mehrfachänderung einen Beleg erzeugt, verschickt genau diesen, unabhängig davon, ob es schon einen anderen gibt (Shopware-Dokumentation). Die Option „Bereits versendete Dokumente überspringen“ verhindert, dass Kunden denselben Beleg zweimal erhalten. Wer Rechnungen als E-Rechnung im ZUGFeRD-Format ausgibt, findet die Einstellungen dazu im Beitrag ZUGFeRD direkt aus Shopware.

Grenzen: wann ERP-Rückmeldung oder Admin-API besser passen

Die Mehrfachänderung ist ein Werkzeug für Menschen: Jemand filtert, wählt aus, entscheidet über Mails und Flows und klickt auf Anwenden. Das passt zu gelegentlichen Sammelschritten. Es passt schlechter, wenn dieselben Schritte jeden Tag in großer Menge anfallen, wenn der Stapel deutlich über 1.000 Bestellungen liegt (Shopware-Dokumentation) oder wenn jede Bestellung eine eigene Information braucht, die nur ein anderes System kennt, allen voran die Sendungsnummer.

Kommt der Versand aus einer Warenwirtschaft, ist die Rückmeldung von dort in der Regel der bessere Weg: Das ERP kennt Paket, Sendungsnummer und Versandzeitpunkt und kann den Lieferstatus je Bestellung setzen, sobald das Paket das Lager verlässt. Die Mehrfachänderung bleibt dann für Ausnahmen. Wie solche Anbindungen aufgebaut sind, zeigen unsere Seiten zu ERP- und Shop-Schnittstellen, zur Anbindung von Versanddienstleistern und zur JTL-Wawi-Integration.

Ein Lauf über die Admin-API passt, wenn Bestellungen nach festen Regeln geändert werden sollen, die keine Warenwirtschaft liefert, etwa eine Korrektur nach einem Fehler in einer Zahlungsanbindung. Für Massenimporte über die Sync-API beschreibt die Entwicklerdokumentation die Kopfzeile sw-skip-trigger-flow, damit beim Import keine Flows und damit keine Mails ausgelöst werden (Shopware-Entwicklerdokumentation). Dieselbe Kopfzeile setzt die Administration, wenn „Flows auslösen“ aus ist (Shopware-Quelltext). Wer Daten aus dem ERP dauerhaft in den Shop holt, findet einen verwandten Fall im Beitrag zu Bestandskunden aus dem ERP.

Vor der Black Week: Checkliste für die Abwicklung

Die Mehrfachänderung lässt sich nach Aktionstagen nicht mehr in Ruhe kennenlernen. Was sich vorher klären lässt, gehört deshalb in die Wochen davor. Die folgende Liste ist so angelegt, dass sie in einer Testumgebung mit Kopien der Shop-Einstellungen abgearbeitet werden kann, ohne echte Kundendaten zu nutzen.

• Testumgebung mit aktuellem Stand und ohne echte Kundendaten bereitstellen, wie im Beitrag zum Shopware-Staging ohne Kundendaten beschrieben.
• Flows an den Triggern für Zahlung, Lieferung und Bestellung erfassen und ihre Aktionen notieren.
• Je Statusart entscheiden: Status-E-Mails an oder aus, Flows auslösen ja oder nein.
• Mail-Vorlagen je Verkaufskanal prüfen; ist dem Verkaufskanal noch keine passende Vorlage zugewiesen, fragt schon die Statusänderung in den Bestelldetails zuerst nach einer Zuweisung (Shopware-Dokumentation).
• Nummernkreise für Rechnung, Lieferschein und Stornorechnung kontrollieren, bevor der erste Stapel erzeugt wird.
• Einen Probelauf mit einer kleinen Auswahl fahren und Mails, Anhänge, Tags und Belege an jeder Bestellung prüfen.
• Message Queue und Worker im Produktivbetrieb kontrollieren, damit Mails und Dokumente nicht im Rückstau hängen.
• Festlegen, welches System den Status führt: Warenwirtschaft oder Administration. Doppelte Pflege führt zu doppelten Mails.

Zur Vorbereitung gehört auch die Frage, was passiert, wenn an den Aktionstagen selbst etwas klemmt. Lasttest und Notfallplan behandelt der Beitrag zu Peak Season, Lasttest und Notfallplan. Die Checkliste oben ergänzt ihn um die Tage danach.

So unterstützen wir die Vorbereitung

Wir richten Shopware-Shops für Bestellspitzen ein und begleiten die Abwicklung danach. Für die Mehrfachänderung heißt das vor allem: die bestehenden Flows lesen, Entscheidungen festhalten und die Abläufe testen, bevor sie gebraucht werden.

Die Abwicklung planen, bevor die Bestellungen kommen

Die Mehrfachänderung nimmt dem Team nach Aktionstagen viel Klickarbeit ab, und sie ist im Kern von Shopware enthalten. Ihre Fallen liegen nicht in der Bedienung, sondern in dem, was ein Statuswechsel nebenbei auslöst: Mails, Flows, Belege und Nummernkreise. Wer diese Wirkungen vor der Black Week in einer Testumgebung prüft, die Grenze von 1.000 Bestellungen je Auswahl einplant (Shopware-Dokumentation) und für dauerhaft große Mengen eine Rückmeldung aus der Warenwirtschaft vorsieht, arbeitet den Bestellstau nach den Aktionstagen in geordneten Durchgängen ab.