[gelöst] Einkaufsrechnungen Stapelbuchen Buchungsdatum

Guten Morgen zusammen,

ich habe ein Problem mit dem Report 'Eink. Rechnungen stapelbuchen'.
Beim Aufruf des Reports habe ich das Buchungsdatum = 30.12.19 eingetragen und den Haken 'Buchungsdatum ersetzen' gesetzt.

Durch den Lauf wurden einige gebuchte Einkaufsrechnungen erzeugt, wie es zu erwarten war

Allerdings passt bei einigen das Buchungsdatum nicht. Bei 5 Rechnungen steht jetzt das Buchungsdatum 20.12.2019 und ich verstehe nicht, warum.
Aufgefallen ist mir noch, dass die Rechnungsnummern bei diesen 5 Rechnungen nicht fortlaufend sind, hier hat sich das System die Nummern 1000480, 1000482, 1000502, 1000509 und 1000520 gezogen. Die ordentlichen Rechnungsnummern laufen dann von 1000528 - 1000613.

Bei den "komischen" 5 handelt es sich um Direktlieferungen. Handelt es sich hier um einen Fehler oder muss das so sein?
An welcher Stelle wird das Buchungsdatum von wo gezogen?
Bei uns ist es sehr wichtig, dass das Buchungsdatum so gesetzt wird, wie es im Report zum Stapelbuchen vorgegeben wird, weil wir sonst Probleme in einer Schnittstelle bekommen.

Kennt das Phänomen jemand und kann mir hier helfen?

Vielen Dank.

Gruß
Alexander

Zuletzt geändert von zannaleer am 27. Februar 2020 15:42, insgesamt 1-mal geändert.

Hallo zusammen,

mir ist gerade aufgefallen, dass dieses Phänomen auftritt, wenn im Einkaufskopf das Feld "Posting No." (63) gefüllt ist.
Hier steht dann die gebuchte Rechnungsnummer, die sich das System beim Buchen auch nimmt.
Is it a bug or is it a feature?

Danke.

Gruß
Alexander

...im Einkaufskopf das Feld "Posting No." (63) gefüllt ist.
Hier steht dann die gebuchte Rechnungsnummer, die sich das System beim Buchen auch nimmt.
Is it a bug or is it a feature?
...

Das ist definitiv ein Feature. Dadurch kann die Buchungsnr. bereits im Vorfeld ermittelt werden. Passiert zum Beispiel, wenn eine Rechnung nicht gebucht werden kann. und nach Korrektur dann gebucht wird.
Das Buchungsdatum sollte dennoch korrekt sein.

Hallo Michael,

das Buchungsdatum sollte definitiv stimmen
Ich finde aber selbst mit dem Object Explorer keine Stelle, an der das Buchungsdatum auf einen anderen Wert gesetzt wird.
Ich finde die Stellen, an denen das Buchungsdatum auf das Datum des Stapelbuchen-Reports gesetzt wird, aber nicht die, wo ein anderes Datum genommen wird.

Gruß
Alexander

Hallo Alexander,

was Michael versucht hat zu erklären, ist die Tatsache, dass beim Buchen einer Einkaufsrechnung ziemlich früh in der Verarbeitung, das Feld "Posting No." gefüllt wird.
Dadurch wird dann (bei einer Einkaufsrechnung) die Nummer der gebuchten Einkaufsrechnung lt. Nummernserie ermittelt und in das Feld "Posting No." zurückgeschrieben.
Zu diesem Zeitpunkt ist das Feld "Buchungsdatum" in der ungebuchten Einkaufsrechnung bereits gefüllt.
Nachdem das Feld "Posting No." gefüllt wurde, wird in der Codeunit 90 ein COMMIT durchgeführt.

Sollte dann bei der eigentlichen Buchungsverarbeitung ein Fehler auftreten (z.B. wegen fehlenden Dimensionen in den Rechnungszeilen) und der Buchungsvorgang abgebrochen werden, steht die "Posting No." und das "Posting Date" bereits in der ungebuchten EK-Rechnung.

Beim Stapelbuchen über den Report 497 wird das Buchungsdatum über die Funktion "SetPostingDate" in der Codeunit 90 gesetzt.
Diese Funktion ruft dann wiederum die Funktion "ValidatePostingAndDocumentDate" auf:

