[16.0][FIX] l10n_es_vat_prorrate: Method _compute_with_vat_prorate is not running in some times
#4401
Conversation
… computed in some times In some times the method `_compute_with_vat_prorate` is not running before the account move line is created, so the account move line is not prorated. With this fix, the field is computed always when it is invisible because it will be readonly MT-11182 @moduon
|
Un poco más de contexto ayudaría a valorar el problema. |
pedrobaeza
changed the title
_compute_with_vat_prorate is not running in some times_compute_with_vat_prorate is not running in some times
|
Efectivamente, ¿cuáles son esos "In some times"? Además, esto parece estar trucando un poco el ORM para ponerlo |
La verdad es que no tengo muy claro el motivo pero desde que entraron los cambios de la prorrata especial #4287 empezamos a recibir incidencias de que había facturas en las que no se estaba haciendo la prorrata. Tras estudiar los casos nos dimos cuenta que el problema era que el nuevo campo Tras depurar los casos vimos que no se estaba ejecutando el método Al ponerlo Supongo que el error será algún fallo en el ORM de Odoo. No he podido profundizar más, estamos al final del trimestre y los impuestos tienen que estar correctos. |
|
¡Hola! ¿Debemos entender que esto nunca se va a mezclar @OCA/local-spain-maintainers ? ¿Esto rompe algo? ¿arregla algo? ¿Cuantos clientes / instancias usan este módulo? Si nosotros somos mantenedores de este módulo y le hemos dedicado ya una cantidad de horas muy importantes no sería esto suficiente para entender que esto se debe mezclar. Habrá clientes que tenga este error y ni se estén enterando.... Abracitos ❤️ PD: me ha dicho mi equipo técnico que nos da igual porque el PR lo tenemos aplicado y listo, pero no me parece entonces que nadie más que nosotros se beneficie de esto... |
|
@rafaelbn no se mergeará hasta que se respondan las preguntas que se hicieron. Se especificó claramente. Preguntamos un: ¿por que? Y la respuesta de Emilio es un: No sé, bueno, he visto que lo resuelve... si no se descubre el motivo yo preferiría no tocar hasta entenderlo. Antes de empezar a pedir reviews y merge, te recomendaría que revisaras los últimos 3 comentarios del PR para decidir si puedes dar este tipo de respuestas. A mi personalmente, no me gusta que me envíes un comentario pidiéndome un merge cuando se ha especificado el por que no y no se ha respondido. En mi opinión, deberías haber contactado con tu equipo para que respondan a la pregunta realizada. Sinó, lo que haces es que yo tenga que dedicar mi tiempo a responder este PR cuando no seria necesario, ya que está en las manos de moduon. Personalmente, esto crea un gran hartazgo dentro de la comunidad. Lo siento si parezco el malo de la película, pero no es la primera vez que lo haces y es un poco cansado. Todos tenemos nuestros trabajos y no era necesario que yo le dedicará estos 10 minutos a responderte cuando podría haber revisado un PR que estuviera preparado para ser mergeado (tu también habrás dedicado tiempo, o sea que también podríamos contarlo). En resumen, ambos estamos perdiendo el tiempo discutiendo en esto cuando seguro que podemos hacer cosas más productivas. |
|
Chicos, vamos a ser prácticos y a beneficiar a la Comunidad. @rafaelbn podéis aclarar los casos en los que ocurre lo que comentaba @EmilioPascual ? Habéis podido descubrir un "por qué" que sea preciso? Evidentemente es algo que interesa resolver para toda la Comunidad. Muchas gracias de antemano por la investigación y las aportaciones 💪🏻 |
|
@etobella perdón por no llegar al desencadenante del error, perdón por malgastar 10 minutos de tu valioso tiempo en leer los comentarios de un PR de la comunidad. Yo le he dedicado bastantes horas desde agosto que se fusionó el PR de la prorrata especial. Por mucho que lo he intentado, no consigo reproducir el error en ningún entorno, pero no quiere decir que el error no esté sucediendo. Cada día había un mínimo de 2 facturas donde no se calculaba la prorrata y todo porque no se ejecutaba el compute antes del create. Quizá fue ingenuo por mi parte el intentar dar una solución a la comunidad, o quizá el fallo fue pensar que podría obtener ayuda de los grandes desarrolladores de la localización española para mejorar el fix. He compartido el proceso por el que he llegado al fix, puede que insuficiente para ti o los mantenedores del repositorio, pero es lo que tengo. Como ha dicho Rafa, nosotros lo tenemos desplegado y desde entonces no ha vuelto a suceder el error. Hemos tenido que corregir todos los impuestos que no se habían prorrateado. Ahora hemos revisados todos los impuestos de la prorrata y están bien, espero que todo el mundo pueda decir lo mismo a la hora de presentarlos en estas fechas. |
|
Hola @EmilioPascual , El caso es que hay otras empresas que también utilizan el módulo. Nosotros, por ejemplo, tenemos a clientes que lo utilizan. Si nos centramos en el objetivo final (resolver un error) necesitamos algo más de info. ¿Sabes lo que te quiero decir? Con la información de la que disponemos ahora tenemos una posible solución, pero para un problema no detectado y que no hemos podido reproducir el resto. Para poder aceptar el cambio (que no te digo que no tengas razón) necesitamos saber el origen, para tener claro qué es lo que lo genera. Solo falta un origen claro. Gracias por la aportación. |
7 participants
In some times the method
_compute_with_vat_prorateis not running before the account move line is created, so the account move line is not prorated.With this fix, the field is computed always when it is invisible because it will be readonly
MT-11182 @moduon
@yajo @pedrobaeza @etobella revisad por favor