11. Juli 2013 15:26
Hallo,
wenn wir versuchen in einer Cronus DB eine Lieferung zu buchen, dann bekommen wir folgende Fehlermeldung:
Fehlermeldung.jpg
Kann mir jemand sagen was da schief läuft?
Gruß
Michael
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
11. Juli 2013 15:35
Hallo,
du hast wahrscheinlich in einem Unterprogramm mit einer lokalen Recordvariable den Einkaufskopf geändert (MODIFY), und übergibst jetzt die ursprüngliche Version an die CU 90, NAV merkt jetzt anhand des Timestamps, das die zu buchende Version älter als die Version auf der Platte ist, und sagt "so geht das nicht"
Gruß, Fiddi
11. Juli 2013 15:47
Hallo Fiddi,
danke für Deine Antwort. Was mich wundert ist, dass dies eine Cronus DB ist ohne irgendwelche Anpassung.
Wie kann ich den Übertäter da herausfinden?
Gruß
Michael
11. Juli 2013 15:51
aktuelles Build?
11. Juli 2013 16:43
Hallo Fiddi,
die Buildversionnr. lautet 34902. Der Fehler tritt beim PurchHeader.Modify(true) in der CU415
Gruß
Michael
11. Juli 2013 16:56
das ist mir beim anpassen von 2013ner db's schon häufiger passiert....wird da ein transferfields gemacht?
ich hab kein PurchHeader.Modify(true) in der CU415 o_O
was mir im onRUn auffällt, ist das dort mehrere MODIFY(TRUE) gemacht werden, aber worauf denn? ich seh da kein "with" oder bin ich blind?!?
11. Juli 2013 16:56
Hast du den aktuellen Update- Rollup 3 eingespielt?
Gruß, Fiddi
11. Juli 2013 16:59
sweikelt hat geschrieben:was mir im onRUn auffällt, ist das dort mehrere MODIFY(TRUE) gemacht werden, aber worauf denn? ich seh da kein "with" oder bin ich blind?!?
Der Record (Rec) befindet sich in den Eigenschaften der Codeunit und steht als Parameter neben dem Namen des OnRun-Triggers.
11. Juli 2013 17:00
@natalie, ja, manchmal sollte man die augen aufmachen und nachdenken, bevor man schreibt - sorry für den unqualifizierten kommentar :'(
ich hab leider auch noch kein rollup 3 installiert
11. Juli 2013 17:11
Hallo,
das ist eine AT-Datenbank dafür gibt es keine Update Rollups
Der Fehler kommt an folgender Stelle:
- Code:
PurchLine.SetPurchHeader(Rec);
PurchLine.CalcVATAmountLines(0,Rec,PurchLine,TempVATAmountLine0);
PurchLine.CalcVATAmountLines(1,Rec,PurchLine,TempVATAmountLine1);
PurchLine.UpdateVATOnLines(0,Rec,PurchLine,TempVATAmountLine0);
PurchLine.UpdateVATOnLines(1,Rec,PurchLine,TempVATAmountLine1);
MODIFY(TRUE); <---
Gruß
Michael
Zuletzt geändert von MichaelK am 11. Juli 2013 17:25, insgesamt 1-mal geändert.
11. Juli 2013 17:12
MichaelK hat geschrieben:das ist eine AT-Datenbank dafür gibt es keine Update Rollups
Du kannst aber auch die W1-Version benutzen.
15. Juli 2013 09:06
Hallo,
in der Zwischenzeit konnte ich den Fehler finden.
Falls es an der folgenden Stelle in der Tabelle 39 zu einem Modify kommt, dann tritt der Fehler auf.
- Code:
UpdateInvoiceOnPurchOrder()
IF "Document Type" = "Document Type"::Order THEN BEGIN
GetPurchHeader;
IF ("Quantity Received" > 0) AND ("Quantity Invoiced" > 0) AND NOT PurchHeader.Invoice THEN BEGIN
PurchHeader.Invoice := TRUE;
PurchHeader.MODIFY;
END;
END;
Die Bedingung für ein Modify tritt dann zu, wenn eine andere Zeile geliefert und fakturiert wurde. Außerdem muss die Bestellung sich im offenen Status befinden.
Um die Fehlermeldung zu bekommen reicht es nicht aus die Bestellung freizugeben, da das Feld Invoice auf Yes nach der Fakturierung steht. Erst beim erneuten Liefern ohne zu fakturieren kommt es zu einer Fehlermeldung.
Hier muss Microsoft wahrscheinlich nachbessern.
Gruß
Michael
19. Juni 2014 14:58
Hallo,
gibt es hierzu eine Lösung?
Hotfix?
VG Mikka
19. Juni 2014 15:22
mikka hat geschrieben:gibt es hierzu eine Lösung?
Hotfix?
Wenn jemand es an Microsoft gemeldet hat, dann wahrscheinlich schon. Ich würde bei Bedarf das neueste Update Rollup testen und bei Erfolg den Code vergleichen.
Eine Quick-and-Dirty-Korrektur wäre (ohne es jetzt getestet zu haben), in der Funktion UpdateInvoiceOnPurchOrder das
GetPurchHeader; zu ersetzen durch
PurchHeader.GET("Document Type","Document No.");
19. Juni 2014 15:27
Danke für Deinen Beitrag,
wir haben das Problem an einer anderen Stelle.
Es wird ein Transferfields ausgeführt, wenn kein INSERT, dann MODIFY. Da der Timestamp im Hintergrund wohl mir kopiert wird, kommt es vermutlich zu diesem Fehler.
Ich werde meinen Kollegen es weiter reichen :)
19. Juni 2014 15:43
Hallo,
Ich würde den Aufruf der Funktion einfach mal auskommentieren. das sollte eigentlich nichts ausmachen, außer das die Stapel im Rollencenter dann u.U.
andere falsche Werte anzeigen
(man darf Invoice, Receive und Ship nicht für irgendwelche Auswertungen benutzen, die werden unmittelbar vor dem Buchen gesetzt, und sind nur temporär zu verwenden, außerdem widersprechen sich die Aussagen der Flags).
Ein weiteres fatales Problem könnte auch auftreten, wenn die Funktion SetPurchHeader mit einem temporären PurchHeader in der tabelle 39 gesetzt wurde, dann dürfte die Funktion hier noch mehr Unsinn verursachen.
Wahrscheinlich trifft hier mal die wichtige Programmierregel "Fehler beseitigt man durch weglassen" zu.
Gruß,Fiddi
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.