Disponibilidad y overbooking

La disponibilidad responde una sola pregunta: ¿esta unidad puede tomar esta
estadía? Cómo se calcula depende por completo de la
configuración de la unidad.

Dos estadías se traslapan cuando una empieza antes de que la otra termine y
termina después de que la otra empiece — así que el día de salida queda libre
para volver a venderse. Las reservas canceladas nunca cuentan contra la
disponibilidad.

El camino interno no puede sobrevender

Toda reserva hecha dentro de Axis Pro — pantallas merchant, External API, móvil,
seeders — pasa por un solo flujo, dentro de una única transacción con candados de
fila. La disponibilidad se vuelve a revisar bajo candado, así que un
conflicto se rechaza en vez de registrarse.

Cuando se pide un room type sin nombrar habitación, Axis Pro asigna una. Cuando
se nombra una habitación concreta y está tomada, la petición se rechaza en vez de
moverse calladamente.

Estos rechazos son el sistema funcionando:

Son prevención de overbooking, no overbooking.

De dónde viene el overbooking de verdad

De los canales. Axis Pro empuja disponibilidad al channel manager con cada cambio
de reserva, pero una venta de OTA y ese push no son una sola transacción atómica.
En los segundos entre que una habitación se agota acá y que availability: 0
llega a todas las OTAs, una OTA puede aceptar una reserva más por una habitación
que ya no está.

Ese huésped reservó de verdad y pagó de verdad. Axis Pro no puede rechazar un
hecho. Así que una reserva entrante sin habitación libre se crea igual — sin
habitación física asignada y con el conflicto registrado y señalado.

flowchart TD
    W["El canal avisa<br/>de una reserva de OTA"] --> M["Mapear el room type a una unidad"]
    M --> A{"¿Hay una habitación libre<br/>para esas fechas?"}
    A -- sí --> OK["Asignar 201 / 202 ...<br/>registrada, sin conflicto"]
    A -- no --> CF["Registrar la reserva igual<br/>sin habitación asignada<br/>señalada como conflicto"]

El canal solo sabe un room type y un número. Nunca dice qué habitación física.
La asignación de habitación es exclusivamente de Axis Pro, que es justamente
por lo que puede ser inteligente con ella: el canal dice "una Doble Deluxe", Axis
Pro decide que esa es la 201.

La señal de overbooking

Un overbooking es más huéspedes que habitaciones, y le llega a un operador en
dos formas:

• Sin asignar — no se encontró habitación. Inventario fragmentado, un canal
  que vendió un conteo que las habitaciones físicas no pueden honrar, una
  restauración que no recuperó nada.
• Habitación compartida — un operador puso deliberadamente dos estadías en
  una habitación, forzando un movimiento, porque su forma de trabajar lo pedía.

Axis Pro ejecuta el movimiento forzado en vez de rechazarlo, que es precisamente
por lo que la señal tiene que ver también la segunda forma. Si no, forzar un
movimiento sería una manera de volver invisible un overbooking real.

La señal solo aplica donde debería haberse asignado una habitación concreta —
un room type con filas de inventario. Las reservas de unidades únicas y de casa
completa no tienen espacio de habitación que pueda faltar, así que ahí una sin
asignar no significa nada.

Limpiarla es la misma acción en las dos formas: asignar una habitación libre.

Mover y desfragmentar

Mover una reserva a otra habitación física es la primitiva detrás de todo esto.

• Dentro del mismo room type (201 → 202) no se recotiza nada y el canal no ve
  ningún cambio — el conteo por tipo nunca se movió.
• Entre room types el origen se libera y el destino se llena, así que el
  cargo de alojamiento se recotiza por defecto — o se congela el monto actual a
  propósito, que es el caso operativo en que un huésped conserva lo que pagó pese
  a cambiar de habitación. El canal se actualiza para ambos tipos.
• Forzar siempre está disponible. Al operador nunca se le bloquea; la
  habitación que pidió se honra y en su lugar se registra el conflicto.

Desfragmentar un room type corre la misma primitiva en masa: reacomoda qué
estadías van en qué habitaciones para que dos estadías traslapadas no compartan
una, abriendo espacio contiguo. Nunca mueve a un huésped que está o estuvo
físicamente en la habitación — las estadías con check-in y check-out quedan
fijadas — y corre en seco por defecto, así que uno ve los movimientos propuestos
antes de que se escriba nada.

En la API

• Merchant: GET /api/merchant/availability para una unidad (devuelve las
  reservas en conflicto, que es lo que la hace útil),
  GET /api/merchant/availability/units para toda la propiedad.
• External: GET /availability. Ojo con los
  nombres de los parámetros — esta operación toma start y end, mientras que
  GET /rates toma from y to. No son
  intercambiables. remaining_capacity es 1 para una habitación física y el
  conteo restante para un room type.

Relacionado

• Unidades — las configuraciones, los bloqueos de venta y la ventana de disponibilidad.
• Reservas — qué pasa una vez reclamado el espacio.
• Distribución y Channel Manager — el otro lado del push.