Hallo lieber ​@tuge ; habt ihr inzwischen eine Lösung für die “abweichende Lieferadresse”, die keine ist? Wir finden es auch sehr ungünstig, dass hier die identische Adresse 2x abgebildet wird.
Vielen Dank vorab

Jenny

Leider sind die da noch nicht weiter. Wir haben das letztes Jahr auch schon mit Tickets bei Xentral platziert. Auf Nachfrage gestern waren die “Themen” auf einmal neu für Xentral und man wollte, dass wir Ihnen nochmals “erklären” warum diese Punkte denn für uns wichtig seien … hier dann mal unser Feedback von heute an Xentral: 

 

1. Mehrsprachigkeit / Artikelübersetzungen

Unter der bisherigen Schnittstelle funktioniert die Übertragung von z. B. englischen Artikeltexten problemlos – warum ist das in der neuen Connect-Schnittstelle nicht möglich?

Für uns ist Xentral die zentrale Datenquelle, und wir pflegen dort alle Sprachen – nicht nur Deutsch. Demnächst auch niederländisch. Eine Umstellung auf die neue Schnittstelle ist für uns nur denkbar, wenn diese Funktionalität sichergestellt ist.

Ein Workaround über bspw. Freifelder kommt für uns nicht in Frage, da diese nicht über den WYSIWYG-Editor gepflegt werden können und uns darüber hinaus  erheblicher mehr Aufwand entsteht, denn die Daten sind ja alle gepflegt.

Daher unsere konkrete Frage: Wann wird die Mehrsprachigkeit (inkl. Übertragung der englischen oder anderer fremdsprachiger Inhalte) in der neuen Schnittstelle wieder unterstützt, wie es in der aktuellen Schnittstelle bereits der Fall ist?

2. Lieferadresse = Rechnungsadresse → trotzdem „abweichende Lieferadresse“

Auch hier verhält sich die aktuelle Schnittstelle anders – dort wird eine abweichende Lieferadresse nur dann an Xentral übergeben, wenn diese tatsächlich vom Rechnungsempfänger abweicht. Das ist logisch und korrekt so.

In der neuen Schnittstelle wird offenbar immer eine abweichende Lieferadresse übermittelt, auch wenn diese mit der Rechnungsadresse identisch ist. Auf dem Beleg erscheint dadurch immer ein separater Lieferadressblock – was aus Kundensicht verwirrend und inhaltlich falsch ist.

Daher unsere Rückfrage: Warum wird hier auf eine bereits vorhandene Logik verzichtet und wann wird dieses Verhalten wieder angepasst?

2. USt-ID wird nicht in den Kundenstammdaten gespeichert

Auch dieses Verhalten war bisher anders: Wenn ein B2B-Kunde aus dem EU-Ausland im Shop eine USt-ID angibt und netto ohne MwSt. bestellt, wird diese bei der Neuanlage in Xentral in die Kundenstammdaten übernommen – genau wie Straße, PLZ etc.

Eure Argumentation, dass die USt-ID ja im Auftrag gespeichert wird, hilft uns im Alltag leider nicht weiter. Wenn der Kunde beim nächsten Mal nicht im Onlineshop bestellt, sondern z. B. ein Angebot per E-Mail anfragt und wir die Stammdaten in Xentral nutzen, fehlt die USt-ID.

Wir müssen dann entweder alte Aufträge durchsuchen oder die Nummer erneut beim Kunden anfragen – beides ist aus unserer Sicht unnötige doppelte Arbeit.

Daher unsere konkrete Frage: Warum wird die USt-ID nicht gemeinsam mit den anderen Stammdaten übertragen und gespeichert, obwohl sie aus Shopware übermittelt wird?

Wichtiger Hinweis:

Alle genannten Punkte wurden bereits im Rahmen unserer damaligen Testphase vor ca. 4 Monaten über eure Ticketsysteme kommuniziert.

Daher wundert es uns sehr, dass diese Themen nun erneut wie „neue“ Anforderungen behandelt werden.
 

Wir bitten euch daher ausdrücklich, unsere genannten Punkte verbindlich in eure interne ToDo-/Anforderungsübersicht zur Weiterentwicklung des Connectors zu übernehmen.

Nur so ist sichergestellt, dass bereits gemeldete und dokumentierte Themen nicht erneut verloren gehen oder ignoriert werden.

Vielen Dank für eure Rückmeldung und euer Verständnis. Sobald wir eine klare Perspektive zur Umsetzung dieser Punkte haben, sind wir gern bereit, die Umstellung erneut zu prüfen.

