ValidaCFD

Hola, antes que nada un saludo a todos, este es mi primer respuesta!

Acabo de comunicarme al SAT en el centro de atención telefónica y efectivamente confirmaron que es problema de ellos, me dicen que estan trabajando en la correccion y que lo este monitoreando hasta ver que funcione con un CFD que haya validado anteriormente.

Ya nos estabamos preocupando pero esperaremos sin agregar el BOM hasta recibir informacion oficial o ver si el SAT cambia su posicion.

De cualquier manera estaremos buscando alguna solucion, lo que comenta Dado arriba funciona bien con nosotros.

Gracias y saludos!

Teneis razon amigos esos tipos del SAT son de lo mas torpes e ineptos. He estado todo el dia investigando lo del famoso BOM (Marca de Orden de Bytes) y en el mismisimo sitio del W3C (http://www.w3.org/International/questio ... ark.es.php), dicen lo siguiente:

“Al principio de un archivo Unicode se pueden encontrar algunos bytes que representan el punto de codificación Unicode U+FEFF SIN ANCHO NI ESPACIO (ZERO WIDTH NON-BREAKING SPACE, ZWNBSP). Esta combinación de bytes se conoce como una marca de orden de bytes (BOM)…
...La marca de orden de bytes indica qué orden se usa, para que las aplicaciones puedan decodificar inmediatamente el contenido. El contenido de UTF-16 siempre debería comenzar con la BOM.
En la codificación de UTF-8, la presencia de BOM no es esencial, porque a diferencia de las codificaciones de UTF-16, no existe una secuencia alternativa de bytes en un carácter…”

O sea, para UTF-16 es obligatorio, para UTF-8 no.

He encontrado la misma referencia en varios sitios mas:

"The Byte-Order-Mark (or BOM), is a special marker added at the very beginning of an Unicode file encoded in UTF-8, UTF-16 or UTF-32. It is used to indicate whether the file uses the big-endian or little-endian byte order. The BOM is mandatory for UTF-16 and UTF-32, but it is optional for UTF-8."

Solo nos hacen perder el tiempo esos inutiles del SAT (y apanicarnos como bien comentan). Asi que no modifiquen sus aplicaciones, hasta que corrijan su "error" estos tipos .

Saludos.

En el caso que el SAT insiste de dejarlo asi, no es tan muy dificil de cumplir.
Lo probé con la rutina abajo, que me convierte el XML a otro XML y este si validó perfectamente en el SAT.
Solo Tomo el archivo original como un archivo de bytes (igual el de salida). Antes de escribir los datos del archivo original solo insert el BOM (EF BB BF)
El resto no mas se copea igual (ni si quiera vi lo del DTD, a la mejor el SAT lo pone despues).

procedure Convert$%#$SAT(infile, outfile: string);
var f, outfile: file of byte;
s: string ;
c: byte;
h: integer;
begin
assignfile(f,infile); {abrir el XML original}
assignfile(outfile, outfile); {escribir un XML nuevo}
reset(f);
rewrite(outfile);
c:= 239; write(outfile, c); {insertar EF}
c:= 187; write(outfile, c); {insertar BB}
c:= 191; write(outfile, c); {insertar BF}
while not eof(f) do
begin
read(f,c); {leer archivo original}
s:=s+IntToHex(c, 2)+' ';
write(outfile, c); {escribir lo mismo en el nuevo}
end;
closefile(f);
closefile(outfile);
end;

claro hay que reemplazar el "$%#$" por otra cosa

Convert$%#$SAT je je je

Claro, no es que sea dificil, "son solo 3 bytes", el problema es que apenas nos estamos acostumbrando los programadores y EDUCANDO A NUESTROS CLIENTES acerca de la factura electronica y de repente nos cambian la jugada.

Imaginate que acabas de cobrar el flamante cheque por $25,000 de un sistema de facturacion hecho a la medida y que tu cliente te llame...."oye, cuando me lo instalaste estaba perfecto, pero hoy valide las facturas Y NI UNA SOLA MUGRE FACTURA PASA EN EL VALIDADOR DEL SAT" no puedes explicarle acerca del BOM!

Yo desarrolle un validador y creeme que he sufrido con una decena de cambios repentinos, desde los mas visibles como el MD5 a SHA1 asi como algunos pocos conocidos como la derogacion del complemento "por cuenta de terceros"

Cada "Resolucion Miscelanea" es un dolor de cabeza, ponen y quitan condiciones que parecen de caprichosos, como la ultima que dice que "si no envias tu reporte de folios mensual durante 3 meses consecutivos estas obligado a cambiar a CFDI"

QUE YA ESTABLEZCAN BIEN LAS REGLAS DEL CFD ES TODO LO QUE PEDIMOS!!!

Hola a todos este es mi primer post. Para empezar debo decir que este foro ha sido de mucha utilidad para mi como programador porque me ha ayudado a hacer mi implementación del cfdi mejor de lo que hubiera podido hacerlo sin la valiosa información en este foro. Mi implementación esta hecha en .net y el bom es manejado de forma automática por .net yo ni siquiera sabía del mentado BOM hasta que el sábado anterior en el cual ví este nuevo post y revisé con un editor hexadecimal los archivos que genera mi implementación del cfd y cfdi.

Yo soy de los que pienso que el SAT le va a valer un cuerno nuestros reclamos y vamos a terminar agregando el BOM en cada archivo XML

Saludos

Y ahora, también la addendas están dando errores, en algunas hay que duplicar la declaración del name space pero en otras ni así funciona, veremos que más se les ocurre...

Por cierto, aquí pueden ver una forma de agregar el ahora famoso BOM con perl: http://cofradia.org/2011/07/11/castrosi ... sitas-bom/

Saludos a todos

DADO escribió:AVISO : Me han preguntado si en el ValidaCFD voy a validar el que lleve el BOM, para que sea mas "apegado" al validador *oficial*......

Tengo un dilema.......no se si ponerlo.......hay mas de UN BILLON Y MEDIO de comprobantes que AUTOMATICAMENTE SERIAN INVALIDOS.

Asi que esta decision no es para tomarse a la ligera, los del SAT deben reaccionar a esta condicion, voy a esperar un tiempo prudente para ver si esta decision permanece o la corrigen.

Por otro lado mi experiencia me dice que si aplico esta validacion MAS DEL 90% ME VA A RECLAMAR al igual que los que han publicado sus inquietudes PERO LO PEOR ES QUE NO TENGO FUNDAMENTO LEGAL para decirles que debe llevar el BOM, NO HAY EN TODA LA LITERATURA que ha publicado el SAT que diga que debe llevar este dato, es solo un requisito tecnico implicito de la tecnologia XML y eso es dificil explicarle al contribuyente comun.

Se imaginan, que tenga que decirles, "mira debe llevar el BOM porque el consorcio W3 asi lo define"......"el consorcio de que???"

Escucho (o mas bien leo) sus opiniones al respecto.........le seguimos el juego al SAT?

Yo pienso que con sólo que lo pongas como warning hasta q se aclaren las cosas bien.

Por cierto este error sólo está saliendo en CFDs?, en CFDIs no ?

Solo en CFD's en CFDI no hay problema (por ahora...)

Buenas tardes a todos , lo mejor que debemos hacer es poner el BOM ya que aunque no es un requisito obligatorio para UTF-8 no afecta para ningun proceso del XML , mejor aun agregarlo tambien en CFDI's por aquello de las malditas dudas con el SAT , ya verifique si agregar este BOM en CFDI podria traerme problemas con el PAC y no es asi, al menos con el PAC "Solucion Factible" funciona de igual manera con el BOM que sin el.

Dudas, aclaraciones y ventas amigo_secreto71@hotmail.com

WIWI

Gracias.