Factura Electronica México

[odrack]

Gracias DADO por la respuesta estaba buscando algo asi que me orientara por donde comenzar, si tengo problemas te enviare un correo o preguntare en el foro que tanto me a ayudado, gracias a una gran parte de este foro he logrado formar un ERP.

[mesquivelh]

Empezado por dado

Basicamente lo que te dice la validacion es que no esta bien formada la Addenda.

Yo tengo la "Addenda AMIS", es la que usan las empresas de Seguros como Mapfre, Zurich, Qualitas, etc etc

Para que empresa estas tratando de implementar la Addenda?, hay decenas, Chedraui, Soriana, Chrysler, AMECE, Liverpool, etc etc y mas etc

Es para PEMEX

[dado]

Empezado por mesquivelh

Es para PEMEX

Buscando la definicion de la addenda para PEMEX me encontre este documento

Y lo que alcanzo a ver es que esta Addenda, ES LA MAS FACIL que haya visto jamas (bueno, no he visto muchas, pero esta si es facil)

Hay un ejemplo de la addenda :

<Addenda>0047|2009|90309|T|137|GTT-0047|2009</Addenda>

Asi que lo que estas haciendo es correcto :

Código Delphi [-]
CFD.Addenda.Text := '0047|2009|90309|T|137|GTT-0047|2009'

Despues de todo los datos en el XML aparecen como deben ser y en la posicion que debe ser.

Entonces mi teoria es que el validador del SAT "no sabe" interpretar esta Addenda y por eso marca error.

Es mas, me atrevo a decir que el validador del SAT NO DEBERIA marcar error en NINGUNA ADDENDA, la misma ley dice que los datos de la addenda no son regulados por el SAT y son de formato libre.

Lo que creo que esta pasando es que necesitas agregar el "namespace" de la Addenda Pemex.

El namespace es la direccion donde se supone deberia estar la definicion de la addenda.

Por ejemplo el namespace de la factura digital es : xmlns="http://www.sat.gob.mx/cfd/2" junto con otras dos que por ahi aparecen.

Alguien del foro tendra una factura "real" de Pemex que haya pasado la validacion?

Por cierto !!! www.validacfd.com.mx ya valio!!!!

[mesquivelh]

Muchas gracias dado, espero que tu suposición sea correcta.

[dado]

Si, parece que el validador de Hacienda falla al validar las Addendas, estoy trabajando en una Addenda para Mapfre y un colega me proporciono una factura hecha por el prestigiado programa de Aspel.

Recalco lo de "prestigiado" ya que aunque no son una autoridad considero que emplearon muchos recursos para desarrollar un buen producto.

Al tratar de validar dicha factura me muestra los siguientes datos:

El sello del comprobante es válido:
Se presentaron los siguientes errores al validar la estructura del comprobante C:\Users\Desktop\Addenda_Amis (Aspel).xml
Error: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'ECFD'.

Realizando validación del sello con un certificado interno
Certificado usado : 00001000000001924752
El comprobante incluye un certificado codificado
Cadena original:
||blah|blah||
Digestión MD5 de cadena como HEX:
c876a849de4b1a6cfe4d9becd5f6970e
El sello del comprobante es válido

Asi que aunque no es una prueba "de fuego" si es una muestra de que el validador de hacienda se hace bolas con las addendas

[nejamube]

Pues como en big brother, las reglas cambian para factura electronica.

http://elempresario.mx/centro-soluci...ra-electronica

[jourdan]

Señores vengo saliendo de una junta y según me dicen para el 2011 va a haber cambios para los contribuyentes que quiran expedir sus propios comprobantes electronicas ya que estos van a tener que ser autentificados en tiempo real por un Proveedor Certificador Autorizado (van a ser empresas autorizadas por el SAT para autenfificar los CFE), con esto, los que desarrollamos algun sistema vamos a tener que contratar de todas maneras a un tercero autorizado por el SAT para que válide los comprobantes emitidos por nuestros sistemas.
Alguien sabe más de esto?
Gracias y saludos

[nejamube]

Creo que no es en una junta donde lo escuchaste, lo leiste en el link que puse anteriormente.

Saludos !.

[[AzidRain]]

Una pregunta para todos, tengo un cliente al cual le desarrollé un software de facturación hace ya algunos años, factura un promedio de 200 documentos diarios. Hace como 3 meses le comenté sobre esta nueva disposición y que habría que tener en cuenta porque no es algo que se pueda echar a andar en poco tiempo, pero le pareció que no tendría problema (él) cuando llegara el momento.

Mi pregunta es de acuerdo con su experiencia, ¿Que tiempo en promedio se requeriría para adaptar un software a esta nueva disposición?. Les comento que mi software trabaja vía internet y el software de contabilidad de mi cliente lo hace de la misma forma además de permitir el registro al momento de facturar, la pega sería nada más todo el rollo de los sellos y demás.

