En absoluto Dado.
Lo que no está permitido es hacer publicidad, o en todo caso sería desviar la conversación a otro lugar (tal vez eso sería poco ético) y hay quien a veces lo ha hecho con "mala intención"; Pero el hecho de añadir un link a cualquier hilo (de otro foro o de otra página web), no tiene que ser (y de hecho no lo es) ningun problema.
No hay ninguna norma que marque exclusividad, al contrario, compartir enlaces, links, páginas,... en un hilo, lo enriquecen más.

Un saludo.

Como obtienen los datos del archivo .cer ?
 

Hola a todos, de casualidad alguien esta utilizando otro metodo para obtener del certificado los datos (NoCertificado, Vigencia Incial y Final, archivo PEM, etc) que no sea el bat que llama al OpenSSL (no se, tal vez con componentes como LockBox o algun otro)... Por un lado, no me gusta que al correr el bat que ejecuta los comandos del OpenSSL, Windows me pregunta que si estoy deacuerdo en ejecutar este archivo, le de al boton de Aceptar, pues como que se ve mal. Por otro lado, el dejar ahi el archivo PEM que presenta en plano tu certificado no me parece seguro. Como ven?

Hola Felipe! En que formato está el archivo?
 

Ya lo bajé, pero NO lo pude leer.

Gracias de antemano por el aporte!

El Documento que nos facilita "felipep" se puede leer con Word o similar...
 

... y la info de interés está a partir de las "páginas" 490-510.

Espero y a alguien le sea de utilidad.

Salu2!

P.D. Es el código borrado por "uamero".

Eso de "uamero" será por lo de las "uamas"? ; )

entonces esa es la unica manera de obtener la leyenda de "El Sello es Valido"?? no hay ninguna otra opcion??

segun lo que aparece en: http://www.lacorona.com.mx/fortiz/sa...p#verificacion lo unico que tendriamos que hacer es volver a sellar la cadena original con el certificado incluido en la misma factura ¿no?

Como en tooodo lo de programacion, siempre vas a encontrar varias formas de hacer lo mismo, en este caso, de verificar.

En mi caso solo conozco la que menciono, por eso no habia contestado tu mensaje, PERO, creo que mi estimado Fernando Ortiz (de la corona) esta vez si se equivoco en los terminos.

Es IMPOSIBLE* volver a firmar la factura para ver si esta bien, el dice :

él dijo......

openssl dgst -md5 -verify 00002020.cer.pem -signature sello

yo "dije".......

openssl dgst -md5 -verify "pubkey.txt" -signature "sellobin.txt" "cadoriginal.txt" >resultado.txt

Como puedes ver es lo mismo, solo que mas revuelto.

*IMPOSIBLE....bueno, no imposible, pero para volver a firmar un CFD necesitas que te proporcionen la (secreta) llave privada, y no creo que NADIE quiera darte su llave privada para "volver a firmar" y validar el CFD.

Lo que dice Fernando Ortiz de La Corona, no esta bien "dicho", no puedes volver a firmar el CFD con la llave publica, es simple logica, si eso fuera posible entonces cualquiera podria sellar una factura y hacerla pasar por buena.

Solo para aportar un poco más al hilo ya que a todo interesado en el tema le va servir coloco los siguientes links:

El SAT ya tiene disponibles herramientas para validar los CFDs, tanto en línea como como aplicación de escritorio

Este es uno
Y este otro

También desarrollo una aplicación web para emitir CFDs y está disponible de manera gratuita aquí, inclusive se puede acceder a una aplicación de prueba.

No recuerdo si ya apareció en el hilo, pero uno de los requisitos del SAT para el contribuyente es que "lleve su contabilidad mediante un sistema de software" y que el registro contable se haga de manera "simultánea" en dichos sistema aunque más adelante especifica que se puede realizar dicho registro hasta 24 horas después de elaborado el CFD.

Aquí hay un blog que habla del tema tanto por el lado del software (aunque sin llegar a detalles de programación) como del lado fiscal.

