[US][Report][10135][Item Sales Statistics] Add integration event OnBeforePrintOnlyIfSalesCheck in the Item OnAfterGetRecord trigger, before the PrintOnlyIfSales skip check

[mavohra]

Why do you need this change?

Our extension computes an alternate-unit-of-measure sales figure from our own Item Ledger Entry sum, which is expected to disagree with the standard FlowField-sourced Sales (Qty.) , that disagreement is the entire point of the customization. The standard OnAfterGetRecord trigger calculates Sales (Qty. ) via CalcFields and immediately decides, in the same statement block, whether to CurrReport.Skip() the record based on PrintOnlyIfSales and that FlowField value before any extension trigger (modify(Item) { trigger OnAfterAfterGetRecord }) ever runs. PrintOnlyIfSales itself is a private global with no accessible getter and it cannot be read from any kind of extension trigger, including a request-page control extension's OnAfterValidate.

Net effect: when "Only Items with Sales" is checked, an item, our own calculation shows as having real (alternate-UOM) sales can be silently skipped before our code runs, and an item we'd consider zero-sales can still print. We currently ship a second, custom checkbox that only produces a correct result when the standard "Only Items with Sales" is left unchecked which is a workaroud. A single event exposing the already-computed skip decision, raised after CalcFields and before CurrReport.Skip() , would let us fold our own figures into the one decision the user sees.

Describe the request

Add an integration event immediately after the existing CalcFields call and before the existing skip check, exposing the record and the already-computed skip boolean by var so a subscriber can override it in either direction:

trigger OnAfterGetRecord()
begin
    NoShow := false;
    if BreakdownByVariant then begin
        NoVariant := Text002;
        if AnyVariants() then
            NoShow := true;
    end;

    SetRange("Variant Filter");
    CalcFields("Sales (Qty.)", "Sales (LCY)", "COGS (LCY)");
    SkipRecord := ("Sales (Qty.)" = 0) and PrintOnlyIfSales;
    OnAfterGetRecordOnBeforePrintOnlyIfSalesCheck(Rec, PrintOnlyIfSales, SkipRecord);
    if SkipRecord then
        CurrReport.Skip();
    Profit := "Sales (LCY)" - "COGS (LCY)";
    ...
end;

Event Signature:

[IntegrationEvent(false, false)]
local procedure OnAfterGetRecordOnBeforePrintOnlyIfSalesCheck(var Item: Record Item; PrintOnlyIfSales: Boolean; var SkipRecord: Boolean)
begin
end;

Alternatives evaluated:

• Reading PrintOnlyIfSales from a request-page control extension's OnAfterValidate , confirmed by the compiler that the variable is inaccessible from every kind of extension trigger, not just dataset ones.
• Recomputing the entire skip/Profit/ItemProfitPct block ourselves inside a modify(Item) { trigger OnBeforeAfterGetRecord }, not viable even with access, because that trigger runs before the base's own CalcFields, so "Sales (Qty.)" isn't populated yet at that point.
  Internal work item: AB#644155

[github-actions]

Hi Ahmed Vohra (@mavohra),

Thank you for your extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

Missing Information:

• Performance considerations: Describe the expected execution frequency for this report path and the expected runtime impact of allowing subscribers to override SkipRecord.
• Data sensitivity review: Confirm whether exposing Item, PrintOnlyIfSales, and SkipRecord involves any sensitive data exposure, and why exposing these values is safe.
• Multi-extension interaction: Explain whether multiple subscribing extensions could conflict when overriding SkipRecord, and how that interaction risk is understood.

Please update the issue with the missing details. We'll automatically re-analyze once updated.

Note

Automatically generated by the Triage Agent — advisory only. An engineer will review before any action is taken.

Tip

Not accurate? Reply with /not-accurate (optional: add a short explanation). Your feedback improves future responses.

[mavohra]

Performance considerations

