[16.0][ADD] l10n_es_aeat_verifactu #3579

zamberjo · 2024-05-10T05:57:04Z

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 · 2024-06-28T10:39:49Z

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 · 2024-09-03T07:20:13Z

Se puede ya hacer rebase.

zamberjo · 2024-09-03T07:23:58Z

Se puede ya hacer rebase.

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

giarve · 2024-09-19T20:37:41Z

l10n_es_aeat_verifactu/models/account_move.py

+        return self.amount_total
+
+    def _get_verifactu_previous_hash(self):
+        # TODO store it? search it by some kind of sequence?


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

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.

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.

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).

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.

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 · 2024-09-30T13:53:09Z

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 · 2024-10-01T07:15:33Z

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 · 2024-10-08T09:11:35Z

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 · 2024-10-08T09:54:48Z

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 · 2024-11-07T10:33:51Z

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 · 2024-11-14T12:17:47Z

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

ozono · 2024-11-14T13:44:11Z

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 · 2024-11-14T14:38:12Z

@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 · 2024-11-14T14:44:54Z

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

anmarmo1 · 2025-01-23T07:47:47Z

@SoniaViciana @ljsalvatierra-factorlibre ¿Vais a implementar la parte del Encadenamiento? Es por seguir nosotros.
El registro ha de ser único para todas las series.

Lo que no se que pasaría si el sistema esta caído, siempre hablan de "por orden cronológico de generación de registros de facturación en el SIF", he enviado la consulta a la AEAT por que no lo he visto en las FAQ

ljsalvatierra-factorlibre · 2025-01-23T08:06:37Z

@SoniaViciana @ljsalvatierra-factorlibre ¿Vais a implementar la parte del Encadenamiento? Es por seguir nosotros. El registro ha de ser único para todas las series. Lo que no se que pasaría si el sistema esta caído, siempre hablan de "por orden cronológico de generación de registros de facturación en el SIF", he enviado la consulta a la AEAT por que no lo he visto en las FAQ

Hola @anmarmo1 estamos realizando el desarrollo para tener un SIF para el backend de Odoo y un SIF por cada TPV (pos.config), del mismo modo que TicketBAI.

anmarmo1 · 2025-01-23T08:36:38Z

@ljsalvatierra-factorlibre ok entonces esperamos. ¡Gracias!

ljsalvatierra-factorlibre · 2025-01-30T11:51:42Z

@ljsalvatierra-factorlibre ok entonces esperamos. ¡Gracias!

Podéis revisar los cambios aquí #3973
Me decís por favor en ese PR cualquier cambio que veáis necesario, gracias.
Cuando esté todo listo vemos cómo integrarlo.

ljsalvatierra-factorlibre · 2025-01-30T11:52:39Z

@ljsalvatierra-factorlibre ok entonces esperamos. ¡Gracias!

Podéis revisar los cambios aquí #3973 Me decís por favor en ese PR cualquier cambio que veáis necesario, gracias. Cuando esté todo listo vemos cómo integrarlo.

Estoy ahora con el desarrollo de l10n_es_aeat_verifactu_pos.

anmarmo1 · 2025-01-30T12:22:36Z

@ljsalvatierra-factorlibre ok entonces esperamos. ¡Gracias!

Podéis revisar los cambios aquí #3973 Me decís por favor en ese PR cualquier cambio que veáis necesario, gracias. Cuando esté todo listo vemos cómo integrarlo.

Ok! Revisamos

almumu · 2025-02-04T11:53:28Z

Muchas gracias por vuestra aportación @ljsalvatierra-factorlibre , en el pr #3973
a nivel funcional lo hemos probado y está correcto, y la idea de guardarlo a nivel de compañía es buena.

