Nuevo complemento de nómina versión 1.2

[meelboom]

El Servicio de Administración Tributaria (SAT) informó que, como una facilidad, los contribuyentes tendrán hasta el 31 de marzo de 2017 para seguir utilizando su actual sistema de emisión de nómina digital.

El administrador general de Servicios al Contribuyente del SAT, Adrián Guarneros Tapia, explicó que los contribuyentes que aún no migran a la nueva nómina digital, pueden emitir durante el primer trimestre del año su nómina como lo vienen haciendo.

Sin embargo, aquellos que utilicen la facilidad, a partir del 1 de abril de 2017, a más tardar, deberán volver a emitirla (retimbrar) ahora con las actualizaciones, expuso durante el taller “Nómina Digital” realizado por el Colegio de Contadores Públicos.

Orale! quiere decir que si voy a tener una navidad más tranquila.

Pues si y no, porque el mismo SAT menciona que vas a tener que retimbrar todas las nominas de 2017 que hagas en version 1.1. Lo que te ahorres de trabajo ahora lo terminaras pagando en Abril.

[acanas]

Así es, ya leí otros comunicados más claros y no vale la pena, es mejor terminar antes del 31.

[crono81]

Se pusieron bien estrictos los PACS con la validación de la nómina, digamos que es una probadita de como será el cfdi 3.3, algunas cosas que se me hicieron absurdas es que el concepto del compbrobante de nómina (el del cfdi 3.2) a fuerzas tienes que dejarlo literalmente como "Pago de nómina" y en los conceptos de las deducciones no aceptan puntos por si tienen I.M.S.S. o I.S.R deben eliminarlos antes de considerarlos en la nómina

Confirmo lo que expresa acanas, ahorita estaba haciedo pruebas y esto sucede con edicom, imagino que los otros va a ser lo mismo

[acanas]

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.

[crono81]

A mi el pac me dejó, al menos en el entorno de pruebas, con el mismo recibo los dos formatos de antigüedad. Pero si valida que la diferencia entre la fecha de inicio laboral y la de pago, sea igual en años, meses y dias que especificas

[acanas]

Ya pude timbrar varios pero tuve que a fuerzas ponerlo en formato de semanas, edicom no me dejó ponerle el formato de año,mes,días y eso que le ajuste los dias en varios intervalos para tratar de ver donde estaba el intervalo correcto, creo que tienen un bug en edicom pero bueno me doy por bien servidor con que soporte las semanas.

[Dado]

El problema del dato de antiguedad es general para todos los PAC

El detalle es que el SAT propuso una validacion REGEX que aveces es imposible cumplir :

FechaInicioRelLaboral: 2015-01-06
FechaFinalPago: 2017-01-30

Las expresiones válidas (sin tomar en cuenta el formato de semanas por el momento) según el estándar pueden ser:
P2Y23D
P2Y0M23D
Sin embargo estas no son aceptadas por la expresión regular porque no se permite omitir los meses ni poner 0M, por lo que el contribuyente pudiera tener estas dos opciones:
Siempre expresar la antigüedad en semanas
Hacer una adaptación para que cuando se tenga el caso de que M sea cero, se reste un año y se exprese como 12M, en el ejemplo anterior quedaría: P1Y12M23D, esta nueva expresión sigue cumpliendo con el estándar pero en mi opinión tiene menos sentido expresarlo así

[acanas]

Con razón no me pasaba la validación ya que tenía un caso igual, dada las circunstancias es mejor declararlo donde no tiene pierde y es hacerlo por semanas.

[crono81]

Yo para la prueba que hice de usar el formato años meses dias, fue un calculo raro, digamos 136 semanas, esto fue solo didactico para hacer la prueba:
136 semanas = 952 dias
952 / 365 = 2.608219178082192 años ya tenemos los años
0.608219178082192 años = 222 dias
222 / 30 = 7.4 meses ya tenemos los meses
0.4 meses = 12 dias
2 años 7 meses y 12 dias
El problema es que como no todos los meses tiene 30 dias el cálculo no es preciso, tuve que probar con 12, 13, 11, 14 y 10 dias hasta dar con
el bueno que no recuerdo cual fue.
Pero como comentan, lo más sencillo es lo mejor.

[acanas]

Como comentaba opté por definir la antigüedad en semanas, de esta forma estoy sacando las semanas:

int iNumSems = Convert.ToInt32(Math.Floor( ((TimeSpan)(nom.FechaInicialPago - nom.Receptor.FechaInicioRelLaboral)).TotalDays / 7D));

Si el total de días fuera 25, el resultado me da 3.5714 y esto es técnicamente 3 semanas y de momento me lo acepta el PAC de esta forma, solo me falta considerar si no se cumple una semana habría que expresarlo en meramente días.