Mehrlagerverwaltung in PrestaShop: Versand aus mehreren Standorten

Sobald Sie einen zweiten Versandstandort hinzufügen, entscheidet eine Frage darüber, ob die Mehrlagerverwaltung Ihnen hilft oder schadet: Wenn eine Bestellung eingeht, welches Lager erfüllt sie, und spiegelt der Versandpreis, den der Kunde sieht, diesen Ursprung wider? Wenn diese Weiterleitung stimmt, versenden Sie schneller und günstiger vom Standort, der dem jeweiligen Kunden am nächsten liegt. Wenn sie nicht stimmt, berechnen Sie einen Tarif von Hamburg nach Paris für ein Paket, das tatsächlich aus Barcelona verschickt wird, oder verkaufen ein Produkt zu viel, das nur noch in einem Ihrer beiden Lager vorhanden ist. Dieser Beitrag behandelt gezielt, wie PrestaShop Lager, Bestände und Versanddienst-Ursprünge abbildet. Was der Core tatsächlich bietet, wo seine Grenzen liegen und wie Sie Auftragsrouting und ursprungsbasierte Versandkosten sauber steuern.

Es ist kein allgemeiner Essay darüber, ob Sie expandieren sollten. Die operativen Gründe für mehrere Standorte (Geografie, Nähe zu Lieferanten, Risikostreuung) sind real, aber bekannt; woran Händler scheitern, sind die PrestaShop-Mechaniken. Genau darum geht es hier.

Was PrestaShop unter Mehrlagerverwaltung versteht: Advanced Stock Management

Die native Multi-Standort-Funktion von PrestaShop heißt Advanced Stock Management (ASM). Sie ist standardmäßig nicht aktiviert. In PrestaShop 1.6 aktivieren Sie sie unter Advanced Parameters → Configuration (die Konfigurationsvariable PS_ADVANCED_STOCK_MANAGEMENT); anschließend entscheidet ein produktbezogener Schalter im Produkt-Tab Quantities, ob dieses Produkt ASM oder die einfache Bestandsverwaltung nutzt. Nach der Aktivierung erscheint ein Menü Stock mit Warehouses, Stock Management, Stock Movements und Stock Coverage.

Wichtig, bevor Sie darauf etwas aufbauen: Das lagerbasierte ASM wurde in PrestaShop 1.7.0 aus dem Core-Backoffice entfernt. PrestaShop 1.7.2 führte wieder eine vereinfachte Bestandsverwaltungsseite für einen einzelnen Standort ein (Bestandsbewegungen, Warnungen bei niedrigem Bestand), aber nicht das Mehrlagermodell mit Standortbeständen und Versanddienst-Sets, um das es in diesem Beitrag geht. Frische Installationen von 1.7 / 8.x / 9.x enthalten daher keine native Mehrlageroberfläche. Einige der alten ASM-Datenbanktabellen und Klassen können im Codebestand noch vorhanden sein, insbesondere bei Shops, die von 1.6 aktualisiert wurden. Aber die Lagerfunktion wird nicht mehr als erstklassiger Bestandteil des Cores angezeigt oder gepflegt. Ein modernes Lagermodul nutzt daher ebenso wahrscheinlich ein eigenes Bestands- und Standort-Schema, statt auf diesen Legacy-Interna aufzubauen. Wenn Sie mit einer modernen, sauberen Installation arbeiten und Lagerrouting benötigen, entscheiden Sie sich von Anfang an für ein Modul oder individuellen Code, nicht für das Aktivieren einer Core-Einstellung. Darauf kommen wir zurück; zunächst aber dazu, was das native Modell tatsächlich macht, weil seine Datenstrukturen weiterhin eine hilfreiche Referenz dafür sind, wie Module dasselbe Problem häufig abbilden.

Wie das Lagermodell unter der Haube verdrahtet ist

Die beweglichen Teile zu kennen spart Ihnen Stunden, wenn Bestandszahlen nicht übereinstimmen, denn PrestaShop trennt bewusst „was physisch in einem Lager liegt“ von „was ein Kunde kaufen darf“. Die Bestandteile:

