Nuevo lío con los modelos de factura personalizados

[espinete]

Es que es imposible que el software permita elegir, diseñar, modificar facturas pero que impida por otro lado usar otro, quitar el QR, etc. Sencillamente lo que exige Hacienda no siempre se puede conseguir. No basta con decir "tienen que hacer esto así y si no te llevas una sanción" y limpiarse las manos. Es injusto y, sobre todo, abusivo.

[Neftali [Germán.Estévez]]

Empezado por espinete

Lo que haremos por lo pronto es, para nuevos clientes (durante la instalación/configuración), si está acogido a VeriFactu, establecer un diseño de factura predefinido oficial para VeriFactu. Pero con los clientes antiguos va a haber un problema.
En fin, va a ser super divertido cuando llegue el momento.

¿Vosotros habéis tenido el mismo problema o similar? ¿Cómo tenéis pensado afrontarlo?

En nuestro caso hemos dado una utilidad simple de conversión, que edita el Report, le añade una banda y en ella incrusta el código.
En principio de esta forma los listados que el usuario quiera convertir, ya lo llevan (la utilidad es opcional).
Luego ya los clientes, que pueden modificar los listados o crear nuevos, pueden "tunearlos".

Y las plantillas que lleva el programa por defecto ya los llevan incluídos.

Empezado por rci

Lo que mas me preocupa a mi, es que como el usuario puede editar los impresos y escoger el diseño que quiere al imprimir, algún usuario listillo podría imprimir una factura sin QR y eso no podemos controlarlo desde programa. Quiero pensar que es responsabilidad del usuario si utiliza mal el programa que si cumple la ley, pero ...

En nuestro caso al imprimir una factura, se comprueba que incluya un QR y de las medidas mínimas estipuladas (y algunas cosillas más, como que no exista otro por encima).
Si el usuario usa una plantilla suya que no lo incluye (o una en la que lo ha eliminado), falla la impresión.

[espinete]

Empezado por Neftali [Germán.Estévez]

En nuestro caso hemos dado una utilidad simple de conversión, que edita el Report, le añade una banda y en ella incrusta el código.
En principio de esta forma los listados que el usuario quiera convertir, ya lo llevan (la utilidad es opcional).
Luego ya los clientes, que pueden modificar los listados o crear nuevos, pueden "tunearlos".

Y las plantillas que lleva el programa por defecto ya los llevan incluídos.

En nuestro caso al imprimir una factura, se comprueba que incluya un QR y de las medidas mínimas estipuladas (y algunas cosillas más, como que no exista otro por encima).
Si el usuario usa una plantilla suya que no lo incluye (o una en la que lo ha eliminado), falla la impresión.

Nosotros intentamos lo de añadir (por código) una nueva banda con el QR, pero los resultados no nos convencían, ya que hay diseños de factura muy complejos, y añadir la banda nueva movía todo lo demás.
Además la banda solo contiene el QR, dejando un montón de espacio desaprovechado al lado. Por eso lo descartamos. Está claro que como medida provisional y automática, bastante es, y bastante curro te has pegado para conseguirlo, pero la verdad es que lo vemos complicado tal como tenemos hecho el software ahora mismo.

Lo único que podremos hacer es impedir la impresión si no detectamos el QR asignado al campo correspondiente, pero poco más.

[rci]

Empezado por Neftali [Germán.Estévez]

En nuestro caso al imprimir una factura, se comprueba que incluya un QR y de las medidas mínimas estipuladas (y algunas cosillas más, como que no exista otro por encima).
Si el usuario usa una plantilla suya que no lo incluye (o una en la que lo ha eliminado), falla la impresión.

Habíamos pensado en eso pero en nuestro caso creemos que no es posible. Utilizamos un componente (Combit List & Label) que no permite o hace muy complicado ese control.
Podríamos llegar a detectar si hay el QR pero no podemos saber si el usuario ha puesto un recuadro en blanco encima para taparlo y que no se vea/imprima...
De momento hemos desestimado ese control.

gracias

[espinete]

Es que si Hacienda pretende que además controlemos que el usuario no ponga nada encima del QR...

Luego se quejaran también de que la impresora tenga poca tinta y no se lea bien el QR. También va a ser culpa nuestra?

[keno_71]

Nosotros también dejamos configurar las plantillas y vamos a guardar la factura diseñada tal como se imprimió en base de datos, para controlar si por ejemplo el cliente metió algo en una plantilla que no debería, hicimos una consulta a verifactu y lo recomiendan. cavando el hoyo...


pregunta

Nuestra aplicación tiene un editor de plantillas donde se configura "el
diseño de la factura". Actualmente estos diseños pueden ser modificadas
por los usuarios , por distintos motivos: resaltar con logotipos
determinadas certificaciones, facturas en otros idiomas, facturas con
distintas cláusulas, simplemente por tener varios diseños etc. Una vez
realizada una factura (en un formato por defecto) el usuario tiene
opción a cambiar el formato de la factura . El formato (un código de un
fichero de plantillas ) con el que se emite la factura se guarda en el
registro de la factura. ¿ Sería subsanación cambiar esto ? Nos
planteamos guardar el diseño de la factura con cada registro de
facturación. Entendemos que la "parte visual" de lo que llega al cliente
forma parte de la trazabilidad de la factura. ¿es conveniente guardar
esa plantilla asociada a la fra ?

respuesta

Buenos días:

No se considera subsanación cambiar solo el diseño visual si no se modifica el contenido contable o fiscal de la factura o del registro de facturación, aunque sí es recomendable que quede traza del diseño original asociado a cada factura emitida.

Por tanto, la decisión que están valorando —guardar la plantilla con el registro de factura— es totalmente adecuada y alineada con los principios de trazabilidad e integridad del RRSIF.

[Neftali [Germán.Estévez]]

Empezado por espinete

Nosotros intentamos lo de añadir (por código) una nueva banda con el QR, pero los resultados no nos convencían, ya que hay diseños de factura muy complejos, y añadir la banda nueva movía todo lo demás.
Además la banda solo contiene el QR, dejando un montón de espacio desaprovechado al lado. Por eso lo descartamos. Está claro que como medida provisional y automática, bastante es, y bastante curro te has pegado para conseguirlo, pero la verdad es que lo vemos complicado tal como tenemos hecho el software ahora mismo.

Nos pasa lo mismo.
La intención es darles una solución temporal. Luego les es más fácil mover el QR ya existente y borrar la banda.
(se les dice en la documentación donde debe ir)

Empezado por rci

Podríamos llegar a detectar si hay el QR pero no podemos saber si el usuario ha puesto un recuadro en blanco encima para taparlo y que no se vea/imprima...
De momento hemos desestimado ese control.

Nosotros si controlamos que no "colisione" con otro control, pero aun así hay mil formas de saltarselo.
Saben que por ley DEBEN hacerlo así.
Digamos que el software controla determinadas cosas, pero es imposible controlar todas.

[espinete]

Habrá que actualizar la documentación, crear artículos específicos explicando el proceso, videos o lo que sea

Menudas semanas/meses nos esperan una vez esto empiece a funcionar en serio 😅