Guten Tag,

heute ist mir folgendes aufgefallen.
Ich suche den Betrag einer alten bezahlten Lieferantenrechnung, 1.589,69
Bei Eingabe dieses Betrages in das Suchfenster ganz oben rechts (über alle Konten) selektiert während der Eingabe B4W schon einige Datensätze, ABER der gesuchte ist nicht dabei !!!???
Erst bei Eingabe des kompletten Betrages, inkl Nachkommastellen, wirft B4W den Datensatz plötzlich als gefunden heraus.

Das finde ich schon befremdlich, weil, durch das vorangegangene "finden" einiger willkürlicher Datensätze denkt der User, das ein Substring Suche stattfindet, die aber in Wirklichkeit garnicht da ist.

Selbst Wildcards, wie z.B. 1589* führen zu keinem Ergebnis.

Da dem User NICHT klar ist, das eine EXAKTE Suche durchgeführt wird, ist das schon sehr irreführend, bzw ich habe, in Unkenntnis dieser starren Suchbearbeitung durch die Software, hier mehr als eine Stunde bei der Fehlersuche vergeudet ......
Frage: Warum können, über alle Konten, keine Teilsuchen mit Substrings oder Wildcards durchgeführt werden ?

Ich gebe zu, das ist verwirrend. Allerdings ist dieses Verhalten nur bei den Beträgen so. Bei Eingabe von 296 werden Datensätze mit ein Betrag 296,00 und auch -296,00 angezeigt, Datensätze mit 296,10 oder 296,11 nicht. Datensätze, bei denen im Verwendungszweck 296 vorkommt, werden angezeigt. Wenn also irgendo ein EC251942961234 auftaucht, dann wird das angezeigt. Somit reagiert die Suche zweigeteilt, bei Texten sucht sie das Vorommen von Teilstrings, bei Beträgen wird nur der GENAUE Betrag gefunden. Wenn man's weiß, kann man damit eine Menge machen, wenn man's nicht weiß, kann man lange rumsuchen.

Das, was Du gemacht hast, würde ich allerdings nicht über diese obige Generalsuche machen. Diese sucht offenbar nur noch in den Umsätzen, wenn ich mich recht erinnere, dann suchte die früher auch in Zahlungsaufträgen und Vorlagen und Begünstigten... bin mir aber nicht mehr sicher. Jedenfalls ist für Deine Belange sicher die Filtersetzung unter der Umsatzanzeige besser geeignet. Dort kannst Du einen Betragsbereich a la "Ausgaben zwischen 290 und 300" setzen und ggf. noch weitere Einschränkungen über Zeit und Text. Damit fidest Du das Gesuchte auf jeden Fall, auch wenn Du den Centanteil des Betrages nicht genau kennst.

Danke für die ausführliche Erklärung.
Trotzdem erschliesst sich mir der Sinn nicht?
Warum eine Suche im Verwendungstext Teilstrings sucht und im Betrag NUR exakt, das soll man erst mal logisch argumentieren ....
Denn, wenn ich bei einer Teilstringsuche den GANZEN Betrag eingebe, ja, dann findet die Suche ja auch den GENAUEN Betrag- was soll also das Wirrwarr ??

Das Tollste ist, das wenn ich den Suchbetrag 1.589,69 (also exakter Betrag) unten in das Suchfeld eingebe, dann wird garnichts mehr gefunden!?
Erst wenn ich den identischen Betrag oben rechts eingebe, dann findet er den Datensatz.

Fazit: Ich habe noch nie in meinem Leben soviel herumreden müssen, um vom Programmierer zu hören, "ja, exakte Suche macht keinen Sinn, wäre ja von Teilstring sowieso auch abgedeckt."

Unten gehen nur GANZE Zahlen und nur Bereiche. Für 1589,69 müßtest Du also "von 1589 bis 1590" eingeben.

Wenn Du "oben zusätzlich" den genauen Betrag eigibst, dann übernimmt die obige Generalsuche und deaktiviert die untere Filterfuntion. Somit findest Du da den Betrag dann doch.

Und ja, mir erschließt sich der Sinn hinter dem Ganzen auch nicht wirklich völlig. Ich nehme an, daß das letztendlich mit dem historischen Wachsen des Programms zu tun hat...

Hallo,

der Betrag wird nur exakt gesucht, da dieser intern ja nicht als Text gespeichert ist. Intern werden Beträge immer als positive decimal Typen gespeichert. Das ist ein 128 Bit langes binäres Muster das mit dem Dezimaltext rein gar nichts mehr zu tun hat und damit auch nicht verglichen werden kann. Deshalb wird für die Betragssuche die Eingabe in das Suchfeld erst in ein decimal gewandelt (sofern möglich) und dann nach diesem Dezimalwert gesucht. Die Textsuche läuft parallel dazu. Es finden also immer zwei separate unabhängige Suchen statt.

