Jump to content

Das kleine 1 x 1 bei der Berichtserstellung


Go to solution Solved by Kai Hildebrandt,

Recommended Posts

  • Solution

Bei der Berichtserstellung ist für einen Creator einiges zu beachten. 
Um leere Seiten im Bericht zu vermeiden oder das Verhalten des Berichts besser zu kontrollieren, können wir uns an folgenden kleinen Punkten orientieren, die die Fehler in Berichten stark minimieren. 

1. Der Bericht wird idealerweise erst am Ende der smap-Erstellung bearbeitet

Warum? Durch die Änderung der Berichtsvorlage verlieren wir den Vorteil das Verhalten der Bausteine über das Eigenschaftenpanel in Bezug auf den Bericht zu ändern. 

Beispiel: 

image.png.a08faba5d89413179db59599377da3e2.png    VS    image.png.a6a9ce731ef6417028612fb9328f8e45.png

Angenommen, wir tauschen die Berichtsvorlage nach dem ersten gesetzten Baustein, dann verlieren wir direkt die Möglichkeit, die Darstellung des Bausteins im Bericht zu ändern. Nun müssten wir das händisch selbst durchführen und das birgt einfach ein Fehlerpotential.

 

2. Wir nutzen den Berichtsupload, um unseren angepassten Bericht auf Fehler zu überprüfen

Durch die Upload Möglichkeit können wir unseren angepassten Bericht auf Fehler prüfen lassen,

wie das zum Beispiel hier mit den schwarzen oder roten Ausrufezeichen zu sehen ist:

image.png.09d1870b01ec9420a697517c2b54c4a8.png

Oder auch:

image.png.acc380ed7e99d51270c4204b057f5584.png

 

Idealerweise laden wir den Bericht nach jeder! geänderten Seite hoch und lassen diese vom System überprüfen. 

Denn gibt es einen Fehler, dann kann der Fehler nur auf der zuletzt bearbeiteten Seite zu finden sein. Das hilft ungemein, den Fehler massiv einzugrenzen. 

 

3. Wir haben im Bericht exakt genau so viele IF Bedingungen wie ENDIF Bedingungen platziert. Ist das nicht der Fall, dann laufen wir Gefahr keine korrekte Anzeige im Berichtsrückläufer zu haben.MIt STRG + F öffnen wir in Word ein Suchfeld und können nach {%IF und {%END suchen um diese gegenüberzustellen. 

image.png.0ca1b68068bceefefd14bf9a6f335431.png  -> image.png.4a9e242b0e6a3881a0a0e7eb81a2fc03.png

 

Wenn wir diese Aspekte bei der Berichtserstellung beachten, dann minimieren wir die Fehleranfälligkeiten enorm und können den Bericht schneller in Umlauf geben. 

Viele Grüße 

Kai

Edited by Kai Hildebrandt
  • Like 9
  • Thanks 3
Link to comment
Share on other sites

Richtig gut, @Kai Hildebrandt, danke!

Was mir auch immer ganz gut hilft beim Bauen von Berichtstemplates ist das manuelle Einfärben gleicher IF-ENDIF-Bausteine, so dass man sie optisch besser zuordnen kann.

image.thumb.png.1c35b95dbd88b2377561ed7ac6df2c20.png

Da diese Steuerkommandos im fertigen Dokument (Word oder PDF) sowieso wieder entfernt werden, kann man sich hier im Grunde beliebig austoben.

Zu beachten ist aber: man muss schon genau darauf achten, welche Anweisungen auch wirklich zusammengehören. Wenn man erstmal farbig falsch zugeordnet hat, kann das eine etwaige Fehlersuche sogar verschlimmern. Deshalb: "Holzauge, sei wachsam!" 😉 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Sinn der %IF/%ENDIF Funktion ist es, in einem Bericht Überschrift und Werte nicht einzublenden, wenn der Baustein nicht vom Nutzer befüllt wurde. Der Bericht verschiebt sich um den fehlende Inhalt nach oben. Der Bericht wird kürzer und kompakter. Bei einer Tabelle wird das Tabellenfeld immer angezeigt. Verwendest du in der Tabelle den %IF/%ENDIF Befehl, wäre im Falle einer Nichteingabe dieses komplett leer. Ggf. möchtest du aber, dass z.B. die Überschrift angedruckt wird, sodass man sieht, dass hier nichts eingegeben wurde. Also beides möglich - je nach Usecase.

  • Like 1
  • Thanks 3
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...