ValidaCFD

Me he topado con este caso

El RFC del cliente tiene un amperson. Incluso en el nombre
Esta es parte de la cadena original . OJO, se ve con otro simbolo pero es Amperson

|G&L020822MF6|GROUNDING & LIGHTNING, S.A. DE C.V.|

En el xml está asi,

<Receptor rfc="G&L020822MF6" nombre="GROUNDING & LIGHTNING, S.A. DE C.V.">

Al subir el xml al validador del SAT, obtengo el resultado

Se presentaron errores al leer el comprobante E:\Pruebas\CAM9008281U8-A5.xml
Error:The reference to entity "L020822MF6" must end with the ';' delimiter.


y todo por el Amperson
¿Alguien ya se encontró en ésta situación?

Este error es muy comun, en el anexo 20 esta muy claro, tienes qeu trabajar con ese estandar, aqui como hacerlo...

¦ En el caso del & se deberá usar la secuencia &
¦ En el caso del “ se deberá usar la secuencia "
¦ En el caso del < se deberá usar la secuencia <
¦ En el caso del > se deberá usar la secuencia >
¦ En el caso del „ se deberá usar la secuencia &apos;

Te recomiend leer bien este anexo20

Saludos.

Yo tengo duda por ejemplo en el caso del amperson se debe usar &

En el xml y en la cadena?

airam escribió:Yo tengo duda por ejemplo en el caso del amperson se debe usar &

En el xml y en la cadena?

No, en la cadena no debes usar & eso solo es una codificacion para el XML

bueno ai si difero dado porque si al momento de armar lacadena no es la misma obviamente salta un error que no es valido por parte del sat y otro por parte tusha asi que pues yo creo que si va tal cual se convierte ya que ni validacfd ni el sat lo validan como bueno.

este problema pues creo ke me pasa ja ja ja el detalle es elegir entre dejar el ampersand o no en el rfc sin la tal & ya que pues segun el xsd es de 13 caracteres matzimo y con ello sobrepasa pero en fin eso aparece en tu validador, el sat ni pio dice ya ke dice ke es valido, ke porkeria de cosas hace el sat con esto

<xs:minLength value="12"/>
<xs:maxLength value="13"/>
y si tuviera ampresand SAT?? ke pp?

validacfd si omito el ampersand en la cadena orginal pues por obvias razones no es el mismo sello, y tu mismo lo dices o si lo ves por estética en el mismo CFD impreso ahi si podrias quitarlo y ya pero? seria una falsificacion del CFD?

en fin, toe loko ia con esto

la secuencia "&" es la REPRESENTACIÓN del símbolo "&" dentro del XML, eso es todo, para cualquier otra cosa (incluyendo la cadena original) DEBES UTILIZAR EL CARACTER "&", no su representación que es exclusiva para dentro del XML.

Cualquier lector correcto de XML al leer "&" te dará simplemente el símbolo "&", que es lo correcto. La razón de esta sustitución es precisamente para permitir almacenar dentro de un XML algunos símbolos que utiliza el propio XML para su formato y que de otra forma tendrían que estar restringidos y no podrían utilizarse, "<", ">", "&".

Esa es mi duda a lo cual aun así sigo sin entender eso del amperson en el RFC ya que pues el validador del sat no checa correctamente el xml, el tuyo si pero aún así en una parte del foro dices que no debe aparecer en la cadena original, al generar el sello con validacfd me lo pone en la cadena original!!, no entiendo eso y sé que & = &. Ahora viendolo hexadecimalmente pues se vé igual el xml a menos que fuese html como lo manejas en html en validacfd.

ioriyagami escribió:Esa es mi duda a lo cual aun así sigo sin entender eso del amperson en el RFC ya que pues el validador del sat no checa correctamente el xml, el tuyo si pero aún así en una parte del foro dices que no debe aparecer en la cadena original, al generar el sello con validacfd me lo pone en la cadena original!!, no entiendo eso y sé que & = &. Ahora viendolo hexadecimalmente pues se vé igual el xml a menos que fuese html como lo manejas en html en validacfd.

