RDLC für NAV Entwickler #3 – Grundlagen des Layouts – Teil 2 “Der Textkörper”

Von | 27. Februar 2016

Als Folgethema zum RDLC für NAV Entwickler #2 – Grundlagen des Layouts – Teil 1 „Der Kopf“ gehe ich nun auf die letzten Details eines normalen Berichts ein! Hierbei gehe ich Schritt für Schritt darauf ein, wie man möglichst effizient eine neue Datentabelle (Tablix) im RDL integriert und mit Daten füllt.

Zu aller erst füge ich im Textkörper per Rechtsklick eine neue Tabelle (Tablix) ein.

RDL3_1_neueTabelle

Dann nehme ich folgende Schritte vor:

  1. Löschen zweiter Spalten.
  2. Entfernung der Randeinstellung (Border) der Tabelle von BorderColor Lightgrey auf Black und BorderStyle von Solid auf None.
  3. Verändern des Paddings von 2pt;2pt;2pt;2pt auf 2pt;2pt;0pt;0pt & Zeilenhöhe von 0,6 cm auf 0,423 cm.
  4. Umstellung der Schriftart von Arial auf Segoe UI und die Schriftgröße auf 9pt.
  5. Anschließend wähle ich nur die Zelle aus, in der Kopfzeile steht und stelle folgende Einstellungen ein: FontWeight – Bold / Textallign: Bottom
  6. Hinzufügen des Datasets zur Tabelle über die Eigenschaften der Tabelle.

Hier die Schritte visuell dargestellt:

RDL3_2_TabelleSpaltenlöschen

RDL3_3_Tabelle_Borderentfernen

 

RDL3_4_Tabelle_Sonstiges

RDL3_5_2_Tabelle_Eigenschaft

RDL3_5_3_Tabelle_EigenschaftDatset

Somit ist meine Tabelle vorbereitet. Ich bereite meine Tabelle immer am Anfang vor. Es gibt nämlich Eigenschaften, die später ausgeblendet werden, wenn man alle Zellen markiert und dann noch eine Einstellung verändern möchte. Somit spare ich bereits von Anfang an Zeit und konzentriere mich auch die korrekten Formatierungen. Es ist natürlich jedem selbst überlassen, welche Eigenschaften man verwenden möchte, aber die oben genannten Einstellungen kommen den Classic Einstellungen sehr nahe. Die Schriftart Segoe UI wird ebenfalls vom Standard genutzt.

Ich füge nun 6 weitere Spalten ein. Unsere Tabelle sollte jetzt so aussehen.

RDL3_5_Tabelle_7Spalten

Nun können wir uns um die zu druckenden Daten kümmern. Klickt man die Tabelle an, dann hat sieht man eine “Zeilengruppe” Details.

RDL3_6_Tabelle_Details

Diese besitzt aktuell die Standardeinstellung. Man kann sich Gruppen im RDL wie OnAfterGetRecords-Trigger vorstellen. Sie laufen nämlich immer über das DataSet. Gruppen sind also die Möglichkeit unsere Datenquelle auch auszugeben. Dabei sind zwei Elemente sind wichtig:

  1. Filter – Gruppen können gefiltert werden. Damit wird definiert, welcher Bereich des Datasets gedruckt wird. Ist kein Filter gesetzt, dann wird das komplette Dataset in der Gruppe durchlaufen.
  2. Gruppierungsfelder – Pro Gruppe können beliebig viele Felder definiert werden, nach denen das Dataset gruppiert wird. Gruppiere ich also nach der Debitorennr., dann wird innerhalb der Gruppe nur eine Zeile pro Kunde ausgegeben, auch wenn es darunter x-Posten gibt.

Diese zwei Eigenschaften machen wir uns natürlich zu Nutze. Für unseren Bericht “Debitorenstatistik” benötigen wir zwei Gruppen! Eine Gruppe für die Debitoren und eine ungefilterte Detailgruppe zur Ausgabe der Debitorenposten. Daher füge ich per Rechtsklick auf die Details, eine übergeordnete Gruppe ein.

RDL3_7_Tabelle_NeueGruppe

Die neue Spalte am links, lösche ich gleich wieder, da ich diese Spalte nicht brauche.

RDL3_8_Tabelle_NeueGruppe2

Damit haben wir nun die Grundlage für unsere Datentabelle. Ich befülle die Tabelle nun mit Daten. Wie man die Felder anordnet oder wie man diese formiert möchte ich jedem selbst überlassen.

RDL3_9_Tabelle_Feldereingefügt

