Shopware 6 Available Stock: Lösungen für Bestandsprobleme im Shop

Es ist Montagmorgen, 9:17 Uhr. Deine Performance-Marketing-Kampagne läuft seit einer Stunde, die ersten Klicks kommen rein – und dann die ersten Support-Tickets: „Produkt zeigt ‚Ausverkauft', obwohl ihr gestern noch 230 Stück auf Lager hattet?" Du öffnest das Admin-Panel. Bestand: 230. Produkt aktiv. Alles grün. Trotzdem: Auf der Produktdetailseite steht in großen Lettern „Derzeit nicht verfügbar". Dein Ads-Budget verbrennt, potenzielle Kunden springen ab – und du weißt nicht, wo der Fehler steckt. Genau bei solchen Fällen hilft dir eine erfahrene Shopware Agentur, weil sie die typischen Stellschrauben sofort erkennt.

Willkommen in der Welt von Shopware 6 Available Stock – dem unsichtbaren Mechanismus, der darüber entscheidet, ob dein Shop wirklich verkaufen darf oder nicht. Denn „Bestand im Admin" ist nicht dasselbe wie „verfügbar im Frontend". Zwischen diesen beiden Zuständen liegen Regeln, Reservierungen, Variantenlogik, Sales-Channel-Zuordnungen, Import-Prozesse und manchmal auch ERP-Systeme, die zyklisch überschreiben. In diesem Artikel zeige ich dir, wie Shopware 6 Available Stock funktioniert, welche fünf Hauptursachen am häufigsten zu Problemen führen – und wie du sie in zehn Minuten diagnostizieren kannst, ohne Entwickler zu sein.

Was ist Shopware 6 Available Stock – und warum reicht „Bestand" allein nicht?

Bevor wir in die Diagnose einsteigen, müssen wir drei Begriffe sauber trennen, die im Alltag oft synonym verwendet werden – technisch aber völlig unterschiedlich sind:

• stock – der gebuchte Lagerbestand, den du im Admin siehst (Ausgangspunkt)
• available stock – die Menge, die Shopware im Moment wirklich noch verkaufen darf, nachdem Regeln (z. B. Closeout, Min-/Max-Menge), Reservierungen und offene Bestellungen berücksichtigt wurden
• buyable – die technische Kaufbarkeit (kann ins Warenkorb gelegt werden oder nicht)

Ein Produkt kann technisch „kaufbar" sein, aber trotzdem „Lieferzeit unbekannt" anzeigen – oder umgekehrt: Es hat Bestand, ist aber durch Regeln blockiert. Shopware 6 Available Stock ist das Ergebnis aus Daten, Reservierungen, Regeln und Timing. Wenn auch nur eine dieser Komponenten nicht passt, stimmt die Anzeige im Frontend nicht mit deiner Erwartung überein.

Ein typisches Missverständnis: „Ich sehe im Admin 50 Stück, also muss der Shop verkaufen." Nein – denn vielleicht ist Closeout aktiv und eine Bestellung hat gerade 50 Stück reserviert. Oder die Min-Purchase-Menge liegt bei 100. Oder die Variante, die der Kunde sehen will, hat eigenen Bestand – und der liegt bei 0. Oder dein ERP überschreibt alle 15 Minuten den Wert, weil es eine andere „Wahrheit" kennt.

Die 5 häufigsten Ursachen für falsche Shopware 6 Available Stock Anzeigen

Aus hunderten Support-Tickets, Agentur-Projekten und Community-Threads kristallisieren sich fünf Hauptursachen heraus, die für über 90 % aller „Bestand stimmt nicht"-Fälle verantwortlich sind:

1. Closeout/Backorder falsch konfiguriert

