Factura Electronica México

[lcarrasco]

Hola amigos, mejorando la liberia que les comente, me topo con que el Numero de Serie que reporta OpenSSL a traves del siguiente comando:

openssl.exe x509 -inform DER -in aaa010101aaa_CSD_02.cer -noout -serial > Serial.txt

Es:
3330303031303030303030313030303030383030

Y el que me regresa la libreria OpenSSL a traves de la DLL es:
3000100000010000080

En algun lado vi que se tenia que quitar un 3 de cada par de digitos. Solo que con esto quiero estar seguro al 100% y saber porque se quita ese 3. De donde viene? porque se quita y donde esta especificado que tiene que tener una longitud de 20 digitos el numero de serie?

Notese tambien la ausencia del ultimo 0 para completar los 20 digitos.

Gracias de antemano por sus respuestas

[nejamube]

Buenas noches.

En el siguiente enlace pueden descargar el codigo fuente para la generacion de el codigo QRCODE, entre muchos mas.

http://code.google.com/p/theunknowno...ts/ZintBarcode

http://sourceforge.net/projects/zint...0.exe/download

Sitio principal del proyecto con fuentes disponibles en C, que se pueden compilar en Visual C:
http://www.zint.org.uk/zintSite/

Entonces a disfrutar se ha dicho.

[edgaronfo]

Hola amigos, esperando que estén bien.

Oigan, en este sitio del SAT:
http://www.sat.gob.mx/sitio_internet.../66_19430.html

están los nuevos xsd y xslt para los CFDi's, y algunas otras notas, también viene un ejemplo de factura CFDi

Alguien ya lo probó? porque en el ejemplo vienen los campos del xml como: cfdi:comprobante o cfdi:emisor, pero a mí no me lo produce así el delphi, por eso pregunto si a ustedes les sale así o les sale como en el anterior, con solo el nombre del campo

Espero haberme hecho entender,

Gracias y saludos

[dado]

Empezado por edgaronfo

Hola amigos, esperando que estén bien.

Oigan, en este sitio del SAT:
http://www.sat.gob.mx/sitio_internet.../66_19430.html

están los nuevos xsd y xslt para los CFDi's, y algunas otras notas, también viene un ejemplo de factura CFDi

Alguien ya lo probó? porque en el ejemplo vienen los campos del xml como: cfdi:comprobante o cfdi:emisor, pero a mí no me lo produce así el delphi, por eso pregunto si a ustedes les sale así o les sale como en el anterior, con solo el nombre del campo

Espero haberme hecho entender,

Gracias y saludos

Si debe llevar los prefijos cfdi: se debe a un nuevo namespace que acaban de introducir.

Por otro lado el ejemplo ESTA PESIMO, lo hicieron con las PATAS y disculpen si lo menciono asi pero es verdad ya me lo han confirmado otros desarrolladores.

Aqui menciono los errores del ejemplo publicado por el SAT, lee ese post y los que le siguen ya que tambien hay publicado un ejemplo valido tanto en forma como en los DOS sellos

[[Al González]]

Leyendo sus comentarios tengo la impresión (equivocada quizá) de que el SAT ha venido pecando de impericia con esta cuestión de la factura electrónica. De por sí, ya tenía dudas de que fuera posible ponerla en práctica a partir del próximo enero (dado el escaso porcentaje de contribuyentes que siquiera hacen algún tipo de operación electrónica), y ahora con tantos cambios en apariencia apresurados uno se queda estupefacto.

Espero que cuando llegue a mí la necesidad de implementar mecanismos de factura electrónica el terreno sea menos agreste. Mis respetos para quienes hoy no tienen otra opción que entrarle al asunto.

[edgaronfo]

Empezado por dado

Si debe llevar los prefijos cfdi: se debe a un nuevo namespace que acaban de introducir.

Por otro lado el ejemplo ESTA PESIMO, lo hicieron con las PATAS y disculpen si lo menciono asi pero es verdad ya me lo han confirmado otros desarrolladores.

Aqui menciono los errores del ejemplo publicado por el SAT, lee ese post y los que le siguen ya que tambien hay publicado un ejemplo valido tanto en forma como en los DOS sellos

