ID Inventory — Operación sin conexión

ID Inventory ya existía y estaba en producción: una aplicación web instalable para controlar compras, recepciones y despachos en bodegas de construcción. Yo no la construí. Llegué a un sistema en uso para resolver el problema que lo estaba frenando.

El encargo tenía dos partes: auditar el sistema a fondo —base de datos, seguridad y lógica de negocio— y después desarrollar la operación sin conexión, para que un bodeguero en una obra sin señal pudiera seguir registrando movimientos con la certeza de que nada se perdería.

Las bodegas de obra están donde está la construcción, no donde está la cobertura. La aplicación necesitaba red para cada operación, así que cuando la señal caía el trabajo se detenía o volvía al papel, que es justo lo que el sistema había venido a eliminar.

El riesgo no era solo perder un registro. Un reintento mal resuelto es peor que un fallo: una recepción enviada dos veces duplica inventario que nadie recibió, y ese error se descubre semanas después en un conteo que no cuadra.

Empecé por la auditoría, no por el código: recorrí el esquema completo, las políticas de acceso y las funciones de negocio, documentando qué hacía cada pieza y dónde estaban los huecos. De ahí salieron seis defectos preexistentes que corregí y verifiqué en producción.

Para la operación sin conexión implementé una cola local en IndexedDB: cuando no hay red, la operación se guarda en el dispositivo en lugar de fallar, y el usuario sigue trabajando con una señal visible de que está offline.

Al recuperar la señal, la cola se sincroniza sola con reintentos escalonados —cada fallo espera un poco más que el anterior— para no golpear al servidor cuando la conexión vuelve inestable, que es como suele volver en una obra.

La idempotencia es lo que hace seguro ese reenvío: cada operación viaja con una clave única que el servidor usa para reconocerla. Si una recepción llega dos veces, la segunda no duplica nada. Al confirmarse, el sistema emite y archiva el comprobante correspondiente.

Cerré con documentación: manual de usuario, manual de administración y documentación técnica, para que el sistema no dependa de que yo esté disponible.

Entrar a un sistema ajeno en producción exige una disciplina distinta a empezar de cero: primero entender por qué está hecho así, después proponer. La auditoría no fue el preámbulo del trabajo, fue parte del trabajo.

«Sin conexión» no es una funcionalidad, es un modelo de consistencia. La parte difícil no es guardar datos en el dispositivo, sino decidir qué significa que una operación esté confirmada cuando el dispositivo y el servidor no se ponen de acuerdo.

Los errores más caros son los que no fallan de forma visible. Un inventario duplicado no lanza ninguna alerta: aparece meses después como un faltante que nadie sabe explicar.