menu di navigazione del network

Nuove Specifiche 1 Gennaio 2020 Versione 1.6

si si, è solo un estratto dalle regole tecniche… la riga prima riporta “N2 non soggette” :wink:

Io l’ho letto qui:
https://commercialisti.it/documents/20182/1236796/Allegato+6+-+Informativa++08-2020.pdf/2011deea-2b06-4e0f-87d7-c03bd8e2a613
Sono le slide di presentazione delle novità al Forum italiano sulla fatturazione elettronica.
Dell’attributo SistemEmittente dicono:

Per finalità di natura puramente informativo/statistica è stato previsto un nuovo attribute nello schema XSD, opzionale, che consenta di identificare il sistema attraverso il quale è stato prodotto il file XML

Quindi mi sembra di capire che uno ci può mettere più o meno quello che vuole (idealmente il nome del proprio applicativo), a meno che non sia previsto un qualche registro di questi sistemi (cosa di cui dubito, considerando che non ce n’è uno nemmeno per i canali registrati e relativi codici destinatario).

Fai attenzione che questo documento è vecchiotto…fa ancora riferimento a tipi documenti ormai “scomparsi / modificati” tipo il TD13, TD14, TD15 … ed altre imprecisioni presenti…

Io da utente finale posso solo pregare che ci sia un foglio di stile “umano” e non la schifezza illeggibile che ci tocca usare adesso quando vogliamo stampare le fatture da programmi tipo Sicoge.

Non conosco il programma che usi,
ma sappi che,
una volta scaricato il file xml della fattura,
puoi farlo transitare per qualsiasi altro programma che riesca a trasformarti il documento xml in documento pdf. Uno tra tutti, Assoinvoice di Assossoftware, che puoi usare gratuitamente.

Prova https://www.bellacopia-fe.it è free ed è anche una webapi richiamabile da programma.
Se vuoi ti do un account di test.

Grazie. Non avevo letto con attenzione il documento (uso le specifiche come riferimento), ma era l’unico posto dove compariva qualche spiegazione dell’attributo SistemaEmittente.

Vi mando anch’io un link al nuovo articolo del mio blog dove riassumo tutte le modifiche apportate dalle nuove specifiche 1.6:

Direi che i codici N6 ed N6.x vanno usati per il “reverse charge interno” (Italia <–> Italia), documenti che vanno, quindi, già inviati ad ADE con la Fatt.Ele.
Non dovrebbe mai capitare che emetti una fattura ad un cliente estero, utilizzando “N6” (ne tantomeno, che tu la possa ricevere !!! )

ma nello schema dal 4 maggio il formato di trasmissione è sempre FPA12 e FPR12. Come si fa a distinguere le fatture tra quelle con versione con xsd 1.2 e xsd 1.2.1?
Mi sarei aspettato nel formato di trasmissione dell’xsd 1.2.1 -> FPA121 e FPR121

In teoria devi guardare lo schema dichiarato nell’xml della fattura. Per questo anche io chiedevo se c’e’ ufficialità sugli url esatti da usare.

Nelle vecchie fatture guardavo l’attributo ‘versione’ nel tag ‘FatturaElettronica’: versione = ‘1.0’ , versione ='1.1, versione=‘FPA12’, versione=‘FPR12’. Nel nuovo schema (https://www.fatturapa.gov.it/export/fatturazione/sdi/fatturapa/v1.3/Schema_del_file_xml_FatturaPA_versione_1.2.1.xsd) è rimasto ‘FPA12’ e ‘FPR12’ e quindi la versione sarà ancora ‘FPA12’ o ‘FPR12’ ?

<xs:attribute name="versione" type="FormatoTrasmissioneType" use="required" />

Rileggiti la discussione qualche messaggio più indietro riguardo quanto si diceva sulla confusione che hanno fatto con le versioni.
La soluzione al “problema” può essere di questo tipo:

  • quando “ricevi” o “crei” una nuova fattura, ti salvi la versione della specifica in uso e successivamente usi sempre quella per fare il parsing o la scrittura dell’XML corrispondente a quella specifica fattura
  • dal 4 maggio, ogni nuova fattura che devi interpretare (ricevuta o da creare), se rientra nell’ambito della versione “1.2.x”, la interpreti come se fosse nel nuovo formato, che è retrocompatibile col vecchio, per cui se anche quella fattura in realtà fosse più vecchia (e dunque creata in origine con l’intenzione di essere conforme al formato precedente) dovresti comunque poterla interpretare ed elaborare correttamente, come se fosse nel “formato nuovo”

