Scoping: welche Artikeldaten hält ERPNext (PIM-Rolle), was geht an Shopware? #32

New issue

Closed

opened 2026-08-22 18:55:49 +00:00 by csaeum · 1 comment

csaeum commented

2026-08-22 18:55:49 +00:00

Owner

Ziel: ERPNext soll so weit wie möglich als führendes System (ähnlich einem PIM) für Artikeldaten dienen — so viel wie möglich in ERPNext sammeln/pflegen, so wenig wie möglich direkt in Shopware.

Dieses Issue ist bewusst als Scoping/Recherche-Aufgabe angelegt, nicht als konkrete Implementierung: eine Bestandsaufnahme, welche Datenarten in Frage kommen und wie der Datenfluss (nur ERPNext → Shopware, oder auch Shopware → ERPNext für Felder, die es in ERPNext noch nicht gibt) aussehen sollte, bevor daraus einzelne Umsetzungs-Issues abgeleitet werden.

Zu klären:

Welche Artikeldaten hält ERPNext heute schon (Item-Standardfelder + bisherige Custom Fields aus #16-#19: meta_title/meta_description, Shopware-IDs, etc.)?
Welche zusätzlichen PIM-typischen Datenarten fehlen noch und wären sinnvoll in ERPNext zu pflegen statt in Shopware, z. B.:
- Erweiterte Produktbeschreibungen/Marketingtexte je Zielgruppe
- Cross-/Upselling-Verknüpfungen zwischen Artikeln
- Technische Attribute/Spezifikationen (über die bestehenden Item-Attribute aus #14 hinaus)
- Dokumente/Datenblätter, Herstellerangaben, EAN/GTIN, Zollnummern
- Bilder (siehe separates Issue "Artikelbilder aus ERPNext an Shopware pushen")
Für jede Datenart: gehört sie zu ERPNext (Quelle der Wahrheit, Push nach Shopware), zu Shopware (z. B. rein shopspezifische Darstellungsoptionen, die in ERPNext keinen Sinn ergeben), oder beidseitig synchronisiert?
Existiert dafür schon was Wiederverwendbares bei Julian/Marcel oder in ALYF-Bundles (gleiche Prüfung wie bei #23/#24 etabliert), bevor eigene DocTypes/Felder geplant werden?

Ergebnis: eine dokumentierte Übersicht (vermutlich in Projekt.md/docs/architecture.md), aus der sich einzelne, klar abgegrenzte Umsetzungs-Issues ableiten lassen — kein Big-Bang-Issue.

Noch keinem Milestone zugeordnet.

**Ziel**: ERPNext soll so weit wie möglich als führendes System (ähnlich einem PIM) für Artikeldaten dienen — so viel wie möglich in ERPNext sammeln/pflegen, so wenig wie möglich direkt in Shopware. Dieses Issue ist bewusst als Scoping/Recherche-Aufgabe angelegt, nicht als konkrete Implementierung: eine Bestandsaufnahme, welche Datenarten in Frage kommen und wie der Datenfluss (nur ERPNext → Shopware, oder auch Shopware → ERPNext für Felder, die es in ERPNext noch nicht gibt) aussehen sollte, bevor daraus einzelne Umsetzungs-Issues abgeleitet werden. **Zu klären**: - Welche Artikeldaten hält ERPNext heute schon (Item-Standardfelder + bisherige Custom Fields aus #16-#19: `meta_title`/`meta_description`, Shopware-IDs, etc.)? - Welche zusätzlichen PIM-typischen Datenarten fehlen noch und wären sinnvoll in ERPNext zu pflegen statt in Shopware, z. B.: - Erweiterte Produktbeschreibungen/Marketingtexte je Zielgruppe - Cross-/Upselling-Verknüpfungen zwischen Artikeln - Technische Attribute/Spezifikationen (über die bestehenden Item-Attribute aus #14 hinaus) - Dokumente/Datenblätter, Herstellerangaben, EAN/GTIN, Zollnummern - Bilder (siehe separates Issue "Artikelbilder aus ERPNext an Shopware pushen") - Für jede Datenart: gehört sie zu ERPNext (Quelle der Wahrheit, Push nach Shopware), zu Shopware (z. B. rein shopspezifische Darstellungsoptionen, die in ERPNext keinen Sinn ergeben), oder beidseitig synchronisiert? - Existiert dafür schon was Wiederverwendbares bei Julian/Marcel oder in ALYF-Bundles (gleiche Prüfung wie bei #23/#24 etabliert), bevor eigene DocTypes/Felder geplant werden? **Ergebnis**: eine dokumentierte Übersicht (vermutlich in `Projekt.md`/`docs/architecture.md`), aus der sich einzelne, klar abgegrenzte Umsetzungs-Issues ableiten lassen — kein Big-Bang-Issue. Noch keinem Milestone zugeordnet.

csaeum added the

Artikel

Dokumentation

labels

2026-08-22 18:56:05 +00:00

csaeum referenced this issue

2026-08-22 19:12:57 +00:00

B2B / B2C Unterscheidung implementieren #25

csaeum commented

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

Author

Owner

Scoping abgeschlossen, wie im Issue-Text vorgesehen ohne Code — reine Recherche/Dokumentation.

Marcel-Fork (mittlerweile deutlich gewachsen: product_sync/catalog_mirror/smart_collections/ai_description/rag/medusa) liefert die ergiebigsten Erkenntnisse:

EAN nutzt ERPNexts natives Item Barcode (barcode_type="EAN"), kein Custom Field.
Manufacturer/Brand wird direkt aus ERPNexts nativem Item.brand gespeist ("Shopware has no separate Brand concept, so the manufacturer is the brand").
Eigener Code-Kommentar bestätigt wörtlich: "Cross-selling (both directions) — no ERPNext-side data model decided yet" — auch im fortgeschritteneren Fork ungelöst.
Shopware Item Custom Field Mapping: generische Mapping-DocType für beliebige Shop-Flags ohne Code — als Architekturidee vermerkt.
Keine Treffer für Zollnummer/HS-Code/Datenblätter in beiden Forks.

Julian-Fork bestätigt unabhängig denselben brand-als-Manufacturer-Ansatz und dieselbe Item Barcode-Nutzung.

ERPNext-Core, live gegen die echte Bench geprüft: Item.brand, Item.customs_tariff_number (genau die im Issue genannten Zollnummern!), Item.country_of_origin, Item.weight_per_unit/weight_uom, Item.barcodes (EAN/GTIN) sind alle bereits native, bisher ungenutzte Felder. Das native E-Commerce-Modul (Website Item/technische Specs/Cross-Sell) ist nicht verfügbar, da die separate webshop-App in dieser Bench nicht installiert ist.

Ergebnis: vier Datenarten (EAN/GTIN, Zollnummer, Brand, Gewicht) sind bereits native ERPNext-Felder und werden in einem einzelnen neuen, klar abgegrenzten Push-Issue gebündelt (reine Verdrahtung nach dem #16-#20-Muster). Vier weitere Kategorien (Marketingtexte je Zielgruppe, technische Specs jenseits der Varianten-Attribute, Dokumente/Datenblätter, Cross-/Upselling) bleiben bewusst offene, dokumentierte Design-Fragen ohne abgeleitetes Issue — kein Big-Bang-Issue, wie gewünscht.

Details inkl. vollständiger Scoping-Tabelle: docs/architecture.md → Issue 32.

Scoping abgeschlossen, wie im Issue-Text vorgesehen ohne Code — reine Recherche/Dokumentation. **Marcel-Fork** (mittlerweile deutlich gewachsen: `product_sync`/`catalog_mirror`/`smart_collections`/`ai_description`/`rag`/`medusa`) liefert die ergiebigsten Erkenntnisse: - EAN nutzt ERPNexts natives `Item Barcode` (`barcode_type="EAN"`), kein Custom Field. - Manufacturer/Brand wird direkt aus ERPNexts nativem `Item.brand` gespeist ("Shopware has no separate Brand concept, so the manufacturer is the brand"). - Eigener Code-Kommentar bestätigt wörtlich: *"Cross-selling (both directions) — no ERPNext-side data model decided yet"* — auch im fortgeschritteneren Fork ungelöst. - `Shopware Item Custom Field Mapping`: generische Mapping-DocType für beliebige Shop-Flags ohne Code — als Architekturidee vermerkt. - Keine Treffer für Zollnummer/HS-Code/Datenblätter in beiden Forks. **Julian-Fork** bestätigt unabhängig denselben `brand`-als-Manufacturer-Ansatz und dieselbe `Item Barcode`-Nutzung. **ERPNext-Core, live gegen die echte Bench geprüft**: `Item.brand`, `Item.customs_tariff_number` (genau die im Issue genannten Zollnummern!), `Item.country_of_origin`, `Item.weight_per_unit`/`weight_uom`, `Item.barcodes` (EAN/GTIN) sind alle bereits native, bisher ungenutzte Felder. Das native E-Commerce-Modul (`Website Item`/technische Specs/Cross-Sell) ist nicht verfügbar, da die separate `webshop`-App in dieser Bench nicht installiert ist. **Ergebnis**: vier Datenarten (EAN/GTIN, Zollnummer, Brand, Gewicht) sind bereits native ERPNext-Felder und werden in einem einzelnen neuen, klar abgegrenzten Push-Issue gebündelt (reine Verdrahtung nach dem #16-#20-Muster). Vier weitere Kategorien (Marketingtexte je Zielgruppe, technische Specs jenseits der Varianten-Attribute, Dokumente/Datenblätter, Cross-/Upselling) bleiben bewusst offene, dokumentierte Design-Fragen ohne abgeleitetes Issue — kein Big-Bang-Issue, wie gewünscht. Details inkl. vollständiger Scoping-Tabelle: `docs/architecture.md` → Issue 32.

csaeum closed this issue

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

csaeum referenced this issue

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

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

csaeum referenced this issue

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

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

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)