Il tracciato dell’XML della Fattura Elettronica è “standard”, ma la fantasia dei programmatori è fervidissima…
Per quale oscuro motivo molti cedenti omettono di indicare il proprio Codice Fiscale? Questione di “privacy”? Se non si completano tutti i dati anagrafici, si inficia parzialmente la comodità di caricare automaticamente tutti i dati dei propri Fornitori;
Per quale motivo le linee di dettaglio devono essere numerate a passi di 5/10/20? Si pensa forse di potere aggiungere in futuro delle righe di fattura?
Per quale motivo non indicare nei blocchi DatiDDT le linee di fattura alle quali si riferiscono, aggiungendo invece ad ogni linea di dettaglio il riferimento al relativo DdT negli AltriDatiGestionali? (Questa la so: per compilare correttamente il riferimento alle linee di fattura occorre prima smazzarsi tutti i DdT coinvolti nella Fattura, e solo dopo inserire un blocco che deve essere piazzato prima dei DatiBeniServizi. Non proprio banale, e se il committente ha tirato sul prezzo del software per la compilazione degli XML… );
Dati Ordine Acquisto, Contratto, Convenzione: vedi punto precedente;
Quando si usano i codici IVA Nx, perché non indicare lo stramaledetto articolo di non applicabilità dell’IVA? AssoSoftware ha catalogato circa 95 (novantacinque!) modi diversi di dire “non c’è IVA” (e questa è la conseguenza di aver lasciato ai “filosofi” della contabilità carta bianca, un programmatore avrebbe usato un boolean). Ravanare nell’elenco dei 95 quasi alla cieca è una bella seccatura, basterebbe che i controlli dell’SDI includessero anche l’obbligatorietà del tag RiferimentoNormativo se esistesse il tag Natura;
Per il Reverse Charge usare N6!!! Ho visto degli N3 e N4… e le mie procedure per contabilizzare correttamente in maniera automatica l’RC vanno a p…allino;
Per i codici univoci SDI dei privati, s’è persa un’occasione: niente check digit, e niente elenchi pubblici dei codici assegnati e validi. Ho visto I scambiate per 1, O per 0, V per U, soprattutto se i clienti hanno compilato moduli di richiesta codice a penna. E l’errore si scopre solo dopo lo scarto…
Righe di fattura descrittive, senza importi: usate un codice IVA già presente nelle righe di Fattura valorizzate, per favore, invece di un Nx a caso!
Aggiungo un’altra casistica che non si risolverebbe con un check digit. Proprio oggi abbiamo ricevuto una fattura per qualcuno che non è nostro cliente. Lo stesso fornitore però aveva appena emesso una fattura ad un nostro cliente ed entrambe avevano il nostro codice destinatario.
La mia ipotesi: nell’inserire la seconda fattura, il fornitore ha copiato la precedente e l’ha modificata, dimenticandosi però di modificare il codice destinatario (o di toglierlo).
Sarebbe stato meglio non usare per niente i codici destinatario nelle fatture e basarsi piuttosto sulla partita IVA/codice fiscale, obbligando la gente ad inserire il codice destinatario (o pec) nel proprio cassetto fiscale se le vogliono recapitare da qualche parte.
Noi abbiamo spinto i nostri clienti verso questa soluzione… Pero’ ci sono aziende che vogliono tal fatture di qua e tal altre di là e quindi comunicano codici diversi a fornitori diversi.
d’accordo pero’ rimane il problema che se voglio indirizzare le fatture dei fornitori dello stabilimento A al canale X e le fatture dei fornitori dello stabilimento B al canale Y non avrei potuto farlo
Il problema di fondo è che si è dato uno standard che di standard ha ben poco. Avrebbero dovuto mettere dei paletti ben più rigidi nel controllo del tracciato.
Un buon 50% sbatte tutti i dati eccetto gli importi nella descrizione riga e già questo manderebbe in palla qualsiasi import su ERP che gestiscono anche il controllo sugli acquisti, aggiungici anche tutto il resto delle schifezze in pratica devi registrare ancora tutto a mano come con la vecchia fattura cartacea.
Gli xml così come sono adesso vanno bene solo per chi tiene solamente la contabilità, in sistemi strutturati sono inutilizzabili.
Se fosse compilato correttamente da tutti e in modo univoco il tracciato avrebbe tutti gli elementi necessari per incrociare i dati nei gestionali.
Il problema è che se devo andare a prelevare articolo e DDT ad esempio e come mi è già successo mettono tutto nella descrizione o non citano le righe a cui il DDT fa riferimento è impossibile automatizzare qualsiasi processo.
Si ma allora prima di partire avrebbero dovuto aprire il cassetto fiscale a tutti compresi i privati, dando la possibilità di specificare la destinazione per tutti i soggetti fiscali e la possibilità a tutti i soggetti di vedere le proprie fatture, implementando direttamente loro un webservice per l’interrogazione del cassetto e l’invio delle fatture (parlo contro il mio interesse)
Ma la mia idea è che non l’abbiano fatto per evitare di beccarsi denuncie per interruzione di pubblico servizio generalizzate al primo problema…
Il tracciato xml attuale è carente in diversi punti: ad esempio non permette di inserire delle diciture in fatture (esenzione ritenuta, regime forfettario per chi fa la FE, etc.). L’elemento causale prevede un limitato e insufficiente numero di caratteri per tale esigenza e allora si fa la forzatura di utilizzare i righi degli articoli. LINK
Ma anche la tradizionale modalità di pagamento “rimessa diretta” non è stata prevista e allora alcuni compensano (giustamente) sempre con i righi descrittivi.
mi sorprende che tu possa contabilizzare correttamente in automatico un xml considerando che le spese accessorie non sono suddivisibili tra trasporto, spese bancarie, spese imballaggio, varie ecc… salvo che per qualche caso fortuito il fornitore non abbia scritto esattamente quelle parole nella descrizione libera.
non hai modo di distinguere la merce dai servici se il fornitore non lo ha specificato nel rigo e non c’è uno standard in merito.
ai fini iva esistono ad esempio aliquota 22%, 22% indetraibile al 100%, indetraibile al 50% e l’unica cosa riportata nel riepilogo iva del XML è :
I 22% e con un po di fortuna la normativa a descrizione libera (niente standard)
Non voglio nemmeno pensare a tutti i casi N3 o N4 dove la sola differenza è la normativa che potrebbe non venir riportata da chi emette la fattura o la riporta a propria discrezione.
La contabilizzazione di una fattura fornitore, per quanto il programma possa attingere a tutti i dati dallo xml, prevede cmq, un intervento da parte dell’operatore.
Ad esempio, la deducibilità dell’iva non dipende da chi emette il documento, ma da chi lo riceve,
oppure, i costi potrebbero essere suddivisi su piu conti contabili, ed altro ancora…
Ci sono pero’ delle situazioni in cui, un xml fatto bene, consente di fatto una automazione completa. Per esempio “utenze” (elettricità, telefoni, …). Servizi ripetuti (p.es. pulizie, manutenzioni, …). Oppure acquisti basati su “ordini di acquisto”, ecc…
Noi abbiamo automatizzato una gran parte della contabilizzazione fatture; ogni azienda avrà chiaramente una percentuale maggiore o minore di fatture che può trattare in questo modo.
Sicuramente ci possono essere aziende che hanno un grado di automazione maggiore,
io ho preferito, contabilizzare un documento alla volta, ti faccio vedere il documento del fornitore nel formato assosoftware (se vuoi te lo stampi), ti faccio vedere eventuali allegati presenti sul documento, e ti propongo tutto quello che posso…
l’operatore ha la possibilità di correggere ( o di aggiungere ) quello che ritiene, per poi convalidare il tutto.
questo significa personalizzare la lettura del’XML per ogni fornitore.
analizzando le fatture ricevute di 10 clienti diversi non ho trovato similarità certe che possano garantire in modo affidabile la contabilizzazione.
anche noi preimpostiamo la contabilizzazione per fattura ma non la generiamo automaticamente.
In pratica al click viene aperto un nuovo movimento contabile con i dati precompilati e l’utente decide se salvarlo, modificarlo o annullare il tutto.
Sinceramente non mi affiderei su un sistema a “descrizione libera”.
piu che altro sarebbe stato utile avere la possibilità di avere un inoltro in contemporanea su due codici senza necessità di avere un reinoltro da parte del codice ricevente.
oppure la possibilità di interrogare il cassetto fiscale per ottenere i dati aggiornati.
avrebbe evitato molte discussioni tra commercialisti/clienti che entrambi vogliono avere le fatture sul proprio gestionale senza dover star li ad esportarle/importarle.
Anche questo si sarebbe potuto risolvere, consentendo di specificare codici destinatario multipli e verificare durante l’invio che il codice nella fattura corrisponda ad uno di quelli validi (come già avviene per la PA).
Se non si completano tutti i dati anagrafici, si inficia parzialmente la comodità di caricare automaticamente tutti i dati dei propri Fornitori;
);
