Category: upgrade

Navision RDLC reporting – SetData and GetData – Why It Is REQUIRED

Ever wondered why there’s no tutorial on how to create a Sales Order report from scratch in the RDLC? The reason is because it takes a LONG TIME! Even for an experienced developer, it takes a long time. As I previously mentioned on my article, Microsoft really needs to address this in future versions.

The reason for SetData and GetData is not because of performance reason as stated in the manual 80146B. For additional information on defining SetData and GetData, please look here.

For multiple pages, the header data is dependant on whether there are lines. If you’re printing multiple form type reports like the sales order and you do not use the SetData and GetData, the header will only link to the lines displayed on the first page of the report. So this means that if your sales order is printed to the 2nd page, the header information will all disappear.

Here’s an example if you create a report without using the SetData and GetData logic:

This is the first page. As you can see, the header displays nice and pretty. I used whiteout to remove some sensitive information in Paint.

Now this is what happens when you print the 2nd page:

No, it’s not an error. You’re seeing it correct. It’s a blank page. I didn’t even have to use Paint to remove any information.

The reason why the 2nd page is blank, again, is because the link was done only on the first page on the header. If the report goes to the 2nd page, the link is essentially gone, therefore, no value is loaded and so nothing is displayed.

 

So when you create a report that has headers in forms (sales order, quote, etc). You need these:

Shared Offset As Integer
Shared NewPage As Object
 
Public Function GetGroupPageNumber(NewPage As Boolean, PageNumber As Integer) As Object
    If NewPage
        Offset = PageNumber – 1
        NewPage = False
    End If
    Return PageNumber – Offset
End Function
 
Public Function IsNewPage As Boolean
    NewPage = True
    Return NewPage
End Function
 
Shared HeaderData As Object
 
Public Function GetData(Num As Integer) As Object
   Return Cstr(Choose(Num, Split(Cstr(HeaderData),Chr(177))))
End Function
 
Public Function SetData(NewData As Object)
    If NewData <> “” Then
        HeaderData = NewData
    End If
End Function

 And you need these controls with the proper code:

We spent hours and hours trying to get our report header to print on multiple pages. Don’t make the same mistakes we did!

EDIT – Thanks to Steven for pointing this out. It turns out that this was mentioned on the 80146B manual on Chapter 3 page 35. Shows you that you shouldn’t go through the 300+ page manual quickly!

Open Suggestions to Make Navision RDLC Reporting More Efficient

Working with the new RDLC reporting for a few months now after the NAV2009 release, I thought I would like it as I work with it more. Sad to say, that hasn’t happened yet. It’s like being in a bad relationship and hoping some day that it’ll magically get better. And from the general consensus from NAV forums like mibuso.com and dynamicsuser.net, I’m not alone.

The new RDLC reporting tool in Visual Studio makes creating new reports is a lot longer (and tougher) than if you were to create the same report in the C/side report writer. For NAV, we’re all about efficiency. This RDLC reporting tool is by no means efficient. The report writer should be simple and can be easily picked up by non-developers (i.e. end users), RDLC reporting tool is not.

When I saw the demo for the capabilities of the new reports, I must admit I was drooling. If only I had known at the time that I would have to pull all of my hair out to realize only a portion of those capabilities.

Microsoft said that NAV2009 (Navision 6.0) was going to create new opportunities for partners, I’m not sure who they’re referring to. For companies that create external reporting tools like Jet Reports or Pivotier, I have to say this RDLC reporting tool benefits them the most. They are probably laughing all the way to the bank. But for the rest of the general public, I’m not so sure what kind of opportunties they’re talking about…

So in an attempt to make this relationship better and easiers for partners and end users alike, I would like to make 2 suggestions on how Microsoft can help us improve the relationship we have with the new RDLC reporting tool. Yes, just 2 suggestions.

Suggestion #1:
If Everything Has to be in Table Format, Why Not Just Get Rid of the Layout Designer?

For this suggestion, I’m going to use report 10048 (Customer/Item Statistics). This is one of the more popular reports for customers to analyze who bought what.

Before a standard C/Side report can be converted into the RDLC format, you must first create the sections in the C/side report designer. This is what it looks like on the Section Designer:

The report printed from this is pretty straight forward:

It’s not perfect, but a novice Navision developer or the ned user can easily go in and modify the formating easily and add and remove fields very easily.

Now let’s look at the RDLC layout for this same report:

The output is almost exactly the same. If you save this report to Excel, the formatting would still be messed up. So all the features stayed the same and all of the problems came along with it. Other than the ability to save it as PDF, there’s no benefits that can be seen.

This report is not what the customer signed up for and it’s not what we’ve all see in the demos. I spent a few hours creating the proper layout so the report can take advantage of the features described in COURSE: 80146B – Report Design in Microsoft Dynamics NAV 2009. Here’s what I came up with:

