Estancia mínima y cierres de llegada: las reglas que deciden si una fecha es reservable
Una temporada es una sola decisión comercial — "agosto son 140, mínimo tres noches, sin llegadas en sábado" — pero para el software son dos preguntas distintas. ¿Cuánto cuesta esta estancia, y se puede aceptar?
Precio y permiso son preguntas distintas
Quien gestiona un espacio piensa en temporadas: agosto son 140 la noche, mínimo tres noches, sin llegadas en sábado. Para él es una decisión. Para el software son dos preguntas, hechas en momentos distintos y por quien llama desde sitios distintos.
El precio se pregunta cuando alguien está casi decidido. El permiso — ¿puede existir esta estancia? — tiene que poder responderse antes de que nadie haya aceptado pagar nada, porque es la comprobación de disponibilidad la que lo necesita para decidir si pinta una fecha como reservable.
Las dos respuestas deben leer las mismas filas de regla. Si se separan en tablas distintas, llegará el día en que alguien cambie el precio de agosto y se deje atrás el mínimo de agosto.
Las tarifas se resuelven noche a noche
Una estancia que empieza en temporada baja y acaba en alta no tiene "una tarifa". Cada noche paga la tarifa de la regla que la cubre, y el total es su suma.
Parece obvio y se hace mal constantemente, porque una tarifa única por estancia es mucho más cómoda de guardar. El fallo es invisible: ningún error, ninguna queja, solo un total silenciosamente equivocado en cada reserva que cruza un límite, en la dirección que la implementación eligió sin decirlo.
Cuando varias reglas podrían cubrir la misma noche, la precedencia tiene que ser determinista y no la que devuelva antes la base de datos. En Boris una regla de una habitación concreta gana al valor por defecto del espacio, y entre dos reglas del mismo nivel gana la fecha de inicio más reciente.
Las restricciones pertenecen a la noche de llegada
Noches mínimas y máximas y los cierres de llegada se juzgan con la regla que cubre la noche en que la estancia empieza. Es la convención que sigue cualquier channel manager, y no es una elección arbitraria.
Mírese la alternativa. Si el mínimo se aplicara a cada regla que la estancia toca, alguien que llega el 30 de julio para cuatro noches quedaría rechazado porque su estancia roza una regla de agosto que pide tres: una estancia de cuatro noches rechazada por ser demasiado corta. Comprobar todas las noches convierte un suelo en una trampa.
El cierre de salida es la excepción, y es el detalle que más se olvida: la fecha de salida no es una noche de la estancia. La regla de la noche de llegada puede no extenderse hasta ese punto del calendario, así que necesita su propia consulta. Quien la mete dentro de la regla de llegada se queda con un fallo que solo asoma en estancias largas, que son precisamente las reservas que menos conviene equivocar.
Cero no es un límite
Un detalle pequeño con consecuencias grandes: en una columna de "noches mínimas" que admite NULL van a aparecer tanto NULL como 0, y los dos significan "sin límite". Un sistema que tome el 0 guardado como mínimo real comparará todas las estancias con él y no rechazará nada — o, si la comparación está escrita al revés, las rechazará todas. Esto se normaliza una vez, al leer, no en cada sitio que pregunta.
Rechazar en el checkout es un fallo, no una protección
Una restricción que solo se aplica al enviar la reserva sigue siendo correcta y sigue siendo una mala experiencia. El huésped ha elegido fechas, ha metido sus datos, ha llegado al pago, y ahí se le dice que los sábados no se puede llegar.
La solución es exponer la restricción, no solo el veredicto. El endpoint de disponibilidad de Boris sabe decir qué exige una fecha de llegada — noches mínimas, máximas, si la llegada o la salida están cerradas — para que la tienda deshabilite las fechas que iba a rechazar en lugar de rechazarlas después del checkout. La misma regla, una consulta antes, una conversión completamente distinta.
Por lo mismo, todos los caminos de reserva tienen que consultar las reglas. Una tarifa o una restricción que vale en el panel pero no en la tienda, la app o la API es peor que no tenerla: parece aplicada, y eso impide que alguien la revise.
Nada debe cambiar hasta que exista una regla
Última propiedad de una implementación sensata: cuando ninguna regla cubre la estancia, el resolutor no devuelve nada y quien pregunta se queda con el precio que ya tenía. Instalar tarifas por temporada no debe alterar ningún precio existente hasta que alguien escriba una temporada a propósito.
Los huecos conviene informarlos, no rellenarlos. Una noche sin cubrir dentro de un plan diario puede caer sobre el precio de ese plan de forma defendible. Un precio mensual no se divide en noches de ninguna manera que se pueda justificar ante un cliente, así que ahí lo honesto es declinar el presupuesto en vez de inventar una cifra.
Preguntas frecuentes
¿La estancia mínima se aplica a todas las noches?
No. Se comprueba contra la regla que cubre la noche de llegada, que es la convención de todos los channel managers. Si no, una estancia que solo roza una temporada de tres noches quedaría rechazada por su segunda noche: alguien que llega en temporada baja y sale en alta recibiría un "su estancia es demasiado corta" que la regla nunca quiso decir.
Si la estancia cruza dos temporadas, ¿qué tarifa se aplica?
Cada noche paga la tarifa de la regla que la cubre. Una tarifa única por estancia no sabe representar una estancia que empieza barata y acaba cara: redondea hacia el extremo para el que se escribió, y el margen se pierde justo en las reservas que cruzan el límite entre temporadas.
¿Por qué el cierre de salida es una comprobación aparte?
Porque la fecha de salida no es una noche de la estancia. La regla que cubre la noche de llegada puede no llegar hasta ahí, así que necesita su propia consulta sobre la fecha de salida. Meterla dentro de la regla de llegada es un fallo que solo aparece en estancias largas.
¿Deben aplicarse estas restricciones a reservas por horas?
Nunca. "Mínimo tres noches" no significa nada para una sala de reuniones o un puesto, y aplicar en silencio una regla de noches a una reserva por horas cerraría un coworking por accidente. Una petición sin noches debe saltarse la comprobación.