Per una migliore interpretazione dei nostri documenti sul tema della Travel Automation di seguito una classificazione e spiegazione di alcuni dei termini da noi utilizzati.

Figure Professionali della filiera del turismo

Riteniamo che i soggetti coinvolti lungo tutta la filiera turistica possano essere raggruppati nelle seguenti categorie/funzioni:

• Viaggiatore (traveler) il soggetto/funzione  che usufruisce dei servizi turistici
• Proprietario/Produttore/Gestore (owner) il soggetto/funzione che crea/gestisce  un servizio turistico singolo o che assembla un insieme di servizi turistici (pacchetto) da offrire come servizio turistico complessivo
• Aggregatore di Prodotto (wholesaler) il soggetto/funzione  che costruisce un inventory di servizi turistici realizzati da una pluralità di produttori.
• Aggreratore di Domanda il soggetto/funzione che agevola l'accesso dei viaggiatori ai prodotti turistici provenienti da una pluralità di produttori (in questa categoria ricadono una pluralità di modalità che vanno dall'agevolare la sola ricerca in modo generalistico come ad esempio Google alla ricerca specializzata come nel caso dei comparatori tipo Trivago fino agli IDS (Internet Distribution System) che concretizzano la prenotazione)

Nel settore turistico esistono dei soggetti che svolgono più di una di queste funzioni come ad esempio le DMC (Destination Management Corporation) che per una specifica località turistica fungono da AgP ed AgD ed in alcuni casi sono anche i produttori  degli aggregati (pacchetti)

Interfacce Applicative (API)

le interfacce permettono ad una applicazione di inter-operare con altre applicazioni esterne (interazione M2M Machine to Machine) ed i loro diversi aspetti sono descritti mediante i termini:

• Sincrono/Asincrono
  • Sincrono modalità di comunicazione tra due entità dove chi invia resta in attesa della risposta del ricevente
  • Asicrono modalità di comunicazione tra due entità dove chi invia non resta in attesa della risposta del ricevente
• Locale/Remoto (Interno/Esterno)
  • Locale (interno) il lato di una comunicazione tra due entità prossimo al soggetto/sistema che si sta descrivendo
  • Remoto (estreno) il lato di una comunicazione tra due entità opposto al soggetto/sistema che si sta descrivendo 
• Client/Server
  • Client  chi origina delle richieste  
  • Server chi resta in attesa di richieste
• Consumer/Producer
  • Consumer
  • Producer

Noto il significato dei termini su riportati è possibile costruire diverse tipologie di interfacce che si differenziano per:

• protocollo del trasporto (ad esempio webservices HTTP SOAP in modalità Document)
• processi (client/server) previsti per ciascuno  dei lati dell'interfaccia (local/remoto) vi sono interfacce che prevedono un solo processo per lato (che può essere o client o server) ed interfacce che prevedono che entrambi i lati si dotino sia del processo client che di quello server. 
• flusso informativo (sequenza di scambio dei messaggi)
  
  • direzione del flusso informativo
    
    • Distribution quando le informazioni fluiscono dal local side verso il remote side e cioè quando il CRSEngine fornisce all'esterno informazioni (esempio disponibilita, prezzi, Dati Statici)
    • Procurement quando le informazioni fluiscono dal remote side  verso il local side e cioè quando il CRSEngine  recupera dall'esterno  informazioni (esempio quando recupera dal PMS le informazioni di disponibilità prezzi)
  • emettitore delle richieste di flusso (soggetto che emette il messaggio di RQ)
    
    • Consumer Pull  (pull mode) il consumer invia un messaggio di RQ al producer per farsi dare le informazioni che desidera
    • Producer Push (push mode) il producer invia un messaggio di RQ al consumer per comunicargli un cambio delle informazioni (nella terminologia OTA si tratta di messaggi che contengono nella loro nome il termine "Notify").
  • tempistica del flusso(correlazioni temporali dei messaggi RQ/RS)
    
    • Sincrono quando il richiedente resta in attesa della risposta e quindi le informazioni sono fornite nel momento in cui necessitano
    • Asincrono quando il richiedente NON resta in attesa della risposta

