Skip to main content

Notifications

Announcements

No record found.

Microsoft Dynamics NAV (Archived)

Undo Receipt (crack the code) - NAV2009 R2 - Require Pick Only

(0) ShareShare
ReportReport
Posted on by 385

I want to do Undo Receipt, but it raises error:

---------------------------

Microsoft Dynamics NAV Classic

---------------------------

You cannot undo line 10000 because warehouse put-away lines have already been posted.

---------------------------

OK  

---------------------------

I have browse some blogs, and they suggested that I should delete the Posted Inventory Put-away. Hence, I have an idea to just remove the 'checking line code':

CU5817 - Undo Posting Management

...

IF NOT (UndoType IN [DATABASE::"Purch. Rcpt. Line",DATABASE::"Return Receipt Line"]) THEN

 TestWarehouseReceiptLine(UndoLineNo,SourceType,SourceSubtype,SourceID,SourceRefNo);

TestWarehouseShipmentLine(UndoLineNo,SourceType,SourceSubtype,SourceID,SourceRefNo);

TestPostedWhseShipmentLine(UndoLineNo,SourceType,SourceSubtype,SourceID,SourceRefNo);

//TestPostedInvtPutAwayLine(UndoLineNo,SourceType,SourceSubtype,SourceID,SourceRefNo); --> remove this line

TestPostedInvtPickLine(UndoLineNo,SourceType,SourceSubtype,SourceID,SourceRefNo);

I want to ask you, whether this is a 'safe' solution?

Thanks in advance.

*This post is locked for comments

  • Andri Wianto Profile Picture
    Andri Wianto 385 on at
    RE: Undo Receipt (crack the code) - NAV2009 R2 - Require Pick Only

    Thank you all for sharing your ideas.

    I think I will consider to use the Whse. Receipt functionality, instead of Invt. Put-away, so that I can use Undo Receipt, using standard function, and no need customs :)

    Thank you very much!

  • Verified answer
    Jens Glathe Profile Picture
    Jens Glathe 6,092 on at
    RE: Undo Receipt (crack the code) - NAV2009 R2 - Require Pick Only

    Hi Andri,

    it depends a little on what is classified as "error" by the system and by the company that's using the business logic.

    • Wrong quantity, UOM, location code, vendor/PO: These are real errors that must be corrected. When your received quantity is already reserved/picked/consumed, then it's a mess. The problem is that the undo function is accessing the item ledger entries of the receipt, and if they are (even partially) closed, then the system will refuse the undo. It is similar with customer/vendor/bank ledger entries when they have applications. Resolving this with item ledger entries can be quite a pain. You would need to look up item receipt entry no. and also item entry relation to find out what went wrong, and then to change the according entry no. connections (assuming you have inventory left for the undo).


    I would suggest to have a look at when the errors get recognized. From what you write it seems that there is some time before they are being detected. Maybe a small change in the workflow would help:

    - All receipts are posted to locations/bins where they can't be consumed from directly.
    - After verifying the receipts were correct (by another person), they will be transferred to normal inventory locations.

    This keeps the errors away from normal (moving) inventory. It can be achieved with little or no modifications.

    • Wrong (product/VAT) posting group: these are errors with no real consequences. The only deviation thinkable would be on expected cost, but that's a non-issue. Therefore my proposal to disarm CU90 accordingly.

    • Wrong currency code: Yeah well that would be a possible issue with the PO itself, or the vendor invoicing in a different currency. I would propose to handle this like the wrong posting groups, although checking the invoice might be a little more complex because the PO is in a different currency. But basically, I'd say it's also a non-issue. You have no wrong values in your system, only a strange-looking PO/Invoice combination.


    IMO, the best strategy is to keep the inventory movements as they are, as long as they are with the right quantity/UOM/location/PO. The financial stuff is pretty much decoupled from it and shouldn't lead to an undo receipt just becaus the currency or some other code is wrong in the receipt. The system should ignore it.

    with best regards

    Jens

  • ManishS Profile Picture
    ManishS 78 on at
    RE: Undo Receipt (crack the code) - NAV2009 R2 - Require Pick Only

    I think you should do what urpok has been telling you.

  • Andri Wianto Profile Picture
    Andri Wianto 385 on at
    RE: Undo Receipt (crack the code) - NAV2009 R2 - Require Pick Only

    Hi Jens,

    Thank you for your reply.

    Would you please explain me with an example for the scenario you given?

    As far as I understand you, I think that is not the case.

    The Accounting need to do Undo Receipt so that it will not need effort for him, to invoicing every receipt that is posted by mistakenly quantity, Currency Code, or Vendor No.

    There are many mistake cause by the Purchase Order, and some by the Warehouse Personnel who posted the Receipt Qty.

    Regards,

    Andri

  • Suggested answer
    Jens Glathe Profile Picture
    Jens Glathe 6,092 on at
    RE: Undo Receipt (crack the code) - NAV2009 R2 - Require Pick Only

    Hi Andri,

    the question is do you really want to do the undo receipt, or is the system (and accounting) telling you to do so because some posting group is different in the receipt, but the invoice needs another one? We found out at our site that this was the case at almost all occurences. The receipt itself (quantity, location, bin) was correct.

    The solution was to disarm CU90 a little by disabling the check against the posting groups of the receipt lines.

    with best regards

    Jens

  • Damogran Profile Picture
    Damogran 360 on at
    RE: Undo Receipt (crack the code) - NAV2009 R2 - Require Pick Only

    Well, the test for this line is certainly there for a reason. If you do not delete the posted put-away line, you end up disrupting your physical warehouse quantities and values.

    Probably deleting just the posted put-away line is not enough either, you will have to see if the entry has been inserted into other tables as well.

    I would suggest you to do return order, pick and post it, and create a new purchase order instead.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Congratulations 2024 Spotlight Honorees!

Kudos to all of our 2024 community stars! 🎉

Meet the Top 10 leaders for December!

Congratulations to our December super stars! 🥳

Get Started Blogging in the Community

Hosted or syndicated blogging is available! ✍️

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 291,642 Super User 2024 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 230,371 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans