Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[edari]

Empezado por sglorka

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

[ermendalenda]

Empezado por edari

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

[edari]

Empezado por ermendalenda

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


Thx

[ermendalenda]

Empezado por edari

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


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.

[sglorka]

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.

[edari]

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....

[Franche]

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.

[edari]

Empezado por Franche

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]

[antoniomarquezc]

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 ?

[ermendalenda]

Empezado por edari

Yo consulto las dudas en este


[email protected]

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

[ermendalenda]

Empezado por edari

Yo consulto las dudas en este


[email protected]

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

[ermendalenda]

Empezado por edari

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....

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

[edari]

Empezado por ermendalenda

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

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


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

[ermendalenda]

Empezado por edari

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


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

Ah sí, perfect
Gracias

[thinkows]

Empezado por edari

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....

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]

[keys]

Empezado por thinkows

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]

Habría que ver cuantos de los que les han enviado esa sugerencia somos de este foro.

[[newtron]]

Empezado por keys

Habría que ver cuantos de los que les han enviado esa sugerencia somos de este foro.

Yo lo que creo es que tristemente la gente que tiene que definir estos asuntos parece que no están en este mundo y que no han visto una factura en su puñetera vida.



Saludos.

[thinkows]

Empezado por keys

Habría que ver cuantos de los que les han enviado esa sugerencia somos de este foro.

Buenos días a todos los "sufridores", respueta de VERI*FACTU a la consulta :

Buenos días:

Es de suponer que lo expresado en la consulta no se refiere a tiques (facturas simplificadas), ya que habitualmente son menos extensos en cuanto a contenido [ NO HABRÁN VISTO UN TICKET DE SUPERMERCADO EN FIN DE SEMANA ]y más numerosos, lo que plantearía una operativa más engorrosa, lenta e ineficiente (entre otras cuestiones, en el uso de papel) y más proclive a generar problemas o incidencias relacionadas con la necesidad de encajar correctamente lo preimpreso con el contenido generado por el sistema informático de facturación. Por lo tanto, solo afectaría a una parte de las expediciones: las facturas "completas u ordinarias".

A este respecto, cabe señalar que esta forma de expedir las facturas (mediante la composición de una parte preimpresa con otra generada electrónicamente) no parece la más apropiada hoy en día porque, entre otros posibles inconvenientes, es menos práctica y flexible que generar su contenido completo desde el sistema informático de facturación. Por ejemplo, obliga a imprimir siempre la factura [ PUES NO ES CIERTO, PUEDO IMPRIMIRLA I/O ENVIARLA POR EMAIL SIMULTANEAMENTE CON EL MISMO FORMATO QUE EL PREIMPRESO ], lo que no permite generar informáticamente y en origen un PDF de la factura completa (obligando, en su lugar, a escanearla con posterioridad para conseguirlo, pero en formato imagen, menos útil). Esto mismo también impide que sea enviada -por el sistema informático- automáticamente y de forma directa al cliente vía correo electrónico o aplicación de mensajería, cosa muy común hoy en día y especialmente fomentada por los emisores debido a la comodidad que supone para el cliente (inmediatez y guardado) y, sobre todo, por el ahorro de tiempo y costes que implica para el emisor: dispositivos de impresión, papel y otros consumibles (como tinta, tóner...), intervención y operativa manual, etc.

En cualquier caso, abundando en el punto anterior, está práctica va a dejar de admitirse en un futuro próximo cuando se apruebe y entre en vigor el Real Decreto que regulará el uso de la factura electrónica obligatoria entre empresarios y profesionales, en desarrollo del artículo 12 de la Ley 18/2022, de 28 de septiembre, de creación y crecimiento de empresas, que modifica el artículo 2 bis de la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Por lo tanto, este es un buen momento para adaptarse ya en este aspecto a ese cambio.

Por último, mencionar que el planteamiento de ubicación al principio de la factura pretende alinearse con el espíritu del artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, introducido por el artículo de la Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal. Así se logra dar máxima visibilidad al QR tributario, dado que conviene al objetivo de lucha antifraude para el que nace dicho QR, siendo un pilar fundamental del mismo. De esta forma se garantiza que destaque -al ser lo primero que aparece en la factura- y llame más la atención a su receptor (muchas veces, consumidor), favoreciendo su uso y contribuyendo a la concienciación y colaboración ciudadana en este cometido, además de suponer una demostración más de transparencia en el cumplimiento fiscal de quien expide las facturas, lo que contribuye a proyectar una buena imagen. Ubicar el QR en otro sitio podría contribuir a restarle protagonismo :("escondiéndolo" o "camuflándolo") y desvirtuar la efectividad de su cometido.

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