The event fires exactly where OnAfterGetRecord already fires today: once per Item record that survives the report's request-page filters, i.e. no change to execution frequency versus the current shipped behavior. It's a single integration event invocation added after work (CalcFields) that already happens on every iteration. In our case, a lookup against a sum we already have to maintain for our own alternate-UOM figure regardless of whether this event exists, so no new computation is introduced by the event itself, only a new place to plug in work we're already doing.

Data sensitivity review

• Item — already fully readable by extensions today via the existing table-level Item.OnAfterGetRecord trigger (which fires immediately after this one, with the same CalcFields'd values already populated). This event exposes nothing about Item that isn't already visible through a currently-published extension point.
• PrintOnlyIfSales — a boolean sourced directly from the "Only Items with Sales" request-page checkbox the user themselves ticks before running the report. It's a UI filter flag, not customer/financial data, and carries no more sensitivity than the request page control itself.
• SkipRecord — a transient, non-persisted local boolean computed for this one report execution and discarded afterward. It never gets written to a table or exposed outside the run.

None of the three introduce new sensitive-data exposure beyond what's already reachable from existing standard events on this report/table.

Multi-extension interaction

This follows the same var Boolean override pattern already used pervasively in the base app (e.g. IsHandled/skip-style events), where the last-executing subscriber's write wins if two extensions disagree. That's a general characteristic of any mutable var shared across subscribers, not something specific to this event.

Happy to adjust the event name/placement if there's a preferred convention for this report.

[github-actions]

✅ Analysis complete - ready for further processing

---

Implementation:

Add a new integration event in the OnAfterGetRecord() trigger of report 10135 "Item Sales Statistics" after CalcFields("Sales (Qty.)", "Sales (LCY)", "COGS (LCY)") and before the PrintOnlyIfSales skip check so extensions can override whether the current Item record is skipped.

Location in OnAfterGetRecord() trigger:

trigger OnAfterGetRecord()
var
    SkipRecord: Boolean;
begin
    NoShow := false;
    if BreakdownByVariant then begin
        NoVariant := Text002;
        if AnyVariants() then
            NoShow := true;
        // EXIT;
    end;

    SetRange("Variant Filter");
    CalcFields("Sales (Qty.)", "Sales (LCY)", "COGS (LCY)");
    SkipRecord := ("Sales (Qty.)" = 0) and PrintOnlyIfSales;
    OnAfterGetRecordOnBeforePrintOnlyIfSalesCheck(Item, PrintOnlyIfSales, SkipRecord);
    if SkipRecord then
        CurrReport.Skip();
    Profit := "Sales (LCY)" - "COGS (LCY)";
    if "Sales (LCY)" <> 0 then
        ItemProfitPct := Round(Profit / "Sales (LCY)" * 100, 0.1)
    else
        ItemProfitPct := 0;
    QuantityReturned := 0;
    ItemLedgerEntry.SetRange("Item No.", "No.");
    ItemLedgerEntry.SetRange("Variant Code");
    if ItemLedgerEntry.Find('-') then
        repeat
            if ItemLedgerEntry."Invoiced Quantity" > 0 then begin
                QuantityReturned := QuantityReturned + ItemLedgerEntry."Invoiced Quantity";
                "Sales (Qty.)" := "Sales (Qty.)" + ItemLedgerEntry."Invoiced Quantity";
            end;
        until ItemLedgerEntry.Next() = 0;
end;

Event Publisher (add at the end of the codeunit with other events):

[IntegrationEvent(false, false)]
local procedure OnAfterGetRecordOnBeforePrintOnlyIfSalesCheck(var Item: Record Item; PrintOnlyIfSales: Boolean; var SkipRecord: Boolean)
begin
end;

---

File: ItemSalesStatistics.Report.al

Note

Automatically generated by the Triage Agent — advisory only. An engineer will review before any action is taken.

Tip

Not accurate? Reply with /not-accurate (optional: add a short explanation). Your feedback improves future responses.

[AleksandricMarko]

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.