[W1][Codeunit][22][Item Jnl.-Post Line] Add integration event OnUpdateItemLedgEntryOnBeforeUpdateInvoicedQuantity in Procedure UpdateItemLedgEntry

[mavohra]

Why do you need this change?

We need to intercept the invoiced quantity update block in UpdateItemLedgEntry to replace the standard ItemLedgEntry."Invoiced Quantity" := ItemLedgEntry."Invoiced Quantity" + ValueEntry."Invoiced Quantity" assignment with logic that updates alternate quantity fields on the item ledger entry alongside the standard invoiced quantity, and to replace the ItemJnlLine.Quantity = 0 gate condition with an alternate quantity check.

The standard code uses ItemJnlLine.Quantity = 0 to determine whether this posting is a pure invoice with no quantity movement, then unconditionally adds ValueEntry."Invoiced Quantity" to ItemLedgEntry."Invoiced Quantity". In scenarios where alternate quantity fields drive costing logic, the Quantity = 0 check produces an incorrect gate result, and the single-line invoiced quantity assignment does not update the corresponding alternate quantity field on the item ledger entry.

No event currently exists between the OnUpdateItemLedgerEntryOnAfterSetAppliedEntryToAdjust call and the outer if (ValueEntry."Entry Type" = "Direct Cost") and (ItemJnlLine."Item Charge No." = '') and (ItemJnlLine.Quantity = 0) block that allows a subscriber to take control of the gate condition evaluation and the invoiced quantity assignment.

Describe the request

Add an integration event OnUpdateItemLedgEntryOnBeforeUpdateInvoicedQuantity in UpdateItemLedgEntry in Codeunit 22 "Item Jnl.-Post Line" after the applied-entry-to-adjust block and before the invoiced quantity update condition, with IsHandled wrapping the entire outer invoiced quantity update block.

            then begin
                ItemLedgEntry."Applied Entry to Adjust" := true;
                ModifyEntry := true;
                OnUpdateItemLedgerEntryOnAfterSetAppliedEntryToAdjust(ItemLedgEntry);
            end;

            IsHandled := false;
            OnUpdateItemLedgEntryOnBeforeUpdateInvoicedQuantity(ItemJnlLine, ItemLedgEntry, ValueEntry, ModifyEntry, IsHandled); // <---- New Event
            if not IsHandled then
                if (ValueEntry."Entry Type" = ValueEntry."Entry Type"::"Direct Cost") and
                   (ItemJnlLine."Item Charge No." = '') and
                   (ItemJnlLine.Quantity = 0) and (ValueEntry."Invoiced Quantity" <> 0)
                then begin
                    if ValueEntry."Invoiced Quantity" <> 0 then begin
                        ItemLedgEntry."Invoiced Quantity" := ItemLedgEntry."Invoiced Quantity" + ValueEntry."Invoiced Quantity";
                        CheckInvoicedQuantity(ItemLedgEntry, ValueEntry, ModifyEntry);
                    end;

                    if (ItemLedgEntry."Entry Type" <> ItemLedgEntry."Entry Type"::Output) and
                       (ItemLedgEntry."Invoiced Quantity" = ItemLedgEntry.Quantity) and
                       not ItemLedgEntry."Completely Invoiced"
                    then begin
                        ItemLedgEntry."Completely Invoiced" := true;
                        ModifyEntry := true;
                    end;

                    if ItemLedgEntry."Last Invoice Date" < ValueEntry."Posting Date" then begin
                        ItemLedgEntry."Last Invoice Date" := ValueEntry."Posting Date";
                        ModifyEntry := true;
                    end;
                end;
         

Event Signature:

[IntegrationEvent(false, false)]
local procedure OnUpdateItemLedgEntryOnBeforeUpdateInvoicedQuantity(var ItemJnlLine: Record "Item Journal Line"; var ItemLedgEntry: Record "Item Ledger Entry"; ValueEntry: Record "Value Entry"; var ModifyEntry: Boolean; var IsHandled: Boolean)
begin
end;

