[Überlegung] »Master Layout Report« bauen

Hi,

ich hatte schon öfters die Idee, das Reportlayout der Standardbelege auszulagern um Mehrfachanpassungen und damit Arbeitszeit zu sparen. Nur wie? Möglichst mit Boardmitteln.

Dabei sollten die Standardbelege so wenig wie möglich umgebaut werden. Diese könnten in allen nötigen OnAfterGetRecord Triggern, die benötigten Reportdaten in temporäre Tabellen speichern. Diese temporären Tabellen sind dann Grundlage für den »Master Layout Report«.

2 Varianten sind mir eingefallen. Beiden besitzen Vor- u. Nachteile:

chrome_2017-07-06_11-14-21.png

Ich bevorzuge die 2. Variante. Bei dieser Variante enthält der »Master Layout Report« alle möglichen DataItem Tabellen (Sales Header, Service Header, ...). Wenn es nun noch die Möglichkeit gebe, die DataItem Filter in der Requestpage dynamisch anzuzeigen, dann wäre das super! So muss man die wichtigsten Filterfelder selbst in die Requestpage nehmen und diese per Programmierung ansteuern. Oder man hat halt alle DataItems in der RequestPage ODER man verzichtet gänzlich auf die Filter.

Ich habe das mal Probeweise mit dem Angebot probiert und habe dabei lediglich ein TRANSFERFIELDS in eine temporäre Kopie der Tabellen 36 u. 37 gemacht. Diese Tabellen müssten dann natürlich noch um alle anderen im Report verwendeten Daten erweitert werden. Zudem kommen noch Dimensionen, Mwst. Tabelle, usw. hinzu.

Es gibt auch andere Nachteile, welche ggf. weitere Anassungen benötigen. (RequestOptions, Archivierung, PrinterSelection, ...)


Dies ist erstmal nur eine Idee und kann als Diskussionsgrundlage dienen. Vielleicht gibt es ja ähnliche Wünsche nach solch einem Feature.

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

Hallo,

ich bevorzuge die Standard- Reports nicht für das Reportdesign. Die sind in meinen Augen nicht gerade effizient, und für die meisten unserer Kunden nicht zu gebrauchen. Das Kopieren das Daten in temporäre Tabellen führt auch nicht gerade zu eine Performance- Gewinn.

Was allerdings bei den meisten Kunden der Fall ist, ist das Layout des Headers und des Footers auf allen Belegen identisch ist. Außerdem ist das Layout der ungebuchten Belege jeweils auch oft Identisch (Der einzige Unterschied ist oft nur der Belegname Auftrag, Angebot, Reklamatinsbestätigung,..)

Wenn man das annimmt, könnte man die ungebuchten Belege mit jeweils einem Report drucken. Das macht aus 8 Reports schon mal 2.
Wenn man dann die Aufbereitung eines Großteils der Daten an eine Codeunit auslagert, die per Recordref bedient wird, und alle Daten wie Z.B. Lables, Adressinformationen,... als Textvariable fürs RDLC bereitstellt, dann ist der Aufwand die ganzen Variablen in die Übergabeliste einzutragen auch nur einmal nötig.

Wenn man dann dann auch noch ein wenig geschickt mit Variablennamen arbeitet und einen "Sales Header" nicht SalesHeader sondern DocHeader nennt, schafft man es evtl., dass man Reports kopieren kann, und nur noch ganz wenig Anpassungen nötig sind, um aus einer Auftragsbestätigung eine Rechnung oder eine Bestellung zu machen.

Diese Arbeitsweise hat zwar den Nachteil, das man bei jedem MS- Update prüfen muss, ob die da was geändert haben, aber das sollte eigentlich großes Problem sein.

Gruß Fiddi

Hallo fiddi,

Es müssen nicht unbedingt die Standardreports sein, das stimmt. Das war vielleicht etwas schlecht ausgedrückt. Die Basis können natürlich auch schon bereits angepasste Reports sein. Das Dataset der Standardreports muss man ja sowieso optimieren, was dann aber nur 1x im Master Layout Report nötig wäre. Die "Basisreports" können danach auf ProcessingOnly gestellt werden.

Man könnte auch alles in Codeunits auslagern, daran habe ich auch gedacht. Da die Berechnungen allerdings schon im Report enthalten sind, würde ich diese dort belassen. Lediglich alle zu verwendenden Daten und Variablen in eine extra dafür vorgesehene Tabelle schieben, welche möglichst mit vielen "Standardbelegen" kompatibel ist. Das am besten in eine Funktion am Ende der entsprechenden Trigger. Damit bleibt es auch übersichtlich und lässt sich besser mit neueren MS Reports vergleichen.

Es wäre halt super wenn MS bei zukünftigen Versionen gleich an so etwas denkt. Wir haben mehrere Kunden, welche im Prinzip die gleiche Reportbasis haben. Wenn aufgrund von winzigen Änderungen/Wünschen Anpassungen am Layout nötig werden, müsste man halt deutlich weniger Objekte anfassen. Im besten Fall nur nur eins. Wieviele Objekte muss ich aktuell anfassen? Angebot, Auftrag, Rechnung, Lieferschein, Gutschrift, ... und das für Verkauf, Service und ein paar im Einkauf. Hinzu kommen noch Reports aus Erweiterungen... und das für jeden Partner *puh

Zum Master-Layout nochmal:

Kannst du mir erklären, wie du Lieferscheine, Packscheine, Angebote, Rechnungen,.. usw. mit einem Layout drucken willst? Ich glaube nicht, dass das möglich ist.

Selbst mit dem Header wird es problematisch, wenn du mit unterschiedlicher erster und Folgeseite und evtl. Überträgen da wo sie hin gehören arbeiten möchtest.

Gruß Fiddi

P.S.: SilverX hat mir mal erzählt, er hätte schon mal so einen ähnlichen Ansatz mit nur einem Report gehabt. Das wäre ja auch nicht ganz unmöglich. (ich vermute jetzt mal, dass er es so oder ähnlich gemacht hat)

Der Report läuft über die Integer- Tabelle, der eigentliche Master- Record wird per Funktion in den Bericht eingetragen, und die Daten werden dann aus den gesetzten Records in Report- lokale Variablen kopiert, und ans RDLC übergeben. Fertig ist der Report für alles, wie du ihn wolltest. Hat allerdings den Haken, das es eben doch nicht das einmal- Layout gibt. Das könnte man dann evtl. in ein HTML- Template für das Tabellenlayout basteln, den man dann im RLDC in einem Textfeld ausgibt, das die komplette Seitenbreite ausfüllt.

Gruß Fiddi

P.S.: SilverX hat mir mal erzählt, er hätte schon mal so einen ähnlichen Ansatz mit nur einem Report gehabt. Das wäre ja auch nicht ganz unmöglich. (ich vermute jetzt mal, dass er es so oder ähnlich gemacht hat)

Also wir nutzen verschiedene. Aber vllt. habe ich mal von einem Partner erzählt, der nur einen "Master-Report" nutzt, was aber durch die Komplexität dann andere Probleme aufwirft.

Unsere Lösung nutzt für alle Belege eigene Berichte, die aber auf einem Vorlagen-Bericht basieren. Klassisch werden alle spezifischen Bereiche vom Namen her generalisiert, also anstatt SalesHeader beispielsweise nur Header. Das verringert den Aufwand.

Weiterhin geschieht die Aufbereitung größtenteils (leider noch nicht so viel wie ich gerne möchte) in einer Codeunit.


Beispielsweise sieht unser Header-Bereich fast durchgängig so aus:

Code:

LineSection := 'Header';
SetSwitches(FALSE, Header);

CurrReport.LANGUAGE := DocRepHelper.Initialize("Language Code", LanguageName, FALSE);
DocRepHelper.AddSwitchesToReportDictionary(Switches);
DocRepHelper.GeneralInfoToReportDictionary();
DocRepHelper.GetAdditionalSettings(DocRepHelper.GetReportID(CurrReport.OBJECTID(FALSE)), Header, DocRepAddSettings);

DocRepHelper.GetCompanyInfo(CompanyInfo, Header);
DocRepHelper.AgentToReportDictionary(Header);
DocRepHelper.DocumentHeaderToReportDictionary(Header);
DocRepHelper.DocumentFooterToReportDictionary(DocRepHelper.GetReportID(CurrReport.OBJECTID(FALSE)), Header);

DocRepHelper.FormatAddressSales(Header, ShowShipToAddress, ShowSellToAddress);
Cust.GET("Sell-to Customer No.");
DocRepHelper.PartnerToReportDictionary(Cust);

IF DocRepHelper.IsSwitchSet(Switches, DocRepHelper.SwitchPrintInternalInformation()) THEN BEGIN
  HeaderDimensionText := DocRepHelper.GetDimensionText("Dimension Set ID");
END;

IF DocRepHelper.IsSwitchSet(Switches, DocRepHelper.SwitchPrintAdditionalFeeNote()) THEN BEGIN
  DocRepHelper.GetLineFeeNote(Header, TempLineFeeNoteOnReportHist);
END;

DocRepHelper.CollectBankAccounts(Header, TempBankAccount);

DocRepHelper.LogInteraction(LogInteraction AND (NOT CurrReport.PREVIEW),
    Header, "No.", 0, 0, "Bill-to Customer No.", "Bill-to Contact No.",
    "Salesperson Code", "Campaign No.", "Posting Description", '');

Switches ist eine Bitmaske von "Features", die generell und pro Partner konfiguriert werden können. Ob Barcodes für Belegnr., Externe Belegnr., Seriennummern usw. gedruckt werden sollen uns ähnliches.

Die Codeunit sammelt für die verschiedenen Fälle (mit generalisierten Namen) die Daten, bereitet ggf. das Format auf und speichert diese in einem Dictionary, auf das wir per "DocRepHelper.GDE('CompanyAddr1')" zugreifen können.
Einer der Vorteile des Dictionaries ist, dass man dieses mit Dictionary.Clear() löschen kann und damit die ganzen Header-Felder nur einmalig im DataSet auftauchen und mit einer Zeile alle gelöscht werden können. Damit ist unser DataSet durchgängig schlank, mit Ausnahme von Bildern (Barcodes).

Falls Barcodes zu Anwendung kommen, bei uns durchaus mal tausende in einem Bericht, kann man diese wirklich sehr schön direkt im RDLC per eingebundener DLL erzeugen. Allerdings tritt dann ein Speicherleck auf (es reicht eigentlich sogar "EnableExternalAssemblies" zu aktivieren um das Problem zu haben), welches so immens viel Speicher frisst, dass man das tunlichst nicht machen sollte, sondern klassisch Blobs im DataSet übertragen. Dafür haben wir auch extra die Bilddaten auf ein absolutes Minimum (Graustufen) reduiziert, damit diese Mega-Belege kein Problem sind.

Hallo

das mit dem Masterreport sehe ich ähnlich, es wir sehr schwer die unterschiedlichen Belegarten in einem Report zu koordinieren.

Das andere mache ich genauso, allerdings mit NAV- Bordmitteln (Textvariablen mit (fast) unbegrenzter Länge sei Dank).

Die Vorgehensweise ist dann beim Kunden so, das man einen "Master- Report" erstellt (oder man nimmt seinen eigenen Master- Report), das Layout von Kopf und Fuss mit dem Kunden abstimmt, und dann wird dieser Bericht in alle weiteren kopiert und dann mit dem spezifischen Leben gefüllt.

Gruß Fiddi

Das sind auch schöne Varianten. So kann man große Teile des Layouts gleich wiederverwenden.

Ich werde mir etwas für die nächste Reportanpassung überlegen. Das generalisieren der Variablen wird wohl auch dazu gehören.
Um das Dataset zu verkleinern, verwende ich die Methode, die Variablen über ein Integer Dataitem zu übergeben, welches nur 1x durchlaufen wird.

So wie hier z.B.

finsql_2017-07-19_16-32-38.png

Microsoft.Dynamics.Nav.Client_2017-07-19_16-45-42.png

Microsoft.Dynamics.Nav.Client_2017-07-19_16-54-13.png

Wichtig ist, dass man die Variablen, welche ggf. zur Sortierung/Filterung nötig sind, nicht in das Integer Dataitem schiebt.

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

Zuletzt geändert von Raik Zobel am 19. Juli 2017 16:56, insgesamt 3-mal geändert.

Um das Dataset zu verkleinern, verwende ich die Methode, die Variablen über ein Integer Dataitem zu übergeben, welches nur 1x durchlaufen wird.