Existen unas herramientas hechas por ELDOS.com en particular Secure Black Box VCL Edition que no son otra cosa mas que las funciones del OpenSSL llevadas a una libreria en éste caso para Delphi. De esta manera te evitas estar llamando un .bat

En cuanto a que windows te esté preguntando cada vez que ejecutas el bat, supongo que quizas estas utilizando WVista o W7, de ser así, es cuestión de derechos que tiene la misma cuenta, aun y cuando 'aparentemente es un usuario administrador'.

Respecto a lo que comentas de dejar ahi el PEM, en efecto, es un riesgo de seguridad. Podrias generar el archivo PEM cada vez que emitieras una factura, y pedirle al usuario la contraseña por cada vez que se emita un CFD, esto con las consecuencias de tiempo que ya te puedes imaginar, amen de lo tedioso que puede llegar a ser para tu usuario.

TE recomiendo este http://www.cryptosys.net/rijndael.html
 

Hola, te recomiendo esta DLL, en cuestion de minutos estas facturando.

http://www.cryptosys.net/pki/satmexico.html

cryptosys
 

Es cierto, también las evaluamos en su momento si mal no recuerdo es un grupo de Australianos quienes la desarrollarons ...jaja irónico no!

Son muy fáciles de usar y estan 100% enfocadas a las funciones que el SAT solicita, es un desarrollo a la medida. El unico inconveniente que le vimos es que es una 'caja negra' uno como programador pierde el control, cosa que no sucede con otras herramientas en las que uno tiene el 'control' de lo que se hace, pero de ahi en más, son excelentes las de cryptosys.

Sobre Crytosys
 

Hola Nejamube, he estado leyendo todo el lio de la Factura electronica y baje un codigo en Lazarus desde Delphiaccess , estoy en estos momentos pasandolo a Delphi, pero me intereso mucho lo de Cryptosys,que segun leo esta enfocado al SAT pero aun no logro comprender,me imajino que esta es una Dll, entonces mi pregunta es si yo uso esta dll, practicamente viene todo para hacer lo de la factura electronica sin meter tanto codigo? saludos y gracias.
:confused:

Asi es
 

Efectivamente, con esta DLL no tendrias que escribir todos los procedimientos para la factura electronica, solo mandas llamar las funciones. Lo que tendrias que hacer seria adecuar tu software para la factura electronica, el informe mensual al SAT, reporte de folios utilizados y cancelados, entre otras cosas.

Si llegas a utilizar cryptosys, lo más "difícil" que te tocaría por hacer es formar los XML's correctamente.
Yo uso esa librería, y el esquema de licenciamiento que utilizan es muy accesible, pues puedes distribuir esa dll entre los usuarios finales de tu aplicación sin necesidad de pagar licenciamiento extra. Además si el sat hace cambios menores, al pagar el licenciamiento tienes derecho a bajar actualizaciones de las librerías.
Al momento que te escribo, llevamos 10,000 cfd's generados con absolutamente cero problemas.
Y sobre el código... si le debes meter un poquito de código... pero ya no se compara para nada con hacer todas las rutinas a mano, pues te lo digo por experiencia, ya que cuando estuve haciendo todo "a mano" (sin usar OpenSSL) me encontré con broncas al momento de leer el certificado.

Saludos y suerte.

Gracias Nejamube, ya heche andar con el Cryptosys lo necesario para lo de las CFD,saludos.

Hola nuk3zito, baje el Cryptosys y ya estoy generando los XML, cosa muy sencilla y ya leo las cadenas ,Cerfiticados, genero sellos, etc. esta de Pelos, saludos.

Pero....el Cryptosys cuesta una lana!!

Son 169.00 dolares de base mas 120.00 dolares por las rutinas FirmaSAT, en total y al tipo de cambio son como $3,700.00 pesos

Con el OpenSSL te cuesta 0.00 (cero pesos), pero bueno, cada quien.

Bueno, en total son 159 dlls incluyendo FirmaSAT. No se de donde obtuviste ese otro precio.

Ps es que si es de cada quien.

