Factura Electronica México

[dado]

ORO !! ya esta la informacion publica acerca del timbrado.

http://www.validacfd.com/phpbb3/viewtopic.php?f=9&t=232

Saludos,

[E=M*C^2]

Hola Dato, solo quiero comentar que para el timbrado el archivo no será enviado por al SAT, debe ser enviando a un proveedor que es quien esta autorizado por el SAT y que cada proveedor define la forma en que va a recibir y dar respuesta del firmado.

Por lo tanto no va a existir un estándar.

Saludos

[lcarrasco]

Empezado por E=M*C^2

Hola Dato, solo quiero comentar que para el timbrado el archivo no será enviado por al SAT, debe ser enviando a un proveedor que es quien esta autorizado por el SAT y que cada proveedor define la forma en que va a recibir y dar respuesta del firmado.

Por lo tanto no va a existir un estándar.

Saludos

Creo que si el SAT autorizara a estos proveedores, deberia (es mi teoria al menos) definir que debe de haber un estandar, si me imagino todo sera por web services creo que lo mas produente por parte del SAT seria que definiera una misma interfase o protocolo de metodos que defina el webservice de cada PAC para hacerlo, de lo contrario sera un poco de caos si cada PAC tiene su propia definicion de webservice, metodos, etc y llevara a los clientes a un "lock-in" es decir a estar casados con el PAC a menos que el cliente tenga la facilidad de tener a un programador que logre migrar otro PAC si asi se desea.

En fin, solo teorias, ya que hay poca informacion.

En canto tenga algo concreto lo comentare por este medio para hacer publica la informacion por el bien de la comunidad.

Saludos!

[ContraVeneno]

hombre... ¿pos cuantos años tienes viviendo en México?

"...el SAT debería...", pues sí, debería, lo "lógico" sería crear un método estandarizado... pero cuando una institución es regida por políticos, lo "lógico" pocas veces se usa.

"...llevara a los clientes a un "lock-in" es decir a estar casados con el PAC ...", pues con la voracidad que algunos demuestran, no veo otro escenario diferente al de "ya te tengo amarrado"... ¿cuanto se tardaron en darle un esquema abierto a los afores?

[E=M*C^2]

Yo creo que ese “debería” no aplica, es lo mismo que sucede hoy en día con las facturas pre-impresas, el SAT autorizo un monto de impresores, pero no estandarizo nada, solo dio unos lineamientos, pero nunca dijo cuantas copias, ni cuanta tinta, ni de que tamaño la letra…en fin, dio unos requisitos y de ahí para adelante que cada uno se haga bolas.


Ahora bien, da proveedor va a poner las reglas de como conectarnos y esto lo va a hacer por varios motivos, uno de ellos tecnológicos, otro por recursos y otro por costos; no solamente es por gusto ni por factor ganancias.


También es cierto que ya vivimos con una realidad, parecida, y son las adendas, cuantas adendas no existen en el mercado, en diferentes formatos, estándares…en fin tenemos todo un lio con eso y nadie la ha podido estandarizar, la AMECE trato de sacar un estándar y tuvo que aceptar 2: XML y EDI, pero además de eso no todos cumplen al 100 % con el estándar, conozco empresas que te piden la adenda de AMECE pero con ciertas características adicionales o especiales; pero eso no es lo peor existen empresas que manejan varias adendas al tiempo…repito toda una locura.


Debería el SAT estandarizar el proceso de integración con el PAC?, Desde mi humilde punto de vista: NO, es algo que debe dejar al mercado, en donde la competitividad por un mejor servicio permita que el proceso mejore y los costos disminuyan.

[[Al González]]

Empezado por E=M*C^2

[...] es lo mismo que sucede hoy en día con las facturas pre-impresas, el SAT autorizo un monto de impresores, pero no estandarizo nada, solo dio unos lineamientos, pero nunca dijo cuantas copias, ni cuanta tinta, ni de que tamaño la letra…en fin, dio unos requisitos y de ahí para adelante que cada uno se haga bolas.[...]

