[28.5] [W1 E-Document] Fix item charge mapping for electronic documents

[Milica Đukić (djukicmilica)]

Why

Item charges exported as synthetic invoice lines can carry an empty or invalid unit code on BT-130, causing EN16931 BR-23 / BR-CL-23 validation failures.

This is the W1 E-Document portion of the releases/28.5 backport of #9860. The German E-Document portion is in NAV PR 253761.

Summary

• Added configurable item-charge mapping to document-level, line-level, or fallback invoice-line structures.
• Updated E-Document service setup and permissions for item-charge mapping.
• Added regression coverage for W1 item-charge classification and setup scenarios.

Fixes
AB#649141

[github-actions]

Could not find linked issues in the pull request description. Please make sure the pull request description contains a line that contains 'Fixes #' followed by the issue number being fixed. Use that pattern for every issue you want to link.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept with Suggestions

What this PR does

This change adds a reusable classification for how a posted sales item charge is represented when a document is exported as an e-invoice: as a document-level allowance/charge, a line-level allowance/charge, or a separate invoice line with a unit code. It also adds a per-service default, a per-item-charge override, and a fallback unit code (C62) so a charge exported as an invoice line always carries a valid unit code.

The classification logic is sound. The "Automatic" path only groups a charge onto an assigned line when there is exactly one assigned line and its VAT category and rate match; otherwise it falls back to a document-level allowance/charge. The code also guards the case where the charge is the only line, exporting it as an invoice line so the document is never left without a document line. The fallback unit price uses Abs(amount) with a signed quantity, so the exported line total stays correct and the price is never negative (BR-27). The new codeunit has no production caller in this app yet - it is exercised by the tests and consumed by format-specific extensions - which is the intended shape for shared infrastructure.

Problem-solution fit

Fit: Strong

The reported problem is that item charges exported as invoice lines could carry an empty or invalid unit code and fail EN16931 BR-23 / BR-CL-23 validation. The change fixes this directly by defaulting the exported unit code to C62 and by giving each charge a controlled representation, and it adds broad regression coverage for the classification. This is a maintenance-branch backport of a change already made on the main branch, so the scope matches the original fix.

Suggestions

S1 (🟡 Minor): Value-entry lookup does not filter by document type
CollectDocumentLineNosByItemLedgerEntry filters Value Entry by Document No. only, and its per-document cache is keyed on Document No. alone. Item ledger entry numbers are unique, so the result stays correct, but a posted invoice and credit memo that share a document number would build one larger mixed map. Adding the document type to the filter and the cache key would keep the lookup tight and easier to read.

Risk assessment and necessity

Risk: The change is additive. The new fields on Item Charge and E-Document Service are hidden by default, and the classification codeunit has no production caller in this app, so existing e-document exports are unaffected until a format extension opts in. The two new integration events are raised last and let partners override the structure, so the extensibility surface is safe. Both mapping enums are extensible; an override value the built-in classification does not recognize falls back to the service setting, which is documented.

Necessity: The change is needed to make item-charge e-invoice export standards-compliant (BR-23 / BR-CL-23). Backporting it to the maintenance branch is appropriate so affected customers on this version get the fix. The change is larger than a one-line fix because it introduces the reusable classification the compliant export needs, but it is well contained and covered by matching tests.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11103 round=1 by=alexei-dobriansky at=2026-09-06T22:21:48Z lastSha=3a2e626dc46b49e32fbd4f1ec5934691dc524891 reviewKey=21fb233d75f14c5e553b842f3c807abc24ed4436f59188d2c5a791e46b819a9b suggestions=S1@c70589af