Neu Artikelsuche mit % Platzhalter funktioniert nicht mehr (wie früher)

[M_P]

Es gibt ab der Wawi 1.10 nun die neue Wildcardsuche für die "F2 / Artikel"-Übersicht.

Leider ist das in der Praxis unpraktisch, weil man jetzt ständig zwischen "Beginnt mit" / "Enthält" / "Wildcard" wechseln muss und das so den alltäglichen Arbeitablauf stört.

Beispiel:
- man sucht eine Schraube, also gibt man mit aktivierten "Enthält"-Filter schraube ein.
-> es wird etwas gefunden, aber noch zuviel✔️
- also ergänzt man schraube%10mm es wird etwas gefunden:

-> ✅ FRÜHER (vor Wawi 1.9): Alles gut und alle Schrauben mit "schraube" und "10mm" z.B. irgendwo im Namen werden SOFORT gefunden.
-> ❌ Wawi 1.9: FRUST/Verägerung - Es wird nichts gefunden, weil der Begriff "Enthält" nicht greift.
-> wenn man aber auch ein "%" an den Anfang uns ans Ende schreibt geht doch wieder (Notlösung ✔️), siehe Forum: Wildcardsuche kaputt
-> ❌❌ Wawi 1.10: 2. MAL FRUST/Verägerung Es wird immer noch nichts gefunden, weil in "Enthält" keine Wildcards mehr greifen und nur nach dem Exakten Begriff gesucht wird 🤬
-> also zusätzlich zu den % am Anfang Ende auf "Wildcard umstellen" -> endlich klappt es ✔️

Die vorherige Suche war also erfolgreich und man arbeitet weiter und muss dann wieder etwas suchen-> z.B. die passenden Muter für die Schraube also gibt man "Mutter" ein:
-> ✅✅ FRÜHER (bis Wawi 1.9): Alles gut und alle Muttern werden SOFORT gefunden und man spezifiziert bei Bedarf weiter.
-> ❌❌❌ Wawi 1.10: 3. MAL FRUST/Verägerung Es wird wieder nichts gefunden und man muss entweder %Suchbegriff% setzen oder wieder und wieder und wieder von "Wildcard" auf "Enthält" umstellen... 🤬🤬🤬

Lösung:
Für versierte Nutzer, die die Wildcards nutzen wollen, lassen sie sich dauerhaft aktivieren, ohne die oben beschriebenen Nachteile in der Effizienz:



Stimmt ab für eine bessere Artikelsuche in der Wawi, wir würden uns freuen:
➡️ https://issues.jtl-software.de/issues/WAWI-85542 ⬅️

________________________________________________________________________________________________________________

(@DaPlaya9971 ; @Sladek-IT ; @mvh ; @Wissenssammler )

 

[mvh]

Moin. Grundsätzlich bin ich dafür. Allerdings nutze ich meistens die Wildcard Suche und die anderen Mitarbeiter Beginnt und Enthält. Wir haben uns schon daran gewöhnt. Ich finde die Lösung zumindest für uns optimal. Alle Mitarbeiter haben verstanden: Wildcard mit %_[] und der Rest ohne. Ich werde bei uns in der Runde mal fragen. Viele Grüße, Ihr MVH Team.

 

[M_P]

Das kann ich nachvollziehen.

Aktuell ist es halt für den versierten Nutzer, der wildcards nutzt, wirklich umständlich, weil er keine schnelle Suche in Kombination mit Wildcars ohne immer wieder umständliches Umstellen mehr direkt zur Verfügung hat.

Die von uns gezeigte Lösung bietet genau das und hätte dann imho keinen Nachteil gegenüber der aktuellen oder?

 

[Peeters]

Diese Varianten sind alle überflüssig und machen die UI unübersichtlich bzw. überfrachten diese, so mal JTL keine einheitliche UI-Sprache unter den Teams kennt, so der Anschein der Außenstehenden. Der Standart sollte generell von „Beginnt“ sein, und durch Wildcard ergänzt werden können. Ein Mouseover Hint-Text könnte für nicht versierte Benutzer auf die Wildcard hinweisen.

 

[M_P]

Diese Varianten sind alle überflüssig und machen die UI unübersichtlich bzw. überfrachten diese, so mal JTL keine einheitliche UI-Sprache unter den Teams kennt, so der Anschein der Außenstehenden. Der Standart sollte generell von „Beginnt“ sein, und durch Wildcard ergänzt werden können. Ein Mouseover Hint-Text könnte für nicht versierte Benutzer auf die Wildcard hinweisen.

