Filter setzen über Lookup

Hallo zusammen,

mir ist heute ein sehr merkwürdiges Phänomen in NAV aufgefallen.

Ein Kunde von uns möchte in einem Inventur-Buchblatt einen Filter setzen. Dazu drückt er die Taste F7 und wählt per Lookup einen Artikel aus. Wenn er jetzt in der Artikelübersicht mit OK bestätigt erscheint folgende Fehlermeldung:

Inventur muss Nein in Artikel Buch.-Blattzeile Buch.- Blattvorlagenname='INVENTUR',Buch.-Blattname="STANDARD',Zeilennr.=60000 sein.

Mit dem Debugger bekommt man heraus, das er bei diesem Lookup, den OnLookup-Trigger der Artikelnr. im Buchblatt durchläuft. Wie kann das sein? Gibt es einen Weg den Aufruf des Triggers zu verhindern?

Gruß, Fiddi

Mit dem Debugger bekommt man heraus, das er bei diesem Lookup, den OnLookup-Trigger der Artikelnr. im Buchblatt durchläuft.

Habe ich das richtig verstanden?
Obwohl der Benutzer definitiv keinen Lookup tätigt, sondern nur F7, wird der OnLookup-Trigger durchlaufen?
Welcher - Tabelle oder Form?

PS: Ich habs erst jetzt verstanden ...
Du hast doch selbst geschrieben, dass der Benutzer nach F7 manuell einen Lookup auf die Artikelnummer ausführt.
Dann ist es doch klar, dass der Trigger durchlaufen wird? Ob wir uns zu dem Zeitpunkt direkt auf der Tabelle befinden oder in den Filtern (die wiederum auf Tabellenfelder zeigen) ist irrelevant.

Interessanter ist doch, wie die Fehlermeldung zustande kommt.
Ist es ein Testfield in der Lookup-Codezeile?
Oder kommt sie aus der Feldeigenschaft ValidateTableRelation?

Genauso ist es.

Ich hab das ganze mit der Standard-Addon 5.0Sp1 ausprobiert. Inv-Buchblatt berechnet, in Artikelspalte auf F7 gedrückt, F6 für Artikelübersicht, einen anderen Artikel ausgewählt, mit OK bestätigt und gestaunt.

Gruß,Fiddi

Genauso ist es.

Ich hab das ganze mit der Standard-Addon 5.0Sp1 ausprobiert. Inv-Buchblatt berechnet, in Artikelspalte auf F7 gedrückt, F6 für Artikelübersicht, einen anderen Artikel ausgewählt, mit OK bestätigt und gestaunt.

Gruß,Fiddi

Ich habe meine Antwort editiert ...

Interessant ist nur das er beim Setzen des Filters gerade versucht meine aktuelle Buchblattzeile auf die ausgewählte Artikelnr. zu ändern, und noch so einigen andere Dinge veranstaltet, die definitiv nicht zum setzen eines Filters gehören.
Entweder ist da ein grober Fehler des Standards, im Onlookup- Trigger Daten zu verändern, oder da ist was im Client nicht sauber programmiert (wie wärs, wenn der Client über die Tablerelation des Feldes geht und nicht über den Onlookup) .
Niemand erwartet bei der Auswahl eines Artikels für einen Filter, dass seine Daten, die er filtern will verändert werden

Gruß, Fiddi

Niemand erwartet bei der Auswahl eines Artikels für einen Filter, dass seine Daten, die er filtern will verändert werden

Aber woraus schließt du, dass versucht wird, Daten zu ändern? Wo genau bleibt der Debugger hängen (ich fragte bereits ob in Tabelle oder Form, TESTFIELD oder TableRelation)?

Hallo Natalie
Der Debugger bleibt an im Quantity- Onvalidate stecken . Wenn man sich Rec ansieht steht jetzt auch die ausgewählte Artikelnr. drin und nicht mehr die ursprüngliche. Ich denke das erwartet man nicht, wenn man einen Filter setzt, oder?

