Ir al contenido

¡Bienvenido a los foros Aeodoo!

Somos la comunidad de Odoo internacional hispanohablante.
Estos foros son para compartir y debatir dudas técnicas, funcionales y mejores prácticas para Odoo. Recuerda que no están permitidos los insultos, descalificaciones o spam, cualquier conducta reprobable supondrá el baneo del usuario.

 
Ocultar IntroRegistro

Esta pregunta ha sido marcada
1 Responder
55 Vistas

Como muchos sabréis por experiencia, uno de los históricos dolores de cabeza para la gestión de autónomos en Odoo es el tratamiento de las facturas con deducibilidad parcial. El clásico ejemplo del vehículo afecto al 50% o los suministros del hogar al 30%, donde parte del IVA soportado no es deducible y debe pasar a ser mayor valor del gasto para el IRPF.

Hemos estado trabajando en una arquitectura limpia para resolver esto en Odoo 18.0 y hemos creado el módulo l10n_es_autonomo.

¿Qué hace exactamente el módulo?

  • Perfiles Dinámicos: Permite crear perfiles de deducibilidad (ej. "Gasolina 50%") y asignarlos por defecto a Proveedores o Productos.
  • Transparencia en Factura (UI): Añade un banner reactivo que calcula en tiempo real (mientras estás en borrador) la Cuota Deducible y el Gasto Neto final.
  • Reclasificación en el _post: Al confirmar la factura, el motor intercepta los Journal Items. Reduce la cuota de la cuenta 472 (IVA Soportado) y engorda automáticamente la cuenta del gasto base (6xx).
  • Auditoría Fiscal: Añade una pestaña técnica en la factura donde el gestor puede ver exactamente la base, el IVA original, el IVA no deducible reasignado y el asiento resultante para futuras inspecciones.
  • Compatibilidad AEAT: Al modificar los apuntes contables reales, el Modelo 303, el Modelo 115 y los informes de Pérdidas y Ganancias (130) salen cuadrados por defecto y sin tocar el "core" de los informes de Odoo.

El objetivo de este post: Queremos que lo rompáis

Antes de hacer la propuesta oficial y abrir la Pull Request a los repositorios de l10n-spain de la OCA, queremos estar seguros de que cubre todas las casuísticas reales de las gestorías.

Por eso, lo hemos subido a un repositorio público independiente para iniciar una fase de beta testing con la comunidad. Nos gustaría que los que trabajáis habitualmente con contabilidad de autónomos lo clonéis, lo probéis en vuestras bases de datos de test y nos deis feedback.

🔗 Repositorio de pruebas: [https://github.com/GutierrezTi/gti_odoo_modules]

Cualquier issue, sugerencia de mejora, caso de uso no contemplado o Pull Request directamente en este repositorio temporal será más que bienvenida.

Creemos que entre todos podemos depurarlo y dejarlo con un nivel de "calidad industrial" antes de enviarlo a AEODOO.

¡Gracias de antemano por vuestro tiempo y vuestro feedback!

Un saludo,

Avatar
Descartar

Hola, Joaquín,

En realidad, este problema podría ser de cualquier empresa, no solo de los autónomos, y se podría llamar l10n_es_vat_partial_non_deductible. Además, el tratamiento ya lo tenemos gestionado en l10n_es_vat_prorate, que igualmente utiliza un porcentaje (el de prorrata), para llevarlo como mayor valor del gasto. Sería utilizar ese mismo motor para inyectarle el porcentaje. Se podría extraer el motor a un módulo común, y que uno y otro lo utilicen con el porcentaje y parametrización adecuados.

Avatar
Descartar
Autor

Hola Pedro
¡Muchas gracias por la rápida respuesta y por el análisis!
Tienes toda la razón en ambas cosas. Efectivamente, acotarlo solo a "autónomos" es un error de concepto por nuestra parte, ya que cualquier S.L. con vehículos de renting o dietas se enfrenta a este mismo escenario. El nombre l10n_es_vat_partial_non_deductible encaja perfectamente.
También compartimos la visión de no reinventar la rueda y extraer la lógica de reclasificación del IVA a un módulo común (core) del que puedan beber tanto la prorrata como la deducibilidad parcial.
Te cuento por qué lo habíamos enfocado inicialmente como un módulo aislado: Nuestra obsesión principal era la usabilidad y la inminente llegada de VeriFactu.
Sabemos que con VeriFactu, confirmar una factura significa firmar un asiento que ya no se puede alterar. Por eso, diseñamos el módulo volcando mucho esfuerzo en la "capa visual" (UI/UX) para darle tranquilidad al usuario final:
· Un banner que precalcula los totales de deducción mientras la factura sigue en borrador.
· Una pestaña de "Ajuste Fiscal" que desglosa línea por línea el IVA original, el no deducible y cómo queda la base antes de asentar.
Nuestra prioridad es mantener esa agilidad, sencillez y transparencia visual, pero integrándolo en la arquitectura robusta que propones.
¿Cómo ves esta propuesta de trabajo conjunto?
1. Extraer el motor: Ayudamos a separar la lógica actual del l10n_es_vat_prorate hacia un módulo base (ej. l10n_es_vat_reclassification_core). Este motor recibiría porcentajes y se encargaría puramente del Journal Entry (el _post).
2. Adaptar Prorrata: El módulo de prorrata actual pasaría a inyectar a ese core sus porcentajes globales de empresa.
3. Módulo (ej. l10n_es_vat_partial_non_deductible): Mantendríamos toda la interfaz visual que hemos desarrollado (los perfiles por proveedor/producto, el banner en tiempo real y la pestaña de auditoría), pero su única función técnica será calcular y enviarle los porcentajes por línea a ese nuevo módulo core en el momento de asentar.
Creemos que así sumamos lo mejor de los dos mundos: la arquitectura unificada y óptima que exige la OCA, y la experiencia de usuario transparente que necesitan las empresas frente a VeriFactu.
Si la hoja de ruta os parece bien, nos ponemos a vuestra disposición para empezar a "despiezar" y adaptar el código.
Un saludo y gracias de nuevo por la guía,

Publicaciones relacionadas Respuestas Vistas Actividad
1
feb. 26
333
1
ene. 26
468
1
ene. 26
377
2
ene. 26
419
3
nov. 25
577