Más que nada porque le quiero dejar claro a mi cliente que si no se decide en x tiempo yo ya no me puedo hacer responsable por hacer esa adaptación precisamente por falta de tiempo.

[jourdan]

Empezado por nejamube

Creo que no es en una junta donde lo escuchaste, lo leiste en el link que puse anteriormente.

Nejamube, el articulo del cual pusiste el enlace mencionan que podran coexistir los dos esquemas, es decir el que uno podrá solicitar sus folios y el nuevo en el que hay que verificar los comprobantes en linea atraves de un proveedor autorizado, la información que me mostraron hoy por la mañana menciona que todos tendremos que verificar nuestros comprobantes por un verificador autorizado por el sat. A ver si alguien puede ampliar o validar esta la información
.
Saludos

[nejamube]

1. Modelo 2010, antes del 31 de diciembre del 2010.-



Comprobantes Fiscales Digitales CFD (Factura Electrónica) obligatorios para todos los contribuyentes en operaciones mayores a dos mil pesos. En este rubro continuarán vigentes, después de diciembre del 2010, los esquemas actuales de CFD (emisión propios medios y terceros), en donde los requisitos no sufren ninguna modificación. Este esquema coexistirá con el nuevo modelo que tomará vigencia en enero del 2011.


2. Modelo 2011, a partir del 1 de enero del 2011.-



Al utilizar este esquema, se debe remitir el CFD al SAT o al prestador de servicios autorizado por la autoridad para validar los requisitos estipulados en el artículo 29-A del Código Fiscal de la Federación, asignar número de folio e incorporar el Sello Digital del SAT, para después enviar dicho documento validado al receptor.

“Entre los beneficios de este nuevo modelo desaparece el requisito de contabilidad electrónica (sólo se tendrá que registrar en la contabilidad interna de la empresa) y el reporte mensual, además de acelerar las devoluciones de impuestos. El documento se debe resguardar durante 5 años y tiene convivencia con los esquemas actuales”, según la Asociación Mexicana de Estándares para el Comercio Electrónico, AMECE-GS1 México.








http://elempresario.mx/centro-soluci...ra-electronica

[dado]

jourdan

El termino que estan usando es "timbrar" (recuerdan la Ley del Timbre, yo creo que no, muchos de nosotros ni siquiera existiamos).

Aqui hay una presentacion que me parece interesante http://www.slideshare.net/faroviejo/facturas-digitales

Tambien he visto que "estaran conviviendo los dos esquemas", es decir el de Medios Propios como lo hemos desarrollado y mediante el timbrado con el SAT.

Hay un blog interesante donde mencionan 5 (si!! CINCO) esquemas que van a estar vigentes....aqui

AzidRain

Acerca de cuanto tardaras en implementar, te comento que (perdon la vanidad) soy un programador experimentado y me tarde 3 meses en convertir un programita de factura convencional a factura electronica.

Sabes? lo mas dificil de un programador no es la programacion "per se" si no mas bien el contexto....deja me explico con un ejemplo inventado....

Supon que un programador muy fregon de repente le piden hacer el software para que controle un hospital, debe controlar los medicamentos, las salas de operacion (el horario etc), los costos, la entrada y salida de ambulancias, etc etc.

Pareceria simple, pero quien (sin ofender, solo es un ejemplo) de nosotros sabe que fregados pasa dentro de un hospital.....

Entonces lo dificil va a ser, ver como se va a mandar la factura al SAT para el timbrado, mediante ftp? con www? SOAP? POAS? PAS PIS? y si ya tienes experiencia en eso, entonces es pan comido

[jourdan]

Empezado por dado

El termino que estan usando es "timbrar" (recuerdan la Ley del Timbre, yo creo que no, muchos de nosotros ni siquiera existiamos).

Dado, exactamente esto es lo que mencionaron hoy por la mañana, parece inclusive que la miscelanea fiscal de esto aún no ha sido publicada y son puros rumores de desarrolladores que tienen contacto con el SAT para hacer el outsourcing del timbrado.
Muchas gracias, voy a revisar la información que publicas.
Saludos

[jourdan]

Dado, esta excelente la información del blog que mencionas en tu mensaje anterior, gracias.

[JXJ]

Azid Rain,

yo calculo que como 1 mes mas o menos.

pues hay mas que solo los detalles de la generacion de la factura
sino tambien asuntos de la comunicacion con el SAT y el
tramite de los Certificados. y su administracion.

[[AzidRain]]

Gracias jxj, tomaré en cuenta el dato.

[Oscar Súchil]