Gruß, Fiddi

P.S.: machst du das ganze in einem normalen Artikelbuchblatt mit Daten, wird deine Artikelnr. geändert. Was man aber erst auf den zweiten Blick merkt (nachdem man das Filterform verlassen hat).

Der Debugger bleibt an im Quantity- Onvalidate stecken . Wenn man sich Rec ansieht steht jetzt auch die ausgewählte Artikelnr. drin und nicht mehr die ursprüngliche.

Was für ein Rec ist das? Ist dies wirklich "dein" Datensatz oder ein (fast) leerer? Schau mal im Debugger nach den Feldinhalten.

Ich tippe nämlich darauf, dass es sich entweder um einen leeren Datensatz oder eine Kopie irgendeines Datensatzes handelt, nicht jedoch um die tatsächlichen Daten, die damit geändert würden.
Und wenn doch nicht: Men lernt schließlich nie aus

Hallo Natalie,

die Zeilennummer ist identisch mit der meines ursprünglichen Datensatzes.

Gruß, Fiddi

Und wie erklärt der Debugger den Sprung zum Quantity - OnValidate?

Hallo Natalie,

Hier der Aufrufstack des Debuggers: (Die Trigger werden von unten nach oben durchlaufen, der oberste ist der letzte)

Table 83 Artikel Buch.-Blattzeile\Quantity - OnValidate()
Table 83 Artikel Buch.-Blattzeile\Unit of Measure Code - OnValidate()
Table 83 Artikel Buch.-Blattzeile\Item No. - OnValidate()
Table 83 Artikel Buch.-Blattzeile\LookupItemNo()
Table 83 Artikel Buch.-Blattzeile\Item No. - OnLookup()

Gruß, Fiddi

Dachte ich es mir :-/
Ich vermute, du wirst für dein Problem um einen Woraround nicht herumkommen:
Statt nach F6 und Artikelauswahl OK zu klicken, müsste man sich den Artikel seiner Wahl in der Übersicht kopieren und ihn im Filterfeld wieder einfügen ...
So wird das Validate nicht durchlaufen.
Oder man ersetzt im OnLookup-Trigger das VALIDATE durch eine harte Zuweisung (normerweise kein Lösungsweg). Ist vielleicht beim Lookup aus dem Filterfeld CurrFieldNo = 0 (und beim Lookup aus der "richtigen" Tabelle <> 0)?
Wenn ja, dann könnte man versuchen, unter dieser Bedingung eine Zuweisung statt ein VALIDATE auszuführen ...

Hallo,

das dürfte ein Standard-Bug sein.
Soweit ich weiß, wird beim LookUp nach F7 der Lookup gem. der Tabelle vorgenommen und der ist hier in T83 ausprogrammiert.

Ohne jetzt die enthaltenen Funktionalität geprüft zu haben, sollte die Funktion "LookupItemNo" nur direkt aus der Form heraus verwendet werden und in der Tabelle sollte nur der Lookup über die Proporties gesteuert werden. Dann gibt es auch mit F7->Lookup keine Probleme.

@woger:

Das sehe ich genauso wie du.
Der Hintergedanke von NAV, den Lookup- Trigger aufzurufen, ist so falsch nicht. In unserer Branchenlösung gibt es eine Lookupform, in der sind Pseudo Tabellenummern enthalten, um die unterschiedlichen Einheiten des Artikel referenzieren zu können. Diese Tabelle wird im OnLookup erstellt, und damit eine Form aufgerufen, damit die korrekte Einheit aufgerufen werden kann. Die Filterfunktion kann also die temporären Daten verwenden, was mit der reinen Tabellenrelation nicht funktionieren würde.
Aus dem eben genannten Beispiel heraus darf man aber auch das Ändern von Daten im Onlookup nicht verbieten.

Eine Lösung kann meiner Meinung nur sein, den Filter- Lookup auf einer temporären Kopie des aktuellen Datensatzes laufen zu lassen.

Gruß, Fiddi