Permessi 104, congedi parentali e malattia: il problema della molteplicità

Perché la parola assenza non basta

Immaginiamo quattro richieste inserite nella stessa app: due ore di permesso legge 104, tre giorni di congedo parentale, un periodo di malattia accompagnato da certificazione, quattro ore di permesso studio. A prima vista sono quattro intervalli nel calendario. In realtà seguono percorsi differenti: il primo può dipendere da un’autorizzazione e da un limite mensile, il secondo dal rapporto con il minore e dalle regole del congedo, il terzo da certificazione e comunicazioni specifiche, il quarto da requisiti e documenti previsti dal contratto.

Una UI che mostra soltanto “dal 10 al 12 settembre” perde il significato amministrativo dell’evento. Il campo type non è un dettaglio grafico: decide quali campi mostrare, quali controlli eseguire e quale flusso usare.

Le cinque dimensioni da modellare

Prima di disegnare i componenti è utile classificare ogni istituto secondo cinque dimensioni: la fonte, cioè se la regola deriva da legge, CCNL o policy interna; l’unità, cioè se si conta in ore, giorni o intervalli; il trattamento, cioè come vengono gestite retribuzione e contribuzione; i documenti, cioè se serve un certificato o un allegato; e il workflow, cioè chi deve verificare, approvare o registrare l’evento. A queste si possono aggiungere autorizzazione, periodo di maturazione, plafond, limiti giornalieri e incompatibilità.

Una configurazione esemplificativa può assomigliare a questa:

const absenceConfig = {
  law_104: {
    unit: 'hour_or_day',
    requiresAuthorization: true,
    requiresDocument: false,
    approvalRole: 'hr',
  },
  parental_leave: {
    unit: 'day_or_hour',
    requiresChildData: true,
    approvalRole: 'hr',
  },
  sickness: {
    unit: 'period',
    requiresCertificate: true,
    approvalRole: 'hr',
  },
};

Va detto con chiarezza: questa configurazione è puramente esemplificativa, e non va copiata senza un’analisi del dominio e delle fonti applicabili al caso concreto.

Permessi legge 104

I permessi collegati all’articolo 33 della legge 5 febbraio 1992, n. 104, richiedono di verificare presupposti e condizioni previsti dalla normativa e dalle istruzioni INPS. Un’app HR dovrebbe distinguere almeno tre momenti: il lavoratore possiede un’autorizzazione registrata, il lavoratore inserisce la fruizione richiesta, e l’azienda registra e controlla l’evento secondo le regole applicabili.

Non è corretto lasciare che il semplice selettore “Legge 104” abiliti automaticamente qualunque intervallo. La UI può mostrare il tipo di permesso solo quando il profilo è configurato, oppure indicare che la richiesta sarà sottoposta a verifica.

I limiti possono essere espressi in ore o giornate, e dipendono dal tipo di fruizione, dal rapporto di lavoro e dalle condizioni previste. Un messaggio generico come “superato il limite” non aiuta l’utente — è preferibile spiegare il contesto: “Per il profilo configurato sono disponibili 2 ore nella giornata selezionata. Controlla la data o contatta l’ufficio HR.” Il messaggio non deve però trasformarsi in un’interpretazione legale automatica: deve limitarsi a descrivere il risultato della configurazione applicata.

La richiesta può essere collegata a informazioni personali delicate. L’app deve raccogliere soltanto i dati necessari, limitare gli accessi, e non mostrare dettagli sanitari a manager o colleghi che non ne hanno bisogno. Il manager può avere bisogno di sapere che esiste un’assenza autorizzata, non necessariamente la motivazione o la documentazione medica.

Congedi parentali

I congedi parentali sono disciplinati principalmente dal D.Lgs. 151/2001 e dalle modifiche successive. La gestione concreta può prevedere fruizione a giornate o ore, informazioni sul minore, periodi già utilizzati e regole economiche da verificare. Il form non dovrebbe chiedere gli stessi campi di una ferie: può essere necessario raccogliere tipo di congedo, date di inizio e fine, unità di fruizione, minore interessato se richiesto dal processo, eventuale alternanza o coordinamento con l’altro genitore, documentazione prevista, e stato della verifica.

const request = {
  type: 'parental_leave',
  startDate: '2026-09-14',
  endDate: '2026-09-16',
  unit: 'day',
  childId: 'child-123',
  status: 'pending',
};

Non bisogna però confondere il modello applicativo con la prova del diritto. L’app raccoglie e inoltra; la verifica segue il processo aziendale e le fonti ufficiali.

Malattia e certificazione

La malattia ha una natura diversa da ferie e permessi programmabili. In molti flussi l’azienda riceve una comunicazione collegata a una certificazione, e deve gestire periodo, reperibilità, rettifiche e informazioni provenienti dai canali previsti. L’app aziendale può raccogliere una segnalazione o mostrare lo stato della pratica, ma una dichiarazione inserita dal lavoratore non dovrebbe essere trattata automaticamente come certificazione valida.

