Category Archives: upgrade

Going Live with Dynamics NAV (Dynamics 365) is the Easy Part

Overview

After doing ERP implementations with Dynamics NAV (aka Dynamics 365) for almost 2 decades (18 years to be exact…), you kind of know how to get things done.

Usually, when you prepare for a go-live during a software conversion, there are certain tasks and steps that absolutely have to be accomplished in a certain manner. There are certain things that you will also postpone until after you go live with the new system. Balancing what are absolulte musts and what can wait are what every legitimate project manager should do.

Another pitfall is spending countless hours talking about the exceptions and the wrong business process that ensues. Again, a legitimate NAV project leader should not take you down that path. From my experience one of the guarantee failures of taking a customer live is trying to “do too much”. Focusing on things that does not really matter to the business. As a legitimate Dynamics NAV (Dynamics 365) project manager, you should be well aware of what to be done and what shouldn’t be done when going live. On this subject, this is probably a separate article.

The Go-Live

A week prior to, you begin to feel the nervousness about switching to a new system. Despite my assurance on how everything will be fine because we followed the plan, they will still feel very anxious. The anxiety in the air is so thick you can scoop it with a spoon.

When the live date approaches, we do our thing to do the final cut over to their legacy system to Dynamics NAV. Run through our check-list and have the customers go through their check-list.

The next day when people come in for work, you can tell they were ready. They were ready for this because that’s what they’ve prepared for.

About a few days after the customer is live with the new system, the most frequent response I get is:

“That’s it?”

The Real Challenge

“Yes, that’s it. You’re live with Dynamics NAV.” That’s the response I typically give in response with a smile. As I mentioned, going live with Dynamics NAV is the easy part.

This is the point where my anxiety begins to increase, little by little.

Why?

If the customer just transacts with their normal business process and their customers and vendors behaves the same way, then everything would be okay. But it never happens that way.

There are always new problems and challenges as time progresses. Businesses do not stand still.

A couple of of these issues after go live that will begin to raises my blood pressure are, but not limited to the following:

– Exception problems or problems that are just weird and unusual
– Things that were allowed from their old system that are no longer allowed in the new system (i.e. just deleting a posted transaction)
– People circumventing the agreed upon process
– Wanting to turn on new features
– The “I didn’t mention because it’s not that important” processes. Well… It’s important now.

The toughest portion for the end user is after they go live for about 2-3 weeks. This is when all of the weird processes and exceptions start occurring and they have to deal with problems using the new environment and new thinking. Problems where they could just change a few numbers or transactions in the old system quickly, but they can’t do that anymore.

This is the part where the problems gets interest, and quite frankly, more fun. This is also the part where most solution center do not focus on because it’s not as lucrative.

Good Business Practice is a Lifestyle

What you resolved with your NAV partner during a new implementation is what you’re currently doing and where you want to go. These are known problems that has been brought up and addressed during the design of the software.

What challenges you going to face in the future are what we haven’t spoken about. It’s tough to plan and have a solution for something that you don’t even know about.

Dynamics NAV is a very good system. It’s also a very strict system. When you have an accurate system, sometimes problems come up where it was not apparent before or been swept under the rug. The reason is because it’s not important enough to deal with on a daily basis. i.e. inventory inaccuracies on the bins or returns processing.

With an accurate system, all of these normal process that no one wants to deal with will become apparent and will require a correct process and procedure for. Sometimes, when addressing these annoyance, owners will be surprised that they need additional resources to manage those processes.

Most of the time, when left unaddressed, those problem will blow up like a huge volcano. Implementing Dynamics NAV prevents these volcano type problems because it needs to be tracked.

Conclusion

Compound to real problems arising after 2-3 weeks is that implementation consultants will have already left by then, patting themselves on the back on a job well done.

As much as I advise on budgeting enough time and money for post implementation support, they always go unheard. Most of the quote that they receive for new software implementation are only enough to take them live, not to address these more interesting problems after they’re live.

Going live with Dynamics NAV (aka Dynamics 365) is the easy part. What comes after will be the core of the challenge during the implementation lifecycle.

Types of Training in Dynamics NAV

Overview

Often, we get calls from companies that asks us to help with their Dynamics NAV implementation. The conversation would usually start off about a little history of their implementation, the problems they’re running into, and what they’re looking to resolve.

Inevitably, the request will lead to training the users on how to better use Dynamics NAV.

This is a tough question to respond to.

