Varianten-Mapping (Shopware Properties → ERPNext Item Variants) #14

New issue

Closed

opened 2026-05-10 16:44:02 +00:00 by csaeum · 1 comment

csaeum commented

2026-05-10 16:44:02 +00:00

(Migrated from gitlab.localdomain)

Shopware-Produktvarianten auf ERPNext Item Variants mappen:

Shopware Properties (z.B. Farbe, Größe) → ERPNext Item Attributes
Shopware Property Options → ERPNext Attribute Values
Varianten-Artikel als ERPNext Item Variants anlegen
Shopware Variant ID in Custom Field am ERPNext Item speichern
Implementierung in shopware6/api/product.py

Shopware-Produktvarianten auf ERPNext Item Variants mappen: - Shopware Properties (z.B. Farbe, Größe) → ERPNext Item Attributes - Shopware Property Options → ERPNext Attribute Values - Varianten-Artikel als ERPNext Item Variants anlegen - Shopware Variant ID in Custom Field am ERPNext Item speichern - Implementierung in `shopware6/api/product.py`

csaeum commented

2026-08-22 10:50:37 +00:00

Owner

Implemented by extending ecommerce_integrations/shopware6/api/product.py from #13 (as specified in the issue) with variant awareness, plus a new shopware_variant_id Custom Field on Item.

Behavior change vs. #13: list_products() now filters server-side to top-level parents (parentId == None) and embeds each parent's variant children via the children association (with options.group). Products without variants are unaffected — still a single flat Item, same as #13.

Research (Julian/Marcel): Both already use ERPNext's native variant mechanism (has_variants/variant_of/attributes), no custom parallel structure — good confirmation for our approach. Both fetch children embedded on the same search call rather than a second parentId-filtered request, which we adopted directly. Marcel's code comment (and our own live check against the real catalog) confirms a Shopware parent's own options is always empty — only children carry the group/value matrix. Julian's variant code reads only the parent's options, a latent bug we did not copy (ERPNext's own validation throws "Attribute table is mandatory" on an empty attributes table).

Design decisions:

Dedup on item_code directly (template and variant SKUs), plus shopware_variant_id as required by the issue — consistent with #13's dedup approach, diverging from both forks' Ecommerce Item-based linking.
Item Attribute/value dedup by name, following Julian's/Marcel's shared approach, with a fix: their abbr = value[:10] truncation isn't collision-safe and broke on real data (two distinct values sharing the same first 10 characters). Replaced with a _generate_abbr() helper that disambiguates with a numeric suffix on collision — same idea already used for Item Group name collisions in #12.

Live verification against the real catalog:

72 templates + 2181 variants + 26 unchanged plain products = 2279 total (matches #13's total product count exactly).
72 Item Attributes created (each product has its own per-product colour group name in this catalog, e.g. "Farben Mojave | Büffelleder" — not a shared generic group).
Second run: 0 created, 2279 skipped, attribute count unchanged — full dedup confirmed for templates, variants, and attributes.
No scope creep: no prices/stock/images, no Shopware properties relation (only options), no generic field mapper.
Test data (items, item groups, item attributes, test account) cleaned up after verification.

See Projekt.md → Architecture Decisions for the full writeup.

Implemented by extending `ecommerce_integrations/shopware6/api/product.py` from #13 (as specified in the issue) with variant awareness, plus a new `shopware_variant_id` Custom Field on `Item`. **Behavior change vs. #13:** `list_products()` now filters server-side to top-level parents (`parentId == None`) and embeds each parent's variant children via the `children` association (with `options.group`). Products without variants are unaffected — still a single flat Item, same as #13. **Research (Julian/Marcel):** Both already use ERPNext's native variant mechanism (`has_variants`/`variant_of`/`attributes`), no custom parallel structure — good confirmation for our approach. Both fetch children embedded on the same search call rather than a second `parentId`-filtered request, which we adopted directly. Marcel's code comment (and our own live check against the real catalog) confirms a Shopware parent's own `options` is always empty — only children carry the group/value matrix. Julian's variant code reads only the parent's `options`, a latent bug we did not copy (ERPNext's own validation throws `"Attribute table is mandatory"` on an empty attributes table). **Design decisions:** - Dedup on `item_code` directly (template and variant SKUs), plus `shopware_variant_id` as required by the issue — consistent with #13's dedup approach, diverging from both forks' `Ecommerce Item`-based linking. - Item Attribute/value dedup by name, following Julian's/Marcel's shared approach, **with a fix**: their `abbr = value[:10]` truncation isn't collision-safe and broke on real data (two distinct values sharing the same first 10 characters). Replaced with a `_generate_abbr()` helper that disambiguates with a numeric suffix on collision — same idea already used for Item Group name collisions in #12. **Live verification against the real catalog:** - 72 templates + 2181 variants + 26 unchanged plain products = 2279 total (matches #13's total product count exactly). - 72 Item Attributes created (each product has its own per-product colour group name in this catalog, e.g. "Farben Mojave | Büffelleder" — not a shared generic group). - Second run: 0 created, 2279 skipped, attribute count unchanged — full dedup confirmed for templates, variants, and attributes. - No scope creep: no prices/stock/images, no Shopware `properties` relation (only `options`), no generic field mapper. - Test data (items, item groups, item attributes, test account) cleaned up after verification. See `Projekt.md` → Architecture Decisions for the full writeup.

csaeum closed this issue

2026-08-22 10:50:42 +00:00

csaeum referenced this issue from a commit

2026-08-22 11:36:38 +00:00

feat(shopware): map Shopware variants to ERPNext Item Variants (#14)

csaeum referenced this issue

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

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

csaeum referenced this issue

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

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

csaeum referenced this issue