Inventario de vinos desde el celular: movimientos y modo offline
Inventario de vinos desde el celular: registra el movimiento donde ocurre
La función principal de una app móvil de inventario no es mostrar un dashboard pequeño. Es registrar una recepción, traslado, salida, devolución, incidencia o conteo en el lugar y el momento en que sucede. Ese cambio reduce la distancia entre la botella y el registro, pero introduce preguntas difíciles: ¿qué ocurre sin señal?, ¿cómo se evita una duplicación?, ¿qué dispositivo tiene razón si dos personas mueven la misma unidad?
Este artículo se concentra en la ejecución operativa. No compara marcas ni elige proveedor. Para ese proceso existe una comparativa de apps de inventario de vinos para restaurantes. Aquí el objetivo es definir cómo debería comportarse cualquier solución cuando el equipo trabaja con botellas reales.
Un movimiento móvil confiable debe poder responder:
- qué unidad o cantidad cambió;
- de dónde salió y a dónde llegó;
- quién lo registró y con qué permiso;
- cuándo ocurrió y cuándo llegó al servidor;
- por qué se realizó y qué evidencia lo acompaña;
- si está pendiente, aceptado, rechazado o en conflicto;
- qué evento lo corrigió, si después hubo una reversión.
Qué tareas pertenecen al celular
El móvil funciona bien para acciones breves ligadas al contexto físico:
- recibir botellas contra una orden o depósito;
- trasladar entre ubicaciones;
- registrar salida a servicio o retiro;
- declarar rotura, devolución o cuarentena;
- contar una sección y capturar diferencias;
- consultar disponibilidad con estado y ubicación;
- adjuntar una fotografía o referencia operativa;
- resolver una excepción junto a la botella.
La configuración masiva, importaciones, permisos, análisis, cierres y conciliaciones complejas suelen requerir una interfaz mayor y una revisión deliberada. Móvil y escritorio comparten datos, pero no deberían copiar todas sus pantallas.
Modela movimientos, no solo cantidades finales
Guardar únicamente «quedan 12» impide explicar cómo se llegó a esa cantidad. Un libro de eventos conserva cada cambio y permite reconstruir el estado.
Tipos de movimiento
Define un catálogo corto y estable:
| Movimiento | Datos mínimos adicionales |
|---|---|
| Recepción | proveedor o propietario, documento, ubicación de entrada |
| Traslado | origen y destino distintos |
| Salida | destino operativo, referencia de servicio o retiro |
| Devolución | procedencia, destino y motivo |
| Incidencia | condición, evidencia y disposición |
| Conteo | ubicación, cantidad observada y sesión de conteo |
| Ajuste | diferencia, motivo y aprobación requerida |
| Reversión | evento original y explicación |
Un ajuste no debe convertirse en la salida rápida para cualquier error. Si la botella se trasladó, registra traslado; si un movimiento se capturó mal, genera reversión o corrección enlazada. Así el inventario conserva su historia.
Campos de cada evento
- identificador único del movimiento;
- identificador de producto, lote o botella;
- cantidad y unidad;
- origen y destino;
- actor, rol, sede y dispositivo;
- fecha del evento en el dispositivo;
- fecha de recepción y decisión del servidor;
- referencia operativa y motivo;
- evidencia adjunta, cuando aplique;
- versión de estado usada como base;
- estado de sincronización;
- identificador del evento relacionado si corrige otro.
Separar hora del dispositivo y hora del servidor permite investigar retrasos y relojes incorrectos. La interfaz puede mostrar la hora local, pero la transmisión necesita una representación inequívoca con zona horaria.
Escanear no siempre identifica una botella individual
Un código comercial suele identificar un tipo de producto, no una unidad física específica. Las Especificaciones Generales de GS1 distinguen el GTIN de los datos de serialización utilizados para una instancia.
Esto cambia el flujo:
- Inventario por SKU: el escaneo identifica la etiqueta y el usuario confirma cantidad, ubicación y añada o variante.
- Inventario por lote: el código debe relacionarse también con el lote pertinente.
- Custodia por botella: cada unidad necesita un identificador serial propio, además de los datos del vino.
El reconocimiento fotográfico puede proponer una ficha, pero el usuario debe confirmar coincidencias críticas. Una etiqueta parecida no prueba añada, formato, propietario ni unidad. El sistema también necesita un camino manual controlado cuando el código no existe o está dañado.
Diseña el flujo en el punto de acción
Un registro móvil debería reducir decisiones sin ocultar consecuencias. Un flujo razonable:
- el usuario elige el tipo de movimiento;
- identifica la unidad o producto;
- confirma origen, destino y cantidad;
- agrega referencia, motivo o evidencia requerida;
- revisa un resumen antes de enviar;
- recibe un estado visible: guardado local, enviado, aceptado, rechazado o conflicto.
Los valores por defecto pueden acelerar, pero deben derivarse del contexto y mostrarse. Preseleccionar siempre la última ubicación puede propagar un error entre racks. En operaciones masivas, presenta el número de unidades y permite revisar la lista antes de confirmar.
La confirmación visual, sonora o háptica debe diferenciar éxito final de guardado offline. Un color verde idéntico para ambos induce al usuario a creer que el servidor aceptó algo que aún está pendiente.
Modo offline: una cola durable, no una promesa vaga
Una cava puede tener muros gruesos, sótanos o zonas sin cobertura. El modo offline necesita un comportamiento definido.
Cuando el usuario confirma un movimiento sin conexión, la app debería:
- validarlo localmente con las reglas disponibles;
- guardarlo en almacenamiento durable con su identificador único;
- mostrarlo como pendiente, no como aceptado;
- mantenerlo en una cola aunque la app se cierre o el dispositivo reinicie;
- reintentar cuando regrese la conectividad;
- enviar el mismo identificador en cada intento;
- esperar la respuesta del servidor;
- mostrar aceptación, rechazo o conflicto y conservar el detalle.
La documentación de Android sobre arquitectura offline-first distingue escrituras en línea, en cola y locales con sincronización posterior. Es un ejemplo de implementación para Android, no una receta universal, pero deja clara la necesidad de persistencia, reintentos y resolución de conflictos.
Idempotencia para no duplicar
La red puede cortar después de que el servidor recibió un movimiento pero antes de que el teléfono recibió la confirmación. La app volverá a enviarlo. El servidor debe reconocer el identificador original y devolver el resultado existente, no registrar otra recepción o salida.
Generar un ID nuevo en cada reintento rompe esa protección. El evento conserva el mismo ID durante toda su vida; una corrección deliberada crea otro y enlaza el anterior.
Sincronización y fuente de verdad
El teléfono mantiene una vista local para trabajar. El servidor mantiene el estado autorizado para coordinar personas y dispositivos. Al recuperar conexión, la app envía eventos pendientes y recibe cambios ocurridos en otros equipos.
El ciclo necesita estados explícitos:
borrador → guardado_local → enviando → aceptado
↘ rechazado
↘ conflicto
Un movimiento rechazado no desaparece. Muestra la razón y permite corregir según permisos. Un evento en conflicto tampoco debe contabilizarse como aceptado hasta que se resuelva.
Por qué «última escritura gana» no basta
Para una nota personal puede ser razonable conservar el cambio más reciente. En inventario, dos escrituras pueden representar dos hechos distintos o una doble captura del mismo hecho. Sobrescribir una con la otra puede ocultar una salida.
Prefiere eventos anexados y reglas específicas por tipo de conflicto. El servidor decide el estado autorizado y conserva ambas propuestas para revisión.
Conflictos que debes diseñar antes de desplegar
| Conflicto | Respuesta operativa esperada |
|---|---|
| Dos usuarios trasladan la misma botella a destinos distintos | Bloquear confirmación automática, mostrar ambos eventos y exigir resolución autorizada |
| Un conteo contradice movimientos pendientes | Mantener la sesión y movimientos, recalcular al sincronizar y abrir una diferencia |
| Se reenvía el mismo movimiento | Reconocer el ID y devolver el resultado previo sin duplicar |
| Se escanea un GTIN con varias añadas o propietarios | Solicitar desambiguación; no elegir por frecuencia |
| El permiso cambió mientras el dispositivo estaba offline | Revalidar en servidor y rechazar con motivo si ya no está autorizado |
| Se eliminó o cerró la ubicación de destino | Rechazar y pedir una ubicación vigente; no redirigir silenciosamente |
| El catálogo cambió mientras había eventos pendientes | Conservar la versión usada y solicitar revisión si afecta identidad o unidad |
La resolución debe registrar persona, decisión, fecha, motivo y eventos resultantes. El usuario que originó el conflicto puede aportar contexto; otra función puede necesitar aprobarlo.
Permisos y seguridad en un dispositivo que puede perderse
El celular contiene inventario, ubicaciones, actividad de personal y quizá datos de clientes. Diseña acceso por rol, sede y acción:
- consultar no implica trasladar;
- trasladar no implica ajustar;
- ajustar no implica aprobar;
- ver una cava no implica ver todas;
- adjuntar evidencia no implica descargar cualquier documento.
Reautentica acciones sensibles según el riesgo, revoca sesiones de dispositivos perdidos y evita guardar secretos o exportaciones sin protección. Los datos locales y la comunicación necesitan controles apropiados, y los logs no deberían exponer más información de la necesaria.
El OWASP Mobile Application Security Verification Standard organiza controles para almacenamiento, criptografía, autenticación, red, plataforma, código, resiliencia y privacidad. No certifica automáticamente una app; sirve como base para requisitos y pruebas técnicas.
Evidencia y privacidad
Una fotografía puede documentar daño o recepción, pero también capturar rostros, documentos o espacios privados. Limita la cámara a casos definidos, informa su propósito, minimiza el encuadre y establece acceso y retención. No pidas una foto para cada movimiento si no aporta evidencia.
Registra quién consultó o exportó información sensible. En dispositivos compartidos, cierra sesión correctamente y no dependas solo del bloqueo general del teléfono.
Móvil y escritorio: responsabilidades distintas
| Móvil | Escritorio o consola de gestión |
|---|---|
| Captura junto a la botella | Catálogos e importaciones masivas |
| Consulta contextual | Roles, políticas y configuración |
| Conteo por sección | Conciliación y revisión cruzada |
| Evidencia de incidencia | Reportes y análisis extensos |
| Cola y estado de sincronización | Monitor de dispositivos, colas y conflictos |
| Resolución simple autorizada | Excepciones complejas y aprobaciones |
La carta digital puede consumir disponibilidad, pero esa integración requiere reglas propias sobre reservas, unidades y retrasos. La guía de inventario de vinos y carta digital aborda esa sincronización; no debe mezclarse con el flujo de captura móvil.
Pilota con escenarios de fallo
Una demostración con buena señal prueba muy poco. Antes de ampliar el uso, ensaya:
- cierre de la app con movimientos pendientes;
- reinicio del teléfono;
- varias horas sin conexión;
- reintento después de respuesta perdida;
- dos dispositivos sobre la misma botella;
- reloj del dispositivo incorrecto;
- código ilegible o identificación ambigua;
- permiso revocado durante el periodo offline;
- almacenamiento local casi lleno;
- fotografía que falla al cargar;
- actualización de la app con cola pendiente.
El piloto debe usar una zona y un grupo acotados, mantener una forma de conciliación y definir quién atiende conflictos. No borres la evidencia de los fallos: conviértela en casos de prueba.
Métricas que describen la ejecución
Evita medir solo descargas o aperturas. Observa:
- movimientos por estado;
- tiempo desde captura hasta aceptación;
- porcentaje y antigüedad de la cola pendiente;
- reintentos por movimiento;
- duplicados evitados por idempotencia;
- conflictos por tipo y ubicación;
- rechazos por permisos o datos;
- correcciones y reversiones;
- eventos sin motivo o evidencia requerida;
- dispositivos con versiones obsoletas.
Estas métricas no prueban por sí solas exactitud física. Compáralas con conteos y revisiones operativas.
Preguntas frecuentes
¿Una app móvil necesita conexión permanente?
No necesariamente. Debe declarar qué consultas y escrituras funcionan offline, cuánto se conserva localmente y cómo se sincroniza. «Modo offline» sin cola, estados y conflictos definidos es insuficiente.
¿Un código de barras identifica una botella única?
No siempre. Un GTIN normalmente identifica la clase de producto. La trazabilidad por unidad requiere serialización u otro identificador propio de la botella.
¿Qué sucede si dos personas mueven la misma botella?
El servidor no debería ocultar un evento con «última escritura gana». Conserva ambos, marca conflicto y aplica una resolución autorizada con rastro.
¿Se puede corregir borrando el movimiento?
No es recomendable. Una reversión o corrección enlazada mantiene la historia y permite explicar el estado.
¿Cómo se aplica esto a Kavasoft?
Convierte los escenarios de esta guía en criterios de prueba para tu operación: eventos, estados offline, duplicados, permisos y conflictos. Kavasoft para restaurantes puede evaluarse dentro de ese flujo, mientras que la asignación de botellas a clientes requiere además las reglas del programa de socios. La validación debe hacerse con tus procesos y dispositivos reales.
Referencias técnicas
- Android Developers: arquitectura de datos offline-first, colas, reintentos, sincronización y conflictos.
- GS1 General Specifications 25.0, identificación y serialización de artículos.
- OWASP MASVS, controles de seguridad y privacidad para aplicaciones móviles.