With every release of Dynamics NAV, the software has become more intuitive and easy to use. In addition, Microsoft has released the full manual on their MSDN site. In addition, there are great step by step examples on how to process, for example, a sales order. So whenever I hear this request, my sense immediately goes into overdrive.

Of course, the customer will want an estimate on how long that will take.

Tough Question

What makes the subject of training a tough question is that the training, in itself, is not what the customer is looking for. What the customer is really looking for is, by the end of our task (whatever that may be), their users will have thorough understanding of their job responsibilities within the company and how Dynamics NAV can better their ability within their job roles.

They’re looking for their users to have an A-ha basically saying “Wow! I fully understand my job and can do my job 300% faster now!”.

The Response

Being a terrible salesperson, instead of giving them some numbers and try to close the deal, will naturally ask a ton of questions on their request. I will even question their question because I just find this request (although challenging) very fascinating.

Most of the time, the people that are reaching out are not the managers or the people that are responsible for the task. They’re just “forced” into it by their boss or owners. Instead of a number so they can create a list to find the cheapest one, they get more questions.

On a side note, the calls we get where the person has to hang up and ask their boss or other people for more information ususally never calls us back. Subsequent follow up calls are ususally unreturned as well.

Not All Training Are the Same

There are many aspects when we talk about training. To keep things simple, we’ll just talk about 2 types of training. One is just learning how to use Dynamics NAV, the other is learning how to use Dynamics NAV in conjunction with your job roles within your organization.

In my opinion, training just how to use NAV is not worth to company to spend their money on. The reason is, as mentioned above, there are plenty of resources (such as MSDN site mentioned above) that are free for the user to learn how to navigate around Dynamics NAV.

The training that I would always recommend is the implementation type of training is where the training covers the details of their job on how Dynamics NAV can help them do their specific job. The training would be how to better do their job with Dynamics NAV, instead of just using NAV.

The Challenge

The challenge is how to explain this to the customer who is tasked by their supervisor to “get more training”.

They would need to understanding their internal business process for each department and how NAV will fit into each part of the business process. They will need to fill the consultants in on how things work for the consultants to devise a training plan.

If the customer does not do , they will need to spend the money to have someone else to do so. Very much like an implementation.

Conclusion

Of course if the users do not have time to learn the product or they prefer to learn in a classroom environment, consultants like us would step in and help out. Even then, the training shouldn’t be just how to use NAV. Rather, it should incorporate what their job functions are within NAV.

Sometimes the training should just consist of a big Q&A session where the users can bring up what they’re doing and how to better utilize their job function in the system.

Understanding what type of training you require will save you a ton of time and unnecessary costs from consultants like ourselves. It does require some work on the end user to determine what kind of training is needed.

Better to put the work up front than having to pay, a lot, later.

When your Dynamics NAV Database is Too Big

Overview

Everyone once in a while, we will get a support call from a customer about archiving their historical data.

Dynamics NAV (formerly Navision) has been in the US since 1996 and for customers that were first to adopt Dynamics NAV, they have kept those data with them through the years.

Some will argue that with the cost of storage in decline, why is it necessary to archive old data. While I tend to agree with that statement, but trying to manage a 700 GB database backup, if nothing else, very time consuming.

There are a couple of ways to “shrink” the size of your database by eliminating the data within Dynamics NAV.

Data Compression

Date Compression Dynamics NAV

The date compression processes will consolidate multiple entries in the table in question into one entry.

The problem with date compression process is that it takes a loooong time to run. It takes so long to run that we usually just stop the process. The design of the Date Compression process seem to want companies to run it periodically when they start using NAV instead of running it when you’re database is 700GB. This is never the case.

Most Dynamics NAV consultants out there will never recommend their clients to use Date Compression (me included). One of the main reasons is because in the prior versions of Navision caused data problems when you did date compression when you try to upgrade.

Removing Data That Adds No Value

There are data in the database that one can consider as low priority value. You’re keeping the historical data, but the historical data is more “nice to have” instead of regulatory compliance or critical to running the business. These tables include, but are not limited to:

  • Change Log
  • Sales Document Archive
  • Purchase Document Archive
  • E.D.I. Receive Documents
  • E.D.I. Send Document
  • Posted Sales/Purchase Documents
  • Posted Warehouse Documents
  • Warehouse Registered Documents
  • Any posted documents

This is not to say you should delete all of the data, but you can certainly delete those data not required by the tax or audit authorities.

Re-implementation

This is the nuclear option. Basically, start fresh in a new Dynamics NAV database with only your setup data, master data, and opening balances. This option is popular with companies that have been using Dynamics NAV for a long time. It gives an opportunity to eliminate a lot of bad data, in addition, to modifications that are no longer needed.

