[Gelöst] NAV2013R2: Restbestellbetrag im Einkauf ist 0

Hallö, ich mal wieder!

Ich habe heute ein interessantes Verhalten entdeckt und frage mich, welchen Grund das Ganze hat.

Wenn ich eine Einkaufsbestellung anlege und dann mit die Details einer Zeile mit Strg-Alt-F1 anschaue, dann sehe ich im Feld "Restbestellbetrag" den korrekten Betrag. Gebe ich diese Bestellung nun frei und setze dann den Status wieder zurück, ist der Restbestellbetrag 0. Ein weiteres Freigeben ändert nichts an diesem Wert. In der CU415 habe ich dann tatsächlich in der Funktion Reopen folgende Zeile gesehen:

Code:

ZeroAmountInLines;

Diese setzt alle Amount-Werte auf 0 zurück. Der einzige Weg, den Restbestellbetrag jetzt wieder berechnen zu lassen, ist die Menge, den Preis oder ähnliche Felder der Zeile zu ändern. Wieso verhält sich NAV da so? Das wäre an und für sich ja gar nicht so problematisch, allerdings werden diese Bestellungen und der Restbestellbetrag ja auch für die Cashflowplanung genutzt, die dadurch natürlich völlig falsch wird. Ich tendiere derzeit dazu, den Aufruf einfach auszukommentieren. Was meint ihr?

Liebe Grüße
Patrik

EDIT: Lösung siehe hier.

Zuletzt geändert von Patrik am 31. März 2015 12:56, insgesamt 1-mal geändert.

Hmm, zu sagen es wäre das richtige Verhalten möchte ich mir nicht anmaßen. Aber es war schon immer so

Da der CF später dazu kam, denke ich, dass dort das Problem liegt. Für nicht gebuchte Belegzeilen kommt es zum Problem, sofern der Beleg nicht freigegeben ist bzw. zwischenzeitlich wieder geöffnet wurde.

Meine Empfehlung, unabhängig von einer Meldung an den Partner, der das wiederum an Microsoft meldet:

Report 840:

Code:

LOCAL GetPurchaseAmountForCFLine(PurchaseLine : Record "Purchase Line") : Decimal
PurchHeader.GET(PurchaseLine."Document Type", PurchaseLine."Document No.");
IF PurchHeader.Status <> PurchHeader.Status::Released THEN BEGIN
  PurchaseLine.SETRECFILTER();

  PurchaseLine.SetPurchHeader(PurchHeader);
  PurchaseLine.CalcVATAmountLines(0,PurchHeader,PurchaseLine,TempVATAmountLine0);
  PurchaseLine.CalcVATAmountLines(1,PurchHeader,PurchaseLine,TempVATAmountLine1);
  PurchaseLine.UpdateVATOnLines(0,PurchHeader,PurchaseLine,TempVATAmountLine0);
  PurchaseLine.UpdateVATOnLines(1,PurchHeader,PurchaseLine,TempVATAmountLine1);
END;

EXIT(PurchaseLine."Outstanding Amount (LCY)" + PurchaseLine."Amt. Rcd. Not Invoiced (LCY)");

Siehe dazu auch Codeunit 415 OnRun().
Gleiches natürlich sinngemäß für Verkauf und Service auch implementieren.

Huhu SilverX!

Danke für deine Antwort :).

Hmm, zu sagen es wäre das richtige Verhalten möchte ich mir nicht anmaßen. Aber es war schon immer so

Ein Kollege von mir würde sich jetzt zurücklehnen und mit einem Grinsen auf dem Gesicht sagen: "Ach so, das! Das hat historische Gründe..." ;)

Da der CF später dazu kam, denke ich, dass dort das Problem liegt. Für nicht gebuchte Belegzeilen kommt es zum Problem, sofern der Beleg nicht freigegeben ist bzw. zwischenzeitlich wieder geöffnet wurde.

Oha, das ist natürlich eher unschön. Allerdings werden die Restbestellbeträge leider auch nicht neu berechnet, wenn man die Bestellung nochmals freigibt. Die bleiben also bei 0. Da ist spätestens der Zeitpunkt erreicht, an dem ich den Sinn nicht erkenne =D. (Spätestens ;))

Meine Empfehlung, unabhängig von einer Meldung an den Partner, der das wiederum an Microsoft meldet

Gute Idee. Also beides. Mit dem Code-Schnippsel habe ich aber folgendes Problem: Nehmen wir an, es ist tatsächlich gewollt (also "richtiges" Verhalten ;)), dass das zurückgesetzt wird. Würde ich dann dadurch nicht eben genau jenes Verhalten durch das Auslösen der Cashflowplanung zerstören? Bei verteilten Personen/Rollen würden die entsprechenden Stellen ja noch nicht mal etwas davon mitbekommen.

