I can understand you don't like BlackTiger remarks (sometimes) but his opinion, remarks and criticisme are still very usefull to get the full picture about things. Please keep posting both of you.
I can understand you don't like BlackTiger remarks (sometimes) but his opinion, remarks and criticisme are still very usefull to get the full picture about things. Please keep posting both of you.
...
...
I am who I am. And believe me, it's not difficult for me to repeat my blaming of lack of Unicode support in NAV again, again and again. IT'S BLOODY 21ST CENTURY!
BlackTiger!!
Have you ever implemented real Unicode ERP using Estonian, Latvian. Russian, Latin language?
Can you deliver us what features and LIMITATIONS comes with unicode usage?
When you deliver REAL reasons why customer needs unicode, then i can discuss with you.
"Bloody 21st century" is not reason to blaming NAV.
I don't think anybody at Microsoft thinks that Unicode is a bad thing and I am sure that it will find its way into the product in the future (no promises given of course). Fact is just that adding Unicode support to the Classic Client would be a huge effort - and things just becomes easier when moving to the managed world (NAV 2009) where we get more things from the framework.
So you can see NAV 2009 as the first step on the journey to an updated platform for NAV, including stuff like unicode.
If you ask whether NAV 2009 is the endpoint of that journey - the answer is clearly No - but IMO it is a huge step in the right direction, and Microsoft will continue to invest in the development of Microsoft Dynamics NAV.
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
besides, cant say that unicode is on top of our wishlist. Just give us all localisations (for europe for a start) in one database and the dynamics client for office for sharepoint, and happy faces are there...
Just add my "2 cents" as consultant/developer who needed unicode with russians/latvians/lithuanians, claimed Navision because of not supporting unicode etc...
So BlackTiger example: Russians want to see reports in russian. Supper wish. Lets take customer list. Customers have Latin names. Of course russian want to see cyrilic characters in names, but latvian want to see Latin+Latvian characters and Greeks want to have greek... There unicode will not help - we need few fields to enter customer name/translation in different languages. The only point unicode resolves - these fields could be in the same table. Today NAV solution could be use SSRS and get names from another db. Actually it works in my customer site.
Lets imagine we have unicode NAV and have few different fields with different names, how to use "search name" functionality - do we need few different languages search names fields. I guess russians want "search name" to using russian language, what about latvians, greeks...?
Next point:
How to be sorted customers by names if it is: ABC, BCA, CBA. Now it looks simple for peaople who don't know cyrilic. Because cyrylic C equal to latin S and in Russian will be sorted somewhere in the midle of name list (A....O,P,S!!!!,R...) as we expecting it must be in the begining of name lists. And all letters looks the same: are it russian or Latin - only PC knows what codepage is behind it.
If for example customer has name starting "West" in russian it will be "Bect". In russian Language letter B is 3rd letter in alphabet, so customer will be in the beginning in list in Russian language and in the end of list in Latin language.
Lets imagine user want to sort, filter etc on customer list - result depends on what keyboard layout was used when user entered customer name. For example in Lithiania usually users have 3 layouts: Lithiaunian, English US, Russian. And customer name like CBA enterer with different keyboard will be sorted differently. Moreower we can have 2 customers CBA; one entered with russian layout, one with Latin layout, both looks the same but from unicode it are different.
So what is limitation: we can't use chars in fields used in keys. Simple??? But all nav is based on this now, all users working with this functionality and are happy.
Of course unicode is future, but it isn't just option in db: use unicode or don't use; unicode requires absolutely different NAV: different view, different work style, different functionality (maybe like AX ).
And i don't know what i like more: current NAV style or next NAV with unicode.
Just add my "2 cents" as consultant/developer who needed unicode with russians/latvians/lithuanians, claimed Navision because of not supporting unicode etc...
We also had a lots of doubts about the DCO. In fact I was desperately searching ](*,) for those web parts in the sharepoint portal in the VPC, as we were looking for such a solution for a long time to overcome the hell lot of limitations of employee portal. But it seems that the DCO client is not immediately available with NAV 2009. Can anyone tell me the possible release date of the DCO?
littleoaks wrote:
IF every page was available as a web part for sharepoint (with all the links and functionality) and the pricing was based upon employee portal (DCO - WSS / DCO - MOSS) then why would people pay the full price for classic client or RTC?
Great question =D> littleoaks. I was exactly having the same question after seeing the demo, and looking for a positive answar.
Thanks littleoaks and all for clarifying many the doubts through this post..
Then what is the point of including it in the NAV 2009 sales demo???????
The new price list (in the demo ppt) is saying that DCO components are available from Jan 2009. Infact the end customers are looking for upgrading NAV mostly for this feature only? RTC does not seem to have that much impact than the web services/3T and especially DCO - WSS/MOSS....
A ready (and steady) 'WEB BASED NAV' (not employee portal) is what everyone is looking for...
Same question here, however: it's not in your VPC, just in the video. As to the DCO in the price sheet: that's just the licensing of external users, not functionality... Count on the fact it will not be in SP1 of NAV 2009, then it can only become better if it does...
The aim is not to have a web based NAV (like Outlook Web Access), the aim is for our partners and users to integrate more deeply into Sharepoint where it makes sense.
So instead of having users doing all their work in Sharepoint - you will have some users, doing some of their tasks in Sharepoint - because it makes sense.
I cannot imagine the Order Processor doing heads down data entry in a web based Client.
So when we have demoed that you can reuse the pages in Sharepoint, it is because our new architecture allows us to do so - and when/if we ship that functionality there still will be things you cannot do in Sharepoint (like there are things you cannot do with pages through Web Services).
I also think we want deeper integration with Sharepoint than just rendering our pages in Sharepoint - unless we are targetting a user who is in the airport needing to reach his NAV installation.
So stay tuned - I am sure this is going to be worth waiting for.
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
Freddy, with all do respect, but for some roles we do want to just render pages from NAV in Sharepoint. Imagine all the work done at this moment to build custom GUI's to facilitate light users! You can not oversee this, believe me. Imagine a project manager just having to go through all the hours of his project members on monday morning, or an employee changing his adress.
We now have to offer concurrent users at full price for for example these projectmanagers, where our competition does this for a price 8 times lower! than we...
This, along with internationalisation, should be the only thing at the development roadmap, along with stabilizing NAV 2009...
A ready (and steady) 'WEB BASED NAV' (not employee portal) is what everyone is looking for...
Tell me what... Do you want "web based NAV" or you want "cheap NAV"? Will you/anyone buy "web based NAV" with current pricing?
The general assumption before the release of NAV 2009 was the RTC is going to be a browser based client (somthing like the way 'MS CRM' works) rather another windows client. You must be knowing how 'MS CRM' works where all you need to access your complete application is the Internet Explorer and Connection and the entire application is open in front of you from anywhere in the world. I am not sure about how the licensing policies should be in that case. But this is something which most of the prospects/customers at least in India are looking for even at the cost of same price (or may be more than that).
The web service option seems to be useful, but again a good amount of development effort is required to use it.
But the way, the SharePoint integration (DCO) has been demonstrated in the demo video seems to be very useful and attractive. We can simple develop pages (or convert any forms to pages) in NAV and all we need to do is to add those pages as web parts in the SharePoint and any process of NAV (with all it's business logic) can be accessed over the web. I think, to some extent, we can achive a 'web based NAV' through this option especially for the light users and MIS users.
Amitava, we never had the assumption that it was a browserbased client, Microsoft told from the start that this would become a "fat" client. And maybe to clear some things: the sharepoint capabilities of the demo video are not present in the upcoming release...
Freddy, with all do respect, but for some roles we do want to just render pages from NAV in Sharepoint.
I agree - and this is also what we have demoed. I simply state that it might not be a goal to be able to do everything in a browser - some roles will never use a browser. I know that people in the Product team will be starting now, to look into requirements for this, in order to make it right.
The general assumption before the release of NAV 2009 was the RTC is going to be a browser based client (somthing like the way 'MS CRM' works) rather another windows client.
That has never been the plan. NAV 2009 ships with a new totally metadata driven client, where we have removed the code, which interacts closely with the pages from the pages - in order to allow us to refactor the client, make webservice and do stuff like Sharepoint, Silverlight or whatever in the future.
the sharepoint capabilities of the demo video are not present in the upcoming release...
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
The general assumption before the release of NAV 2009 was the RTC is going to be a browser based client
Maybe that's been YOUR assumption, but that doesn't make it a general assumption. It certainly has NEVER been communicated by Microsoft that way.
Some people on this board knew the real story, and saw all the rumors fly around, and really wanted to set the record straight, because we knew that this kind of discussion would happen, but were told not to say anything about it because of NDA.
Maybe that's been YOUR assumption, but that doesn't make it a general assumption. It certainly has NEVER been communicated by Microsoft that way.
Daniel, I may be wrong as I really didn't know the 'real story', but what I meant by 'general' is most of the partners and customers in India only and not the rest of the world. Actually we, as a partner, attended an event on the upcoming NAV 2009 few 7/8 months back from where the 'wrong' assumption came from. But as everythig was verbally communicated, I really can't prove it or we might really misunderstood the concept as the product was still on the development phase.
Anyway, thanks for your clarity, and forgive me if you feel my point should not be a part of this topic.
Amitava, we never had the assumption that it was a browserbased client, Microsoft told from the start that this would become a "fat" client. And maybe to clear some things: the sharepoint capabilities of the demo video are not present in the upcoming release...
forgive me if you feel my point should not be a part of this topic.
Your point should absolutely be a part of this discussion You clearly had a misunderstanding, and the purpose of forums like these is to inform people. We could discuss the manner in which that happened, but a lot of that is lost in translation too I think.
Comments
RIS Plus, LLC
- http://www.mibuso.com/forum/viewtopic.php?f=32&t=28679&st=0&sk=t&sd=a&hilit=unicode&start=15
- http://www.mibuso.com/forum/viewtopic.php?f=32&t=28112&hilit=unicode
- http://www.mibuso.com/forum/viewtopic.php?f=23&t=28148&hilit=unicode
- http://www.mibuso.com/forum/viewtopic.php?f=32&t=25606&st=0&sk=t&sd=a&hilit=unicode&start=20$hilit=unicode
- http://www.mibuso.com/forum/viewtopic.php?f=32&t=22245&st=0&sk=t&sd=a&hilit=unicode&start=30
- http://www.mibuso.com/forum/viewtopic.php?f=7&t=22120&hilit=unicode
- http://www.mibuso.com/forum/viewtopic.php?f=23&t=14672&hilit=unicode
- http://www.mibuso.com/forum/viewtopic.php?f=23&t=13525&hilit=unicode
- http://www.mibuso.com/forum/viewtopic.php?f=23&t=15894&hilit=unicode
... little bit boring in my opinion. But other then that ... the critisism (no matter how it's "brought") keeps everyone alert ... and that's for sure a positive thing.
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
BlackTiger!!
Have you ever implemented real Unicode ERP using Estonian, Latvian. Russian, Latin language?
Can you deliver us what features and LIMITATIONS comes with unicode usage?
When you deliver REAL reasons why customer needs unicode, then i can discuss with you.
"Bloody 21st century" is not reason to blaming NAV.
So you can see NAV 2009 as the first step on the journey to an updated platform for NAV, including stuff like unicode.
If you ask whether NAV 2009 is the endpoint of that journey - the answer is clearly No - but IMO it is a huge step in the right direction, and Microsoft will continue to invest in the development of Microsoft Dynamics NAV.
Group Program Manager, Client
Microsoft Dynamics NAV
http://blogs.msdn.com/freddyk
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
So BlackTiger example: Russians want to see reports in russian. Supper wish. Lets take customer list. Customers have Latin names. Of course russian want to see cyrilic characters in names, but latvian want to see Latin+Latvian characters and Greeks want to have greek... There unicode will not help - we need few fields to enter customer name/translation in different languages. The only point unicode resolves - these fields could be in the same table. Today NAV solution could be use SSRS and get names from another db. Actually it works in my customer site.
Lets imagine we have unicode NAV and have few different fields with different names, how to use "search name" functionality - do we need few different languages search names fields. I guess russians want "search name" to using russian language, what about latvians, greeks...?
Next point:
How to be sorted customers by names if it is: ABC, BCA, CBA. Now it looks simple for peaople who don't know cyrilic. Because cyrylic C equal to latin S and in Russian will be sorted somewhere in the midle of name list (A....O,P,S!!!!,R...) as we expecting it must be in the begining of name lists. And all letters looks the same: are it russian or Latin - only PC knows what codepage is behind it.
If for example customer has name starting "West" in russian it will be "Bect". In russian Language letter B is 3rd letter in alphabet, so customer will be in the beginning in list in Russian language and in the end of list in Latin language.
Lets imagine user want to sort, filter etc on customer list - result depends on what keyboard layout was used when user entered customer name. For example in Lithiania usually users have 3 layouts: Lithiaunian, English US, Russian. And customer name like CBA enterer with different keyboard will be sorted differently. Moreower we can have 2 customers CBA; one entered with russian layout, one with Latin layout, both looks the same but from unicode it are different.
So what is limitation: we can't use chars in fields used in keys. Simple??? But all nav is based on this now, all users working with this functionality and are happy.
Of course unicode is future, but it isn't just option in db: use unicode or don't use; unicode requires absolutely different NAV: different view, different work style, different functionality (maybe like AX ).
And i don't know what i like more: current NAV style or next NAV with unicode.
Sorry for long "2 cents" :oops: #-o
=D> wow great explanation.
So just explain instead of claiming :?
Well Said
We also had a lots of doubts about the DCO. In fact I was desperately searching ](*,) for those web parts in the sharepoint portal in the VPC, as we were looking for such a solution for a long time to overcome the hell lot of limitations of employee portal. But it seems that the DCO client is not immediately available with NAV 2009. Can anyone tell me the possible release date of the DCO?
littleoaks wrote:
IF every page was available as a web part for sharepoint (with all the links and functionality) and the pricing was based upon employee portal (DCO - WSS / DCO - MOSS) then why would people pay the full price for classic client or RTC?
Great question =D> littleoaks. I was exactly having the same question after seeing the demo, and looking for a positive answar.
Thanks littleoaks and all for clarifying many the doubts through this post..
Amitava.
New Delhi, India
The new price list (in the demo ppt) is saying that DCO components are available from Jan 2009. Infact the end customers are looking for upgrading NAV mostly for this feature only? RTC does not seem to have that much impact than the web services/3T and especially DCO - WSS/MOSS....
A ready (and steady) 'WEB BASED NAV' (not employee portal) is what everyone is looking for...
So instead of having users doing all their work in Sharepoint - you will have some users, doing some of their tasks in Sharepoint - because it makes sense.
I cannot imagine the Order Processor doing heads down data entry in a web based Client.
So when we have demoed that you can reuse the pages in Sharepoint, it is because our new architecture allows us to do so - and when/if we ship that functionality there still will be things you cannot do in Sharepoint (like there are things you cannot do with pages through Web Services).
I also think we want deeper integration with Sharepoint than just rendering our pages in Sharepoint - unless we are targetting a user who is in the airport needing to reach his NAV installation.
So stay tuned - I am sure this is going to be worth waiting for.
Group Program Manager, Client
Microsoft Dynamics NAV
http://blogs.msdn.com/freddyk
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
We now have to offer concurrent users at full price for for example these projectmanagers, where our competition does this for a price 8 times lower! than we...
This, along with internationalisation, should be the only thing at the development roadmap, along with stabilizing NAV 2009...
The general assumption before the release of NAV 2009 was the RTC is going to be a browser based client (somthing like the way 'MS CRM' works) rather another windows client. You must be knowing how 'MS CRM' works where all you need to access your complete application is the Internet Explorer and Connection and the entire application is open in front of you from anywhere in the world. I am not sure about how the licensing policies should be in that case. But this is something which most of the prospects/customers at least in India are looking for even at the cost of same price (or may be more than that).
The web service option seems to be useful, but again a good amount of development effort is required to use it.
But the way, the SharePoint integration (DCO) has been demonstrated in the demo video seems to be very useful and attractive. We can simple develop pages (or convert any forms to pages) in NAV and all we need to do is to add those pages as web parts in the SharePoint and any process of NAV (with all it's business logic) can be accessed over the web. I think, to some extent, we can achive a 'web based NAV' through this option especially for the light users and MIS users.
That has never been the plan. NAV 2009 ships with a new totally metadata driven client, where we have removed the code, which interacts closely with the pages from the pages - in order to allow us to refactor the client, make webservice and do stuff like Sharepoint, Silverlight or whatever in the future.
Correct
Group Program Manager, Client
Microsoft Dynamics NAV
http://blogs.msdn.com/freddyk
The information in this post is provided "AS IS" with no warranties, and confers no rights. This post does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.
Some people on this board knew the real story, and saw all the rumors fly around, and really wanted to set the record straight, because we knew that this kind of discussion would happen, but were told not to say anything about it because of NDA.
RIS Plus, LLC
Daniel, I may be wrong as I really didn't know the 'real story', but what I meant by 'general' is most of the partners and customers in India only and not the rest of the world. Actually we, as a partner, attended an event on the upcoming NAV 2009 few 7/8 months back from where the 'wrong' assumption came from. But as everythig was verbally communicated, I really can't prove it or we might really misunderstood the concept as the product was still on the development phase.
Anyway, thanks for your clarity, and forgive me if you feel my point should not be a part of this topic.
Thanks a lot for the clarity...
So, anything you want to discuss goes really
RIS Plus, LLC