Aunque la parte de anulación de facturas aún no está hecha, ahí también se envía el encadenamiento, habrá que tener cuidado a futuro de no invocar a _get_chaining_invoice_dict ya que se machacaría el valor del encadenamiento. O bien añadir una comprobación de que si ya está establecido el verifactu_last_invoice_id en la factura, no lo modifique ni en la factura ni en la compañía.

Aun así siguen habiendo varias dudas que aún no sabemos como se van a implementar y que tendremos que llegar a un consenso entre todos...
En qué momento se enviarán las facturas? al validarlas? generamos una cola de envío? porque si hay múltiples usuarios validando y enviando facturas, puede haber problemas de concurrencia con lo del encadenamiento. O por ejemplo si se va la luz durante un envío, y no se sabe si se ha enviado a verifactu porque no se había obtenido la respuesta de la aeat de si el envío ha sido correcto.., y ese tipo de cosas que pueden afectar al encadenamiento.

Tampoco tenemos claro cuál es la fecha-hora que deberíamos enviar en la huella (FechaHoraHusoGenRegistro), ahora mismo es la de creación (_get_verifactu_registration_date), pero eso no es viable porque si pasan más de 120 segundos de esa fecha-hora de creación hasta que se envía a verifactu (lo cual es muy probable que pase), la aeat la rechaza con el error "2004 El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos". Quizá lo correcto sería crear un nuevo campo de fecha envío verifactu que sea cuando realmente se envía a verifactu y que se guarde en la factura y sea ese el que se use para obtener el hash.

En cualquier caso, de momento podéis hacernos un pr a nuestra rama con estos cambios 03f46ef y así los mergeamos mientras se decide todo lo demás.
Agradeceros de nuevo vuestra contribución
Saludos

ljsalvatierra-factorlibre · 2025-02-05T08:52:13Z

Muchas gracias por vuestra aportación @ljsalvatierra-factorlibre , en el pr #3973 a nivel funcional lo hemos probado y está correcto, y la idea de guardarlo a nivel de compañía es buena.

Aunque la parte de anulación de facturas aún no está hecha, ahí también se envía el encadenamiento, habrá que tener cuidado a futuro de no invocar a _get_chaining_invoice_dict ya que se machacaría el valor del encadenamiento. O bien añadir una comprobación de que si ya está establecido el verifactu_last_invoice_id en la factura, no lo modifique ni en la factura ni en la compañía.

Aun así siguen habiendo varias dudas que aún no sabemos como se van a implementar y que tendremos que llegar a un consenso entre todos... En qué momento se enviarán las facturas? al validarlas? generamos una cola de envío? porque si hay múltiples usuarios validando y enviando facturas, puede haber problemas de concurrencia con lo del encadenamiento. O por ejemplo si se va la luz durante un envío, y no se sabe si se ha enviado a verifactu porque no se había obtenido la respuesta de la aeat de si el envío ha sido correcto.., y ese tipo de cosas que pueden afectar al encadenamiento.

Tampoco tenemos claro cuál es la fecha-hora que deberíamos enviar en la huella (FechaHoraHusoGenRegistro), ahora mismo es la de creación (_get_verifactu_registration_date), pero eso no es viable porque si pasan más de 120 segundos de esa fecha-hora de creación hasta que se envía a verifactu (lo cual es muy probable que pase), la aeat la rechaza con el error "2004 El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos". Quizá lo correcto sería crear un nuevo campo de fecha envío verifactu que sea cuando realmente se envía a verifactu y que se guarde en la factura y sea ese el que se use para obtener el hash.

En cualquier caso, de momento podéis hacernos un pr a nuestra rama con estos cambios 03f46ef y así los mergeamos mientras se decide todo lo demás. Agradeceros de nuevo vuestra contribución Saludos

Hola @almumu, muchas gracias por revisarlo, sobre el envío:

"El tema de encadenamiento de la huella de las facturas esa huella su encadenamiento se genera en funcion de la serie de 
facturacion, es decir hago la A/1, A/2 se encadena con A/1 pero si ahora hago la C/1 ¿se encadena con A/2 o realmente no 
porque es la primera de la serie C?",Ramon Sanchez,'-,,10/28/2024 13:56:15,,

