Wird VirtueMart als mögliche Zielplattform betrachtet, konzentriert sich die Fehlervermeidung auf wiederkehrende Probleme in Datenbeziehungen, Zielrepräsentation und Betrieb. Typische Fehler bei einer Migration zu VirtueMart entstehen, wenn ein mit Joomla verbundenes Commerce-Modell auf Produkte, Kunden und Bestellungen reduziert wird. Die tatsächliche Betriebsstruktur umfasst Parent und Child Products, Custom Fields, Shopper-Gruppen, Berechnungsregeln, Joomla-Identitäten, Routing, Layouts und Plugin-eigenes Verhalten. Fehler lassen sich nur vermeiden, wenn jedes wiederkehrende Muster früh erkannt, einem bewussten Ziel-Eigentümer zugewiesen und mit einer szenariospezifischen Pass-Bedingung abgeschlossen wird.
Fehler 1: Parent-, Child- und Custom-Field-Produktstrukturen verflachen
Was schiefgeht
VirtueMart kann eine verkaufbare Produktfamilie über Parent Products, abgeleitete Child Products und Custom Fields darstellen, die als Spezifikationen, Warenkorbattribute, Plugin-Ausgaben oder Varianten-Selektoren dienen. Nur den sichtbaren Parent-Datensatz zu übertragen kann SKU-spezifische Preise, Bilder, Bestand, Kategorie- und Auswahlverhalten löschen, während der Katalog scheinbar vollständig bleibt.
Frühe Warnsignale
Das Problem zeigt sich meist zuerst bei Produktfamilien, deren Auswahlen von Vererbung oder Custom-Field-Verhalten statt von gewöhnlichen Textfeldern abhängen.
| Warnsignal | Was es zeigt |
|---|---|
| Child Products fehlen oder erscheinen als unabhängige Produkte | Die Parent-Child-Abhängigkeit wurde nicht erhalten. |
| Ein Custom Field erscheint als Text, kann aber nicht ausgewählt werden | Ein Warenkorbattribut oder Plugin-gestütztes Feld wurde verflacht. |
| Varianten zeigen falsches Bild, falschen Preis oder Bestand | Child-Overrides wurden nicht der richtigen Auswahl zugeordnet. |
Prävention
Klassifizieren Sie jedes Custom Field nach Funktion und bilden Sie jede abgeleitete Produktbeziehung explizit ab. Bewahren Sie Parent-Kennung, Child-Kennung, Custom-Field-Typ, Warenkorbattribut-Verhalten und alle Plugin-Abhängigkeiten, die der Auswahl kommerzielle Bedeutung geben. Gehen Sie nicht davon aus, dass ein ähnlich benanntes Zielattribut dasselbe Verhalten reproduziert.
Empfehlungsbeispiel
Dokumentieren Sie bei einem konfigurierbaren Fahrrad, welche Werte vom Parent stammen, welche Werte jedes Child überschreibt und welche Custom Fields die Warenkorbposition verändern. Rekonstruieren Sie diese Beziehung, bevor Sie das Muster auf die übrigen Produktfamilien übertragen.
Pass-Bedingung
Ein Shopper kann jede vorgesehene Auswahl treffen, erhält die richtige SKU, den richtigen Preis, die richtigen Medien und den richtigen Bestand und sieht dieselbe Auswahl eindeutig in der Bestellung.
Fehler 2: Kategorie-, Hersteller-, Medien- und Related-Product-Beziehungen verlieren
Was schiefgeht
VirtueMart-Produkte können mehreren Kategorien angehören, auf Hersteller verweisen, Mediendatensätze gemeinsam nutzen und über System-Custom-Fields mit verwandten Produkten oder Kategorien verbunden sein. Diese Beziehungen als dekorative Felder zu behandeln kann Navigation, Auffindbarkeit, Merchandising und administrative Pflege beschädigen, selbst wenn Produktseiten weiterhin geöffnet werden können.
Frühe Warnsignale
Der Verlust von Beziehungen wird sichtbar, wenn dasselbe Produkt über einen Pfad auffindbar ist, in einem anderen kommerziellen Kontext aber verschwindet.
| Warnsignal | Was es zeigt |
|---|---|
| Ein Produkt erscheint nur in einer Kategorie | Mehrere Kategoriezuordnungen wurden zusammengefasst. |
| Herstellerseiten enthalten unvollständige Sortimente | Herstellerbeziehungen wurden nicht rekonstruiert. |
| Verwandte Artikel oder gemeinsam verwendete Medien fehlen | System-Custom-Fields oder Medienreferenzen wurden als gewöhnlicher Inhalt behandelt. |
Prävention
Erstellen Sie getrennte Beziehungsinventare für Kategorien, Hersteller, Medien, verwandte Produkte und verwandte Kategorien. Entscheiden Sie, ob gemeinsam verwendete Medien im Zielshop gemeinsam bleiben oder dupliziert werden, und bewahren Sie genügend Kennungen, um ein Bild oder eine Beziehung nicht dem falschen Produkt zuzuordnen.
Empfehlungsbeispiel
Wählen Sie ein Produkt, das mehreren Kategorien, einem Hersteller, gemeinsam genutzten Medien und zwei verwandten Produkten zugeordnet ist. Verfolgen Sie jede Beziehung von der Administration bis zur Auffindbarkeit im Shop, statt das Produkt nur über seine direkte URL freizugeben.
Pass-Bedingung
Repräsentative Produkte bleiben über alle vorgesehenen Kategorie- und Herstellerpfade auffindbar, zeigen die richtigen Medien und bewahren sinnvolle Related-Item-Beziehungen.
Fehler 3: Kommerzielle Regeln von Shopper-Gruppen verlieren
Was schiefgeht
VirtueMart-Shopper-Gruppen können Produktsichtbarkeit, Preise, Berechnungsregeln, Versandmethoden, Zahlungsmethoden und angezeigte Preiselemente beeinflussen. Ein Kundenlabel ohne die von dieser Gruppe gesteuerten Beziehungen zu migrieren kann einen Shop erzeugen, in dem das Konto vorhanden ist, aber die falsche kommerzielle Erfahrung erhält.
Frühe Warnsignale
Die ersten Hinweise sind meist inkonsistente Ergebnisse zwischen Gästen, Retail-, Wholesale- oder privilegierten Konten.
| Warnsignal | Was es zeigt |
|---|---|
| Wholesale-Kunden sehen öffentliche Preise | Gruppenspezifische Produktpreise oder Regeln wurden nicht zugeordnet. |
| Eine Zahlungs- oder Versandmethode erscheint für den falschen Käufer | Methodenberechtigung wurde von Shopper-Gruppen-Mitgliedschaft getrennt. |
| Eingeschränkte Produkte werden öffentlich | Produktsichtbarkeitsregeln wurden nicht abgebildet. |
Prävention
Inventarisieren Sie jede aktive Shopper-Gruppe und listen Sie jedes Verhalten auf, das sie steuert. Bewahren Sie die explizite Kundenmitgliedschaft getrennt von zielseitiger Preis-, Sichtbarkeits-, Steuer-, Zahlungs- und Versandkonfiguration. Wenn ein Kunde mehreren Gruppen angehört, erhalten Sie die kombinierte kommerzielle Bedeutung, statt ein einzelnes bequemes Label auszuwählen.
Empfehlungsbeispiel
Verwenden Sie einen Gast, einen normalen registrierten Kunden und einen Wholesale-Kunden, der zusätzlich für eine besondere Zahlungsmethode berechtigt ist. Vergleichen Sie Sortiment, angezeigte Preise, Steuerergebnis und verfügbare Checkout-Methoden für alle drei Identitäten.
Pass-Bedingung
Jeder repräsentative Kunde erhält den vorgesehenen Produktzugriff, die richtige Preisbehandlung, die passende Berechnungslogik und die berechtigten Checkout-Methoden seiner Gruppen.
Fehler 4: Joomla-Identität von VirtueMart-Shopper-Profilen trennen
Was schiefgeht
Ein VirtueMart-Käufer kann von einem Joomla-Benutzerkonto, VirtueMart-Benutzerinformationen, Rechnungs- und Versanddatensätzen und individuellen Shopper-Feldern abhängen. Nur Namen, E-Mail-Adressen und eine Adresse zu kopieren kann Login-Kontinuität, Kontodarstellung, rechtliche Felder, Lieferdaten und die Interpretation historischer Bestellungen zerstören.
Frühe Warnsignale
Identitätsprobleme werden sichtbar, wenn die Administration einen Kunden zeigt, Konto-, Adress- oder Bestellbeziehungen aber unvollständig sind.
| Warnsignal | Was es zeigt |
|---|---|
| Der Kunde existiert, kann aber nicht auf das erwartete Konto zugreifen | Joomla-Identität und Commerce-Profil wurden nicht verbunden. |
| Nur eine Adresse bleibt erhalten | Rechnungs- und Versanddatensätze wurden zusammengeführt oder überschrieben. |
| Individuelle Checkout-Daten fehlen in alten Bestellungen | Shopper-Field-Spalten oder Bestell-Snapshots wurden ausgelassen. |
Prävention
Modellieren Sie Joomla-Benutzeridentität, VirtueMart-Shopper-Informationen, Adressen und Shopper-Felder als verwandte, aber getrennte Datensätze. Bestimmen Sie, welche Felder Kontoeigenschaften sind, welche Bestellzeit-Snapshots darstellen und welche besondere Behandlung benötigen, weil sie durch ein Plugin oder eine individuelle Shopper-Field-Definition eingeführt wurden.
Empfehlungsbeispiel
Verfolgen Sie einen registrierten Käufer mit getrennten Rechnungs- und Versandadressen, Steuerkennung, individueller Lieferanweisung und mehreren historischen Bestellungen. Bestätigen Sie, welche Werte zum Konto gehören und welche in jeder Bestellung unverändert erhalten bleiben müssen.
Pass-Bedingung
Kundenidentität, Kontoverknüpfung, Adressen, erforderliche Shopper-Felder und historische Bestell-Snapshots bleiben intern konsistent und verständlich.
Fehler 5: Preise ohne Kontext der Berechnungsregeln rekonstruieren
Was schiefgeht
VirtueMart-Preisbildung kann Produktpreise, Währungen, Shopper-Gruppen, Kategorien, Hersteller, Länder, Regionen, Datumswerte, Steueroperationen, Rabatte und Regelreihenfolge kombinieren. Angezeigte Preise als feste Zahlen zu migrieren kann das gestrige Ergebnis bewahren und zugleich die Logik zerstören, die den morgigen Betrag erzeugen soll.
Frühe Warnsignale
Preisabweichungen werden sichtbar, wenn dasselbe Produkt je nach Käufer-, Standort-, Mengen- oder Datumsszenario andere Summen liefert.
| Warnsignal | Was es zeigt |
|---|---|
| Basispreise stimmen, Warenkorbsummen aber nicht | Berechnungsregeln oder ihre Reihenfolge wurden nicht rekonstruiert. |
| Rabatte gelten für die falsche Kundengruppe | Regeleinschränkungen wurden vom Shopper-Gruppen-Kontext getrennt. |
| Steuer oder Rundung unterscheidet sich in gemischten Warenkörben | Operationen pro Produkt und pro Rechnung wurden vermischt. |
Prävention
Dokumentieren Sie die aktive Kette der Berechnungsregeln und nicht nur den final angezeigten Betrag. Trennen Sie historische Bestellsummen von Live-Preis-Konfiguration, bewahren Sie Regeleinschränkungen und Prioritäten und identifizieren Sie Product-Level-Overrides, die allgemeine Regeln umgehen. Beziehen Sie Rundung und Währungsverhalten in die Rekonstruktionsentscheidung ein.
Empfehlungsbeispiel
Verwenden Sie ein Produkt mit kategoriesteuernder Steuerregel, ein Produkt mit explizitem Override und einen Wholesale-Preis. Berechnen Sie sie getrennt und gemeinsam für zwei Kundenstandorte, um Unterschiede in der Operationsreihenfolge sichtbar zu machen.
Pass-Bedingung
Repräsentative Kombinationen aus Produkt, Kunde, Standort und Warenkorb erzeugen die vorgesehenen Preisbestandteile und Endsummen, ohne auf kopierte historische Zahlen angewiesen zu sein.
Fehler 6: Bestand falsch zwischen Parent und Child Products zuordnen
Was schiefgeht
Bestand kann auf Child-Product-Ebene bedeutsam sein, während der Parent nur als Auswahlcontainer dient, oder der Shop kann Custom Fields und Plugins verwenden, die Verfügbarkeit verändern. Die gesamte Menge dem Parent zuzuweisen kann nicht verfügbare Varianten kaufbar und verfügbare Varianten ausverkauft erscheinen lassen.
Frühe Warnsignale
Bestandsfehler bleiben oft verborgen, bis ein Shopper ein bestimmtes Child oder eine bestimmte Optionskombination auswählt.
| Warnsignal | Was es zeigt |
|---|---|
| Der Parent zeigt Bestand, aber jede Auswahl ist nicht verfügbar | Bestand wurde dem Container statt den verkaufbaren Children zugeordnet. |
| Alle Varianten teilen unerwartet dieselbe Menge | Child-Level-Bestand wurde zusammengefasst. |
| Backorder- oder Verfügbarkeitslabels widersprechen der Menge | Plugin- oder Konfigurationsbedeutung wurde nicht berücksichtigt. |
Prävention
Identifizieren Sie für jede Produktfamilie den tatsächlich verkaufbaren Bestands-Eigentümer. Bewahren Sie Child-Kennungen, Mengen, Verfügbarkeitsstatus und jede Custom-Field-Beziehung, die zur Auswahl des bestandsführenden Datensatzes nötig ist. Halten Sie historische Mengennachweise getrennt vom Bestandsprozess, der nach dem Übergang Mengen pflegt.
Empfehlungsbeispiel
Setzen Sie für ein Produkt mit vier Child-SKUs bewusst unterschiedliche Mengen und Verfügbarkeitszustände. Bestätigen Sie, dass jede Shopper-Auswahl zum richtigen bestandsführenden Child führt und die Administration dieselbe Verantwortung zeigt.
Pass-Bedingung
Jede kaufbare Auswahl verweist auf den vorgesehenen Bestandsdatensatz, und nicht verfügbare Children können nicht über das Parent Product bestellt werden.
Fehler 7: Historische Zahlungs- und Versandlabels als Live-Methoden behandeln
Was schiefgeht
VirtueMart-Bestellungen speichern Zahlungs- und Versandkontext, Live-Checkout-Methoden werden jedoch von konfigurierten Plugins mit Einschränkungen und Zugangsdaten bereitgestellt. Ein altes Methodenlabel wie eine ausführbare Checkout-Methode zu verwenden verwechselt historischen Nachweis mit aktuellem Betriebsverhalten.
Frühe Warnsignale
Der Fehler zeigt sich, wenn alte Bestellungen lesbar sind, neue Warenkörbe aber die vorgesehene Methodenberechtigung oder Kosten nicht reproduzieren können.
| Warnsignal | Was es zeigt |
|---|---|
| Historische Methodennamen sind vorhanden, aber der Checkout bietet nichts an | Bestell-Snapshots wurden mit Live-Plugin-Konfiguration verwechselt. |
| Kosten unterscheiden sich nach Shopper-Gruppe oder Standort | Methodeneinschränkungen wurden nicht rekonstruiert. |
| Ein Legacy-Plugin-Name wird wie eine portable Fähigkeit behandelt | Die ausführbare Integration wurde nicht separat bewertet. |
Prävention
Bewahren Sie historische Methodennamen, Kosten und Referenzen als Bestellnachweise. Rekonstruieren Sie Live-Zahlungs- und Versandverhalten unabhängig mit unterstützten Funktionen der Zielplattform und expliziter Verantwortung für Zugangsdaten, Einschränkungen, Gebühren, Steuerbehandlung und externe Referenzen.
Empfehlungsbeispiel
Wählen Sie eine Bestellung, die eine eingeschränkte Versandmethode und eine Zahlungs-Plugin-Referenz verwendet hat. Bewahren Sie diese Werte in der Historie und definieren Sie anschließend separat, wie ein äquivalentes neues Checkout-Szenario Berechtigung und Kosten bestimmt.
Pass-Bedingung
Alte Bestellungen bewahren wahrheitsgemäße Methodennachweise, während neue Warenkörbe unterstütztes und bewusst konfiguriertes Zahlungs- und Versandverhalten verwenden.
Fehler 8: Bedeutung von Mehrsprachigkeit, Währung, Aliasen und Routen beschädigen
Was schiefgeht
Mehrsprachige VirtueMart-Inhalte, Währungen, Produkt-Aliasse, Kategorie-Aliasse und Joomla-Routing bilden gemeinsam kundenorientierte Pfade. Übersetzten Text ohne Sprachzuordnung zu migrieren oder Aliasse ohne Routenplan wiederzuverwenden kann doppelte Inhalte, falsche Sprachseiten und defekte wertvolle URLs erzeugen.
Frühe Warnsignale
Routing- und Lokalisierungsfehler werden sichtbar, wenn der Sprachwechsel den falschen Datensatz öffnet oder wichtige Pfade inkonsistent aufgelöst werden.
| Warnsignal | Was es zeigt |
|---|---|
| Übersetzte Produkte werden als unabhängige Produkte dupliziert | Sprachbeziehungen gingen verloren. |
| Währungsdarstellung ändert sich, die Preisbedeutung aber nicht | Währungsdarstellung und Berechnungsverantwortung wurden vermischt. |
| Alte Produktpfade führen zu generischen Seiten | Aliasse und Joomla-Menu-Item-Kontext wurden nicht abgebildet. |
Prävention
Ordnen Sie jede Übersetzung ihrer kanonischen Produkt- oder Kategoriebeziehung zu, bestimmen Sie den Währungs-Eigentümer und inventarisieren Sie Aliasse plus Menu-Item-Kontext für wichtige Routen. Definieren Sie Weiterleitungen von Quellpfaden zu bewussten Zielen, statt zu erwarten, dass gleiche Titel automatisch dieselbe URL erzeugen.
Empfehlungsbeispiel
Nehmen Sie ein Produkt, das in zwei Sprachen übersetzt und über mehrere Menüpfade in zwei Währungen verkauft wird. Verfolgen Sie kanonischen Datensatz, Sprachzuordnung, Alias, angezeigte Währung und Weiterleitungsziel für jede Route.
Pass-Bedingung
Sprachwechsel bewahrt die Datensatzidentität, Währungsverhalten ist beabsichtigt und priorisierte URLs führen zum richtigen lokalisierten Ziel.
Fehler 9: Joomla-Menüs, Module, Templates und Sublayouts ignorieren
Was schiefgeht
VirtueMart-Datensätze werden erst durch Joomla-Menu-Items, Module, Templates, Overrides, Sublayouts und Theme-Assets zu einem nutzbaren Shop. Eine vollständige Datenbankübertragung kann dennoch einen leeren oder defekten Shop erzeugen, wenn diese Präsentations- und Routing-Abhängigkeiten außerhalb der Verantwortlichkeitskarte liegen.
Frühe Warnsignale
Der Shop wirkt in der Administration gefüllt, während Navigation, Produktgrids, Warenkorbplatzierung oder Checkout-Darstellung unvollständig sind.
| Warnsignal | Was es zeigt |
|---|---|
| Direkte Produkt-URLs funktionieren, Navigation aber nicht | Menü- und Modulbeziehungen wurden nicht rekonstruiert. |
| Individuelle Produktlayouts fehlen | Template-Overrides oder Sublayouts wurden ausgelassen. |
| Warenkorb- oder Suchmodule zeigen inkonsistente Inhalte | Modulzuordnung und Kontext wurden nicht neu aufgebaut. |
Prävention
Inventarisieren Sie jedes Commerce-relevante Menu Item, jede Modulzuordnung, jedes Template-Override, Sublayout und jede Asset-Abhängigkeit. Entscheiden Sie, welche Präsentationselemente in der Zielplattform neu aufgebaut, ersetzt oder stillgelegt werden sollen, und bewahren Sie Routenziele für Elemente mit SEO- oder Conversion-Wert.
Empfehlungsbeispiel
Dokumentieren Sie den Pfad von der Hauptnavigation zu einer Kategorie, einer Produktdetailseite, dem Warenkorbmodul und dem Checkout. Erfassen Sie jede beteiligte Joomla- und VirtueMart-Komponente, bevor Sie den Ziel-Shop-Pfad definieren.
Pass-Bedingung
Kunden können repräsentative Produkte über die vorgesehene Navigation und das vorgesehene Layout erreichen, verstehen und kaufen, ohne von fehlenden Joomla-Präsentationsartefakten abhängig zu sein.
Fehler 10: Annehmen, Plugins, Integrationen und Custom Tables seien selbsterklärend
Was schiefgeht
VirtueMart kann über vmPlugin-basierte Zahlungs-, Versand-, Custom-Field-, Preis- und Integrationslogik erweitert werden. Custom Tables und externe Kennungen können wie optionale technische Daten wirken, obwohl sie Produkte, Kunden oder Bestellungen mit ERP, PIM, Fulfillment-Service oder Lizenzsystem verbinden.
Frühe Warnsignale
Daten ohne klaren Eigentümer werden meist erst sichtbar, nachdem ein Geschäftsprozess die Kennung oder das Ereignis nicht mehr erhält, das er erwartet.
| Warnsignal | Was es zeigt |
|---|---|
| Eine Custom Table enthält IDs ohne dokumentierten Verbraucher | Integrationsverantwortung ist unbekannt. |
| Ein Plugin-Feld wird kopiert, aber kein Verhalten verwendet es | Gespeicherter Wert und ausführbare Logik wurden verwechselt. |
| Externe Systeme erzeugen doppelte Datensätze | Stabile systemübergreifende Kennungen wurden nicht erhalten. |
Prävention
Erstellen Sie ein Erweiterungs- und Integrationsregister, das Datenverantwortlichen, Geschäftszweck, Datensatzschlüssel, Schreibrichtung und künftigen Zielverbraucher benennt. Bewahren Sie nur Werte mit explizitem künftigem Nutzen und definieren Sie Rekonstruktion oder Stilllegung für Plugin-Verhalten, das nicht als Daten übertragen werden kann.
Empfehlungsbeispiel
Identifizieren Sie für ein ERP-verknüpftes Produktfeld VirtueMart-Tabelle, Product-Key, externen Schlüssel, Synchronisationsrichtung und den Prozess, der ihn liest. Verwenden Sie diesen Vertrag, um Zielort und Cutover-Verantwortung zu bestimmen.
Pass-Bedingung
Jeder erhaltene individuelle Wert hat einen bekannten Eigentümer und Verbraucher, kritische externe Kennungen bleiben eindeutig und stillgelegte Plugin-Daten werden bewusst ausgeschlossen.
Fazit
Die Vermeidung von VirtueMart-Migrationsfehlern hängt davon ab, Beziehungen und nicht nur Zeilen zu bewahren. Produktvererbung, Custom Fields, Shopper-Gruppen, Berechnungsregeln, Joomla-Identität, Bestell-Snapshots, Routen, Layouts und Plugin-Verträge benötigen jeweils einen klaren Eigentümer. Eine Migration ist kontrolliert, wenn jede kritische Beziehung eine bewusste Zielbedeutung besitzt und jedes ausführbare Verhalten getrennt von historischen Daten neu aufgebaut wird.
Häufige Fragen
Sind VirtueMart-Custom-Fields gleichbedeutend mit gewöhnlichen Produktattributen?
Nicht unbedingt. Ein Custom Field kann Spezifikation, Warenkorbattribut, Varianten-Selektor, Related-Product-Beziehung oder Plugin-gestütztes Verhalten sein. Typ und Produktkonfiguration müssen verstanden werden, bevor eine Zieldarstellung gewählt wird.
Warum müssen Child Products getrennt von Parent Products geprüft werden?
Child Products können vom Parent erben und zugleich Preis, Bild, Kategorie, Shopper-Gruppe, Bestand oder andere Werte überschreiben. Eine reine Parent-Prüfung kann genau die Datensätze übersehen, die Kunden tatsächlich kaufen.
Sind Shopper-Gruppen relevant, wenn Kundenkonten korrekt migriert wurden?
Ja. Shopper-Gruppen können Produktsichtbarkeit, Preise, Berechnungsregeln, Zahlungs- und Versandmethoden sowie angezeigte Preiselemente steuern. Kontenidentität allein bewahrt diese kommerziellen Beziehungen nicht.
Können historische Zahlungs- und Versandnamen Checkout-Methoden rekonstruieren?
Nein. Historische Namen und Gebühren gehören zu Bestellnachweisen. Live-Checkout-Methoden benötigen unterstützte Plugins oder Zielkonfigurationen, Zugangsdaten, Berechtigungsbedingungen und operative Verantwortung.
Warum gehören Joomla-Menu-Items und -Module in die VirtueMart-Fehlerprüfung?
Sie liefern häufig die tatsächlichen Shop-Routen und Platzierungen, über die Kunden Kategorien, Produkte, Warenkorbfunktionen und Checkout erreichen. Vollständige VirtueMart-Datensätze können ohne diese Präsentationsbeziehungen unbrauchbar bleiben.
Was ist das klarste Zeichen dafür, dass ein VirtueMart-Fehlerrisiko kontrolliert ist?
Ein repräsentatives Geschäftsszenario funktioniert Ende-zu-Ende: Der richtige Kunde sieht die richtige Produktauswahl und den richtigen Preis, durchläuft den vorgesehenen Kaufpfad und erzeugt eine Bestellung, deren Historie und Kennungen verständlich bleiben.