È utile distinguere con chiarezza i passaggi: segnalazione del lavoratore, ricezione o associazione della documentazione, verifica amministrativa, registrazione del periodo, ed eventuale rettifica o chiusura. La UI deve comunicare lo stato corretto in ogni fase — “segnalata” non significa “approvata”, e “documento ricevuto” non significa necessariamente “pratica validata”.

I dati relativi alla salute richiedono particolare attenzione. La card visibile a un manager dovrebbe contenere solo l’informazione necessaria alla gestione organizzativa, mentre i dettagli documentali devono restare accessibili solo ai ruoli autorizzati. Un buon sistema separa dati operativi e dati documentali, applicando autorizzazioni anche lato API.

Permessi studio e aspettative

I permessi studio possono avere quote, requisiti e documentazione regolati dal CCNL o da accordi aziendali. L’utente potrebbe dover indicare corso, periodo, esame o allegare una prova secondo la procedura applicabile. L’aspettativa, invece, può avere effetti diversi sul rapporto di lavoro, e non dovrebbe essere rappresentata come un semplice permesso con un intervallo più lungo.

Per ogni causale è utile definire chi può richiederla, quanto può durare, se matura un saldo, se è retribuita secondo la regola applicabile, quali documenti servono, chi effettua il controllo, e come viene mostrata nello storico. Questa scheda di dominio è spesso più importante del componente React Native che verrà sviluppato dopo.

Ore, giorni e periodi continui

Una delle fonti più frequenti di errore è la conversione automatica tra ore e giorni. Non tutti i lavoratori hanno una giornata convenzionale di otto ore: part-time, turni e contratti diversi possono richiedere criteri differenti.

Il valore calcolato può servire alla UI, ma il backend deve ricevere il formato previsto dal contratto, con arrotondamenti applicati secondo una regola dichiarata, non in punti diversi del codice.

La validazione deve controllare anche la sovrapposizione con altre richieste: due assenze nello stesso intervallo, ferie e permesso sulla stessa giornata, richiesta duplicata dopo un timeout, periodo già chiuso dal payroll, o assenza incompatibile con un turno. Questi controlli vanno sempre ripetuti dal server, perché il client può essere offline o non aggiornato.

Validazione client e server

La validazione può essere organizzata su tre livelli. La validazione sintattica controlla date, ore positive, campi obbligatori e formati. La validazione di calendario controlla ordine delle date, sovrapposizioni, giorni lavorativi, festività e turni quando disponibili. La validazione normativa e contrattuale, infine, controlla plafond, autorizzazione, preavviso, documenti e regole dello specifico istituto.

Il client offre un feedback immediato, ma il server deve sempre ripetere le verifiche: il form può sembrare completo lato client, salvo poi essere ricalcolato e accettato o rifiutato dal server con una motivazione strutturata. Un errore restituito dal server dovrebbe avere un codice stabile e un messaggio leggibile, così la UI può distinguere richiesta non autorizzata, conflitto di date e dato mancante.

Contratti e package cieco

In un’architettura modulare il package ferie non dovrebbe conoscere URL, token o Redux. I suoi hook ricevono callback dal LeavesContext:

const {
  onSendLeaveRequest,
  onGetTypeSelectorOptions,
  onGetContatoriFeriePermessi,
} = useLeavesContext();

L’app shell fornisce l’implementazione reale, mentre il package conserva logica di presentazione, stato locale e validazioni applicative. Questa separazione consente di testare un form con mock, e di cambiare backend senza dover riscrivere sette schermate.

Errori comuni

Trattare ogni assenza come ferie fa perdere documenti, limiti, stati e ruoli differenti. Usare sempre i giorni ignora che i permessi possono essere orari, e che la conversione dipende dal lavoratore. Mostrare dati sanitari al manager confonde ruolo organizzativo e accesso alle informazioni personali. Validare solo nel client lascia scoperta un’app non aggiornata, o una richiesta costruita manualmente che aggira i controlli locali. Chiamare “approvata” una segnalazione confonde stati che devono restare distinti — ricezione, presa in carico, verifica e approvazione non sono la stessa cosa. Hardcodare le regole, infine, ignora che normativa e CCNL cambiano nel tempo: le regole devono restare configurabili e verificate.

Domande frequenti

Conclusione

La complessità delle assenze non nasce dal numero di pulsanti, ma dalla molteplicità delle regole. Permessi 104, congedi parentali, malattia, studio e aspettative vanno modellati come istituti diversi, con unità, documenti, limiti e workflow specifici propri.

Un’app HR ben progettata non nasconde questa complessità: la rende comprensibile, la applica nel posto corretto, e protegge i dati che non devono essere visibili a tutti.