Todo resulta por lo siguiente, tu sabes que el caracter < y el caracter > tienen significados muy especiales en HTML y XML, son el principio y fin de los tags.

pero si por ejemplo quieres poner "una cadena como esta con un signo < aqui adentro" entonces ese "<" tiene que codificarse para no confundirlo.

La codificacion para el < es precisamente &lt (es "lt" por "less than" menor que), como ves usan el ampersand & para indicar que lo que sigue es un codigo y debe convertirse de &lt a <

Pero ahora esta el dilema, todo lo que esta a continuacion de ampersand & es interpretado como un codigo, asi que si quieres un ampersand en tu codigo pues debes echar todo el &

Ahora, porque no aparece en la Cadena Original? por que esa codificacion SOLO AFECTA HTML Y XML, para la cadena original no le importa si le metes un < o un > o un & ya que no representa nada ahi.

Y si, es un lio entre "codigos HTML" y el UTF-8 de la cadena original

Ahora, aun cuando DENTRO del HTML/XML se vea como &amp o &lt al extraer la informacion se debe convertir o parsear a su correspondiente caracter.

Ahora, porque no aparece en la Cadena Original? por que esa codificacion SOLO AFECTA HTML Y XML, para la cadena original no le importa si le metes un < o un > o un & ya que no representa nada ahi.

Y si, es un lio entre "codigos HTML" y el UTF-8 de la cadena original

DADO escribió:Todo resulta por lo siguiente, tu sabes que el caracter < y el caracter > tienen significados muy especiales en HTML y XML, son el principio y fin de los tags.

pero si por ejemplo quieres poner "una cadena como esta con un signo < aqui adentro" entonces ese "<" tiene que codificarse para no confundirlo.

La codificacion para el < es precisamente &lt (es "lt" por "less than" menor que), como ves usan el ampersand & para indicar que lo que sigue es un codigo y debe convertirse de &lt a <

Pero ahora esta el dilema, todo lo que esta a continuacion de ampersand & es interpretado como un codigo, asi que si quieres un ampersand en tu codigo pues debes echar todo el &

Ahora, porque no aparece en la Cadena Original? por que esa codificacion SOLO AFECTA HTML Y XML, para la cadena original no le importa si le metes un < o un > o un & ya que no representa nada ahi.

Y si, es un lio entre "codigos HTML" y el UTF-8 de la cadena original

Ok, bueno mi problema es que codifico como en el anexo 20 a & para el xml y demas caracteres especiales, asi que por ejemplo así aparecería en mi XML y pues por obvias razones cuando se lee para obtener la cadena original tienque que ser lo mismo sino el sello es inválido es a lo que me refiero en sí, ahora en esta cuestion si omito eso en la cadena original para generar el sello me salé que es inválido (pues por que no coincide la cadena).

Este pues saldria bien porque coinciden
<Receptor rfc="G&L020822MF6" nombre="GROUNDING & LIGHTNING, S.A. DE C.V.">
||.....|G&L020822MF6|GROUNDING & LIGHTNING, S.A. DE C.V.|...||

igual aquí sale bien
<Receptor rfc="G&L020822MF6" nombre="GROUNDING & LIGHTNING, S.A. DE C.V.">
||.....|G&L020822MF6|GROUNDING & LIGHTNING, S.A. DE C.V.|...||

Aquí ya no sale bien porque en el xml es diferente si la cadena original se omite &
<Receptor rfc="G&L020822MF6" nombre="GROUNDING & LIGHTNING, S.A. DE C.V.">
||.....|G&L020822MF6|GROUNDING & LIGHTNING, S.A. DE C.V.|...||

Ahora, debo manejar & o solo & para RFC??, u omitir en la cadena original del pdf el & o cual sería la recomendación o estoy haciendo mal??.

El caracter "&" sólo queda como "&" dentro del XML, en la cadena original queda simplemente como "&", es la forma correcta de manejarlo y está totalmente confirmado con el validador del SAT o el de Dado o el que gustes, no hay ningún conflicto con esta situación.

Si tu pones "&" en el RFC (o en cualquier otro campo) directamente en tu cadena original esta mal.