What is the future of the cal/code report writer in Navision. As an end user without a developer license, I can use the processing only report feature in Navision to accomplish a lot of things. If Dynamics Nav moves to the sql report writer is the functionality going to be lost?
I understand most people on this forum are developers, but from and end user point of view, what other features for 4.0 native database users do you see being lost, in 5.1 sql version?
What I am asking is if we want to go to the new client, ect. what will we have to give up to do that.
0
Comments
This does mean that there will be some restrictions with the code that you can place within a report. From what we've all been told in the new client Forms and Reports are for displaying information (and forms for updating) only and not for doing business processing. So some reports may need to be rewritten as codeunits.
All will work the same as before (5.0 is still a C/SIDE client).
If you want, you can export your basic design to RDL, and go ahead with Visual Studio.
The reports that you design via RDL, will ONLY work on Dynamics Client (aka "new" client), so we'll have to wait for this enhancement.
So, basically, it's the same that SteveO was explaining
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
it is very useful and I would consider it a deal breaker if as an end user I could no longer use this functionality. Now when we need slight changes I can edit the report and make for example the suggest vendor payments, include the project code, or something like that, if it is moved to a codeunit, I now would have to run to my solution center to get a program change made.
I am sure that there are many people out there that know what they are doing, but there should just not be access to C/AL code in reports. You have no idea what kind of crap we see sometimes because users program reports to manipulate data....
RIS Plus, LLC
Now, not to take a shot at programmers, but you wouldn't believe some of the stuff they have sent to us, even I as an end user found many problems, and I even had to tell them what needed to be done to correct it. so poor programing is not limited to end users. and it appears that Dynamics Nav. is moving to open up the programming to anybody that is a gold partner, can't wait for that to unlease a ton of programmers who know nothing about Navision.
RIS Plus, LLC
Indeed, there are bad programmers as well, but that doesn't mean all programmers are bad. In our company, we are responsible for the functionality. If there's a bug, we'll fix it for free. That's obvious and normal. But when we notice that the customer is write code ... we're not responsible anymore ... . We just can't allow the customer to make that kind of changes. We are educated for it. We are certified for it. So we are the ones that can be responsible.
imho, it should not have been sold to you like that. It has the ability to be changed ... by a Certified Microsoft Partner.
Sorry .. :oops:
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
Now, Reports are by design made to do much more then display data, the core of navision uses non-printing reports to do a significant portion of the work. Like the example of populating the vendor payment table, it is a report "Suggest Vendor Payments" that runs and fills the journal.
the report designer quide from Navision gives directions on it. So, if you have a problem with it, you have a problem with the core of Navision. As many features where built around it.
I know about the possibilities, the fact that NAV uses reports, the different granules, etc etc etc. . If this makes it the "core" ... that's another discussion.
I also know what it takes to become a decent developer, who, by experience, can estimate what impact certain customizations can have. (At least, I'm supposed to know ... ).
Therefore, I know it is a hell of a job to create a decent developer out of a customer that is not dedicated to that job, to someone who does some things, here and there, once a week. You see what I'm getting at?
If you get a decent education, get some experience, are dedicated, ... sure you can become a good developer. Everyone can ... customer, partner, women , ... everyone!
Nevertheless, don't expect the partner to take responsibility
It's a matter of viewing points:
you (as a customer) are afraid you won't be able to do modifications anymore.
I (as partner) am looking forward that the customer can't do modifications anymore.
Tip:
just buy the solution builder granule. You get a developer's license. All is possible with it, and there is no reason for this arguement. =D>
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
But I also am not in the business of giving money away to make simple changes, once the program changes to the point where I have to pay to make the entire part number show on a report is the day I get another program.
To me, I have been with Navision a reasonal amont of time, about eight years now, it has always been a program that was usable, with a few changes, which made it very attractive. But I feel it is moving away from that, everything seems to be going to a cookie cutter implementation, where you buy standard Navision and buy an add-on, rather then custom program changes. As and end user you accept what the programer has done because he knows best.
It seems to me, Microsoft was sitting in the audiance a few years ago, when Larry Ellison gave his speach about Oracle should be a standard product and should not be modified, users should change their business practice to fit the program, not the program to fit the business practics. If I had wanted that, I could just switch to Oracle.
Nowadays it's virtually impossible to get a deal that has development included from the outset, everyone wants an out-of-the-box solution. You'd be surprised at how much we argue with customers about what should have been included.
RIS Plus, LLC
And other customers saying B, wanting C, but definitally not A.
:-k
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
Very very bad point of view.
You as NSC are unhappy about customers customisation and propose to limit that?
Next natural step is: MBS is unhappy NSC customisations (error, terrible upgrade and new version release) so will deny any customisation except new reports and new functionality on top of existing - no modifications on existing... ()
We don't need such ERP product. Which of you didn't make changes in codeunit 1;12;22? We need possibilities to change base functionality.
Now we have NAV on SQL, so actually every customer(system administrator) can open SQL table and change G/l amounts (or writes SQL query which changes customers setup). Will they show these amounts to NSC and will say: You did errors in programming - please correct everything for free??? If so, then they need not open functional ERP, but closed code software without permisions to db and so. :evil:
Really customer is responsible for data and i don't worry that they are responsible for product code they modified too. We can consult them, training them and allow them make any changes they want, just customer must be responsible for actions they do. And we can correct customers errors but it is chargeable jobs.
I vote for freedom
Again:
Unfortunately, my experience tells me that customer plays around, and we should be responsible ... why? Because NAV (or NSC) should foresee that user CAN play around, but CAN'T make mistakes. :-k
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
The bad thing though is that whenever a customer has a problem, no matter who wrote the bad code, it is always the NSC that was wrong and has to fix the problem.
My personal opinion is that it was a bad choice by Navision to make it possible to develop anything you want with report objects. You can make reports act like codeunits if you want, and anyone with a little bit of VBA knowledge will use that and try to make NAV act like they want.
Trust me I am all for freedom, I just wish that when a customer plans to do some development that they would write it up and have us review it, instead of hacking their way through issues.
RIS Plus, LLC
It is not about IT, it is all about people. Most customers I work with want the freedom to drag and drop a field on a form or on a report. Or to put something bold on a report. Most customers also have common sense and realise that if you develop one line of code per day on average, you are not really skilled to do things which can have a big impact.
It is all about common sense, but for the partner it is sometimes frightening having to rely on that.
It just want to point out that without that tool, you should not be making changes (unless it is about the things I mentioned such as adding a field on a form or make something bold in a report).
Developer's Toolkit - Source Analyzer 99003640 7.090,00€
But again, ...
From my point of view they give it for free.
It just want to point out that without that tool, you should not be making changes (unless it is about the things I mentioned such as adding a field on a form or make something bold in a report).
I'm NOT talking about the developer license, I'm talking about the developers TOOLKIT :
Developer's Toolkit - Source Analyzer 99003640 7.090,00€
But again, ...
From my point of view they give it for free.
It just want to point out that without that tool, you should not be making changes (unless it is about the things I mentioned such as adding a field on a form or make something bold in a report).
But again, ...
From my point of view they give it for free !!!
It just want to point out that without that tool, you should not be making changes (unless it is about the things I mentioned such as adding a field on a form or make something bold in a report).
If you wanted a complete makeover for say an Invoice, "Has to look exactly like our current Invoice", "Boxes, Lines Shipping Information, and comments in boxes, loose half the data and add different data", send it back to the Customer, "Oh can we have another change, while you are there loose them other fields and change the font size", send it back to the Customer and they might just accept it after another change.
This could well cost a days work, even for a highly skilled developer, I have seen "Standard" reports going back an forward several times, because the layout has to be just like the printed stationary!
It would have often been cheaper to scrap the stationary and start again!
How long does it take for an NSC to change the length of the "No." field on the Sales Order document? "Five Minutes"?
Customer phones,NSC Records Support Call, NSC Raises a Change Request and sends to Customer, Customer Accepts, NSC Delegates Work, Developer Changes Report, NSC Sends to Customer, Customer Accepts, NSC Closes Call, NSC Raises Invoice!
How do you do business?
Accepting that sometimes NSC use less skilled developers to alter reports, without enough checking by the NSC before it goes to the Customer.
If you was charged a day for minor changes then that is bad, but it is not always a "scam", Customers often want more than they are paying for, and NSC often under estimate the time it will take to give the Customer the reports in the format they want, so it is a double edged sword, that the developer has to avoid.
Quite often as developers we works hard on a projects, which are under quoted, tight timeline, trimmed budget, user training and acceptance testing cut to a minimum and porly scoped to bring the contract in! :evil:
When the Go-Live has a few problems or the project goes over budget it is "poor development!"
Mobile: +44(0)7854 842801
Email: david.cox@adeptris.com
Twitter: https://twitter.com/Adeptris
Website: http://www.adeptris.com
I agree and dissagree :?
People(developpers) are migrating customer>NSC>Maybe MS> back to customer.. So there could be we have better developper in customer as in NSC or MS. Or maybe not
But we have one limitation: customer can't make changes in ledger entry tables, and can't modify objects which has permissions to modify these tables. So customer bad programing is less impacts to base data as NSC bad developper changes in base codeunits.
If customer want to change report or write advanced report with many code in it, why we must deny this? Let he does that - he will not damage very important data...
But now, when customer have SQL, they can do everything with SQL data and we'll never find reasons for it. I think we have another level of responsibility now (instead of how it was in native NAV db) - we are responsible only for code and for data produced by this code (we must be sure data is produced by our code). And nothing more. All other services like data researching and correction is chargeable.
I had case when customer in native NAV deleted db :evil: I think NAV asks 3 times about "do you really want to delete db". And customer push "Yes". Who is responsible for this? I think the same is with customer bad programming too - this is customer responsibility and he must pay if he want our corrections, researching and so...