[Bug]: Italian FatturaPA routing incorrectly requires PA Code and does not derive CodiceDestinatario for PEC or foreign recipients

Describe the issue

In the Italian localization, FatturaPA validation currently requires Customer."PA Code" to be populated before an electronic invoice can be exported.

The validation includes:

ErrorMessage.LogIfEmpty(
    Customer,
    Customer.FieldNo("PA Code"),
    ErrorMessage."Message Type"::Error);

The exporter then writes that field directly as CodiceDestinatario:

TempXMLBuffer.AddNonEmptyElement(
    'CodiceDestinatario',
    Customer."PA Code");

if Customer."PA Code" = '0000000' then
    TempXMLBuffer.AddNonEmptyElement(
        'PECDestinatario',
        Customer."PEC E-Mail Address");

This makes the user responsible for manually entering FatturaPA routing constants into a field named PA Code, even in cases where Business Central already has enough information to derive the correct value.

For a domestic private recipient:

• if a valid recipient/SdI code is configured, that code should be used;
• if no recipient code is configured but a PEC address is available, CodiceDestinatario should be 0000000 and PECDestinatario should contain the PEC address;
• if neither recipient code nor PEC is available, CodiceDestinatario can still be 0000000.

Therefore, PA Code should not be unconditionally mandatory.

For a qualifying foreign recipient, the prescribed FatturaPA routing value is instead:

<CodiceDestinatario>XXXXXXX</CodiceDestinatario>

The current implementation does not derive this from the customer's foreign country. It simply exports the manually configured PA Code.

There is also a related foreign-recipient identification issue.

PopulateCustomerData currently emits IdFiscaleIVA only when a VAT Registration No. exists and the customer is not marked as an individual person:

if (Customer."VAT Registration No." <> '') and
   (not Customer."Individual Person")
then begin
    TempXMLBuffer.AddGroupElement('IdFiscaleIVA');
    TempXMLBuffer.AddNonEmptyElement(
        'IdPaese',
        Customer."Country/Region Code");
    TempXMLBuffer.AddNonEmptyLastElement(
        'IdCodice',
        Customer."VAT Registration No.");
end;

For foreign recipients, natural-person/legal-entity classification should determine whether Anagrafica is represented using Nome/Cognome or Denominazione; it should not by itself prevent the foreign fiscal-identification block from being produced when an appropriate foreign fiscal identifier is available.

The current behavior therefore conflates several independent concepts:

• recipient routing;
• PEC delivery;
• domestic vs. foreign recipient;
• natural person vs. legal entity;
• fiscal identification.

Expected behavior

FatturaPA routing should be derived according to the recipient's actual configuration rather than requiring a raw PA Code value in every case.

For domestic private recipients, the expected behavior should be approximately:

Valid configured recipient/SdI code:
    CodiceDestinatario = configured code

No recipient code + PEC available:
    CodiceDestinatario = 0000000
    PECDestinatario = configured PEC address

No recipient code + no PEC:
    CodiceDestinatario = 0000000

For qualifying foreign recipients:

CodiceDestinatario = XXXXXXX

The foreign recipient address and identification should also use the correct FatturaPA representation, including:

Nazione = ISO alpha-2 foreign country code
CAP = 00000

and, where an appropriate foreign fiscal identifier is available:

IdFiscaleIVA/IdPaese = ISO alpha-2 country code
IdFiscaleIVA/IdCodice = foreign fiscal/tax identifier

Whether a recipient is a natural person or a legal entity should independently control the Anagrafica representation (Nome/Cognome versus Denominazione) and should not incorrectly suppress required foreign fiscal identification.

It may not be appropriate for this issue to require introduction of a completely new generalized foreign-tax-identifier data model.

If existing Business Central fields cannot reliably represent all foreign fiscal identifiers, an extensibility point allowing extensions to provide the FatturaPA IdPaese/IdCodice values would also be an acceptable design.

Steps to reproduce

Scenario 1 - Domestic customer with PEC but no PA Code

1. Create or open an Italian private customer.
2. Leave PA Code empty.
3. Populate PEC E-Mail Address with a valid PEC address.
4. Create and post a sales invoice.
5. Attempt to generate the FatturaPA electronic invoice.

Business Central reports the empty PA Code as an error and prevents export.

The document could instead be generated with:

<CodiceDestinatario>0000000</CodiceDestinatario>
<PECDestinatario>customer@examplepec.it</PECDestinatario>

Scenario 2 - Domestic customer with neither recipient code nor PEC

1. Create or open an Italian private customer.
2. Leave both PA Code and PEC E-Mail Address empty.
3. Create and post a sales invoice.
4. Attempt to generate the FatturaPA electronic invoice.

Business Central prevents the export because PA Code is mandatory.

The FatturaPA routing value should instead be allowed to default to:

<CodiceDestinatario>0000000</CodiceDestinatario>

Scenario 3 - Foreign customer

1. Create a foreign customer with a non-Italian Country/Region.
2. Leave PA Code empty or enter a value other than the FatturaPA foreign-recipient constant.
3. Create and post a sales invoice.
4. Generate or attempt to generate the FatturaPA electronic invoice.

Business Central either rejects the empty PA Code or serializes the manually supplied value directly.

For a qualifying foreign recipient, the exporter should derive:

<CodiceDestinatario>XXXXXXX</CodiceDestinatario>

rather than requiring the user to know and manually enter this FatturaPA-specific constant.

Additional context

The relevant logic is primarily in:

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

and:

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

Fattura Doc. Helper currently treats Customer."PA Code" as an unconditionally mandatory field.

Export FatturaPA Document then serializes that value directly as CodiceDestinatario and emits PECDestinatario only when the user has manually set PA Code to 0000000.

The field caption PA Code is also misleading for this use. For private-sector electronic invoicing the value represents the recipient/SdI routing code and is not necessarily related to the Pubblica Amministrazione.

Renaming the existing field may have backward-compatibility implications and does not need to be a requirement of this issue, but the current naming reinforces the underlying usability problem: users are expected to understand and manually enter FatturaPA routing constants.

The exporter already contains some foreign-recipient-specific behavior, such as using CAP = 00000 for foreign addresses. Deriving the corresponding CodiceDestinatario = XXXXXXX routing behavior would make the implementation more consistent.

A separate issue has been opened for resolving Business Central Country/Region values to ISO alpha-2 codes, so this issue does not need to duplicate that implementation work.

For foreign fiscal identification, the standard fix should avoid assuming that every jurisdiction has a VAT-number concept equivalent to the Italian/EU model. If the existing master-data fields are insufficient for some jurisdictions, an extensibility event allowing an extension to supply the FatturaPA foreign fiscal identifier could provide a suitable fallback without requiring a larger global master-data redesign.

I will provide a fix for a bug

• I will provide a fix for a bug

Start by reading FatturaDocHelper.Codeunit.al and ExportFatturaPADocument.Codeunit.al, focusing on the PA Code validation, routing serialization, PEC handling, and PopulateCustomerData. Reproduce the three customer scenarios from the issue and inspect existing FatturaPA tests or export entry points; done means routing and foreign-recipient identification follow the documented cases without requiring a raw PA Code.