Página 1 de 1
Diferencias en criterios de validacion de fechas
Publicado: Mar Mar 15, 2011 7:48 pm
por rescamilla
He tenido varias discusiones con algunos proveedores ya que el validaCFD marca como error una fecha que se le incluye zona horaria p.e.
2011-03-11T11:18:17-06:00 ellos alegan que en el Anexo 20 del CFF menciona que la fecha debe especificarse usando el estándar ISO8601 y que el estándar permite la inclusión de la zona horaria lo cual es correcto, pero mi argumento es que en ese mismo apartado del Anexo se menciona de manera explicita el formato a seguir en este caso solo se menciona aaaa-mm-ddThh:mm:ss y no menciona la inclusion de la zona horaria y no dice solo cualquier formato que vaya con ese estándar sino menciona solamente ese en particular, según un proveedor esto esta revisado y aprobado por "funcionarios de tecnologia del SAT" y afirman que es valido con o sin zona horaria, sera???

Re: Diferencias en criterios de validacion de fechas
Publicado: Mar Mar 15, 2011 8:54 pm
por Dado
rescamilla escribió:He tenido varias discusiones con algunos proveedores ya que el validaCFD marca como error una fecha que se le incluye zona horaria p.e.
2011-03-11T11:18:17-06:00 ellos alegan que en el Anexo 20 del CFF menciona que la fecha debe especificarse usando el estándar ISO8601 y que el estándar permite la inclusión de la zona horaria lo cual es correcto, pero mi argumento es que en ese mismo apartado del Anexo se menciona de manera explicita el formato a seguir en este caso solo se menciona aaaa-mm-ddThh:mm:ss y no menciona la inclusion de la zona horaria y no dice solo cualquier formato que vaya con ese estándar sino menciona solamente ese en particular, según un proveedor esto esta revisado y aprobado por "funcionarios de tecnologia del SAT" y afirman que es valido con o sin zona horaria, sera???

