Why do you need this change?
We need an event inside the trigger OnModify of the table "Withholding Tax" in order to skip the code inside the trigger or to manage a custom condition before calling an Error().
It is necessary to manage a variable IsHandled (Boolean), otherwise there are no other ways to skip the Error.
In fact, even if I would decide to manage the further custom check before every Modify done on "Witholding Tax" table, this is not enough to skip the subsequent check on Reported field.
No sensitive data will be exposed in the custom code, we are supposed to add.
Describe the request
In trigger OnModify of table 12116 "Withholding Tax" we need an event:
[IntegrationEvent(false, false)]
local procedure OnBeforeOnModify(var Ishandled: Boolean; var Rec: record "Withholding Tax")
begin
end;
Changes between **:
trigger OnModify()
var
**Ishandled: Boolean;**
begin
**ishandled := false;
OnBeforeOnModify(ishandled, Rec);
if ishandled then
exit;**
if Reported or
Paid
then
Error(Text1033);
end;Performance considerations
The OnModify trigger of table 12116 "Withholding Tax" is executed only when a withholding tax entry is modified. These modifications are relatively infrequent and are typically initiated by user actions or specific application processes rather than high-volume batch operations.
The proposed change adds only:
OnBeforeOnModify(IsHandled, Rec);
if IsHandled then
exit;This introduces a single event invocation and a Boolean check, which has a negligible performance impact. No additional database operations are introduced by the platform change itself.
Multi-extension interaction
As with any IsHandled event, there is a potential risk that multiple extensions subscribe to the event and influence the control flow by setting IsHandled := true.
Possible scenarios include:
- One extension intentionally bypasses the standard validation (
Reported/Paid check), while another extension expects the base validation to execute.
- Multiple extensions implement different replacement logic and depend on subscriber execution order, which is not guaranteed.
However, the risk is considered acceptable because:
- The event is highly specific and only affects the
OnModify behavior of the Withholding Tax table.
- Subscribers should set
IsHandled := true only when they intentionally replace the standard validation with equivalent custom logic.
- Extensions that only need to perform additional checks can subscribe without changing
IsHandled, allowing the standard behavior to continue.
Currently, there is no extensibility point that allows partners to bypass or replace the Error(Text1033) condition. Without this event, extensions have no supported way to implement custom behavior and would be forced to use unsupported workarounds or redesign their business processes.
Therefore, despite the inherent considerations of the IsHandled pattern, the proposed event provides a controlled and maintainable extensibility point with minimal risk.
Internal work item: AB#640860
Why do you need this change?
We need an event inside the trigger OnModify of the table "Withholding Tax" in order to skip the code inside the trigger or to manage a custom condition before calling an Error().
It is necessary to manage a variable IsHandled (Boolean), otherwise there are no other ways to skip the Error.
In fact, even if I would decide to manage the further custom check before every Modify done on "Witholding Tax" table, this is not enough to skip the subsequent check on Reported field.
No sensitive data will be exposed in the custom code, we are supposed to add.
Describe the request
In trigger OnModify of table 12116 "Withholding Tax" we need an event:
Changes between **:
Performance considerations
The
OnModifytrigger of table 12116 "Withholding Tax" is executed only when a withholding tax entry is modified. These modifications are relatively infrequent and are typically initiated by user actions or specific application processes rather than high-volume batch operations.The proposed change adds only:
This introduces a single event invocation and a Boolean check, which has a negligible performance impact. No additional database operations are introduced by the platform change itself.
Multi-extension interaction
As with any
IsHandledevent, there is a potential risk that multiple extensions subscribe to the event and influence the control flow by settingIsHandled := true.Possible scenarios include:
Reported/Paidcheck), while another extension expects the base validation to execute.However, the risk is considered acceptable because:
OnModifybehavior of theWithholding Taxtable.IsHandled := trueonly when they intentionally replace the standard validation with equivalent custom logic.IsHandled, allowing the standard behavior to continue.Currently, there is no extensibility point that allows partners to bypass or replace the
Error(Text1033)condition. Without this event, extensions have no supported way to implement custom behavior and would be forced to use unsupported workarounds or redesign their business processes.Therefore, despite the inherent considerations of the
IsHandledpattern, the proposed event provides a controlled and maintainable extensibility point with minimal risk.Internal work item: AB#640860