El encadenamiento se realiza por orden cronológico de generación de registros de facturación, independientemente de si es un 
registro de alta o anulación o del nº de factura o serie del mismo.  No está relacionado con el orden en que los registros son 
comunicados (pueden desordenarse en la comunicación si hubiera que hacer reenvíos), ni con la serie/número de la factura 
(aunque normalmente suela seguir una cierta pauta temporal), sino con el orden en que son generados.  Cualquier registro de 
facturación nuevo tiene que ir encadenado al registro de facturación inmediatamente anterior. Eso quiere decir que el bloque 
"Encadenamiento" se rellenará con los datos del bloque "RegistroAnterior" del registro de facturación anterior y el campo 
“Huella”.

aritzolea · 2025-02-11T15:00:13Z

l10n_es_aeat_verifactu/models/account_journal.py

+                record.restrict_mode_hash_table = True
+                record.restrict_mode_hash_table_readonly = True


He detectado que esto no está llamando al write de account.journal, y está dando problemas al activar Verifactu en una compañía. Podríais actualizar esos dos campos mediante un write?

hola @aritzolea , no sé muy bien qué problemas os estará dando esta parte pero si tienes el caso controlado, podéis hacer cualquier modificación necesaria en vuestra rama y añadirlo al pr que nos hagáis. Quizá sería buena idea que nos hagáis el pr a esta rama para poder mergearlo cuanto antes y que todos hagamos las pruebas y aportaciones sobre el mismo código, como hicimos con el de @ozono , y seguir avanzando.

Buenas @almumu
Estoy con pruebas en mi local, intento abriros el PR entre hoy y mañana.

genial! muchas gracias @aritzolea

Buenas! Os he abierto PR

He abierto otro PR para corregir pre-commit y tests

He abierto otro PR para corregir pre-commit y tests

merged. He hecho otro commit porque todavía daba error el precommit

aritzolea · 2025-02-11T15:02:13Z

l10n_es_aeat_verifactu/models/account_journal.py

+    # no vamos autilizar el hash de odoo porque la estructura no nos sirve
+    # para verifactu, por lo que este código no nos terminaría de valer.
+    # De momento lo dejamos hasta saber cómo vamos a controlar
+    # el tema de la factura anterior enviada a verifactu para el cálculo


No entiendo del todo por que se ha hecho esto de esta forma. pero sigue siendo necesario después de la implementación del encadenamiento en #3973?

Sí que habrá que controlar la modificación de las facturas ya enviadas, pero la primera parte no me queda clara.

se hizo en su momento para utilizar la parte de odoo que mediante el restrict_mode_hash_table del account.move (que es un related al journal) controla la modificación de facturas, no permite pasarlas a borrador, controla qué campos se pueden modificar, etc. Lo que no se usa es ese ese propio hash para enviarlo a verifactu como hash puesto que no tiene nada que ver el formato de ese hash con el que pide verifactu.

Agencia Tributaria en el momento de su producción

* Add verifactu hash code

* Primera versión funcional de envío de facturas a verifactu

