Sistema de ubicación de botellas: rack-fila-posición

La ubicación es una relación que cambia

Un sistema de ubicación de botellas responde dónde está o dónde debería estar una unidad en un momento determinado. No define qué vino es, a qué categoría pertenece ni cuál es su identidad permanente.

La botella conserva su ID cuando pasa de recepción a cuarentena, de cuarentena a rack y de rack a una estación de servicio. Lo que cambia es la relación de ubicación, registrada mediante eventos con origen, destino, fecha, actor y motivo.

Principio: identifica de forma estable la botella y la ubicación por separado. Un movimiento conecta ambas; no renombra ninguna.

La clasificación de botellas administra categorías y atributos. El etiquetado operativo define portadores. Esta guía se concentra en dirección física, capacidad y movimientos.

Jerarquía completa: sitio a bin

rack-fila-posición puede ser una dirección visible útil dentro de una cava. La base de datos necesita contexto suficiente para que sea única:

sitio → sala o cava → zona → rack → fila o nivel → bin o slot

Nivel	Pregunta	Ejemplo conceptual
Sitio	¿en qué sucursal o edificio?	restaurante Centro
Sala/cava	¿en qué espacio controlado?	cava principal
Zona	¿qué área funcional?	custodia, carta, cuarentena
Rack	¿qué estructura?	rack B
Fila/nivel	¿qué altura o banda?	nivel 03
Bin/slot	¿qué contenedor o posición?	posición 07

Una dirección humana podría verse como CTR-CAVA1-CUS-B-03-07. El ejemplo no es un estándar obligatorio. Cada restaurante debe documentar su perspectiva, orientación y alcance.

No uses solamente B-03-07 si puede repetirse en otra sala o sucursal. La pantalla puede mostrar una versión corta cuando el contexto ya está fijado; la clave interna conserva toda la relación.

ID interno y código visible

Cada ubicación necesita dos representaciones:

ID interno estable: una clave sin significado, usada por base de datos e integraciones;
código visible: una dirección que el equipo puede leer, escanear y recordar.

Si la cava cambia de layout, el código visible puede modificarse y mantener el mismo ID cuando la entidad física sigue siendo la misma. En otros casos, conviene cerrar la ubicación antigua y crear una nueva. Define la regla antes de reconfigurar racks.

No incrustes el código de ubicación en el ID de botella. B-03-07-001 se vuelve engañoso en el primer traslado. Conserva, por ejemplo, btl_... para la botella y loc_... para el bin.

Modelo de datos para una ubicación

Un registro útil incluye:

ID estable y código visible;
ubicación padre;
tipo: sitio, sala, zona, rack, bin, staging, cuarentena u otro;
estado: borrador, activa, bloqueada, cerrada;
capacidad y unidad de capacidad;
reglas de mezcla;
restricciones de formato, peso o acceso;
zona horaria del sitio;
fechas de vigencia;
etiqueta física y versión;
responsable y bitácora de cambios.

La capacidad debe expresar una unidad. “12” puede significar doce botellas de 750 ml, doce posiciones o doce cajas. Un bin que admite botellas estándar puede no admitir magnum.

El estado también importa. Una ubicación cerrada no debe recibir nuevas asignaciones; una bloqueada puede conservar contenido mientras se investiga una incidencia.

Slot individual o bin multiunidad

No existe una regla universal de una botella por ubicación.

Slot individual

Conviene cuando cada posición física es distinguible, hay custodia individual o el riesgo exige localizar una unidad concreta. Capacidad nominal: una botella compatible.

Bin multiunidad

Conviene para varias unidades intercambiables de un SKU o para una caja. Necesita cantidad, unidad y política de mezcla. Si admite distintos SKUs, aumenta la complejidad del conteo y selección.

“Un SKU por bin” puede ser una política operativa, no una ley del modelo. Documenta si el bin permite:

una instancia;
varias instancias del mismo SKU;
una caja cerrada;
distintos SKUs;
material temporal sin asignación final.

Convenciones que el equipo puede ejecutar

Define y coloca en el procedimiento:

orden de izquierda a derecha o viceversa;
si las filas se numeran desde piso o techo;
desde qué lado se observa el rack;
relleno con ceros para ordenar correctamente;
caracteres excluidos por confusión, como O/0 o I/1;
longitud máxima de la etiqueta;
color solo como apoyo, nunca como único identificador;
forma de leer el código por radio o voz.

Haz que una persona ajena al diseño recorra la cava con el documento. Si interpreta fila 1 desde el lado opuesto, la convención no está suficientemente definida.

Etiqueta de ubicación y etiqueta de botella

La etiqueta del rack identifica el destino; la de botella, el objeto. Para registrar un traslado, el equipo puede escanear ambas.

No copies la dirección actual en una etiqueta permanente de botella. Si necesitas una referencia visual, muéstrala en pantalla o usa un elemento reemplazable que no se confunda con la identidad.

Prueba etiquetas de bin con iluminación, humedad, ángulo, distancia y material reales. Una etiqueta grande al fondo de un rack lleno puede quedar oculta. Conserva un código humano para contingencia.

Flujo de recepción y colocación

Un flujo controlado puede ser:

registrar o identificar la botella en recepción;
asignarla a staging o cuarentena mientras se verifica;
consultar ubicaciones elegibles con capacidad;
seleccionar destino;
escanear botella y ubicación destino;
confirmar que el objeto, destino y acción son correctos;
guardar el evento;
actualizar la relación vigente solo si el evento fue aceptado.

