/
Reporting Empfehlungen

Reporting Empfehlungen

Empfehlungen für Reports vom Typ Auswertung und Sub-Auswertung.

Bilder / Image Behandlung

Vektor basiertes Bild-Format verwenden.

Wenn immer möglich .svg verwenden! - nur in Ausnahmen Bilder wie .png.

Siehe auch hier optimale Logo Formate Konfiguration von Login- und Header-Logo sowie FavIcon | Logo Spezifikationen

PDF Einstellungen

Damit exportierte PDFs nicht zu gross werden sind diese Export Optionen vordefiniert:

An den PDF Einstellungen auf dem Report wirklich nur dann etwas ändern, wenn es wirklich nötig ist. Die Gefahr riesiger PDFs ist sehr gross…

Reihenfolge der Bänder auf einem Report

Um den Aufbau und das Verhalten der Reports designen zu können ist es wichtig den Aufbau der Bänder zu verstehen. Das folgende Bild zeigt die Reihenfolge der Bänder in einem DevExpress Report. Zu beachten ist, dass der Page Header auf der ersten Seite nach dem Report Header angezeigt wird.

Unbenannt-20241023-140757.png
Reporting Bänder

Siehe https://docs.devexpress.com/XtraReports/2587/detailed-guide-to-devexpress-reporting/introduction-to-banded-reports

Grundsätze Report Design

Allgemein

Grundsätzlich soll wie folgt designt werden:

  • Page Margins auf 0 stellen damit Randabfallende Header/Footer Designs umgesetzt werden können.

    • grafik-20241122-155020.png
      Page Settings - Margins
  • Verwendung von Panels und Tabellen um die Controls hierarchisch zu verschachteln resp. auszurichten.

Design für Einzel-Objekte vs. Listen

Einzel-Objekt: Ziel ist ein einzelnes Objekt darzustellen und abhängige Relationen anzuzeigen

  • Report- oder Page Header/Footer sollten sich auf das einzelne Objekt beziehen

  • Bei den Einstellungen Einzelobjekt Report berücksichtigen! Siehe Reporting | Auswertung Details

Liste: Ziel ist eine Listendarstellen eines Typs

  • Zuerst prüfen ob die Möglichkeiten der Liste mit PDF und Excel Export genügend sind! Erst bei expliziten Designs eine Auswertung erstellen.

  • Der Report-Header/Footer wird nur einmal vor der Liste und einmal am Ende angezeigt. Spaltenüberschriften müssen mit PageHeader oder alternativ mit GroupHeader gelöst werden.

Übersetzung von Reports

Nie (wirklich nie!) durch Umstellen des “Language” Properties auf dem Report selber. Sonst werden auch Änderungen am Report-Layout und anderen Sachen sprach-spezifisch gemacht und das kann man eigentlich nicht mehr fixen. Der Report muss dann neu aufgebaut werden.

Siehe Localize Reports | DevExpress End-User Documentation

Mail Merge

Mit Mail-Merge können dynamische Werte in einen Fliesstext eingebunden werden. Siehe Beispiel für .NET https://docs.devexpress.com/XtraReports/2433/detailed-guide-to-devexpress-reporting/use-report-controls/bind-report-controls-to-data/use-embedded-fields-mail-merge

Sub-Reports

Verschachtlungen und Wiederverwendung von Reports ist möglich mit Sub-Reports. Siehe

Sub-Report Typen

  • Sub-Report von DevExpress direkt

    • Geeignet für statische Elemente oder Master-Detail Reports von :n Relationen

  • Quino-Sub-Report

    • Spezifischer Typ für die optimierte Benutzung von :1 und :n Relationen

      • Filterung des Reports kann für komplexere Abfragen nach der Expression Syntax verwendet werden.

    • Siehe Reporting | Quino Sub Report

Detail Report vs. Sub-Report

Wenn die Darstellung einer Relation oder Liste nur innerhalb eines Reports verwendet wird, dann sollte ein Detail-Report verwendet werden, da dieser einfacher zu integrieren ist. Sobald ein bestimmtes Design resp. ein Teilreport an mehreren Stellen wiederverwendet werden kann, sollte ein Sub-Report verwendet werden.

Optimierungen sind mit dem Quino-Sub-Report möglich.

