Sales Return Orders with Item Tracking

I have a client on Dynamics NAV 2009 R2 who uses Item Tracking (Serial No.) on most of their items.

The issue is when handling returns. When using the “Get Posted Document Lines to Reverse” to copy the lines to be returned, then they are applying the “Return Reason” for either an actual return (and credit) or for repair. All returned items are to be returned to their special return location and not the location code from where they where originally shipped from.

But when changing the location code then they are getting this error:

Item tracking is defined for item XXX in the Sales Line.
You must delete the existing item tracking before modifying or deleting the Sales Line.

With the default location code on the “Return Reason” then I would say that this was actually something the developers had in mind (and I know that many companies are doing the same9. But what is the correct procedure for such a return?

I would think you would either return it to the original location and then do a reclassification journal or transfer order. Or you could add a field to a setup table that stores your special location code, and do a mod to use that when creating the document instead of the original location code.

Hi Matt

Thanks, but doesn’t it look strange that you cannot use the standard functionality in the Return Reason codes?

I have actually changed the code so that it’s going to update the location on the reservation entries. Then it looks like there is no problem!

If you receive the actual material in other location then you physical inventory will never match for the material dispatch location.

I would suggest receive the material to the actual location the transfer the same.

Hi Erik,

We have the same situation, being able to default a seperate location to go on the line from the return reason code is very useful, but it is a pain to not be able to use the copy document functionality accross locations. We are in the process of changing the code and testing to allow this to happen.

Nav will obviously allow the lot to exist in multiple locations, and one only has to think of a retail environment where a customer may buy in one store, but return to a different store.

Actually in the process of testing and seems to be working fine.

My client uses mixture of lot functionality, lot, lot and SN, SN, FEFO, mamufactures batch, strict expiry etc