Die Closeout-Funktion (im Deutschen oft „Abverkauf" genannt) entscheidet, was passiert, wenn der Bestand auf 0 fällt. Ist Closeout aktiv, wird das Produkt bei Bestand 0 automatisch nicht mehr kaufbar. Ist Closeout inaktiv, sind Backorders möglich – der Shop verkauft also auch bei 0 weiter (und du musst nachliefern oder stornieren).

Typische Probleme:

• Closeout ist aktiv, obwohl du Vorbestellungen erlauben willst → Shop blockiert bei 0, obwohl du das nicht möchtest
• Closeout ist inaktiv, obwohl du bei 0 stoppen willst → Shop verkauft weiter, Stornos häufen sich
• Min Purchase ist auf 3 gesetzt, Bestand liegt bei 2 → wirkt wie „ausverkauft", obwohl technisch Ware da ist

Prüfe im Admin unter Kataloge → Produkte → Produkt öffnen → Spezifikationen die Felder „Abverkauf" und „Min-/Max-Abnahmemenge".

2. Variante betroffen – Bestand liegt woanders

Shopware unterscheidet strikt zwischen Parent-Produkt und Varianten. Wenn dein Produkt Varianten hat (z. B. Größe, Farbe), liegt der Bestand in der Regel auf der Variante, nicht auf dem Parent. Im Frontend wird aber oft zuerst das Parent angezeigt – und wenn keine Variante ausgewählt oder aktiv ist, erscheint „nicht verfügbar", obwohl einzelne Varianten durchaus Bestand haben.

Typische Szenarien:

• Variante „Blau / L" hat Bestand 50, aber Variante ist nicht aktiv oder nicht sichtbar
• Kunde landet auf Parent-URL, keine Variante ist vorausgewählt → Frontend zeigt „ausverkauft"
• Import setzt Bestand nur auf Parent, Varianten bleiben bei 0

Prüfe jede Variante einzeln: Ist sie aktiv? Hat sie eigenen Bestand? Ist sie im Sales Channel sichtbar?

3. Kaufregeln blockieren (Min/Max Purchase, Purchase Steps)

Shopware erlaubt dir, Mindest- und Höchstabnahmemengen sowie Staffelungen festzulegen. Wenn dein Bestand 2 ist, die Min-Purchase-Menge aber 3, kann niemand kaufen – obwohl technisch Ware da ist. Das System zeigt dann „nicht verfügbar" oder lässt den „In den Warenkorb"-Button inaktiv.

Weitere Stolperfallen:

• Purchase Steps: Produkt nur in 10er-Schritten verkaufbar, Bestand liegt bei 7 → nicht kaufbar
• Max Purchase niedriger als Bestand, aber Customer-Experience leidet, weil Kunde mehr will

4. Sichtbarkeit/Sales Channel – Produkt aktiv, aber nicht zugewiesen

Ein Produkt kann im Admin „aktiv" sein, aber trotzdem im Frontend nicht erscheinen oder nicht kaufbar sein, weil:

• es nicht dem aktuellen Sales Channel zugewiesen ist
• es in diesem Sales Channel auf „unsichtbar" gesetzt ist
• Sprache, Währung oder Kundengruppe eine Regel auslösen, die das Produkt ausblendet

Prüfe unter Kataloge → Produkte → Produkt → Sichtbarkeiten, ob der richtige Sales Channel aktiviert ist.

5. ERP/Import überschreibt zyklisch oder fehlerhaft

Wenn dein Shop an ein ERP oder eine Warenwirtschaft angebunden ist, hast du oft einen zyklischen Import (z. B. alle 15 Minuten). Typische Probleme:

• ERP sendet Bestand 50 → Shopware verkauft 5 → Bestellung reduziert auf 45 → ERP überschreibt wieder mit 50 → „Ping-Pong"
• Import-Mapping falsch → Bestand landet auf falscher Variante oder falschem Produkt
• CSV-Encoding/Trennzeichen falsch → Spalten verrutschen, Bestände werden mit 0 überschrieben
• Retouren/Stornos: Shopware bucht zurück, ERP weiß nichts davon → Differenzen wachsen

Definiere klar: Wer ist die „Single Source of Truth" für Bestände? Shopware oder das ERP? Und wer bucht bei Retouren/Stornos zurück?

Schnellcheck in 10 Minuten: So diagnostizierst du Shopware 6 Available Stock ohne Technik-Know-how

Du musst kein Entwickler sein, um die häufigsten Ursachen zu identifizieren. Hier ist eine Checkliste, die du in zehn Minuten durchgehen kannst:

Wenn du diese fünf Punkte durchgehst und dokumentierst, hast du in den allermeisten Fällen bereits die Ursache identifiziert – oder zumindest so viele Informationen gesammelt, dass ein Entwickler oder deine Agentur in fünf Minuten weiterhelfen kann. Als zusätzliche Grundlage kannst du auch einen strukturierten Shopware-Check nutzen, um wiederkehrende Fehlerquellen systematisch auszuschließen.

So entsteht Shopware 6 Available Stock: Datenfluss verstehen

Um die Logik hinter Shopware 6 Available Stock wirklich zu durchdringen, hilft es, den Datenfluss Schritt für Schritt nachzuvollziehen. Hier ist, was im Hintergrund passiert:

Ausgangswert: Produktbestand (stock)

Der gebuchte Lagerbestand, den du im Admin pflegst oder per Import/ERP setzt. Das ist die „rohe" Zahl – noch ohne jede Logik.

Abzüge durch offene/gebuchte Mengen

Je nach Konfiguration und Workflow reduziert Shopware den verfügbaren Bestand, sobald:

• eine Bestellung in einem bestimmten Status ist (z. B. „in Bearbeitung", „bezahlt")
• Reservierungen aktiv sind (je nach Plugin/ERP-Setup)

Welche Bestellstatus „stock-relevant" sind, hängt von deiner State-Machine-Konfiguration ab. Standardmäßig wird Bestand bei Bestellabschluss reduziert – aber manche Shops reduzieren erst bei Zahlung oder Versand.

Regeln, die Kaufbarkeit beeinflussen

Selbst wenn rechnerisch noch Bestand da ist, können Regeln die Kaufbarkeit blockieren:

• Closeout/Backorder: bei Bestand 0 kaufbar oder nicht?
• Min/Max Purchase: Mindest-/Höchstabnahmemenge
• Purchase Steps: nur in bestimmten Schritten verkaufbar (z. B. 5er, 10er)
• Varianten-Availability: jede Variante hat eigene Regeln und Bestände

Ergebnis: Available Stock im Frontend

Das Ergebnis dieser Berechnungen ist der Wert, den die Storefront und die Store API ausgeben. Aber Achtung: Dieser Wert ist nicht immer sofort aktuell, denn:

• Indexing: Nach Bulk-Updates (z. B. CSV-Import) muss Shopware die Daten neu indizieren, damit sie im Frontend sichtbar werden
• Caching: HTTP-Caches, Reverse-Proxies oder CDN können veraltete Werte ausliefern
• ERP-Sync-Intervalle: Wenn dein ERP nur alle 15 Minuten synchronisiert, hinkt der Wert im Shop entsprechend hinterher

Closeout, Backorders & Kaufbarkeit: Der kritischste Konfigurationspunkt

Die Closeout-Funktion ist der Hebel, der am häufigsten missverstanden wird – und die größte Auswirkung auf Shopware 6 Available Stock hat. Schauen wir uns die Szenarien im Detail an:

Szenario 1: Bestand = 0, Closeout aktiv

Das Produkt wird automatisch nicht mehr kaufbar. Der „In den Warenkorb"-Button verschwindet oder wird inaktiv, es erscheint ein Text wie „Derzeit nicht verfügbar" oder „Ausverkauft". Das ist das Standardverhalten für die meisten Shops.

Szenario 2: Bestand = 0, Closeout inaktiv

Backorders sind möglich. Der Kunde kann bestellen, obwohl keine Ware da ist. Du musst dann nachliefern, kommunizieren oder im schlimmsten Fall stornieren. Das macht Sinn für:

• Vorbestellungen (Preorder)
• Just-in-Time-Beschaffung (du bestellst beim Lieferanten, sobald Kunde bestellt)
• Digitale Produkte (kein physischer Bestand nötig)

Aber Achtung: Wenn du Backorders erlaubst, ohne es dem Kunden zu kommunizieren, riskierst du schlechte Bewertungen und hohe Supportkosten.

Typische Missverständnisse

• „Ich will Lieferzeit anzeigen, aber nicht verkaufen bei 0" → Closeout aktiv + Lieferzeit-Text anpassen
• „Ich will verkaufen bei 0, aber nur mit klarer Ansage" → Closeout inaktiv + individuelle Verfügbarkeitstexte pflegen (z. B. „Lieferbar in 2–3 Wochen")

