Come emettere fatture e ricevute fiscali “full credit” e “half credit” per il tuo hotel

full credit half credit

Full credit, half credit, no credit: nel gergo alberghiero vi sarà sicuramente capitato di sentirne parlare, magari relativamente a voucher, cofanetti regalo o soggiorni business.
In questo articolo cercheremo di capire insieme il significato dietro a ciascuno di questi termini che abbiamo preso in prestito dall’inglese.

Che cosa significa “full credit”?

Full credit, che in italiano vuol dire pieno credito, è un tipo di prenotazione tipica delle aziende che, per i propri clienti o dipendenti, coprono per intero sia il costo del soggiorno che quello dei servizi extra.

In questo caso l’ospite che ha soggiornato non dovrà saldare nulla in fase di checkout, pertanto il documento fiscale emesso sarà contrassegnato come “corrispettivo non incassato”.

Nella quasi totalità dei casi, la tipologia di trattamento “full credit” è riservata ai clienti business. In casi più remoti, a prenotazioni provenienti da specifiche agenzie che vendono pacchetti turistici in modalità tutto incluso.

Che cos’è “half credit”?

Half credit, che in italiano vuol dire metà credito, è di gran lunga il metodo di prenotazione più diffuso in ambito business. Con questa modalità il cliente che soggiorna paga di tasca propria eventuali extra consumati, mentre il soggiorno sarà a carico dell’azienda o agenzia di viaggio.
Un esempio lampante è quello dei cofanetti o buoni regalo. Un ospite in possesso di un box ha già acquistato il pernottamento, ma tutti i servizi aggiuntivi dovranno essere pagati separatamente.

Un altro esempio pratico molto diffuso è quello in cui un ospite business, dopo una lunga giornata di lavoro, decide di concedersi un massaggio rilassante presso il vostro centro SPA. Con buona probabilità il suo datore di lavoro non accetterà di buon grado l’addebito del massaggio, quindi il nostro businessman pagherà di tasca propria il trattamento anti-stress.

Il caso più facile, “no credit”!

Ultimo caso è quello che prende il nome di no credit: questa non è altro che la classica prenotazione in cui il cliente si trova a pagare sia il soggiorno che eventuali extra.

Fatture full credit ed half credit, l’importanza di un software gestionale per la fatturazione del tuo hotel

Nei casi di half credit e full credit è necessario emettere una ricevuta fiscale da dare all’ospite che ha soggiornato e una fattura intestata all’agenzia o all’azienda.

Le fatture cumulative alle agenzie o aziende vengono emesse da parte della struttura ricettiva in genere su base mensile o trimestrale. Queste fatture cumulative (o riepilogativa) elencano tutti i soggiorni, extra e supplementi e referenziano le ricevute fiscali a con “corrispettivo non incassato” che sono state emesse nei confronti degli ospiti che hanno soggiornato in struttura.

Tenere traccia di tutti questi documenti non è cosa banale e per questa ragione l’utilizzo di un gestionale alberghiero è fondamentale per evitare errori di compilazione di questi documenti che possono diventare anche molto complessi.

Slope è un software gestionale per hotel che include nel PMS le funzionalità necessarie per gestire ogni aspetto della fatturazione del tuo hotel.
Fatture, ricevute, note di credito, fatturazioni business, tassa di soggiorno e tanto altro.
Tutte le funzionalità di Slope sono integrate ed interconnesse, crea in pochi click documenti fiscali per soggiorni, servizi extra e tasse, il tutto integrato con il vostro sistema di gestione prenotazioni e il vostro CRM (gestione banca dati clienti)!

Dietro le quinte del software Slope

software Slope

Sveliamo le strategie di sviluppo software, continuous integration e continuous delivery alla base di Slope, un SaaS Cloud con più di 200 rilasci all’anno.

