La vera domanda e’: come e’ possibile lavorare cosi’ male?
Fin ora ho riscontrato i seguenti problemi:
documentazione vecchia, con dati addirittura sbagliati, completamente opaca, molto frammentata
fatturapa.gov.it e’ un labirinto di informazioni buttate la’ senza un ordine ne’ un senso
il webservice e l’xml andavano forte 20 anni fa, fare questa scelta oggi significa vivere su un altro pianeta, ad essere buoni
i nomi dei tag xml sono in italiano ed inglese, a volte scritti per esteso, a volte abbreviati
il servizio fornito dallo sdi ha tempistiche degne forse solo della posta ordinaria
l’assistenza ha operatori maleducati, frettolosi, incompetenti
la struttura dell’xml e’ cervellotica ed improbabile
e’ tutto in chiaro, cosa che rimarca la scollatura che questi geni hanno con la realta’
Questa roba e’ fragilissima e non oso pensare cosa succederea’ alla prima modifica, che avverra’ credo presto per criptare le informazioni.
Vorrei sapere cosa ne pensano anche altri su questo forum, se hanno notato le stesse cose che ho notato io o se invece pensano che sia un punto di partenza accettabile per poter lavorare serenamente e facilitare gli sviluppatori ed i milioni di utenti.
Io personalmente, ancora dopo settimane e mesi, non mi capacito di come si possa lavorare cosi’ male.
Sono pienamente d’accordo.
Io sto cercando di capire come emettere un’autofattura nei confronti di soci esonerati che vendono prodotti agricoli ad una cooperativa.
Cercando di reperire informazioni da ovunque, non immagina quante soluzioni ho a disposizione.
Dovendo però integrare la e-fattura in un gestionale, dovrei avere una risposta unica e chiara.
Ho rivolto anche il quesito all’ADE, ma in più di una circostanza, le risposte date vengono smentite da altri operatori i quali, a loro volta, hanno ricevuto risposta dalla stessa Agenzia.
NON riesco ad andare avanti !!! TD01, TD20 ancora non lo so. Né so se il cedente/prestatore, nel caso specifico, coincide con il cessionario/committente.
E’ sufficiente emettere un documento “autifattura” utilizzando la codifica TD01 (no TD20) indicando nella descrizione della fattura che si tratta di una “autofattura emessa per assolvere agli obblighi di inversione contabile”; non è necessario creare un apposito registro sezionale IVA ma se volete farlo non è un errore.
Anch’io ho rilevato grandi carenze nelle documentazione, grande confusione rispetto al fatto che il progetto iniziale fosse rivolto solo alla pa (fatturaPA appunto), e operatori che rispondevano un po’ in ritardo… ma tutto sommato la struttura “busta xml” via web service è un modo abbastanza lineare per comunicare un dato complesso (l’xml è un formato dati ideale per questo tipo di informazioni, perchè veicola le informazioni in maniera corretta sia come documento singolo che come collezioni di documenti).
Scambiarsi questi documenti via web-service soap mi sembra normale… quali erano le alternative? Forse REST, che è comunque un ws, ma è meno espressivo.
Sicuramente è un po’ astruso il fatto che noi canali accreditati siamo costretti a tenere on-line un server ws per ricevere le chiamate dell’agenzia… probabilmente sarebbe stato sufficiente che i web-service funzionassero in un senso solo (ovvero che solo l’agenzia esponesse dei web-service, a cui mandare le fatture, e dove -ogni tot- controllare se ci sono notifiche). Accendere questo benedetto server ws per me è stato il 50% dello sbattimento, dato che i requisiti per i certificati erano decisamente cervellotici e mal documentati. Ma evidentemente c’erano problematiche relative alla certezza legale che il dato fosse comunicato ai canali…
Scusa ma questa proprio non la capisco… se ti accrediti come canale comunque immagino che tu debba ricevere le fatture dai clienti… quindi in qualche modo un ws (o un server rest) che le fatture le prende deve pure stare su…
Se non lo vuoi tenere su tutti i giorni e usi il tuo canale solo per l tue fatture, rivolgiti ad un servizio esterno…
Di problemi SDI ne ha tanti, ma se non volevi tenere su un server a rispondere SDI bastava che tu non diventassi un canale…
La logica di “ogni tot controllare se ci sono notifiche” avrebbe portato un carico sui server di SDI totalmente inutile con n-mila chiamate a vuoto e non una sola chiamata da parte di SDI al tuo server per dirti ci sono esiti… Questo si che sarebbe lavorare veramente MALE…
Capisco la tua critica, in effetti il mio punto di vista è parziale perchè il nostro canale è solo in invio, non in ricezione.
Di conseguenza il nostro server ws deve solo a ricevere le notifiche delle fatture che inviamo; e dato che le notifiche sono in relazione 1 a 1 con le fatture e sono emesse solitamente entro 24h, il “controllare ogni tot se ci sono notifiche” si tradurrebbe in “controllare dopo 24 ore l’invio di una fattura se c’è una una notifica corrispondente”.
Anche se poi non vedrei questo dramma di caso di “richieste a vuoto”, molte tecnologie funzionano con richieste pull (esempio: le email)… poi la minimizzazione del traffico dipende molto dalle api dei ws.
Invece francamente non capisco la logica del “rivolgiti a un servizio esterno”: l’agenzia delle entrate è un ente pubblico, se io voglio avere un rapporto diretto (anche un rapporto informatico) e aprire un canale per gestire le mie fatture, certamente l’agenzia mi deve mettere nelle condizioni di farlo!
Per quale motivo dovrei essere obbligato a pagare un servizio esterno privato (spesso con costi esosi) per adempiere a un mio dovere (oltre che un mio piacere ), che è quello di fatturare?
Anzi ho molto apprezzato che l’agenzia abbia messo in campo diversi strumenti per permettere ai professionisti e alle aziende di emettere fatture elettroniche in relativa semplicità (come il sito fatture e corrispettivi, l’app per smartphone, etc).
Se volevi notifiche pull bastava mandare le fatture per pec e andarsi a leggere la casella imap della pec per gli esiti… Anche quello è un servizio messo gratuitamente a disposizione dall’agenzia delle entrate… Una casella PEC costa meno della corrente che consuma un server…
L’agenzia ha messo a disposizione degli utenti 3 canali più o meno parametrizzati per traffico…
PEC
SDICOOP
SDIFTP
due di questi richiedono che il server del canale sia sempre su… non ci vedo nulla di assurdo…
Al massimo trovo assurdo che non funzionino…
si può dire che, l’agenzia delle entrate, come tutti gli italiani, se la prende con calma.
la fatturazione elettronica esiste da anni, dal 2016/2017 si potevano inoltrare le fatture al b2b ma realmente nessuno o in pochi hanno adottato il sistema.
di conseguenza le problematiche non sono venute fuori e il sistema di interscambio è rimasto in panciolle in attesa delle problematiche.
Se si avesse preso in generale più seriamente la cosa (e mi metto in mezzo) a quest’ora non saremmo qui a incasinarci la vita perchè queste problematiche non ci sarebbero. d’altro canto però, l’ade avrebbe dovuto non dormire sugli allori e organizzare un sistema di fatturazione consono già da allora e non aspettare gli ultimi 6 mesi con modifiche apportate gli ultimi 15 giorni ed in corso d’opera.
Daniele, dato che non era un obbligo, ma era facoltativo inoltrare le fatture al b2b mi spieghi per cortesia perché un impresa avrebbe dovuto farsi carico di costi senza trarre alcun beneficio ?
Tuttavia nel momento in cui tu, Agenzia delle Entrate, mi rendi obbligatorio utilizzare un tuo servizio, devi essere stra-certa che quel servizio funzioni.
Ho clienti che non ricevono fatture (non solo quelli che usano me come intermediario), che inviano fatture che non essendo ricevute dal cliente non sono neppure pagabili.
Insomma un ulteriore danno ad un economia che già fatica a camminare, senza considerare il fatto che alla fine chi evadeva, continuerà ad evadere dato che chi non faceva fattura continuerà a non farla…
Il fatto che un sistema pubblico non funzioni a casa mia è configurabile nel reato di interruzione di pubblico servizio, ma vedo che nessuno dice nulla. In 30gg ci sono stati fino ad ora 10gg di disservizi, almeno per quanto mi riguarda, secondo te è normale ?
Non centra nulla che gli i cittadini non avessero fatto le prove, qui nonostante i 45 milioni di € messi a disposizione di SDI per il sistema qualcuno ha fatto calcoli di dimensionamento errati ed evidentemente il sistema SDI non riesce a tener testa ai flussi di dati in ingresso/uscita.
Ciao Romolo,
io non sto dicendo che si sarebbe dovuto ma potuto.
quello su cui riflettevo è semplicemente lo stesso ragionamento che probabilmente abbiamo fatto tutti.
“c’è la possibilità, ma dato che non è obbligatorio , che l’azienda lavora già su altro e (probabilmente) non ha tempo da dedicare su servizi che fanno perdere tempo e non guadagnare, e considerando che con i vari governi che ci troviamo questa cosa potrebbe saltare …aspettiamo”
ma scrivevo anche che SDI/ADE avrebbe dovuto (loro si DOVEVANO) darsi una mossa e gestire la cosa senza aspettare gli ultimi mesi. non c’è una guida, non ci sono informazioni, non c’è assistenza.
Non è un segreto che purtroppo una “buona parte” (non tutti) degli operatori legati a servizi statali lavorano lenti, male e poche ore. Avendo conoscenze personali all’interno di alcuni enti ne ho sentite tali che la fuga dall’ufficio nei film di fantozzi è roba da bambini.
anche adesso abbiamo l’esempio plateale che se non “imbocchi” i servizi statali facendo da tester, non si muovono.
La riflessione di prima era :
se tanto l’ADE non si sarebbe mossa a prescindere, tanto vale partire prima, trovare le problematiche prima, e vivere sereni ora che è obbligatorio.
In un paese che spero che prima o poi possa diventare “Normale”, in una situazione del genere l’azionista di riferimento di SOGEI dovrebbe prendere l’Amministratore e dargli una lavata di capo…
Vedi che a quel punto le cose iniziano a funzionare…
In alcune realtà che conosco, dove le cose non funzionavano, gli Amministratori degli Enti sono stati convocati e gli è stato prospettato il licenziamento in tronco.
Entro due mesi funzionava tutto, dato che l’Amministratore in questione ha iniziato a minacciare della stessa fine tutti i suoi dirigenti e sono iniziate a partire lettere di richiamo…
purtroppo l’italia è un sistema ad interpretazione dove chi può approfittarne ne approfitta.
tra dipendenti sfruttati dagli amministratori ai dipendenti inadempienti che sfruttano il sistema a scapito dell’azienda. entrambe le realtà esistono a seconda dell’azienda che visiti.
Comunque, stanchi di queste situazioni ho conoscenze che si sono trasferite in olanda, germania e lussemburgo e con sorpresa, hanno trovato situazioni simili. Come dicevano i vecchi, tutto il mondo è paese.
comunque … stiamo andando off topic.
Per la soluzione che dici, un service per mandare le fatture e controllare ogni tanto se ci sono notifiche, si chiama posta elettronica pec
Che poi è la soluzione che ho adottato io, senza nessuno sbattimento di certificati. Mando le fatture con pec (integrarsi con un smtp è una cavolata) e le ricevo via pec (integrarsi con un imap non è esattamente una cavolata, ma resta piuttosto semplice).
Condivido alcune delle tue annotazioni, ma non tutte.
Sulla scelta degli standard onestamente non so: penso occorrerebbe avere un quadro preciso di quali siano gli standard più diffusi nell’IT che si occupa di fatturazione. Per me che mi occupo d’altro REST e JSON per esempio sarebbero stati più comodi, e probabilmente più in linea con gli stadard attuali, ma forse avrebbe costretto la maggior parte della gente a usare standard diversi da quelli che usa di solito.
Sulla criptazione, mah… fino a ieri le fatture hanno viaggiato su fogli di carta dentro a buste, spesso neppure sigillate. Peraltro credo che facciano più o meno tutta la strada dietro a SSL, no?
Vi vedo parecchio convinti con questa patch di usare la pec come forma di comunicazione server-server d’altronde problemi complessi necessitano soluzioni creative.
Dai mi avete intrigato. Quindi il vostro giro è: creo l’xml, lo invio tramite pec, controllo le pec in arrivo, prendo gli allegati delle pec in arrivo, confronto i nomi degli allegati con le fatture inviate per verificare se sono notifiche correlate… e poi alla fine passate tutto e lo importate tutto nei vostri gestionali?
Guarda che è un giro che fanno anche altri gestionali di contabilità (so per certo quello della sistemi).
Comunque si il giro è quello…
Invio la fattura, leggo la casella imap, guardo il mittente, scarico il messaggio e leggo la notifica.
La fattura passerà quindi per i seguenti stati:
inviata (ho l’accettazione della pec)
consegnata a SDI (ricevuta di consegna della PEC)
elaborata (PEC con notifica di esito da parte di SDI)
se notifica di esito=Mancata consegna o Ricevuta di consegna importo la fattura fra quelle emesse della contabilità
se notifica di esito=Scarto riemetto la fattura previa correzione degli errori.
Per il B2B basta questo, per le PA ovviamente ho anche altri stati intermedi prima della effettiva contabilizzazione.
Sì, anch’io faccio come Romolo_Manfredini.
In realtà mi sono semplificato ulteriormente la cosa forwardando la pec a una casella GMAIL, così invece di usare imap uso le API di Gmail che sono ancora più veloci. Per la serie soluzioni creative
S*
), che è quello di fatturare?
d’altronde problemi complessi necessitano soluzioni creative.
hai vinto tutto!!! Altro che configurare il certificato sul server dedicato!!!