Le applicazioni agli estremi dell'interfaccia(channel) possono poi essere caratterizzate dalla presenza del caching e cioè della possibilità che le informazioni ricevute dal "producer" vengono memorizzate nel "consumer" ed il "consumer" successivamente in caso di necessità possa utilizzare tali informazioni memorizzate invece di riemettere, tramite il channel, una richiesta al producer, tale comportamento nasce dalla necessità di rendere le tempistiche  del "consumer" indipendenti dai tempi di risposta del "producer" tuttavia  è la fonte di problemi come l'overbooking.

In particolare abbiamo le seguenti interfacce (channel) a seconda delle varie combinazioni:

• One Way Interface dove ciascuna delle due applicazione è sempre o  "producer" o "consumer", l'emettitore delle richieste è sempre il consumer  ed il consumer non replica su di se le informazioni ricevute dal producer.
• Two Way Interface quando entrambe le applicazioni svolgono sia il ruolo di "producer" che quello di "consumer" e quindi per alcune informazioni sono "producer" e per altre sono "consumer" (ad esempio su canali di tipo "distribution" il CRSEengine è il "producer" delle informazioni di disponibilità e prezzo mentre è "consumer"  delle informazioni di prenotazione realizzate dall'applicazione esterna) ed  il "consumer" replica su di se le informazioni ricevute dal "producer" (ad esempio nel caso di una interfaccia distribution 'applicazione esterna replica le informazioni di disponibilità e prezzi  ricevute dal  CRSEngine), l'emettitore delle richieste è sempre il producer.
• Two Way Interface (Emulated Push) è una interfaccia che realizza i medesimi flussi di una interfaccia "Two Way Interface" solo che l'emettitore delle richieste è il consumer  che interroga "ciclicamente" il "producer" per chiedere se vi sono variazioni. Potenzialmente tale comportamento potrebbe essere realizzato su entrambi i lati del canale ma non condurrebbe ad alcun vantaggio, mentre se fatto solo su di un solo lato del canale permette di avere una "Two Way Interface" implementando su ciascun lato o solo il client o solo il server.

Allotmet, Release Period, Freesale

Con il termine "Allotment" si intende una assegnazione di disponibilità "esclusiva"  (di solito collegata ad un contratto) per la rivendita attuata  da un grossista (wholesaler) o da un "Tour Operartor" a cui viene anche associato un "Release Period" (vedi anche wikipedia - Allotment) che consente di ritornare nella disponibilità  del proprietario le camere invendute ad un numero di giorni pari  al "Release Period" dalla data di "checkin".

Nel caso il "Release Period" sia impostato a 0 ("zero") si intende che il contratto sia di tipo "Fullfill" e cioè "vuoto per pieno", mentre se il "Release Period" è impostato ad 1 ("uno") significa che il propritario delle camere è libero di allocare le camere invendute il giorno del "checkin" e così via.

Con il termine "Freesale" si intende una assegnazione di disponibilità "non esclusiva" in pratica un certo numero di camere viene comunicato ai "wholesaler" e mano a mano che essi procedono con le prenotazioni tale numero diminuisce in modo comune a tutti i soggetti assegnatari del "Freesale"

Guest Profile

I partecipanti vengono classificati sulla base della loro età in:

• Adulti (Adult)
• Bambini (Child)
• Neonati (Infant)

Ogni singola unità residenziale (Hotel, B&B etc.) può definire se gestire la differenziazione Adulto Bambino e a quale età essa intervenga mentre è fissa la fascia di determinazione dei neonati (da 0 a 2 anni). 

Adulti e Bambini possono utilizzare la medesima tipologia di letto  mentre i Neonati  necessitano delle Culle (Crib) pertanto la gestione e quotazione dei partecipanti neonati viene gestita separatamente dagli altri partecipanti mediante un importo fisso giornaliero per la culla.

Ogni camera viene caratterizzata mediante il numero  di ospiti che può ospitare per mezzo di:

• "MaxAB" (Adulti+Bambini) determina il  numero massimo di posti letto (escluse le culle)
• "MinAB" (Adulti+Bambini) serve quando il prezzo base è inteso "per partecipante" (Adulto/Bambino) per determinare il valore minimo di vendita della stanza
• "StdAB" (Adulti+Bambini) serve quando il prezzo base è inteso per "camera" ma si vuole realizzare indipendente dal numero di partecipanti solo quando essi sono minori od uguali a tale valore e per quelli che superano tale numero si vuole poter applicare un eventuale costo extra.
• "MaxCrib" (numero massimo di neonati)