Empfehlungen für Sub-Reports

  • Reports die nur als Sub-Report und nicht eigenständig verwendet werden, sollten mit dem Typ Sub-Auswertung. Diese sind damit nicht eigenständig in der Applikation ersichtlich.

  • Sub-Auswertungen sollten nicht mehr umbenannt werden! Der Verweis zu dem Sub-Report geht über den Namen. Ist dieser nicht mehr im System vorhanden, führt das zu einem Fehler und muss im XML des Reports korrigiert werden.

Corporate Identity / Corporate Design (CI/CD)

Schrift

  • Einstellung in jedem Report notwendig, da dies nicht mit Sub-Reports abgebildet werden kann.

  • Im Report generell einstellen, sollte möglichst nicht von einzelnen Feldern überschrieben werden.

  • Control-Styles sollte keine Schriftart enthalten, wenn diese vom CI/CD abhängig sein sollen.

Umsetzung Seitenränder

  • Grundsätzlich Margin in den Page-Settings auf 0 stellen

  • Design der Sub-Reports berücksichtigt die Margins

  • Jeder Report muss im Design die seitlichen Ränder berücksichtigen

Logos

  • Möglichst als SVG bereitstellen, siehe Bilder / Image Behandlung oben

  • Schriften können innerhalb des Bildes oder Sub-Report abgebildet werden.

Statische Designs

Ein statisches Design hat auf allen Seiten immer den gleichen Header und Footer. Es gibt da keinerlei Einfluss auf das Aussehen der Header und Footer aus den Daten. Vorgehen:

  • Statische Header oder Footer können in den Margin-Bändern untergebracht werden

  • Diese werden immer angezeigt

Dynamische Designs

Das dynamische Design muss in den folgenden Situationen angewendet werden:

  • den Kopf der ersten Seite im Vergleich zu den folgenden Seiten anders zu gestalten

  • den Header resp. Footer aufgrund der Daten gestalten (also z.B. Bilder aus der DB)

  • den Abschluss des Reports zu verändern

Vorgehen:

  • Benutzung von Report-Bändern (Header/Footer) zusammen mit Page-Bändern (Header/Footer). Alle Margins werden auf 0 gesetzt.

    • Steuerung der Dynamik mit Hilfe der DevExpress Funktionen, z.B. des Page Headers:

  • Wiederverwendung mittels Sub-Reports

Sub-Reports

Wiederholende Designs von Margins, Headern oder Footern können in Sub-Reports ausgelagert werden.

  • Fix designte, statische Elemente die nicht aus den Daten ermittelt werden -> mit normalen Sub-Reports

  • Informationen die aus :1 oder :n Relationen stammen und wiederholt angedruckt werden → mit effizienteren QuinoSubReport

Umsetzung Kopf-/Fusszeilen

Basierend auf der Entscheidung oben statischen und dynamischen Designs oben.

  • Nach den oben verlinkten Empfehlungen als Sub-Reports aufgebaut

  • Jeweils für Kopf und Fuss, Hoch- oder Querformat und dynamischer Ausrichtung wird ein Sub-Report im Standard hinterlegt. Daraus resultieren 8 Sub-Reports, die als Datenquelle den Geschäftsbereich hinterlegt haben.

  • Design der Kopf-Fusszeilen wird innerhalb des Reports erstellt.

Integration in Reports

Die Sub-Reports müssen in den Report jeweils eingebunden werden. Die Steuerung der Dynamik erfolgt mit den Eigenschaften der Bänder.

Empfehlungen

  • Die Sub-Reports füllen jeweils das komplette Band (Gleiche Höhe und Breite) aus. So können unbeabsichtigte Margins vermieden werden.

  • Die Höhe der Bänder sollten möglichst klein gewählt werden. Der Sub-Report drückt die Höhe des Bands auf die eigene Höhe auf.

  • Das Design des Sub-Reports beinhaltet die Margins

Kopfzeile und Fusszeile immer gleich:

  • Page-Header/Footer Beibehalten

  • Alle Elemente aus Report-Header/Footern in den jeweiligen Sub-Reports löschen

Scripting

  • Es steht in der Web-Umgebung aus Sicherheitsgründen kein Scripting zur Verfügung

 

Related content