[RR062]

Premesso che la piattaforma funziona e la gestione delle disponibilità è chiara. Per chi gestisce appartamenti c'è sempre l'adattamento room=appartamento e concettualmente la disponibilità dovrebbe essere al massimo 1.
Per errore umano o in casi in cui c'è necessità di riaprire subito la camera anche se dal canale non è arrivata ancora la cancellazione, si rischiano overbooking non desiderati (es. quando poi arriva la cancellazione che re-incrementa di 1 la disponibilità).
A noi è capitato qualche volta :-/
Proposta: una opzione nella configurazione della room di un limite massimo per la disponibilità, che ci dia la possibilità di impostarla a 1 oppure 2 (se uno vuole gestire overbooking).
Una impostazione che di default è senza alcun limite, come oggi, ma se viene attivata può aiutare a limitare errori umani.
Non so se anche altri sentono questa necessità.
Nella creazione della camera madre dovrebbe essere facile aggiungere un campo Disponibilità Massima, forse più complesso aggiungere questa variabile nella tabla e nei processi vari di aggiornamento automatici.

Grazie

[white]

Ciao buongiorno!!

Se non sbaglio il concetto potrebbe valere anceh per un hotel, no? Voglio dire, se "fisicamente" ho solo 5 doppie, perché poterne vendere 6? E se questo é vero allora, perché il channel manager mi lascia farlo?

Io credo (ma é personale eh!) che il channel deve poter avere questa flessibilitá. Sia per gli hotel che per gli appartamenti. Poi l'allocazione può anche giocare a mio favore ma é dal PMS che si controlla lo "stock" a disposizione.

Ti inviterei a considerare l'opzione di usare un PMS. Per esempio su Zak, non si "discute" la disponibilitá massima :) Quelle sono le unitá, quelle vendo online.

Credo possa fare al caso tuo. Vuoi magari provare?

[RR062]

In realtà la tabla è già uno strumento molto utile sia come visione d'insieme che per intervenire a livello operativo, è da li che gestiamo prezzi, disponibilità etc.
Zak l'ho provato a suo tempo ma lo riguardo volentieri.
Altrimenti se non è una necessità diffusa, noi potremmo aggiungere una sicurezza via api e casomai forzare con update_avail(), ma c'è sempre il timore delle Anti Flood Policies :-)

[brown]

In realtà la tabla è già uno strumento molto utile sia come visione d'insieme che per intervenire a livello operativo, è da li che gestiamo prezzi, disponibilità etc.
Zak l'ho provato a suo tempo ma lo riguardo volentieri.
Altrimenti se non è una necessità diffusa, noi potremmo aggiungere una sicurezza via api e casomai forzare con update_avail(), ma c'è sempre il timore delle Anti Flood Policies :-)

Ciao a tutti,

io non sono certo di aver compreso a fondo l'esigenza. Anzi, probabilmente non ho capito.
Non sono molto daccordo con un'esubero di controlli.

Nel vostro esempio RR062, assumete: "Per errore umano o in casi in cui c'è necessità
di riaprire subito la camera anche se dal canale non è arrivata ancora la cancellazione".

1) L'errore umano è trasversale. Nel senso che per errore, un nostro cliente, potrebbe
configurare un'errato limite disponibilità.
In quali casi "c'è necessità di riaprire subito la camera" quando questa è già prenotata?
2) Se volontariamente riaprite la disponibilità di un'appartamento prenotato, vi esponete
volontariamente e consapevolmente al rischio di overbooking (se siete voi a volerlo fare,
il sistema non dovrebbe fermarvi).
3) Addirittura mettere questo limite variabile sul tabla... moltiplichiamo la possibilità di
errori umani. Il tabla diverrebbe più complesso, la probabilità di errore si estenderebbe
anche agli altri campi (prezzi, restrizioni, disponiblità).
4) Non capisco il senso di avere un limite disponibilità variabile. Potrei capirlo fisso sul
tipo camera, ma variabile nel tempo non lo comprendo. Creerebbe una complessità
(limite disponibilità-disponibilità-prenotazioni), inestricabile.