Das ist jetzt die technische Erklärung, die auch einleuchtet. Der "Normalnutzer" wird da nie draufkommen und sich dann so wundern wie Salorian.

Dumme Frage: Wäre es nicht möglich, stattdessen die Beträge in Dezimaltext zu wandeln und dann den Suchstring damit zu vergleichen? Wahrscheinlich eine Frage der Performance? Wobei dieser Dezimaltext in vielen Fällen ja schon vorhanden ist, für die Anzeige... Für den Normalnutzer wäre das wahrscheinlich logischer...

Abgesehen davon, das sicher die Mehrheit der User die Programmiersyntax nur schwer verstehen, ist es doch ganz simpel.

Wie zitiert, wird also die Eingabe in das Suchfeld (Beispiel 158 ) in ein Decimal umgewandelt.
Ich verstehen tu, das aus meinen 3 Ziffern 158 ein Decimal erwandelt wird, welches auch 158 heisst?

Zitat: Intern werden Beträge immer als positive decimal Typen gespeichert
Dies vorausgesetzt findet leider die Suche eben nicht die Übereinstimmung meines Suchbegriffes "158" mit dem Datensatz, welcher 1589,69 enthält (als positive decimal typ)

Im Normaldeutsch:
Jedes Handy sucht aus Teileingaben die tollsten Trefferlisten, jede Suche mit heutiger IT, egal wo und mit welcher Software ausgeführt, findet bei Eingabe von "158" einfachst "1589,69" -
nur die B4W Software nicht.....?

Hallo,

@Salorian Gib mir bitte nur ein einziges Beispiel einer Software welche Datensätze mit Dezimalwerten in großen Mengen verarbeitet und bei der eine Suche nach dem Betrag "123" auch einen Treffer bei dem Wert 541234,98 liefert? Nur ein einziges.

Das ist eine sehr subtil unfaire Frage, ich spreche nicht von einem "Innenfragment" einer längeren Zahl, sondern davon, unter Eingabe der ersten und weiteren Ziffern einer bekannten Zahl den Datensatz zu finden.
Ein Mittenfragment aus einer gesuchten Summe einer Überweisung wird man nur unter zuhilfenahme von viel Rotwein für sinvoll erachten ....
Siehe Anfang des Threads:
Ich suche den Betrag einer alten bezahlten Lieferantenrechnung, 1.589,69
Bei Eingabe dieses Betrages in das Suchfenster ganz oben rechts (über alle Konten) selektiert während der Eingabe B4W schon einige Datensätze, ABER der gesuchte ist nicht dabei !!!???

Um einen mega simplen Test zu machen, bitte einfach mal die von ihnen benannte Zahl 541234,98 per Email an ihr Handy senden dann die mail lesen, dann mal nach "541" suchen, voila, gefunden. Dito mit etlichen anderen Suchroutinen, selbst Excel hält da etwas bereit ....

Warum bei Benennung eines Problemes in täglichen Handling immer gleich die Emotionen anspringen ist auch nicht so hilfreich ....

@salorian: Du schreibst völlig am Thema vobei, da Du offenbar den technischen Hintergrund nicht verstanden hast. Der ist:

In der Datenbank liegen die Zahlen in Form einer binären Codierung vor - also einer Folge von Nullen und Einsen - und eben nicht in Form von Ziffernstrings. Jedes Mal, wenn die Zahl dem Menschen präsentiert wird, muß sie in den Ziffernstring gewandelt werden. Dies passiert zwar bei der Anzeige auf dem Bildschirm - aber eben nur für die gerade angezeigten Datensätze. Wenn man blättert, dann für die nächsten nötigen Datensätze.

Bei der Suche passiert nun folgendes: Der eingegebene Suchstring wird erstens mit den Texten verglichen (die Texte liegen als Textstrings vor, somit ist der Vergleich sofort möglich). Weiterhin wird der Suchstring, wenn er einen Zahlenwert darstellt, in die binäre Darstellung umgewandelt (EIN Mal) und diese Binärdarstelliung mit den Binärdarstellungen in der Datenbank verglichen - mit allen vorhandenen Datensätzen aller Konten. Das ist wohl noch halbwegs performant machbar. Wenn man es anders machen würde, dann müßte man beim Suchen von JEDEM Datensatz die Binärdarstellung des Betrages in einen Zahlenstring umwandeln, vergleichen und dann den Datensatz hernehmen oder verwerfen. Hier würde dann gerade bei großen Datenmengen die Performance massiv einbrechen.

