Sponsoring UBL Invoice-2

As invoice is “printed” when invoice is posted, report invoice could be added as attachment in the ubl peppol bis 3 file. Here’s an example with a report saved as pdf file (still needs improvements).

Adding a property to convert report in base64 in account_invoice/invoice.py

class Invoice(metaclass=PoolMeta):
    __name__ = 'account.invoice'

    @property
    def base64_report(self):
        if self.invoice_report_cache:
            return (base64.b64encode(self.invoice_report_cache)).decode('ascii')

In edocument_ubl/template/2/Invoice.xml:


<py:if test=“specification == ‘peppol-bis-3’ and this.invoice.base64_report”>
<cac:AdditionalDocumentReference>
<cbc:ID>${this.invoice.number}</cbc:ID>
<cbc:DocumentType>${this.invoice.invoice_report_format}</cbc:DocumentType>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode=“application/pdf” filename=“invoice.pdf”>${this.invoice.base64_report}</cbc:EmbeddedDocumentBinaryObject>
</cac:Attachment>
</cac:AdditionalDocumentReference>
</py:if>

For me it is a matter to use the European tax identifier instead of the local tax identifier on the invoice.
Now I do not know how I could enforce this except by removed national identifier from the tax identifiers (but it is not backward compatible).

I seems it should be at least one of <cbc:BuyerReference> or <cac:OrderReference> / <cbc:ID>.
I guess for <cbc:BuyerReference> we could fill with the Invoice.reference if filled.
And for <cac:OrderReference> / <cbc:ID> it should be the origin but the problem is that Tryton may have multiple origins.

The last revision should fix all the comments and include the invoice as additional document.

2 Likes

Thanks Cédric !

One last error when testing peppol-bis-3 file:

[UBL-CR-666] A UBL invoice shall not include an AdditionalDocumentReference simultaneously referring an Invoice Object Identifier and an Attachment

So <cbc:DocumentTypeCode>130</cbc:DocumentTypeCode> is not needed when there is an attachment.

I really do not understand the rule. One more rule that does not make sense for me.

Indeed. Don’t understand too :slight_smile:

As far as I understand despite the documentation for <cbc:DocumentTypeCode> saying that the default value is 130 (which was the reason I set it to this value).
This code 130 seems to indicate that the document is not attached but just providing via the <cbc:ID>.

1 Like

We noticed that defined eas code for Belgium is ‘0208’ which is Enterprise Number. (Add edocument_ubl module (!2632) · Merge requests · Tryton / Tryton · GitLab)

Some company does not have an enterprise number but only a Belgian VAT Number, so eas code should be ‘9925’.

Example for “Bol .com” : Peppol Directory - Search

So how to define this eas for a party ?

Wondering if only companies with an enterprise number should use peppol for invoicing ?

I think I will have to add a be_bussinessid as identifier type (and some others) for countries for which python-stdnum is using aliases but not EAS.

Ok, but Tryton remove the prefix ‘BE’ when defining Belgian Enterprise Number on a party.

So we have such xml which is incorrect because party will not be found with this number.

<cac:AccountingSupplierParty>
        <cac:Party>
                    <cbc:EndpointID schemeID="9925">0440740581</cbc:EndpointID>

You should use ${identifier.vatin} instead of ${identifier.code} in case of schemeID=”9925” (it should be the same for other country codes)

<cac:AccountingSupplierParty>
        <cac:Party>
                    <cbc:EndpointID schemeID="9925">BE0440740581</cbc:EndpointID>

I do not find such rule in Peppol BIS Billing 3.0 - May 2025 Release
And it will be strange to have to prefix with the country code a number that is already defined as being from this country with the schemeID.

It’s not a rule. But I think the id will not be found without prefix.

If you search in the peppol directory, you could see that id for 9925 has ‘be’ prefix.

See ‘Bol’ example: Peppol Directory - Search

Peppol id is 9925:be0824148721 and not 9925:0824148721

Anyway, I’ve not tested to send an invoice to a recipient through peppol network using 9925 id without prefix…

It is quite impressive that the EU is basing its e-invoicing legislation on such poorly documented protocol as Peppol.

2 Likes

I found this Peppol Code Lists - Participant identifier schemes with some validation (the 0208 is defined as to validate like in python-stdnum :person_facepalming:) but there are no validation for all the EU schemeID starting at 99xx.

Ok. The only way to verify would be to send an invoice through the network but don’t think there’s a test environment…

I have opened a ticket to https://peppol.org/ about the missing of clear formatting for those values.

But I’m not sure it is a problem because we base the assumption on the Peppol directory for which the participant ID is probably sanitized and formatted.

Meanwhile I implemented a customizable version of the “EAS” code which adds the country code prefix for VAT identifiers.

1 Like

The modules have been merged. I will send the invoices.

2 Likes