Que tal soy nuevo en este foro, he estado siguiendo su foro y me parece bastante enriquecedor y retroactivo; pues bien me encargo de generar una solución de factura electrónica para la empresa que trabajo hasta ahora no he tenido problemas con la generación de mi xml y sello digital.... pero
me pidieron realizar como complemento un validador en forma de servicio para
todas las facturas que lleguen, de lo cual lo único que he podido avanzar es validar los folios y certificados pero el sello digital no tengo ni idea de por donde empezar; tomando en cuenta como genero el sello y tener en cuenta como sería el proceso inverso requiero lo siguiente:

> Archivo .Cer con el certificado referenciado por el no. de serie de las facturas recibidas
> Extraer la clave publica del .cer pasado a .pem
> utilizar la clave pública en otro archivo para desencriptar el sello digital
pasado a bytes y haber quitado la expresión en base 64 bits.


Y listo en teoría debería de obtener el mensaje encriptado ó al menos el MD5

Peeeeeeeero, mi problema es como espera el SAT que hagamos un validador por lote si nos pone solo su validador para hacerlo 1 x 1 en su página

../ValidadorComprobantes/Validador.html(todavia no me dejan poner links)

He querido descargar de esta pagina los certificados de los clientes que
me envian sus facturas, y nada mas no me deja

> Aqui accedo para descargar el .cer

../sitioaplicaciones/verifica_comprobante/
> Aqui debería de poder descargarlo
../tramitesdigitales.sat.gob.mx:9443/certisat/validate.jsp
Entonces aterrizando un poco mi duda, alguien sabe como debería de hacer
esta validación ya que es la más importante para saber si el contenido es ó
no el correcto?

O bien alguien conoce si el SAT ya hizo su chamba y publico algún otro ftp
ó web service?, ó bien alguien sabe como le hizo validacfd.com.mx para validar el sello?, chax de verdad que ando medio frustradon por esto es lo
último que me falta .

Agradezco cualquier info que tengan .

[skime]

Hola compañeros.... me acabo de integrar al foro... realmente yo no se mucho object pascal pero si puedo ayudarles en un codigo que tengo en vb.net y funciona bastante bien.... talvez uds lo pueden cambiar al lenguaje que mas les acomode, solo espero que si alguno de uds tiene un metodo con chilkat me lo haga llegar, con todo gusto lo puedo compartir

[Oscar Súchil]

Hola skime,

Pues me llevo bien con vb.net no habría problema yo tengo un proyecto
con lo que empece la facturación electrónica en chilkat pero la verdad
ya no lo continue por que teníar restricciones despues de 30 dias de uso
pero te lo puedo compartir esta programado en vb.net.

Ahora te explico no tengo problemas con la emisión si no con la recepción
utilizando openssl básicamente a continuación explico como estoy intentando
hacerlo:

Asi encripto:

open dgst -md5 -sign "claveprivada.pem" -out "md5.txt" "cadena.txt"

claveprivada.pem > clave para encriptar cadena original
md5.txt > resumen hash firmado de la cadena original
cadena.txt > archivo que contiene la cadena original a encriptar

Asi desencripto pero no me sale:

openssl rsautl -in sello.txt -out desencriptado.txt -inkey cer.pem -decrypt

cer.pem > certificado digital .cer convertido a .pem
sello.txt > archivo que contiene el sello digital en .txt


Este último código no funciona pero me gustaría saber si lo estoy haciendo bien el desencriptado?

Agradezco cualquier ayuda de ustedes.

[skime]

Empezado por Oscar Súchil

Hola skime,

Pues me llevo bien con vb.net no habría problema yo tengo un proyecto
con lo que empece la facturación electrónica en chilkat pero la verdad
ya no lo continue por que teníar restricciones despues de 30 dias de uso
pero te lo puedo compartir esta programado en vb.net.

Ahora te explico no tengo problemas con la emisión si no con la recepción
utilizando openssl básicamente a continuación explico como estoy intentando
hacerlo:

Asi encripto:

open dgst -md5 -sign "claveprivada.pem" -out "md5.txt" "cadena.txt"

claveprivada.pem > clave para encriptar cadena original
md5.txt > resumen hash firmado de la cadena original
cadena.txt > archivo que contiene la cadena original a encriptar

Asi desencripto pero no me sale:

openssl rsautl -in sello.txt -out desencriptado.txt -inkey cer.pem -decrypt

cer.pem > certificado digital .cer convertido a .pem
sello.txt > archivo que contiene el sello digital en .txt


Este último código no funciona pero me gustaría saber si lo estoy haciendo bien el desencriptado?

Agradezco cualquier ayuda de ustedes.

----------

Que ondas amigo.... no habia leido con atencion el código que pusiste.... yo unicamente utilizo OpenSSL para crear la conversion de la clave privada a PEM, despues de ahi todo lo hago por medio de bouncycastle..... te puedo mandar el codigo pero no se si aqui en el foro se me permita darles mi cuenta de email para que me agreguen y explicarles bien... me encuentro en completa disposicion a aportar este engorroso y fastidioso tema generado por la ignorancia de los informaticos del SAT