[Event Request] codeunit 442 "Sales-Post Prepayments" - UpdatePrepmtAmountOnSaleslines procedure

[tuan-nguyen-fenwick]

Why do you need this change?

We would like to request the addition of 3 new integration events to further enhance the extensibility of the UpdatePrepmtAmountOnSalesLines procedure in Base Application.

The existing implementation does not provide sufficient extension points to control key parts of the prepayment update process. Specifically, we are not able to:

• Adjust or override the filters applied when retrieving prepayment sales lines.
• Handle scenarios where no prepayment lines exist without triggering an error.
• Run custom logic before individual sales lines are updated.

Describe the request

The 3 new proposed events that we would like to add at the end of the SalesPostPrepayments.Codeunit.al object are:

    [IntegrationEvent(false, false)]
    local procedure OnUpdatePrepmtAmountOnSalesLinesOnAfterSetFilters(var SalesLine: Record "Sales Line"; SalesHeader: Record "Sales Header"; var NewTotalPrepmtAmount: Decimal)
    begin
    end;

    [IntegrationEvent(false, false)]
    local procedure OnUpdatePrepmtAmountOnSalesLinesOnBeforeErrorIfLinesNotFound(var SalesLine: Record "Sales Line"; SalesHeader: Record "Sales Header"; var RaiseError: Boolean)
    begin
    end;

    [IntegrationEvent(false, false)]
    local procedure OnUpdatePrepmtAmountOnSalesLinesOnBeforeModify(var SalesLine: Record "Sales Line"; SalesHeader: Record "Sales Header"; var NewTotalPrepmtAmount: Decimal; var TotalPrepmtAmount: Decimal)
    begin
    end;

Event 1: OnUpdatePrepmtAmountOnSalesLinesOnAfterSetFilters should be added after filters are set and right before the table is locked. This allows extensions to adjust filters prior to processing and provides a safe hook before record locking occurs.

Event 2: OnUpdatePrepmtAmountOnSalesLinesOnBeforeErrorIfLinesNotFound should be added after attempting to retrieve prepayment sales lines, when no lines are found. This enables subscribers to suppress the standard error. Introduces a RaiseError variable and the default behaviour remains unchanged by setting it to RaiseError = true

Event 3: OnUpdatePrepmtAmountOnSalesLinesOnBeforeModify should be immediately before each line record is modified. This allows extensions to adjust values prior to modification.

[AleksandricMarko]

Hi @tuan-nguyen-fenwick,

Thanks for submitting this extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

Missing Information:

• Event in Loop — Performance Justification (Event 3): The proposed event OnUpdatePrepmtAmountOnSalesLinesOnBeforeModify is placed inside a repeat...until loop, which means it will fire for every sales line being modified. This may cause performance issues if subscribers perform heavy operations. Please address the following:
  1. Why must the event fire on each iteration rather than once before or after the loop?
  2. What operations will subscribers perform in the event handler?
  3. Have you considered alternative placements (e.g., a single event before or after the loop)?

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

[tuan-nguyen-fenwick]

Hi @tuan-nguyen-fenwick,

Thanks for submitting this extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

Missing Information:

• Event in Loop — Performance Justification (Event 3): The proposed event OnUpdatePrepmtAmountOnSalesLinesOnBeforeModify is placed inside a repeat...until loop, which means it will fire for every sales line being modified. This may cause performance issues if subscribers perform heavy operations. Please address the following:

  1. Why must the event fire on each iteration rather than once before or after the loop?
  2. What operations will subscribers perform in the event handler?
  3. Have you considered alternative placements (e.g., a single event before or after the loop)?

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

@AleksandricMarko We have a custom field that is calculated based on CustomField = SalesLine."Prepmt. Line Amount" - SalesLine."Prepmt. Amt. Inv."; and no other heavy calculation will occur here.

[github-actions]

Hi @tuan-nguyen-fenwick,

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:

• Existing events or alternative patterns considered: Please specify which existing events or alternative extensibility patterns you considered and why they are insufficient for this scenario.
• Bypass/suppress behavior justification: Please explain why suppressing the standard error behavior is necessary instead of using a regular event-only design.
• Data sensitivity statement: Please confirm whether any sensitive data is involved in this scenario.
• Multi-extension interaction or conflict risk: Please provide a brief note on how this behavior should work if multiple extensions subscribe and whether any conflict risk is expected.

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.

[tuan-nguyen-fenwick]

Hi @tuan-nguyen-fenwick,

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:

• Existing events or alternative patterns considered: Please specify which existing events or alternative extensibility patterns you considered and why they are insufficient for this scenario.
• Bypass/suppress behavior justification: Please explain why suppressing the standard error behavior is necessary instead of using a regular event-only design.
• Data sensitivity statement: Please confirm whether any sensitive data is involved in this scenario.
• Multi-extension interaction or conflict risk: Please provide a brief note on how this behavior should work if multiple extensions subscribe and whether any conflict risk is expected.

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.

• Existing events or alternative patterns considered: There's no other alternative without having to duplicate the entire UpdatePrepmtAmountOnSaleslines function.
• Bypass/suppress behavior justification: We don't have to bypass all errors being thrown in the function. Only the error that occurs when there is no prepayment line found.
• Data sensitivity statement: No.
• Multi-extension interaction or conflict risk: Minimal.

[github-actions]

Hi @tuan-nguyen-fenwick,

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:

• No-prepayment-lines handling: Please clarify the intended behavior when no prepayment lines are found. Suppressing the proposed no-lines-found error alone would still lead to the subsequent Error(Text013, NewTotalPrepmtAmount) because TotalLineAmount = 0. Please describe the required outcome for that case, or update the request with a different event shape/location that covers the full scenario.

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.