Für die Bewertung von osCommerce als möglicher Zielplattform ist entscheidend, wie das Datenmodell Quellbeziehungen und Geschäftsbedeutung aufnehmen kann. osCommerce umfasst heute zwei deutlich unterschiedliche Datenepochen. Das moderne osCommerce v4 bietet mehrere Front Ends beziehungsweise Vertriebskanäle, konfigurierbare Products, Kundengruppen, Product-Attribute, Product-Eigenschaften, Marken, CMS-Steuerung, Themes, Apps und erweiterte Preismodelle. Viele Quellshops laufen jedoch weiterhin auf älteren 2.x-basierten Datenbanken oder stark angepassten Installationen, deren Erweiterungen und Tabellenstrukturen nicht dem v4-Modell entsprechen.
Diese Versionslinie ist die erste Datenmodellentscheidung. Ein Datensatz aus products_attributes eines älteren Shops entspricht nicht automatisch einem aktuellen v4-Attribut, einer Eigenschaft oder einer Beziehung eines konfigurierbaren Products. Eine Legacy-Erweiterungstabelle kann Bestands-, Lieferanten-, Gutschein-, SEO- oder Order-Daten enthalten, die v4 an anderer Stelle abbildet. Ein aktuelles v4-Product kann außerdem Vertriebskanälen und Kundengruppen zugewiesen werden, Beziehungen, die in älteren Installationen nicht in gleicher Form existieren.
Die Migrationsplanung muss deshalb für jeden Datensatz klären, welche osCommerce-Generation ihn besitzt, welche geschäftliche Bedeutung er hat und welche verbundenen Entitäten im Zielshop zusammenbleiben müssen.
Die Versionslinie bildet eine Datenmodellgrenze in osCommerce
Modernes v4 und ältere osCommerce-Shops dürfen nicht wie ein einheitliches Schema behandelt werden. v4 ist eine aktuelle Open-Source-Plattform mit mehreren Front Ends, CMS-Steuerung, konfigurierbaren Products, Themes, Apps und einem neueren Administrationsmodell. Ältere 2.x-Shops verwenden dagegen häufig direkte Tabellenerweiterungen, manuell installierte Module, veränderte PHP-Dateien und Community-Contributions.
Der Quellshop kann außerdem Upgrades oder Forks durchlaufen haben. Tabellennamen können vertraut aussehen, obwohl sich Felddefinitionen und Beziehungen tatsächlich geändert haben. Die Versionslinie bestimmt daher, ob eine Product-Option, Kundengruppe, ein Vertriebskanal, eine Inhaltsseite oder ein Erweiterungsdatensatz ein natives aktuelles Äquivalent besitzt.
| Nachweis in der Quelle | Interpretation in osCommerce | Auswirkung auf die Migration |
|---|---|---|
| Aktuelle v4-Product- und Zuweisungsdatensätze | Modernes osCommerce-Katalogmodell | Products, Categories, Marken, Attribute, Eigenschaften, Kanäle und Kundengruppenbeziehungen erhalten. |
| Legacy-2.x-Kerntabellen | Früheres osCommerce-Datensatzmodell | Über Legacy-Beziehungen interpretieren, nicht über aktuelle v4-Bezeichnungen. |
| Tabellen oder Spalten aus Community-Erweiterungen | Daten im Besitz einer Erweiterung | Erweiterung und den von ihr veränderten Kerndatensatz identifizieren. |
| Verändertes PHP und SQL | Individuelle Geschäftslogik oder eigenes Schema | Geschäftliche Bedeutung übersetzen, statt den alten Mechanismus zu kopieren. |
| Von einem Fork abgeleiteter Shop | Verwandte, aber nicht identische Plattformlinie | Entitätsdefinitionen und IDs anhand der tatsächlichen Installation bestätigen. |
| Kennung eines externen Systems | ERP-, PIM-, WMS-, Marketplace-, Accounting- oder Fulfillment-Kennung | Dauerhafte systemübergreifende Identität erhalten. |
Diese Trennung verhindert, dass ein modernes Zielmodell auf Annahmen aufgebaut wird, die nur für eine ältere Quellinstallation galten.
Products, Categories, Marken und Vertriebskanäle sind verbunden, aber eigenständig
Im aktuellen osCommerce v4 kann ein Product Kernidentität, Beschreibungen, Kennungen, Preis und Kosten, Steuern, Bestandsmodus, Bilder, Videos, Verpackung, virtuelle oder herunterladbare Eigenschaften, SEO-Daten, Lieferanten, Notizen und Marketingbeziehungen tragen. Products können Vertriebskanälen und Kundengruppen zugewiesen oder für diese eingeschränkt werden. Auch Categories können bestimmten Front Ends und Kundengruppen zugeordnet werden.
Das ist mehr als eine Product-zu-Category-Hierarchie. Ein einzelnes Product kann über mehrere Front Ends gemeinsam genutzt werden und dabei unterschiedliche Sichtbarkeit, Inhalte, Preise oder geschäftliche Kontexte haben. Ein Quell-Multi-Store, der Products dupliziert, lässt sich möglicherweise besser als eine Product-Identität mit Kanalzuweisungen darstellen. Eine andere Quelle kann tatsächlich getrennte Products benötigen, weil sich ihre kommerzielle Identität unterscheidet.
| Struktur in der Quelle | Eigentümer in osCommerce v4 | Zu erhaltende Beziehung |
|---|---|---|
| Kanonischer verkaufbarer Artikel | Product | Identität, Kennungen, Preis, Bestand, Medien, Steuern und Beschreibungen. |
| Browsing-Hierarchie | Category und Product-Zuweisung | Category-Baum und Many-to-many-Platzierung der Products. |
| Marke oder Hersteller | Marken- oder Lieferantenbeziehung | Markenidentität bleibt von Category-Klassifikation getrennt. |
| Regionale oder markenspezifische Storefront | Front End oder Vertriebskanal | Verfügbarkeit von Products und Categories je Kanal. |
| Käuferabhängiger Katalog | Product-/Category-Zuweisung zur Kundengruppe | Sichtbarkeit und Verfügbarkeit bleiben mit der vorgesehenen Gruppe verbunden. |
| Verwandtes Merchandising | XSell, UPSell, Product Groups oder andere Product-Beziehung | Merchandising-Beziehungen bleiben von der Category-Mitgliedschaft getrennt. |
Die Anzahl migrierter Products sagt wenig darüber aus, ob das Product mit dem richtigen Front End, der richtigen Category, Kundengruppe oder Marke verbunden ist.
Attribute, Eigenschaften, konfigurierbare Products und Product Groups erfüllen unterschiedliche Rollen
Das aktuelle osCommerce v4 unterscheidet Attribute von Eigenschaften. Attribute können auswählbare Werte definieren, Vorlagen verwenden, Preis oder Gewicht verändern, virtuelle/herunterladbare Dateien unterstützen und in die Product-Bestandslogik einfließen. Eigenschaften beschreiben Product-Merkmale und können Darstellung, Filterung, Suche, Vergleich, Product Groups, Symbole, Farbfelder, Bereiche und strukturierte Werte unterstützen.
Eine Option aus der Quelle sollte deshalb nach ihrem Verhalten klassifiziert werden. Wählt der Käufer einen Wert, der den gekauften Artikel verändert, gehört er in die Attribut- oder konfigurierbare-Product-Ebene. Beschreibt der Wert den Artikel für Suche oder Vergleich, passt er in die Eigenschaftsebene. Gruppiert er Products für Merchandising oder gemeinsame Merkmale, kann eine Product-Group-Beziehung geeigneter sein.
| Bedeutung in der Quelle | Zu prüfende osCommerce-Struktur | Beziehungsgrenze |
|---|---|---|
| Größen- oder Farbauswahl | Attribut und zugewiesener Wert | Product, Auswahl, Preis-/Gewichtseffekt und gewählter Order-Line-Wert. |
| Kombination mit eigenständigem Bestand | Konfigurierbares Product oder Attribut-Bestandsbeziehung | Child-/Kombinationsidentität, Menge, SKU und Verfügbarkeit. |
| Technische Spezifikation | Eigenschaftskategorie, Eigenschaft und Wert | Strukturierte Information bleibt von einer Kaufoption getrennt. |
| Filterbarer Bereich | Eigenschaft mit Filter-/Suchdarstellung | Typ, Einheit, Bereich und Product-Werte bleiben normalisiert. |
| Wiederverwendbarer Optionssatz | Attributvorlage | Definitionen bleiben für die vorgesehenen Products wiederverwendbar. |
| Product-Familie oder Vergleichsgruppe | Product Group oder verwandte Product-Beziehung | Gruppenbedeutung bleibt von der Category-Hierarchie getrennt. |
| Digitale Datei | Virtuelles/herunterladbares Product und Attribut-/Dateibeziehung | Datei, Ablauf, Download-Limit, Product und Order-Kontext. |
Legacy-osCommerce-Attribute müssen möglicherweise in diese modernen Rollen neu eingeordnet werden. Nur den alten Feldnamen beizubehalten, ohne das Verhalten zu klassifizieren, kann eine verkaufbare Kombination in einen Filterwert verwandeln oder eine Spezifikation fälschlich zu einer bestandsführenden Option machen.
Bestand, Preise, Lieferanten, Kanäle und Kundengruppen bilden ein kommerzielles Beziehungsnetz
Aktuelle v4-Product-Datensätze können echten Bestand oder alternative Bestandsmodi, Lieferantenkosten, Mengenrabatte, empfohlene Preise, Steuerklasse, Kanalverfügbarkeit, Kundengruppenzuweisungen und gruppenspezifische Einschränkungen enthalten. Weitere Apps können Wholesale-, Marketplace-, Retail- oder Enterprise-Verhalten ergänzen.
Diese Beziehungen sollten als Netz verstanden und nicht in Product-Spalten abgeflacht werden. Ein Quellpreis kann zu einer Kundengruppe, Mengenschwelle, Lieferantenkostenregel, einem Kanal, einer Währung oder Promotion gehören. Ein Bestandswert kann zu einem Product, einer Attributkombination, einem Standort oder externen Lager gehören. Eine Lieferantenkennung kann ein internes Product-Feld oder der Schlüssel zu einem externen Beschaffungsdatensatz sein.
| Kommerzieller Wert | Eigentümer und Beziehung | Zu erhaltende Bedeutung |
|---|---|---|
| Basisverkaufspreis | Product und Währung | Standardmäßiger kommerzieller Wert. |
| Sichtbarkeit für Kundengruppe | Product-/Category-zu-Gruppe-Zuweisung | Käuferzugriff auf das Katalogobjekt. |
| Gruppen- oder Wholesale-Preis | Product, Kundengruppe und Preisregel | Vorgesehener Käuferkontext und Betrag. |
| Mengenrabatt | Product und Schwellenbeziehung | Mengengrenzen und Preiswirkung. |
| Lieferantenkosten | Product-zu-Lieferant-Beziehung | Beschaffungsverantwortung, Kosten, Währung und Lieferantenschlüssel. |
| Kanalverfügbarkeit | Product-/Category-zu-Front-End-Beziehung | Wo der Artikel angeboten wird. |
| Bestandsmenge | Product oder konfigurierbare Kombination und Bestandsverantwortlicher | Verkaufbare Identität und maßgeblicher Bestand. |
Historische Order-Preise müssen historische Momentaufnahmen bleiben. Sie dürfen nach der Migration nicht aus der aktuellen Kundengruppe, dem aktuellen Kanal oder Product-Preis neu berechnet werden.
Customers, Kundengruppen, Adressen und Berechtigungen haben unterschiedliche Bedeutungen
Kundengruppen in osCommerce v4 können die Sichtbarkeit von Products und Categories, Steueranwendung, kumulative Rabatte sowie die Standardbehandlung von Gästen oder neu registrierten Käufern steuern. Customer-Datensätze sind außerdem mit Adressen, Orders, Kommunikationsdaten und möglicherweise Apps für Wholesale-, Kredit-, Loyalty-, Marketplace- oder B2B-Strukturen verbunden.
Ein Segment der Quelle sollte nach seiner Funktion interpretiert werden. Steuerbefreiung, Marketingsegment, Wholesale-Konto, Unternehmensbeziehung und Loyalty-Stufe sind nicht zwangsläufig dieselbe Kundengruppe. Manche gehören zu Kerngruppeneinstellungen, andere zu einer App, wieder andere zu einem externen CRM oder ERP.
| Kontokonzept in der Quelle | Möglicher Eigentümer in osCommerce | Zu erhaltende Beziehung |
|---|---|---|
| Einzelner Käufer | Customer-Konto und Adressbuch | Identität, Login, Adressen und Orders. |
| Gastkäufer | Customer-Momentaufnahme auf Order-Ebene | Historische Identität ohne künstlich erzeugtes dauerhaftes Konto. |
| Wholesale- oder Retail-Stufe | Kundengruppe und verbundene Katalog-/Preisregeln | Mitgliedschaft plus Sichtbarkeits-, Rabatt- und Steuereffekte. |
| Steuerbefreiung | Gruppeneinstellung oder dediziertes Customer-/App-Feld | Rechtliche/kommerzielle Bedeutung bleibt explizit. |
| Firmen- oder Handelskonto | Wholesale-/B2B-App oder externe Kontoentität | Mehrere Nutzer und Geschäftsregeln bleiben verbunden. |
| Administrator oder Mitarbeiter | Backend-Nutzer und Berechtigungen | Mitarbeiterzugriff bleibt von Customer-Segmentierung getrennt. |
| CRM-/ERP-ID | Externe Kennung | Stabiler Schlüssel zur Wiederverknüpfung. |
Die Gruppenbezeichnung allein reicht nicht aus, wenn unterschiedliche Preise, Products, Categories, Steuern oder Zahlungsbedingungen davon abhängen.
Orders bewahren Transaktionsmomentaufnahmen über mehrere verbundene Datensätze
osCommerce-Orders können Customer- oder Gastidentität, Rechnungs- und Lieferadressen, Product- und Attributmomentaufnahmen, Mengen, Preise, Rabatte, Steuern, Versand, Zahlungsinformationen, Auftragsstatus, Kommentare, Transaktionen, Sendungen, Erstattungen, Rückgaben, Rechnungen und Datensätze aus Erweiterungen enthalten. Die aktuelle v4-Administration kann außerdem manuelle Orders und die zugehörige Customer-Historie verwalten.
Bei der Order-Migration muss die historische Transaktion erhalten bleiben, statt sie aus aktueller Product- oder Customer-Konfiguration neu zu erzeugen. Ein Product kann inzwischen Name oder Preis geändert haben. Ein Customer kann die Gruppe gewechselt haben. Ein Zahlungsmodul kann ersetzt worden sein. Die Order bleibt nachvollziehbar, wenn ihre eigenen Positionen, Summen, Adressen, Status und Referenzen erklären, was zum damaligen Zeitpunkt geschehen ist.
| Order-Element | Historischer Eigentümer | Zu erhaltende Bedeutung |
|---|---|---|
| Product-Position | Order-Product-Momentaufnahme | Product-Name/SKU, Menge, gewählte Attribute und Preis zum Kaufzeitpunkt. |
| Rechnungs-/Lieferadresse | Order-Momentaufnahme | Historische Adresse unabhängig vom aktuellen Customer-Adressbuch. |
| Rabatt-/Steuer-/Versandbetrag | Order-Summe oder Anpassungsdatensatz | Bezeichnung, Betrag, Reihenfolge und Beitrag zur Endsumme. |
| Zahlungsreferenz | Transaktions- oder Zahlungsmodul-Datensatz | Historischer Abstimmungsnachweis. |
| Auftragsstatus und Kommentare | Order-Historie | Statusfolge, Datum, Sichtbarkeit und Erläuterung. |
| Sendung/Tracking | Versand- oder Fulfillment-Datensatz | Carrier, Methode, Tracking und versandte Positionen, sofern vorhanden. |
| Erstattung/Rückgabe | Zugehöriger After-Sales-Datensatz | Betrag, betroffene Positionen, Grund und Status. |
Ein Zielshop kann neue aktive Zahlungs- und Versandkonfiguration verwenden und zugleich die Bezeichnungen und Referenzen historischer Orders erhalten.
CMS, Front Ends, Themes, URLs und Kataloginhalte haben getrennte Eigentümer
Modernes osCommerce v4 bietet CMS-Steuerung, mehrere Front Ends, Themes, einen visuellen Theme-Designer, Product- und Category-Inhalte, SEO-Einstellungen, Bilder, Videos und sprachspezifische Werte. Legacy-Installationen können stattdessen Erweiterungen für Informationsseiten, statische PHP-Seiten, Template-Boxen, Sprachdateien oder SEO-Contributions verwenden.
Diese sichtbaren Elemente sollten in Inhalts-, Routen-, Kanal- und Präsentationsdomänen getrennt werden. Eine Product-Beschreibung gehört zum Product. Eine CMS Page hat eine eigene Identität und Route. Eine Category-Beschreibung gehört zur Category. Ein Menüeintrag oder eine Front-End-Platzierung steuert die Navigation. Theme und Template definieren die Darstellung. Ein Redirect verbindet eine alte Route mit einem neuen Ziel.
| Asset in der Quelle | Eigentümer im Ziel | Auswirkung auf das Datenmodell |
|---|---|---|
| Product-/Category-Beschreibung | Katalogentität | Inhalt bei der richtigen Entität und Sprache halten. |
| Informations- oder Richtlinienseite | CMS Page | Seitenidentität, Route, Hierarchie und Sichtbarkeit erhalten. |
| Front-End-spezifischer Inhalt | CMS-/Inhaltsdatensatz plus Kanalzuweisung | Inhalt und Kanalumfang verbunden halten. |
| Menü- oder Navigationsknoten | Navigationskonfiguration | Vorhandener Inhalt stellt seine Platzierung nicht automatisch wieder her. |
| Theme-Block oder Template-Box | Darstellungsebene | Layout getrennt vom zugrunde liegenden Inhalt neu aufbauen. |
| Product-Bild/-Video | Product-Medienbeziehung | Medienidentität, Reihenfolge, Sprache und Product-Verknüpfung erhalten. |
| Legacy-URL | Entitätsroute und Redirect | Quelle-zu-Ziel-Pfadbeziehung erhalten. |
Diese Trennung ist besonders wichtig beim Wechsel von einem alten 2.x-Shop, dessen Inhalte in Templates oder Erweiterungen eingebettet sind, zu den aktuellen v4-CMS- und Front-End-Strukturen.
Apps, Legacy-Erweiterungen, eigene Tabellen und externe Systeme erweitern osCommerce
Das aktuelle osCommerce v4 nutzt einen App Shop und unterstützt Apps für Zahlung, Versand, Marketing, Wholesale, Marketplaces, Accounting und weitere Funktionen. Legacy-Shops verwenden häufig manuell installierte Erweiterungen, die Kerndateien und Datenbanktabellen verändern. Beide Modelle können Datensätze besitzen, die außerhalb des nativen Katalog- und Order-Schemas liegen.
| Datenverantwortlicher | Beispieldatensätze | Übersetzungsentscheidung |
|---|---|---|
| osCommerce Core | Products, Categories, Marken, Attribute, Eigenschaften, Customers, Orders, CMS | Über native Datenbeziehungen abbilden. |
| v4-App | App-Felder, Entitäten, Transaktionen, Marketplace-Angebote, Wholesale-Regeln | Bei der App oder einem anderen expliziten Zieleigentümer erhalten. |
| Legacy-Erweiterung | Zusätzliche Spalten, Tabellen, Status, Gutscheine, SEO, Bestand, Berichte | Erweiterung und die von ihr veränderten Kerndatensätze identifizieren. |
| Individueller Code | Eigene Tabellen, Abläufe oder veränderte Berechnungen | Geschäftliche Bedeutung statt alter Codestruktur übertragen. |
| Externer Dienst | Steuern, Zahlung, Versand, Suche, Marketplace, Analytics | Historische Referenzen und aktive Verbindungsschlüssel erhalten. |
| ERP/PIM/WMS/CRM | Master-IDs für Product, Customer, Bestand, Lieferant und Order | Dauerhafte Kennungen und Systemhoheit erhalten. |
Ein Feld aus einer Legacy-Erweiterung wird nicht automatisch zu einem v4-App-Feld. Auch ein aktueller App-Name beweist nicht, dass alte Erweiterungsdaten dasselbe Schema oder dieselbe geschäftliche Bedeutung haben. Die Migrationsgrenze muss Datensatz für Datensatz definiert werden.
osCommerce-Übersetzungsentscheidungen nach geschäftlicher Bedeutung
| Muster in der Quelle | Richtige Übersetzungsfrage | Folge einer falschen Annahme |
|---|---|---|
| Legacy-Optionsmatrix | Handelt es sich um ein Core-Attribut, eine Beziehung eines konfigurierbaren Products oder eine bestandsführende Kombination einer Erweiterung? | Child-SKU, Bestand, Preis oder ausgewählte Werte gehen verloren. |
| Beschreibendes Product-Feld | Gehört es zu einer v4-Eigenschaft, Inhalt, Marke, Lieferant oder externem PIM? | Such- und Vergleichsstruktur werden inkonsistent. |
| Product in mehreren Stores dupliziert | Gibt es eine Product-Identität mit Kanalzuweisungen oder mehrere tatsächlich getrennte kommerzielle Identitäten? | Bestand und SEO werden unnötig aufgeteilt oder regionale Unterschiede überschrieben. |
| Kundengruppe | Welche Sichtbarkeits-, Rabatt-, Steuer- oder Preisbeziehungen hängen davon ab? | Die Segmentbezeichnung bleibt erhalten, ihre geschäftliche Wirkung jedoch nicht. |
| Order-Summe aus altem Modul | Welcher historische Betrag und welche Bezeichnung müssen an der Order erhalten bleiben? | Vergangene Summen lassen sich nicht mehr erklären. |
| Statische Legacy-Seite | Ist sie CMS-Inhalt, Template-Code, Route oder Erweiterungsdatensatz? | Inhalt kommt ohne korrekte Zuständigkeit oder Navigation an. |
| Externe ID | Welches System und welche Entität identifiziert der Schlüssel? | Abstimmung und Synchronisierung schlagen fehl. |
Eine osCommerce-Migration ist erfolgreich, wenn das Zielmodell die richtige Plattformgeneration widerspiegelt und Beziehungen über Katalog-, Kanal-, Customer-, Order-, Inhalts-, App- und externe Systemdomänen hinweg erhält.
Fazit
Die Übersetzung des osCommerce-Datenmodells beginnt mit der Trennung moderner v4-Strukturen von Legacy-Installationen. Das aktuelle v4 unterstützt Products mit Zuweisungen zu Vertriebskanälen und Kundengruppen, Attribute, Eigenschaften, konfigurierbare Katalogbeziehungen, CMS-Steuerung, mehrere Front Ends, Themes, Apps und erweiterte Preise. Ältere Shops können dagegen von deutlich anderen Tabellen, Erweiterungen und veränderten Dateien abhängen.
Der Zielshop sollte die Identität von Products und Categories, auswählbare Attribute, beschreibende Eigenschaften, Kanal- und Kundengruppenbeziehungen, historische Order-Momentaufnahmen, CMS- und Routenverantwortung sowie dauerhafte externe Kennungen erhalten. Ein Legacy-Erweiterungsdatensatz darf nicht allein deshalb als nativ gelten, weil das aktuelle v4 eine ähnlich benannte Funktion anbietet.
Häufige Fragen
Warum ist die osCommerce-Version der Quelle so wichtig?
Modernes v4 und Legacy-2.x-Shops verwenden deutlich unterschiedliche Architektur- und Erweiterungsmodelle. Dieselbe Bezeichnung kann auf andere Tabellen, Beziehungen oder Verhaltensweisen verweisen. Deshalb bestimmt die Versionslinie, wie ein Datensatz übersetzt werden muss.
Worin unterscheiden sich osCommerce-Attribute und -Eigenschaften?
Attribute können auswählbare Product-Werte darstellen und Preis, Gewicht, Bestand oder herunterladbare Dateien beeinflussen. Eigenschaften beschreiben strukturierte Merkmale für Darstellung, Filterung, Suche, Vergleich oder Product-Gruppierung.
Kann ein osCommerce-Product mehreren Front Ends oder Kundengruppen zugewiesen werden?
Das aktuelle v4 unterstützt Zuweisungen oder Einschränkungen von Products und Categories nach Front End, Vertriebskanal und Kundengruppe. Die Migration muss diese Beziehungen erhalten, statt Products unnötig zu duplizieren.
Sollte jede Legacy-Product-Option zu einer modernen Beziehung eines konfigurierbaren Products werden?
Nein. Manche Optionen verändern nur den Preis oder erfassen eine Käuferangabe, andere identifizieren eigenständig bestandsgeführte Kombinationen. Das richtige Ziel hängt von SKU, Bestand, Preis, Medien und dem Verhalten der Order-Position ab.
Wie sollten historische Orders behandelt werden, wenn Zahlungs- oder Versandmodule wechseln?
Erhalten Sie Product-Positionen, Adressen, Summen, Methodenbezeichnungen, Transaktionsreferenzen, Status, Sendungen und After-Sales-Datensätze aus dem Zeitpunkt der Order. Die aktive Zielkonfiguration kann sich ändern, ohne die historische Transaktion umzuschreiben.
Was sollte mit Daten aus alten osCommerce-Erweiterungen oder aktuellen v4-Apps geschehen?
Identifizieren Sie die Erweiterung oder App, die von ihr erweiterte Kerndateneinheit und jedes externe System, von dem sie abhängt. Aktive Datensätze benötigen einen expliziten Zieleigentümer; veraltete technische Daten können archiviert oder ausgeschlossen werden, statt sie in native Felder zu zwingen.