gemischt und alle in einer Kundegruppe…
Selbst durchgeführt habe ich in mehreren Projekten diese beiden Umstellungsbefehle:
ALLE Konten von privat auf business
UPDATE account_type SET business
Konten MIT BESTIMMTER KUNDENGRUPPE von privat auf business
UPDATE customer
SET account_type = ‚business‘
WHERE customer_group_id = UNHEX(‚ID_DER_GRUPPE‘)
Könnte mir in Deinem Fall in etwa die 2. Variante vorstellen, mit Abfrage, ob eine VAT-ID hinterlegt ist:
UPDATE customer
SET account_type = ‚business‘
WHERE vat_ids IS NOT NULL
… keine Ahnung, ob es so funktioniert, noch nicht getestet, nur eine Idee.
Das könnte gut klappen aber es fehlt dann doch noch der Befehl, der den Firmenname aus den Adressen mit in das von Privat in Gewerblich geänderte Profil kopiert, denn das könnte leer bleiben:
Die Einstellungen im persönlichen Profil werden ja nicht „doppelt“ abgefragt, sondern geben dem Kunden die Möglichkeit, zB als Privatkunde zu bestellen und an eine Firmenanschrift liefern zu lassen.
Der Kunde könnte doch in den Adresse von mir aus eine abweichende Lieferadresse an eine Firma angeben… Wieso sollte er dann dort nochmal wählen ob Privat oder Gewerblich? Was hat das mit einer Lieferadresse an eine Firma zu tun?
Fakt ist doch, dass der Kunde einmal in den Profileinstellungen den Kontotyp wählen kann und genau das selbe nochmal in der Adresse.
Ich habe das so gelöst:
Innerhalb seines Profils ist der Kunde ja nicht „gezwungen“, nochmal irgendwelche Daten zu ändern oder anzugeben… nur die Möglichkeit, dass er kann wenn er will!
dann nochmal hier:
Für mich verwirrt das unheimlich.
In Shopware 5 gab es einmal die Möglichkeit das Profil als Privat oder gewerblich zu markieren und damit war alles übersichtlicher und einfacher. Weshalb man das jetzt in SW6 so verkompliziert bleibt mir rätselhaft.
Ja gut wie dem auch sei… Vielleicht bin ich dieser Logik einfach nicht gewachsen:
Einfach mal so stehen lassen 
Innerhalb des normalen Bestellvorgangs wird das ja gar nicht alles immer nochmal abgefragt.
Privatkunde bestellt und will an Firmenadresse liefern lassen, dass wird über „Adresse Gewerblich“ das Zusatzfeld für den Firmennamen mit freigegeben. Im „Profil“ nehmen aber die wenigsten Kunden direkt irgendwelche Änderungen vor… Daten werden während des Bestellvorgangs im Checkout geprüft und notfalls angepasst.
1 „Gefällt mir“
Wir hatten das gleiche Problem, ich hab das mit einem SQL gelöst und einfach von der Kundenadresse die Firma in den Kundendatensatz übernommen.
update customer
inner join customer_address on customer.id = customer_address.customer_id
set customer.company = customer_address.company
where customer_address.company is not null and customer.company is null
Möchte hier für alle, die nicht so SQL-firm sind, die Lösung per Import/Export nochmals zusammengefasst darstellen:
- Profil Kunden duplizieren
- Die Spalten „customer.account_type“, „vatids“ und „company“ der Kopie hinzufügen (verwendet für die CSV-Spaltenbenennung zumindest den Datenbankspalten ähnliche Bezeichnungen) und speichern.
- Kaffee holen.
- Die Exportdatei in Libre/Open-Office öffnen (für Anfänger: ja nicht direkt in Excel! Niemals!).
- Nach der UST-ID sortieren und den Rest (nach unten) löschen.
- Optional - falls notwendig - Kunden aus bestimmten Ländern entfernen.
- Die Spalte billing.company umbenennen in company.
- Alle accountType umbenennen von „privat“ zu „business“.
- Die gesamte Tabelle bereinigen um nicht benötigte Spalten - für den Import benötigt werden nur die Spalte ID, company (die neue mit den Firmennamen) und accountType.
- Zeit für einen weiteren Kaffee mit Schuss (Baldrian) - mit SW6 wird das schließlich nicht das letzte Problem des Tages gewesen sein …
Hoffe, ich konnte hiermit anderen viel unnötiges Herumprobieren ersparen.
PS: Dafür, dass das bei der Migration nur auf einem Mapping-Problem und einer simplen Wenn-Dann-Entscheidung zu beruhen scheint: Shopware! Setzen! 6!
Möchte nicht wissen, wie viele Shopbetreiber von diesem Problem gar nichts wissen. Und wenn der Shop dann womöglich auch noch mit gleichbleibendem Netto arbeitet, dann sieht der EU-Netto-Kunde zwar einen gewohnt krummen, aber eben um etwa 20% höheren Preis - und spätestens jetzt braucht wohl der Kunde erst einmal einen Kaffee mit Schuss 
.
1 „Gefällt mir“
@10taur Perfekt, sehr gut zusammengefasst. So auch meine inzwischen routinemässige Vorgehensweise ohne SQL-Befehle. „Möchte nicht wissen, wie viele Shopbetreiber von diesem Problem gar nichts wissen.“ Dazu sage ich nur, dass das Problem über einen Zeitraum von mehr als 1 Jahr gar niemandem aufgefallen ist und das scheinbar jeder als „normal in SW6“ hingenommen hat.