Simbolo £ in Codice Articolo

Fatturazione Elettronica
1

Buongiorno a tutti,
ho inserito il codice articolo interno nelle righe della fattura utilizzando il campo 2.2.1.3.2 definito nel foglio di stile come “String35Type”. Ho verificato che i codici articolo con il simbolo £ danno origine all’errore 00200 es: “The value ‘2153Q£204’ of element ‘CodiceValore’ is not valid”.
Esiste un modo per specificare in modo corretto il valore di questo codice con il carattere £?
Ho provato con la sua rappresentazione £ ma l’elemento viene scartato in modo analogo.
Grazie per un vostro aiuto.

2

Mi rispondo da solo: la stringa è “definita” come “IsBasicLatin” e quindi sono ammessi solo i primi 128 caratteri. Sostituisco “£” con un “?”.

3

Quello è cio che faccio ad esempio con i dati sul circuito interbancario nelle causali dato che anche li ci sono delle restrizioni (io uso * che fa comunque parte del basiclatin). Chiaro che poi il cliente leggendo la fattura elettronica poi non capisce più nulla…
(da cui la necessità dell’allegato di dettaglio…)

4

Io ho fatto una conversione in ASCII, ed appunto anche a me lo converte in “?”.
Ho poi modificato la maschera della anagrafica articoli impedendo all’operatore di mettere caratteri non ASCII.

5

Certo che in un mondo UTF8 e pensando ad una fatturazione elettronica europea ci si rende conto quanto le specifiche siano lungimiranti…:disappointed_relieved::disappointed_relieved::disappointed_relieved:

6

Ciao,
basta convertire quei caratteri in entità HTML.
anche il simbolo dell’euro (€) dà problemi , ma se lo si converte in entità HTML, ovvero € , viene regolarmente accettato.

Ciao

1 Mi Piace
7

ah si?
Tutti quelli che conosco hanno filtrato via i caratteri!! Non sapevo che questa era la soluzione!
Sicuro che funziona? C’è qualche riprova?

Grazie

8

A me veniva scartata la fattura per la presenza del simbolo € e non avevo gestito questa situazione nel mio script.
Provando con il solito strumento di verifica (https://sdi.fatturapa.gov.it/SdI2FatturaPAWeb/AccediAlServizioAction.do?pagina=controlla_fattura) mi confermava la presenza di errori.
Effettuata la variazione e testato con il tool di cui sopra il responso è stato positivo quindi mi sento di dirti che questa soluzione è corretta.
Qualcuno ha avuto il mio stesso riscontro?

9

Accettato da chi?
Hai usato € oppure €?

Ho provato entrambe le varianti con il controllo online delle fatture e le rifiuta entrambe. La prima perché l’entità non è valida nei file xml (a meno che non sia specificato nel file DTD), la seconda perché equivalente a un carattere non ammesso dal xsd.

10

Considerate valide dal tool che ho citato sopra, con il carattere € veniva scartato, con € viene accettato!
C’è da dire che tutti i campi descrittivi li inserisco come CDATA in questo modo:

<DettaglioLinee>
	<NumeroLinea>02</NumeroLinea>
	<Descrizione><![CDATA[rimborso n.2 marche da bollo da &euro;.16]]></Descrizione>
	<PrezzoUnitario>32.00</PrezzoUnitario>
	<PrezzoTotale>32.00</PrezzoTotale>
	<AliquotaIVA>0.00</AliquotaIVA>					
	<Natura>N1</Natura>
</DettaglioLinee>

Al momento sembra tutto funzioni correttamente.

11

Usando CDATA, il contenuto non viene interpretato come xml o html. Il problema così lo sposti su chi la fattura la riceve. Se il software che riceve la fattura non sa che deve interpretare un particolare campo come html (e nelle specifiche non c’è scritto) non visualizzerà il simbolo dell’euro ma l’entità per esteso. A parte quelli che schiaffano il contenuto del campo così com’è sulla pagina web (il cui software io non userei, perché è sicuramente pieno di vulnerabilità).

Hai provato a usare l’XSLT per convertirla in HTML? Hai provato a convertirla in PDF sul sito dell’agenzia delle entrate? A me in entrambi i casi viene un bel “&euro;” per esteso.

1 Mi Piace
12

Ho optato per questa soluzione avendo ricevuto a mia volta documenti che lo contenevano.
Vista la penuria di informazioni ufficiali e il livello di supporto fornito da ADE e da Sogei l’ho ritenuta una soluzione valida.
Il validatore ha fatto passare il file e tanto mi è bastato per considerate la soluzione utilizzabile.
Diciamo che tra il non ricevere un carattere e ricevere un’entità HTML forse è meglio la seconda, ma questa è ovviamente un opinione personale.
In altri casi mi sono stati recapitati files con caratteri “assurdi”: i files erano condificati in UTF-8 e penso abbiano tentato qualche conversione nel classico 8859-1 o windows-1250, ma direi che il risultato è addirittura peggiore.
Non mi risultano linee guida precise, se hai documentazione ti chiedo gentilmente di condividerla,
grazie

13

Non ce ne sono perché semplicemente certi caratteri non sono previsti. Secondo me è una mancanza da parte dell’AdE. Avrebbero dovuto consentire l’inserimento quanto meno di tutti i caratteri utilizzati nelle lingue europee. Mi chiedo come fa Ikea con i nomi degli articoli in svedese :grin:

La soluzione da te adottata ti permette di far accettare la fattura dal SDI, ma chi la riceve non sa come interpretarla e nella maggior parte dei casi l’entità verrà visualizzata così com’è per esteso. Tanto valeva metterci “(Euro)” o “[Euro]”, più facile da interpretare da parte di chi legge.

14

Anche quella di rimappare arbitrariamente era un’ipotesi:

  • “€” -> EUR
  • “>” -> maggiore di
    …
    ma l’ho scartata perché non mi sembrava valida per tutte le casistiche.
    Boh, personalmente l’unico cruccio è che la mia soluzione divenga “deprecata” dall’ADE con conseguente scarto dei files.
    In questo caso OVVIAMENTE lo scoprirei sul campo viste le strabilianti doti di comunicazione esibite fino ad ora. :frowning:
    Cercherò ti tenere le orecchie dritte per anticipare eventuali cambiamenti e speriamo bene!
15

Per quanto riguarda maggiore e minore, fanno parte del set di caratteri ASCII quindi si possono usare. L’unica accortezza è di usare le entità &gt; e &lt; (che fanno parte dello standard XML), ma questo di norma lo fanno automaticamente le librerie per la gestione dei file XML.

16

ma riportare :

Descrizione : Rimborso marca da bollo
Quantità: 2
Prezzo unitario : 16.00
Prezzo Totale: 32

Era tanto brutto?

comunque un problema simile lo si ha con il carattere °
anche se convertito in HTML riportando °, il SDI risponde che & non è un carattere valido.

17

In quale campo hai avuto problemi?
Il carattere ° fa parte del blocco latin-1 (codice Unicode 00BA) ed è ammesso nella maggior parte dei campi descrittivi della fattura elettronica (tutti quelli il cui tipo nel xsd è uno dei vari StringXXLatinType).

18

premesso che non l’ho “generato” io (o meglio un utente che usa il mio software) ma l’ho ricevuto : non è comunque una soluzione “accettabile”.
Pensa all’esempio citato da vbato: l’ikea come dannazione fa a vendere un articolo? avessero un nome che non riporti un carattere non ASCII standard! :rofl:
speriamo migliorino il tracciato o quanto meno diano indicazioni precise!