table 246 "Requisition Line" field(9; "Vendor No."; Code[20]) trigger OnValidate

[Kotaite]

Why do you need this change?

At 4PS Construct, we have specific requirements for updating vendor item information in requisition lines to align with our customized item and vendor data management processes. In the OnValidate trigger of the "Vendor No." field (field 9) in table 246 "Requisition Line", the system automatically updates vendor-specific item information (such as vendor item number, lead time, and costs) whenever the vendor matches the item's vendor. This behavior is hardcoded and cannot be conditionally skipped, leading to unnecessary or incorrect updates in scenarios where the item record already contains correct vendor-specific data or where custom business logic should override the default behavior. There is no existing extensibility point to control this update, forcing partners to use less maintainable workarounds like overriding the entire OnValidate trigger.

Alternatives Evaluated:

• Existing events like OnValidateVendorNoOnBeforeSetVendorItemNoFromItemVend or OnValidateVendorNoOnBeforeGetDirectCost are too granular and do not allow skipping the entire vendor item info update block.

• Overriding the OnValidate trigger via table extension is possible but fragile, as it requires duplicating all standard logic and risks breaking with future updates.

• No other patterns (e.g., field-level events or redesigns) provide the needed control without significant code duplication.

Performance Considerations:
The event executes infrequently, only when validating the "Vendor No." field on requisition lines where Type = Item and "No." is populated (excluding production orders). It involves no loops, large datasets, locking, or external calls. The impact is minimal, as it's a simple boolean check with potential subscriber logic that should be lightweight.

Justification for IsHandled:
A standard (non-IsHandled) event would not suffice because multiple subscribers might conflict on whether to update or not, and there's no clear way to resolve ordering or precedence. A new IsHandled pattern allows one subscriber to definitively control the behavior, which is appropriate here since the update is an all-or-nothing operation. Redesigning the core logic (e.g., moving it to a separate procedure) would be overkill for this specific need and could introduce broader breaking changes.

Describe the request

Dear ALAppExtensions team,
On behalf of 4PS, I would like to request a new integration event OnBeforeUpdateVendorItemInfo and a local variable UpdateVendorItemInfo in the OnValidate trigger of field 9 ("Vendor No."). The event should be published before the vendor item information update logic, allowing subscribers to set UpdateVendorItemInfo to false to skip the update.

Current code:

Suggested extensibility:

Internal work item: [AB#616624](https://dynamicssmb2.visualstudio.com/1fcb79e7-ab07-432a-a3c6-6cf5a88ba4a5/_workitems/edit/616624)

[AleksandricMarko]

Hello @Kotaite

Recently we announced that for every new IsHandled event request, author need to provide a response to several question (please check link)

We want to be sure that IsHandled event is the only option, as this kind of events is not the best approach due to several reasons (codebase harder to maintain, harder refactoring, fragile solutions, easily break other implementations...)

Please also check the explanation about when and how to use IsHandled events (link)

[Kotaite]

Hello @AleksandricMarko,
I added additional information to the request.