[GELÖST] Report:PrintOnFirstPage=FALSE reduziert Seite1 body

[Dominik Meyer]

Hallo Mitglieder der MSDynamics.de Community,

freue mich als neues Mitglied eine Frage zum Reporting stellen zu dürfen.

Mein Problem: Ich erhalte einen unerwünschten Seitenumbruch auf Seite 1, wenn für die Kopfzeile PrintOnFirstPage = False eingestellt ist.

Der Effekt tritt auf, wenn der Report aus mehr als einer Seite besteht und äußert sich wie folgt: Der druckbare Bereich der Seite 1 wird im unteren Bereich um die Höhe der Kopfzeile reduziert.
Man(n) könnte auch sagen, dass ein Seitenumbruch zu früh erfolgt.

Hintergrund ist, dass ein Kunde auf Seite 1 einen anderen Kopf (der von mir im oberen body-Bereich, wie von MS empfohlen, angelegt ist) als auf den Folgeseiten benötigt.

Bsp: Beträgt die Höhe der Kopfzeile 7 cm, so erfolgt auf Seite 1 der Seitenumbruch 7 cm zu früh.

Der Effekt ist reproduzierbar, z. B. in dem Report 206, wenn PrintOnFirstPage auf False gestellt wird und der Report aus mind. 2 Seiten besteht.

In meinem Fall handelt es sich um Report 5911 (Service - Invoice), welcher individuell unter einer anderen ID für den Kunden entwickelt wird.

Wer von Euch hat dieses Problem schon erfolgreich gelöst bzw. kann Lösungsansätze vorschlagen?

Vielen Dank vorab. Freue mich auf eine konstruktive Zusammenarbeit in diesem Forum.

Gruß
Dominik

Zuletzt geändert von Dominik Meyer am 2. April 2013 08:29, insgesamt 1-mal geändert.

Willkommen bei uns!

Reporting ist ein sensibles Thema, und die Terminologie führt allzuschnell zu Missverständnissen
Es wäre daher sehr hilfreich, wenn du noch Screenshots deinem Beitrag anfügen würdest, damit ich sehen kann
a) was für dich die Kopfzeile ist
b) was sich wie verschiebt.

Danke!

Hallo Natalie,

oh ja, Du hast recht! RTC-Reporting ist eine Herausforderung. Wie ehemals der Übergang von der Schreibmaschine zum Computer. Wenn man es kann, möchte man nicht mehr ohne

