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.
Dann nehme ich folgende Schritte vor:
- Löschen zweiter Spalten.
- Entfernung der Randeinstellung (Border) der Tabelle von BorderColor Lightgrey auf Black und BorderStyle von Solid auf None.
- Verändern des Paddings von 2pt;2pt;2pt;2pt auf 2pt;2pt;0pt;0pt & Zeilenhöhe von 0,6 cm auf 0,423 cm.
- Umstellung der Schriftart von Arial auf Segoe UI und die Schriftgröße auf 9pt.
- Anschließend wähle ich nur die Zelle aus, in der Kopfzeile steht und stelle folgende Einstellungen ein: FontWeight – Bold / Textallign: Bottom
- Hinzufügen des Datasets zur Tabelle über die Eigenschaften der Tabelle.
Hier die Schritte visuell dargestellt:
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.
Nun können wir uns um die zu druckenden Daten kümmern. Klickt man die Tabelle an, dann hat sieht man eine “Zeilengruppe” 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:
- 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.
- 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.
Die neue Spalte am links, lösche ich gleich wieder, da ich diese Spalte nicht brauche.
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.
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.
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.
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:
Zum Prüfen oder einfach zum Schauen gibt es hier den Bericht als fob und txt: R50000_Debitorenstatistik_160227
Pingback: RDLC für NAV Entwickler #5 – RDLC Belegdesign – Grundlagen & unterschiedliche Kopfgrößen - Microsoft Dynamics NAV Community
Pingback: RDLC für NAV Entwickler #5 – RDLC Belegdesign – Grundlagen & unterschiedliche Kopfgrößen | Robert's Dynamics NAV Entwickler Blog
Pingback: RDLC für NAV Entwickler #4 – Kopieren von Berichten / Layouts | Robert's Dynamics NAV Entwickler Blog
Pingback: RDLC für NAV Entwickler #6 – RDLC Belegdesign – Übertrag - Microsoft Dynamics NAV Community
Pingback: Dynamics NAV Belegdesign RDLC Übertrag Funktion | Robert's Dynamics NAV Entwickler Blog
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
Das muss man Microsoft fragen 🙂
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
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.)