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 ). 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.
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)
Io quando parlavo di retrocompatibilità mi riferivo alle versioni 1.2.x. Le versioni 1.0 e 1.1 usavano target namespace diversi, per cui lì basta basarsi su quelli per capire in che formato è la fattura. Lì le cose erano fatte bene…
Non capisco perché ci sia il problema di validare la fattura per mandarla in conservazione: quando mandi in conservazione un documento si presuppone che sia già stato validato quando necessario, a meno che non si voglia fare un processo alle intenzioni. Non capisco la politica (adottata anche dai conservatori purtroppo a volte…) di fare una validazione puntuale all’atto della conservazione (ad esempio sulla firma digitale), quando in realtà se proprio si vuole fare un controllo, lo si dovrebbe fare nel contesto della data di emissione del documento.
Il caso è questo, poi come tutte le cose si può risolvere ma per disegno non è stato gestito in modo robusto: mi cambiano l’xsd nel 2020 e nel 2021 e l’xsd non è completamente retrocompatibile. Ora devo estrarre delle info dalle fatture (non fatte da me) per mettere in conservazione nel 2021 quelle del 2020. Prendo l’ultimo xsd creo la classe al volo e deserializzo l’xml ovviamente questo processo va in errore se non utilizzo l’xsd corretto. E’ questo il problema. Tecnicamente dovresti utilizzare lo schemaLocation che ti dice cosa utilizzare ma non sempre è presente. Se avessero almeno utilizzato l’attributo versione con type ‘incrementale’ che indicava l’xsd in modo univoco sarebbe stato meglio di niente.
Tu hai chiesto come fare nel caso concreto, è inutile adesso fare un’ipotesi su cosa accadrebbe se… Voglio sperare che se un domani rilasceranno un nuovo schema non retrocompatibile valuteranno di cambiare il target namespace…
Poi un conto è usare l’XSD per il parsing (probabilmente perché usi tecnologie quali JAXB o simili), un conto è usarlo per la validazione. Nel primo caso, se ti fallisce la deserializzazione mediante uno schema, ne provi un altro finché non trovi quello giusto. Io faccio così per supportare tutte le versioni della specifica.
ti sei fatto un TryParse … proprio quello che volevo evitare . Cmq prima valido per evitare errori nella deserializzazione, cmq quando fai binding e cambi qualcosa nello schema non avrai la stessa istanza anche se compatibile
Oggi mi sono collegato e ho dato un’occhiata. Su 30 mila fatture ricevute ne abbiamo solo 480 senza schemaLocation.
Fermo restando che il problema di identificare la versione ce l’hai solo su quel che ricevi, e visto che lo schema è “retrocompatibile” e che il namespace non è cambiato quello che farò io è :
il binding con lo schema nuovo (questo anche per non avere due serie di classi diverse per le due versioni);
l’eventuale validazione si fa con lo schemaLocation se presente; se assente bisogna per forza assumere che tutto quel che si è ricevuto prima del giorno x è versione A, tutto quel che si è ricevuto dopo il giorno y è version B, tutto quel che si è ricevuto tra x e y (periodo in cui entrambi gli schemi sono validi) non è determinabile a meno di andare per tentativi…
infatti tutto il succo è qui … bastava utilizzare una cosa che già c’era (l’attributo versione) che nell’xsd è required e che è associato all’enumeratore FormatoTrasmissioneType ma che è anche il tipo del FormatoTrasmissione ed è lì che hanno fatto casino. Spero lo sistemino. O sdoppiano l’associazione (uno dice la versione e l’altro il tipo di fattura) o vanno cambiati i valori dell’enumeratore con le due info tipoversione (FPA121-FPR121)
Salve a tutti,
riprendo un attimo alcuni temi che erano stati in qualche modo toccati all’inizio della discussione (con l’occasione consiglio di aprirne una dedicata alla versione dell xml 1.2.1, il titolo di questa è assolutamente fuorviante).
Dopo ormai anni che è partita la fatturazione elettronica e ora che c’è un team Italia Digitale etc… ma non è possibile ricondurre il processo di creazione di nuove specifiche a qualche best practices?
Voglio dire: ma non è possibile che vengano pubblicate le versioni alpha, beta, draft chiamateleComeVolete, che vengano discusse pubblicamente prima di diventare definitive, come si fa con qualsiasi documento di nuovi standard? E che magari vengono ufficializzate in date precise, in modo da poter effettuare una pianificazione di adesione, laddove necessaria?
Perché - tranne una fase iniziale, ormai superata - trovo un controsenso che solo alcuni vendor/player del settore siano ben informati e in anticipo.
Posso capire che ci sono certi interessi commerciali, ma questo non dovrebbe riguardare documenti/specifiche/chiamateliComeVolete pubblici.
Vivere con “l’ansia” che ogni tanto escono versioni più o meno sofisticate e con scadenze più o meno ravvicinate, non è piacevole. Nè credo sia più accettabile avere versioni di fatture (fpa12, fpr12), versioni di formato xml (v.1.2, v.1.2.1), versioni di documenti di specifiche, versioni di documenti dei controlli, versioni delle notifiche… andrebbe tutto allineato, anche se non cambia nulla in alcuni documenti.
Quello che dici è corretto ma non gestibile.
Dimentichi il punto fondamentale : “noi” non valiamo nulla in merito.
Il sistema di fatturazione elettronica è gestito dall’agenzia delle entrate e dallo stato.
Loro gestiscono un servizio e non è scritto da nessuna parte che per gestire un servizio devi chiedere consiglio al distributore. (l’ENI non chiede consiglio al distributore su come lavorare il carburante ed Apple non chiede consiglio ai negozianti su come migliorare il software)
Se domani mattina si svegliano e decidono che parte il formato 1.3( incompatibile con la 1.2.1) semplicemente inizi a lavorare sul nuovo formato sapendo di non potercela fare e nel frattempo si creerà una forma di “protesta” per chiedere lo slittamento.
Non fraintendere, sarebbe bello se fosse possibile ma se l’agenzia delle entrate dovesse ascoltare i suggerimenti di tutti, non si andrebbe mai avanti.
Loro hanno i loro programmi, guardano quello che serve a loro, e organizzano per fare i loro controlli.
Poi per “gentilezza” (o per cercare di ottenere il risultato più velocemente), discutono con chi gestisce il maggior numero di fatture, in modo da trovare una soluzione che permetta loro di ottenere ciò che vogliono senza incasinare troppo tutto ed ottenere un risultato in maniera celere.
Prova www.bellacopia-fe.it è free anche l’integrazione con il tuo gestionale ed è l’unico che ti permette di stampare anche la data di ricezione dello SDI sul PDF oltre che numerare le pagine ed impaginarle correttamente.
Tutte cose che il free di assosoft non fa.
CIao
Domanda seria.
Considerando che per ENASARCO nel 2019 ricordo bene le varie alchimie e precisazioni con la riga ad hoc, gli altri dati gestionali, eccetera… adesso che si mette il tipo ritenuta specifico, bisogna ancora infilare la riga “strana” o facciamo in modo che il mondo intero comprenda che quel dato ritenuta entri al posto della riga suddetta?
Perché a me preoccupa parecchio tutta questa parte di “consuetudini”… ve ne vengono in mente altre che potrebbero essere superate dal nuovo formato?
Proprio per evitare le alchimie di cui parli, hanno previsto il codice specifico RT04 per Enasarco,
ed ancora che il blocco relativo alle ritenute, sia ripetibile.
Scusate, ma nella descrizione del controllo con codice errore 00474 manca qualcosa?
Perchè si fa riferimento al tipo documento, ma poi non viene usato nel controllo.
). 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.