Alternatives evaluated: OnUpdateItemLedgEntryOnBeforeUpdateAvgCostAdjmtBuffer fires at the top of the non-variance/rounding block but is scoped to the average cost adjustment buffer update and exposes no mechanism to skip the invoiced quantity condition. OnUpdateItemLedgerEntryOnAfterSetAppliedEntryToAdjust fires immediately before the invoiced quantity condition but does not expose the value entry or ModifyEntry, making it impossible to intercept the gate condition or the invoiced quantity assignment. OnUpdateItemLedgEntryOnBeforeUpdateOutboundItemLedgEntry fires after the invoiced quantity block is already complete, too late to replace the assignment. No event currently exists before the ItemJnlLine.Quantity = 0 gate that allows a subscriber to substitute an alternate quantity check and take over the invoiced quantity update logic.

[github-actions]

Hi @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 note: Add a brief note acknowledging the expected execution frequency and impact of this IsHandled event, for example that it runs during posting and subscriber logic will remain lightweight.
• Data sensitivity review: Add a short confirmation that this event does not expose sensitive data, or explain any exposure concerns.
• Multi-extension interaction assessment: Add a brief description of potential subscriber conflicts and explain why overlap or ordering risks are acceptable or how they are mitigated.

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 note: UpdateItemLedgEntry is called once per value entry during item journal line posting. The event fires on every call that passes the entry-type filter (non-variance, non-indirect-cost, non-rounding). When a subscriber sets IsHandled, it takes over the entire invoiced quantity update block: evaluating the gate condition, updating the alternate quantity fields, calling CheckInvoicedQuantity, and setting Completely Invoiced and Last Invoice Date as needed. These are all in-memory field assignments and the same codeunit calls made by the standard path. No additional DB reads are introduced.

Data sensitivity review: The parameters are ItemJnlLine (Item Journal Line), ItemLedgEntry (Item Ledger Entry), ValueEntry (Value Entry), ModifyEntry, and IsHandled. These are the same standard posting records already used throughout UpdateItemLedgEntry, containing item numbers, quantities, cost amounts, and document references. No sensitive personal data is exposed beyond what the procedure already handles internally.

Multi-extension interaction assessment: Unlikely

[github-actions]

Hi @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:

• Multi-extension interaction assessment: Please add a brief explanation of potential subscriber overlap or ordering conflicts for this IsHandled event, and why that risk is acceptable or how it would be mitigated.

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]

Any subsequent subscriber can check IsHandled before acting to avoid conflicts. This is the same pattern used by existing IsHandled events throughout Purch.-Post. No additional mitigation is needed.

[github-actions]

Hi @mavohra,

Thank you for your extensibility request.

The requested IsHandled event needs the invoiced-quantity update logic to be extracted into a dedicated local procedure first, rather than wrapping the existing inline block directly.

Recommended approach:

Add a local helper for the invoiced-quantity update logic in UpdateItemLedgEntry, then raise OnUpdateItemLedgEntryOnBeforeUpdateInvoicedQuantity(ItemJnlLine, ItemLedgEntry, ValueEntry, ModifyEntry, IsHandled) immediately before calling that helper so IsHandled skips the helper call when the subscriber takes over.

Please confirm if this alternative approach works for your scenario, or explain why the original approach is required.

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]

Yes, extracting the invoiced-quantity update block into a dedicated local procedure is acceptable

[github-actions]

Hi @mavohra,

Thank you for your extensibility request. Unfortunately, this request cannot be implemented.

Reason: The requested IsHandled event would let extensions fully bypass critical invoiced-quantity integrity logic in UpdateItemLedgEntry, including CheckInvoicedQuantity and the standard updates to Invoiced Quantity, Completely Invoiced, and Last Invoice Date, so the change is unsafe under the ishandled_unsafe_code_block rule.

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.