[gelöst] Print Event

Guten Tag zusammen.

Eigentlich bin ich ja mit den Events ganz zufrieden, aber was mir immer wieder fehlt, ist ein "Print Event".
Hat jemand etwas gehört, ob es soetwas zukünftig geben wird?

Momentan frage ich das Action Event in den Pages ab, das ist mehr als "unsportlich"...

Zuletzt geändert von rallnus am 3. August 2017 10:20, insgesamt 1-mal geändert.

Du könntest als Workaround das Event OnAfterFindPrinter der Codeunit 1 nehmen.
(Die Funktion OnReportRun der Codeunit 1 gab es leider nur in den 2009er Versionen und funktioniert ab 2013 nicht mehr.)

Du könntest als Workaround das Event OnAfterFindPrinter der Codeunit 1 nehmen.

Das wird Ihm wahrscheinlich nichts nutzen, da er den Event aus dem aufrufenden Kontext benötigt.

Das ist übrigens ein generelles Problem der Events, dass man sie oft aus dem aufrufenden Kontext heraus benötigen würde, also quasi den OnBeforeBefore- bzw. OnAfterAfter- Event, der jeweils vor dem Insert, Modify, Delete aufgerufen wird, damit man z.B. noch Felder aus dem aufrufenden Kontext in die zu modifizierenden Tabellen einfügen kann, bzw. nach der Änderung (z.B. Einfügen) zusätzliche Tabellen pflegen kann, die Referenzen die geänderte Tabelle haben.

Gruß Fiddi

ja, genauso ist es. Ich muss wissen, was ich drucken möchte.
Dann gehe ich hin und suche mir einen alternativen Report zu dem Standard-Report und drucke die Alternative.

Dann gehe ich hin und suche mir einen alternativen Report zu dem Standard-Report und drucke die Alternative.

Hast du da spezielle Wünsche, dass man das mit der/den Berichtsauswahl(en) über Tabelle 77 usw. nicht lösen kann?

Gruß Fiddi

Gute Frage.
Ich versuche keine Änderungen an Standardtabellen vorzunehmen.
Anstelle der Standard-Reports haben wir eigene Reports.
Vor dem Drucken ersetze ich die Standard Report-ID durch die individuelle ID.
Nach dem Druck wird wieder die Standard-ID eingetragen.

Hallo,

also können es immer andere individuelle Reports sein? Statt der Standardrechnung 206 ist es dann z.B. Report 50206 oder auch mal 60206? Von was wird die Individualisierung abhängig gemacht. In 2017 gibt es z.B. die Möglichkeit Kundenindividueller Reports schon im Standard.

Solange der Standard da kein Event bereitstellt, musst du dich dafür in die Tabelle 77 Funktion "PrintWithGUIYesNo" / "PrintWithGUIYesNoVendor" einklinken.

Der Eingriff in den Standard wäre dann aber minimal. Sollte der Standard hier IntegrationEvents bereitstellen sollte es die zukünftig möglich sein, die ReportID per Event zu verändern.

Letzten endlich erschließt sich mir nicht, warum du die Berichtsauswahl nicht auf den korrekten Bericht umstellst. Der einzige Grund dafür wäre ja, dass du Kunden oder Lieferantenbezogene Belege hast oder Standardauswertungen durch angepasste ersetzen willst. In beiden Fällen kommst du aber nicht um eine Anpassung im Standard herum. Diese Anpassung müssen aber nur leicht in den Standard eingreifen und sollten sich auch zukünftig gut automatisch mergen lassen.

VG

Ok, ja dann warten wir mal ab.
Momentan komme ich ja auch mit den OnAction Events zurecht, ist aber nicht so schön.
Danke!

Vieleicht legst du nochmal kurz dar, was du eigentlich versuchst umzusetzen. Ich denke da können wir dir effektiver helfen.

Na ja, eigentlich ist mir ja schon geholfen.
Es ist so: Das eigentliche Ziel ist es, sämtliche Geschäftsbelege in einem einzigen RDLC-Layout (=1 Report) abzubilden. Damit man aber wie gewohnt auf den Tabellenköpfen filtern kann, benötigt man für jeden Kopf einen Report, von dem man eigentlich nur die Request Form benötigt. Diese Request-Reports rufen dann den einen und einzigen General-Report auf. Das klappt auch alles soweit.