Abgesehen davon scheint das Freigeben ja schon die Zeilen nicht zu aktualisieren, daher dürften die Calc/Update-Zeilen das alleine eigentlich auch nicht können =/.

Gleiches natürlich sinngemäß für Verkauf und Service auch implementieren.

Da passiert das interessanterweise nicht.

Liebe Grüße
Patrik

Ich meinte generell die Tatsache, dass bestimmte Werte erst zum Zeitpunkt der Freigabe kalkuliert werden. Nicht zwingend genau diese Konstellation und Funktion zum ausnullen.

Und stimmt, im Verkauf gibt es das gar nicht. Hmm, sehr merkwürdig. Ich würde tatsächlich den Partner und Microsoft kontaktieren.

Huhu!

Ein Mini-Update zu der ganzen Geschichte:

Wir haben herausgefunden, dass nicht nur der Restbestellbetrag, sondern auch der Betrag 0 ist. Darüber hinaus wird der Restbetrag der Zeile in der Funktion InitOutstandingAmount() in Tabelle 39 lediglich durch die Restmenge berechnet wird. Unserer Meinung nach ist das allerdings nicht ganz korrekt, da die Menge, die bereits geliefert aber noch nicht fakturiert wurde auch mitgenutzt werden müsste. Der relevante Teil der (schrecklich programmierten) Funktion sieht so aus:

Code:

 VALIDATE(
    "Outstanding Amount",
    ROUND(
   AmountInclVAT * "Outstanding Quantity" / Quantity,
      Currency."Amount Rounding Precision"));

Wir haben es umgeschrieben in:

Code:

  VALIDATE(
    "Outstanding Amount",
    ROUND(
      AmountInclVAT * (("Outstanding Quantity" + "Qty. Rcd. Not Invoiced") / Quantity),
      Currency."Amount Rounding Precision"));

Was meint ihr dazu? Wieso sollte die nicht fakturierte Menge nicht mitberücksichtigt werden?

Damit das bei der Cashflowplanung auch berücksichtigt wird, haben wir im Report 840 (Suggest Worksheet Lines) in "Purchase Line".OnAfterGetRecord() noch UpdateAmounts() aufgerufen. Bewusst erstmal ohne MODIFY, damit wir nichts vom Standard zerstören, falls die ganze Geschichte doch noch einen Sinn hat.

So haben wir das zumindest teilweise gelöst. Sobald ich von unserem Partner oder MS höre, werde ich das Thema noch mal aktualisieren und ggf. als gelöst taggen.

Liebe Grüße
Patrik

Darüber hinaus wird der Restbetrag der Zeile in der Funktion InitOutstandingAmount() in Tabelle 39 lediglich durch die Restmenge berechnet wird. Unserer Meinung nach ist das allerdings nicht ganz korrekt, da die Menge, die bereits geliefert aber noch nicht fakturiert wurde auch mitgenutzt werden müsste. Der relevante Teil der (schrecklich programmierten) Funktion sieht so aus:

Code:

 VALIDATE(
    "Outstanding Amount",
    ROUND(
   AmountInclVAT * "Outstanding Quantity" / Quantity,
      Currency."Amount Rounding Precision"));

Wir haben es umgeschrieben in:

Code:

  VALIDATE(
    "Outstanding Amount",
    ROUND(
      AmountInclVAT * (("Outstanding Quantity" + "Qty. Rcd. Not Invoiced") / Quantity),
      Currency."Amount Rounding Precision"));

Was meint ihr dazu? Wieso sollte die nicht fakturierte Menge nicht mitberücksichtigt werden?

Ich antworte mir da mal selbst: Das ist natürlich (rückblickend betrachtet) völliger Unsinn. Es gibt ja noch "Amt. Rcd. Not Invoiced" genau für diesen Fall. Die Cashflowplanung berücksichtigt die auch. Also: Die Änderung nicht machen, das führt zur Verdoppelung des Betrags.

Der Rest bleibt aber bislang bestehen.

Hallo zusammen!

Leider habe ich noch keine Meldung von Microsoft bekommen =/.

Könnte das vielleicht jemand mit einem Standard-NAV nachbauen? Ich frage mich, ob das wirklich Teil des Standards ist, oder ob sich der Fehler durch eine Partneranpassung reingeschlichen hat. Nach folgenden Schritten wird der Restbestellbetrag und auch der Betrag 0:

