Lagerbestand aus ERPNext (1 Warehouse) an alle Storefronts pushen #20

New issue

Closed

opened 2026-05-10 16:45:13 +00:00 by csaeum · 1 comment

csaeum commented

2026-05-10 16:45:13 +00:00

(Migrated from gitlab.localdomain)

Aktuellen Lagerbestand aus ERPNext auslesen und an alle konfigurierten Shopware Storefronts übertragen:

Bestand aus dem im Storefront konfigurierten Warehouse auslesen (Bin DocType)
Endpoint: PATCH /api/product/{id}/stock oder über Product-Update
Pro Storefront das konfigurierte Warehouse verwenden
Negative Bestände als 0 übertragen
Implementierung in shopware6/api/stock.py

Aktuellen Lagerbestand aus ERPNext auslesen und an alle konfigurierten Shopware Storefronts übertragen: - Bestand aus dem im Storefront konfigurierten Warehouse auslesen (`Bin` DocType) - Endpoint: `PATCH /api/product/{id}/stock` oder über Product-Update - Pro Storefront das konfigurierte Warehouse verwenden - Negative Bestände als 0 übertragen - Implementierung in `shopware6/api/stock.py`

csaeum commented

2026-08-22 17:18:09 +00:00

Owner

Umgesetzt in einer neuen Datei shopware6/api/stock.py (wie im Issue-Text gefordert):

push_stock(shopware_account) — pro Item mit bereits gepushter Shopware-ID (shopware_product_id/shopware_variant_id, gleiches Muster wie #18/#19): Bestand aus Bin.actual_qty im konfigurierten Warehouse des/der aktiven Storefronts lesen, negative Werte auf 0 clampen, PATCH /api/product/{id} mit {"stock": N}.
Neuer Button "Push Stock" auf Shopware Account.

Wichtige Design-Entscheidung, vorab gegen die offizielle Shopware-Doku geprüft: Shopware führt stock als einziges globales Feld pro Produkt (offizielles ADR 2023-05-15-stock-api.md: "We have only one field stock in the product definition"), es gibt kein Kern-Multi-Warehouse pro Sales Channel. Da unser Shopware Storefront.warehouse aber pro Storefront konfiguriert ist (#10), kann ein Item, dessen aktive Storefronts auf unterschiedliche Warehouses zeigen, nicht sinnvoll auf einen Wert verdichtet werden. Passend zum Issue-Titel ("... 1 Warehouse ...") ist das bewusst auf den Standardfall (ein gemeinsames Warehouse) begrenzt — bei mehreren unterschiedlichen Warehouses wird das Item als failed mit klarer Fehlermeldung im Error Log markiert statt geraten/summiert (gleiches Prinzip wie #18s Preis-Konflikt-Behandlung).

Live-Verifikation (alle drei Fälle bestätigt):

Standardfall: Bin.actual_qty = 42 in einem Storefront-Warehouse → korrekt als stock: 42 in Shopware gelandet.
Negativ-Fall: Bin.actual_qty = -5 → korrekt als stock: 0 gepusht.
Konflikt-Fall: zweiter Test-Storefront mit abweichendem Warehouse angelegt → alle Items korrekt als failed markiert, Error-Log-Eintrag mit klarer Meldung, bestehender Shopware-Wert blieb unangetastet statt überschrieben.

Testdaten (Shopware-Produkt, Stock Entry, Item, beide Test-Storefronts) sind nach dem Test wieder gelöscht.

Volle Begründung: docs/architecture.md#issue-20

Umgesetzt in einer neuen Datei `shopware6/api/stock.py` (wie im Issue-Text gefordert): - `push_stock(shopware_account)` — pro Item mit bereits gepushter Shopware-ID (`shopware_product_id`/`shopware_variant_id`, gleiches Muster wie #18/#19): Bestand aus `Bin.actual_qty` im konfigurierten Warehouse des/der aktiven Storefronts lesen, negative Werte auf `0` clampen, `PATCH /api/product/{id}` mit `{"stock": N}`. - Neuer Button "Push Stock" auf `Shopware Account`. **Wichtige Design-Entscheidung, vorab gegen die offizielle Shopware-Doku geprüft**: Shopware führt `stock` als **einziges globales Feld pro Produkt** (offizielles ADR `2023-05-15-stock-api.md`: "We have only one field `stock` in the product definition"), es gibt kein Kern-Multi-Warehouse pro Sales Channel. Da unser `Shopware Storefront.warehouse` aber pro Storefront konfiguriert ist (#10), kann ein Item, dessen aktive Storefronts auf unterschiedliche Warehouses zeigen, nicht sinnvoll auf einen Wert verdichtet werden. Passend zum Issue-**Titel** ("... **1 Warehouse** ...") ist das bewusst auf den Standardfall (ein gemeinsames Warehouse) begrenzt — bei mehreren unterschiedlichen Warehouses wird das Item als `failed` mit klarer Fehlermeldung im Error Log markiert statt geraten/summiert (gleiches Prinzip wie #18s Preis-Konflikt-Behandlung). Live-Verifikation (alle drei Fälle bestätigt): 1. Standardfall: `Bin.actual_qty = 42` in einem Storefront-Warehouse → korrekt als `stock: 42` in Shopware gelandet. 2. Negativ-Fall: `Bin.actual_qty = -5` → korrekt als `stock: 0` gepusht. 3. Konflikt-Fall: zweiter Test-Storefront mit abweichendem Warehouse angelegt → alle Items korrekt als `failed` markiert, Error-Log-Eintrag mit klarer Meldung, bestehender Shopware-Wert blieb unangetastet statt überschrieben. Testdaten (Shopware-Produkt, Stock Entry, Item, beide Test-Storefronts) sind nach dem Test wieder gelöscht. Volle Begründung: [docs/architecture.md#issue-20](https://git.web-seo-consulting.eu/Frappe-Projekte/ecommerce_integrations/src/branch/shopware6-dach/docs/architecture.md#issue-20-push-item-stock)

csaeum closed this issue

2026-08-22 17:18:10 +00:00

csaeum referenced this issue from a commit

2026-08-22 17:19:32 +00:00

feat(shopware): push item stock to Shopware (#20)

csaeum referenced this issue

2026-08-22 17:24:18 +00:00

Scheduled Job für stündlichen Bestandsabgleich einrichten #21

csaeum referenced this issue from a commit

2026-08-22 17:25:11 +00:00

feat(shopware): add hourly scheduled stock sync (#21)