Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Microsoft Dynamics NAV 2009 RTC report design using RDLC has a lot of flexibility when formatting dates, times, and numbers. While you can create custom number formatting (which we will cover in a future blog post) many of the standard formatting options will often do the trick far more easily and without requiring the developer to worry about localization differences.
For a full list of the formatting options, the MSDN site has a handy reference page for both numbers and dates/datetimes/times. I will not be covering all of the various formatting options in my example due to the fact that there are so many of them, but the most commonly used ones are represented.
The RDLC formatting options typically will use your default localization info for formatting. If you are a USA developer working for a French client you may need to change your current locale in order to see the formatting options as your client will see them. One of the nice things about the standard formatting options vs. the custom formatting strings is that they will take care of this change for you without you having to write a lick of code and without you having to define multiple formatting strings for each locale you service.
It bears mentioning that if you need to include multiple different locale formats in a single report there are some hoops to jump through to get that to work properly. We will cover that subject in a blog post very soon. Suffice it to say that it will not work to do multiple locales with just the standard formatting options.
Create your report data items in classic as you normally would. Our example report skips some of the good design steps for localization and multi-language in favor of simplicity. The entire report is just several different type data items in a single section:
Once you fire up RDLC and place your data item in the desired location you will want to look at the properties, specifically the “Format” property:
In the example above, I am formatting a decimal value to the locale default currency format (denoted by the “C”). Since I have my locale set to the USA, it will print in $#,###.00 format: Leading USD dollar sign, comma group separator, period decimal place designator and two decimal place precision. As I mentioned previously, if I send this report off to a French client I will not have to redo the report to print properly in Franc or Euro, the localized default format for currency will automatically handle that for me (Note: This does not convert the amount, only changes the format).
If, for some reason, I have to call a Code.SomeFunction to do some special processing and want to return the formatted text from that function it is worth noting that you can use these standard formatting codes in the VB.Net Format function call like so:
Public Function SomeFunction(ByVal Value As Decimal)
…processing code here…
See the attached sample report and PDF printout of the report that shows the most commonly used codes for more information.
Business Applications communities