Motore di controllo trasferte e diarie su SAP BTP
Backend SAP CAP su Node.js e HANA Cloud che automatizza le trasferte in SAP Concur: policy, diarie e integrazione con agenzia viaggi, ServiceNow e payroll. Include un servizio di routing su Cloud Foundry per le distanze in km, senza API a pagamento.
Descrizione
Applicazione backend sviluppata per un gruppo bancario italiano tra i primi cinque per attivi che estende SAP Concur con le regole di rimborso previste dal contratto collettivo e dalla policy interna. Il sistema riceve gli eventi di ciclo di vita di richieste di trasferta e note spese (Submitted, Approved, Cancelled, Rejected), applica i controlli che la configurazione standard di Concur non copre, calcola la diaria giornaliera e propaga i risultati verso Concur, l'agenzia viaggi, ServiceNow e i file per il payroll. Non ha interfaccia utente: è un livello di servizi OData V4 invocato da SAP Integration Suite (Cloud Integration).
Il problema
Le trasferte del gruppo sono gestite in SAP Concur, ma le regole di rimborso non sono esprimibili nella sua configurazione standard: la diaria si compone a terzi (pranzo, cena, pernotto) su tariffe che dipendono dalla piazza e dalla categoria contrattuale, va detratta o meno a seconda che la trasferta sia in Italia o all'estero, decade sotto una soglia di giorni e si riduce del 15% oltre il trentunesimo o quarantaseiesimo giorno consecutivo. A questo si aggiungono i controlli di conformità — trasferte brevi, missioni in sede, paesi a rischio, sovrapposizione con assenze registrate a sistema — che l'amministrazione doveva verificare a mano nota spese per nota spese.
Vincoli
Lavoro sotto accordo di riservatezza: il cliente non è nominabile e il codice non è pubblico. I sistemi a valle non sono negoziabili: le presenze vivono su PeopleFocus, un servizio SOAP raggiungibile solo tramite Cloud Connector, e l'agenzia viaggi accetta esclusivamente una busta XML proprietaria con versioning decrescente dei documenti. Le action sono chiamate da webhook: un errore non gestito non deve innescare tempeste di retry. Diverse query hanno dovuto aggirare limiti reali di SAP HANA (LIMIT vietato nelle subquery correlate, colonne NCLOB per i payload lunghi).
Architettura
Applicazione SAP Cloud Application Programming Model (CAP) su Node.js, distribuita su SAP BTP Cloud Foundry come archivio MTA (servizio, deployer HANA, approuter), con autenticazione XSUAA.
Il flusso parte sempre da Concur: i webhook sugli eventi di richiesta di trasferta e nota spese chiamano Cloud Integration, che inoltra la chiamata al servizio CAP senza trasformarla. Da lì in avanti la logica sta tutta nel CAP, che interroga Concur per i dettagli della pratica, PeopleFocus per la sovrapposizione con le assenze registrate, ServiceNow per i dati di servizio, e produce la busta XML per l'agenzia viaggi. Le conferme dell'agenzia rientrano da un secondo flusso di Cloud Integration e aggiornano le pratiche a database.
Andata
SAP Concur --webhook--> Integration Suite --OData V4--> servizio CAP (Node.js)
|
+----------------+----------------+---------------+
v v v v
SAP HANA Cloud Concur REST API PeopleFocus ServiceNow
(28 entità) (v3/v4/v5) (SOAP, Cloud
Connector)
Ritorno
servizio CAP --busta XML--> Integration Suite --> agenzia viaggi
agenzia viaggi --conferme--> Integration Suite --> servizio CAP --> SAP HANA Cloud
- sette servizi CAP, circa venticinque action, un unico modello dati CDS di 28 entità sullo schema
TRAVEL; - due stored procedure HANA (
.hdbprocedure) per gli upsert massivi, dove il round-trip riga per riga non reggeva; - diario di run strutturato (
run-trace.js) inviato a Cloud Integration per il monitoraggio: esito, severità, contatori, passi per singola richiesta; - 12 self-check basati su
assert, eseguibili connode, a copertura delle regole di calcolo.
Risultato
Cosa cambia per il cliente#
Prima le trasferte passavano da una piattaforma esterna al mondo SAP, con un livello di automazione più basso: le regole di rimborso previste dal contratto collettivo e dalla policy interna finivano comunque sotto verifica manuale dell'amministrazione, una nota spese alla volta. Il programma aveva quindi due obiettivi: riportare l'intero processo dentro il perimetro SAP, accanto agli altri sistemi del gruppo, e far applicare al sistema le regole che fino a quel momento dipendevano da un controllo umano.
Il motore calcola oggi la diaria nelle quattro casistiche previste — giornaliera e pluri-giorno, Italia ed estero — e applica da solo i controlli che l'amministrazione eseguiva a mano: trasferte brevi, missioni in sede, paesi a rischio, continuità fra trasferte consecutive, riduzione oltre soglia, sovrapposizione con le assenze registrate a sistema. I flussi di approvazione, cancellazione e rifiuto e la consegna del documento all'agenzia viaggi sono implementati end-to-end. Il sistema è stato consegnato ed è attualmente in validazione utente presso il cliente.
La scelta che ha evitato un costo ricorrente#
Il rimborso chilometrico richiede la distanza reale fra due indirizzi. Le opzioni disponibili — Google Distance Matrix e un servizio equivalente dell'ecosistema SAP — sono entrambe a consumo, con soglie che il volume di trasferte di una popolazione bancaria di alcune migliaia di persone supera senza difficoltà: significava un costo ricorrente per ogni distanza calcolata, su una funzione per cui il cliente non voleva una dipendenza a pagamento.
Ho proposto e realizzato l'alternativa. OSRM è un motore di routing open source su dati OpenStreetMap: l'ho verificato in locale, ne ho costruito un'immagine Docker con il solo estratto cartografico italiano — l'unico perimetro richiesto — e l'ho distribuito come servizio su Cloud Foundry, accanto all'applicazione. Il calcolo delle distanze resta quindi dentro l'infrastruttura del cliente, senza chiamate verso servizi esterni e senza costo per chiamata, con una cache persistente sulle coordinate che evita di ricalcolare le tratte ricorrenti.
Come è stato costruito#
Seguo la componente CAP come unico sviluppatore da fine febbraio 2026, con proprietà tecnica end-to-end — modello dati, servizi, integrazioni e rilasci su BTP — lavorando sulle specifiche funzionali curate dall'analista di progetto. Il perimetro è cresciuto per fasi successive, dalle prime casistiche di calcolo della diaria fino all'integrazione con l'agenzia viaggi e alla gestione del flusso di ritorno.
Le regole che è più facile sbagliare — continuità fra trasferte consecutive, riduzione oltre soglia, allineamento delle date fra testata e segmenti — sono coperte da controlli eseguibili: una regressione emerge subito, senza dover ripartire da una richiesta reale.