Mira, en tu caso que has estado comercializando con tu desarrollo, pues si ya hiciste algo con OpenSSL, solo les adviertes a tus clientes que utilizas OpenSSL y asunto arreglado... te lo pagan y listo.

En el caso de otras empresas, si a un programador le pagan $3,500.00 a la semana y resulta que el hacer las rutinas te va a llevar un tiempo de 10 días a dos semanas, entonces resulta mejor comprar FirmaSAT, pues sale más barato, y el soporte ya lo tienes. Y si fuera tan necesario tener el código fuente de los algoritmos de encriptación, pues continuas con tu desarrollo "a ratos" pues ya no urge. Como quiera, la empresa se ahorra un billete.

Pero pues, ahí si que es de cada quien... ¿o a poco no es mejor para tí que alguien decida no hacerlo y comprate a ti la solución?
Ahora que si tu ofreces exactamente lo mismo que cryptosys pero más barato, pues claro que es de considerarse lo que tu ofreces, pero de hecho cryptosys es un desarrollo muy completo. Cada quien hace su luchita.

P.D. Lo raro es que ese es un proyecto de otro país, pero pues toman como base los mismos algoritmos para la facturación electrónica en general.

Los precios los obtuve de esta pagina . Importante notar que el "FirmaSAT" de $120 es un "ADD ON" y que se requiere que previamente compren el Cryptosys PKI de $169.00 dolares

El comentario lo hice porque he comprado otras librerias (Alpha Skins, Topaz, SCI, etc) y cualquiera de ellas me ha costado menos de 60 dolares, por eso se me hace caro el Crypto. Solo queria "prevenir" a los lectores que hay opciones gratuitas. En ningun momento hice el comentario de que por $200.00 pesos pueden conseguir la adaptacion del OpenSSL a los CFD.

TOTALMENTE de acuerdo! por supuesto, para eso estan las "librerias de terceros" para adaptarlas a tus necesidades especificas.

Insisto, solo queria comentar de esta tercera opcion ya que comentaron de Eldos.com y de Criptosys, crei conveniente comentar de OpenSSL y que la ventaja era que es gratuita.

De acuerdo ambos.

Para serte sincero, aún pretendo retomar la programación de los algoritmos, pues no pienso dejar que la lectura del certificado me gane la batalla (solo eso me faltó :( )

A ver si raza en el foro se anima y lo hacemos todo nativo para no estar dependiendo de terceros.

El programa del sat "Microsat" tiene algunas cosas buenas pero tambien tiene desventajas como la lentitud con la que se ejecuta, por cada factura que se emita hay que estar buscando el archivo .key y el .cer, lo cual para el cliente me imagino que seria tedioso, otra cosa es, cuando estamos haciendo una factura al agregar un nuevo concepto a la misma hay que seleccionar el producto desde un combo pero que pasa si en el negocio se maneja mas de 500 productos ya se imaginaran lo tedioso de ir buscando producto por producto. Nuestro trabajo como programadores es mejorar o hacer mejores soluciones, mas rapidas, eficientes y seguras y sobre todo que al usuario final le resulte mas comodo usar por que al fin y al cabo los que usan nuestros sistemas no son informaticos, y a mi la verdad si fuese un usuario normal (me refiero a no ser informatico) me traumaria con el uso del MicroSaT, como han de saber todo lo que hace el Sat es una pura Cochinada, nomas digo :D

Obtener detallas del certificado
 

Yo en particular si lo logre amigo, pero lo hice en C#, es decir: hice un program en C# que me obtiene la informacion del certificado solo con pasarle como paremetros la ruta y el password desde x programa en este caso desde delphi, entonces el programa de C# se encarga de obtener toda esa informacion y porteriormente me la devuelve en un archivo de texto que despues extraigo con delphi. Use esta solocion porque, si es bien sabido que hay unas librerias como SatFirma que obtienen toda esa información con delphi pero pues son de prueba, en cambio esta solucion me sale mas factible mientras encuentro otra. algo que intente fue convertir ese programa de C# en una dll el problema que me encuentro es que no la puedo leer desde Delphi :D:D:D

de acuerdo... no es "volver a firmar", es "verificar" ;)


