Beleggenehmigung - Der Typ wird nicht unterstützt

Bei der Beleggenehmigung einer Einkaufsbestellung erhalten die Anwender sporadisch die Meldung "Der Typ wird nicht unterstützt".

Der Debugger bleibt in der Codeunit 1503 in der Funktion BackupRecord auf dem ERROR (2. Zeile) stehen, weil der übergebene Variant keine Record-Variable darstellt (sondern einen RecordRef).
Verfolge ich die Aufruf-Kette zurück, dann stelle ich folgendes fest:
1. Der Prozess beginnt mit einem Record zur Tabelle 38 Purchase Header.
2. Aus diesem Record wird durch den NAV-Workflow ein Variant, welcher von nun an weitergereicht wird.
3. Zwischendurch wird von diesem Variant (Typ Record) ein RecRef gezogen.
4. In der Funktion ExecuteQueuedEvents wird anstelle des Variant der gezogene RecRef weitergereicht
5. Der Variant (jetzt vom Typ RecordRef) entspricht nicht dem Typ Record und es wird der ERROR geworfen.

Ein Blick in den Programmcode unter BC14 CU06 zeigt, dass in der Funktion ExecuteQueuedEvents der Codeunit 1501 immer noch der RecRef weitergereicht wird und in der Funktion BackupRecord der Codeunit 1503 der übergebene Variant immer noch vom Typ Record sein muss.

Habe ich hier gerade einen Bug im NAV-Standard entdeckt?

Wurde dies in einem neueren CU bereits behoben, und wenn ja, wie?
Wurde die Funktion ExecuteQueuedEvents der CU1501 oder die Funktion BackupRecord der CU1503 geändert?

Screenshot.png

Screenshot.png

Kann es sein, dass die Lösung wirklich so nah liegt?

Screenshot.png

Zur Info: Es handelt sich um NAV2017 CU 05. Im Bereich des NAV-Standard-Workflow gibt es absolut keine Anpassungen, weder von uns, noch von Drittanbietern.

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

also ich habe mir jetzt mal BC17 angesehen - da ist es weiterhin noch so wie von dir beschrieben (jedenfalls die gemeldeten Codestellen)
Komisch ist natürlich, dass es nur sporadisch auftritt

Das es selbst in BC17 (also mehrere Jahre nach NAV2017) immer noch so im Programmcode steht ist kein Zeichen dafür, dass es deswegen richtig sein muss.
Ich hatte auch schon einen NAV-Standardfehler gefunden, den ich bis in eine 10 (in Worten: "zehn") Jahre ältere NAV-Version zurückverfolgen konnte.
Es gab halt bis dato noch keinen Anwender, der mit der für den Fehler verantwortlichen Datenkonstellation gearbeitet hatte.

Und so könnte es auch in unserem Fall sein, was das (mal mehr, mal weniger) sporadische Auftreten erklären könnte.
Es muss einfach eine spezielle Datenkonstellation vorliegen, damit innerhalb des NAV-Standard-Workflow ein bestimmter Pfad durchlaufen wird, der letztendlich in dem Fehler mündet.

Wenn man dann noch ein unterschiedliches Handling der Konstellation Variant = Record bzw. RecordRef in bestimmten Platform Builds unterstellt, wäre das eine weitere Erklärung, warum der Fehler bis heute unentdeckt blieb.
Sollte z. B. ein bestimmtes Build Variant.ISRECORD mit Variant.ISRECORDREF gleichstellen, dann würde die Funktion BackupRecord in der Codeunit 1503 keinen Error werfen.

ich wollte definitiv nicht sagen, dass es sich nicht um einen Fehler handelt - im Gegenteil bin ich der Meinung, dass du einen Fehler entdeckt hast - ggf. machst du in git mal ein Issue dazu auf

im Gegenteil bin ich der Meinung, dass du einen Fehler entdeckt hast - ggf. machst du in git mal ein Issue dazu auf

Ich habe meine Erkenntnisse - wie im ersten Beitrag zusammengefasst - an unser betreuendes Systemhaus geschickt.

Wenn einer von euch Zeit und Lust hat, darf er sich meinen ersten Beitrag nehmen und ihn an den Microsoft Support schicken.
Das wird uns zwar jetzt nicht direkt helfen, aber dann besteht wenigstens die Chance, dass es zeitnah in einem der nächsten CUs (auf welche Art und Weise auch immer) behoben wird.

Und wenn es dann behoben wurde, kann ja jemand von euch die offizielle Lösung hier posten.
Sollte ich in der Zwischenzeit von unserem Partner eine offizielle Lösung mitgeteilt bekommen, werde ich sie selbstverständlich hier bereitstellen.
So hätte die ganze Community etwas davon.

Unsere bisherigen Erfahrungen mit meiner oben vorgeschlagenen Lösung sind äußerst positiv.
Wir haben es zu Testzwecken über ein spezielles ServiceTier in die Live-Datenbank importiert und einen KeyUser eine Einkaufsbestellung zuerst auf einem anderen ServiceTier (auf dem noch der Original-NAV-Programmcode läuft) genehmigen lassen (was natürlich auf den Fehler lief), und anschließend auf dem ServiceTier, über das wir die Anpassung importiert hatten.
Siehe da: Die Beleggenehmigung lief fehlerfrei durch.

Kurz darauf meldeten die Key-User jedoch eine andere Fehlermeldung bei der Beleggenehmigung ("Beleggenehmigung - Variable NavVariant nicht initialisiert")
Wir befürchteten, dass wir es nur "verschlimmbessert" hatten, konnten jedoch herausfinden, dass die andere Fehlermeldung gar nichts mit unserer Anpassung zu tun haben konnte, weil der Fehler ausgelöst wurde, noch bevor NAV bis zu unserer Anpassung gekommen ist.

Nachdem wir auch das Problem "Beleggenehmigung - Variable NavVariant nicht initialisiert" mit einem einfachen Workaround gelöst hatten, kämpfen wir jetzt mit verwaisten Einträgen in der Tabelle 1550 "Restricted Record".
Möglicherweise sind diese verwaisten Einträge nur eine Altlast aus den Abbrüchen aufgrund des Fehlers in diesem bzw. dem Schwester-Thread, da die Eintragungen in diese Tabelle am Anfang eines Workflows vorgenommen werden und am Ende durch den Workflow wieder gelöscht werden.
Wenn der Workflow aufgrund eines unerwarteten Fehlers jedoch nicht bis zum Ende laufen kann, dann kommt er gar nicht bis zu der Aktion, welche den Eintrag wieder löscht.
Ein denkbarer Workaround könnte sein, dass wir die Einträge in der Tabelle 1550 nachts (wenn garantiert kein User mehr im System angemeldet ist und somit keine Workflows aktiv sein können) komplett löschen.