[EVENT REQUEST] Codeunit 926 (Assembly Line-Reserve)

[MarkusW-BSG]

Describe the request

Request 1 DeleteLine

procedure DeleteLine(var AssemblyLine: Record "Assembly Line")

has no event to customize code

New event
OnBeforeDeleteReservEntries(AssemblyLine: Record "Assembly Line")

Call
OnBeforeDeleteReservEntries(...)
ReservationManagement.DeleteReservEntries(true, 0);

Usage:
Get Information about an assembly line to be deleted... Passing parameters, calling validations,... on the non-var Assembly Line

Request 2 VerifyQuantity

procedure VerifyQuantity(var NewAssemblyLine: Record "Assembly Line"; var OldAssemblyLine: Record "Assembly Line")

has no appropriate event to customize the code

New event
VerifyQuantityOnBeforeDeleteReservEntries(var NewAssemblyLine: Record "Assembly Line")

Call
VerifyQuantityOnBeforeDeleteReservEntries(...)
ReservationManagement.DeleteReservEntries(false, NewAssemblyLine."Remaining Quantity (Base)");

Usage:
Get Information about an assembly line to be deleted... Passing parameters, calling validations

Request 3 TransferAsmLineToItemJnlLine

procedure TransferAsmLineToItemJnlLine(var AssemblyLine: Record "Assembly Line"; var ItemJournalLine: Record "Item Journal Line"; TransferQty: Decimal; CheckApplFromItemEntry: Boolean): Decimal

is completely free of events

New event
TransferAsmLineToItemJnlLineOnBeforeTransferReservEntry(var AssemblyLine: Record "Assembly Line"; var ItemJournalLine: Record "Item Journal Line"; var OldReservationEntry: Record "Reservation Entry")

Call
TransferAsmLineToItemJnlLineOnBeforeTransferReservEntry(...)
TransferQty := CreateReservEntry.TransferReservEntry(
Database::"Item Journal Line",
ItemJournalLine."Entry Type".AsInteger(), ItemJournalLine."Journal Template Name",
ItemJournalLine."Journal Batch Name", 0, ItemJournalLine."Line No.",
ItemJournalLine."Qty. per Unit of Measure", OldReservationEntry, TransferQty);

Request 4 TransferAsmLineToAsmLine

procedure TransferAsmLineToAsmLine(var OldAssemblyLine: Record "Assembly Line"; var NewAssemblyLine: Record "Assembly Line"; TransferQty: Decimal)

New event
TransferAsmLineToAsmLineOnBeforeTransferReservEntry(var OldAssemblyLine: Record "Assembly Line"; var NewAssemblyLine: Record "Assembly Line"; var OldReservationEntry: Record "Reservation Entry")

Call
TransferAsmLineToAsmLineOnBeforeTransferReservEntry(...)
TransferQty :=
CreateReservEntry.TransferReservEntry(
Database::"Assembly Line", NewAssemblyLine."Document Type".AsInteger(), NewAssemblyLine."Document No.", '', 0,
NewAssemblyLine."Line No.", NewAssemblyLine."Qty. per Unit of Measure", OldReservationEntry, TransferQty);

Additional context

In Steel Industry, one quantity is not enough for any process. Therefore our current Business Central is customized for using a second quantity. Every item has furthermore two inventories instead of one. An inventory measured by the base UOM (the standard) and a second one measure by its second UOM.

Example:
A customer orders approx. 2 tons of steel sheets, /.100 pieces.
Quantity: 2000
UOM: KG
Sec. Quantity: 100
Sec. UOM: PCE
Internal work item: AB#563881

[nikolakukrika]

@MarkusW-BSG IsHandled events are making code difficult to maintain and are leading to fragile solutions. Issue is that we are turning off large sections of the code. These solutions can easily break your implementation if we change the code that is currently called, you would need to react and update the code.

We are also seeing these problems with partner code: multiple extensions can clash trying to handle the same event, one extension is shutting off the code from another extension that is expecting that the events from the code will be called.

Can you please restructure the code to use different events instead of the handled event? We could add regular events in the different places to enable you to run more code, or to turn-off/skip less.

[MarkusW-BSG]

@nikolakukrika please give me a hint how I can extend the codeunit / the functions without any event.

If you create any other events that suits better for you and it is still possible for me to handle reservations differently / in an extended way this is completely okay.

As described in "additional context" we handle two quantities / units, not just one. Making it necessary to handle reservations differently (in an extended way)

[nikolakukrika]

@MarkusW-BSG I did not say without the event. Could you change the code to allow handling of the two quantities in the existing code instead of turning off the methods above? These could be other events that are in the places where we have issues of handling multiple quantities.

It is going to be a much better solution as we will see the intent when adding new code. Handled "pattern" has caused a lot of issues to the partner extensions, we are receiving complaints about coding this way. It is quick but it is also dirty, the price will be paid down the line in maintenance and it is higher.

We could also discuss this with the feature team, if they find this useful, you could change the base app code and introduce it as a proper extensibility/solution. If you are interested, I could ask to get you access to the GitHub and modify base app code.

We could also do a proper interface, thus you can replace the entire codeunit with your own interface implementation.

[MarkusW-BSG]

@nikolakukrika same comment as in #28006

I will redesign this for use without "isHandled"

[MarkusW-BSG]

@nikolakukrika
Hi Nikola,
many thanks for your suggestions, I redesigned my event requests such that they fit my needs and are a much better solution for the integrity of the whole... I hope. :-)

Please check that internal work items match the new requests for this and #28006 . :-)

Greetings
Markus

[nikolakukrika]

@MarkusW-BSG thanks a lot. This is a great example how we can move away from the Handled events.