Wichtig ist nun, dass wir die Kopfzeile auf jeder Seite wiederholen und die Kundendaten wiederholen, wenn es einen Seitenumbruch gibt. Dafür muss der “Erweiterter Modus” aktiviert werden.

RDL3_10_Tabelle_ErweiterterModus

Anschließend sehen wie auch die “statischen” Zeilen in den Zeilengruppen. Damit der Kopf wiederholt wird und die Kundendaten wiederholt werden, muss die erste statische Zeile und die Kundenzeile mit den folgenden Eigenschaften ausgestattet werden.

RDL3_11_Tabelle_TransHeader

Die Eigenschaft “HideIfNoRows” blendet die Überschrift aus, wenn sich keine Datensätze im Filter befinden. Das halte ich in diesem Fall für nicht notwendig, sollte aber berücksichtigt werden, da Tabellen in Berichten nicht gedruckt werden, aber trotzdem Platz reservieren.

Ich speichere das Layout und kann den Bericht nun ausführen. Dabei kann es je nach Datenbasis die unterschiedlichsten kleinen Probleme geben. Beispielsweise, dass Kunden gedruckt werden, die gar keine Posten haben, die Abstände sind zu knapp oder die Formatierungen gefallen einem nicht. Ist man mit allem fertig, dann sollte die Tabelle genau links oben im Textkörper positioniert werden. Ebenfalls sollte es keinen leeren Bereich im Bericht geben. Das würde nämlich nur dazu führen, dass Platz reserviert wird und das kann beispielsweise zu nicht gewollten Seitenumbrüchen führen. Mein Bericht sieht im Ergebnis so aus:

RDL3_12_Debitorenstatistik

Zum Prüfen oder einfach zum Schauen gibt es hier den Bericht als fob und txt: R50000_Debitorenstatistik_160227

9 Gedanken zu „RDLC für NAV Entwickler #3 – Grundlagen des Layouts – Teil 2 “Der Textkörper”

  1. Pingback: RDLC für NAV Entwickler #5 – RDLC Belegdesign – Grundlagen & unterschiedliche Kopfgrößen - Microsoft Dynamics NAV Community

  2. Pingback: RDLC für NAV Entwickler #5 – RDLC Belegdesign – Grundlagen & unterschiedliche Kopfgrößen | Robert's Dynamics NAV Entwickler Blog

  3. Pingback: RDLC für NAV Entwickler #4 – Kopieren von Berichten / Layouts | Robert's Dynamics NAV Entwickler Blog

  4. Pingback: RDLC für NAV Entwickler #6 – RDLC Belegdesign – Übertrag - Microsoft Dynamics NAV Community

  5. Pingback: Dynamics NAV Belegdesign RDLC Übertrag Funktion | Robert's Dynamics NAV Entwickler Blog

  6. Dennis

    Vielen Dank für diesen Beitrag, wir waren schon fast daran verzweifelt, die Kopfzeilen eines Tablix auch auf der zweiten Seite gedruckt zu bekommen.

    Wieso besitzt das Tablix selbst solche Flags (Repeat Header/Column Rows on each page), die aber einfach ins leere laufen und man stattdessen an den Zeilen selbst was einstellen muss – das kann einen ja dann nur verwirren

    Antworten
  7. Hussein

    Hi,

    zunächst vielen Dank für diesen ausführlichen Beitrag. Eine Sache ist mir noch unklar. Nachdem die Tabelle hinzugefügt worden ist, woher kommen die Caption Felder PostingDateCaption, DocumentTypeCaption etc…..Diese wurde ja nicht im DataSet definiert ?

    Viele Grüße,

    Hussein

    Antworten
    1. Robert Beitragsautor

      Schau mal im Report Designer in C/SIDE unter View bzw. Ansicht -> Labels

      – Lables werden nur einmal übertragen (performanter und sinnvoll bei internen Berichten, die in der Sprache des Clients gedruckt werden sollen)
      – Textkonstanten müssen im Dataset übergeben werden und werden dann für jeden Record erneut übertragen. Das benötigt man nur, wenn man die Sprache innerhalb des Berichtsdruck ändern möchte (Beispiel: Rechnungsdruck über drei Rechnungen – eine davon ist für einen Deutschen, eine ist für einen Engländer und eine für einen Franzosen. In diesem Fall kann man die Sprache mit CurrReport.Language im Bericht ändern und damit werden die Textkonstanten dann auch in der jeweiligen Sprache des Kunden übertragen.)

      Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert