Bei der Bewertung von Phoca Cart als mögliche Zielplattform zeigt das Datenmodell, wie Quelldaten, Beziehungen und geschäftliche Bedeutung in der Zielumgebung abgebildet werden müssen.
Wenn Phoca Cart als mögliche Zielplattform bewertet wird, muss die Datenstruktur zusammen mit der Joomla-Umgebung betrachtet werden, in der sie betrieben wird. Phoca Cart ist eine Joomla-native Commerce-Komponente mit eigenen Strukturen für Products, Categories, Customers, Orders, Preise, Steuern, Bestand und Kundenvorteile. Joomla stellt zugleich Benutzer, Zugriffsebenen, Menüs, Module, Templates, Sprachkontext, Routing und die weitere Erweiterungsumgebung bereit. Eine Migration muss deshalb sowohl die Commerce-Datensätze als auch die Joomla-Beziehungen übertragen beziehungsweise neu herstellen, durch die diese Datensätze auffindbar und nutzbar werden.
Phoca Cart trennt außerdem mehrere Konzepte, die Quellplattformen häufig zusammenfassen: Product-Optionen, Attribute, Spezifikationen, Kundengruppenpreise, Rabatte, Coupons, Bonuspunkte, Steuersätze, Währungen, Bestandsstatus und Download-Zugriff. Ein Feldname allein reicht nicht aus, um den richtigen Zielort zu bestimmen. Entscheidend ist, wie ein Wert Kaufvorgänge, Administration und die Interpretation historischer Daten beeinflusst.
Product-Identität und Katalogbeziehungen
Ein Phoca-Cart-Product kann mit Categories, Herstellern, Bildern, Attributen, Optionen, Spezifikationen, verwandten Products, Downloads, Bestand, Preisen, Rabatten, Steuern, Reviews, sprachspezifischen Inhalten und Kundengruppenregeln verbunden sein. Der Product-Datensatz ist daher nur das Zentrum eines Beziehungsnetzes.
| Bedeutung im Quell-Shop | Möglicher Eigentümer in Phoca Cart | Zu erhaltende Beziehung |
|---|---|---|
| Grundlegende Product-Identität | Product-Datensatz | Name, Alias, Code/SKU, Beschreibungen, Veröffentlichungsstatus und Sprache |
| Platzierung im Katalog | Phoca-Cart-Categories | Zuordnung von Products zu Categories und beabsichtigte Hierarchie |
| Markenidentität | Hersteller-Datensatz, Category oder externer Schlüssel | Zuordnung Product zu Hersteller sowie Nutzung für Navigation oder Integrationen |
| Product-Medien | Product-Bilder, Download-Dateien oder Inhaltsressourcen | Rolle, Reihenfolge, Sichtbarkeit und Zugriff |
| Auswahl durch Käufer | Options- oder Attributbeziehung | Gewählter Wert im Verhältnis zu Preis, Bestand, Bild oder Bedeutung der Order-Position |
| Beschreibende Daten | Attribut, Spezifikation, Parameter oder Inhaltsfeld | Zweck für Anzeige, Vergleich, Filterung oder Administration |
| Käuferspezifischer Vorteil | Kundengruppe, Preis, Rabatt, Coupon oder Bonusdatensatz | Berechtigung des Customers für das jeweilige kommerzielle Ergebnis |
Ein Quell-Product mit separaten untergeordneten SKUs kann als getrennte Products bestehen bleiben oder über Optionen dargestellt werden. Entscheidend ist, ob Phoca Cart für jede Auswahl eine eigenständige Bestands-, Preis-, Bild-, Code- oder Auftragsabwicklungsidentität benötigt. Unterschiedliche verkaufbare Artikel sollten nicht nur deshalb zusammengelegt werden, damit die Zielseite einfacher aussieht.
Optionen, Attribute, Spezifikationen und Parameter
Die wichtigste Unterscheidung im Phoca-Cart-Katalog betrifft die Funktion einzelner Product-Detailwerte.
- Optionen stehen für Auswahlmöglichkeiten des Käufers, die am Kauf beteiligt sind.
- Attribute können Products beschreiben oder je nach Umsetzung Bestandteil einer Optionsstruktur sein.
- Spezifikationen strukturieren vergleichbare technische oder beschreibende Informationen.
- Parameter und individuelle Werte können Anzeige, Filterung, Import/Export, Module oder individuellen Code unterstützen.
Ein Quellfeld wie „Größe“ zeigt das Problem. Es kann eine auswählbare Konfektionsgröße, eine Verpackungsabmessung, einen Filterwert oder interne Lagerinformation darstellen. Diese Bedeutungen benötigen unterschiedliche Eigentümer auf der Zielplattform.
| Verhalten im Quell-Shop | Interpretation im Ziel | Zu erhaltende Bedeutung |
|---|---|---|
| Auswahl verändert Bestand oder Product-Code | Strukturierte Option/Attribut oder separate Product-Beziehung | Bestands- und Order-Positionsidentität |
| Auswahl verändert nur den Preis | Optionswert mit Preisbeziehung | Gewählter Wert und Preisanpassung |
| Käufer gibt Text ein | Eingabeorientiertes Feld oder Erweiterungsdatensatz | Eingegebener Wert an der richtigen Order-Position |
| Technische Spezifikation | Spezifikation oder beschreibendes Attribut | Bezeichnung, Wert, Gruppe, Reihenfolge und Vergleichsnutzung |
| Such- oder Filtermerkmal | Strukturiertes Attribut oder von Filtern genutzter Parameter | Normalisierter Wert und Filterzugehörigkeit |
| Interner Betriebswert | Individuelles Feld oder Datensatz eines externen Systems | Administrative Verantwortlichkeit ohne unbeabsichtigte Anzeige im Shop |
Definitionen und Product-Zuordnungen sollten getrennt bleiben. Eine Spezifikationsgruppe, Attributdefinition oder Optionsdefinition kann von vielen Products gemeinsam genutzt werden, während der konkrete Product-Wert oder die zulässige Auswahl zur jeweiligen Product-Beziehung gehört.
Preise, Bestand, Rabatte, Coupons und Bonuspunkte
Phoca Cart kann unterschiedliche Arten kommerzieller Werte darstellen. Grundpreis, Kundengruppenpreis, Product-Rabatt, Warenkorbrabatt, Coupon, Bonuspunkte, Steuer, Währung und Bestandsstatus sind getrennte Konzepte. Werden sie in einem einzigen „Preis“-Feld zusammengeführt, geht die Regel verloren, die erklärt, wann und für wen ein Wert gilt.
| Kommerzielle Regel im Quell-Shop | Phoca-Cart-Beziehung | Zu klärende Frage |
|---|---|---|
| Großhandels- oder Mitgliederpreis | Kundengruppe plus Product-Preis | Welche Customers gehören zur Gruppe und für welche Products gilt der Preis? |
| Product-spezifische Aktion | Product-Rabatt und seine Bedingungen | Ist der Rabatt ein gespeicherter Betrag, ein Prozentsatz oder eine zeitabhängige Regel? |
| Warenkorbaktion | Warenkorbrabatt oder Coupon | Welche Warenkorbkriterien und Nutzungslimits bestimmen die Berechtigung? |
| Loyalty-Guthaben | Bonuspunkte-Datensatz des Customers | Ist Phoca Cart oder ein anderes System die maßgebliche Quelle für den Saldo? |
| Bestandsverfügbarkeit | Product-Bestand, Optionsbestand und Bestandsstatus | Gehört der Bestand zum Product oder zu einer bestimmten Auswahl? |
| Mehrwährungswert | Währungs- und Preis-/Anzeigebeziehung | Welcher Betrag wird gespeichert und welcher nur zur Anzeige umgerechnet? |
Historische Order-Summen sollten Preis-, Rabatt-, Coupon-, Bonus-, Steuer-, Versand-, Zahlungs- und Währungsinformationen so erhalten, wie sie zum Kaufzeitpunkt aufgezeichnet wurden. Diese historischen Werte ersetzen keine aktiven Zielregeln. Neue Warenkörbe verwenden die aktuelle Phoca-Cart-Konfiguration und Plugin-Logik.
Bonuspunkte benötigen eine eindeutige Verantwortlichkeit. Customer-Saldo, durch eine Order verdiente Punkte, eingelöste Punkte und die Regel zur Umrechnung in einen Wert sind miteinander verbunden, aber unterschiedliche Datensätze. Wird nur der Saldo migriert, bleiben Historie und Berechtigungslogik möglicherweise ungeklärt.
Categories, Hersteller, Suche und Joomla-Navigation
Phoca-Cart-Categories und Hersteller gehören zum Commerce-Katalog. Joomla-Menüs und -Module stellen ausgewählte Product-, Category-, Hersteller-, Such-, Filter-, Vergleichs- oder andere Ansichten für Käufer bereit. Eine Navigationsstruktur des Quell-Shops kann daher mehrere Zielbeziehungen benötigen und nicht nur einen einzigen Category-Baum.
| Struktur im Quell-Shop | Mögliches Ziel | Zu erhaltende Bedeutung |
|---|---|---|
| Product-Category | Phoca-Cart-Category und Product-Zuordnungen | Kataloghierarchie und Gruppierung für Käufer |
| Markenseite | Hersteller-Datensatz plus Menü- oder Modulziel | Markenidentität, Navigation und Filterung |
| Dynamische Collection | Filter, Suchregel, Modulabfrage, Category oder individuelle Logik | Mitgliedschaftsregel statt nur aktueller Product-IDs |
| Featured- oder Latest-Block | Joomla-Modulkonfiguration | Abfrage, Sortierung, Zielgruppe und Platzierung |
| Vergleich oder Wunschliste | Phoca-Cart-Customer-/Sitzungsdatensätze und Module | Product-Beziehungen und bei dauerhafter Speicherung die Kontozuordnung |
| Eingeschränkter Katalog | Joomla-Zugriffsebene, Kundengruppe oder Erweiterung | Wer Products sehen oder kaufen darf |
Joomla-Categories und Phoca-Cart-Categories sind nicht automatisch dieselbe Taxonomie. Joomla-Categories organisieren Datensätze innerhalb der jeweiligen Joomla-Komponente; Phoca Cart verwaltet sein eigenes Commerce-Category-Modell. Sie sollten nicht zusammengeführt werden, nur weil die Bezeichnungen übereinstimmen.
Suche und Filterung hängen von normalisierten Product-Werten ab. Enthalten Quellattribute unterschiedliche Schreibweisen, Einheiten oder Werteformate, kann das Ziel jeden einzelnen Textwert erhalten und trotzdem brauchbares Filterverhalten verlieren. Entscheidend ist die Beziehung zwischen Product, Attribut- oder Spezifikationsdefinition und normalisiertem Wert.
Customers, Joomla-Benutzer, Gruppen und Adressen
Ein registrierter Phoca-Cart-Customer kann mit einem Joomla-Benutzer verknüpft sein. Kundengruppen können Preise und Vorteile beeinflussen, während Joomla-Zugriffsebenen die Sichtbarkeit auf der Website steuern können. Adressen, Steuerdaten, Unternehmensangaben, Bonuspunkte, Wunschlisten und Orders können unterschiedlichen Teilen dieser Customer-Beziehung gehören.
| Customer-Wert | Geeigneter Eigentümer | Grund |
|---|---|---|
| Login-Identität und Aktivierungsstatus | Joomla-Benutzer | Steuert die Authentifizierung |
| Zugriffsrolle auf der Website | Joomla-Benutzergruppe/Zugriffsebene | Steuert Sichtbarkeit von Inhalten und Komponenten |
| Kommerzielles Segment | Phoca-Cart-Kundengruppe | Kann Preise, Rabatte oder andere Vorteile beeinflussen |
| Wiederverwendbare Rechnungs-/Lieferadresse | Phoca-Cart-Customer-/Adressdatensatz | Gehört zum Customer-Lebenszyklus |
| Gastadresse | Historische Order | Gehört zu einer einzelnen Transaktion |
| Bonusguthaben | Phoca-Cart-Bonusdatensätze oder externes Loyalty-System | Erfordert ein maßgebliches Ledger |
| Steuer- oder Unternehmenskennung | Customer, Adresse, Order oder externes System | Verantwortlichkeit hängt von Wiederverwendung und rechtlichem Zweck ab |
Joomla-Benutzergruppen und Phoca-Cart-Kundengruppen dürfen nicht als austauschbar vorausgesetzt werden. Die eine Struktur kann CMS-Zugriffe steuern, die andere die kommerzielle Behandlung. Manche Shops verbinden beide über individuelle Logik; diese Verbindung ist jedoch selbst eine Beziehung, die identifiziert werden muss.
Gast-Customers sollten von registrierten Konten unterscheidbar bleiben. Eine E-Mail-Adresse in einer Order belegt nicht, dass ein dauerhaftes Joomla-Benutzerkonto existierte. Werden aus sämtlichen Gastbestellungen Konten erzeugt, können doppelte Identitäten entstehen.
Orders, Rechnungen, Zahlungen und Versandnachweise
Phoca-Cart-Orders können Product- und Optionsdetails, Adressen, Customer-Kontext, Preise, Rabatte, Coupons, Bonuspunkte, Steuern, Versand, Zahlung, Währung, Status, Notizen und Rechnungsreferenzen enthalten. Eine Order sollte den Zustand der Transaktion zum Kaufzeitpunkt bewahren, statt sich ausschließlich auf den aktuellen Product- oder Customer-Datensatz zu stützen.
| Order-Beziehung | Zu erhaltende Bedeutung |
|---|---|
| Order zu Customer oder Gast | Beim Kauf verwendete Identität |
| Order-Position zu Product und Optionswerten | Exakt gekaufte Konfiguration |
| Order-Position zu Preis und Rabatt | Historische Zusammensetzung des Betrags |
| Order zu Coupon- oder Bonusnutzung | Auf die Transaktion angewendeter Vorteil |
| Order zu Steuer, Versand und Zahlung | Historischer finanzieller und logistischer Kontext |
| Order zu Status und Zeitstempeln | Betrieblicher Verlauf |
| Order zu Rechnungs- oder Belegreferenz | Dokumentkontinuität, sofern erforderlich |
| Order zu externer ID | Kontinuität zu ERP, POS, Buchhaltung, Versanddienstleister oder Marketplace |
Phoca Cart kann Rechnungs- und Point-of-Sale-Abläufe unterstützen. Diese Fähigkeiten dürfen nicht aus einer einzelnen Order-Tabelle abgeleitet werden. Online- und Offline-Transaktionen können Products, Customers, Bestand und Dokumentnummern gemeinsam nutzen und zugleich zusätzliche POS- oder Rechnungsdatensätze besitzen. Das Zielmodell muss festlegen, welches System für jede Nummernfolge und externe Referenz maßgeblich ist.
Zahlungs- und Versand-Plugins schaffen ebenfalls eine Trennung zwischen historischen Nachweisen und aktivem Verhalten. Eine alte Order benötigt gegebenenfalls lesbare Methodennamen, Beträge, Tracking- und Anbieterreferenzen. Das aktuelle Ziel benötigt dagegen eine eigene Plugin-Konfiguration.
Inhalte, Sprachen, URLs und Shop-Darstellung
Phoca Cart läuft innerhalb von Joomla. Product- und Category-Datensätze sind daher nur ein Teil des kundenseitigen Ergebnisses. Joomla-Menüs, Module, Templates, Sprachzuordnungen, Zugriffsebenen, Routing und Inhaltsseiten bestimmen Auffindbarkeit und Darstellung mit.
Ein Quell-Shop kann Product-Daten mit Kaufratgebern, Vergleichsseiten, Herstellerseiten, Blog Posts, Landingpages und Download-Ressourcen verbinden. Diese Inhalte sollten dem Zieldatensatz zugeordnet werden, der ihren Lebenszyklus verantwortet:
- Product-spezifische Verkaufsinhalte können in Product-Feldern liegen;
- Einleitungen zu Categories können Category-Inhalte werden;
- allgemeiner redaktioneller Inhalt kann zu Joomla CMS Pages oder Blog Posts werden;
- modulbasierte Product-Blöcke bleiben Joomla-Präsentationskonfiguration;
- Downloads können je nach Zweck zum Product-Zugriff oder zu CMS-Inhalten gehören.
Mehrsprachige Beziehungen können übersetzte Products, Categories, Hersteller, Attribute, Spezifikationen, Menüs, Module, Metadaten und URLs umfassen. Nur den übersetzten Text zu kopieren, ohne Sprach- und Routenbeziehungen zu erhalten, erzeugt voneinander getrennte Inhalte.
Die Verantwortung für URLs ist geteilt. Product- und Category-Aliase liefern die Commerce-Identität, während Joomla-Menükontext und Routing den sichtbaren Pfad bestimmen können. Das Ziel sollte kanonische Zielseiten festlegen und Redirects mit ihnen verbinden, statt die vollständige Quell-URL wie ein einzelnes Product-Feld zu behandeln.
Plugins, Module, Importe, POS und externe Systeme
Phoca Cart ist modular. Zahlungs- und Versand-Plugins, Such- und Filtermodule, PDF-Erzeugung, Newsletter, Open-Graph-Integration, Import-/Export-Abläufe, POS-Funktionen, Template-Overrides und individuelle Joomla-Erweiterungen können Daten außerhalb der Standardstrukturen für Products, Customers und Orders erzeugen oder verwenden.
| Abhängigkeit | Zusätzliche Daten oder Annahmen | Frage für das Ziel |
|---|---|---|
| Import-/Export-Ablauf | Spaltenzuordnungen, externe IDs, Zeitpläne, transformierte Werte | Bleibt Phoca Cart oder ein externer Prozess maßgeblich? |
| POS-Ablauf | Offline-Orders, Bestandsaktualisierungen, Dokumentnummern, Kassen- oder Standortkontext | Welche Datensätze werden mit dem Online-Commerce gemeinsam genutzt? |
| Such-/Filtermodul | Indexierte Werte, Parameterdefinitionen, Abfragekonfiguration | Welche Product-Beziehungen steuern die Auffindbarkeit? |
| Zahlungs-/Versand-Plugin | Anbieterreferenzen, Tracking, Methodenmetadaten, individuelle Status | Was ist historischer Nachweis und was aktive Konfiguration? |
| PDF- oder Rechnungserweiterung | Dokumenttemplates, Nummerierung, erzeugte Dateien | Welche Kennungen und Dateien müssen fortgeführt werden? |
| ERP-, Buchhaltungs-, Marketplace- oder Feed-Integration | Stabile Product-, Customer-, Order-, Steuer- und Bestandsschlüssel | Welches System verantwortet welche Kennung? |
| Template-Override | Erwartete Felder, Modulpositionen, Routing-Annahmen | Welche migrierten Datensätze müssen weiterhin adressierbar sein? |
Das Vorhandensein einer Erweiterung sollte eine Frage nach der Datenverantwortung auslösen, nicht die Annahme, dass sämtliche zugehörigen Datensätze in ein allgemeines individuelles Feld gehören. Manche Werte gehören zu Phoca Cart, andere zu Joomla und wieder andere zum externen System, das sie erzeugt hat.
Wie Unterschiede in Phoca Cart den Migrationsumfang verändern
Der Phoca-Cart-Umfang sollte zwischen diesen Behandlungsarten unterscheiden:
| Behandlung | Typische Beispiele | Auswirkung auf den Umfang |
|---|---|---|
| Direkte Übertragung von Datensätzen | Products, Categories, Hersteller, Customers, Orders, Medien | Unterstützte Felder und Kennungen zuordnen |
| Rekonstruktion von Beziehungen | Optionen, Attribute, Spezifikationen, Kundengruppen, Bonusdatensätze, Vorteile in Orders | Definitionen, Zuordnungen und Verantwortlichkeitsbeziehungen neu herstellen |
| Joomla-Präsentationsstruktur | Menüs, Module, Templates, Routen, Zugriff, Sprachkontext | Der Implementierung der Ziel-Website zuordnen |
| Plugin- oder Prozessdaten | POS, Rechnungen, Importe, Zahlungs-/Versandmetadaten, Suchindizes | Aktuelles Ziel oder historisches Archiv definieren |
| Kontinuität externer Systeme | ERP-, Buchhaltungs-, Marketplace-, Loyalty-, Carrier- und Feed-IDs | Dauerhafte Schlüssel und klar benannte Verantwortlichkeit erhalten |
| Bewusste Stilllegung | Veraltete Module, ungenutzte Parameter, doppelte Routen, aufgegebene Integrationen | Mit dokumentierter Begründung ausschließen |
Ein schlüssiges Zielmodell ermöglicht es Mitarbeitern, ein Product über Category, Option, Spezifikation, Preis, Bestand, Kundengruppenregel, Order-Position, Joomla-Route und externe Kennung hinweg nachzuvollziehen, ohne raten zu müssen, welches System den jeweiligen Wert verantwortet.
Fazit
Die Unterschiede im Phoca-Cart-Datenmodell entstehen aus dem Zusammenspiel einer umfangreichen Commerce-Komponente mit der Joomla-Website darum herum. Products können von Categories, Herstellern, Optionen, Attributen, Spezifikationen, Preisen, Bestand, Vorteilen, Steuern, Plugins und mehrsprachigen Inhalten abhängen. Customers können sich über Joomla-Benutzer, Zugriffsebenen, Phoca-Cart-Gruppen, Adressen, Bonuspunkte und Orders erstrecken. Routen und Darstellung im Shop bleiben Joomla-Beziehungen.
Eine belastbare Migration ordnet jeden Wert anhand seiner Funktion zu. Käuferauswahlen bleiben mit dem richtigen Product und der richtigen Order-Position verbunden; beschreibende Werte bleiben für Anzeige und Filterung nutzbar; historische Summen bleiben von aktiven Regeln getrennt; und Plugin- oder externe Systemdaten erhalten eine eindeutige Verantwortlichkeit. So bleibt erhalten, wie der Shop tatsächlich funktioniert, und nicht nur, wie seine Tabellen benannt waren.
Häufige Fragen
Was ist der praktische Unterschied zwischen einer Phoca-Cart-Option und einer Spezifikation?
Eine Option ist Teil der Kaufentscheidung des Käufers. Eine Spezifikation beschreibt oder vergleicht das Product. Dieselbe Bezeichnung, etwa Größe oder Material, kann je nach Wirkung auf das gekaufte Ergebnis in die eine oder andere Struktur gehören.
Sollten Joomla-Categories und Phoca-Cart-Categories zusammengeführt werden?
Nicht automatisch. Sie gehören zu unterschiedlichen Joomla-Komponenten und können unterschiedliche Aufgaben erfüllen. Phoca-Cart-Categories organisieren Commerce-Datensätze, während Joomla-Categories die Datensätze der jeweiligen CMS-Komponente strukturieren.
Wie sollten Kundengruppen und Joomla-Benutzergruppen übertragen werden?
Behandeln Sie sie als getrennte Beziehungen, sofern keine ausdrückliche Logik des Shops beide miteinander verbindet. Joomla-Gruppen können den Website-Zugriff steuern; Phoca-Cart-Gruppen können Preise, Rabatte oder andere kommerzielle Behandlung bestimmen.
Gehören Bonuspunkte nur zum Customer-Saldo?
Nein. Saldo, verdiente Punkte, eingelöste Punkte, zugehörige Orders und Umrechnungsregeln können getrennte Datensätze sein. Das Ziel benötigt eine maßgebliche Verantwortlichkeit für die vollständige Loyalty-Beziehung.
Können historische Steuer-, Zahlungs- und Versanddaten dieselben Datensätze wie aktive Checkout-Regeln verwenden?
Historische Orders sollten Beträge, Bezeichnungen und Referenzen so erhalten, wie sie beim Kauf aufgezeichnet wurden. Aktive Zielregeln und Plugins steuern neue Transaktionen und bleiben eine separate Konfigurationsebene.
Wie sollten POS- oder Import-/Export-Daten behandelt werden?
Bestimmen Sie, welche Products, Bestandsdatensätze, Orders, Dokumentnummern und externen Kennungen mit Phoca Cart gemeinsam genutzt werden. Dauerhafte Geschäftsschlüssel sollten erhalten bleiben, während der aktuelle Betriebszustand dem System zugeordnet wird, das künftig maßgeblich bleibt.