1. Einkaufsbestellung mit Zeilen anlegen
2. Einkaufsbestellung freigeben
3. Betrag und Restbetrag (Am besten mit STRG-ALT-F1 auf der Zeile oder in der Tabelle nachschauen) der Zeile ist normal
4. Einkaufsbestellung zurücksetzen
5. Betrag und Restbetrag sollten jetzt 0 sein (Soweit normal, habe ich gehört)
6. Einkaufsbestellung wieder freigeben
7. Betrag und Restbetrag ist bei mir jetzt noch immer 0

Vielen Dank im Voraus!

Cheers
Patrik

Hallo zusammen!

Leider habe ich noch keine Meldung von Microsoft bekommen =/.

Könnte das vielleicht jemand mit einem Standard-NAV nachbauen? Ich frage mich, ob das wirklich Teil des Standards ist, oder ob sich der Fehler durch eine Partneranpassung reingeschlichen hat. Nach folgenden Schritten wird der Restbestellbetrag und auch der Betrag 0:

1. Einkaufsbestellung mit Zeilen anlegen
2. Einkaufsbestellung freigeben
3. Betrag und Restbetrag (Am besten mit STRG-ALT-F1 auf der Zeile oder in der Tabelle nachschauen) der Zeile ist normal
4. Einkaufsbestellung zurücksetzen
5. Betrag und Restbetrag sollten jetzt 0 sein (Soweit normal, habe ich gehört)
6. Einkaufsbestellung wieder freigeben
7. Betrag und Restbetrag ist bei mir jetzt noch immer 0

Vielen Dank im Voraus!

Cheers
Patrik

Hi,
Ich habs anhand des Cronis AG Mandanten probiert (Demo Daten/Mandant von MS im NAV) und konnte kein zurücksetzen des Betrags in den Zeilen beim Zurücksetzen feststellen. Würde mich ehrlich gesagt auch wundern.

Die Hilfe gibt zum Feld Restbetrag diese Info:

Gibt den Betrag für diejenigen Artikel der Bestellung an, die noch nicht geliefert wurden. Der Betrag wird in der Währung des Einkaufsbeleges angezeigt.
Die Anwendung berechnet den Restbestellbetrag als Betrag inkl. MwSt. * Restbestellungsmenge / Menge.
Die Anwendung aktualisiert automatisch dieses Feld, wenn der Inhalt des Feldes "Menge" sich ändert oder die Einkaufszeile gebucht wird.

Fazit:
Meine Tests auf nicht (!) R2:
Im Cronus wird der "Betrag" nicht zurückgesetzt.

Ich habe es auch (um sicher zu gehen) in unserem Testsystem ausprobiert (nicht Cronus) und dort wird der Betrag der Zeilen auch nicht zurückgesetzt beim Öffnen des Belegs.

Hi,
Ich habs anhand des Cronis AG Mandanten probiert (Demo Daten/Mandant von MS im NAV) und konnte kein zurücksetzen des Betrags in den Zeilen beim Zurücksetzen feststellen. Würde mich ehrlich gesagt auch wundern.

Hey Thomas!

Danke für deine Hilfe soweit. Das ist echt interessant. In der CodeUnit 415 (Release Purchase Document) wird bei mir in der Funktion "ReOpen(PurchHeader)" die Funktion "ZeroAmountInLines;" des PurchHeaders aufgerufen, der die Beträge tatsächlich auf 0 stellt. Da kein Modify-Kommentar von unserem Partner drumherum steht, sollte das dann Standard sein.

Das ist ja sehr seltsam =/.

Cheers
Patrik

Edit: Der Seite hier nach zu urteilen, wird das im Nav 6 standard allerdings auch gemacht. Nur nicht als eigene Funktion.

Hallo zusammen!

Die ganze Situation hat sich aufgelöst. Trotz mehrfacher Zusicherung unseres Partners, dass man es natürlich im Standard nachvollziehen kann und dass der Fehler sicherlich nicht durch Anpassungen hervorgerufen werden, konnten wir die Problematik heute durch eine Änderung einer Anpassung beheben.

Der Fehler liegt also definitiv nicht im Standard sondern definitiv bei der Anpassung durch unseren Partner. Das Standardverhalten setzt beim Wiedereröffnen tatsächlich den Betrag auf 0, berechnet diesen aber beim Freigeben neu.

Es tut mir leid, dass ich hier so viel Wind gemacht habe und bin ein wenig unzufrieden darüber, dass unser Partner uns mit Fehlinformationen füttert.

Liebe Grüße und danke an alle, die hier mitgeholfen haben :)!
Patrik

Trotz mehrfacher Zusicherung unseres Partners [...]

Jaja ... da geht es nicht nur dir so.