[18.0][FIX] l10n_es_vat_prorate: Antes de publicar la factura, verificar que la prorrata se ha aplicado

[Andrii9090]

En algunas instancias de nuestros clientes se ha detectado una situación rara en la que facturas de proveedor que deberían incluir líneas de prorrata no las generan.

El problema se ha resuelto manualmente volviendo la factura a borrador y confirmándola de nuevo (sin cambiar nada), lo que provoca que la prorrata se calcule correctamente.

Estas situaciones no han podido reproducirse ni en entorno local ni en Runbot.
Para evitar este problema, proponemos el siguiente fix:
Antes de publicar la factura, comprobar:

• si la empresa tiene prorrata configurada,
• si las líneas de factura están sujetas a prorrata,
• y si no existe ninguna línea de apunte contable correspondiente a la prorrata.
  En caso de cumplirse estas condiciones, recalcular la prorrata llamando al método
  _apply_vat_prorate del modelo account.move.

@moduon
MT-13468

[OCA-git-bot]

Hi @EmilioPascual, @rafaelbn,
some modules you are maintaining are being modified, check this out!

[rafaelbn]

Muy buena mejora. Resiliencia.

[christian-ramos-tecnativa]

Estoy a favor de la comprobación, pero no me gusta nada hacer cosas que modifiquen la factura durante la validación. Ya que estás validando una factura que consideras correcta pero luego puede presentar datos distintos y esto puede confundir al usuario. ¿No podríamos transformarlo en un raise directamente? Indicando en el error que pasando la factura a cancelado y a borrador de nuevo debería generar el vat correctamente

[Andrii9090]

He cambiado el código, ahora

• si la empresa tiene prorrata configurada,
• si las líneas de factura están sujetas a prorrata,
• si los impuestos de la factura tienen with_vat_prorate=True
• si no existe ninguna línea de apunte contable correspondiente a la prorrata.
  En caso de cumplirse estas condiciones, salta un raise

Además, he establecido el campo with_vat_prorate de account.move.line como readonly en el caso de prorrata general, para evitar que el ORM lo establezca a False por defecto durante el cálculo de las líneas de prorrata.

@EmilioPascual puedes revisar de nuevo?

[christian-ramos-tecnativa]

Gracias por cambiarlo a un raise, un pequeño comentario

[christian-ramos-tecnativa]

La condición del readonly es la misma que el column_invisible, por lo tanto se hace readonly cuando está invisible, no hace nada en realidad. Ya que el readonly en la vista aplica solo al usuario por la interfaz, no a las acciones por ORM

Suggested change

readonly="not parent.with_special_vat_prorate or parent.move_type not in ['in_invoice', 'in_refund']"

[pedrobaeza]

Este parche vuelve a ser lo mismo que en 16 con #4401, y los comentarios serían los mismos: ¿cuál es la razón/pasos para reproducirlo y por qué este hack es la solución?