Quando è presente una "Occupancy Business Rule" anche se il "prezzo base giornaliero" (PBG) è inteso "per camera" viene determinato un "prezzo base giornaliero" per partecipante ("prezzo base giornaliero"/StdAB) ed i partecipanti (Adulti+Bambini) vengono ripartiti nelle sotto classi "Normal" ed "Extra" in funzione di dove cada "StdAB" dopo che adulti e bambini siano stati ordinati nel modo sotto riportato.

0----------<Adulti> -------- <Bambini> -----------"MaxAB"

di modo che si possa parlare di Adulti o Bambini che necessitano di "ExtraBed" piuttosto che di Adulti o  Bambini collocati nei "NormalBed".

La "Occupancy Business Rule" consente di definire come variare il "prezzo base giornaliero" in funzione dei soli Adulti e Bambini, nel caso di "prezzo base giornaliero" inteso "per partecipante" ed in funzione anche di "Adulti Extra" e "Bambini Extra" nel caso di "prezzo base giornaliero" inteso "per camera" e numero partecipanti maggiore di quello standard StdAB

le rogole di calcolo impostate nelle "Occupancy Business Rule" possono:

1. determinare un prezzo sommando o sottarendo un valore dal "prezzo base giornaliero"
2. determinare un prezzo sommando o sottarendo dal "prezzo base giornaliero" un valore determinato come percentuale del  "prezzo base giornaliero"
3. impostare un valore (indipendente dal "prezzo base giornaliero")

Il "prezzo giornaliero della Crib" viene indicato nel tab "crib" della "Occupancy Business Rule" e permette il solo caso "c" un valore indipendente dal "prezzo base giornaliero".

Extra (ancillaries)

Gli extra si dividono nelle seguenti grandi categorie:

• Offline beni e servizi che non necessitano di un controllo "on line" disponibilità e che quindi non necessitino della interoperabilità del sistema CRSEngine con una applicazione esterna che gestisca la disponibilità di tali beni.
• Online beni e servizi che necessitano di un controllo "on line" per essere venduti contestualmente alla vendita di camera.

Il CRSEngine permette la gestione diretta degli Extra del tipo "OffLine" consentendo di definire le seguenti caratteristiche:

• al viaggiatore durante la prenotazione di
  
  • definire il godimento giornaliero desiderato
• al gestore durante la configurazione dell'Extra di
  
  • definire vincoli sulla erogazione giornaliera (giorno arrivo, giorno partenza, giorni di soggiorno)
  • definire se "pacchetto"
  • definire l'inclusione/esclusione del prezzo della camera
    • nel caso di inclusione ("prezzo esposto" o "prezzo non esposto")
  • definire se obbligatorio/facoltativo
  • definire se il pagamento è ("alla prenotazione" "in Hotel")
  • definire che tipo di ricorrenza abbia (per persona, per notte, per soggiorno, per uso, per persona-notte)
  • differenziare il prezzo  Adulto/Bambino
  • di definire il periodo durante il quale è erogabile ed in quali giorni della settimana.

Ovviamente non tutte le combinazioni sono ragionevoli come ad esempio:

• se l'extra è  "Incluso" non può essere "facoltativo" ne può essere pagabile in hotel.
• se l'extra è a "pacchetto" allora è automaticamente "incluso" con l'aggiunta che  il prezzo della camera (a cura di chi gestisce la UI) non va mostrato come voce separata ma solo come "totale" determinabile ovviamente solo a valle della scelta degli extra pacchettizzati, che a loro volta non devono esporre singolarmente il prezzo. 

Nel caso di Extra del tipo "Online" sono presenti le caratteristiche del caso precedente a cui va aggiunta la necessità di un controllo "on line" della disponibilità dell'Extra, quindi il CRSEngine deve cooperare con il sistema di gestione disponibilità  della risorsa "Extra", nel caso dell' Extra di tipo volo il Crsengine fa uso del "Travel XML Proxy".