[16.0][ADD] l10n_es_aeat_verifactu

[zamberjo]

Movemos a este PR el nuevo módulo l10n_es_aeat_verifactu

Depends on:

• [16.0][IMP] Refactor para futura implementación Veri*FACTU.

[almumu]

Añadido la lógica que generará el hash de las facturas. Basado en la documentación de la aeat
https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Veri-Factu_especificaciones_huella_hash_registros.pdf
De momento son campos compute y sin store True para poder ir avanzando.

• Pendiente decidir de qué modo se va a saber cuál es la factura anterior enviada, ya que el hash de una factura a su vez está compuesto por el hash de la anterior factura enviada.

• Pendiente decidir en qué momento generaremos el hash y que se guarde en la factura.

• El tipo de documento de verifactu, de momento es un selection, si esos son los tipos definitivos podríamos convertirlo a un modelo y un data

[pedrobaeza]

Se puede ya hacer rebase.

[zamberjo]

Se puede ya hacer rebase.

Hecho y he añadido los últimos cambios para setear el campo aeat_sending_enabled

[giarve]

Indeed Odoo chose to create a sequence when creating the journal and uses the sequence to find the previous entry.

https://github.com/odoo/odoo/blob/d8a20717c830a7cddaad4889bec182f0fa5f786a/addons/account/models/account_move.py#L2548-L2551

https://github.com/odoo/odoo/blob/d8a20717c830a7cddaad4889bec182f0fa5f786a/addons/account/models/account_journal.py#L950

[anmarmo1]

Yes, but the problem in this case is that the previous record is not the previous one from the same journal. A possible solution is to implement a unique sequence for all invoices, but we also need to know if they have been sent and received by the AEAT.

[giarve]

Lo que se me ocurre es una especie de cola, así se elimina el problema de la concurrencia (y se puede tener tantas secuencias como diarios). La cola FIFO guarda la referencia o hash de la última factura en un campo global por orden de inserción.

Faltaría decidir cuando meter la factura en la cola que generará el hash y la enviará a AEAT. No sé si por la ley hay obligatoriedad de hacerlo cuando se le da a enviar factura o solamente al guardar, o pasa como el SII que puede ser manual. En cualquier caso sería meterlo en la cola desde cualquier diario y encadenar facturas de diferentes diarios, validadas por diferentes usuarios, o demás concurrencias, gracias a la cola no supondrían un problema.

es por dar ideas.

[pedrobaeza]

Me resulta muy extraño que esa factura anterior tenga que ser global en lugar de por diario. La AEAT es muy consciente de las cuestiones técnicas asociadas a tener más de una secuencia de numeración (como múltiples canales de venta).

[ljsalvatierra-factorlibre]

Según mi interpretación de la documentación, el encadenamiento es por SIF (Sistema Informático de Facturación).

Caso 2: registro de facturación –en este caso de alta–
con registro de facturación anterior existente en el SIF
(siendo, por tanto, el segundo registro o sucesivo)

Lo interpreto de ese modo porque dice factura anterior existente en el SIF.

En caso de ser mi interpretación correcta, entiendo que habría que crear un SIF para la facturación de Odoo y uno por TPV, si no recuerdo mal así es como funciona en TicketBAI.

[anmarmo1]

Si por eso interpretamos que el encadenamiento era con el anterior enviado y eso excluye el orden por diario pero realmente tampoco habla de series en ningun lado que yo haya visto...

[SoniaViciana]

Hola @zamberjo @almumu

Veo que falta la parte del hash:

La documentación técnica de la AEAT está disponible (en "Borrador"), y en cuanto al tema de controlar la factura anterior enviada a Verifactu, si no me equivoco, es algo que ya requiere y está disponible dentro de TicketBai, así que seguramente lo podremos aprovechar.

¿Os parece bien si trabajamos de nuestro lado en la parte del Hash? ¿Veis necesario reunirnos antes? lo comento por no trabajar en paralelo en lo mismo y que nos repartamos la carga de trabajo.

Quedo a la espera de vuestros comentarios.
Gracias!

---

Fuente: https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Documentacion/IVA/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU.html

[anmarmo1]

Hola @zamberjo @almumu

Veo que falta la parte del hash:

La documentación técnica de la AEAT está disponible (en "Borrador"), y en cuanto al tema de controlar la factura anterior enviada a Verifactu, si no me equivoco, es algo que ya requiere y está disponible dentro de TicketBai, así que seguramente lo podremos aprovechar.

¿Os parece bien si trabajamos de nuestro lado en la parte del Hash? ¿Veis necesario reunirnos antes? lo comento por no trabajar en paralelo en lo mismo y que nos repartamos la carga de trabajo.

Quedo a la espera de vuestros comentarios. Gracias!

Fuente: https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Documentacion/IVA/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU.html

Hola Sonia
Perfecto, si quereis encargaros vosotros de la parte del HASH no hay problema, si quereis una reunión tampoco hay problema.
El tema del hash es que, el que implementa Odoo no vale, por que los valores para construirlo para el verifactu son distintos y además la complejidad reside en saber cual es el último registro que ha sido enviado a la AEAT por el tema del encadenamiento. Con respecto a utilizar la parte de ticketbai para esto, podéis revisar como se implemento como inspiración, pero no vale para la implementación del verifactu ya que esta implementado con una librería de python externa y en los OCA Days los PSC nos indicaron que de esta manera no se fusionaría. Por nuestro lado, si queréis podemos empezar con las llamadas al wsdl de la AEAT y así avanzamos.

[ljsalvatierra-factorlibre]

