EAN/GTIN, Zollnummer, Herstellerangaben (Brand) und Gewicht an Shopware pushen #36

New issue

Closed

opened 2026-08-23 13:50:34 +00:00 by csaeum · 1 comment

csaeum commented

2026-08-23 13:50:34 +00:00

Owner

Ziel

Aus dem Scoping in #32 abgeleitet: vier PIM-typische Artikeldaten sind bereits native, bisher ungenutzte ERPNext-Item-Felder und sollten wie die übrigen Artikeldaten (#16-#20) nach Shopware gepusht werden.

Betroffene ERPNext-Felder (alle nativ, live gegen die echte Bench bestätigt)

Item.barcodes (Table → Item Barcode, barcode_type="EAN") — EAN/GTIN
Item.customs_tariff_number (Link → Customs Tariff Number) — Zollnummer
Item.brand (Link → Brand) — Herstellerangabe (beide Referenz-Forks nutzen unabhängig voneinander genau dieses Feld als Shopware-„manufacturer"-Äquivalent, da Shopware kein separates Brand-Konzept kennt)
Item.weight_per_unit/Item.weight_uom — Gewicht

Referenzcode (aus #32s Recherche)

Marcels Fork (product_sync/engine/canonical.py, product_sync/api.py:_resolve_ean()): EAN aus Item Barcode, Manufacturer aus Item.brand.
Julians Fork: unabhängig derselbe brand-als-Manufacturer-Ansatz, dieselbe Item Barcode-Nutzung.
Beide vor Umsetzung erneut gegenprüfen (Standard-Vorgehen), da Marcels Fork seit dem letzten Review deutlich gewachsen ist.

Zu klären bei der Umsetzung (noch nicht live verifiziert)

Die genauen Shopware-seitigen Feldnamen (ean, manufacturerNumber, manufacturerId, ggf. customFields-Slot für Zollnummer) sind aus dem Referenzcode plausibel, aber noch nicht live gegen die echte Shopware-API dieses Projekts bestätigt (Netzwerkproblem beim #32-Scoping verhinderte den Live-Check aus dem ERPNext-Container heraus). Vor Umsetzung live prüfen, wie in #16-#22 etabliert.

Design-Vorschlag (grob, im Umsetzungs-Plan zu verfeinern)

Reine Verdrahtung nach dem #16-#20-Muster: ein PATCH /api/product/{id} pro Item (ggf. zusammen mit einem bestehenden Push wie "Push Items"/#16, statt eines weiteren separaten Buttons — im Plan zu entscheiden), targetiert dieselbe Item-Menge wie #16-#20.

Explizit außerhalb des Scopes

Die vier in #32 bewusst offen gelassenen Design-Fragen (Marketingtexte je Zielgruppe, technische Specs jenseits der Varianten-Attribute, Dokumente/Datenblätter, Cross-/Upselling) — kein natives ERPNext-Modell vorhanden, nicht Teil dieses Issues.
Artikelbilder — separates Issue #31.

## Ziel Aus dem Scoping in #32 abgeleitet: vier PIM-typische Artikeldaten sind bereits native, bisher ungenutzte ERPNext-`Item`-Felder und sollten wie die übrigen Artikeldaten (#16-#20) nach Shopware gepusht werden. ## Betroffene ERPNext-Felder (alle nativ, live gegen die echte Bench bestätigt) - `Item.barcodes` (Table → `Item Barcode`, `barcode_type="EAN"`) — EAN/GTIN - `Item.customs_tariff_number` (Link → `Customs Tariff Number`) — Zollnummer - `Item.brand` (Link → `Brand`) — Herstellerangabe (beide Referenz-Forks nutzen unabhängig voneinander genau dieses Feld als Shopware-„manufacturer"-Äquivalent, da Shopware kein separates Brand-Konzept kennt) - `Item.weight_per_unit`/`Item.weight_uom` — Gewicht ## Referenzcode (aus #32s Recherche) - Marcels Fork (`product_sync/engine/canonical.py`, `product_sync/api.py:_resolve_ean()`): EAN aus `Item Barcode`, Manufacturer aus `Item.brand`. - Julians Fork: unabhängig derselbe `brand`-als-Manufacturer-Ansatz, dieselbe `Item Barcode`-Nutzung. - Beide vor Umsetzung erneut gegenprüfen (Standard-Vorgehen), da Marcels Fork seit dem letzten Review deutlich gewachsen ist. ## Zu klären bei der Umsetzung (noch nicht live verifiziert) Die genauen Shopware-seitigen Feldnamen (`ean`, `manufacturerNumber`, `manufacturerId`, ggf. `customFields`-Slot für Zollnummer) sind aus dem Referenzcode plausibel, aber noch nicht live gegen die echte Shopware-API dieses Projekts bestätigt (Netzwerkproblem beim #32-Scoping verhinderte den Live-Check aus dem ERPNext-Container heraus). Vor Umsetzung live prüfen, wie in #16-#22 etabliert. ## Design-Vorschlag (grob, im Umsetzungs-Plan zu verfeinern) Reine Verdrahtung nach dem #16-#20-Muster: ein `PATCH /api/product/{id}` pro Item (ggf. zusammen mit einem bestehenden Push wie "Push Items"/#16, statt eines weiteren separaten Buttons — im Plan zu entscheiden), targetiert dieselbe Item-Menge wie #16-#20. ## Explizit außerhalb des Scopes - Die vier in #32 bewusst offen gelassenen Design-Fragen (Marketingtexte je Zielgruppe, technische Specs jenseits der Varianten-Attribute, Dokumente/Datenblätter, Cross-/Upselling) — kein natives ERPNext-Modell vorhanden, nicht Teil dieses Issues. - Artikelbilder — separates Issue #31.

csaeum referenced this issue

2026-08-23 14:00:47 +00:00

Technische Eigenschaften (Shopware Property Groups) in ERPNext abbilden und synchronisieren #37

csaeum added the

Artikel

label

2026-08-23 14:00:54 +00:00

csaeum referenced this issue from a commit

2026-08-23 14:43:05 +00:00

docs: scope PIM data ownership between ERPNext and Shopware (#32)

csaeum referenced this issue from a commit

2026-08-23 17:25:00 +00:00

feat(shopware): push EAN, brand, customs tariff number and weight (closes #36)

csaeum commented

2026-08-23 17:26:01 +00:00

Author

Owner

Umgesetzt in e01bd97 auf shopware6-dach (neuer Button "Push Product Data" auf Shopware Account, Modul shopware6/api/product_data.py).

Live gegen erpnext-sync/sw6-erpnext verifiziert - die im Issue offen gelassenen Shopware-Feldnamen:

EAN → direktes ean-Feld am Produkt
Brand → manufacturerId, per Name gegen product-manufacturer aufgelöst/angelegt (Get-or-Create, gleiches Muster wie die Property-Group-Behandlung in product.py)
Gewicht → weight in Kilogramm (Umrechnung aus den vier in dieser Bench vorhandenen Gewichts-UOMs; ein Artikel mit Gewicht aber nicht zuordenbarer UOM wird übersprungen statt geraten)
Zollnummer → wichtiger Fund: dieser Shop hat bereits das Pickware-Shipping-Plugin mit einem fertigen Zollnummer-Custom-Field (pickware_shipping_customs_information_tariff_number) - kein neues Shopware Custom Field nötig

Kein Delta-Sync (anders als #22/#31) - diese Daten ändern sich selten, kein Scheduler geplant, daher immer ein voller Push je Lauf.

Live-Test: Test-Item mit allen vier Feldern bestückt (Brand, Zollnummer, EAN-Barcode, Gewicht in kg) und gepusht - alle vier Werte korrekt in Shopware angekommen (inkl. neu angelegter Manufacturer-Entität). Dabei einen Zählfehler gefunden und behoben: ein Artikel mit ausschließlich einer nicht zuordenbaren Gewichts-UOM wurde doppelt gezählt (skipped_no_weight_uom + skipped_no_data). Test-Fixtures danach in ERPNext wieder entfernt.

Umgesetzt in `e01bd97` auf `shopware6-dach` (neuer Button "Push Product Data" auf Shopware Account, Modul `shopware6/api/product_data.py`). **Live gegen `erpnext-sync`/`sw6-erpnext` verifiziert - die im Issue offen gelassenen Shopware-Feldnamen:** - EAN → direktes `ean`-Feld am Produkt - Brand → `manufacturerId`, per Name gegen `product-manufacturer` aufgelöst/angelegt (Get-or-Create, gleiches Muster wie die Property-Group-Behandlung in `product.py`) - Gewicht → `weight` in Kilogramm (Umrechnung aus den vier in dieser Bench vorhandenen Gewichts-UOMs; ein Artikel mit Gewicht aber nicht zuordenbarer UOM wird übersprungen statt geraten) - Zollnummer → **wichtiger Fund**: dieser Shop hat bereits das Pickware-Shipping-Plugin mit einem fertigen Zollnummer-Custom-Field (`pickware_shipping_customs_information_tariff_number`) - kein neues Shopware Custom Field nötig Kein Delta-Sync (anders als #22/#31) - diese Daten ändern sich selten, kein Scheduler geplant, daher immer ein voller Push je Lauf. **Live-Test:** Test-Item mit allen vier Feldern bestückt (Brand, Zollnummer, EAN-Barcode, Gewicht in kg) und gepusht - alle vier Werte korrekt in Shopware angekommen (inkl. neu angelegter Manufacturer-Entität). Dabei einen Zählfehler gefunden und behoben: ein Artikel mit ausschließlich einer nicht zuordenbaren Gewichts-UOM wurde doppelt gezählt (`skipped_no_weight_uom` + `skipped_no_data`). Test-Fixtures danach in ERPNext wieder entfernt.

csaeum closed this issue

2026-08-23 17:26:06 +00:00