Code:

LOCAL ValidatePostingAndDocumentDate(VAR PurchaseHeader : Record "Purchase Header")
IF PostingDateExists AND (ReplacePostingDate OR (PurchaseHeader."Posting Date" = 0D)) THEN BEGIN
  PurchaseHeader."Posting Date" := PostingDate;
  PurchaseHeader.VALIDATE("Currency Code");
END;

IF PostingDateExists AND (ReplaceDocumentDate OR (PurchaseHeader."Document Date" = 0D)) THEN
  PurchaseHeader.VALIDATE("Document Date",PostingDate);


Das Problem ist meines Erachtens, dass die erste IF-Bedingung nicht erfüllt ist, weil in deinen zuvor nicht gebuchten Rechnungen das Feld "Posting Date" nicht leer ist.

Das Problem ist meines Erachtens, dass die erste IF-Bedingung nicht erfüllt ist, weil in deinen zuvor nicht gebuchten Rechnungen das Feld "Posting Date" nicht leer ist.

Doch der Ausrduck muss wahr sein (2017 CU9?), weil

1. Report setzt "ReplacePostingDate" = TRUE

Code:

PurchPost.SetPostingDate(ReplacePostingDate,ReplaceDocumentDate,PostingDateReq);


2. CU 90 setzt PostingDateExists = TRUE

Code:

Function SetPostingDate(NewReplacePostingDate : Boolean;NewReplaceDocumentDate : Boolean;NewPostingDate : Date)
PostingDateExists := TRUE;
ReplacePostingDate := NewReplacePostingDate;
ReplaceDocumentDate := NewReplaceDocumentDate;
PostingDate := NewPostingDate;

Es kann eigentlich nur sein, dass nach der anfänglichen Änderung wegen der Direktlieferung irgendwas im Hintergrund passiert.

Hallo zusammen,

ich habe das Problem gefunden.
Es tritt dann auf, wenn der Haken 'Rechnungsrabatt berechnen' in der Kreditoren & Einkauf Einrichtung gesetzt ist und zusätzlich das Feld 'Buchungsnummer' gefüllt ist.
In diesem Fall führt die markierte Zeile in der CodeUnit 90 dazu, dass auf einen alten Stand des Datensatzes zugegriffen wird und das Datum wieder auf dem ursprünglichen Zustand ist.

CU90.jpg

Wenn ich es richtig gesehen habe, verhält sich das System anders, wenn die Buchungsnummer nicht gefüllt ist, weil dann eine neue Nummer ermittelt und der Datensatz mit einem Modify geschrieben wird.
Echt merkwürdig das Verhalten an dieser Stelle und meiner Meinung nach ein Bug im NAV-Standard.


Gruß
Alexander

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

Hier die Funktion aus einem aktuellen NAV 2017 CU. Hat also schon mal jemand gemerkt. Ist im Verkauf übrigens identisch.

Code:

LOCAL PROCEDURE CalcInvDiscount@134(VAR PurchHeader@1000 : Record 38);
    VAR
      PurchaseHeaderCopy@1005 : Record 38;
      PurchLine@1001 : Record 39;
    BEGIN
      WITH PurchHeader DO BEGIN
        IF NOT (PurchSetup."Calc. Inv. Discount" AND (Status <> Status::Open)) THEN
          EXIT;

        PurchaseHeaderCopy := PurchHeader;
        PurchLine.RESET;
        PurchLine.SETRANGE("Document Type","Document Type");
        PurchLine.SETRANGE("Document No.","No.");
        PurchLine.FINDFIRST;
        CODEUNIT.RUN(CODEUNIT::"Purch.-Calc.Discount",PurchLine);
        RefreshTempLines(PurchHeader);
        GET("Document Type","No.");
        RestorePurchaseHeader(PurchHeader,PurchaseHeaderCopy);
        IF NOT PreviewMode THEN
          COMMIT;
      END;
      EXIT;
    END;

Hallo Michael,

cool, danke.
Dann warte ich entweder auf unsere komplette Developer Lizenz oder bitte unseren Dienstleister, das zu fixen.

Gruß
Alexander