Hola @zamberjo @almumu
Veo que falta la parte del hash:

La documentación técnica de la AEAT está disponible (en "Borrador"), y en cuanto al tema de controlar la factura anterior enviada a Verifactu, si no me equivoco, es algo que ya requiere y está disponible dentro de TicketBai, así que seguramente lo podremos aprovechar.
¿Os parece bien si trabajamos de nuestro lado en la parte del Hash? ¿Veis necesario reunirnos antes? lo comento por no trabajar en paralelo en lo mismo y que nos repartamos la carga de trabajo.
Quedo a la espera de vuestros comentarios. Gracias!
Fuente: https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Documentacion/IVA/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU.html

Hola Sonia Perfecto, si quereis encargaros vosotros de la parte del HASH no hay problema, si quereis una reunión tampoco hay problema. El tema del hash es que, el que implementa Odoo no vale, por que los valores para construirlo para el verifactu son distintos y además la complejidad reside en saber cual es el último registro que ha sido enviado a la AEAT por el tema del encadenamiento. Con respecto a utilizar la parte de ticketbai para esto, podéis revisar como se implemento como inspiración, pero no vale para la implementación del verifactu ya que esta implementado con una librería de python externa y en los OCA Days los PSC nos indicaron que de esta manera no se fusionaría. Por nuestro lado, si queréis podemos empezar con las llamadas al wsdl de la AEAT y así avanzamos.

Hola @anmarmo1, ¿con librería de python externa te refieres a la librería de Javascript tbai.js?

[anmarmo1]

Hola @zamberjo @almumu
Veo que falta la parte del hash:

La documentación técnica de la AEAT está disponible (en "Borrador"), y en cuanto al tema de controlar la factura anterior enviada a Verifactu, si no me equivoco, es algo que ya requiere y está disponible dentro de TicketBai, así que seguramente lo podremos aprovechar.
¿Os parece bien si trabajamos de nuestro lado en la parte del Hash? ¿Veis necesario reunirnos antes? lo comento por no trabajar en paralelo en lo mismo y que nos repartamos la carga de trabajo.
Quedo a la espera de vuestros comentarios. Gracias!
Fuente: https://www.agenciatributaria.es/AEAT.desarrolladores/Desarrolladores/_menu_/Documentacion/IVA/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU/Sistemas_Informaticos_de_Facturacion_y_Sistemas_VERI_FACTU.html

Hola Sonia Perfecto, si quereis encargaros vosotros de la parte del HASH no hay problema, si quereis una reunión tampoco hay problema. El tema del hash es que, el que implementa Odoo no vale, por que los valores para construirlo para el verifactu son distintos y además la complejidad reside en saber cual es el último registro que ha sido enviado a la AEAT por el tema del encadenamiento. Con respecto a utilizar la parte de ticketbai para esto, podéis revisar como se implemento como inspiración, pero no vale para la implementación del verifactu ya que esta implementado con una librería de python externa y en los OCA Days los PSC nos indicaron que de esta manera no se fusionaría. Por nuestro lado, si queréis podemos empezar con las llamadas al wsdl de la AEAT y así avanzamos.

Hola @anmarmo1, ¿con librería de python externa te refieres a la librería de Javascript tbai.js?

Hola @ljsalvatierra-factorlibre realmente me referia a este PR #3547

[almumu]

Hemos hecho una primera versión funcional de envío de facturas a verifactu.

El desarrollo está hecho de la forma más parecida posible al módulo del sii, para que en caso de que haya que unificar o modificar procesos, sea los más entendible posible para todos los que toquemos código.

Falta mucho por hacer pero ya es un paso, cualquier aportación es bienvenida.

Para poder probarlo:

• Tener certificado
• Activar verifactu en la compañía y establecer que es entorno de pruebas.
• Configurar en la posición fiscal la clave de impuesto (Verifactu Tax Key): IVA y clave de registro verifactu: Operación de Régimen General, para que al crear la factura se rellenen los datos.
• Hay un mapeo de impuestos como en el sii, algunos están ya rellenados pero faltará revisarlo.
• De momento el envío se hace desde el botón manual en la factura, una vez validada. Todavía no está implementado el envío con queue job.
• Sólo se han hecho pruebas de envío con facturas normales de régimen nacional o recargo de equivalencia sin impuestos especiales. Como la parte del encadenamiento con el registro anterior en el hash sigue sin estar clara, de momento se envía siempre como si fuera el primer registro para poder enviarlo.
• No están contemplados aún casos como facturas simplificadas, terceros, no sujetas.., tampoco modificaciones y anulaciones de facturas.
• Los datos del desarrollador: IdSistemaInformatico, NumeroInstalacion, .. nos los hemos inventado un poco, esto habrá que verlo.

[syci]

Hola, por mi parte empezaré a revisar/probar y demás para poder desarrollar la parte necesaria para la ATC en Canarias.

[ozono]

He enviado un PR aurestic#62 a los compañeros de Aurestic como punto de partida para el QR en las facturas. Es una implementación funcional, aunque hay detalles por discutir y revisar. Aprovecho para dar las gracias a todos por el trabajo realizado.

[syci]

@pedrobaeza veo que en los mapeos los impuestos del IGIC no están en https://github.com/aurestic/l10n-spain/tree/ADD/l10n_es_aeat_verifactu/l10n_es_aeat_verifactu/data , ¿Dónde se implementaría en el módulo del igic, en uno nuevo verifactu_igic ...... ?

[pedrobaeza]

Eso es, @syci. Habrá que hacer un módulo puente.