Oye dado, pero si yo agarre el cfdv3.xsd de la pagina del SAT y lo use para generar my XML data bind en Delphi y no me da los "cfdi:" , entonces, de donde saco ese nuevo namespace?
o tu como le hiciste en delphi?

saludos

[dado]

Empezado por edgaronfo

Oye dado, pero si yo agarre el cfdv3.xsd de la pagina del SAT y lo use para generar my XML data bind en Delphi y no me da los "cfdi:" , entonces, de donde saco ese nuevo namespace?
o tu como le hiciste en delphi?

saludos

Checa esta entrada en mi foro, ahi explica un poco sobre este asunto

[edgaronfo]

Empezado por dado

Checa esta entrada en mi foro, ahi explica un poco sobre este asunto

Gracias dado, está muy buena tu explicación, aunque ya lo solucioné de manera diferente, lo que hice fue añadir el prefijo cfdi: directamente a la funcion GetComprobante, así:

Código Delphi [-]
function GetComprobanteCFDi(Doc: IXMLDocument): IXMLComprobanteCFDi;
begin
  Result := Doc.GetDocBinding('cfdi:Comprobante', TXMLComprobanteCFDi, TargetNamespace) as IXMLComprobanteCFDi;
end;

Bueno, entonces cómo voy? ya tengo:
1.- mi XML "supuestamente" bien formado usando el cfdv3.xsd del SAT y ahora con el prefijo cfdi:
2.- luego aplico la transformación con el archivo: "cadenaoriginal_3_0.xslt" también bajado desde el SAT, y "supuestamente" voy a tener mi cadena original versión 3.0 también de manera correcta.
3.- Ahora solo mando a llamar la funcion sello de la unidad sello.pas publicada en este foro, pero le cambio un parámetro, verdad? en vez de EVP_md5() le pongo EVP_sha1(), creo...

Saludos y gracias

[JXJ]

Empezado por nejamube

Buenas noches.

En el siguiente enlace pueden descargar el codigo fuente para la generacion de el codigo QRCODE, entre muchos mas.

http://code.google.com/p/theunknowno...ts/ZintBarcode

http://sourceforge.net/projects/zint...0.exe/download

Sitio principal del proyecto con fuentes disponibles en C, que se pueden compilar en Visual C:
http://www.zint.org.uk/zintSite/

Entonces a disfrutar se ha dicho.

¿donde dice que hay que suar QRcode?
¿y como usarlos?

[ContraVeneno]

de acuerdo a "lo que me han dicho", después del 2011, todos los CFD (comprobante fiscal digital) deberían ser sellados por un PAC (Proveedor Autorizado de Certificación). Dando al traste con el esfuerzo realizado por el área de desarrollo para generar de manera interna los CFD, ya que sin importar lo que se haga, se tendrían que enviar al PAC para su proceso, así que en este caso, pos pa que lo hago yo si el PAC también lo hace...

Pero por lo que he leído, aquellos que ya iniciaron con la emisión de CFDs en 2010, por medio de desarrollo interno o por medio de la adquisición de un sistema que emita CFDs, podrán seguir utilizando este medio de manera indefinida, es decir, no se requerirá de los servicios de un PAC.

¿Alguién está más informado que yo en este tema?

Saludos.

[nuk3zito]

Empezado por ContraVeneno

de acuerdo a "lo que me han dicho", después del 2011, todos los CFD (comprobante fiscal digital) deberían ser sellados por un PAC (Proveedor Autorizado de Certificación). Dando al traste con el esfuerzo realizado por el área de desarrollo para generar de manera interna los CFD, ya que sin importar lo que se haga, se tendrían que enviar al PAC para su proceso, así que en este caso, pos pa que lo hago yo si el PAC también lo hace...

Pero por lo que he leído, aquellos que ya iniciaron con la emisión de CFDs en 2010, por medio de desarrollo interno o por medio de la adquisición de un sistema que emita CFDs, podrán seguir utilizando este medio de manera indefinida, es decir, no se requerirá de los servicios de un PAC.

¿Alguién está más informado que yo en este tema?

