Metodo de pago ahora debe usar clave

[Eduardo18]

Hola!

Entonces para confirmar, puedo poner:

01
01 Efectivo
Efectivo
NA

y todos son válidos?

El tercero, "Efectivo", es el único que no es válido.

Gracias!!!

[s3cr3to]

El tercero, "Efectivo", es el único que no es válido.

El 1ro de agosto, ¿el SAT responde/añadió esto en la pregunta #1 ?
http://www.sat.gob.mx/informacion_fisca ... o_Ago1.pdf

Preg1_20160801.png (24.07 KiB) Visto 11411 veces

[Jesus Castelo]

El tercero, "Efectivo", es el único que no es válido.

El 1ro de agosto, ¿el SAT responde/añadió esto en la pregunta #1 ?
http://www.sat.gob.mx/informacion_fisca ... o_Ago1.pdf
Preg1_20160801.png

Esto no aplica solo para los que usen esa aplicación de "Mis cuentas"?

Yo pongo la clave a dos dígitos en el XML y la clave junto con la descripción separados por un guion en la representación impresa. Estoy mal?

[s3cr3to]

Como dijo alguien, este acto de "terrorismo fiscal" nos dejó peor que antes del 15 de julio.
Dan tantas ganas de gritar "Cada quien ponga lo que quiera!" y de hecho así lo están haciendo (ver ejemplos).. pero.. la duda es: ¿será posible que el " " niegue la devolución/compensación de IVA en los comprobantes que no sigan estos (pseudo)estándares?

En el ejemplo que pone satán dice "01 Efectivo" (01 espacio efectivo), y alguien dirá "No dice que no se pueda usar otros signos para separar la clave de la descripción". y eh aquí como encontramos tantas variantes en producción: ejemplos reales con espacios omitidos a solo 30 caracteres:

Código: Seleccionar todo

,02
01
01,01,99
01,04
01EFECTIVO
02
02,01
02,4789
02-
02-Cheque
02-ChequeNom
02-CHEQUENOMI
02-Chequenomin
02BANAMEX
02Cheque
02CHEQUENOMIN
03
03,02,01
03-TRANSFEREN
03Transferenci
04
08
2
28
28:TarjetadeD
28TarjetadeD
98
99
CH
CHEQUE
CHEQUEBANAMEX
ChequeNominati
CLAVE2:CHEQUE
CONTADO
CREDITO
Deposito
DEPOSITOBANCAR
Desconocido
Efectivo
EFECTIVODLLS(
EFECTIVOMN
EFECTIVOMNE
NA
NoAplica
NoIdentificado
PAGOELECTRONICO
Pagoenunasol
Tarjeta
TARJETADEBITO
TARJETADEDEBI
Tarjetadedébi
TRANSFERENCIAB
TransferenciaE

------
"El diablo está en los detalles (y en la falta de detalles)"

[QenK]

Hay un nuevo dato permitido en MetodoDePago y es "pago"

Mas informacion en el primer mensaje de este foro

Ojo!

Lo que la regla fiscal dice es que el dato "pago" para MetodoDePago se colocará en el CFDI del complemento de pago (es decir, el que ampara el pago), NO en el de la factura. No es un dato para indicar que la factura será a crédito.

Es decir, que "pago" es el dato que se usará cuando se timbre un CFDI con total cero pesos y con un complemento de pago que apunte a una factura (esto ya que entre en vigor el complemento de pago).

[Sinchi]

Si, aplica a todos los PAC, todos los emisores, todo Mexico

No entiendo en que afecta a los PAC. Esta obligacion es solamente para el contribuyente. La ley no menciona en absoluto las obligaciones que tienen los PACs al respecto. Algunos pueden hacerse la vista gorda y seguir timbrando mientras que otros pueden poner controles que se este usando los codigos.

Es mas, no estoy tan seguro que el SAT tampoco los verifique cuando un PAC reporta los CFDIs timbrados.

[Dado]

Efectivamente, despues de una semana o talvez mas el SAT envio un comunicado diciendo basicamente que "es bronca del emisor que este dato vaya bien, el PAC no debe validarlo"

Se me ocurrio esa respuesta porque el usuario que originalmente pregunto me hizo pensar en aquellas disposiciones que solo aplican a un determinado grupo de emisores, como por ejemplo personas fisicas, empresas con ingresos menores a xyz cantidad, etc

Como no habia ninguna condicion del tipo que comento se me hizo facil decir que "era para todos"

Ahora, porque todos, incluyendo los PAC se pusieron tan nerviosos ?

Porque los PAC por ley deben validar la estructura de los XML, y por ley tienen permitido equivocarse solo 3 veces (si solo 3 !!!) si no les quitan la concesion, asi que ya te imaginaras que los PAC estaban ansiosos por saber si este cambio debian o no validarlo porque literalmente podian perder la chamba si se equivocaban.

[Sinchi]

Pues la frontera donde termina "validar la estructura de los XML" es discutible.
El schema de CFDI 3.2 no ha cambiado y sigue permitiendo cualquier valor, asi que un CFDI que no usa los nuevos metodos de pago con clave, es correcto desde el punto de vista de schema, que es lo que un PAC puede validar.

[acanas]

Así es los PACS no están validando los códigos de los métodos de pago como se había anticipado y tiene mucho que ver con ese temor de las equivocaciones ya como bien dice DADO el SAT no permite más que 3 errores sino cuello y precisamente no se si sea por eso que se estén retrasando mucho con la publicación oficial de la versión del esquema cfdi v3.3

[Sinchi]

Después de tanta confusión con esto del método de pago, conversando con un fiscalista, me comentaba que la legislación esta tan enredada que al final la resolución con el nuevo catalogo con los métodos de pago a usar despues del 15 de julio, perdió su validez debido a las resoluciones posteriores que por su formulación abrían nuevamente la puerta a diferentes interpretaciones muy abiertas que matan el propósito inicial, retrocediendo a practicas anteriores al 15 de julio.

Con otras palabras, el SAT se disparó a si mismo en los pies.

Pues a compartir experiencias buenas (SAT acepto CFDIs con metodos que usaba antes del 15/7) o malas (SAT me rechazo CFDI por ello).