Anexo 20 version 3.3 y Recepción de pagos

[Dado]

Aver si no me salgo del tema pero tengo una pregunta que hacer ¿es viable generar la clase con xsd.exe del cfdv33.xsd? Lo que pasa es que pide a catCFDI.xsd y tdCFDI.xsd y termina siendo una motrucidad, lo digo por las pcs de poco desempeño. ¿Que recomiendan?

Va a haber tres momentos en los que se pueden validar los datos y asegurarse que cumplan con el catalogo :

Al momento de presentarle el formulario al usuario final, validar que solo capture datos validos

Al momento de insertar los datos en el XML (por ejemplo con nuestra libreria DLL, Servitimbre, etc, aqui es donde tu mencionas que seria muy lento con las PC de poco desempeño ya que el catalogo es bastante extenso)

Al momento de enviarlo a timbrar, el PAC debe validar nuevamente toda la informacion.

Nosotros aqui en casa vamos a eliminar la validacion por esquema (XSD), vamos a permitir que se inserte cualquier dato sin importar lo que sea, pensamos que la validacion es mejor llevarla a un nivel mas arriba, en el GUI que se le presenta al usuario. Eso significa que puedes editar el XSD, eliminar el catalogo y convertir todos los datos al tipo simple string

[shakira]

Gracias, DADO, como siempre muy acertado en tus comentarios.

[CETSIAT]

Buen día a todos los colegas, estamos en un proceso que todavía no están muy claros los procedimientos para cumplir con las definiciones del SAT en lo que se refiere a la versión 3.3.

Yo sugiero que asi como todos estamos ocupados en entender toda esta madeja de información, propongo que durante este diciembre y el mes de Enero, nos empapemos de todo este rollo y realicemos una reunion en algún lugar estratégico, para comentar los detalles y asi aprovechar la experiencia de todos los colaboradores.

Recordemos que el SAT, en cualquier momento puede cambiar lo que se le antoje, asi que estaremos muy atentos a estos posibles cambios.

Yo he estado recolectando información documental de varios despachos y apoyándome con algunos contadores, y todavía nos quedan muchas lagunas por entender bien este nuevo proceso.

En la medida que tengamos información que valga la pena, la estaremos compartiendo.

Asi que manos a la obra y a divertirnos en serio.

Saludos
Ing. Vega

[Dado]

.... realicemos una reunion en algún lugar estratégico, para comentar los detalles y asi aprovechar la experiencia de todos los colaboradores....

Yo apoyo la idea, hay que buscar algun patrocinador para el pago de alguna sala de juntas (espero que Ecodex me este leyendo )

Seria la "Primera Reunion de Programadores y despistados de la Factura Electronica"

[ramonzea]

Pues que mejor reunión que este foro; pues "semos" de muchos estados del país.



Saludos.

[jggtz]

Pues que mejor reunión que este foro; pues "semos" de muchos estados del país.

Apoyo la sugerencia

[Sinchi]

Consideren la posibilidad de poder participar remotamente por ejemplo Skype o Gotomeeting.

[ramonzea]

Podríamos empezar con dudas a la "redacción" del SAT, cosas del los nodos y los nuevos tipos de nodo condicionales.

Al menos, lo que yo he visto que los nodos del "manual" en PDF no corresponden al que viene en el XSD para generar el XML.

Saludos.

[meximaster]

Supuestamente los CFDI ya no van a poder ser cancelados si cuentan con al menos un "complemento de pago", la verdad no se como SATanas piensa que va a evitar los fraudes, ahora los estafadores van a emitir una nota de crédito en lugar de cancelar las facturas.

El complemento de pagos se ve muy complejo comercialmente, hay casos donde 1 ingreso corresponde a N facturas por lo que ahora se van a tener que rastrear N cantidad de complementos de pago, no suena nada bien...

Que desmadre, que desmadre! del punto de vista del programador esta fácil implementar la versión 3.3 pero para los clientes desde el punto de vista comercial es una locura, de milagro en estos momentos están generando los CFDIs correctamente y ahora aumentan el grado de dificultad al triple.

Platicando con algunos clientes aparentemente piensan generar la factura únicamente cuando se recibe el pago, es decir, no van a emitir facturas ni nada hasta que no se reciba el monto exacto de la operación, en muchos casos comentan que por culpa de los clientes que pagan a lo loco y fuera de tiempo van a terminar generando un volumen de facturas mucho más alto y un desmadre administrativo.

Me pregunto, cuando el cliente paga de mas como se debe manejar ese saldo a favor si el SAT establece que no se puede emitir un comprobante de pago con un importe mayor..

[Hugo Galindo]

Un gran problema que veo con lo de la cancelación es que hay facturas que en el momento que se expiden es porque ya se pagó el producto o servicio. Por consiguiente esas facturas ya contarán desde su elaboración con su complemento de pagos.

¿Qué va a pasar si por error el facturista le hace la factura a un cliente incorrecto? ¿Cómo diablos va a contactar a quien por error se le emitió una factura para que le "autorice" a cancelarla? Muchas veces simplemente no se cuenta con los datos de contacto.

Sé por experiencia que cuando a ti te retienen el recopilar los comprobantes de retenciones es un gigantesco problema porque a muchas empresas simplemente no se les da la gana perder el tiempo en darte la retención (siempre te dicen que sí pero nunca cuándo). ¿Se imaginan ahora con "por favor autorízame a cancelar una factura que te hice por error? Si, claro, segurito que van a ordenar inmediatamente a contabilidad que como prioridad te otorguen la autorización. Y eso si es que tuvimos la suerte de tener los datos de contacto.

Al menos el SAT debería permitir la cancelación incondicional de cualquier factura dentro de las 24 o 48 horas de su elaboración. Así un cliente que confirme su factura a los 3 días de su elaboración sabe que ya no se la pueden cancelar, y al mismo tiempo permite corregir errores normales en la emisión.

Aunque claro que el SAT normalmente no se destaca por sus brillantes ideas o por preocuparse de los problemas que puedan tener los contribuyentes.