[Bug]: Italian FatturaPA exporter can generate invalid CAP values from unconstrained Post Code fields

Describe the issue

In the Italian localization, the FatturaPA exporter writes the company/customer Post Code directly into the CAP element for domestic addresses.

The current behavior is effectively:

TempXMLBuffer.AddNonEmptyElement(
    'CAP',
    CompanyInformation."Post Code");

and, for customers:

if Customer."Country/Region Code" <> CompanyInformation."Country/Region Code" then
    TempXMLBuffer.AddNonEmptyElement('CAP', '00000')
else
    TempXMLBuffer.AddNonEmptyElement('CAP', Customer."Post Code");

The FatturaPA schema requires CAP to contain exactly five numeric characters.

The standard Business Central Post Code fields are not restricted to that format, and the FatturaPA validation currently checks only that the value is populated, not that it satisfies the XSD constraint.

As a result, values such as:

1234A

or post codes with more or fewer than five characters can be accepted by Business Central and then emitted directly into the FatturaPA XML, resulting in schema-invalid output.

Expected behavior

For Italian addresses, Business Central should ensure that the value emitted in the FatturaPA CAP element complies with the schema requirement of exactly five numeric characters.

The standard Post Code field itself should not necessarily be globally restricted, because it is used for international addresses and other Business Central functionality.

Instead, the FatturaPA validation/export logic should validate the domestic Italian CAP value before generating the XML and prevent creation of a schema-invalid document.

For foreign recipients, the existing FatturaPA-specific behavior of emitting:

<CAP>00000</CAP>

can remain as appropriate.

Steps to reproduce

1. Open Company Information or an Italian customer in an Italian Business Central company.

2. Set the relevant Post Code to a value that does not satisfy the FatturaPA CAP constraint, for example:

   1234A
   

3. Create and post a sales invoice for a customer configured for FatturaPA.

4. Generate/export the electronic invoice.

5. Inspect the generated XML.

For a domestic address, Business Central emits the invalid value directly, for example:

<CAP>1234A</CAP>

The FatturaPA export is generated even though the value does not match the required five-digit CAP format.

Additional context

The issue is in the Italian FatturaPA export/validation logic, primarily in:

src/Layers/IT/BaseApp/Local/EServices/EDocument/ExportFatturaPADocument.Codeunit.al

and in the validation performed by:

src/Layers/IT/BaseApp/Local/EServices/EDocument/FatturaDocHelper.Codeunit.al

The current validation verifies that Post Code is populated but does not validate the FatturaPA-specific format before export.

The exporter already contains explicit schema-aware transformations for other fields and also already handles foreign addresses specially by emitting 00000.

Adding a FatturaPA-specific domestic CAP validation would make the behavior consistent and prevent schema-invalid XML from being generated.

I will provide a fix for a bug

• I will provide a fix for a bug

Start with src/Layers/IT/BaseApp/Local/EServices/EDocument/ExportFatturaPADocument.Codeunit.al and FatturaDocHelper.Codeunit.al, tracing the domestic company and customer CAP paths and their existing validation. Confirm how foreign recipients retain the 00000 behavior. Done means invalid domestic Post Code values are rejected before export and valid domestic CAP values can still be emitted.