Anexo 20 version 3.3 y Recepción de pagos

[luis_cfd]

Aquí dice como debe quedar:

http://www.sat.gob.mx/informacion_fisca ... _pagos.pdf

Saludos.

Esa guía de donde salió no me había tocado verla !, gracias

[ramonzea]

Igual está el del cfdi

http://www.sat.gob.mx/informacion_fisca ... nexo20.pdf

Saludos.

[s3cr3to]

Aquí varias dudas, ojala alguien conozca las respuestas:

1) La restricción de cancelar CFDi de facturas (pedir autorización al receptor) ¿aplica a las "notas de cargo"?
2) ¿Podremos cancelar CFDi de recepción de pagos sin pedir autorización al receptor?
3) ¿Se puede generar un CFDi de recepción de pagos para múltiples CFDi? Viendo el csd 3.3 veo que sí cuando es un mismo receptor/rfc.
4) ¿Se debe generar la representación de un CFDi de Pagos y enviar al receptor?
5) Si mis CFDs están con el método de Pago "PUE" (una sola exhibición), pero nuestros dichosos clientes, deciden pagar parcialmente (por su cuenta), ¿podré generar CFDi por cada pago recibido sin colocar la información extra que pide en caso de CFDi en parcialidades? Y es que ni siquiera sabemos si cliente pagará o si lo hará en una o varias exhibiciones. Imagino que lo fácil sería hacer que todos nuestros CFDi sean PIP o PPD (Pago inicial y parcialidades, Pago en parcialidades o diferido)
6) ¿Saben si se maneja alguna prorroga?

Gracias por sus respuestas... no dudo que estas dudas van a aumentar.

[luis_cfd]

A como viene en la guía de pagos, no hablan de pedir autorización al receptor en ningún caso, yo creo que este mecanismo fue algún sueño de alguien del sat, es complejo operativamente implementar algo así. Solamente dice que no se vale cancelar un cfdi inicial que tiene otro cfdi de pagos.

Parece ser posible hacer un cfdi de pagos para muchos cfdi, opino que dependerá del receptor, que nos diga si quiere un sólo cfdi o varios.

Lo de enviar al receptor el cfdi de pagos debe ser igual que con cualquier cfdi, se hace llegar todo al receptor, ahora sobre la representación impresa no he visto algún requerimiento especial, supongo que es igual que una factura, salvo el concepto predeterminado que debemos poner y el nuevo qrcode.

Lo de PUE, es un mal diseño del sat, en vez de ser 3 metódos de pago, deberían de ser 2 , contado y crédito y tantan. Pero bueno a atascarle, los clientes optan por cambiar sus formas de pago, si te dicen que es PUE y siempre no, pues hay que cancelarles el cfdi y hacerles otro .

Sobre prórroga no hay noticias pero apuesto mi tarjeta de video agp, a que el 30 junio lo aplazan, son muchos cambios no sólo técnicamente, sino operativos que van a mover el modo que se manejan controles internos, deja tu hacer que el usuario mortal elija el ClaveProdServ( de un catálogo de mas de 50,000 items) o que elija la ClaveUnidad( de un catálogo de mas de 3mil items), ese trabajo es del contador, apenas él tendría un mejor criterio y obviamente no lo hará el.

Satludos colegas

[meximaster]

Aquí varias dudas, ojala alguien conozca las respuestas:

1) La restricción de cancelar CFDi de facturas (pedir autorización al receptor) ¿aplica a las "notas de cargo"?
2) ¿Podremos cancelar CFDi de recepción de pagos sin pedir autorización al receptor?
3) ¿Se puede generar un CFDi de recepción de pagos para múltiples CFDi? Viendo el csd 3.3 veo que sí cuando es un mismo receptor/rfc.
4) ¿Se debe generar la representación de un CFDi de Pagos y enviar al receptor?
5) Si mis CFDs están con el método de Pago "PUE" (una sola exhibición), pero nuestros dichosos clientes, deciden pagar parcialmente (por su cuenta), ¿podré generar CFDi por cada pago recibido sin colocar la información extra que pide en caso de CFDi en parcialidades? Y es que ni siquiera sabemos si cliente pagará o si lo hará en una o varias exhibiciones. Imagino que lo fácil sería hacer que todos nuestros CFDi sean PIP o PPD (Pago inicial y parcialidades, Pago en parcialidades o diferido)
6) ¿Saben si se maneja alguna prorroga?

Gracias por sus respuestas... no dudo que estas dudas van a aumentar.

En cuanto a tus dudas:

1) La restricción de cancelar CFDi de facturas (pedir autorización al receptor) ¿aplica a las "notas de cargo"?
Las notas de cargo según hemos investigado si tienen restriccion en cancelacion y dicen que es por lo siguiente:
Si emites una nota de cargo y el cliente paga entonces el cliente cuenta con 2 facturas, la original y la nota de cargo del cobro adicional, si cancelas la nota de cargo causas el mismo problema fiscal que cancelando la factura original así es que también aplica el mismo criterio.

2) ¿Podremos cancelar CFDi de recepción de pagos sin pedir autorización al receptor?
En teoría no se deberían cancelar los CFDI de recepción de pagos ya que las transacciones bancarias no se borran, siempre se quedan en el histórico, esto lo puedes ver en bancos, paypal, tarjetas..etc, lo que hacen es generar una nueva transacción con signo negativo para anular el efecto de la anterior.

