Propiedades

Una propiedad es un lugar físico: un hotel, un hostal, un edificio de
apartamentos. Pertenece a una cuenta y es
dueña de unidades,
planes tarifarios, reservas, turnos de caja y
reportes.

Casi todo el sistema está acotado a una propiedad. Los huéspedes y las tasas de
cambio son las excepciones notables — esos pertenecen a la cuenta.

Tres campos que llegan a todas partes

timezone — el reloj de la propiedad

Toda fecha que cargue dinero o significado operativo se resuelve con el reloj de
la propia propiedad, nunca con el del servidor. La ventana de un reporte, el día
al que se atribuye un pago, una hora de check-in, si la última noche de una
estadía cae dentro de un horizonte de reserva.

Esto no es una preferencia de visualización. Un reporte que doblara los días en
UTC movería ingresos de un día a otro para cualquier propiedad que no esté
sentada en UTC, y en silencio.

default_currency — una semilla, no una restricción

Los planes tarifarios nuevos la heredan cuando quien los crea no especifica una.
Pero un plan tarifario puede usar otra moneda, y nada obliga a que coincidan
una propiedad y sus planes. Es también la moneda con la que abre un turno de caja
y con la que un reporte abre seleccionado. Ver Monedas.

Solo se pueden seleccionar monedas que Axis Pro pueda almacenar — las columnas de
dinero guardan dos decimales, así que las monedas de tres dígitos menores quedan
excluidas de la selección hasta que esas columnas se ensanchen.

booking_code_prefix — se bloquea después del primer código

Los códigos de reserva son {prefijo}-{000001}: seis dígitos, rellenados con
ceros, contados por propiedad desde 1. El prefijo son de 2 a 5 caracteres de
A-Z0-9, lo fija un admin de plataforma, y es único entre las propiedades de la
cuenta.

Dos consecuencias que sorprenden:

• Deliberadamente no es único a nivel global. Dos cuentas distintas pueden
  usar ambas SUR. Por eso un código de reserva no puede identificar una reserva
  por sí solo — y por eso el enlace de
  check-in digital es un token opaco y no
  un código.
• Se bloquea con el primer uso. Una vez que la propiedad emitió algún código
  de reserva — incluido uno de una reserva cancelada, porque ese código ya se
  entregó — cambiar el prefijo se rechaza. Una propiedad retirada se queda con su
  prefijo para siempre; reciclarlo reiniciaría un contador en 1 contra códigos
  que ya existen.

Quién configura qué

La división entre el admin de plataforma y el hotel es deliberada, no un
accidente de permisos.

Los primeros cuatro de la columna del admin rompen algo río abajo si se cambian a
la ligera: las URLs públicas, la numeración de códigos de reserva, en qué día
aterriza el dinero, y cada folio que la propiedad ya tiene.

Mandar un intento de cambio a un campo solo-de-admin por el endpoint merchant
es un 422, no un no-op silencioso — la lectura devuelve esos campos con
apariencia corriente, así que descartar el cambio calladamente lo perdería sin
nada en pantalla que lo dijera. Devolver el mismo valor ya guardado de un campo
está bien y responde 200.

Las features son por propiedad

Los módulos se habilitan por propiedad. El channel manager se cobra por
propiedad, así que la restricción coincide con cómo se vende; el check-in digital
también es una feature de pago por propiedad. Una feature deshabilitada no
aparece — no está en gris, está ausente.

En la API

• Merchant: GET /api/merchant/properties (un arreglo pelado, no envuelto en
  data — respalda el selector de propiedad),
  GET|PUT /api/merchant/properties/{property}. Ninguno lleva X-Property: la
  propiedad es el segmento de la ruta.
• External: GET /properties lista las
  propiedades que cubre una key. Conviene revisar
  api_rate_plans_configured — cuando está en false, unidades, disponibilidad
  y tarifas vuelven vacías correctamente, y solo el hotel puede cambiarlo.

Relacionado

• Unidades — lo que vende una propiedad.
• Monedas — cómo se usa y cómo no se usa default_currency.
• Finanzas y movimientos — el dinero siempre se atribuye a una propiedad.