Uso del Caracter Ø (utilizado para representar diámetro)

[jassivg]

Buenas Tardes,

Ojalá puedan ayudarme

Hoy he tenido un problema con un CFDI, se generó y se timbró correctamente, la cuestión es que al querer abrir el xml, resulta que marca error por un caractér inválido, es el símbolo Ø (diámetro),

Al verificar la validez de la factura en el SAT, se vé perfectamente, me aparecen todos los datos de la factura, sin embargo, al validar la estructura marca el error de que el xml no puede ser leído. El programa validacfd marca el mismo error de que el xml no puede ser leído.

Para hacer pruebas le quité el símbolo de Ø y ya se puede abrir con el explorer, el valida cfd lo lee, pero obviamente dice que el sello esta equivocado, pues le quité un caracter.

La pregunta es que caracteres no deben utilizarse? para poder validar en la captura?

De antemano Gracias,

Saludos

[Dado]

Buenas Tardes,

Ojalá puedan ayudarme

Hoy he tenido un problema con un CFDI, se generó y se timbró correctamente, la cuestión es que al querer abrir el xml, resulta que marca error por un caractér inválido, es el símbolo Ø (diámetro),

Al verificar la validez de la factura en el SAT, se vé perfectamente, me aparecen todos los datos de la factura, sin embargo, al validar la estructura marca el error de que el xml no puede ser leído. El programa validacfd marca el mismo error de que el xml no puede ser leído.

Para hacer pruebas le quité el símbolo de Ø y ya se puede abrir con el explorer, el valida cfd lo lee, pero obviamente dice que el sello esta equivocado, pues le quité un caracter.

La pregunta es que caracteres no deben utilizarse? para poder validar en la captura?

De antemano Gracias,

Saludos

Pues tecnicamente, debido a que la factura esta basada en UTF-8 eso significa que puedes usar CUALQUIER CARACTER UNICODE, incluyendo Coreano, Chino y Japones.....y no es broma o sarcasmo.

Aqui mas bien es considerar dos asuntos importantes :

1. Que dicho signo exista en unicode y que este bien codificado en UTF-8
2. Que las aplicaciones (incluyendo mi ValidaCFD) sean capaces de interpretar CUALQUIER UTF-8 que le presentes, cosa que no siempre pasa.

Asi que en resumen, tecnicamente esta permitido, solo hay que ver que si se codifique y decodifique correctamente

[jassivg]

Gracias por tu pronta respuesta, creo saber por donde va el problema, mas no se cómo solucionarlo,

Ya logré abrir el archivo xml que genera el sistema con el Chrome, marcaba error porque estaba configurado para abrir archivos con la codificación UTF-8, le cambié a automática y ya se abrió, y al ver las propiedades del archivo me dice que está en ISO 8859-1, y ese caracter tiene diferentes valores en las 2 tablas.

La pregunta, como hago desde delphi para que el archivo que se graba se codifique en utf-8 y no en iso 8859-1

Esta es la forma en la que grabo el XML:

CFD.SaveToFile(qry_pathPATH.AsString+CFD.Datos.Emisor.Rfc+' '+CFD.Datos.Serie+'-'+CFD.Datos.Folio+'.xml');

De antemano y nuevamente Gracias,

Saludos

[Dado]

Mmmmh, pero no lo abras en Chrome, o el explorer, esos va a tratar de interpretar el caracter y vas a caer en el supuesto del numero 2 (que los sistemas sean capaces de interpretarlo)

Abrelo con un editor hexadecimal, con ese vas a poder ver a ciencia cierta si esta bien codificado porque se debe llevar dos bytes y NINGUNO de ellos se va a mostrar como Ø

Con el Hex Editor ves las tripas y te aseguras que si este bien codificado.

Que mira, la ultima conclusion va a ser, aunque este bien codificado ya pudiste comprobar que no cualquier sistema (ya sea validador, o un ERP o un explorador) lo va a poder reconocer y lo mejor talvez sea........no usar simbolos complicados o poco usuales.

[mauricio]

Me dio curiosidad tu caso... tal como dice mi amigo Dado, si el XML esta en UTF-8, puedes meter "casi" cualquier cosa en cualquier lenguaje...

Te anexo una prueba con mi sistema para que veas el código de este símbolo, se genera y se ve correctamente, por lo que solo tienes que asegurarte de que sea UTF-8, lo siento, no programo en Delphi para ayudarte...

Factura.7z

(78.17 KiB) Descargado 295 veces

Saludos

[Dado]

@Mauricio

Vaya, mira que curioso, tu archivo NO CUMPLE con la regla no.1 ("que este bien codificado en UTF-8") y aun asi todo funciona correctamente.

Mira, esto es lo que se ve con el editor hexadecimal (ya habia mencionado lo importante de ver *exactamente* como esta el archivo y no solo la representacion visual mentirosa de los visores)

estado="México, D.F." ESTO NO ES UTF-8, esto es codificacion XML

descripcion="Simbolos @ Ø" mismo caso, no es UTF-8, es codificacion XML

La representacion UTF-8 de la "é" acentuada son DOS BYTES hexadecimales y son #C9 #A9

