[W1][Codeunit][370][Bank Acc. Reconciliation Post] OnBeforeApplyVendLedgEntry event Requested

[pandea04]

Why do you need this change?

Business Requirement:
Current solution requires to change the logic of application in Vendor Ledger Entry, for Bank Account Reconciliation.

Current Limitation:
The existing functionality in BC does not allow to change the logic of the method that posts application of Vendor Ledger Entry and add additional validation

Microsoft Idea Proposal Document - Bank Account Reconciliation.docx

Describe the request

Requesting even to be added on Bank Acc. Reconciliation Post
Requested Integration Event

    [IntegrationEvent(false, false)]
    local procedure OnBeforeApplyVendLedgEntry(var VendLedgEntry: Record "Vendor Ledger Entry"; AppliedPmtEntry: Record "Applied Payment Entry"; var BankAcc: Record "Bank Account"; AppliesToID: Code[50]; PostingDate: Date; PmtDiscDueDate: Date; PmtDiscToleranceDate: Date; RemPmtDiscPossible: Decimal;var PreviewMode:Boolean;var IsHandled: Boolean)
    begin
    end;

This event will allow to add additional logic for the amount that needs to be applied for logical data flow to be added in 
, adding IsHandled

        IsHandled := false;
        OnBeforeApplyVendLedgEntry(VendLedgEntry, AppliedPmtEntry, BankAcc, AppliesToID, PostingDate, PmtDiscDueDate, PmtDiscToleranceDate, RemPmtDiscPossible, PreviewMode,IsHandled);
        if IsHandled then
            exit;

procedure ApplyVendLedgEntry(AppliedPmtEntry: Record "Applied Payment Entry"; AppliesToID: Code[50]; PostingDate: Date; PmtDiscDueDate: Date; PmtDiscToleranceDate: Date; RemPmtDiscPossible: Decimal)

similar to ApplyCustLedgEntry(AppliedPmtEntry: Record "Applied Payment Entry"; AppliesToID: Code[50]; PostingDate: Date; PmtDiscDueDate: Date; PmtDiscToleranceDate: Date; RemPmtDiscPossible: Decimal)

to be added in procedure ApplyVendLedgEntry

Internal work item: AB#619542

[AleksandricMarko]

Missing Information Required

Thank you for your event request. To process IsHandled event requests, we need additional information beyond the basic event description.

Required Information

1. Alternatives Evaluated

• Which existing events or patterns did you evaluate?
• Why are they insufficient for your needs?

2. Justification for IsHandled Pattern

• Why is bypassing the standard logic necessary?
• What specific business logic must be skipped or replaced?
• Why can't this be achieved with a standard event that doesn't bypass logic?

3. Performance Considerations

• How frequently will this event be raised?
• What is the expected performance impact?

4. Data Sensitivity Review

• Does this event expose any sensitive customer/business data?
• If yes, why is this exposure necessary?

5. Multi-Extension Interaction

• What happens if multiple extensions subscribe to this event?
• How would conflicts be handled if multiple subscribers set IsHandled := true?

Why This Matters

IsHandled events allow extensions to completely bypass standard Business Central logic, which can:

• Impact system stability if not carefully designed
• Create conflicts between multiple extensions
• Affect upgradability and supportability

Please update the issue description with these details so we can properly evaluate the request. We'll automatically re-analyze once the information is provided.

[pandea04]

Hi @AleksandricMarko ,

We did analyse other events but they are not helpful

The logical approach which we are trying to achieve is explained, as per tolerance limit we are trying to achieve customization intended for business and currently having no event does not allow us to achieve

[pandea04]

Hi @AleksandricMarko ,

Updated information

1. Alternatives Evaluated

Which existing events or patterns did you evaluate?

• Existing integration events in Codeunit 370 *“Bank Acc. Reconciliation Post” does not meet current extension expected
• Post-application and post-posting events related to Vendor Ledger Entries "OnPostPaymentApplicationsOnAccountTypeCaseElse"

Why are they insufficient for your needs?

• All existing events are raised after the standard vendor application logic has already executed.

• There is currently no event raised before the standard logic inside ApplyVendLedgEntry.

• Existing events do not allow:

  • Suppressing the standard vendor reconciliation algorithm
  • Replacing the calculation of Amount to Apply, Accepted Payment Tolerance, and Applies-to ID

• Post-posting adjustments or reversal-based workarounds are not acceptable due to:

  • Financial correctness
  • Auditability requirements
  • Increased complexity and risk

---

2. Justification for IsHandled Pattern

Why is bypassing the standard logic necessary?

• The standard ApplyVendLedgEntry procedure enforces a fixed reconciliation algorithm that cannot be conditionally altered.

• The business requirement requires vendor-level override logic during Bank Account Reconciliation, based on:

  • Bank Account setup (e.g., suspense account usage)
  • Vendor payment tolerance rules

What specific business logic must be skipped or replaced?

• Standard calculation of:

  • Amount to Apply
  • Accepted Payment Tolerance
  • Remaining amount comparison during reconciliation

