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