Das ist nach meiner Meinung nicht notwendig, da wenn richtig designt, die Belege eh nur noch einen Datensatz haben.
Außerdem solltest du dir die XML- Datei aus der Vorschau anschauen, das ist das was an den Reportgenerator übergeben wird, nicht dass was du in der Tabelle siehst.

Aus meiner Sicht ist es wesentlich wichtiger die Anzahl der vom Reportgenerator zu bearbeitenden Datensätze zu reduzieren, das bringt mehr als ein Integer Daten- Item. Ich würde eher versuchen dieses Integer- Dataitem als ein Feld im übergeordneten Record zu übergeben.

Gruß Fiddi

Ich würde eher versuchen dieses Integer- Dataitem als ein Feld im übergeordneten Record zu übergeben.

Gruß Fiddi

Wenn aber nach einem Dataitem noch eingerückte Dataitems folgen, so befinden sich dort auch wieder alle Daten aus dem übergeordneten Dataitem. Außer man packt diese in ein Integer Dataitem. Das sieht man auch in der XML. Ansonsten habe ich das nicht richtig verstanden. Hast du vielleicht ein Bild?

Wenn aber nach einem Dataitem noch eingerückte Dataitems folgen, so befinden sich dort auch wieder alle Daten aus dem übergeordneten Dataitem.

Verwendest du ein separates DataItem (nicht eingerückt), dann bleiben zwar die meisten anderen Felder leer, dafür aber erzeugst du eine zusätzliche Zeile, die durchlaufen werden muss.
Keine Ahnung, welche Lösung performanter ist?
Meine Persönliche Erfahrung ist: sehr viele Zeilen tun nicht weh, wenn man die Anzahl an Spalten klein genug hält.

Verwendest du ein separates DataItem (nicht eingerückt), dann bleiben zwar die meisten anderen Felder leer, dafür aber erzeugst du eine zusätzliche Zeile, die durchlaufen werden muss.

Ich habe mal die Bilder aus meinem vorhergehenden Beitrag aktualisiert. Habe auch bei eingerücktem Dataitem eine leere Zeile (gelb). Diese muss ich dann mit einem Filter bei der Ausgabe der eigentlichen Datensätze herausfiltern (Also alles was dann in der Spalte »Kostenstelle« nicht "<>" ist.)

Edit: Ein Bild habe ich nun nochmal aktualisiert.
Edit2: Bild der Reportausgabe hinzugefügt.

Hallo,

mal davon abgesehen, das die die Reportstruktur für schwer verständlich halte, glaube ich auch nicht, das es was bringt. Vergleiche doch mal die Größe der XML einer normalen Struktur mit deiner.

Wichtig ist, wie Natalie schon sagte, die Tabelle/Recordstruktur mit vielen Datensätzen, möglichst wenig Felder enthält.

Gruß Fiddi

mal davon abgesehen, das die die Reportstruktur für schwer verständlich halte,

Dazu muss man wissen, dass bei dem Kunden zu jedem Debitoren neben einem Verkäufer (IDM bzw. TEL) auch ein Vertreter (ADM) existiert. Der Bericht listet also die Debitorenumsätze nach Kostenstellen auf. In dem Fall erst sortiert nach Vertretern, dann nach Verkäufern und letztendlich alle Kostenstellen, die bei der Kombination in den Debitorposten auftauchen. Das gleich ist mit dem selben Bericht auch andersherum möglich und zusätzlich auch mit Auflistung der Debitoren möglich. Das ist schon sehr komplex, ja. Vor allem um das Dataset klein zu halten, wenn die Debitorenauflistung per Requestpage nicht gemacht werden soll. War aber Kundenwunsch.

Aber eigentlich wollte ich nur das Integer Dataitem erklären.
... und selbst das ist schon am eigentlichen Thema vorbei.

Was den Master Report betrifft, werde ich wohl doch von dem Thema, einen zusätzlichen Layoutreport zu verwenden, abrücken und lieber eure Tipps beherzigen und das layout so gestalten, dass man es zum großen Teil kopieren kann.
Ursprünglich gingen meine Vorstellungen soweit, dass man eben nicht nur die Variablennamen bereinigt (z.B. HeaderInfo1Caption, HeaderInfo1Text, LineColumn1Value, LineColumn2Value, ... ), sondern dazu auch nur einen Layoutreport hat. Es würde gehen, aber die Nachteile kann ich gerade nicht alle einschätzen.

