Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.6K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 295 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Comments
Nope your noe alone i feel exactly the same and i could sign your statement right now
And guess what, your not the jungest guy here :P
... refreshing =D> But I must say I'm more on the side of OldNavDog. But that's nothing new from me
with best regards
Jens
The thing that gets me the most is.. why the f... can't I use my arrow-keys to move between fields on pages (Cards that is. Not lists) ? It is either TAB or ENTER both of which suck with regards to navigating between fields and don't get my started on using the mouse.... Thank God it actually works somewhat user friendly like on worksheets or no bookkeepers anywhere would touch the RTC.
](*,)
I haven't been able to run the RTM version just yet due to license problems (unfathomable ones at that) but I suspect I won't be able to do this simple task in this version either.
Tommy
But seriously; since the release of NAV2009, the amount of non-billable hours has skyrocketed. The reason for this has been that there are so many things that does not work on RTC or just behave unexpectedly. Just to mention few: RDLC reports, file reads and writes, automation, three tier authentication.
The main issue is that it has been difficult to find good documentation for dos and don’ts BEFORE you stumble into problems. The documentation in the format of help files is not a very user friendly way for studying new things and they are not very thorough either. The course materials you can load from MS eLearning are very common and do not focus in daily problems. MSDN, Mibuso and other sites together have been the life saver, but the RDLC is something that is not covered enough.
I used to say that "Navision 3.7 was the last good version of NAV" but I am very impressed with the work MS has done with NAV2013. But. I have to accompany OldNavDog with his opinions. It's good that someone has the guts to stand up while the NAV community is mainly very MS favorable and prefer being shut up than speaking out loud.
I think the answer is really straight forward, but as I do not work for MS I can't say for sure. But, 1) What has Microsoft been pushing? Standardization of the user interface across all mediums. 2) What is the largest medium? The internet / web pages, where arrow keys don't work. For better or worse, the "interface" to the internet isn't going to change any time soon, so it makes sense to start with the biggest / most commonly used thing. Just my opinion. I miss the arrow keys too
I'll agree with some of those. I had trouble with the files reads / writes too, but I got past it. I haven't had any trouble building add-ins or anything. The setup / authentication / SPN ridiculousness was a serious pain, one I think they have taken great steps to improve with NAV 2013, or so I've heard.
Again, this sounds like that magic book. The one that tells you exactly how to cover every scenario. Should the documentation be more thorough? Absolutely, 100% agree. But the daily problems of one company are not the daily problems of another. That's where you need company specific documentation of processes, policies, and procedures. That should be done during the implementation and continued by the customer. As far as technical documents go, again, yes I wish they were more thorough, but they give you the building blocks to solve the majority of what you need. As developers we take those building blocks and use them to solve complex issues. Thankfully we do have these wonderful online communities to help out and shoulder some of the load and share that knowledge. It's never going to all be found in one place.
My Blog - nav.education
I can tell you with 100% certainty that the NAV product team looks at it and takes feedback there under consideration. I know because they have told me as much and I have seen them implement some of the suggestions in 2013. So by all means go out there, put your ideas up, and vote them to the top if you're serious about it. Every avenue helps.
My Blog - nav.education
Any more of them, and we'll have to have "Floating Pallets" for each Window, LOL!
But what really burns my bum (trying to be European in my slang), is that, in 2013, the USER has more "Design Control" over a Page than the DEVELOPER of that Page!
There are certain "Actions" that come in automagically, depending on the Page Type. They don't SEEM to appear ANYWHERE that a Developer can get to. How helpful...
But I'm not even going to get started on yet ANOTHER rant (I hear everyone applauding!). So, I'll leave that for someone else to whine about!
Reminds me of some of my users' help desk tickets. "Something isn't working like I think it should, but I won't tell you what it is or where it's happening"
What do you think should or shouldn't be there? What do you need to get to?
My Blog - nav.education
So, MS' "borrowing" of that (along with a zillion other things) from Apple (don't get me started!) is actually a Good Thing; because TAB and SHIFT-TAB are used, OS-Wide, on everything from Dialog Boxes to Databases, in both of the two major computing platforms in common use since the mid-1980s.
Honestly, I don't have the time this morning to go into details, sorry. Maybe later.
All I mean to say is that if you (by that I mean everyone here) don't like the way something works, meaning you want to get it fixed/changed, or if you want to learn how it works, you need to provide detail. Otherwise it's just complaining to complain and it's not helpful to those participating in the discussion or to those who can do something about it. I totally understand someone wanting to get something off their chest, but we shouldn't guise it as feedback.
Maybe I've misunderstood what this thread is supposed to be? :-k
My Blog - nav.education
My Blog - nav.education
You must be new here.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
I am frustrated with the product (NAV2009, NAV2013) to the point that I am planning to start doing something else. I am looking for another product that would be something what NAV was back in the day - a solid standalone small ERP that was not dependent on changes on the underlying techniques like the OS version and so on. A product that was supported by the maker of the software so that us, partners, did not have to spent the most of our time trying to figure out the latest gimmicks to get the product working.
What we got now is a messed up solution with lots of unfinished features and techniques. A product that you get a new Hot Fix every week. Just take a look at the list of latest published KB articles on NAV 2013. Thank god I am not responsible for maintaining a large official add In. I just wonder how intense that would be. You just can't rely on any features cause MS might take them a way or change them the next version so that old objects need to be redesigned from the scratch.
How can it be so hard to provide a descent report editor when MS Access had a marvelous report designer in version 2.0 in the 1990's...
And finally: I do not think that the cycle of announcing new major versions for an ERP system should be two years - this is not Office, for crying out loud.
In Dallas, Texas there are a huge number of jobs for people who know this product and a large number of companies successfully deploying it.
I was surprised at some of its initial limitations, but the newer versions have removed them. Plus Visual Studio 2010 allows simple tabular and matrix reports to be designed extremely quickly using the old Windows friend - the right click button on the mouse.
(Nobody I know is perfect, but I like what they have done in NAV 2013. I am curious to see what exactly they do for NAV 2014. I am expecting more of the equivalent of a service pack with bug fixes and added functionality. Maybe they will surprise me.)
http://mibuso.com/blogs/davidmachanick/
In my training class I will i.e. together with the attendes upgrade a Classic 5.0 document report to NAV 2013 in one hour. Normal list and group reports I show you how to do in minutes
Yes their are many new things and tricks we need to learn with reporting in NAV 2013, but when we have learned these, I would argue that we can actually do things almost as fast as we did in the Classic reports designer and sometimes even faster.
/Claus Lundstrøm
I'm blogging here:http://mibuso.com/blogs/clausl and used to blog here: http://blogs.msdn.com/nav
I'm also offering RDLC Report Training, ping me if you are interested. Thanks to the 700 NAV developers that have now already been at my training. You know you can always call if you have any RDLC report issues :-)
I have found with grouping style reports that I can do them even faster than Classic, and matrix reports just blows away Classic.
Which makes me wonder when it is better to rewrite as opposed to upgrade old reports.
Will Classic reports with many optional sections convert to a usable NAV 2013 report easily?
Will custom invoice type forms convert over to NAV 2013 easily?
Do you have some general rule on when to convert and when to rewrite?
http://mibuso.com/blogs/davidmachanick/
http://mibuso.com/blogs/clausl/2012/10/03/simplifying-document-reports-in-nav-2013/
Code.GetData and Code.SetData is also performance heavy, so another reason not to use this approach. Unfortunately, all standard document reports is using Code.GetData and Code.SetData heavily.
Only thing I really miss, is to be able to place Page number in body. Then I don’t need any Header or Footers in my reports. If anybody can figure that one out I will buy them a nice dinner. People talk about this in other forums, but I have not managed to get any of the solutions working. So let me know if anybody can figured that one out.
/Claus Lundstrøm
I'm blogging here:http://mibuso.com/blogs/clausl and used to blog here: http://blogs.msdn.com/nav
I'm also offering RDLC Report Training, ping me if you are interested. Thanks to the 700 NAV developers that have now already been at my training. You know you can always call if you have any RDLC report issues :-)
Hey, who was PM of reporting in those days... :whistle:
Back in those days "we" had a Platform and Application PM responsible for Reporting. I was the Platform PM responsible for the Report Data Designer, the designer you see today in NAV 2013.
The Application PM and Application team was responsible for the actual Report objects. Of course I had the opportunity to influence the design of the reports for NAV 2013 and not to use Code.GetData and Code.SetData, but I did not, so of course I'm also to blame, no doubt about that. But after leaving MS and the NAV team and joining the partner Abakion, my IQ has tripled. Now I'm not inventing Simon, Victor and Isaac scenarios anymore but working with real customers who don't care if a bug is by design. They just want the problem fixed now.
I had a long talk with Dan Brown that MS should start sending people from the NAV team out to partners, for a period of 2-3 months, where they could experience the real world. It would be a revelation for many people in the NAV team. I.e. the way the Actions are now done in Configuration in NAV 2013 and not controlled 100% from Page Designer, is a clear signal that somebody in the NAV team have no clue on how much extra work that gives us Partners, when we cannot control this in Page Designer for our Add-on solutions.
But after having this talk with Dan Brown I guess he got inspired and then also left. [-X So now I'm not suggesting this idea to anybody, because I don't want anymore people leaving the NAV team!!!
/Claus Lundstrøm
I'm blogging here:http://mibuso.com/blogs/clausl and used to blog here: http://blogs.msdn.com/nav
I'm also offering RDLC Report Training, ping me if you are interested. Thanks to the 700 NAV developers that have now already been at my training. You know you can always call if you have any RDLC report issues :-)
I read the complex blog item about report 206. Did you ever create a video about 2013 reporting? Complex things look easier when visualized.
Is that a challenge? Because I like challenges.
Actually, I've been meaning to record a session on how to do this for a while now.
AP Commerce, Inc. = where I work
Getting Started with Dynamics NAV 2013 Application Development = my book
Implementing Microsoft Dynamics NAV - 3rd Edition = my 2nd book
That looks like "slapped with a gauntlet" challenge! 8)
It might be a long video though, resizing the fields to match-up is tedious. (But worth it.)
http://www.interdynbmi.com
Please understand just one thing only. "Reporting" does not matter much, but documents are an incredibly sensitive thing!
"Reporting" in the sense of management reports does not matter so much because it is outdated anyway to print out a report on paper and put it on the managers desk, I for example (in Classic) generate complicated Excel reports with Excel Buffer and email them out and basically this runs the whole company, globally consolidated stock, sales, everything. With the current modern, open architecture it does not matter how convenient is to use RDLC reporting, we could do this, or queries, or in the worst case put something like Crystal directly on the SQL tables (is that even legal? anyway there are surely legal options) or whatever really.
But the documents! You must understand how sensitive that is. Every manager ever is obsessed about having just the right layout, just the right information, not wasting space, not having too much information, not having too little information, every long running project ever evolves (or devolves) into invoices and suchlike having 10 conditional footers showing all sorts conditional texts and so on. And then the crazier stuff when for example they want to book 1 product out of inventory but want 2 lines on an invoice or the other way around... documents are always the hardest parts of customization, because they are the only part of Navision that is not for your customer but for your customers customer. So you can tell your customer they cannot have X but you can never tell their customer cannot have X. Because the typical NAV user is a small company selling stuff to a big company. If they were big they would use SAP, if their customers would also be small they could not even afford NAV
Sooner or later I will have to upgrade 7 subsidiaries to the RTC / 2013, and reading topics like this plus my own learning experiments show documents will be the hardest part. When you spent years to get them just right, with incredible amounts of conditional logic, how can you explain to users to redo them when they are happy what they already have? A lot of investment and from their viewpoint no positive change at all. Nobody wants colored charts on their invoices. That is already a very precarious situation and with undocumented difficulties and bugs what OldNavDog described this starts to border on the extremely difficult.
(I think I will have to start with upgrading the Danish subsidiary - I guess they are not very concerned about documents layout because they send them in OIOXML Efaktura anyway not much on paper. I guess this may also be the reason Vedbaek does not really empathize why precise and predictable document layouts are so important for the rest of us... We all should move to electronic documents but as long as ancient, outdated standards like EDIFACT are unwilling to die I guess we won't.)
Anyway, Lars, Claus, I would just like to raise awareness that the reporting system in NAV is not really for reporting. Since the invention of the Excel Buffer we don't really need that much reporting anyway. It is for documents, and documents must always look exactly in a way they want it... WYSIWYG and all that.
Dear ClientMonitor,
Look, if it was about the product price/quality ratio we would have never used these big international stuff like Navision or SAP (or the older ones, Baan, MFG etc. so not these big players) anyway, we would be using the much more niftier small local accounting packages where you just pick up your phone and talk directly to the guy who coded a module.
We use them because everybody is brand name crazy. Sad but true. Drop names like Microsoft or SAP and it is sold. Drop a name like it is some whatever product developed by 4 guys in a small town and nobody buys it because they don't trust it.
This brand name craziness is for two reasons. One, many customers want a long term IT strategy and they assume there is or will be a lot of integration and synergies to win by using many Microsoft products and the same with other big players like SAP. Also the support of small ERP vendors was often bad. Another and even more logical reason is that it is literally impossible for a customer to check or anyhow get a guarantee for the quality of an ERP product before they buy it and to be 100% honest our industry is very good at generating bullshit and very bad at generating honest criticism of products the customers could rely upon, I mean, how many blogs or even better articles in professional magazines you know which says "X Y part of inventory costing sucks in Navision, X Y part of fixed assets sucks in SAP" and so on? Nobody gives out this kind of honest information, ERP does not get tested like cars do. So customers must go for brand names, what else can they do? If I have no idea if a car is good then I will just assume a Lamborghini is better than a Tata, what else can I do? Brand names are the only thing that help.
This is why making add-ons is such a great business. You can have a tiny noname company 4 guys making some software in a small town, zero market prestige or brand recognition, but once you can brand your product as a Navision (or I guess SAP) add-on suddenly you can piggyback on the well recognized brand name.
So, we don't really have a choice. If we want to make a living we have to stick to big brand names. Microsoft, SAP, Oracle, nobody else is playing the big game anymore.
I understand what you are saying - Navision is adopting the Axapta philosophy - focuses more on coolness than on reliability...
BMW e.g. doesn't rely on just one screw supplier. They obtain screws from many different suppliers and also store screws for daily consumption of several days in their warehouse.
But since an ERP system isn't something that could be easily switched to another supplier, all bigger companies will rely on bigger suppliers.
Yes, I agree that is very often a big concern. However if it was the only concern it would be easy to resolve that by using open source software, yet it does not happen much. Imagine you want to make a very specialized add-on for a very special industry (think hotels), where standard ERP features don't matter much because you are going to replace almost everything. Why wouldn't you just make it something open source like OpenERP which can be supported by any of the millions of Python programmers in the world after a few weeks of studying the code? I think the only truly good explanation is brand power.
Again I am not saying it is irrational or wrong or stupid. It is not. It is the consequence of the sad fact that the customer has no ways of checking the quality of what they buy before they buy it, or enforcing the quality later on as a kind of warranty. IT especially ERP is still in the "Wild West" stage when you cannot sue a supplier for having too many bugs. (I think this has to change somehow in the coming decades, there have to be professional standards set like in every other industry for buildings to cars.) Therefore we are incredibly trust based industry.