Sincronizzare l'anagrafica dipendenti tra HR e note spese: guida tecnica e operativa
Quando l'anagrafica dipendenti vive separatamente nel sistema HR e nel software di note spese, il rischio è concreto: utenti duplicati, ex dipendenti ancora attivi, spese approvate da responsabili sbagliati. Risolvere il problema richiede una strategia chiara su fonte di verità, chiave di join e flusso di aggiornamento. fees supporta questo processo tramite export configurabili e API.
Il problema: due anagrafiche che divergono
In assenza di sincronizzazione, l'anagrafica del sistema HR e quella del software di note spese evolvono in modo indipendente. Un'assunzione registrata in HR non viene propagata: il nuovo dipendente non può caricare spese. Una cessazione non comunicata lascia l'account attivo: il rischio di rimborsi indebiti è reale. Le anagrafiche duplicate nascono spesso da onboarding manuali ripetuti o da import parziali. La radice del problema è l'assenza di una fonte di verità unica e di un identificativo stabile condiviso tra i due sistemi.
Chiave di join e fonte di verità: i criteri di scelta
La fonte di verità deve essere il sistema HR: è lì che vivono assunzione, cessazione, centro di costo, responsabile gerarchico. Il software di note spese è il sistema downstream che consuma quei dati. La chiave di join deve essere un identificativo stabile e non riutilizzabile: il codice fiscale o la matricola interna sono candidati validi; l'email aziendale no, perché può cambiare. Il flusso ideale è unidirezionale in scrittura (HR → note spese) e prevede eventi espliciti: creazione utente, modifica ruolo o centro di costo, disattivazione. Senza eventi espliciti si ricade nella riconciliazione periodica, che introduce finestre di disallineamento.
Il problema: due anagrafiche che divergono
fees supporta due modalità di integrazione con i sistemi HR. La prima è tramite tracciati di export contabile configurabili (CSV, XML o TXT): il sistema HR genera il file secondo il tracciato concordato in fase di onboarding e fees lo importa, aggiornando utenti, centri di costo e struttura approvativa. La seconda è tramite le API fees Can, che restituiscono e ricevono dati in JSON e consentono di automatizzare il flusso in modo event-driven, senza file intermedi. In entrambi i casi, i flussi di approvazione multilivello e il tagging per centro di costo o commessa riflettono la struttura organizzativa importata dall'HR, mantenendo coerenza tra gerarchia reale e processo di rimborso.
Q&A
Quale identificativo usare come chiave di join tra HR e fees?
Come gestisco la cessazione di un dipendente senza lasciare l'account attivo?
fees supporta l'aggiornamento automatico dei centri di costo e degli approvatori quando cambia la struttura organizzativa?