Zusammenspiel mit Min/Max Purchase

Ein häufiger Fehler: Bestand liegt bei 2, Min Purchase ist auf 3 gesetzt. Ergebnis: Das Produkt wirkt wie „nicht verfügbar", obwohl technisch Ware da ist. Shopware zeigt in diesem Fall oft keinen Fehler – der Button bleibt einfach inaktiv oder der Kunde kann nicht in den Warenkorb legen.

Prüfe daher immer: Passt die Min-/Max-Konfiguration zum tatsächlichen Bestand?

Varianten: Der häufigste Grund für „Bestand da, aber nicht verfügbar"

Wenn dein Produkt Varianten hat (z. B. T-Shirt in Größe S/M/L und Farbe Rot/Blau/Grün), verwaltet Shopware den Bestand in der Regel pro Variante, nicht auf dem Parent-Produkt. Das bedeutet:

• Parent-Produkt hat Bestand 0 (oder keinen eigenen Bestand)
• Variante „Blau / L" hat Bestand 50
• Variante „Rot / S" hat Bestand 0

Wenn der Kunde auf der Produktdetailseite landet und keine Variante ausgewählt ist (oder die Standardvariante Bestand 0 hat), zeigt der Shop „nicht verfügbar" – obwohl andere Varianten durchaus lieferbar wären.

