Posting Date Whse. Rcpt. ignored if earlier than Purch Order

AndwianAndwian Member Posts: 627
edited 2014-01-02 in NAV Three Tier
When we posting Warehouse Receipt, there is a condition that:
If Posting Date in the Purchase Order is blank or earlier than Posting Date on Warehouse Receipt, then the Posting Date on Purchase Order is set equal to the Warehouse Receipt.
Codeunit 5760 Whse.-Post Receipt
InitSourceDocumentHeader()
WITH WhseRcptLine DO BEGIN
  CASE "Source Type" OF
    DATABASE::"Purchase Line":
      BEGIN
        IF (PurchHeader."Posting Date" = 0D) OR
           (PurchHeader."Posting Date" < WhseRcptHeader."Posting Date")
        THEN BEGIN
          PurchRelease.Reopen(PurchHeader);
          PurchHeader.SetHideValidationDialog(TRUE);
          PurchHeader.VALIDATE("Posting Date",WhseRcptHeader."Posting Date");
          PurchRelease.RUN(PurchHeader);
          ModifyHeader := TRUE;
        END;

The problem is:
If someone create a new replacement Purchase Order on 10/25/13, but the Warehouse Receipt must posting on 10/24/13, then the Posted Purchase Receipt is posted on 10/25/13, although the Posted Warehouse Receipt is 10/24/13.
It could be a problem, when the first Purchase Receipt is using later Posting Date, than the second Purchase Receipt (not make sense in real scenario, but this could be happen when there is an erroneous in first Purchase Receipt).

I have tested posting it using:
Inventory Put-away, and
Purchase Order
and all other way is resulting in Purchase Receipt with Posting Date of 10/25/13.

Does anyone know, if it is a known bug, or any logical reason behind this work-as-design?
Thank you.
Regards,
Andwian

Answers

  • AndwianAndwian Member Posts: 627
    I found a KB Article KB981707 "You obtain an incorrect posting date in item ledger entries if you post an inventory put-away by using a posting date before the work date in Microsoft Dynamics NAV 5.0" that similar to problem in Whse. Receipt, but applied to Inventory Put-away.

    Hence, I am sure that this is a bug.
    Regards,
    Andwian
  • AndwianAndwian Member Posts: 627
    I check on the Whse. Shipment side, the behavior also exist there.
    Regards,
    Andwian
  • forianduforiandu Member Posts: 1
    As my thinking, it is not bug, it follows a logic, the Posting Date of a purchase order cannot be earlier than the Posting Date of a purchase receipt. This function like a utility used for person input data in the system. it differs from the operation of the warehouse keeper.

    Let's think this case:

    You have 3 purchase orders with different Vendor:
    - 1st Vendor A. Order Date: 5 Dec 2013, Posting Date: 5 Dec 2013
    - 2nd Vendor B. Order Date: 10 Dec 2013, Posting Date: 12 Dec 2013
    - 3rd Vendor C. Order Date: 20 Dec 2013, Posting Date: 30 Dec 2013
    (as you known if post receipt directly in Purchase Order, need to edit Posting Date in the Purchase Order)

    So normally when you do the receipt, you need to create 3 times independently. But actually just do once with get source document. Assumption that the person input data makes 'warehouse' posting date is 5 Dec 2013 (for 3 above source documents), then post, system will automatically check and put 3 Posted Purchase Receipts with corresponding Posting Date.

    In my opinion, in NAV, Stock Receipt Note is Posted Purchase Receipt, not Posted Warehouse Receipt.

    Regards

    Foriandu
  • AndwianAndwian Member Posts: 627
    Thanks for sharing your thought!

    I forgot that Warehouse Receipt can be used for multiple Order, and even Vendors.

    In my practice, I use the Warehouse Receipt just for 1 Vendor Shipment No. Hence, rarely using some Orders, and never multiple Vendors.
    If, for example Purch. Order 1 is created on 01/01/14 (hence the Posting Date is by default 01/01/14), while Order 2 is on 01/02/14, and the actual receipt date is 01/03/14 (Posting Date on Warehouse Receipt), hence the Purch. Receipt Date will be false, ie 01/01/14 and 01/02/14. It should be the actual Receipt Date 01/03/14.
    Regards,
    Andwian
Sign In or Register to comment.