Precios calculados en el servidor: la defensa contra el ticket manipulado desde la tablet
Cuando el precio de un platillo vive en la tablet del mesero, cualquiera con el acceso correcto puede cambiarlo antes de que el ticket llegue al folio del huésped. Aquí está por qué ese cálculo debe vivir en el servidor del restaurante de tu hotel, y cómo se detecta cuando alguien lo intenta de todos modos.
El contralor de un hotel revisa el corte de un turno y encuentra algo que no cuadra: un platillo que en el menú cuesta 180 aparece cobrado en 90 en un ticket, sin ninguna nota de cortesía ni de descuento autorizado. Nadie confiesa. El mesero dice que la tablet mostró ese precio. La pregunta correcta no es quién mintió: es dónde se calculó ese número, porque ahí está el origen real del problema.
Dos formas de calcular un precio, y solo una es segura
Hay dos maneras de construir el precio final de un ticket en el restaurante de un hotel. La primera es que la tablet del mesero tenga una copia del menú, calcule el subtotal, aplique impuestos y descuentos, y envíe al servidor el resultado ya hecho: “este ticket cuesta 540”. La segunda es que la tablet solo envíe qué se pidió, cada platillo con su identificador, y el servidor sea quien busca el precio vigente, aplica impuestos, revisa si hay algún descuento válido y calcula el total desde cero.
La diferencia entre las dos formas parece técnica, pero tiene una consecuencia directa sobre la seguridad del restaurante de tu hotel: en la primera forma, cualquiera que pueda intervenir la aplicación, el tráfico de red o incluso instalar una versión modificada en un dispositivo, puede cambiar el número final antes de que llegue al servidor. En la segunda forma, ese número nunca sale de la tablet: el servidor lo calcula él mismo, con su propia copia del menú, y no le importa qué diga la tablet sobre cuánto debería costar.
Por qué calcular en la tablet abre la puerta a la manipulación
Una tablet es un dispositivo físico que vive en el restaurante, a veces sin supervisión directa durante horas, especialmente en turnos nocturnos o en puntos de consumo remotos como el bar de alberca. Si el precio final se calcula ahí, existen varias formas de alterarlo: interceptar y modificar la solicitud antes de que salga hacia el servidor, usar una aplicación alterada que cambia los números antes de mostrarlos, o simplemente aprovechar un error de la aplicación que permite editar un campo que no debería ser editable.
Ninguna de estas formas requiere ser un experto en sistemas. Basta con que alguien sepa que el precio se puede tocar y tenga acceso físico al dispositivo el tiempo suficiente. Y en el restaurante de un hotel, con rotación de personal y turnos que cambian de manos varias veces al día, ese acceso físico eventual es prácticamente garantizado.
Cómo funciona el cálculo en el servidor, paso a paso
- La tablet envía únicamente qué se pidió: el identificador de cada platillo y la cantidad, nunca un precio.
- El servidor busca el precio vigente de cada platillo en su propio catálogo, el mismo que usa el menú digital y el que administra el gerente.
- El servidor revisa si aplica algún descuento o cortesía, y solo acepta los que fueron autorizados por alguien con el permiso correspondiente, verificado en el propio servidor.
- El servidor calcula el impuesto según la configuración fiscal de la propiedad, no según lo que la tablet asuma.
- El servidor arma el total final y se lo devuelve a la tablet ya calculado, para que el mesero lo muestre al huésped.
- Ese mismo total, calculado por el servidor, es el que viaja al folio del huésped cuando el consumo se carga a la habitación, así que el restaurante y recepción siempre ven el mismo número.
Con este diseño, no importa qué diga la tablet, qué versión de la aplicación tenga instalada o si alguien intentó interceptar el tráfico de red: el precio que termina en el ticket y en el folio siempre es el que el servidor calculó con su propio catálogo, en el momento del pedido.
Quién puede cambiar un precio, y cómo queda registrado
Que el precio se calcule en el servidor no significa que nunca pueda cambiar: significa que solo cambia cuando alguien con el permiso correcto lo autoriza, y que ese cambio queda registrado con nombre, hora y motivo. Un gerente que aplica una cortesía, un supervisor que autoriza un descuento por una queja del huésped, o un ajuste de precio de temporada en el catálogo son todos cambios legítimos, pero todos deben pasar por el mismo camino: una acción autorizada en el servidor, nunca una edición silenciosa en la pantalla del mesero.
La pregunta que debes poder responder en cualquier momento es: ¿quién cambió este precio, cuándo y con qué justificación? Si la respuesta es “no lo sabemos, la tablet mostró ese número”, el sistema no está calculando el precio en el lugar correcto.
Cómo se detecta un intento de manipulación
Un sistema que calcula precios en el servidor puede además vigilar activamente los intentos de manipulación, porque cada solicitud que llega desde la tablet incluye información que el servidor puede comparar contra lo que él mismo esperaba recibir.
- Si la tablet envía un total distinto al que el servidor calcula con su propio catálogo, esa discrepancia queda registrada como una alerta, aunque el servidor use siempre su propio número.
- Si un mismo dispositivo genera muchas discrepancias en poco tiempo, el patrón es visible en el reporte de seguridad, no oculto en el ruido de las operaciones normales.
- Si alguien intenta aplicar un descuento sin el permiso correspondiente, el servidor lo rechaza y registra el intento, incluyendo quién estaba autenticado en ese momento.
- Si un platillo se envía con un identificador que no existe en el catálogo vigente, el servidor lo rechaza en lugar de aceptar cualquier precio que la tablet proponga.
Un ejemplo ilustrativo del costo de calcular en la tablet
Las cifras que siguen son inventadas para mostrar el cálculo, no describen ningún hotel real. Imagina un restaurante de hotel con 90 tickets por día donde, por un sistema que confía en el precio que envía la tablet, un empleado logra aplicar un descuento no autorizado en uno de cada treinta tickets.
| Concepto | Valor (ejemplo ilustrativo) |
|---|---|
| Tickets procesados al día | 90 |
| Proporción con descuento no autorizado | 1 de cada 30 |
| Tickets afectados al día | 90 ÷ 30 = 3 |
| Descuento promedio aplicado sin autorización | 90 |
| Pérdida diaria | 3 × 90 = 270 |
| Pérdida en un mes de 30 días | 270 × 30 = 8,100 |
En el ejemplo, 8,100 al mes es dinero que el restaurante nunca cobró y que ningún reporte de ventas va a mostrar como faltante, porque desde el punto de vista del sistema, cada ticket se cerró en su monto correcto. Con el precio calculado en el servidor, ese mismo descuento no autorizado simplemente no existe: la solicitud llega, el servidor calcula el precio real del catálogo, y si nadie autorizó un descuento, el ticket se cierra en 180, no en 90.
La relación con el cargo a la habitación
Este problema se vuelve más serio en el restaurante de un hotel porque el ticket no siempre se paga en efectivo o con tarjeta en el momento: muchas veces se carga al folio del huésped, y ese folio termina en el estado de cuenta que recepción entrega en la salida. Si el precio se pudo manipular en la tablet, el error o el fraude no se queda en el restaurante: viaja hasta el folio del huésped, y desde ahí hasta la contabilidad del hotel, sin que nadie lo note hasta que alguien haga una auditoría manual.
El precio final de un ticket debe calcularlo el servidor con su propio catálogo, nunca la tablet del mesero. Solo así ningún cambio en el dispositivo, en la red o en la aplicación puede alterar cuánto paga realmente el huésped. Cualquier descuento debe pasar por una autorización verificada en el servidor, con registro de quién y por qué.
Qué hacer esta semana
- Pregunta a tu proveedor actual dónde se calcula el precio final del ticket: en la tablet o en el servidor.
- Pide un reporte de discrepancias entre lo que la tablet envía y lo que el servidor calcula, si tu sistema lo tiene.
- Revisa con tu contralor si en el último corte hubo tickets con descuentos sin la autorización correspondiente registrada.
- Verifica quién en tu equipo tiene permiso para aplicar descuentos y confirma que ese permiso se valida en el servidor, no solo en la pantalla.
- Si tu sistema actual no puede explicar quién cambió un precio y por qué, súmalo a la lista de riesgos que tu próxima evaluación de proveedor debe resolver.
Inn Restaurant calcula cada precio en el servidor a partir del catálogo vigente de la propiedad, sin excepción, y registra cualquier descuento con quién lo autorizó y por qué. Puedes revisar cómo funciona en la página de seguridad (Seguridad y control) o verlo en vivo en una demo de 15 minutos (contacto).
Más artículos
Operaciones atómicas: por qué un cargo al folio debe ocurrir completo o no ocurrir
Un cargo a la habitación toca dos sistemas a la vez: el restaurante de tu hotel y el folio del huésped en recepción. Si la tablet se apaga a la mitad, el sistema tiene que decidir qué hacer con esa mitad, y esa decisión es la diferencia entre un hotel confiable y uno que discute con sus huéspedes.
La red del hotel para el restaurante: cobertura en la alberca, tablets y qué hacer cuando falla el internet
El punto de venta del restaurante de un hotel comparte la red con doscientos huéspedes viendo series. Cómo separar zonas, dar prioridad a la venta, elegir tablets que aguanten el turno y tener un plan de contingencia que sí se pueda ejecutar a las nueve de la noche.
Punto de venta y sistema de gestión hotelera en uno: por qué la integración es la fuente de casi todos los errores
Cuando el restaurante del hotel usa un sistema y recepción usa otro, hay un enlace en medio. Ese enlace es donde vive cada cargo que no llegó al folio, cada huésped que cambió de habitación y cada conciliación de fin de mes que no cuadra.
El restaurante de tu hotel ya vende bien. Falta que el hotel lo sepa.
Quince minutos, con tu carta y tus mesas. Sin instalar nada.