Thought Process on Receiving Defective Inventory in Dynamics NAV

Receiving items from vendor can be a tricky thing. This question has come up quite a bit during implementation regarding defective inventory. I know a lot of companies has put a lot of modifications into receiving defective inventory, I’d like to propose an out of the box solution to receiving goods that have some defective quantities.

Here is the scenerio:
1. A purchase order came in on a container for ItemA with 100 pieces
2. Of the 100 pieces, 30 are damaged and they want to reject these pieces and send them back to the supplier
3. The user wants to be able to return the 30 pieces to the supplier and revert the Qty. to Receive to 30 to indicate there is still 30 to be received

Before we get into processing this, I want to bring up an important concept a person taught me when I was starting out doing Dynamics NAV:

Processing any task on a computer is no different than if you were to process processing a task manually.

This is a very important concept that changed the way I thought about automation, implementation, and how we can use Dynamics NAV (or any other computer software) to help us. This is especially true in the world of accounting where paper trail is everything. This concept is literally the difference between 100 hour modifications or 2 hour training session.

The Quick and Dirty Way
Looking at this problem, the natural instinct would be to do this:
1. Use the undo receipt function to undo what I’ve received
2. Post the receipt of the correct 70 quantities so the PO would look like it has 30 remaining on the original line

Here are the problems with the above approach:
1. Undo Receipt will not work if the received quantity has been sold
2. You have no record to match up with the vendor bill of lading
3. There is no record of the return to the vendor

Realistically speaking, is the truck unloading the shipment going to wait for you to do QC on the pieces received? The trucker has people to see, places to go, the trucker is a driver and probably does not even work for the vendor you bought the stuff from.

Being a developer with limited knowledge of operations, this would be the process that’s the easiest. For accounting, they want it easy and just want everything back to how it should be. For warehouse and operations, just do it and avoid the system at all cost.

This process would work in the perfect world. The problem arises if there are disputes, lost items, vendor reconciliations where they said you received some stuff but your records says you didn’t.

As I’ve said it time and time before, skip any data entered into the system you want as long as the financials balances out. The problem only arises when it’s time to reconcile.

The Manual Way
Going back to the original concept that’s laid out before, let’s solve the problem on the same issue if we had no computer in front of us. Here’s what I would do.

1. Unload the goods from the truck and sign the BOL because the trucker need to leave
2. Place the goods in a holding area in the warehouse to be checked/put-away
3. As the goods are checked, move the defective items into a separate area in the warehouse and put the good pieces in the warehouse bins
4. Call the vendor and say “Dude, your product is broken, I’m gonna return it. I also need you to replace the 30 that’s defective.”
5. Arrange transportation, prepare packing list, bill of lading, (if international, prepare commercial invoice, etc).

Bring in the System
Knowing how we process this manually, we can then replicate this into the system, in our case, Dynamics NAV:
1. Receive the items in full into the QC location (or into your main warehouse and into the QC bin if you’re using WHM)
2. As the items are checked, the good items should be moved to your main warehouse or bins using the item reclass journal or movement worksheet
3. Create Purchase Return Order for the defective goods. Use the document to generate the packing list, commercial invoice, etc.
4. Add a line to the purchase order to indicate replacement of the additional goods

Doing the above will create some additional steps and data entry, but it also has the benefit of having a paper trail. You need the full story on what happened to the PO. You need to show that you received 100 pieces originally, returned 30, then received the additional 30.

Each of the steps above can be handled by one person, but it should split out to ensure checks and balances. For example, it’s not realistic for the warehouse guys to call your vendor asking for a return.

In addition, it’s not realistic to generate a return every time there’s a defective part especially if the vendor is in another country. For returns dealing with international vendors, the company will ususally accumulate all fo the defective parts until they can fill a container, then process the return in one shot.

Again, doing things the proper way will create some additional steps, but I’m assuming you bought Dynamics NAV to help you organize your business, not creating more mess. Not every tasks requested by the end users will make sense in the long term.

