FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Sobre el código QR
Se menciona que las facturas deberan de incluir un código QR, pero una duda que tengo es si ese código QR deberá de incluirse en TODAS y cada una de las páginas o solamente en la última página será suficiente.
Pues la manera que tengo implementada de impresión de mis facturas, la voy generando a medida que voy leyendo registros, y no es hasta el final de los registros, y puede ocupar más de una página, que obtengo los totales, calculo el IVA, etc... que es ahí cuando pretendo enviar a hacienda, obtener la huella y generar el QR para incustrarlo en la factura, pero claro, estoy ya situado en la última página y no puedo retroceder en las anteriores. No se si me explico. |
#2
|
||||
|
||||
Cita:
|
#3
|
||||
|
||||
Cita:
Creo que el orden es incorrecto. El enviar a hacienda debería ser lo último e independiente de lo demás. Por ejemplo, puede ser que no tengas conexión a internet e igualmente debes poder generar tu factura, firmarla y imprimirla (con el QR). Para posteriormente enviarla cuando puedas...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#4
|
|||
|
|||
Cita:
¿De qué me serviria imprimir una factura de la que no dispongo del registro OK de VERI*FACTU y su huella??? Vaya, es como veo yo que debería de trabajar mis datos para ahorrar fallos o errores. |
#5
|
||||
|
||||
Cita:
Siempre todo esto asumiendo que el funcionamiento va a ser similar a TicketBAI (que parece que si). Imagina una tienda cualquiera que genera tickets cuando compras una barra de pan, una prenda de ropa o cualquier otra cosa; Y que en ese momento se cae la conexión a internet o simplemente durante esa mañana tu operador ha tenido una incidencia y no tienes conexión. ¿No vendes? ¿No generas tickets/facturas? Se asume que tus facturas son correctas y por eso para generarlas no necesitas conexión a internet o conexión con la AEAT. Si la tienes bien, las envías, pero si no la tienes tu sistema DEBE seguir funcionando con normalidad y deberán "encolar" esos envíos para cuando puedas comunicarlas. Es una de las premisas. Si luego por lo que sea tu factura es incorrecta, pues deberás rectificarla y comunicarlo a la AEAT. Entiendo que si es un cliente al que le puedes "reenviar" la factura corregida (como se hace ahora), pues se la enviarás de nuevo. Y si es un cliente que se ha ido con un ticket, pues en ese caso no creo que se pueda hacer nada.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#6
|
|||
|
|||
Código de retorno
Cita:
No creo que la AEAT suministre un código de retorno para identificar cada documento que se le envíe. Si así fuera sería un cachondeo. Por un lado la AEAT dice que esperemos a tener 1000 documentos para hacer un envío o bien que pasen dos horas antes de enviar lo acumulado. Me imagino que una gran superficie o simplemente un supermercado de tamaño medio, o una ferretería, o una muebleria, o.... tengan que esperar para imprimir un ticket a un cliente dos horas. Sería sinceramente un puro cachondeo. Los datos del QR no tienen nada que ver con un código de retorno. Y menos mal ! Al menos es como yo lo veo. Un saludo. |
#7
|
|||
|
|||
Dictamen del CES (Consejo Economico y Social de España)
Aunque este dictamen versa sobre la Facturación Electrónica, hace varias puntualizaciones que creo que nos afectan. La que me parece más significativa es:
"El CES considera necesario que el Proyecto de Real Decreto garantice de forma explícita la coherencia con la propuesta de la Comisión Europea “IVA en la Era Digital”, "VAT in the Digital Age" en inglés, publicado el 8 de diciembre de 2022, y cuyo objeto es modernizar el sistema del iva de la Unión Europea, abordando los retos relacionados con la economía de plataformas e introduciendo un registro único a efectos del iva para evitar registros múltiples dentro de la Unión Europea. De esta forma, el sistema de declaración del iva para las transacciones transfronterizas de la Unión Europea se basará en la facturación electrónica y en la norma europea de facturación electrónica, y además a los Estados miembros que deseen establecer un sistema de declaración del iva para las operaciones nacionales, se les exigirá que también lo basen en la facturación electrónica. Así, la facturación electrónica se convertirá en el método de facturación por defecto antes de enero de 2028." Según entiendo yo, va a ser la Facturación Electrónica el punto de partida también para la declaración del iva, y no temas independientes y separados. Esto me genera aún más confusión. ¿ Que pensáis vosotros ? Podéis verlo en el siguiente enlace: https://www.ces.es/documents/10180/5.../Dic032024.pdf |
#8
|
|||
|
|||
Ley crea y crece vs ley veri*factu
Cita:
Son cosas paralelas y no excluyentes. Al igual que lo es el SII (sistema de información inmadiato) Aquí cada cual va por su lado. Por un lado se saca la ley "antifraude" o veri*factu para conocer lo que a la AEAT le interesa que no es mas que los importes del IVA, las bases imponibles para hacer cálculos de beneficios y que nadie pueda "extrapolar facturas". Eso ya lo había hecho con el SII para empresas de un cierto volumen de operaciones. Aunque el veri*factu es mucho mas restrictivo. En mi opinión el SII se eliminará y quedaremos todos en el veri*factu. (Es solo una opinión particular aunque algo parecido escuché en un weminar de la AEAT al respecto) Otra cuestión bien distinta es la denominada "ley crea y crece". En teoría es para que no se disparen los cobros y lo pagos en sus vencimientos respectivos. Esto lo promueve el Gobierno. NO sé donde ha quedado esa Ley de 60 días máximos de pago en los mismos estamentos del Estado. Otra cuestión que en teoría se persigue es automatizar los procesos de entrada y salida de documentos de forma semiautomática. En mi opinión solo sirve para contabilizar facturas de compra puesto que los procesos de entrada, pedidos y albaranes, son procesos previos a la emisión de la factura por parte del proveedor. Así que no se podrá verificar nada, salvo que la factura tenga las mismas condiciones que el albarán. La AEAT se ha prestado "desinteresadamente" para crear un portal con los webservices necesarios y el archivo de las facturas obligatorias. Por lo tanto se perfila mas que como un sistema de automatizacion, como un sistema de control, no solo de los cobros y pagos sino también de la totalidad de la factura. Precios, ofertas, condiciones, zonas, proveedores, tipos de artículos, etc.etc. Con todo lo que esto conlleva. En estos modelos van a hacer su agosto algunas plataformas de intercambio automático entre diversos tipos de facturación electrónica. Aquí si hay ya intercambio de pedidos, albaranes, tarifas, etc. pero el costo es algo abusivo, al menos para la mayoría de empresas. Para terminar, al final se terminará por anular la factura electrónica de cada país miembro de la Comunidad Económica Europea y se tenderá a un solo sistema unificado. Que de hecho ya hay, pero sin obligación por el momento de usarlo en cada país. NO recuerdo ahora mismo si este formato es el que hay que usar para las facturas intracomunitarias. Tendré que revisar la documentación, pero creo que de momento no. Disculpe, ese PDF ya lo leí en su día y antes de contestar no lo he leído de nuevo. Hablo pues de memoria, por si se me escapase algo. La opinión personal tal y como vd demanda no tiene mayor importancia. Eso es lo que va a ocurrir en breve. "Cosas mayores veréis, amigo Sancho" Un saludo. |
#9
|
|||
|
|||
Cita:
Luego si se lee la propuesta de la comisión (COM(2022) 701 final), se ve que hay una diferencia importante entre las facturas intracomunitarias, dónde la comisión quiere que pasen al 100% electrónico, y las facturas nacionales (donde la comisión no tiene las mismas competencias, si leo bien), donde se dice que hay que «modernizar las obligaciones de notificación a efectos del IVA mediante la introducción de requisitos de notificación digital, que normalizarán la información que deben presentar, en formato electrónico, los sujetos pasivos a las autoridades tributarias sobre cada operación» (1º parágrafo 3ª página, en la exposición de motivos). Para mi, esto suena muchísimo más a SII o Veri*factu que a facturas electrónicas tipo Factura-e. Entonces estoy en desacuerdo sobre el texto que has puesto en negrita: para mi entender no se exige pasar a la facturación electrónica en nacional; y no veo que será por esta razón si la facturación siga electrónica por defecto en 2028. Ahora bien, entiendo que se está generando confusión. Y lo veo así desde el principio, cuando surgen casi al mismo tiempo dos normas, con objetivos similares pero distintos, con implementaciones también distintas (hasta el punto que con lo que hay actualmente sobre la mesa, cada factura se debe declarar dos veces a las administraciones públicas, la cual cosa parece una locura), viniendo de dos ministerios distintos. Y creo que la clave está en lo último: detrás de esto hay luchas de poderes. |
#10
|
|||
|
|||
Cita:
En ello están ahora las asociaciones de empresarios en denunciar esto. |
#11
|
|||
|
|||
Cita:
Posiblemente sea igual De todas formas la hilera de hacerlo todo al final está bien para sistemas monousuarios, pero como haya al menos 2 usuarios en el mismo sif (trabajando a la vez) vas a tener problemas de encadenamientos, contadores... |
#12
|
|||
|
|||
Orden del QR
Cita:
Sinceramente no veo cual es el problema de imprimirla en la primera, en la última o en todas. La NO Ley porque todavía no es Ley hasta que salgan todos los detalles técnicos, en sus prolegómenos indica que el DOCUMENTO debe llevar un QR que por cierto tampoco hay indicaciones de qué datos debe llevar. En uno de sus weminar aparece un QR y si se lee puede ver un pequeño puñado de datos. Que se le supone van a ser los definitivos. No sé si se refiere a que en sus algoritmos sólo puede tener el número de documento y la serie al final de la impresión o si no puede imprimir el QR hasta el final. No veo cual es el problema de imprimirlo al final si así lo desea. Es el documento el que lleva el QR asignado. Al igual que puede imprimir lo acumulado de los importes en cada página previa y en el final los totales generales o solo imprimir totales generales al final. Al menos tal y como yo lo veo es indistinto. Un saludo. |
#13
|
|||
|
|||
Codifo QR
Cita:
Desde el dia 05/03/2024 ya hay una version preliminra de lo que deve llevar el qr, colocacion y tamaño, el dia 04/06/2024 lo modificaron para poner ejemplos.He intentado poner el enlace, pero no me deja. |
#14
|
|||
|
|||
continuación
Cita:
Si, ya me he bajado los pdf. Y ya estoy haciendo pruebas. Tienen 4 modalidades : a) Veri*factu 1- en pruebas 2- en producción a partir del 01-06-2025 b) NoVeri*factu 3- en pruebas 4- en producción a partir del 01-06-2025 Al final en los informes he creado unas funciones de forma que dependiendo de la fecha utiliza un modelo u otro. De este modo no estaré pendiente de cambiar informes el último día. Ojo con la localización y el tamaño de los QR. La AEAT es muy explícita. Ahora solo nos falta que diseñen las facturas de los clientes. Saludos. |
#15
|
|||
|
|||
Proteccion de datos.
Una cosa, se que no iria aqui, pero..
Para proteger los datos del cliente,(Telefono,dni,Email) , para cumplir con la normativa subiendolos a mi base de datos codificado en MD5 , ¿es suficiente? Teniendo en cuentea que el servidor Mysql, no se puede acceder mas que desde la intranet? Por ejemplo para subir los datos desde un textbox, los pongo en en la estructura de datos, en texto plano, antes de subirlo lo codifico en MD5 y ese codigo es el que subo a la base de datos. Para recogerlos, hago la consulta y asigno a la estructura el resultado de resolver el MD5. Lo pregunto por que una vez puesto a rectificar cosas, modificarlo. Por cierto para hallar el tiempo para el HASH , uso esto en c# Código:
string retorno = DateTime.Now.ToString("yyyy-MM-dd'T'HH:mm:ssK"); Gracias por vuestras respuestas. |
#16
|
|||
|
|||
Colocacion QR
No se al final que decidiran, pero yo estaba por poner el qr, al lado del numero de factura y demas, como pone que dejemos un espacio de 6mm, se supone que puede ir en una pare visible, siempre delante de cualquier otro Qr qu epueda incluir la factura.
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
|