Die Punkte 1 und 3 sind für uns auch extrem wichtig - vor allem ohne eine funktionierende Übertragung mehrerer Sprachen können wir gar nicht erst auf die neue Schnittstelle umsteigen.

Vielen Dank für die Rückmeldungen hier!
Alle per Ticket besprochenen Themen gehen hierbei nicht verloren, sondern werden von unserem Team weiter bearbeitet und an die entscheidenden Stellen weitergeleitet. Es ist nachvollziehbar, wenn man eine bestimmte Funktion benötigt, dies zu Frustration führt.
Für viele Bereiche, die im Standard nicht in Connect verfügbar sind, gibt es die Option eines Customizings, um diese umzusetzen. Hierfür ist der Kontakt zu euren CSMs wichtig, um hierfür in den Austausch zu treten.

Ferner möchte ich euch darüber informieren, dass wir für SW6 nun auch den initialien Datenimport hinzugefügt haben.

Hallo Dennis, 

“...

Zeitplanung

Bitte beachte, dass wir die bisher von euch genutzte “alte” Shopware 6 Schnittstelle zum 15.02.2025 in den Status "Deprecated" überführen werden. Das bedeutet für euch: Ab diesem Datum leisten wir für dieses Modul nur noch eingeschränkten Support in dringenden Fällen.

Das endgültige “End-of-life” der bisherigen Shopware 6 Schnittstelle wird voraussichtlich zum 15.05.2025 erreicht werden. Ab diesem Datum werden wir keinen Support mehr für die bisherige Lösung leisten. 

...”

Diese Zeitinfo ist aus deinem Eingangsposting. Ist dieses dort angegebene Zeitfenster zur “alten”  Schnittstelle noch Stand der Dinge? 

Es ist zwar gut, dass es die Möglichkeit des Customizing gibt. Doch bevor wir Geld für Customizing zahlen, würden wir schon zunächst wissen wollen, ob bspw. die von mir beschriebenen drei Funktionen (die in der alten Schnittstelle Standard sind und funktionieren) auch noch in der neuen Schnittstelle vor dem 15.05. oder in Absehbarer Zeit  zum Standard werden oder nicht mehr Standard werden.
 

Meines Standes nach ist das noch aktuell. Ich werde zu deinen Punkten nochmal direkt bei unserem Connect-Team nachfragen und dir Rückmeldung geben!

Was du hier in einem Nebensatz beschreibst, ist für uns der Gamechanger und wird uns Wochen an Arbeit einsparen. Das wird sofort getestet!

Der Initiale Datenimport ist mit sehr viel Vorsicht zu genießen, wie wir jetzt erfahren mussten. Wir haben den SW6-Shop eines neuen Fulfillment-Kunden über den Connector angebunden und den Initialen Datenimport durchgeführt. Das hat dazu geführt, dass ganz andere Artikel plötzlich überschrieben bzw. zurückgesetzt wurden - obwohl es keinerlei Dopplungen von SKUs oder EANs gibt (das haben wir vorher natürlich kontrolliert). Zum Teil wurden durch den Datenimport aus Lagerartikeln plötzlich Nicht-Lagerartikel, Artikel gesperrt und hinterlegte Gewichte wurden gelöscht. Und das wohlgemerkt bei Artikeln, die über ganze andere Connectoren (Shopify und WooCommerce) schon vor Monaten importiert worden waren. Der Support hat uns im Ticket auch bereits bestätigt, dass da ein Problem vorliegt und anscheinend der Datenimport nicht getrennt durchgeführt wird, sondern über alle Connectoren. Und es werden anscheinend nicht bloß die Artikel geändert, die vorher identifiziert wurden, sondern auch einfach weitere. Ziemlich unfassbar! Wer soll damit rechnen?!

Wir haben das zum Glück bemerkt, bevor wirklich Schlimmes dadurch passiert ist. Das hätte dazu führen können, dass wir Pakete unserer Kunden gar nicht versenden oder unvollständig versenden, da Artikel plötzlich gesperrt waren oder keine Lagerartikel mehr waren. Was auf jeden Fall passiert ist, ist, dass wir Pakete mit falschem Gewicht versendet haben. Das ist aber zum Glück nur bei wenigen Paketen der Fall gewesen.

Insgesamt sehr ärgerlich, wenn sowas passiert. Solange dieses Problem nicht gelöst ist, würde ich empfehlen, den Datenimport per CSV durchzuführen.