It’s really up to the consultants to challenge the end user’s way of thinking and what’s the proper way to process certain business tasks. If you find that every request you made to the consultant always results in additional modification instead of training, you probably need to challenge your own request to see if your request makes sense if you were to do it manually.

12 thoughts on “Thought Process on Receiving Defective Inventory in Dynamics NAV

  1. Andri Wianto says:

    Like this part:
    “If you find that every request you made to the consultant always results in additional modification instead of training, you probably need to challenge your own request to see if your request makes sense if you were to do it manually.”

    This is one of the quality article that is needed by the consultant, even by the customer that almost request anything if NAV does not work like his thought, or his old system.

    This is one approach of how to think out-of-the-box!

    Thanks, Alex!

  2. Jodie Holt says:

    Hi Alex,

    I’m not hopeful of an answer as this blog is so old, but I’m desperate so willing to try anything…

    I’m not a developer or anything, just an accountant trying to improve a process.

    I’m not a fan of Return Purchase Orders, unless it is a straight return for a credit. We work in a standard costing environment where a Purchase Price Variance GL entry is caused when we post an invoice and the value does not match the GRNI. This works perfectly, however the system fails to do this accurately for the Credits posted against Return Orders as the Entries get stuck in the Applied Intrim accounts and results in a manual journal.

    My other problem with return orders is…If the Material is found to be defective or even sent away for a modification at a much later stage IE post payment, we as a business own that asset while it is still in Inventory, WIP or Finished Goods. If we post a Return Order, the item is shipped off the system and becomes very dificult to trace.

    I enstalled a different process using Subcontracting.

    We will do a Transfer Order to transfer the item to the Vendors location as this is all that has happened physically.
    Await result of analysis from supplier.
    If the Item Requires re-work a Manufacturing Order is raised, with a Subcontract Routing Link Code for the item to consume itself from the vendor location and produce itself.
    This enables us to generate a PO linked to the MO for the cost (if any) of the rework.
    The Supplier sends the item back, we book the PO in and the system Creates the Output and Backflushes the Component.

    This way we have perfect visibility of what happened to the part and the generation of the PO makes the item appear on the Purchasers Order Book to chase. Also the inventory is shown at the correct location.

    The Only problem I have is…For our normal subcontracted parts (ie free issue components to vendorfor them to assemble) with the BOM all set up and Subcontract Routing, the process works perfectly.

    For Purchased Items where we return for repair, everything works bar the backflushing at the Booking in stage.

    I read somewhere online that the backflushing fuction will not work for Serial Tracked Items and I can almost live with that, but I can’t understand what I’m doing wrong with a normal purchased component.

    Can you offer any advice??



  3. Alex Chow says:

    Hi Jodie, that’s quite a long comment! For the questions you raised, is there a reason why you’re not asking this to your solution center? They’re not uncommon questions that a typical company would ask.

  4. Jodie Holt says:

    WOW!!! Wasn’t expecting a reply!

    We have a team of “programmers/ Nav Consultants” at our corporate site that are just toooo busy to help with any of my operational requirements, even simple requests like expanding a field on a pick list are at the very bottom of the pile.

    I have raised my issue several times, but they have not yet come up with a solution as it is not on their priority list. I have so far waited nearly 2 years so decided it was far easier to just learn it myself, give them the solution and continuously moan until they sort it. 🙄 Problem is I can’t work out the solution 😥

  5. Alex Chow says:

    Yes, internal NAV team can sometimes have a long backlogs of issues that they need to resolve. This is why NAV consultants like us exist. We have the expertise and the capacity to resolve your issues.

    Have you tried raising your concerns for support to your supervisor? Someone needs to go through the returns process with you so you can troubleshoot this on your own in the future.

  6. Jodie Holt says:

    Yes, I report direct to the FD, I’ve also gone above him to corporate finance and it’s just not a priority to them.

    We have an external consultant coming in next week (who my boss has already stated that my issue is right at the bottom of the pile and will unlikely be looked at)

    So looks like I will just have to continue to bang my head agaisnt a brick wall…

  7. Carlos says:


    What would be the easiest way to exclude those damage inventory from the inventory availability calculation ?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.