Wenn osCMax als mögliche Zielplattform bewertet wird, sollte sein Datenmodell als von osCommerce abgeleitete Commerce-Installation verstanden werden, deren tatsächliche Struktur durch das installierte Paket, Contributions, Templates, geänderte Dateien und individuelle Datenbankstrukturen geprägt wird. Zwei osCMax-Shops können vertraute Tabellen für Products, Categories, Customers und Orders teilen und sich dennoch unterschiedlich verhalten, weil einer eine gebündelte Contribution nutzt, ein anderer jahrelange direkte Codeänderungen enthält und ein dritter auf individuelle Exporte oder externe Systeme angewiesen ist.
Abstammung und Eigentümerschaft sind deshalb wichtiger als vertraute Tabellennamen. Ein Product-Attribut, Customer-Segment, Order Total, Content-Objekt oder eine externe Kennung aus dem Quellshop kann im osCMax-Kernmodell, in einer Contribution-Struktur, in einer Custom Table oder in einem weiterhin betriebenen externen System landen müssen. Dieses Ziel muss feststehen, bevor ein Wert als sicher darstellbar gilt.
Das Migrationsmodell sollte Geschäftsbeziehungen erhalten, nicht jeden Quellmechanismus kopieren. Es muss unterscheiden, welche Bedeutung zu Core-Commerce-Datensätzen gehört, welche unterstütztes Mapping erfordert, welche von osCMax-Konfiguration oder Contributions abhängt und welches Quellverhalten besser neu gestaltet oder stillgelegt wird.
Die Bedeutung von osCMax beginnt mit Abstammung und installierten Contributions
osCMax stammt aus der osCommerce-Familie, wurde aber mit zusätzlichen Funktionen ausgeliefert und häufig durch Contributions erweitert. Langjährig betriebene Shops können mehrere Generationen von Core-Dateien, Datenbank-Patches, Templates, Sprachdateien, Zahlungsmodulen, Versandmodulen, Order-Total-Modulen und händlerspezifischen Änderungen enthalten.
Die Quellversion allein beschreibt das Schema nicht vollständig. Installierter Code und Datenbank müssen zusammen betrachtet werden. Eine Tabelle kann standardisiert aussehen und trotzdem zusätzliche Spalten enthalten. Ein vertrautes Feld kann von individuellem Code gelesen werden. Eine Contribution kann eigene Tabellen anlegen und sie über interne IDs mit Products, Customers oder Orders verknüpfen. Datenherkunft ist deshalb eine Frage auf Datenkategorie- und Beziehungsebene und nicht nur eine technische Inventur.
| Quellebene | Typische Nachweise | Konsequenz für das Datenmodell |
|---|---|---|
| Von osCommerce abgeleiteter Kern | Products, Categories, Customers, Adressen, Orders, Manufacturers, Reviews | Lässt sich gewöhnlich über vertraute Commerce-Beziehungen abbilden. |
| osCMax-Paketebene | Gebündelte Erweiterungen, Template-Konventionen, Verwaltungsfelder | Prüfen, ob der Wert Daten, Konfiguration oder Darstellung ist. |
| Installierte Contribution | Zusätzliche Tabellen, Felder, Status, Reports, Rabatte, Gutscheine, Versand- oder Zahlungslogik | Contribution und ihre Beziehungen zu Core-Datensätzen bestimmen. |
| Händleranpassung | Bearbeitetes PHP, SQL-Änderungen, individuelle Sprachdateien, maßgeschneiderte Exporte | Als individuelle Eigentumsgrenze statt als natives Plattformverhalten behandeln. |
| Externes System | ERP, Buchhaltung, Lager, Marketplace, CRM, Lieferantenfeed | Stabile externe Kennungen und Systemautorität bewahren. |
| Veraltetes technisches Artefakt | Aufgegebene Modultabellen, ungenutzte Felder, alte Template-Dateien | Ungenutzte technische Rückstände nicht zu Zieldaten aufwerten. |
Diese mehrschichtige Betrachtung verhindert einen häufigen Fehler: die Annahme, dass alle Datensätze in einer erkennbaren osCommerce-ähnlichen Tabelle in jeder osCMax-Installation dieselbe Bedeutung haben.
Products, Categories, Manufacturers und Attribute bilden den Katalogkern
Der grundlegende osCMax-Katalog dreht sich gewöhnlich um Products, Categories, Manufacturers, Product-Beschreibungen, Bilder, Bestand, Preise, Specials, Reviews und Product-Attribute. Products können Categories zugewiesen sein; mehrsprachige Installationen können Namen und Beschreibungen sprachabhängig getrennt speichern. Attribute verbinden Optionsnamen und -werte mit Products und können abhängig vom installierten Contribution-Set Preis, Gewicht, Modell, Bestand oder anderes Verhalten beeinflussen.
Wichtiger als einzelne Zeilen ist die Beziehung zwischen Products, Categories und Attributen. Ein Quellshop kann einen Product-Datensatz mit mehreren Attributen verwenden, für jede SKU getrennte Product-Datensätze anlegen oder Contribution-spezifische Tabellen für Bestand je Attribut führen. Das Zielmodell sollte nicht allein deshalb unabhängige Varianten ableiten, weil Optionswerte vorhanden sind. Ebenso darf Bestand nicht pauschal dem Parent Product zugeordnet werden, wenn Kombinationen im Quellshop eigenständig verkauft werden.
| Quellmuster | osCMax-Interpretation | Zu bewahrende Beziehung |
|---|---|---|
| Standard-Product | Core-Product-Datensatz | Identität, Beschreibung, Preis, Steuer, Bestand, Bilder und Category-Beziehungen. |
| Product in mehreren Categories | Product-zu-Category-Beziehung | Eine kommerzielle Identität mit mehreren Auffindbarkeitspfaden. |
| Manufacturer oder Marke | Manufacturer-Datensatz und Product-Verknüpfung | Markenidentität bleibt von Category-Platzierung getrennt. |
| Größen- oder Farbattribut | Product-Attribut-Beziehung | Optionsname, Wert, Product, Preis-/Gewichtseffekt und Bezeichnung auf der Order Line. |
| Kombinationsspezifischer Bestand | Contribution-eigener Attribut-/Bestandsdatensatz | Product, Optionskombination, Menge, SKU und externer Schlüssel. |
| Sonderpreis | Product-Special-Beziehung | Aktiver Preis und Zeitkontext bleiben vom Basispreis getrennt. |
| Review | Review mit Product- und, soweit vorhanden, Customer-Bezug | Bewertung, Text, Datum, Status und Product-Identität. |
Eine Product-Beschreibung kann nahezu jede Information anzeigen, ersetzt aber keine strukturierten Beziehungen zu Categories, Manufacturers, Attributen, Bestand oder Reviews.
Attributkombinationen, Bestand, Bilder und Preise hängen häufig von Erweiterungen ab
Ältere osCMax-Shops verwenden häufig Contributions, um das Core-Modell für Product-Attribute zu erweitern. Solche Erweiterungen können Bestand auf Attributebene, getrennte Kombination-SKUs, zusätzliche Bilder, weitere Product-Felder, Mengenrabatte, Preise je Customer Group, Geschenkgutscheine oder individuelle Product-Konfiguratoren einführen. In der Storefront können diese Funktionen nativ wirken, obwohl ihre Datensätze außerhalb der Core-Tabellen liegen.
Bei der Migration sollte jede Auswahl nach ihrem kommerziellen Verhalten klassifiziert werden. Eine rein beschreibende Option benötigt keinen eigenen Bestand. Eine verkaufbare Kombination mit eigener SKU und eigenem Bestand dagegen schon. Eine Texteingabe gehört zur Order Line. Ein Mengenpreis gehört in eine Beziehung zwischen Product und Schwellenwert. Ein zusätzliches Bild kann zu einem Product, einem Optionswert oder einer Template-Galerie-Contribution gehören.
| Verhalten | Wahrscheinlicher Eigentümer | Abbildungsgrenze |
|---|---|---|
| Option ändert nur Preis oder Gewicht | Core-Product-Attribut-Beziehung | Optionsname, Wert, Product-Verknüpfung und Anpassung erhalten. |
| Kombination hat eigenen Bestand oder SKU | Attribut-/Bestands- oder Varianten-Contribution | Kombinationsidentität und Menge getrennt vom Parent erhalten. |
| Käufer gibt Gravur oder Nachricht ein | Texteingabe-Contribution | Eingegebenen Wert an der gekauften Order Line erhalten. |
| Product hat mehrere Galeriebilder | Bild-Contribution oder Template-Konvention | Medienidentität und Product-/Optionsbeziehung erhalten. |
| Mengen- oder Customer-Preis | Pricing-Contribution | Product, Schwellenwert oder Gruppe, Währung und Betrag verknüpft erhalten. |
| Geschenkgutschein oder Voucher | Voucher-Contribution und zugehörige Order-Datensätze | Code, Restwert, Empfänger, Einlösung und aktive Order-Historie erhalten. |
Maßgeblich sind die tatsächlichen Tabellen- und Codebeziehungen des Quellshops. Ein allgemeiner Export von Attributen reicht nicht aus, wenn eine Erweiterung die verkaufbare Kombination an anderer Stelle verwaltet.
Customers, Address Books, Gruppen und Kontoerweiterungen sind getrennte Strukturen
Das von osCommerce abgeleitete Customer-Modell umfasst typischerweise ein Customer-Konto, ein Address Book, Verweise auf Standardadressen, Login-Daten und Kommunikationspräferenzen. osCMax-Contributions können Customer Groups, Großhandelsstatus, Steuerkennungen, zusätzliche Profilfelder, Referral-Daten, Reward Points, Guthaben oder Freigabe-Workflows hinzufügen.
Diese Datensätze müssen nach Zweck getrennt werden. Eine gespeicherte Adresse ist wiederverwendbare Customer-Stammdaten. Billing- und Shipping-Adressen auf einer Order sind Transaktions-Snapshots. Eine Großhandelsgruppe kann Preise oder Zugriff steuern. Eine Marketingquelle oder Referral-Kennung kann Reporting-Metadatum sein. Eine externe CRM-Kennung kann der Schlüssel sein, mit dem der Customer nach der Migration wieder verknüpft wird.
| Element des Quellkontos | Eigentümer | Zu erhaltende Bedeutung |
|---|---|---|
| Customer-Konto | Core-Customer-Datensatz | Identität und Beziehung zu Adressen und Orders. |
| Address-Book-Eintrag | Customer-Adressdatensatz | Wiederverwendbare Adressbeziehung. |
| Billing-/Shipping-Adresse einer Order | Order-Snapshot | Historischer Transaktionsnachweis. |
| Großhandels- oder Händlergruppe | Contribution-eigene Customer-Klassifikation | Gruppenmitgliedschaft und zugehörige Preis-/Zugriffsregeln. |
| Zusätzliches Profilfeld | Contribution-Feld oder Custom Table | Feldzweck, Datenschutz und Customer-Schlüssel. |
| Reward Points oder Guthaben | Loyalty-/Credit-Contribution | Saldo, Transaktionshistorie und zugehöriger Workflow. |
| ERP- oder CRM-Schlüssel | Externe Kennung | Dauerhafte systemübergreifende Identität. |
Ein flacher Customer-Export kann Kontaktdaten bewahren und dennoch die kommerzielle Beziehung verlieren, durch die der Customer als Händler, steuerbefreiter Käufer oder Kreditkunde behandelt wurde.
Orders, Order Totals, Status, Zahlungen und Versand tragen historische Nachweise
osCMax-Orders können Customer- oder Gastidentität, Billing- und Shipping-Snapshots, Product Lines, Attributbezeichnungen, Mengen, Preise, Steuern, Rabatte, Versand, Zahlungsbezeichnungen, Order-Status, Kommentare und Contribution-eigene Datensätze enthalten. Besonders wichtig ist die Order-Total-Ebene, weil viele Legacy-Module getrennte Positionen für Zwischensumme, Steuer, Versand, Coupon, Geschenkgutschein, Zuschlag, Kleinmengengebühr, Rabatt oder Guthaben erzeugen.
Diese Positionen sind nicht mit der aktuellen Checkout-Konfiguration gleichzusetzen. Historische Orders sollten bewahren, was berechnet wurde und warum, auch wenn der Zielshop andere Steuer-, Versand-, Zahlungs- oder Aktionsregeln verwendet. Eine Transaktions-ID aus einem Zahlungsmodul kann wichtiger historischer Nachweis sein; Zugangsdaten oder Code des alten Moduls gehören jedoch nicht zum Order-Datensatz.
| Order-Element | Historischer Eigentümer | Zu bewahrende Bedeutung |
|---|---|---|
| Product Line | Order-Product-Snapshot | Name, Modell/SKU, Menge, Preis und beim Kauf gewählte Attribute. |
| Adresse | Billing-/Shipping-Snapshot der Order | Historische Adresse unabhängig von aktuellen Customer-Daten. |
| Order-Total-Zeile | Order-Total-Modul oder Core-Total-Datensatz | Bezeichnung, Betrag, Sortierreihenfolge und Auswirkung auf die Endsumme. |
| Zahlungsreferenz | Transaktionsdatensatz des Zahlungsmoduls | Historischer Abstimmungsschlüssel, ohne ihn als Live-Konfiguration zu behandeln. |
| Versandmethode und Tracking | Versandmodul und Shipment-Kontext | Carrier-/Methodenbezeichnung, Kosten, Tracking und Fulfillment-Nachweis. |
| Order-Status und Kommentare | Order-Historie | Reihenfolge, Datum, Sichtbarkeit und Mitarbeiter-/Customer-Kontext. |
| Return-, Voucher- oder Credit-Datensatz | Contribution-eigener After-Sales-Datensatz | Beziehung zur Order, betroffener Betrag und gegebenenfalls Restwert. |
Das Order-Modell ist dann brauchbar, wenn Mitarbeiter die ursprüngliche Transaktion verstehen können, ohne das stillgelegte Modul rekonstruieren zu müssen, das sie erzeugt hat.
Inhalte, Boxen, Templates, Sprachdateien und Bilder haben unterschiedliche Eigentümer
osCMax-Storefronts verwenden häufig Templates, Boxen, Sprachdateien, Banner, Informationsseiten, Product-Beschreibungen, Category-Beschreibungen, Bilder, Buttons und durch Contributions erzeugte Blöcke. All diese Assets beeinflussen die Kundensicht, sind aber nicht dieselbe Inhaltsdatenkategorie.
Product- und Category-Beschreibungen gehören zu Katalogdatensätzen. Informationsseiten können in einer Inhalts-Contribution oder statischen Dateien gespeichert sein. Box-Überschriften und Interface-Texte können in Sprachdateien liegen. Die Box-Platzierung gehört zum Template. Buttons und Icons sind Theme-Assets. Ein Aktionsblock kann aus Konfiguration erzeugt werden, statt als Seite gespeichert zu sein.
| Storefront-Asset | Daten- oder Darstellungseigentümer | Migrationsinterpretation |
|---|---|---|
| Product-/Category-Beschreibung | Katalogdatensatz | Inhalt mit Datenkategorie und Sprache erhalten. |
| Informations- oder Richtlinienseite | Inhalts-Contribution oder statischer Inhalt | Seitenidentität, Route und Navigationsbeziehung erhalten, wenn weiterhin aktiv. |
| Box-Überschrift oder Interface-Bezeichnung | Sprachdatei | Als Interface-Text, nicht als CMS-Inhalt behandeln. |
| Box-Platzierung | Template-Konfiguration | Zielplatzierung getrennt vom Inhalt neu aufbauen. |
| Product-Galeriebild | Product- oder Bild-Contribution | Medienbeziehung und Options-/Variantenumfang erhalten. |
| Button, Icon oder Hintergrund | Theme-Asset | Nur beibehalten, wenn weiterhin Designwert besteht. |
| Legacy-URL | Product, Category, Inhalt oder individuelle Route | Quell-zu-Ziel-Redirect-Beziehungen erhalten. |
Diese Trennung ermöglicht es, wertvolle Inhalte und Medien zu übertragen, ohne veraltete Template-Mechanik in den Zielshop mitzunehmen.
Contributions und Custom Tables können geschäftskritische Datensätze besitzen
Die zentrale Herausforderung von osCMax ist die Eigentümerschaft von Contributions. Eine Contribution kann einem Core-Table ein Feld hinzufügen, eine eigenständige Datenkategorie erzeugen, eine Order-Berechnung verändern, einen neuen Status einführen oder eine Beziehung über einen individuellen Schlüssel pflegen. Die Zielentscheidung hängt vom geschäftlichen Zweck ab, nicht davon, wie leicht sich eine Datenbankzeile exportieren lässt.
| Contribution-Muster | Beispielbedeutung | Erforderliche Eigentumsentscheidung |
|---|---|---|
| Zusätzliche Product-Spalten | Lieferantencode, Badge, Garantie, Einschränkung, Feed-Status | In natives Feld, strukturiertes Attribut, externen Schlüssel oder Archiv abbilden. |
| Individuelle Product-Tabelle | Fitment, Bundle-Bestandteil, Subscription, Staffelpreise | Datenkategorie und Product-Beziehungen erhalten, sofern weiterhin aktiv. |
| Customer-Erweiterung | Freigabe, Loyalty, Referral, Steuer, Händlerstatus | Klassifikation sowie Regeln oder Historie bewahren, die ihr Bedeutung geben. |
| Order-Erweiterung | Fraud-Flag, Exportstatus, Zahlungsreferenz, Fulfillment-Batch | Als historische Metadaten erhalten oder mit Zielworkflow verbinden. |
| Reporting-/Exporttabelle | Buchhaltungs- oder Betriebsstatus für Extrakte | Nur erhalten, wenn weiterhin maßgeblicher geschäftlicher Datensatz. |
| Veränderte Core-Logik | Geändertes Steuer-, Versand-, Preis- oder Berechtigungsverhalten | Geschäftsregel im Zielmodell darstellen, nicht den alten PHP-Mechanismus. |
Wenn kein aktueller Workflow einen Contribution-Datensatz mehr verwendet, kann Archivierung genauer sein als eine erzwungene Überführung in ein generisches individuelles Feld. Aktive Datensätze benötigen eine explizite Zielverantwortung und stabile Beziehungen zu Core-Products, Customers oder Orders.
osCMax-Abbildungsentscheidungen nach geschäftlicher Bedeutung
| Quellmuster | Richtige Abbildungsfrage | Folge einer falschen Annahme |
|---|---|---|
| Vertraute Core-Tabelle mit Zusatzspalten | Welche Felder sind Core-, Paket-, Contribution- oder individuelle Felder? | Erweiterungsdaten werden fälschlich wie ein natives Zielfeld behandelt. |
| Product-Attribute plus separate Bestandstabelle | Welche Kombination besitzt SKU und Menge? | Parent-Bestand ersetzt den Bestand verkaufbarer Kombinationen. |
| Customer Group oder Händlerkennzeichen | Welche Preise, Zugriffsregeln, Steuern oder Zahlungsbedingungen hängen davon ab? | Gruppenname bleibt erhalten, seine kommerzielle Bedeutung verschwindet. |
| Mehrere Order-Total-Zeilen | Welches Modul erzeugte jeden Betrag und wie wirkt er auf die Endsumme? | Historische Summen werden unvollständig oder irreführend. |
| Storefront-Box | Ist der Wert Inhalt, Konfiguration, Sprachtext oder Template-Platzierung? | Sichtbarer Text kommt ohne Route oder Platzierung an oder veralteter Code wird als Daten bewahrt. |
| Individuelle Export-ID | Welches externe System besitzt den Schlüssel? | Products, Customers oder Orders können nach der Migration nicht abgestimmt werden. |
| Aufgegebene Contribution-Tabelle | Hängt noch ein aktueller Workflow davon ab? | Technischer Ballast wird dauerhaft in das Zielsystem übernommen. |
osCMax-Daten bleiben dann nützlich, wenn grundlegende Commerce-Fakten von den Contribution- oder Template-Mechanismen getrennt werden, die sie früher dargestellt oder verarbeitet haben.
Fazit
Bei der Bewertung von osCMax als Zielplattform beginnt die Abbildung des Datenmodells mit der Abstammung der Quelldaten. Products, Categories, Customers, Adressen, Orders, Manufacturers, Reviews und Attribute können dem osCommerce-abgeleiteten Kern folgen. Erweiterungen können jedoch eigenen Bestand, Preise, Gutscheine, Customer-Klassifikationen, Order Totals, Inhaltsstrukturen, Exporte und Custom Tables hinzufügen. Templates und Sprachdateien prägen zusätzlich die Storefront, ohne zu gewöhnlichen Commerce-Datenkategorien zu werden.
Ein belastbarer Zielshop bewahrt geschäftliche Fakten und aktive Beziehungen: Product-Identität, verkaufbare Auswahlmöglichkeiten, Customer-Kontext, historische Order Totals, nützliche Inhalte und externe Kennungen. Er nimmt nicht an, dass jede Contribution, geänderte Datei oder jedes alte Template-Artefakt ein direktes Gegenstück im Ziel verdient.
Häufige Fragen
Warum können zwei osCMax-Shops unterschiedliche Datenmodelle haben?
Installierte Paketversionen, Contributions, Templates, Datenbank-Patches und Händleranpassungen können sich unterscheiden. Vertraute Core-Tabellen können deshalb unterschiedliche Felder enthalten oder von anderem Code interpretiert werden.
Sind osCMax-Product-Attribute dasselbe wie unabhängige Varianten?
Nicht immer. Core-Attribute können ein Product verändern, während eine Contribution zusätzlich SKU, Bestand, Preis oder Bilder auf Kombinationsebene verwaltet. Eine eigenständige verkaufbare Identität sollte aus der vollständigen Beziehung und nicht nur aus Optionsbezeichnungen abgeleitet werden.
Wie sollten Customer Groups oder Händlerfelder interpretiert werden?
Bestimmen Sie, welches Verhalten sie steuern, etwa Preise, Zugriff, Steuerbehandlung, Zahlungsbedingungen oder Freigabe. Die Klassifikationsbezeichnung allein ist ohne zugehörige Geschäftsregeln unvollständig.
Warum sind osCMax-Order-Total-Datensätze wichtig?
Sie können Zwischensumme, Steuern, Versand, Coupons, Geschenkgutscheine, Rabatte, Gebühren oder Guthaben erklären. Wird nur die Endsumme bewahrt, geht die historische Struktur verloren, die zeigt, wie dieser Betrag zustande kam.
Sollten Templates, Boxen, Buttons und Sprachdateien als Inhalte migriert werden?
Nur wenn sie weiterhin benötigte geschäftliche Inhalte enthalten. Platzierung, Interface-Bezeichnungen und visuelle Assets gehören zur Darstellung. Ihre Bedeutung sollte von Product-, Category- und Inhaltsdatensätzen getrennt werden.
Was sollte mit Contribution-eigenen Daten oder Custom-Table-Daten geschehen?
Bestimmen Sie die Contribution, die von ihr erweiterten Core-Datensätze und den Workflow, der diese Daten weiterhin verwendet. Aktive Beziehungen benötigen eine explizite Zielverantwortung; veraltete Datensätze können archiviert oder ausgeschlossen werden, statt sie in generische Felder zu zwingen.