The historical information is basically kept at the old database environment. If an old data is needed, the user basically goes to the old NAV database to retrieve the information.

But re-implementation is really overkill to specifically address the database size issue.

Conclusion

With the performance and capacity of storage ever increasing and the cost of storage ever declining, these types of question does not come up as often. I suspect as time progresses, these questions will come up once in a very long while.

I typically would recommend companies remove the data that adds little or no value first before attempting to do anything drastic. Usually holding those data takes a ton of storage in the Dynamics NAV database.

There was a company I visited that had 10 GB worth of Change Log entries. Worst is that the customer didn’t even know what the change log is…

Performance Problem in VM Environment for NAV 2016 and Beyond

Overview

This is a story of upgrading one of our clients from Microsoft Dynamics NAV 2013 to Microsoft Dynamics NAV 2016 (we recommended going to NAV 2017, but they didn’t want to be guinea pigs).

The upgrade itself was done on the customer’s live server, which was a brand new powerful server on VM (virtual) environment. During the upgrade, our developers complained that the performance on the live server was extremely slow. Initially, we thought it may have been the large amount of data (100 GB) that are being upgrade so we brushed it off.

When we went live, that’s when the performance on NAV got worst.

The Problem

Researching on Google and the Dynamics NAV forums on performance issues with Dynamics NAV 2016 came up with nothing. Of all the researches, NAV 2016 should perform a lot faster, not slower.

We’ve tried reindexing, changing the settings on the Dynamics NAV service tier, changing the CPU cores, SQL tuning. Nothing worked.

The problem in the end was how the VM hosts were setup. It matters which host SQL Server and Dynamics NAV server were setup. The following VM configuration was how the server was setup:

virtualenvironmentdynamicsnav

The Solution

The internal IT director put the Dynamics NAV server and the SQL Server on the same host on the VM and *poof*… All the performance problems went away. NAV was back running in blazing speed.

What was strange was that for NAV 2013, the SQL Server and the Dynamics NAV Server was running on different host and there were no performance issues.

Conclusion

When you’re in an VM environment, put the SQL Server and the Dynamics NAV server on the same host machine.

Upgrading to Dynamics NAV 2016 is nothing new for us. We’ve done quite a bit of the upgrades for companies but this issue baffled me a bit. The same structure used on NAV2013 did not work well on NAV2016.

Hopefully, if you read this, it will save you from some headaches that I’ve gone through.

Dynamics NAV Extensions – A Potential Weapon of Mass Destruction

Overview
With the release of Dynamics NAV 2017 and Dynamics 365 for Financials (which is technically NAV2017), the buzz word in the Dynamics NAV development community is the development function called Extensions.

What are Extensions?
Extensions is a way for NAV Developers to put modifications in your live environment without modifying your core NAV system.

How Does it Work?
The extension basically implements the code on the Service Tier instead of the NAV development environment. The clients connects to NAV using the service tier, this is how you see your NAV in whatever state it’s in.

Implementing the code directly in the service tier means that you won’t see any of the modifications if you go into the NAV development environment. You can only see the new tables created and table field changes if you look into the SQL tables directly.

Why is the Development Community Buzzing About This?
I honestly don’t know. I think the hype of Microsoft releasing something new have people gagaing and swept up into the hype.

I remember when Microsoft first announced the idea of multi-tenant for NAV services. Even though people didn’t fully understand it and it didn’t apply to 99% of the NAV population, the community still tauted like it was something that was the second coming. But… That’s hype and marketing for you.

At its current state, the NAV Extension will benefit partners and ISV in that they can quickly take their code and implement it on customer sites. In addition, it gives partners, ISVs, and independent NAV developers to protect their code from everyone else that does not have the “source code”.

For customers, the benefit is that the partners won’t charge too much for putting modifications that they’ve developed for other customers. They will now have a wide range of solutions that are developed in extensions they can essentially “bolt on”.

Lastly, it’s the only way to get your IP (intellectual property) on the Microsoft AppSource.

Why it’s a Weapon of Mass Destruction for a Company?

Notice the statement I made above:

It gives partners, ISVs, and independent NAV developers to protect their code from everyone else that does not have the “source code”

By implementing the code on directly on the service tier, nobody in the world will be able to modify what the original developer has done. The code that your partner/ISV/internal developer has put in is effectively sealed off from the rest of the world.