otra pregunta... ya tengo todo jalando bien, ahora necesito meter ADDENDAS... si estoy utilizando el cfdv2.pas que genera el Dephi, como le puedo hacer para "agregar" una adenda a ese esquema?? :confused:

Las reglas cambian en facturacion electronica
 

Hola.

El SAT publico el Anexo 20 2010 y ahora las reglas cambian. Quien ya creia tener todo para factura electronica, se equivoco:eek:, porque en Enero del 2011 no sera igual.

:(
Formato electrónico único


C. Estándar y uso del complemento obligatorio Timbre Fiscal Digital del SAT






Elemento: TimbreFiscalDigital

Diagrama



Descripción


Complemento requerido para el Timbrado Fiscal Digital del SAT que da validez a un Comprobante Fiscal Digital por Internet.

Atributos


Version

Descripción
Atributo requerido para la expresión de la versión del estándar del Timbre Fiscal Digital

Uso
requerido

Valor Prefijado
1.0

UUID

Descripción
Atributo requerido para expresar los 36 caracteres del UUID de la transacción de timbrado conforme al estándar (RFC) 4122

Uso
requerido

Tipo Base
xs:string

Longitud
36

Espacio en Blanco
Colapsar

Patrón
[a-f0-9A-F]{8}-[a-f0-9A-F]{4}-[a-f0-9A-F]{4}-[a-f0-9A-F]{4}-[a-f0-9A-F]{12}

FechaTimbrado

Descripción
Atributo requerido para expresar la fecha y hora de la generación del timbre por la certificación digital del SAT conforme con la especificación ISO 8601.

Uso
Requerido

Tipo Base
xs:dateTime

Espacio en Blanco
Colapsar

selloCFD

Descripción
Atributo requerido para contener el sello digital del comprobante fiscal, que será timbrado. El sello deberá ser expresado como una cadena de texto en formato Base 64.

Uso
Requerido

Tipo Base
xs:string

Espacio en Blanco
Colapsar

noCertificadoSAT

Descripción
Atributo requerido para expresar el número de serie del certificado del SAT usado para el Timbre

Uso
Requerido

Tipo Base
xs:string

Longitud
20

Espacio en Blanco
Colapsar

selloSAT

Descripción
Atributo requerido para contener el sello digital del Timbre Fiscal Digital, al que hacen referencia las reglas de Resolución Miscelánea aplicable. El sello deberá ser expresado como una cadena de texto en formato Base 64.

Uso
Requerido

Tipo Base
xs:string

Espacio en Blanco
Colapsar






Secuencia de Elementos a Integrar en la Cadena Original del Timbre Fiscal Digital del SAT.


Cadena Original


Se entiende como cadena original, a la secuencia de datos formada con la información contenida dentro del Timbre fiscal digital del SAT. Siguiendo para ello las reglas y la secuencia aquí especificadas:

Reglas Generales:

• Ninguno de los atributos que conforman al comprobante fiscal digital deberá contener el carácter | (“pipe”) debido a que este será utilizado como carácter de control en la formación de la cadena original.
• La cadena original resultante del complemento será integrada a la cadena original del comprobante de acuerdo con lo especificado en el anexo 20 de la Resolución Miscelánea Fiscal para 2010.
• Se expresará únicamente la información del dato sin expresar el atributo al que hace referencia. Esto es, si el atributo tipoOperación tiene el valor “monedero” solo se expresará |monedero| y nunca |tipoOperacion monedero|.
• Cada dato individual se encontrará separado de su dato anterior, en caso de existir, mediante un carácter | (“pipe” sencillo).
• Los espacios en blanco que se presenten dentro de la cadena original serán tratados de la siguiente manera:
  • Se deberán remplazar todos los tabuladores, retornos de carro y saltos de línea por espacios en blanco.
  • Acto seguido se elimina cualquier carácter en blanco al principio y al final de cada separador | (“pipe” sencillo).
  • Finalmente, toda secuencia de caracteres en blanco intermedias se sustituyen por un único carácter en blanco.
• Los datos opcionales, cuando no existan, no aparecerán expresados en la cadena original y no tendrán delimitador alguno.
• Toda la cadena de original se expresará en el formato de codificación UTF-8.

Secuencia de Formación

La secuencia de formación será siempre en el orden que se expresa a continuación, tomando en cuenta las reglas generales expresadas en el párrafo anterior.

• Atributos del elemento raíz TimbreFiscalDigital

• • version
  • UUID
  • FechaTimbrado
  • selloCFD
  • noCertificadoSAT

Ejemplo de cadena original de un timbre:

||1.0|ad662d33-6934-459c-a128-bdf0393e0f44|2001-12-17T09:30:47Z|iYyIk1MtEPzTxY3h57kYJnEXNae9lvLMgAq3jGMePsDtEOF6XLWbrV2GL/2TX00vP2+YsPN+5UmyRdzMLZGEfESiNQF9fotNbtA487dWnCf5pUu0ikVpgHvpY7YoA4lB1D/JWc+zntkgW+Ig49WnlKyXi0LOlBOVuxckDb7EAx4=|12345678901234 567890||

Nota: El atributo selloCFD será el sello previo del Comprobante Fiscal Digital, el sello del timbre será guardado dentro del atributo selloSAT. Esta cadena original será sellada utilizando el algoritmo de digestión SHA-1.


El resultado de la validación de un CFDI, asignación de un folio fiscal e incorporación del sello digital del SAT se entenderá como el Timbrado Fiscal Digital. El folio fiscal digital será referido como el UUID. Para integrar el complemento TimbreFiscalDigital a un comprobante fiscal digital por Internet, la estructura resultante deberá integrarse como un nodo hijo del nodo Comprobante/Complemento/TimbreFiscalDigital.



:confused:

Solucion Tralix
 

Para no meterme en tanta bronca de cambios en las reglas del SAT, no es que quiera hacer propaganda, acabo de venir de un curso de certificacion en Mexico de Tralix, ellos van a la par en los cambios que haga el SAT, pues es lo que meteremos en Chiapas para las empresas que aun estan hechas pelotas con esto del CFD. saludos.

:cool:

Las reglas cambian en facturacion electronica
 

Se elimina la facturacion por medios propios, los requisitos para ser proveedor de CFDI son bastante dificiles de cumplir, el mas dificil de todos es que nosotros programamos en Delphi, un lenguaje que no es de internet como PHP.

Requisitos para ser Proveedor de Certificación de CFDI

http://www.sat.gob.mx/sitio_internet.../66_19069.html


http://www.sat.gob.mx/sitio_internet.../66_19072.html

Nota: Podrán ser autorizadas las personas morales a que se refiere la fracción III del artículo 95 de la Ley del ISR, siempre que el servicio se preste únicamente a sus agremiados y cumplan con los requisitos establecidos en esta ficha salvo lo señalado en las fracciones VII, inciso a) y VIII.


