Why do you need this change?
The Bank Acc. Reconciliation Line table (274) contains three procedures that determine whether a bank transaction can be imported:
IsTransactionPostedAndReconciled()
IsTransactionPostedAndNotReconciled()
IsTransactionAlreadyImported()
The IsTransactionPostedAndReconciled() procedure already provides an OnBeforeIsTransactionPostedAndReconciled integration event with ReturnValue and IsHandled parameters.
However, the two related procedures IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported() do not provide equivalent extensibility points.
I would like to be able to bypass the IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported() procedures, based on additional fields or business conditions that an extension may introduce on the Bank Acc. Reconciliation Line.
Right now I cannot do this without duplicating or replacing standard application logic.
Describe the request
I would like to request equivalent OnBefore integration events for the following two local procedures in table 274 "Bank Acc. Reconciliation Line":
1. IsTransactionPostedAndNotReconciled()
Current implementation:
local procedure IsTransactionPostedAndNotReconciled(): Boolean
var
PostedPaymentReconLine: Record "Posted Payment Recon. Line";
begin
if "Transaction ID" <> '' then begin
PostedPaymentReconLine.SetRange("Bank Account No.", "Bank Account No.");
PostedPaymentReconLine.SetRange("Transaction ID", "Transaction ID");
PostedPaymentReconLine.SetRange(Reconciled, false);
exit(not PostedPaymentReconLine.IsEmpty());
end;
exit(false);
end;
I request an event following the same pattern as OnBeforeIsTransactionPostedAndReconciled, for example:
[IntegrationEvent(false, false)]
local procedure OnBeforeIsTransactionPostedAndNotReconciled(
var BankAccReconciliationLine: Record "Bank Acc. Reconciliation Line";
var ReturnValue: Boolean;
var IsHandled: Boolean)
begin
end;
and that the procedure calls it before executing its standard logic:
local procedure IsTransactionPostedAndNotReconciled(): Boolean
var
PostedPaymentReconLine: Record "Posted Payment Recon. Line";
ReturnValue: Boolean;
IsHandled: Boolean;
begin
OnBeforeIsTransactionPostedAndNotReconciled(Rec, ReturnValue, IsHandled);
if IsHandled then
exit(ReturnValue);
if "Transaction ID" <> '' then begin
PostedPaymentReconLine.SetRange("Bank Account No.", "Bank Account No.");
PostedPaymentReconLine.SetRange("Transaction ID", "Transaction ID");
PostedPaymentReconLine.SetRange(Reconciled, false);
exit(not PostedPaymentReconLine.IsEmpty());
end;
exit(false);
end;
2. IsTransactionAlreadyImported()
Current implementation:
local procedure IsTransactionAlreadyImported(): Boolean
var
BankAccReconciliationLine: Record "Bank Acc. Reconciliation Line";
begin
if "Transaction ID" <> '' then begin
BankAccReconciliationLine.SetRange("Statement Type", "Statement Type");
BankAccReconciliationLine.SetRange("Bank Account No.", "Bank Account No.");
BankAccReconciliationLine.SetRange("Transaction ID", "Transaction ID");
exit(not BankAccReconciliationLine.IsEmpty());
end;
exit(false);
end;
I request an equivalent event, for example:
[IntegrationEvent(false, false)]
local procedure OnBeforeIsTransactionAlreadyImported(
var BankAccReconciliationLine: Record "Bank Acc. Reconciliation Line";
var ReturnValue: Boolean;
var IsHandled: Boolean)
begin
end;
and that the procedure calls it before executing its standard logic:
local procedure IsTransactionAlreadyImported(): Boolean
var
BankAccReconciliationLine: Record "Bank Acc. Reconciliation Line";
ReturnValue: Boolean;
IsHandled: Boolean;
begin
OnBeforeIsTransactionAlreadyImported(Rec, ReturnValue, IsHandled);
if IsHandled then
exit(ReturnValue);
if "Transaction ID" <> '' then begin
BankAccReconciliationLine.SetRange("Statement Type", "Statement Type");
BankAccReconciliationLine.SetRange("Bank Account No.", "Bank Account No.");
BankAccReconciliationLine.SetRange("Transaction ID", "Transaction ID");
exit(not BankAccReconciliationLine.IsEmpty());
end;
exit(false);
end;
Reason for the extensibility request
We have an extension that adds additional information to the Bank Acc. Reconciliation Line and uses this information when determining whether an imported bank transaction should be considered a duplicate or an already posted transaction.
The standard implementation of IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported() only considers the standard fields, such as Bank Account No., Transaction ID, Statement Type, and Reconciled status.
In our scenario, there are additional conditions that need to be taken into account when making this determination. These conditions depend on fields added by our extension and cannot be evaluated by the standard procedures.
As a result, there are cases where the standard procedure returns true, but our extension needs the transaction to be treated differently based on the additional information available on the Bank Acc. Reconciliation Line.
Currently, there is no way for an extension to override the result of these two procedures. The only alternatives are to duplicate the standard logic or replace/modify standard application behaviour, which is undesirable and makes the extension more dependent on the implementation details of the base application.
The requested events would allow an extension to participate in this decision while leaving the standard behaviour unchanged for all other scenarios.
In particular, the ReturnValue and IsHandled parameters would allow an extension to:
- leave the standard behaviour unchanged when the additional conditions do not apply;
- provide its own result when the additional conditions do apply
- and avoid duplicating the standard implementation of the procedures.
This is consistent with the existing OnBeforeIsTransactionPostedAndReconciled event in table 274, which already provides this extensibility pattern for the related procedure.
Alternatives evaluated
We evaluated the existing integration events and extensibility points available in table 274, "Bank Acc. Reconciliation Line", particularly the events around bank reconciliation line filtering, transaction import, and the existing IsTransactionPostedAndReconciled() implementation.
The existing OnBeforeIsTransactionPostedAndReconciled event provides the required extensibility pattern for the first transaction-import check, including a ReturnValue and IsHandled parameter. However, there are no equivalent events for IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported().
The relevant logic is contained inside the CanImport() procedure, where these three checks are evaluated as part of the standard import decision:
IsTransactionPostedAndReconciled()
IsTransactionAlreadyImported()
IsTransactionPostedAndNotReconciled()
Because the latter two procedures are local and their results cannot currently be influenced by an extension, an extension cannot change the outcome of these checks without duplicating or replacing standard application logic.
We also considered subscribing to events further up or down the import process. However, those approaches do not provide the same level of control over the result of these specific checks. In particular, they would require the extension to reproduce part of the standard transaction-import decision logic, which would create unnecessary coupling to the implementation of the base application.
Justification for IsHandled
The requested events specifically require the ability for an extension to replace the result of the standard check in a controlled scenario.
A regular OnBefore event without IsHandled would allow an extension to inspect or modify parameters, but it would not provide a reliable way to prevent the standard implementation from subsequently executing and determining a different result.
The existing OnBeforeIsTransactionPostedAndReconciled event already establishes this pattern for the corresponding check. We are therefore requesting the same extensibility pattern for the two related checks rather than introducing a new or different extensibility mechanism.
The intended use is not to replace the complete CanImport() process. The extension would only override the result of one of these specific checks when additional business conditions require it; otherwise the standard Business Central logic would continue to execute unchanged.
This is particularly relevant because the extension has additional information available on the Bank Acc. Reconciliation Line that is not considered by the standard implementation. The extension needs to use that information when determining whether a transaction should be considered already imported or posted-but-not-reconciled.
Performance considerations
These procedures are part of the bank statement transaction import process and can therefore be executed once for each transaction being evaluated for import.
The requested events themselves would have negligible overhead when there are no subscribers, following the same pattern as the existing OnBeforeIsTransactionPostedAndReconciled event.
The subscribing extension would perform only lightweight checks against fields already available on the Bank Acc. Reconciliation Line. It would not introduce additional processing for transactions where the custom conditions are not applicable.
The requested events also avoid requiring extensions to duplicate the standard database queries currently performed by IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported(). This should be preferable from a performance and maintainability perspective to extensions implementing their own replacement logic around the complete import process.
Data sensitivity review
The requested change does not introduce any new fields, tables, or data exposure.
The events would expose the existing Bank Acc. Reconciliation Line record and a Boolean return value/IsHandled flag, following the same pattern already used by OnBeforeIsTransactionPostedAndReconciled.
The underlying logic relates to bank reconciliation transactions, so the record can contain customer content such as transaction IDs, descriptions, amounts, account information and other bank statement information. However, the requested events do not expose this information beyond what is already accessible to extensions that have access to the Bank Acc. Reconciliation Line table.
No new sensitive data is being introduced or persisted by the requested change.
Multi-extension interaction
The requested events could technically have multiple subscribers, as with other integration events using an IsHandled pattern.
The expected usage is that an extension sets IsHandled := true only when it has a specific reason to override the standard result and provides the corresponding ReturnValue. Otherwise, the standard implementation remains in control.
As with other IsHandled events, multiple extensions attempting to override the same result could potentially interact with each other. However, this is limited to extensions that explicitly subscribe to these events and set IsHandled.
This is also consistent with the existing OnBeforeIsTransactionPostedAndReconciled extensibility pattern in the same table. The requested events would therefore extend an existing pattern rather than introduce a new interaction model.
Example scenario
For example, when an imported transaction has the same standard Transaction ID as an existing transaction, the standard implementation can determine that it has already been imported. However, our extension has additional information that allows us to distinguish transactions that should be considered separate for our business process.
In that situation, we need to be able to override the result of IsTransactionAlreadyImported() from an extension without replacing or duplicating the standard application logic.
The same requirement applies to IsTransactionPostedAndNotReconciled(): the standard result may need to be overridden when additional extension-specific information indicates that the transaction should be handled differently.
Therefore, we are requesting the two equivalent OnBefore events described below.
Provide an implementation (optional)
Why do you need this change?
The Bank Acc. Reconciliation Line table (274) contains three procedures that determine whether a bank transaction can be imported:
IsTransactionPostedAndReconciled()
IsTransactionPostedAndNotReconciled()
IsTransactionAlreadyImported()
The IsTransactionPostedAndReconciled() procedure already provides an OnBeforeIsTransactionPostedAndReconciled integration event with ReturnValue and IsHandled parameters.
However, the two related procedures IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported() do not provide equivalent extensibility points.
I would like to be able to bypass the IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported() procedures, based on additional fields or business conditions that an extension may introduce on the Bank Acc. Reconciliation Line.
Right now I cannot do this without duplicating or replacing standard application logic.
Describe the request
I would like to request equivalent OnBefore integration events for the following two local procedures in table 274 "Bank Acc. Reconciliation Line":
1. IsTransactionPostedAndNotReconciled()
Current implementation:
I request an event following the same pattern as OnBeforeIsTransactionPostedAndReconciled, for example:
and that the procedure calls it before executing its standard logic:
2. IsTransactionAlreadyImported()
Current implementation:
I request an equivalent event, for example:
and that the procedure calls it before executing its standard logic:
Reason for the extensibility request
We have an extension that adds additional information to the Bank Acc. Reconciliation Line and uses this information when determining whether an imported bank transaction should be considered a duplicate or an already posted transaction.
The standard implementation of IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported() only considers the standard fields, such as Bank Account No., Transaction ID, Statement Type, and Reconciled status.
In our scenario, there are additional conditions that need to be taken into account when making this determination. These conditions depend on fields added by our extension and cannot be evaluated by the standard procedures.
As a result, there are cases where the standard procedure returns true, but our extension needs the transaction to be treated differently based on the additional information available on the Bank Acc. Reconciliation Line.
Currently, there is no way for an extension to override the result of these two procedures. The only alternatives are to duplicate the standard logic or replace/modify standard application behaviour, which is undesirable and makes the extension more dependent on the implementation details of the base application.
The requested events would allow an extension to participate in this decision while leaving the standard behaviour unchanged for all other scenarios.
In particular, the ReturnValue and IsHandled parameters would allow an extension to:
This is consistent with the existing OnBeforeIsTransactionPostedAndReconciled event in table 274, which already provides this extensibility pattern for the related procedure.
Alternatives evaluated
We evaluated the existing integration events and extensibility points available in table 274, "Bank Acc. Reconciliation Line", particularly the events around bank reconciliation line filtering, transaction import, and the existing IsTransactionPostedAndReconciled() implementation.
The existing OnBeforeIsTransactionPostedAndReconciled event provides the required extensibility pattern for the first transaction-import check, including a ReturnValue and IsHandled parameter. However, there are no equivalent events for IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported().
The relevant logic is contained inside the CanImport() procedure, where these three checks are evaluated as part of the standard import decision:
IsTransactionPostedAndReconciled()
IsTransactionAlreadyImported()
IsTransactionPostedAndNotReconciled()
Because the latter two procedures are local and their results cannot currently be influenced by an extension, an extension cannot change the outcome of these checks without duplicating or replacing standard application logic.
We also considered subscribing to events further up or down the import process. However, those approaches do not provide the same level of control over the result of these specific checks. In particular, they would require the extension to reproduce part of the standard transaction-import decision logic, which would create unnecessary coupling to the implementation of the base application.
Justification for IsHandled
The requested events specifically require the ability for an extension to replace the result of the standard check in a controlled scenario.
A regular OnBefore event without IsHandled would allow an extension to inspect or modify parameters, but it would not provide a reliable way to prevent the standard implementation from subsequently executing and determining a different result.
The existing OnBeforeIsTransactionPostedAndReconciled event already establishes this pattern for the corresponding check. We are therefore requesting the same extensibility pattern for the two related checks rather than introducing a new or different extensibility mechanism.
The intended use is not to replace the complete CanImport() process. The extension would only override the result of one of these specific checks when additional business conditions require it; otherwise the standard Business Central logic would continue to execute unchanged.
This is particularly relevant because the extension has additional information available on the Bank Acc. Reconciliation Line that is not considered by the standard implementation. The extension needs to use that information when determining whether a transaction should be considered already imported or posted-but-not-reconciled.
Performance considerations
These procedures are part of the bank statement transaction import process and can therefore be executed once for each transaction being evaluated for import.
The requested events themselves would have negligible overhead when there are no subscribers, following the same pattern as the existing OnBeforeIsTransactionPostedAndReconciled event.
The subscribing extension would perform only lightweight checks against fields already available on the Bank Acc. Reconciliation Line. It would not introduce additional processing for transactions where the custom conditions are not applicable.
The requested events also avoid requiring extensions to duplicate the standard database queries currently performed by IsTransactionPostedAndNotReconciled() and IsTransactionAlreadyImported(). This should be preferable from a performance and maintainability perspective to extensions implementing their own replacement logic around the complete import process.
Data sensitivity review
The requested change does not introduce any new fields, tables, or data exposure.
The events would expose the existing Bank Acc. Reconciliation Line record and a Boolean return value/IsHandled flag, following the same pattern already used by OnBeforeIsTransactionPostedAndReconciled.
The underlying logic relates to bank reconciliation transactions, so the record can contain customer content such as transaction IDs, descriptions, amounts, account information and other bank statement information. However, the requested events do not expose this information beyond what is already accessible to extensions that have access to the Bank Acc. Reconciliation Line table.
No new sensitive data is being introduced or persisted by the requested change.
Multi-extension interaction
The requested events could technically have multiple subscribers, as with other integration events using an IsHandled pattern.
The expected usage is that an extension sets IsHandled := true only when it has a specific reason to override the standard result and provides the corresponding ReturnValue. Otherwise, the standard implementation remains in control.
As with other IsHandled events, multiple extensions attempting to override the same result could potentially interact with each other. However, this is limited to extensions that explicitly subscribe to these events and set IsHandled.
This is also consistent with the existing OnBeforeIsTransactionPostedAndReconciled extensibility pattern in the same table. The requested events would therefore extend an existing pattern rather than introduce a new interaction model.
Example scenario
For example, when an imported transaction has the same standard Transaction ID as an existing transaction, the standard implementation can determine that it has already been imported. However, our extension has additional information that allows us to distinguish transactions that should be considered separate for our business process.
In that situation, we need to be able to override the result of IsTransactionAlreadyImported() from an extension without replacing or duplicating the standard application logic.
The same requirement applies to IsTransactionPostedAndNotReconciled(): the standard result may need to be overridden when additional extension-specific information indicates that the transaction should be handled differently.
Therefore, we are requesting the two equivalent OnBefore events described below.
Provide an implementation (optional)