If you are not prepared to change the way your organization works to make it fit in Navision, forget it. Customizing is a VERY expensive process that reveals that the code behind Navsision really is very low quality. There is virutally NO documentation to the tables, the codeunits, the forms, the reports, and the form designer and report designer are of mediocre quality.
The code editor and debugger are even not worthy of that name.
The NSC that started the Navision implementation here promised to get the job done in 4 months. We are almost two years later, and only one department (the finanace department where very litle customization has been done) is already operational on Navision.
I would advise Navision (and any software package in that category) only if you have a relatively small organization that does not do mucgh special things. From the moment you need to customize (beyond adding or removing a few fields in a few tables), your IT-ers will be VERY frustrated and the complete project becomes unmanageable.
I for one actually really hate it. In my previous job, I built a web-based payroll application in .NET. When we had to change something there, we had full control over everything. Now we change something and if we actually find out how to technically do what we want to do, and we actually find out where to change waht we want to change, than we still need to cross our fingers because something completely different that happens to interact with what we changed is likely to break.
I can't agree to the moaning of jesam, because you can do a really wide range of configuration and customizing by yourself with some experience.
For too small companies I would never recommend Navision (Too expensive). I think Navision fits best for mid-range sized companies (50-1000 employees). And -thats evtl. a disadvantage- you need at least one person inhouse with some programming skill who will do the inhouse customizing.
To do all and everything with the solution center can be an expensive job. But nevertheless, you will need a solution center for many other things.
Well, you are asking for disadvantages. What I can think about is:
- Many problems with managing different accounting systems (IAS/US-GAAP and (German HGB)
- Strange Licensing: You must buy a new range of free reports, tables, forms when you need them. This leads sometimes to bad table structures as you always try to use as less tables as possible (Normalization is expensive)
- Performance Limits: The Navision Server runs only on Windows, you can't scale up the same way like you do in Unix (I know Navision-Axapta is different)
- It's a Microsoft Product (Which is basically no problem, but it extends the monopole of MS dramatically)
- You need to know what you want to do !!! (Believe me, thats not always clear for managers)
But with this disadvantges you get a perfect working database (We have had no failure since now 5 Years with the native database) and a very good tool for managing and reporting your business. Especially the SIFT-Technology (Sum Index Flow technology) is great when you know how to handle with it (I's faster than many OLAP-Databases and you have real time access to your data)
I can't agree to the moaning of jesam, because you can do a really wide range of configuration and customizing by yourself with some experience.
Wel, it is easy to call it moaning, but it is the thruth. We have Attain 3.10, maybe that's a very bad version, but it's the one we are stuck with.
When I say that the editor and the dbugger are not wothy of that name, I have a reason to say that.
Debugging :
* It is impossible to set a breakpoint in the debugger before the debugging has started.
* When the debugging has started, it is impossible to do a find in the source code.
* When the debugging has started, the procedures are not in the same order as they appear in the code window.
* It is impossible to step over a function (the menu item exists but does not work).
* When debugging, the code window does not show the definitions of the procedure parameters, only their name.
* It is impossible to do a watch of local and global variables at the same time.
Editor :
* The code that is shown depends on what is slected on the form. There is no way to show all the code of the form.
* It is impossible to selcet a word by double clicking in the editor.
* It is impossible to have a 'flat' code window. Each variable must be declared in a special window. The declaration of local variables can only be seen in that window. This means that when coding or debugging you can not see which variables are declared. This also means that if you refactor and move some code over form one procedure to another, you need to move over the local variables sperately. I gues this is the main reason that the Navision code is full of Global Variables, something that they teach ITers not to do in their first lesson in school.
* You cannot enter lines longer than (have not counted) characters. After that, you need to switch to a new line (this is a limitation that other develometn environments have fixed since 10 years).
* The procedure headings are shown as a grey bar. Unfortunately, they even show less characters, which means that if you have long variable names and more that 3 parameters, the complete procedure heading is not shown. VERY anoying.
I could go on, but I think this proves that even Turbo Pascal 4.0, whoch must be 15+ years old, had a better debugger and editor.
For too small companies I would never recommend Navision (Too expensive). I think Navision fits best for mid-range sized companies (50-1000 employees). And -thats evtl. a disadvantage- you need at least one person inhouse with some programming skill who will do the inhouse customizing.
The only problem is, since there is no documentation, that person is lost if he/she needs to do more than addign labels and fields.
The online help is virtually useless and sometimes plain wrong.
To do all and everything with the solution center can be an expensive job. But nevertheless, you will need a solution center for many other things.
At 600 to 700 € a day per person, that becomes very expensive very fast.
- It's a Microsoft Product (Which is basically no problem, but it extends the monopole of MS dramatically)
Well, MS bought it, but I would never call it a MS product. MS products are of much better quality and are way better documented. As for the monopoly (what does that have to do with anything), as far as I know MS has far from a monopoluy in this market.
- You need to know what you want to do !!! (Believe me, thats not always clear for managers)
And not always clear for developers since there is no documentation.
But with this disadvantges you get a perfect working database (We have had no failure since now 5 Years with the native database)
That would be the least you expect from a database. The application on the other hand is crash-prone.
Debugger:
You are right for older Version (I know the bad debugger from the 2.01 Version I used before), but in 3.70 you can set breakpoints before.
But even with the old debugger you can work (not very comfortable, but not as bad as you mentioned if you use it correctly)
There is a very extensive documentation as PDF available (Look for PDF's on your Product CD's).
I've got it for Navision 2.01 but I don't need it very often. The CSIDE online help is usually enough.
If you are pure MS-Programmer and you expect an interface like Visual Studio you may be disappointed. But you don't need to do so much "low-level"-stuff with the CSIDE-Interface, because you have very powerful functionality built in. Otherwise you can create your own Code with the (documented) library for C. You may need this if you need to build interfaces to external devices like chipcard readers, machine-controllers e.g.
With the MS-Monopoly: Forst you have to use Windows. Then you should use a WinXY-Server, then you need the "Virus-Mutiplyer) Outlook, then the Office Package, the SQL-Server, the Exchange-Server (the nice try to replace sendmail) the Sharepoint-Services, BIZtalk, Update to 200x Versions, WinCE on Palms........ And after all you will be treated like a murder while one of your employees did not inform you about the installation of Visio on it's notebook. Nice to share your profits with MS.
I rather like to work for my company and try have alternatives (E.g. Linux in the backoffice, Lotus Notes for collaboration, openoffice for parts of the company) and use really open standards instead of MS-Standards.
And with the databases: Try to remove the power plug on a running SQL-Server, much luck. Try to exceed the reserved tablespace in other databases. Yes I expect no problem with the database, but I've seen many unexpected things in my live.
If I would have a task to choose a suitable solution, I would ask for some budget for analisys.
Navision can be good if you are immporting and wholesale company, and very bad if you need retail and manufacturing functionalities.
There are many parts that started to work properly only with fix 16 ver 3.60.
How many users ? What business you are in ?
How much money your client is willing to pay?
Here is one thing that realy stinksl - Security (user roles)in Navision are pure disaster. :roll:
It is pretty clear that Jesam is only talking from a developer kind of position. I am not sure what business your company is in, but I can only say 2 things:
1) Maybe you should reconsider getting a new NSC since there might something wrong with them
2) Your company didn't do enough research and was not clear enough about what you wanted in your selection period.
3) Consider a migration to 3.70 or wait for 4.00, lot of problems will be solved then.
With an installed base of over 130.000 it would be very strange saying it's a lousy product and it needs to fit in your company.
jesam, I would really like to know if you were forced into adopting Navision as an ERP. It sort of looks like it, you know...
You seem to be an IT person, maybe even one with decision-making responsibility.
Your company bought a software designed to automate every kind of business processes inside organizations. This is certainly not a decision to be made lightly.
You say you don't like Navision.
I say OK, it's your choice.
But please don't complain about something that your company should have investigated long before buying and deploying Navision.
Also, I believe that something like 80/90% of the bad situation you are in is because of your MBS-Partner and not Navision itself.
Most of the times, that's the case.
Maybe in your case, the best option would have been an internally developed .NET application. Do you think 2 years would have proved enough for that task?
Finally, it makes no sense to complain about features that Navision is not supposed to have.
Someone who wants to develop "real" applications uses Java, Visual Studio, (Assembler?)... whatever. Just not Navision.
Judging by the reactions, it seems that I have done the unthinkable, complain about Navision.
First of all, yes, I am a developer, and that is the main reason I don't like it. To a developer, developing with Navision is like driving a Trabant.
And yes, we did have a lousy NSC. we've already changed NSC, and the new one is better, but the amount of customization we have to do makes it unafordable to let that al be done by an NSC.
It is true that my company did not do enough research, but that is due to on hand the NSC promising VERY much in a complete urealistic timeframe and on the other hand an at that time a beheaded IT department (only one person left) that wasn't even involved in the decision to choose Navision. This means we who work here now are left to clean up the mess.
We are a manufacturing company and we have done already so much customization that an upgrade from 3.10 to a newer version is in itself a project that would take a year (at least). Given that the current version does not even work correct, this is a decision this company is never going to take, so we are stuck.
That is why I wrote that if you are willing to adapt the way your company works to the way Navision works, it might be an OK choice, but as soon as you want to make deep changes, you are in for a very expensive and uncontrollable project (at least in version 3.10).
If we would have doen this project in .NET (or in Java), we would not be any further right now, but, and that is the big difference, first of all we would have total control. If something breaks, we would know what breaks and why it breaks. We would have a decent debugger and a decent editor which are really as important as good tools are to a mechanic. Good tools don't mean a good job, but no good tools mean that it is very hard to do a good job. We would have a source control system so that we don't have to synchronize code manually if more than one developer works on it.
And second of all, we would have all the fundaments in place to build the rest of the system (something we now are still going to have to do).
As it stands now, managment realises that Navision is not the right tool for this job and if we ever manage to get sales on the road, we are going to do an inhouse .NET development for the other departments. As we are on SQL server, we still get to share data with Navision.
Now I'm of to work again, because we haven't been able to produce a correct invoice for the last two months and the last patch that our NSC delivered and that was installed yesterday now causes the bookig of invoices to fail. So I'm of again for a frustrating day of debugging ...
We have been in similar situation for the last three years where things were promised by the sales team of the NSC but never got delivered in time. And on the things that were finally delivered it became too expensive to get something changed. But for the last 6 months we are live on Navision on every area of our business. Mainly due to the new NSC that we have. There has been a comitted involvement from the management where they made changes in certain funtions of the business, which helped in our sucessful implementation.
From my experience there are mainly two reasons why an implementation goes wrong. The first and major reason is the NSC and the second is the user. The NSC that we had, did not understand our requirement or our business. They provide a solution which takes care of one thing, but fails in the other area. Each and every company is unique and has a certain way of doing business. And, thats the reason they are still in business. If only certain NSC's understand that before promising things. Then the users want eveything the same way they had before. The look & feel that they are used to. Plus, the new functions / features of Navision. Once the users get that and seeing newer things, new requirements come in. This goes on forever. Before in our older system the users could go in and make any kind of changes with no respect to the consequences. Now, those are the users who are not happy because they lost that ability. In Navision everything is balanced and controlled.
I feel Navision is a great tool and gives solutions to businesses. It is not made for programmers / developers. If anybody wants to customize something, the first thing to do is ask youself if there is an alternative. And customisation scenarios are true for any solutions like Navision. My suggestion stay away from customization, if not possible, do it areas which is not core objects of Navision. Always ask for complete documentation / version of the customization. Keep a demo company running where these customization are tried and tested by the end user. If they are not comfortable then dont even use it.
Well, my company is 1 of the NSC... and i am 1 of the developer that involved in the customization of this Navision.. So far, without any training, any proper documentation, it is a way very, very hard for me to learn and try to do the customization.
Customization seems hard... how do we actually find out which tables are related to each other? Lets say that we have modified a field length in a tables, how do we actually identify that the modification would actually affect other table? Sometimes, i just don't know until some error pops up while using the other part.
1 more thing that i am facing is that, while trying to run the program after some modification of the codes, sometimes, i got a syntax error problem. However, it doesn't point out which line actually giving the problem. I have to go through line by line just to figure out the problem line.
Are there any recommendation of what kind of documentations that i should have in order to help me do the development or customization work more efficiently? Sometimes, i also find that the knowledge of particular specific fields such as financials, accounting, sales, and etc are important in order to do the work better...
"Not everything can be judged by judging. Not everything can be seen by just seeing... Not all things can be understood thru understanding..."
You can use the MBS Navsion Developers Toolkit to find out where fields are used within the application. Mind that at present this Toolkit can only be used for analyzing, not for development. Maybe with the next version...
Still. it does take a long time to learn to estimate the long-term side effects
you customizing will have, but I am afraid there are no shortcuts to this.
Navision is often described as object-orientated, but this is nonsense and one of the reasons why large-scale modifications can take a long time.
Well, the quality of an ERP does not depend on the quality of the development environment, but it depends on the quality of the persons who use the development environment.
If I read your reaction 2 years ago, I would have fully agreed with you, really ... but now I'm more experienced, and I must admit ... you can do a lot more in Navision, in less time ! Untill now, the development environment hasn't pulled me back to do anything: I'm using dll's, I'm using SOAP, I'm fully using XML, ... .
I would advise Navision (and any software package in that category) only if you have a relatively small organization that does not do mucgh special things. From the moment you need to customize (beyond adding or removing a few fields in a few tables), your IT-ers will be VERY frustrated and the complete project becomes unmanageable.
Managing a Navision-project is not a simple task. You can't compare it with managing a VB.NET-project (yes, I also have a lot of .NET experience), but that doesn't mean that it's a bad thing. At least our NSC found a perfect method to manage our projects. We must say, at reasonable time we manage to complete our projects every time again.
Just one thing else ... developing in Navision requires much more functional knowledge (how does Navision work functionally and what do we have to do to bend it to customers' needs) than VB.NET. I mean, when developing in .NET (or any other language), you just have to mind your application you're writing, but when developing in Navision, you have to mind the functionality you're writing, PLUS you have to mind the Standard Navision functionality!!
Well, the quality of an ERP does not depend on the quality of the development environment,
True
but it depends on the quality of the persons who use the development environment.
Not true, it depends on the quality of the 'out-of-the-box' solution.
If I read your reaction 2 years ago, I would have fully agreed with you, really ... but now I'm more experienced, and I must admit ... you can do a lot more in Navision, in less time !
Maybe you are not working with v3.10.
Untill now, the development environment hasn't pulled me back to do anything: I'm using dll's, I'm using SOAP, I'm fully using XML, ... .
I have never stated that it is impossible to do. We use COM components to. It is however also possible to screw apart your car with a Swiss Army knife, but I'd rather have a professional toolkit (and I am only talking about the development environment here).
Just one thing else ... developing in Navision requires much more functional knowledge (how does Navision work functionally and what do we have to do to bend it to customers' needs) than VB.NET.
Of course it does, and that is the heart of the problem. There are virutally no sources to learn what is functionally already present in Navision, how it works, how the tables and the codeunits work together.
Also, the quality of the code is poor. Some CodeUnits perform user interaction, which makes it impossible to reuse them in automated tasks. Some functions span across 10 (TEN) printed pages (if you would write a function of that length in any computer-sience class you'd never get a grade), the code is sprinkled with global variables, and so on.
Some code parts are duplicated (for instance in T37 and T39 there are identical procedures called CalcVATAmountLines and UpdateVATAmountLines), so obviously the Single Point Of Definition principle is something they do not know at Navision.
I mean, when developing in .NET (or any other language), you just have to mind your application you're writing, but when developing in Navision, you have to mind the functionality you're writing, PLUS you have to mind the Standard Navision functionality!!
Well Jesam, it's a pity your NSC let you down. Navision is a great product. I accept that there are certain flaws - but all products have these. Yes, the development environment may not be the best, but one must always bear in mind that this environment was designed for a financial application.
I strongly disagree with you comment on the poor quality of programming. Five years ago when I started out with Navision, I did battle initially. Within less than two months however, I was able to do the development for an entire implementation by myself. The product is user friendly and easy to self-learn. The coding is consistent throughout - this makes different parts of code very easy to understand and follow once you have had experience in another section.
As far as your comments on how difficult it is to customize - once again I strongly disagree. I find it very easy to customize, and most development tasks do not take long either. We have many customers from a variety of industries. Many of these customers had very specific requirements that could not be found in any standard product and we were able to cater for them with Navision. We have been able to do so much with Navision. I just can't conceive how you can make a statement like
If you are not prepared to change the way your organization works to make it fit in Navision, forget it. Customizing is a VERY expensive process that reveals that the code behind Navsision really is very low quality.
I would really like to know how you can qualify that statement.
As far as the following comment:
Now we change something and if we actually find out how to technically do what we want to do, and we actually find out where to change waht we want to change, than we still need to cross our fingers because something completely different that happens to interact with what we changed is likely to break.
If you methodology is to make a change that might work and then cross your fingers, then yes, it's likely to break. The thing is, it's not Navision's fault if you don't do your testing properly.
I sounds to me that you have a negative attitude - forgive me if I'm wrong. There is no way that you'll make the product work for you if you're always trying to prove it to be at fault.
Fortunately, the majority of Navision users and developers to do not share your sentiments. The product is very comprehensive in terms of functionality (given it's target market), it's stable and the security is very comprehensive too. Once implemented, the administration of the system does not even need to be carried out by an IT professional.
As for your comments on the development environment - while it does have some flaws, it more that adequately serves the purpose for which it was intended.
Jesam, I think your experience is very typically with Navision.
The advantages are:
* It's very customizable
* It's quick
* It has a lot of specalized solutions
The disadvantages are:
* Code quality is more than poor
* No code documentation is available
* There is no documentation available for the data model
* If you pay 100$ for a customization, you have to pay 25 - 50 $ for each update of this customization
* The reports are more poor than the code quality. I haven't seen an ERP system with such spare reports. Mediocre is a quite good description.
* The system dependecies to other Microsoft products is growing by each version - together with your costs to operate.
* The programming tools are state of the art - but art of 1986 (looks like a composition of mainframe tools of mid 80s and the first character based IDEs for the PCs in mid 80s). You can see the Turbo Pascal basics (the start of Navision) very often.
* The complete system seems to be the DOS Version recompiled with an Windows extender.
* During a Microsoft Developers Conference the Microsoft people has announced, that this code is buried! There is no way for Microsoft or anyone else to take the code of this system and to transfer it to a modern software system.
* The main disadvantage is, that Microsoft isn't able to make a good support. Support from Navision / Denmark was really good, but Microsoft needs some years to learn the difference between a program like Word and an aplication like Navision.
If I have the possibility for a new decision I will never take Navision. It's to antiquated.
Has your company considered a technical upgrade of you navision database?
With this i mean that you upgrade your client and your server program from the 3.10 to the 3.70 version and leave the actual coding in the database 'as it is'.
To do so you have to upgrade your licence so that it is allowed to use the 3.70 client, you don't have to buy all the modules again.
Once this is done you can use the new debugger and you also profit from the increased stability of the client and the server program.
bglxx,
Code quality is more than poor
Can you define your standards of "Perfect" Code?
The only thing i agree with is that the report designer is of a poor quality.
Greetings,
Now, let's see what we can see.
...
Everybody on-line.
...
Looking good!
I am a bit confused. Do you mean by 'technical upgrade' that it is possible to leave *ALL* the code as it is now (3.10 + NSC code + our own code) and still upgrade to 3.7 (that would be an upgrade without the Objects then) ?
As far as I know our NSC has never spoken about this possibility.
Is it something that is officially supported by MBS/Navision ?
And is it something we could do ourselves or would our NSC have to perform this task for us ?
Anyway, I doubt very much that at this point the managment is willing to do more investments in Navision. The project is already more than a year late and costs are already much more than anticipated, so I doubt that asking for more investments with as the only argument the fact that we would be able to do our work better is a clever move. And although it would take away some of the frustration, it would not give us a better insight in how the different pieces of Navision hang together, it would not solve our NADA (Navision Architecture Documentation Absence).
Do you mean by 'technical upgrade' that it is possible to leave *ALL* the code as it is now (3.10 + NSC code + our own code) and still upgrade to 3.7 (that would be an upgrade without the Objects then) ?
Yes, you just install a new Navision Server version 3.70 which points to you existing DB and then connect to this new Server with a 3.70 client. I have done this for a lot of customers, going back to version 1.30, with the knowledge of MBS/Navision.
You can do this yourself, but I advise that a consultant is present.
In regard to the investment issue I can say the following. Normally your company pays a SLA (Service License Agreement) fee on a yearly basis. This fee also includes the access to service packs, new executable versions, etc without an extra cost.
But this doesn't apply for the upgrading of customized code and the work that comes with the actual upgrading of your existing objects (Merging, data conversion, etc, etc)
I've talked with a colleague of mine and we came to the conclusion that you do not need a licence upgrade to do this technical upgrade (from 3.10 to 3.70).
Greetings,
Now, let's see what we can see.
...
Everybody on-line.
...
Looking good!
We were using the Web Interface along with the UPS and Fedex add-ins and had modified 2.6 to support Size/Color Matrix's
Our NSC re-built our system in 3.6, and on the day of deployment we discovered that they used LOTS of ranges we weren't licensed for. $11,000 later we went production.
The Web Server still isn't online, 8 months later because the "Sync" tools didn't work as advertised and the web developer had to write them from scratch with our NSC (I have no idea how much that cost)
I'm afraid to even sugest 3.7, cause I don't have enough hair left on my head for that
Im sure for a large company (1000+) its a place to start. But for mid-sized companies, its so heavy a burden it could actually lead to some companies financial demise, trying to figure out its finances.
BTW, Microsoft Attain 3.6 will not install on Microsoft 2000 Terminal Server without a badly written batch file.. What TRULY amazes me about that is the whole "transform" concept has existed for Terminal Server for quite a long time. Where is my Attain-Transform.mst
I am not sure of this... but from the replies, I can see that most of you are saying that development and customization are pretty much easy... provided of course, you really understand in and out of the Navision...
BUT, the thing is, how long should i take up to learn all those thing? what kind of materials should i have in order for me to learn all those thing by myself? i am trying to explore the C/AL... but it seems like not very easy... hmmm... really need more practice...
Navision has a lot of functionality but you need to invest some time to learn about it. It is the same as if you join a .NET development company that developed its own ERP solution. You need some time to learn what they did so far too.
If you develop your own solution, you are the only one who can support it. Investment in Navision is much safer as there are other companies that can support it.
I always wondered whether developers in Denmark delete comments from the code before they release it? I know their support people don't have versions with comments. Does that mean they don't exist
For any serious customizations you need Navision Developers Toolkit and a lot of knowledge about functional areas. For developers that accept it, Navision can be a dream job (higher salary, easy job).
You can create a data model in Visio or some other tool. I used Visio and DBDesigner to create a full E/R model for Navision.
Other thing is workflow/process diagrams. They take much more effort. I currently work on one for manufacturing.
http://www.NaviTools.com
Documentation for Microsoft Navision
E/R diagrams, Workflow diagrams, UML diagrams, process diagrams
As a general rule I find that my customers are very happy with the financial systems, but less so with inventory costing.
The licensing is designed to suit Navision, but not their customers.
The standard database is very reliable and easy to maintain. (SQL is up to 25% slower and a pain to administer. Avoid it unless its a company standard or you want to use a third party report writer).
It's very easy to analyse data and find things.
Probably the most important thing is to have a very clear understanding of the business process and an NSC that understands the product and who can identify the most efficient way of implementing the business process. Navision is not a "Noddy" product. You have to know what you are doing from a design perspective.
As a Delphi, Java, C# and Navision developer I agree that there is a lot to wish for in Navision. However, when used correctly and with proper training in Navision development you can achieve great things.
In our company we have developed Automated testing for Navision and several other developer friendly tools. This greatly enhances productivity, quality and development time.
As for your complaints about bad Navision code ... I have seen terrible code in Delphi, Java, C# and VB. What else is new? More important does it make Navision a bad product?
Code reuse and refactoring is hard in any large project and I think you cannot disagree with me that Navision is a very large project. Just because you see problems in the Navision code does not mean it is the only bad product around.
For example: maybe the code in Windows or MS Office really stinks as well. (Just you cannot see it!) Both defininately have their share of bugs!
I have seen code from other projects that are shipped around the world which would make your head spin. Also if Navision would be such a lousy ERP tool, why would people be using it? Or do you think people like working with tools that do not work? Customers will never use a product if the product sucks. I have the feeling you would like to have control over the Navision code and because of the fact you do not you like to tear it down. Moreover I would like you to name a development tool that does not have debugger problems or does not crash ... Because I am still looking for that tool for the development in Java, Delphi and .NET projects.
I just think you are biased regarding Navision based on the bad expierences you've had in the past. Just like some Windows, Linux, MS Office, IE, Netscape and Mozilla users.
It's not bad to have an opinion, just facts tell that other tools are not always better and may have other issues ...
I would like to see you write a tool that could even compare to Navision.
In our company we have developed Automated testing for Navision and several other developer friendly tools. This greatly enhances productivity, quality and development time.
[...]
This sounds like an interesting topic. Maybe you can start another thread, discussing this subject? [-o<
No support using PM or e-mail - Please use this forum. BC TechDays 2024: 13 & 14 June 2024, Antwerp (Belgium)
Before I partnered up with Microsoft I was an end-user of Navision, I learned how to program in it and we scaled the company from $8 mil to $80 mil in 7 years. (Really good marketing) That was on versioin 1.0! Navision's great, but you have to know your business. If you don't know the details of your processes then there isn't a system out there that will help you. Granted the are good NSC's and bad, which is where the customer gets the short end of the stick, but for $100,000 and 6 months you can get an enterprise wide application with a pretty robust development environment, thats cheap to me!
Look at the competition MAS 90/200 yuck!!!
I have been setting up SQL Server views to improve Navision reporting. So far the speed seems very good and it greatly simplifies reporting.
The support for this goes back to Navision 2.6.
IF you are using SQL Server, I highly recommend taking a look at this.
the basic idea is this:
- create a view in sql server, and name it like navision with name a navision table.
- create a table in navision with the same fields as in the view, with the same datatypes.
- and if I remember correctly, the "LinkedObject" property on the table must be set to "yes".
Comments
The code editor and debugger are even not worthy of that name.
The NSC that started the Navision implementation here promised to get the job done in 4 months. We are almost two years later, and only one department (the finanace department where very litle customization has been done) is already operational on Navision.
I would advise Navision (and any software package in that category) only if you have a relatively small organization that does not do mucgh special things. From the moment you need to customize (beyond adding or removing a few fields in a few tables), your IT-ers will be VERY frustrated and the complete project becomes unmanageable.
I for one actually really hate it. In my previous job, I built a web-based payroll application in .NET. When we had to change something there, we had full control over everything. Now we change something and if we actually find out how to technically do what we want to do, and we actually find out where to change waht we want to change, than we still need to cross our fingers because something completely different that happens to interact with what we changed is likely to break.
I can't say I'm really happy with it.
I can't agree to the moaning of jesam, because you can do a really wide range of configuration and customizing by yourself with some experience.
For too small companies I would never recommend Navision (Too expensive). I think Navision fits best for mid-range sized companies (50-1000 employees). And -thats evtl. a disadvantage- you need at least one person inhouse with some programming skill who will do the inhouse customizing.
To do all and everything with the solution center can be an expensive job. But nevertheless, you will need a solution center for many other things.
Well, you are asking for disadvantages. What I can think about is:
- Many problems with managing different accounting systems (IAS/US-GAAP and (German HGB)
- Strange Licensing: You must buy a new range of free reports, tables, forms when you need them. This leads sometimes to bad table structures as you always try to use as less tables as possible (Normalization is expensive)
- Performance Limits: The Navision Server runs only on Windows, you can't scale up the same way like you do in Unix (I know Navision-Axapta is different)
- It's a Microsoft Product (Which is basically no problem, but it extends the monopole of MS dramatically)
- You need to know what you want to do !!! (Believe me, thats not always clear for managers)
But with this disadvantges you get a perfect working database (We have had no failure since now 5 Years with the native database) and a very good tool for managing and reporting your business. Especially the SIFT-Technology (Sum Index Flow technology) is great when you know how to handle with it (I's faster than many OLAP-Databases and you have real time access to your data)
When I say that the editor and the dbugger are not wothy of that name, I have a reason to say that.
Debugging :
* It is impossible to set a breakpoint in the debugger before the debugging has started.
* When the debugging has started, it is impossible to do a find in the source code.
* When the debugging has started, the procedures are not in the same order as they appear in the code window.
* It is impossible to step over a function (the menu item exists but does not work).
* When debugging, the code window does not show the definitions of the procedure parameters, only their name.
* It is impossible to do a watch of local and global variables at the same time.
Editor :
* The code that is shown depends on what is slected on the form. There is no way to show all the code of the form.
* It is impossible to selcet a word by double clicking in the editor.
* It is impossible to have a 'flat' code window. Each variable must be declared in a special window. The declaration of local variables can only be seen in that window. This means that when coding or debugging you can not see which variables are declared. This also means that if you refactor and move some code over form one procedure to another, you need to move over the local variables sperately. I gues this is the main reason that the Navision code is full of Global Variables, something that they teach ITers not to do in their first lesson in school.
* You cannot enter lines longer than (have not counted) characters. After that, you need to switch to a new line (this is a limitation that other develometn environments have fixed since 10 years).
* The procedure headings are shown as a grey bar. Unfortunately, they even show less characters, which means that if you have long variable names and more that 3 parameters, the complete procedure heading is not shown. VERY anoying.
I could go on, but I think this proves that even Turbo Pascal 4.0, whoch must be 15+ years old, had a better debugger and editor.
The only problem is, since there is no documentation, that person is lost if he/she needs to do more than addign labels and fields.
The online help is virtually useless and sometimes plain wrong.
At 600 to 700 € a day per person, that becomes very expensive very fast.
Well, MS bought it, but I would never call it a MS product. MS products are of much better quality and are way better documented. As for the monopoly (what does that have to do with anything), as far as I know MS has far from a monopoluy in this market.
And not always clear for developers since there is no documentation.
That would be the least you expect from a database. The application on the other hand is crash-prone.
You are right for older Version (I know the bad debugger from the 2.01 Version I used before), but in 3.70 you can set breakpoints before.
But even with the old debugger you can work (not very comfortable, but not as bad as you mentioned if you use it correctly)
There is a very extensive documentation as PDF available (Look for PDF's on your Product CD's).
I've got it for Navision 2.01 but I don't need it very often. The CSIDE online help is usually enough.
If you are pure MS-Programmer and you expect an interface like Visual Studio you may be disappointed. But you don't need to do so much "low-level"-stuff with the CSIDE-Interface, because you have very powerful functionality built in. Otherwise you can create your own Code with the (documented) library for C. You may need this if you need to build interfaces to external devices like chipcard readers, machine-controllers e.g.
With the MS-Monopoly: Forst you have to use Windows. Then you should use a WinXY-Server, then you need the "Virus-Mutiplyer) Outlook, then the Office Package, the SQL-Server, the Exchange-Server (the nice try to replace sendmail) the Sharepoint-Services, BIZtalk, Update to 200x Versions, WinCE on Palms........ And after all you will be treated like a murder while one of your employees did not inform you about the installation of Visio on it's notebook. Nice to share your profits with MS.
I rather like to work for my company and try have alternatives (E.g. Linux in the backoffice, Lotus Notes for collaboration, openoffice for parts of the company) and use really open standards instead of MS-Standards.
And with the databases: Try to remove the power plug on a running SQL-Server, much luck. Try to exceed the reserved tablespace in other databases. Yes I expect no problem with the database, but I've seen many unexpected things in my live.
Navision can be good if you are immporting and wholesale company, and very bad if you need retail and manufacturing functionalities.
There are many parts that started to work properly only with fix 16 ver 3.60.
How many users ? What business you are in ?
How much money your client is willing to pay?
Here is one thing that realy stinksl - Security (user roles)in Navision are pure disaster. :roll:
1) Maybe you should reconsider getting a new NSC since there might something wrong with them
2) Your company didn't do enough research and was not clear enough about what you wanted in your selection period.
3) Consider a migration to 3.70 or wait for 4.00, lot of problems will be solved then.
With an installed base of over 130.000 it would be very strange saying it's a lousy product and it needs to fit in your company.
Cheers
Erik
You seem to be an IT person, maybe even one with decision-making responsibility.
Your company bought a software designed to automate every kind of business processes inside organizations. This is certainly not a decision to be made lightly.
You say you don't like Navision.
I say OK, it's your choice.
But please don't complain about something that your company should have investigated long before buying and deploying Navision.
Also, I believe that something like 80/90% of the bad situation you are in is because of your MBS-Partner and not Navision itself.
Most of the times, that's the case.
Maybe in your case, the best option would have been an internally developed .NET application. Do you think 2 years would have proved enough for that task?
Finally, it makes no sense to complain about features that Navision is not supposed to have.
Someone who wants to develop "real" applications uses Java, Visual Studio, (Assembler?)... whatever. Just not Navision.
First of all, yes, I am a developer, and that is the main reason I don't like it. To a developer, developing with Navision is like driving a Trabant.
And yes, we did have a lousy NSC. we've already changed NSC, and the new one is better, but the amount of customization we have to do makes it unafordable to let that al be done by an NSC.
It is true that my company did not do enough research, but that is due to on hand the NSC promising VERY much in a complete urealistic timeframe and on the other hand an at that time a beheaded IT department (only one person left) that wasn't even involved in the decision to choose Navision. This means we who work here now are left to clean up the mess.
We are a manufacturing company and we have done already so much customization that an upgrade from 3.10 to a newer version is in itself a project that would take a year (at least). Given that the current version does not even work correct, this is a decision this company is never going to take, so we are stuck.
That is why I wrote that if you are willing to adapt the way your company works to the way Navision works, it might be an OK choice, but as soon as you want to make deep changes, you are in for a very expensive and uncontrollable project (at least in version 3.10).
If we would have doen this project in .NET (or in Java), we would not be any further right now, but, and that is the big difference, first of all we would have total control. If something breaks, we would know what breaks and why it breaks. We would have a decent debugger and a decent editor which are really as important as good tools are to a mechanic. Good tools don't mean a good job, but no good tools mean that it is very hard to do a good job. We would have a source control system so that we don't have to synchronize code manually if more than one developer works on it.
And second of all, we would have all the fundaments in place to build the rest of the system (something we now are still going to have to do).
As it stands now, managment realises that Navision is not the right tool for this job and if we ever manage to get sales on the road, we are going to do an inhouse .NET development for the other departments. As we are on SQL server, we still get to share data with Navision.
Now I'm of to work again, because we haven't been able to produce a correct invoice for the last two months and the last patch that our NSC delivered and that was installed yesterday now causes the bookig of invoices to fail. So I'm of again for a frustrating day of debugging ...
Regards.
From my experience there are mainly two reasons why an implementation goes wrong. The first and major reason is the NSC and the second is the user. The NSC that we had, did not understand our requirement or our business. They provide a solution which takes care of one thing, but fails in the other area. Each and every company is unique and has a certain way of doing business. And, thats the reason they are still in business. If only certain NSC's understand that before promising things. Then the users want eveything the same way they had before. The look & feel that they are used to. Plus, the new functions / features of Navision. Once the users get that and seeing newer things, new requirements come in. This goes on forever. Before in our older system the users could go in and make any kind of changes with no respect to the consequences. Now, those are the users who are not happy because they lost that ability. In Navision everything is balanced and controlled.
I feel Navision is a great tool and gives solutions to businesses. It is not made for programmers / developers. If anybody wants to customize something, the first thing to do is ask youself if there is an alternative. And customisation scenarios are true for any solutions like Navision. My suggestion stay away from customization, if not possible, do it areas which is not core objects of Navision. Always ask for complete documentation / version of the customization. Keep a demo company running where these customization are tried and tested by the end user. If they are not comfortable then dont even use it.
...
...
Love, Light & Peace
Customization seems hard... how do we actually find out which tables are related to each other? Lets say that we have modified a field length in a tables, how do we actually identify that the modification would actually affect other table? Sometimes, i just don't know until some error pops up while using the other part.
1 more thing that i am facing is that, while trying to run the program after some modification of the codes, sometimes, i got a syntax error problem. However, it doesn't point out which line actually giving the problem. I have to go through line by line just to figure out the problem line.
Are there any recommendation of what kind of documentations that i should have in order to help me do the development or customization work more efficiently? Sometimes, i also find that the knowledge of particular specific fields such as financials, accounting, sales, and etc are important in order to do the work better...
"Not everything can be judged by judging. Not everything can be seen by just seeing... Not all things can be understood thru understanding..."
Still. it does take a long time to learn to estimate the long-term side effects
you customizing will have, but I am afraid there are no shortcuts to this.
Navision is often described as object-orientated, but this is nonsense and one of the reasons why large-scale modifications can take a long time.
seems like you're not happy with Navision?
Well, the quality of an ERP does not depend on the quality of the development environment, but it depends on the quality of the persons who use the development environment.
If I read your reaction 2 years ago, I would have fully agreed with you, really ... but now I'm more experienced, and I must admit ... you can do a lot more in Navision, in less time ! Untill now, the development environment hasn't pulled me back to do anything: I'm using dll's, I'm using SOAP, I'm fully using XML, ... .
Managing a Navision-project is not a simple task. You can't compare it with managing a VB.NET-project (yes, I also have a lot of .NET experience), but that doesn't mean that it's a bad thing. At least our NSC found a perfect method to manage our projects. We must say, at reasonable time we manage to complete our projects every time again.
Just one thing else ... developing in Navision requires much more functional knowledge (how does Navision work functionally and what do we have to do to bend it to customers' needs) than VB.NET. I mean, when developing in .NET (or any other language), you just have to mind your application you're writing, but when developing in Navision, you have to mind the functionality you're writing, PLUS you have to mind the Standard Navision functionality!!
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
True
Not true, it depends on the quality of the 'out-of-the-box' solution.
Maybe you are not working with v3.10.
I have never stated that it is impossible to do. We use COM components to. It is however also possible to screw apart your car with a Swiss Army knife, but I'd rather have a professional toolkit (and I am only talking about the development environment here).
Of course it does, and that is the heart of the problem. There are virutally no sources to learn what is functionally already present in Navision, how it works, how the tables and the codeunits work together.
Also, the quality of the code is poor. Some CodeUnits perform user interaction, which makes it impossible to reuse them in automated tasks. Some functions span across 10 (TEN) printed pages (if you would write a function of that length in any computer-sience class you'd never get a grade), the code is sprinkled with global variables, and so on.
Some code parts are duplicated (for instance in T37 and T39 there are identical procedures called CalcVATAmountLines and UpdateVATAmountLines), so obviously the Single Point Of Definition principle is something they do not know at Navision.
Which is sadly undocumented.
I strongly disagree with you comment on the poor quality of programming. Five years ago when I started out with Navision, I did battle initially. Within less than two months however, I was able to do the development for an entire implementation by myself. The product is user friendly and easy to self-learn. The coding is consistent throughout - this makes different parts of code very easy to understand and follow once you have had experience in another section.
As far as your comments on how difficult it is to customize - once again I strongly disagree. I find it very easy to customize, and most development tasks do not take long either. We have many customers from a variety of industries. Many of these customers had very specific requirements that could not be found in any standard product and we were able to cater for them with Navision. We have been able to do so much with Navision. I just can't conceive how you can make a statement like
I would really like to know how you can qualify that statement.
As far as the following comment:
If you methodology is to make a change that might work and then cross your fingers, then yes, it's likely to break. The thing is, it's not Navision's fault if you don't do your testing properly.
I sounds to me that you have a negative attitude - forgive me if I'm wrong. There is no way that you'll make the product work for you if you're always trying to prove it to be at fault.
Fortunately, the majority of Navision users and developers to do not share your sentiments. The product is very comprehensive in terms of functionality (given it's target market), it's stable and the security is very comprehensive too. Once implemented, the administration of the system does not even need to be carried out by an IT professional.
As for your comments on the development environment - while it does have some flaws, it more that adequately serves the purpose for which it was intended.
The advantages are:
* It's very customizable
* It's quick
* It has a lot of specalized solutions
The disadvantages are:
* Code quality is more than poor
* No code documentation is available
* There is no documentation available for the data model
* If you pay 100$ for a customization, you have to pay 25 - 50 $ for each update of this customization
* The reports are more poor than the code quality. I haven't seen an ERP system with such spare reports. Mediocre is a quite good description.
* The system dependecies to other Microsoft products is growing by each version - together with your costs to operate.
* The programming tools are state of the art - but art of 1986 (looks like a composition of mainframe tools of mid 80s and the first character based IDEs for the PCs in mid 80s). You can see the Turbo Pascal basics (the start of Navision) very often.
* The complete system seems to be the DOS Version recompiled with an Windows extender.
* During a Microsoft Developers Conference the Microsoft people has announced, that this code is buried! There is no way for Microsoft or anyone else to take the code of this system and to transfer it to a modern software system.
* The main disadvantage is, that Microsoft isn't able to make a good support. Support from Navision / Denmark was really good, but Microsoft needs some years to learn the difference between a program like Word and an aplication like Navision.
If I have the possibility for a new decision I will never take Navision. It's to antiquated.
Has your company considered a technical upgrade of you navision database?
With this i mean that you upgrade your client and your server program from the 3.10 to the 3.70 version and leave the actual coding in the database 'as it is'.
To do so you have to upgrade your licence so that it is allowed to use the 3.70 client, you don't have to buy all the modules again.
Once this is done you can use the new debugger and you also profit from the increased stability of the client and the server program.
bglxx,
Can you define your standards of "Perfect" Code?
The only thing i agree with is that the report designer is of a poor quality.
Greetings,
...
Everybody on-line.
...
Looking good!
As far as I know our NSC has never spoken about this possibility.
Is it something that is officially supported by MBS/Navision ?
And is it something we could do ourselves or would our NSC have to perform this task for us ?
Anyway, I doubt very much that at this point the managment is willing to do more investments in Navision. The project is already more than a year late and costs are already much more than anticipated, so I doubt that asking for more investments with as the only argument the fact that we would be able to do our work better is a clever move. And although it would take away some of the frustration, it would not give us a better insight in how the different pieces of Navision hang together, it would not solve our NADA (Navision Architecture Documentation Absence).
Yes, you just install a new Navision Server version 3.70 which points to you existing DB and then connect to this new Server with a 3.70 client. I have done this for a lot of customers, going back to version 1.30, with the knowledge of MBS/Navision.
You can do this yourself, but I advise that a consultant is present.
In regard to the investment issue I can say the following. Normally your company pays a SLA (Service License Agreement) fee on a yearly basis. This fee also includes the access to service packs, new executable versions, etc without an extra cost.
But this doesn't apply for the upgrading of customized code and the work that comes with the actual upgrading of your existing objects (Merging, data conversion, etc, etc)
I've talked with a colleague of mine and we came to the conclusion that you do not need a licence upgrade to do this technical upgrade (from 3.10 to 3.70).
Greetings,
...
Everybody on-line.
...
Looking good!
We were using the Web Interface along with the UPS and Fedex add-ins and had modified 2.6 to support Size/Color Matrix's
Our NSC re-built our system in 3.6, and on the day of deployment we discovered that they used LOTS of ranges we weren't licensed for. $11,000 later we went production.
The Web Server still isn't online, 8 months later because the "Sync" tools didn't work as advertised and the web developer had to write them from scratch with our NSC (I have no idea how much that cost)
I'm afraid to even sugest 3.7, cause I don't have enough hair left on my head for that
Im sure for a large company (1000+) its a place to start. But for mid-sized companies, its so heavy a burden it could actually lead to some companies financial demise, trying to figure out its finances.
BTW, Microsoft Attain 3.6 will not install on Microsoft 2000 Terminal Server without a badly written batch file.. What TRULY amazes me about that is the whole "transform" concept has existed for Terminal Server for quite a long time. Where is my Attain-Transform.mst
BUT, the thing is, how long should i take up to learn all those thing? what kind of materials should i have in order for me to learn all those thing by myself? i am trying to explore the C/AL... but it seems like not very easy... hmmm... really need more practice...
Navision has a lot of functionality but you need to invest some time to learn about it. It is the same as if you join a .NET development company that developed its own ERP solution. You need some time to learn what they did so far too.
If you develop your own solution, you are the only one who can support it. Investment in Navision is much safer as there are other companies that can support it.
I always wondered whether developers in Denmark delete comments from the code before they release it? I know their support people don't have versions with comments. Does that mean they don't exist
For any serious customizations you need Navision Developers Toolkit and a lot of knowledge about functional areas. For developers that accept it, Navision can be a dream job (higher salary, easy job).
You can create a data model in Visio or some other tool. I used Visio and DBDesigner to create a full E/R model for Navision.
Other thing is workflow/process diagrams. They take much more effort. I currently work on one for manufacturing.
Documentation for Microsoft Navision
E/R diagrams, Workflow diagrams, UML diagrams, process diagrams
The licensing is designed to suit Navision, but not their customers.
The standard database is very reliable and easy to maintain. (SQL is up to 25% slower and a pain to administer. Avoid it unless its a company standard or you want to use a third party report writer).
It's very easy to analyse data and find things.
Probably the most important thing is to have a very clear understanding of the business process and an NSC that understands the product and who can identify the most efficient way of implementing the business process. Navision is not a "Noddy" product. You have to know what you are doing from a design perspective.
In our company we have developed Automated testing for Navision and several other developer friendly tools. This greatly enhances productivity, quality and development time.
As for your complaints about bad Navision code ... I have seen terrible code in Delphi, Java, C# and VB. What else is new? More important does it make Navision a bad product?
Code reuse and refactoring is hard in any large project and I think you cannot disagree with me that Navision is a very large project. Just because you see problems in the Navision code does not mean it is the only bad product around.
For example: maybe the code in Windows or MS Office really stinks as well. (Just you cannot see it!) Both defininately have their share of bugs!
I have seen code from other projects that are shipped around the world which would make your head spin. Also if Navision would be such a lousy ERP tool, why would people be using it? Or do you think people like working with tools that do not work? Customers will never use a product if the product sucks. I have the feeling you would like to have control over the Navision code and because of the fact you do not you like to tear it down. Moreover I would like you to name a development tool that does not have debugger problems or does not crash ... Because I am still looking for that tool for the development in Java, Delphi and .NET projects.
I just think you are biased regarding Navision based on the bad expierences you've had in the past. Just like some Windows, Linux, MS Office, IE, Netscape and Mozilla users.
It's not bad to have an opinion, just facts tell that other tools are not always better and may have other issues ...
I would like to see you write a tool that could even compare to Navision.
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
This sounds like an interesting topic. Maybe you can start another thread, discussing this subject? [-o<
Look at the competition MAS 90/200 yuck!!!
The support for this goes back to Navision 2.6.
IF you are using SQL Server, I highly recommend taking a look at this.
http://mibuso.com/blogs/davidmachanick/
How would I go about setting and using SQL server views for Navision reporting. Any information you can give me would be appreciated.
Thanks,
Dneal
- create a view in sql server, and name it like navision with name a navision table.
- create a table in navision with the same fields as in the view, with the same datatypes.
- and if I remember correctly, the "LinkedObject" property on the table must be set to "yes".
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog