Skip to content

Markets

The Markets navigation group holds the configuration and reference data that defines where and how Volāre sells: each Market (a country storefront with its locales, currencies, margins, and customer-service contact details), the Airports and Points of Interest lookup data that power search and destination content, and the Volare Entity legal identity used on contracts.

  • Operations / configuration owners setting up markets and their commercial defaults.
  • Content and data teams maintaining airport and POI reference data.
  • Admins maintaining the legal entity used for supplier contracts.

Full CRUD for each storefront. A market defines:

  • Locales & currency: supported locales (the first is the default), a default currency code, and the list of supported currencies.
  • Commercial defaults: default offer margin and custom-quotation margin (both margin-on-sale).
  • Geography: the countries and departure airports the market sells from (with a primary departure airport), and localized tour URL path slugs per language.
  • Customer-service contact (shown in the Web footer and storefront): phone, WhatsApp link, email, and an opening-hours schedule (per weekday/Saturday/Sunday, with time-range slots). This is the single source for the footer’s customer-service block and the “agendar cita” contact form — the CMS Footer does not edit it.

Markets carry regional formatting (timezone, date/time formats), a status toggle, and sort order. See i18n URL Routing for how locales and path slugs shape public URLs.

Reference data for airports, used for departure/arrival lookups and search. Manages IATA/ICAO codes and an IATA city code (which groups airports in the same city, e.g. JFK + LGA = NYC), name/city/country, geographic coordinates and timezone, a type classification, and per-market associations (with a primary flag).

Airport search on the public site is PostgreSQL full-text-search backed with a relevance ranking (exact IATA, city, and name matches score highest). See Airport Search for the ranking and query details.

Reference data for cities and attractions used in destination content. Managed here: a Google Places lookup that auto-fills name/coordinates/country/type, a type/category, coordinates, an image, provider metadata, and per-locale translations (a translations relationship — one localized name per locale, locales sourced from the markets’ supported locales). Each POI can be linked to an Airport, which lets airport results show a localized city name.

See POI System for the data model and how POIs relate to airports.

An admin-only, single-record settings page (not a list resource) holding Volāre’s legal identity: legal name, trade name, tax ID (CIF/NIF), address, and contact details (email, reservations email, phone, website). There is no separate registration-number field — the tax ID is the only fiscal identifier.

This legal identity is injected into the supplier-contract PDFs that are sent for digital signature, so keeping it accurate matters for every contract. See Signaturit E-Signature for the contract-signing flow.

  • Market default locale is the first entry in the supported-locales list; tour path slugs are auto-filled from those locales on save.
  • Customer-service contact is configured per market here — not in the CMS Footer.
  • Airport IATA/ICAO codes are unique; airport search relies on the Postgres search vector.
  • Volare Entity is a single global record, admin-only to edit.
  • All models here are activity-logged.