Esta gente de AEAT no ha visto una factura en su vida... ¿En serio van a obligar a que el QR esté arriba?

Ya veras las risas cuando le digas a las empresas que van a tener que cambiar el diseño de factura que llevan años usando. Muchas empresas se curran el diseño de factura a tope, todo bien cuadradito, ajustado, con sus colores, etc.
Ahora ponles un QR ahí arriba, que se vea bien, junto al logo :D

Yo voy a enviarles un correo diciendo que no es normal que lo pongan esa posición. Aunque no creo que sirva de nada.

Jajaja, la verdad es que llama la atención que no pongan un ejemplo de diseño A4 normal.

He hecho una reflexión similar hace no mucho. Me contestó el consultor: «No es cierto. La mayoría de las facturas hoy en día van/irán en formato electrónico. Sin logotipo.» :o

Estos han pensado que si lo ponen al principio y se empiza a imprimir ya es mas seguro que el registro quede guardado.

Supongo que habra miles de quejas, y como está en borrador lo mismo lo cambian.

En un futuro me imagino que si, pero de momento no creo que sea así. Si este proyecto esta tardando, no me imagino lo que puede tardar la LEy Crea y Crece. Que es lo que regula la factura electrónica.

Piensan tener todo atado. Pero...

Si se hace una factura en árabe o en hebreo, y si usas un formato apaisado, el lado izquierdo es el final. :eek:

Por cierto, en una factura eléctronica ¿donde van a meter el QR? Arriba, abajo al centro o pa dentro :D

Y estamos en 2024, y la Ñ sigue sin estar parte del abecedario... ¡de una administración española! :eek:

Luego se hace una mirada a las especificaciones XSD, y se ve que el número de factura es un string de hasta 60 caracteres. La codificación es UTF-8, entonces no hay límite (que puede ser que siga demasiado laxo :cool:)

Por si acaso salen de la caverna: debe codificarse la Ñ como %C3%91 y la ñ como %C3%B1 (y el código 32 como %20, cuidado con éste que veo bastante a menudo.)

Estas olvidando todas las facturas que se mueven por EDI.

Sin embargo, es cierto que estaba pensando en el entorno B2B, no B2C. Un detalle importante. Que lo cambia todo: en B2C, los logotipos van a quedarse un buen rato más.

Yo en mi entorno pocas empresas conozco que utilicen el formato de facturae, solo lo usan cuando facturan a una empresa pública, al resto de empresas tanto como a clientes finales les envían como mucho la factura en pdf.

Y conozco unas cuentas. :rolleyes:

Jajaja
Va la cadena en un nodo que ya diran

Por cierto, en Face añado también en el xml el pdf de la factura generada. No me gusta que se pierda el logotipo.

Por cierto, en Face añado también en el xml el pdf de la factura generada. No me gusta que se pierda el logotipo.

Seguramente ya esté pensado. Estará contemplado de que alguien quiera joder a un comercio y genere qr erróneos y los envíe desde algún dispositivo a la aeat

Buenos días,


Estoy intentando conseguir que mi calculo del hash coincida con el de los 3 ejemplos que nos ponen en la documentación y tengo un problema con el caso 3, el de la anulación de la segunda factura.


Aquí indica que tienen que ser las etiquetas IDEmisorFacturaAnulada, NumSerieFacturaAnulada, FechaExpedicionFacturaAnulada




Y por contra cuando explica el caso 3 pone






Para hacer lo que dice el manual tendría que coger esas etiquetas del nodo "RegistroAnterior" pero se hace raro...

Lo estoy yo entendiendo mal o está mal explicado???


Gracias

Se han equivocado ellos, el copia pega les ha jugado una mala pasada, efectivamente debe hacer referencia a los campos FacturaAnulada

Con lo cual su cálculo de Hash para ese ejemplo no es correcto.


En fín...


Gracias sglorka ^\||/

La huella del registro anterior estará en el registro de la anulación tb. No es como en ticketbai

Lo sé y por eso al ir a calcularla y no darme el mismo hash del ejemplo me di cuenta.


Se lo he preguntado a ellos de todas formas y he aprovechado para sugerirles (como tú creo...) que eso de poner el QR arriba va a ser una puñetada...


A ver si lo logramos entre todos :D


Thx

Estaría bien, si nl tengo que hacer algunos cambios.
Pero me encuentro otros dilemas.
En el borrador anterior había otras configuraciones para los pdfs, había que ponerle el link sobre el qr y escrito bajo el mismo . Es raro que no digan nada, si hay que ponerlo se va a petar de mensajitos para el qr.
Por otro lado, el comienzo de la factura no tiene que implicar el comienzo de la hoja, yo tengo varios en que sale a la vez un encabezado con el numero(en grande) de pedido de comanda, y hacer un corte en el papel, crea dudas de la entrega del pedido con los artículos pagados. No aclaran bien ese asunto.

En mi modesta opinión yo grabaría la imagen del código QR en base de datos una vez generado y luego imprimiría la factura tomando ese campo. La idea de recalcular campos de Verifactu para luego exponerlos cada vez que imprimimos una factura no lo veo viable. Pero bueno, es sólo una opinión.

Y me contestan


Respecto a la ubicación del código QR está ya trasladado a los responsables ya que hemos recibido más consultas similares al respecto. En cuanto tengamos novedades de alguna de las dos cuestiones se la trasladaremos.






p.d.

Bien, bien....

autofacturas de compra
 