Entregar copia de una aplicación informática para la generación y expedición de CFDI, y poner la misma a disposición del público en general, de manera gratuita y junto con los servicios necesarios para su uso, en el mismo lugar en que el proveedor ofrezca el servicio de certificación de CFDI, permitiendo que a la misma se tenga acceso incluso de manera directa desde la página de Internet del SAT.

No es necesario PHP
 

Hola no es necesario PHP, ahi tienes a Extpascal o Raudus (Todo con la magia de Delphi), hechate una vuelta a Delphiaccess.com ahi tengo mis tutoriales de Extpascal, para hacer aplicaiones WEB, saludos.

;)

entonces si ya tenias planeado facturar electronicamente en el octube de 2010
para enero¿ ya no vas a poder facturar. con tu desarrollo actual?

¿Pero aun asi puedes desarrollar una aplicacion para uso privado.?

o a fuerza la tienes qeu hacer libre.

Las reglas cambian en facturacion electronica
 

Si empiezas a facturar electronicamente en el 2010 (hasta el ultimo dia del 2010), podras permanecer en el esquema actual hasta Junio 2011, despues no sera valido.

;)

nejamube.. bien.. por la informacion

algo que no entiendo es que ahora la facturacion electronica va a aser
via servicios. de un tercero y que ese tercero se tiene que certificar
y debe de dar acceso gratuito a la facturacion
y que el sat podra revisar su sistema via web