La representacion XML de la "é" acentuada es mediante el codigo ASCII y se representa con SEIS BYTES (uno por cada caracter siguiente) y son é (esto es, el caracter ascii numero 233)

ves la diferencia?

[mauricio]

Hola Dado...

Que raro, varios de mis editores, te muestro uno, me indican claramente que es UTF-8...

pantalla.png (102.13 KiB) Visto 8999 veces

De todos modos, me apego a esto del Anexo 20:

Adicionalmente a las reglas de estructura planteadas dentro del presente estándar, el contribuyente que opte por este mecanismo de generación de comprobantes deberá sujetarse tanto a las disposiciones fiscales vigentes, como a los lineamientos técnicos de forma y sintaxis para la generación de archivos XML especificados por el consorcio w3, establecidos en www.w3.org.

Y, en el estándar XML del w3 podemos ver el uso de esto.

De todos modos, como siempre, agradezco tu consejo, paso a revisar a detalle y te comento.

Un abrazo

[Dado]

Permiteme insistirte, revisalo con un EDITOR HEXADECIMAL

[RickAlanis]

Espero que no sea muy tarde mi intervención.

No sé si éste sea tu caso, pero a mi me causó dolores de cabeza por los últimos 2 o 3 meses y no con XML, sino con un archivo llamado de "dispersión", o sea un archivo texto formado en UTF-8 y que contiene la información para el pago de nómina de los empleados de un cliente, requerido por el banco para facilitar depósitos a su cuenta de nómina. Para el pago de cada semana, mi sistema genera 4 archivos de éstos, para dos empresas y para empleados administrativos y sindicalizados.

Me reportaba el cliente que el banco le reportaba errores en los archivos, pero eran por completo aleatorios. A veces todos los archivos marcaban error, a veces era sólo uno, a veces sólo los de una empresa. Revisábamos cada archivo y no encontrábamos ningún problema, aunque no podíamos probarlos con el sistema de producción del banco de nuevo.

Finalmente el usuario que hacía la generación de los archivos y luego los subía al portal del banco fue quien directamente habló conmigo y me envió los mismos archivos que él envió al banco y los que el banco le regresó corregidos (3 de los 4). Abrí uno de los archivos "malos" el que estaba bien y me encontré con 3 caracteres al inicio del archivo "malo": #EF #BB y #BF como primeros caracteres.

Y recordé que, mientras iniciaba con factura electrónica, consulté mucho este foro el año pasado y, aunque no recuerdo en dónde lo leí, se comentó que antes de timbrar cierto CFDi había que hacerle un pequeño cambio y que, si se abría en NotePad, había que quitarle los 3 primeros caracteres, agregados por NotePad quién sabe por qué, pero que no corresponden a UTF-8.

Resulta que el usuario que generaba los archivos de dispersión, los abría con el NotePad y, curiosamente, ¡Los guardaba! Pero eso no era siempre, sólo era cuando tenía duda de haberle puesto el nombre correcto al archivo. El usuario es obsesivo compulsivo y este padecimiento lo obligaba a verificar de más las cosas.

Se le prohibió abrir los archivos y ¡Sanseacabó!, ya no hemos tenido reporte de errores en el banco.

Bajé el ejemplo de factura que envías y, como dice DADO, lo abrí en un editor hexadecimal y, efectivamente, tu archivo inicia con esos 3 caracteres.

Y por el caso de la "e" acentuada que es transformada como "é" no debe haber problemas, porque es perfectamente correcto en UTF-8 aunque no signifique para esta codificación nada, cuando se interpreta el XML, el interpretador lo cambia por una "é".

¿Será éste el mismo caso para ti?

Saludos y perdón por tanto rollo, pero a veces es necesario para que quede la anécdota en la memoria.

[jassivg]

Antes que nada muchas Gracias a todos los que dedicaron tiempo a apoyarme con la solución de mi problema, sus comentarios fueron muy útiles, y me sirvieron para encontrar el problema, utilice un visor hexadecimal, tal y como lo propusieron, y el último comentario de que el archivo se podría estar modificando después de generado, fue lo que me llevó a la solución.

A continuación la solución para que a quienes se les presente el mismo problema ó algo similar, puedan tomar como referencia:

El CFD.SaveToFile('archivo.xml'); funciona correctamente graba el archivo con codificación UTF-8

Sin embargo, mi problema era al grabar el xml en mi tabla, ya que utilizaba la siguiente línea:
tbl_facturasARCHIVO_XML.Value := CFD.Datos.XML;

Al hacer esto se guardaba el valor con codificación ISO-8859-1, y como de la base de datos se hacía el envío por e-mail, pues ya todo salía con el juego de caracteres incorrecto.

Solución: cambiar la forma de grabar el xml en la tabla por:
CFD.SaveToFile('archivo.xml');
tbl_facturasARCHIVO_XML.LoadFromFile('archivo.xml');

y Asunto arreglado, los valores en la Base de Datos quedan en UTF-8, y al enviarlos por email, llegan en UTF-8

Saludos y Nuevamente Gracias