E-Document Integration in Business Central: Key Features and Benefits

The new E-Document functionality has been released with Dynamics 365 Business Central 2023 Wave 2. Since introduction, Microsoft has included a connector named Pagero and announced that Avalara connector will be available from 25.1. Some more localized connectors are “cooking” in the Microsoft’s kitchen, but the general idea is to address the fact the eInvoicing will become obligatory in European countries in the following years. In that sense I have also dealt with extending the “E-document” framework for Serbia. Here in Serbia, there are two use cases:

• Government managed eInvoicing portal (B2B) – mandatory for documents with VAT since 2023
• Government managed portal for fiscal bills – mandatory for retails since 2022

There is comprehensive documentation from Microsoft on topic how to extend the E-Documents framework on the link. There are few entities that Microsoft have foreseen to be extended – there also a few that were not intended to be extended but I did it anyway. 😀

Extensible entities are:

• Document Interface – There are two built-in document formats:
  • Data Exchange
  • PEPPOL BIS 3.0 – using XML ports
• Integration Interface – there are also two integrations available:
  • No Integration – for manual file upload
  • Pagero
• Setup wizard – There is only a documentation about the wizard. I have not found that Microsoft provided any wizard for currently available connectors.

From first sight it looks like there are not that many entities that have to be touched in order to get a working E-Documents integration. However, the local requirements may vary thus asking for a developer to find out some creative solutions.

For Serbian eInvoicing portal I have chosen a Data Exchange document format thus did not have to create a new document format. I also used Data Exchange Definitions provided by Microsoft. Those definitions had to be adapted a bit in order to work for the format being used in Serbia which is a would say localized version PEPPOL format – even though the documentation does not reference to PEPPOL but actually to the European standard named EN 16931-1. I have chosen Data Exchange over XML Ports as it provides more flexibility when there are changes in Format over XML Ports – where objects have to be adapted by a developer. This decision can be different for other countries/portals. I would say that both paths are valid. I did not have to invent the document format, but I had to implement an Integration interface which is specific for Serbia. I started with receiving side and finished up with sending.

In addition to above mentioned attaching points that were meant to be extended I have also implemented following for Serbian eInvoicing portal:

• Sleeping time – there is limit of a portal that not more than 3 http requests are allowed per second, thus I had to make sure that the limit is not reached.
• Receving e-documents for specific date or period.
• Receiving attachmens during receipt.
• Posibility to delete E-Documents and accompanying purchase documents that were not created correctly for whatever reason.
• Marking received prepayment purchase documents as processed automatically.
• Integrated document statuses specific to Serbian portal

For a portal for fiscal bills the integration story is a bit different. The idea is to use a QR Code Scanner built into Business Central in order to scan a QR Code from a fiscal slip that would trigger a http request to portal and fetch the fiscal bill in a text format. It is a common scenario that employees pay for costs while being on a field service or during trips. I also used Data Exchange Format but, in this case, I had to create a new Data Exchange Format as I had to parse the text file provided by the portal into XML first. The integration interface had to be extended in order to get the fiscal bill in text format. The slip received as text file is saved as attachment so that it can be inspected at any point of time. The goal is not to be forced to manually create Purchase Invoices but to be able to register those expenses fast inside of Business Central.

There are few glitches of the E-Document module but in general I like the fact that there is a dedicated generic framework for creating connectors for different types of E-doc portals.

There are of course few improvements I would like to see happening in the module:

• It seems like to module is intended to be extended but many parts are still hidden as internal objects/methods. Probably the extensibility should be addressed sometime in the future.
• The processing of document dates seems not possible out of the box. It looks like it the module completely ignores the Date in the XML file and sets Posting, Document and Due date to work date.
• Not being able to delete purchase documents related to E-Documents can lead to headaches, especially if there’s an error that needs correction.
• After initial release of the module Microsoft received feedback that attachments are a thing in E-Invoicing. The attachment processing for PEPPOL seems to be implement for XML processing but not for Data Exchange. The Data Exchange processing is obviously not the preferred way of processing. Apart from that I simply do not like the fact the attachment processing did not land in E-Document Framework but in the PEPPOL implementation with XMLs.
• There is a new field named “Receive E-Document To” in Vendor. The values are Purchase Order and Purchase Invoice. I absolutely hate that I have to set the field value to Purchase Invoice for every Vendor manually as the Purchase Order is the default value. I hope the default setting will appear on Vendor Templates.

So, should you start extending this module as soon as possible? It depends. For example, the module extension for Germany is on a roadmap for Microsoft. So, the big markets are first in the line for receiving the localized versions implemented by Microsoft. Those markets that are not planned to be localized by Microsoft – yes, partners in those countries should definitely start localizing the module. I understand that there might be completely custom solutions but for me the path was clear. The eInvoicing portal is mandatory in Serbia for entities that deal with VAT and Microsoft will not release localized version of this module and I do not have the capacity to reinvent the wheel.

I will be participating in a workshop on Directions 2024 in Wien. If you would like to have a chat and brainstorm your extensions of the module join me on a workshop or at the 𝗕𝗼𝗼𝘁𝗵 𝗦𝟵.

In some of the next blog posts I will talk about the code that I have implemented in order to support attachments in E-Document module. I know few people are waiting for code examples.