DOC. NIO-CASOSCasos de campo

Experiencia aplicada,
resultados documentados.

Estos casos resumen mi experiencia profesional como desarrollador y consultor Odoo — el criterio de diagnóstico que hoy aplico en NioSystems. Los detalles han sido generalizados para proteger la confidencialidad de cada cliente y empleador anterior.

  • 10 casos documentados
  • Distribución · Manufactura · Restaurantes · Salud · Construcción · E-commerce
  • Guatemala · Centroamérica · LATAM · v10 → v19
CASO-01Distribución mayorista

Precios por zona, recompensas de volumen y fuerza de ventas en campo

Contexto

Distribuidora con tres centros de distribución y red de ruteros cubriendo el sur del país. Cada zona opera con rentabilidad y políticas de fidelidad distintas. El equipo en campo registra pedidos desde dispositivos móviles con conectividad intermitente.

Problema identificado

Los precios de lista no reflejaban ni la zona del cliente ni el volumen acumulado del período. Los cálculos correctos se hacían en hojas de cálculo externas y luego se introducían manualmente en Odoo, generando descuadres frecuentes entre lo facturado y lo cobrado en ruta.

Intervención

Lógica de precios multi-zona dentro del motor de listas de precio de Odoo, con reglas de volumen acumulado por período comercial. Adaptación de las vistas de la app móvil de ventas para operar sin conexión con sincronización diferida. Múltiples unidades de medida por SKU según destino de distribución.

Resultado

Eliminación del proceso de cálculo manual externo. Los ruteros cotizan y confirman precios correctos desde el campo. Cero descuadres en cierre de período desde la implementación.

  • Distribución
  • Multi-zona
  • App móvil
  • Múltiples UoM
  • Offline-first
CASO-02Importación / Comercio exterior

Diagnóstico y corrección de sobrevaloración de inventario de Q1,000,000

Contexto

Importadora de equipo industrial con alto flujo de contenedores. Valoración de inventario en costo promedio estándar de Odoo, con documentos aduaneros procesados manualmente como ajuste posterior al ingreso.

Problema identificado

Auditoría contable detectó una diferencia de ~Q1,000,000 entre el valor contable del inventario y el valor real, acumulada en ~120 movimientos durante meses sin alerta del sistema. La causa raíz no era evidente: una modificación previa de otro desarrollador alteró el recálculo de un campo contable, haciendo que el precio del primer producto afectado se arrastrara a través de toda la cadena de valoración posterior.

Intervención

Trazado de la cadena de valoración movimiento a movimiento hasta identificar el campo y la línea de código fuente responsable. Corrección del comportamiento. Desarrollo de módulo de prorrateo con referencia al DUCA (documento aduanero), que distribuye el costo de aterrizaje real en el momento del ingreso — no como ajuste retroactivo.

Resultado

Diferencia contable corregida. El módulo de prorrateo elimina la carga manual y previene la acumulación de la discrepancia en ciclos futuros.

  • Inventario
  • Valoración
  • DUCA
  • Importaciones
  • Código fuente Odoo
CASO-03Restauración / Food service

Configuración de contabilidad anglosajona consumía 53% de la memoria de instancia

Contexto

Cadena de 5 puntos de venta con POS de alto flujo. Los reportes de cierre diario comenzaron a tardar varios minutos y colapsaban la instancia en horas pico. El equipo había migrado dos veces a servidores con más RAM sin mejora sostenida.

Problema identificado

La instancia tenía activada la configuración de contabilidad anglosajona — una opción por defecto de Odoo que en instalaciones de bajo volumen es inocua, pero en operaciones de alto flujo genera millones de líneas en el diario de valoración de inventario. Una consulta de agregación sobre esa tabla en cada cierre de POS consumía 53% de la memoria total de la instancia.

Intervención

Análisis de consultas SQL activas durante un cierre de POS para identificar la consulta responsable. Trazado hasta la configuración contable. Desactivación de la opción anglosajona y limpieza de las entradas de diario generadas incorrectamente.

Resultado

Uso de memoria normalizado en el siguiente cierre. Sin cambio de hardware. El problema de rendimiento que había "requerido" dos actualizaciones de servidor era configuración — no capacidad.

  • POS
  • Rendimiento
  • Contabilidad
  • SQL
  • Restaurantes
CASO-04Hotelería / Restauración · Instancia propia

Condición de carrera en POS: empleados eliminaban órdenes ya cobradas

Contexto

