timbrefiscal caracteres & en lugar de &

[bicentenario2010]

hola
pues tengo un problema con los caracteres.

el validador del sat si me reconoce
el caracter

&

lo convierte a &
para validar mi sello

pero timbrefical me dice que el error es
[com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '0' (code 48
) (expected a name start character)


por que el rfc que es del receptor es
AA&0356219E6

mi trozo de xml es asi


<cfdi:Receptor rfc="AA&0356219E6"

ustedes han tenido el mismo problema o algo ando ahaciendo mal????

gracia.s

[bicentenario2010]

he estado revisando

y el problema es el RFC

por que el nombre tambien tiene una &

Angel & Asosciados

convertido con ampersand
me da
Angel & Asosciados

y si se timbra en el sistema de priebas de timbrefiscal.
pero el problema es el RFC

saben si hayq eu envolver el RFC con un CDDATA ?

[acanas]

Ya me habia comentado DADO acerca de este horror, lo que te puedo decir es que la bronca es del PAC ya que en realidad deberia convertir de vuelta el codigo de escape & a & para poder realizar sus consultas de validación. Jaja y en soporte que te dicen? favor de poner tu petición en los canales correctos jaajajajajajajaajajaja . Otra tachita para los regios.

[acanas]

De hecho ahorita estoy haciendo pruebas con productos como un chocolate m&m y me marca que el esquema es inválido el WS de timbrefiscal, osea tengo que violar la estructura de un xml y ponerlo como & en vez de & ?

Actualización:
Hice otra prueba y el problema efectivamente radica en el RFC Receptor el cual no acepta codificación de ampersand con código de escape y el WS de timbrefiscal regresa un Response "esquema inválido".

[acanas]

he estado revisando

y el problema es el RFC

por que el nombre tambien tiene una &

Angel & Asosciados

convertido con ampersand
me da
Angel & Asosciados

y si se timbra en el sistema de priebas de timbrefiscal.
pero el problema es el RFC

saben si hayq eu envolver el RFC con un CDDATA ?

Pero envolver un nodo o el valor de un atributo en CDATA significa que el parser del WS de Timbrefiscal lo va ignorar por completo el nodo o el valor del atributo. el CDATA debe usarse como para ejemplos de scripts o datos que lleven caracteres ilegales en XML.

[acanas]

Oyes creo que ya se cual es la bronca, yo este problema lo habia arreglado en CFDV2 pero se me paso portear el arreglo a CFDV3 , lo que sucede es que estas tratando de cambiar los caracteres inválidos para xml por las respectivas secuencias de escape y al momento de generar el XML tu lenguaje o framework que usas lo hace tambien y se duplica.

Es decir si tienes un RFC como:
AI&B800545DW9 lo convierte a AI&& y pues truena la cosa. Deberias analizar con un soap sniffer la respuesta de salida de tu aplicación para que puedas ver como estas formando tu request. Te recomiendo el Http Analizer, pero también esta el wireshark y fiddler.

[condor0086]

Nop, confirmado, cheque con un RFC con "&" y está bien establecido en el XML sin duplicar y sin nada, pero Timbre Fiscal regresa:

ERROR: No fue posible timbrar:
javax.xml.bind.UnmarshalException - with linked exception: [com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '9' (code 57) (expected a name start character)
at [row,col {unknown-source}]: [1,3481]]

(El RFC inicia con: "AT&9" )

[Dado]

Nop, confirmado, cheque con un RFC con "&" y está bien establecido en el XML sin duplicar y sin nada, pero Timbre Fiscal regresa:

ERROR: No fue posible timbrar:
javax.xml.bind.UnmarshalException - with linked exception: [com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '9' (code 57) (expected a name start character)
at [row,col {unknown-source}]: [1,3481]]

(El RFC inicia con: "AT&9" )

No me habia "metido" a esta platica porque tengo entendido que mi estimado acanas programa en .NET

Pero tu mi estimado condor0086 estas usando "mis" rutinas en Delphi, por falta de tiempo (esta bien lo reconozco, tambien por un poco de decidia) no confirme si tenia este mismo problema en mi codigo Delphi, confirmame si este es el caso para que mañana muy temprano me ponga a hacer pruebas y corregirlo......

[condor0086]

Ya reporté este problema con Timbre Fiscal, pero dicen que están bien e incluso presentan una muestra de un CFDI con "&" en el RFC receptor y ya timbrado. ¿Has encontrado algo Dado?

[acanas]

Ya reporté este problema con Timbre Fiscal, pero dicen que están bien e incluso presentan una muestra de un CFDI con "&" en el RFC receptor y ya timbrado. ¿Has encontrado algo Dado?

@Condor0086:Yo pensaba que era problema del PAC y resulta que no porque yo lo pude arreglar ese problemita en mi programa dejando que el entorno en que programo hiciera los cambios al xml en caso de haber caracteres ilegales.Tengo entendido con temor a equivocarme que los que trabajan con la libreria de DADO primero generan un Request en un archivo xml y ese es el que mandan por medio de un http request al url del ws de timbrefiscal y respectivamente te responde con un response y lo graban en un response.xml o algo asi.

Bueno lo que creo es esto:
1- En el archivo Request.xml si se codifica el RFC que tiene ampersand con su respectivo codigo de escape y hasta aqui esta bien.
2.- Que pasa cuando ese xml lo manda la función de http request en Delphi o soap request? lo vuelve a convertir y se duplica???. <-- creo que aqui debe estar la bronca...
3.- En caso extremo haz una prueba con tu request.xml mediante la aplicación curl y te sacas de dudas.