List & Label Reporting Blog

Version 1.0 of the electronic invoice data format ZUGFeRD for the exchange of invoices has already been supported. For List & Label 25, the specification of version 2.0, officially released in March 2019, is now also supported.

.NET Standard and .NET Core have been around for a while now. We jumped the bandwagon early and offered beta support since LL23 while officially supporting the new framework since List & Label 24. With the advent of .NET Core 3.0, Microsoft announced that the .NET 4.x releases will be the last of their kind and .NET Core 3.0 – which will later simply be called .NET and will be named ".NET 5" in its next release – is the place to go. We're already there.

The combit Report Server celebrates its 5th birthday. Right on time for the anniversary, the product again has some new features to offer. We focused especially on the wishes of our customers.

Continuing our quest to make the table object more versatile and powerful in LL25, we added an important tweak to the way table lines are kept together. Before, you just had the choice between keeping all lines together or none. That means, if the output for a single record stretched over a couple of pages and consisted of several line definitions, there was hardly ever a way to get the wrapping "right". 

This has been another great suggestion from our community at Idea Place. While the mail module is quite flexible and can send mails via SMTP, MAPI and XMAPI, and can either use the client's mail dialog or a custom, built in dialog, there was no way to append Outlook standard signatures to the sent mails so far. Microsoft has finally declined the request to add this feature to Outlook's MAPI implementation. So there was room for improvement.

This is another of those "huh, you didn't have that before" features. As a WYSIWYG layout oriented reporting tool, the page has always been king for List & Label. While this is nice in many circumstances, when it comes to reporting for the web or XLS and printing is not planned at all, the result can be unwanted although looking beautiful.

Another step forward in our continuing quest to improve what's already great – our table object. Until LL25, you had to decide which widths you'd like to reserve for your respective columns. While this works out just nice most of the time, sometimes the result is less than perfect.

This is another great addition to the report container's feature set. Until LL25, related tables always needed to have an actual relation on the data source level in order to be usable as data source for sub items. If there was no relation, there was no way to insert the sub item, even if both tables in question had an ID field that would easily allow a custom linkage. In LL25, you can now have relations based on filter conditions.

Multi-columnar layouts for tables are quite popular for newspaper or phone book style reports. Whenever you have just a few actual columns in the table it's handy to use the page's real estate by splitting it in multiple columns. This feature has been around for ages, however it was missing one important setting until LL25.

Complex data is usually processed visually in dashboards in order to be able to capture trends, outliers or up-to-date data at a glance. The design of dashboards depends on important details. These details make the difference between whether the information is interesting for the target group and whether conclusions can be drawn from it or not. For example, a bar chart is better to capture than to work your way through hundreds of table entries. Dashboards are often used incorrectly and are hopelessly overloaded with numerous different charts and gauges, such as traffic lights, speedometers and hardly readable tables.