ValidaCFD

Ja! que horror! muchas nóminas no lo hacen así, estuve viendo un ejemplo con solución factible y si pueden convivir diferentes tipos de percepciones, se me hace que edicom ya estuvo tirando la toalla con tantas validaciones, gracias por el dato.

acanas escribió:Agregando, al parecer el dato de la antigüedad es medio latoso de dejar contento al PAC con su validación porque si manejas IMSS parece que debe expresarse la cadena en semanas y si es ISSSTE debe expresarse en año,mes, dias, a lo mejor esos atributos condicioneales donde expresas no. de seguridad social automáticamente te trata de validar con un formato u otro.

Confirmo lo dicho bro (Acanas)...es tal cual...la diferencia es que en el caso de IMSS la cadena se expresa en semanas (por lo de semanas cotizadas) y el ISSTE en años...y, sí, es medio latoso, pues no queda otra

crono81 escribió:Segun soporte de edicom, si tienes algun otro concepto a parte de esos tres, no se puede. No se por que esos tres conceptos no pueden convivir con cualquier otro dentro del mismo recibo, la solución que ellos me dieron, es hacer otro recibo a parte.

Efectivamente, hablé con soporte edicom y como que los agarré en curva con esa pregunta(no daban con bola), hice la prueba separando la prima de antiguedad y sólo así me deja timbrar, al parecer el principal motivo es que el atributo TotalSueldos no debe ser incluido si se están declarando percepciones tipo 022,023,025 las cuales forman parte del elmento SeparacionIndemnizacion.

acanas escribió:Al timbrar con edicom les ha salido este error ?

com.edicom.ediwinws.service.cfdi.CFDiException: NOM225: TotalSeparacionIndemnizacion y el elemento SeparacionIndemnizacion, no deben existir. Ya que la clave expresada en TipoPercepcion no es 022 ó 023 ó 025.

El SAT nos mandó a los PAC una lista de códigos de error de las cosas que quieren que validemos antes de poder timbrar y el error NOM225 dice



Así que yo quiero pensar que por algún motivo interno de EDICOM ellos decidieron no dejarlos pasar, o al menos yo no he encontrado razón para no permitirlos.

Anexo un XML timbrado de pruebas y el acuse de recepción que me manda el SAT.

Y si puedes ayudame validando en mi pagina https://www.lacorona.com.mx/fortiz/sat/cfdcvali.php

Saludos

Hola fortiz, de hecho ya había revisado el fuente de tu validador en github y si noté ese detalle del nom225 como un error desconocido o no determinado, en edicom no me supieron decir si estaba bien o mal. Hice una prueba con la nómina que le da problemas a edicom en tu validador y noté que al parecer tienes un pequeño error en la validación del totalizado de los importesGravados de las percepciones contra el total de Nomina.Percepciones.TotalGravado, quizás debas manejar un pequeño margén de error pero en la calculadora hice la totalizada y me dio correcto, de hecho he pasado más de 200 recibos de nómina en edicom de prueba y por conceptos de totales no he tenido errores, el único problema ha sido sus validaciones con respecto a los tipos de percepcción 022,023 y 025 que no pueden convivir con el resto (sólo te deja timbrar si las dejas sólas en el nodo de percepcciones).

acanas escribió:Al timbrar con edicom les ha salido este error ?

com.edicom.ediwinws.service.cfdi.CFDiException: NOM225: TotalSeparacionIndemnizacion y el elemento SeparacionIndemnizacion, no deben existir. Ya que la clave expresada en TipoPercepcion no es 022 ó 023 ó 025.


Lo raro es que en mis percepciciones tengo identificado el tipo de percepcción como prima de antiguedad (022) y de todos modos me sale el error de validación, será un bug en el validador de edicom?

.
.
<nomina12:Percepcion ImporteGravado="0.00" ImporteExento="16528.94" Concepto="PRIMA DE ANTIGUEDAD" TipoPercepcion="022" Clave=3502-0010-0000" />
<nomina12:SeparacionIndemnizacion TotalPagado="16528.94" NumAñosServicio="9" UltimoSueldoMensOrd="14046.02" IngresoAcumulable="14046.02" IngresoNoAcumulable="2482.92" />
</nomina12:Percepciones>