This is the RDLC layout that I had to create in order to generate a report like that:

In order to take full advantage of the capabilities that you saw in the NAV reporting demo, you have to put everything into Table(s). For every standard NAV report, none of the formats created allows you to easily convert it into the format that is needed. Even if you used the Create Layout Suggestion feature in the report designer, it wouldn’t format it properly into what is needed.

The problem is that the reporting tool is still trying to replicate how standard C/side report works. Standard C/side report does not work well in the RDLC environment. It’s what we’ve been told. We get it. But why is the tools built within NAV saying the opposite?

If everything nice and cool in the RDLC requires Table(s) to work, why not just eliminate the RDLC layout designer completely? For list type reports (which is what we’re dealing with), we only use the layout designer to put fields we want to be displayed. We’re not making anything pretty like Sales Order, Sales Invoice, etc. If the user needs list type report to look pretty, or add some wierd format, it’s easy enough to export this report to Excel and manipulate the formatting there.

If that’s the case, why not just allow a table-like report designer and have this designer automatically create the report layouts for us? This designer should allow us to easily group records, create formulas, bold, underline, etc. Allow us to utilize the capability of charting, document mapping, etc with option like interface.

Basically, as I mentioned previously, eliminate the layout designer completely and have the computer AUTOMATE the layout process for us. Create the appropriate tables for us to allow us to take advantage of the new reporting features.

Having this will allow the end users to easily create their own reports within NAV with greater efficiency and would promote the non-IT end users to be more involved with NAV. And we know for a fact that the more involved the user becomes with how the data flows, the better they will trust in the system and the happier the users will be.

The last thing we want NAV to become is a software that only people with high technical ability knows what’s going on.


Suggestion #2:
For form type reports, blow it up!

For form type reports, such as sales order, sales invoice, purchase order, etc. We don’t need nice features like document map, expand/collapse, etc. So why are we fussing with the RDLC layout report writer?

Even when the sales order is properly formatted in the RDLC, the preview of the report will not match what’s actually printed. If you print a sales order right now, the preview will not match what is being pritned on paper.

Microsoft seems to have taken away the WYSIWYG (What You See Is What You Get) functionality in print preview. Any report writer will tell you that having a WYSIWYG preview is very important when we create a delicate form type report with nice graphics, lines, boxes, etc. How can we make quick changes to align everything perfectly if we cannot quickly view them? We have to either print them on paper or print them to PDF.

The suggestion here is simple, again, eliminate the RDLC layout designer and create a new report designer for forms that allows NON-TECHNICAL to create nice and professional forms.

Conclusion:
I will repeat this over and over again. The best customers we have are the customers that actively tries to learn the system. Most of these users are non-technical.

I understand the desire to move to a more general report writing tool like Visual Studio, I understand the need to move into a language that are more generally accepted. However, I can easily teach someone how to create and modify reports in C/side environment to a non-IT person. I cannot say the same with RDLC reporting tool and Visual Studio.

As I mentioned in the previous article, NAV is a business software, NOT an IT software. As such, everything in NAV must be designed so a business person can easily utilize its full potential. The ease of use should not stop at the front end, it should extend to the back end as well. Including development.

Properly Upgrading to New Versions of Dynamics NAV / Navision

Despite what the salespeople will tell you, an upgrade is an intensive task. While it’s not as intensive as doing a new implementation, it should not be taken lightly by the partner or the end user.

One of the best things about Dynamics NAV/Navision it gives you the freedom to modify it so it fits your company like a glove. It’s because of this freedom, that you’re able to gain an competitive edge over your competitors and/or to satisfy your customer’s demands. With that freedom, you may have made a ton of modifications in order to satisfy a certain operation at some point in time.

As we all know in the world of business, everything is constantly changing. Requirements change, the way business is done change, the way we interact with each other change. Some change for the better, some may be worse. But one thing that is constant is that we, as human beings, cannot foresee the future changes with 100% certainty. Because of this, business owners and decision makers will often make modification requests that satisfies certain demands of their industry that seems brilliant at the time, but is quickly phased out in place of other changes.

The ERP software itself has to change with the business. This is why you’re considering a software upgrade to your business. Because business demands have changed and the technology has changed.

Having said that, there are basically 2 ways of doing an upgrade. In this post, I will explain the 2 methods of doing an upgrade and why I prefer one way over the other.

Merge Object Run Toolkit
One way to do an upgrade is the “merge object run toolkit” method. There are numerous tools to merge code, in fact, I’m surprised there’s not already a tool out there to automatically merge the code for you. Troubleshooting the error messages that comes up after compilation is easy. A programmer just have to compile, identify the problem, change the variables, remove some code, add some code, then done.

