Wenn Phoca Cart als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn Phoca Cart als Zielplattform ausgewählt oder konkret für die Auswahl vorbereitet wird, muss die Vorbereitung die vielen Strukturen unterscheiden, die neben einem Product bestehen können. Attribute können Varianten erzeugen und Preise beeinflussen, Spezifikationen den Vergleich unterstützen, Parameter Filter ermöglichen, Kundengruppen Preise und Shop-Zugriff verändern, Download-Dateien von Order-Beziehungen abhängen und Joomla-Menüs, Sprachen, Module, Templates sowie Zugriffsebenen bestimmen, wie der Shop erreichbar ist.
Das Vorbereitungspaket sollte für jeden wesentlichen Bereich eine Aktion, einen Verantwortlichen, einen Nachweis und eine eindeutige Bereitschaftsbedingung festlegen. Die Bedeutung der Quelldaten muss durch ausgewählte Stichproben, Backups, Inventare, Beziehungsübersichten und ausdrückliche Bereitschaftsentscheidungen erhalten bleiben.
Zugriff auf Joomla, Phoca Cart, Hosting und Dateien absichern
Bestätigen Sie den Zugriff auf Joomla-Administration, Phoca-Cart-Administration, Hosting, Datenbank, Dateisystem, Product-Bilder, Download- und Upload-Dateien, geplante Prozesse und externe Dienste. Dokumentieren Sie Joomla- und Phoca-Cart-Versionen, PHP- und Datenbankumgebung, Sprachen, Template, Zugriffsebenen, aktivierte Module/Plugins, Zahlungs- und Versandmethoden sowie individuellen Code.
| Vorbereitung | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Administrativen Zugriff bestätigen | Joomla-/Phoca-Cart-Administrator | Funktionierende Konten und Rollenübersicht | Products, Attribute, Customers, Orders, Module und Konfiguration können geprüft werden. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortlicher | Datenbankexport, Dateisystemarchiv, geschützte Download-/Upload-Verzeichnisse und benannter Restore-Verantwortlicher | Der Quell-Shop kann wiederhergestellt werden, ohne vom Live-Shop abhängig zu sein. |
| Umgebung und Erweiterungen erfassen | Technischer Verantwortlicher | Inventar von Joomla, Phoca Cart, PHP, Datenbank, Template, Modulen, Plugins und Sprachen | Versions- und erweiterungsabhängige Datensätze sind dokumentiert. |
| Anpassungen erfassen | Entwicklungsverantwortlicher | Template-Overrides, individuelle Felder, Custom SQL, Quellcodeänderungen und individuelle Plugins | Jede Anpassung, die Commerce-Datensätze liest oder schreibt, hat einen Verantwortlichen. |
| Verbundene Systeme zuordnen | Integrationsverantwortliche | Endpunkte und IDs für Feeds, ERP, CRM, POS, Buchhaltung, Zahlung, Versand und Marketplaces | Fortzuführende Systeme und maßgebliche Werte sind bekannt. |
Erhalten Sie IDs für Products, Categories, Hersteller, Attribute, Spezifikationen, Parameter, Customers, Kundengruppen, Orders, Order-Positionen, Status, Bonuspunkte, Reviews, Formularfelder, Feeds und externe Systeme, sofern diese benötigt werden, um Beziehungen wiederherzustellen.
Products, Categories, Hersteller, Bilder und Bestand vorbereiten
Phoca-Cart-Products können Kennungen, Beschreibungen, Categories, Hersteller, Bilder, Video, Preise, Steuern, Bestand, Abmessungen, Bonuspunkte, Downloads, Tags, Labels, Sprachzuordnungen, Metadaten, verwandte Products und externe Schlüssel enthalten. Bereiten Sie die Datensätze entsprechend Verkaufsverhalten und betrieblicher Bedeutung vor.
| Product-Muster | Vorzubereitende Nachweise | Bereitschaftsbedingung |
|---|---|---|
| Einfaches Product | Product-ID, SKU/EAN/MPN, Preis, Steuer, Bestand, Category, Hersteller, Medien und Beispiel-Order | Ein Datensatz identifiziert den verkauften Artikel eindeutig. |
| Attributbasiertes Product | Attributdefinitionen, Optionen, Kombinationen, Preiseffekte, Bestandsberechnung, Bilder und Order-Stichprobe | Jede kaufbare Variante und ihre Optionswerte sind nachvollziehbar. |
| Download-Product | Product-Datei, attribut-/optionsbezogene Dateien, Pfad, Ablaufzeit, Download-Anzahl und abgeschlossene Order | Eigentum an geschützten Dateien und Order-basierter Zugriff sind dokumentiert. |
| Product in mehreren Categories | Product-zu-Category-Beziehungen, priorisierte Route und Sprachumfang | Auffindbarkeitsbeziehungen bleiben ohne Product-Duplikation erhalten. |
| Product mit Bonuspunkten | Erforderliche/verdiente Punkte, Product-Bezug, Customer-Historie und geltende Regeln | Bonusbeziehungen sind von gewöhnlichen Preisdaten getrennt. |
| POS- oder eingereichtes Product | POS-/Quellkontext, Einreicher, Status, Kennungen und zugehöriger Product-Datensatz | Nicht standardmäßige Erstellungswege besitzen einen eindeutigen Verantwortlichen. |
Dokumentieren Sie Veröffentlichungsstatus, reinen Katalogmodus, Bestandsstatus, Mindest- und Mehrfachmengen, externe IDs, Feed-Felder und Sprachzuordnungen. Eine leere Mengenangabe, unbegrenzter Bestand und ein ausverkauftes Product dürfen nicht als derselbe Zustand behandelt werden.
Attribute, Spezifikationen, Parameter, Tags und individuelle Felder trennen
Phoca Cart unterscheidet mehrere Systeme für Product-Informationen. Attribute können Varianten erzeugen und Preise verändern. Spezifikationen unterstützen Vergleich und Filterung, ohne den Preis zu verändern. Parameter bilden eine weitere Filterstruktur. Tags und Labels dienen überwiegend visuellen oder klassifizierenden Aufgaben. Zusätzliche Product-Felder können Kennungen, Feed-Werte, Medien, Abmessungen und externe Referenzen enthalten.
| Struktur | Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Attribut und Option | Attributtyp, Pflicht-/Standardstatus, Optionswerte, Kombinationsverhalten, Preiseffekt, Bild, Bestand und Product-Zuordnungen | Kaufbare Auswahlmöglichkeiten werden nicht zu beschreibenden Feldern abgeflacht. |
| Spezifikation | Spezifikationsgruppe/-wert, Product-Beziehungen, Vergleichs-/Filternutzung und Sprache | Beschreibende Vergleichsdaten bleiben von Varianten getrennt. |
| Parameter | Parameter/Wert, Product-Zuordnungen, Such-/Filternutzung und Routen | Filterbeziehungen sind dokumentiert, ohne Preiseffekte zu erfinden. |
| Tag oder Label | Typ, Wert, Darstellungszweck, Product-Zuordnungen und Sprache | Visuelle Labels werden nicht mit zentralen Product-Categories verwechselt. |
| Zusätzliches Product-Feld | Feldname, geschäftliche Bedeutung, Datentyp, externer Verbraucher und Product-Schlüssel | Betriebs- und Integrationswerte haben einen benannten Verantwortlichen. |
Erstellen Sie eine normalisierte Begriffswelt erst, nachdem Definitionen und Zuordnungen des Quell-Shops gesichert sind. Ähnliche Bezeichnungen können unterschiedliche Funktionen haben; eine Product-Familie kann Attribute verwenden, während eine andere Spezifikationen nutzt.
Preise, Kundengruppen, Steuern, Rabatte und Bonuspunkte vorbereiten
Phoca Cart kann Products mit Kundengruppenpreisen verbinden, Preis- und Add-to-Cart-Sichtbarkeit nach Gruppe steuern, Product- oder Warenkorbrabatte anwenden, mehrere Steuern und Währungen nutzen und Bonuspunkt-Datensätze führen. Bereiten Sie diese Elemente als Beziehungen statt als isolierte Zahlenfelder vor.
| Kommerzieller Bereich | Vorzubereitende Nachweise | Bereitschaftsbedingung |
|---|---|---|
| Product-Preise | Product-/Varianten-ID, Kundengruppe, Währung, Betrag, Datum/Bedingung und Quellverantwortlicher | Jeder Preis ist dem richtigen Product und Käuferkontext zugeordnet. |
| Kundengruppen | Gruppendefinition, zugeordnete Customers, Sichtbarkeitseinstellungen, Preisverhalten und Automatisierungsregel | Gruppenbedeutung ist über die Bezeichnung hinaus dokumentiert. |
| Steuern | Steuersatz/-klasse, Länder-/Regions-/Zonenumfang, Product-/Category-Zuordnungen und historische Order-Beispiele | Aktive Steuerkonfiguration ist von historischen Steuerbeträgen getrennt. |
| Rabatte und Coupons | Regeltyp, Products/Categories, Mengen-/Betragsschwellen, Gruppe, Datumsgrenzen und historische Nutzung | Aktive Regeln und historische Nachweise sind unterscheidbar. |
| Bonuspunkte | Customer, Product, verdiente/eingelöste Punkte, Saldo und Transaktionskontext | Loyalty-Historie besitzt ein benanntes Ziel oder einen fortbestehenden Eigentümer. |
| Bestand | Product/Variante, Menge, Berechnungsmethode, Mindest-/Mehrfachmenge, Standort-/POS-Verantwortung und externer Schlüssel | Die maßgebliche verkaufbare Menge ist bekannt. |
Wenn ERP, POS, Marketplace oder Lieferanten-Feed Preis oder Bestand verantwortet, dokumentieren Sie die Startwerte getrennt von dem System, das sie künftig laufend pflegt.
Customers, Joomla-Benutzer, Formulare, Reviews und Adressen vorbereiten
Die Vorbereitung der Customers sollte Joomla-Benutzer, Phoca-Cart-Customers, Kundengruppen, Rechnungs- und Lieferadressen, individuelle Formularfelder, Loyalty-Kennungen, Bonuspunkte, Reviews, Newsletter-Status und externe CRM- oder Buchhaltungsschlüssel miteinander verbinden.
| Kontobereich | Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Registrierter Customer | Joomla-Benutzer-ID, Customer-ID, E-Mail, Status, Gruppe, Adressen, Loyalty-Nummer und externe IDs | Doppelte und systemübergreifende Identitäten besitzen eine beabsichtigte Behandlung. |
| Gast-Customer | Name, E-Mail, Rechnungs-/Lieferwerte und Order-Referenzen auf Transaktionsebene | Gast-Historie bleibt erhalten, ohne ein Konto zu erfinden. |
| Checkout-Formularfeld | Felddefinition, Typ, Pflicht-/Anzeigeregeln, Zugriffsebene, Kundengruppe und gespeicherte Werte | Individuelle Customer-Daten gehen nicht verloren und werden nicht falsch klassifiziert. |
| Review | Product, Customer-/Gastidentität, Bewertung, Text, Datum, Status und Sprache | Reviews bleiben mit dem vorgesehenen Product und Moderationsstatus verbunden. |
| Bonus- oder Loyalty-Datensatz | Customer-Schlüssel, Saldo, Transaktionsquelle und Product-/Order-Kontext | Loyalty-Daten verfügen über vollständige Eigentumsnachweise. |
| Authentifizierung | Lokales Passwort, SSO/Social Login, Reset-Ablauf und Kommunikationsverantwortlicher | Kontozugriff wird geplant, ohne Passwort-Portabilität vorauszusetzen. |
Nehmen Sie Customers mit mehreren Adressen, Kundengruppenpreisen, Loyalty-Daten, Reviews, individuellen Feldern und wichtigen Orders in die Stichproben auf. Diese Fälle machen Beziehungen sichtbar, die bei gewöhnlichen Retail-Konten nicht auftreten.
Orders, Rechnungen, Downloads, Versand, Zahlung und POS-Historie vorbereiten
Phoca-Cart-Orders können Online- oder POS-Herkunft, Order-Nummer, Token, Customer- oder Gastidentität, Adressen, Product-Positionen, Attribute, Steuern, Rabatte, Zahlung und Versand, Status, Kommentare, Datenschutz-/AGB-Nachweise, Tracking, Rechnungs-/Belegnummern, Download-Links und externe Referenzen enthalten.
| Order-Nachweis | Verantwortlicher | Bereitschaftsbedingung |
|---|---|---|
| Order-Kopf und Herkunft | Commerce-/POS-Verantwortlicher | Order-Nummer, Kanal, Customer-/Gastidentität, Datum, Sprache und Status sind dokumentiert. |
| Product-Positionen und Attribute | Katalog- und Order-Verantwortliche | Product-IDs, SKUs, gewählte Attribute, Mengen, Preise, Steuern und Snapshot-Text sind vollständig. |
| Summen und Rabatte | Finanzverantwortlicher | Zwischensumme, Product-/Warenkorbrabatt, Coupon, Steuer, Versand, Zahlungskosten, Bonuspunkte und Endsumme stimmen überein. |
| Zahlung, Versand und Tracking | Finanz-/Auftragsabwicklungsverantwortliche | Historische Methodenbezeichnungen, Referenzen, Carrier, Tracking und Versanddatum sind bekannt. |
| Rechnung, Beleg und Lieferschein | Finanzverantwortlicher | Nummerierung, Daten, Dateien/Layoutdaten und Order-Beziehungen können wiederhergestellt werden. |
| Download-Zugriff | Verantwortlicher für digitale Auslieferung | Dateien, Ablauf, maximale Download-Anzahl, Product-/Attributbeziehung und Order sind verknüpft. |
| Externe Referenzen | Integrationsverantwortlicher | POS-, ERP-, Buchhaltungs-, Marketplace- oder Auftragsabwicklungs-IDs bleiben nachvollziehbar. |
Wählen Sie, sofern vorhanden, gewöhnliche, Gast-, attributintensive, rabattierte, Bonuspunkt-, erstattete oder angepasste, herunterladbare, POS-, mehrsprachige und getrackte Versand-Orders.
Joomla-Routen, Sprachen, Zugriffsebenen, Module und Medien vorbereiten
Phoca Cart ist vollständig in Joomla integriert. Menüs, Zugriffsebenen, Sprachzuordnungen, Module, Template-Overrides, Filter-/Suchmodule, Medienpfade und Metadaten können bestimmen, ob migrierte Commerce-Datensätze auffindbar bleiben.
| Shop-Bereich | Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Product- und Category-URLs | Quellroute, Alias, Menükontext, Sprache, Metadaten und Zielabsicht | Für wichtige Pfade besteht eine eindeutige Entscheidung: behalten, ändern, zusammenführen, stilllegen oder weiterleiten. |
| Joomla-Menüs und Zugriff | Menüelementtyp, Parent, Alias, Zugriffsebene, Sprache und Ziel | Katalogeinstiege und eingeschränkte Routen sind dokumentiert. |
| Module und Filter | Modultyp, Position, Menüzuordnung, Attribut-/Spezifikations-/Parameterquelle und Verantwortlicher | Auffindbarkeitsverhalten ist von Product-Daten getrennt. |
| Mehrsprachige Zuordnungen | Product-/Category-/Begriffszusammenhänge, Sprachen, Menüs und Medien | Übersetzungen werden nicht wie unabhängige Duplikate behandelt. |
| Template-Overrides | Override-Dateien, betroffene Ansichten, individuelle Felder und Modulpositionen | Darstellungsabhängigkeiten sind getrennt von Commerce-Datensätzen dokumentiert. |
| Medien und geschützte Dateien | Product-Bilder, Thumbnails, Videos, Downloads/Uploads, Remote-Speicher und Dateisystemberechtigungen | Wichtige Dateien sind verfügbar und mit den richtigen Datensätzen verbunden. |
Der allgemeine Joomla-CMS-Umfang verantwortet allgemeine Articles und CMS Pages. Hier werden nur die Joomla-Strukturen erfasst, die direkt Phoca-Cart-Routen, Zugriff, Auffindbarkeit und Commerce-Medien beeinflussen.
Module, Plugins, Feeds, individuellen Code und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeitsregister für Zahlung, Versand, Suche, Filter, Marken, Vergleich, Wunschlisten, POS, Feeds, Importe/Exporte, Buchhaltung, ERP, CRM, Marketplaces, Analysen und individuelle Änderungen.
| Abhängigkeit | Vorzubereitende Nachweise | Bereitschaftsbedingung |
|---|---|---|
| Phoca-Modul oder -Plugin | Name, Version, Zweck, Product-/Customer-/Order-Abhängigkeiten und Konfiguration | Von Erweiterungen verwaltete Datensätze haben ein vorgesehenes Ziel oder einen fortbestehenden Eigentümer. |
| XML-/CSV-Feed | Feed-Definition, Product-Felder, Category-Zuordnung, Kennungen, Verbraucher und Zeitplan | Kanaldaten sind vom maßgeblichen Product-Modell getrennt. |
| POS-Integration | Standort-/Gerätekontext, Product-/Bestandsverantwortung, Customer-/Order-IDs und Synchronisationsprozess | Online- und POS-Historie werden nicht fälschlich zusammengeführt. |
| Individuelle Tabelle oder Quellcodeänderung | Schema, Schlüssel, Geschäftszweck und nutzender Code | Individuelle Datensätze können interpretiert statt blind kopiert werden. |
| Externes System | Endpunkt, Datenverantwortung, Synchronisationsrichtung, IDs und Cutover-Verantwortlicher | Systemübergreifende Identität bleibt nutzbar. |
| Generierte Daten | Caches, Thumbnails, Logs, temporäre Feeds, Sessions und Indizes | Nicht maßgebliche technische Daten werden bewusst ausgeschlossen. |
Open-Source-Anpassungen machen die Prüfung des Quellsystems besonders wichtig. Ein vertrauter Feldname kann durch individuellen Code oder SQL-Änderungen lokales Verhalten erhalten haben.
Repräsentative Migrationsstichproben auswählen
Dokumentieren Sie für jede Stichprobe Quell-IDs, SKUs, URLs, zugehörige Datensätze, Sprache, Kundengruppe, externen Schlüssel und den Grund für die Auswahl.
| Stichprobe | Vorzubereitende Nachweise | Zweck der Vorbereitung |
|---|---|---|
| Einfaches Product | Preis, Bestand, Steuer, Category, Hersteller, Bilder und Order | Definiert die gewöhnliche Product-Baseline. |
| Attributvariante | Attribute/Optionen, Pflicht-/Standardstatus, Preis-/Bild-/Bestandseffekte und Order-Position | Deckt kaufbares Variantenverhalten ab. |
| Product mit Spezifikationen/Filtern | Spezifikationen, Parameter, Tags, Categories und Filtermodule | Deckt beschreibende Beziehungen und Auffindbarkeit ab. |
| Kundengruppenfall | Customer, Gruppe, Product-Preis/-Sichtbarkeit, Formularfelder und Order | Deckt segmentierten Commerce ab. |
| Komplexe Order | Gast-/registrierte Identität, Attribute, Rabatte, Steuern, Bonuspunkte, Zahlung, Versand, Tracking und Rechnung | Deckt historischen kommerziellen Kontext ab. |
| Download-Product/-Order | Dateien, geschützter Pfad, attribut-/optionsbezogene Datei, Ablauf, Anzahl und Order | Deckt digitale Auslieferung ab. |
| Mehrsprachige Route | Zugeordnete Products/Categories, Aliase, Menüs, Metadaten und Redirect-Absicht | Deckt Joomla-Sprach- und Routingumfang ab. |
| POS- oder Erweiterungsdatensatz | Kerndatensatz, Kanal-/Erweiterungsverantwortlicher, externe ID und zugehörige Orders | Macht Nicht-Kernabhängigkeiten vor der Ausführung sichtbar. |
Die Vorbereitung repräsentativer Migrationsstichproben definiert Stichproben und Quellnachweise. Spätere Pass-, Watch- oder Block-Entscheidungen gehören in den Validierungsablauf.
Abschließende Bereitschaft für Phoca Cart prüfen
| Bereitschaftsbereich | Bereitschaftsbedingung |
|---|---|
| Zugriff und Wiederherstellung | Joomla, Phoca Cart, Hosting, Datenbank, geschützte Dateien, Backups und Restore-Verantwortung sind bestätigt. |
| Katalog | Products, Categories, Hersteller, Attribute, Spezifikationen, Parameter, Medien, Downloads, Bestand, Preise und Kennungen sind dokumentiert. |
| Customers | Joomla-Benutzer, Customers, Gruppen, Formulare, Adressen, Reviews, Bonuspunkte und Authentifizierungsabhängigkeiten sind klassifiziert. |
| Orders | Online-/POS-Herkunft, Positionen, Attribute, Summen, Status, Zahlung, Versand, Rechnungen, Downloads und externe IDs haben Nachweise. |
| Shop | Menüs, Zugriff, Sprachen, Module, Filter, Overrides, URLs, SEO und Medien sind dokumentiert. |
| Abhängigkeiten | Plugins, Module, Feeds, individueller Code, externe Systeme und Datenverantwortliche sind benannt. |
| Stichproben | Repräsentative Datensätze decken alle wesentlichen Katalog-, Customer-, Order-, Routen-, Download-, POS- und Erweiterungsmuster ab. |
Der Phoca-Cart-Umfang ist bereit, wenn jeder wesentliche Datensatz einen Quellverantwortlichen, eine Übersicht seiner Beziehungen, einen Nachweis und eine Entscheidung für Ziel oder fortbestehendes System besitzt.
Fazit
Die Vorbereitung auf Phoca Cart erfordert koordinierte Nachweise über Joomla, Products, Attribute, Spezifikationen, Parameter, Kundengruppen, Customers, Orders, Downloads, POS, Routen, Module, Plugins, Feeds und externe Systeme. Diese Strukturen müssen vor der Migrationsausführung nach ihrer geschäftlichen Bedeutung getrennt werden.
Ein belastbares Vorbereitungspaket sichert wiederherstellbare Backups, dokumentiert maßgebliche Datensätze, trennt historische Transaktionen von aktiver Konfiguration, wählt repräsentative Stichproben und weist jeder wesentlichen Abhängigkeit einen Verantwortlichen und eine Bereitschaftsbedingung zu.
Häufige Fragen
Was sollte für eine Phoca-Cart-Migration zuerst vorbereitet werden?
Bestätigen Sie den Zugriff auf Joomla, Phoca Cart, Hosting, Datenbank, Dateisystem, geschützte Download-/Upload-Verzeichnisse und Erweiterungen. Erstellen Sie wiederherstellbare Backups und dokumentieren Sie Software- und Anpassungsinventar, bevor die detaillierte Katalogarbeit beginnt.
Was ist bei der Vorbereitung der Unterschied zwischen Attributen und Spezifikationen?
Attribute können Product-Varianten erzeugen und Preis, Bild, Bestand oder Käuferauswahl beeinflussen. Spezifikationen beschreiben Products für Vergleich und Filterung, ohne den Preis zu verändern. Definitionen und Product-Zuordnungen sollten getrennt bleiben.
Warum sollten Parameter und Tags getrennt inventarisiert werden?
Parameter können Filter und durchsuchbare Werte unterstützen, während Tags und Labels meist visuelle oder klassifizierende Aufgaben erfüllen. Eine Zusammenführung kann Auffindbarkeit im Shop und die Bedeutung historischer Daten verändern.
Wie sollten Daten zu Kundengruppen vorbereitet werden?
Dokumentieren Sie Gruppendefinitionen, zugeordnete Customers, Product-Preise, Anzeige- und Add-to-Cart-Einstellungen, Attributsichtbarkeit, Rabattregeln und automatische Zuordnungskriterien. Die Gruppenbezeichnung allein ist kein ausreichender Nachweis.
Welche Orders sollten im Stichprobenregister enthalten sein?
Berücksichtigen Sie Online- und POS-Orders, Gäste und registrierte Käufer, attributintensive Positionen, Rabatte, Steuern, Bonuspunkte, Erstattungen oder Anpassungen, Downloads, Tracking, Rechnungen und externe Referenzen, die Kundenservice oder Finanzen benötigen.
Wie sollte die Vorbereitung zwischen Joomla und Phoca Cart aufgeteilt werden?
Der Joomla-Umfang verantwortet allgemeine CMS-Inhalte, Benutzer, Menüs, Module, Templates und Zugriffsarchitektur. Die Phoca-Cart-Vorbereitung verantwortet Commerce-Products, Customers, Orders, Attribute, Bestand, Bonuspunkte und Erweiterungen und dokumentiert nur die Joomla-Abhängigkeiten, die für diese Datensätze erforderlich sind.