Hallo,

kurze Frage an die Experten zum aktuellen Stand bei der Connect Schnittstelle und Shopware. Sind diese Punkte in zwischen mit Connect gelöst, die ich weiter oben beschreiben habe? Dann würden wir das jetzt noch mal angehen und testen:

1. Mehrsprachigkeit / Artikelübersetzungen

2. Lieferadresse = Rechnungsadresse → trotzdem „abweichende Lieferadresse“

3. USt-ID wird nicht in den Kundenstammdaten gespeichert

Wir sind bisher weiterhin noch bei 6.5 mit der alten Schnittstelle verbunden, weil die funktioniert.

Aber leider müssen wir eigentlich aus Shopware-Sicht bis Ende Juni spätestens auf 6.6 gehen, damit wir die Voraussetzungen für das „BFSG – Barrierefreiheitsstärkungsgesetz“ erfüllen können. Das geht nicht mehr  unter 6.5 …

Hallo ​@ibims 

ich kopiere zur Mehrsprachigkeit und Sprachmapping einmal eine Antwort von mir aus einem anderen Thread:
 

• Sprachmapping: Das Sprachmapping an sich sollte funktionieren, zumindest übertragen wir die Sprache am Auftrag, wenn wir ihn zu Xentral importieren. Was aktuell noch Probleme macht, ist, wenn der Kunde die Artikelbezeichnung und die Artikelbeschreibung aus Xentral nutzen kann. Dies kann man ja aktuell als Konfiguration in der SCMA anhaken. Dabei werden aktuell noch die Standard Texte aus dem Artikel verwendet und Übersetzungen nicht beachtet. Wir sind gerade dran, eine Lösung im Standard zu finden. Ein Kunde hat auch bereits ein Customizing bekommen, was als Übergangslösung dazu dient. Bei Mehrsprachigkeit kommt es aktuell bei manchen Sprachen zu einem zusätzlichen Fehler. Die Vermutung liegt nahe, dass in diesem Fall das Alias für das Land nicht vorhanden ist. 
• Lieferadresse: Aktuell wird die Lieferadresse beim Import immer gefüllt, unabhängig davon, ob die Adresse abweicht oder nicht. Die neue API kann Liefer- und Rechnungsadresse nicht abgleichen, weshalb das beschriebene Verhalten auftritt. Hierbei wird jede Lieferadresse importiert, die der Shop bereitstellt. Dies ist ein bereits bekanntes Thema, dem wir unter IMPCONNECT-194 bearbeiten.
• USt-ID-Import: Auch beim Import der USt-ID über die API kommt es derzeit noch zu Problemen. Dies ist Teil eines größeren Tickets, an dem unser Team aktuell arbeitet (IMPAPI-305)
   

Ich habe gesehen, dass du dazu auch vorhin ein Ticket beim Support eröffnet hast. Diese werden deine Anfrage mit den entsprechenden Tickets verknüpfen, sodass du hier direkt eine Antwort erhalten solltest, wenn die jeweiligen Themen behoben sind.

Ich bin mir dessen bewusst, dass der aktuelle Stand keine befriedigende Antwort darstellt, dennoch halte ich es für notwendig, dir auf deine Frage eine Antwort zu geben, die so transparent ist wie möglich. Ferner möchte ich natürlich auch nicht, dass du eine Shopumstellung durchführst, die dir aktuell zusätzliche Probleme bereiten könnte.

Beste Grüße

Hi Dennis, 

danke für die Antwort 

zu 1.) 1. Mehrsprachigkeit / Artikelübersetzungen

Ich meinte nicht das Sprachmapping, wenn wir Aufträge in anderen Sprachen von Shopware zu Xentral importieren. So weit waren wir offen gesagt mit dem testen noch nicht. Keine Ahnung ob das funktioniert. 

Es geht erst mal darum, dass wir unsere ganzen Artikeldaten, die wir in Xentral mehrsprachig pflegen (inkl. Formatierung, Links, META Daten  usw.) auch dort belassen und nur dort pflegen und von dort zu Shopware exportieren. 

Ist dies inzwischen mit der Connectschnittstelle möglich?

 

Tut mir leid, dass ich das falsch verstanden habe!
Hierbei scheint es auch noch zu Problemen durch die Übertragung bei der API zu kommen. Die unterschiedlichen Sprachen scheinen bei Connect daher aktuell per Freifeld gehandhabt werden zu müssen. Weitere Infos liegen mir hierzu leider aktuell nicht vor.

Beste Grüße