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!