[Bug]: [Subscription Billing] Page 8002 "Extend Contract" — Move key page variables to `protected var` to enable partner extensions via PageExtension

[pamura1977]

Describe the issue

Page 8002 "Extend Contract" currently exposes only a limited set of variables in its
protected var section, which was recently extended to include ItemNo, VariantCode,
QuantityDecimal, ExtendCustomerContract, ExtendVendorContract, and SellToCustomerNo.
However, several additional variables that partner extensions need to read or write remain
in the global (unprotected) var block and are therefore inaccessible from a PageExtension.

This prevents partners from implementing key automation scenarios on top of the standard
"Extend Contract" flow without having to clone the entire page — which in turn is blocked
by the internal procedures already addressed in issue #8385 / pull request #8387.

The following variables should be moved from the global var block to protected var:

---

1. CustomerContractNo: Code[20]

Why needed: A PageExtension needs to pre-populate the customer contract number based
on context from the calling page (e.g. a usage data import line that already contains a
resolved contract ID). Without protected var access, the value cannot be set from a
PageExtension after the page is opened.

---

2. VendorContractNo: Code[20]

Why needed: When the "Extend Contract" page is opened from a customer subscription
contract that has a linked vendor contract, a PageExtension should automatically pre-fill
the vendor contract number. This is not possible as long as VendorContractNo remains in
the unprotected var block.

---

3. SubscriptionDescription: Text[100]

Why needed: When a user selects an item variant on the "Extend Contract" page, the
subscription description should be updated to reflect the variant's description. A
PageExtension cannot write to SubscriptionDescription to implement this behaviour
because the variable is not in protected var.

---

4. ItemDescription: Text[100]

Why needed: Closely related to SubscriptionDescription — a PageExtension needs to
update the item description when the variant code changes. Currently inaccessible for
the same reason.

---

5. UnitPrice: Decimal

Why needed: Partner extensions that derive the unit price from an external source
(e.g. a vendor invoice line or a distributor price list) need to write the resolved
price into UnitPrice before the contract extension is executed. This is not possible
without protected var access.

---

6. UnitCostLCY: Decimal

Why needed: Same as UnitPrice — the unit cost in LCY needs to be settable from a
PageExtension to support scenarios where cost data is available from an upstream record
(e.g. a purchase invoice line matched to a vendor subscription contract).

---

7. ProvisionStartDate: Date

Why needed: When the "Extend Contract" page is opened programmatically from an
automation extension (e.g. a usage data import batch), the provision start date is
already known from the import record. A PageExtension should be able to set this date
directly. Currently only settable via SetParameters(), which requires the page to be
called in a specific way — a PageExtension on OnOpenPage cannot override it.

---

Current state (BC 28-vNext / BC 29-vNext)

The protected var section currently contains:

protected var
    ItemNo: Code[20];
    VariantCode: Code[10];
    QuantityDecimal: Decimal;
    ExtendCustomerContract: Boolean;
    ExtendVendorContract: Boolean;
    SellToCustomerNo: Code[20];

The seven variables listed above remain in the unprotected global var block.

Expected behavior

The seven variables are moved to the protected var section, making them writable
from PageExtensions:

protected var
    ItemNo: Code[20];
    VariantCode: Code[10];
    QuantityDecimal: Decimal;
    ExtendCustomerContract: Boolean;
    ExtendVendorContract: Boolean;
    SellToCustomerNo: Code[20];
    CustomerContractNo: Code[20];
    VendorContractNo: Code[20];
    SubscriptionDescription: Text[100];
    ItemDescription: Text[100];
    UnitPrice: Decimal;
    UnitCostLCY: Decimal;
    ProvisionStartDate: Date;

Steps to reproduce

Create a PageExtension on Page 8002 "Extend Contract" and attempt to assign a value to
any of the listed variables (e.g. CustomerContractNo := 'CC10000';). Result: AL0132
compiler error — "CC10000 is not accessible".

Additional context

This request is related to issue #8385 and pull request #8387, which addressed inaccessible
internal procedures on the same page. Together, these changes would allow partners to
build automation extensions on top of the standard "Extend Contract" flow without cloning
the page.

I will provide a fix for a bug

• I will provide a fix for a bug

[JesperSchulz]

🤖 AI triage completed. Product group, please validate the triage report (Microsoft internal access only, use Ctrl+Click to open in new tab).

