Refactorización centrada en la mejora del rendimiento - issue 57
En este MR se realizaron varios cambios orientados a mejorar el rendimiento de una funcionalidad previamente hecha (de los MR: !22 (merged), !23 (merged) y !24 (merged)) asociada a la issue coodesoft/polcecal#57.
Estado de situación
La issue coodesoft/polcecal#57 solicita que haya integridad entre la información que se visualiza en el sistema y la que se imprime. Una de las patas de la issue es la vinculación entre los remitos y las facturas. Esta requería que se pudieran visualizar los remitos tanto en el detalle de la factura como en el listado puesto que se pueden visualizar en el pdf.
Vista de litado de facturas | Vista de detalle de factura en PDF |
---|---|
![]() |
![]() |
- Cambios implementados en los MRs !22 (merged) y !24 (merged).
Cuál es el problema?
Que el código de esos MRs resulta ser ineficiente para cargas de trabajo grandes (lease, miles o decenas de miles de facturas - hoy hay mas de 3k de facturas - y remitos), puesto que por cada factura que lista, realiza una búsqueda en la db sobre los remitos existentes cuyo documento de origen coincida con el de la factura. Para unas cientos de facturas no hay problema, pero a medida que crece el número, crece el tiempo de espera. Esta implementación previa, surgió a partir de que Odoo, no vincule desde el origen los remitos a las facturas, durante el circuito de venta + facturación. Hasta ahora, una factura que se generó a partir de un remito, solo guarda un texto con el Documento de origen del remito.
Detalle de factura | Detalle de remito |
---|---|
![]() |
![]() |
Cuál es la mejora implementada en ese MR?
- Se realizó: 8271cfdd
- una vinculación muchos-a-muchos entre las facturas y remitos:
stock_picking = fields.Many2many('stock.picking',...)
. - se implementó el método
add_remitos(self)
que es el responsable de vincular modelo a modelo, los remitos y las facturas. - se sobreescribió el método
create(self, vals_list)
responsable de crear una factura para que ejecute el método previo. - se reimplementó el método
_get_remito(self)
->get_remitos_srt(self)
para que solo calcule la representación en texto de los remitos ya vinculados.
- una vinculación muchos-a-muchos entre las facturas y remitos:
- Se definió un hook
post_init_runner(cr, registry)
que se ejecuta luego de la instalación del módulo (hay que reinstalarlo) y que realiza esta vinculación para todas las facturas preexistentes. De esta manera luego de la instalación del módulo ya nos queda la db actualizada. cc5758b6 - Se agrega la definición del hook en el manifesto y se actualiza la versión del módulo. 507ab7eb
- Se actualizan las vistas con los nuevos nombres de las relaciones del modelo. 9f3a0486