[E-Document][Peppol] - Move PEPPOL BIS 3.0 from BaseApp to the 1st-party App #4931
Conversation
Adds the PEPPOL 3.0 electronic document format to enable sending and receiving business documents according to the PEPPOL standard. This initial implementation includes: - Core codeunits for managing and validating PEPPOL documents - XMLports for exporting Sales Invoices and Credit Memos - New enums and interfaces to provide extensibility - Service support for handling Service Invoices and Credit Memos The implementation provides a framework for creating PEPPOL-compliant documents and ensures data integrity through validation rules.
Moves main app source files into an 'App' subfolder and introduces a new 'Test' folder for PEPPOL, including test runner configuration, logo, test app manifest, and an extensive automated test suite for PEPPOL functionality and validation. Enables comprehensive automated testing and separation of production and test code for improved maintainability.
Improves maintainability and developer experience by introducing comprehensive XML documentation across PEPPOL 3.0 management, validation, export, and interface layers. Summarizes intent, parameters, and return values for procedures, enums, and fields. Enhances clarity and discoverability of PEPPOL e-document processing, validation, and export workflows, supporting better onboarding and future extensibility.
Eliminates unused format provider references to simplify code and reduce maintenance overhead. Renames various procedures for consistency and clarity. Refactors tests to use interfaces instead of concrete implementations, enhancing flexibility and future extensibility.
Aligns codeunit and app object IDs with new reserved range to ensure compliance with updated extension conventions and prevent conflicts with existing objects.
Introduces examples and guidance for extending PEPPOL export functionality, including dependency setup, enum extensions, and interface implementations. Helps partners customize business logic and validation while leveraging standard procedures.
…ment.Codeunit.al Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
…mentImpl.Codeunit.al Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
…um.al Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
…Impl.Codeunit.al Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
…PPOL30Mgmt.Codeunit.al Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
…e/BCApps into dev/aan/PEPPOL_App
Co-authored-by: Grasiele Matuleviciute <131970463+GMatuleviciute@users.noreply.github.com>
…e/BCApps into dev/aan/PEPPOL_App
Integrates format provider selection via company setup, replacing hardcoded logic and manual interface instantiation. Improves extensibility for PEPPOL document export and related info providers. Reduces obsolete comments and unused code, clarifies interface documentation, and corrects minor typos. Enables easier support for future e-document formats and cleaner code maintenance.
|
Could not find linked issues in the pull request description. Please make sure the pull request description contains a line that contains 'Fixes #' followed by the issue number being fixed. Use that pattern for every issue you want to link. |
GMatuleviciute
changed the title
GMatuleviciute
changed the title
|
Nice. Are there any plans to remove the old PepPol logic in the document sending profile? 
|
| { | ||
| fields | ||
| { | ||
| field(37200; "E-Document Format"; Enum "E-Document Format") |
There was a problem hiding this comment.
For what use case is this field intended?
Are there any plans to support multiple formats for a Business Central company?
Context:
From the perspective of our customers in Germany, two formats are relevant (EN 16931):
- ZUGFeRD (essentially CII/XML format embedded in a PDF), widely used in German industry.
- XRechnung (a PEPPOL variant in UBL/XML format), required by government entities.
Many customer will need both. And for them with customers outside Germany but within the EU, these formats may be uncommon. An exception is Factur-X in France, which is the same format as ZUGFeRD. For broader EU invoicing, PEPPOL could become a good option for sending invoices to customers, even if—at least as far as I know—there are currently no near-term plans to make it mandatory. Still, it seems like a sensible approach.
CII
There was a problem hiding this comment.
In this iteration it is picked up by the XML ports to determine what implementation to use for certain parts of the export.
Are there any plans to support multiple formats for a Business Central company?
- I would say we this already when you setup multiple services in a e-document workflow. Or how do you think on multiple formats?
There was a problem hiding this comment.
Yes, I can create several workflows for each format, each connected to a different e-document service. I’m just wondering what this field is actually used for.
There was a problem hiding this comment.
Im not sure the field on CI is the right place to put this, but the enum allows partial/full override of the behavior when creating PEPPOL documents.
Since XML ports are from baseapp is run using xmlport.run, then the impl would need to live somewhere, and allowed to be overwritten. Thats the idea anway.
There was a problem hiding this comment.
@Groenbech96 I'm sorry, but I don't understand your response.
My question is: why is this field set up on Company Information?
My reasoning is: If you want to support multiple PEPPOL-based formats (such as XRechnung and PEPPOL 3.0) side by side, wouldn't it make more sense to place this on the E-Document Service table where the format is selected?
There was a problem hiding this comment.
@DanielGoehler great we look at it the same.
Yes, i was thinking to add some API on the codeunits that call the XMLPorts, that would allow you to set that as you call it. So you could implement your own format that allow you to overwrite it with custom code.
I plan to update the PR with said changes soon.
Yes. That is indeed the intention here. |
Ensures new electronic document formats are automatically created when the app is installed by introducing a dedicated install codeunit and refactoring initialization logic. Updates documentation to clarify adjustments needed for PEPPOL format usage.
|
Just a note if you also plan to move away from XMLports regarding PEPPOL BIS 3.0. The main differences between XRechnung and PEPPOL BIS 3.0 are the additional mandatory fields (Buyer Reference, Payment Means Code, Contact Name, Contact Phone No., and Contact Email), as well as the different namespaces:
|
5 participants
This pull request does not have a related issue as it's part of the delivery for development agreed directly with @altotovi @Groenbech96
Implementation
Created new PEPPOL and Tests-PEPPOL apps to move PEPPOL BIS 3.0 format out of Base app to a 1P app. Replaced the extensibility points with interfaces instead of events.
This initial implementation includes:
You can find new app extensibility examples in extensibility_examples.md file (part of this pull request)
Important
This Pull request related with https://github.com/microsoft/BusinessCentralApps/pull/1595
Fixes #