Change NAV Partner

One way is to buy Application Developer or Solution Developer granule into your license, than you (and it means your partner too) can change the objects of addon you have bought (App. developer is enough if there are no "ledger" tables, else you need SD).

Sometimes the partners are able to make contract that they can change objects in addon from the second partner, but all depends on people.

Hi Tia,

If the add-on is in a custom range then, as far as I am aware, the code must be open source for anyone with partner/development license. To "protect" addon code it must be a registered add-on with Microsoft and a granule associated with it. This granule must then be issued with the customer license. Do you have a granule for the addon on your license?

MS won't do shit about it. It's up to the partner to determine the licensing model.

You are basically hosed, if the solution center's addon cannot be modified by 3rd party Developers.

I would never implement an addon that cannot be added to 3rd party developer license so that they can customize it.


I suggest to re implement the feature and move on. Sadly I see more and more Partners doing this. Most of the partners come from different Systems/programming language background and do not know the NAV ERP business.
Instead of MS recommend them how to license it, MS simply cuts them a license.
This NAV ERP it used to be is changing rapidly.

generic wrote:

MS won't do shit about it

You are quite vocal about your dislike about Microsoft (I wonder why the hell you work in this area if you hate it so much), but this one falls squarely on the partners. Microsoft CAN'T do anything about it, even if they wanted to, because that is how the model is set up.

Some partners have created add-ons and even verticals, and they then decide not to grant other partners execute rights to the objects. Understandably because they don't want other partners selling their product, but when customers do switch partner, they are completely stuck, with no possibility to fix any issues, because the new partner doesn't have access to the objects.

generic wrote:

MS changes licensing model everyday and they can change this if they want.

yes, thats true as long as there are people who pay

generic wrote:

Sadly your post is another personal attack.

Show me exactly what it is that I wrote that attacked you personally. All I did was wonder why you work in this area if you hate it so much.

<edit>you're right Luc, not worth it</edit>

KTA8 wrote:

Before read this post, I think this fact was a Myth. In what part of the contract is that clause?. I never read a point about a partner can close code

Do you mean "can" as in is there a physical way they can do it. Or did you mean "may" as in are they permitted to do so.

Unfortunately the answer to both is yes, but with different provisos.

On the CAN side they can request closed objects from Microsoft. These used to be rarely given out, but are becoming more common. There are a handful of cases that they make sense, payroll and credit cards come to mind. In these cases you need to make sure there is a clause in your contract with the partner that guarantees you unhindered access to the code in the case that you change partners. Otherwise simple DO NOT do business with the company.

Note that some Add-Ons have locked code, and partners can get access to that code ONLY after meeting certain training requirements, and I think this is fair and reasonable. (please check because its quite possible that this is your case).

Another CAN option is hacking the code. This is clearly ILLEGAL. The two most common methods are 1/ to hack the objects to remove the text code so its unreadable and thus un-editable. 2/ to crash the checksum in the object giving a similar effect. Mae sure in your contract that the partner agrees never to do this.

On the MAY side, there is the legal vs moral aspect. Personally I would recommend all Navision clients to make clear in their contract with their partner that they must leave all code open and simply don't buy product or services if the partner refuses.


Don't forget Microsoft want to sell software, they don't want problems. Your partner DOES NOT own the code that you are running, Microsoft does, so ultimately Microsoft will want to do what they can to help you resolve your issues. They don't want you hating Navision and they don't want you switching products, so I am quite sure they will help you resolve this.

David Singleton wrote:

David Singleton wrote:

On the MAY side, there is the legal vs moral aspect. Personally I would recommend all Navision clients to make clear in their contract with their partner that they must leave all code open and simply don't buy product or services if the partner refuses.

I would recommend to all Navision users that in your contract or agreement that the developing partner agrees to provide ALL new and modified objects to you in TEXT format along with FOBs. There is no justification what so ever for them not to do this.

