odoo/odoo#197635

Created by Accounting, Sven Führ (svfu)

label

odoo-dev:17.0-add_l10n_es_edi_verifactu-svfu

head

7cd34567a8b9b4b556ca5e0d4fd1fd2026ff3132

merged

2 weeks ago by Accounting, Sven Führ (svfu)

	odoo/odoo	odoo/documentation
17.0	#197635	#12068
18.0	#219953
saas-18.2	#221214
saas-18.3	#221431
saas-18.4	#221556
master	#221588

[ADD] l10n_es_edi_verifactu{,_pos}: Veri*Factu support

[ADD] l10n_es_edi_verifactu{,_pos}: Veri*Factu support

Spain introduces a new EDI called "Veri*Factu" to send invoicing records
to the Spanish tax agency (AEAT).
It is mandatory for most tax payers (that cannot use any of the
other Spanish EDIs like SII or TicketBAI).

This commit adds 2 modules to enable Veri*Factu compliance
- l10n_es_edi_verifactu for invoicing / accounting
- l10n_es_edi_verifactu_pos for Point of Sale (PoS)

Their setup and usage is briefly described in the documentation
(see the related documentation PR).
The main features of the new modules are as follows.
- l10n_es_edi_verifactu
- The "Send & Print" wizard can be used to generate and send VeriFactu documents.
- A QR code is added to the PDF of invoices send with the VeriFactu option.
It can be used to check whether the invoice is known to the AEAT.
- A "VeriFactu" tab is added to the account move form view.
It i.e. gives an overview about the send documents and their status.
- l10n_es_edi_verifactu_pos
- A VeriFactu documents is generated and sent when validating each order.
- A QR code is added to the PDF of PoS order receipts.
It can be used to check whether the order is known to the AEAT.
- A "Veri*Factu" tab is added to the pos order form view.
It i.e. gives an overview about the send documents and their status.

I.e. note the following about VeriFactu documents
- Each document has a fingerprint (hash of some important values) called Huella.
- All documents belonging to one company are linked together in a single chain in generation order.
(Each document refers to the previous document including the Huella of the previous document)
- There is a waiting time between submissions of documents (usually 60s).
We sent the document immediately if possible.
But due to the waiting time this is not always possible.
- We still generate / store the needed values when the invoice is sent
(mandated by VeriFactu spec).
- Documents can be sent in batches.
- Due to the waiting time we sent all "waiting" documents at once.
- In case of 1000 documents the waiting time can be / is ignored
- A "VeriFactu Document" in Odoo only represents a single invoice / PoS order.
- The needed document values mandated by VeriFactu are stored in JSON format
on each invoice / order.
- The actual "communication" with AEAT is done via SOAP. (So we sent / receive
XML files)
- We do not store the actual batch XML we sent to the AEAT or the received responses.
- For the responses we extract the necessary information and store them
on each of the document

It can happen that the document reached the AEAT but the response
timed out for some reason (Read-Timeout).
- The AEAT has (potentially) registered the document but we have
not received the response they sent.
- The document will be marked with an error starting with [Read-Timeout].
and automatically be sent again as soon as possible
- When the document is resend successfully we receive a response that the document
was rejected with error [3000] Registro de facturación duplicado.
(Assuming the AEAT registered / not rejected the document when it was sent originally.)
But the response also contains some information about the state and potential errors
of the record / duplicate.
- Since the duplicate is the document we previously sent we just take the state from there.

There are 2 ways to create a correcting Veri*Factu document for invoices
- Correction by difference: Done via "Reverse" in credit note wizard
We just send a document representing the credit note as "correction by difference".
The document references the corrected invoice.
- Correction by substitution: Done via "Reverse and Create Invoice" in credit note wizard
We first send a document representing the reversing credit note (it does not
reference the original invoice and is send as an "invoice type").
And then we send the new invoice created by the wizard. It is send as a
"correction by substitution" and references the original invoice.
To link the new invoice to the original invoice a new field was added
- We do not support correcting multiple documents with a single new documents
(neither correction by difference nor correction by substitution)

The "Veri*Factu" tab on the invoice form view also gives information
about which invoice was refunded or substituted.

Limitations
- In VeriFactu there is some dedicated way to handle the substitution of
simplified invoices with "real" invoices.
This is not implemented currently.
- In VeriFactu multiple tax types (Impuesto) and regimen keys (ClaveRegimen) can
be indicated (one per DetalleDesglose element).
We currently only allow a single tax type and regimen key for the whole
document.
- In VeriFactu it is possible to send a "Subsanación" in case a change is made
that does not require updating the invoice PDF.
This is currently not supported.
- I.e. we do not support sending new submission documents for already registered
(possibly with errors) records.
- It is not possible to reset registered (possibly with errors) records back to draft.
- In VeriFactu it is possible to send a cancellation for records that are otherwise
known to the AEAT (not VeriFactu).
We do not support sending cancellations for records that are not VeriFactu registered
within Odoo.
- For simplified invoices there are the special keys / fields FacturaSimplificadaArt7273
and FacturaSinIdentifDestinatarioArt61d. Currently we never set them (so they are assumed
to be N by the AEAT).

[IMP] l10n_es{,edi_sii,edi_tbai}: move some code to l10n_es

The moved code will also be needed for Veri*Factu
- patched http adapter
- a function to retrieve partner info

[FIX] l10n_es_pos: set simplifed partner only when we will invoice

Currently we also set the simplified partner directly on pos orders even
in case we do not invoice the pos order directly.
This is unnecessary; we only need to set a partner in case we invoice.
(Since we need a partner to put on the invoice.)

After this commit we only set the simplified partner on pos orders
that will be invoiced as simplified invoice.
(This happens automatically in case a simplified invoice journal is
set in the settings; see field pos_l10n_es_simplified_invoice_journal_id)

References

documentation PR: odoo/documentation#12068
task-3745982