Fix #11377: Prevent invalid FatturaPA CAP values

[Marco Antonio Mauro (marcus905)]

What & why

The Italian FatturaPA exporter writes the Business Central Post Code directly to the CAP element for domestic addresses.

FatturaPA requires CAP to contain exactly five numeric characters, while the standard Business Central Post Code field is intentionally more general and is not restricted to that format. This means values such as 1234A can currently be accepted by Business Central and then emitted as schema-invalid FatturaPA XML.

This change adds FatturaPA-specific validation without changing the general-purpose Post Code field.

The change:

• validates the company Post Code before generating a FatturaPA document;
• validates the customer Post Code when the customer is domestic;
• requires domestic FatturaPA CAP values to contain exactly five numeric characters;
• preserves the existing foreign-recipient behavior, where FatturaPA emits 00000 instead of the foreign postal code;
• reports invalid values through the existing FatturaPA error-message validation flow rather than allowing schema-invalid XML to be generated.

Linked work

Fixes #11377

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 a domestic customer with an invalid CAP such as 1234A.

The test verifies that FatturaPA validation reports the invalid customer Post Code and prevents generation of the electronic document.

The localized Italian Base Application and test applications build successfully.

FatturaPA Test codeunit 144200 was executed locally:

• 46 tests total;
• 38 passed;
• the regression test added for [Bug]: Italian FatturaPA exporter can generate invalid CAP values from unconstrained Post Code fields #11377 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 existing test baseline.

Risk & compatibility

No standard field or table schema is changed.

The standard Post Code field remains unrestricted for normal Business Central use and international addresses. The five-digit numeric constraint is applied only by the FatturaPA validation logic when the value will be used as a domestic CAP.

Foreign-customer behavior is unchanged: the exporter continues to emit 00000 for the FatturaPA CAP element.

The XML serialization itself is unchanged for valid domestic post codes.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept with Suggestions

What this PR does

This change prevents domestic FatturaPA documents from using a CAP that is not exactly five numeric characters. It validates both the company and customer Post Code before export while preserving the existing 00000 value for foreign customers.

The validation matches the exporter’s domestic-address condition and runs through the existing error-message flow before XML generation. The shared helper correctly rejects values with the wrong length or nonnumeric characters, and the existing valid domestic and foreign behaviors remain unchanged.

Problem-solution fit

Fit: Strong

The change directly prevents malformed domestic CAP values from reaching the generated XML. Its scope is limited to FatturaPA validation and does not restrict the general-purpose Post Code fields.

Suggestions

S1 (🟠 Moderate): Cover invalid company CAP validation
Add a regression test that sets the Company Information Post Code to an invalid four- or six-digit value and verifies the Error Message flow. This covers the separate company branch and the exact-length rule.

Risk assessment and necessity

Risk: The production change is limited to pre-export validation in FatturaDocHelper.Codeunit.al. It changes no persisted data, public API, posting calculation, or foreign-customer behavior; the main remaining risk is that the separate company validation branch lacks direct regression coverage.

Necessity: The validation is required because malformed domestic CAP values otherwise produce schema-invalid FatturaPA XML. The scope is appropriate and uses the existing validation mechanism.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11660 round=1 by=alexei-dobriansky at=2026-09-21T13:22:26.7149789Z lastSha=0a56a80099c3c214c7cd71845cb5728073b60785 reviewKey=fbab43ede547fec37928b0d21538bf86650344e6b19fe675cc9a224af66e8052 suggestions=S1@99a1f180