Quick Checks für Varianten

• Ist die betroffene Variante wirklich aktiv? (Admin → Kataloge → Produkte → Varianten → Status prüfen)
• Hat die Variante eigenen Bestand gesetzt? (nicht auf Parent verlassen)
• Ist die Variante im Sales Channel sichtbar und zugewiesen?
• Welche Variante ist Standard/Vorausgewählt? (oft die Ursache für „funktioniert nicht beim ersten Laden")

Ein typisches Problem bei CSV-Importen: Der Import setzt Bestand nur auf dem Parent-Produkt, die Varianten bleiben bei 0 – und niemand merkt es, bis die ersten Support-Tickets eintreffen.

Sales Channel & Sichtbarkeit: Bestand korrekt, Produkt trotzdem „weg"

Ein Produkt kann im Admin „aktiv" sein, korrekten Bestand haben und trotzdem im Frontend nicht erscheinen oder nicht kaufbar sein. Warum? Weil Shopware die Sichtbarkeit pro Sales Channel steuert.

Prüfe:

• Ist das Produkt dem richtigen Sales Channel zugewiesen? (Admin → Kataloge → Produkte → Sichtbarkeiten)
• Ist die Sichtbarkeit auf „Versteckt" oder „Nur über Direktlink" gesetzt? (dann erscheint es nicht in Listings)
• Gibt es Kundengruppen- oder Regel-basierte Einschränkungen, die das Produkt ausblenden?

Ein weiterer Stolperstein: Wenn du mehrere Sales Channels hast (z. B. B2C-Shop und B2B-Portal), musst du für jeden Channel separat die Sichtbarkeit und ggf. auch die Bestände verwalten – je nach Setup.

Unterschied: „nicht gelistet" vs. „nicht kaufbar" vs. „nicht lieferbar"

• Nicht gelistet: Produkt erscheint nicht in Kategorie/Suche, ist aber per Direktlink erreichbar
• Nicht kaufbar: Produkt ist sichtbar, aber Button inaktiv (z. B. wegen Closeout, Min-Purchase, Regeln)
• Nicht lieferbar: Produkt ist kaufbar, aber Lieferzeit-Text sagt „aktuell nicht verfügbar" (Kommunikation vs. technische Kaufbarkeit)

Diese Unterschiede zu kennen hilft dir, gezielt nach der richtigen Stellschraube zu suchen.

Import/Export: Häufigster Hebel – und häufigste Fehlerquelle

Viele Shops pflegen Bestände nicht manuell im Admin, sondern per CSV-Import oder über Schnittstellen. Das ist effizient – aber auch fehleranfällig. Hier die häufigsten Stolpersteine:

1. Falscher Identifier (Mapping)

Shopware braucht einen eindeutigen Schlüssel, um zu wissen, welches Produkt/welche Variante aktualisiert werden soll. Üblich sind:

• productNumber (Artikelnummer)
• id (UUID des Produkts/der Variante)

Wenn der Identifier falsch gemappt ist, landet der Bestand auf dem falschen Produkt – oder wird als neues Produkt angelegt.

2. Encoding/Trennzeichen/Quotes

Shopware erwartet standardmäßig:

• UTF-8 Encoding
• Semikolon als Trennzeichen
• Anführungszeichen als Textumgrenzung (optional, aber oft nötig bei Texten mit Sonderzeichen)

Wenn Excel oder ein anderes Tool das CSV in einem anderen Format exportiert (z. B. ANSI-Encoding, Komma-Trennzeichen), können Umlaute falsch dargestellt werden oder Spalten verrutschen – mit der Folge, dass Bestände überschrieben oder gelöscht werden.

3. „Update existing data" überschreibt unbeabsichtigt

Wenn diese Option aktiv ist, überschreibt der Import vorhandene Werte. Das ist oft gewollt – kann aber auch bedeuten, dass du versehentlich andere Felder (z. B. Preise, Beschreibungen) zurücksetzt, wenn sie in deinem CSV leer oder nicht vorhanden sind.

Empfehlung: Testlauf mit 5 Produkten/Varianten, bevor du 5.000 Datensätze importierst. Prüfe nach dem Testlauf Stichproben im Frontend, in der Store API und im Admin.

Sicherer Ablauf „Bestand per CSV aktualisieren"

1. CSV mit eindeutigem Identifier (productNumber) und Bestandsfeld vorbereiten
2. Encoding auf UTF-8 setzen, Trennzeichen Semikolon, Quotes bei Bedarf
3. Import-Profil anlegen oder bestehendes wählen (Admin → Einstellungen → Automatisierung → Import/Export)
4. Mapping prüfen: Welche CSV-Spalte wird auf welches Shopware-Feld gemappt?
5. Testlauf mit 5 Datensätzen (Dry-Run, falls verfügbar, oder manuell nachprüfen)
6. Stichprobe im Frontend/API/Admin
7. Erst dann: Vollimport
8. Nach Import: Import-Aktivität prüfen (Admin → Einstellungen → Automatisierung → Import/Export → Importaktivität)
9. Bei Bedarf: Indexer/Caches gezielt aktualisieren (aber nicht prophylaktisch nach jedem Import)

Wenn du dabei zusätzlich auf Plugins setzt, lohnt sich ein Blick auf ein Shopware-Import-Plugin, um wiederkehrende Mapping- und Formatfehler zu reduzieren.

Nach dem Import: Was prüfen?

• Import-Protokoll: Gab es Fehler, Warnungen, übersprungene Zeilen?
• Stichproben: 5–10 Produkte im Frontend aufrufen – stimmt der Bestand?
• Store API: Falls du Zugriff hast, Produkt per API abfragen und Bestandswert vergleichen
• Admin: Bestandswert im Produkt-Datensatz kontrollieren

ERP/Wawi-Integration: Single Source of Truth & Timing

Wenn dein Shop an ein ERP-System (z. B. SAP, Microsoft Dynamics, JTL, Pickware) oder eine Warenwirtschaft angebunden ist, wird es komplex – aber auch mächtig. Die zentrale Frage lautet: Wer ist die „Single Source of Truth" für Bestände?

Shopware führend vs. ERP führend

• ERP führend: Bestände werden nur im ERP gepflegt, Shopware ist „Empfänger". Vorteil: Eine Wahrheit, keine Konflikte. Nachteil: Shopware kann Bestände nicht selbst korrigieren (z. B. bei manuellen Korrekturen).
• Shopware führend: Bestände werden in Shopware gepflegt, ERP synchronisiert zurück. Vorteil: Flexibilität. Nachteil: Synchronisations-Konflikte, wenn beide Systeme gleichzeitig schreiben.

In den meisten Fällen ist ERP führend die sauberere Variante – aber nur, wenn das ERP alle relevanten Vorgänge kennt (Bestellungen, Retouren, Stornos, manuelle Korrekturen).

Typische Konflikte

• Ping-Pong: ERP sendet Bestand 50 → Shopware verkauft 5, reduziert auf 45 → ERP überschreibt wieder mit 50 (weil es die Bestellung noch nicht kennt) → Overselling
• Retouren/Stornos: Shopware bucht Bestand zurück, ERP weiß nichts davon → Differenzen wachsen, bis manuell korrigiert wird
• Multi-Channel: Shop A und Shop B verkaufen parallel, ERP synchronisiert nur alle 15 Minuten → beide Shops verkaufen dasselbe letzte Stück

Praxisempfehlungen

• Klares Ownership: Definiere für jedes Feld (Bestand, Lieferzeit, Backorder-Flag, Preis), welches System führend ist
• Sync-Frequenz: Je höher die Verkaufsfrequenz, desto kürzer das Sync-Intervall (aber Vorsicht vor Server-Last)
• Monitoring: Alarme bei negativen Beständen, „verkaufbar trotz 0"-Spikes, großen Differenzen zwischen ERP und Shopware
• Peak-Sales-Plan: Bei Black Friday, Weihnachten etc. höhere Sync-Frequenz, klare Reservierungsstrategie, Notfallregeln (z. B. Backorder temporär deaktivieren)

Concurrency & Peak-Sales: Was passiert bei hoher Last?

Selbst wenn alle Konfigurationen korrekt sind, kann es bei hoher Last zu Race Conditions kommen: Zwei Kunden legen parallel das letzte verfügbare Produkt in den Warenkorb, beide schließen die Bestellung ab – und plötzlich hast du -1 im Bestand.

Typische Effekte

• Overselling in Sekundenfenstern (bis die Bestandsreduktion greift)
• Verzögertes Indexing/Caching: Frontend zeigt noch „verfügbar", obwohl gerade verkauft wurde
• ERP-Sync hinkt hinterher: Verkauf läuft schneller als Sync-Intervall

Maßnahmen

• Closeout bewusst konfigurieren: Soll bei 0 wirklich gestoppt werden oder Backorder erlauben (mit klarer Kommunikation)?
• Sync-Frequenz anpassen: Während Peak-Sales ggf. auf 1–5 Minuten reduzieren (statt 15–30 Minuten)
• Reservierungsstrategie: Manche Shops reservieren Bestände bereits im Warenkorb (für X Minuten), andere erst bei Bestellabschluss
• Fail-safe: Klare Storno-/Kommunikationsprozesse, falls es doch zu Overselling kommt

Problem-Landkarte: Symptome, die du wirklich kennst

Hier sind die typischen Support-Tickets und Probleme, die immer wieder auftauchen – mit jeweils der wahrscheinlichsten Ursache:

Reproduzierbares Debug-Vorgehen für Agenturen & Entwickler

Wenn du technischen Zugriff hast oder mit einer Agentur zusammenarbeitest, hilft dir dieser strukturierte Reproduktionsplan:

1. Reproduktionsplan erstellen

• Zeitpunkt notieren (wann tritt das Problem auf?)
• SKU/Produktnummer/Variante dokumentieren
• Sales Channel festhalten
• Erwarteter Bestand vs. tatsächlicher Bestand (Admin vs. Frontend vs. API)

2. Vergleich: Storefront vs. Store API vs. Admin

• Storefront: Produktdetailseite öffnen, Verfügbarkeit ablesen
• Store API: Produkt per API abfragen, Bestandswert auslesen
• Admin: Produkt im Backend öffnen, Bestandsfeld prüfen

Unterschiede zwischen diesen drei Quellen zeigen dir, ob es ein Darstellungs-, ein Cache- oder ein Datenproblem ist.

3. DB/CLI/Logs (je nach Zugriff)

• Datenbankfelder: product.stock, product.available_stock (falls vorhanden), Varianten-Bestände
• Bestellmengen & Status: Welche Bestellungen sind offen/bezahlt/storniert? Welche Mengen wurden reserviert?
• Queue/Indexer/Logfiles: Fehlermeldungen, Verzögerungen, nicht abgearbeitete Jobs

Ziel: „Welche Komponente ändert den Wert?"

Ist es ein Admin-User? Ein Import? Ein ERP-Job? Eine Bestellung? Ein Plugin? Sobald du die Quelle identifiziert hast, kannst du gezielt korrigieren.

Checkliste: Vor & nach CSV-Import

Imports sind die häufigste Ursache für plötzliche Bestandsprobleme. Diese Checkliste hilft dir, Fehler zu vermeiden:

Vor Import

• Encoding UTF-8, Trennzeichen Semikolon, Quotes bei Bedarf
• Mapping eindeutig (productNumber/SKU + Variantenspezifik)
• Testlauf mit 5 Produkten/Varianten
• Überschreib-Regeln bewusst wählen (Update existing data: ja/nein?)
• Stichprobenliste vorbereiten (welche Produkte prüfst du nach Import?)

Nach Import

• Import-Protokoll/Activity prüfen (Admin → Einstellungen → Automatisierung → Import/Export → Importaktivität)
• Stichproben im Frontend (5–10 Produkte)
• Stichproben in der Store API (falls Zugriff)
• Stichproben im Admin (Bestandswerte, Varianten)
• Bei Bedarf: Cache/Indexer aktualisieren (gezielt, nicht prophylaktisch)

Quick Fix vs. sauberer Prozess: Leitplanken für echte Stabilität

Wenn es brennt, brauchst du einen Quick Fix. Langfristig brauchst du aber einen sauberen Prozess. Hier ist der Unterschied:

Quick Fix (wenn es brennt)

• Closeout/Backorder/Min-Max-Purchase prüfen und anpassen
• Varianten einzeln durchgehen (aktiv, sichtbar, Bestand?)
• Sales-Channel-Sichtbarkeit kontrollieren
• Letzte Importe/ERP-Jobs identifizieren und ggf. zurückrollen
• Cache/Indexer gezielt aktualisieren

Sauberer Prozess (damit es nicht wieder passiert)

• Single Source of Truth definieren (Shopware vs. ERP, pro Feld)
• Statuslogik für Rückbuchungen klären (Storno, Retoure: wer bucht zurück?)
• Monitoring & Alarme einrichten (negative Bestände, Overselling-Spikes)
• Test-Imports & Staging etablieren (nie direkt in Produktion importieren)
• Dokumentation: Wer pflegt Bestände? Wer darf Importe starten? Wer ist bei Problemen zuständig?

FAQ: Die wichtigsten Fragen zu Shopware 6 Available Stock

Warum ist mein Produkt trotz Bestand nicht kaufbar?

Häufigste Ursachen: Closeout aktiv + Bestand 0, Min-Purchase-Menge höher als Bestand, Variante betroffen (Parent hat Bestand, aber ausgewählte Variante nicht), Sales-Channel-Sichtbarkeit fehlt, oder Kaufregeln (Purchase Steps) blockieren.

Warum zeigt das Frontend falsche Verfügbarkeit nach Import/ERP-Update?

Entweder wurde der Bestand nicht korrekt importiert (Mapping-Fehler, falsche Spalten), oder Indexing/Caching hinkt hinterher. Prüfe das Import-Protokoll, kontrolliere Stichproben im Admin und aktualisiere ggf. gezielt Cache/Indexer.

Was ist der Unterschied zwischen Lieferzeit, Bestand und Available Stock?

Bestand (stock) ist die gebuchte Lagermenge. Available Stock ist die tatsächlich noch verkaufbare Menge (nach Abzug von Reservierungen/Regeln). Lieferzeit ist Kommunikation/Erwartungsmanagement und kann unabhängig vom Bestand gesetzt werden.

Wie wirken Closeout/Backorder und Min/Max Purchase konkret?

Closeout entscheidet, ob bei Bestand 0 verkauft werden darf (inaktiv = Backorder möglich, aktiv = nicht kaufbar). Min/Max Purchase legt fest, welche Mengen überhaupt in den Warenkorb gelegt werden können. Wenn Min Purchase 3 ist, Bestand aber 2, ist das Produkt nicht kaufbar.

Wie prüfe ich Varianten richtig?

Jede Variante einzeln öffnen (Admin → Kataloge → Produkte → Varianten), Status prüfen (aktiv?), Bestand prüfen (hat die Variante eigenen Bestand?), Sales-Channel-Sichtbarkeit prüfen. Nicht davon ausgehen, dass Parent-Einstellungen automatisch für alle Varianten gelten.

Was sollte ich zuerst prüfen: Produkt, Sales Channel, Import oder ERP?

Start mit dem 10-Minuten-Schnellcheck: Produkt im Frontend öffnen, Closeout/Min-Max prüfen, Varianten prüfen, Sales-Channel-Sichtbarkeit prüfen, letzte Importe/ERP-Jobs identifizieren. In 80 % der Fälle findest du die Ursache in den ersten drei Schritten.

Fazit: Verfügbarkeit ist wie eine Ampel im Checkout – grün heißt wirklich kaufbar

Shopware 6 Available Stock ist kein magisches Feld, das manchmal funktioniert und manchmal nicht. Es ist das präzise Ergebnis aus Daten, Regeln, Reservierungen und Timing. Wenn die Ampel im Checkout grün zeigt, heißt das: Der Kunde darf kaufen – weil Bestand da ist, keine blockierenden Regeln greifen, die richtige Variante ausgewählt ist, das Produkt im Sales Channel sichtbar ist und ERP/Import nicht gerade überschreiben.

Die gute Nachricht: In den allermeisten Fällen kannst du die Ursache in zehn Minuten identifizieren, wenn du systematisch vorgehst. Closeout/Backorder, Min-/Max-Purchase, Varianten, Sales-Channel-Sichtbarkeit und Import-Protokolle – das sind die fünf Hebel, an denen du zuerst drehen solltest. Und wenn du einmal die Logik hinter Shopware 6 Available Stock verstanden hast, wirst du nie wieder rätseln, warum dein Shop „nicht verfügbar" zeigt, obwohl Ware da ist.

Deine nächsten Schritte:

• Nimm dir 30 Minuten Zeit und gehe die Diagnose-Checkliste an einem deiner Top-Seller durch – auch wenn gerade kein Problem sichtbar ist. Du lernst dabei die Logik kennen und bist vorbereitet, wenn es das nächste Mal brennt.
• Kläre mit deinem Team (oder deiner Agentur), wer für Bestände verantwortlich ist: Shopware oder ERP? Wer bucht bei Stornos/Retouren zurück? Wer darf Importe starten?
• Sichere deinen Import-/Sync-Prozess mit Testläufen, Stichproben und Monitoring ab. Ein einziger fehlerhafter Bulk-Import kann mehr Schaden anrichten als zehn kleine manuelle Fehler.

Verfügbarkeit ist kein Zufall. Sie ist das Ergebnis sauberer Prozesse, klarer Verantwortlichkeiten und einer Shopware-Konfiguration, die zu deinem Geschäftsmodell passt. Und genau dabei hilft dir dieses Wissen über Shopware 6 Available Stock. Wenn du zusätzlich die Storefront-Seite als Fehlerquelle ausschließen willst, ist ein tieferer Blick in die Shopware Storefront-Konfiguration oft der schnellste nächste Schritt.