El 08/08/14 a les 16:45, Jordi Esteve ha escrit:
On 08/08/14 16:25, Sergi Almacellas Abellana wrote:
El 08/08/14 a les 15:41, Jesús Martín Jiménez ha escrit:
Hola a todos,
He hecho este merge propose donde sobre escribo el método
on_change_lines de sale.sale para mejorar el rendimiento del módulo.
La mejora es considerable puesto que tarda del orden de 1/100
respecto al método del módulo oficial (sale). El problema es que el
diseño no es correcto porqué en ningún momento se vuelve a llamar al
método padre y eso puede llegar a romper algún otro módulo que
herede el mismo método. ¿Alguien tiene una idea mejor de como
solventar el problema?
Justo esta semana estaba Nico tocando ese código. Puedes probar si
esto mejora con este review:
http://codereview.tryton.org/9561002/
No, no creo que este review de Nicoe mejore el rendimiento. Este
review sirve para unificar la forma de calcular los impuestos en
facturas, ventas, compras.
Pues ese es justo el momento para intentar mejorar el rendimiento, así
lo tenemos para facturas, ventas, compras y cualquier otro modelo :P
No me he mirado el review a fondo, por eso lo he apuntado, por si puede
ayudar. Además igual se puede aprovechar la api que estan creando, para
que se utilizen los campos funcionales ya guardados en las línias y así
evitar tener que sobreescribrir el on_change_lines de esa forma. Y sinó
se puede aprovechar, haciendo unos pocos comentarios se puede conseguir
que sea aprovechable. Todo es discutir-lo ;)
El merge proposal de Jesús
https://bitbucket.org/aneolf/trytond-sale_pos/commits/48a2f8af2f8118331e9138f9f7452bb3b3858413
redefine el cálculo de la base imponible, impuesto y total de la venta
a partir de los valores ya calculados en cada línea de venta (importe
sin y con impuestos) que ya se calculan en el sale_pos.
Esto mejora mucho el rendimiento en ventas con muchas líneas, ya que
sinó, por cada modificación de una línea (cambiar el producto,
cantidad, precio, descuento) implica el recálculo de la base
imponible, impuesto y total de la venta, y el módulo sale calcula los
impuestos de cada línea, los agrupa por impuesto, los redondea, los
vuelve a sumar y redondea el impuesto y total obtenidos.
Me imaginaba que era por eso, ahora entendido el problema :)
Esta propuesta tiene dos inconvenientes como apuntaba Jesús:
1) Sustituye el método on_change_lines de sale.sale completamente sin
hacer super para hacer el cálculo mucho más rápido.
Esto hace incompatible el sale_pos con el sale_shipment_cost ya que este
segundo tambien sobreescribe el on_change_lines, y por lo tanto no se
llamaría. De todos modos ya existia un módulo sale_pos_shipment_cost verdad?
2) El impuesto y el importe total de la venta calculado con el nuevo
on_change_line puede tener algunos céntimos de error respecto al
calculado originalmente, ya que no es lo mismo sumar los impuestos
redondeados línea a línea, que sumar impuestos de todas las líneas y
redondear por impuesto. Pero es un problema menor, cuando se guarda la
venta ya se muestra el impuesto y el importe total de la venta
correcto, pues entonces ya se usan los campos funcionales.
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
