[PA][Pioneer]: Numeric line fields mis-extracted (discount, quantity, unit of measure)

[Explorer986]

What & why

When a scanned invoice line has no quantity or a zero line total, the importer used to force the quantity to 1 and invent a discount from the price. That created phantom lines and wrong discounts. Now we keep a genuine zero quantity, only derive quantity from total over price when it makes sense, and never fabricate a discount. Unresolved units like HUR now carry through to the BC unit of measure field instead of showing blank.

Linked work

Fixes AB#642334

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 the Spanish invoice in CRONUS ES. The zero hour lines now show quantity 0 instead of 1, and the Docencia line shows 50 as on the document.
• Confirmed no discount is invented when the line total already matches price times quantity.

Risk & compatibility

The unresolved unit fallback puts the raw code like HUR straight into the BC unit of measure field in View Extracted Data Page.

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Agent}$

PopulateEDocumentPurchaseLine now only records Total Discount when the derived value (Unit Price * Quantity) - Sub Total is positive; a negative DerivedDiscount (i.e., Sub Total exceeds Unit Price * Quantity — a surcharge, rounding difference, or extraction inconsistency) is silently discarded and Total Discount stays 0. Previously the raw discrepancy (positive or negative) was always recorded. Dropping negative discrepancies means the line's Unit Price * Quantity - Total Discount will no longer reconcile with the extracted Sub Total whenever the document shows a surcharge or a negative variance, which can cause downstream amount mismatches (e.g., document-total validation, purchase line totals not tying to the imported invoice) that are hard to diagnose because the information was silently dropped rather than surfaced. Consider still capturing the full discrepancy (e.g., in a dedicated field, or via telemetry/log) rather than dropping it, or clamping only for display while preserving reconciliation elsewhere.

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

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

[github-actions]

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

Both EDocMLLMSchemaHelper.MapLinesFromJson and EDocumentADIHandler.PopulateEDocumentPurchaseLine previously defaulted an unusable quantity (<= 0) to 1. The new logic instead clamps negative quantities to 0 and only derives a quantity from Sub Total / Unit Price when both Unit Price and Sub Total are non-zero. If the extracted document has Quantity = 0 (or negative) together with Unit Price = 0 or Sub Total = 0 — plausible for OCR/LLM-extracted invoice data with missing fields — the line is now inserted with Quantity = 0 instead of the previous safe default of 1. A zero-quantity purchase line is atypical downstream (unit-cost/unit-price back-calculations elsewhere in the purchasing pipeline, or posting validations expecting a non-zero quantity) and can surface as a confusing error or a silently wrong line far from this code. Consider retaining a final fallback (e.g., default to 1) when quantity is still 0 after the derivation attempt, matching the safeguard this change removed.

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

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