Das sehe ich nicht so, denn mit wildcards jonglieren ist definitiv nicht jedermans Sache und auch u.U. gefährlich ("SQL-Injection")

Normalerweise einmal eingestellt fasst man das Dropdwonmenu dann nur noch selten/bei Bedarf an.
Aber der jetzige Wawi-Zustand macht genau das notwendig und die Scuhe behäbig und langsam....

 

[Peeters]

Das sehe ich nicht so, denn mit wildcards jonglieren ist definitiv nicht jedermans Sache und auch u.U. gefährlich ("SQL-Injection")

SQL-Injection sollten Programmierer immer berücksichtigen, dass habe ich bereits schon vor über 25 Jahren berücksichtig. Und mit Wildcards zu jonglieren ist keine grosse Sache, wenn Benutzer ein Wildcard kennen reicht das meistens schon aus.

 

[M_P]

Bzgl. SQL-Injection bin ich absolut bei dir, aber das scheint wohl theoretisch bisher möglich gewesen zu sein, getestet hab ich es nicht.
Aber ich möchte JTL mit dem Wunsch so wenig wie möglich Arbeit bereiten, so dass die Chance der Umsetzung des Tickets höher sind.

Bzgl. Wildcards musst du dann aber auch bedenken, dass es Wawi-Bediener gibt, die evtl. nicht so sicher im Umgang mit den verschiedenen "Steuerzeichen" sind und gern ein "Beginnt mit", "Enthält" oder "ist genau" hätten... Das gibt es zwar über die Erweiterte Suche ist aber im normalen Alltag eher aufwändig und klickintensiv.

Es wäre einfach toll, wenn es für typische Alltagssituationen (siehe mein Beispiel oben) eine schnelle und effektive Suche gibt, so wie es sie vor Wawi 1.9 gab.

 

[Chris Ohm]

Die Artikelsuche frustet bei uns schon immer. Das liegt vielleicht auch zum kleinen Teil auch an der eigenen Datenhygiene, aber auch die Wildcard-Lösung ist in meinen Augen suboptimal. Vorallem da auch die Position der Wildcards im Artikelnamen bekannt sein muss.

Zum Beispiel wird "Mütze Marke Farbe Größe" nicht gefunden wenn nach %Mütze%Größe%Farbe% gesucht wird.

Das ist besonders bei Beratungsgesprächen kontraproduktiv, wenn schnell eine Übersicht aller Produkte mit bestimmten Merkmalen gefunden werden soll. Sollte die Reihenfolge der Begriffe in allen Produkten nicht 100%ig konsitent sein, was durchaus bei einem großen Produktportfilio vorkommen kann, ist es quai unmöglich alle gewünschten Produkte in der Suche zu filtern.

Vielleicht bin ich hier zu naiv, aber mein Wunsch wäre, dass standardmäßig ein "Leerzeichen" statt "%" die Suchbegriffe trennt und die Reihenfolge der Suchbegriffe irrelevant ist. Exakte Suchbegriffe mit Leerzeichen müssten dann mit Anführungszeichen versehen werden. So wäre die Suche wirklich sehr intuitiv und vielseitig.
Auch dass vor und nach einem Suchbegriff ein Platzhalter eingefügt werden muss, ist vollkommen unpraktisch und sollte, (wenn es prokramiertschnisch notwendig ist), direkt als festgeschriebener Befehl in die Programmierung eingebaut sein.

Durch das standardmäßige Umstellen unterschiedlicher Suchmodi wie von @SportNet vorgeschlagen würde das für unterschiedliche Nutzertypen noch individueller gestalten bzw. anpassbar machen.

 

[M_P]

Zum Beispiel wird "Mütze Marke Farbe Größe" nicht gefunden wenn nach %Mütze%Größe%Farbe% gesucht wird.

ich bin komplett bei dir, eine noch "intelligentere" Suche wäre schon toll, allerdings sind wir dann wieder bei folgendem Thema:
> Aber ich möchte JTL mit dem Wunsch so wenig wie möglich Arbeit bereiten, so dass die Chance der Umsetzung des Tickets höher sind

Es wäre aus unserer Sicht einfach toll, wenn man zumindest zeitweise (bis deine umnfangreiche Version möglich ist), das alte gewohnte und vermutlich bessere Verhalten vor 1.9 wiederhergestellt wird.