Mettere lo sviluppatore in condizione di capire il progetto e di ragionare sul preventivo (giornate per figura e per fase). Non è una specifica tecnica di dettaglio: quella nasce dopo l'analisi con il cliente.
GO WORLD, tour operator di Ancona (gruppo, ~15 società, ~19 brand), specializzato in viaggi outgoing extra-UE su misura.
Valutano 3-4 fornitori. Badano al Total Cost of Ownership e al tasso di correttezza.
Automatizzare 3 processi con una squadra di agenti AI, lasciando il controllo finale a una persona e facendo tornare le registrazioni dentro il loro gestionale (niente sistema contabile parallelo).
Fondamentale per stimare: la difficoltà (e quindi lo sforzo) cresce da sinistra a destra. Il valore del progetto si concentra a destra.
Il rendiconto BSP ha campi certi (n. biglietto, nome, documento). Match con la pratica o "record non abbinato". Rischio basso.
⚠︎ SferaNet lo fa già in parte nativamente → valore aggiunto limitatoIn più c'è il cambio: pagano fornitori in USD, addebitati in EUR a date diverse. Importo in pratica ≠ importo addebitato. Serve human-in-the-loop sui casi che non tornano.
Documenti destrutturati, niente tracciati, cambio da recuperare alla data operazione, fonti multiple e multilingua. Qui si vince o si perde: abbinare ogni documento alla pratica e comporre il margine.
Deposito centrale delle rendicontazioni fornitori. Idea validata dal cliente: un osservatore intelligente che cattura report/allegati e li smista. SferaNet ha un Mail Reader nativo (casella → CRM) usabile come gancio.
File periodico. SferaNet lo importa già: da capire quanto ci appoggiamo al nativo.
Via Open Banking (PSD2) in sola lettura, oppure import estratto conto (CAMT/MT940). Mai credenziali del cliente.
Piattaforme internazionali (transfer, escursioni): alcune espongono report via login (a volte 2FA), altre mandano PDF via email. Numero limitato di fornitori → pochi modelli/formati. I casi limite (es. email in francese da operatore locale) restano all'uomo.
Ciclo SdI (XML).
SferaNet espone Export Data, API REST JSON su pratiche, anagrafiche, preventivi (ACL per azienda/utente). È da qui che l'agente pesca i dati per l'abbinamento.
Import Data API (2FA + HTTPS, XML/JSON) scrive entità operative: prenotazioni, pratiche, anagrafiche, incassi. Esistono già integrazioni terze reali che scrivono in SferaNet (Pliant, Sekurest).
NON risulta un'API che scriva direttamente le registrazioni contabili/IVA/74-ter. Quelle le genera SferaNet internamente, a valle dei dati operativi. → Scriviamo a monte (agganciamo il documento fornitore alla pratica) e lasciamo che SferaNet produca lui la scrittura fiscale. Coerente col vincolo "un solo sistema contabile".
Due scenari da prevedere: A) scrittura via API → integrazione lineare. B) solo lettura → l'agente produce un file di import mappato esattamente sulla struttura pratica, caricato con validazione umana. In entrambi: nessuna contabilità parallela.
Per ogni pratica (un viaggio), la catena di agenti deve produrre la registrazione finale. Qui si concentra lo sforzo di sviluppo.
Un errore sul 74-ter (IVA) è grave. Il sistema deve isolare l'incerto, non forzarlo. Soglie di confidenza + human-in-the-loop obbligatori; il commercialista firma.
Unità di esercizio = la PRATICA, per complessità (non per documento). Costo per pratica = Σ (estrazione documenti + abbinamento + margine) lato AI [centesimi] + validazione umana [solo eccezioni]. Il costo AI è trascurabile; il driver è il minuto-uomo residuo, che cala con l'auto-approvazione.
In rodaggio (si valida tutto) il costo umano è ~2-3× più alto; poi scende a regime. Numeri indicativi, da misurare in demo su documenti reali.
Con Marco/Andrea: workflow reali, volumi, fonti, conferma SferaNet.
Già offerta al cliente, con garanzia di recesso: un flusso end-to-end su dati loro.
Base condivisa (osservatore email + estrazione) → flusso più semplice → riconciliazione → 74-ter.
Un solo sistema contabile (SferaNet), l'output torna lì. Accuratezza critica sul 74-ter. GDPR su dati bancari e fiscali (cliente titolare, noi responsabili). Human-in-the-loop obbligatorio sui numeri; il commercialista firma.
Stimare le giornate per figura e per fase (vedi § 3 e § 12), per costruire insieme il preventivo di produzione + il modello di esercizio.