Moin liebe Gambio-Experten. Ich habe eine Frage. Es kommt relativ häufig vor, dass meine Kunden vergessen die Hausnummer in der Versandadresse einzugeben - da das Eingabefeld Straße/Hausnummer in einem Feld erwartet. Kann man das als extra Feld machen, so dass man Straße und Hausnummer getrennt voneinander eingeben kann? Danke euch für eure Hilfe, liebe Grüße, Petra
Genau die gleiche hatte ich schon mal gestellt. Das ist nur mit einigen tiefgreifenderen Änderungen möglich. Ich hab dem ganzen damals keine so hohe Priorität eingeräumt. Das wäre vielleicht mal ein Vorschlag für künftige Updates da ich denke dass bestimmt mehr Gambionutzer von diesem Thema ein Lied singen können.
Ich bin auch dafür, dass so eine Änderung sollte von der Seite der Gambio generell gemacht werden. Sonst bei jedem Update muss man per Hand an viele Stellen schrauben.
Ich habe Euch für fast die gleiche Frage vor fünf Tagen eine Lösung gepostet: http://www.gambio-forum.de/threads/...ngabe-machen-!?p=125533&viewfull=1#post125533
Hallo Christian, danke dir. Ist das dann auch updatesicher oder muss ich das jedesmal neu anpassen? Danke und Grüße, Petra
Das is ja das Problem! So eine Änderung muss bei jedem Update angepasst werden. Außerdem noch ein Problem gibt es bei den Kunden die keine Hausnummer haben. PS: Wer weiß wie viele Kunden aufgeben und nicht anrufen?
Das so abzufangen, dass es für alle zu 100% passt ist aber m.E. auch nicht möglich: Mit einer Abfrage auf Nummern in dem bestehenden Feld oder einem Extra-Pflichtfeld für die Hausnummer verliert man die Kunden ohne Hausnummer, da wird ein Großteil in vielen Branchen nicht anrufen => Ohne den Zwang nimmt es sich nicht viel, ob die Kunden die Hausnummer in das gleiche Feld oder ein separates eintragen sollen. Wers vergisst, vergissts. Es wird in allen Varianten Kunden geben, die es nicht schaffen ihre Adresse richtig einzugeben.
Hallo Stefan, insgesamt ist es schwierig zu sagen was zu welchen Kundenvarianten passt oder nicht passt. Ich habe persönlich gar keine Probleme damit ob es zwei oder nur einen Feld für die Straße/Hausnr. gibt. Und bin ich in selber Meinung wie du: Ich sehe es bei unserem Webshop, wir führen ein Webshop in dem grundsätzlich zwei Artikel-Kategorien gibt. 1: Artikel die nur zum Abholen geeignet sind. (FRISCHE Waren) 2: Versandartikel. Und obwohl alles ganz genau bezeichnet ist trotzdem vermischen manche Kunden die beide Kategorien. Inzwischen um diese Probleme zu vermeiden haben wir unsere Kategorien für Selbstabholer und Versandkunden komplett von einander getrennt. Selbstabholer Kunden müssen sich bei uns erst anmelden damit sie Zugangsdaten passend zu ihrer Kundengruppe bekommen. Alle andere Kunden ohne von uns ausgestellte Zugangsdaten werden als Versandkunden behandelt und dürfen nur die Artikel sehen die zum Versand freigegeben sind. Genau diese Ansicht habe ich versucht mit meine Aüßerung zu erwecken. Es ist nicht Updatesicher und gibt NICHT NUR DIE KUNDEN, DIE ES VERGESSEN IHRE HAUSNUMMER EINZUGEBEN, SONDERN AUCH DIE JENIGEN DIE KEINE HAUSNUMMER HABEN. So lieber es so lassen wie es ist, als ändern und immer bei Updates alles mit Hand anpassen zu müssen.
Hallo, habe in der Roadmap gesehen, dass dies für die Shopversion 3.0 geplant ist. Ich habe hier eine DRINGENDE Bitte: Wäre es möglich, diese Trennung nur für die Dateneingabe zu machen, aber die Daten doch wieder zusammen in eine Spalte in der Datenbank zu schreiben? Ich sorge mich darum, dass eine Änderung in der Datenbank bewirkt, dass wieder zahlreiche Anbindungen, Module, Plugins etc. zu Drittsystemen angepasst werden müssen (denke hier v.a. an den JTL Connector, der uns immer noch Kummer bereitet, aber auch an andere Wawi-Anbindungen, Marktplatzanbindungen, Logistikanbindungen, ... Oder wenn ihr das tatsächlich in der DB trennen wollt, dann auf jeden Fall mit Konfigurationsmöglichkeit im Shop? Hausnr. trennen => Ja/Nein?
Das wäre nicht Sinn der Sache. Es geht darum saubere Daten zu bekommen und abzulegen, das werden wir dann schon getrennt speichern. Das steht zu befürchten, ja. Wir haben aber schon echt lange für die Speicherung in einem Feld geblutet und wollen da raus, das tut auch immer wieder weh. MIttelfristig werden wir alle externen dazu bringen müssen über unsere APIs und Services auf die Shop-Entitäten zuzugreifen, damits dann dafür mal richtig langfristig stabil wird. Wir reden hier noch lange nicht über die letzte DB-Änderung, die kommen wird. Alle Dinge, die direkt auf der DB operieren werden den Pflegern dieser Dinge ab jetzt tendenziell häufiger mal weh tun, das muss man hier mal klar ausformulieren, der bisherige Weg ist Mist und blockiert die Shopentwicklung an einige Stellen. Ich müsste mir den Code mal ansehen, in Entwicklerversionen ist das schon drin, ich kenne aber die Details soweit selbst nicht. Ich mach das mal, dann kann man antworten. Was auch immer kommt, niemand wird euch gleich zwingen upzudaten, das wird man dann in Ruhe lösen können.
Puh... ich befürchte Schlimmes. Wir bekommen den JTL Connector noch nicht mal richtig zum Laufen und sind gerade noch mit externen Programmierern zugange, uns das ganze kostenpflichtig lauffähig zu machen, und schon sind die ersten Änderungen im Anmarsch, so dass man wieder von vorne anfängt... Du hattest aber auch am Telefon mal von einem Unternehmen gesprochen, das an einem eigenen JTL-Gambio-Connector arbeitet. Wer war das noch gleich, und wie ist der Status quo? Arbeitet dieser Connector mit eurer API? Haben ja zu der ganzen Thematik auch noch 3 Tickets vom 10. und 11. Februar offen, z.B. 100312890. Für Gambio kommt es nach wie vor überhaupt nicht in Betracht, aufbauend auf der Gambio API einen (evtl. kostenpflichtigen) eigenen JTL Connector zu bauen?
Wäre es denn vielleicht denkbar, die ganzen strukturellen Änderungen am Core und v.a. in der Datenbank nicht fortlaufend zu machen, sondern das ganze in 2-3 Jahren einfach in ein Super-Master-Mega-Update zu packen? Dann hätten alle Schnittstellen-Anbieter zumindest nur einmal den Anpassungsaufwand und nicht bei jedem Master Update. Würde ja auch ein heilloses Chaos geben in Sachen Versionskompatibilitäten. Früher war ein Modul einfach kompatibel mit Gambio, dann für GX2, und jetzt muss man mittlerweile schon genau auf die Versionsnummer schauen. Ich möchte hier keine schnelle Antwort, sondern mein Wunsch wäre es, dass du dieses Anliegen mal einfach mit in die nächste Teamsitzung mitnimmst. Das Argument, dass man nicht jedes Update mitmachen muss, lasse ich nicht gelten. Eure Update-Politik ist ja so engmaschig geworden, dass wer jetzt noch z.B. in der 2.2.x oder der 2.4.x Reihe steckt, gar keine Updates mehr bekommt. Da wäre echt noch die Überlegung, vielleicht doch noch parallel eine Longlife-Stable-Reihe zusätzlich anzubieten. Und wer rechtlich auf dem aktuellen Stand sein möchte, kommt ohnehin um jedes Master Update nicht umhin - Stichwort Versandkostenangabe im Warenkorb, Buttongesetz, VRRL, ... Oder gibt es solche Updates demnächst jeweils für 2.0, 2.2, 2.4, 2.6, 2.8, 3.0, ...
Es ist ja kein großes Problem die Hausnummern in der Schnittstelle wieder zuzufügen. Schwieriger wird es die Anschriften dann wieder Zielland-konform darzustellen. Wie wird denn dann entscheiden ob die Hausnummer vorne oder hinten steht? (z.B. in Frankreich) Wenn der Zusteller in Frankreich die Hausnummer nicht vorne findet, geht das Paket als unzustellbar zurück! Hatten wir schon. Brauchen wir nicht.
Altes Thema: Sorry, so funktioniert das nicht. Wir planen nicht die Datenbank um der Änderungen selbst willen zu verändern, sondern weil wir andere Dinge gut machen wollen. Aktuell denken wir zum Beispiel scharf über den Checkout nach und wollen da was machen. Wenn wir den neubauen, bauen wir auch die Hintergrundstrukturen neu, die können dann andere Anforderungen an die Datenbank stellen und da sind wir beim Kern. Wir werden keinen Checkout bauen der nicht mehr kann als der alte weil wir irgendwas in der Datenbank stabil halten wollen. Wir werden aber alles was wir bauen über eine stabile API bereitstellen, immer mehr. Dann wollen wir auch noch die Variantenartikel anfassen, und werden dafür neue Strukturen bauen, und das wird wohl ebenfalls recht sicher Änderungen in der Datenbank bringen,... Wenn wir jetzt all diese Dinge hinter verschlossenen Türen und ewig bauen, kommen wir in 2 Jahren mit einem unglaublichen Monster Checkout-Datenbank-Varianten-FSK-Mobile-HTML7-SSL-Autofabrik-Bananenshake Update und bis dahin kommt nix. Wenn wir die Zwischenstände präsentieren, wird dass das Ganze auch nicht reparieren. Das Statement wäre dann "Wir haben einen neuen, tollen Checkout und ihr dürft ihn ankucken liebe Kunden, aber ihr kriegt ihn nicht, der kommt in ein Monsterupdate in 1,5 Jahren"... Andernfalls wird uns jeder Kunde für tot erklären und wegrennen, weil er sich mit seinen aktuellen Sorgen allein gelassen fühlt. Am Ende steht: Die Dinge die wir machen müssen schon raus, und das immer einigermassen in Zeit, und das werden wir auch so machen. Wenn du Sorgen hast das zukünftige Änderungen am Shop für euch erstmal nicht funktionieren: dated den Shop nicht up bis der Staub sich für euch legt. Wir machen recht lange Security-Support für ältere Shops, so dass dass sicher funktioniert. Wenn ihr etwas neues bauen lasst, apifiziert das Ganze ab jetzt immer soweit schon möglich. Auf der Datenbank direkt rumschreiben müssen sich alle irgendwann abgewöhnen, wenn sie nicht leiden wollen.
Wenn ich das lese wird mir auch ganz schlecht. Ich hoffe nur das sich vieleicht auch jemand von JTL in diesem Forum umsieht und von den geplanten Änderungen in der DB liest. Einen dierekten Drat zwischen Gambio u. JTL scheint es ja nicht zu geben.
Doch, sehr großes Problem. Die JTL Schnittstelle ist sehr komplex, dazu in ein phar Archiv gepackt, so dass man an den Quellcode gar nicht ohne weiteres rankommt und sich dann immer mit irgendwelchen Plugins behelfen muss, deren Funktionsweise ich nicht raffe. Basiert wohl auf symfony - da kennt sich offenbar in Deutschland auch kaum jemand mit aus, habe ich den Eindruck. Selbst im JTL Forum meldet sich kein einziger JTL Servicepartner auf bitten um Angebote.
Ok, Bitte bleibt trotzdem: Nicht nur Security Fixes, sondern auch zwingende rechtliche Anpassungen für ältere Versionen anbieten! Sonst gibt es eine faktische Update-Pflicht. Bitte bitte mal in die Teamsitzung bringen!! Thema API: Ist der neue Connector von JTL ein API-Connector? Auch noch nicht, oder? Wo gibt es eine Doku zur API? Und ist der neue Connector-Entwickler, von dem du gesprochen hast, API-basiert? Wie ist da der Status? Danke und VG, Burkhard
Der Connector den JTL aktuell selbst vertreibt operiert meiner Kenntnis nach rein auf der Datenbank. Die APIs in ihren jeweils aktuellen Ständen sind auf developers.gambio.de dokumentiert. Was andere Connectoren angeht ist das Thema bei uns wach, aber noch nicht perfekt in der Spur, was nichts anderes heisst als es gibt noch kein Endkunden-verkaufsfähiges Produkt. Wenn wir da zu einem verkündbaren Ergebnis gelangt sind, werden wir das verlauten lassen.