Bei der Bewertung von osCMax als mögliche Zielplattform legt die Validierung fest, welche Nachweise zeigen müssen, dass Daten, Beziehungen und Geschäftsanforderungen im Ziel funktionieren.
Die Validierung sollte vier Fragen getrennt beantworten: Sind die unterstützten Datensätze korrekt angekommen? Ist ihre geschäftliche Bedeutung erhalten? Unterstützen osCMax-Zielkonfiguration und Contribution-eigenes Verhalten den vorgesehenen Betrieb? Und besitzt jede nicht unterstützte Anforderung vor dem Launch einen klaren Verantwortlichen und Behandlungsweg?
Was Validierung bei osCMax bedeutet
Die osCMax-Validierung sollte mit einer einfachen Frage beginnen: Wird der Shop wie ein gewöhnlicher osCommerce-ähnlicher Katalog geprüft oder als Contribution-geprägter Legacy-Shop? Die Antwort bestimmt, was bewiesen werden muss. Bei einem einfachen Shop kann der Review Categories, Products, Customers, Orders, Bilder, Adressen, Order-Status, Coupons und CMS Pages fokussieren. Hängt der Shop von alten Modulen, Templates, Artikelboxen, individueller Order-Verarbeitung, verändertem Versand oder Bildverhalten ab, muss auch dieses zusätzliche Verhalten rund um die migrierten Datensätze geprüft werden.
Ein starker Prozess behandelt osCMax-Nachweise schichtweise. Erstens wird bestätigt, dass zulässige Datensätze korrekt migriert wurden. Zweitens wird geprüft, ob sie weiterhin die richtige Geschäftsbedeutung tragen. Drittens muss Zielkonfiguration die erwarteten Storefront-, Checkout-, Admin- und Reporting-Funktionen unterstützen. Viertens wird alles identifiziert, was sich durch kundengeführte Ausführung allein nicht belegen lässt und möglicherweise vereinbartes Field Mapping, Datenkonfiguration, unterstützte Migrationsanpassungen oder nicht standardisierte Behandlung benötigt.
| Validierungsebene | Was sie beweist | Warum sie bei osCMax wichtig ist |
|---|---|---|
| Vorhandensein von Datensätzen | Products, Customers, Orders, Categories, Adressen, Bilder und andere zulässige Datensätze existieren auf der Zielplattform. | Reine Datensatzanzahlen beweisen kein Contribution-geprägtes Verhalten. |
| Geschäftsbedeutung | Preise, Attribute, Order-Status, Customer-Segmentierung, Versandreferenzen und Inhalte bleiben verständlich. | Legacy-Anpassungen können die Interpretation gewöhnlicher Datensätze verändern. |
| Zielverhalten | Storefront-Navigation, Checkout, Katalogdarstellung, Suche und Admin-Nutzung funktionieren wie erwartet. | Templates und Module können Verhalten erzeugt haben, das nicht als Rohdaten migriert wird. |
| Umfangsgrenze | Nicht unterstützte individuelle Logik ist vor dem Launch identifiziert. | Contribution-eigenes Verhalten kann nicht standardisierte Behandlung oder Neuaufbau auf der Zielseite erfordern. |
Damit wird ein häufiger Fehler vermieden: Validierung als abschließenden Datensatzvergleich zu behandeln. Bei osCMax ist Validierung eine Prüfung der Geschäftskontinuität. Ein Bereich besteht erst, wenn migrierte Daten und Zielkonfiguration das erforderliche Customer-, Admin- und kommerzielle Verhalten tragen können.
Annahmen zu Versionslinie und Umgebung validieren
Versionsklarheit gehört zu den ersten Prioritäten, weil osCMax-Shops auf unterschiedlichen Legacy-Zweigen, inoffiziellen Updates oder individuell gepflegten Paketen beruhen können. Zwei Shops mit ähnlichem Admin-Bereich können unterschiedliche Datenbankänderungen, Datei-Overrides, Contribution-Sets und Template-Annahmen haben. Die Bezeichnung osCMax allein erklärt den Migrationsumfang nicht.
Im repräsentativen Test sollten Versionsnachweise aus Admin-Einstellungen, Datenbanktabellen, Dateizeitstempeln, Wartungsnotizen und Erweiterungshistorie abgeglichen werden. Außerdem ist zu prüfen, ob der Shop sauber aktualisiert oder über manuelle Patches gepflegt wurde. Bei unvollständiger Versionslage muss konservativer validiert werden, weil unerwartete individuelle Spalten, fehlende Beziehungen oder alte Modulreste auftreten können.
Auch die Umgebung ist relevant, da osCMax häufig selbst gehostet wird. PHP- und Datenbankversion, Bildpfade, Rewrite-Regeln, Dateiberechtigungen, Mail-Verhalten, Cron-ähnliche Aufgaben und Hosting-spezifische Konfiguration können erklären, warum Katalogbilder, Kontaktformulare, Order-Exporte oder Versandberechnungen so funktionieren. Diese Einstellungen werden nicht zwingend als Commerce-Datensätze migriert, gehören aber zur Interpretation des Quellverhaltens.
Die Bestehenskriterium lautet nicht, jede alte technische Einstellung zu reproduzieren. Das Team muss verstehen, welche Umgebungsannahmen den Migrationsumfang beeinflussen und welche zur Einrichtung der Zielseite gehören. Abhängigkeiten von Serververhalten oder lokalen Dateipfaden müssen dokumentiert sein, bevor die breitere Migrationsvalidierung als belastbar gilt.
Katalogstruktur und Contribution-geprägtes Product-Verhalten validieren
Katalogvalidierung muss über Product-Anzahlen hinausgehen. osCMax kann standardisierte Product-Daten, Categories, Bilder, Specials, Attribute, Downloads und Bestand enthalten, während Darstellung oder Verhalten durch Contributions beeinflusst werden. Bildverwaltung, Product-Slider, Quick Updates, eingeschränkte Artikelanzeige, Countdown-Aktionen oder individuelle Texteingabefelder können außerhalb normaler Product-Datensätze liegen.
Zuerst sollte Product-Identität verglichen werden: SKU oder Modell, Product-Name, Category-Zuordnung, Status, Basispreis, Sonderpreis, Steuerklasse, Bestand, Bildreferenzen, Beschreibungen und Metadaten. Danach folgt das Verhalten: Bilden Product-Optionen weiterhin Customer-Auswahl korrekt ab? Sind Downloadable Products kaufbar? Gibt es ein Zielgegenstück für individuelle Text- oder Gravureingaben? Benötigen Bildergalerien oder Thumbnails separate Konfiguration?
| Katalogbereich | Validierungsfrage | Fehlersignal |
|---|---|---|
| Categories | Sind Products der richtigen Hierarchie zugeordnet und im erwarteten Navigationskontext sichtbar? | Products existieren, erscheinen aber unter falschem Category-Pfad oder doppelter Menüstruktur. |
| Attribute und Optionen | Beeinflussen Customer-Auswahlmöglichkeiten Preis, Product-Bedeutung oder Fulfillment weiterhin korrekt? | Optionen werden als Bezeichnungen importiert, tragen aber die ursprüngliche Verkaufslogik nicht mehr. |
| Bilder | Sind Hauptbilder und zusätzliches Bildverhalten erhalten oder bewusst ersetzt? | Product-Seiten zeigen fehlende Thumbnails, defekte Galerien oder verwaiste Bilder. |
| Specials und Aktionen | Entsprechen Rabattzeitraum, Sale-Sichtbarkeit und Preisdarstellung den Geschäftsanforderungen? | Sale-Preise existieren, aber Ablauf, Countdown oder Aktionsdarstellung fehlen. |
| Inhaltsbezogenes Katalogverhalten | Werden Artikelboxen, News-Blöcke oder eingeschränkte Inhalte als Inhalt und Konfiguration statt als einfache Product-Daten behandelt? | Inhalte erscheinen unstrukturiert oder fehlen im Storefront-Review. |
Eine repräsentative Stichprobe sollte einfache Products, attributreiche Products, Sonderpreis-Products, Downloadable Products, bildreiche Products und von Contributions beeinflusste Products enthalten. Eine Stichprobe mit nur sauberen Products beweist keine osCMax-Migrationsbereitschaft.
Customers, Orders und kommerzielle Bedeutung validieren
Customers und Orders verlangen sorgfältige Prüfung, weil osCMax Admin-Abkürzungen, Contribution-basierte Customer Groups, telefonische Bestellungen, Order-Exporte oder angepasste Statuslogik enthalten kann. Eine migrierte Order ist nicht allein deshalb valide, weil Total, Datum und Customer-Name vorhanden sind. Der Review muss zeigen, dass die Order für Customer Service, Reporting und historische Referenz verständlich bleibt.
Bei Customers sind Kontoidentität, E-Mail, Adressen, Customer Group oder Großhandelsstatus, gegebenenfalls Newsletter-Präferenz, Erwartungen an Passwortbehandlung und Customer-to-Order-Beziehungen zu prüfen. Nutzte der Altshop eingeschränkten Artikelzugriff, Distributor-Preise, Großhandelsanfragen oder individuelle Kontaktformulare, muss geklärt werden, ob dies migrierte Customer-Daten, Zielkonfiguration, eine abgegrenzte Migrationsanpassung oder nicht standardisierte Behandlung ist.
Bei Orders sind Order-Nummern, Daten, Customer-Verknüpfungen, Product Lines, Mengen, Steuern, Rabatte, Versand, Zahlungsreferenzen, Statushistorie, Kommentare, Rechnungen und Export-/Reporting-Anforderungen zu prüfen. Alte Order-Total- oder Versandmodule können die Historie beeinflussen. Eine Order besteht erst, wenn sie nach der Migration weiterhin erklärt werden kann.
Eine sinnvolle operative Bestehenskriterium lautet: Ein Support-Mitarbeiter kann eine migrierte Order öffnen und verstehen, was gekauft wurde, welcher Betrag berechnet wurde, wie Versand und Steuer dargestellt waren, welchen Status die Order erreichte und welche historische Aktion relevant sein kann. Technisch vorhandene, aber nicht erklärbare Order-Daten bestehen die Validierung nicht.
Storefront-Templates, Inhalte und Navigation validieren
Template-Validierung ist bei osCMax wichtig, weil Storefront-Verhalten von älteren Template-Strukturen, Category-Boxen, InfoBoxes, individuellen Buttons, Bild-Assets, CSS oder Layoutkonventionen abhängen kann. Katalogdatensätze können vollständig sein und die Storefront dennoch gebrochen wirken, wenn das Ziel-Theme Navigation oder Inhaltsplatzierung nicht entsprechend umsetzt.
Der Review sollte trennen, welche Storefront-Elemente Daten, welche Design oder Zielkonfiguration und welche Legacy-Template-Funktion sind. Product-Beschreibungen, Category-Namen, CMS Pages und Bilddateien können Migrationsumfang sein. Template-Layout, generierte Buttons, Sideboxes, Navigationsmenüs und Frontpage-Module sind gewöhnlich Implementierung auf der Zielseite oder, bei tiefer individueller Logik, Fragen nicht standardisierter Behandlung.
Inhaltsvalidierung sollte Homepage-Blöcke, Informationsseiten, Kontaktseiten, Artikel-/News-Bereiche, eingeschränkte Inhalte, Category-Landingtexte, Policy-Seiten und SEO-sichtbare Inhalte umfassen. Wurden News, aktuelle Artikel, Aktionsboxen oder Specials über Content-Module dargestellt, muss entschieden werden, ob der Zielshop CMS Pages, Blog Posts, Seitenblöcke oder individuelle Konfiguration benötigt.
Auch Suche und Navigation müssen aus Customer-Sicht geprüft werden. Testen Sie häufige Product-Suchen, Category-Browse-Pfade, Header- und Sidebar-Navigation sowie Footer-/Policy-Zugriff. Pass bedeutet nicht visuelle Identität mit dem Altshop, sondern dass Customers Products finden, bewerten und kaufen können, ohne wichtigen kommerziellen Kontext zu verlieren.
Integrationen, Module und Anpassungsgrenzen validieren
Die osCMax-Validierung muss eine klare Grenze zwischen migrierten Daten und alten Funktionen ziehen. Installierte Module können Versandraten, Zahlungsoptionen, Order-Exporte, E-Mails, Inhaltsboxen, Customer-Einschränkungen, Bilddarstellung oder Admin-Produktivität gesteuert haben. Manche lassen sich durch native Zielkonfiguration ersetzen. Andere benötigen unterstützte Migrationsanpassungen. Bei Custom Tables, Dateiänderungen oder Contribution-spezifischen Datensätzen kann nicht standardisierte Behandlung erforderlich sein.
Vor der finalen Validierung sollte ein Modulinventar erstellt werden. Nicht jedes alte Modul muss erhalten bleiben. Wichtig ist, welche Module Umsatz, Fulfillment, Customer Service, Compliance oder Launch-Bereitschaft beeinflusst haben. Ein rein visuelles Modul kann entfallen. Verändert ein Modul Order Totals, Customer-Berechtigung, Versandraten, Product-Optionen oder Exportlogik, braucht es stärkere Prüfung.
| Legacy-Verhalten | Validierungspfad | Wahrscheinliche Behandlung |
|---|---|---|
| Altes Versandmodul | Historische Raten und Checkout-Verhalten mit Zielkonfiguration vergleichen. | Zielkonfiguration, unterstützte Migrationsanpassung oder nicht standardisierte Behandlung je Komplexität. |
| Order-Exportroutine | Erforderliche historische und operative Exportfelder bestätigen. | Vereinbartes Field Mapping oder nicht standardisierte Behandlung bei nicht standardisierten Feldern. |
| Template-spezifische Boxen | Bestimmen, ob Inhalt, Navigation oder individuelle Darstellung. | Ziel-Theme/-Konfiguration oder nicht standardisierte Behandlung bei Logikabhängigkeit. |
| Individueller Customer-Zugriff | Prüfen, ob Zugriff von Customer Group, Content Restriction oder maßgeschneiderter Logik abhängt. | Vereinbarte Datenkonfiguration, unterstützte Migrationsanpassung oder nicht standardisierte Behandlung. |
| Bild- oder Galerieänderungen | Hauptbilder, Zusatzbilder, Thumbnails und Galerieerwartung prüfen. | Standardmigration für zulässige Bilder; Zielkonfiguration oder nicht standardisierte Behandlung für Verhalten. |
Validierung darf keine Leistungen überversprechen. Unterstützte Migrationsanpassungen decken abgegrenzte Migrationsbedarfe ab. Nicht standardisierte Behandlung dient Anforderungen, die maßgeschneiderte Prüfung brauchen. Beides ist keine automatische Entwicklung des Zielshops. Entscheidend ist, ob altes Verhalten bewahrt, ersetzt, stillgelegt oder außerhalb des Migrationsumfangs neu aufgebaut wird.
Repräsentative, breitere und spätere osCMax-Ergebnisse validieren
Der repräsentative Migrationstest ist der sicherste Ort, um osCMax-Unsicherheit vor einem produktionsweiten Ergebnis sichtbar zu machen. Die Stichprobe sollte normale und bewusst schwierige Fälle enthalten: attribut- und bildreiche Products, Sonder- oder Mengenpreise, Downloadable Products, Customer Groups, ungewöhnliche Order Totals oder Status, Inhaltsseiten, Template-abhängige Navigation, Contribution-eigene Felder, Custom Tables und externe Kennungen.
Die breitere Migrationsausführung muss beweisen, dass die im Test akzeptierte Interpretation auch für ältere und seltene Datensätze gilt. Dazu gehören deaktivierte Products, langjährige Customers, Guest Orders, archivierte Status, historische Totals, alle priorisierten Inhaltspfade, verbleibende Contribution-Datensätze sowie finale Template- und Anpassungsentscheidungen. Historische Orders müssen erklärbar bleiben, ohne daraus abzuleiten, dass Live-Zahlung, Versand, Steuer, Checkout, E-Mail, Export oder Template-Verhalten bereits konfiguriert sind.
| Nachweisstufe | osCMax-Nachweis | Fehlersignal |
|---|---|---|
| Repräsentativer Migrationstest | Repräsentative Beziehungen aus Contributions, Attributen, Customer Groups, Order Totals, Inhalten und Templates sind erklärbar. | Stichprobe vermeidet Legacy-Module, Custom Tables oder ungewöhnliche kommerzielle Datensätze. |
| Breitere Migrationsausführung | Die freigegebene Interpretation bleibt bei alten, seltenen, deaktivierten und modulgeprägten Datensätzen konsistent. | Gewöhnliche Datensätze bestehen, historische oder Contribution-eigene Ausnahmen bleiben ungeprüft. |
| Launch-Nachweis | Jedes offene Verhalten hat Verantwortlichen, Behandlungspfad und Entscheidung zur Launch-Auswirkung. | Der Zielshop hängt weiterhin von undokumentierten Annahmen aus der alten osCMax-Installation ab. |
Spätere osCMax-Aktionen erfordern explizite Neuvalidierung aller betroffenen Legacy-Product-, Attribut-, Customer-, Order-, Routen-, Contribution- und Custom-Table-Beziehungen:
| Spätere Aktion | Erforderliche osCMax-Neuvalidierung |
|---|---|
| unter der freigegebenen Konfiguration fortfahren | Bestätigen, dass spätere Products, Customers, Orders, Blog Posts, Contribution-Felder und externe Kennungen der freigegebenen Interpretation folgen und kein neues Legacy-Muster einführen. |
| mit überarbeiteter Konfiguration fortfahren | Jede geänderte Filter-, Mapping-, Datenkategorie-, Contribution-Feld-, Custom-Table-, Inhalts- und Routenentscheidung erneut prüfen. |
| ein eigenständiges neues Migrationsergebnis erzeugen | Neue Nachweisbasis schaffen und relevante Entscheidungen aus repräsentativem Test und breiterer Ausführung für das eigenständige neue Ergebnis wiederholen. |
Launch-Handoff und Verantwortung nach der Migration validieren
Der finale osCMax-Review muss zwischen migrierten Nachweisen, Zielshop-Konfiguration, stillgelegtem Legacy-Verhalten und vereinbarten nicht standardisierten Deliverables unterscheiden. Langjährige Shops können von manueller Bildverwaltung, Order-Exporten, Admin-Abkürzungen, Inhaltsboxen, individuellen E-Mails, alten Zahlungsanweisungen oder Template-spezifischem Merchandising abhängen. Solche Gewohnheiten sind keine migrierten Datensätze, geschäftskritische Abhängigkeiten brauchen aber weiterhin einen benannten Verantwortlichen.
| Offenes Element | Erforderlicher Nachweis | Verantwortungsentscheidung |
|---|---|---|
| Interpretation historischer Orders | Totals, Status, Product-Auswahl, Zahlungs-/Versandbezeichnungen und Kommentare bleiben verständlich. | Händlerbetrieb bestätigt geschäftliche Nutzbarkeit. |
| Live-Checkout- oder Fulfillment-Verhalten | Zielkonfiguration für Zahlung, Versand, Steuer, Bestand, E-Mail und Export funktioniert unabhängig vom alten Modulcode. | Zielshop-Verantwortlicher oder Implementierungsteam. |
| Gekauftes, freigegebenes Migrationsergebnis | Vereinbartes Filter-, Mapping- oder Konfigurationsergebnis ist an benannten Stichproben sichtbar und reproduzierbar. | Der Kunde validiert das abgegrenzte Deliverable. |
| Vereinbartes nicht standardisiertes Deliverable | Custom Tables, Contribution-eigene Datensätze, maßgeschneiderte Transformationen oder externe Kennungen entsprechen dem freigegebenen Umfang. | Customer validiert das vereinbarte Ergebnis; nicht unterstützte neue Arbeit wird nicht impliziert. |
| Stillgelegtes Verhalten | Veraltetes Modul, Template-Kürzel oder manueller Prozess ist ausdrücklich als ausgeschlossen dokumentiert. | Händler akzeptiert Stilllegung und gegebenenfalls Ersatzprozess. |
Der Handoff besteht nur, wenn jedes offene Element Verantwortlichen, Behandlungspfad und Launch-Auswirkung besitzt. Der Nachweis sollte außerdem festhalten, ob die Abhängigkeit zu migrierten Daten, Zielkonfiguration, unterstützter Migrationsanpassung, vereinbartem nicht standardisiertem Deliverable, externem System oder bewusster Stilllegung gehört. So bleibt Legacy-Verhalten mit geringem Wert außerhalb des Umfangs, während geschäftskritische Abhängigkeiten sichtbar und testbar bleiben.
osCMax-Launch-Bereitschaft mit Pass, Watch oder Block entscheiden
osCMax-Nachweise sollten als Pass, Watch oder Block klassifiziert werden. Der Status gehört immer zu einem konkreten Product-Muster, einer Customer Group, einem Order-Typ, Inhaltspfad, einer Contribution, Custom Table oder Template-Abhängigkeit.
| Entscheidungsstatus | Erforderlicher Nachweis | Launch-Auswirkung |
|---|---|---|
| Pass | Migrierter Datensatz bewahrt Geschäftsbedeutung, zugehörige Zielshop-Verantwortung ist klar und Ergebnis lässt sich ohne alten Admin reproduzieren. | Der geprüfte Bereich unterstützt den Launch. |
| Watch | Ergebnis ist nutzbar, aber eine dokumentierte nicht blockierende Template-, Bild-, Reporting-, Inhalts- oder Konfigurationsaufgabe bleibt offen. | Launch darf nur mit Verantwortlichem und Folgenachweis fortgesetzt werden. |
| Block | Product-Auswahl ist falsch, Customer-Group-Bedeutung geht verloren, eine Order ist nicht erklärbar, ein priorisierter Pfad scheitert oder ein erforderliches Contribution-/Custom-Table-Ergebnis ist ungeklärt. | Launch-Freigabe bleibt aus, bis korrigiert oder der Umfang formell geändert wurde. |
Ein Block ist nicht dasselbe wie eine kosmetische Abweichung. Er bedeutet fehlende oder irreführende kommerzielle Bedeutung. Watch ist nur akzeptabel, wenn das aktuelle Ergebnis nutzbar ist und die Folgemaßnahme die freigegebene Dateninterpretation nicht verändern kann. Das Entscheidungsprotokoll sollte erwartetes Ergebnis, beobachtetes Ergebnis, betroffenen Geschäftsprozess, Verantwortlichen, Behandlungspfad und Re-Test-Nachweis dokumentieren. Ein Block darf erst zu Watch oder Pass werden, wenn derselbe repräsentative Datensatz erneut geprüft werden kann, ohne den alten osCMax-Shop zur Erklärung zu benötigen.
Fazit
Die osCMax-Validierung muss Geschäftsbedeutung und nicht nur abgeschlossene Übertragung beweisen. Da osCMax-Shops osCommerce-ähnliche Datensätze mit Contribution-eigenem Verhalten, Template-Abhängigkeiten, alten Versionslinien und individueller Wartungshistorie verbinden können, müssen Daten, Konfiguration, Storefront-Verhalten und nicht unterstützte Legacy-Logik getrennt geprüft werden.
Ein starkes Validierungsergebnis ermöglicht eine praktische Launch-Entscheidung: Products sind nutzbar, Orders erklärbar, Customers mit ihrer Historie verbunden, Inhalte und Navigation unterstützen den Kauf und alte Module sind als bewahrt, ersetzt, stillgelegt oder eskaliert klassifiziert. Sind diese Bedingungen erfüllt, kann die breitere Migrationsausführung mit klarerem Umfang und weniger späten Überraschungen fortgesetzt werden.
Häufige Fragen
Warum unterscheidet sich die osCMax-Validierung von einer gewöhnlichen osCommerce-Validierung?
osCMax kann osCommerce-abgeleitete Datensätze mit gebündelten Contributions, alten Modulen, Templates, individuellen Feldern und Wartungshistorie verbinden. Validierung muss sowohl die migrierten Geschäftsdaten als auch die Verantwortlichkeit für Contribution- oder Template-abhängiges Verhalten beweisen.
Was sollte eine repräsentative osCMax-Teststichprobe enthalten?
Nehmen Sie attributreiche, bildreiche, rabattierte, Downloadable-, Customer-Group-, ungewöhnliche Order-Total-, Inhalts-, Custom-Table- und modulsensitive Datensätze auf statt nur saubere Products und gewöhnliche Orders.
Soll jedes alte osCMax-Modul auf der Zielplattform rekonstruiert werden?
Nein. Klassifizieren Sie jedes Verhalten als durch migrierte Daten bewahrt, durch Zielkonfiguration ersetzt, von einer unterstützten Migrationsanpassung oder einem nicht standardisierten Deliverable abgedeckt, von einem anderen System getragen oder bewusst stillgelegt.
Wie sollten historische Orders von der Live-Checkout-Validierung getrennt werden?
Historische Orders müssen verständliche Lines, Totals, Status, Kommentare, Zahlungs- und Versandbezeichnungen behalten. Live-Checkout, Zahlung, Versand, Steuer, E-Mail, Bestand und Export benötigen separate Nachweise aus der Zielshop-Konfiguration.
Wann ist ein osCMax-Fund ein Block?
Block gilt, wenn Product-Auswahl, Customer-Group-Bedeutung, Order-Interpretation, priorisierte Inhaltspfade, Custom Tables oder vereinbarte Contribution-eigene Ergebnisse materiell falsch oder ungeklärt bleiben.
Was muss nach einer späteren osCMax-Migrationsaktion erneut validiert werden?
Validieren Sie alle betroffenen Products, Customers, Orders, Blog Posts, Contribution-Felder, Custom-Table-Beziehungen, Inhaltspfade und externen Kennungen erneut. Eine geänderte Konfiguration oder ein neues Ergebnis braucht eine neue Nachweisbasis.