¿ya no se se permitira que uno expida sus certificados ?
(un programa delphi que genere el xml)

nejamube, no encuentro en el anexo 20 de junio de 2010 eso que mencionas del elemento TimbreFiscalDigital (ni haciendo un "search").
¿De donde bajaste ese documento?

JXJ, claro que le seguirán permitiendo a uno generar sus CFD's (certificados es otra cosa), por eso el SAT te libera estos Anexos (anexo 20 y sus varias versiones). No es obligatorio usar servicios de un tercero, pero puedes optar por hacerlo si así lo requieres aunque puedes ahorrarte la cantidad exagerada del dinero que te van a cobrar. Eso no cambia, no se quien esté propagando esta información.

Las reglas cambian en facturacion electronica
 

http://www.sat.gob.mx/sitio_internet.../66_19267.html
:cool:

Las reglas cambian en facturacion electronica
 

http://www.sat.gob.mx/sitio_internet.../66_19202.html

http://www.sat.gob.mx/sitio_internet.../66_18779.html

http://www.sat.gob.mx/sitio_internet.../66_18785.html

http://www.sat.gob.mx/sitio_internet.../66_19069.html

http://www.sat.gob.mx/sitio_internet.../66_19072.html

Que tal nejamube, seguí sin encontrar lo del timbre postal pero los links que posteaste se ven interesantes y a la vez desconcertantes, pues efectivamente parte de lo que dices aplica. Si empezaste a emitir facturas electrónicas antes del 2011 entonces podrás seguirlo haciendo en el 2011, pero si no empiezas en este año y te esperas a que inicie el 2011 tendrás que contratar a uno de los 26 proveedores autorizados de este servicio.
La historia no está escrita para el 2012, pues se que hay anteproyectos a esto y se está considerando que ciertos sistemas puedas seguir generando sus cfd's como ahora ya lo han estado haciendo... la pregunta es si una empresa de sistemas que no vende al por mayor tendrá oportunidad de entrar en este esquema pues todo apunta a que el sat quiere beneficiar a esos 26 proveedores.
Tengo aún un año y 3 meses para preocuparme sobre el futuro de los cfd's, pues todo el 2011 podré seguir emitiendo los cfd's como hasta ahora lo hemos hecho. http://www.sat.gob.mx/sitio_internet.../66_19208.html

Te agradezco el aporte... es desconcertante pero es material que vale la pena. Es de reciente publicación y al parecer uno debe estar atento todos los días a lo que publica la página del sat.

Saludos y gracias.

Por cierto, por teléfono dicen otra cosa y dicen que mientras no salga en el DOF, nada está escrito sobre tener a fuerza que contratar un proveedor de CFD's, pues esto está perjudicando a muchas empresas que no consideraban tenerle que pagar algo a un nuevo proveedor de servicios.

Las reglas cambian
 

Efectivamente, no es oficial hasta que se publica en el Diario Oficial de la Federacion, pero ten por seguro que se publicara, ya que la factura electronica es obligatoria a partir de Enero 2011, lo dice el Codigo Fiscal de la Federacion. Que en este momento sea un "anteproyecto" significa que estan afinando los ultimos detalles, pero lo mas seguro es que el anteproyecto quedara tal cual, no creo que lo cambien demasiado y mucho menos la parte del Timbre, porque eso le da al SAT "candados", como de que las facturas estan el formato correcto y demas controles necesarios para evitar facturas apocrifas. Es solo cuestion de tiempo para que se publique el DOF y sea oficial.

:confused:

ftp://ftp2.sat.gob.mx/asistencia_ser...0_03092010.doc

:rolleyes:

