Generate Spanish Electronic Invoices (Facturae)


Facturae is an Electronic invoice format that is used in Spain to issue and receive invoices. Here is the specification of the format. It is and XML file which the following XSD definition.

This format is required to generate invoices to a public entity (like a local council) and they require that such invoices are signed digitaly using XADES signature. There is a dedicated portal from the goverment to upload such invoices and deliver them to the right entity.

For now it can not used to send invoices to other parties. Also a company musting continue using the non electronic format to send invoices to parties that don’t agree to accept the electronic one. This means that in a same Tryton database we need to generate the Facturae format for some parties, and the non electronic format for others.

There are several versions of the Facturae format. Here is a link for the current one and the previous ones.


Create a new module called edocument_facturae which will be responsible of generating the XML file using the facturae format. Altought the are multiple versions available I think we should just accept the latests available (3.2.2) but allow to define more versions in the futur following the desing of Electronic document

This module should have an optional dependency with account_invoice module, which will add the following features:

  1. Add a print action on the invoice to let the user print the invoice. Once the invoice is printed it should be stored to avoid changes like we do for the current invoice format.
  2. Allow to define a digital certificate (on configuration file) to include a signature on the signed document. If set the document will be signed using Python XMLSign using the XADES format.

This way the user will be allowed to generate the proper document format and upload it to the portal.



I’m not sure if it’s worth adding some checkbox (or some other way) on the party to indicate that such party uses the facture format and extend the current invoice report to just generate the facturae format. This way printing the normal invoice report will use the Facturae format instead of the current one.

This may be also usefull for generating other documents like EDI invoicing.

I would prefer to have es prefix because facturae is not an international standard.

I do not understand why it should be optional. What will be the feature of such module without an invoice?

I do not see the point to let use printing an XML file. For me we need to have a queue like in account_fr_chorus.

I do not see why? The XML format will not be changed so it should generate always the same file. But also I guess that once it is submitted to the portal, it is the portal version that is the official one.

For me it sounds like a business certificate and probably you must have one per company. So for me it must be stored in the database as configuration.

For me it is a problem to add a dependency on a 3 years old PR. For me it looks like upstream is not interested by this feature.
Maybe GitHub - etobella/python-xades: Xades Signature for Python is a better option.

Can this be automated?

1 Like

Make sense. So we should make it hard dependency.

To allow the user get the file and send to anyone else. You should note that the portal is only used for public entities but the format may be accepted by other parties which do not use the portal.

Indeed my plan was to continue working on the PR to make it part of the standard library. I have already done some work on it in the last year implementing the Xades functionality.

I prefer to contribute to a bigger library which may be also used for other signature formats if required in the future, than a one maintaned by a fewer set of developers. Indeed I guess such library will become deprectaed once the feature is implemented on XMLSign. Note that the work to include it on XMLSign has been started by some of the developers on the python-xades library. So better to finish it and include upstream.

Yes but the idea was to include such feature as future work.

For me this does not work in most cases. Usually edocument formats can work only on posted invoice, so using report model does not work.

Also I think if the edocument can be send by different means, the module should implement in the queue the different means.

We can add an error message for validate that if is realy required.

There are some means that can not be automated. For example, in order to validate the Next Generation EU digitalization grants for Spanish (called Kit Digital) you need to send the invoice using FacturaE format and this can only be sent using a web form that a user should fill in. So we need some way to the user to export the format and upload it manually to the web form.

No you can not raise user error in report.

WTF Spain! You should remove the E.

That does not prevent to have a queue like in account_fr_chorus.

Sure but for having an account_es_face module to automate the sending is not a strict requirement:

  • One may be interested on generating FacturaE invoices just for the Kit Digital form. This is currently the case of our company.
  • The Face portal accepts sending the invoices using a form. So there are some companies with a low volume of invoices that using this form is enough for them.

You still need to have a queue that define which invoices are to be sent this way (even if it is manual).

So I will not accept in standard the simplification of wrongly using a report entry in place of automated/configured process.

Ok so IIUC what you propose is to have a queue like we have for account_fr_chorus which is activated using a “Facturae” flag on party. Then on this queue how the user will be able to export the queue? Using a report? Should the user be able to manually update the state of the queue to mark it as sent?

On the future we may have another module called account_es_face which will allow a “Face” flag on the party which will sent automatically the invoices to the FACE portal using the same queue. Right?

As there are many means to deliver it, I guess it should be a selection.

I guess when it is manual, there should be a button to download it. I guess it is better to use a computed Binary field as it should be downloaded and not open or print.

In case of manual I guess the system should change automatically the state once the file has been downloaded. So for me the best is to have a wizard that expose the binary field and update the state.

For me there should be a edocument_es_facturae and a module account_es_facturae that define the queue with at least the manual mode. This can be extended by other modules to add more mode.

1 Like