Versione 1.2.1, superset della versione 1.2 (o meglio, la 1.2 è un caso base della 1.2.1)?

Fatturazione Elettronica
1

Ciao a tutti,
vista la potenziale difficoltà rilevata da alcuni a distinguere facilmente e univocamente se una fattura appartiene all’uno o all’altro formato, stavo verificando se la nuova versione può costituire un super-set della vecchia, ovvero se la versione 1.2 potrebbe essere considerata un istanza particolare, un caso base, della versione 1.2.1 e quindi gestire tutte le fatture come se fossero della nuova versione.

Valutando le differenze descritte nell’apposito documento mi sembra che questo sia fattibile, come di seguito dettagliato:

  • Aggiunto l’attribute SistemaEmittente: è opzionale, quindi non è un problema
  • Modificata la molteplicità dell’elemento DatiRitenutain DatiGeneraliDocumentoType: la versione 1.2 rientra nel “caso-base” con molteplicità 0…1, dato che è stata estesa la molteplicità e non ridotta
  • Modificata l’obbligatorietàdell’elemento ImportoBolloin DatiBolloType: è stato reso opzionale
  • Modificato il type dell’elemento Importo in ScontoMaggiorazioneType per recepire fino a 8 decimali: : non credo sia un problema, 12,34 è uguale a 12,34000000… al massimo bisogna forzare la trasformazione
  • Aggiunti i valori M2 e ZO in type CausalePagamentoTypeed eliminato il valore Z: non dovrebbe essere un problema mantenerli entrambi
  • Aggiunti i valori TD16, TD17, TD18, TD19, TD21, TD22, TD23, TD24, TD25, TD26 e TD27 in type TipoDocumentoType: sono nuovi valori, non è un problema
  • Aggiunti i valori RT03, RT04, RT05 e RT06 in type TipoRitenutaType: sono nuovi valori, non è un problema
  • Aggiunto il valore MP23 in type ModalitaPagamentoType: nuovo valore, non è un problema
  • Modificato il type dell’elemento CodiceValorein CodiceArticoloType con ampliamento di caratteri ammessi: non credo sia un problema
  • Aggiunti i valori N2.1, N2.2, N3.1, N3.2, N3.3, N3.4, N3.5, N3.6, N6.1, N6.2, N6.3, N6.4, N6.5, N6.6, N6.7, N6.8, N6.9 in type NaturaType (presente indicazione che i codici N2, N3 e N6 non saranno più validi a partire dal primo ottobre 2020): sono nuovi valori, non è un problema
  • Modificato il type EmailType: non credo sia un problema.

Anche a livello di foglio di stile si potrebbe ipotizzare che il nuovo gestisca anche la struttura del vecchio. Che dite? Gli assunti suddetti sono veri? Posso “forzare” qualsiasi fattura in ingresso come se fosse v1.2.1 e gestirla come tale?

1 Mi Piace
2

Non vedo alcun problema… in modo particolare per le “fatture acquisti” che riceverai, ci saranno alcune con il vecchio tracciato, altre con il nuovo, e quindi, se le tratti tutte come se fossero nuove, non vedo alcun problema.

3

Questo è l’unico potenziale problema che vedo. La nuova espressione regolare, assurdamente complicata, è più stringente di quella precedente. O per essere più precisi, è più stringente, tranne un caso. La vecchia espressione regolare richiedeva la presenza di un punto nel dominio, mentre quella nuova no.

Tra l’altro non capisco perché l’abbiano fatto. Anche se un indirizzo email rispetta la sintassi corretta, non vuol dire che sia valido. La verifica può essere fatta solo provando ad inviare un’email all’indirizzo. L’unica utilità che vedo è per evitare di inviare la fattura via PEC ad un indirizzo che non può essere valido, restituendo una notifica di scarto piuttosto che una di mancata consegna. Però mi chiedo quanti casi del genere abbiano avuto (di indirizzi PEC che soddisfano la vecchia espressione regolare, ma non quella nuova).

4

Anche questo è un problema. Se si usa il nuovo file xsd per validare una fattura che segue le vecchie specifiche e usa il codice Z, il file risulterà non valido.

Mi chiedo cosa farà il SDI nel periodo in cui saranno validi entrambi i formati. Visto che la versione del formato non è cambiata, nella fattura non c’è nulla che indichi quali specifiche segue. Faranno la verifica con entrambi gli xsd?