[FR E-Reporting] Implement invoice payment lifecycle tracking

[Milica Đukić (djukicmilica)]

Why

French e-reporting regulation requires that when a payment is applied to an e-invoice, the Collected lifecycle status must be captured and reported to the Portail Public de Facturation (PPF). Currently, the EReporting FR app has no mechanism to track payment applications against e-invoices or to build the required XML lifecycle messages. This gap blocks compliance with the French e-invoicing mandate.

Summary

• Added FR E-Invoice Lifecycle table to capture immutable lifecycle occurrences (payment applications, reversals) linked to e-documents and customer ledger entries
• Added FR E-Invoice Lifecycle VAT table to store per-occurrence VAT breakdown lines with amounts and currency
• Added FR E-Invoice Lifecycle Mgt. codeunit that subscribes to OnAfterInsertDtldCustLedgEntry and OnAfterInsertDtldCustLedgEntryUnapply to automatically capture payment lifecycle events
• Added FR E-Invoice Lifecycle Msg. codeunit implementing IEDocMessageBuilder to produce CrossDomainAcknowledgementAndResponse XML messages per the French regulatory profile
• Added FR E-Invoice Lifecycle Error and FR E-Invoice Lifecycle Worker codeunits for asynchronous processing with error handling
• Added enums for lifecycle status (Deposited, Collected, PaymentCollected, etc.) and processing status (Queued, Sending, Sent, Failed)
• Added page extensions on E-Document Service and E-Documents list to surface lifecycle configuration and navigation
• Added FR E-Invoice Lifecycles list page for viewing captured occurrences
• Added permission sets (EReportingFRObjects, EReportingFREdit, EReportingFRRead) and D365/Local permission set extensions
• Added comprehensive tests covering payment application capture, reversal handling, VAT breakdown, and message building

Fixes
AB#637593

[github-actions]

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

The pageextension declares a namespace but still adds unaffixed members to the base "E-Documents" page: field("Clearance Date"; ...) and action(ViewFREInvoiceLifecycles). A namespace only replaces the owned-object affix; members added to another publisher's page still need the registered app prefix or suffix, otherwise AppSourceCop AS0011 can reject the extension.

Knowledge:

• microsoft/knowledge/appsource/two-level-namespace-replaces-object-affix-not-extension-member-affix.md

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

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

[Milica Đukić (djukicmilica)]

Follow-up on the general review findings:

• The Clearance Date tooltip is restored, and the new lifecycle action uses the FR-affixed control name. The pre-existing Clearance Date control name is retained to avoid changing an existing control identity.
• Exact negative-test messages are intentional contract assertions; moving identical strings to labels would not reduce brittleness.
• A PDF without embedded Factur-X data now raises the dedicated NoEmbeddedInvoiceErr, and malformed French Peppol post-processing raises an internal contextual ErrorInfo.
• Lifecycle worker call-stack telemetry now uses TelemetryScope::ExtensionPublisher so implementation details remain publisher-only.
• A real PDF/A-3 happy-path test remains unavailable because the repository contains no approved embedded-invoice PDF fixture or generator; a synthetic non-PDF blob would not exercise the production attachment path.

[github-actions]

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

InsertAllowanceElement and InsertLineAllowanceElement declare AllowanceReasonLbl and LineDiscountLbl inside procedure-local var blocks. Per the referenced guidance, Labels should live in the codeunit's top-level var block so XLIFF extraction and translation keys remain stable across builds and review tooling.

Knowledge:

• microsoft/knowledge/style/labels-declared-at-object-scope.md

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

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

[github-actions]

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

The new negative import tests verify asserterror, but they pin Assert.ExpectedError to inline message text (for example at the unsupported-root-element case) instead of a shared label or assert helper. That makes the tests brittle to harmless wording/localization changes rather than to the actual validation behavior.

Knowledge:

• microsoft/knowledge/testing/asserterror-needs-expectederror-and-code.md

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

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

[Milica Đukić (djukicmilica)]

Superseded by #10374, which contains this payment lifecycle implementation together with lifecycle message sending in a single PR targeting main.