In questo articolo vogliamo raccontare ai lettori più curiosi del blog alcuni dei retroscena tecnici alla base dell’architettura software, dal processo di sviluppo a quello di rilascio del software Slope. L’articolo è rivolto anche a tutti coloro che non fanno parte della limitata nicchia degli “addetti ai lavori”, cioè quelli che non operano direttamente nell’ambito dello sviluppo software, ma vogliono comunque capire quali sono gli accorgimenti e le strategie scelte dal team di ingegneriche operano quotidianamente allo sviluppo della piattaforma Slope.

Quando si è intenzionati ad acquistare un prodotto, è importante fare valutazioni approfondite con l’obiettivo di capire bene i pregi ed i difettidel bene che si sta acquistando.
L’acquisto di un software non fa eccezione, per questa ragione noi di Slope vogliamo essere trasparenti e raccontarvi quali sono le ragioni che permettono alla nostra piattaforma di essere stabile, veloce e soprattutto estremamente espandibile e flessibile. Partiamo dal presupposto che sviluppare e mantenere un software cloud SaaS non è cosa facile, soprattutto se si tratta di un software utilizzato quotidianamente da diverse migliaia (se non milioni) di utenti. Le problematiche quotidiane da affrontare e gestire sono molteplici e crescono in modo esponenziale all’aumentare del carico e del traffico, quindi all’aumentare degli utenti sulla piattaforma. Per questa ragione, e per tutte quelle che vi stiamo per descrivere, è importante che l’azienda abbia a disposizione un team di tecnici (sviluppatori e ingegneri informatici) che siano preparati e specializzati nello sviluppo e mantenimento, sia delle applicazioni web ma anche dell’infrastruttura che le mette a disposizione.

Volendo fare una carrellata di alcune delle principali problematiche che sono intrinseche nello sviluppo e manutenzione di un software cloud possiamo elencare:

  • Garantire uptime del servizio;
  • Avere cicli di sviluppo del codice efficienti;
  • Effettuare rilasci del codice rapidi e senza regressioni;
  • Gestione dell’infrastruttura (server);
  • Monitorare le performance e i log di sistema.

Continuous Integration (di seguito CI) e Continuous Delivery (di seguito CD) sono due paradigmi ben noti a chi si occupa di sviluppo software per il web, sono però poche le aziende che riescono a mettere in pratica queste metodologie su progetti medi e grandi. Cerchiamo di capire di cosa si tratta e perché è così difficile.
Continuous Integration (CI) è la modalità secondo la quale ogni sviluppatore del team lavora a funzionalità del sistema apportando cambiamenti il più limitati possibile, che possono essere integrati velocemente alla codebase comune a cui tutti gli altri membri del team attingono.

Con questa tecnica si cerca di evitare che sviluppatori lavorino a funzionalità molto grandi per un intervallo di tempo troppo lungo (ad esempio più di 4-5 giorni). In questo caso, infatti, diventerebbe difficile e rischioso re-integrare tale funzionalità nel sistema che nel frattempo è evoluto grazie al lavoro di altri sviluppatori.
Questo garantisce che ogni sviluppatore lavori a una versione del codice il più vicina possibile allo stato del codice di produzione. Inoltre, ogni qual volta che un cambiamento viene effettuato (aggiunta, rimozione o modifica di codice) si avvia un processo automatico di testing che garantisce che il software continui a funzionare correttamente anche nella sua nuova versione.

 

Prima di tutto, per fare in modo che la CI possa essere applicata con successo, è necessario che la piattaforma software (nel nostro caso il software Slope) sia corredata di una suite di test automatici in grado di verificare il corretto funzionamento di tutte le funzionalità del sistema con un buon livello di precisione.
Quindi, su di una codebase non sufficientemente corredata da test automatici non si potrà applicare la strategia di CI con successo; il motivo è che viene meno la possibilità di verificare automaticamente che il corretto funzionamento del sistema sia mantenuto ogni volta che si interviene al codice.