---

_{Was this triage helpful? React with 👍 or 👎 on this comment to provide feedback.}

Additional finding: protected var alone is not sufficient

We analysed the page in more detail and found that moving the variables to protected var
solves only half of the problem. We would like to propose a refinement.

The problem

A PageExtension always runs after the base page trigger. This means that if an extension
assigns a value to a protected variable in OnOpenPage, the validation chain in the base
page has already completed:

trigger OnOpenPage()
begin
    IsLookupMode := CurrPage.LookupMode;

    SetGlobalsFromParameters();

    if ItemNo <> '' then
        if not Item.Get(ItemNo) then begin
            Clear(ItemNo);
            Clear(ItemDescription);
        end;
    if CustomerContractNo <> '' then
        if not CustomerContract.Get(CustomerContractNo) then
            Clear(CustomerContractNo);
    if VendorContractNo <> '' then
        if not VendorContract.Get(VendorContractNo) then
            Clear(VendorContractNo);

    FillTempServiceCommitmentPackage();
    ValidateExtendCustomerContract();
    ValidateExtendVendorContract();
    ValidateItemNo();
    ValidateUsageSupplierNo();
    ValidateSubscriptionEntryNo();

    CountTotalServiceCommitmentPackage();
    CurrPage.Update();
end;

As a result, values set from a PageExtension would appear in the fields, but the dependent
data would remain empty: item description, unit price, unit cost, subscription packages,
and the vendor/customer names. The user would have to re-enter each field manually to
trigger validation, which defeats the purpose of the automation.

The good news

The validation chain above already handles all the values we need. OnOpenPage loads
the item, the customer contract and the vendor contract, and calls ValidateItemNo() and
ValidateExtendVendorContract(). The infrastructure is complete, but missing is a public entry
point to supply the values before the page opens.

Proposal: Follow the existing SetUsageBasedParameters pattern

Page 8002 already establishes this pattern: rather than extending SetParameters(),
a second, separate setter was added for the usage-based path. We propose adding two more
setters in exactly the same style, which is purely additive and does not change any
existing signature:

procedure SetVendorContractParameters(NewExtendVendorContract: Boolean; NewVendorContractNo: Code[20])
begin
    ExtendVendorContractParam := NewExtendVendorContract;
    VendorContractNoParam := NewVendorContractNo;
end;

procedure SetItemParameters(NewItemNo: Code[20]; NewVariantCode: Code[10]; NewQuantity: Decimal)
begin
    ItemNoParam := NewItemNo;
    VariantCodeParam := NewVariantCode;
    QuantityParam := NewQuantity;
end;

With the corresponding assignments in SetGlobalsFromParameters():

local procedure SetGlobalsFromParameters()
begin
    SellToCustomerNo := SellToCustomerNoParam;
    CustomerContractNo := CustomerContractNoParam;
    ProvisionStartDate := ProvisionStartDateParam;
    ExtendCustomerContract := ExtendCustomerContractParam;
    UsageDataSupplierNo := UsageDataSupplierNoParam;
    SubscriptionEntryNo := SubscriptionEntryNoParam;
    ExtendVendorContract := ExtendVendorContractParam;
    VendorContractNo := VendorContractNoParam;
    ItemNo := ItemNoParam;
    QuantityDecimal := QuantityParam;
end;

No existing signature is modified, no existing caller is affected, and the values flow
through the complete validation chain that is already in place.

One special case: The variant code

ValidateItemNo() deliberately clears the variant code at the end:

    ShowNotificationIfStandardSubscriptionPackageDoesNotContainUBBLine(ItemNo);
    VariantCode := '';
    OnAfterValidateItemNo(ItemNo);
end;

This is correct for manual entry, changing the item should reset the variant. For a
programmatic call it would discard the supplied value, so the variant code needs to be
assigned after the validation chain. We suggest adding one statement at the end of
OnOpenPage:

    CountTotalServiceCommitmentPackage();

    if VariantCodeParam <> '' then
        VariantCode := VariantCodeParam;

    CurrPage.Update();
end;

The guard keeps the existing behaviour unchanged whenever no parameter is supplied.

[pamura1977]

The comment above from the now-deleted "ghost" account was posted by me — I previously had a second GitHub account (pamura77) without realizing it, and have since deleted it. Please treat that proposal as coming from pamura1977 (this account). Apologies for the confusion.