Eigene Berechnung bei Versandarten führt zu Migrationsprobleme

Shopware 6 (German)
, ,
1

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.

1 „Gefällt mir“
2

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. :confused:

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.

3

Ich habe bei uns nun den ShippingMethodConverter angepasst, indem ich einfach das Mapping um Type 3 ergänzt habe.

protected const CALCULATION_TYPE_MAPPING = [
    0 => 3, // Weight
    1 => 2, // Price
    2 => 1, // Quantity
    3 => 3, // Weight -- Custom mapping of own calculation
];

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.

4

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.

5

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!