Note spese e database aziendale: come portare i dati di fees in SQL Server, PostgreSQL o Oracle
Molti reparti IT preferiscono ricevere i dati delle note spese su una staging table interna e distribuirli a valle con le proprie trasformazioni. fees supporta esattamente questo approccio: l'integrazione con il database aziendale è già sviluppata e viene calata sulla configurazione specifica dell'azienda durante l'onboarding.
Le due strade disponibili: export configurabile o API JSON
Il collegamento tra fees e il database aziendale avviene in due modi. La prima opzione è un tracciato di export contabile in formato CSV, XML o TXT, configurato sui campi e sulle codifiche che il database si aspetta in import: si carica il file su una stored procedure o un job di importazione già in produzione. La seconda opzione è l'API fees Can: le spese approvate vengono esposte in JSON e il database le consuma tramite un'integrazione custom lato client. La scelta dipende dall'architettura esistente: se hai già un processo di import batch, il tracciato è la strada più rapida; se preferisci un flusso event-driven o near-real-time, l'API è più adatta.
Mappatura dei dati: centri di costo, commesse e anagrafiche
Il punto critico di ogni integrazione è la mappatura: i codici usati in fees (centri di costo, commesse, causali di spesa, anagrafiche dipendenti) devono corrispondere a quelli presenti nelle tabelle di destinazione. In onboarding il team fees analizza la struttura del database e configura il tracciato o il payload JSON in modo che i valori chiave siano già allineati. Se l'azienda usa una staging table intermedia, la mappatura può essere parziale in uscita da fees e completata da una logica di trasformazione interna prima che il dato raggiunga le tabelle operative. Questo approccio lascia al reparto IT il pieno controllo sulle regole di business senza dipendere da aggiornamenti del software di note spese.
Le due strade disponibili: export configurabile o API JSON
Per avviare l'integrazione in modo efficiente è utile arrivare all'onboarding con alcune informazioni pronte: la struttura della tabella o della staging area di destinazione (nomi colonne, tipi di dato, chiavi esterne), l'elenco dei codici di centro di costo, commessa e causale già in uso nel gestionale, e le credenziali o le modalità di accesso per il trasferimento dei file o per esporre un endpoint che consumi il JSON. Non è necessario costruire nulla da zero: fees porta il collegamento già strutturato e lo adatta. Il lavoro lato IT riguarda principalmente la validazione della mappatura e il test del flusso di import nell'ambiente di staging.
Q&A
Se uso una staging table intermedia, il tracciato di fees può uscire con campi non ancora valorizzati che completo lato mio?
Cosa devo fornire al team fees durante l'onboarding per configurare la mappatura?
fees espone i dati delle spese approvate in tempo reale tramite API o solo a fine periodo?