Auf den Abbildungen ist ersichtlich, dass der Kopf der Seite 2 (ich meine den von Microsoft benannten Page Header) genau auf Seite 1 unten in den Body passt. Vergrößert man den Page Header vergrößert sich auch der leere untere Bereich auf Seite 1.
Setze ich die Eigenschaft PrintOnFirstPage auf True wird der Page Header (korrekterweise) über den Report Header angezeigt (so nennt MS den Bereich im Anfang des Bodys (Textkörper) und kein Leerraum unten im Body auf Seite 1 erscheint.
Die Farbe Pink habe ich als Hintergundfarbe für die List bzw. das Rechteck vergeben, welches vollständig standardmäßig die Tabelle platzmäßig ausfüllt, die wider rum vollständig den Textkörper ausfüllt.

Kopfzeile Layout.jpg

Druckansicht.pdf

Hoffe ein wenig Licht ins Dunkle begracht zu haben. Benötigst Du weitere Angaben?

Gruß
Dominik

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hoffe ein wenig Licht ins Dunkle begracht zu haben. Benötigst Du weitere Angaben?

Ich habe wirklich länger gebraucht, weil du so viele Farben gebrauchst (super), ohne sie zu benennen (schade).

Ich verstehe dich so: Dadurch, dass du PrintOnFirstPage = False setzt, rückt (nur) auf Seite 1 der gesamte Bereich (rosa) nach oben, lässt dafür über der Fußzeile eine rosa Lücke in der Größe des ausgeblendeten Headers.
Das hätte ich sofort verstanden

Das "schockt" mich aber aus einem anderen Grund.
Ich erwarte, dass wenn die Kopfzeile ausgeblendet wird, der Platz für sie oben aber trotzdem reserviert wird. Du hättest dann oben eine graue Lücke gehabt.
Dass der Lücke weiter unten nachholt, ist mir völlig neu und leider kann ich dazu nichts gescheites sagen

ABER dafür sage ich dir, wie du das Problem umgehen kannst:
Setze PrintOnFirstPage wieder True.
Die ersten Zeilen der Fußzeile und des Textkörpers sind doch eigentlich identisch. Einzige Unterschiede: Wenn Seite = 1, drucke oben die Seitenzahl, sonst drucke [kann ich nicht erkennen, ich meine die zwei breiten Felder, links rosa, rechts weiß).

Darum: entferne aus dem Textkörper die Wiederholungen (und rücke den Rest nach oben auf). Die zwei Felder, mit deinen ich nichts anfangen kann, packe in die Kopfzeile.

Jetzt wollen wir noch dafür sorgen, dass die drei Felder oben links in der Kopfzeile nicht auf der ersten Seite angedruckt werden:
Packe sie in ein neues Rechteck und setze für dieses einen Hiddenausdruck: Hidden = (aktuelle Seite = 1).

Die zwei mir unbekannten Felder packe in eine neues Rechteck, dass du über dem bestehenden platzierst. Dieses erhält den Hiddenausdruck Hidden = (aktuelle Seite > 1).

Ich habe wirklich länger gebraucht, weil du so viele Farben gebrauchst (super),

Ich habe mittlerweile in meinem Job gelernt, geduldig zu sein

ABER dafür sage ich dir, wie du das Problem umgehen kannst:
Setze PrintOnFirstPage wieder True.
Die ersten Zeilen der Fußzeile und des Textkörpers sind doch eigentlich identisch.

Eigentlich , Dein Lösungsvorschlag ist super, ABER --> gemäß Kundenvorgabe sind die Angaben zwingend sehr unterschiedlich anzugeben. Somit bleibt die Hürde bestehen, die überwunden werden muss.
Mein Chef hat parallel bereits gestern in aller Früh eine Supportanfrage (Prio B, 4 - 8 Std.) an MS gestellt. Bis aktuell ist keine Antwort erfolgt!!!

Hoffe sehr, dass hier im Forum eine Lösung gefunden wird. Das wäre letztendlich der Beweis, dass msdynamics.de besser als der Support von MS ist .

Anmerkung: Sollte dies ein MS-Mitarbeiter lesen: Treten Sie den Gegenbeweis an .

Grundsätzlich ist mein Chef auch bereit kostenpflichtige Dienstleistung in Anspruch zu nehmen. Nur - wer kann die Anforderung umsetzen *Rätsel*.

Gruß, Dominik

Hallo,

da hast du dich aber an etwas heran gewagt. Ich bastle gerade an den gleichen Problem.

Ich hatte dabei im wesentlichen zwei Probleme:
1. Die Seitenzahl bzw. ein Übertrag wird in einem Groupheader nicht aktualisiert, weil ein GroupHeader einmal am Anfang gerendert wird, und danach nicht wieder.
2. Die Höhe der Headerzeile ist fix. D.h. du hast nicht die Möglichkeit zwei Typen von Headern zu definieren, und die untereinander zu platzieren und dann mit den Properties aus und ein zu schalten (das funktioniert ebenso nicht, wenn man mehrere Belege am Stück druckt)

Für den zweiten Punkt ist mir die Lösung eingefallen, den Header der ersten Seite aufzuteilen, damit die Headerzeile maximal auf die Höhe der Kopfzeile der zweiten Seite kommt. Dann kann man zwei Rechtecke übereinander in den Header legen, die jeweils die Felder für die erste Seite bzw. für die zweite Seite enthalten. Die wiederum kann man dann einfach ein bzw. ausschalten mit einer eigenen Visible- Funktion, die das ganze abhängig von der ersten Dokumentseite umschaltet.
Den Rest des erste Seite Headers packst du dann als Zeile über dein Dokument.

Gruß, fiddi

Eigentlich , Dein Lösungsvorschlag ist super, ABER --> gemäß Kundenvorgabe sind die Angaben zwingend sehr unterschiedlich anzugeben.

Verstehe ich nicht. Entweder hast du mich missverstanden (das Ergebnis ist nach meinem Vorschlag genau so, wie von dir beabsichtigt!), oder ich unterschätze die "Befehlsgewalt" eures Kunden.

Für den zweiten Punkt ist mir die Lösung eingefallen, den Header der ersten Seite aufzuteilen, damit die Headerzeile maximal auf die Höhe der Kopfzeile der zweiten Seite kommt. Dann kann man zwei Rechtecke übereinander in den Header legen, die jeweils die Felder für die erste Seite bzw. für die zweite Seite enthalten. Die wiederum kann man dann einfach ein bzw. ausschalten mit einer eigenen Visible- Funktion, die das ganze abhängig von der ersten Dokumentseite umschaltet.

Genau das habe ich doch vorgeschlagen??

[quote"Natalie"]Genau das habe ich doch vorgeschlagen??[/quote]

Du hast recht . Ich musste es aber auch erst drei mal lesen um es zu verstehen. Es ist aber auch sehr schwierig so etwas mit Text zu beschreiben. Leider hat der Report dann noch die Macke, dass er nicht nahtlos Header und Datenteil anschließt (es bleibt entweder eine Lücke zwischen Header Daten oder das ganze wird ineinander gedruckt)

Gruß, Fiddi

Es ist aber auch sehr schwierig so etwas mit Text zu beschreiben.

Allerdings ... Wenn die Dinger nicht so komplex wären

Erst einmal vielen Dank für Eure Antworten und ein frohes, neues - vor allem aber gesundes - Jahr 2013.

Ich habe das beschriebene Problem an Microsoft übergeben, da ich bisher keine Lösung herausbekommen habe.

Seitens MS wurde mir die Nachvollziehbarkeit des Verhaltens bestätigt - ebenso, dass das Verhalten vermutlich im Standardbeleg nicht korrekt ist.

Ein fast identisches Problem existierte bereits in NAV 2009 (laut Aussage des MS-Supports) und wurde durch einen Hotfix behoben. Wer in NAV 2009 nicht mit dem Problem konfrontiert wurde, hatte bisher einfach Glück gehabt .

Die Anfrage wird vom MS-Eskalationssupport bearbeitet und ich erhalte eine wöchentliche Statusmeldung. Sobald ich eine Lösung erhalten habe, werde ich diese hier im Forum bekannt machen.

Vielen Dank für Eure Unterstützung.

Hallo,

der aktuelle Stand ist, dass mittlerweile das Reporting Services Team sich mit dem Fall beschäftigt.

Der gemeldete Fehler wurde mir aktuell bestätigt: After checking with the Reporting Services team, this seems to be a known issue. Please let me know if it would be ok to use PrintOnFirstPage = True in your report or if on the contrary this is necessary in which case I would escalate the case to the next level.

Sobald es Neuigkeiten gibt, informiere ich wieder.

Der Fall ist "erst einmal" abgeschlossen.

Auszug aus der letzten Info, die ich von MS erhalten habe:

...and can only hope that they will fix this in the future but this is a decision that will be made by SQL Server product managers. I will close the case as non-chargeable and with status of “no solution”.