ValidaCFD_cl V0.2 con opcion a Red y Monitoreo de carpeta

[Dado]

@cmarquez

FTP. Me es dificil descubrir el error "desde aqui", para una conexion a internet hay mil variables, proxis, firewalls, lo ultimo que se me ocurre es que hagas un "port forwarding" desde tu router, es una funcion en la que defines que TODO el puerto 20 y 21 se pase SIN NAT'S o Firewalls o NADA hacia el ValidaCFD_cl

"Datos no valido para....(vacio)". Ese es un tema que ya habia expuesto en el foro te paso la conclusion : EL XML ESTA MAL DEBES REGRESARLO AL EMISOR, si quieres mas explicacion, comentarios etc visita el foro mencionado y puedes expresar tu opinion.

Emisor.RFC no aparece en la lista.......deja investigo de que se trata.

Dado, buenas tardes

1. Insisto en éste foro porque considero oportunidad de mejora a ValidaCFD_cl; trato de explicar:

La factura

IMSA_P00230_2011-01-17_GDE-3736_CFD.xml

la reporta con sello invalido unicamente ValidaCFD_cl.

Califican el sello como valido SAT y http://www.misfacturas.net

Adicionalmente, xsltproc genera la cadena original con los "||" intermedios.

No encuentro en el anexo 20 la indicacion de que no se permiten "||" intermedios. Dice que la cadena inicia y termina con un "||", pero no restringe explicitamente los intermedios.

Es claro que si hay otro error por la falta de país, pero pido no considerarlo en éste momento.

No es un caso frecuente, pero pregunto: ¿porque devolver una factura por sello invalido cuando otros validadores lo califican como válido?

2. Acerca de actualizacion de base de datos, ¿que problema habría para agregarle a ValidaCFD_cl la funcionalidad de actualizar a partir de archivos en disco? Esto porque ya tenemos programada la descarga automatica desde SAT por medio de FTP.

Pipes intermedios.....dice el anexo 20, la cadena original INICIA con doble Pipe y TERMINA con doble pipe.....

Imagina la siguiente cadena

||2.0|A|123454||AAA010101XXX|Concepto1||

Las COMPUTADORAS van a seguir la orden.....TERMINAR en doble pipe :

Cadena Original = ......||.....2.0.....|....A.....|....12345....|| OK, doble pipe FIN DE CADENA!!!...conclusion, NO SE PERMITE DOBLE PIPE INTERMEDIO ya que ese el el indicador para FIN DE CADENA, queda implicito que esta prohibido intermedio.

Ahora, como los abogados.....YA EN MAS DE UNA OCASION EL SAT HA MENTIDO TERRIBLEMENTE y por andar ajustando el ValidaCFD al validador oficial se han cometido errores fatales.

EJEMPLO mas claro es el caso MD5 / SHA1, tuve enormes quejas que "como permitio el ValidaCFD" validar documentos firmados con MD5 estando en el 2011, mi respuesta era "porque el validador los acepta, yo tambien los tengo que aceptar" PERO cambio el validador (no me quiero acordar del lunes negro del 3-ene) y corrigieron ese error.

De cualquier manera, la validacion ES MUCHO MAS QUE EL Sello de Valida/no valida. Los datos vacios ESTAN PROHIBIDOS y tienes (me parece) 3 de ellos, eso es motivo suficiente para rechazar el XML y son precisamente los que provocan el doble pipe.

Tambien en el anexo 20 "los datos opcionales no expresados NO APARECERAN EN LA CADENA Y NO TENDRAN DELIMITADOR ALGUNO", tambien dice "Cada dato individual se encontrara separado de su dato subsiguiente en caso de existir mediante un pipe"

El dato (vacio) no es precisamente un dato, es una de las reglas de computacion, si una cadena="" entonces la cadena "no existe" es vacia.

Un dato vacio ROMPE CON MAS DE 5 REGLAS ! el resultado es un XML INVALIDO (nota que no puse "sello invalido" ya que el CFD es TODO el XML y no solo un sello)

Por ultimo, El validador del SAT NO LO ACEPTO ! Este es parte de tu mensaje :

pero aprobado por el validador del SAT:

Resumen del análisis del XML
Archivo XML :IMSA_P00230_2011-01-17_GDE-3736_CFD.xml
Ruta :C:\Users\cmarquez.IMSAAIB\Documents\CFD\IMSA_P00230_2011-01-17_GDE-3736_CFD.xml
Estructura :
1 Dato no válido para el atributo 'no. Exterior'
2 Dato no válido para el atributo 'estado'
3 Dato no válido para el atributo 'país'

Insisto, la validacion NO ES UNICAMENTE EL SELLO......