Even if they do give you the text and fob, you'll need to add to your license permission to modify that range.
which means you have to renumber the objects. Which means you are stealing.
Now if MS owns all the Code, then renumber any addon is not stealing?

ssingla wrote:

Does that mean I can renumber any standard object (MS developed) and can use it?
Will it not amount stealing :-k

If you read the contract you signed with Microsoft you will realize that you are not permitted to develop ANY code that would duplicate of compete with any code in Navision. For example if you have a client that needs a job scheduler but does not want to buy the Service Module, so you renumber those objects to the 50,000 range, you are then in breach of contract.

An exception though is that you MAY copy code or snippets and concepts from Navision that will be used for a different purpose. This means to create a function that does not currently exist in Navision. You can always take an existing granule and expand it though, since the client would have to purchase that granule first.

The situation, that more and more so called "certified solutions" (formerly known as AddOns) have got their objects protected from being modified is on the one hand contrary to the original philosophy of NAV (or should I say Navision), that "everything can be customized". On the other hand, this is an effective (and may be the only) possibility for an addon providing company to take over the customers who have bought that addon through other MS partners, because that partner cannot customize the addon and cannot even guarantee to fix any of its bugs or inconveniences quickly, or (as complained above in the case that the coaching partner is the addon selling one) it is a strong argument to stick to the addon selling partner, even if their are other causes for complaints.

generic wrote:

You can copy existing MS objects in 50K as is. MS allows that.

MS released a document so that you can copy localization from other companies to merge into one. You can find it on partnersource.

Also addons are not existing Nav functionality.
Based on the above post You could copy an object, Modify it to your needs and it would be still ok. hmmm

You are not correct. Merging localization is something separate from using the code to avoid purchase of granule. Former can be allowed but the later will be against the contract between the partner and MS and will only amount to stealing.

gerdhuebner wrote:

generic wrote:

You can copy existing MS objects in 50K as is. MS allows that.

I propose that you remove this sentence, because I always considered this as a bug, which may be fixed in the next version..

I wonder this will be done ever in the future. This will create unnecessary hardship to the developers. If somebody needs to modify the standard report then he will have to develop it from scratch #-o

David Singleton wrote:

KTA8 wrote:

Before read this post, I think this fact was a Myth. In what part of the contract is that clause?. I never read a point about a partner can close code

Do you mean "can" as in is there a physical way they can do it. Or did you mean "may" as in are they permitted to do so.

Unfortunately the answer to both is yes, but with different provisos.

On the CAN side they can request closed objects from Microsoft. These used to be rarely given out, but are becoming more common. There are a handful of cases that they make sense, payroll and credit cards come to mind. In these cases you need to make sure there is a clause in your contract with the partner that guarantees you unhindered access to the code in the case that you change partners. Otherwise simple DO NOT do business with the company.

Note that some Add-Ons have locked code, and partners can get access to that code ONLY after meeting certain training requirements, and I think this is fair and reasonable. (please check because its quite possible that this is your case).

Another CAN option is hacking the code. This is clearly ILLEGAL. The two most common methods are 1/ to hack the objects to remove the text code so its unreadable and thus un-editable. 2/ to crash the checksum in the object giving a similar effect. Mae sure in your contract that the partner agrees never to do this.

On the MAY side, there is the legal vs moral aspect. Personally I would recommend all Navision clients to make clear in their contract with their partner that they must leave all code open and simply don't buy product or services if the partner refuses.


Don't forget Microsoft want to sell software, they don't want problems. Your partner DOES NOT own the code that you are running, Microsoft does, so ultimately Microsoft will want to do what they can to help you resolve your issues. They don't want you hating Navision and they don't want you switching products, so I am quite sure they will help you resolve this.

I've heard that some partners have done add-ons that are closed by code. They try to trap the client with that. Normally the old partner partner and the new one have previous agreements about that point.
But I've never seen a contract between partner and customer than says that they have to accept a close code.