[16.0][FIX] l10n_es_verifactu_oca: registro de facturas rechazadas: alta por rechazo

[almumu]

• arreglado el envío de facturas incorrectas y por tanto rechazadas, se deben subsanar igual que se hace con las que están aceptadas con errores, pulsando manualmente el botón de volver a enviar desde la factura una vez arreglado el motivo del rechazo por el usuario, y se envían como alta por rechazo con los valores Subsanacion="S" y RechazoPrevio="X".
• actualizado el readme, quitado cosas del roadmap que ya están.
• mejorado alguna vista

[pedrobaeza]

Buenas, Almu, al mensaje de commit le falta el nombre del módulo. Parece que en FL no se pone ese nombre, pero la convención de OCA sí debe llevarlo: https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/CONTRIBUTING.rst#commit-message

Luego, revisa pre-commit.

[anmarmo1]

Revision funcional correcta, aunque no puedo probar que AEAT acepta el envio si se envia con "Subsanacion": "S", "RechazoPrevio": "X cuando esta en estado "Rechazada"

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[almumu]

faltaba hacer squash de commits, esto ya se podría mergear @pedrobaeza ?

[pedrobaeza]

Por qué cambiar todo y poner un nuevo estado en lugar de utilizar el de incorrecto? Es mejor solo cambiar la etiqueta si es que queremos ser precisos, pero no el valor interno y que no tengas que modificar tantos archivos.

[almumu]

@pedrobaeza lo puse porque los aeat_state que hay son estos:

l10n-spain/l10n_es_aeat/models/aeat_mixin.py

Line 24 in 7f10061

