Volver al portfolio
Case Study
01 · 2025Retail · ERPEn producción

Implementación ERP Odoo 18 — Ferretería Aramayo

Dos sucursales, dos catálogos separados y +10.000 productos unificados en un solo ERP.

Rol
Analista · Implementador · Desarrollo · Deploy · Capacitación
Período
2025 – Presente
Equipo
Analista e implementador único + 3 usuarios operativos
Año
2025
10.000+
productos migrados
Catálogo limpiado y normalizado
2 → 1
catálogos unificados
Stock diferenciado por sucursal
3
usuarios capacitados
Transición en paralelo, sin frenar la operación

Dos sucursales, dos sistemas separados y ningún catálogo en común.

La ferretería operaba con dos instalaciones independientes de Adm Global, una por sucursal. Cada una mantenía su propio catálogo, sus códigos internos y su stock, así que un mismo producto podía existir dos veces con nombres y códigos distintos. Con más de 10.000 productos, migrar sin una estrategia significaba trasladar todos esos errores al sistema nuevo.

  • Dos catálogos independientes, sin códigos ni nombres compartidos.
  • Sin visibilidad del stock real consolidado entre sucursales.
  • Actualización de precios fragmentada y casi ninguna capacidad de análisis.

3 fricciones costosas, todos los días.

01

Catálogo duplicado

El mismo producto vivía dos veces, con código, nombre y categoría distintos en cada sucursal. Toda alta o modificación se hacía dos veces.

02

Stock que nadie conocía

Sin un catálogo común no había forma de saber el stock real de un producto ni de ordenar compras con criterio. Las exportaciones del sistema anterior llegaban incompletas y desordenadas.

03

Precios sin política

Las actualizaciones de precio se hacían producto por producto y por sucursal. No existían márgenes por categoría ni una regla consistente que sostener.

Qué no se podía romper.

A.Continuidad

La ferretería no podía dejar de vender ni un día durante la migración.

B.Volumen de datos

Más de 10.000 productos exportados en CSV con columnas incompletas y datos inconsistentes entre sucursales.

C.Usuarios sin experiencia en ERP

Tres empleados acostumbrados al sistema anterior. La adopción tenía que ser gradual y sin fricción.

D.Reversibilidad

Cualquier problema serio tenía que poder resolverse volviendo al sistema anterior sin perder ventas.

Qué se construyó.

Odoo 18 Community centralizado: catálogo unificado con stock diferenciado por sucursal, módulos de Ventas, Compras, Inventario, POS y Facturación adaptados, módulos custom de precios y cuentas corrientes, POS rehecho para operar por teclado, y despliegue en VPS con Docker, Nginx, SSL y backups automáticos.

Stack moderno, pragmático, mantenible.

Sucursal 1POS · CajaSucursal 2POS · CajaBackofficeCompras · PreciosOdoo 18 CommunityVentas · Inventario · POSMódulos customPrecios · Cuentas corrientesNginx + SSLDominio propioDocker en VPSProd + entorno localPostgreSQLCatálogo unificadoBackups Google DriveAutomáticos
Entry pointsInfraestructura
ERP
  • Odoo 18 Community
  • Ventas
  • Compras
  • Inventario
  • Punto de Venta
  • Facturación
Desarrollo
  • Python
  • XML
  • JavaScript (OWL)
  • Módulos custom
Datos
  • PostgreSQL
  • CSV import
  • Limpieza y normalización
  • Deduplicación entre sucursales
Infraestructura
  • VPS
  • Docker
  • Nginx
  • Dominio + SSL
  • Backups automáticos a Google Drive

Tres decisiones que se sostienen seis meses después.

A·01

Odoo 18 Community, no un sistema a medida

El negocio necesitaba ventas, compras, inventario, POS y facturación funcionando en semanas, no un desarrollo desde cero que iba a tardar meses y quedar sin mantenimiento.

Elegido
Odoo 18 Community + módulos custom donde el estándar no alcanzaba
Razón
El 80% de la operación ya está resuelta por el estándar. El desarrollo propio se reserva para lo que realmente diferencia al negocio: precios y cuentas corrientes.
A·02

Catálogo único con stock por sucursal, no dos bases separadas

Se podía replicar la estructura anterior con dos compañías o unificar el catálogo y separar solo el inventario. La primera opción era más fácil de migrar y mantenía el problema original intacto.

Elegido
Un solo producto por artículo, con ubicaciones de stock distintas por sucursal
Razón
Un alta de producto, un precio, un historial. La diferencia entre sucursales pasa a ser dónde está la mercadería, no qué es.
A·03

POS rehecho para teclado, no para pantalla táctil

El Punto de Venta estándar de Odoo está pensado para interacción táctil. En el mostrador se vende desde una computadora con teclado y cada segundo de mouse cuenta.

Elegido
Personalización del POS con atajos de teclado y menos pasos por operación
Razón
Se adapta el sistema al hábito real de los empleados en vez de pedirles que cambien de forma de trabajar en plena migración.

Lo que no estaba en el plan.

  1. Identificar productos equivalentes entre sucursales. Códigos internos distintos, nombres parecidos pero no iguales, categorías diferentes y datos faltantes. Utilicé herramientas de IA para acelerar la limpieza y la transformación inicial, pero definí las reglas de matching, revisé los resultados y validé manualmente cada caso ambiguo.
  2. Convertir un POS táctil en uno operable por teclado. Rehice gran parte de la experiencia del Punto de Venta: navegación por atajos, flujos optimizados para ventas repetitivas y menos pasos por operación, sin romper la compatibilidad con las actualizaciones del módulo estándar.
  3. Módulos custom de precios y cuentas corrientes. Desarrollé en Python, XML y JavaScript una gestión de precios por margen global, margen por categoría y configuración individual por producto, más las cuentas corrientes de clientes según la operación habitual del negocio.
  4. Capacitar sin frenar las ventas. Instalé el acceso en cada equipo y pedí a los empleados replicar en Odoo las mismas ventas que hacían en el sistema anterior. Acompañé cada operación, registré las dificultades reales de uso y ajusté el sistema con ese feedback antes de depender de él.

Lo que cambió, medido.

Estructura de productos
Antes
2 catálogos
Ahora
1 catálogo
Visibilidad de inventario
Antes
Stock por sistema aislado
Ahora
Stock por sucursal en un solo lugar
Política de precios
Antes
Precio por producto y sucursal
Ahora
Márgenes global, por categoría o individual
Infraestructura
Antes
Sin backup ni entorno de pruebas
Ahora
VPS con Docker, SSL y backups automáticos

Lo que me llevo para el próximo proyecto.

  1. Una migración de ERP es principalmente un proyecto de procesos y datos, no una instalación técnica. La limpieza del catálogo resultó más crítica que el desarrollo de funcionalidades.
  2. La adopción se gana adaptando el sistema a la forma real de trabajo. El POS por teclado hizo más por la aceptación que cualquier funcionalidad nueva.
  3. Mantener ambos sistemas en paralelo durante la estabilización redujo el riesgo operativo a casi cero y me dio margen para corregir sin presión.
  4. El desarrollo asistido por IA acelera la transformación de datos, pero las reglas, la validación y la responsabilidad sobre el resultado siguen siendo mías.
Siguiente

¿Querés un proyecto así para tu producto?

Respondo en menos de 24 hs hábiles. Cuanto más concreto el contexto, más rápido te digo si encaja.