Planes tarifarios

Un plan tarifario es un producto con precio enganchado a una o más
unidades. Las unidades no tienen precio propio; el plan
tarifario es donde empieza el precio.

Un plan pertenece a una propiedad, y las unidades que referencia tienen que ser
de esa misma propiedad. Una propiedad puede tener muchos planes, y exactamente
uno puede estar marcado como el predeterminado.

Cómo se vende un plan

Por unidad — un precio por noche, sea cual sea la ocupación.

Por persona — el precio se mueve con la cantidad de huéspedes, en uno de dos
modos:

• Manual — un precio explícito para cada nivel de ocupación.
• Derivado — un precio base más un modificador en porcentaje o monto por
  nivel.

Los canales de venta deciden quién puede ver un plan

Todo plan lleva un sales_channel: direct, ota o api. Esto no es una
etiqueta — es una regla de acceso, y es la causa más común, con diferencia, de
"su API no muestra mis habitaciones".

• Un plan direct pone precio a las pantallas propias del hotel y a su motor
  de reservas.
• Un plan ota es lo que va a los canales.
• Un plan api es lo único que la External API pública va a
  cotizar o vender.

Una unidad es invisible para la External API hasta que tenga al menos un plan
activo del canal api, aunque esté publicada, sea reservable y se venda bien
en todos lados. Esa decisión le corresponde al hotel — una integración vende lo
que el hotel eligió exponerle a las integraciones — pero es lo primero que hay
que revisar cuando faltan habitaciones que uno esperaba.

El sales_channel es un hecho sobre la venta. Se registra cuando se hace
la reserva y describe de dónde vino la venta; no es una restricción que haya
que volver a hacer valer cuando alguien edite esa reserva después.

Qué lleva un plan además del precio

Las restricciones de estadía se leen noche por noche

Una estadía no se mide contra "el plan" sino contra sus propias fechas. Cada
noche tiene cuatro restricciones:

Los cierres no le quitan disponibilidad a la noche. Una estadía del 22 al 26 pasa
tranquila por un 24 cerrado a la llegada; lo único que no se puede es llegar el
24. Por eso un calendario de reservas no debe mostrar el 24 como ocupado, sino
como un día que no se ofrece como entrada.

Cada restricción se resuelve por separado, y gana el primer valor que exista:

1. el precio diario de esa fecha, si alguien la escribió;
2. la temporada que gana esa noche;
3. el plan tarifario (para los cierres: abierto).

Un precio diario que solo pone "cerrado a la llegada" no toca el precio ni la
estadía mínima: esas siguen saliendo de la temporada o del plan. Y un cierre
puesto en false en una fecha la abre aunque la temporada la cierre.

Al huésped se le rechaza; al equipo del hotel se le avisa

• Sitio web, widget y External API: una estadía que rompe cualquiera de las
  cuatro se rechaza con un 422 que dice cuál y por qué (ver
  Errores).
• El equipo del hotel (reservas desde Aloha Hospitality, cotizaciones, grupos, Kai)
  nunca es bloqueado por estas restricciones. Recibe un aviso y decide. Un
  recepcionista que acepta una noche suelta a pedido de un cliente conocido está
  haciendo su trabajo, no rompiendo una regla.

Cambiar una restricción no toca las reservas que ya existen.

Las variaciones son planes, aplanados

Un "No reembolsable, 10% menos" se modela internamente como una variación de un
plan padre. Quien consume nunca ve esa jerarquía. Una variación llega como un
plan tarifario corriente con su propio id, su propio precio final y sus propias
restricciones de estadía. No hay un padre que buscar ni un ajuste que aplicar —
se reserva por su propio id.

Una variación cuyo padre se apagó no se lista en absoluto, así que todo plan que
uno puede ver es un plan que efectivamente puede reservar.

Una variación no tiene columnas de precio propias: se cotiza desde la grilla de
su padre y después se le aplica su propio ajuste. Por eso puede listarse y
venderse sin exponer nunca al padre.

A qué unidades se puede enganchar un plan

A cualquiera, incluidas las incómodas:

• Unidades únicas — el caso corriente.
• Padres de casa completa — la tarifa de vender el lugar entero como una sola
  unidad.
• Hijas de casa completa — cada hija puede llevar su propio plan,
  independientemente del padre.
• Room types — el plan se engancha al tipo. Todas las habitaciones físicas de
  adentro comparten ese plan; no se puede ponerle a la 201 un precio distinto que
  a la 202 enganchándole otro plan.

En la API

• Merchant: GET /api/merchant/rate-plans, más /rate-plans/stats para los
  contadores que muestra la lista de planes.
• External: los planes tarifarios salen por
  GET /rates — una entrada por unidad y plan, con la
  grilla por noche, min_stay, max_stay, closed_to_arrival y
  closed_to_departure ya resueltos para cada noche. Solo aparecen los planes del
  canal api, y las variaciones llegan aplanadas como se describió arriba.
• Merchant, en bloque: POST /api/merchant/pricing/bulk/preview y
  POST /api/merchant/pricing/bulk cambian precio y restricciones de muchas
  unidades, planes y fechas de una vez. Ver
  Reglas de precio.

Relacionado

• Reglas de precio — las capas que se aplican encima del precio base de un plan.
• Unidades — a qué se engancha un plan.
• Impuestos — si el precio configurado ya trae impuesto adentro.