AEAT_STATES = [

AEAT_STATES = [
("not_sent", "Not sent"),
("sent", "Sent"),
("sent_w_errors", "Accepted with errors"),
]
y rechazada o incorrecta no encajaría con ninguno de ellos,no? cuál debería usar?

[pedrobaeza]

@almumu hazme ping cuando quieras que revise, porque si no, no sé si está terminado o no. Te he puesto un comentario para que no haya tantos cambios por un lado, pero por otro, para que al listar los valores del campo selection del objeto, no lleve a confusión de por qué hay un valor incorrect y otro rejected.

[pedrobaeza]

Pero entonces las referencias en código a send_state como incorrect estaban mal?

[almumu]

Pero entonces las referencias en código a send_state como incorrect estaban mal?

@pedrobaeza el campo send_state es propio del módulo de verifactu y está en los modelos verifactu_invoice_entry y del verifactu_invoice_entry_response_line que son los envíos y las respuestas. En el account_move se utiliza el del aeat.mixin que es el campo aeat_send_state (también por tema de que se pueda controlar que una factura se ha enviado a la AEAT sea desde el sii o sea desde verifactu independientemente de que se active una cosa u otra), pero se quedaba cojo porque no hay un "incorrecto", lo que puedo hacer es llamarle incorrect en vez de rejected para que coincida con los de los entry.

[pedrobaeza]

Uf, veo que la estructura se complica y es muy fácil que se "desincronicen" los estados de las líneas y del documento padre. Según comentas, fuera de añadir un estado o no, ¿el estado del account.move (o luego del pos.order), no debería ser un calculado que obtenga su valor de las líneas entry?

[almumu]

Uf, veo que la estructura se complica y es muy fácil que se "desincronicen" los estados de las líneas y del documento padre. Según comentas, fuera de añadir un estado o no, ¿el estado del account.move (o luego del pos.order), no debería ser un calculado que obtenga su valor de las líneas entry?

sí, igual podemos hacerlo así, añadiendo un nuevo campo en los account.move y pos.order (en verifactu.mixin) que sea calculado y trabajar sobre ese, pero actualizando también el aeat_state para que si luego se pasan al sii no se ponga a enviar facturas ya enviadas desde verifactu, o viceversa .

[pedrobaeza]

No haría falta un nuevo campo: el aeat_state puede pasar a ser calculado, y bueno, añadir ese estado que falta. No sé si realmente podríamos pasar el nuevo estado a l10n_es_aeat y que SII y VERI*FACTU lo compartan.

[almumu]

No haría falta un nuevo campo: el aeat_state puede pasar a ser calculado, y bueno, añadir ese estado que falta. No sé si realmente podríamos pasar el nuevo estado a l10n_es_aeat y que SII y VERI*FACTU lo compartan.

pero si pasa a ser calculado, habría que modificar el módulo del sii para que lo calcule también

[pedrobaeza]

No, porque lo pasas a calculado en verifactu.mixin, no en aeat.mixin, y así solo afecta a VERI*FACTU.

[almumu]

No, porque lo pasas a calculado en verifactu.mixin, no en aeat.mixin, y así solo afecta a VERI*FACTU.

@pedrobaeza no he podido ponerme con esto aún para comprobar si realmente pasaría esto, pero estoy pensando si no dará problemas que lo cambiamos por un compute el campo aeat_state en el caso de que se tengan instalados los 2 módulos, el del sii y el de verifactu, porque tienen multicompañía y en una están en el sii y en otra en verifactu. Al instalar verifactu el campo aeat_state pasaría a ser calculado, pero para el sii dejaría de funcionar bien supongo porque nunca se calcularía, porque ese campo es del aeat.mixin y tanto el sii.mixin como verifactu.mixin heredan de él y luego el account.move al tener los 2 módulos heredaría de ambas. Creo que sería mejor dejar ese campo como está sin ser compute, simplemente se podría añadir un valor más que sea "incorrecto" en el aeat.mixin y luego en verifactu en caso de rechazo por ser incorrecto ponerle ese estado.

[pedrobaeza]

Bueno, lo que habría que hacer en el compute del verifactu.mixin es no hacer nada si en la compañía asociada no se tiene habilitado. De esa forma, para SII se asigna a mano (sería un computed writable el campo), y para VERI*FACTU lo calcula.

[almumu]

cuando puedas le echas un vistazo @pedrobaeza ?

[IvanHRN]

@almumu Por mi parte he estado realizando algunas pruebas y funciona correctamente tanto la gestión de los estados como la funcionalidad de reenvío a verifactu.

En cuanto a los estados veo bien igualar los valores del campo aeat_state y del campo send_state, para así evitar errores/confusiones. No obstante, habría que analizar/corregir los filtros de la vista tree de las facturas, ya que tienen estados no disponibles como son 'sent_modified' y 'cancelled_modified'. Siendo solo ventas y no permitiendo modificaciones sobre una factura ya confirmada/enviada entiendo que estos estados no tendrían sentido. No obstante, desconozco como afectará a otros casos como el del SII, donde si que existen compras (si no recuerdo mal se permiten modificaciones) y existen los estados mencionados en el código.

En el código de account.move entiendo que hay una errata a la hora de rellenar el "RechazoPrevio", ya que está puesta una "X" (entiendo que tendría que ser una "S"). Las pruebas las he realizado manteniendo la X y hacienda no ha devuelto error, el envío ha sido correcto.

Mientras estaba haciendo las pruebas y parando el código he tardado más de los 240 segundos fijados por hacienda para realizar el envío por lo que la factura se ha marcado como "Enviada e Incorrecta". Al volverla a enviar a ocurrido lo mismo y esta vez se ha marcado como enviada con errores (falta la traducción por cierto). ¿Sería conveniente capturar este error específico y marcar las facturas como correctas para evitar que salgan como erróneas? Aunque se trata de un error como tal no hay nada que subsanar. Es algo que puede pasar si falla la conexión del odoo en cuestión o el sistema verifactu está caido.

[almumu]

buenos días @IvanHRN

El valor X en las altas por rechazo, es correcto, así lo indica la documentación de verifactu

Los estados que comentas de sent_modified o cancelled_modified, es cierto, en verifactu no deberían estar esos estados en los filtros de la vista search, porque son estados que sólo existen en el sii.

Por otro lado, respecto al envío con retardo:
Si te fijas, en ese caso, se envía con el valor Incidencia="S" en la cabecera,que sirve para justificar que has tenido un problema técnico que te ha impedido enviarla antes.

El cron, que se ejecuta cada minuto, ya tiene en cuenta si ha habido este retardo y las que han excedido este tiempo las envía directamente con el incidencia="S" para que no devuelva el error 2004, por lo que en pocos casos el error va a ser el 2004.

l10n-spain/l10n_es_verifactu_oca/models/verifactu_invoice_entry.py

Line 141 in b1d71ec

outdated_records.with_context(

Ejecutándose el cron de envío cada minuto sería raro que se superen los 240 segundos salvo que pares el cron o que realmente haya habido un problema técnico.
Aún así, si por el motivo que fuera, la factura fuera "aceptada con errores" con el código de error 2004, que indica que se ha excedido el tiempo de los 240 segundos, se debe subsanar, porque está en la lista de errores que hay que subsanar.

Estos son los códigos de error que requieren subsanación, como verás el 2004 está en esa lista.
********* Listado de códigos de error que producen la aceptación del registro de facturación en el sistema (posteriormente deben ser subsanados) *********
2000 = El cálculo de la huella suministrada es incorrecta.
2001 = El NIF del bloque Destinatarios no está identificado en el censo de la AEAT.
2002 = La longitud de huella del registro anterior no cumple con las especificaciones.
2003 = El contenido de la huella del registro anterior no cumple con las especificaciones.
2004 = El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de:
2005 = El campo ImporteTotal tiene un valor incorrecto para el valor de los campos BaseImponibleOimporteNoSujeto, CuotaRepercutida y CuotaRecargoEquivalencia suministrados.
2006 = El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados.
2007 = No debe informarse como primer registro, existen facturas emitidas con el obligado emisión y el sistema informático actual.
2008 = El valor de la huella del registro anterior debe ser diferente a la huella del registro actual.

Es por ello que no creo que haya que cambiar nada respecto a esto.

Por último, te agradezco mucho que estés probando esto a fondo, porque queda poco tiempo y hay que detectar cualquier cosa que haya que solucionar.

[IvanHRN]

buenas @almumu

Si en la documentación pone que el RechazoPrevio tiene que ser una X pues perfecto. En cualquier caso, hacienda no me devolvió error al enviarlo.

En cuanto a los filtros de la vista de facturas lo que hemos comentado, entiendo que habría que quitar el filtro verifactu_pending (ya que no existen los estados) y modificar el verifactu_cancelled (sobra un estado).

En relación al error 2004, ¿cuál sería el procedimiento recomendado desde la perspectiva del cliente? Entiendo que la solución pasaría por reenviar la factura para actualizar el campo FechaHoraHusoGenRegistro.

Por último, en cuanto a las pruebas, no hay problema. Estamos todos en la misma situación y cualquier aportación y colaboración es bienvenida.

[almumu]

Dado que el cliente es el responsable de ir supervisando las facturas que den error y subsanándolas según el error que le haya devuelto AEAT, el cliente debe ir a la factura en cuestión que tenga el error y darle al botón de reenviar a verifactu, ya está hecho el proceso de que se envíe la subsanación pulsando ese botón. En el raro caso de que diera el error 2004 simplemente le daría al botón y ya está, porque no tiene que cambiar nada en la factura, pero hay que hacerlo así porque si aeat ya ha devuelto el aceptado con errores, es que esa factura ya existe en AEAT y por tanto hay que subsanarla, y si hay que subsanarla, se tiene que volver a encadenar la factura cuando se quiere volver a enviar con el error subsanado.

Aquí está todo el documento explicativo
https://sede.agenciatributaria.gob.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Veri-Factu_Descripcion_SWeb.pdf

[IvanHRN]

Perfecto, queda todo entendido y aclarado con respecto al error y su resolución.

He seguido realizando pruebas y me he encontrado con que al hacer una venta extracomunitaria hacienda devuelve el siguiente error:

1286 | Si el impuesto es IVA(01), IGIC(03) o vacio, si ClaveRegimen es 02 solo se podrá informar OperacionExenta.

Entiendo que esto quedaría resuelto con el PR #4499 , donde veo que se cambia el mapeo del "IVA 0% Exportaciones" a no sujeto (además de otros cambios).

Buscando en la documentación sobre el error anterior he llegado a los posibles valores del campo RechazoPrevio en el proceso de alta (L17), donde se puede ver que la X es cuando no se ha registrado aún en la AEAT.

No he encontrado más cosas con respecto a la operativa. He probado a realizar ventas y hacer alguna rectificativa con varias posiciones fiscales y salvo la extracomunitaria no he tenido ningún problema.

[almumu]

@IvanHRN efectivamente, hay cosas que no son implícitamente relacionadas con este PR, y el caso que puedas encontrarte depende de otros prs , como el caso de las exportaciones que comentas.

@pedrobaeza cómo lo ves para fusionar esto?