[16.0][IMP] l10n_es_vat_prorate: Constrain para prevenir errores manuales

[EmilioPascual]

La cuenta en una apunte marcado con la prorrata del IVA puede ser cambiado manualmente. Con esta restricción se evita que se puedan asingar cuentas no deseadas, como llevarlo al alguna cuenta que esté configurada en la distribución del impuesto.

MT-9939 @moduon

[EmilioPascual]

Vídeo explicativo de la mejora
https://www.loom.com/share/9d07646248114795a0311f41cf92dd85?sid=17739543-eb8e-43a6-9ddf-3561213e362a

¿@rafaelbn @ArantxaSudon @Gelojr @fcvalgar @pedrobaeza @etobella podéis revisar el PR? Gracias.

[rafaelbn]

Muchas gracias @EmilioPascual .

Visto el vídeo y visto en staging y prod. Gracias a esta mejora el módulo es más resiliente y maduro y evita errores que se nos han dado en los clientes y muy laborioso de encontrar y arreglar.

Perfecto! 💯 ❤️ 🎸 ⭐

[ArantxaSudon]

Visto el vídeo y comprobado en el runboat. Perfecto!

Gracias @EmilioPascual

[pedrobaeza]

Aunque comparto que está bien prevenir errores que pueda provocar el usuario, la forma de implementarlo impacta seriamente en el rendimiento, ya que el constraint tiene lugar siempre para todos los apuntes, y como mínimo, hay que comprobar el flag vat_prorate. Si el requisito es que no se permita cambiar la cuenta, que se haga el chequeo precisamente en el write, no siempre vía @api.constrains, que entiendo que además tiene todo ese follón de código de mapeo y demás para que no salte en la creación del apunte.

Además, se debería incluir un test que cubra el caso que se está añadiendo.

[pedrobaeza]

Por qué hace falta todo ese tema del mapeo de la cuenta contable? No se puede pasar un contexto cuando el cambio viene del propio Odoo, y prevenir todos los demás?

[EmilioPascual]

He vuelto al constrain porque después de hacer pruebas es más eficiente, el write se llama muchas veces aunque se haga una salida rápida mientras que el contrain sólo se llama cuando uno de los campos se actualiza.

En cuanto al mapeo es necesario porque las cuentas que se restringen son las cuentas de la reparticiones de impuestos del impuesto originador. Da igual que sea manualmente el cambio o sea el propio odoo el que cometiera el fallo, se quiere prevenir en todos los casos para evitar incongruencias.

[pedrobaeza]

Pues yo personalmente creo que esta sobrecarga es demasiado con el escaso beneficio que trae. ¿Qué piensas tú, @etobella? Una opción sería añadir ese check en un módulo extra para así que fuera opcional. Como una configuración dentro de este módulo no lo plantearía, puesto que al final, como mínimo habría que comprobar esa configuración cada vez.

[etobella]

Personalmente es un mal uso del cliente. Yo no veo añadirlo. Al final es explicarle por que no debe cambiar los impuestos por que si.

[rafaelbn]

@etobella , personalmente no es un mal uso del cliente si no una debilidad del software mal programado permitiendo errores en usos normales. Es decir el software no es resiliente.

Gracias a todos por las revisiones y el entendimiento.

[etobella]

Estais proponiendo esto solo para este modulo, cuando puede pasar con cualquier impuesto. Si os parece grave, podeis hacer algo genérico para que los usuarioa no puedan tocar ciertas cosas de los impuestos, no solo en la prorata. Al final es igual si cambian cosas fuera de la prorata no? O si ponen la cuenta de capital social en una factura. No deben hacerlo pero pueden.

Al final, IMO es cuestión de formar correctamente a los usuarios.