Part 6: Do reservations work properly these days?

Those companies that have used Dynamics NAV for a long time will be wary of reservations, as they may well have seen complex errors described as ‘reservation entry not found’ at some point. These often have to be resolved by a developer editing tables directly (not recommended) to sort the issue. Given these errors tend to happen when shipping for instance, time pressure is on because a drivers waiting they are not good errors to have.

Back in NAV version 4, the reservation functions used to crop up all the time in the bug list. Each version since has got progressively better though and certainly by 2009 they were useable. Now on 2015, while I cannot say you never see a reservation error, it’s so rare I cannot remember the last one that didn’t have a cause associated with a badly design customisation.

Even more important to understand is that NAV creates reservation entries regardless of if reservations are on or not. As well as holding all of the data for transactions involving both serial and lot number tracking it creates entries for all item of type tracking or surplus that link the demand to the supply across the system.

This means that if you invoke the tracking function on the requisition worksheet for instance, to see why it has recommended a purchase it will go to the reservation entry table, and use that to show you the sales or production demand that generated that line.

That means that you’re actually using lots of the reservation functionality without knowing it. Why not get the benefits, to offset the minimal risk of it not doing what you expect?

So in summary – yes they do work and they are worth using if you need them. No they will not cause you lots of endless grief.

Note

This post is part of a 6-part series. A link to rest of the posts in this series are below (updated as published);