Fix #11371: Prevent invalid FatturaPA RegimeFiscale values

[Marco Antonio Mauro (marcus905)]

What & why

The Italian FatturaPA exporter builds RegimeFiscale by prefixing Company Information."Company Type" with RF, but the current company type setup allows values that are not valid FatturaPA fiscal regimes. This can result in invalid XML such as RF99.

This change makes the existing company type model explicitly represent the FatturaPA fiscal regime while preserving the existing field, table, and object IDs for compatibility.

The change:

• exposes Company Information."Company Type" as FatturaPA Fiscal Regime;
• uses the existing "Company Types" table as a fixed, read-only catalog of the supported 01-19 FatturaPA fiscal regimes;
• initializes the standard fiscal-regime catalog for new companies and existing companies during upgrade;
• keeps catalog initialization idempotent, restoring missing standard entries and standard descriptions without deleting non-standard legacy rows;
• validates the selected value on Company Information;
• validates the value again during FatturaPA document validation so legacy or bypassed invalid data cannot generate invalid XML;
• keeps the existing serialization behavior, so for example fiscal regime 19 is exported as RF19;
• reuses the same production catalog from demo data and test helpers instead of maintaining a separate list.

Linked work

Fixes #11371

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

Added regression coverage in FatturaPATest.Codeunit.al for the following scenarios:

• initialization creates all 19 supported FatturaPA fiscal regimes (01 through 19);
• initialization repairs standard descriptions while preserving non-standard legacy rows;
• the standard fiscal-regime catalog rejects insert, modify, and delete operations;
• unsupported values such as 99 are rejected;
• fiscal regime 19 is exported as RF19;
• an invalid legacy value stored directly in Company Information."Company Type" is detected during FatturaPA validation and cannot generate invalid RegimeFiscale XML.

The test library was also updated to select values from the standard fiscal-regime catalog instead of creating arbitrary company type codes.

The localized Italian Base Application and test applications build successfully.

FatturaPA Test codeunit 144200 was executed locally:

• 50 tests total;
• 42 passed;
• all five regression tests added for [Bug]: Italian FatturaPA export can generate invalid RegimeFiscale values from unvalidated Company Type #11371 passed;
• 8 existing tests fail in Library - Error Message.LoadErrorMessages because TestPage field ID 2074815070 is not present on page Error Messages. These failures are unrelated to the changes in this PR and are unchanged from the pre-existing test baseline.

Risk & compatibility

The existing Company Information."Company Type" field remains Code[2], and the existing "Company Types" table, field IDs, and object IDs are retained, so no field-type or data-schema migration is introduced.

The "Company Types" table now represents fixed FatturaPA reference data rather than user-defined setup data. Standard 01-19 entries are initialized for new companies and during upgrade for existing companies.

Existing non-standard rows are not deleted during upgrade to avoid destructive data changes. They are excluded from the normal lookup, cannot be selected as a valid FatturaPA fiscal regime, and are rejected by FatturaPA validation if referenced by legacy or bypassed data.

The exporter itself retains its existing RF + fiscal-regime-code serialization once the value has passed validation.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept

What this PR does

This change makes the Italian FatturaPA fiscal regime a fixed setup catalog, uses that catalog for company setup, and validates the value again before export. The approach addresses both the setup problem and the export backstop while keeping the stored field and existing object IDs stable.

Problem-solution fit

Fit: Strong

The reported problem is that invalid fiscal-regime values can reach the generated XML. The change prevents invalid selection, restores the standard catalog during setup and upgrade, and still blocks legacy or bypassed invalid values during validation.

Suggestions

No suggestions.

Risk assessment and necessity

Risk: The change affects Italian FatturaPA setup, upgrade initialization, and document validation. Compatibility risk is limited because the existing table, field, and object IDs remain in place, and non-standard legacy rows are not deleted.

Necessity: The change is necessary because the exporter must not generate fiscal-regime values outside the allowed set. The scope is appropriate because it fixes setup clarity, seeds supported values, and validates again before XML generation.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11633 round=1 by=alexei-dobriansky at=2026-09-20T13:18:03Z lastSha=75b6a65e58fe290368fd3211a20dc2802b9587be reviewKey=984239ca37db549353708922cb04b920adc58b2ef9273fbf59db1b79aae7a6b7 suggestions=