Dazu muss man wissen, dass bei dem Kunden zu jedem Debitoren neben einem Verkäufer (IDM bzw. TEL) auch ein Vertreter (ADM) existiert.

Ich habe mir schon gedacht, dass es so etwas sein sollte. Aber warum nennst du die Records dann nicht Representative und Salesperson. Das liest sich im Reportdesign wesentlich besser, und jeder weiß was mit den Feldinhalten im RDLC gemeint ist.
Das mit der Generalisierung der Namen sollte jetzt nicht soweit getrieben werden, dass die Angaben kryptisch werden. Es sollte schon aus dem Zusammenhang erkennbar sein was da angezeigt wird.

dass man es zum großen Teil kopieren kann

Wenn du Layoutelemente kopieren möchtest, daran denken, in deren Expresions ein ' (Basic- Komentarzeichen) an die Expression dran zu hängen, sonst klappt das kopieren im Reportbuilder oder VS meistens nicht .

Gruß Fiddi

Hallo,

ich habe mal versucht HTML einzubinden, doch die verfügbaren HTML Befehle fallen sehr dürftig aus. Das sind so wenige, dass es sich kaum lohnt das zu benutzen. Allerhöchsten, wenn man in einem Feld unterschiedliche Textformatierungen haben möchte. Eine Tabelle hätte ich gerne gemacht.

ich habe mal versucht HTML einzubinden, doch die verfügbaren HTML Befehle fallen sehr dürftig aus. Das sind so wenige, dass es sich kaum lohnt das zu benutzen. Allerhöchsten, wenn man in einem Feld unterschiedliche Textformatierungen haben möchte. Eine Tabelle hätte ich gerne gemacht.

ich entwickle derzeit alle Dokumenten-Reports von uns mit HTML Boxen und hol mir die Texte dazu aus ner Tabelle.
Allerdings hat das eher den Hintergrund das bei uns jeder Report in 8 Sprachen geführt wird und gefühlt alle 2 Wochen der irgendwelche Änderungen vorgenommen werden sollen.

Trotzdem möcht ich kurz nen Einblick geben:

report.png

layout.png

in den meisten Fällen reicht es für neue Dokumente einfach die Lines auszutauschen bzw anzupassen und im Layout die Detail Tabelle anzulegen.
Durch den HTML Part kann ich innerhalb von ner Minute den kompletten Text in dem Report austauschen.

mapping.png

Ermöglicht dann auch Platzhalter.

Was allerdings nicht geht, was ich sehr schade finde, das man Bilder im HTML Text einbinden kann.

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

Hallo,

was gibt es für einen Grund die Adresszeilen immer noch einzeln zu übergeben, statt in einem String, und dann mit den Kopfdaten?

Gruß Fiddi

Vielen Dank Ted, genauso stelle ich mir das vor und so wollte ich es umsetzen.

Ich vermute das Feld rechts neben der Adresse enthält Beleginformationen. Bisher haben wir da eine schöne Tabelle und ich wollte es genau so machen. Stehe jetzt aber vor dem Problem, dass ich lieber eine HTML Tabelle an der Stelle gebaut hätte. Ich habe auch versucht mit DIVs eine Tabelle zu bauen. Das klappt aber auch aufgrund der starken Einschränkungen nicht!

Warum möchte ich eine Tabelle?
1. Weil ich einen festen Abstand zwischen Caption (1.Spalte) und Wert (2. Spalte) haben möchte.
2. Weil es passieren kann, dass der Wert aufgrund seiner Länge umbricht.

Jetzt könnte ich natürlich auch schon 2 Spalten in RDLC Layout anlegen, habe aber dann das Problem, dass die 1 Spalte ja nicht weiß das evtl. in der 2 Spalte ein Wert aufgrund seiner Länge umbricht. Außerdem würde ich dazu nicht wirklich HTML benötigen.

Das gleiche bei den Zeilen. Wenn man HTML Tabellen verwenden könnte, dann könnte man auch den Zeilenbereich bei jedem Report gleich halten und steuert dann einfach per HTML den Inhalt und die Anzahl der Spalten.

Eine mögliche Alternative wäre noch die Umwandlung von HTML zu einem Bild per DotNet Automation. Leider habe ich noch keine funktionierende gefunden. Wobei ich hier auch nicht weiß ob das überhaupt Sinn machen, am Ende hat man wieder Arbeitsspeicherprobleme.

