Sintesi del progetto
Villa Luce è un sito multilingua con prenotazione diretta e amministrazione per l'ospitalità. Il progetto collega disponibilità, preventivo, pagamento con carta o bonifico, gestione degli incassi e calendari esterni. Comprende inoltre strumenti per mantenere contenuti e informazioni della struttura.
La parte più significativa dello sviluppo riguarda i confini tra questi passaggi. Una data selezionabile deve diventare un soggiorno coerente; un pagamento in attesa non può essere trattato come un incasso; una sessione Checkout abbandonata deve smettere di bloccare il calendario secondo condizioni verificabili. Il caso approfondisce queste relazioni attraverso codice e documentazione del progetto.
Il bisogno: autonomia senza perdere coerenza
L'esigenza inferita dai flussi è permettere all'ospite di prenotare direttamente e al proprietario di gestire il percorso ordinario senza modificare il codice. Prezzi, disponibilità, contenuti, prenotazioni e incassi devono appartenere a una struttura leggibile anche quando il pagamento avviene in più momenti.
Un sito di ospitalità non termina infatti alla pagina che presenta le camere. Dopo la scelta delle date possono esserci un pagamento incompleto, un bonifico parziale, una modifica amministrativa o un aggiornamento del calendario esterno. Il lavoro progettuale consiste nel mantenere il significato degli stati mentre la stessa prenotazione attraversa interfaccia pubblica, amministrazione e servizi collegati.
Sette lingue e percorsi localizzati
Il progetto contiene italiano, inglese, tedesco, francese, olandese, danese e spagnolo. Le pagine pubbliche usano percorsi localizzati e una base di traduzioni dell'interfaccia. Eventi e luoghi conservano contenuti multilingua separati dai testi statici.
L'obiettivo non è cambiare soltanto l'etichetta del menu. La lingua deve accompagnare il visitatore nelle pagine interne e nei passaggi della prenotazione. La documentazione comprende anche una gestione editoriale delle traduzioni che conserva i testi manuali già presenti. Il caso descrive la struttura e gli interventi documentati, senza equiparare la disponibilità linguistica alla qualità perfetta di ogni traduzione.
Check-in e check-out non occupano le stesse notti
Il calendario considera gli intervalli di occupazione includendo il check-in ed escludendo il check-out. Il giorno di partenza può quindi essere disponibile per un nuovo arrivo, salvo che un'altra prenotazione cominci proprio in quel giorno. Una selezione di soggiorno non può attraversare una notte occupata.
La regola cambia a seconda della fase della scelta. Quando l'ospite sta selezionando la partenza, il calendario valuta se l'intervallo dalla data di arrivo tocchi un'occupazione. Quando sceglie un nuovo arrivo, controlla invece se quel giorno possa iniziare il soggiorno. I confronti usano date di calendario, evitando di attribuire alla selezione effetti casuali del fuso del browser.
Il preventivo nasce dalle impostazioni del soggiorno
Il calcolo server comprende notti, camere e voci aggiuntive previste dalle impostazioni, come pulizia, biancheria, culla ed extra selezionati. Il preventivo controlla inoltre il minimo di notti e la disponibilità. Non consiste semplicemente nel moltiplicare un prezzo visualizzato per il numero di giorni scelti.
La creazione del Checkout ripete i controlli pertinenti. Tra il primo preventivo e la conferma può essere cambiato qualcosa: disponibilità, configurazione o selezione dell'ospite. Il server deve quindi usare lo stato richiesto dal percorso effettivo. Nel progetto sono presenti anche promozioni applicate alle sole notti comprese nel periodo previsto, separate dalla tariffa base.
Carta e bonifico seguono stati differenti
La prenotazione può seguire il pagamento con carta oppure il bonifico, se quest'ultimo è configurato e disponibile. Il codice distingue i due percorsi prima di creare lo stato iniziale: con carta viene preparata una prenotazione in attesa; il bonifico conserva una prenotazione attiva con l'importo ricevuto inizialmente pari a zero.
È una distinzione essenziale per leggere l'amministrazione. Una prenotazione confermata con bonifico non significa che il denaro sia già stato incassato. Occorrono dati separati per il soggiorno, il metodo, il totale concordato e i versamenti registrati. Le date devono restare occupate secondo lo stato della prenotazione mentre il registro degli incassi conserva la propria situazione.
Un Checkout abbandonato deve poter liberare le date
Il percorso carta introduce un blocco temporaneo delle disponibilità durante il Checkout. Se l'ospite annulla, il sistema verifica la sessione Stripe prima di liberare la prenotazione. Una sessione completata non viene trattata come un abbandono; una sessione ancora aperta viene fatta scadere prima del rilascio previsto.
Il motivo è concreto: liberare prima le date lascerebbe un collegamento di pagamento ancora utilizzabile per un soggiorno tornato disponibile. Il progetto comprende anche una riconciliazione delle sessioni scadute durante le letture pubbliche della disponibilità, utile quando il webhook è in ritardo. Il controllo lascia il pagamento completato al percorso di riconciliazione che gli compete.
Il webhook aggiorna lo stato, l'email ha un proprio esito
Le notifiche Stripe vengono verificate tramite firma. Il percorso di completamento aggiorna la prenotazione prevista e limita la modifica allo stato in attesa. Il codice distingue inoltre alcuni piani di pagamento, nei quali la registrazione del metodo e il momento dell'incasso non coincidono.
La comunicazione di conferma viene avviata dopo l'aggiornamento pertinente. Un errore nell'email viene gestito separatamente dal cambiamento della prenotazione: non deve essere interpretato automaticamente come annullamento di un pagamento o di uno stato già registrato. La documentazione segnala comunque che l'osservabilità storica delle email generiche al proprietario non era completa per tutte le tipologie.
Il bonifico come registro di versamenti
L'amministrazione registra i singoli bonifici come transazioni separate. Importo, momento e tipo di versamento possono così comporre il totale ricevuto, invece di sostituire ogni volta un unico campo senza storia. Sono presenti anche registrazioni distinte per gli aggiustamenti al saldo.
Il calcolo degli importi limita lo sconto successivo al saldo originale, in modo da non ridurre retroattivamente l'acconto concordato. Totale aggiornato, ricevuto e residuo vengono mantenuti separati e il residuo non diventa negativo. Questi dettagli sono utili quando l'ospite paga in più momenti o quando il proprietario concorda una correzione economica successiva alla prenotazione.
Scadenze e promemoria con condizioni esplicite
Il flusso bonifico prevede promemoria e gestione del mancato primo versamento. La procedura esaminata considera prenotazioni confermate con quel metodo, controlla le scadenze e applica la regola di annullamento dopo il periodo di tolleranza soltanto quando non risulta alcun pagamento registrato. Un versamento parziale cambia quindi il trattamento del caso.
La procedura distingue inoltre errori nel caricamento dei dati dagli esiti ordinari della scansione. Se una lettura necessaria fallisce, non presenta semplicemente il lavoro come completato. La logica permette di spiegare al proprietario perché una prenotazione resta attiva, richiede attenzione o può liberare le date, senza affidare tutto a un promemoria manuale.
Sincronizzare i calendari senza promettere istantaneità
Il progetto importa blocchi da un calendario esterno e produce un feed in uscita. I riferimenti degli eventi consentono di riconoscere le occupazioni e di gestire esclusioni puntuali. Dopo una lettura valida, l'importazione riconcilia l'insieme dei blocchi esterni futuri, comprese le occupazioni che non compaiono più.
Le due direzioni non hanno necessariamente la stessa frequenza. L'importazione è periodica; il sistema esterno decide quando leggere il feed prodotto dal sito. Per questo «sincronizzato» non significa «aggiornato nello stesso istante». Le verifiche documentate comprendono stabilità del calendario e gestione dei contenuti parziali, mentre l'allineamento tra due servizi richiede controlli periodici di creazione, modifica e cancellazione.
Un percorso completo e ciò che le fonti dimostrano
Un esempio illustrativo parte dalla scelta di arrivo e partenza. Il server produce il preventivo; l'ospite sceglie il metodo disponibile. Con carta, le date restano temporaneamente riservate durante il Checkout e il risultato viene riconciliato. Con bonifico, la prenotazione resta attiva mentre l'amministrazione registra acconto e saldo. Promemoria e calendari seguono i rispettivi stati.
Il contesto del progetto documenta rilasci e controlli storici delle funzioni descritte. Questa revisione ha consultato codice e note, senza creare prenotazioni, eseguire pagamenti o verificare oggi servizi esterni. Il risultato documentabile è un percorso di prenotazione e gestione con eccezioni esplicite, non una stima di commissioni risparmiate o occupazione aumentata. Per una struttura con esigenze analoghe puoi esplorare gli altri casi studio o richiedere una consulenza.
