Un cliente pidió diez unidades y acabó necesitando siete.

Las otras tres llevaban ya varios días descompuestas en dos referencias de stock distintas, con su coste repartido y sus movimientos generados, esperando una operación que nunca llegó. Había que decidir qué hacer con ellas: recomponerlas para otro cliente, devolverlas al proveedor o dejarlas separadas por si aparecía otra venta. Ninguna de esas tres salidas estaba prevista, porque cuando especificamos aquello nadie contemplaba que pudieran sobrar.

La automatización funcionaba. Detectaba la recepción, calculaba cantidades, repartía coste y dejaba el stock partido sin que nadie tuviera que tocar nada. Llevaba semanas haciéndolo tal como fue diseñada.

El error no estaba en el código, sino en la frase con la que arrancó el desarrollo: “este producto siempre se descompone al recibirlo”.

Casi todas las peticiones empiezan igual

Cuando pase esto, quiero que Odoo haga aquello automáticamente.

No desconfío de la petición. Suele venir de alguien que lleva meses repitiendo la misma secuencia de clics y tiene todo el derecho a querer quitársela de encima. Lo que intento averiguar antes de escribir nada es cuántas veces al mes va a ocurrir de verdad, qué problema resuelve y, sobre todo, si el proceso es determinista o todavía depende de información que el sistema no tiene.

Hay procesos en los que la respuesta es clara y el sistema debe actuar sin preguntar. Si un cliente tiene una tarifa asignada, Odoo la aplica. Si la política de la empresa dice que un documento se envía en unas condiciones concretas, dejar esa decisión en manos de cada usuario solo añade trabajo y hace que el resultado dependa de quién ejecute el proceso.

En el caso de las tres unidades, la alternativa segura era mucho más modesta. Detectar la recepción y avisar:

Has recibido este producto. Está preparado para descomponerse. Pulsa aquí si corresponde.

El sistema calcula las cantidades igual, prepara el reparto de costes igual y deja la operación lista igual. La persona mira el contexto y confirma. El ahorro de tiempo es prácticamente el mismo y desaparece la obligación de deshacer una transformación que quizá nunca debió ejecutarse.

Entre manual y automático hay más de dos opciones

Las conversaciones sobre automatización tienden a plantearse como un interruptor: o lo hace una persona, o lo hace el sistema. Por mi experiencia hay bastante recorrido entre ambos extremos.

Una aplicación puede limitarse a avisar de que ha ocurrido algo que merece atención. Puede ir un paso más allá y proponer la acción con los datos ya preparados. Puede pedir una confirmación explícita enseñando qué va a cambiar exactamente. O puede ejecutar sin preguntar, que es lo correcto cuando la regla no admite excepciones.

Para situar cada proceso en esa escala comparo dos escenarios: qué pasa si la automatización no se ejecuta y qué pasa si se ejecuta cuando no debía.

Si no descomponer el producto en el momento de la recepción solo implica hacerlo tres días después, esperar cuesta muy poco. Si la automatización mueve stock, reparte costes o manda un correo al cliente, la cosa cambia bastante.

Un movimiento de stock incorrecto puede hacer que el sistema recomiende comprar material que la empresa ya tiene en la estantería, o dejar un descuadre que alguien tendrá que investigar dentro de dos meses sin saber por dónde empezar. Un reparto automático de costes con valoración AVCO altera el coste medio del producto y contamina todo lo que venga después: salidas, márgenes de venta, informes. Cuando eso se detecta tarde, deshacerlo implica averiguar qué coste se aplicó, cuál tocaba, qué se movió y qué documentos posteriores heredaron el error.

Las comunicaciones tienen su propia versión del problema, porque una vez que el correo está en la bandeja del cliente ya no puedes retirarlo.

En ese tipo de procesos prefiero que el sistema prepare la acción, enseñe sus efectos y pida una confirmación consciente. Es un clic más a cambio de no tener que reconstruir después una operación mal ejecutada.

Se puede deshacer, pero ¿a qué coste?

Muchas operaciones son relativamente fáciles de revertir justo después de ejecutarse, pero se complican en cuanto otros procesos empiezan a apoyarse en ellas. Si el sistema reparte costes y después hay salidas de stock, ventas confirmadas y un cierre de mes por medio, volver al estado anterior exige bastante más que una acción inversa.

Por eso, cuando una automatización tiene efectos relevantes, intento que exista una vía de corrección clara y que el usuario sepa en qué momento esa vía se cierra.

No existe una lista de procesos que jamás deban automatizarse, porque depende de la política de cada empresa y de sus controles. Pero hay algunos con los que voy con pies de plomo: movimientos de stock con trazabilidad complicada, cualquier cosa que toque la valoración de inventario y las comunicaciones que salen hacia fuera. Se pueden automatizar por completo cuando las reglas están cerradas y el contexto necesario vive dentro de Odoo; si una parte relevante de ese contexto vive fuera, prefiero propuesta y confirmación.

El contexto que no está en Odoo

Un cliente iba a recibir su pedido por transporte y a última hora un compañero suyo pasó a recogerlo por el almacén.

Odoo conoce el albarán y la dirección de entrega, pero no sabe que dos personas acaban de acordar otra cosa por teléfono hace veinte minutos. El código funciona a la perfección y el cliente recibe un aviso de expedición que ya no describe lo que va a ocurrir.

Este es el fallo que más me cuesta anticipar, porque no se deduce mirando los campos del documento. Depende de una llamada, de una decisión reciente, de algo que nadie ha registrado en ningún sitio porque no había ningún sitio donde registrarlo.

De ahí que durante el análisis pregunte siempre lo mismo: qué mira una persona antes de tomar esta decisión, y cuánto de eso está realmente dentro del sistema. Cuanto más de ese contexto quede fuera, más cuidado tengo antes de automatizar la decisión por completo.

Escribir el método ya es barato

Un wizard de confirmación, una validación, una vista que enseñe qué va a cambiar antes de cambiarlo. Hace no tanto, construir esas piezas sumaba horas de desarrollo, así que era fácil que se cayeran del alcance y acabáramos aceptando un flujo más tosco. Hoy sale mucho más barato.

Es una buena noticia para todo lo que he descrito hasta aquí, porque casi todo consiste en construir piezas adicionales: comprobaciones, avisos, pantallas intermedias. También permite abordar automatizaciones que merecían la pena y seguían siendo manuales porque la inversión inicial no salía.

Lo que no se ha abaratado es el trabajo previo: entender el proceso entero, detectar qué información falta, imaginar cómo puede cambiar el negocio y decidir qué trozo de la decisión se queda con la persona. Ahora que construir cuesta menos, entender bien qué merece la pena tiene todavía más peso, porque también es más fácil montar en un rato una automatización que no debía existir.

Las tres unidades

Con el tiempo he ido reforzando lo previsible: tests en los métodos críticos, nombres claros, documentación que alguien pueda leer dentro de un año. Pero el cambio que más me ha servido está antes del código, y consiste en ser más crítico con los “siempre” y los “nunca” de la primera reunión.

En determinadas situaciones compensa automatizar el 90 % inequívoco y entregar el 10 % restante a una persona con todo el trabajo previo hecho. Esa solución híbrida suele dar menos problemas cuando cambia el negocio: hay menos reglas escondidas que revisar y menos posibilidades de que una excepción nueva dispare un comportamiento pensado para otro contexto.

Al final tocó recomponer las tres unidades para poder devolverlas al proveedor. Se resolvió, aunque a base de reparación manual: exactamente el trabajo que se habría evitado con una confirmación de dos segundos en el momento de la recepción.