Fehler mal reproduzierbar, mal nicht - Zufall oder zup?
15. Juni 2007 12:22
Ich habe zum wiederholten Mal folgenden Fall:
Kunde meldet Fehler, den ich auf meiner Entwicklungsdatenbank (mit Testdaten) nicht nachstellen kann. Ich ziehe mir daraufhin seine Echtdaten auf eine separate lokale Datenbank. Diese kopiere ich mir sicherheitshalber - habe also nun zweimal exakt die gleiche Datenbank mit den Original-Kundendaten.
Mir gelingt es, das seltsame Verhalten nachzustellen. Aber nur beim 1. Versuch. Ab dann lässt sich der Fehler nicht mehr repproduzieren.
Ich greife nun auf meine gesicherte Datenbank zurück und müsste nun wieder den Fehler reproduzieren können - aber nix da!
Wie kann das sein? Inwiefern spielt vielleicht die zup-Datei dabei eine Rolle? Oder habt ihr eine ganz andere Erklärung?
Kunde meldet Fehler, den ich auf meiner Entwicklungsdatenbank (mit Testdaten) nicht nachstellen kann. Ich ziehe mir daraufhin seine Echtdaten auf eine separate lokale Datenbank. Diese kopiere ich mir sicherheitshalber - habe also nun zweimal exakt die gleiche Datenbank mit den Original-Kundendaten.
Mir gelingt es, das seltsame Verhalten nachzustellen. Aber nur beim 1. Versuch. Ab dann lässt sich der Fehler nicht mehr repproduzieren.
Ich greife nun auf meine gesicherte Datenbank zurück und müsste nun wieder den Fehler reproduzieren können - aber nix da!
Wie kann das sein? Inwiefern spielt vielleicht die zup-Datei dabei eine Rolle? Oder habt ihr eine ganz andere Erklärung?
15. Juni 2007 13:22
Hallo Kollegin 
ZUP-Datei würde ich jetzt gefühlsmäßig ausschließen (mag mich aber irren). Kannst du den Fehler etwas genauer beschreiben?
Gruß Jan
ZUP-Datei würde ich jetzt gefühlsmäßig ausschließen (mag mich aber irren). Kannst du den Fehler etwas genauer beschreiben?
Gruß Jan
15. Juni 2007 13:38
lol Ja wenn das mal so einfach zu beschreiben wäre.
Aktuell ist es der Fall:
Kunde hat manuell einen Umlagerungsauftrag erstellt: von einem Logistiklager auf ein "normales Lager". Hierin werden zwei Seriennummer-verwaltete Artikel umgelagert (also 2 Zeilen).
Hiefür musste man zuerst einen Warenausgang erstellen.
Danach muss man eine Kommissionierung erstellen. Hier die Seriennummer zuweisen und Bewegungsmenge definieren. Registrieren. Nun gibt es für diese beiden Artikel und diesem Umlagerungsauftrag entsprechende Einträge in der Tabelle Reserve Entry (Ursprungslager, Menge negativ).
Zurück zum Warenausgang.
Sobald in der Artikelverfolgung die Bewegungsmenge gesetzt wird, kommen weitere Reservierungsposten fürs Ziellager mit pos. Menge hinzu.
Den Warenausgang nun durchbuchen. In diesem Augenblick verschwinden die negativen Reservierungsposten.
Und fehlerhafterweise auch alle positiven Reservierungsposten für einen der beiden Artikel. Auswirkungen:
1) In der entspr. Umlagerungsauftragszeile gibt für "Wareneingang" keine Artikelverfolgung
2) Der Umlagerungsauftrag kann daher nicht gebucht werden, da die Artikelverfolgung fehlt. Sie lässt sich aber auch nciht nachtragen.
Ich habe dieselben Artikel unter neuen Seriennummern neu eingelagert und einen neuen Umlagerungsauftrag erstellt (Konstellation exakt wie oben). Auch diesmal war eine der beiden Umlagerungszeilen vorm Buchen des Wareneingangs fehlerhaft (diesmal aber die andere Zeile!).
Und ab den weiteren Versuchen funktionieren alle Umlagerungsaufträge tadellos.
Seitdem gelingt es mir nicht mehr, den Fehler nachzustellen. Wie bitte soll ich denn jetzt rausfinden, warum um Gottes Willen mir Navision einfach so Reservierungsosten gelöscht hat? Und: Wie kann der Vorgang fortgesetzt oder storniert werden, wenn der Warenausgang schon komplett (und richtig) gebucht worden ist und sich die Artikel damit auf einem Transitlager befinden?
Verstehst du jetzt, warum ich euch nicht mit diesen Einzelheiten konfrontieren wollte?
PS: Natürlich ist es mir NICHT gelungen, dieses Phänomen auf einer CRONUS-DB nachzustellen. Wäre ja auch zu einfach!
Aktuell ist es der Fall:
Kunde hat manuell einen Umlagerungsauftrag erstellt: von einem Logistiklager auf ein "normales Lager". Hierin werden zwei Seriennummer-verwaltete Artikel umgelagert (also 2 Zeilen).
Hiefür musste man zuerst einen Warenausgang erstellen.
Danach muss man eine Kommissionierung erstellen. Hier die Seriennummer zuweisen und Bewegungsmenge definieren. Registrieren. Nun gibt es für diese beiden Artikel und diesem Umlagerungsauftrag entsprechende Einträge in der Tabelle Reserve Entry (Ursprungslager, Menge negativ).
Zurück zum Warenausgang.
Sobald in der Artikelverfolgung die Bewegungsmenge gesetzt wird, kommen weitere Reservierungsposten fürs Ziellager mit pos. Menge hinzu.
Den Warenausgang nun durchbuchen. In diesem Augenblick verschwinden die negativen Reservierungsposten.
Und fehlerhafterweise auch alle positiven Reservierungsposten für einen der beiden Artikel. Auswirkungen:
1) In der entspr. Umlagerungsauftragszeile gibt für "Wareneingang" keine Artikelverfolgung
2) Der Umlagerungsauftrag kann daher nicht gebucht werden, da die Artikelverfolgung fehlt. Sie lässt sich aber auch nciht nachtragen.
Ich habe dieselben Artikel unter neuen Seriennummern neu eingelagert und einen neuen Umlagerungsauftrag erstellt (Konstellation exakt wie oben). Auch diesmal war eine der beiden Umlagerungszeilen vorm Buchen des Wareneingangs fehlerhaft (diesmal aber die andere Zeile!).
Und ab den weiteren Versuchen funktionieren alle Umlagerungsaufträge tadellos.
Seitdem gelingt es mir nicht mehr, den Fehler nachzustellen. Wie bitte soll ich denn jetzt rausfinden, warum um Gottes Willen mir Navision einfach so Reservierungsosten gelöscht hat? Und: Wie kann der Vorgang fortgesetzt oder storniert werden, wenn der Warenausgang schon komplett (und richtig) gebucht worden ist und sich die Artikel damit auf einem Transitlager befinden?
Verstehst du jetzt, warum ich euch nicht mit diesen Einzelheiten konfrontieren wollte?
PS: Natürlich ist es mir NICHT gelungen, dieses Phänomen auf einer CRONUS-DB nachzustellen. Wäre ja auch zu einfach!
15. Juni 2007 14:05
Hey, jetzt ist mir das Wunder auf einer CRONUS-DB SP2 geglückt (SP3 ja nicht) - ob mir das noch ein 2. Mal gelingt???
15. Juni 2007 14:57
So, es ist ein Standardfehler.
Hat trotzdem jemand schon einmal Bekanntschaft gemacht mit dem im Startbeitrag geschilderten Phänomen? Wie wird der ausgelöst?
Hat trotzdem jemand schon einmal Bekanntschaft gemacht mit dem im Startbeitrag geschilderten Phänomen? Wie wird der ausgelöst?
Funktion in Umlagerungsauftrag
24. Juni 2007 15:31
Hallo Natalie,
laut unserem NSC (wie nennt man die heute?) ist es ein Standardfehler und für die Version 4.00 SP1 seit februar 06 in der Bearbeitung bei Microsoft.
Wir haben jetzt eine Funktion im Umlagerungsauftrag:
SN Resp.Posten nachtragen:
OnPush:
MaTransferFunc.CorrectSN4TransferLines("No.")
...
Hilft das weiter?
laut unserem NSC (wie nennt man die heute?) ist es ein Standardfehler und für die Version 4.00 SP1 seit februar 06 in der Bearbeitung bei Microsoft.
Wir haben jetzt eine Funktion im Umlagerungsauftrag:
SN Resp.Posten nachtragen:
OnPush:
MaTransferFunc.CorrectSN4TransferLines("No.")
...
Hilft das weiter?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: Funktion in Umlagerungsauftrag
24. Juni 2007 17:38
Erst einmal danke!
Gute Frage ...
Nicht ganz, der Fehler wurde im SP3 behoben und kann auch für ältere Versionen nachgezogen werden, was ich auch schon längst getan habe (jedenfalls für SP2).
Die bereits zerstückelten Umlagerungsauftrages habe ich mittels eines Reports wieder gerade biegen können - geht ja Gott sei Dank.
Hatte ja eigentlich schon weiter oben angedeutet, dass sich das Problem längst erledigt hat
Aber mein Thema dreht sich ja eigentlich um eine scheinbar willkürliche Reproduzierbarkeit von Fehlern in Navision.
bräu hat geschrieben:laut unserem NSC (wie nennt man die heute?)
Gute Frage ...
ist es ein Standardfehler und für die Version 4.00 SP1 seit februar 06 in der Bearbeitung bei Microsoft.
Nicht ganz, der Fehler wurde im SP3 behoben und kann auch für ältere Versionen nachgezogen werden, was ich auch schon längst getan habe (jedenfalls für SP2).
Die bereits zerstückelten Umlagerungsauftrages habe ich mittels eines Reports wieder gerade biegen können - geht ja Gott sei Dank.
Hilft das weiter?
Hatte ja eigentlich schon weiter oben angedeutet, dass sich das Problem längst erledigt hat
Aber mein Thema dreht sich ja eigentlich um eine scheinbar willkürliche Reproduzierbarkeit von Fehlern in Navision.
Re: Funktion in Umlagerungsauftrag
25. Juni 2007 08:23
bräu hat geschrieben:laut unserem NSC (wie nennt man die heute?)
Heute spricht man von MBSP (Microsoft Business Solution Parter). So wird das jedenfalls hier im Forum immer wieder getan.
25. Juni 2007 08:41
Ja, aber Business Solutions heißt doch jetzt Dynamics ... Ist das noch "zeitgemäß"?
25. Juni 2007 09:06
Das Produkt heißt Dynamics aber die Abteilung soweit ich weiß immer noch MBS
25. Juni 2007 09:30
Versteh das mal einer *g*
Ich glaube, ich bleibe bei meinem altbekannten (weil ehem. Arbeitgeber) "Microsoft-Partner" ...
Ich glaube, ich bleibe bei meinem altbekannten (weil ehem. Arbeitgeber) "Microsoft-Partner" ...
An Zufall glaube ich nicht - an die ZUP eigentlich auf nicht
25. Juni 2007 17:04
Hi Natalie,
in der Zup-Datei sind doch "nur" die Spalteneinstellungen, Filter und so gespeichert. Wenn also der Code mit "GETFILTER" oder so gesteuert wird - könnte es zu so "kranken" Situationen kommen. Das traut sich aber keiner - oder doch?
Du schreibst: "der Fehler wurde im SP3 behoben und kann auch für ältere Versionen nachgezogen werden". Den habe ich leider noch nicht.
Kann man das dann nicht genauer herausbekommen, wenn man den Code vergleicht?
Gruß
Bräu
in der Zup-Datei sind doch "nur" die Spalteneinstellungen, Filter und so gespeichert. Wenn also der Code mit "GETFILTER" oder so gesteuert wird - könnte es zu so "kranken" Situationen kommen. Das traut sich aber keiner - oder doch?
Du schreibst: "der Fehler wurde im SP3 behoben und kann auch für ältere Versionen nachgezogen werden". Den habe ich leider noch nicht.
Kann man das dann nicht genauer herausbekommen, wenn man den Code vergleicht?
Gruß
Bräu
25. Juni 2007 17:24
Michael Schumacher hat geschrieben:Das Produkt heißt Dynamics aber die Abteilung soweit ich weiß immer noch MBS
Auf der offiziellen MS-Seite (Dynamics Partner) spricht man von:
Microsoft Dynamics NAV - Partner (nach MS Terminologie dann wohl ein MDNP
)
Microsoft Dynamics NAV ist ist auch die Produktbezeichnung
Re: An Zufall glaube ich nicht - an die ZUP eigentlich auf n
25. Juni 2007 18:39
bräu hat geschrieben:Du schreibst: "der Fehler wurde im SP3 behoben und kann auch für ältere Versionen nachgezogen werden". Den habe ich leider noch nicht.
Kann man das dann nicht genauer herausbekommen, wenn man den Code vergleicht?
Ähm, möchtest du jetzt einfach nur wissen, wie man den Standardfehler korrigiert oder worum geht es dir ...?
SP3 kommt in ein paar Wochen auch bis zu mir.
26. Juni 2007 06:18
Mir geht es darum, dass der Fehler doch jetzt nachvollziebar sein muss - nachdem eine korrektur von MS kam.
Dann muss es doch auch möglich sein herauszubekommen, warum der Fehler mal reproduzierbar war und mal nicht.
Mein schlimmstes Erlebnis in der Version 2.01 war, dass die Berechnung in der Verkaufszeile nicht gestimmt haben. Das lag an einem Commit bei der Verfügbarkeitsmeldung und war immer davon abhängig ob man die meldung schließt oder mit Abrechen weiterarbeitet.
Das war aber auch schlecht programmiert.
Dann muss es doch auch möglich sein herauszubekommen, warum der Fehler mal reproduzierbar war und mal nicht.
Mein schlimmstes Erlebnis in der Version 2.01 war, dass die Berechnung in der Verkaufszeile nicht gestimmt haben. Das lag an einem Commit bei der Verfügbarkeitsmeldung und war immer davon abhängig ob man die meldung schließt oder mit Abrechen weiterarbeitet.
Das war aber auch schlecht programmiert.
Re: SP3 kommt in ein paar Wochen auch bis zu mir.
26. Juni 2007 08:39
bräu hat geschrieben:Mir geht es darum, dass der Fehler doch jetzt nachvollziebar sein muss - nachdem eine korrektur von MS kam.
Dann muss es doch auch möglich sein herauszubekommen, warum der Fehler mal reproduzierbar war und mal nicht.
Ach so... Ich habe ehrlich gesagt keine Zeit gehabt, nachzuvollziehen, was und wie genau der falsche Code angerichtet hat. Hauptsache, jetzt geht es richtig.
Und wie gesagt, ich habe Ähnliches schon in einem ganz anderen Kontext erlebt - also gar nicht nachvollziehbar. Was damals der Fehler war (er tritt heute nicht mehr auf), kann ich bei bestem Willen nicht mehr ausmachen.
Das lag an einem Commit bei der Verfügbarkeitsmeldung und war immer davon abhängig ob man die meldung schließt oder mit Abrechen weiterarbeitet.
Guter Hinweis - da muss man erst einmal drauf kommen ...
2. Juli 2007 09:42
4. Juli 2007 06:01
Hi,
in meiner Zeit im Support und in Projekten haben wir aus solchen Dingen immer den Schluß gezogen "...Und es lebt doch...".
in meiner Zeit im Support und in Projekten haben wir aus solchen Dingen immer den Schluß gezogen "...Und es lebt doch...".
Re: Fehler mal reproduzierbar, mal nicht - Zufall oder zup?
3. November 2009 17:54
Hallo zusammen, ich weiß der Beitrag ist zwar alt,
aber unser Kunde hat ein ähnliches Problem wie anfangs von Natalie beschrieben.
Unterschied: NAV51 und statt Seriennummern, mit Chargennummern.
Es ist zum verrückt werden.
Bei Warenausgang ist noch alles in Orndung,
schaut man dann in die Artikelverfolgungszeilen des WE,
fehlt ein Teil der im WA def. Menge und lässt sich auch nicht mehr eintragen.
Selbst bei ganz einfachen ULA passiert es.
Wenn wir in einer Testumgebung mit den Kundendaten testen, ist der Fehler natürlich nicht reproduzierbar.
Zusätzlich negativer Beigeschmack: die Menge bleibt natürlich im Transitlager stecken
Kennt jemand das Problem?
Gruß
Gollum
aber unser Kunde hat ein ähnliches Problem wie anfangs von Natalie beschrieben.
Unterschied: NAV51 und statt Seriennummern, mit Chargennummern.
Es ist zum verrückt werden.
Bei Warenausgang ist noch alles in Orndung,
schaut man dann in die Artikelverfolgungszeilen des WE,
fehlt ein Teil der im WA def. Menge und lässt sich auch nicht mehr eintragen.
Selbst bei ganz einfachen ULA passiert es.
Wenn wir in einer Testumgebung mit den Kundendaten testen, ist der Fehler natürlich nicht reproduzierbar.
Zusätzlich negativer Beigeschmack: die Menge bleibt natürlich im Transitlager stecken
Kennt jemand das Problem?
Gruß
Gollum