Nuevo complemento de nómina versión 1.2

[figarogdl]

las últimas dicen que tienen vigencia a partir de junio

Yo entendí a partir del 6 de enero (dd-mm-aaaa)

[jggtz]

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 ...etcy el error NOM225 dice

Código: Seleccionar todo

125	
Otro error no documentado.	
NOM225	
Error no clasificado.	
Si se identifica un error que no esté tipificado en los registros previos se mostrará este mensaje.

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.

Creo que aqui se explica el error de cuando existen percecpiones de finiquito combinadas con percepciones 'normales'

Sab Dic 17, 2016 4:58 pm

Hola, buenas tardes, no se si ya leyeron la actualización a la guía que acaba de actualizar el SAT este 13 de Diciembre. En especifico en la pagina 35, hay una indicación que en lo particular me va a causar bastantes cambios tanto en proceso como en sistemas...

En esta nota mencionan que si en TipoPercepcion se contiene uno o mas de las siguientes claves: 022 Prima de Antigüedad, 023 Pagos por Separación, 025 Indemnizaciones, 039 Jubilaciones, pensiones o haberes de retiro en una sola exhibición y 044 en parcialidades, entonces no se podrá incluir en el mismo comprobante otras claves distintas a estas.

[meximaster]

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.

Las nuevas deducciones son definitivas y son necesarias para realizar ajustes a la nómina, el problema es que si no los integras los usuarios van a acabar usando el "Otros" cuando el SAT ya estableció las reglas del juego con 2 claves para cada tipo de ajuste.

Esto es bastante delicado y absurdo, el problema es que los del SAT si no piden una banana entonces rebuznan.

[JCFlores]

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>

Tu error está en la clave= no tiene comillas antes del valor

[acanas]

Al timbrar con edicom les ha salido este error ?
Tu error está en la clave= no tiene comillas antes del valor

en realidad ese es un error de copy paste de un extracto de un xml, ya nos ilustraron de que esta recientemente documentado en la guía del SAT (ver página 35) que no se pueden mezclar otros tipos de percepciones diferentes a las de separaciones e indemnizaciones en un mismo recibo de nómina, razones? no tengo ni la menor idea de porque obligan hacer 2 recibos de nómina para los casos de separación laboral, pero así se encapricho el SAT.

[CexarE]

Buenas Tardes:

He buscado en todas las respuestas algo relacionado al "Banco" y la "CuentaBancaria" cuando se paga en efectivo.

¿Sabra alguno de ustedes como se utilizan estos campos cuando el pago al empleado es en "Efectivo" o por medio de un "Cheque" ?

Agradecere las respuestas. Saludos...

[acanas]

Buenas Tardes:

He buscado en todas las respuestas algo relacionado al "Banco" y la "CuentaBancaria" cuando se paga en efectivo.

¿Sabra alguno de ustedes como se utilizan estos campos cuando el pago al empleado es en "Efectivo" o por medio de un "Cheque" ?

Agradecere las respuestas. Saludos...

Puedes dejarlo en null o simplemente omitirlos del xml de la nómina si el pago es en efectivo, en caso de ser cheque o transferencia si deberías considerarlos.

[CexarE]

Gracias acanas...

[rickge]

Hola
Me he topado el caso de un trabajador cuya antigüedad es de 1113 semanas,
al expresarlo como : P1113W, el Pac retorna el error:

l comprobante no cumple con la estructura de un XML valido. Error: Element '{http://www.sat.gob.mx/nomina12}Receptor', attribute 'Antigüedad': [facet 'pattern'] The value 'P1113' is not accepted by the pattern 'P(([1-9][0-9]{0,3})|[0])W|P(([1-9][0-9]?Y)?([1-9]|1[012])M)?([0]|[1-9]|[12][0-9]|3[01])D'. ,Error: Element '{http://www.sat.gob.mx/nomina12}Receptor', attribute 'Antigüedad': 'P1113' is not a valid value of the local atomic type.

Me da la idea de que solo permite 3 caracteres, porque con P999W, sí pasa la validación

Alguien más a tenido este problema?

Gracias

[figarogdl]

al expresarlo como : P1113W, el Pac retorna el error:

Pues según el pattern

Código: Seleccionar todo

P(([1-9][0-9]{0,3})|[0])W

sí debería pasar
Puedes validarlo aquí: http://regexr.com/3f0tb

Sería bueno revisarlo con el PAC, yo supongo que depende de la implementanción del RegExp que cada PAC realizó.