This means that if you are, for whatever reason, unhappy with your partner/ISV/internal developer, you better make sure, as a company, you have the original source code on which they built their extensions on.

Playing the devil’s advocate and assuming the worst scenarios with extensions

If you have a NAV or ISV partner that delivered their modifications to you as extensions and they provide terrible service and lacks basic knowledge of the product. If you want to ask another NAV partner or a freelancer to come in and help you, you will need the blessing of your previous NAV partner and pray that they are cooperative in provide the source codes.

If you purchased an ISV for your business, however, there are still some missing features on the ISV that you need your partner to add. Your partner will be unable to help you. You will need to reply in the ISV to re-release the extension for you.

If you have your own internal NAV developer on staff. If you need to terminate his employment for whatever reason, it’s very possible he/she can take the source code with them and leave you high and dry. No partner can come to your aide and you essentially have to live with what you have.

Conclusion
Even now, if you purchase an add-on in the 30 million object ranges, you’re effectively held prisoner by your ISV or the partner. There are special ways to “hack” the 30 million object ranges within SQL, but it’s usually messy and will incur a lot of additional expense on your part.

However, with Extensions at it’s current form, it will be impossible for any NAV developer to come help you if you do not have the original source code for the extensions.

Dynamics NAV (Navision) has always been an open source software. Implementing a structure where you effectively seal off the code is troubling.

It seems like before you do any kind of Extensions development with your partner or customer, you will need to lawyer up first. And as we all know, once you get lawyers into the mix, it just goes downhill from there.

Why it makes sense to upgrade to (at least) Dynamics NAV 2015

Overview
As you are all probably know, Microsoft has announced the next release of Dynamics NAV, called Microsoft Dynamics NAV 2016. With this release, there are a lot of fantastic features that are out of the box. Here’s an image of the planned features releases for Dynamics NAV 2016:

NAV2016

Historically, there are 2 major time consuming portion of an upgrade:

  • Code Merge
  • Data Upgrade

However, since the release of Dynamics NAV 2015, Microsoft introduced a number of PowerShell cmdlet to automate the upgrade process.

One of the cmdlet in the Development Shell called Merge-NAVApplicationObject, it essentially merges the application code for you and spits out any conflicts for you to resolve manually.

Additionally, Microsoft also introduced the cmdlet Start-NavDataUpgrade that will essentially run the upgrade toolkit for all companies as a script.

This means what used to take hundreds (sometimes thousands) of hours for an upgrade can now be done at a fraction of the time!

Not only major upgrades, you can use the same method to apply hotfixes that are released every month into your database without spending tons of hours on consulting fees.

All this… Providing you upgrade to at least Dynamics NAV 2015.

The Strategy Behind This
Prior to Dynamics NAV 2015, clients would wait, and wait, and wait, then wait some more until they find a version with the improvements they like; or sometimes wait until they can’t run Dynamics NAV in their current operating system before they even consider upgrading. This is why you see some end user sites running version 5.0, 4.0, 3.7, or even 2.0!

The problem when you’re behind on the versions in any software is that when you do decide to upgrade, it’ll be a major impact on your business and your budget. In some cases, companies running on older version of Dynamics NAV (or Navision as it was called back then) may decide to get rid of Navision and make the mistake of moving into a competing product.

This is a threat to Microsoft and they realize this. With the Upgrade cmdlets, Microsoft finally has a solution to this.

What Microsoft Hopes You Do
With these improvements, instead of having a major upgrade, you would do “incremental” upgrades (hotfixes every month, R2 releases, etc). This means that you would implement Dynamics NAV, apply all the monthly release hotfixes with the cmdlets, then use the same method to upgrade to the newer version when it’s released.

This goal is that when you guys do go to a newer version, the impact on your business and your budget will be incredibly minor; while the benefits for the newer version will have greater beneficial impact for your business.

What Microsoft do not want you to do is to wait and then do a big version jump with a big upgrade cost.

Conclusion
As any developer that have use the upgrade cmdlets will tell you, it’s good but it’s not perfect. However, it’s a FANTASTIC starting point.

What my personal hope is that the upgrade process will be so easy with future releases that the end user can run the upgrade themselves, rather than to hire a consultant to do it for them.

 

Optimizing your Aged Accounts Receivables Report

Overview
Doing numerous upgrades from an older version of Navision to NAV 2015 and 2013, one common complaint is how slow the reports are running. This is especially true for larger reports like the Aged Accounts Receivables, Aged Accounts Payables , Inventory Valuation, etc.