Pues si, veo que eso de contratar un proveedor forzosamente es lo que está en tela de duda... ojalá no nos afecte (y beneficie solo a esas 26 empresas).

Esperemos a ver que pasa, por lo pronto sigamos generando CFD's.

LA regla cambió porque ahora habrá terceros encargados de emitir la certificación fiscal de cada comprobante emitido, algunos ya ofrecen un servicio via conector: se envían los datos del comprobante y se recibe el comprante ya certificado y válido para su proceso. Es la forma más sencilla de hacer todo el proceso. Algunos también ofrecen acceso vía API. Lo del proveedor ya estaba de todos modos "amarrado" pues de por sí para imprimir facturas tenías que ir con "imprentas autorizadas".

El famoso timbre aplicará para autofactura, o sea contribuyentes del sector primario que emiten sus propias facturas de menos de 2000 pesos, quienes podran hacer su factura hasta en Excel siempre y cuando le peguen el "timbre" que será una holograma o similar.

El sat en efecto podrá y puede tener acceso a la información de tus cfds( en cualquier caso) ya que por ley te obliga no solo a darle acceso sino a proporcionarle las herramientas necesarias para ello.

Reglas cambian
 

Te equivocas con que podras hacer tu factura "hasta en excel", el holograma que entregara el SAT es para los contribuyentes que aun cuenten con facturas que no sean facturas electronicas, ya que el tiempo de validez por ley de una factura una vez solicitada y antes de que "caduque" es de 2 años.

El SAT enviara por correo los hologramas a los contribuyentes, cada contribuyente tendra que agregar un hollolograma a las facturas que aun no son facturas electronicas.

Tambien te equivocas al decir "solo los contribuyentes del sector primario".

El "timbre fiscal" es algo parecido al Sello que actualmente se genera en los CFD y comprueba la integridad del comprobante, a diferencia del "holograma" para las facturas que en 2011 y 2012 sean de papel, necesitaran de este holograma para ser validas.

Timbre fiscal en XML de factura electronica.
Holograma en facturas que no son electronicas.

En 2011 desparace la figura de "impresor autorizado", por lo que muchas imprentas van a cerrar, las unicas facturas que seran de papel en este tiempo son las que aun queden y fueron tramitadas en 2010. Aunque tramitaras millones de facturas en 2010 solo tienen 2 años de validez, por lo tanto la migracion a factura elecronica es un hecho.



http://www.sat.gob.mx/sitio_internet...s/33_9691.html

¿ Pudes poner los link de quien ofrece el servicio de certificacion via conector ?
:rolleyes:

nejamube
Bueno, si y no. Para los que esten facturando antes del 31-dic-2010 van a poder seguir facturando igual durante (por lo menos) todo el 2011.
Para los que quieran entrar a la F.E. despues de enero de 2011 entonces si, van a tener que enviar sus CFD para "Timbrarlos"
No, no se elimina "por medios propios", de hecho el SAT va a publicar un portal gratuito para timbrar. Tambien los PAC (proveedores Autorizados de Certificacion) tienen LA OBLIGACION de ofrecer servicios gratuitos de timbrado.
Si vas a poder, pero apurale, tienes que hacerlo antes del 31-dic-2010 o si no entonces entras al "Esquema 2011"
Cambiaron las reglas, ya no es "obligatoria para todos", ahora solo es obligatoria para los que (ingresan) mas de 4,000,000.00 anuales. (perdon puse "ingresan" ya que no estoy seguro del termino, hay que checar el anteproyecto)
Es correcto, puedes hacerla en Excel e imprimirla (perdon por la expresion) en papel de baño, asi lo dice el SAT y no, ya no es holograma (nunca dijeron oficialmente que pudiera ser un holograma), el "dispositivo de seguridad" va a ser un codigo de barras bidimensional del tipo QR Code (Quick response code) que va a tener encriptado RFC, datos de autorizacion y otros
Segun yo si las puedes hacer "hasta en Excel", no hay nada que lo contradiga, con ponerle el Codigo de Barras (recuerda, ya no es holograma) ya estas validando esa factura.