…ice post and refactor (#66)

zamberjo marked this pull request as ready for review May 10, 2024 06:09

pedrobaeza added this to the 16.0 milestone Sep 3, 2024

zamberjo force-pushed the ADD/l10n_es_aeat_verifactu branch from 46637e3 to db76bac Compare September 3, 2024 07:22

zamberjo force-pushed the ADD/l10n_es_aeat_verifactu branch 2 times, most recently from 4a39d23 to 8652e53 Compare September 9, 2024 05:35

pedrobaeza mentioned this pull request Sep 10, 2024

El Gobierno aprueba el Reglamento que desarrolla los requisitos de los programas informáticos de facturación para evitar el ‘software de doble uso’ #3337

Closed

giarve reviewed Sep 19, 2024

View reviewed changes

almumu force-pushed the ADD/l10n_es_aeat_verifactu branch 3 times, most recently from 192593e to 0a8205b Compare November 7, 2024 11:58

almumu force-pushed the ADD/l10n_es_aeat_verifactu branch from f26de9e to 61fb366 Compare November 28, 2024 06:37

ljsalvatierra-factorlibre mentioned this pull request Jan 29, 2025

[16.0][IMP] l10n_es_aeat_verifactu: backend SIF chaining #3973

Draft

ljsalvatierra-factorlibre mentioned this pull request Feb 9, 2025

[16.0][ADD] l10n_es_aeat_verifactu_pos #3997

Draft

aritzolea suggested changes Feb 11, 2025

View reviewed changes

zamberjo and others added 10 commits February 25, 2025 09:30

[ADD] envío de los registros de facturación a la sede electrónica de la

ac4e837

Agencia Tributaria en el momento de su producción

[IMP] l10n_es_aeat_verifactu: Activar Journal Hash para compañía

af1a5b4

[IMP] Adaptando a refactor de l10n_es_aeat+sii

cb73769

Add verifactu hash code (#55)

6659107

* Add verifactu hash code

Envío de facturas a verifactu (#61)

a5085ee

* Primera versión funcional de envío de facturas a verifactu

[ADD] Primera version QR Verifactu (#62)

e85986c

[IMP] l10n_es_aeat_verifactu: Fixes on views, hash calculated on invo…

04b3598

…ice post and refactor (#66)

[IMP] l10n_es_aeat_verifactu: Adapt tests to last changes

ec9a6bc

[FIX] l10n_es_aeat_verifactu: do pre-commit stuff

6d36089

pre-commit requirements

62e0169

almumu force-pushed the ADD/l10n_es_aeat_verifactu branch from 7ee354c to 62e0169 Compare February 25, 2025 08:33

		record.restrict_mode_hash_table = True
		record.restrict_mode_hash_table_readonly = True

[16.0][ADD] l10n_es_aeat_verifactu #3579

Are you sure you want to change the base?

[16.0][ADD] l10n_es_aeat_verifactu #3579

Conversation

zamberjo commented May 10, 2024 • edited by pedrobaeza Loading

almumu commented Jun 28, 2024 • edited Loading

pedrobaeza commented Sep 3, 2024

zamberjo commented Sep 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SoniaViciana commented Sep 30, 2024

anmarmo1 commented Oct 1, 2024

ljsalvatierra-factorlibre commented Oct 8, 2024

anmarmo1 commented Oct 8, 2024

almumu commented Nov 7, 2024

syci commented Nov 14, 2024

ozono commented Nov 14, 2024

syci commented Nov 14, 2024 • edited Loading

pedrobaeza commented Nov 14, 2024

anmarmo1 commented Jan 23, 2025

ljsalvatierra-factorlibre commented Jan 23, 2025

anmarmo1 commented Jan 23, 2025

ljsalvatierra-factorlibre commented Jan 30, 2025

ljsalvatierra-factorlibre commented Jan 30, 2025

anmarmo1 commented Jan 30, 2025

almumu commented Feb 4, 2025 • edited Loading

ljsalvatierra-factorlibre commented Feb 5, 2025

aritzolea Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

almumu Feb 25, 2025 • edited Loading

Choose a reason for hiding this comment

aritzolea Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zamberjo commented May 10, 2024 •

edited by pedrobaeza

Loading

almumu commented Jun 28, 2024 •

edited

Loading

syci commented Nov 14, 2024 •

edited

Loading

almumu commented Feb 4, 2025 •

edited

Loading

aritzolea Feb 11, 2025 •

edited

Loading

almumu Feb 25, 2025 •

edited

Loading

aritzolea Feb 11, 2025 •

edited

Loading