microsoft / microsoft/BCApps

[Bug]: Italian FatturaPA exporter can generate invalid Provincia values from unconstrained County fields

Open
#11,389 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Approved Team: Finance
Dominant language
AL
Stars
683
Forks
459
Avg merge
3d 26m
Merged PRs (30d)
633

Description

Describe the issue

In the Italian localization, the FatturaPA exporter writes the Business Central County field directly into the Provincia element.

For example, the exporter effectively does:

TempXMLBuffer.AddNonEmptyElement(
    'Provincia',
    CompanyInformation.County);

and similarly for customers.

However, the FatturaPA schema requires Provincia to contain exactly two uppercase alphabetic characters representing the Italian province code.

The standard Business Central County field is not constrained to that format. It can contain values such as:

Milano

which are valid general-purpose BC address values but are not valid FatturaPA Provincia values.

The current FatturaPA validation does not enforce the required two-character province code before export.

As a result, Business Central can generate XML such as:

<Provincia>Milano</Provincia>

which is not valid according to the FatturaPA schema.

Expected behavior

Business Central should ensure that any value emitted in the FatturaPA Provincia element satisfies the FatturaPA schema requirements.

For Italian addresses, the exporter should use a valid two-character Italian province code and should prevent generation of XML containing arbitrary County values.

The general-purpose County field should not necessarily be globally restricted, because it is used outside the FatturaPA context and for international addresses.

The validation or export logic should instead apply the FatturaPA-specific constraint when generating an Italian electronic invoice.

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

  2. Enter a value in County that is not a valid two-character Italian province code, for example:

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

  4. Generate/export the electronic invoice.

  5. Inspect the generated XML.

Business Central emits the value directly, for example:

<Provincia>Milano</Provincia>

The FatturaPA document is generated even though the value does not satisfy the schema requirement for Provincia.

Additional context

The issue is in the Italian FatturaPA exporter, primarily in:

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

The exporter serializes the standard Business Central County field directly into the FatturaPA Provincia element.

This is especially inconsistent with other parts of the Italian localization where province-related data is already modeled explicitly as a two-character code. For example, Company Information."Registry Office Province" is defined as Code[2].

A FatturaPA-specific mapping or validation for Provincia would prevent schema-invalid XML while preserving the general-purpose semantics of the standard County field.

I will provide a fix for a bug
  • I will provide a fix for a bug

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/Layers/IT/BaseApp/Local/EServices/EDocument/ExportFatturaPADocument.Codeunit.al and trace where Company Information and customer County values are written to the FatturaPA Provincia element. Review the existing Registry Office Province Code[2] field for relevant context. Done means invalid arbitrary County values cannot produce schema-invalid Provincia XML while the general County field remains unrestricted.

Written by the indexing model from the issue text.

Assessment

Domain
backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.