Mover un campo en Odoo Studio toma segundos; explicar por qué existe puede costar meses. Cuando cada reunión termina con otra casilla, una vista distinta o una automatización urgente, el ERP deja de representar un proceso y empieza a conservar todas sus dudas. Odoo Studio permite adaptar campos, vistas, modelos, reglas, reportes y aprobaciones sin escribir código, pero la velocidad de configuración no elimina el costo de decidir, probar y mantener. Nuestra tesis es directa: personalizar antes de estabilizar el proceso no acerca la implementación a la empresa; convierte la indecisión operativa en deuda permanente.
Una necesidad real debe sobrevivir sin una pantalla nueva
Antes de abrir Studio, describa la decisión o el trabajo que hoy falla. ¿Quién necesita actuar, con qué información, en qué momento y qué evidencia debe quedar? Una solicitud como “agreguemos un campo de prioridad comercial” no responde si la prioridad cambia el seguimiento, la aprobación o el plazo. Si nadie puede explicar qué ocurre cuando el valor está vacío, errado o desactualizado, todavía no existe un requisito: existe una preferencia de interfaz.
Clasifique la solicitud. Puede tratarse de dato obligatorio, segmentación, control, cálculo, comunicación, reporte o integración. Después pruebe si una función estándar ya resuelve el caso mediante etiquetas, actividades, etapas, propiedades, filtros guardados o configuración existente. Adaptar no es fracaso; duplicar una capacidad porque nadie la revisó sí crea dos fuentes para la misma verdad.
Exija un ejemplo positivo y uno negativo. Si el cambio busca bloquear una confirmación, muestre una operación que debe avanzar y otra que debe detenerse. Si crea una clasificación, defina quién la mantiene y qué reporte la consume. Ese ejercicio reduce campos “por si acaso” y permite decidir si el problema necesita configuración, capacitación, limpieza de datos o un rediseño del proceso.
Cada campo personalizado necesita dueño y ciclo de vida
La documentación de Odoo 18 explica que los campos creados con Studio se guardan como columnas en la base de datos. No son simples etiquetas visuales. El tipo de campo determina qué información admite, y sus propiedades pueden cambiar por vista, incluidos rótulo, visibilidad, obligatoriedad y solo lectura. Elegir texto cuando se necesita una relación, o una selección cerrada para valores que cambian cada mes, limita búsquedas, integraciones y mantenimiento futuro.
Para cada campo registre nombre funcional, nombre técnico, modelo, propósito, responsable, población esperada, valor predeterminado, origen y criterio de retiro. Defina también si contiene datos personales o sensibles. Un campo obligatorio no corrige la calidad por sí solo: puede incentivar valores ficticios cuando el usuario todavía no conoce la respuesta. Considere hacerlo obligatorio en la etapa donde la información realmente existe, no desde la creación del registro.
Revise duplicidad semántica. “Sector”, “industria”, “vertical” y “mercado” pueden terminar describiendo lo mismo con listas incompatibles. Antes de agregar otro campo, busque los existentes y consulte reportes, importaciones y automatizaciones que dependen de ellos. Si se reemplaza uno, planee migración, período de convivencia y validación. Ocultarlo de una vista no elimina los datos ni las dependencias que ya creó.
Una automatización rápida también necesita controles
Odoo Studio permite ejecutar acciones por cambios de valores, eventos de correo, condiciones de tiempo, disparadores personalizados o eventos externos. La documentación recomienda nombres claros y notas que expliquen propósito y funcionamiento. También advierte que una acción al guardar puede ejecutarse varias veces por registro si no se seleccionan campos específicos. Ese detalle convierte una buena intención en actividades duplicadas, correos repetidos o cambios difíciles de reconstruir.
Escriba la regla como una frase comprobable: cuando cambia este campo, si el registro cumple estas condiciones, ejecutar esta acción una vez y dejar esta evidencia. Separe condiciones anteriores y posteriores cuando el caso lo requiera. Incluya escenarios de edición masiva, importación, creación por integración y cambios hechos por otra automatización. La prueba manual desde el formulario no demuestra necesariamente lo que ocurrirá por API o por un proceso programado.
Para webhooks y acciones externas, delimite autenticación, datos enviados, reintentos, idempotencia y manejo de errores. Odoo advierte que una configuración incorrecta puede afectar la base y ser difícil de revertir. No conecte producción como primera prueba. Use un caso controlado, registre identificadores y compruebe tanto el origen como el sistema destino. Ver un estado técnico exitoso no basta si el cliente, pedido o actividad esperada no aparece donde debía.
El inventario de personalizaciones es parte del ERP
Una implementación gobernada mantiene un inventario vivo de campos, vistas, modelos, reglas, aprobaciones, reportes y conexiones. Para cada elemento anote necesidad, dueño, fecha, alcance, dependencias, prueba y decisión de permanencia. Odoo permite exportar personalizaciones de Studio; esa capacidad ayuda a transportar cambios, pero no reemplaza una lista entendible por el negocio ni prueba que el destino tenga datos, permisos y configuración compatibles.
Defina ambientes y una ruta de promoción. Un cambio pequeño puede alterar una vista usada por ventas, una importación de compras o una regla que ejecuta contabilidad. Pruebe con roles representativos y casos reales anonimizados. Compare antes y después, relea el registro guardado y valide el documento o actividad resultante. Si el cambio toca reportes, permisos o integraciones, incluya explícitamente esos consumidores en el alcance.
Asigne una versión y una salida. Antes de llevar una personalización a producción, conserve qué se modificó y cómo desactivarla o revertirla. No suponga que borrar un campo es una reversión segura: puede perder información o romper una dependencia. A veces la recuperación correcta consiste en desactivar una regla, retirar una vista o restaurar una configuración aprobada mientras se conserva el dato para análisis.
Un piloto debe demostrar valor y capacidad de mantenimiento
Seleccione un proceso delimitado, por ejemplo la calificación de oportunidades o la aprobación de una excepción comercial. Limite el piloto a pocos cambios: uno o dos campos, una vista y una automatización con evidencia. Defina resultados observables como menos reprocesos, información completa en la etapa correcta, tiempo de decisión o reducción de tareas manuales. Evite medir éxito por cantidad de personalizaciones entregadas.
Ejecute casos normales, incompletos, duplicados y fuera de orden. Pruebe con un usuario operativo, un responsable y una cuenta sin permiso. Confirme nombres, valores predeterminados, búsqueda, exportación, historial, notificaciones y comportamiento cuando la regla falla. Pida a una persona distinta del configurador que explique el flujo y diagnostique un caso. Si solo el autor entiende la solución, el piloto todavía no demostró mantenibilidad.
Cierre con una decisión explícita: conservar, ajustar o retirar. Documente responsables y fecha de revisión. Acumular todas las pruebas exitosas sin retirar lo que ya no sirve produce un ERP cada vez más difícil de actualizar y enseñar. Wondertech puede acompañar la implementación de Odoo 18 en Colombia con un gobierno de personalizaciones que permita adaptar el sistema sin convertir cada solicitud urgente en una obligación indefinida.
Más artículos de implementación Odoo · Converse con Wondertech
Fuentes oficiales Odoo 18: Odoo Studio · Campos y widgets · Reglas de automatización · Modelos, módulos y apps