Già questo si doveva fare per “distinguere” tra i formati 1.2, 1.2.1 e 1.2.1 con le modifiche del 2018, questo in realtà è una sorta di “1.3”.

visto che non è ancora in vigore spero che cambino il FormatoTrasmissioneType.
altrimenti che senso ha mettere gli xsd. Io non parso gli xml ma li costruisco/valido con gli xsd. se devo elaborare fatture passate non mie cosa faccio guardo la data ? O testo gli schemi ? Ma non possono correggere sta cosa ?? Sono costretto a leggerlo nello schemaLocation ?

Secondo me va chiaramente letto dallo schema quindi guardando l’attributo schemaLocation… anche perchè lo schema dice di fatto qual’ è la versione dei tag dell’xml.

In altre parole, un valore di un attributo dentro l’xml come FormatoTrasmissioneType è una versione “applicativa” che riguarda non tanto la struttura dell’xml quanto quello che è rappresentato dall’xml stesso.
Invece lo schema riguarda la struttura dell’xml, quindi per esempio la possibilità di non inserire il valore del bollo ecc…; in questo senso è corretto che sia cambiato lo schema.

Tra l’altro se si usano librerie di parsing XML che trasformano un file XML in una struttura dati (io per esempio uso JAXB), è proprio lo schema che “comanda”.

cmq io stavo parlando dell’attributo versione (nel primo nodo dell’xml dopo la declaration xml) che è obbligatorio e che nel tempo ha avuto diversi ‘type’ ma era sempre definito (nell’ultimo schema è definito con il type FormatoTrasmissioneType). Non sto parlando di quello all’interno dell’xml (FormatoTrasmissione). Leggerlo dallo schema location ok ma non sempre c’è e in pratica il tool non ha l’indicazione con cosa validarlo … per quello che mi agganciavo a qualcosa anche di ‘non standard’ ma che era già presente

Si scusa intendevo anche io quel ‘versione’ (non ho sottomano fatture siamo chiusi per virus :upside_down_face: ). Ma dici che lo schemaLocation non c’e’ sempre ? Se quello non c’e’ sempre (avrei pensato che fosse obbligatorio) bisognerà guardare il nome del namespace e questo si sicuramente è obbligatorio… pero’ guardando i link che avevo postato qui sopra tempo fa, quello non l’hanno cambiato! Quindi non è usabile per determinare la versione, a meno che non sia una svista che correggeranno.

Se dovrai elaborare fatture passate, come ti ho detto, potrai usare lo schema nuovo, che è retrocompatibile. Ovviamente ciò ti consentirà di controllare la validità della fattura sulla base delle regole vigenti in quel momento e non di quelle necessariamente in vigore quando la fattura è stata fatta. Ma tutto dipende dal flusso di lavoro. Se stai elaborando una fattura passata che “già conoscevi”, la strada più semplice è che tu ti sia salvato da qualche parte qual era lo schema usato quando l’hai “scoperta” e continuare ad usare quello anche successivamente. Poi dipende anche da cosa intendi per “elaborare”, perché se lo scopo è spedirla nuovamente a SdI, allora è chiaro che dovrai usare comunque lo schema nuovo, anche se la fattura è “vecchia”.

Purtroppo, come già dibattuto precedentemente, stanno gestendo malissimo il versioning delle specifiche.

In questo caso è il target namespace che comanda, non lo schemaLocation. Ed il namespace comunque l’hanno mantenuto uguale per tutte le revisioni 1.2.x, cioè http://ivaservizi.agenziaentrate.gov.it/docs/xsd/fatture/v1.2

Quindi anche il binding con JAXB può essere problematico, io ad esempio mi sono fatto degli schemi “merge” per gestire tutti i casi in fase di parsing e poi applico regole di validazione distinte a seconda della versione per cui intendo validare.

@mauromol : beh non direi retrocompatibile prendi ad esempio FormatoTrasmissioneType. Questo type è diverso nell’xsd della versione 1.1 e della versione 1.2. Se valido una fattura fatta con 1.1 (ovviamente non da me e che quindi non conosco) con l’ultimo xsd darebbe errore. (cmq non per inviarla ad sdi ma ad esempio mettendola in conservazione in differita)