3) ¿Se puede generar un CFDi de recepción de pagos para múltiples CFDi? Viendo el csd 3.3 veo que sí cuando es un mismo receptor/rfc.
Si, un pago que corresponde a 5 facturas tiene que estar enlazado a cada una de ellas.

4) ¿Se debe generar la representación de un CFDi de Pagos y enviar al receptor?
Si.

5) Si mis CFDs están con el método de Pago "PUE" (una sola exhibición), pero nuestros dichosos clientes, deciden pagar parcialmente (por su cuenta), ¿podré generar CFDi por cada pago recibido sin colocar la información extra que pide en caso de CFDi en parcialidades? Y es que ni siquiera sabemos si cliente pagará o si lo hará en una o varias exhibiciones. Imagino que lo fácil sería hacer que todos nuestros CFDi sean PIP o PPD (Pago inicial y parcialidades, Pago en parcialidades o diferido)
En este caso el metodo de pago no es relevante ya que no somos adivinos, es imposible saber que va hacer el cliente, por lo tanto no importa lo que se ponga en metodo de pago, lo importante es generar los cfdi de recepción de pagos cuando se reciba el dinero.
Si emites una factura con PUE y tiene enlazados 2 cfdi de pago entonces quiere decir que a la mera hora el cliente no cumplió con lo pactado, metodo de pago ya es un campo "informativo" , lo que importan son las recepciones de pago.

6) ¿Saben si se maneja alguna prorroga?
Realmente la versión 3.3 es una exageración del SAT por el control que quieren tener.
Nadie está emitiendo facturas v3.3, ningún "grande" las emite ni tampoco puede recibirlas, traten de enviar un cfdi 3.3 a liverpool o soriana.
El SAT seguramente va a lanzar una prórroga para enero del 2018, no tiene sentido que coexistan las 2 versiones en un mismo periodo para efectos de minería de datos, si solo cuentan con 6 meses de facturas v3.3 no pueden generar automáticamente las declaraciones anuales que es lo que quieren hacer ya que no se cuenta con toda la información.
La fecha de mediados de año la pusieron para "probar" pero lógicamente no les ha funcionado, quien se va a meter ahorita en broncas cancelando facturas, emitiendo recepciones de pago..etc nadie, las empresas tienen broncas subsistiendo como para complicar las cosas más.
Todos seguramente van a esperar hasta el último minuto para lanzar la v3.3.

Otro punto interesante es la cancelación, como la cancelación ahora es complicada las empresas le están dando la vuelta al asunto, en lo que hemos trabajado con ciertas empresas es que el botón de cancelar ahora emite una nota de crédito en automatico, asi se estan evitando todo el proceso de cancelación, es chistoso como el SAT quita la cancelación pero deja un backdoor y las empresas lo saben aprovechar, los del SAT ponen restricciones a lo menso nadamas..

[ramonzea]

Yo tuve que implementar un proceso para cambiar por bloques las unidades de medidas y las claves de servicio, pero incluso haciendo pruebas con mis datos no hay claves exactas para equipos de computo, ni para tornillos, dice clavo o tornillo, "madera de tornillo" y no "tornillo de madera", por loq ue veo solo tradujeron literal, y el catálogo de unidades, sigue en inglés, y nada mencionan en el SAT.
En el caso de los de PAGO, entiendo que el CFDi si no lo pagan ya no es "PUE" si no "PPD" y luego haces los CFDi de pagos, pero aun veo lagunas pues la información que piden solo para un pago es mucha, imaginen las empresas que reciben cientos de transferencias a diario, o solo con decenas, y al menos como transmitirle tanto tecnisismo a los clientes cuando lo único que ellos quieren es vender y no pasarse media hora haciendo una factura y luego otra para cada pago.

Saludos.

[jyaver]

Hola buenos dias !

Saludos a todos, para molestar a ver si alguien cuenta con ejemplos de XML ya con complemento de Pagos en Ver CFDI 3.3 que pudiera hacerme el favor de compartir, de antemano muchas gracias...

[Dado]

Hola buenos dias !

Saludos a todos, para molestar a ver si alguien cuenta con ejemplos de XML ya con complemento de Pagos en Ver CFDI 3.3 que pudiera hacerme el favor de compartir, de antemano muchas gracias...

En este foro hay unos kit de desarrollo para CFDI V3.3, no estan totalmente terminados, pero puedes usar el Servitimbre para generar ejemplos de CFDI V3.3 con el complemento de pagos

[s3cr3to]

Gracias ramonzea y meximaster! muy interesantes sus aportaciones.

...Otro punto interesante es la cancelación,... es que el botón de cancelar ahora emite una nota de crédito en automatico, asi se estan evitando todo el proceso de cancelación, es chistoso como el SAT quita la cancelación pero deja un backdoor y las empresas lo saben aprovechar, los del SAT ponen restricciones a lo menso nadamas..

Caray, por la "auto-presión" olvidé las notas de crédito, que inicialmente había considerado.
Me agrado el enfoque de la cancelación del documento con nota de crédito.
Ahora, a la tarea de analizar si lo podemos aplicar desde ahora en v3.2, no será fácil, por la falta de control en la captura de notas de crédito.
Pero fue peor cuando por error cancelaron una factura pagada por error y lo detectamos semanas después.

Gracias!

[ramonzea]

Te anexo un ejemplo ya timbrado en prueba con un PAC.

Estoy armando el de Pagos, pero aún el origen de la info me ha sido un poco no entendible, y aún no se si algún PAC ya soporte la emisión.

Saludos.