Hallo,

meinst du nicht, das du da ein ziemliches Rad drehen musst, bis du das was der RDLC- Report kann in HTML fehlerfrei nachgebildet hast (Cellmerge,Zellenbreite, keeptogether,...)?

wäre es da nicht einfacher ein Tool wie den http://simplanova.com/simplanova-report-designer/ fernzusteuern?

Gruß Fiddi

Naja,

so eine HTML Tabelle ist doch fix gemacht. Das bisschen css für Breite, Rahmen, Abstände und Co doch auch. Der Rest bleibt im RDLC. Hätte mir dazu die originale RDLC-Tabelle genommen und von dieser nur eine Spalte übrig gelassen, diese Spalte würden dann für jede Zeile eine HTML Tabelle darstellen. Zumindest war das mein Gedanke.

Hm, selbst wenn du es irgendwie hinbekommen solltest, hast du spätestens wenn du inhaltsbedingte Tabellenköpfe hast, ein problem. Also "Zeige die Rabatt spalte nur an wenn auch Rabatt vorhanden ist".
Das stört mich derzeit auch total an den Word Reports, aber vielleicht stell ich mich damit nur zu blöd an.

@Fidi:
Momentan seh ich einfach noch nicht wirklich den Vorteil bzw Sinn darin die Adressdaten in einer Spalte zu übergeben... Klar das Dataset wird ein wenig kleiner, aber dafür muss ich den RDLC mit Logik versehen.

Hallo,

das sieht auf den ersten Blick einfach aus, wenn du nur 0815- Zeilen hast, ist das kein Problem, möchtest du aber einen Belegzeilentext haben,der etwas breiter ist als die normale Beschreibung, oder zusätzliche Tabellen in der Tabelle, dann gibt es da schon etwas mehr zu stricken.

Wenn dann der Beleg etwa so aussieht, musst du schon einiges programmieren:

Beleg.png

Schließlich ist es doch so, dass sich ein Basis- Beleg selten wirklich komplett ändert, da wird mal ein paar Millimeter hier verschoben und ein paar Millimeter da, aber das normale Layout bleibt wie es ist. Du machst einmal ein Design, das du eigentlich fast immer grundsätzlich übernehmen kannst. Die nötigen Korrekturen sind im Designer schneller gemacht, als per Code.
Im Designer berücksichtigt er Abhängigkeiten meist automatisch, die musst du nicht per Programm anpassen. (Eine ganze Zeile oder Tabelle im Designer von Arial 9 auf Arial 10 zu setzen ist ein Witz)

Momentan seh ich einfach noch nicht wirklich den Vorteil bzw Sinn darin die Adressdaten in einer Spalte zu übergeben... Klar das Dataset wird ein wenig kleiner, aber dafür muss ich den RDLC mit Logik versehen.

Warum musst du im RDLC was verändern? du benötigst ein Textfeld, in das du die Adresse als eine Textvariable ausgibst.
Du musst im C/AL was tun, um die Adresse mit Zeilenumbrüchen aufzubereiten. Aber das machst du einmal in einer Codeunit, und kannst es in jedem Report nutzen, da das Adressarray immer gleich ist. Du sparst die dann die Übergabe jedes einzelnen Feldes ans RDLC und genauso das Layouten jedes einzelnen Adressfeldes.

Gruß Fiddi

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

Wenn man dann die Aufbereitung eines Großteils der Daten an eine Codeunit auslagert, die per Recordref bedient wird, und alle Daten wie Z.B. Lables, Adressinformationen,... als Textvariable fürs RDLC bereitstellt, dann ist der Aufwand die ganzen Variablen in die Übergabeliste einzutragen auch nur einmal nötig.

Genauso habe ich es mal umgesetzt. Ist ja schon eine Weile her. Ich zeig mal den grundsätzlichen Aufbau:

Report Design mit HTML Platzhaltern

ReportDesign.png

Dataset. Die Platzhalter bekommen ihre Daten per Funktionsaufruf in eine Codeunit und Übergabe des Records. Wenn man hier die ersten 3 Variablen im Report an allen Stellen, die Text beinhalten, nutzt. Dann kann man auf einen Schlag Schriftart, Schriftfarbe und Schriftgröße ändern.