Por ultimo, creeme, corregir este "detalle" es agregar dos palabras por ahi a mi codigo fuente, cambiar de false(falso) a true (verdadero) en cada uno de los atributos, de verdad te digo, estoy dedicando mas tiempo esfuerzo y palabras a este mismisimo mensaje que cambiar tres "false" por tres "true" y recompilar, no es porque no quiera cambiarlos, es porque creo firmemente que el SAT esta mal y no seria la primera vez en que yo tengo la razon (despues de todo, detras del validador del SAT esta gente comun y corriente como nosotros, no son mejores o peores, cada quien hace su mejor esfuerzo)

[cmarquez]

Dado, buenas noches

Entiendo el punto de vista acerca de "pipe doble intermedio", me parece lógico pero no práctico: el hecho de haber error por valores vacios no justifica error en el sello. Insisto que xsltproc y www.misfacturas.net generan una cadena original que da como resultado un sello válido.

En consecuencia, vamos a llevar a cado acciones para complementar el proceso de recepcion de facturas:
- Agregar al proceso de descarga de archivos desde sitios de SAT, ValidaCFD y SEPOMEX, proceso de borrado e inserción en tablas de MySQL.
- Agregar que antes de ejecutar ValidaCFD_cl verifique si el XML incluye certificado. En caso de no haberlo, descargar por ftp certificado público al directorio temp.
- Agregar proceso que había sido desarrollado como prototipo de validacion, combinando ejecuciones de xsltproc y openssl, para verificar resultado de la validación de sello hecha por ValidaCFD_cl.

[jsand]

Como me puedo contactar con alguno de ustedes para adquirir sus servicios????

[Dado]

Como me puedo contactar con alguno de ustedes para adquirir sus servicios????

Enviame un mail a la direccion que aparece en mi firma y me dices en que puedo ayudarte.....saludos.

[rescamilla]

Una pregunta Dado, te comento que debido a que los contadores (por lo menos los de mi empresa, conste que no generalizo) se aferran mucho al validador del SAT y confian ciegamente en este, me cuestionan muchas de las validaciones que hace tu programa que obviamete son bastante completas y exhaustivas, pero siempre salen con el argumento de que si el validador del SAT no les marca error entonces es bueno el documento (aunque no cuadre ni papa) y ahi te encargo al rato cuando les requieran todos los XML "dados por buenos". La pregunta es tendrás el soporte documental (Oficial) donde se especifican todas y cada una de las validaciones que hace tu programa para yo tener elementos para justificarle tanto a ellos como a nuestros proveedores el rechazo de su documento y por ende la contraprestacion que amapara dicho documento.

[Dado]

Una pregunta Dado, te comento que debido a que los contadores (por lo menos los de mi empresa, conste que no generalizo) se aferran mucho al validador del SAT y confian ciegamente en este, me cuestionan muchas de las validaciones que hace tu programa que obviamete son bastante completas y exhaustivas, pero siempre salen con el argumento de que si el validador del SAT no les marca error entonces es bueno el documento (aunque no cuadre ni papa) y ahi te encargo al rato cuando les requieran todos los XML "dados por buenos". La pregunta es tendrás el soporte documental (Oficial) donde se especifican todas y cada una de las validaciones que hace tu programa para yo tener elementos para justificarle tanto a ellos como a nuestros proveedores el rechazo de su documento y por ende la contraprestacion que amapara dicho documento.

Normalmente no me gusta comentar acerca de las mejoras que pienso hacer para no "quedar mal" ya que suena como a promesa que talvez tarde en cumplir, pero te adelanto :

Estoy trabajando en la "version 0.2" de los validadores, entre las opciones que tengo en mente son:

1. Hacer un "wiki" de los errores, en los que los mismo usuarios me ayuden a redactar uno o dos parrafos que describan el error, como se puede corregir y el fundamento legal, este "wiki" estaria accesible dando clic en el error que arroja el valida

2. Respaldo de la base de datos de los CFD almacenados (es increible, pense que no se usaba mucho esta opcion, pero resulta que si, he tenido ultimamente muchas sugerencias al respecto)

3. Opcion de que trabaje en red (oye s3cr3to, te serviria esta opcion?)

4. Validacion multiple y no de "corto ciruito", esta opcion se explica bien con el atributo "certificado", resulta que al certificado se le pueden hacer por lo menos 5 validaciones, anteriormente al primer error se detenia y no continuaba, ahora pienso dejar toda la "cadena" de validacion, por ejemplo, vigencia, aparicion en el listado oficial, validacion del numero de serie, validacion de si es FIEL o CSD, validacion de la relacion RFC-certificado, etc.

