---
title: "Wer besitzt welches Feld: Shop, ERP oder PIM"
description: "Der Bestand ist das einfache Feld. Preise, Attribute, Medien, Alt-Texte, Texte je Sprache und URL-Schlüssel schreiben zwei Systeme gleichzeitig, und die Eigentumsregel ist durch das begrenzt, was Ihre Plattform ausdrücken kann."
author: "Luboš Zápotočný"
published: "2026-08-06"
language: "de"
canonical: "https://zapolu.com/de/blog/wer-besitzt-welches-feld/"
---

# Wer besitzt welches Feld: Shop, ERP oder PIM

Jeder Shop, der ein ERP-System anbindet, klärt irgendwann, wem die
Bestandsnummer gehört. Die Antwort lautet
[fast immer das ERP- oder Lagersystem](/de/blog/erp-eshop-stock-mismatch/),
denn dort werden die Waren gebucht und dort bewegen sie sich
physisch. Ist das einmal festgelegt, werden Synchronisierungsfehler
zu einer rein mechanischen Angelegenheit.

Dann stellt sich dieselbe Frage für jedes andere Feld, und die
einfache Antwort funktioniert nicht mehr. Der Bestand ist eine Zahl
mit einer Bedeutung. Der Preis ist eine Zahl pro Website, pro Markt
oder pro Kundenunternehmen. Der Produkttext ist ein Wert pro
Sprache. Ein Bild ist eine Datei, aber sein Alt-Text ist ein Satz pro
Sprache. Wem der Bestand gehört, darüber streitet niemand lange. Der
Rest des Datensatzes ist der Bereich, in dem die Eigentumsfrage
offen bleibt.

Dieser Beitrag legt eine Eigentumsregel je Feld fest, für Preise,
Attribute, Medien, sprachspezifische Texte, B2B-Preise und
URL-Schlüssel, und prüft anschließend jede Regel daran, was Magento
und Shopify tatsächlich abbilden können, wo die in Mitteleuropa
verbreiteten ERP-Systeme an ihre Grenzen stoßen und wann sich ein PIM
lohnt. Die Plattformhälfte besteht aus Magento und Shopify; ein
tschechischer oder slowakischer Shop läuft mindestens genauso häufig
auf Shoptet, und die Frage der Feldzugehörigkeit stellt sich dort
gleichermaßen, auch wenn die Mechanismen andere sind. Jede
Anbieterangabe wurde am 4. August 2026 anhand der jeweiligen
Anbieterdokumentation geprüft, und die tragenden Aussagen sind
verlinkt; wo eine Prüfung nicht möglich war, ist das vermerkt.

## Ein Zuständiger pro Feld, ein Geltungsbereich

Das Prinzip aus dem Beitrag zum Bestand gilt weiterhin: ein führendes
System pro Sachverhalt. Neu ist, dass ein Feld erst dann ein
Sachverhalt ist, wenn auch sein Geltungsbereich benannt wurde. „Das
ERP besitzt den Preis“ ist keine Regel, die sich integrieren lässt.
„Das ERP besitzt den Listenpreis pro Website, und niemand besitzt den
Preis pro Store View, weil die Plattform ihn dort nicht speichern
kann“ ist dagegen eine Regel, die sich umsetzen lässt.

