All NAV clients know that to add additional functionality to NAV they must purchase run time license access to access the development made by their partner.
A very few lucky clients will be told this by their partner during the sales process BEFORE they sign a contract. The majority will learn this before Go-Live during the gap-fit analysis when the development estimates come in. Then a very unlucky few will learn after they have committed to an enhancement and it's too late to do anything except pay.
The cost of these objects (when put into perspective) is quite low, so I can never fathom why partners don't make this very clear before signing, instead of the belated excuse of "Yeah well its right there in the price list, surely you did your due diligence and read the price list".
In my opinion though if your partner caught you like that, then you have a lousy partner.
But that is not what this blog is about. This is about a common practice I see from partners that I find totally unacceptable. And that is using the 50,000 object range for development.
The range of objects from 50,000 through 50,099 (50,009 for tables) was intended to be used by Clients that purchased the NAV development tools. Commonly many clients are advised to purchase the basic designers
Obviously to use these they need access to objects, and thus the inclusion of basic objects for them to create their own forms and reports, and later some tables. But very often I see that the partner has already started development at the 50,000 range, and thus 6 months down the track the client is ready to start development, and is told "Ah well you need to buy tables and forms, because we used the all up during the Implementation process. So since ten tables cost the same as the table designer, from the client's point of view they have to go out and purchase the development tools all over again.
This is shameful.
When you perform development for a client, you should define a range that your company will use, and start there. DON'T start at 50,000, and you will thus completely avoid this issue, and most importantly you will avoid a horrible argument with your client all over a lousy $800. When I quote modifications to a client, I would make it very clear the difference between buying one table for $200 or ten at $80 each. But make it clear, don't just sneak it in as a line item at the bottom of the quote.
Of course there are clients that will never use 1000 reports and 10 tables, so in those cases, sit with them up front, be frank and open with them, and tell them that it's not recommended practice, but if they want you can develop using the 50,000 range. What customers hate is deception, or at least the feeling of being deceived.
I guess it comes down to trust, and whether it's $1.00 item or a $1,000,000.00 if the customer doesn't trust their VAR, they will go away.
It seems odd how a lot of U.S. VAR'S are more inclined complete for the cheapest price up front, then try to back charge projects rather than make a good presentation and proposal in the first place.
I guess it's cheaper for quoting costs as long as the customer doesn't leave or litigate you in the end.
Successful projects come down to quality engineering and operations if your VAR doesn't appear to have a good director of engineering that is separate from the sales department, run away...
I completely agree with you on this. I am currently in the stages of learning CAL through reports and forms and have found that I am limited to design only a handful of reports because of the lack of remaining form ID's within our acceptable number range.
I don't know what the range has got to do with anything. It all comes down on "telling the right story". And that story is very simple.
You want modifications? You'll have to buy objects.
You want to do changes yourself? You'll have to buy the designer-granule ... and hey, you'll get some objects for free!
The objects have to be foreseen, wether the partner does the changes or not. If you get some objects for free when buying the designers, be thankful for it, in stead of being disappointed when having to pay for additional objects.
So why would range matter? It's the number of objects that matter - and telling/warning in time, off course (I agree on that...).
Personally I think it doesn't matter at all which number you use, and it is perfectly ok to start NSC development at 50,000, as long as the NSC and the customer communicate about how many objects are needed for what purpose. 50,000 is the standard range that any license starts with custom objects. You have to specify any other object during the license ordering process, and I've seen that being screwed up more than once.
There does seem to be a tendency to leave out certain details until the project is well under way. Whether that is intentional or not is up for debate of course, although it is interesting to observe that some of these things appear to happen over and over again and that certain NSC's don't seem to learn from it.
It boils down to communication, and with that I agree with you wholeheartedly. There needs to be clear communication about what objects are used for what purpose. If the customer is going to do development, and they need 10 tables, then it is up to project management to make sure that those objects are added to the license, and that the available object numbers are allocated properly. To me the value of the object numbers themselves really don't matter at all.
[QUOTE]You want to do changes yourself? You'll have to buy the designer-granule ... and hey, you'll get some objects for free![/QUOTE]
Exactly, BUT if the tabels have gone, then what are they getting "for free" The point is that I keep seeing over and over again, that the cleint purchases the Table designer for example, but then some time after Go Live they decide to start creating tables (forms reports or what ever) they then find that there are no objects available, and they see it as having to pay again for the objects that they feel they allready paid for.
The fact that partners don't see this as an issue is my point here. I know that many partners explain it in detail (and I am sure you do), but trust me a LOT of partners do not make this clear, and clients get very very angry at the feeling of having been nickled and dimed.
Daniel said it right, the key is communitcation and setting expectations.
PS re-read my last paragraph in the Blog.
Agreed. We have the same problem. We have clients that are using our licence for "some reason" (forgotten) an now that our licence is expiring we are running around changing our licence to theirs to only find out that the licence has granules missing sometime including the 50,000+ numbs of those tables.
This raises an important question,
Should MS still continue to charge each time you want to use a couple of new objects (tables, codeunits ...)
Many customer don't understand that in this day and age, many company companies run their businesses with totally "free", open software that they can customize at will ...
I've always found odd (and I've been in the Navision world for 11 years now)
to charge for "virtual empty container" (that's a Navision object),
But now some argue, but that's the simplest and most reliable way to calculate support fee since it's based on a % of the purchase additional objects ...
I'll stop poluting this thread for now ;-)
Freelance Dynamics NAV (Navision) Developer