The old reports that took a long time, such as the Inventory Valuation report, will still take a long time. It doesn’t matter what version you go to. However, there are some reports that used to be quick, but is slow after the upgrade.

One of these reports is the Aged Accounts Receivables report (Report ID: 10040 – Aged Accounts Receivable).

The Breakdown
CAUTION: I’m about to get “programmer”. If you want the faster report, just skip down to the bottom and download the object.

Removing the Data Type of Column from the report, we get the following DataItem that the report loops through:

AgedReceivables

On initial look, the report looks simple enough. There are 3 data items:

  • Customer – The report loops through the customer record to see which customer we need to calculate the aging for
  • Cust. Ledger Entry – For every customer record it finds, it will loop through the all of the customer ledger for that customer. For any customer ledger that has a remaining amount, it’ll put it into a temporary table
  • Integer – This dataitem loops through the same records that are inserted into the temporary table on the Cust. Ledger Entry dataitem and summerizes the information to display in different aging “buckets”.

The Problem
The reason why this report is slow is if you check the DataItemTableView property on the Cust. Ledger Entry dataitem, you’ll see that the report is looping through ALL of the customer ledger for that customer.

NoFilterSet

This report will run fine if you’re A/R aging is small. However, this report will get slower as time progresses with more transactions. Worst, it’ll consume all the memory on the server and force you to restart.

The problem becomes real apparent when you have EDI customers that are running hundreds of invoices per day.

The Solution
The idea of the original A/R aging report is correct. Basically, look at the remaining amount based on the date criteria; if there is a balance, then it goes into the calculation.

The problem is that it’s not running any type of filters to exclude old transactions that has no relevance in our calculation.

To address the performance problem, here are the main things we will need to do:

  1. Look at only transactions that are marked as Open
  2. If the report is to be backdated, look into the only the history that pertains to the date criteria

First thing we do is to set the proper DataItemTableView property with the filter of Open.

FilteronOpenOnly

Then we need to add a new Detailed Cust. Ledger Entry dataitem to look at the application history of our A/R transaction:

The Property:

DCLEProperty

The Code:

AddDetailedCustLedger

Basically, we’re limiting the reads of the database to only open transactions and the subsequent A/R applications from the Aged as of Date set on the report.

Here are the report objects and the text file for your reference:
OptimizedARAging

Conclusion
Not sure what the developer at Microsoft is thinking when programming this report. Aged Accounts Receivable/Payable is one of the most data intensive reports next to the inventory valuation. Reading through every record just does not make sense.

Yes, it’ll work in the short run, but give a few years and the report will slow to a crawl, which is already experienced by customers upgrading.

Dynamics NAV 7 and Improvements to RDLC Reporting

Improvements
Having made a big deal about how bad the current RDLC for Dynamics NAV 2009 (Navision 6.0) has lead me to numerous disucssions with Claus Lundstrøm. For those of you who doesn’t know, Claus is the main guy behind the new reporting tool in Navision. He blogs regularly at the Dynamics NAV Team Blog on reporting and how to make it better.

Not being able to write too much on our discussion because of the NDA, Claus assured me that RDLC will not go away. It was important for everyone at Microsoft to emphasize that what partners had invested with learning the RDLC in NAV 2009 (Navision 6.0) will carry over to NAV ‘7’ and beyond. The RDLC will NOT go away.

Initially hearing this, my heart sank to the floor. I could not believe how customers can be better served with the current RDLC tool. That is until Claus showed me some improvements with the new RDLC tool and additional improvements that’s been moved to high priority after our discussion. Again, not being able to disclose too much, I can only say that I’m very optimistic about the improvements that will be made in NAV 7 (Navision 7.0). If not, you bet I will have more long discussions with Claus again.

NAV 7 Classic Report to be Discontinued
As many of you know by now, in NAV 7, the classic report will be discontinued. That’s not to say you have to convert every report to RDLC right now. Classic client report will still work, it just will not work if you decide to convert the report in NAV 7. Yes, there’s a button that you push in NAV 7 to convert each report.

On the side note, even though Microsoft has said that the classic report will be discontinued in Navision 7.0, I wouldn’t be surprised if that support would be removed when NAV 7 actually hits the store shelves. I remember when Microsoft announced in version 5.0, the classic client will be discontinued, only to continue support to what we have now.

The point is, the product has to be ready before partners can safely say “ok, we’re ready to move our clients to the new environment”. The new technology has to make our lives easier, not just prettier. As to what kinds of improvements can be expected, at least on the reporting side, in NAV 7, I’m just as in the dark as you.

