ValidaCFD

Quien realiza la Validación en este momento el PAC o Hacienda?
Acabo de realizar unas pruebas y me regresa la antigüedad incorrecta, pero según mi lógica es correcta, Ejemplo:

Fecha de Contratación: 27 de Junio del 2011 y Fecha Final Pago: 25 de Enero del 2015. Mi rutina indica: P3Y6M29D ( 3 Años, 6 Meses, 29 Días ).
o puede indicar: P03Y06M29D, Y esta es la lógica que utilizo:

Al 27 de Junio del 2012 va 1 año; al 27 de Junio del 2013 van 2 años, al 27 de Junio del 2014 van solamente 3 años.
Al 27 de Julio, va 1 mes, al 27 de Agosto van 2 Meses, al 27 Septiembre van 3 Meses, al 27 de Octubre van 4 Meses, Al 27 de Noviembre van 5 Meses, Al 27 de Diciembre van 6 Meses.
Del 28, 29, 30 y 31 de Diciembre son 4 Días y si le sumas los 25 días del 1 al 25 de Enero, son 29 días.

Y ellos me indica que esta incorrecta.

PepePaniagua escribió:Quien realiza la Validación en este momento el PAC o Hacienda?

El PAC tiene esa responsabilidad, es uno de los encargos mas importantes del PAC, validar que la informacion este correcta y sellar digitalmente si todo esta bien

Te comento de forma extraoficial que los PAC tambien estan sufriendo mucho con esto, entre ellos mismos no se ponen de acuerdo, como comente en un mensaje anterior el problema es que el SAT puso una regla REGEX que al parecer no es correcta*


___________________________________
*solo como informacion de referencia, estoy suscrito a un foro privado en donde los PAC discuten esto y otros temas, por confidencialidad no puedo publicar abiertamente toda la informacion ahi contenida, pero creo que puedo formar mi propia opinion y tratar de ayudar en la medida de lo posible.

Quien realiza la Validación en este momento el PAC o Hacienda?
Acabo de realizar unas pruebas y me regresa la antigüedad incorrecta, pero según mi lógica es correcta, Ejemplo:

Primo: Para no meterme en problemas lo hice de la siguiente manera y funciono con edicom

truncar((fechafinal-fechainiciolabores+1)/7). Si por ejemplo el resultado es 88 le indico que es semana P88W

DADO Muchas gracias por el tip. Me lleve bastantes horas un desarrollar un select para obtenerla en ese formato y ahora me dicen que no es correcta...

spaniaguag Primo, que gusto encontrarte aquí, aun que no sabia que tenia un "pariente"
La voy a cambiar a semanas dejándola asi: Select Trunc(((C.PRD_END_DT - E.CMPNY_SENIORITY_DT)+1)/7) NumSemanas
Y mañana la prueba de fuego con mi PAC.

Hola buenas tardes...
Como le están haciendo con su PAC/SAT para el tema de horas Extras?
Según la guía el nodo hijo de Horas Extra en especifico en el atributo HorasExtra para reflejar el Numero de Horas, este debe de ser tipo xs:int
, sin embargo, nuestra en nuestra nomina, si utilizamos fracciones, es decir, si alguien trabaja solo media hora, entonces solamente se le paga media hora extra, yo lo estoy representando como .5 , pero mi PAC me lo rechaza indicando que solamente se permiten números enteros...

Si lo trunco, se arregla el problema, pero esto mostraría en el recibo (pdf del empleado) información diferente de la que realmente es...

Veo varios detalles interesantes en los conceptos de la versión 1.2:

En el catálogo de percepciones quitaron la clave 016 "Otros"

En el catálogo de percepciones quitaron la clave 017 "Subsidio al empleo"

En la nueva tabla de TipoOtroPago pusieron la clave 999 donde aparentemente se pueden manejar "Pagos distintos a los listados y que no deben considerarse como ingreso por sueldos, salarios o ingresos asimilados."

Considerando todo esto existen varias interrogantes:

Para manejar "OTROS" en percepciones ahora se debe usar la clave 038 de "Otros ingresos por salarios"?

Ahora para manejar el subsidio se tiene que usar la clave 002 de c_TipoOtroPago?

Ahora si hicieron un desmadre en la nomina, a pesar de no ser contador lograba encontrarle logica a la version 1.1 pero con la 1.2 ahora si ya valio.

Es una buena observación, prodrias por lo pronto truncar al entero superior y compenzar con el importe.
Mientras sale la version 1.3 de nomina
O no se si contablemente solo se pueda enteros realmente

Es correcto meximaster, esos conceptos se movieron y queda como 038, y el subsidio pasa a ser "otro pago"

PepePaniagua escribió:Hola buenas tardes...
Como le están haciendo con su PAC/SAT para el tema de horas Extras?
Según la guía el nodo hijo de Horas Extra en especifico en el atributo HorasExtra para reflejar el Numero de Horas, este debe de ser tipo xs:int
, sin embargo, nuestra en nuestra nomina, si utilizamos fracciones, es decir, si alguien trabaja solo media hora, entonces solamente se le paga media hora extra, yo lo estoy representando como .5 , pero mi PAC me lo rechaza indicando que solamente se permiten números enteros...

Si lo trunco, se arregla el problema, pero esto mostraría en el recibo (pdf del empleado) información diferente de la que realmente es...

El campo de número de horas extra es INT por lo que vas a tener que hacer un roundup, no hay otra manera, los del SAT se volaron la barda para variar, asi como esto hay miles de cuestiones que se suelen manejar en las nóminas y que no cuadran con lo que propone SATanas.

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>

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.