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, 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 (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 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; das Tolerieren einer wiederholten Nachricht ist ein Idempotent Receiver, 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. Hellands Life beyond Distributed Transactions (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, 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 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 und deaktiviert sie bei sku und media_gallery in der Konfiguration des Admin-Formulars (2.4-develop, geprüft am 4. August 2026). Ein Attribut, das als konfigurierbare Option verwendet wird, muss global sein, 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. 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 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

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, 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 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 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, 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, 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 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 (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 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, exportNaEshop bei einer ABRA-Flexi-Preislistenposition, dokumentiert im veröffentlichten Feldschema 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 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 (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 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 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 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 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 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 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: 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 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 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 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, und die individuelle Arbeit oberhalb des Datenmodells der Plattform ist individuelle Entwicklung. Für welche Tools Sie sich auch entscheiden, die Feldliste ist die Grundlage, auf der die Integration entsteht.