Hola a todos, tengo varios clientes (por ejemplo chatarrerías) que usan autofacturas de compra a diario y no pocas, alguien tiene información de que hacer ? espero que no haya que hacer verifactu tambien con las autofacturas porque para este tipo de empresas sería un incidencia detras de otra, por la operativa que tienen a la hora de trabajar.
¿ a que mail de la AEAT se les podría consultar ?
Gracias.

Yo consulto las dudas en este


[email protected]

Duda sobre el registro de facturación
 

Hola. Tengo una duda sobre el registro de facturación.

En mis aplicaciones las facturas se almacenan en varias tablas (cabecera de factura, detalle, resumen ivas, etc ...), supongo que como en casi todos los programas.
En verifactu se habla del registro de facturación y de que este debe permanecer inalterable y que por ejemplo si hay una corrección y/o anulación, debe generarse un
nuevo registro de facturación sin alterar el registro original.

¿ Significa esto que hay que llevar una tabla paralela (registro de facturación) ?
Es decir, ¿ cuando emito una factura, además de las tablas de las facturas, debo generar un nuevo registro en el registro de facturación y
si modifico dicha factura debo generar otro nuevo registro en dicho registro ?

Hola. Te aconsejo que leas el reglamento y al menos algo del foro.
En resumen es que los registros de facturación y anulación son registros en formato xml. Lo que tengas en las bases de datos no vaa valer sin esas nuevas estructuras.

Perfecto
Y la otra cuestión que has presentado es publica?

Claro.qje haga la factura el destinatario en vez del comprador no le exime de las obligaciones verifactu. E

Sí, ya la he dicho. Lo del tema del error que tiene la documentación al explicar el cálculo de la huella :eek:


Que por cierto me han contestado que ya lo han corregido y subido (y es verdad)...

Claro.qje haga la factura el destinatario en vez del comprador no le exime de las obligaciones verifactu. E

Ah sí, perfect
Gracias

Hola muy buenas!

Llevo unos días leyendo el foro y estoy viendo que ya la AEAT ha ido subido más información con respecto al código QR y a la generación huella/hash para los registros de facturacion y eventos.

En estos días me voy a poner manos a la obra con estas cosas y lo que pueda aportar al foro pues genial.

Actualmente tengo una pregunta que no se si me podeis ayudar ¿se sabe cuando va a estar disponible el entorno de pruebas del codigo QR? He intentando hacer llamadas por GET a la url de prueba que ponen tanto en navegador como postman y me arroja un error 404 not found.

Saludos y gracias de antemano!

Hola, animo pues.
El entorno de pruebas creo que lo abrirán cuando publiquen en el boe la aprobación del reglamento etc.
Que no sabemos cuando.

Si es como en TicketBAI (y no sabemos si será igual, pero tal vez os sirva como muestra) no será un servicio Web, sino una URL.
Es decir, como está pensado para que se escanee desde un móvil (por ejemplo), es QR es una URL, que al visitarla te da los datos básicos de la factura para comprobarla.

Creas una factura de 1€ al 21%.
Al imprimir la factura se añade el QR




Si escaneas ese QR (con un móvil, por ejemplo) te lleva a este enlace para comprobar que la factura es correcta:
https://batuz.eus/QRTBAI/?id=TBAI-A9...&i=1.21&cr=219

Tamaño excesivo del QR
 

Para el poco contenido que tiene no sé por que le han puesto un tamaño tan grande, sobra la mitad.
Incluso para escanearlo en un ticket es más complejo con ese tamaño. Ya que suelen quedar curvos al sujetar el tiquet con la mano.

Una duda que me surge en eso del encadenamiento de facturas.
Cuando hay un cambio de ejercicio, se seguirán encadenando las facturas, imagino, ¿no?
O sea, al primer registro de una empresa/nif que enviemos a hacienda, huella anterior vacia o a ceros, pero terminamos el ejercicio con la factura 1250 y abrimos nuevo ejercicio volviendo a numerar las facturas por la 1... PERO ¿la huella anterior corresponderá a la de la factura 1250 o sera otra vez a ceros???

No se si habeis leido algo al respecto, o si debo plantear la duda directamente a hacienda.

Gracias.

Por lo menos en TicketBAI la primera de un ejercicio tiene que encadenar con la última del ejercicio anterior. Me imagino que aquí será igual.

Es lógico que si
Incluso si haces una parada de actividad de varios años tendrás que encadenar con el último registro generado en dicho dispositivo.
Otra cosa es que cambies el dispositivos y no uses las series anteriores,. Imagínate que al cambiar de año cambias la serie y el identificador del dispositivo también cambia, ya es otro escenario que no se como lo van a recoger. Yo creo que mejor ni plantees la duda y esperes que publiquen la doctrina. Pero en principio contemplalo que van a estar encadenados aunque vuelvas a empezar por el 1, por que seguro eso va a ser así.

Presión contra el QR Veri*Factu
 

Buenos días, yo hice la observación ayer :

"Buenos días, rogaríamos reconsideren la ubicación del QR que se deberá imprimir en las facturas/tickets y podamos situarlo al final de los documentos (como por ejemplo se realiza en la operativa TicketBAI) ya que supone que muchos de nuestros clientes, tengan que rediseñar los formatos pre-impresos, de los mencionados documentos, con los costes que ello implica."

y me contestaron :

Buenos días:

Remitimos sus comentarios a los responsables para que se tenga en cuenta y se valoren otras posibilidades.

Muchas gracias por contactar con la AEAT.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]