Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K 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
- 305 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
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Comments
Indeed. But in which direction? ;-) I must say that my encounters with RDLC were all awful, although I've got it working after a while. I'm not sure about throwing away the thing that at least worked... like the reports in Navision 3.56
with best regards
Jens
I'll tell you this much: those who DID invest in learning how to develop RDLC reports, and those that DID help their customers develop them, those that did NOT take the easy way out, all of those companies are now at a HUGE advantage with NAV 2013 coming out later this year.
RIS Plus, LLC
Visual Studio offers a lot more features and functionality and NAV 2013 will remove most of the clunkiness for the developer.
Hopefully the users will take advantage of the interactive capabilities of the new reports and save a lot more trees.
http://mibuso.com/blogs/davidmachanick/
Generally I find they lead to more readable, cleaner, maintainable programming.
Consider a report as Items in lines, and in columns this weeks sales, this month, last month and YTD. With FlowFields, it is looping through Items, setting Date Filters and CalcFields. You don't have to read the entry table. This way it is short, succint, readable, making the numbers bascially a "property" of the master data record which IMHO is clean and logical, because in real life we can consider a "sales" as the property of an Item. The SQL way would be to go to the entry table and SUM and GROUP which is not as clean IMHO because we don't work on the same conceptual level as in real life (in real life we consider sales as a property of an item and not as the result of a sum of entries).
OK this is what in my experience never works. I am in favor of everything done by programmers although not necessarily everything done by programming (as configurable solutions are cleaner). I think this is a dream that works at some companies at best. I know many managers who don't use Navision, they want reports mailed to them. If they use it, they don't want to configure them, at best they just want to click a button. The folks in admin, sales, accounting generally don't want to configure reports either, because even if it looks easy they usually don't want to take responsibility for them. When the manager sees a strange number and ask why is it that they don't want to be held responsible. They tend to delegate it to IT an IT tends to delegate it to external consultants or hire an internal one for a larger organization. However many organzations don't even have IT they demand that external consultants provide them with ready reports.
At any rate, of course easily configurable solutions are often useful, so that you can delegate some jobs to a junior consultant or internal IT.
But only if everything configurable is also modifiable infinitely by code, because managers often have requests that outstrip the limitations of every possible too. Note that I am not talking about business requirements in the school sense. I am talking about personal requirements that came from the personalities of people. For example a manager who used a previous reporting tool in his previous job might demand that his reports look the same, for convenience's sake. (I even had requirements of simulating parts of the UI of another accounting software in order not to have to retrain people.)
Given the almost infinite ways requirements and expectations can outstrip the limitations of any tool, I am quite in favor of DIY solutions by people who can program, these should be configurable and not every single thing hardcoded, but still anything and everything must be modifiable by code. This can cost in the longer run more, and in an ideal world where people were rational and personal requirements would be equal to sensible business requirements, and thus expectations could be managed, we would avoid it. But in the real world populated with real people driven by habits, emotions, personality traits flexibility is the only way to keep everybody happy. Even if costs more in the longer run. (Actually a lot of managers prefer more costs in the longer run than an investment up front. Liquidity logic often beats investment logic in todays liquidity-scarce world.)
I will reformulate my question. No matter how good we are, we at the lowest level of the hiearchy because we do hands-on technical work instead of just managing people. In every corporate hierarchy the bottom level is the people who work with things (like software), who get things done directly, and above them there is a hierarchy of managers who manage teams, departments, divisions etc. who work with people. So naturally after doing 10 years of hands-on work I am thinking it is time to start rising up and you know actually begin having a career, one ladder step after the other, into management, instead of spending my whole life with technical hands-on work. And of course at a certain level in management it does not matter much with what technology you work with, Navision or SAP, Classic or RDL reports, you leave that for the people on the bottom level, you just manage concepts, deadlines, teams etc. My question was - do you think it is not realistic, not possible, or do you simply personally don't wish to do that? I do consider consulting/programming as a temporary springboard for gathering experience and the trying to shoot for a management job. I am asking this because I don't know whether it is really realistic to have an old-fashioned ladder-climbing career out of the realms of hands-on technical work and into pure management, or really this is something of the 1980's and not applicable anymore. I do find it is very hard and had no success with it so far, I don't know if it is realistic at all. (I am thinking about large end-user companies, not consulting companies who tend to be small, hence no career. This is part of the reasons I switched to the end-user side.)
It seems like you think whether to use the new technology is not relevant in your stage of your career. The way I interpret your thoughts here that you're choosing to no longer concern yourself with those details because you want to move up the ladder and let other people worry about that. To me that almost sounds like you think that at some point you get to work in an office with wood paneling, and really have all the underlings do the work, all you need to do is hold them to deadlines. In my opinion that is exactly what makes you not management material. The higher you climb, the harder you have to work, and all of a sudden it's YOU that makes the decisions, and "I've done enough programming, I don't need to think about new technology anymore" is not something that someone in management should be thinking. And don't even think about whether you at the customer side of things should be bothered, I personally think it is even MORE important to be aware on that side, because now NAV is not the only thing you do anymore and it has to fit into the rest of the technology ecosystem.
The decisions on what technology to use to grow as an organization is not made by the programmers. It is management that determines whether to hold on to old technology (because it is inconvenient / difficult / costly to learn the new technology) and where to invest in new technology. I would say the more you are in management, the MORE relevant it becomes to stay up to speed of all the new things. Maybe not every single little detail, but you certainly need to stay aware of what's going on. YOU need to be informed if you're the one making the decisions.
I'll say it again: That doesn't just apply to RDLC reports, that applies to any new technology.
RIS Plus, LLC
The bizarre thing here is that this is the first time I remember ever in a thread where something at the same time tells me that I agree with Miklos and disagree with Denster. :shock:
It is an amusing book about what happens at many companies - people rise to their level of incompetence.
The decision about whether to move into management should be based on whether you will enjoy it (working for the next 30 years at something you hate is not a wise decision) and whether you will actually be good at it.
Take some time to consider this before you make your decision.
Remember that 10 years out of hands-on working with technology will make it hard to move back.
8)
http://mibuso.com/blogs/davidmachanick/
:thumbsup: I haven't read that since I left Uni. Might get a copy and re-read it.
Same 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
RIS Plus, LLC
It's not that I completely disagree with you, I just agree with Miklos more.
From my perspective (and only mine alone), my sole dedication is to my customers. I don't really care about the technology and I don't care about being the best programmer or how "good" I am. I believe if we can deliver the best solution for the customer, regardless of technology, that is what we owe to our customers.
In order for partners like us to deliver the best solution, if technology is needed, it has to be easily implemented. I do realize the term "difficulty" is relative, however, comparing RDLC reporting to Jet Reports and/or Pivotier you don't have to be a programmer to see which one is more difficult to implement.
I'm all about learning new things. In this specific case, learning RDLC is like taking step backwards. I don't feel like learning RDLC will make me a better programmer or implementor. Furthermore, I don't believe learning the new RDLC will make our clients better off than they were yesterday.
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
By the way, my response is not to the part about career advice. Everyone has their own preference on how they want to live and how they want to die. The important things, again for me at least, is to have as few regrets as you can when you lay on your death bed.
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
Yes that's true. But in my work experience, those decisions made are - to be polite - often not in the best interest of the company. That's what I learned over the last 20 or so years: Getting management informed is a tough job, it is an art form to present decision paths that work. Lots of the decision makers don't keep up to speed with changing technology, often they do fall for marketing hype and buzzwords, with sometimes fatal consequences. That's part of the reason why so many crap software installations are around. In this spirit, calling NAV 2009 RTC with RDLC as "fit for business" is ... well ... not what I'd call it. And I've done my share on pages and RDLC coding. Using it is an expensive decision in the long run, IMO.
I know it sounds a bit off-topic, but looking at the title I think it's not.
with best regards
Jens
Well said. :thumbsup:
with best regards
Jens
=D> Very well written.
It's too bad that NAV will not go off of this RDLC BS. I still don't understand why the NAV we can go in the direction of using SSRS for native NAV reporting.
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
My point was about not being willing to invest in new technologies, not about any particular specific tool. I think we DO agree, you just thought I meant something that I never said.
Now having said that.... refusing to learn this "RDLC BS" because for some reason you believe it is too difficult is indeed a mistake in my opinion. I don't care how many alternatives there are, it IS the reporting solution in NAV for now, and we DO need to know how to work with it. I just don't see how you are helping your customers by not learning how to use that. I guess that's something we'll never agree on, which is totally fine with me
What I do agree with is that there should be a way to have SSRS reports within the context of the RTC, that should absolutely be available.
RIS Plus, LLC
A lot of this is a matter of perspective. Using reporting as the specific example, NAV developers complain about RDLC and designing reports in visual studio. If you had been doing BI reports in SSRS for 10 years and were forced to do NAV reports in the Classic designer you would sing a different tune. It is different for everyone, no matter which way you're moving. To generalize that, it's hard to move to new technologies. Doesn't matter what the technology is. Classic to RTC, QuickBooks to a real ERP, native to SQL, automatic transmission to stick shift, whatever. The new technology is not going away, there is a learning curve, deal with it or fall behind. It is the way of the world.
I understand the reservations, the thinking that clients will not be better off, but I disagree. Taking the ERP out of it, just talking about software in general, the most common type of complaint I hear is that "It's too hard to use." There can be many reasons for that, but that's it at the simplest level. So Microsoft develops a standard interface across the majority of its applications. NAV, CRM, Office, the programs that people use every day, all look and feel the same. We do the same thing in NAV every day by naming buttons properly, putting the correct shortcut keys on things, etc. It's design 101: standardize your application so the user can intuitively figure out something new based on something they've already done. Great move in my opinion.
Now that the front end is standardized, the back end needs to be. Common development tools, interfaces, databases across the product suites. That "should" force what is being developed by partners to be consistent with the look / feel of the other applications. At least if they care about designing a good add-on / app. I'm not saying everything has to fall in line perfectly, not the "my way or the highway" approach, but if you are designing a strong suite of tools this is part of it. There will be short term pain, but it is better in the long run.
The keyword for all of that that hasn't been outright stated is seamless. 10 years ago I don't think very many people thought that cell phones would be an integral part of most people's lives now, or that they would be powerful enough to do what they do. But people are joined at the hip with those things and the apps / software on them. While I enjoy the separation between work and home life, a lot of people don't. They want all of the information in one place, whether it be a Facebook feed, a Windows 8 desktop, or something else. That's where things are moving. It is where the next generation of work force, and to some extent current, will be. It could not be done on the technology that NAV was on.
I'll be honest, it semi-scares me when partners say they don't know the RTC or the new reporting yet. To use the old saying, that's just the tip of the iceberg. When NAV 2013 comes out, this will have been available for four years, plus beta testing time before that. So there's been almost half a decade to learn this stuff, and it seems like very few people have. I wonder if it's because no one thought it would be successful, no one had the time, no one cared, or something else? You can't hold on to the past forever; the change is already here and there's a ton more to come.
[/end rambling]
Now it is different and there is not a one for one correspondence, but overall you can do much more with the new, and we have a nice upgrade on the way for developers.
I have been in the business a long time, and I don't think punched cards and paper tape are coming back - and I am very grateful for that.
Every thing keeps changing and improving with a little Vista now and then to keep us humble.
http://mibuso.com/blogs/davidmachanick/
A modern company is just using printable reports for documents and everything else is exported into Excel anyway for further processing, hence you only lose functionality with RDLC reports, like transheaders, you do not gain anything.
How the heck do you explain to a non-technical customer or boss that a new product is actually worse in some extent, that you lose functionality? It makes no sense - do you expect a new Opel Astra to be in any ways worse or less comfortable than one manufactured in 1995?
Maybe they should have found some other way to get what they needed - or look at whether they really needed it.
http://mibuso.com/blogs/davidmachanick/
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
I can't argue that for specific reports, like a customer facing invoice, that it is a pain to redevelop the report. It's going to look exactly the same, there's no debate there. I think, however, that your focus is way too narrow. There are a handful of these types of document reports. They are significantly more other types of reports.
Excel is a great tool, one of my favorite and most used programs. And now I can export every report to Excel without writing custom Excel Buffer code on each one. I would say that these are primarily used by users in a finance department, though. Warehouse Managers, Salespeople, and plenty of other departments don't need to do that. I think a modern company uses the tools it has to its advantage, whatever they may be. Excel is a spreadsheet app primarily used for data analysis/manipulation, not a reporting tool. There is a difference.
I mean if Excel was supposed to be the reporting engine, it would have become the reporting engine a long time ago. You can create document "reports" in Excel if you want to, but people don't because that's not what it is good at. Classic example of not seeing the forest for the trees I think.
I think it depends and I think the analogy is a bad one. Was the car totally redesigned? If so than my old ideas about what it is need to be redefined. Maybe people wanted more storage space so they sacrificed some leg space. Maybe they didn't need 8 cup holders in a 5 person car and added a center console. Point being, with a "new model" things change. You lose some things and you gain others. You can choose to go with that new model or you can choose to stay with what you have or go with something else. The same decisions you would make regardless of the new model type (Classic or RTC).
I'm genuinely interested, if you were in Microsoft's position, how would you have made a huge transition like this? Or would you not have done it at all?
Look at Jet Reports and Pivotier. See how they do it and either buy them or just copy it.
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
On the low levels not, but on the high levels even much more than in finance. Finance is at least clear, if the balance of an account is 123 then it is 123. In sales, logistics etc. nothing is so fixed. A margin, a COGS or a stock quantity is whatever a manager deems realistic. A margin can be reduced because there are overheads associated with a customer, or stock can be increased because we know an important delivery arrived just not booked in yet etc.
It has always been a reporting engine in the sense that a report is not something an ERP software prints out. Only mid-level, not high-level. A high-level report is something a controller-type person writes manually in Excel combining data from many reports, multiple sources, multiple countries, manual adjustments etc. Then our job is to automatize it because to manually combine for example inventory levels in 8 countries in order to get a full picture to drive your purchasing decisions is a major pain.
Of course, that is not what I was saying. The opposite actually. The documents are about the only thing that need to come out of Navision's report designer because we need to know if an invoice was printed or not. This is why the bad report designer matters mostly for documents, as you don't really need to use it for anything but documents.
The basic minimum is that if they know the report designer in NAV6 sucks and in NAV7 won't, then keep the Classic in NAV7 so that companies can begin transitioning in NAV7 slowly and finish it by NAV8 when the Classic would be gone. So leave a easy-to-transition new version (NAV7) parallel with the old one, instead of having a hard-to-transition one (NAV6) parallelly and then kill it by the easy-to-transition one.
The absolutely ideal would have been to split the product into a NAV Classic and NAV RTC product lines and keep NAV Classic supported with the basic legal changes and bugfixes and nothing else for like 7 years more. So you only need to change if you really want the extra functionality.
Learning it in the basic sense of getting a training and being able to do a basic report I think everybody done latest in 2010. I did in early 2010 I think. _Mastering_ with all the special tips and tricks to emulate TransHeaders and whatnot it I think not, at least I don't, because there is little incentive.
First of all there are more old projects going than new installations. At least I always seen this. It is much more interesting to work for customer who bought it at 3.01 and has a really high-level customization, almost like their own vertical add-on, than to do basic customization for new clients. More lucrative, too, with new clients there is always arguments of "why can't it do this do it for free for me", once a company spent 5 years and €200K they know they are going to pay for every further development, they have a highly trained staff who does not need to get introduced to the F8, you rarely need to do basic support, it is overall better.
Second it is fairly well-know that the No. 1 problem that makes RDLC suck - lack of hiearchy in data - will go away in NAV7 which again reduces the incentive to really figure out black magic tricks because you won't need them anyhow.
Thirdly people can very accurate sense when a product is mature or when it is more like a beta. And NAV6 is clearly more or less beta, it has nothing of the characteristics of mature products. This is OK, they have to start somewhere. The only problem is to cut off Classic too early. NAV6 was something to play with, to test, a nice concept, not a rounded off product.
I mean the lack of proper matrix boxes and their ridiculous replacement, I was looking at it and laughing loudly, you have a nice conceptual product, Microsoft, but is not even close to a finished, ready replacement for the Classic.
NAV7 will be probably a mature product, to start transitioning to. And by NAV8 they can kill Classic, that is fine.
They really don't understand that what made this product succesful back in like 2.6 was the ease and freedom of development. In every release they are taking part of that away. In every release more and more things we must say "can't do" or "would be hard and expensive". How long can it take until some more open product which like 3.7 was take over its market share because in that product, like in 3.7 if your client told you to make that field three times as high and bright purple you just did it, without having to give complicated technical excuses why you can't?