Trazabilidad de botellas de vino: guía para restaurantes

Trazabilidad es poder reconstruir qué ocurrió

La trazabilidad de botellas de vino es la capacidad de reconstruir la historia, aplicación o ubicación de un objeto a partir de identificadores y eventos. En un restaurante, responde preguntas concretas: ¿qué botella o lote se recibió?, ¿de quién?, ¿en qué ubicación quedó?, ¿quién aceptó su custodia?, ¿qué movimientos ocurrieron?, ¿cuándo se sirvió, devolvió o retiró?

No elimina pérdidas ni disputas por sí sola. Tampoco demuestra autenticidad, propiedad jurídica, estado físico o condiciones ambientales. Mejora la evidencia disponible cuando identidad, proceso y captura se diseñan bien.

Modelo mínimo: objeto identificado + evento observable + fecha y zona + ubicación + motivo y estado + actor y fuente + evidencia proporcional + corrección vinculada cuando sea necesaria.

Esta guía se concentra en el modelo de eventos y responsabilidad. QR, código de barras, RFID o NFC son medios de captura; su selección e implantación corresponden a etiquetado de botellas, escaneo QR y QR en botellas de cava.

Define alcance antes de serializar

Hay dos alcances relacionados pero distintos:

Trazabilidad entre empresas

Conecta proveedor, recepción, lote o unidad logística y, cuando corresponde, el destinatario empresarial posterior. Sirve para responder a una retirada, una consulta del proveedor o una obligación regulatoria.

Trazabilidad interna

Registra lo que ocurre dentro del restaurante: alta, asignación, ubicación, traslado, inspección, servicio, devolución, ajuste y baja. Puede trabajar por lote, caja o botella según el riesgo y la decisión.

El Reglamento (CE) 178/2002 exige trazabilidad de alimentos en las etapas de producción, transformación y distribución y que los operadores puedan identificar a sus proveedores y a las empresas a las que suministran. El artículo 18 no impone por sí solo que cada restaurante serialice cada botella ni que identifique al consumidor final. Evalúa obligaciones concretas por jurisdicción, actividad y canal con asesoría competente.

La Organización Internacional de la Viña y el Vino también publica directrices sectoriales para un enfoque armonizado. Ninguna referencia sustituye el análisis legal del establecimiento.

Producto, lote e instancia no son lo mismo

Nivel	Qué identifica	Ejemplo conceptual	Límite
Producto o clase	un tipo de artículo comercial	etiqueta + añada + formato	varias botellas comparten identidad
Lote	unidades relacionadas por producción o criterio del fabricante	lote declarado por proveedor	no distingue una botella dentro del lote
Instancia	una unidad física concreta	GTIN + serial o ID interno único	exige vincular el ID a la botella correcta
Agrupación	caja, pallet, locker u otro contenedor	ID del contenedor y sus miembros	debe actualizarse al agregar o retirar unidades

En el sistema GS1, el GTIN identifica el artículo comercial a nivel de clase. Para una instancia individual puede combinarse con un serial; lote y serial cumplen funciones distintas. Un restaurante también puede usar un identificador interno único si documenta su alcance y evita colisiones.

No inventes un GTIN del fabricante. Si el artículo no tiene uno o el restaurante no necesita interoperabilidad externa, conserva el identificador del proveedor como dato y crea un ID interno bajo reglas propias.

Reglas del identificador interno

no contiene nombre de propietario, valor ni ubicación;
no se reutiliza silenciosamente después de una baja;
se genera una sola vez o con control de duplicados;
la reimpresión conserva vínculo y queda registrada;
una etiqueta sustituida invalida la anterior cuando el medio lo permite;
el ID visible no funciona como credencial ni secreto;
la unidad física se verifica antes de vincular.

Una etiqueta puede copiarse o trasladarse. El identificador facilita captura; no auténtica el vino ni garantiza que el soporte siga unido al mismo objeto.

Actores, roles, ubicaciones y custodia

Modela entidades antes de registrar eventos:

parte: proveedor, restaurante, socio u otra organización/persona autorizada;
rol: entrega, recibe, autoriza, transporta, audita o sirve;
ubicación: restaurante, almacén, cava, zona, locker o estación;
objeto: producto, lote, botella o contenedor;
documento: pedido, recepción, devolución, auditoría o incidencia.

Custodia física y propiedad no son sinónimos. Una botella puede pertenecer a un socio y estar bajo custodia del restaurante; Kavasoft puede registrar datos sin poseerla físicamente. Conserva relaciones separadas:

Relación	Qué responde
Propietario declarado	¿a quién atribuye el sistema la titularidad?
Custodio actual	¿qué parte aceptó responsabilidad física?
Ubicación conocida	¿dónde fue observada por última vez?
Responsable operativo	¿qué rol debe actuar ante una excepción?

El registro refleja declaraciones y eventos aportados; no decide por sí solo una controversia jurídica de propiedad.