5. Posibilidad de descargar los listados de forma fraccionada para no tener que descargar toda la lista cada vez.

6. Verificar que no se registre dos veces la misma factura.

7. Opcion de programar "mi RFC" de forma que valide tambien si es una factura "con mi RFC" (este caso fue curioso, una persona valido una factura y todo bien, sin ningun error y sin ninguna observacion, todo bien......PERO! era una factura equivocada, que no iba dirigida a su empresa, simplemente era otra factura cualquiera y la metio a su contabilidad como si nada.....despues de todo era valida..........je je je)

etc.

Y lo dicho....esta es una parte de las ideas que tengo, que lleguen a concretarse quien sabe

[rescamilla]

Dado te entiendo, aunque los planes no son promesas para los usuarios mortales normalmente es asi en fin creo que es muy interesante todo lo que pudieras hacer, bueno en mi caso uso tu validador como motor, pero todo el manejo está en Web, por lo que para los ojos del usuario es una aplicación de red . Lo que te sugiero para la parte de "mi RFC" sería mas bien mis RFCs (un catalogo) porque si manejas varias razones sociales puedes incluso clasificar para que razón social va cada CFD y así almacenarlo y las que no descartarlas, eso justamente hace mi aplicación antes de validar, y tanto la recepción como la respuesta con el resultado de validación se envía via correo electrónico automatizado.

La parte del "wiki" es una buena opción para revisar y discutir fundamentos técnicos y legales pero quisiera saber de donde puedo obtener el documento oficial base con todas la especificaciones para los CFD.

[Dado]

Dado te entiendo, aunque los planes no son promesas para los usuarios mortales normalmente es asi en fin creo que es muy interesante todo lo que pudieras hacer, bueno en mi caso uso tu validador como motor, pero todo el manejo está en Web, por lo que para los ojos del usuario es una aplicación de red . Lo que te sugiero para la parte de "mi RFC" sería mas bien mis RFCs (un catalogo) porque si manejas varias razones sociales puedes incluso clasificar para que razón social va cada CFD y así almacenarlo y las que no descartarlas, eso justamente hace mi aplicación antes de validar, y tanto la recepción como la respuesta con el resultado de validación se envía via correo electrónico automatizado.

La parte del "wiki" es una buena opción para revisar y discutir fundamentos técnicos y legales pero quisiera saber de donde puedo obtener el documento oficial base con todas la especificaciones para los CFD.

Anexo 20 del CFF por supuesto, ahi esta TOOOODO.

[ccrux713]

DADO,
Esos planes me parecen excelentes que harían de tu programa mejor de lo que ya es. Ya he puesto otro correo, pero quiza a tu lista cabria agregar la cuestion de las facturas expedidas a extranjeros para que no efectue la validación en los datos del domicilio del cliente, ya que esa información no se encuentra en la base de datos de SEPOMEX.

Aprovecho este hilo para preguntar, se que el VALIDACFD no verifica correctamente aquellas facturas con addenda, incluso a mi varias me las marca como erroneas porque detecta que el total no corresponde con la suma de los importes de las partidas (conceptos) de la factura -subtotal menos descuentos mas traslados- pero es este un error "normal" o es que de alguna manera hay algo mal en el CFD?

Excelente trabajo amigo y muchas gracias por poner a nuestro alcance tan valiosa herramienta.

Claudio C.

[Dado]

DADO,
Esos planes me parecen excelentes que harían de tu programa mejor de lo que ya es. Ya he puesto otro correo, pero quiza a tu lista cabria agregar la cuestion de las facturas expedidas a extranjeros para que no efectue la validación en los datos del domicilio del cliente, ya que esa información no se encuentra en la base de datos de SEPOMEX.

Aprovecho este hilo para preguntar, se que el VALIDACFD no verifica correctamente aquellas facturas con addenda, incluso a mi varias me las marca como erroneas porque detecta que el total no corresponde con la suma de los importes de las partidas (conceptos) de la factura -subtotal menos descuentos mas traslados- pero es este un error "normal" o es que de alguna manera hay algo mal en el CFD?

Excelente trabajo amigo y muchas gracias por poner a nuestro alcance tan valiosa herramienta.

Claudio C.

Bueno hay que aclarar algunos puntos.

El programa NO VALIDA LA ADDENDA, pero el resto de la informacion si la valida.

Por otro lado el Total NO TIENE QUE VER NADA CON LA ADDENDA, literalmente la addenda no tiene valor fiscal asi que no debe haber datos ahi que afecten a los totales, subtotales, etc.

Si gustas enviame uno de tus XML a mi mail con los errores que reportas (rfc de extranjero y totales) para darle una revisada.