Dataset.png

Verarbeitungscodeunit. Hier mal nur im OnRun Trigger zur besseren Übersicht "verlinkbar" die Funktionen gezeigt.

CU-OnRun.png

Man muss dazu sagen, dass die Codeunit auch ganz schön komplex werden kann. Man muss sich dafür eine sehr gute Struktur überlegen um nicht die Übersicht zu verlieren. Mir hilft es enorm, wie im obigen Bild, die Hauptfunktionen im OnRun Trigger auskommentiert aufzuzeigen. So kann man "Go to definition" nutzen und hangelt sich zügig an die gewünschte Stelle :D
Die gezeigten Funktionen splitten sich dann meist noch weiter in Sales, Purchase, einzelne Belge und natürlich Sonderwunsch. hier mal ein Ideeneinblick:

CU-TextAbove.png

Ja, hart programmierter Text.. Bitte ignorieren

CU-LineFuncs.png

Die Funktion SetTableRecord(s) stellt anhand der Variants die globalen RecordRefs zur Verfügung.

Für die Zeilenbeschreibung gibt es natürlich viele Sonderwünsche für die Belege, da dort auch oft viele Zusatzinformationen oder auch Barcodes mit erscheinen sollen. Barcodes klappen auch wunderbar per Schriftart und entsprechender Funktion: FormatHtmlFamilySize(GetBarcode128(Barcodeartikelnr),'Code-128','20pt'). Hierzu muss ich anmerken, dass es Probleme beim Barcode geben kann, wenn dieser Zeichen enthält, die eigentlich aufgrund der HTML Nutzung konvertiert werden müssen. Die FormatHtml Funktion wandelt solche Zeichen um (z.B. ">" wird zu "&gt") und nicht alle Scanner erkennen das. Ich mache es so: Wenn der fertige Barcode eins der Zeichen <,>,",& enthält, so verwerfe ich diesen und lass einen neuen Barcode, nur nach Code128B erstellen. Damit wird der Barcode dann ein wenig länger, aber die Zeichen werden nicht verwendet. Die Einbindung von Bildern über die Codeunit habe ich noch nicht ausprobiert. Vielleicht könnte man auch so den Barcode als Image einbinden.

lg

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

Hallo,

viel zu kompliziert

Die Report Parameter bekommen die Labels und manche wiederkehrende Daten (Verkäufer, Belegnr,...) gar nicht zu sehen. D.h. die werden als EINE (JSON-) Text- Variable in der Codeunit erstellt, und dann als EINE Variable an das RDLC übergeben.
Die dortigen Funktionen im Code pflücken die Text- Variable auseinander und speichern die Werte ein einer Hash- Tabelle, aus der du dir die Werte dann per Name wieder heraus holen und verwenden kannst. ( wobei ich mir das mit den JSON überlegen würde, um Speicherplatz zu sparen)

Gruß Fiddi

Die dortigen Funktionen im Code pflücken die Text- Variable auseinander und speichern die Werte ein einer Hash- Tabelle, aus der du dir die Werte dann per Name wieder heraus holen und verwenden kannst.

Hi,

bin mir nicht sicher, ob ich dir folgen kann. Also ja, die einzelnen Funktionen in der Codeunit geben einen HTML Formatierten String an das ReportDataSet. Für jede Funktion gibt es einen fest definierten Platzhalter im Report.

Schau mal ins erste Bild. Da sind über den Belegzeilen 7 HTML-Platzhaltervariablen die auf einen HTML Formatierten String "warten". Die Programmierung ist also nicht mehr im Report, sondern in der Codeunit. Wenn der Kunde jetzt in der rechten großen Box (Doc_Informations) noch zusätzliche Informationen haben möchte, dann ergänze ich diese neuen Informationen in der Codeunit Funktion GetDocInformations und mache das auf Wunsch auch mit wenig Arbeit gleich für alle Verkaufs/Einkaufsbelege. Dazu muss ich überhaupt nichts mehr am Report machen.

Falls man doch mal eine Designänderung machen möchte, weil die Platzhalter vielleicht verschoben werden sollen, dann kann man die Reports teilweise auch einfach komplett kopieren. Also einen umdesignen und dann dieses Layout für den Rest verwenden.

LG