[Gelöst] Auftragszeilen aktualisieren

[meto89]

Hallo,

ich habe folgende Situation:

Ich sollte die Verkaufspreisfindung ein wenig anpassen. War auch alles kein Problem.
Mein Problem ist jetzt, dass die Preise in den Auftragszeilen voneinander abhängen.
Deswegen müssen, wenn ich eine neue Zeile erzeuge oder eine Zeile änder, alle anderen Zeilen des Verkaufauftrages "aktualisiert" werden.
Sprich sie müssen neu validiert werden.

Wie kann ich es schaffen, dass ich die Zeilen aktualisiere? Das Problem ist, wenn ich z.B. einfach sage validate(Quantity), dass er dann natürlich für jede Zeile wieder jede Zeile
aktualisieren will, was bedeutet, dass ich in einer Endlosschleife lande.
Wie kann ich es schaffen, dass jede Zeile dieses Verkaufsauftrags einmal neu validiert wird?


Schonmal danke für die Hilfe.

Zuletzt geändert von meto89 am 2. September 2009 14:43, insgesamt 2-mal geändert.

Meinst du, dass du für die anderen VK-Zeilen den Preis neu berechnen musst?
Du könntest doch "einfach" für alle anderen nacheinander

Code:

SalesLine.UpdateUnitPrice(FIELDNO(Quantity));

aufrufen (nicht ausprobiert).

Zur Vermeidung der Endlosschleife könnte dir CurrFieldNo weiter helfen.

So in der Art habe ich das auch ausprobiert, mein Problem ist, an welcher Stelle ich den Aufruf verwenden soll...

Ich glaube ich vergesse gerade was sehr einfaches, ich komme aber einfach nicht drauf. Sorry

Edit: Das bezog sich jetzt auf die Antwort von Natalie

Hallo Meto89,

das ist ein nicht sehr simples Unterfangen, da du dadurch auch Änderungen auf dem Formular erzwingst, die nicht gerade den aktuellen Record betreffen. Das führt regelmäßig ins Abseits. Ich habe das dadurch gelöst, das ich das bei schließen/verlassen des Formulars/Sales Headers oder manuell per Button mache. Eine weitere Möglichkeit ist im OnAfterValidate eines Feldes im Form, aber Vorsicht: soviel ich weiß gibt es diesen Trigger beim RTC auf den Pages nicht mehr.

Gruß, Fiddi

So in der Art habe ich das auch ausprobiert, mein Problem ist, an welcher Stelle ich den Aufruf verwenden soll...

Ich glaube ich vergesse gerade was sehr einfaches, ich komme aber einfach nicht drauf. Sorry

Erst einmal solltest du dir klar werden, wann du die anderen Zeilen aktualisieren sollst.
IMMER wenn für eine VK-Zeile ein Preis ermittelt wird (durch welche Eingabe auch immer)?
Dann würde es sich anbieten, dass du die Funktion direkt in UpdateUnitPrice schreibst.
Diese Funktion hat gleich zu Anfang folgende Abfrage (ich nehme an, darauf hat auch McClane angespielt):

Code:

IF (CalledByFieldNo <> CurrFieldNo) AND (CurrFieldNo <> 0) THEN
  EXIT;

Das heißt, wenn du z.B. für die anderen VK-Zeilen diese Funktion mit einer nicht existenten Feldnummer als Parameter aufrufst, dann bist du auf der sicheren Seite.:

Code:

SalesLine.UpdateUnitPrice(987654321);

Wenn du es ein Stück eleganter (?) haben möchtest, kannst du auch für die anderen VK-Zeilen eine neue globale Variable setzen. Ist sie gesetzt, soll die neue Funktion innerhalb von UpdateUnitPrice nicht ausgeführt werden.

Vielen Dank für die Hilfe, ich habe das ganze jetzt in die Funktion UpdateUnitPrice geschrieben...
Wie fatal es doch sein kann, wenn man so ein modify vergisst

Jetzt ist nur noch das Problem, dass wenn das ganze durch eine Mengenänderung aufgerufen wird, dass er die anderen Zeilen noch mit der alten Menge der geänderten zeile berechnet,...

Jetzt ist nur noch das Problem, dass wenn das ganze durch eine Mengenänderung aufgerufen wird, dass er die anderen Zeilen noch mit der alten Menge der geänderten zeile berechnet,...

Soll ich das so verstehen, dass in den anderen VK-Zeilen auch die Menge geändert werden soll?
Wenn ja, dann führst du die Mengenänderung vor dem Aufruf von UpdateUnitCost aus. Wenn du allerdings die Menge validieren solltest, wird intern die Funktion UpdateUnitCost vom Standard aus aufgerufen und schon hast du wieder die Endlosschleife .... DANN bliebe ja noch der Weg mit der zu setzenden globalen Variable.

Nein die Menge soll nicht geändert werden, jedoch soll die Menge, die geändert wurde in die Preisberechnung der anderen Zeilen mit einfließen.