Eventos críticos y datos clave

GS1 denomina Critical Tracking Events (CTE) a los pasos del proceso que es importante registrar y Key Data Elements (KDE) a los datos que describen cada instancia del evento. EPCIS organiza visibilidad alrededor de qué, cuándo, dónde, por qué y cómo.

Para un restaurante, una taxonomía práctica puede ser:

Evento	Objeto	Resultado esperado	Excepción importante
Recepción	lote, caja o botella	cantidad y condición aceptadas	diferencia, daño o producto sin identificar
Comisión/vinculación	botella + ID	identidad interna activa	etiqueta duplicada o vínculo dudoso
Ubicación	objeto o contenedor	observación en zona concreta	destino inexistente o no autorizado
Transferencia	origen y destino	cambio solicitado	objeto no disponible o traslado duplicado
Aceptación de custodia	objeto + partes	nuevo custodio confirma recepción	entrega sin aceptación o cantidad distinta
Inspección	objeto	condición observada y evidencia	daño, sello dudoso o foto faltante
Servicio/apertura	botella	disposición cambia a servicio/consumo	ID no coincide o evento se cancela
Devolución	objeto	regresa a ubicación y estado definidos	unidad distinta o condición cambiada
Ajuste	objeto y cantidad	diferencia explicada y autorizada	ajuste sin conteo ni aprobador
Baja	objeto	consumo, devolución, destrucción u otra salida	motivo o evidencia insuficiente

No todos requieren escaneo. La regla es capturar en el punto donde cambia la responsabilidad, ubicación o disposición de manera relevante.

Qué debe contener cada evento

Qué

ID de instancia, lote o agrupación dentro del alcance;
cantidad y unidad;
relación con contenedor o documento;
estado anterior y posterior cuando aplique.

Cuándo

hora real del evento;
zona horaria y offset;
hora de registro si fue posterior;
secuencia cuando varios eventos comparten momento.

Dónde

ubicación de lectura;
origen y destino para un traslado;
nivel de precisión justificado: local, cava, zona o locker.

Por qué

paso de negocio, como recepción, almacenamiento o servicio;
disposición posterior, como disponible, reservado, abierto o retirado;
motivo estructurado para excepción o ajuste;
referencia a pedido, reserva, auditoría o incidencia.

Quién y fuente

usuario o sistema que capturó;
rol que autorizó;
dispositivo o integración de origen;
parte que entrega y parte que acepta en cambio de custodia.

Evidencia

fotografía, documento o nota cuando el riesgo lo exige;
hash o identificador del archivo;
timestamp y autor;
política de acceso y retención.

Una foto documenta lo visible en un momento; no prueba autenticidad, condiciones anteriores ni ausencia total de manipulación. Una marca temporal demuestra lo que registró el sistema, no vuelve el hecho incontrovertible.

Cambio de custodia con doble confirmación

Actualizar ubicación = mesa no demuestra que alguien aceptó la botella. Para transferencias de mayor riesgo, usa estados:

solicitada: origen, destino, objeto y motivo definidos;
preparada: custodio saliente verifica la unidad;
entregada: queda constancia del traspaso físico;
aceptada: custodio entrante confirma identidad, cantidad y condición;
en excepción: existe desacuerdo o falta una parte;
cerrada: ubicación, custodio y evidencia quedan coherentes.

La aceptación puede ser simultánea o posterior según operación. Si el receptor no confirma dentro de la ventana, no declares automáticamente éxito: conserva el caso pendiente y escala.

Los procedimientos detallados para entrega, transporte y evidencia pertenecen a cadena de custodia de botellas. Aquí interesa que la transición produzca eventos compatibles con el historial.

Offline, eventos tardíos y duplicados

En una cava puede fallar la red. El dispositivo debe guardar un identificador de evento, hora local confiable, usuario, objeto y acción; al sincronizar, el servidor conserva tanto hora del hecho como hora de recepción.

Aplica:

clave idempotente para no duplicar al reintentar;
validación de reloj y zona;
estado “pendiente de sincronizar” visible;
resolución de conflictos, no “último cambio gana”;
límites a operaciones offline de alto riesgo;
conciliación después de recuperar conexión.

Si dos personas registran movimientos incompatibles, crea una excepción. No alteres el pasado para que la historia parezca lineal.

Corregir sin sobrescribir silenciosamente

Los errores ocurren: botella equivocada, ubicación invertida o cantidad mal capturada. Conserva el evento original y añade una corrección vinculada con:

ID del evento afectado;
motivo;
valor correcto;
quién solicita y quién aprueba;
fecha efectiva y fecha de registro;
impacto sobre eventos posteriores.

No hace falta prometer una bitácora “inmutable”. Sí hace falta impedir que una edición ordinaria destruya la secuencia y aplicar controles de acceso, versión y respaldo proporcionados al riesgo.

La prueba de recorrido debe descubrir huecos, no solo mostrar una línea bonita: un evento sin actor, ubicación o aceptación sigue incompleto.

