Nelle specifiche v.1.6, sezione esterometro, paragrafo 4.2.1.2.2 sono state aggiunte le nuove Natura N2.* e N3., ma non N6.; N6 è stato tolto del tutto.
Nel file XSD dell’esterometro N6 è rimasto (senza N6.*) con nota che verrà tolto dal 1/10/2020.
Oggi in una webconference uno di AdE ha detto che è intenzionale, e che tali operazioni che prima erano N6 dovranno essere N2.1 !?!?!?!?
Qualcuno ha idee chiare in materia?
Sembra che se si mandano integrazioni via canale FE si deve usare N6.*, ma se si mandano fatture di acquisto in reverse charge via esterometro (per cui prima si usava N6) si debba usare una diversa Natura.
Sì, io parlavo dell’esterometro “Operazioni transfrontaliere”, non di FE.
Tutti eravamo in attesa delle modifiche per FE, ma, a tradimento e sottotraccia, nelle specifiche modificate per FE (cosa attesa) hanno messo modifiche per esterometro (non atteso):
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.
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.
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
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 ?