Hotel con restaurante de alto volumen. El POS de Odoo incluye protección estándar contra cancelación de órdenes cobradas, pero la mitigación estándar tiene una ventana de vulnerabilidad específica.

Problema identificado

Empleados enviaban la orden a comanda y la eliminaban durante ese envío — exactamente en la ventana en que el estado de pago había sido iniciado pero aún no confirmado. La mitigación estándar de Odoo no cubre esa transición. El dinero cobrado físicamente no quedaba registrado en el sistema.

Intervención

Análisis del flujo de estados del módulo de POS en el código fuente. Identificación de la ventana exacta de la condición de carrera. Parche sobre el núcleo de POS que bloquea la eliminación cuando el estado de pago ha sido iniciado, independientemente del progreso de la sincronización.

Resultado

Vulnerabilidad cerrada. El parche es transparente en uso normal y bloquea específicamente la condición de explotación.

  • POS
  • Seguridad
  • Condición de carrera
  • Núcleo Odoo
  • Hotelería
CASO-05Restauración · Instancia SaaS oficial

El mismo fraude de POS, sin acceso a código: solución por configuración y trazabilidad

Contexto

Dos restaurantes operando en la instancia SaaS oficial de odoo.com. Se identificó el mismo patrón de fraude interno que en CASO-04 — empleados manipulando órdenes para retener efectivo — pero sin posibilidad de modificar código.

Problema identificado

En SaaS oficial no hay acceso al código fuente ni a la base de datos. Las mismas restricciones que hacen el entorno más seguro para el operador también impiden aplicar el parche a nivel de código. La vulnerabilidad en esa versión no estaba resuelta por Odoo.

Intervención

Diseño de un esquema de permisos restringidos para cajeros que elimina el acceso a funciones críticas innecesarias. Implementación de un sistema de trazabilidad de estado de caja que registra la actividad del empleado durante el turno, generando una auditoría visible para el administrador sin intervención manual.

Resultado

Vector de fraude cerrado mediante configuración y visibilidad operativa. La solución es replicable en cualquier instancia SaaS sin tocar código.

  • POS
  • SaaS
  • Seguridad
  • Permisos
  • Trazabilidad
CASO-05Salud / Sector público

Automatización de formatos de facturación para contratos IGSS

Contexto

Intermediaria de equipo médico con contratos activos con el Instituto Guatemalteco de Seguridad Social y otras entidades de gobierno. Cada entidad exige un formato de factura con campos, distribución y numeración específicos.

Problema identificado

El equipo administrativo reconstruía manualmente el formato de cada factura copiando datos desde Word hacia Odoo, ajustando el documento según la entidad destinataria. El proceso consumía horas por lote de facturas y era propenso a errores que podían trabar el proceso de pago gubernamental.

Intervención

Mapeo de todos los formatos requeridos por entidad. Desarrollo de módulo que detecta la entidad pagadora desde el pedido de venta y selecciona automáticamente la plantilla QWeb correspondiente al generar la factura. Los campos requeridos se llenan desde el contrato registrado en Odoo.

Resultado

Generación automatizada de facturas con formato correcto por entidad. El proceso que tomaba horas ahora es un botón.

  • IGSS
  • Sector público
  • QWeb
  • Automatización
CASO-06Manufactura

Módulo de diagnóstico vehicular integrado a ventas y contabilidad

Contexto

Empresa de manufactura del sector motos con red de servicios técnicos. Los técnicos registraban diagnósticos en papel; el traspaso a presupuesto y luego a factura era manual y tardaba entre días y semanas según la carga.

Problema identificado

No existía trazabilidad digital del diagnóstico al presupuesto, ni del presupuesto a la orden de trabajo, ni de la orden al repuesto consumido en inventario. Cada paso requería entrada manual duplicada.

Intervención

Diseño y desarrollo de módulo completo de diagnóstico vehicular: registro de síntomas, asignación de técnico, generación automática de presupuesto en Odoo, aprobación por el cliente, conversión a orden de trabajo con descuento automático de inventario y facturación al cierre. Conectado a contabilidad en tiempo real.

Resultado

Ciclo completo diagnóstico → factura trazable y sin entrada duplicada. Los gerentes visualizan el estado de cada unidad en servicio desde el tablero de Odoo.

  • Manufactura
  • Módulo custom
  • Órdenes de trabajo
  • Inventario
CASO-07Manufactura / Construcción

Migración v10 → v19 con nómina completa

Contexto

Empresa del sector construcción y asfaltos con instancia Odoo v10 en producción durante varios años. El sistema acumulaba datos de nómina, contabilidad, compras e inventario que no podían perderse ni quedar desconectados.