Damit ich aber die Standard-Berichtsauswahlen nicht ändern muss, ersetze ich vor dem Drucken die Standard-ID's durch die ID's der Request-Reports und nach dem Druck drehe ich alles wieder zurück. Das Ganze ist über ein Setup gesteuert, sodass die NAV Standard-Belege gedruckt werden, wenn es kein setup gibt.

Ursprünglich wollte ich einen 2. Button zum Drucken vorsehen, aber es sind doch sehe viele Masken, die man dann anpassen muss. Vor daher war es mir sympathischer die Berichtsauswahlen dynamisch zu ändern. Schön wäre dann ein zentrales Druck-Event, dann braucht man nicht so viele Events.

Das eigentliche Ziel ist es, sämtliche Geschäftsbelege in einem einzigen RDLC-Layout (=1 Report) abzubilden.

Ich weiß nicht in welcher Branche du arbeitest, aber alle Belege mit einem Layout zu verarbeiten zu wollen ist schon recht sportlich. Ich stelle mir gerade das normale Layout eines Lieferscheins und das einer Rechnung vor. Die unterscheiden sich im Tabellen- Bereich normalerweise sehr. Wenn es jetzt auch noch einen Packschein gibt, der noch einmal anders aussieht wird es lustig.

Aber wenn du mit einem Layout hinkommen solltest, dann solltest du auch mit einem Bericht hinkommen. In NAV 2017 gibt es die Möglichkeit sich Requestpages selbst zu bauen.

Gruß Fiddi

Das passt ja dann prima hier rein: viewtopic.php?f=64&t=34066
Ich hatte es aus Zeitmangel noch nicht weiter probiert. Probleme könnte es aber geben, wenn eine Archivierung aktiv ist.

Das du die Reportselection umschreibst, finde ich nicht so gut. Das könnte zu Sperren führen. Was spricht dagegen, die Report IDs dauerhaft zu speichern. Diese sind doch sowieso die "Request-Reports" welche dann immer aufgerufen werden?

ja, das mit dem Layout darf man nicht so ernst sehen. Ich sehe schon ziemliche Ähnlichkeiten zwischen den Belegen.
In RDLC lässt sich das ja schön übe Sichtbarkeiten etc. steuern.

Dass man eine request page für mehrere Tabellen gleichzeitig vorsehen kann, ist mir neu. gibt es irgendwo eine Doku zu dem Thema?

zu :

Das passt ja dann prima hier rein: viewtopic.php?f=64&t=34066

Ja, genau. Ich komme mit einem RDLC-Layout in einem Report aus.

Der Ablauf ist wie folgt:

1. Ermitteln welche Report-ID gedruckt werden soll.
2. Ersetzen dieser ID durch die ID des request reports. (kann man natürlich auch dauerhaft ersetzen. Ich sehe hier gewisse Vorteile, wenn man das Ganze konfigurieren kann. In einem setup ist hinterlegt, welche ID durch welche zu ersetzen ist.
3. Start des request-reports.
4. Erfassen der Filter und Optionen.
5. Übergabe der Informationen an den master report in Form von Parametern und Variant Objekten.
6. Identifikation der Quelldaten im master report
7. Ermittlung welche Daten angezeigt werden sollen aus einem setup.
8. Holen der Daten auf Basis von Tabellen- und Feldnummern. (Beispiel: get(quantity,'HEADER') liefert die Daten aus unterschiedlichen Tabellen und Feldern)

Dabei werden keine festen Dataitems verwendet, sondern Integer und Temp-Tabellen. Der Ansatz mit festen DataItems wurde auch schon mal erfolgreich umgesetzt, ist aber nicht so schlank.

Das Thema Archivierung stellt kein Problem dar.
Ansonsten habe ich weitgehend alle Funktionen, die der Standard mitbringt, versucht einzubauen.
Problematisch sind Dinge wie buchen und senden...

Dass man eine request page für mehrere Tabellen gleichzeitig vorsehen kann, ist mir neu. gibt es irgendwo eine Doku zu dem Thema?

Kann man auch nicht. du könntest rein theoretisch aus deinem Report heraus mit RUNREQUESTPAGE die Requestpage eines anderen Reports aufrufen, und mit dem Ergebnis deinen Report Filtern.

Was ich meinte, findet man im NAV 2016 in der Hilfe unter dem Stichwort "FilterPageBuilder".

Gruß Fiddi

Danke für den Tipp.