• Lager (die Klasse Warehouse, Tabelle ps_warehouse), ein benannter Standort mit Adresse, Bewertungsmethode (WA / FIFO / LIFO) und zugeordnetem Versanddienst-Set.
• Produkt-Lager-Zuordnung (WarehouseProductLocation, ps_warehouse_product_location). Welche Produkte (und Kombinationen) in welchem Lager liegen, optional mit Gang-/Regalplatz als Textangabe.
• Physischer Bestand (ps_stock), der tatsächliche Bestand pro Lager und Produkt, geschrieben über Bestandsbewegungen.
• Bestandsbewegungen (ps_stock_mvt), der Audit-Trail: jede Erhöhung, Verringerung, Umlagerung und ihr Grund. Das ist Ihre zentrale Wahrheit für „wo ist diese Einheit geblieben“.
• Verfügbarer Bestand (StockAvailable, ps_stock_available), die Zahl, die der Shop im Frontoffice tatsächlich prüft, bevor jemand ein Produkt in den Warenkorb legen darf. Wenn ASM für ein Produkt aktiviert ist und seine Bestandsabhängigkeit aktiv ist, wird diese verfügbare Menge aus dem physischen Lagerbestand pro Standort abgeleitet und synchronisiert; andernfalls bleibt ps_stock_available schlicht die Bestandsquelle für das Frontoffice, die Sie direkt setzen.
• Lager–Versanddienst-Verknüpfung (ps_warehouse_carrier). Welche Versanddienste aus welchem Lager versenden dürfen. Genau diese Zeile macht ursprungsbasierten Versand überhaupt möglich.

Was bringt Ihnen das? Wenn Ihre „verfügbare“ Menge und Ihre „physische“ Menge nach einer Retoure oder Umlagerung auseinanderlaufen, wissen Sie jetzt, dass Sie ps_stock_mvt (die Wahrheit) mit ps_stock_available (der zwischengespeicherten Frontoffice-Zahl) vergleichen sollten, statt zu raten. Und weil das Versanddienst-Set am Lager hängt, ist der Ursprung eines Pakets in PrestaShop ein Datenfakt. Nichts, was Sie beim Versandschritt rückwirkend erschließen müssen.

Die zentrale Herausforderung: welches Lager die Bestellung erfüllt

Jede Mehrlagerkonfiguration muss dieselbe Frage beantworten, und die Antwort ist eine Routing-Regel. Das native ASM von PrestaShop ist eher ein Bestands-Hauptbuch als eine Routing-Engine. Es sagt Ihnen, was wo liegt, aber die Zuteilungsentscheidung ist weitgehend manuell oder einem Modul überlassen. Diese vier Strategien sollten Sie kennen, einschließlich ihrer operativen Kosten:

Keine Strategie ist abstrakt „richtig“. Ein Shop mit identischem Bestand an beiden Standorten will nächstgelegenes Lager; ein Shop, bei dem jedes Lager unterschiedliche Produktlinien hält, arbeitet natürlicherweise mit Teillieferung; ein Shop, der Lager zwei nur als Überlauf eröffnet hat, will Priorität. Die Entscheidung, die später am stärksten wirkt, ist die Teillieferung, weil sie verändert, was dem Kunden versprochen wird, dazu unten mehr.

Ursprungsbasierter Versand: Versanddienst und Tarif dem Lager folgen lassen

Das ist der Teil, der wirklich PrestaShop-spezifisch ist und bei dem die meisten Mehrlager-Anleitungen ungenau werden. Ein Versandpreis in PrestaShop wird durch Versandzonen, Gewichts- oder Preisbereiche sowie die Steuer- und Bearbeitungseinstellungen des Versanddienstes bestimmt, nichts davon kennt nativ den Ursprung des Pakets. Standardmäßig sind die Preisbereiche eines Versanddienstes global; PrestaShop zieht nicht ab: „Gut, dieses Paket kam aus Barcelona, also gilt die spanische Preisliste.“ Der native Hebel, den Sie haben, ist die Zuordnung ps_warehouse_carrier: Pro Lager beschränken Sie, welche Versanddienste von dort aus versenden dürfen. So kann ein deutscher Standort DHL/DPD anbieten und ein spanischer Standort SEUR/Correos, und der Kunde sieht nur Versanddienste, die für das Lager gültig sind, dem seine Bestellung zugeordnet wurde.

