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.
Proposal
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:
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.
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.
Implementation
There is an issue to include that as part of standard modules which is still pending to be accepted.
Meanwhile we have published a fully working implementation under tryton community and published the modules on PYPI for 6.8 and 7.0 series. If you find any bug feel free to use the tryton community bug tracker.
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.
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.
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.
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.
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.
I’m wondering what is the difference between this certificate and SII certificate, which was defined on configuration file.
IMHO both are business certificate and should be defined per company.
The SII certificate is to create a session so for me it is there to secure the communication not to authenticate it.
While here the certificate is to sign permanently the document as the company. It will make no sense to share the certificate between multiple parties.
But now if you tell me that the SII certificate is linked to the company, then it was a mistake to put it in the configuration.
The SII certificate is for authentication. You need it to enter to SII portal from the web browser and it gives you access to the invoices of the company linked to the certificate.
In fact, it is not used only for SII but for other company managements as well.
Because a certificate can be used to send information for another company if an authorization has been given to such company before. So for example, with a certificate of company A, you can send information of company A and B if B fills an electronic form allowing company A to send the information. For a company using its own certificate there is no need to fill any form.
On the other way, the Facturae certificate is just used for signing the file and validating its correctness.
Yes but if a company has a certificate set then there is no need to use the server one.
There issue here with certificates is that the user normally has a .p12 file which contains both the public key and the private one and that should be extracted using openssl. This is the same case as when using the certificate for signing the facturae invoices.
I think we should not care about that. We request a specific format for the certificate.
This sentence is not clear. I am struggling to understand both of you about those certificate.
Sometimes you seem to say their the same use to make a session and to sign. Sometimes not. I’m completely lost.
As I have no clue about what are the validity and usage of those certificate, it is impossible to assess the risks.