Wenn ich das Ganze mit der globalen Variable machen würde, das war nämlich mein erster Ansatz, ist die Frage, welchen Aufruf ich dort verwenden soll.
Würde ich dann einfach ein validate(quantity) für die anderen Zeilen ausführen, oder womit würde ich dies am besten durchführen?
Und würde ich den Aufruf dann auch weiterhin am Ende der UpdateUnitPrice Funktion einfügen?

Wie wärs mit ungefähr sowas

Code:

SalesLine.SetzdeineFilter;
IF SalesLine.FINDSET THEN BEGIN
  REPEAT
    SalesLine.Quantity := neueMenge; // nicht validieren
    SalesLine.UpdateUnitPrice(...); // füllt Unit Price auf SalesLine
    // Kein MODIFY!
    SalesLine2 := SalesLine;
    SalesLine2.VALIDATE("Unit Price", SalesLine."Unit Price");
    SalesLine2.MODIFY(TRUE);   
  UNTIL SalesLine.NEXT = 0;
END;

@Natalie,

das mit dem aktualisieren funktioniert zwar, es kann dir aber passieren, dass das Formular sich beschwert, weil jemand einen Datensatz geändert hat, den es gerade anzeigt.

Gruß, Fiddi

das mit dem aktualisieren funktioniert zwar, es kann dir aber passieren, dass das Formular sich beschwert, weil jemand einen Datensatz geändert hat, den es gerade anzeigt.

Stimmt, aber dank CurrForm.UPDATE(FALSE) kein Drama.

@Natalie,

ich bin der Meinung, das ich damals schon gar nicht mehr zum CURRFORM.Update gekommen bin.

Gruß, Fiddi

Wobei diese Meldung bei einer SQL-DB häufiger vorkommt als bei einer Native. Entscheidend bei SQL scheint mir, auf welchem Weg man die Aktualisierung programmiert, wenn man sich in einer Form befindet; also: direkt in der Form oder der Tabelle oder einer CU? Da ich den Fehler "ein anderer Anwender hat .." bisher nicht oft hatte (also in der Art: native klappt, aber SQL bringt diesen Fehler und CurrForm.Update(false) oder commit hilft gar nix), weiß ich gar nicht mehr genau, wie ich das gelöst habe. Ich glaube, meist ging es, wenn der code zur Aktualisierung in der Tabelle lag.

Weiß jemand die Zusammenhänge, was genau da beim SQL-Server passiert, und wie man es am Besten umgeht?

Hallo, tut mir leid, dass ich mich die letzten Tage nicht gemeldet habe, kam nicht dazu, mich weiter mit dem Problem zu beschäftigen.
So, habe mich mal wieder dran gesetzt und ich glaube ich habe mich etwas missverständlich ausgedrückt.

Nochmal von vorne... meine Anpassung habe ich in CU 7000 gemacht, die die Menge, die verwendet wird für die Berechnung des Verkaufspreises anpasst. Diese geänderte Menge kommt aus den Zeilen vom Auftrag.
Das Ganze ist für die Zeile, die ich ändere auch kein Problem, da ich noch auf die Menge zugreifen kann.

Nun wollte ich es so machen, dass die Preise für die anderen Zeilen auch neu berechnet werden. Das habe ich momentan in der Funktion <UpdateUnitPrice> der Tabelle 37 versucht. Ich habe einfach die Menge jeder Zeile validieren lassen. Nun ist das Problem, dass wenn er die Zeilen validiert und dann den Preis für diese berechnet, welcher von der Menge abhängt, dass die Menge des Feldes welches geändert wurde noch nicht validiert wurde.
=> Er rechnet noch mit der Menge die davor verwendet wurde.
Wenn ich die gleiche Menge noch ein 2tes mal validiere, berechnet er alle Zeilen korrekt, allerdings sollte man das nicht machen müssen.

Meine nächste Überlegung war, ob ich nicht die ganzen Datensätze in einen temporären Record kopiere, anschließend den echten Record lösche und die Datensätze aus dem temporären wieder einfüge. Dann würden die Mengen schon richtig drin stehen und das validate sollte dafür sorgen, dass alle Preise richtig berechnet werden.
Jetzt ist die Frage, ob das sinnvoll wäre, dass so zu lösen und ob es nicht vielleicht einfacher funktionieren würde.


Anmerkung: Ich möchte nicht auf der Form programmieren.

Wie ich schon früher erwähnt hatte funktioniert das mit dem Preis aktualisieren nur sauber, wenn du sicher sein kannst, das der aktuelle Record komplett validiert ist, und eigentlich schon in der DB steht. Deshalb auch mein Vorschlag am Anfang, das per Button oder in den erwähnten Triggern zu machen, da man dort sicher sein kann, einen konsistenten Zustand vorzufinden. (Ich habe an dem Problem auch schon einige Tage zugebracht , aber wenn du eine funktionierende Lösung findest, lass es uns wissen)

Gruß, Fiddi

So, ich habe mitlerweile auch aufgegeben es anders zu lösen und den Code in der Form hinterlegt =/

Naja, aber gelöst ist es quasi...