Con la diferencia, mi estimado Darío, de que esta vez se trata de algo electrónico que pretende aprovechar la tecnología informática para facilitar las cosas tanto a los contribuyentes como al gobierno, y, como toda solución informática de uso público, debe aspirar a regirse por normas estándares. Por tanto, en mi opinión no es válida esa comparación.

Si lo que han dicho ustedes, sobre que el SAT [organismo del fisco en México] deja aspectos clave de este asunto de la factura electrónica "a criterio" de otras entidades, entonces el SAT comete un grave desacierto en detrimento de quienes se supone debe beneficiar este cambio.

Empezado por E=M*C^2

Debería el SAT estandarizar el proceso de integración con el PAC?, Desde mi humilde punto de vista: NO, es algo que debe dejar al mercado, en donde la competitividad por un mejor servicio permita que el proceso mejore y los costos disminuyan.

El mundo viene equivocándose desde hace tiempo con esa ambigua bandera de la competitividad. Van por ahí los pragmáticos de bolsillo argumentando que se deje todo o casi todo en manos de competidores, pues los espectadores (consumidores, público, ciudadanos) habrán de darle el triunfo al que haya desarrollado la mejor solución. Pero la misma Historia nos muestra cómo el que gana no siempre es el que mejores beneficios otorga, incluso habiendo sido elegido democráticamente (Bush hijo).

Hay cosas que conviene dejar a la azarosa competitividad e incluso a los designios del, hoy, semidiós mercado; pero hay otras, como los estándares, que definitivamente NO.


Y sí, tal como me pediste, habré de hacer una revisión general de tu biblioteca (bendita Razón, dejaste de llamarle "librería"), pero ahora te pido que durante estas semanas (o meses) de espera te des el tiempo para leer alguna obra de Víctor Hugo. Eso puede contribuir a que la siguiente versión de la misma salga un poco más humanizada (nótese el sentido figurado) y la comunidad la reciba con mayor gratitud, mi hermano.


Y a los oportunistas les ruego dejen el traje de vendedor en casa, pues esto es Club Delphi (donde la riqueza se construye con cada aportación desinteresada), no el mercadillo.

Un abrazo estándar.

Al González.

[E=M*C^2]

Empezado por Al González

Y sí, tal como me pediste, habré de hacer una revisión general de tu biblioteca (bendita Razón, dejaste de llamarle "librería")

AL, bienvenido sea cualquier comentario que contribuya a mejor la biblioteca. Estaré atento a cualquier sugerencia que realices tu o cualquier miembro de la comunidad, ya que unos de los objetivos al liberarla es obtener retroalimentación de todos ustedes.

Empezado por Al González

Y a los oportunistas les ruego dejen el traje de vendedor en casa, pues esto es Club Delphi (donde la riqueza se construye con cada aportación desinteresada), no el mercadillo.

Me uno a esta petición.

[[AzidRain]]

Les comparto un link con más información sobre los aspectos tanto técnicos como legales, aquí.

[nuk3zito]

Empezado por Al González

...
Y a los oportunistas les ruego dejen el traje de vendedor en casa, pues esto es Club Delphi (donde la riqueza se construye con cada aportación desinteresada), no el mercadillo.
...

Esta es una de las contadas veces que puedo estar de acuerdo contigo. Me uno a tu petición.

[[AzidRain]]

Perdon Dado, no vi que ya habias puesto el mismo link.

[nuk3zito]

Empezado por AzidRain

Perdon Dado, no vi que ya habias puesto el mismo link.

Si no me equivoco, esa página la hizo dado para estos fines.

[JXJ]

yo estoy a la espera de un documento igual o semejante
al de la version 2 del cfd.

los datos son estos. lo opcional es aquello.
la cadena original la obtines asi.
por que el XML de XSD, y el propuesto de que es y como se genera
la cadena original y que se usa SHA1.

y lo mas importante. despues de eso para mi es un validador. del
sat. a menos que el validador. actual mismo enlace
lo esten haciendo capaz de validar las diferentes versiones. del XML