[l10n_es_aeat_vat_prorrate] Concordancia con libro de IVA e informes de IVA

[jalzaga]

De acuerdo con el planteamiento de este módulo, el IVA prorrateado se ajusta contablemente al crear el asiento de regularización de IVA desde el modelo 303. En ese asiento se abona en la cuenta de IVA soportado el porcentaje de IVA no deducible y se carga en la cuenta de gastos. El resultado final es correcto contablemente pero en cualquiera de los informes de IVA no se reflejan esos ajustes. Por otro lado se hace difícil cuadrar la cuenta 472 con el modelo 303 ya que en dicha cuenta no aparecen los ajustes llevados a gastos. Esa cuenta se salda por el total del IVA soportado del periodo. En mi opinión, creo que los ajustes por la prorrata deberían ser independientes del asiento de regularización del IVA y deberían añadir los campos para que se reflejasen en los informes de IVA. En eso quisiera contrastar con vuestras opiniones. Por otro lado, yendo un poco más allá, la prorrata debería ser calculada en el momento de validar las facturas, fundamentalmente porque otros módulos lo necesitan, e.g. el SII necesita reportar el IVA prorrateado: el campo “cuota deducible” se calculará aplicando la prorrata provisional

Agradezco cualquier comentario y aportación que consideréis conveniente.

[AlbertCabedo]

nosotros configuramos impuestos para la prorrata y creo que todo cuadra. En versiones v11 que el 303 lo coge de apuntes contables, entiendo que también, puede que le falte la parte de la regularización del último periodo únicamente. Información prorrata en : https://gafic.com/configurar-la-prorrata-odoo/

[jalzaga]

Muy interesante tu aportación @albertgafic gracias por ella, la estudiaremos para ver cómo encaja. Con esta configuración no sería necesario este módulo.

[pedrobaeza]

Las razones que me llevaron a tomar esa decisión de diseño de generar la diferencia de prorrata en el 303 y no factura a factura fueron:

1. Evitar tener que reconstruir facturas por no haber introducido una prorrata cuando se empezaron a meter dichas facturas. Así, demoramos indicar ese porcentaje hasta la declaración del 303.
2. Para ser tolerante a errores (no será la primera vez que alguien pone mal el porcentaje de prorrata...). Con este método, es muy sencillo de corregir.
3. Ser flexible con contabilidades importadas, como todo lo que hemos estado haciendo en la localización para olvidarnos de esa dependencia de facturas.
4. Un cuadre más sencillo de la última declaración del año, en la que el porcentaje de prorrata provisional da paso al porcentaje definitivo, y así no hay que corregir todos los gastos del último trimestre, si no que esos ya salen bien, y solo hay que llevar a la cuenta de regularización de la prorrata lo de los anteriores periodos. Otros software llevan todo el descuadre de todos los periodos a esa cuenta, y eso hace el análisis financiero más inexacto.

Ahora bien, cuando hice ese diseño, no estaban en juego ni SII ni el libro de IVA.

Para el libro de IVA, no sería muy difícil añadir los impuestos en el asiento de regularización, y entonces el mismo saldría cuadrado de la misma forma (se puede considerar un TODO del módulo). Pero antes de todo esto, habría que ver realmente cómo hay que indicar esta situación con el nuevo libro de IVA normalizado.

Para el SII sí podría suponer algún problema mayor, sobre todo para evitar errores de redondeo, y claro, ya perderíamos las ventajas 1, 2 y 4 expuestas. Pero un posible diseño para solucionarlo sería:

• Tener a nivel de compañía definido por años esos porcentajes.
• Añadir a nivel de account.move el porcentaje de prorrata aplicado, y a nivel de account.move.line, el importe de dicha prorrata.
• Añadir a nivel de account.invoice ese porcentaje, y a nivel de account.invoice.tax los importes prorrateados (base y cuota), compute en base al porcentaje y a los importes
• Trasladar la información al crear el asiento desde la factura.
• Al enviar el SII, se envía los importes calculados.
• En el 303, se leen esos datos de los apuntes, se podrían comprobar incoherencias, y se ponen en la declaración, pero la generación del asiento de regularización sigue siendo la misma, asegurando la utilización de los importes grabados.
• El último trimestre, habrá que cambiar el código para poner el ajuste con la diferencia total incluido ese trimestre.

Otra opción es formalizar el cambio en los impuestos que propone Albert, creando un módulo que amplíe el plan contable español con los mismos, e incluso utilizando el account_tax_python para calcular dinámicamente ese porcentaje cogiéndolo de otra tabla, y luego añadiendo también el correspondiente módulo que amplíe el SII para lidiar con esos impuestos y enviarlo correctamente.

[pedrobaeza]

@jalzaga qué vas a hacer al final?

[jalzaga]

@pedrobaeza En mi opinión, creo que utilizando la opción de @albertgafic quedan resueltos la mayoría de los casos, hemos hecho las pruebas configurando impuestos, mapeos, etc. y llegamos a las siguientes conclusiones.

1. El uso de grupos de impuestos resuelve bien los cálculos de la prorrata general y es totalmente estandar. se ajusta perfectamente a los pedidos de compra, las facturas de proveedor y los apuntes contables.
2. Respecto a los informes fiscales, si se incluyen los mapeos necesarios en los modelos no encuentro dificultades.
3. La prorrata especial también quedaría contemplada ya que se utilizarían los tipos de iva deducible, no deducible y prorrateable según las necesidades
4. Respecto al SII, según la AEAT en las FAQ se puede ver: ¿Debe facilitarse a través del SII información sobre la prorrata? La información sobre el porcentaje de prorrata aplicable se ofrecerá a través del modelo 303 o 322. No obstante, debe tenerse en cuenta respecto al SII lo siguiente: • el campo “cuota deducible” se calculará aplicando la prorrata provisional. • En el caso de bienes de inversión, deberá suministrarse con carácter anual la información correspondiente a las regularizaciones que procedan en el Libro registro de bienes de inversión. No sería necesario hacer modificaciones, solo añadir los tipos de IVA a los mapeos.
5. Habría que añadir los nuevos tipos de IVA, ampliar los mapeos de impuestos de los modelos afectados , incluido el libro de IVA, y ampliar las posiciones fiscales.

[pedrobaeza]

Bueno, si como he dicho, no es mala solución, pero tiene la pega del control financiero en el 4T. De momento, nosotros seguimos con el cliente que tiene esto de la prorrata en v10 con los módulos existentes, ya que no tienen SII, y lo del libro de IVA está aún en ciernes y no sabemos cómo va lo de la prorrata. Cuando migremos a v12 a finales de año, volveré a esto.

[pedrobaeza]

Por vuestra parte, si queréis implementar esta opción para v11/v12, yo revisaré como siempre para ayudar.

[pedrobaeza]

Finalmente para v12 sigo de momento con el mismo enfoque en #1356 porque mi cliente dice que "ni por asomo" quiere perder la flexibilidad que este mecanismo le ha otorgado. Ellos no tienen SII, pero el libro de IVA sí que lo ajustaremos acorde a cómo deba salir la información de prorrata.

[HaraldPanten]

@pedrobaeza Estaba revisando este hilo y creo que podemos cerrarlo al estar fusionado el #1356. Con lo cual resolvemos vuestra casuística y también contamos con las indicaciones de Albert como alternativa.

[pedrobaeza]

Bueno, realmente la parte del libro de IVA queda aún pendiente de revisar, así que lo dejamos así hasta entonces.

[HaraldPanten]

OK

[github-actions[bot]]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.