Fehlermeldung: Da Datum ist Ungültig
21. April 2008 18:21
Hallo,
kann mir hier jemand weiterhelfen.
Seit neuesten kommt beim Versuch einen Storno eines Sachkonten- oder Bankbuchung durchzuführen, foglende Fehlermeldung:
Das Datum ist ungültig.
Bis vor ca. 2 Wochen kannte ich diese Fehlermeldung noch nicht. Es müsste irgendwie mit den Einstellungen zusammenhängen?
Wer weiß, wie dies behoben werden kann?
kann mir hier jemand weiterhelfen.
Seit neuesten kommt beim Versuch einen Storno eines Sachkonten- oder Bankbuchung durchzuführen, foglende Fehlermeldung:
Das Datum ist ungültig.
Bis vor ca. 2 Wochen kannte ich diese Fehlermeldung noch nicht. Es müsste irgendwie mit den Einstellungen zusammenhängen?
Wer weiß, wie dies behoben werden kann?
21. April 2008 22:34
Hi! Schalte mal den Debugger ein (Extras - Debugger - Active). Die Funktion Breakpoint auf Triggern (Extras - Debugger - ...) muss ausgeschaltet sein.
Dann führe dein Strono erneut durch. Sobald der Fehler kommt müsste der Debugger automatisch starten und er zeigt dir, wo der Fehler verursacht wird. Wäre gut, wenn du uns das sagen könntest.
Viele Grüße
Marc
Dann führe dein Strono erneut durch. Sobald der Fehler kommt müsste der Debugger automatisch starten und er zeigt dir, wo der Fehler verursacht wird. Wäre gut, wenn du uns das sagen könntest.
Viele Grüße
Marc
Zuletzt geändert von Marc Teuber am 9. Mai 2008 08:14, insgesamt 1-mal geändert.
22. April 2008 16:27
Hi Marc,
Codeunit 12 Gen. Jnl.-Post Line\InsertGLEntry(CalcAddCurrResiduals)
Codeunit 12 Gen. Jnl.-Post Line\Reverse(ReversalEntry,ReversalEntry2)
Form 179 Posten stornieren\Post(PrintRegister)
Form 179 Posten stornieren\<Control46> - OnPush()
Table 179 Stornoposten\ReverseTransaction(TransactionNo)
Form 372 Bankposten\<Control37> - OnPush()
Hilft dies weiter?
Was ich sehr komisch finde: Aus einer alten Datensicherung habe ich die Codeunit 12 neu implementiert - ohne Problemlösung? Komisch, komisch.
Gruß
Andreas
Codeunit 12 Gen. Jnl.-Post Line\InsertGLEntry(CalcAddCurrResiduals)
Codeunit 12 Gen. Jnl.-Post Line\Reverse(ReversalEntry,ReversalEntry2)
Form 179 Posten stornieren\Post(PrintRegister)
Form 179 Posten stornieren\<Control46> - OnPush()
Table 179 Stornoposten\ReverseTransaction(TransactionNo)
Form 372 Bankposten\<Control37> - OnPush()
Hilft dies weiter?
Was ich sehr komisch finde: Aus einer alten Datensicherung habe ich die Codeunit 12 neu implementiert - ohne Problemlösung? Komisch, komisch.
Gruß
Andreas
23. April 2008 11:04
Hallo,
evt. in Fibu/Einrichtung den Zeitraum geändert, in dem Buchungen zugelassen sind ?
Ist aber nur ein Tip ins Blaue....
evt. in Fibu/Einrichtung den Zeitraum geändert, in dem Buchungen zugelassen sind ?
Ist aber nur ein Tip ins Blaue....
23. April 2008 18:25
ne auch nicht der fall
was mich sehr stutzig macht.
ich habe sämtliche objekte (Forms, Reports, etc.) von der Datensicherung in die neue Datenbank kopiert.
Hat gar nichts gebracht, aber komischerweise gibt es bei der Datensicherung keine Probleme.
was mich sehr stutzig macht.
ich habe sämtliche objekte (Forms, Reports, etc.) von der Datensicherung in die neue Datenbank kopiert.
Hat gar nichts gebracht, aber komischerweise gibt es bei der Datensicherung keine Probleme.
23. April 2008 20:59
Jetzt ist mir heute noch was komisches aufgefallen:
Über Finanzbuchhaltung Journale kann ich die Buchungen stornieren bzw. das jeweilige Journal. Kommt auch in der Fibu richtig an.
Jedoch: Bin ich in einem Bankkonto oder direkt in den Sachkonten, kommt die genannte Fehlermeldung.
Über umwegen funktioniert der Storno noch.
Über Finanzbuchhaltung Journale kann ich die Buchungen stornieren bzw. das jeweilige Journal. Kommt auch in der Fibu richtig an.
Jedoch: Bin ich in einem Bankkonto oder direkt in den Sachkonten, kommt die genannte Fehlermeldung.
Über umwegen funktioniert der Storno noch.
9. Mai 2008 08:08
Ist in der Benutzereinrichtung vielleicht das Buchungsdatum eingeschränkt worden? Also nicht generell in der FiBu-Einrichtung sondern per Benutzer?
Ich denke der Ansatz Buchungsdatum ist erstmal richtig.
Was vielleicht noch interessanter wäre, wäre ein Screenshot aus dem Debugger. Also nochmals Debuggen und dann mal den Zoom schicken, dann haste mal die Zeile an der es hängt und eventuell kann man schon daraus ersehen wo Nav "weint".
So eine Ferndiagnose ist aber nicht leicht...
Die Stornos... waren die alle im selben Monat?
Ich denke der Ansatz Buchungsdatum ist erstmal richtig.
Was vielleicht noch interessanter wäre, wäre ein Screenshot aus dem Debugger. Also nochmals Debuggen und dann mal den Zoom schicken, dann haste mal die Zeile an der es hängt und eventuell kann man schon daraus ersehen wo Nav "weint".
So eine Ferndiagnose ist aber nicht leicht...
Die Stornos... waren die alle im selben Monat?
9. Mai 2008 11:00
arbeitest Du unter SQL oder Native?
Das Datum ist ungültig
4. Juni 2008 09:23
Ich hatte heute die gleiche Fehlermeldung.
Es stellte sich heraus, dass in einem Datumsfeld aus irgendeinem Grund ein fehlerhafter Wert stand. Versuche daher mittels einer Routine zunächst den fehlerhaften Datensatz zu ermitteln. Eine REPEAT Schleife mit FORMAT(rec) sollte beim fehlerhaften Satz mit der gleichen Fehlermeldung aussteigen. Danach kann man mittels FieldRef das fehlerhafte Feld ermitteln und dessen Inhalt korrigieren. Wahrscheinlich sind mehrere Datensätze betroffen.
Es stellte sich heraus, dass in einem Datumsfeld aus irgendeinem Grund ein fehlerhafter Wert stand. Versuche daher mittels einer Routine zunächst den fehlerhaften Datensatz zu ermitteln. Eine REPEAT Schleife mit FORMAT(rec) sollte beim fehlerhaften Satz mit der gleichen Fehlermeldung aussteigen. Danach kann man mittels FieldRef das fehlerhafte Feld ermitteln und dessen Inhalt korrigieren. Wahrscheinlich sind mehrere Datensätze betroffen.