ValidaCFD

Ese campo debería ser irrelevante en una factura global ya que se trata de una factura no deducible. (Sólo mi opinión).

Les traslado una pregunta ya que me encuentro en una situación que no se muy bien como voy a atacar.

Nuestra aplicación permite generar CFDi 3.2 desde inicio y también puede modificar los datos de aquellos CFDi que no están sellados ni timbrados.

A partir del 15 de Julio a la hora de remitir al PAC -> SAT será obligatorio que MetodoDePago lleve el valor del catálogo, pero que sucederá si alguien modifica un CFDi 3.2 de la versión anterior. (esto claramente solo podrá pasar en un intervalo de 72 horas por la validez del CFDi) Quiero decir, el cfdi no llevará el valor del catálogo aún sino el valor anterior que era un texto libre.

¿Están realizando una conversión a modo de texto contra el catálogo nuevo? Ya que si digamos es un combobox no estarian permitiendo añadir texto libre y lo correcto sería emplear un catálogo...

Espero que haya sido lo mas claro posible con la duda existencial.

Muchas gracias por sus opiniones.

Saludos.

Buen dia, para eso y me imagino que vas agregarle un nuevo campo a la tabla de facturas referenciando la nueva CLAVE del metodo de pago, si esta en nulo ese campo, a obligar al usuario a capturarlo, asi de facil...

Nosotros en nuestra aplicacion Safari de facturacion ya estamos aplicando un combo box desde este momento

No nos esperamos a que fuera obligatorio, tambien eso nos da tiempo de que la actualizacion automatica haga su trabajo para que el 15 de julio ya todos esten actualizados

Asi que esa seria mi recomendacion, ya aplica el catalogo

agag4 escribió:Buen dia, para eso y me imagino que vas agregarle un nuevo campo a la tabla de facturas referenciando la nueva CLAVE del metodo de pago, si esta en nulo ese campo, a obligar al usuario a capturarlo, asi de facil...

El campo no estaría nulo, hablo de editar la factura, el campo ya tiene un valor "antiguo" que era un texto libre y ahora le estaría obligando a emplear un "combo" por lo cual no podria "mapear" el texto del formato antiguo con el formato del nuevo.

DADO escribió:Nosotros en nuestra aplicacion Safari de facturacion ya estamos aplicando un combo box desde este momento

No nos esperamos a que fuera obligatorio, tambien eso nos da tiempo de que la actualizacion automatica haga su trabajo para que el 15 de julio ya todos esten actualizados

Asi que esa seria mi recomendacion, ya aplica el catalogo

Y en caso de estar editando una factura no te estaría sucediendo lo mismo? O quizá la aplicación vuestra de Safari no permite editar una factura que no fue ni sellada ni timbrada?


Muchas gracias a ambos por vuestras contestaciones.

En el Safari ya NO permito editar una factura que no fue sellada ni timbrada, la pongo en una cola de espera y la timbro mas adelante como esta

Si hay algun cambio el usuario debe cancelar esa factura y volver a hacerla

Y por supuesto no digo que esa es la "mejor opcion", depende de cada usuario y de cada programador, es solo la forma en que yo lo hago

Yo me refiero , que si tienes un sistema de factura electronica desarrollado por ti, lo más facil es meter un campo nuevo para la clave nueva de metodo de pago sobre la tabla donde guardas tus facturas, ese campo estaría en nulo para las facturas ya almacenadas y si intentas modificar alguna para re-Timbrarla ese campo seguira en nulo asi OBLIGARAS al usuario a elegir el metodo de pago acorde al catalogo nuevo...

saludos...

JackMorton escribió:

agag4 escribió:Buen dia, para eso y me imagino que vas agregarle un nuevo campo a la tabla de facturas referenciando la nueva CLAVE del metodo de pago, si esta en nulo ese campo, a obligar al usuario a capturarlo, asi de facil...

El campo no estaría nulo, hablo de editar la factura, el campo ya tiene un valor "antiguo" que era un texto libre y ahora le estaría obligando a emplear un "combo" por lo cual no podria "mapear" el texto del formato antiguo con el formato del nuevo.

DADO escribió:Nosotros en nuestra aplicacion Safari de facturacion ya estamos aplicando un combo box desde este momento

No nos esperamos a que fuera obligatorio, tambien eso nos da tiempo de que la actualizacion automatica haga su trabajo para que el 15 de julio ya todos esten actualizados

Asi que esa seria mi recomendacion, ya aplica el catalogo

Y en caso de estar editando una factura no te estaría sucediendo lo mismo? O quizá la aplicación vuestra de Safari no permite editar una factura que no fue ni sellada ni timbrada?


Muchas gracias a ambos por vuestras contestaciones.

Claro, si tuviera detrás una base de datos sería perfecto, el problema es que yo trabajo con el XML mapeado con mis objetos de Factura CFDi 3.2, es decir no tengo ningún campo de mas ni de menos que tenga el comprobante CFDi 3.2.

La opción que creo que usaré es que cuando el texto insertado en la factura no se encuentre en el catalogo y no se pueda mapear lo dejaré en blanco obligando a que el usuario vuelva a seleccionar pero esta vez del catalogo.

De nuevo muchas gracias a todos por vuestra ayuda.

Este cambio lo puede hacer el PAC osea ustedes...

al enviarles la factura remplazan el campo con la clave segun el texto encontrado en el nodo metododepago
si yo envio un xml como tradicionalmente lo hago metododepago = "efectivo" ustedes
lo remplazan por metododepago = "01"
si dentro del nodo tengo la palabra cheque la reemplazan por "02" y asi sucesivamente.

luego lo timbran y lo regresan
eso nos ahoraria mucho tiempo y dinero a todos sus usuarios.

No funcionaria por lo siguiente

Porque para ello tendriamos que definir un catalogo de frases, eso debido a la gran variedad de formas que pueden presentarse, por ejemplo :

Transferencia bancaria
Transferencia electronica
Transferencia de fondos

Cheque
Cheque nominativo

....y los que se te ocurran, y si definimos un catalogo, pues caemos en lo mismo, mejor usamos el catalogo de claves del SAT

Por otro lado hay un problema, incluso legal, en el que NO podemos modificar el XML, para ello necesitariamos autorizacion por escrito, y no solo eso, tendriamos que tener tu certificado y llave privada (secreta, confidencial) para poder alterar el XML y volverlo a sellar.

Creeme, no seria buena idea lo que propones