Reconciliar historial y conteo físico

La existencia calculada se deriva de eventos; el conteo físico observa el mundo. Compara ambos con un corte común.

congela o controla movimientos durante el conteo;
define ubicación y población esperada;
captura observaciones físicas sin copiar el saldo esperado cuando sea viable;
identifica faltantes, sobrantes, duplicados y objetos en ubicación distinta;
revisa eventos tardíos y transferencias pendientes;
clasifica causa;
aprueba ajustes por rol;
crea eventos de corrección, no ediciones ocultas;
verifica el saldo final;
conserva evidencia del cierre.

Una política “sin escaneo no se mueve” puede mejorar disciplina, pero necesita excepciones seguras: emergencia, etiqueta dañada, dispositivo sin conexión y servicio inmediato. El objetivo es que esas excepciones entren a una cola visible y se regularicen, no forzar datos ficticios.

Prueba de retirada o investigación

Realiza un ejercicio con un lote o proveedor de prueba:

identifica todas las unidades recibidas;
muestra ubicaciones y disposición actuales;
separa botellas disponibles, servidas, devueltas y sin estado;
identifica proveedor directo y, cuando aplique, destinatarios empresariales;
bloquea movimientos mientras se investiga;
registra cuarentena, devolución o baja;
demuestra quién tomó cada decisión;
mide tiempo y huecos;
corrige el proceso.

La trazabilidad individual interna puede dar más precisión, pero no sustituye documentación de proveedor, lote ni obligaciones externas. Una botella serializada sin lote de origen puede ser inútil para una retirada.

Accesos, privacidad y retención

Separa capacidades:

capturar evento;
aprobar ajuste;
reasignar custodia;
consultar identidad de socio;
exportar historial;
administrar catálogos y ubicaciones;
corregir o anular mediante eventos controlados.

Los movimientos vinculados con socios o personal pueden contener datos personales. Minimiza nombres en pantallas y etiquetas, usa roles cuando sea suficiente y define finalidad, acceso y retención conforme a la LFPDPPP vigente. Un identificador público no debe revelar dueño, valor, locker ni historial.

La retención depende de finalidad operativa, contractual y legal. Conserva el historial necesario para reconstruir, pero no adjuntos o datos personales indefinidamente “por si acaso”. Coordina borrado, anonimización y copias de respaldo.

Métricas de calidad, no beneficios inventados

Mide si el sistema produce evidencia útil:

cobertura de eventos críticos;
porcentaje con objeto, hora, ubicación, motivo y actor completos;
tiempo entre evento y registro;
duplicados y conflictos;
transferencias sin aceptación;
correcciones por causa;
objetos sin ubicación o disposición;
diferencia entre conteo físico y saldo calculado;
tiempo para recorrer proveedor → existencia → salida;
huecos encontrados en el ejercicio de retirada;
usuarios o integraciones con permisos excesivos.

No prometas reducir merma a un porcentaje fijo ni eliminar disputas. Define una línea base local y observa si mejoran completitud, oportunidad y capacidad de investigación.

Tecnología: portador, captura y backend

Un QR o código de barras representa datos; RFID permite otra forma de captura. Ninguno crea por sí solo el evento, verifica al actor ni decide la disposición. El backend valida permisos, guarda el evento, resuelve duplicados y conserva el historial.

El rendimiento de RFID cerca de líquidos, vidrio, metal y estantería depende de etiqueta, frecuencia, antena, lector, orientación y entorno. Prueba físicamente antes de publicar distancia, velocidad o costo. Un sello o etiqueta destructible puede aportar una señal de intervención, pero no auténtica la botella.

Papel y límite de Kavasoft

Kavasoft puede registrar inventario, movimientos, fotografías y auditorías aportadas por el operador. Esas funciones pueden formar parte de una trazabilidad interna si se configuran y utilizan con un protocolo coherente.

Kavasoft no es custodio físico, autenticador, asegurador, sensor ni garante de la cadena de custodia. El restaurante controla la botella, define responsables y verifica lo ocurrido. Confirma el alcance de Kavasoft para restaurantes: identificadores, estados, permisos, evidencia, exportación, operación offline e integraciones disponibles en tu plan.

Checklist de diseño

Fuentes y lecturas recomendadas

GS1 Global Traceability Standard, marco para identificar objetos, definir eventos críticos y capturar datos clave de trazabilidad.
GS1 EPCIS, modelo e interfaces de eventos para responder qué, dónde, cuándo, por qué y cómo, incluidos movimiento y cadena de custodia.
OIV: Traceability Guidelines in the Vitivinicultural Sector, directrices oficiales del sector vitivinícola.
Reglamento (CE) 178/2002, artículo 18, texto consolidado sobre trazabilidad alimentaria en la Unión Europea.
Cámara de Diputados: LFPDPPP vigente, referencia para datos personales en relaciones de socios, personal y registros de actividad en México.