Was das allein nicht tut: den Preis eines Versanddienstes nach Ursprung neu berechnen. Wenn „DPD Standard“ eine Preisbereichstabelle hat, bezahlt jede DPD-Bestellung nach dieser Tabelle, unabhängig davon, aus welchem Lager sie versendet wurde. Die realistischen Wege zu echten ursprungsbasierten Tarifen:

• Versanddienst pro Ursprung. Legen Sie separate Versanddienste an ("DPD – DE", "DPD – ES"), jeweils mit eigenen Zonen und Preisbereichen, und verknüpfen Sie jeden nur mit seinem Lager. Grob, aber es funktioniert mit reinem Core und ist nachvollziehbar prüfbar.
• Ein Routing-/Lagermodul, das das erfüllende Lager vor dem Lieferschritt bestimmt und ursprungskorrekte Versanddienste und Tarife anzeigt. Das ist die saubere Lösung für mehr als zwei Standorte.
• Echtzeit-Tarife der Versanddienste. Wenn Sie bereits Live-Angebote von Ihren Versanddienstleistern abrufen, übergeben Sie die aufgelöste Lageradresse als Ursprung, damit das Angebot tatsächlich für diese Strecke gilt. Zur Einrichtung von DHL/DPD/UPS im Detail siehe unseren Integrationsleitfaden für DHL, DPD und UPS; für GLS in mehreren Ländern siehe GLS-Versand über mehrere Länder.

Die allgemeine Versandkonfiguration, Zonen, Bereiche, Schwellenwerte für kostenlosen Versand, Bearbeitungsgebühren, funktioniert wie bei einem einzelnen Lager, nur eben pro Versanddienst angewendet. Wir erklären sie hier nicht noch einmal; die vollständige Anleitung finden Sie im kompletten Leitfaden zur PrestaShop-Versandkonfiguration. Wenn Sie noch Ihren ersten Versanddienst einrichten, beginnen Sie mit Versandmodule Schritt für Schritt einrichten.

Bestände über mehrere Standorte hinweg korrekt halten

Der operative Kopfschmerz bei Mehrlagerbetrieb ist nicht das zweite Gebäude, sondern korrekte Zahlen. PrestaShops Trennung zwischen physischem Bestand (ps_stock) und verfügbarem Bestand (ps_stock_available) ist hilfreich, aber genau dort driften Shops auseinander, weil Retouren und Umlagerungen das eine berühren und nicht immer sauber auch das andere. Disziplin, die speziell in PrestaShop trägt:

• Lassen Sie PrestaShop den führenden Datensatz sein. Bestandsänderungen laufen über Stock Management (oder die Oberfläche eines Moduls), wodurch eine Zeile in ps_stock_mvt geschrieben wird. Sobald ein Lager eine parallele Tabelle pflegt, lügt Ihr Audit-Trail. Jede Korrektur sollte einen Bewegungsgrund haben.
• Behandeln Sie Umlagerungen atomar als zwei Bewegungen. Wenn 10 Einheiten von DE nach ES gehen, ist das eine Verringerung in DE und eine Erhöhung in ES. Wenn nur eine Hälfte geschrieben wird, sieht Ihre verfügbare Gesamtmenge korrekt aus, während ein physischer Standort falsch ist. Nutzen Sie einen Umlagerungsablauf, der beide Seiten gemeinsam bucht.
• Setzen Sie Sicherheitsbestände pro Produkt und Lager. Ein globaler Schwellenwert für niedrigen Bestand ist nutzlos, wenn Standort A 40 Stück und Standort B 0 Stück derselben SKU hat. Mindestbestände pro Lager lösen eine Umlagerung oder Nachbestellung aus, bevor B überverkaufen kann.
• Gleichen Sie verfügbaren Bestand regelmäßig mit physischem Bestand ab. Da ps_stock_available faktisch ein zwischengespeichertes Aggregat ist, bringt eine missglückte Retoure oder eine halb abgeschlossene Umlagerung ihn aus dem Takt mit der Summe von ps_stock. Eine regelmäßige Nachzählung, als Bewegungen gebucht, ist das Einzige, was die Realität zurücksetzt.

