:roll: When you're through upgrading (and burnt through 6 to 8 digits of cash), you will find that you still have this craptastic UI and even more complexity to deal with. Sounds more like a typical decoy project.
After almost 3 years and especially with NAV 2013 I started "enjoying" RDLC and I wouldn't come back to old report designer at all, I just find quite unbelivebable not to have an elementary feature such as manage justified text! (a proper suggestion was added in Connect 4 years ago!)
Inventory Valuation report - rewrite the NAV side to pass a smaller dataset.
The report curently gets all the detail but does not print it.
Still takes a while to run, but it does finish.
The other alternative is to use the example using SQL posted by ara3n a few years ago or some of the more recent postings.
The NAV dev team really needs to rewrite all the reports using their own report development principles.
Let me rephrase, how do you print a large dataset using RDLC? Answer, you can't.
This means that you cannot rely on RDLC for any meaningful financial analysis.
Thank God for Odata (which I still can't get it to work), Excel Buffer (still has its limitations), SQL (rewrite standard code using SQL), writing a .csv file (back to DOS days?).
Simple question - how much data average human can analyse(!)? Well trained? Not as much as some people think. There are only two reasons why some people ask for "large dataset" - lack of understanding and... lack of understanding. Customer requirements in first case and just requirements in second.
So... Just minimize your dataset. SSRS is not designed for "bring me something - I will check it later" concept.
Nice one. Do you get away with this in negotiations with a customer? There are customers that have quite a big pile of (useful) data which is mostly there to keep track of the (for them useful) stuff they have. When the newfangled technology craps out on these volumes, and the oldschool one they had before didn't, then there is no room for discussion left on what's wrong. The bottom line then is simply "not fit for business use".
Oh I agree with you. I don't use RDLC for everying, maybe about only 30% of our reporting needs. I find that for us at least, the sum of the tools available below meets our needs really well:
* RDLC - Anything that needs to physically print for external parties (e.g. document reports). Also, using it for any report that needs to be sent by email. Since 2013 we can't run automations locally, so we can't send excel buffer reports from the NAS.
* Excel buffer - Anything where having it straight in excel is convenient. However, since 2013 the excel buffer is very slow so now only using it for reports with small amounts of data
* OData + Powerpivot - Anything with a lot of rows needing analysis. (We use Odata for 80 % of our new reports).
@Miklos
* RDLC - Anything that needs to physically print for external parties (e.g. document reports). Also, using it for any report that needs to be sent by email. Since 2013 we can't run automations locally, so we can't send excel buffer reports from the NAS.
* Excel buffer - Anything where having it straight in excel is convenient. However, since 2013 the excel buffer is very slow so now only using it for reports with small amounts of data
Really?
Both have been fixed. Exporting to Excel now uses officexml that is a. fast and b. runs on serverside without excel installed.
Simple question - how much data average human can analyse(!)? Well trained? Not as much as some people think. There are only two reasons why some people ask for "large dataset" - lack of understanding and... lack of understanding. Customer requirements in first case and just requirements in second.
So... Just minimize your dataset. SSRS is not designed for "bring me something - I will check it later" concept.
Bro, have you not been following this thread? The answer to your question is the Inventory Valuation report. Another one is the standard Inventory to G/L Reconciliation report.
Customers want reports in summarized version, but want to have detail when they want it. This is the flexibility required.
On those two points, sorry my description was wrong, what I meant for the first issue was that excel buffer reports cannot be sent from the NAS since 2013, which is my issue. Error given:
"Message: Microsoft Dynamics NAV Server attempted to issue a client callback to create an Automation object: 00024500-0000-0000-c000-000000000046 (Report 50091 TheReportName). Client callbacks are not supported on Microsoft Dynamics NAV Server."
For the speed, I just gave it another try, but running a report that exports about 80000 ILE's from 2013 takes about 30 minutes, in 5.1 it takes about 5 minutes. I was hopeful at your words. I might try sometime to make an open XML version of the excel buffer, but for now RDLC takes care of it.
I'm sorry mate, but you must be doing something different from what I meant.
Your error message indicates that you have automation variables in your report 50001. This can never be the case if you use the excel buffer table (370) the way it is meant to be used.
Many thanks Mark.
You were right, the report I use as a template has a couple of the automations for creating new sheets in excel, pivots, etc.
I will create a stripped down version of the template I use based only on the Excel buffer for the NAS. This is good news! My apologies for sharing a misunderstanding.
This is important for me because I would like to go towards the direction of RDP only NAV access, no local clients installed. Makes upgrades, admin a lot easier. The problem is buying Excel twice, for the local PCs for everyday work and for the RDP server for NAV. So I am considering not having Excel on the RDP server. So exports still work this way? I assume OData doesn't.
I found out that I cannot show vertical lines in tables in Nav2013 - lines that separate cells from each other. For the last couple of days I watched my users missing cells because they dont know WHERE THE COLUMN IS. This is ridiculous. Can you imagine excel without vertical lines?
I found out that I cannot show vertical lines in tables in Nav2013 - lines that separate cells from each other. For the last couple of days I watched my users missing cells because they dont know WHERE THE COLUMN IS. This is ridiculous. Can you imagine excel without vertical lines?
I suppose that you mean NAV 2013 R2, since NAV 2013 still has them. Apart from that, I totally agree. It is an appalling situation that you have to tell the company accountant who is making his way through an endless confetti of numbers in rows and columns in worksheets and analyses each day of the week that these were removed, for no apparent reason. If these are not visible by default, there should be at least a property to reactivate them where you need these.
Comments
with best regards
Jens
http://mibuso.com/blogs/clausl/2013/12/ ... ckfactory/
The report curently gets all the detail but does not print it.
Still takes a while to run, but it does finish.
The other alternative is to use the example using SQL posted by ara3n a few years ago or some of the more recent postings.
The NAV dev team really needs to rewrite all the reports using their own report development principles.
http://mibuso.com/blogs/davidmachanick/
Let me rephrase, how do you print a large dataset using RDLC? Answer, you can't.
This means that you cannot rely on RDLC for any meaningful financial analysis.
Thank God for Odata (which I still can't get it to work), Excel Buffer (still has its limitations), SQL (rewrite standard code using SQL), writing a .csv file (back to DOS days?).
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
with best regards
Jens
I always like the diplomatic side of your comments. Nice one. Do you get away with this in negotiations with a customer? There are customers that have quite a big pile of (useful) data which is mostly there to keep track of the (for them useful) stuff they have. When the newfangled technology craps out on these volumes, and the oldschool one they had before didn't, then there is no room for discussion left on what's wrong. The bottom line then is simply "not fit for business use".
with best regards
Jens
Oh I agree with you. I don't use RDLC for everying, maybe about only 30% of our reporting needs. I find that for us at least, the sum of the tools available below meets our needs really well:
* RDLC - Anything that needs to physically print for external parties (e.g. document reports). Also, using it for any report that needs to be sent by email. Since 2013 we can't run automations locally, so we can't send excel buffer reports from the NAS.
* Excel buffer - Anything where having it straight in excel is convenient. However, since 2013 the excel buffer is very slow so now only using it for reports with small amounts of data
* OData + Powerpivot - Anything with a lot of rows needing analysis. (We use Odata for 80 % of our new reports).
Bruce Anderson
Both have been fixed. Exporting to Excel now uses officexml that is a. fast and b. runs on serverside without excel installed.
Fixed directly by MS or still need to create a custom Excel Buffer working with OpenXml?
Good
Is there any KB around regarding it?
Gunnar Gestsson
Microsoft Certified IT Professional
Dynamics NAV MVP
http://www.dynamics.is
http://Objects4NAV.com
So is there an example object available in NAV2013R2 with openxml?
Every object in NAV that uses the excel buffer uses officexml.
Check out the budgetting import/export features.
Bro, have you not been following this thread? The answer to your question is the Inventory Valuation report. Another one is the standard Inventory to G/L Reconciliation report.
Customers want reports in summarized version, but want to have detail when they want it. This is the flexibility required.
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
Just did. So as I understand it now the Excel buffer writes with openxml. After creating the file, excel is opened.
I did ask for some improvements regarding formatting etc. I hope they will implement that
On those two points, sorry my description was wrong, what I meant for the first issue was that excel buffer reports cannot be sent from the NAS since 2013, which is my issue. Error given:
"Message: Microsoft Dynamics NAV Server attempted to issue a client callback to create an Automation object: 00024500-0000-0000-c000-000000000046 (Report 50091 TheReportName). Client callbacks are not supported on Microsoft Dynamics NAV Server."
For the speed, I just gave it another try, but running a report that exports about 80000 ILE's from 2013 takes about 30 minutes, in 5.1 it takes about 5 minutes. I was hopeful at your words. I might try sometime to make an open XML version of the excel buffer, but for now RDLC takes care of it.
Bruce Anderson
Your error message indicates that you have automation variables in your report 50001. This can never be the case if you use the excel buffer table (370) the way it is meant to be used.
Here is some background on the Excel Buffer:
http://dynamicsuser.net/blogs/mark_brum ... uffer.aspx
Once used properly it should run in the NAS in 2013 without having Excel installed.
Good luck.
You were right, the report I use as a template has a couple of the automations for creating new sheets in excel, pivots, etc.
I will create a stripped down version of the template I use based only on the Excel buffer for the NAS. This is good news! My apologies for sharing a misunderstanding.
Bruce Anderson
Hi Mark,
This is important for me because I would like to go towards the direction of RDP only NAV access, no local clients installed. Makes upgrades, admin a lot easier. The problem is buying Excel twice, for the local PCs for everyday work and for the RDP server for NAV. So I am considering not having Excel on the RDP server. So exports still work this way? I assume OData doesn't.
I asume ODATA does not work.
This is good feedback.
Microsoft is reading this and I am in communication with them about certain issues in this thread.
Try setting a few filters in a page... :-k and take a coffee (sorry, couldn't help it)