Converting ForNAV reports to Standard RDLC format

jordi79

Hi,

Is it possible to convert a Fornav report layout to the Std RDLC layout?

Jordi

Slawek_Guzek

No, there is no conversion back available, the only way is to re-do them from scratch (or start from existing standard RDLC reports).

Out of curiosity, why would you want to convert them back to RDLC?

Slawek_Guzek

No, there is no conversion back available, the only way is to re-do them from scratch (or start from existing standard RDLC reports).

Out of curiosity, why would you want to convert them back to RDLC?

jordi79

I feel that the ForNAV report solution is a stopgap solution. Because it is only a matter of time, before we have to move to RDLC. But this is only my opinion. It makes ForNAV support difficult because there are increasingly more ppl that knows RDLC than ForNAV.

But thanks for your answer. This confirmed my suspicion that the only way is to convert all the reports back to RDLC manually from scratch.

Slawek_Guzek

Personally, I think that it doesn't matter that more an more people know RDLC. ForNAV is far, far superior, in every aspect - capabilities, control over layout, server load and performance, ease of use, and time and efforts and therefore the overall costs required to get and maintain required results.

I think that RDLC was just a "temporary" fix put in place by Microsoft back then when they launched RTC for the first time. Unfortunately, it has not progressed in any significant way, I dare to say, in any way. Just look at the report 206 - data structure, layout and coding wise it looked absolutely horrible in NAV2009, and it still looks more-less the same in the latest version of BC.

Once you require something more complicated than a simple list of thing time spent developing in RDLC increases almost exponentially.

The fact that more people know RDLC will only make the resources a bit more available and a bit cheaper, but it will not reduce the complexity and amount of work required to get a decent result in RDLC. Hiring even 2, 3 times more expensive developer knowing really well ForNAV will still be cheaper than hiring a really cheap resource from Eastern Europe or India, who will spend 10 - 20x times more time doing an advanced report, and at the end the results will be probably still half of those achievable in ForNAV.

IF you don't want to use ForNAV for any reason invest in learning external reporting tools, like PowerBI, don't waste your time on RDLC, imho.

Justina_Simplanova

Hi, jordi79! Next time when you will need to convert your Classic report straight into RDLC format, you can check out Simplanova Report Converter. Reports are converted from Classic (up to 2009 R2) to Native NAV / 365 Business Central RDLC Report Format plus you don't have to pay any license fees.

swpolo

Slawek_Guzek wrote: »

The fact that more people know RDLC will only make the resources a bit more available and a bit cheaper, but it will not reduce the complexity and amount of work required to get a decent result in RDLC. Hiring even 2, 3 times more expensive developer knowing really well ForNAV will still be cheaper than hiring a really cheap resource from Eastern Europe or India, who will spend 10 - 20x times more time doing an advanced report, and at the end the results will be probably still half of those achievable in ForNAV.

IF you don't want to use ForNAV for any reason invest in learning external reporting tools, like PowerBI, don't waste your time on RDLC, imho.

Here i am not agree with you about report convertion to RDLC efforts and budget. Some cheap resources do the same way as years ago, but some use transformation tools which makes convertion faster. And time/budget expences are on the same level as ForNAV convertion.
Middle time on report convertion is 2,5h of development time with finalizing(fixied and tested) report to usable state. Rates are close to Eastern Europe or Indian developers.

So it is not so expensive now as you can think.

We can do report convertion to RDLC( tool usage plus finalizing report) as described in my signiture

jordi79

I must admit, I did not spend a lot of time with ForNAV. But RDLC has been around since NAV2009. So I think I have no choice but to pick RDLC for better or for worst. 1 thing, I really hate about RDLC is the SETDATA and GETDATA workaround that NAV uses to get around document reports.

But maybe my opinions will start to invest more time to learn ForNAV.

Slawek_Guzek

@swpolo please.. I know that you guys (and others) are trying to make our live easier by providing automatic conversion tools. I, and probably lots of other folks here, we are grateful for that. But that does not change the fact that any report in RDLC, which is anything more than a simpe list, is far more complicated than the original 2009 report was, and far, far, far more complicated than ForNAV equivalent

Therefore the logical consequence of this simple fact is that cost of modifying and maintaining it is high to very high in a longer term. Your guys only make it easy and relatively cheap to start. And this is good. We need to have a choice, RLDC or ForNAV or an external tools, choice of developing in-house or outsourcing. Not all reports require frequent tweaking so once converted they may live long and happy live untouched.