Wenn Ihr Shop auf einer 1.6-Installation läuft (oder ein von dort aktualisierter 1.7+-Shop ist) und die alten ASM-Tabellen noch enthält, können Sie diese Abweichung mit einer schreibgeschützten Abfrage sichtbar machen, bevor Sie manuell suchen. Diese Abfrage findet die Differenzen, sie schreibt nie, und ist daher sicher ausführbar. Erstellen Sie trotzdem immer ein Backup, bevor Sie eine Korrektur vornehmen, auf die sie hinweist:

-- Products where the cached storefront quantity (ps_stock_available)
-- disagrees with the sum of real physical stock (ps_stock).
-- Read-only diagnostic. Replace the ps_ prefix if yours differs.
-- Caveat: this is a legacy-ASM diagnostic (ps_stock is the old Advanced
-- Stock Management table) and it does NOT handle per-warehouse / multishop
-- warehouse association – treat the drift as a flag to investigate, not a
-- definitive per-shop balance.
SELECT
    sa.id_product,
    sa.id_product_attribute,
    sa.quantity            AS available_cached,
    COALESCE(SUM(s.physical_quantity), 0) AS physical_total,
    sa.quantity - COALESCE(SUM(s.physical_quantity), 0) AS drift
FROM ps_stock_available sa
LEFT JOIN ps_stock s
       ON s.id_product = sa.id_product
      AND s.id_product_attribute = sa.id_product_attribute
WHERE sa.id_shop > 0           -- per-shop rows only; skip the global aggregate row
GROUP BY sa.id_product, sa.id_product_attribute, sa.quantity
HAVING drift <> 0
ORDER BY ABS(drift) DESC;

Eine Zeile mit einem drift ungleich null ist ein Produkt, dessen Frontoffice-Zahl nicht mehr dem entspricht, was physisch in den Lagern liegt, genau die Zeile, die zu Überverkäufen führt oder verkaufbaren Bestand still versteckt. In einer modernen Installation ohne Legacy-ASM-Tabellen ist derselbe Abgleich Aufgabe Ihres Lagermoduls, nicht einer handgeschriebenen Abfrage.

Was der Kunde sieht, und wo es schiefgeht

Aus Käufersicht sollte Mehrlagerbetrieb unsichtbar sein. Kunden wählen ein Produkt; sie sollten nicht wissen müssen, dass es in zwei Ländern liegt. An zwei Stellen wird die Abstraktion sichtbar, und beide sind vermeidbar:

• Der Liefertermin. Dieselbe SKU kann unterschiedliche Lieferzeiten haben, je nachdem, aus welchem Lager sie versendet wird. Ein festes Versprechen von "3–5 Tagen" ist daher in der Hälfte der Fälle falsch. Das Datum, das der Kunde sieht, sollte dem aufgelösten Ursprung folgen. Wie Sie eine realistische Schätzung pro Ursprung berechnen und anzeigen, ist ein eigenes Thema, siehe realistische Liefertermin-Erwartungen setzen.
• Geteilte Bestellungen. Sobald eine Bestellung aus zwei Lagern versendet wird, erhält der Kunde zwei Pakete, zwei Sendungsnummern und möglicherweise zwei Liefertage für etwas, das er als eine Bestellung bezahlt hat. Das ist ein Kommunikationsproblem, kein Logistikproblem: Sagen Sie es im Voraus, dass die Bestellung in zwei Sendungen ankommt, und geben Sie jeder Sendung eine eigene Sendungsverfolgung. Wie Sie Tracking und Benachrichtigungen so verdrahten, dass zwei Pakete nicht wie ein Fehler wirken, behandeln wir in Sendungsnummern und Lieferbenachrichtigungen.

Wann sich Mehrlagerbetrieb wirklich lohnt

