API y eventos: qué debe poder leer y escribir tu contador desde el sistema del restaurante del hotel

Cada fin de mes, el contador de un hotel arma el mismo ritual: pide el reporte de ventas al gerente del restaurante, pide el corte de caja al cajero, pide el reporte de cargos a la habitación a recepción, y se sienta a cuadrar tres archivos que casi nunca coinciden exactamente. El problema no es que el contador trabaje poco. El problema es que nadie le dio una manera ordenada de leer los datos directamente de donde viven.

Por qué un reporte en PDF ya no alcanza

Un reporte de fin de mes es una fotografía tomada una vez, de un momento que ya pasó. Si el contador necesita revisar algo que ocurrió hace dos semanas, tiene que pedir otro reporte, esperar a que alguien lo genere, y confiar en que nadie tocó nada entre el cierre del periodo y el momento en que se generó el archivo. Un contador que trabaja con hoteles de verdad necesita algo distinto: acceso directo a los datos, en el momento en que los necesita, sin depender de que alguien más se acuerde de generarle un archivo.

Eso es lo que resuelve una API: una puerta de entrada ordenada a los datos del sistema del restaurante de tu hotel, donde el contador, o el software de contabilidad que usa, puede pedir exactamente lo que necesita, cuando lo necesita, sin tener que pasarle un usuario y contraseña de la tablet del mesero ni pedirle a nadie que le exporte un archivo.

Qué es una API y qué son los eventos, sin jerga

Una API es simplemente un conjunto de puertas bien definidas para pedir o entregar información a un sistema, sin tener que entrar por la puerta principal que usan los meseros y los gerentes. Cada puerta tiene un propósito claro: una para consultar el catálogo de platillos, otra para consultar las órdenes de un día, otra para consultar los cortes de caja. Quien entra por esa puerta solo puede hacer lo que esa puerta permite, ni más ni menos.

Un evento es distinto de un reporte: en lugar de que el contador tenga que preguntar “¿qué pasó hoy?”, el sistema le avisa en el momento en que algo relevante ocurre: se cerró un ticket, se aplicó un cargo a la habitación, se cerró la caja del turno. El contador, o su software, recibe ese aviso al instante y puede procesarlo de inmediato, en lugar de esperar al final del día para descubrir todo junto.

Qué debe poder LEER tu contador

La lista de lo que un contador necesita leer del sistema del restaurante de un hotel es más corta de lo que parece, pero cada elemento importa por una razón contable específica.

Con estos seis conjuntos de datos, disponibles a través de la API en el momento en que el contador los pide, el trabajo de cuadrar el mes deja de ser una investigación entre archivos sueltos y se convierte en una consulta directa a la fuente de la verdad.

Qué debe poder ESCRIBIR tu contador, y por qué es tan poco

Aquí es donde muchos hoteles se equivocan al configurar el acceso: le dan al contador o a su software un usuario con permisos amplios “por si acaso”, y ese “por si acaso” es exactamente lo que un mal actor, interno o externo, aprovecharía si ese acceso alguna vez se filtra. La regla correcta es distinta: el acceso de contabilidad casi nunca necesita escribir nada en el sistema operativo del restaurante.

Lo único que un contador podría necesitar escribir, y solo si tu hotel lo decide así, son ajustes contables específicos marcados claramente como tales: por ejemplo, una nota de reclasificación de un consumo entre categorías fiscales. Incluso ahí, ese ajuste debe quedar registrado en el mismo historial de auditoría que cualquier otra operación, con el nombre de quién lo hizo y por qué, nunca como una edición silenciosa de un dato que ya existía.

• El contador puede leer catálogo, órdenes, caja y folios sin restricción dentro de su acceso.
• El contador casi nunca necesita cerrar un ticket, aplicar un descuento ni modificar un precio: eso es operación, no contabilidad.
• Cualquier ajuste contable que sí requiera escribir algo debe quedar registrado con nombre, hora y motivo.
• El acceso de contabilidad se revoca de inmediato cuando cambia el contador o la firma que lleva la contabilidad del hotel.