"Dimelo a mi" que soy el autor del ValidaCFD y me llueven detalles como este........mi argumento es que EXPLICITAMENTE esta definido el formato aaa-mm-ddThh:mm:ss Y PUNTO, no hay especificaciones sobre zona horaria.
Por otro lado, dile que no....exagere, "aprobado por funcionarios del SAT", ello JAMAS van a aprobar o desaprobar aplicacion alguna, lo han dicho varias veces.
Re: Diferencias en criterios de validacion de fechas
Publicado: Mié Mar 16, 2011 9:05 am
por rescamilla
Dado aprovechando el tema de las fechas lo que si creo que hay un detalle en el validador, es la validación del atributo de fecha dentro del nodo de información aduanera, ahi en anexo 20 menciona el formato solo de fecha aaaa-mm-dd y tengo varios documentos que me marca el error y el formato si viene de acuerdo a lo expresado en dicho anexo y creo que tal vez estes comparando con el mismo criterio de fecha del nodo documento y en este caso son diferentes formatos.
Re: Diferencias en criterios de validacion de fechas
Publicado: Mié Mar 16, 2011 9:15 am
por Dado
rescamilla escribió:Dado aprovechando el tema de las fechas lo que si creo que hay un detalle en el validador, es la validación del atributo de fecha dentro del nodo de información aduanera, ahi en anexo 20 menciona el formato solo de fecha aaaa-mm-dd y tengo varios documentos que me marca el error y el formato si viene de acuerdo a lo expresado en dicho anexo y creo que tal vez estes comparando con el mismo criterio de fecha del nodo documento y en este caso son diferentes formatos.
Si tengo programado la distincion cuando es una fecha principal de una fecha de aduana.
Pero si tengo un problemilla por ahi que ya estoy corrigiendo, la situacion se presenta :
Cuando es un CFDI version 3 y tiene una fecha aduanal del 2010, esta combinacion arroja un "para cfdi v3 la fecha debe ser 2011"
Es este tu caso?
Re: Diferencias en criterios de validacion de fechas
Publicado: Mié Mar 16, 2011 10:23 pm
por rescamilla
No, es un caso de un CFD version 2.0 y el formato de la fecha es correcto de acuerdo al formato especificado para ese atributo aaaa-mm-dd en el Anexo 20.
Re: Diferencias en criterios de validacion de fechas
Publicado: Jue Mar 17, 2011 8:08 am
por Dado
rescamilla escribió:No, es un caso de un CFD version 2.0 y el formato de la fecha es correcto de acuerdo al formato especificado para ese atributo aaaa-mm-dd en el Anexo 20.
OK, lo reviso y si es necesario una correccion la aplicare en la proxima version del Valida
Re: Diferencias en criterios de validacion de fechas
Publicado: Mar Mar 22, 2011 11:48 am
por rescamilla
Este es un correo que se recibió como respuesta del SAT desde el 2005 y es el argumento de mi proveedor para hacer valida la fecha.
Reciban un cordial saludo, fíjense que AMECE recibió una factura electrónica a la cual se le hicieron las validaciones requeridas, sin embargo tengo una duda, el comprobante tiene fecha de: “2005-08-22T10:40:35-05:00” pero según especificaciones del ANEXO 20 la fecha debería ser hasta “2005-08-22T10:40:35” es decir, quitandole el “-05:00” cuando le comenté al proveedor me dio el siguiente argumento que quiero consultar con ustedes antes de dar por buena la factura:
1. El anexo 20 dela Resolución Misceláneadel 1 de septiembre de 2004, en su inciso C, define el "estándar de comprobante fiscal digital", en cuyo apartado relacionado con los atributos, al definir la fecha dice textualmente: "Atributo requerido para la expresión de la fecha y la hora de expedición del comprobante fiscal. Se expresa en la forma aaaa-mm-ddThh:mm:ss, DE ACUERDO ALA ESPECIFICACIÓN ISO8601".
2. Si la referida norma no hiciese mención a una norma ISO, indudablemente que la interpretación del texto precedente sería puntual; sin embargo, la sola mención a dicha norma ISO hace mandatoria la consideración de la "representación léxica" de dicho atributo y para eso es necesario remitirnos a las recomendaciones del W3C.
3. Las citadas recomendaciones del W3C, particularmente la relacionada con el apartado 3 (Built-in datatypes), al definir el "xs:dateTime" establece en el numeral 3.2.7 los valores del atributo dateTime, en el numeral 3.2.7.1 la representación léxica y en el numeral 3.2.7.3 las "timezones".
dateTime:
'-'? yyyy'-'mm'-'dd'T'hh':'mm':'ss ('.'s+)? (zzzzzz)?
Timezone(zzzzzz):
(('+'|'-') hh':'mm) |'Z'
4. Ahora bien, si la pregunta es ¿es obligatoria la incorporación de la zona horaria en la expresión del atributo "dateTime"? la respuesta claramente es NO, ya que la propia recomendación del W3C la define como opcional.
5. Si la pregunta es ¿es recomendable la inserción de la zona horaria? la respuesta es SI, ya que eso facilitará su lectura por sistemas automatizados cuya ubicación difiera de la zona horaria en la que fue expedido el CFD.
6. Finalmente, si la pregunta es ¿su inserción viola la definición del Anexo 20 dela Resolución Miscelánea?, la respuesta definitivamente también es no, ya que la cita dela norma ISOpermite el uso de los atributos tal y como son definidos por los estándares internacionales.
Conclusión:
La inserción de la zona horaria de expedición de un CFD no viola la norma ni modifica la estructura definidas por el SAT parala expedición Comprobantes FiscalesDigitales, se trata simplemente de un atributo que lo hace susceptible de ser integrado de manera natural a sistemas ubicados en distintos husos horarios.
Re: Diferencias en criterios de validacion de fechas
Publicado: Vie Mar 25, 2011 6:46 am
por rescamilla
Dado, otra sugerencia para el proximo release, tocando el tema nuevamente de las fechas en la información aduanera, me tope con una factura que trae en la fecha de importacion "2204-05-06" se pudiera validar que por lo menos las fechas de esta informacion aduanera no sean mayores a la de la fecha de emisión del CFD??

Re: Diferencias en criterios de validacion de fechas
Publicado: Vie Mar 25, 2011 6:54 am
por Dado
rescamilla escribió:Dado, otra sugerencia para el proximo release, tocando el tema nuevamente de las fechas en la información aduanera, me tope con una factura que trae en la fecha de importacion "2204-05-06" se pudiera validar que por lo menos las fechas de esta informacion aduanera no sean mayores a la de la fecha de emisión del CFD??

Mensaje recibido. Pero si revisa ese detalle, lo pone como una observacion "Fecha Futura...", pero le echo una checada, no esta de mas.