[Event Request] codeunit 487 "Job Queue Start Report" - OnBeforeProcessPrint

[KlaasKleermaker]

Describe the request

Dear ALAppExtensions team,

On behalf of 4PS I would like to request integration event 'OnBeforeProcessPrint' to be changed in procedure ProcessPrint in codeunit 487 "Job Queue Start Report".

    local procedure ProcessPrint(ReportID: Integer; var JobQueueEntry: Record "Job Queue Entry"; RunOnRec: Boolean; var RecRef: RecordRef)
    var
        IsHandled: Boolean;
    begin
        IsHandled := false;
        //OnBeforeProcessPrint(ReportID, JobQueueEntry, IsHandled); //old
        OnBeforeProcessPrint(ReportID, JobQueueEntry, IsHandled, RecRef); //new
        if IsHandled then
            exit;

        if RunOnRec then
            REPORT.Print(ReportID, JobQueueEntry.GetReportParameters(), JobQueueEntry."Printer Name", RecRef)
        else
            REPORT.Print(ReportID, JobQueueEntry.GetReportParameters(), JobQueueEntry."Printer Name");
    end;

    [IntegrationEvent(false, false)]
    //local procedure OnBeforeProcessPrint(ReportID: Integer; var JobQueueEntry: Record "Job Queue Entry"; var IsHandled: Boolean) //old
    local procedure OnBeforeProcessPrint(ReportID: Integer; var JobQueueEntry: Record "Job Queue Entry"; var IsHandled: Boolean; var RecordRef: RecordRef) //new
    begin
    end;

Additional context

In some cases we need set an extra filter on the RecordRef. In the event OnBeforeProcessSaveAs there is already an argument "var RecordRef: RecordRef". Internal work item: AB#539584

[Groenbech96]

I dont get it. This is supposed to be a single record. It comes from the RecRef.Get(JobQueueEntry."Record ID to Process");

Why would you need extra filters?

[KlaasKleermaker]

For the pro forma sales invoice, posted sales invoice, proforma sales credit memo and posted sales credit memo, we use the same report, so that we don't have to maintain 4 report layouts that are the same.

Before calling this "generic" sales report, we set a filter in FilterGroup 20 (SalesInvoiceHeader.SetFilter("No.", '<>%1', ''), SalesCrMemoHeader.SetFilter("No.", '<>%1', '') or SalesHeader.SetRange("Document Type", SalesHeader."Document Type")). This is done to be able to determine the document type in the "generic" sales report.

[Groenbech96]

I must be misunderstanding something here. Cant you just set different records in ."Record ID to Process" when running the CU? That is being picked up and given to the report.

[KlaasKleermaker]

No, that will not solve our problem. Suppose that you want to print all pro form sales invoices. In that case you have to run the "generic" sales report without any filter on table Sales Header. Because the "generic" report has 3 dataitems (Sales Invoice Header, Sales Credit Memo Header and Sales Header) it somehow has to know which one must be used. To solve this we add a filter in FilterGroup 20, to make it possible in the generic report to find out which data item must be used.

This means that this filter in FilterGroup 20 is not used as a normal filter, but only to pass some information to the "generic" report about which dataitem must be used. This report is not only used codeunit 487, but also on different places. Therefore it would be very nice if we don't have to change this mechanism in the "generic" sales report.

The "generic" sales report is the most important report that we have, and almost all customers made a copy of this report to make there specific layout of the printed sales invoice.

It would be a very big problem for us if this "var RecordRef" would not be added to this event publisher, because then all the customized "generic" sales reports have to be changed for almost all our customers.

[VolodySyn]

@Groenbech96, since we already have the event with half of parameters, it does make sense to add both RunOnRec: Boolean and var RecRef: RecordRef to the event. @KlaasKleermaker, without knowing your generic report details - instead of using filtergroup, can you use JobQueueEntry + report parameters to pass the DataItem to be used?

[KlaasKleermaker]

Maybe it would be possible to use report parameters to solve this problem, but in that case the (customized) generic sales reports must be updated. That would be a big issue, because in that case our technical consultants will have to change thousands of reports that have been customized for our customers.

[JesperSchulz]

Availability update: We will publish a fix for this issue in the next update for release 25.

Build ID to track: 24801.

[JesperSchulz]

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Build ID: 24757.