Ein zweites Lager vervielfacht Ihre operative Fläche, mehr Bestand zum Abgleichen, mehr Versanddienstregeln, mehr Routing-Entscheidungen. Es rechtfertigt diese Kosten in bestimmten Situationen, nicht als standardmäßiger Wachstumsschritt:

• Ein relevanter Teil Ihrer Kunden liegt weit von Ihrem aktuellen Standort entfernt, wartet dadurch länger und zahlt mehr, die Geografie teilt Ihre Karte tatsächlich.
• Ihr einzelner Standort ist zu Spitzenzeiten ein echtes Versandnadelöhr geworden, nicht nur auf dem Papier.
• Sie erschließen einen neuen Markt, in dem lokaler Bestand das Lieferversprechen von „international“ zu „inländisch“ macht.
• Ihr Sortiment ist so vielfältig geworden, dass ein Standort es nicht sinnvoll lagern kann (Klima, Sperrgut, Gefahrgut).

Wenn Sie ein paar Dutzend Bestellungen pro Tag aus einem Raum versenden, ist Mehrlagerbetrieb verfrüht, ein gut geführter Einzelstandort schlägt jedes unsaubere Zwei-Standort-Setup, und die günstigeren Erfolge liegen meist in Ihrer Versandpreisstrategie statt in zusätzlicher Lagerfläche. Bevor Sie einen zweiten Mietvertrag unterschreiben, lohnt sich ein erneuter Blick auf Versandstrategie für kleine Shops. Wenn Sie wirklich bereit sind, starten Sie mit zwei Standorten, bringen Routing, Bestandssynchronisierung und Versanddienst-Ursprung sauber in Ordnung und fügen erst dann einen dritten hinzu.

Moderne PrestaShop-Versionen nutzen, ohne gegen den Core zu arbeiten

Da das native Lagermodell aus dem Core-Backoffice von 1.7+ entfernt wurde, bleiben in einem aktuellen Shop praktisch diese Wege: parallele, ursprungsspezifische Versanddienste aufsetzen und die Zuteilung von Hand verwalten (für zwei Standorte in Ordnung, danach mühsam), oder ein Lager-/Bestandsmodul nutzen, das Ihnen Standortbestände mit echtem Audit-Trail für Bewegungen, Kommissionierung und Sendungen sowie Versanddienst-Sets pro Lager gibt. Genau diesen Weg geht unser eigenes Modul Warehouse Revolution, Mehrlager-Bestandspositionen (Lager → Regal → Fach), Bestandsbewegungen, Auftragsabwicklung mit Kommissionierung, Lieferanten- und Bestellmanagement sowie Retourenbearbeitung mit Bewertung, damit der Standort, von dem ein Artikel versendet wird, und die dafür gültigen Versanddienste Datenfakten sind statt Dinge, die Sie manuell abgleichen müssen. Kombinieren Sie es mit ursprungsspezifischen Versanddiensten, wenn Sie echte ursprungsbasierte Tarife benötigen, denn einen einzelnen Versanddienst nach Ursprung neu zu bepreisen, kann der Core weiterhin nicht allein. Welchen Weg Sie wählen, die PrestaShop-spezifische Checkliste bleibt gleich: Lager mit ihren Versanddienst-Sets definieren (ps_warehouse_carrier), eine Routing-Regel bewusst wählen, physischen und verfügbaren Bestand regelmäßig abgleichen und Liefertermin plus Hinweise zu Teillieferungen dem tatsächlichen Ursprung folgen lassen.

Mehrlagerverwaltung in PrestaShop: FAQ

Hat modernes PrestaShop integrierte Mehrlagerverwaltung?

Nein, nicht als erstklassige Core-Funktion. Das lagerbasierte Advanced Stock Management wurde in 1.7.0 aus dem Core-Backoffice entfernt; 1.7.2 führte nur eine vereinfachte Bestandsseite für einen einzelnen Standort wieder ein (Bewegungen, Warnungen bei niedrigem Bestand), nicht das Mehrlagermodell mit Standortbeständen und Versanddienst-Sets. Frische Installationen von 1.7 / 8.x / 9.x enthalten daher keine native Lageroberfläche. In einem sauberen modernen Shop entscheiden Sie sich also von Anfang an für ein Modul oder individuellen Code, nicht für das Aktivieren einer Einstellung.