The merge object run toolkit option is quick, simple – a monkey can do it. In fact, if you were to go this route, I suggest you ask your solution provider to export all the codes into a text file, then hire an intern to do the code merge for you. Then ask your solution partner to toubleshoot errors that comes up. It’ll be a lot cheaper than asking your solution provider to hire an intern and bill you for it. If you don’t feel comfortable with an intern, you can contract an offshore developer for $10.00 to $15.00 an hour to do the merge for you.

The “merge object run toolkit” method is th the absolute wrong way to do an upgrade. Essentially, you’re piling on crap on top of crap. In this case, you’re better off NOT upgrading and staying with whatever version you’re using. It’ll save you a ton of headaches and unnecessary expenses.

Analysis of Objects then Upgrade
An upgrade has many benefits. They include newer technology so your workers can be more efficient, new ways of bringing information together at your finger tips, easier to get a new hire on board with easier interface. The additions are many.

However, one of the least looked at of the benefits of an upgrade is what we can take out. As stated before, because of Dynamics NAV/Navision ability to customize, you may have made some changes in your system that is no longer used or used sparingly. Removing unnecessary codes will simplify your processes, screen layouts, reduce training for new employees, and yes, improve the performance of your database.

In addition, there may be some changes or modifications done that is now part of the standard functionality in the new version. You may also want to consider removing those the modification in favor of the standard functionality to make support and future upgrades easier.

Doesn’t this seem like a lot of decision making for a “simple” upgrade that you may have been promised?

When doing an upgrade, assuming you have partnered with a good solution provider, should do analysis on existing modifications. List all important changes and modifications done to the existing database. Suggest what can be taken out and if the modifications have a standard function equivalent.

From the list, the users will need to decide what modifications can be removed, what to keep, whether to use existing functions, or revamp the existing process for a better process provided by the new system.

For the NAV partners, this requires a good knowledge of new features and how the new and existing functionalities are used.

Conclusion
Needless to say, I’m not a fan of of the first method. If you’re planning to upgrade using the “merge object run toolkit”, I would highly suggest you to save your money or donate that money to charity.

If you received a quote from a partner for an upgrade with the “merge object run toolkit” method, I would hang up the phone, burn the quote, and run as far away as possible. You may need to take a shower and change your phone number as well.

Be Current or Not Current on the Microsoft Annual Enhancement Plan

Since Microsoft announced the new Business Ready Enhancement Plan Renewal Policy, talks about whether the customer should stay current has increased significantly.

At 16% of your total software list price, it’s potentially a sizable recurring investment for companies using the software. Not just specifically to Microsoft, almost all ERP, CRM, business software out there requires users to pay an annual enhancement of some sort.

Other than the obvious questions of “what do I get for staying current?”, the benefits are numerous and I encourage you to get with your partner to learn what these benefits are. But the primary reason with the new policy is that you need to be current in order to purchase additional granules and users.

This may sound very scary at first, but hopefully this blog post will put in perspective on what this means should you decide to stay current or not.

1. How many years of Enhancement will I pay to pay for the software again?
Assuming your system list price is $100.00. At 16%, you’d be paying $16.00 per year. So $100.00 / $16.00 = 6.25 years. You would need to be current on the Microsoft Enhancement Plan for 6.25 to pay for the software again.

In another words, the bet you placed by staying current on the enhancement plan is that Microsoft will release new versions of NAV that you will upgrade to (full or executable only) during 6.25 years. In addition, with the new enhancement plan policy, you’re also betting that you’re business will grow and change, therefore, requiring additional modules and user licenses in the 6.25 year time span. So if you’ve purchased additional modules, upgraded, etc during the 6.25 year time frame, you’ve won.

2. How many years can I not pay the enhancement plan for the cost to accumulate to pay for the software again?
Again, assuming your system list price is $100.00. Assuming that you decided to skip the enhancement after the first year, the penalty you’ll pay is around 20% (you may have to check the exact percentage in your area). So $100.00 / $20.00 = 5 years. You can skip the enhancement for 5 years and pay for the software again in 5 years.

In another words, the bet you placed by NOT staying current on the enhancement plan is that Microsoft will not release anything of interest worthy of upgrading your system in the next 5 years. You do not expect your business to see growth or changes to purchase additional modules or user licenses. If you have not purchased any modules or done any upgrade to newer version in the 5 years since you skipped the enhancement, you’ve won.

Conclusion:
In a down economy, it may pay not to be current if you do not expect the cycle of your business to turn up again within the next 5 year period. Then again, it’s pretty tough to gage what will happen in the next 5 years.

Whether or not to stay current really depends on the business and the people that runs the business. For the enhancement plan, I always view this as an insurance and the same type of mentality as an insurance. Most of the time you pay for the insurance premiums complaining about it’s hefty price, but when problems occur, you’re glad you paid the premium. In Navision’s case, the time is 6.25 years.