La piattaforma Slope è corredata da una rete di test automatici molto minuziosa e ben bilanciata tra i diversi tipi di test (unitari, integrazione e funzionali, anche conosciuti con il termine “end to end”).
Grazie all’attenzione e al rigore che i nostri sviluppatori hanno posto nella scrittura di test automatici sin dal primo giorno, possiamo operare in sicurezza sapendo che le modifiche apportate al codice (che possono essere la scrittura di nuove funzionalità, l’ottimizzazione di funzioni esistenti o risoluzione di bug) con alta probabilità non causeranno rotture alle funzionalità del sistema già esistenti ed in uso.

Quindi per capire bene in quale parte del processo di sviluppo software ha senso parlare di CI possiamo dire che questa subentra nel momento in cui lo sviluppatore ha ultimato la scrittura del proprio codice (che deve essere rigorosamente corredato da test automatici, sempre!) e invia il proprio codice ad un repository GIT ospitato su un server remoto.

Nel momento in cui lo sviluppatore effettua il “push” (invio del codice), viene chiamato in causa il server di Continuous Integration che avrà il compito di copiare il nuovo codice scritto e lo unirà al resto della piattaforma per poi eseguire in isolamento tutte le verifiche di conformità del codice.
Per darvi un’idea le verifiche consistono nell’ordine:

  • Verifica stilistica del codice;
  • Analisi statica del codice;
  • Verifica della conformità della definizione del modello dei dati;
  • Esecuzione dei test unitari;
  • Esecuzione dei test di integrazione;
  • Esecuzione dei test funzionali su tutte le applicazioni della piattaforma;

 

Se il codice soddisfa tutti i test (e per saperlo dobbiamo aspettare circa 20 minuti) allora questo passa in revisione ad uno degli ingegneri (ovviamente non lo stesso che ha scritto il codice). È suo compito verificare che le modifiche introdotte soddisfino tutti i criteri di sicurezza ed efficienza, e se così è allora il codice viene approvato per l’inclusione nella codebase principale (“master”), cioè quella candidata ad essere messa sui server di produzione al prossimo rilascio.

A questo punto abbiamo del codice che non solo è stato scritto seguendo una serie di requisiti tecnici molto stringenti ma soprattutto siamo ragionevolmente sicuri che questo non vada a rompere funzionalità già esistenti e in uso dagli utenti.

A questo punto entra in gioco il concetto di Continuous Delivery (CD), cioè il processo di creazione della “build” e della messa in produzione del codice. Tale processo è automatico (sebbene pilotato dagli ingegneri) e, con il solo click di un tasto, nel giro di circa 5 minuti la build del codice aggiornata viene rilasciata sul nostro ambiente di “staging”.
Staging è un ambiente intermedio (una sorta di “pre-produzione”) che replica la configurazione e l’architettura dell’infrastruttura di produzione, sulla quale il nostro team generalmente effettua smoke-testing con dati pseudo-reali per assicurarsi che non ci siano problemi macroscopici che la suite di test non è stata in grado di rilevare.

Una volta che tali verifiche sono completate (generalmente in tempi molto brevi), la stessa build viene automaticamente rilasciata anche in produzione, il tutto in una manciata di minuti e con il semplice click di un tasto.

Il fatto che questo processo sia quasi totalmente automatizzato ci permette di rilasciare continuamente (spesso più volte al giorno) senza dover sacrificare altre attività e soprattutto senza dover programmare interruzioni di servizio.

Grazie all’infrastruttura di CI e CD, Slope viene aggiornato con più di 200 rilasci all’anno.

Ciascun rilascio consiste nell’aggiunta di nuove funzionalità, ottimizzazioni, semplificazioni grafiche e interventi di miglioramento alla piattaforma senza causare nessun tipo di interruzione o rallentamento agli utenti che utilizzano il software.

Se siete curiosi di capire di più le strategie di sviluppo software Slope vi suggeriamo di leggere:

Per maggiori informazioni su Slope e sulle funzionalità del software non esitate a contattarci!