A mi me salio un error similar con otro PAC y fue debido a que tenia tambien en el mismo recibo una percepción relacionada con JubilacionPensionRetiro.

El PAC me comentó que ellos hacen más de 300 validaciones en los recibos de nómina 1.2 adicionales a los implementados dentro del XSD, incluso las tienen numeradas y en el mensaje de error mandan el numero.

Aqui tuvimos que implementar pre-validacion XSD y muchos ajustes a la UI para no tener problemas con la variedad de combinaciones en los recibos de nómina.

Todas estas validaciones de la versión 1.2 están causando bastantes problemas, por ejemplo "NumEmpleado" antes aceptaba algo como "013 - 3145" pero en la 1.2 se tuvieron que cambiar a "013-3145", osea no acepta los mendigos espacios entre el guión! esto lo limitaron directo en el XSD.

Nuestra plataforma experimento bastantes ajustes por culpa de la dichosa versión 1.2, nos tomó 7 veces mas implementar la v1.2 en comparación a la v1.1, el problema fue que la 1.1 era muy liberal y los clientes ya tienen bastante información en las bases de datos, tuvimos que hacer muchos ajustes..

A pesar de toda la bronca en que nos metió el SAT, la verdad comprendo que fueron necesarias todas las mejoras, el SAT no puede hacer minería de datos con la 1.1 ya que el 70% de los recibos a nivel nacional están mal hechos, RFCs de empleados que no existen, errores en los cálculos totales, incluso facturas con percepciones totales de $1,000.00 pesos pero arriba en el total del cfdi le ponen $1,000,000,000.... jajaja!

Por cierto ya vieron el validador masivo de RFCs del SAT? es increible el cuate que diseño esa porqueria, te pide subir un archivo TXT con un formato de pipes ( | ) bastante absurdo y tedioso de construir, no es más fácil que pusieran un simple TEXTAREA y pegar ahi los RFC sin pipes y tanta burrada!?!?!?!

meximaster, te recomiendo que antes de timbrar corras una validación de esquema contra tus xml y de esa manera te evitas un buen de problemas ya que de entrada estás validando la estructura antes de mandar el documento a timbrar y solo te concentras en los validaciones propias de la nómina que son numerosas.

Ecodex acaba de enviar un comunicado con un nuevo catálogo de tipo de deducción y percepción.
Lo adjunto a este post.
En la página del SAT no hay nada nuevo publicado

Vaya a última hora actualizan el archivo de catálogos, dejaron el mismo nombre y no pusieron ninguna noticia arriba, si bajan el catCFDI_.xls se van a dar cuenta que hicieron más cambios, estos del sat que puu%%%%%%%% que se decidan de una vez por todas!!

Ahora agregaron como 75 deducciones nuevas y cada una tiene aplicación para gravado y exento, ya me había dicho un contador que en la versión 1.2 se habían equivocado al quitar deducciones exentas y gravadas ya que para hacer ajustes antes se podia poner una deducción gravada o exenta según se necesitaba, ahora terminaron haciendo las cosas mal agregando 2 deducciones por cada percepción como "Ajuste en Horas extra Exento" y "Ajuste en Horas extra Gravado", es decir, el esquema 1.1 manejaba deducciones gravadas y exentas correctamente.

Incluso en el XLS viene la ultima fecha de modificación: 30/12/2016, 15:35:55, Alberto Salinas Alva

En la pagina solo dice:
*Última modificación 28 de octubre de 2016
**Última modificación 13 de diciembre de 2016

A ver con que otra sorpresita sale SATanas! que desmadre!!

Justo estaba viendo eso, revisando las deducciones no estaba seguro si se me habían pasado o habían actualizado el archivo sin mencionar nada, las últimas dicen que tienen vigencia a partir de junio, supongo que es mejor no considerarlas por el momento.