Neu Fehlerhafte Adress-Übernahme durch NinePoint (Mirakl → JTL) – wer ist noch betroffen?

[DaniMarket]

Seit Mitte/Ende September 2025 wird bei uns der Adresszusatz (z. B. c/o-Angaben) durch NinePoint beim Import aus Mirakl/ Shop-Apotheke falsch in JTL gemappt.

Statt im Feld Adresszusatz landet er im Feld Straße & Hausnummer.

Das führt zu unzustellbaren Sendungen, Rückläufern und Kundenbeschwerden.

---

Was passiert genau?​

• Der Marktplatz liefert korrekte Daten, z. B.:
  Straße: Musterstraße 14
  Adresszusatz: c/o Beispielname
• NinePoint hängt den Adresszusatz an das Straßenfeld an, z. B. „Musterstraße 14 c/o Beispielname“.
• Bei längeren Zusätzen „rutscht“ der Rest in die nächste Zeile oder wird abgeschnitten (z. B. „14c“ statt „14 + Zusatz“).

---

Erwartetes Verhalten​

• Straße & Hausnummer bleiben unverändert: „Musterstraße 14“
• Adresszusatz wird korrekt befüllt: „c/o Beispielname“

---

Ist-Zustand (Fehlerbild)​

• Adresszusatz wird dem Straßenfeld angehängt: „Musterstraße 14 c/o Beispielname“
• Hausnummern werden verfälscht oder abgeschnitten.
• DHL kann Adressen nicht zuordnen → Rückläufer, Mehrkosten, Kundenbeschwerden.

---

Kontext & Timeline​

• Seit: 11.–16. September 2025 erste Eskalation an NinePoint (Thema „additional_info“ / „Weitere Versandinformationen“ aus Mirakl).
• Zwischenstand: Das ursprüngliche Problem mit Packstation-Adressen wurde teilweise gelöst – es wurde ein zusätzliches Feld implementiert, sodass diese Daten zumindest ankommen (wenn auch oft manuell nachzuformatieren).
• Stand heute (26. Oktober 2025): Das Problem mit c/o-Zusätzen besteht unverändert weiter.

---

So lässt sich der Fehler reproduzieren​

1. Bestellung über Mirakl-basierten Marktplatz (z. B. Shop-Apotheke) mit Adresszusatz (c/o) auslösen.
2. Import der Bestellung nach JTL via NinePoint.
3. In JTL Lieferadresse prüfen: Adresszusatz leer oder unvollständig, Straße & Hausnummer enthält den Zusatz.

---

Technische Einschätzung​

• Mirakl-Felder wie address_additional oder additional_info werden von NinePoint nicht in
  Auftrag.Lieferadresse.Adresszusatz gemappt, sondern an Straße angehängt.
• Workflows in JTL helfen hier nicht – die Daten kommen bereits falsch importiert ins System.

---

Auswirkungen​

• Operativ: manuelle Korrektur jeder betroffenen Bestellung, zusätzlicher Zeitaufwand im Versand.
• Finanziell: Rücksende- und Wiederzustellkosten, Verlust durch Stornos.
• Kundenseitig: verzögerte Lieferungen, Beschwerden, negative Bewertungen.

---

Fragen an die Community​

• Hat jemand das identische Verhalten mit NinePoint (Mirakl → JTL)?
• Gibt es stabile Mappings oder Workarounds, die den Adresszusatz korrekt übernehmen?
• Falls gelöst: Welche NinePoint-Version oder Konfiguration nutzt ihr?

---

Bitte an NinePoint​

• Korrigiertes Mapping von Mirakl-Feldern (address_additional, additional_info, c/o-Angaben) auf
  JTL.Lieferadresse.Adresszusatz, ohne Anhang an Straße/Hausnummer.
• Klare Info, ab welcher Version das dauerhaft behoben ist.

---

TL;DR:

• NinePoint mischt bei uns den Adresszusatz in das Straßenfeld (Mirakl → JTL).
• Ergebnis: unzustellbare Sendungen, Rückläufer, Frust.
• Das Packstation-Thema wurde inzwischen teilweise gelöst – die fehlerhafte Verarbeitung von Adresszusatzfeldern besteht aber weiterhin.

Wer hat das noch, und gibt es schon eine saubere Lösung?

 

[bbfdesign]

Moin
Da wird NinePoint vermutlich der erste Ansprechpartner sein. Hast Du Chat GPT mal nach einer Lösung gefragt?

Wenn NinePoint da bereits dran ist - wenn man das aus der Antwort von ChatGPT das richtig interpretiert - was ist denn hier die aktuelle Rückmeldung.

Do könntest mit Hilfe eines Workflows sicherlich auch einen Workaround schaffen, der dann die Aufträge korrigiert, bis es eine Lösung von NinePoint gibt.

Sollte NinePoint dir nicht helfen können, dann wäre ein Wechsel der Schnittstelle denkbar: https://www.zahlengrafik.de/jtl-connector/mirakl/

Gruß Björn

 

[DaniMarket]

Moin
Da wird NinePoint vermutlich der erste Ansprechpartner sein. Hast Du Chat GPT mal nach einer Lösung gefragt?

Wenn NinePoint da bereits dran ist - wenn man das aus der Antwort von ChatGPT das richtig interpretiert - was ist denn hier die aktuelle Rückmeldung.

Do könntest mit Hilfe eines Workflows sicherlich auch einen Workaround schaffen, der dann die Aufträge korrigiert, bis es eine Lösung von NinePoint gibt.

Sollte NinePoint dir nicht helfen können, dann wäre ein Wechsel der Schnittstelle denkbar: https://www.zahlengrafik.de/jtl-connector/mirakl/

Gruß Björn

Moin Björn 🦊,

ja, danke, auf die Idee, NinePoint zu fragen, wäre ich natürlich nie gekommen. 😉
Die sind seit Wochen/Monaten damit beschäftigt, es offiziell „in Prüfung“ zu nehmen, praktisch passiert aber nichts.

 

[mvh]

Moin. Du schreibst, mit einem JTL Workflow nicht lösbar. Ich behaupte - es geht. Mein Vorschlag: beim Auftrag-Erstellen Ereignis einen Workflow ausführen, der alles nach der Hausnummer in das Feld Adresszusatz verschiebt. Wir nutzen diese Technik, um die Adressen zu überprüfen und ggf. zu korrigieren. Die Prüfung erfolgt mit RegEx und die Korrekturen mit CustomWorkflow. Viele Grüße, Ihr MVH Team.