Im Falle meines größten Tresores, der derzeit 97.000 Umsätze beinhaltet, wären also 97.000 zusätzliche String-Konversionen nötig. Du kannst Dir vorstellen, daß das dann zu einer argen Trägheit des Programms bzw. der Suchfunktion führen würde, bis dahin, daß die Suchfunktion nicht mehr sinnvoll verwendbar ist (man gibt eine Ziffer ein, es wird konvertiert und gesucht, bis das fertig ist friert das Programm ein, dann gibt man die nächste Ziffer ein, es wird wieder konvertiert und gesucht usw.). Insofern ist das durchaus sinnvoll, wie es jetzt ist. Wenn man eine Zahl sucht, zu der man den Cent-Anteil nicht kennt, kann man das genausogut über einen Betragsfilter von/bis machen, also z.B. 598,43 wird gefunden bei Filger von 598 bis 599. Auch über alle Konten ist dieser Filter möglich. Somit vermißt man nichts und hat oben eine performante Suche für andere Notwendigkeiten.

Ich muß sagen, ich bin eh sehr erstaung, WIE performant die Anwendung ohne große Datenbanken und Drumherum ist, wenn ich meinen größten Tresor mit 350 Konten und 97.000 Umsätzen anschaue. Dafür ganz großen Respekt an Andreas!

danke für die technische Erklärung.
Ich habe halt nur, als sicher sehr simpler Anwender, die einfache Frage, warum mein Handy, mein Excel, Google, dann noch die Software X1.com alles selbst mit Gigabyte Datenmengen erledigen können?
Selbst Outlook vervollständigt selbstständig eingetippte Emailadressen mit dem Verlaufs-Matching. Mein Navi nimmt meine Eingabe nach Städten, Strassen etc und vervollständigt diese mit Vorschlägen....
Sorry, ich verstehe es aus Kunden- und Anwendersicht wirklich nicht ...

Kurz gesprochen: Weil das alles als TEXT vorliegende Strings sind und in dieser Anwendung die Suche so optimiert wurde, wie ich geschrieben habe. Sie ist nicht in erster Linie für eine Betragssuche gemacht, sondern für eine Textsuche. In Textform vorliegende Teile werden ja auch so durchsucht, wie Du es oben geschrieben hast Aber nim Binärformat vorliegende Zahlen sind eben nun mal kein Textstring. Alternative für eine "Benutzerverständlichkeit" wäre, den Betrag bei der Suche ganz wegzulassen und nur die Texte zu durchsuchen.

Für eine Betragssuche gibt es den dafür optimierten Filter. Ob Du das jetzt verstehst oder nicht, ändert daran (leider) auch nichts. Die Programmfunktion ist entsprechend durchdacht und optimiert und für verschiedene Problemstellungen gibt es verschiedene Lösungen im Programm. Das ist so und wird so bleiben. Somit gilt wie so oft im Leben: Friß oder stirb

mir erschließt sich nicht ganz, warum nicht andere Merkmale einer Rechnung gesucht werden, denn die sind doch ebenfalls vorhanden

@Andreas
ich probier mal ein Vorschlag/Idee, der beide Seiten befriedigen könnte.
Es müsste doch möglich sein, den @msa Ansatz zu nehmen, nämlich wenn in der Suche oben ein Betrag** eingegeben wird (bspw. 1589), dass dann im Hintergrund "von 1589 bis 1590" gesucht wird.

das wäre zwar nicht ganz korrekt und der User würde somit "getäuscht", aber die Lösung und "Empfindung das Prog. macht was ich will" wäre gegeben.

**= wie man bei kompletter Eingabe verfährt, also bei 1589,69 - "von 1589 bis 1590" oder dann tatsächlich 1589,69 ist dann evtl. wieder was anderes.

Warum soll Andreas an einer Stelle etwas performanceraubendes (immer doppelt so viele Vergleiche wie derzeit, auch wenn man das garnicht braucht oder will) einbauen, wenn es genau das an anderer Stelle bereits gibt und man es dort gezielt nehmen kann? Wieso muß man unbedingt die EINE Suche hernehmen, wenn die ANDERE Suche das Mittel der Wahl ist? Kann ich nicht einsehen... Die Von-/Bis-Suche GIBT es ja über Filter bereits. Warum kann man die nicht einfach hernehmen und gut is? Dort kann man auch zusätzlich noch einen Textfilter angeben und zusätzlich noch einen Datumsfilter. Man kann gezielt das machen, was man braucht.

