Bei der Bewertung von Phoca Cart als mögliche Zielplattform legt die Validierung fest, welche Nachweise zeigen müssen, dass Daten, Beziehungen und Geschäftsanforderungen im Ziel funktionieren.
Nach einer Migration zu Phoca Cart als Zielplattform muss die Validierung beweisen, dass der migrierte Shop als Joomla-native Commerce-Umgebung funktioniert und nicht nur, dass Datensätze in der Administration erscheinen. Products müssen verkaufbar bleiben, Categories die Auffindbarkeit unterstützen, Customer- und Order-Datensätze weiterhin nutzbar sein und konfigurationsabhängiges Verhalten zur Zielkonfiguration von Phoca Cart passen.
Die stärkste Validierung verbindet die Prüfung von Datensätzen mit der Prüfung ihres Verhaltens. Product-Daten, Customer-Historie, Steuer, Versand, Zahlung, Rechnungskontext, Shop-Pfade, Module, Templates, Sprachen, Währungen und von Erweiterungen verwaltete Daten sollten gemeinsam geprüft werden, weil Phoca Cart innerhalb einer Joomla-Website betrieben wird und nicht außerhalb davon.
Was die Validierung bei einer Phoca-Cart-Migration beweisen sollte
Die Validierung sollte bestätigen, ob die kommerzielle Bedeutung die Migration überstanden hat. Eine vollständige Product-Anzahl reicht nicht aus, wenn Attribute die Auswahl nicht mehr beeinflussen, Spezifikationen keinen Vergleich mehr unterstützen, Kundengruppenpreise nicht mehr nachvollziehbar sind, Bonuspunkte ihre Beziehungen verlieren oder Orders den geschäftlichen Kontext hinter den Summen nicht mehr erkennen lassen.
Ebenso muss geprüft werden, ob der Joomla-Shop die migrierten Datensätze tatsächlich verwenden kann. Phoca Cart kann von Joomla-Menüs, Modulen, Template-Overrides, Plugins, Aliasen, Zugriffsebenen, Sprachen und Layoutentscheidungen abhängen. Ein Shop kann eine Prüfung auf Datenbankebene bestehen und trotzdem im Kaufpfad scheitern.
| Validierungsbereich | Was bewiesen werden sollte | Warum es wichtig ist |
|---|---|---|
| Katalogstruktur | Products, Categories, Manufacturers, Attribute, Optionen, Spezifikationen, Bilder, Download-Products, Bestandsverhalten und verwandte Products behalten ihre Bedeutung. | Käufer benötigen klare Product-Auswahl und Händler nach dem Launch verwaltbare Katalogdatensätze. |
| Kommerzielle Regeln | Preise, Rabatte, Coupons, Bonuspunkte, Warenkorbrabatte, Kundengruppenpreise, Steuerbehandlung, Versandlogik und Zahlungskontext lassen sich korrekt interpretieren. | Umsatz, Vertrauen und Servicequalität hängen von mehr als Product-Namen und Summen ab. |
| Customer- und Order-Historie | Customers, Adressen, Kundengruppen, Order-Positionen, Status, Rechnungen, Lieferscheine, Zahlungsbezeichnungen, Versandkosten und Steuerbeträge bleiben lesbar. | Historische Datensätze müssen Kundenservice, Buchhaltungsreferenzen, Prüfung der Auftragsabwicklung und Wiederkäufe unterstützen. |
| Joomla-Shop-Verhalten | Menüs, Aliase, Category- und Product-Pfade, Module, Templates, Template-Overrides, Suche, Filter und Warenkorbpfade funktionieren wie erwartet. | Korrekte Datensätze helfen nicht, wenn Käufer Products nicht finden oder kaufen können. |
| Lokalisierung und Erweiterungen | Sprachen, Währungen, Zonen, individuelle Plugins, Module, Integrationen und individuelle Daten sind identifiziert und validiert. | Internationale und angepasste Shops scheitern häufig an Beziehungen, die einfache Stichproben nicht sichtbar machen. |
Ein brauchbares Validierungsergebnis beantwortet drei Fragen: Was funktioniert wie erwartet, was benötigt Konfiguration und was erfordert vor dem Launch einen anderen Migrations- oder Behandlungsweg?
Products und Katalog validieren
Die Product-Validierung sollte mit repräsentativen Product-Typen beginnen. Einfache Products sind hilfreich, zeigen aber selten das vollständige Risiko einer Phoca-Cart-Migration. Die Stichprobe sollte Products mit Attributen, Optionen, Spezifikationen, Bildern, Downloads, Bestandsregeln, Rabatten, Kundengruppenpreisen, Manufacturers, verwandten Products und Category-Beziehungen enthalten.
Ein Product sollte sowohl in der Administration als auch im Shop geprüft werden. Die Administrationsprüfung bestätigt, dass migrierte Werte vorhanden sind. Die Shop-Prüfung zeigt, ob Käufer das Product erkennen, vergleichen, auswählen und kaufen können.
| Product-Stichprobe | Validierungsschwerpunkt | Pass-Signal |
|---|---|---|
| Einfaches Product | Name, Alias, SKU/Referenz, Beschreibung, Bild, Preis, Steueranzeige, Bestand, Category-Zuordnung. | Product ist sichtbar, verständlich, kaufbar und korrekt platziert. |
| Product mit Attributen oder Optionen | Auswahlsteuerung, Preisänderungen, Bestandseffekt, Pflichtauswahl, Anzeigereihenfolge. | Käuferauswahl funktioniert wie vorgesehen und Order-Positionen behalten die gewählten Werte. |
| Product mit Spezifikationen oder Parametern | Technische Details, Relevanz für Vergleich/Filterung, strukturierte Darstellung. | Product-Details bleiben für Auffindbarkeit und Bewertung nutzbar. |
| Rabattiertes Product | Rabattpreis, Warenkorbrabatt, Coupon-Kompatibilität, Sichtbarkeit für Kundengruppen. | Aktionsverhalten entspricht der beabsichtigten Verkaufsregel. |
| Download-Product | Kaufpfad, Abhängigkeit vom Order-Status, Zugriffserwartung, Customer-Historie. | Download-Verhalten ist für die Zielkonfiguration realistisch und nutzbar. |
| Product in mehreren Categories | Category-Zuordnung, Pfadverhalten, Modulsichtbarkeit, Risiko doppelter Routen. | Product bleibt auffindbar, ohne verwirrende Shop-Pfade zu erzeugen. |
Attribute, Optionen, Spezifikationen und Parameter dürfen nicht als austauschbar behandelt werden. Eine Option kann Käuferauswahl oder Preis beeinflussen, eine Spezifikation den Vergleich unterstützen und ein Parameter Darstellung oder Klassifikation steuern. Vor der Freigabe muss die Rolle jeder Ebene bestätigt sein.
Bei der Bestandsvalidierung für Phoca Cart sollte außerdem geklärt werden, welches der drei Eigentumsmodelle gilt. Main Product behandelt Varianten als eine gemeinsame Product-Menge; Product Variations behandelt jede Variante als separat bestandsführendes Ergebnis; Advanced Stock Management erlaubt zusätzlich Bestand für aktivierte Kombinationen von Varianten. Die Stichprobe sollte verfügbare, knappe und ausverkaufte Fälle sowie Pflichtoptionen, optionale Optionen und Kombinationen enthalten, damit Mengenabzug und Mindestmengen auf die richtige Ebene zurückgeführt werden können. Bei Stores mit POS- oder stationären Abläufen muss die Bestandsprüfung mit dem vorgesehenen Betriebsmodell nach dem Launch verknüpft werden und darf nicht nur eine statische Zahl bestätigen.
Customers, Orders und kommerzielle Regeln validieren
Customer-Validierung muss mehr als Name und E-Mail prüfen. Phoca-Cart-Stores können Kundengruppen, Joomla-Benutzeridentität, Kundengruppenpreise, Bonuspunkte, Rabatte, Adressen, Order-Historie, Zugriffsebenen und Kontoverhalten nutzen. Ein migrierter Customer kann korrekt aussehen und dennoch die kommerzielle Behandlung verlieren, die den Datensatz nutzbar gemacht hat.
Auch die Order-Validierung muss über Summen hinausgehen. Historische Orders sollten als geschäftlicher Nachweis lesbar bleiben: was gekauft wurde, welche Optionen ausgewählt wurden, welche Kundengruppe galt, welche Steuer- und Versandkosten entstanden, welche Zahlungsmethode verwendet wurde und welcher Rechnungs- oder Lieferscheinkontext relevant ist.
| Datensatztyp | Validierungsfragen | Zu prüfende Nachweise |
|---|---|---|
| Customer-Profil | Ist der Customer mit dem richtigen Joomla-Konto und Phoca-Cart-Customer-Kontext verbunden? | Customer-Details, Login-Identität, Adressen, Gruppenmitgliedschaft, Order-Historie. |
| Kundengruppe | Beeinflusst die Gruppe Preise, Rabatte, Steuerbehandlung oder Zugriff weiterhin wie erwartet? | Gruppenzuordnung, Gruppenpreis-Stichproben, Shop-Darstellung, Warenkorbverhalten. |
| Order-Datensatz | Kann der Kundenservice nachvollziehen, was historisch passiert ist? | Order-Nummer, Datum, Status, Positionen, gewählte Optionen, Summen, Steuer, Versand, Zahlungsbezeichnung, Rechnungsausgabe. |
| Coupon oder Rabatt | Gehört die Regel zur Historie, zum aktiven Verkauf oder zur Konfigurationsprüfung? | Coupon-Code, Datumsbereich, Kundengruppe, Product-/Category-Einschränkungen, Warenkorbverhalten. |
| Bonuspunkte | Sind Punkte historisch nachvollziehbar und nach dem Launch kommerziell nutzbar? | Customer-Punktesaldo, verdiente und eingelöste Punkte, Order-Beziehung. |
Coupons, Rabatte, Bonuspunkte und Kundengruppenpreise sollten, soweit relevant, sowohl anhand statischer Datensätze als auch im Shop beziehungsweise Warenkorb getestet werden. Ein Rabatt, der in der Administration sichtbar ist, aber im Warenkorb falsch wirkt, ist nicht launchbereit. Ein migrierter Coupon, der für die falsche Kundengruppe, das falsche Product, die falsche Währung oder den falschen Zeitraum gilt, kann unmittelbar Umsatz gefährden.
Steuern, Versand, Zahlung und Checkout validieren
Steuer-, Versand- und Zahlungsverhalten ist häufig konfigurationsabhängig. Historische Orders können frühere Steuerbeträge, Versandkosten und Zahlungsbezeichnungen zeigen, beweisen aber nicht automatisch, dass zukünftiger Checkout im Zielsystem korrekt konfiguriert ist.
Die Steuerprüfung sollte repräsentative Products, Kundengruppen, Länder, Regionen, Zonen, Steuersätze, Rechnungs- und Lieferadressen sowie Rechnungsausgabe umfassen. Hat der Quell-Shop individuelle Steuerlogik oder Drittanbieter-Steuerfunktionen verwendet, muss die Validierung trennen, was sich in normalen Phoca-Cart-Einstellungen darstellen lässt und was eine individuelle Prüfung benötigt.
Die Versandprüfung sollte sich auf die Methoden konzentrieren, die nach dem Launch verwendet werden. Stichproben sollten wichtige Zielorte, Gewichts- oder Preisschwellen, Einschränkungen nach Product-Typ, Kundengruppenverhalten, Regeln für kostenlosen Versand und Order-Summen umfassen, die die Methodenverfügbarkeit beeinflussen.
Die Zahlungsprüfung sollte Sichtbarkeit von Zahlungsmethoden, Checkout-Meldungen, Order-Statusbehandlung, Verhalten von Transaktionsreferenzen und die Bestätigung für Customers einschließen. Zahlungs-Plugins können zusätzlich zur migrierten Datenbasis Konfiguration, Zugangsdaten, Callback-Einstellungen oder Gateway-spezifische Tests benötigen.
| Checkout-Szenario | Warum es getestet werden sollte | Erwarteter Nachweis |
|---|---|---|
| Gast-Checkout | Macht Annahmen zu Konten und Adressen sichtbar. | Käufer kann den Checkout ohne unerwartete Kontohürden abschließen. |
| Checkout als registrierter Customer | Prüft die Beziehung zwischen Joomla-Benutzer und Phoca-Cart-Customer. | Customer-Identität, Adressen, Gruppenbehandlung und Order-Historie verhalten sich konsistent. |
| Rabattierte Order | Prüft Zusammenspiel von Coupon, Warenkorbrabatt, Bonus und Steuer. | Rabatt wird korrekt angewendet und Summen bleiben nachvollziehbar. |
| Regionale Order | Prüft Steuer, Zone, Versand, Währung und Zahlungsavailability. | Checkout-Verhalten entspricht der Zielmarktregel. |
| Order mit Optionen | Prüft, ob Product-Auswahl bis in Warenkorb und Order-Historie erhalten bleibt. | Gewählte Optionen bleiben in Order-Bestätigung und Administration sichtbar. |
Die Checkout-Validierung muss bis zum Abschluss der Order fortgesetzt werden. Warenkorbverhalten allein reicht nicht aus, wenn nach dem Absenden Order-Status, Rechnungsausgabe, E-Mail-Nachrichten oder Zahlungsreferenzen scheitern.
Shop, Joomla und Darstellung validieren
Phoca-Cart-Validierung muss die Joomla-seitige Darstellung einschließen, weil Customers mit Shop-Pfaden und nicht mit Datenbanktabellen interagieren. Menüs, Module, Templates, Template-Overrides, Aliase, Metadaten, Suche, Filter, Vergleichslisten, Wunschlisten und Category-Layouts können bestimmen, ob migrierte Daten nutzbar werden.
Wichtige Stichproben sollten stark frequentierte Categories, Top-Products, rabattierte Products, über Module angezeigte Products, gefilterte Products, Checkout- und Kontopfade, mehrsprachige Pfade sowie SEO-kritische URLs einschließen. Stores mit individuellen Templates, Joomla-Modulen oder Phoca-Cart-Template-Overrides benötigen zusätzlich zur Datenprüfung eine Layoutprüfung.
| Shop-Element | Validierungsschwerpunkt | Pass-Signal |
|---|---|---|
| Category-Seiten | Product-Listing, Filter, Pagination, Aliase, Metadaten, Routenverhalten. | Customers können Products ohne defekte Pfade durchsuchen und eingrenzen. |
| Product-Seiten | Layout, Bildausgabe, Preisanzeige, Optionen, Spezifikationen, Reviews, strukturierte Details. | Product-Detailseiten unterstützen Kaufentscheidungen. |
| Module | Warenkorb-, Währungs-, Product-, Category-, Such-, Filter-, Vergleichs-, Wunschlisten- oder individuelle Module. | Module stellen die erwarteten Daten an den vorgesehenen Joomla-Positionen dar. |
| Templates und Overrides | Product-, Category- und Checkout-Layout sowie Rechnungs- oder E-Mail-Darstellung. | Individuelle Darstellung verbirgt oder verfälscht migrierte Werte nicht. |
| SEO-Pfade | Aliase, Canonical-Anforderungen, Redirects, Metadaten und gegebenenfalls strukturierte Daten. | Wertvolle Pfade besitzen Kontinuität oder einen Redirect-Plan. |
Die Darstellungsvalidierung sollte sich nicht auf das Standardtemplate beschränken. Wenn möglich, sollten zukünftiges Theme, Modulpositionen, Menüstruktur und Template-Overrides verwendet werden, weil genau diese Bedingungen Käufer nach dem Launch erleben.
Mehrsprachige, mehrwährungsfähige, Erweiterungs- und individuelle Daten validieren
Phoca Cart unterstützt mehrere Sprachen und Währungen, doch diese Möglichkeiten erhöhen die Validierungskomplexität. Ein Shop kann in der Standardsprache bestehen und zugleich bei übersetzten Product-Namen, Category-Aliasen, Modulausgabe, Checkout-Labels, Währungsanzeige, Rechnungen, E-Mails oder regionsspezifischem Zahlungs- und Versandverhalten scheitern.
Die mehrsprachige Validierung sollte Product- und Category-Seiten, Module, Warenkorb, Checkout, Kontopfade, Order-Bestätigung und wichtige Transaktionsnachrichten einschließen. Die Mehrwährungsvalidierung sollte Product-Anzeige, Warenkorb- und Order-Summen, Rechnungskontext, Rabatte, Steuer und Versandkosten prüfen.
Von Erweiterungen verwaltete und individuelle Daten müssen vor der Freigabe klassifiziert sein. Phoca-Cart-Stores können Plugin-eigene Zahlungs- oder Versanddaten, POS-Datensätze, individuelle Rechnungslogik, Custom Fields, Template-Overrides, Import-/Export-Routinen, ERP-Konnektoren, Feed-Plugins, individuelle Module oder maßgeschneiderte Joomla-Entwicklung enthalten. Solche Elemente dürfen nicht stillschweigend als Standardumfang freigegeben werden, wenn sie Zuordnung, Transformation oder individuelle Behandlung benötigen.
| Komplexer Bereich | Validierungsfrage | Entscheidung |
|---|---|---|
| Mehrsprachige Datensätze | Funktionieren wichtige Products, Categories, Module und Checkout-Pfade in jeder wesentlichen Sprache? | Sprachumfang freigeben, Konfiguration anfordern oder Stichproben erweitern. |
| Mehrwährungsverhalten | Bleiben Preise, Rabatte, Steuer, Versand, Orders und Rechnungen über Währungen hinweg konsistent? | Zieleinstellungen freigeben oder währungsspezifische Regeln prüfen. |
| Zahlungs- und Versand-Plugins | Sind Plugin-eigene Datensätze und Order-Referenzen verständlich? | Konfigurationsumfang bestätigen oder individuelle Prüfung anfordern. |
| POS- oder Rechnungsanpassung | Bleibt das betriebliche Ergebnis im Ziel erhalten? | Unterstütztes Verhalten bestätigen oder nicht standardmäßige Behandlung einplanen. |
| Individuelle Module oder Overrides | Hängt die Darstellung von individueller Joomla-Logik ab? | Im Zieltemplate validieren oder Neuaufbau definieren. |
Eine Validierung darf individuelle Komplexität niemals verdecken. Gehören Daten zu nicht unterstützten Erweiterungen, individuellem Code, Plugin-spezifischen Tabellen oder nicht dokumentierter Geschäftslogik, muss das Ergebnis vor der Freigabe den erforderlichen Behandlungs- oder Servicepfad benennen.
Validierungsergebnisse in Launch-Entscheidungen überführen
Phoca-Cart-Validierung sollte jeden wesentlichen Befund als Pass, Watch oder Block einstufen und die Entscheidung mit konkreten Nachweisen verbinden.
| Entscheidungsstatus | Phoca-Cart-Nachweis | Bedeutung für den Launch |
|---|---|---|
| Pass | Product-Attribute, Spezifikationen, Gruppenpreise, Customers, Orders, Joomla-Routen, Sprach-/Währungskontext und vereinbarte Ausgaben funktionieren wie vorgesehen. | Der geprüfte Bereich unterstützt den Launch. |
| Watch | Ergebnis ist nutzbar, aber eine dokumentierte, nicht blockierende Aufgabe an Modul, Template, Übersetzung, Währung, Konfiguration oder Bereinigung bleibt offen. | Launch kann mit benannter Verantwortung und Folgennachweis fortgesetzt werden. |
| Block | Ein erforderliches Attribut oder ein Preis ist falsch, eine Order lässt sich nicht interpretieren, eine priorisierte Route scheitert oder ein vereinbarter POS-, Rechnungs-, Erweiterungs- oder individueller Datensatz ist unbrauchbar. | Launch-Freigabe für den betroffenen Bereich wird verweigert. |
Repräsentative Tests sollten bewusst ein Product mit Attributen und Spezifikationen, einen Kundengruppenpreis, ein Bonus- oder Rabattbeispiel, eine Order mit Steuer-/Versand-/Zahlungskontext, ein übersetztes Product oder eine übersetzte Category, einen wichtigen Modul-/Menüpfad und einen von Erweiterungen verwalteten oder individuellen Datensatz einschließen. Die breitere Migrationsausführung sollte vollständige Katalog- und historische Abdeckung beweisen, einschließlich seltener Attributkombinationen, alter Order-Status, weniger genutzter Währungen oder Sprachen und Routen-Ausnahmen.
Der Abschlussbericht sollte erwartetes Ergebnis, tatsächlichen Nachweis, Schweregrad, Verantwortlichen, Korrektur oder akzeptierte Abweichung sowie den zum Schließen erforderlichen Nachweis festhalten. Ein Screenshot ohne Datensatzidentität und Szenariokontext reicht nicht aus.
Spätere Phoca-Cart-Aktionen und vereinbarte Ausgaben erneut validieren
Der Revalidierungsdatensatz sollte den geänderten Datensatzumfang, weiterhin gültige frühere Nachweise und die zu wiederholenden Szenarien benennen. So wird verhindert, dass eine begrenzte Fortsetzung wie eine vollständig neue Freigabe behandelt wird.
Die Revalidierung muss der gewählten späteren Aktion folgen.
| Spätere Aktion | Grenze der Phoca-Cart-Revalidierung |
|---|---|
| Fortsetzung unter der akzeptierten Konfiguration | Bestätigen, dass spätere berechtigte Datensätze die freigegebenen Product-, Attribut-, Kundengruppen-, Order-, Sprach-, Währungs- und Joomla-Routenbeziehungen beibehalten. |
| Fortsetzung unter überarbeiteter Konfiguration | Jedes Szenario wiederholen, das von geänderten Filtern, Zuordnungen, Auswahl der Datenkategorien, Product-Feldbehandlung, Sprachumfang oder Erweiterungsbehandlung betroffen ist. |
| Eigenständiges neues Migrationsergebnis erzeugen | Neue Nachweisbasis herstellen und relevante repräsentative Tests, breitere Migration, Routen-, Erweiterungs- und Launch-Entscheidungen für das neue Ergebnis wiederholen. |
Gekaufte und freigegebene Migrationsergebnisse müssen direkt mit den vereinbarten Filter-, Zuordnungs-, Konfigurations- oder erzeugten Ergebnissen verglichen werden. Nicht standardmäßige Migrationsergebnisse benötigen Nachweise für die benannten Custom Fields, Erweiterungsdatensätze, POS-/Rechnungsdaten, externen Kennungen, Transformationen oder die besondere Logik im vereinbarten Umfang. Keine der beiden Kategorien darf allein über eine allgemeine Datensatzanzahl freigegeben werden.
Fazit
Die Validierung von Phoca Cart muss beweisen, dass der migrierte Shop als Joomla-native Commerce-Umgebung betrieben werden kann. Product-, Customer- und Order-Zahlen sind nur der Ausgangspunkt. Entscheidend ist, ob Katalogbedeutung, kommerzielle Regeln, Customer-Historie, Checkout-Verhalten, Joomla-Shop-Pfade, Mehrsprachigkeit und von Erweiterungen verwaltete Daten gemeinsam nutzbar bleiben.
Die beste Validierung nutzt repräsentative Stichproben, prüft Verhalten in Administration und Shop, trennt migrierte Historie von Zielkonfiguration und übersetzt Befunde in klare Launch-Entscheidungen. Enthält eine Phoca-Cart-Migration komplexe Product-Regeln, Kundengruppen, Bonuspunkte, Steuerregionen, Versand- oder Zahlungs-Plugins, Module, Template-Overrides, POS-Abläufe oder individuelle Daten, muss vor der Launch-Freigabe geklärt werden, ob ein Problem zur Konfiguration, zu freigegebenen Migrationsanpassungen oder zu nicht standardmäßiger Behandlung gehört.
Häufige Fragen
Was sollte nach einem repräsentativen Phoca-Cart-Test zuerst validiert werden?
Beginnen Sie mit attributintensiven Products, Kundengruppenpreisen, aussagekräftigen Orders, mehrsprachigen oder mehrwährungsfähigen Datensätzen, priorisierten Joomla-Routen und Erweiterungsdaten, die die tatsächliche Komplexität des Stores sichtbar machen.
Reicht der Vergleich von Datensatzanzahlen bei Phoca Cart aus?
Nein. Anzahlen beweisen nicht, dass Attribute Preise korrekt beeinflussen, Gruppenregeln ihre Bedeutung behalten, übersetzte Routen funktionieren, Orders ihren kommerziellen Kontext bewahren oder Module und Plugins die migrierten Datensätze verwenden.
Warum sollte die Phoca-Cart-Validierung Joomla-Menüs und -Module einschließen?
Sie stellen häufig Katalogeinstiege, Filter-, Warenkorb-, Aktions-, Konto- oder Checkout-Pfade bereit. Korrekte Datenbankdatensätze können kommerziell unbrauchbar bleiben, wenn diese Pfade defekt sind.
Wie sollten Stichproben für repräsentative Migrationstests ausgewählt werden?
Wählen Sie Fälle, die Product-Attribute, Spezifikationen, Gruppenpreise, Steuer-/Versand-/Zahlungshistorie, Sprachen oder Währungen sowie individuelle oder von Erweiterungen verwaltete Beziehungen kombinieren, statt nur einfache Products zu prüfen.
Wann sollte ein Phoca-Cart-Problem als Block eingestuft werden?
Verwenden Sie Block, wenn das Problem Kaufvorgang, Preis- oder Zugriffsregeln, Order-Interpretation, eine priorisierte Route, mehrsprachigen Commerce oder eine vereinbarte individuelle beziehungsweise Erweiterungsausgabe beeinträchtigt.
Was muss nach einer späteren Phoca-Cart-Migrationsaktion erneut validiert werden?
Wiederholen Sie jedes betroffene Product-, Customer-, Order-, Content-, Routen-, Sprach-, Währungs- und Erweiterungsszenario. Geänderte Konfiguration oder ein neues Migrationsergebnis erfordert umfangreichere Nachweise als eine unveränderte Fortsetzung.