Der Wortschatz dafür ist älter als der E-Commerce. Pat Hellands
[Data on the Outside versus Data on the Inside](https://www.cidrdb.org/cidr2005/papers/P12.pdf)
(CIDR 2005) formuliert die Regel in einem Satz: „Reference data
refers to a type of information that is created and/or managed by a
single service and published to other services for their use ...
For each piece, there is exactly one publishing service.“

Die Literatur zum Datenmanagement sagt dasselbe mit anderen Worten,
und es lohnt sich, diese zu übernehmen, weil sie die beiden Rollen
benennen, die die Systeme eines Shops einnehmen. Das DAMA-DMBOK,
zweite Auflage, Kapitel 10 (Reference and Master Data), definiert ein
System of Record als „an authoritative system where data is
created/captured, and/or maintained through a defined set of rules
and expectations“, und ein System of Reference als „an authoritative
system where data consumers can obtain reliable data to support
transactions and analysis, even if the information did not originate
in the system of reference“. Eines seiner sechs Leitprinzipien für
Referenz- und Stammdaten ist Authority: „Master Data values should be
replicated only from the system of record.“ Ein weiteres ist
Ownership, das dort auf Ebene der Organisation verortet wird und
nicht auf Feldebene. Ihr Storefront ist für den Großteil des
Produktdatensatzes ein System of Reference, und in diesem Beitrag
geht es darum, welches System für welches Feld das System of Record
ist.

Was die Literatur offenlässt, ist die Granularität. Die zweite
Auflage benennt die Bezeichnung und zählt Match-, Merge-,
Survivorship- und Trust-Regeln zu den Geschäftsregeln, die
Stammdatenmanagement braucht, behandelt aber Entitäten und
Datenelemente allgemein und nicht die konkrete Frage, welches System
den Alt-Text eines Storefronts auf Polnisch besitzt. Die vier
MDM-Stile, die gewöhnlich als Registry, Consolidation, Coexistence
und Transaction zitiert werden, werden meist Gartner zugeschrieben;
Gartners eigene Seiten haben jede unserer Anfragen abgelehnt, und die
frei zugängliche Quelle, die wir gefunden haben, schreibt die Stile
[Datenmanagement-Beratern und MDM-Anbietern](https://www.techtarget.com/searchdatamanagement/definition/master-data-management)
zu und nicht Gartner. Wir verwenden sie daher als gebräuchliche
Beschreibung, nicht als Definition.

Für die Weitergabe gibt es besser benannte Muster. Ein Push-Feed ist
ein ereignisgesteuerter Consumer, ein nächtlicher Job ist ein
[Polling Consumer](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PollingConsumer.html);
das Tolerieren einer wiederholten Nachricht ist ein
[Idempotent Receiver](https://www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html),
dessen zwei dokumentierte Wege eine explizite Deduplizierung oder
eine Semantik sind, die eine erneute Verarbeitung unschädlich macht;
und das Wiederherstellen der Reihenfolge in einem Stream, der
ungeordnet eingetroffen ist, ist ein
[Resequencer](https://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html).
Hellands
[Life beyond Distributed Transactions](https://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf)
(CIDR 2007) benennt die Anforderung, der diese Muster dienen: „the
application must tolerate message retries and the out-of-order
arrival of some messages.“

## Was Ihre Plattform ausdrücken kann

Eine Eigentumsregel, die die Plattform nicht abbilden kann, lässt
sich nicht implementieren. Prüfen Sie die Regel deshalb am
Datenmodell, bevor Sie sie mit irgendjemandem vereinbaren.

**Magento gliedert sich nach der Shop-Hierarchie.** Adobe dokumentiert eine
[Kaskade aus Global, Website, Store und Store View](https://experienceleague.adobe.com/en/docs/commerce-admin/start/setup/websites-stores-views),
doch ein Produktattribut lässt sich nur für drei dieser vier Ebenen
festlegen: Die Store-Ebene trägt die Root-Kategorie und keine
Attributwerte, ein Attribut ist also global, pro Website oder pro
Store View. Zwei Grenzen entscheiden die meisten Eigentumsfragen. Der Geltungsbereich des Preises ist nicht frei wählbar: Die Einstellung
[Catalog Price Scope](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/catalog-price-scope)
bietet nur Global oder Website an, die Seite erklärt unmissverständlich,
dass „Commerce does not allow setting a product price for each
store“, und im Admin ist die Einstellung nur im Bereich Default
Config zugänglich, sie gilt also als ein einziger Schalter für die
gesamte Installation. Bei manchen Attributen lässt sich der Geltungsbereich
überhaupt nicht ändern: Magento sperrt die Bereichsauswahl bei `sku` und
`category_ids` in der
[eav_attributes.xml](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/eav_attributes.xml)
und deaktiviert sie bei `sku` und `media_gallery` in der
[Konfiguration des Admin-Formulars](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/adminhtml/di.xml)
(2.4-develop, geprüft am 4. August 2026). Ein Attribut, das als
konfigurierbare Option verwendet wird,
[muss global sein](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/product-attributes/product-attributes-add),
seine Optionsbezeichnungen bleiben aber pro Store View übersetzbar.

**Shopify trennt Preisgestaltung und Übersetzung, und das sind zwei
unterschiedliche Mechanismen.** Eine Variante trägt genau einen
Basispreis im Produktdatensatz; ein pro Markt hinterlegter Preis
liegt vollständig außerhalb des Produkts, in einer Price List, die
an einem Katalog hängt, der wiederum an einem Markt hängt. Ein Markt
kann außerdem ohne jede Price List vom Basispreis abweichen, über
Währungsumrechnung und Rundungsregeln. Magento kennt dazu keine
Entsprechung: Ein pro Markt hinterlegter Preis bedeutet eine Website
pro Markt, wobei die darunterliegenden Store Views sich diesen Preis
teilen. Die Übersetzung ist eine eigene Oberfläche und auf der
Produktressource selbst eng gefasst: Übersetzbar sind nur Titel,
Body, Handle, Produkttyp, Meta-Titel und Meta-Beschreibung, und
[die Tags einer Ressource lassen sich überhaupt nicht übersetzen](https://shopify.dev/docs/apps/build/markets/manage-translated-content).
Optionsnamen, Optionswerte und öffentlich zugängliche Metafelder sind
ebenfalls übersetzbar, als eigene Ressourcentypen. Eine Übersetzung
lässt sich über die `marketId` im Übersetzungs-Input zusätzlich auf
einen Markt beschränken, sodass dieselbe Sprache in zwei Märkten
unterschiedlich ausfallen kann. Die URL-Handles bilden die Ausnahme:
Shopify erklärt, dass sie sich nicht pro Markt anpassen lassen. Zwei
Mechanismen sind für denjenigen relevant, der den Schreibpfad
besitzt: Das Schreiben einer Übersetzung setzt den
`translatableContentDigest` der Quelle voraus, und
[`Translation.outdated`](https://shopify.dev/docs/api/admin-graphql/latest/objects/Translation)
zeigt an, ob sich der Originalinhalt seit dem Schreiben der
Übersetzung geändert hat. Das macht Veralterung erkennbar, behebt sie
aber nicht. Und `productSet` gleicht Listenfelder gegen die
gesendete Payload ab: Bei Varianten, Metafeldern und Collections
erstellt und aktualisiert es, was in der Payload steht, und löscht,
was fehlt, wodurch ein naiver, partieller „alles synchronisieren“-Job
destruktiv wird. Das beschriebene Verhalten bezieht sich auf die
Admin API 2026-07, geprüft am 4. August 2026.

## Die Antwort Feld für Feld

| Feld | System of Record | Geltungsbereich, den es tatsächlich abbilden kann | Bei Konflikt |
| ----- | ---------------- | -------------------------- | ----------- |
| Produktidentität | ERP, als Ersatzschlüssel | Die ERP-ID in einem Magento-Attribut oder einem Shopify-Metafeld ablegen; nicht über die SKU verknüpfen, da diese umbenannt wird | Die ERP-ID hat Vorrang; eine geänderte SKU ist eine Umbenennung, kein neues Produkt |
| Listenpreis | ERP | Magento: nur global oder pro Website. Shopify: ein Basiswert pro Variante | ERP gewinnt; Shop-Änderungen werden bei der nächsten Synchronisierung überschrieben |
| Steuergrundlage und Steuerklasse | ERP | Magento: `tax_class_id` ist ein website-bezogenes Attribut, Netto- oder Bruttoanzeige ist eine separate Konfiguration. Shopify: ein Produkt-Flag plus marktspezifische Steuereinstellungen | Festlegen, welche Seite der Mehrwertsteuer-Multiplikation maßgeblich ist, und das dokumentieren. Ein tschechischer oder polnischer B2C-Katalog wird brutto gepflegt; wird der Bruttopreis aus einem Netto-ERP-Preis abgeleitet, entsteht eine Rundungsdifferenz zwischen dem ERP-Preis und dem Preis, den der Kunde sieht |
| Markt- oder Kanalpreis | Shop | Shopify: Price Lists pro Katalog und Markt, plus Währungsumrechnung. Magento kann beides nicht trennen: Der Website-Preis ist der einzige Wert, wer also den Listenpreis besitzt, besitzt auch den Marktpreis | Der Shop gewinnt für die Anzeige. Das ERP erhält weiterhin den tatsächlichen Verkaufspreis der Bestellung und darf eine importierte Bestellung nicht anhand der eigenen Liste neu bepreisen |
| Aktionspreis | Shop, außer die Margenfreigabe liegt beim ERP | Magento: dieselbe Hülle wie der Listenpreis, oder eine Katalogpreisregel pro Website und Kundengruppe. Shopify: Vergleichspreis oder eine Kataloganpassung | Liegt die Margenfreigabe beim ERP, besitzt das ERP das Feld, und der Shop darf auf denselben Produkten keine zusätzlichen Katalogregeln anwenden |
| B2B- oder Vertragspreis | ERP | Magento: Kundengruppen-Staffelpreise pro Website; Shared Catalogs nur mit Adobe Commerce B2B. Shopify: Kataloge pro Firmenstandort | ERP gewinnt. Oberhalb einiger Dutzend Preisprofile bildet keine der beiden Plattformen kundenindividuelle Verträge gut ab |
| Physischer Bestand | ERP, oder das WMS, wo vorhanden | Pro Quelle. Die verkaufsfähige Menge wird von der Plattform aus den Quellen abzüglich Reservierungen berechnet und ist nicht schreibbar | Niemals die verkaufsfähige Menge schreiben; die Quellmenge schreiben und die Plattform ableiten lassen |
| Variantenset | PIM, sonst Shop | Konfigurierbare Magento-Produkte benötigen globale Optionsattribute; die meisten ERP-Systeme führen jede Variante als eigenständigen Artikel ohne übergeordnetes Element | Wer die übergeordnete Gruppierung besitzt, besitzt das Feld; das ERP kann das meist nicht abbilden |
| Attribute und Optionen | PIM, sonst Shop | Attribute für konfigurierbare Optionen müssen bei Magento global sein | PIM gewinnt; der Shop ist eine Anzeigekopie |
| Mediendateien | DAM, sonst PIM | Ein globaler Dateisatz; bei Magento sind die Rollen Base, Small und Thumbnail pro Store View | DAM gewinnt, aber nur, wenn es je Asset eine stabile Identität beibehält; eine Umbenennung bei der erneuten Synchronisierung verwaist jede store-view-bezogene Rolle |
| Alt-Text | PIM, sonst Shop | Pro Store View bei Magento, pro Sprache bei Shopify | Der Eigentümer des Texts gewinnt |
| Sprachspezifischer Text | ERP bis zu seiner Sprachobergrenze, sonst PIM, sonst Shop | Magento: Store Views; Shopify: fünf der sechs übersetzbaren Produktfelder, dazu Optionsnamen, Optionswerte und öffentlich lesbare Metafelder (der Handle ist die URL-Zeile) | Die Ausgangssprache gewinnt; eine veraltete Übersetzung wird markiert, nicht ersetzt |
| URL-Schlüssel oder Handle | Shop | Pro Store View bei Magento; pro Sprache bei Shopify, Handles lassen sich aber nicht pro Markt anpassen | Der Shop gewinnt; niemals aus dem Produktnamen neu generieren |
| Veröffentlichung und Delisting | ERP für die Zulässigkeit, Shop für den Kanal | Das ERP-Flag (`isInternet`, `exportNaEshop`) filtert den Katalog; der Shop veröffentlicht pro Website oder Kanal | Deaktivieren statt löschen: Ein gelöschtes Produkt verliert seine URL, seine Bewertungen und seine Rewrite-Historie |
| Kategorie- oder Collection-Zugehörigkeit | PIM, sonst Shop | Eine globale Zuordnung bei Magento; Collections bei Shopify. Ein ERP-Warengruppenbaum ist eine Eingabe, nicht das System of Record | PIM gewinnt; der ERP-Baum wird gemappt, nicht gespiegelt |
| Regulatorische Felder | Shop, befüllt aus Lieferantendaten | Pro Markt, in einer Sprache, die der jeweilige Mitgliedstaat des Marktes akzeptiert | Eine Attestierung darf niemand automatisch überschreiben |

Zwei Zeilen verdienen eine Erläuterung: Medien und URL-Schlüssel.

**Ein Bild ist global, sein Alt-Text nicht.** Adobe erklärt, dass
„New product images are **_always_** uploaded and visible in
**_all_** store views, even if the `All Store Views` scope is not
used for upload“
([Produktbilder und Video](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/digital-assets/product-image),
geprüft am 4. August 2026), und die Galerie speichert eine Datei pro
Bild ohne Store-Spalte. Ein DAM besitzt daher den Asset-Bestand für
alle Sprachen gleichzeitig. Pro Store View ist dagegen die Zeile
neben jedem Bild: Bezeichnung, Position und ein Deaktivierungs-Flag,
wodurch Alt-Text, Bildreihenfolge und die Frage, welches Bild
ausgeblendet ist, sämtlich store-view-bezogene Felder sind. Eine
Einschränkung erschwert die saubere Trennung: Die Bild-*Rollen*
(Base, Small, Thumbnail, Swatch) sind store-view-bezogene Attribute,
die einen Dateipfad enthalten, sodass sich auch unterscheiden kann,
welche der globalen Dateien ein Storefront je Sprache tatsächlich
rendert. Shopify zieht die Grenze an derselben Stelle, nur aus der
anderen Richtung: Bei einem Media Image ist `alt` das einzige
übersetzbare Feld. Die
[Translate & Adapt-Dokumentation](https://help.shopify.com/en/manual/international/translate-adapt-app)
führt Produktbilder unter den Inhaltstypen auf, die die App nicht
übersetzen kann, während andere Bilder und Videos an einer
übersetzten Ressource durch das Hochladen einer alternativen Datei
je Sprache ausgetauscht werden können (geprüft am 4. August 2026).

Diese Trennung wiegt schwerer, als es zunächst scheint, denn Alt-Text
ist kein rein technisches Feld. Der
[European Accessibility Act](https://eur-lex.europa.eu/eli/dir/2019/882/oj)
erfasst E-Commerce-Dienstleistungen für Verbraucher, und die
Mitgliedstaaten müssen seine Maßnahmen seit dem 28. Juni 2025
anwenden. Die Richtlinie selbst verlangt, dass diese Dienste
wahrnehmbar, bedienbar, verständlich und robust sind, ohne Alt-Text
namentlich zu nennen; die konkrete Anforderung an
Text-Alternativen ist in EN 301 549 formuliert, die auf WCAG
verweist. Zu beachten ist, dass die geltende Fassung, V3.2.1, unter
der Web Accessibility Directive harmonisiert wurde und nicht unter
dem Accessibility Act, und dass die EAA-relevante Fassung V4.1.0 zum
Zeitpunkt unserer Prüfung im Amtsblatt noch nicht zitiert war. Die
Ausnahmeregelung für Kleinstunternehmen ist
[enger gefasst, als sie aussieht](/de/blog/accessibility-act-ecommerce/),
und eine gesonderte Prüfung auf unverhältnismäßige Belastung steht
jedem Anbieter offen. Alt-Text ist sprachspezifischer Inhalt mit
einem angehängten Compliance-Regime, verfasst dort, wo auch der
übrige Text entsteht. Keiner der beiden Upload-Pfade fragt ihn pro
Sprache ab.

**Der URL-Schlüssel gehört meist dem Shop, aber nicht, weil ihn
sonst niemand beansprucht.** Die meisten ERP-Systeme haben keine
Meinung zu Storefront-URLs, und die Versuchung liegt nahe, daraus zu
schließen, das Feld habe keinen konkurrierenden Anspruch. Das stimmt
nicht. Die Dokumentation von Comarch ERP Optima zu e-Sklep gibt dem
ERP einen Reiter „Pozycjonowanie“ (Positionierung) mit Seitentitel,
einem eigenen `Link`-Feld zum Aufbau von URLs, Keywords und einer
Meta-Beschreibung, sowohl für Produktgruppen als auch für einzelne
Artikel
([Comarch Optima Hilfe, Version 2026_5](https://pomoc.comarch.pl/optima/pl/2026_5/dokumentacja/wspolpraca-z-comarch-e-sklep/),
geprüft am 4. August 2026). Auch Konnektoren und PIMs schreiben
Handles, unabhängig davon, was die ERP-Kerndokumentation vorsieht.

Die operative Regel ist der Frage nach dem Geltungsbereich überlegen,
denn Comarch zeigt, dass ein ERP das Feld durchaus abbilden kann. Wer
den URL-Schlüssel besitzt, trägt jede Folge einer Änderung, und
diese Folgen treten außerhalb des Systems ein, das die Änderung
vorgenommen hat. Entscheidend ist daher, was bei einer Umbenennung
geschieht. Magento macht daraus eine Einstellung, „Create Permanent
Redirect for URLs if URL Key Changed“, und wer den Schlüssel
besitzt, erbt eine wachsende Rewrite-Tabelle.

Überlässt man dieses Feld einem externen System zur freien
Änderung, entstehen direkte Kosten. Heurekas
[Feed-Spezifikation](https://sluzby.heureka.cz/napoveda/xml-feed/)
kennzeichnet vier Elemente als unbedingt verpflichtend, Produktname,
Artikel-ID, Preis inklusive Mehrwertsteuer und URL, und erklärt auf
Tschechisch, dass bei Änderungen von Produkt-URLs, -Namen oder
-Kategorien im XML sämtliche Produkte von ihren Heureka-Produktkarten
entkoppelt werden und danach auf eine erneute Zuordnung warten,
wofür laut Spezifikation rund vier Werktage veranschlagt werden. Ein
PIM, das Handles aus Produktnamen neu erzeugt, entkoppelt damit den
gesamten Katalog für mehrere Tage vom Vergleichsportal, ohne dass im
Shop selbst etwas defekt erscheint.

## Wo das ERP an seine Grenzen stößt: sprachspezifischer Text

Für einen Shop, der auf Tschechisch, Slowakisch, Deutsch und
Polnisch verkauft, verläuft die Grenze zwischen „das ERP kann den
Produkttext besitzen“ und „etwas anderes muss es übernehmen“
üblicherweise entlang der Anzahl an Sprachen, die das Datenmodell
des ERPs zulässt, und diese Zahl liegt niedriger als die Anzahl der
Märkte, in die ein Shop dieser Größenordnung verkauft.

ABRA Flexi besitzt mehrsprachigen Text in seiner zentralen
Preislisten-Entität, allerdings als feste Anzahl an Spalten und
nicht als Liste: ein primärer Name und eine Beschreibung plus drei
weitere, sichtbar im
[eigenen veröffentlichten Feldschema der Entität](https://demo.flexibee.eu/c/demo/cenik/properties.json)
(geprüft am 4. August 2026, wo die Demo-Firma sie als Englisch,
Deutsch und Französisch beschriftet). Das sind vier Sprachplätze in
der Kernentität, und ABRAs eigener Support-Artikel bestätigt, dass
weitere Sprachen nur über sprachspezifische benutzerdefinierte
Felder möglich sind, was Integrationsarbeit ist und keine
Konfiguration. Money stellt lokalisierte Namen und Beschreibungen
über die
[PLUS-Ansichten seines E-Commerce-Connectors](https://developer.moneyerp.com/eshop-konektor/vycitani-dat-e-shopem/)
bereit, und Comarch ERP Optima führt sprachspezifische Namen und
Beschreibungen auf demselben e-Handel-Reiter wie seine SEO-Felder.
Business Central exportiert Artikelübersetzungen einseitig nach
Shopify und war das einzige System dieser Gruppe, dessen
Dokumentation eine Custom-Field-Brücke beschrieb, die seine Felder
auf Shopify-Metafelder abbildet. Für SAP Business One und InsERT
fanden wir keinen dokumentierten Export mehrsprachigen Produkttexts,
allerdings rendert das SAP-Dokumentationsportal nur für einen
JavaScript-Client, und wir konnten es nicht vollständig lesen; das
ist daher als unbestätigt zu behandeln, nicht als nicht vorhanden.

Zwei weitere ERP-seitige Grenzen führen unbemerkt zu Integrationsfehlern, weil
beide harte Obergrenzen sind und keine Fehler. ABRA Flexi kodiert
Mengenstaffeln als feste Spalten statt als Zeilen und begrenzt die
Staffelpreisgestaltung auf fünf Stufen. Helios drückt jede
Preisstufe in höchstens sechs Währungen aus, einer inländischen und
fünf ausländischen. Eine Staffeltabelle oder Währungsliste, die über
die Form des ERPs hinauswächst, lässt sich im System of Record
schlicht nicht mehr ausdrücken, ohne dass ein Fehler ausgelöst wird.

Vor allem anderen lohnt es sich, das Flag zu finden, das entscheidet,
welche SKUs der Storefront sehen darf. Jedes System hat eines, und
jedes benennt es anders, `isInternet` auf einer
[POHODA-Lagerkarte](https://www.stormware.cz/schema/version_2/stock.xsd),
`exportNaEshop` bei einer ABRA-Flexi-Preislistenposition, dokumentiert
im
[veröffentlichten Feldschema](https://demo.flexibee.eu/c/demo/cenik/properties.json)
und im eigenen Integrationsleitfaden von ABRA als Filter verwendet.
Wer dieses Flag besitzt, kontrolliert den Katalog, was auch immer
der Rest des Designs vorsieht. Helios klärt die Zuständigkeit
stattdessen über seine API-Fläche: Von den siebzehn Pfaden in seiner
[veröffentlichten eShop-API-Beschreibung](https://public.helios.eu/inuvio/api/eshop/Inuvio_doc_api_eshopv2.json)
akzeptieren nur Bestellungen und Kunden Schreibzugriffe. Produkte,
Kategorien, Preislisten und Bestände sind schreibgeschützt, wodurch
das ERP schon konstruktionsbedingt maßgeblich ist.

## Die vom Gesetzgeber hinzugefügten Felder

Manche der umstrittenen Felder sind neu und stammen aus der
Regulierung statt aus dem Merchandising, weshalb kein System dafür
ausgelegt wurde, sie zu besitzen.

Die
[Verordnung über die allgemeine Produktsicherheit](https://eur-lex.europa.eu/eli/reg/2023/988/oj)
(Verordnung (EU) 2023/988, anwendbar seit dem 13. Dezember 2024)
verlangt, dass ein Fernabsatzangebot den Namen des Herstellers sowie
dessen Post- und elektronische Adresse trägt, ebenso für die
verantwortliche Person eines Herstellers außerhalb der EU,
außerdem Informationen zur Identifizierung des Produkts einschließlich
eines Bildes und seines Typs sowie jede Warn- oder Sicherheitsinformation
„in a language which can be easily understood by consumers, as
determined by the Member State in which the product is made
available on the market“. Diese letzte Klausel macht den
Sicherheitstext zu einem marktspezifischen Inhaltsfeld, und die
Sprache bestimmt der Ziel-Mitgliedstaat, nicht der Anbieter. Die
Verordnung verlangt außerdem einen in der EU niedergelassenen
Wirtschaftsakteur, der für jedes Produkt verantwortlich ist.

Die Energiekennzeichnung fügt weitere Felder hinzu. Die
[Verordnung (EU) 2017/1369](https://eur-lex.europa.eu/eli/reg/2017/1369/oj)
nennt den Online-Fernabsatz ausdrücklich in der Pflicht des Händlers,
das Label anzuzeigen (Artikel 5 Absatz 1 Buchstabe a); das
Produktdatenblatt muss den Kunden gemäß dem folgenden Punkt
zugänglich gemacht werden, allerdings ohne diese Einschränkung.
Artikel 6 Buchstabe a verlangt gesondert, dass eine visuelle Werbung
für ein bestimmtes Modell sowohl die Effizienzklasse als auch die auf
dem Label verfügbare Klassenspanne trägt. Die EPREL-Datenbank
verlangt von Lieferanten seit dem 1. Januar 2019, jedes neue Modell
zu registrieren. Die Folge reicht bis in den Feed:
[Google Merchant Center](https://support.google.com/merchants/answer/7052112)
verlangt seit April 2025 einen EPREL-Registrierungscode im
Zertifizierungsattribut für betroffene, auf die EU ausgerichtete
Produkte und beschränkt sein Energieeffizienzklasse-Attribut inzwischen
auf die Schweiz, Norwegen und das Vereinigte Königreich.

Die Kanäle haben diese Felder bereits abgebildet.
[Allegros API](https://developer.allegro.pl/documentation) führt
verantwortliche Personen und verantwortliche Hersteller als eigene
Ressourcen, dazu Sicherheitsinformationen je Angebot und ein Flag für
Produkte, die vor der GPSR-Pflicht vermarktet wurden. Heureka
dokumentiert eigene Tags für die postalische und elektronische
Adresse des Herstellers. Diese Felder brauchen also ein System of
Record, das sie pro Markt und pro Sprache attestieren kann, und
häufig hält kein bestehendes System eines vor: Ein ERP erfasst einen
Lieferanten statt einer verantwortlichen Person, und ein Storefront
speichert Text statt einer Attestierung. Die praktikable Lösung ist
ein Metafeld oder Attributset pro Markt im Storefront, befüllt beim
Onboarding des Lieferanten statt bei der Listung, wobei die Prüfung
auf leere Felder auf neue und bearbeitete Produkte angewendet wird
und nicht rückwirkend. Als Gate für neue Listings und als Bericht
für den Bestandskatalog einsetzen: Angewendet auf einen Katalog mit
Tausenden SKUs von Dutzenden Lieferanten hebt eine harte Sperre die
Veröffentlichung des Shops am Tag ihrer Aktivierung auf.

## B2B-Preisgestaltung ist auf jeder Plattform ein anderer Mechanismus

Adobe legt B2B-Preise in Shared Catalogs ab, die Teil des Moduls
Adobe Commerce B2B sind und deshalb bei Magento Open Source oder
Mage-OS nicht verfügbar sind. Aktiviert man sie, erhält der
Kundengruppen-Selektor auf der Produktseite
[Advanced Pricing](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/pricing-advanced)
eine Option für Shared Catalog, sodass sich dieselbe Staffeltabelle
von beiden Seiten bearbeiten lässt.

Shopify führt B2B über dieselbe Katalog- und Price-List-Mechanik wie
Märkte, wobei der Katalog auf einen Firmenstandort begrenzt ist. Die
Einschränkung liegt in den Plangrenzen. Shopifys
[B2B-Katalogdokumentation](https://help.shopify.com/en/manual/b2b/catalogs)
erklärt, dass sich auf den Plänen Basic, Grow und Advanced „bis zu 3
aktive Kataloge für alle Ihre B2B-Märkte zuweisen“ lassen, während
Plus eine unbegrenzte Anzahl sowie die direkte Zuordnung zu Firmen
und Standorten bietet (geprüft am 4. August 2026). Gelten für einen
Firmenstandort mehrere Kataloge, wird der niedrigste Preis angezeigt.
Microsofts
[Dokumentation zum Business-Central-Connector](https://learn.microsoft.com/en-us/dynamics365/business-central/shopify/synchronize-items)
erklärt, dass die B2B-Preissynchronisierung ein Shopify-Plus-Abonnement
voraussetzt und die Katalogzugehörigkeit im Shopify-Admin verwaltet
wird, nicht im ERP.

Die Eigentumsregel, die daraus folgt, ist bei beiden Plattformen
gleich: Das ERP besitzt, was ein bestimmter Kunde vertraglich zu
zahlen hat, und die Plattform besitzt, welchem Katalog dieser Kunde
zugeordnet ist. Eine weitergehende Aufteilung verlagert
Vertragsbedingungen in ein Merchandising-Tool.

## Wann sich ein PIM lohnt

Ein PIM ist seinen Preis wert, sobald sprach- und kanalspezifische
Werte nicht mehr in die Plattform passen. Beide führenden Optionen
bilden das direkt ab, und ihre Lizenzierung unterscheidet sich so
deutlich, dass sie die Wahl bereits vor den Funktionen entscheidet.

Akeneos Mechanismus besteht aus zwei unabhängigen Flags je Attribut,
localizable und scopable. Ein Produktwert ist ein Tripel aus Locale,
Scope und Daten, und ein Channel bündelt die Locales, Währungen, den
Kategoriebaum und die Umrechnungseinheiten für ein Publikationsziel.
Die Community Edition ist Open Source unter OSL-3.0 und wird aktiv
gepflegt, mit Release v2026.3, getaggt am 30. März 2026, und Akeneo
beschränkt seine End-of-Support-Tabelle auf die kostenpflichtigen
Editionen, nicht auf die Community. Die Einschränkung betrifft
Upgrades: Die Community ist auf Kalenderversionierung umgestiegen,
und Akeneo schließt Abwärtskompatibilität zwischen zwei beliebigen
Releases ausdrücklich aus. Kommerziell verkauft Akeneo drei
SaaS-Stufen, und die Vergleichsseite rendert die Preise clientseitig
per Skript statt als statischen Text, weshalb wir daraus keinen
Betrag zitieren. Für Akeneo kursieren Preisangaben von Drittanbietern;
keine davon ist auf einer Akeneo-Seite bestätigt, und wir geben sie
nicht wieder.

Pimcore, mit Sitz in Salzburg, hat die Lizenz auf eine Weise
geändert, die für die Leserschaft dieses Artikels unmittelbar
relevant ist.
[Seit Plattformversion 2025.1 ist es nicht mehr Open Source](https://pimcore.com/en/resources/blog/breaking-free-pimcore-says-goodbye-to-gpl-and-enters-a-new-era-with-pocl):
Der öffentlich verfügbare Code steht unter der Pimcore Open Core
Licence, einer Source-Available-Lizenz, und die eigene
`composer.json` im aktuellen Branch deklariert die Lizenz als
proprietär. Der
[Lizenztext](https://raw.githubusercontent.com/pimcore/pimcore/2026.x/LICENSE.md)
gestattet die kostenfreie Produktivnutzung nur Organisationen, deren
weltweiter Gesamtumsatz jährlich 5 Millionen Euro nicht übersteigt,
selbstzertifiziert und einer Prüfung mit rückwirkenden Gebühren
unterworfen, untersagt es, Pimcore als gehosteten oder verwalteten
Dienst anzubieten, untersagt den parallelen Betrieb von unter GPLv3
lizenziertem Pimcore und enthält eine Telemetrie-Klausel, mit der
sich der Lizenznehmer verpflichtet, nicht einzugreifen. Die
[veröffentlichten Listenpreise](https://pimcore.com/en/pricing)
betragen 9.900 US-Dollar pro Jahr für Professional und 29.900
US-Dollar für Enterprise, jeweils On-Premises, mit PaaS auf Anfrage.
Für einen Shop mit mehr als 5 Millionen Euro Umsatz ist Pimcore ein
kommerzieller Lizenzkauf.

## Die Vorgehensweise

Erstellen Sie die Feldliste, bevor Sie sich für ein Tool
entscheiden. Benennen Sie für jedes Feld das System, das den Wert
erstellt und pflegt, den Geltungsbereich, in dem die Plattform ihn
speichern kann, und was geschieht, wenn beide Seiten voneinander
abweichen. Die Richtung ergibt sich aus dem ersten Punkt: Das System
of Record schreibt, alles andere liest, weshalb ein Feld mit zwei
Schreibenden keinen Eigentümer hat. Prüfen Sie danach drei Dinge, an
denen die meisten Entwürfe scheitern: dass der angenommene
Geltungsbereich tatsächlich existiert (Preis pro Store View gibt es
bei Magento nicht), dass das Datenmodell des Eigentümers die
benötigte Bandbreite trägt (fünf Währungen, fünf Staffeln, drei
zusätzliche Locales), und dass kein weiteres System dasselbe Feld
unbemerkt mitschreibt. Die bidirektionale Bearbeitung eines Feldes in
zwei Systemen ist der Entwurf, den es zu vermeiden gilt, und man
gerät meist eher durch Unterlassung als durch bewusste Entscheidung
hinein.

Legen Sie anschließend die Weitergabe fest, im Bewusstsein, dass die
Erstbefüllung und der eingeschwungene Zustand unterschiedliche
Systeme sind. Die anfängliche Katalogbefüllung ist ein Batch-Job:
Shopifys Bulk Operations verarbeiten JSONL und laufen asynchron,
Magento verfügt über die asynchrone Bulk-REST-Schnittstelle und den
CSV-Import. Der eingeschwungene Zustand ist ein Delta, und der
Mechanismus richtet sich danach, was der Eigentümer liefern kann.
Ein ERP, das nur einen nächtlichen Dateiexport bietet, kann nichts
pushen, wie auch immer der Entwurf aussieht; das Delta wird also zu
einem geplanten Pull mit einem Changed-since-Filter, und die
Aktualität des Storefronts ist durch das Exportintervall begrenzt,
unabhängig davon, was jemand zugesagt hat. Der Abgleich ist die
dritte, nicht optionale Aufgabe: ein regelmäßiger vollständiger
Vergleich, der findet, was das Delta übersehen hat, denn ein Feed,
den niemand prüft, driftet unbemerkt ab.

Bei Shopify folgt aus der Funktionsweise von
[`productSet`](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model/sync-data)
eine weitere Regel: Innerhalb eines gesendeten Listenfelds löscht es
die Einträge, die Sie weglassen, sodass eine unvollständige
Variantenliste die fehlenden Varianten entfernt. Setzen Sie es nur
dort ein, wo das sendende System die gesamte Liste besitzt, die es
sendet, und verwenden Sie die gezielten Mutationen dort, wo das
Eigentum aufgeteilt ist.

Diese Feldliste zu erstellen und die Integrationen zu bauen, die sie
tragen, ist Aufgabe unseres
[Integrationsservice](/de/services/integrations/), und die
individuelle Arbeit oberhalb des Datenmodells der Plattform ist
[individuelle Entwicklung](/de/services/custom-development/). Für
welche Tools Sie sich auch entscheiden, die Feldliste ist die
Grundlage, auf der die Integration entsteht.