(ps: le politiche Anti Flood non dovrebbero essere un problema. Controllando
a monte il flusso e l'entità degli aggiornamenti si può usare tranquillamente
l'api update_avail()).

Se ho capito la richiesta, mi trovo in disaccordo.
... ma probabilmente non ho capito bene.

Michele

[RR062]

[quote='brown' pid='7660' dateline='1512663391']

Ciao brown,
"Non sono molto daccordo con un'esubero di controlli."
Concordo con te, è sempre cosa buona e giusta, e anche con white che dice che la disponibilità dovrebbe venire dal PMS.

Resta il fatto che dal momento che ad un "appartamento" corrisponde una "camera madre", per definizione o è libero o è occupato: un booleano True/False non un valore INT di un numero 'n' di disponibilità.
Da qui nasce la possibilità dell'errore umano nella tabla.

Per evitare di mettere in discussione l'architettura del sistema ho proposto una opzione di poter limitare (in modo fisso per la camera madre) la disponibilità massima, ad es. se setto a 1 di fatto ricondurrei le opzioni a 0 e 1 (equivalente di occupato e libero) e nella tabla gli input type della disponibilità potrebbero avere il 'max' corrispondente, ma forse il tutto complicherebbe troppo.

In sintesi un limite fisso sulla camera madre aiuterebbe gli appartamenti, ma forse è meglio agire a monte PMS/Api.

[brown]

[quote='brown' pid='7660' dateline='1512663391']

Ciao brown,
"Non sono molto daccordo con un'esubero di controlli."
Concordo con te, è sempre cosa buona e giusta, e anche con white che dice che la disponibilità dovrebbe venire dal PMS.

Resta il fatto che dal momento che ad un "appartamento" corrisponde una "camera madre", per definizione o è libero o è occupato: un booleano True/False non un valore INT di un numero 'n' di disponibilità.
Da qui nasce la possibilità dell'errore umano nella tabla.

Per evitare di mettere in discussione l'architettura del sistema ho proposto una opzione di poter limitare (in modo fisso per la camera madre) la disponibilità massima, ad es. se setto a 1 di fatto ricondurrei le opzioni a 0 e 1 (equivalente di occupato e libero) e nella tabla gli input type della disponibilità potrebbero avere il 'max' corrispondente, ma forse il tutto complicherebbe troppo.

In sintesi un limite fisso sulla camera madre aiuterebbe gli appartamenti, ma forse è meglio agire a monte PMS/Api.

Ciao e grazie per la partecipazione.

Se ho capito bene continuo ad essere in disaccordo.

Un'intero, se può essere solo 0 o 1, è come se fosse un booleano.
Se un'appartamento è una camera virtuale di una camera madre, allora rappresenta
un modo alternativo di offrire la madre e le loro disponibilità sono le stesse.
Se nella camera madre avete messo disponibilità di default=1 e non la modificate
con il Tabla, potete stare certi che la disponibilità (compresa quella delle virtuali)
non salirà mai sopra 1. (Sarà sempre o 0 o 1, come un booleano).

Un'eventuale controllo "massima disponibilità=1" eviterebbe di inviare disponibilità>1,
però non risolverebbe nulla quando la disponibilità reale è 0 ed invece viene settato
erroneamente 1.

Se volete chiudere la vendita di una virtuale lasciando la madre aperta, potete usare
la restrizione "Chiusura" (rettangolino nero nel Tabla) che opera nella specifica
camera virtuale.

In genere, usando il channel manager ed inserendo le prenotazioni che ricevete
direttamente con youbook(o ZaK), non dovreste mai aver bisogno di sistemare
manualmente la disponibilità sul Tabla. Il channel manager è pensato apposta
perchè gestisca la disponibilità automaticamente.

In quali casi avete bisogno di alzare la disponibilità manualmente sul Tabla?
Può riportare un'esempio al fine di aiutarmi a capire meglio?

Michele

[RR062]

Grazie a te
perché dici "... un'appartamento è una camera virtuale di una camera madre..." ?
c'è chi lo fa? funzionerebbe ?

Come avevo esplicitato nell'email (... ad un "appartamento" corrisponde una "camera madre" ...)
per noi una camera madre corrisponde ad un solo appartamento, le figlie le usiamo solo per differenziare il pricing in funzione dei pax: es. madre parte con 2pax, poi figlia per 3pax, poi altra figlia per i 4pax e così via fino alla capienza massima.

La tabla la usiamo principalmente per la gestione di dettaglio dei prezzi: una volta impostati con piani e sytar, li affiniamo sulla tabla (che da una visone di insieme) in funzione di come vanno le vendite.

Angelo

[brown]

Grazie a te
perché dici "... un'appartamento è una camera virtuale di una camera madre..." ?
c'è chi lo fa? funzionerebbe ?

Come avevo esplicitato nell'email (... ad un "appartamento" corrisponde una "camera madre" ...)
per noi una camera madre corrisponde ad un solo appartamento, le figlie le usiamo solo per differenziare il pricing in funzione dei pax: es. madre parte con 2pax, poi figlia per 3pax, poi altra figlia per i 4pax e così via fino alla capienza massima.

La tabla la usiamo principalmente per la gestione di dettaglio dei prezzi: una volta impostati con piani e sytar, li affiniamo sulla tabla (che da una visone di insieme) in funzione di come vanno le vendite.

Angelo

Grazie Angelo per le utili delucidazioni.
Ora è molto più chiaro cosa intendevi per "ad un appartamento corrisponde una camera madre".

Ok Angelo, questo significa che quando avete creato l'appartamento la prima volta
avete messo disponibilità 1. Automaticamente questa disponibilità viene portata a 0
nei periodi di soggiorno di ogni prenotazione che entra.
Non trovo ancora alcun motivo per cui dovreste alzare manualmente la disponibilità
dal Tabla o con il Sytar. Se non toccate la disponibilità e lasciate che venga gestita
in automatico, sarà sempre corretta.
L'importante è che le prenotazioni che entrano sulla camera al difuori del circuito WuBook
(booking engine e channel manager), le inseriate manualmente in WuBook (con Youbook)
o in ZaK (se lo usate). In questo modo la disponibilità dell'appartamento sarà sempre
quella reale.
Continuo a non capire il panorama: In quali casi hai necessità di mettere le mani
direttamente nella disponbilità? Vorresti riportarmi un'esempio?

Michele