Add a getter procedure for CalledFromHeader in Job Planning Line

Start by locating the Job Planning Line table and its existing SuspendDeletionCheck(Boolean) procedure. Add the parameterless getter alongside it, preserving the setter unchanged, and verify that it returns the current CalledFromHeader value. Done means extensions can call SuspendDeletionCheck() to read the runtime state without modifying it.

Why do you need this change?

The Job Planning Line table contains the internal CalledFromHeader Boolean variable, which is used to control whether certain deletion-check logic should be suspended when operations are initiated from the Job Task/Job Header context.

The table already provides the following procedure to set this value:

procedure SuspendDeletionCheck(Suspend: Boolean)
begin
    CalledFromHeader := Suspend;
end;

This allows standard Business Central code and extensions to set the runtime state of CalledFromHeader.

However, there is currently no corresponding procedure that allows extensions to retrieve the value of CalledFromHeader after it has been set.

This creates a limitation for extensions that need to participate in or extend the standard Job Planning Line deletion logic. In particular, a Table Extension or Codeunit Event Subscriber may need to determine whether the current execution was initiated with deletion checks suspended.

Without a getter procedure, extensions cannot reliably determine the runtime state established by the standard Job Planning Line table logic. The alternative is to maintain a separate state variable in extension code or duplicate/infer the standard logic, neither of which guarantees that the extension remains synchronized with the standard Business Central behavior.

We therefore request a public procedure that returns the current value of CalledFromHeader.

Describe the request

Please add a getter procedure to the Job Planning Line table that returns the current value of the CalledFromHeader variable.

The requested procedure would be:

procedure SuspendDeletionCheck() Suspend: Boolean
begin
    Suspend := CalledFromHeader;
end;

This would complement the existing setter procedure:

procedure SuspendDeletionCheck(Suspend: Boolean)
begin
    CalledFromHeader := Suspend;
end;

The existing setter would remain unchanged.

The addition of the parameterless overload would allow extensions to retrieve the current runtime state without exposing or modifying the underlying CalledFromHeader variable.

For example:

if Rec.SuspendDeletionCheck() then begin
    // Deletion check has been suspended by the standard logic.
end;

This would allow Table Extensions and Codeunit Event Subscribers to determine the state that was established during the current execution of the Job Planning Line record.

The requested procedure does not change any existing Business Central behavior. It only exposes the current value of an already existing runtime variable through a public procedure.

Expected implementation

The implementation can be kept minimal and would simply return the current value of CalledFromHeader:

procedure SuspendDeletionCheck() Suspend: Boolean
begin
    Suspend := CalledFromHeader;
end;

This procedure would be an overload of the existing SuspendDeletionCheck(Boolean) procedure.

The existing procedure:

procedure SuspendDeletionCheck(Suspend: Boolean)
begin
    CalledFromHeader := Suspend;
end;

would continue to be used to set the value.

The new parameterless procedure would only retrieve the value and would not modify it.

Why is this required?

The CalledFromHeader variable represents runtime state within the Job Planning Line table.

An extension may need to make a decision in an event subscriber based on whether the standard logic has suspended deletion checks. For example, an extension may subscribe to an event associated with deletion, validation, or reservation handling and need to determine whether the operation is being executed in the context where the standard deletion check has been suspended.

Currently, there is no supported way for an extension to obtain this state.

Without the requested getter, an extension would have to use one of the following approaches:

1. Maintain its own Boolean variable and attempt to keep it synchronized with the standard code.
2. Infer the state from other fields or execution context.
3. Duplicate part of the standard Business Central logic that determines when CalledFromHeader is set.
4. Request additional events solely to expose information that is already available internally in the table.

These approaches introduce unnecessary coupling to the current implementation of the standard application.

Providing a getter procedure allows extensions to consume the existing state directly and keeps the extension dependent on the supported public API rather than the internal implementation.

Extensibility considerations

This request follows the existing pattern already established by the SuspendDeletionCheck(Boolean) procedure.