Problema identificado

Versión v10 fuera de soporte, sin posibilidad de instalar conectores modernos ni cumplir con actualizaciones de FEL. El salto de v10 a v19 implica cruzar seis versiones mayores, cada una con cambios de esquema de base de datos, modelos depreciados y APIs modificadas.

Intervención

Migración en etapas con entorno de staging paralelo: migración de datos por módulo (contabilidad → inventario → nómina → ventas/compras), ejecución y validación de scripts de transformación de esquema para cada salto de versión, pruebas de integridad de datos antes de cada paso. Módulos a medida reescritos para v19.

Resultado

Instancia v19 en producción con historial íntegro. Nómina operativa desde el primer período en el sistema nuevo. Módulos propios funcionando.

  • Migración
  • v10 → v19
  • Nómina
  • Construcción
CASO-08Consultoría contable

Estructura multiempresa para cartera de clientes con multi-moneda

Contexto

Consultora contable que administra la contabilidad de múltiples empresas cliente desde una sola instancia Odoo en modo multicompañía, con clientes operando en distintas monedas.

Problema identificado

La configuración inicial generaba cruces de asientos entre compañías en operaciones intercompañía. Los reportes consolidados mezclaban monedas sin conversión correcta. El equipo contable de la consultora dedicaba tiempo significativo a correcciones manuales al final de cada período.

Intervención

Reconfiguración de la jerarquía de compañías, cuentas intercompañía y reglas de reconciliación automática. Configuración del módulo de multi-moneda con tasas actualizables. Plantillas de reporte separadas por compañía y consolidado. Soporte especializado en tipos y códigos contables por los términos contractuales estrictos del negocio.

Resultado

Aislamiento correcto entre compañías. Reportes consolidados con conversión de moneda validada. Cero correcciones manuales en el siguiente cierre de período.

  • Multiempresa
  • Contabilidad
  • Multi-moneda
  • Consultoría
CASO-09E-commerce / Equipamiento industrial

Módulo de tracking de pedido visible al cliente en tiempo real desde la web

Contexto

Empresa de equipamiento de laboratorio con presencia en LATAM y procesos de importación/envío complejos. Los pedidos pasan por etapas con información técnica relevante: aduana, despacho, envío, entrega — con tiempos y detalles que el cliente necesita conocer sin tener que consultar.

Problema identificado

Los clientes no tenían visibilidad del estado real de su pedido entre la confirmación y la entrega. El equipo comercial respondía manualmente decenas de preguntas de seguimiento por semana. La información existía en Odoo pero era inaccesible desde el exterior.

Intervención

Desarrollo de módulo de tracking personalizado en Odoo: etapas de seguimiento con campos técnicos de estado (número de despacho, courier, aduana, fecha estimada de entrega). Integración con el sitio web mediante código de seguimiento único visible al cliente, que actualiza el estado en tiempo real desde Odoo sin intervención manual.

Resultado

Los clientes consultan el estado de su pedido sin contactar al equipo comercial. El número de preguntas de seguimiento bajó de forma medible en las primeras semanas.

  • E-commerce
  • Tracking
  • LATAM
  • Sitio web
  • Importaciones
CASO-10Soporte regional · Centroamérica

Soporte continuo a instancia multi-sucursal con presencia en 4 países

Contexto

Empresa con sucursales activas en cuatro países de Centroamérica operando sobre una instancia Odoo compartida. Las sucursales operan con distintas configuraciones fiscales, distintos catálogos parciales y necesidades de soporte simultáneas en zonas horarias distintas.

Problema identificado

El soporte técnico y funcional a una instancia regional requiere entender las variaciones de configuración por país, gestionar cambios que no pueden afectar operaciones activas en otras sucursales, y mantener disponibilidad sin intervenciones en horario de cierre de alguna de las unidades.

Intervención

Soporte funcional y técnico continuo durante dos años a los módulos Odoo de las sucursales regionales: resolución de incidencias, ajustes de configuración por unidad, coordinación de cambios con impacto multi-sucursal, y documentación de las variaciones específicas por país.

Resultado

Instancia regional estable durante dos años. Soporte coordinado sin incidentes de disponibilidad inter-sucursal.

  • Regional
  • Centroamérica
  • Multi-sucursal
  • Soporte continuo
SIGUIENTE PASOSu caso

¿Su operación tiene un problema parecido?

El diagnóstico inicial es sin costo. Cuéntenos qué está pasando y le decimos si aplica — y cómo.

hola@nio.gtWhatsApp