No marques una botella como disponible en el rack antes de colocarla físicamente. La asignación planificada y la colocación confirmada pueden ser estados distintos.

Movimiento origen → destino

Un traslado debería conservar:

ID único del evento;
botella o cantidad afectada;
origen esperado;
destino confirmado;
hora efectiva y zona;
hora de recepción del sistema;
usuario, dispositivo o fuente;
motivo o paso operativo;
estado anterior y posterior;
evidencia proporcional;
relación con corrección o reversión.

El sistema valida que la botella estaba en el origen, que el destino existe, está activo y tiene capacidad. Si no coincide, no debería sobrescribir sin aviso.

Origen, destino, capacidad y excepción deben quedar explícitos en cada movimiento.

Para evitar duplicados, un reintento del mismo evento usa el mismo ID. Si dos dispositivos mueven la botella a destinos distintos, el conflicto entra a reconciliación; “gana el último” oculta el problema.

Read point y business location en EPCIS

GS1 EPCIS modela eventos con dimensiones como qué, cuándo, dónde, por qué y cómo. En la dimensión de ubicación distingue conceptos útiles:

readPoint: lugar específico donde se observó o capturó el evento;
businessLocation: ubicación donde se supone que queda el objeto después del evento.

No siempre son iguales. Un empleado puede escanear en la mesa de recepción y dejar la botella en cuarentena. Registrar solo la ubicación del dispositivo no demuestra dónde quedó.

El Core Business Vocabulary (CBV) aporta vocabulario estandarizado para pasos de negocio, disposiciones y fuentes/destinos. Un restaurante no tiene que implantar EPCIS para aprovechar la disciplina: separa observación, ubicación resultante y motivo.

Cuándo considerar GLN

El Global Location Number (GLN) identifica partes y ubicaciones en el sistema GS1. Sus reglas permiten identificar sububicaciones y contemplan usos internos y cadenas abiertas.

No necesitas asignar un GLN a cada slot de una cava doméstica. Para ubicaciones internas puede bastar un ID propio. GLN cobra valor cuando la ubicación debe comunicarse de forma interoperable con proveedores, operadores logísticos u otras organizaciones.

Si utilizas GLN, sigue sus reglas de asignación y gestión. No llames GLN a una secuencia local ni lo reutilices al cambiar la identidad de una ubicación.

Zonas temporales y excepciones

El diseño debe incluir lugares que no son racks de guarda:

recepción: objetos aún no aceptados;
staging: preparados para traslado o servicio;
cuarentena: daño, discrepancia o verificación pendiente;
devolución: retorno aún no conciliado;
overflow: capacidad temporal controlada;
desconocida: estado de excepción, no ubicación física ficticia.

No uses la oficina de una persona o “con sommelier” como dirección permanente. Las ubicaciones deben ser controlables, etiquetables y auditables.

Bin ocupado

Si el destino excede capacidad, rechaza o solicita autorización. No aumentes la capacidad automáticamente para que el evento pase.

Botella en lugar distinto al sistema

Realiza recuento, registra observación y corrige mediante evento vinculado. No borres el movimiento anterior.

Etiqueta dañada

Usa el código humano o un ID alternativo autorizado, verifica y reemplaza según el ciclo de etiquetado.

Sin conexión

Guarda el evento con ID único, origen esperado, destino escaneado y hora local. Muéstralo como pendiente y valida al sincronizar. Un formulario de contingencia debe conciliarse después.

Reubicación de racks

Mover o renumerar infraestructura es una migración:

congela el plano y genera una lista de contenidos;
crea o actualiza ubicaciones bajo una versión nueva;
controla staging temporal;
registra movimientos por botella o contenedor;
verifica ocupación y capacidad;
cierra ubicaciones antiguas sin borrar historial;
conserva el mapa de códigos anteriores para auditoría.

No actualices masivamente la “ubicación actual” sin eventos si después necesitarás explicar el cambio.

Conciliación física

El sistema expresa dónde debería estar cada objeto. El conteo confirma el mundo físico.

Una conciliación por zona compara:

contenido esperado del bin;
contenido observado;
botellas en ubicación equivocada;
slots vacíos inesperados;
capacidad excedida;
ubicaciones sin etiqueta o cerradas con contenido;
movimientos pendientes u offline.

Recuenta antes de ajustar. Conserva quién contó, cuándo, con qué alcance y qué movimiento corrigió la diferencia.

Métricas del piloto

En lugar de prometer localizar una botella en segundos, mide tu operación:

tiempo de búsqueda por tipo de ubicación;
primera lectura de etiquetas;
movimientos rechazados por origen o capacidad;
ocupación por zona y formato;
botellas en ubicación desconocida;
conflictos offline y antigüedad;
diferencias por conteo;
ubicaciones cerradas todavía referenciadas.

Compara contra una línea base con el mismo alcance y carga de servicio. El resultado depende de layout, disciplina de captura, señalización y formación.

Límites de Kavasoft

Al evaluar Kavasoft para restaurantes, confirma si el plan contratado soporta jerarquías, capacidad, estados de ubicación, historial origen-destino, roles, operación offline y exportación. La plataforma puede registrar ubicaciones y movimientos si está configurada para ello; no coloca físicamente la botella, no confirma por sí sola que el rack esté libre y no sustituye la conciliación.