Wenn EShop by Ossolution Team als mögliche Zielplattform betrachtet wird, muss das Datenmodell als Verbindung zweier Ebenen gelesen werden: EShop besitzt eigene Katalog-, Customer-, Order-, Preis-, Rabatt-, Steuer-, Versand-, Zahlungs- und Checkout-Datensätze, während Joomla Identität, Routing, Module, Sprachen, Templates und den allgemeinen Website-Kontext bereitstellt. Eine belastbare Datenübersetzung bewahrt die Grenze zwischen diesen Ebenen und unterscheidet historische Geschäftsdaten von aktiver Zielkonfiguration.
Ähnlich benannte Quellfelder können deshalb unterschiedliche Zielrepräsentationen benötigen. Ein Quell-„Attribut“ kann eine auswählbare Product-Option, ein Informationsattribut, ein benutzerdefiniertes Product-Feld, ein Product-Tab, ein Checkout-Feld oder eine externe Kennung sein. Eine Kundengruppe im Quellshop kann Preise statt Berechtigungen steuern. Ein Seitenpfad kann von Joomla-Menüeinträgen abhängen, statt direkt zum Product zu gehören. Datenmodellentscheidungen beginnen daher mit Bedeutung und Verantwortung, nicht mit Feldnamen.
EShop verbindet Commerce-Datensätze mit der Joomla-Seitenstruktur
EShop besitzt die zentralen Shop-Datensätze. Joomla besitzt allgemeine Website-Identität, Navigation, Module, Templates, Sprachen, Zugriff und die Erweiterungsinfrastruktur. Zahlungs-, Versand-, Import-, Auswertungs- und Integrations-Plugins können zusätzliche Daten oder Referenzen einführen.
| Verantwortungsebene | Typische Datensätze | Folge für die Datenübersetzung |
|---|---|---|
| EShop-Katalog | Products, Categories, Manufacturers, Optionen, Attribute, benutzerdefinierte Felder, Anhänge, Preise, Bestand | Product-Beziehungen erhalten und auswählbare Optionen von beschreibenden Informationen trennen. |
| EShop-Geschäftshistorie | Customers, Gruppen, Adressen, Orders, Order-Positionen, Gutscheincodes, Wertgutscheine, Steuern, Versand, Zahlung, Status | Historische Momentaufnahmen und Beziehungen erhalten, die Transaktionen erklären. |
| Joomla-Kern | Benutzer, Menüeinträge, Module, Sprachen, Aliase, Templates, Zugriff | Routing-, Identitäts- und Präsentationskontext erhalten, ohne ihn als EShop-Katalogdaten zu behandeln. |
| EShop- und Joomla-Plugins | Zahlung, Versand, Importe, Module, Spezialfelder, Integrationen | Plugin-Verantwortung bestimmen und klären, ob ein Datensatz historisch, operativ oder extern ist. |
| Externe Systeme | ERP, CRM, POS, Auftragsabwicklung, Buchhaltung, Produktinformation | Stabile Kennungen an der EShop-Entität erhalten, die vom externen System erkannt wird. |
Diese Verantwortungslandkarte hält den Product-Datensatz von der Joomla-Seite getrennt, die ihn sichtbar macht, und trennt eine Zahlungsreferenz in einer Order von der Konfiguration des Zahlungs-Plugins für künftige Transaktionen.
Products, Categories, Manufacturers und Katalogbeziehungen
Ein EShop-Product kann an zahlreichen Katalogbeziehungen teilnehmen: Category-Zuordnung, Manufacturer-Identität, Medien, Preise, Bestand, Steuerklasse, Maße, Optionen, Attribute, benutzerdefinierte Felder, Tabs, Anhänge, verwandte Products, Metadaten, Aliase und sprachabhängige Werte. Quellplattformen können diese Konzepte anders kombinieren oder trennen.
Categories können hierarchisch aufgebaut sein und Product-Zuordnungen tragen. Manufacturers bilden eine separate markenähnliche Entität. Verwandte Products, Vergleichsdaten, Wunschlisten, Filter, Module und Suche können von der Product-Identität abhängen, ohne selbst Product-Felder zu sein.
| Quellkonzept | Mögliche EShop-Repräsentation | Zu erhaltende Beziehung |
|---|---|---|
| Product-Familie mit getrennten Child-SKUs | Parent-Product mit Optionen oder getrennte Products mit Merchandising-Beziehungen | Verkaufbare Identität, Bestand, Preis, Medien und externe IDs auf der richtigen Ebene |
| Marke oder Anbieter | Manufacturer | Product-to-Manufacturer-Beziehung, ohne die Marke in die Category-Taxonomie einzuordnen |
| Abteilungshierarchie | EShop-Category-Hierarchie | Parent-Child-Struktur, Product-Zuordnung, Aliase, Metadaten und Sprachkontext |
| Zugehöriger oder ergänzender Artikel | Related-Product-Beziehung | Richtung und Zweck der Product-to-Product-Verknüpfung |
| Download, Handbuch oder Datenblatt | Product-Anhang oder Product-Tab | Dateiverantwortung, Product-Beziehung, Titel, Sprache und Sichtbarkeit |
| Technische Product-Fakten | Attribut, benutzerdefiniertes Feld oder Product-Tab | Beschreibende Bedeutung ohne unnötige Kaufoptionen |
Die Zielrepräsentation sollte die Verwaltungslogik des Quellkatalogs erhalten. Zwei Products mit unterschiedlichen SKUs und Lageridentitäten dürfen nicht nur deshalb zusammengeführt werden, weil sie denselben Titel haben. Umgekehrt kann ein Quellsystem, das für jede Größe einen eigenen Datensatz anlegt, besser über EShop-Product-Optionen abgebildet werden, wenn die Kombinationen zu einem gemeinsamen Merchandising-Parent gehören.
Product-Optionen, Attribute, benutzerdefinierte Felder und Tabs sind nicht austauschbar
EShop trennt Käuferauswahl von beschreibenden Product-Informationen. Product-Optionen stellen Entscheidungen dar, die ein Customer vor dem Hinzufügen zum Warenkorb trifft, etwa Größe oder Farbe. Product-Attribute beschreiben Informationen für Detaildarstellung oder Vergleich. Benutzerdefinierte Felder können zusätzliche strukturierte Werte enthalten. Product-Tabs und Anhänge können erweiterte Inhalte, Videos, Dokumentation oder Dateien bereitstellen.
| EShop-Struktur | Hauptbedeutung | Quellbeispiele |
|---|---|---|
| Product-Option | Käuferauswahl, die die gekaufte Position beeinflussen kann | Größe, Farbe, Verpackung, Oberfläche, Servicelevel |
| Optionswert | Zulässige Auswahl innerhalb einer Option | Small, Medium, Blau, Geschenkbox |
| Product-Attribut | Informationsmerkmal für Beschreibung oder Vergleich | Material, Prozessor, Kapazität, Kompatibilität |
| Benutzerdefiniertes Product-Feld | Zusätzlicher strukturierter Wert außerhalb der Standardfelder | Regulierungscode, interne Klassifizierung, externe Referenz |
| Product-Tab | Erweiterter Inhaltsbereich auf der Product-Seite | Spezifikationen, Garantie, Video, Pflegehinweise |
| Anhang | Dateibeziehung zu einem Product | Handbuch, Zertifikat, Datenblatt, herunterladbares Dokument |
Eine Quelloption sollte nur dann zu einer EShop-Option werden, wenn die Auswahl Teil der gekauften Product-Position ist. Eine technische Spezifikation, die die kaufbare Auswahl nicht verändert, gehört eher in ein Attribut, ein benutzerdefiniertes Feld oder einen Inhaltsbereich. Eine unkontrollierte Vereinheitlichung dieser Strukturen kann unmögliche Optionskombinationen, doppelte Product-Seiten oder Order-Positionen erzeugen, die nicht mehr zeigen, was der Käufer tatsächlich gewählt hat.
Auch die kommerzielle Bedeutung auf Optionsebene muss erhalten bleiben. Wenn Quelloptionen Preis, SKU, Gewicht, Bild, Bestand oder Verfügbarkeit beeinflussen, muss die Zielrepräsentation diese Beziehungen zusammenhalten. Ein Label ohne zugehörige Geschäftslogik ist kein äquivalentes Datenmodell.
Customers, Joomla-Benutzer, Kundengruppen und Adressen haben unterschiedliche Bedeutung
EShop-Customers können mit Joomla-Benutzeridentitäten verbunden sein. Customer-Daten enthalten jedoch commerce-spezifische Beziehungen wie Adressen, Orders, Wunschlisten, Reward-Kontext und Gruppenzuordnung. Gast-Checkout kann historische Käufer- und Adressdaten erzeugen, ohne dass ein dauerhaftes Konto existiert.
Kundengruppen sind besonders wichtig, weil EShop sie für differenzierte Product-Preise verwenden kann. Eine Joomla-Benutzergruppe steht dagegen normalerweise für Berechtigungen oder Zugriff. Eine Quell-„Gruppe“ muss daher vor der Übersetzung nach ihrer Funktion klassifiziert werden.
| Quellrecord | Bedeutung im EShop- oder Joomla-Ziel |
|---|---|
| Registrierter Login | Joomla-Benutzeridentität, soweit unterstützt mit dem passenden EShop-Customer verknüpft |
| Commerce-Customer | EShop-Käuferprofil, Adressen, Order-Beziehungen und kommerzieller Gruppenkontext |
| Gastkäufer | Historische Identität und Adresse in Orders, ohne ein dauerhaftes Konto zu erfinden |
| Wholesale- oder Preisstufe | EShop-Kundengruppe, wenn sie kommerzielle Preise oder Berechtigung steuert |
| Administrator- oder Content-Rolle | Joomla-Benutzergruppe und Berechtigungsstruktur statt EShop-Kundengruppe |
| Organisation und Kontakte | Separate Organisations-/Kontaktstruktur, wenn ein einfacher Customer die Beziehung nicht erhalten kann |
Auch Adressen müssen nach ihrem Lebenszyklus übersetzt werden. Wiederverwendbare Customer-Adressen sind von historischen Order-Snapshots zu trennen. Ein Customer kann eine Adresse nach dem Kauf ändern; die historische Order benötigt weiterhin die Rechnungs- und Lieferdaten zum Transaktionszeitpunkt.
Orders bewahren Product-Auswahl, Checkout-Daten und Geschäftshistorie
Eine EShop-Order kann Customer- oder Gastidentität, Rechnungs- und Lieferadresse, Product-Positionen, ausgewählte Optionswerte, Mengen, Preise, Rabatte, Gutscheincodes, Wertgutscheine, Steuern, Versand, Zahlungsreferenzen, Währung, Status, benutzerdefinierte Checkout-Felder, Notizen und Zeitstempel enthalten. Diese Datensätze erklären, was geschehen ist; sie sind keine Anleitung dafür, wie das Ziel künftige Transaktionen berechnen soll.
| Order-Element | Historische Bedeutung |
|---|---|
| Product-Position | Gekaufte Product-Identität und Beschreibung zum Verkaufszeitpunkt |
| Ausgewählte Optionswerte | Tatsächliche Konfiguration des gekauften Products |
| Benutzerdefiniertes Checkout-Feld | USt-ID, Lieferanweisung, Abholdetail, Firmenreferenz oder anderer erfasster Wert |
| Preis, Rabatt, Gutscheincode, Wertgutschein und Steuer | Monetäre Momentaufnahme, die nicht unter neuen Regeln neu berechnet werden sollte |
| Versandmethode und Betrag | Ausgewählte Auftragsabwicklung und berechnete Versandkosten |
| Zahlungsmethode und Transaktionsreferenz | Historischer Zahlungskontext, keine aktive Gateway-Konfiguration |
| Währung | Für die Transaktion verwendete Währung und gespeicherte Summen |
| Statushistorie | Operative Lifecycle-Evidenz für Service und Auswertung |
Benutzerdefinierte Checkout-Felder benötigen eine eigene Zuordnungsentscheidung. Manche Werte beschreiben den Customer, andere eine Adresse, einige gelten nur für eine einzelne Order und wieder andere identifizieren ein externes Unternehmen oder einen Lieferprozess. Werden alle Checkout-Werte auf dem Customer-Profil gespeichert, können veraltete oder falsche Daten entstehen; werden alle nur als Freitext an einer Order abgelegt, können wiederverwendbare Geschäftskennungen unzugänglich werden.
Preise, Rabatte, Steuern, Versand und Zahlung haben Datensatz- und Konfigurationsseiten
EShop unterstützt Product-Preise, Kundengruppenpreise, Mengenrabatte, Gutscheincodes, Wertgutscheine, Steuersätze, geografische Zonen, Währungen sowie Versand- und Zahlungs-Plugins. Diese Konzepte haben zwei unterschiedliche Rollen im Datenmodell.
Erstens enthalten historische Orders das kommerzielle Ergebnis: berechnete Preise, angewandte Rabatte, gespeicherte Steuern, ausgewählten Versand, Zahlungsreferenzen und Währungssummen. Zweitens enthält der Zielshop aktive Regeln und Plugin-Konfiguration, die zukünftiges Verhalten bestimmen.
| Geschäftsbereich | Historischer Datensatz | Aktive Betriebsstruktur |
|---|---|---|
| Kundengruppenpreis | Preis oder Rabatt in vergangenen Order-Positionen | Aktuelle Product-to-Group-Preisbeziehung |
| Gutscheincode oder Wertgutschein | Code und Rabattwirkung in einer Order | Definition, Berechtigung, Laufzeit und verbleibende Nutzung |
| Steuer | Steuerbetrag und Label in der historischen Order | Steuerklasse, Steuersatz, Geozone und aktuelle Berechnungsregeln |
| Versand | Methodenlabel, Betrag, Adresse und Tracking-Kontext | Aktiviertes Versand-Plugin und aktuelle Tarifbedingungen |
| Zahlung | Methodenlabel, Transaktionsreferenz und Status | Aktiviertes Zahlungs-Plugin, Zugangsdaten und aktuelle Verarbeitungslogik |
| Währung | Gespeicherte Order-Währung und Summen | Veröffentlichte Währungen und aktuelles Wechselkursverhalten |
Diese Trennung verhindert, dass historische Daten durch aktuelle Regeln überschrieben werden, und verhindert umgekehrt, dass eine alte Order fälschlich als vollständige Betriebsconfiguration interpretiert wird.
Mehrsprachige Commerce-Daten und Joomla-Routen bilden ein gemeinsames Modell
EShop unterstützt mehrsprachige Shop-Daten; Joomla stellt die umfassenderen Beziehungen für Content-Sprache, Menüs, Module und Routen bereit. Products, Categories, Manufacturers, Optionen, Attribute, benutzerdefinierte Felder, Labels und Storefront-Texte können sprachabhängige Werte enthalten. Joomla-Menüeinträge und Module können für jede Sprache unterschiedliche Routen oder unterstützende Inhalte bereitstellen.
Eine Quellplattform, die alle Übersetzungen an einem Product speichert, kann sprachabhängige EShop-Werte benötigen. Ein Quellsystem mit getrennten Product-Datensätzen kann Zuordnungs- oder Kennungslogik brauchen, damit die Gleichwertigkeit erhalten bleibt. Interface-Übersetzungen und Sprach-Overrides müssen von übersetzten Geschäftsinhalten getrennt bleiben.
| Sprach- oder Routendatensatz | Bedeutung im Ziel |
|---|---|
| Übersetztes Product- oder Category-Feld | Kunden sichtbarer Commerce-Inhalt für eine bestimmte Sprache |
| Joomla-Inhaltssprache | Sprachzuordnung für Website- und Komponenten-Datensätze |
| Sprachspezifischer Menüeintrag | Öffentlicher Einstiegspunkt, Alias und Navigationskontext für eine Sprache |
| Sprachspezifisches Modul | Unterstützender Storefront-Block für ausgewählte Sprachkontexte |
| Interface-Sprachstring | Erweiterungs- oder Template-Text statt Product- oder Category-Inhalt |
| Product-Alias und Metadaten | SEO- und Routingwerte am jeweiligen Commerce-Datensatz |
Product-Datensatz und öffentliche Route müssen unterscheidbar bleiben. Ein Joomla-Menüeintrag kann auf eine EShop-Ansicht zeigen und den öffentlichen Pfad beeinflussen, während Product-Alias und EShop-Router eigene Routingbedeutung beitragen. Nur den Product-Titel zu übersetzen erhält diese kombinierte Struktur nicht.
Module, Templates, Themes und Layout-Overrides sind Präsentationsbeziehungen
EShop kann Products über Komponentenansichten, Joomla-Module, Joomla-Artikel, Suche, Filter und individuelle Layouts darstellen. Templates und Overrides können Product-, Category-, Cart-, Checkout- und Account-Ausgabe verändern, ohne die zugrunde liegenden Commerce-Datensätze zu ändern.
| Präsentationsobjekt | Datenmodellinterpretation |
|---|---|
| Product- oder Category-Modul | Wiederverwendbare Darstellung, die EShop-Datensätze abfragt |
| Joomla-Artikel mit eingebettetem Product-Output | Content-Datensatz, der eine EShop-Beziehung enthält oder aufruft |
| Template-Override | Renderinglogik statt portables Product-Feld |
| Theme- oder Layout-Einstellung | Präsentationskonfiguration getrennt von Katalogverantwortung |
| Filter- oder Suchmodul | Discovery-Oberfläche auf Basis von Attributen, Categories, Manufacturers oder anderen indexierten Daten |
| Individuelle Landingpage | Joomla- oder Builder-Content, der EShop-Products und -Categories referenziert |
Diese Trennung ermöglicht, dass Katalogdaten autoritativ bleiben, selbst wenn das Ziel einen anderen Page Builder, ein anderes Template oder ein anderes Storefront-Layout verwendet.
Plugins, Importe, individuelle Tabellen und externe Systeme erweitern das Kernmodell
EShop unterstützt Zahlungs- und Versand-Plugins, Importe und Exporte, Module, Integrationen, benutzerdefinierte Felder und eigene Layouts. Langjährig betriebene Shops können zusätzlich veränderte Tabellen, direkte SQL-Integrationen, geplante Synchronisierung, individuelle Reports oder Kennungen aus ERP, CRM, POS, Buchhaltung und Auftragsabwicklung enthalten.
| Signal aus einer Erweiterung | Erforderliche Interpretation |
|---|---|
| Zahlungstransaktionsreferenz | Historische Order-/Payment-Beziehung, die für Support oder Abstimmung relevant sein kann |
| Carrier- oder Auftragsabwicklungskennung | Shipment- oder Order-Beziehung für ein externes System |
| Product-Importschlüssel | Stabile Product- oder Optionskennung für wiederholte Synchronisierung |
| Individuelle Checkout-Tabelle | Order-, Customer-, Adress- oder Organisationswerte mit expliziter Verantwortung |
| Externe Product- oder Customer-ID | Kennung, die an der vom verbundenen System erkannten Zielentität verbleiben muss |
| Plugin-erzeugter Status oder Metadatenwert | Bedeutung wird vom Plugin definiert und nicht von einem gewöhnlichen EShop-Feld |
Das Ziel muss nicht jede Quelltabelle kopieren. Es benötigt jedoch für jeden geschäftskritischen Wert einen klaren Verantwortlichen und eine bewusste Entscheidung darüber, ob der Wert als natives EShop-Feld, Plugin-Datensatz, Joomla-Beziehung oder externe Systemreferenz weiterlebt.
Fazit
Eine Migration zu EShop übersetzt zwischen Katalog-, Transaktions-, Joomla-, Präsentations-, Plugin- und externen Systemebenen. Products, Optionen, Attribute, benutzerdefinierte Felder, Customers, Gruppen, Adressen, Orders, Checkout-Felder, Preise, Steuern, Versand, Zahlung, Sprachen, Menü-Routen und Module tragen jeweils unterschiedliche Verantwortungs- und Beziehungsbedeutung.
Ein kohärentes Zielmodell bewahrt diese Unterschiede, bevor Datensätze transformiert werden. Dadurch bleiben Käuferauswahlen an Product-Positionen gebunden, historische Summen an Orders, kommerzielle Gruppen von Joomla-Berechtigungen getrennt, Übersetzungen mit den richtigen Commerce-Datensätzen verbunden und externe Kennungen an den Entitäten erhalten, die verbundene Systeme tatsächlich verwenden.
Häufige Fragen
Sind EShop-Product-Optionen und Attribute dasselbe?
Nein. Optionen stellen auswählbare Käuferentscheidungen dar und können in der gekauften Position erscheinen. Attribute beschreiben Product-Informationen für Details oder Vergleiche. Benutzerdefinierte Felder, Tabs und Anhänge erfüllen zusätzliche beschreibende Rollen.
Sollte jede Product-Variation aus dem Quellshop zu einer EShop-Option werden?
Nur dann, wenn die Quelldatensätze Auswahlmöglichkeiten innerhalb eines gemeinsamen Merchandising-Products darstellen. Getrennte SKUs mit eigener URL, eigenem Lifecycle, Bestand, Medien oder externen Identitäten müssen möglicherweise getrennte Products bleiben oder eine bewusst geplante Parent-Child-Struktur erhalten.
Sind Joomla-Benutzergruppen und EShop-Kundengruppen gleichwertig?
Nein. Joomla-Benutzergruppen steuern normalerweise Berechtigungen und Zugriff. EShop-Kundengruppen können kommerzielle Segmentierung wie differenzierte Preise abbilden. Eine Quellgruppe muss entsprechend ihrer Funktion zugeordnet werden.
Wo sollten benutzerdefinierte Checkout-Felder gespeichert werden?
Das hängt von ihrer Bedeutung ab. Wiederverwendbare Identitätswerte können zu Customer oder Organisation gehören, Adresswerte zu einer Adresse und transaktionsspezifische Anweisungen oder Referenzen zur Order.
Bestimmen historische Orders künftiges Steuer-, Versand- und Zahlungsverhalten?
Nein. Orders bewahren Beträge, Labels, Referenzen und Entscheidungen zum Kaufzeitpunkt. Künftige Berechnung und Verarbeitung hängen von aktuellen Zielregeln und aktivierten Plugins ab.
Wie sollten Joomla-Menüeinträge rund um EShop-Products und -Categories behandelt werden?
Menüeinträge bleiben Routing- und Navigationsdatensätze, die auf EShop-Ansichten verweisen. Sie können Aliase, Hierarchie, Sprache, Zugriff und Template-Kontext beeinflussen, ersetzen aber nicht das zugrunde liegende EShop-Product oder die Category.