Llaves de acceso por propiedad, no una sola puerta para todos

Si tu hotel forma parte de un grupo con más de una propiedad, o si tu firma de contabilidad atiende a varios hoteles de distintos dueños, la llave de acceso a la API nunca debe ser una sola que abra todas las propiedades a la vez. Cada propiedad debe tener su propia llave, y esa llave solo debe dar acceso a los datos de esa propiedad específica, sin importar que la misma persona o el mismo software administren varias llaves distintas para varios hoteles distintos.

Esta separación protege dos cosas a la vez: si la llave de una propiedad se filtra, el daño se limita a esa propiedad, y no se abre automáticamente el acceso a las demás. Y si tu firma de contabilidad deja de atender a uno de los hoteles del grupo, revocar esa llave específica no afecta el acceso a las otras propiedades que sí sigue atendiendo.

Cómo se entrega una llave nueva sin exponer nada

1. El dueño o el gerente general del hotel solicita la llave desde el panel administrativo del sistema, nunca por correo ni por mensaje.
2. La llave se genera con permisos de solo lectura sobre los datos que el contador necesita, según la lista acordada.
3. La llave se entrega directamente al contador o se configura en el software de contabilidad, sin pasar por un canal donde alguien más pueda verla.
4. Cada uso de la llave queda registrado en el historial de auditoría, con qué se consultó y cuándo.
5. Si el hotel cambia de contador, la llave anterior se revoca el mismo día, no “cuando alguien se acuerde”.

Eventos en tiempo real frente al reporte de fin de día

Un contador que solo recibe un reporte al final del día descubre los problemas tarde: un descuento no autorizado, un patrón raro en los cortes de un punto de consumo, una diferencia entre lo cobrado y lo cargado al folio. Un contador que recibe eventos en tiempo real, o que revisa la API con frecuencia durante el día, puede detectar esos mismos problemas mientras el turno sigue abierto, cuando todavía es posible preguntarle a alguien qué pasó.

Esto no significa que el contador tenga que estar pegado a una pantalla todo el día. Significa que el sistema del restaurante de tu hotel debe estar diseñado para avisar, no solo para reportar después, y que ese aviso debe llegar por el mismo canal ordenado de la API, no por una llamada telefónica del gerente cuando algo ya salió mal.

Un ejemplo ilustrativo del tiempo que ahorra la integración

Las cifras que siguen son inventadas para mostrar el cálculo, no describen ningún hotel real. Imagina un hotel donde, sin acceso directo a la API, el contador dedica 5 horas al mes a pedir, recibir y conciliar reportes en PDF de tres áreas distintas: restaurante, caja y recepción.

En el ejemplo, el ahorro de 1,600 al mes no viene de que el contador trabaje menos horas por trabajar menos: viene de que dejó de perder tiempo pidiendo, esperando y comparando archivos que en teoría deberían decir lo mismo. Ese tiempo se puede usar en algo que sí agrega valor, como revisar tendencias o preparar la declaración con más anticipación.

Qué hacer esta semana

1. Pregunta a tu contador cuánto tiempo dedica cada mes a pedir y conciliar reportes por separado del restaurante, la caja y recepción.
2. Revisa con tu proveedor si tu sistema ofrece acceso por API con llaves separadas por propiedad, o si solo entrega reportes manuales.
3. Confirma qué permisos tiene hoy el usuario de contabilidad en tu sistema: si puede escribir algo que no debería, ajústalo.
4. Si tienes más de una propiedad o trabajas con una firma externa, verifica que cada una tenga su propia llave de acceso.
5. Pide ver el historial de auditoría de accesos por API del último mes, si tu sistema lo tiene disponible.

Inn Restaurant expone catálogo, órdenes, cortes de caja y cargos a folios a través de una API con llaves separadas por propiedad, pensada para que tu contador consulte lo que necesita sin pedirle un reporte a nadie. Puedes ver el detalle en la página de desarrolladores (Desarrolladores) o preguntar por tu caso específico en una demo de 15 minutos (contacto).