Wie entscheidet PrestaShop, welches Lager eine Bestellung erfüllt?

Standardmäßig im Wesentlichen gar nicht. Das native ASM ist ein Bestands-Hauptbuch, keine Routing-Engine. Sie wählen eine Strategie, und ein Modul (oder Code) setzt sie durch: nächstgelegenes Lager (am schnellsten und günstigsten, braucht aber denselben Artikel an mehreren Standorten), Bestandsverfügbarkeit (Versand von dort, wo Ware auf Lager ist), Priorität (immer zuerst der Hauptstandort, Ausweichlager nur bei leerem Bestand) oder Teillieferung (jede Position wird aus ihrem eigenen Lager versendet). Keine davon ist universell richtig, wählen Sie die, die dazu passt, wie Ihre Standorte tatsächlich Bestand halten.

Kann PrestaShop Versandkosten danach berechnen, aus welchem Lager das Paket kommt?

Nicht durch Neubepreisung eines einzelnen Versanddienstes. Die Preisbereiche eines Versanddienstes sind global, und der Core zieht nicht ab: „Dieses Paket kam aus Barcelona, also nimm den spanischen Tarif.“ Der native Hebel ist die Verknüpfung ps_warehouse_carrier, die einschränkt, welche Versanddienste aus welchem Lager versenden dürfen. Für echte ursprungsbasierte Tarife legen Sie separate Versanddienste pro Ursprung an ("DPD, DE", "DPD, ES"), jeweils mit eigenen Zonen und Bereichen, nutzen ein Routing-Modul, das das Lager vor dem Lieferschritt auflöst, oder übergeben die aufgelöste Lageradresse als Ursprung an Live-Angebote der Versanddienste.

Warum stimmen meine Zahlen für „verfügbaren“ und „physischen“ Bestand nicht überein?

Weil PrestaShop physischen Bestand (ps_stock, die tatsächliche Menge pro Lager) von verfügbarem Bestand (ps_stock_available, der zwischengespeicherten Zahl, die das Frontoffice prüft) trennt. Eine missglückte Retoure oder eine halb abgeschlossene Umlagerung berührt das eine und nicht das andere, also driften sie auseinander. ps_stock_mvt ist der Audit-Trail und Ihre zentrale Wahrheit; die schreibgeschützte Diagnose oben markiert driftende Produkte, und eine geplante Nachzählung, die als Bewegungen gebucht wird, stellt die Realität wieder her.

Wann lohnt sich ein zweites Lager wirklich?

Wenn die Geografie Ihre Karte tatsächlich teilt (ein echter Anteil der Kunden sitzt weit entfernt und wartet länger), wenn ein Standort zu Spitzenzeiten ein Versandnadelöhr ist, wenn lokaler Bestand ein Lieferversprechen von „international“ zu „inländisch“ macht oder wenn Ihr Sortiment nicht sinnvoll in einer einzigen Einrichtung gelagert werden kann (Klima, Sperrgut, Gefahrgut). Wenn Sie ein paar Dutzend Bestellungen pro Tag aus einem Raum versenden, ist es verfrüht, ein gut geführter Einzelstandort schlägt ein unsauberes Zwei-Standort-Setup, und die günstigeren Erfolge liegen meist in Ihrer Versandpreisgestaltung.

Mehrlagerbetrieb hört in dem Moment auf, Kopfschmerzen zu bereiten, in dem diese vier Dinge deterministisch statt hoffnungsvoll sind. Der Kunde sieht die Mechanik nie, er bekommt einfach ein Paket, das vom nächstgelegenen Gebäude losgeschickt wurde, zu einem Preis, der zur Strecke passt, an dem Tag, den Sie versprochen haben. Genau darum geht es, wenn man Mehrlagerverwaltung in PrestaShop richtig umsetzt, statt ein zweites Lager an eine Versandkonfiguration mit nur einem Ursprung anzubauen und zu hoffen, dass sich die Tarife ungefähr ausgleichen.