"Menke akt. Rechnung" in EK-Bestellung stehen geblieben

Hallo zusammen,

ich habe ein absolut merkwürdiges Phänomen bei einem bestimmten Kreditor und kann es mir nun wirklich nicht mehr erklären.
Wir haben eine Einkaufsbestellung (ca. 30 Zeilen) bei einem relativ neuen Kreditor gemacht. Die Lieferung wurde ganz normal über den Wareneingang, etc. verbucht und wird auch richtig als "Bereits gelief. Menge" angezeigt. Nun hat unser Einkauf eine EK-Rechnung erstellt und über "Wareneingangszeilen holen" (Codeunit "Purch.-Get Receipt") haben Sie die Wareneingangszeilen in die Rechnung geholt und gebucht. Das hat auch wunderbar funktioniert und die RG wurde OHNE Fehlermeldung durchgebucht.
Nun ist aber das Problem, dass ca. bei der Hälfte der Zeilen immernoch "Menge akt. Rechnung" gesetzt ist. Bei der anderen Hälfte wurde "Bereits berech. Menge" korrekt gesetzt. Nun ist das Problem, dass ich das einfach nicht nachvollziehen kann und zusätzlich nicht 100% sicher bin ob auch alle Posten, etc. richtig gebucht wurden.

In all meinen Tests hat es richtig funktioniert und der Einkauf schwört darauf, dass die nix falsch gemacht haben. Für mich persönlich klingt das auch dannach, dass irgendwo ein COMMIT drin steckt und ein Fehler aufgetaucht ist, aber selbst das konnte ich nicht finden... die Codeunit zum holen ist 100% standard und die Buchungsroutine ist in den relevanten Teilen ebenfalls nicht verändert.

Ich habe absolut keine Idee, wie das passieren konnte... hat das einer von Euch schonmal erlebt?

Vielen Dank für jeglichen Input...
Christoph

hm, was mir jetzt so spontan einfallen würde: gab es evtl mehrere Teillieferungen, und es wurde per "Wareneingangszeilen holen" nur eine davon gezogen?

Wenn der Einkauf drauf "schwört" alles richtig gemacht zu haben, schau mal in die Tabelle 123 "Einkaufsrechnungszeile". Wenn es sauber gebucht worden ist, müssten die Zeilen (alle) ja mir Menge und Wert da auftauchen (was ich nicht glaube, ich denke das nur die Zeilen auftauchen, die eine "Menge fakturiert" haben).

Ich würde nach dem Ausschlußverfahren das Senario nachstellen.

Z.B. Wenn keine Rechnungszeilen gefunden wurden, teste an einer DB-Kopie, ob du die Zeilen Buchen kannst.
Wenn, ja hat der Einkauf diese nicht mitgebucht (aus welchen Gründen auch immer -->Filter gesetzt, nicht alle Zeilen ausgefüllt usw.)

Ich hege an Navision ein recht hohes Vertrauen, das die Buchungen "sauber" klappen. In ca. > 99 % der Fälle sind es Anwender- oder Einrichtungsfehler.

Ist das Problem zum ersten mal aufgetreten?
Wenn die Bestellung korrekt gebucht wurde und beim zweiten Buchungsdurchgang die anderen Zeilen auch "sauber" gebucht wurden, wurde ich das Problem "ad Akta" legen (und mir keinen "Kopf" machen).

Das habe ich ganz vergessen mit einzugeben. Hab schon extra einen DB-Klon erzeugt indem ich testen wollte ob ich die anderen Zeilen einfach über die Bestellung fakturieren kann, ABER genau das ist das Problem. Er sagt mir "Die Zeile xyz wurde bereits fakturiert!".

