[GELÖST] selektives FlowField auf Zeilenebene

Hallo Community,

ich wunder mich momentan über ein seltsames Phänomen. Darauf gestoßen bin ich, dass ich mit "SETFILTER" auf ein Decimal-FlowField einen Filter setze, der Inhalt jedoch immer 0 ist, obwohl ein Wert drin ist.

Ich habe mein Feld BestellPosNr. in der Tabelle über ein FF auf die PosNr. in der Einkaufszeile referenziert.

25-04-_2016_10-20-56.png

Wenn ich nun in meiner Sub-Form einen Lookup auf "BestellPosNr." in der ersten Zeile mache, klappt alles reibungslos.
Wenn ich hingegen einen Lookup auf "BestellPosNr." in der zweiten Zeile mache, folgt dieser Fehler.

FFPurchaseLine2.png

In der Tabelle/Sub-Form stimmt generell etwas gewaltig nicht.
Filter in meine Zeilen-Tabelle, findet er erst die Zeilennr. 20000 und dann 10000 obwohl dem Primary-Key nach die "normale" Reihenfolge kommen sollte.

Ob dies hier irgendwie zusammen hängt?

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von MSNAVLerner am 27. April 2016 14:50, insgesamt 2-mal geändert.

Ich konnte nun das Problem etwas eingrenzen.

Die Flowfields auf die Bestellzeilen funktionieren, solange für diese Bestellzeile keine Menge gebucht wurde.
Sobald gebucht wurde, kommt folgende Meldung (das seltsame ist, dass ich auf purchase line und nicht header gehe)

seltsame meldung.png

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Komisch, bzw. falsch ist ja auch, dass nach Belegart = Anfrage statt Belegart = Bestellung gesucht wird.

Korrekt. Ich übergebe als Typ als CONST "Order" und trotzdem.
Ich habe versucht zu debuggen, doch die Fehlermeldung kommt noch bevor der Debugger anspringt.

Hallo,

das kann eigentlich nichts direkt mit dem FlowField zu tun haben. Die Fehlermeldung bezieht sich auf den Einkaufskopf, nicht auf die Zeilen.

Gruß Fiddi

Ich referenziere aber auf die Purchase Line mit dem FF.
Es betrifft auch nur die Zeilen, die gebucht wurden und auch nur, wenn ich versuche einen LookUp auf das jeweilige Flowfield zu machen.

Mir gehen die Ideen aus.

Hallo,

also das hat nichts mit dem FF zu tun, sind die Bestellungen nur geliefert, oder auch fakturiert?

Wahrscheinlich ist irgendwo ein Flowfield, das nur auf die Belegnummer geht ohne "Document Type" zu berücksichtigen. Das kann auch in der "Purchase line" selbst. sein.

Sollte die Bestellung fakturiert sein, ist Sie im Standard nicht mehr vorhanden, d.h. dein Lookup läuft korrekterweise ins leere.

Gruß Fiddi

Die Bestellzeile ist nur geliefert.
Was meinst du mit "in der Purchase Line" selbst?

Aus meiner Wareneingangszeile gehe ich unter Berücksichtigung von "Document Type" auf die Bestellzeile. Es funktioniert auch reibungslos bei den Zeilen, die bestellseitig noch nicht geliefert wurden.

Ich konnte den Fehler eingrenzen.
Dieses Problem betrifft nur die Bestellzeilen, dessen Bestellung aus einer Anfrage generiert wurde.

Die Frage ist nur, wie ich die Fehlerquelle finden kann, da debuggen hier nicht hilft.

Also nun betrifft es wohl alle Bestellungen, egal ob aus Anfrage oder manuell erstellt.
Sobald die Bestellzeile beliefert wurde, gehen die FlowFields nicht mehr.

Wo kann ich denn einsehen oder mich informieren was der StandardFlowField innerhalb einer Tabelle so treibt?

Es geht hier um die Tabelle 7317, oder?

Und wie genau meintest du diesen Satz aus deinem ersten Beitrag:

Darauf gestoßen bin ich, dass ich mit "SETFILTER" auf ein Decimal-FlowField einen Filter setze, der Inhalt jedoch immer 0 ist, obwohl ein Wert drin ist.

Wieso ist der Beitrag eigentlich "gelöst" - hast du das Problem gefunden?

Ahh total vergessen das Ergebnis noch zu teilen.
Konnte das Problem finden. Der Tabelle Purchase Line (ID39) wurde die LookupFormID "Purchase Line" hinterlegt und diese hat folgenden Filter in der SourceTableView

WHERE(Document Type=CONST(Order),Outstanding Quantity=FILTER(>0))

Vollständig belieferte Zeilen haben nun mal keinen "Outstanding Quantity" und deswegen ist mein LookUp auch immer mit der Meldung gekommen.
Die Meldung hingegen finde ich total bescheuert, doch Hauptsache das Problem konnte behoben werden, auch wenn dies viel Recherche gekostet hat.