Navision Developer for end-user company

I am a certified Navision Solution Developer, who resigned from a small and struggling NSC in the northeast US back in the fall of 2000. (That was not a good time to resign, but I had to do what I had to do.) Periodically, headhunters find my resume with its keyword “Navision” all over the place— and sometimes they call me. The headhunters are always looking for developers to work on end-user companies’ staffs, as opposed to NSCs or Navision itself. Right now TWO headhunters are calling me, which is good. But what I am wondering is this: how much development can you actually do with the developer’s license available to an end-user company (which does not let you modifying posting routines, amongst other limitations) and how do you work around the fact that (theoretically) you can’t get training directly from Navision and you can’t get support directly from Navision’s product support team? I know the last two items are SUPPOSED to be handled by the client’s NSC, but how well does this work in practice, especially when the developer is taking work away from the NSC’s own developers?

Hi Tim, You’re are asking a valid question. But many have asked it before: Take a look here for example But let me repeat what I wrote here:


The developer license is divided into three steps: 1) Designer Level (Report/DataPort/Forms/Table Designers) 2) Application Builder 3) Solution Developer If you buy the Application Builder then you must have all three designers. And when you buy the Solution Developer, then you need the Application Builder. To do EVERYTHING in the system, then you need the Solution Developer, but if you can live with the fact that you cannot change the Protected tables and codeunits, then Application Builder is enough for you.

So the basic rule is if you do work for a company with the full application developer (rather expensive license), then you have no problem. But you cannot contact your local Navision company, unless you know them personally (grin grin). Practically I never personally had any problems and I’ve done this for years. But if the company only have a solution developer, then you can not modify protected areas (posting codeunits etc.). And then you have a problem and cannot do the job of a “real” developer. Most of my “assignments” has been through local solution centers and then you normally get a license from them. Again no problem.

Hello, i think you have confused something. With the Solution Developer Licence you can do more things than with the Application Develeoper license.

Well… in the worse case… you can always remember to develop in a test database in a broken computer where the date is always older than the actual… It’s dangerous to do that, as Navision’s license expiration does check on your computer date and it can make that your development license already expired but you’re still using it on your “broken date” computer…export objects and import on the real when tested, as usual…you should avoid doing this. Biernat… he’s already talk about the differences. Tim, i was at the begining in an end-user company and we bought the application builder license. It was when using 2.00… it allowed me to do much more than expected… there were just a few areas where i was not having permissions… but you know… it’s not as hard to have to call the NSC sometimes… not only for asking them for more tables or more reports and forms… specially when you call them with something like: “i want you to put me this piece of code in this place in this codeunit… and don’t tell me it will take you two hours to do it because i’m sending you all the code”…[:D] Regards,

Hi Tim! I’m now working for an “End-User” for about 4 years, before that, I’ve been NSC Employee (Project Consultant, Developer), and btw. I was “catched” by a HeadHunter [:D] So, I can tell you how I am working here: We have the “big” licences which are available to customers: Designers, Application Builder, Solution Developer. The only limitations are, that we have only access to licences objects, so we can not create objects with ID < 50000. e.g. Codeunit 80 is licenced, so we have FULL access. Table 50000 is licenced, so we can create it. The way of development is quite similar to the “NSC-work”: A department requests any AddOn or Modification, we specify that, then, depending on the “size” of the Modification, we get in contact with our NSC (to find any “Standard-Solution”), or start to develop that. In everycase a kind of project is started - from tiny to BIG. We have dev-environments, test-environments and so on … We have documentation rules and tools (kind of Apollo Styleguide), to have the same way of source-code documentation as our NSC. Finally, the department “confirms” the functionallity of the AddOn, then it’s implemented … (plus education, support) same game as in a NSC - BUT QUICKER!!! Mostly, the time between request and implementation is just a few hours - and that’s the advantage for our company (and of course the lower costs [}:)]) So, we are working as a “Inhouse NSC” with 3 developers. It’s one BIG and LONG project, work never ends here … Generally, we are in very close contact to our NSC. We get all news from them, new releases to test, whenever we are looking for AddOns they support us … [Big Thanx to all guys at amball [:)]] When training is needed, we have workshops, e.g. to learn the differences of 2.60 and 3.60, or how to develop within a SQL-DB, or how the new logistic-module is working, or, or, or … so we are quite “Up to Date”! Finally, the work under theses circumstances is not much different to NSC-Work, is has advantages (not to traval arround) and disadvantages (?). I like it! [:p] Best regards, Jörg



Originally posted by stryk
… Finally, the work under theses circumstances is not much different to NSC-Work, is has advantages (not to traval arround) and disadvantages (?). I like it! [:p] …

I agree with Jörg’s whole posting. We work with the same licences. I would name as an advantage you are always in practise and as a disadvantage you are always available for the users [xx(]. bye André