Ich bin echt absolut ratlos... unsere FiBu prüft gerade (da Monatsabschluss ist) ob zumindest die Sachkonten richtig bebucht wurden und ich spiele wieder aufs neue ein Szenario im Testsystem durch in der Hoffnung durchs Debuggen irgendeinen Hinweis zu bekommen. Langsam bin ich echt am verzweifeln und bisher habe ich NAV auch immer zu (fast) 100% in Sachen Buchungen vertraut... das ist in meiner ganzen NAV Zeit, dass erste mal, dass so ein Fall auftritt! :(

Das habe ich ganz vergessen mit einzugeben. Hab schon extra einen DB-Klon erzeugt indem ich testen wollte ob ich die anderen Zeilen einfach über die Bestellung fakturieren kann, ABER genau das ist das Problem. Er sagt mir "Die Zeile xyz wurde bereits fakturiert!".

Wie man sich das vorstellen?
Es gibt Zeilen, die eine "Menge fakturiert" = 0 haben, sich aber nicht fakturieren lassen?

Hast du die Zeile angeschaut, gibt es Auffälligkeiten?
(entweder das Feld "Zeilennummer" im Design einfügen, oder mit dem Zoom die Zeile ausfindig machen)

Vergleiche Zeile für Zeile die Felder:
"Menge"
"Menge akt. Lieferung"
"Bereits gelief. Menge"
"Menge akt. Rechnung"
"Bereits berch. Menge"

Ich nehm mal eine Beispielzeile die sich nicht fakturieren lässt, wegen eben dieser Fehlermeldung.

Tabelle: Purchase Line
Quantity = 3960
Qty. to Invoice = 3960
Qty. Rcd. Not Invoiced = 3960

Tabelle: Purch. Rcpt. Line
Quantity = 3960
Quantity Invoiced = 3960

Das sind Inkonsistenzen. Das hatte ich auch schon mal in einer verbastelten Datenbank. Die entstehen aber normalerwiese nur durch COMMITs in der Buchungsroutine an Stellen, wo sie nichts zu suchen haben. Wenn die Posten der gebuchten Rechnung korrekt sind (über Navigate prüfen),hilft da nur manuelles Nachbearbeiten der ungebuchten Zeile über Reports ohne die Validate-Trigger anzusprechen. Das verlangt einiges an Erfahrung, was wie wo stehen sollte. Sonst lieber Finger weg

Ich nehm mal eine Beispielzeile die sich nicht fakturieren lässt, wegen eben dieser Fehlermeldung.

Tabelle: Purchase Line
Quantity = 3960
Qty. to Invoice = 3960
Qty. Rcd. Not Invoiced = 3960

Tabelle: Purch. Rcpt. Line
Quantity = 3960
Quantity Invoiced = 3960

Wie sieht die Zeile in der Tabelle 123 "Purch. Inv. Line" aus, steht hier auch eine fakturierte Menge?

Ich denke ich kann dir nicht weiterhelfen.
Wenn das Problem wg. dem Monatsschluß schnell geklärt werden soll, solltest du dich mit Deinem Navision Partner in Verbindung setzten.
(So aus der Ferne kann ich da nichts machen!)

**Edit by Mikka**
Kowa war schneller
Also Nav Partner kontaktieren

**Edit 2**
Was mich nur wundert, du schreibst die Codeunits sind 100% Original!

Irgendwo muss es einen Abbruch gegeben haben (nicht unbedingt beim aktuellen Vorgang, das kann auch schon eine Weile zurück liegen), sonst wäre die Datenbank nicht in diesem Zustand. Durch AddOns und Branchenlösungen befinden sich häufig zusätzliche COMMITs in der Buchungsroutine, da sonst dort sonst das altbekannte Riesenfenster auftaucht, das einzeln auflistet, was innerhalb von Buchungsroutinen nicht erlaubt ist, z.B. Forms modal aufzurufen. Hier ist dann der letzte Satz "Verwenden Sie ein COMMIT, um ihre Änderungen abzuschließen". Wenn man dann diesem Ratschlag folgt, ist das Kind in den Brunnen gefallen. Besser wäre es da natürlich, den Buchungsprozess anders zu gestalten, aber das ist auch nicht immer machbar.

Der Fehler kann aber durchaus nicht im Buchungscode liegen, sondern auch in Inkonsistenzen liegen, die schon länger existieren, die aber erst jetzt angesprochen wurden. Dann es zu z.B. dem anderen bekannten Fehler " Es ist nicht genügend Stackpeicher vorhanden..." kommen, der unter normalen Bedingungen niemals auftauchen würde. So einen Fall hatte ich z.B. mit falschen Mengen in den Ausgleichsposten, siehe hier.

Die einzige absolute Inkonsistenzsperre im System besteht auf Sachpostenebene. Es ist nicht möglich, eine einseitige Sollbuchung zu verbuchen, ohne den gleichen Betrag auch ins Haben zu buchen. Dann bricht der Vorgang mit einer INCONSISTENT-Meldung ab. Das kommt normalerweise in der Praxis nicht vor (beim Entwickeln schon einmal ), aber da die Sachpostenbuchungen normalerweise am Ende des Buchungsvorgangs stehen, wären bei einer Routine mit COMMITs auch hier sofort Inkonsistenzen in anderen Tabellen vorhanden.