Microsoft Dynamics NAV (Archived)

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

(0) Share

Report

Posted on by Andri Wianto

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.

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

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

I have the same question (0)

All responses (6)

Answers (1)

Damogran 360 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Suggested answer

Jens Glathe 6,092 on at

Like (0)

Report

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

Was this reply helpful? Yes No
Andri Wianto 385 on at

Like (0)

Report

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

Was this reply helpful? Yes No
ManishS 86 on at

Like (0)

Report

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

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

Was this reply helpful? Yes No
Verified answer

Jens Glathe 6,092 on at

Like (0)

Report
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

Was this reply helpful? Yes No
Andri Wianto 385 on at

Like (0)

Report

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!

Was this reply helpful? Yes No