microsoft / microsoft/BCApps

[Bug]: Pay-to Name 2 is editable on other conditions than all other Pay-to fields

Open
#9,097 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Approved Team: SCM
Dominant language
AL
Stars
683
Forks
459
Avg merge
3d 26m
Merged PRs (30d)
633

Description

Describe the issue

This is the purchase-side counterpart of #8312.

On the Purchase Quote, Purchase Order, and Purchase Invoice pages, the field "Pay-to Name 2" is only editable when the Pay-to option is "Another Vendor":

Editable = PayToOptions = PayToOptions::"Another Vendor";
Enabled = PayToOptions = PayToOptions::"Another Vendor";

Every other field in the pay-to address group (Address, Address 2, City, County, Post Code, Country/Region Code, Contact No., Contact) uses:

Editable = (PayToOptions = PayToOptions::"Custom Address") or (Rec."Buy-from Vendor No." <> Rec."Pay-to Vendor No.");

So with "Custom Address" selected, the whole pay-to address group can be filled in except "Pay-to Name 2". Like its sales counterpart, the field appears to have been missed when the PayToOptions editability logic was applied to the pay-to address group. "Pay-to Name 2" on the Purchase Header is a plain text field with no validation logic and no table relation.

The Blanket Purchase Order, Purchase Credit Memo, and Purchase Return Order pages have no PayToOptions-based conditions on this field and are not part of this issue.

Expected behavior

When selecting "Custom Address" in the Pay-to section of a purchase document, the "Pay-to Name 2" field should be editable under the same conditions as all other pay-to address fields.

Steps to reproduce
  1. Create a purchase document (e.g. Purchase Order)
  2. Select "Pay-to" -> "Custom Address"
  3. Try to enter a different Pay-to Name 2
Additional context

The sales side is being fixed in #9096. The same correction can be applied here: give "Pay-to Name 2" the same Editable and Enabled expression as its sibling fields on the three affected pages, propagate to the localization layers that carry copies of these pages, and extend the existing CustomAddressPayToOption tests.

I will provide a fix for a bug
  • I will provide a fix for a bug

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Purchase Quote, Purchase Order, and Purchase Invoice page definitions and compare the Pay-to Name 2 conditions with the sibling pay-to address fields. Check the localization layers that carry copies of these pages, then extend the existing CustomAddressPayToOption tests. Done means Pay-to Name 2 is editable and enabled for Custom Address under the same conditions as the other pay-to address fields, without changing the excluded document pages.

Written by the indexing model from the issue text.

Assessment

Domain
frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.