Muchas veces en Odoo es necesario contar con la información histórica. Tener el historial de pedidos de venta y de compra nos permite hacer muchas cosas. Entre ellas segmentar nuestros clientes (usando RFM por ejemplo) o clasificar nuestros productos (lo que cubriremos en otros posts).
xmlrpc
Como lo hacemos? Primero debemos conectarnos al sistema origen y obtener los datos de este. Para esto prefiero hacerlo con xmlrpc por tres motivos. El primero es que no me gusta crear un módulo que va a quedar en Odoo solo para cargar datos históricos. A la larga termina creando problemas.
El otro motivo es que un script de xmlrpc es más flexible que un módulo de Odoo. Por ejemplo no necesito reiniciar Odoo cada vez que tengo que cambiar el script. También podes usar las librerías que necesites. Podes instalar pandas, conectores con otras bases de datos, todo eso sin necesitar de tocar las librerías que utiliza Odoo.
El tercer motivo es que por cada actualización; Odoo hace un commit. Cada registro que leo en el sistema origen me crea un registro en el sistema destino. En cambio con un módulo ello no ocurre, uno debe forzar un commit (lo que módulos como Mercadolibre se ven obligados a ignorar) sino corremos el riesgo que los cambios relacionados en las actualizaciones se pierdan frente al menor problema.
El cuarto motivo que se me viene a la mente es que Odoo los procesos de carga de datos históricos tienden a ser procesos de larga duración, lo cual se lleva a las patadas con la configuración de Odoo que está pensada para operaciones que duren como mucho pocos minutos (lo que se lleva a las patadas con las operaciones batch, pero bueno... es uno de los límites de la arquitectura de Odoo)
El quinto motivo es que mediante los scripts de xmlrpc, puedo (con un gran esfuerzo de desarrollo) acelerar los tiempos de carga utilizando el método load (del que hablamos en este post). Un gran problema de la carga de datos históricos es que debemos cargar miles de registros y en esto Odoo no nos da una gran mano. Muchas veces la solución viene de la mano de soluciones como el método load.
Modificaciones a Odoo
Cuando cargamos datos históricos debemos extender Odoo de forma tal que cuando se confirme un pedido de venta histórico; no se genere una transferencia de stock y no se cree una factura. Por ejemplo; para los pedidos de venta podemos extender el método _action_launch_stock_rule del modelo sale.order.line de forma tal que no invoque la creación de procurements (si el pedido de venta es un pedido histórico). Por ejemplo (para Odoo 19)
def _action_launch_stock_rule(self, *, previous_product_uom_qty=False):
"""
Launch procurement run method with required/custom fields generated by a
sale order line. procurement will launch '_run_pull', '_run_buy' or '_run_manufacture'
depending on the
"""
# PONER LOGICA PARA IDENTIFICAR PEDIDO HISTORICO d
if pedido_historico:
El punto fundamental aca es, si podemos identificar los pedidos históricos podemos extender los métodos que crean transferencias y facturas; y podemos evitar que se creen estas operaciones en caso que se confirmen los pedidos históricos.
Por lo general uno debe agregar una columna extra para identificar el registro que se está importando en el sistema origen. Por ejemplo, podemos extender el modelo de res.partner agregando una columna extra llamada old_id; que contendrá el identificador del sistema origen y permitirá identificar los clientes del sistema legacy.
class ResPartner(models.Model):
_inherit = 'res.partner'
old_id = models.Char('old_id')
Algunas consideraciones
Los datos se van a almacenar en los modelos propios de Odoo. Si uno tiene pedidos de venta o pedidos de compra en el sistema legacy; se deben actualizar los pedidos de compra y pedidos de venta en Odoo. Si uno cuenta con facturas de compra o facturas de venta en el sistema legacy; uno debe actualizar los pedidos de compra o pedidos de venta en Odoo. No vale la pena crear asientos contables que ensucien la contabilidad con información histórica.
Por otra parte, si uno desea cargar las facturas y pagos; lo mejor es cargar los asientos contables y agregar la información de pago o factura al asiento contable. Es muy problemático cargar facturas junto con sus impuestos como para lidiar con la información histórica.
Por último, hay que tener en cuenta la moneda de la operación. En Argentina recomiendo cargar todas las operaciones históricas en USD. Si las cargamos en ARS vamos a terminar comparando peras con bananas. En cambio si la cargamos en USD; tenemos al menos dos años (estamos en 2026) de información financiera que es mucho más estable que si cargamos la información en ARS.
Hacerlo no es dificil. Primero debemos cargar el histórico del dolar en el sistema (solo necesitamos cargar un excel con la cotización histórica del dolar, dicha planilla la podemos obtener de Claude o Chatgpt por ejemplo). Y luego solo necesitamos convertir las operaciones al USD (en este post mostramos un ejemplo sobre como hacerlo). Como pueden ver, no es el fin del mundo.