Das Thema Migration beschäftigt mich nun schon seit Wochen. Viele Probleme, welche man vor einer Migration nicht auf dem Schirm hat. Heute mal ein weiteres Problem mit fatalen Folgen - Eigene Berechnung bei Versandarten.
Bei einem Kunden-Shop gibt es Speditions-Versandarten mit eigene Berechnung. Die eigene Berechnung basieren auf der Grundlage, dass im SW5 Shop mittels Freitextfelder eigenen Versandkosten angelegt wurden. Eine durchaus übliche Vorgehensweise im SW5. Und so wurden eigene Berechnung z.B. mit „MAX(at.attr10)“ angelegt.
Leider ist es aber so, dass der Shopware Migrations-Assistent diese Art und Weise gar nicht unterstützt (zumindest die Version: 4.2.5). Das hat nun zufolge, dass die komplette Versandart bei der Migration gar nicht übernommen wird.
Im Beispiel sieht das so aus:
[warning] SWAG_MIGRATION__SHOPWARE_UNSUPPORTED_SHIPPING_CALCULATION_TYPE
Unsupported shipping calculation type
ShippingMethod-Entity with source id "30" could not be converted because of unsupported calculation type "3".
Weil es nun die Versandarten nicht übernimmt, fehlen die Information auch mit im Mapping der Migration - siehe Tabelle „swag_migration_mapping“. Und weil diese Info hier nicht steht, werden zudem alle Bestellungen mit diesen Versandarten nicht übernommen.
Im Beispiel sieht das so aus:
[warning] SWAG_MIGRATION_SHIPPING_METHOD_ENTITY_UNKNOWN
Cannot find shipping_method
The order entity with the source id "62186" cannot find the depended shipping_method entity with the source id "30".
Fazit:
Eine weitere Stolperfalle bei einer Migration.
Lösung?
Zur Stunde leider keine. Ich überlege allerdings den Shopware Migrations-Assistent auf meine Bedürfnisse anzupassen.
Ich kämpfe aktuell mit dem gleichen Problem. Habe aber bisher auch noch keine Idee wie man das Problem lösen oder zumindest umgehen könnte.
Wobei die Bestellungen bei uns scheinbar migriert wurden, trotz der fehlenden Versandart.
In der Bestellung ist dann in SW6 natürlich keine Versandart hinterlegt / verknüpft.
Problematischer ist es bei Zahlungsarten die nicht mehr existieren.
Hier wurden die Bestellungen NICHT migriert.
So sollten die Versandarten als „Berechnung nach Gewicht“ zu SW6 migriert werden.
Und nachdem die Versandart an sich migriert werden kann, wird auch die Bestellung wieder korrekt mit dieser verknüpft.
Die Berechnung muss dann sowieso über Rule-Builder etc. neu gebaut werden.
Die oben genannte Anpassung (und einige weitere kleine) hat in meinem Fall den Migrationsprozess von ~48h (nur für customersOrders) auf gute 3,5h verkürzt.
Ja da muss natürlich jeder sehen, was die beste Lösung in seinem Falle ist. Bei mir würde das so nicht gehen. Aber egal, auch ich habe eine Lösung gefunden.
Hey,
Der Thread ist ja schon was länger her, aber das selbe Problem habe ich gerade auch. Wie kann man das denn nun umgehen, ohne das Produktivsystem zu verändern?
Und @iLuHa wo passt man den ShippingMethodConverter an?
Danke euch!
Hallo Zusammen. @R4M könntest du uns bitte auch mitteilen, was die Lösung war, die du gefunden hast? Ich bin in Version 6.6.9.0 auf das gleiche Problem gestoßen. Und ich möchte vermeiden, Änderungen wie von @iLuHa gezeigt vorzunehmen.
Das Thema ist ja schon wieder so lange her Nun ja, gefunden natürlich über die Fehlermeldung und angezeigte „source id“ - also so wie im ersten Beitrag gezeigte Fehlermeldungen.
Knackpunkt bei der Migration ist, das Versandarten mit eigenen Berechnung NICHT übernommen werden. Das Problem dadurch, dass auch die dazugehörigen Bestellungen NICHT übernommen werden. Es folgt pratisch eine Kettenreaktion. Von daher ist die Lösung von @iLuHa eine Notlösung damit die Bestellungen nicht verloren gehen. Die Versandarten muss man dann anderes gestalten oder auf zusätzliche Plugins setzen.
Also meine Migrations-Erfahrung vor knapp einem Jahr war:
Übernahme der Versandarten klappt nicht. Die muss man sowieso in SW6 neu erstellen.
Dann noch: Bei der zweiten („Nach-“)-„Migration“ der zwischenzeitlich dazugekommenen Kunden und Bestellungen wurden die bereits in SW6 konfigurierten Versandarten wieder „zerstört“.
Für uns war die Lösung:
Vor Beginn der Migration in SW5 alle Versandarten komplett löschen!
So waren jedenfalls alle Kunden und Bestellungen da und die konfigurierten Versandarten in SW6 bleiben erhalten.
Ist aber wie gesagt ca. 1 Jahr her. Ob das Migrationstool inzwischen verbessert wurde, weiß ich natürlich nicht.
Damit wäre ich sehr sehr vorsichtig. Im schlimmsten Fall können Bestellungen nicht migriert werden, weil Versandarten fehlen. Fehlen Bestellungen können Kunden nicht migriert werden. Hier sollte man NICHT voreilig sein und eine wilde Lösch-Orgie starten.
Die Migration von SW5 zu SW6 muss immer von Fall zu Fall analysiert werden. Gibt es Fehler sollte schauen wie man sie behebt, damit Datensätze nicht verloren gehen. Da gibt es leider auch keine pauschalen Antworten, zu komplex sind manche Shops. Viele Dinge müssen individuell betrachtet werden.
Der Migrations-Assistent wurde zwar geupdatet, kann aber noch wie vor keine Versandarten erfassen, wo es eigene Berechnungen gibt, da es diese Funktionalität in SW6 gar nicht gibt.
Das hast Du jetzt aber etwas falsch verstanden. Ich würde nicht mal eine Erweiterung aktualisieren, ohne das vorher in einer Staging-Umgebung zu testen und eine aktuelle Datensicherung parat zu haben.
Fakt ist allerdings, dass das unser Problem gelöst hat.
Wenn das jemand probieren will, dann testen mit
-Staging-Umgebung SW5
-Staging-Umgebung SW6
Alles in Ruhe ausprobieren und selbst wenn das dann funktioniert.
Niemals am Live-System machen, ohne auf ein aktuelles Backup wieder zurück zu können.
Nun ja, gefunden natürlich über die Fehlermeldung und angezeigte „source id“ - also so wie im ersten Beitrag gezeigte Fehlermeldungen.