Note spese e n8n: come portare i dati di fees nei tuoi workflow di automazione
Chi sceglie n8n di solito ha già un'idea chiara di come vuole che i dati si muovano: self-hosted, flussi costruiti internamente, nessuna dipendenza da connettori di terze parti. L'integrazione con fees segue questa logica: in onboarding viene calata sulla configurazione specifica dell'azienda, con i campi, le causali e le codifiche già allineate a quello che n8n si aspetta in ingresso.
Due strade tecniche, entrambe disponibili
fees supporta due modalità per alimentare n8n con i dati delle note spese approvate. La prima è il tracciato di export contabile: un file CSV, XML o TXT con struttura configurabile, prodotto da fees e leggibile da un nodo di import in n8n. La seconda è l'API fees Can, che restituisce i dati in JSON e si presta a essere consumata direttamente da un nodo HTTP in n8n, senza file intermedi. La scelta dipende dall'architettura già in uso: se il flusso n8n gestisce già file batch, il tracciato è la via più diretta; se si preferisce event-driven o near-real-time, le API JSON sono lo strumento giusto.
Mappatura dei dati: centri di costo, commesse e causali
Il punto critico di qualsiasi integrazione contabile non è il trasporto dei dati, ma la loro mappatura. fees permette di taggare ogni spesa con centro di costo, commessa, progetto o cliente: questi campi devono corrispondere alle codifiche che il flusso n8n usa per instradare i dati verso il gestionale o il sistema HR di destinazione. In onboarding si definisce questa corrispondenza: le causali di fees vengono allineate ai codici attesi a valle, così il flusso n8n riceve dati già pronti, senza trasformazioni manuali aggiuntive. Lato IT, la cosa utile da preparare è la lista delle codifiche in uso nel sistema di destinazione.
Due strade tecniche, entrambe disponibili
Per attivare l'integrazione non serve costruire nulla da zero: il collegamento esiste e viene adattato. Quello che accelera l'onboarding è arrivare con alcune informazioni già pronte: la struttura dei centri di costo e delle commesse nel sistema di destinazione, il formato atteso dal nodo n8n che riceverà i dati (campo per campo, se si usa il tracciato file), e l'eventuale logica di trigger già presente nel flusso. Se l'istanza n8n è self-hosted in rete privata, è utile chiarire in anticipo come esporre o raggiungere l'endpoint, in modo che il team fees possa configurare il flusso di export in modo coerente con la topologia di rete esistente.
Q&A
Cosa riceve esattamente n8n da fees — un file o una chiamata API?
Come si gestisce la mappatura se i codici di centro di costo in fees non coincidono con quelli del sistema di destinazione?
fees supporta l'invio automatico dei dati approvati verso n8n senza intervento manuale?