Moin,

da Solarian m.E. der genaue Betrag sicher bekannt war, wäre ja die Suche mit dieser Angabe 1589,69 schon mal erfolgreich gewesen.

Ansonsten nimmt man den Filter (wenn der ungefähre Betrag bekannt ist) grenzt die Summen "von - bis" dann ein.
Ich bin sicher, das gewünschte Ergebnis ist auf jeden Fall dabei.

Nachtrag: msa, Du hattest ja bereits ausführlich berichtet. Beiträge haben sich etwas überschnitten.

Ja, es sei denn, man will mit dem Kopf durch die Wand

Gedacht habe ich auch schon daran, gesagt habe ich es lieber nicht!

@msa

erstmal war es einen Idee keine Forderungen.
desweiteren ging es drum, wie man das bestehende mit den Wünschen des Users verbinden kann = Kompromiss/Schnittmenge - egal wie es nennen willst.
dies hat auch den Nebeneffekt, dass solche Erklärungen/Diskussion wie hier und dessen dass der Anwender es sodann evtl. doch nicht versteht/verstehen will - aus bleiben.

abschließend wird bei der Idee doch keine performanceraubende Änderung vorgenommen, sondern wie vorgenannt nur bestehendes verwendet.


du solltest vielleicht auch mal, neben den Fakten, dich auf die Umstände einlassen und dann auch Lösungen probieren zu ermitteln/finden - das fällt dir anscheinend schwer.
(bei dem Pseudo-Update warst auch erst vehement dagegen und später hast es sogar in einem deiner letzten Postings aufgeführt)

Im übrigen bedanke ich mich für Deine Analyse, was mir schwer fällt und was ich kann und was nicht. Endlich Klarheit in diesem Bereich, auf diese Erleuchtung warte ich ja schon so lange sehnsüchtig.

Ich war nie gegen ein Pseudo-Update, ich habe nur Anfangs keinen Weg gesehen, das war meine "eigene Dummheit". Nachdem ich einen technisch gangbaren Weg gesehen hatte, fand ich die Idee gut. Wobei das noch nicht komplett durchdacht ist, vielleicht bringt das irgend wo anders Probleme. Aber nachdem Andreas darauf nicht anspringt, ist das auch egal. Hier ist es genauso. Ich sehe das Ganze technisch. Die Möglichkeiten sind im Programm bereits jetzt vorhanden, man muß sie eben nur an der Stelle nutzen, wo sie da sind und nicht zwanghaft an der Stelle, an der sie so explizit nicht vorgesehen sind. Ich sehe auch keinerlei Sinn darin, stur zu fordern, daß an der zweiten Stelle etwas zusätzlich eingebaut wird, was definitiv zu Performanceveringerung führt, weil es an dieser Stelle dann grundstätzlich IMMER nebenher mitläuft, egal ob man es braucht oder nicht. Es sei denn, man baut die derzeit einfache Schnellsuche auch soweit aus, bis man auch dort eine Auswahlsuche hat. Das ist dann irgendwie noch weniger sinnvoll. Schnellsuche oben - schnell und simpel und performant - Filtersuche unten - viele konfigurierbare Möglichkeiten. So ist es gut und im Prinzip bin ich irgendwo froh, daß Andreas sich da auf keine Experimente einlässt. Was bei diesen Experimenten rauskommt sieht man an der Empfänger/Vorlagen-Auswahl in der Zahlungsauftragsmaske. Das ist inzwischen völlig unverständlich und miserabel in der Usability geworden.

ich hab anscheinend die Idee nicht richtig/verständlich darlegen können, denn sonst würdest du mit der Performance nicht kommen.

Basis-Idee eine "if then"-Abfrage in der Suche einzubinden: (das kennst du doch von excel)

- wenn Betrag vollständig (also 100,00) eingegeben = verfahre mit Suche wie bisher
- wenn Betrag unvollständig (also 100) eingegeben = dann geh zu Filter und befülle von <> bis (+1) - hier also von 100 bis 101


Dh. es müsst lediglich die "if then"-Abfrage gemacht werden, alles andere ist vorhanden mit gleicher Performance (also keinerlei Einbuße), da an der ja nichts geändert wird, ebensowenig wie an der Oberfläche.
Aber der User würde ein Ergebnis bekommen, ohne sich den Kopf zu zerbrechen warum das auf die eine Weise geht und nicht auf die andere
Hoffe jetzt ist es verständlicher was ich meine und selbst wenn wir nun einer/keiner gleichen Meinung wären - Andreas müsste es ja umsetzen oder eben auch nicht.