[Bug]: Italian FatturaPA exporter does not enforce Telefono and Fax XSD length constraints
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- xml
- Domain
- backend, localization
Research direction
Open src/Layers/IT/BaseApp/Local/EServices/EDocument/ExportFatturaPADocument.Codeunit.al and inspect PopulateCompanyInformation, especially the Telefono and Fax serialization. Reproduce with phone and fax values shorter than 5 or longer than 12 characters, then validate the generated FatturaPA XML against the XSD. Done means emitted values comply with TelFaxType or non-compliant optional elements are omitted with the intended warning behavior.
Written by the indexing model from the issue text.
Description
Describe the issue
In the Italian localization, the FatturaPA exporter writes the company phone and fax numbers directly into the Telefono and Fax XML elements after only removing hyphens.
The current implementation is effectively:
TempXMLBuffer.AddNonEmptyElement(
'Telefono',
DelChr(CompanyInformation."Phone No.", '=', '-'));
TempXMLBuffer.AddNonEmptyElement(
'Fax',
DelChr(CompanyInformation."Fax No.", '=', '-'));
However, the FatturaPA XSD defines both Telefono and Fax using TelFaxType, which has a minimum length of 5 characters and a maximum length of 12 characters.
Business Central's source fields can contain values outside this range. The exporter does not validate or constrain them before serializing the XML.
As a result, Business Central can generate a FatturaPA document that is not valid against the official schema.
For example, entering a 13-character phone number results in the full 13-character value being written to <Telefono>, making the XML schema-invalid.
The same issue applies to Fax.
Expected behavior
Business Central should ensure that values emitted in the FatturaPA Telefono and Fax elements comply with the TelFaxType constraints defined by the FatturaPA XSD.
The exporter should not generate XML containing values shorter than 5 characters or longer than 12 characters.
The exact handling can be decided by the implementation, for example by validating the value before export or by applying schema-aware normalization/truncation where appropriate, or still, since both fields are not mandatory according to the XSD specification, emitting a warning when not compliant and stopping the serializer from adding the Telefono or Fax elements to the XML.
The standard Company Information phone and fax fields should not necessarily be restricted globally, because they are used outside the FatturaPA context. The FatturaPA-specific export logic should instead ensure that the serialized XML is compliant with the schema, if emitted.
Steps to reproduce
-
Open Company Information in an Italian Business Central company.
-
Enter a phone number longer than 12 characters, for example:
1234567890123 -
Create and post a sales invoice for a customer configured for FatturaPA.
-
Generate/export the electronic invoice.
-
Inspect the generated XML.
The exporter writes:
<Telefono>1234567890123</Telefono>
The value exceeds the maximum length allowed by the FatturaPA XSD.
The same behavior can be reproduced with the Fax No. field.
A value shorter than 5 characters can similarly be emitted even though it also violates TelFaxType.
Additional context
The issue is in the Italian FatturaPA export implementation, currently in:
src/Layers/IT/BaseApp/Local/EServices/EDocument/ExportFatturaPADocument.Codeunit.al
The relevant code is in PopulateCompanyInformation, where Telefono and Fax are emitted using the Company Information fields with only hyphens removed.
Other parts of the same exporter already perform schema-aware serialization, for example by limiting several string values to the maximum length allowed by the FatturaPA schema.
Telefono and Fax should receive equivalent schema-aware handling so that the standard exporter cannot produce XML that fails FatturaPA XSD validation.
I will provide a fix for a bug
- I will provide a fix for a bug
- Dominant language
- AL
- Stars
- 683
- Forks
- 459
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 621
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/BCApps
-
Team: Finance
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Approved event-request ext-ready-to-implement Team: Finance
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Approved event-request ext-ready-to-implement Team: SCM
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
event-request Team: SCM
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Team: SCM
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
All issues in microsoft/BCApps
Similar issues
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100