But if they do then the truth is that all sort of converter tools make problems worse in fact. What you mentioned is just an 'entry point' cost - converting the report, do some light touch it it does not compile right after conversion. Hence the 2.5 hours figure. Lots of people get caught by this low entry cost.

The fundamental problem with this is the difference between the old NAV reports and the RDLC technology. Since the two are completely different the reports, in order to look good, perform well, not overload the NST, and be easy to maintain they should be re-designed to align them with the technology so different than the original like RDLC.

Try converting a report which has a few bitmaps, and report body lines are a few levels deep. It will kill the NST server without major manual rework.

Frankly speaking my rant does not apply to reports only. All sort of cheap upgrade services to make business viable rely on more or less automated code merging. They all suffer from very the same fundamental weakness - they merge existing code, and do not properly redesign. This conversion approach may work in simple cases, aka Cronus with minimal number of changes, but on any larger scale project sooner or later further modification and maintenance costs will mount up.

Been there and seen it with my own eyes. And unfortunately had to dig out my company from a deep s..t they get lead into by a manager, knowing a little about internals and wanting desperately save costs. It ended up with a team of 8 people working full time plus often overtime for 9 straight months to fix the code, data, upgrade routines, and make the system performing. And making sure that the actual go live will not require a week-long maintenance window to enable the upgrade toolkit to chew through the existing data.

swpolo

@Slawek_Guzek, I suppose you did not get me.
We offer conversion reports with running tests on target client's database. It includes all redesigns and manual fixes of all milestones on any complexity that can be found while transforming (Bitmaps,excel, unsupported triggers and so on ).
Our tool just help us to reduce manual work on report conversion.
Also, our experience allows us to do transformation fast enough and with fixed price per object.

Finally, it is not slight conversion just to get any output result. It becomes fully functional report in RDLC.
So this is not only tool conversion.

Slawek_Guzek

@swpolo fair enough. You are probably a noble exception then

swpolo

We have got a huge experience on report transformation to RDLC, so we can do it fast with good quality and very low price per report. Everyone who plans or in the process of NAV upgrade are welcome to test our report transformation to RDLC services. First examples we do for free.

Miklos_Hollender

Slawek, the thing is, if everybody will be forced to upgrade to BC at some point, will ForNAV work with it?

They way I approach the report problem is that already from 2009 when I first saw RTC / RDLC I decided that for me only documents will be printable reports and every report that is really a report, data for making decisions, will be made by the Excel Buffer. This, with various extensions, ClosedXML and other stuff survived fairly well to NAV2018. Not sure about BC. I was betting on that everybody has Excel on the their computer and later on they got it on the phones as well so Excel was an acceptable "paper" to print repors on.

And for documents I was simply hoping they won't get too complicated. Well sometimes they did but I kept the complexity out of the RDLC layer and rather kept it in the C/SIDE layer, processing complex temptable and then just straight out printing them, no multiple level deep bodies. I actually learned this back in the Classic era from an company who was making an add-on that was printing really complex sales quotes for large projects. The method to just code and code until a temptable, shown in test form, looks in itself like a good document (pretty much how one would make a good document in Excel, with just columns and rows), and then just throw the whole thing simply into the sections worked for them already in Classic.

Slawek_Guzek

@Miklos_Hollender ForNAV does work with BC, both with OnPrem version, and the Cloud one. I have BC OnPrem and there are no problems.

A "report" in Excel is pretty much the same approach as a 'report' in PowerBI. I'm not arguing against it, quite the opposite. But there are reports which needs to be printed and need to look in certain way, like documents you've mentioned. A hope that they won't get complicated is simply not enough.

As you've said sometimes they do. I have a recent example of an invoice report for one of customers of ours - a nightmare, with fancy headers and footers, backgrounds, small bar graphs, a QR Code, a bar code, lots of small graphics embedded here and there. A true, true nightmare. We have used a subcontractor to who did it using standard R206 as a base. Yet still it was so bad and so slow that a colleague of mine spend 30+ (!!!) working days to make it acceptable. That unfortunately had to include removing tons of hardcoded sh..t put by the subcontractor to make their work easier.

Should we start from scratch in ForNAV we would probably have it done in a day, maybe two - including all the bells and whistles customer wanted.

Sometimes having just one report like that is worth using ForNav.

I was not in position to make a decision on that one, and my manager wanted to save money and time.

I am a one of first customers of ForNAV, and this product saved us TONS of time. I've blessed them since I've first started using them. That's despite I do have some considerable (16+years) experience with SQL Server, and with the SSRS/RDLC (much shorter as I never fancied SSRS much, still some odd years).