Saludos.

Al parecer tenemos la misma información, muy probablemente las mismas fuentes.

Lo otro que acabo de confirmar es que los que ya generamos CFD's en 2010 SI tendremos que cambiar la forma del sellado utilizando SHA1 en lugar de MD5 para obtener la cadena de digestión... y la versión del cfd no cambiará en estos casos, pues seguirá siendo la versión 2 (Solo cambia un algoritmo).
Esto lo leí en las FAQ de http://www.sat.gob.mx/sitio_internet.../66_19430.html

Por lo demás de los CFDI, creo que la mayoría seguimos en el limbo, solo unos cuantos le han agarrado mas o menos el hilo a esto pues los ejemplos y la información publicada efectivamente si dejan mucho que desear.

[[AzidRain]]

La versión 3, es la versión "perfeccionada" y ya con las omisiones corregidas. Hace rato estaba escribiendo una respuesta y se me reinicio mi lap y ya no la terminé, pero resumo:

Si tu desarrollo basado en el esquema actual ya lo tienes listo libéralo cuanto antes para que no tengas que hacer ningún cambio en 2011.

Si crees que ya no te da tiempo, no hablar, empieza a ver como cambiarlo al esquema nuevo.

QUienes ya estan con lo del 2010 NO tienen que cambiar nada ya que la resolución claramente indica que pueden seguir con el esquema que tienen hasta finales de 2011.

El esquema nuevo es mucho más sencillo de implementar además de que elimina obligaciones fiscales que el esquema actual si impone como:

* registrar simultaneamente cada factura en la contabilidad
* llevar contabilidad en algún software
* proporcionar las herramientas al SAT para que en caso de así requerirlo puedan consultar las cfds que ya emitiste (hacerles su software para consultar tus datos)
* emitir y presentar reporte mensual ante el SAT de los cfds generados

La información completa está en famoso Anexo 20, el cual pasó de unas 89 páginas a mas de 190 ya que se le agregó mucha información más específica y concisa.

Los PAC (que ahora todavia son PCFD) están como "perros" tratando de convencer a todo mundo de entrarle "de una vez" al esquema actual ya que en 2011 el servicio de certificación de los comprobantes es gratuito por ley y están obligados a cumplir con el mismo. Esto último no lo dicen por obvias razones, dado que por el momento SI pueden cobrar por ese servicio y quienes opten por entrar en este esquema no podrán cambiarlo al menos hasta junio del año que viene, o sea, a pescar lo que se pueda.

Por lo que si en sus empresas o clientes le están pensando o ya los están bombardeando, no les hagan caso y tomen una alternativa de transición de las que hay varias opciones y esperen a que salgan las demás reglas que faltan para que les salga mucho más barato y mucho más sencillo el desarollo.

Edito:
Las FAQ a que se refiere nuk3sito se refieren exclusivamente a los aspirantes a PAC (está equivocado el título en la página del SAT), en todo caso si te remites al CFF verás que el contribuyente que ya emita CFDS por medios propios NO está obligado a cambiar nada al menos durante el 2011. Además te lo confirmo dado que ayer precisamente estuve en un taller del SAT y fue una de mis preguntas.

Finalmente, para que le comenten a sus clientes, solo hay alrededor de 25 proveedores autorizados (si vieran todos los requisitos que se piden para obtener la autorización se espantan, no cualquier empresita tiene los recursos) pero sin embargo ya muchas empresas andan vendiendo soluciones que supuestamente "cumplen al 100%" con la disposición, pero no indican que no tienen autorización.

[nuk3zito]

Empezado por AzidRain

QUienes ya estan con lo del 2010 NO tienen que cambiar nada ya que la resolución claramente indica que pueden seguir con el esquema que tienen hasta finales de 2011.