The current procedure provides a mechanism for code to modify the state:

SuspendDeletionCheck(Suspend: Boolean)

The missing complementary operation is the ability to read that state:

SuspendDeletionCheck(): Boolean

Adding the getter would therefore provide a complete API for the state without exposing the underlying variable itself.

This is particularly useful for extensions because CalledFromHeader is an implementation variable and cannot be accessed directly from a Table Extension or external Codeunit.

Alternatives evaluated

The following alternatives were considered:

1. Maintain a separate Boolean variable in the extension

An extension could maintain its own Boolean variable and set it whenever it believes SuspendDeletionCheck(Boolean) has been called.

This is not reliable because the extension would need to reproduce the standard application's execution flow and ensure that its state remains synchronized with Microsoft's implementation.

Any future change to the standard logic could cause the extension's state to become inconsistent with CalledFromHeader.

2. Infer the value from the current execution context

An extension could attempt to determine whether deletion checks are suspended by examining other fields or the calling context.

This would couple the extension to assumptions about the current implementation rather than directly using the state that the standard application has already established.

There is also no guarantee that the same contextual conditions will continue to represent the CalledFromHeader state in future Business Central versions.

3. Add an integration event to expose the value

An event could be introduced to pass CalledFromHeader to subscribers.

However, an event is unnecessary for this requirement because the requested functionality is simply to retrieve an existing state value. A public getter procedure provides a smaller and more direct API and avoids introducing an additional event publisher that extensions would need to subscribe to.

4. Expose CalledFromHeader directly

Making the variable itself accessible would unnecessarily expose an implementation detail.

A getter procedure preserves encapsulation while providing extensions with the information they require.

Justification for the getter procedure

The requested procedure is required because the existing SuspendDeletionCheck(Boolean) procedure provides only the ability to set the runtime state.

An extension that needs to participate in subsequent standard or extension logic has no way to determine what value was set.

The parameterless overload:

procedure SuspendDeletionCheck() Suspend: Boolean
begin
    Suspend := CalledFromHeader;
end;

provides a read-only access pattern without changing the existing behavior or exposing the underlying variable.

This also avoids introducing an IsHandled pattern or additional event solely for exposing state.

The procedure does not make a decision on behalf of the caller. It simply returns the current value of CalledFromHeader, allowing the consuming extension to make its own decision.

Performance considerations

The requested procedure only reads a Boolean variable and returns its value.

It does not perform database operations, filtering, record traversal, or additional business logic.

The performance impact is therefore negligible.

The procedure would only execute when explicitly called by standard code or an extension.

Data sensitivity review

No external or sensitive data is exposed.

The procedure only returns the value of the existing internal Boolean variable CalledFromHeader.

No record data, customer data, user data, or other sensitive information is exposed by this change.

Multi-extension interaction

There is no multi-extension state-management concern introduced by this change.

The procedure is read-only:

procedure SuspendDeletionCheck() Suspend: Boolean

It does not modify CalledFromHeader and therefore cannot overwrite or interfere with the value established by standard code or another extension.

Multiple extensions can independently call the procedure and receive the current value of CalledFromHeader.

The existing setter procedure remains responsible for changing the state.

Breaking-change considerations

This is an additive change.

No existing procedure, variable, trigger, event, or behavior needs to be changed or removed.

The existing procedure:

procedure SuspendDeletionCheck(Suspend: Boolean)

continues to behave exactly as it does today.

The proposed parameterless overload simply adds a supported way for extensions to read the existing state.

Proposed implementation:

procedure SuspendDeletionCheck() Suspend: Boolean
begin
    Suspend := CalledFromHeader;
end;

This should be added alongside the existing procedure:

procedure SuspendDeletionCheck(Suspend: Boolean)
begin
    CalledFromHeader := Suspend;
end;

The two procedures would provide complementary setter/getter functionality for the existing CalledFromHeader runtime state.

Provide an implementation (optional)

• I will provide the implementation for this extensibility request