Resolve purchase lines to items on exact description match

[Jatin Kumar (Explorer986)]

What & why

Inbound invoice lines were falling through to G/L account matching even when an item with the exact same description already existed. The line was posted to a G/L account instead of the item.

This PR adds a deterministic step that resolves the line to the item when there is exactly one eligible item with that description. It runs after item reference and text-to-account mapping, so no impact on explicit setup.

Fixes AB#647171

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome

Imported a sample invoice with a line whose description exactly matches an existing item. Before the change it resolved to a G/L account, after the change it resolves to the item.

Risk & compatibility

Matching only triggers when exactly one non blocked item matches and the unit of measure fits, so ambiguous cases keep the old behavior. No schema or upgrade impact.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new tests prove Text-to-Account Mapping takes precedence over the description match, but nothing proves that an Item Reference match still wins over the new description-match fallback when both would resolve the line. Add a regression test combining both signals to protect the resolution order (Item Reference > Text-to-Account Mapping > description match) against future reordering.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.35.4}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

The new tests hand-insert EDocumentPurchaseLine fixtures with bare Insert() calls instead of using the existing LibraryEDoc.InsertPurchaseDraftLine(EDocument) helper (variable of codeunit "Library - E-Document", already used pervasively elsewhere, e.g. EDocPOMatchingUnitTests.Codeunit.al). That bypasses the app's own fixture path for assigning line numbers/defaults and creates line-0 draft rows that can drift from production behavior as the draft schema evolves; the same pattern is repeated across the other new tests (PreparingPurchaseDraftFindsItemByExactDescription, PurchaseLineProviderDoesNotMatchDuplicateItemDescriptions, PurchaseLineProviderDoesNotMatchPurchasingBlockedItem).

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

EDocumentPurchaseLine := LibraryEDoc.InsertPurchaseDraftLine(EDocument);
EDocumentPurchaseLine.Description := Item.Description;
EDocumentPurchaseLine.Modify();

Knowledge:

• microsoft/knowledge/testing/use-library-codeunits-for-test-fixtures.md

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.35.4}

[Joshua (mynjj)]

Please be aware that after this PR: #7546

This fix will no longer be applicable