RDLC für NAV Entwickler #1 – Allgemeine Informationen & das Dataset

Es gibt immer wieder die gleiche Schwierigkeit im NAV-Projektgeschäft. Ob in einer Neueinführung oder in einem Update, die Thematik Berichte bleibt nicht aus. Dabei gibt es natürlich mehrere Möglichkeiten. Von Konvertierungstools (Classic zu RDLC) über eigenen Berichtsarten, die eine eigene Renderlogik und einen eigenen Designer haben, zu klassischen RDLC Berichten gibt es aktuell alles auf dem Markt. Wenn man danach sucht wird man auch fündig!

Aber was ist nun der beste Weg um das Problem zu lösen? Diese Frage muss jeder für sich beantworten. Ich denke alles hat Vor- und Nachteile. Als Vertreter von RDLC Berichten habe ich auch meine Erfahrungen gemacht. Ebenfalls habe ich mich mit den diversen Tools beschäftigt, aber kam nicht um folgende Argumente herum:

• Einsetzen der Technologie von Microsoft: Ok, es ist ja nicht so, dass Microsoft in NAV 2017 die Berichtslogik komplett über den Haufen wirft und etwas komplett Neues integriert, aber ich halte es für besser, nur von Microsoft abhängig zu sein. Tools, die den Bericht technisch außerhalb von NAV aufbauen und ebenfalls designen, müssen schließlich auch gewartet werden.
• RDLC ist gar nicht so furchtbar schlecht, wie viele behaupten. Klar, es ist nicht die perfekte Technologie für NAV Berichte, aber es ist auch nicht die Schlechteste.
• Trotz des doch nicht so leichten Einstiegs in das Thema RDLC bin ich schnell daran gewachsen. Vieles lässt sich in RDLC lösen und Probleme wird es vermutlich mit jeder Technologie geben, ob nun mit RDLC oder ohne.

Dem Gegenüber steht:

• Schnell und einfach Berichte designen
• Wer Classic Berichte kann, kann es auch mit unserem Tool oder einfacher Einstieg in das Tool
• Mehr Möglichkeiten als im RDLC
• …

Wie gesagt, das sollte jeder für sich entscheiden, ich halte mich dort an RDLC. Wenn ich einen normalen Arbeitstag betrachte, dann werde ich bestimmt 1x pro Tag zum Thema RDLC befragt. Gefühlt ist hier die Unsicherheit noch groß. Daher möchte ich die Serie RDLC für NAV Entwickler starten, da es gar nicht so schwierig ist, den Einstieg in das Thema zu lernen und ein paar Kernthemen davon zu erläutern.

In meinem ersten Blogeintrag möchte ich mich daher auf das Dataset beziehen und dazu meine Erfahrungen teilen.

Was ist also das Dataset? Im Vergleich zu Classic Berichten, definiere ich die Felder selbst, die ich innerhalb meines Berichtes nutzen möchte. Im Classic standen mir durch die integrierte Lösung, des Section-Designers, auch der Zugriff auf alle meine Felder und Variablen zur Verfügung. Im RDLC müssen wir jedes Feld oder jede Variable explizit angeben, sodass diese im Design an Visual Studio oder an den Report Builder übergeben werden.

Nehmen wir mal an, wir bauen uns eine Debitorenstatistik, die zu jedem Kunden alle Debitorenposten ausgibt. In diesem Fall verbinden wir wie im Classic zwei DataItems (Customer / Customer Ledger Entry) miteinander. Zusätzlich dazu lege ich fest welche Felder ich im Layout nutzen möchte (für Andruck oder für die Sichtbarkeit eines druckbaren Elementes).

Für die Entwicklung nutze ich Dynamics NAV 2016 mit Visual Studio 2015.

Das Ganze könnte dann so aussehen:

Wirft man einen Blick auf den Namen, dann fällt auf, dass ich nicht die eingefügte Beschreibung über das FieldMenü genutzt habe. Das würde nämlich normalerweise so aussehen:

Das mache ich aus den folgenden Gründen. Die Debitorentabelle ist vergleichbar mit der Kreditorentabelle. Wenn ich später aus meiner erstellten Debitorenstatistik eine Kreditorenstatistik machen möchte, dann müsste ich mein Dataset  wieder neu aufbauen. Ebenfalls müsste ich Änderungen im Layout vornehmen. Daher halte ich mich an folgende Regeln:

• Vermeide den Tabellennamen im Feld “Data Source”
• Vermeide einen zu spezifischen Namen im Feld “Name”

Hält man sich an diese Regel, kann man später aus einem Rechnungslayout ein Gutschriftslayout machen und lediglich die kleinen Änderungen innerhalb der beiden Belege bearbeiten. Das werde ich exemplarisch in einem späteren Beitrag an unserer Debitorenstatistik zeigen.

Zusätzlich zu unseren übergebenen Feldern, müssen wir ebenfalls Captions (Bezeichnungen / Überschriften) übertragen. Dafür gibt es im RDLC drei Möglichkeiten und unterschiedliche Anwendungsfälle:

• IncludeCaption Eigenschaft im DataSet:
  • Sollte genutzt werden, wenn der Bericht pro Ausführung immer nur in einer Sprache ausgeführt werden soll.
  • Sollte genutzt werden, wenn die Feldcaption aus der Tabelle für dieses Feld genutzt werden soll.
  • Wird einmal an das DataSet übergeben und steht dann dort als Parameter zur Verfügung.
• Labels (Ansicht -> Labels):
  • Sollte genutzt werden, wenn der Bericht pro Ausführung immer nur in einer Sprache ausgeführt werden soll.
  • Sollte genutzt werden, wenn man eine abweichende Caption im Vergleich zur Feldcaption angeben möchte oder für allgemeine Informationen (ReportCaption). Beispiel: Caption vom Feld “No.” aus der Tabelle Customer ist “Nr.” – Möchte ich nun, dass im Bericht “Kundennr.” als Überschrift angezeigt wird, verwende ich ein Label anstatt “IncludeCaption”)
  • Wird einmal an das DataSet übergeben und steht dann dort als Parameter zur Verfügung.
• Text Constants (Ansicht -> C/AL Globals -> Text Constants) / FIELDCAPTION / Variablen + Integration der Textkonstante in das Dataset:
  • Die Textkonstanten, Variablen oder FIELDCaption im Dataset sind das Gegenstück zu den Labels oder IncludeCaption und sollten verwendet werden, wenn sich im Druck eines Beleges die Sprache Datensatz bezogen ändern kann. Hierbei ist zu berücksichtigen, dass Sie das Dataset durch Verwendung von Textkonstanten stark vergrößern.

Klar es gibt auch die Möglichkeit, die Caption hart in die Textboxen im Layout zu hinterlegen. Das ist für mich aber keine Option.

In meinem Fall lege ich nun zwei Labels an und löse den Rest über IncludeCaption. Wir haben in unserem Beispiel keinen Bedarf an Textkonstanten. Des Weiteren gilt: Umso kleiner das Dataset umso schneller läuft der Bericht. Um bei Labels CaptionML zu pflegen muss man dort die Eigenschaften öffnen.

Mein Dataset sieht nun so aus:

Nun kann man sich das Dataset mal anschauen. Dafür führe ich den Bericht einfach aus. Um das Dataset zu betrachten, brauche ich auch kein Layout. Ich möchte lediglich prüfen, ob mein DataSet vollständig ist und das die Informationen so übertragen werden, wie ich es benötige.

Dafür öffnet man den Beleg und wählt über den weißen Pfeil im blauen Feld “Hilfe” aus und “Info zu dieser Seite”. Es öffnet sich ein neues Fenster, welches der Zoom des Berichts darstellt. Dieses Fenster schließen wir wieder. Starte ich nun den Bericht in der Vorschau, dann kann ich mir das Dataset ansehen.

In der geöffneten Seitenansicht, also wieder über den blauen Knopf “Hilfe” und diesmal “Info zu diesem Bericht” auswählen:

Danach öffnet sich das DataSet:

Hier sehen wir nun, das wir die Daten bekommen. Ich möchte kurz auf den Aufbau des Datasets eingehen:

• Jeder Kunde erzeugt mindestens 1 Zeile. Ausnahme: Wenn PrintOnlyIfDetail im DataItem “Customer” auf Ja steht, dann werden Kunden ohne Posten ausgeblendet.
• Der erste Posten wird immer auch in der ersten Zeile zum jeweiligen Debitoren angezeigt. Das sehen wir sehr gut bei “Progessive Ho…”
• Beim Kunden 10000 Möbel Meller KG gibt es mehr als einen Posten. In diesem Fall wiederholen sich die Information aus dem DataItem Customer für jeden Posten erneut.

Das Dataset ist also eine große Zusammenführung unserer DataItems und kennt keine Abhängigkeiten mehr. Das bedeutet, wir erstellen in NAV unsere DataItem Struktur um diese beim Designen verwenden zu können. Die Logik, wann wie etwas gruppiert oder gedruckt werden soll, müssen wir im RDLC anhand der Datenbasis des Datasets selbst festlegen.

Wie wir hier sehen können, werden Labels oder die Captions der Felder mit “IncludeCaption” hier nicht angezeigt. Diese werden einmal übertragen und sind nicht Teil unserer Dataset-Struktur. Diese Felder stehen uns in Designer als Parameter zur Verfügung. Darauf gehe ich das nächste Mal ein, wenn ich das Layout und die Beschaffenheit der Elemente etwas näher erläuterte. Ebenfalls sehen wir hier, dass zu jedem Decimalfeld auch eine Formatierung übertragen wird. Diese Formatierung basiert auf der Vorgabe des Tabellenfeldes. In den Einstellungen des Feldes im jeweiligen DataItem kann die Formatierung dann auch nochmal geändert werden.

Bei Fragen schreibt mir einen Kommentar. Ich versuche die Fragen nach meinen zeitlichen Möglichkeiten zu beantworten.