• Default application behavior when a suspense account is used to be added as extensibility.

Why can't this be achieved with a standard event that doesn't bypass logic?

• A non-IsHandled event would execute in addition to standard logic, resulting in:

  • does not have any extensible hook to implement the expected logic

• It will help to extend and make financial correctness to logic as needed

---

3. Performance Considerations

How frequently will this event be raised?

• Once per Vendor Ledger Entry application during Bank Account Reconciliation posting.
• Only during reconciliation posting runs, not during high-volume transactional posting.

What is the expected performance impact?

• Negligible.
• The custom logic replaces existing processing rather than adding additional database operations.
• No additional record reads beyond those already required by standard logic.

---

4. Data Sensitivity Review

Does this event expose any sensitive customer/business data?

• No additional sensitive data is exposed beyond what is already processed by standard reconciliation logic.

If yes, why is this exposure necessary?

• Not applicable.
• The event parameters consist of records and values already handled internally by Business Central during posting.

---

5. Multi-Extension Interaction

What happens if multiple extensions subscribe to this event?

• The event follows the standard Business Central IsHandled extensibility pattern.
• If no subscriber sets IsHandled := true, standard logic executes.

How would conflicts be handled if multiple subscribers set IsHandled := true?

• The first subscriber setting IsHandled := true suppresses standard logic.
• This behavior is consistent with existing Base App design patterns.
• Solution providers are responsible for coordinating extension compatibility where required.

---

Why This Matters

IsHandled events enable partners to safely replace standard Business Central logic when complex or industry-specific requirements cannot be met otherwise.

Without this event:

• No Extensions replacement is their, whole codeunit replication and replacement does create technical overhead
• Reconciliation logic becomes fragile and difficult to audit
• Upgradeability and long-term supportability are negatively impacted

Providing this event aligns vendor reconciliation extensibility with the existing customer reconciliation pattern and improves overall platform consistency.

[AleksandricMarko]

✅ Analysis complete - approved for implementation

---

Implementation:

Add a new integration event OnBeforeApplyVendLedgEntry with IsHandled parameter at the beginning of the ApplyVendLedgEntry procedure in Codeunit 370 "Bank Acc. Reconciliation Post". The event should be published after initial field validation, allowing subscribers to set IsHandled to true to skip the standard vendor application logic.

Location in ApplyVendLedgEntry procedure (around line 813):

procedure ApplyVendLedgEntry(AppliedPmtEntry: Record "Applied Payment Entry"; AppliesToID: Code[50]; PostingDate: Date; PmtDiscDueDate: Date; PmtDiscToleranceDate: Date; RemPmtDiscPossible: Decimal)
var
    VendLedgEntry: Record "Vendor Ledger Entry";
    CurrExchRate: Record "Currency Exchange Rate";
    IsHandled: Boolean;
begin
    VendLedgEntry.Get(AppliedPmtEntry."Applies-to Entry No.");
    VendLedgEntry.TestField(Open);
    BankAcc.Get(AppliedPmtEntry."Bank Account No.");

    IsHandled := false;
    OnBeforeApplyVendLedgEntry(VendLedgEntry, AppliedPmtEntry, BankAcc, AppliesToID, PostingDate, PmtDiscDueDate, PmtDiscToleranceDate, RemPmtDiscPossible, IsHandled);
    if IsHandled then
        exit;

    if AppliesToID = '' then begin
        VendLedgEntry."Pmt. Discount Date" := PmtDiscDueDate;
        VendLedgEntry."Pmt. Disc. Tolerance Date" := PmtDiscToleranceDate;

        VendLedgEntry."Remaining Pmt. Disc. Possible" := RemPmtDiscPossible;
        if BankAcc.IsInLocalCurrency() then
            VendLedgEntry."Remaining Pmt. Disc. Possible" :=
              CurrExchRate.ExchangeAmount(VendLedgEntry."Remaining Pmt. Disc. Possible", '', VendLedgEntry."Currency Code", PostingDate);
    end else begin
        VendLedgEntry."Applies-to ID" := AppliesToID;
        VendLedgEntry."Amount to Apply" := AppliedPmtEntry.CalcAmountToApply(PostingDate);
    end;

    if PreviewMode then
        VendEntryEditNoCommit(VendLedgEntry)
    else
        CODEUNIT.Run(CODEUNIT::"Vend. Entry-Edit", VendLedgEntry);
end;

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

[IntegrationEvent(false, false)]
local procedure OnBeforeApplyVendLedgEntry(var VendLedgerEntry: Record "Vendor Ledger Entry"; AppliedPaymentEntry: Record "Applied Payment Entry"; var BankAccount: Record "Bank Account"; AppliesToID: Code[50]; PostingDate: Date; PmtDiscDueDate: Date; PmtDiscToleranceDate: Date; RemPmtDiscPossible: Decimal; var IsHandled: Boolean)
begin
end;

---

File: BankAccReconciliationPost.Codeunit.al