Jet Reports Express and ZetaDocs Express Now included in Dynamics NAV
In case you haven’t heard the announcement at Directions EMEA 2011, Jet Reports Express and ZetaDocs Express is now available for customers who are current on their enhancement plan. The draw back is that this is only applicable to customers who are on version NAV 2009 and later.

I’m pretty excite about this. Jet Report is a very good tool for generating quick reports in Excel. Perhaps, with this tool, we won’t need RDLC anymore to generate quick reports for the end users. Jet Report is also very trainable to the end users. The only drawback with Jet Reports is that for complex and reports with a lot of data, it’s very slow and consumes a lot of resource. For more complex reports, we still prefer to suffer through the RDLC.

For those of you that wanted Microsoft to purchase Pivotier, I’m sorry. With this partnership, it looks like Pivotier will always remain an add-on for Dynamics NAV.

Anyways, here’s the information direct from Microsoft:

Jet Report Express for Microsoft Dynamics NAV

Jet Report Express for Microsoft Dynamics NAV is a business reporting tool that gives users an easy and simple way to create high impact reports. Within a familiar Microsoft Excel environment, users will be able to access and merge Microsoft Dynamics NAV data and utilize all of the Microsoft Excel capabilities, such as Power Pivot, formatting, charting and Pivot Tables, to create powerful, insightful and well-formatted reports – quickly and easily.

Jet Report Express for Microsoft Dynamics NAV will be released in Q3 CY2011.  Following a  careful review of customer and partner Business Intelligence (BI) & Reporting needs, Microsoft has worked in cooperation with Jet Reports, Inc. on the development of this solution, which enables us to enhance our BI & Reporting value proposition for customers and partners within the next few months.

Important Facts You Need to Know

  • Jet Report Express for Microsoft Dynamics NAV is available as new functionality for new and existing Microsoft Dynamics NAV customers who are on an active Business Ready Enhancement Plan.
  • Customers who use Jet Report Express for Microsoft Dynamics NAV are licensed under the terms of Jet Reports, Inc.  All training and support for the solution is provided by Jet Reports, Inc.
  • Jet Report Express is only available for Microsoft Dynamics NAV 2009 or later.
  • Access to Jet Report Express for Microsoft Dynamics NAV will be made available via a link from PartnerSource and CustomerSource within the next few months.

Zetadocs Express for Microsoft Dynamics NAV

Zetadocs Express for Microsoft Dynamics NAV makes it possible to store original documents associated with Microsoft Dynamics NAV records, such as emails, faxes and scanned documents, securely in one central location for quick and easy retrieval using Microsoft SharePoint Online.

With this new feature, users are able to work more efficiently. It’s possible to automatically capture electronic documents by dragging and dropping the documents inside Microsoft Dynamics NAV. The documents can then be retrieved and viewed from within the Microsoft Dynamics NAV RoleTailored Client or from Microsoft SharePoint Online giving users greater flexibility in accessing stored documents. What’s more, Zetadocs Express for Microsoft Dynamics NAV provides the possibility to setup a basic document approval process using SharePoint Online.

Zetadocs Express for Microsoft Dynamics NAV also makes it possible to email a report as a PDF attachment, filing a copy of the report automatically in Microsoft SharePoint Online. And, it supports simple automated email addressing for sales documents, such as invoices, using the email address stored in the customer card (if present). 

Zetadocs Express for Microsoft Dynamics NAV will be released in Q4 CY2011.  We are working with Equisys plc to bring this capability to market.  This reflects our excitement about the upcoming release of Office 365 – and the opportunities that integration between NAV 2009 and Office 365 will offer customers.

Important Facts You Need to Know

  • Zetadocs Express for Microsoft Dynamics NAV is available as new functionality for new and existing Microsoft Dynamics NAV customers who are on an active Business Ready Enhancement Plan.
  • A subscription to Microsoft Office 365 is required to use Zetadocs Express for Microsoft Dynamics NAV. Microsoft Office 365 is an online service from Microsoft that combines the familiar Microsoft Office Web Apps with a set of web-enabled tools.
  • Customers who use Zetadocs Express for Microsoft Dynamics NAV are licensed under the terms of Equisys plc.; therefore, all training and support for the solution is provided by Equisys, plc. 
  • Zetadocs Express is only available for Microsoft Dynamics NAV 2009 or later.
  • More information on Zetadocs Express for Microsoft Dynamics NAV will be made available via a link from PartnerSource and CustomerSource very soon.

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.