Esto que mencionas es algo confuso, y no es que no te crea a ti, si no que en cada llamada que he hecho al SAT me dicen algo diferente. La respuesta que predomina es que la forma de sellado se queda tal y como está, pero por eso envié la liga de las FAQ en donde en una de las preguntas indican claramente que SI se debe cambiar el algoritmo usado para obtener la cadena de digestión.
Para esto mismo, cryptosys liberó el 2 de Noviembre el método para obtener el sellado usando SHA1 en lugar de MD5.
Repito, no es que no te crea a ti, pero debemos de creerle al SAT, no crees? El problema como te digo es que en cada llamada telefónica dicen algo diferente, y lo único escrito explícitamente para este tema es en las FAQ lo cual contradice lo que anteriormente se dijo de que la forma de sellado funcionaría en el 2011 "tal y como se hace hoy" en el caso de empresas que iniciaron con CFD's antes de 2011.

Si pudieras mostrarnos una URL en donde diga explícitamente que se seguirá usando MD5 en lugar de SHA1 te estaré agradecido, y no solo yo, creo que somos varios aunque la mayoría solo son lectores de este hilo.

Aqui vienen las FAQ que menciono:
http://www.sat.gob.mx/sitio_internet.../66_19430.html

Saludos.

[lcarrasco]

Hola amigos, disculpen desviarme un poco del tema para pedir ayuda. Lo que pasa es que estoy verificando si la libreria que hice (de codigo abierto) funciona adecuadamente. Para ello descargue la utilidad del SAT Micro-e ver 1.5 descargue los certificados, llave privada de ejemplo de persona con actividad empresarial e hice un comprobante, hasta ahi todo bien, sin embargo al usar mi libreria el sello es totalmente diferente, me estuve quebrando la cabeza todo un dia viendo porque, sin embargo subi el comprobante y el sello al validador del SAT y resulta que dice: "El sello no pudo ser verificado" sin mas detalles. Esto signfifica que la utilidad del SAT esta generando mal los comprobantes???

A alguien le ha pasado esto? es porque es la "version de prueba" del micro-e? hay alguna version mas nueva que la 1.5 ?? La descargue apenas hace 3 dias.

Anexo a este post los archivos que estoy usando asi como el PDF y el XML generado por el MicroE por si alguien puede generarla usando su codigo, programa, etc y verificar quien tiene la culpa.

Les estaria muy agradecido si me dan algunos tips.

PD. Aun no publico la liga al proyecto porque quiero liberar algo terminado y funcional y en cuanto logre pasar esta etapa les mando la liga. Aunque "dado" ya se ofrecio a colaborar y supongo la esta revisando.

[dado]

Empezado por lcarrasco

Hola amigos, mejorando la liberia que les comente, me topo con que el Numero de Serie que reporta OpenSSL a traves del siguiente comando:

openssl.exe x509 -inform DER -in aaa010101aaa_CSD_02.cer -noout -serial > Serial.txt

Es:
3330303031303030303030313030303030383030

Y el que me regresa la libreria OpenSSL a traves de la DLL es:
3000100000010000080

En algun lado vi que se tenia que quitar un 3 de cada par de digitos. Solo que con esto quiero estar seguro al 100% y saber porque se quita ese 3. De donde viene? porque se quita y donde esta especificado que tiene que tener una longitud de 20 digitos el numero de serie?

Notese tambien la ausencia del ultimo 0 para completar los 20 digitos.

Gracias de antemano por sus respuestas

Lo que sucede es lo siguiente :

tomemos un "35", en realidad es un numero hexadecimal asi que lo tenemos que convertir a decimal, bueno eso es facil :

3x16 + 5 = 53

Pero resulta que el codigo ASCII numero 53 es el numero "5"

Si lo revisas en Delphi con Chr(53) puedes ver que te arroja un "5"

En 3000100000010000080 tienes 19 caracteres, si te falta el ultimo "0"

[lcarrasco]

Empezado por dado

Lo que sucede es lo siguiente :

tomemos un "35", en realidad es un numero hexadecimal asi que lo tenemos que convertir a decimal, bueno eso es facil :

3x16 + 5 = 53

Pero resulta que el codigo ASCII numero 53 es el numero "5"

Si lo revisas en Delphi con Chr(53) puedes ver que te arroja un "5"

En 3000100000010000080 tienes 19 caracteres, si te falta el ultimo "0"

Gracias Dado!

Ya vi que el Numero de Serie es por definicion del RFC de 20 digitos.