España: Normativa sancionadora sistemas informáticos

[VictorCasajuana]

Hola,

No sé si para Verifactu o para qué ley, pero es necesario un registro de eventos.
¿ Habéis pensado qué estructura darle ?

fecha, hora, usuario, evento

se me ocurre a mi
¿ Incluimos ahi los errores ?
¿ Qué más incluiriamos en ese registro de eventos ?

slds

De momento obligan al registro de eventos pero no indican la información que debe tener, por lo que se puede implementar dicho registro con la información mínima y dejando la opción a añadir más información

[paquitohm]

Gracias Víctor,

De momento estoy pensando en algo asi como:
ID
Fecha-hora
Aplicacion XXX.EXE
Version Aplicacion (o fecha-hora)
Usuario-Aplicacion
Usuario-Ordenador
ID de sesion
Categoria
Descripcion corta
Descripcion larga (memo)

Si fuera necesario quitaré informacion

[VictorCasajuana]

https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Factu_Descripcion_ServicioWeb_v1.0.pdf

Felices fiestas!!!

[paquitohm]

Víctor,

Calentando motores.
Nos han dejado una oportunidad estupenda de no aburrirnos en Navidades.

Parece que el funcionamiento varia frente al ticket-bai al menos en lo relativo a la subsanacion.
En TBai se emite un zuzendu, aqui se emite otro xml de la misma naturaleza pero cambiando el tipo

Lo que me inquieta es pensar qué hacer con el registro de iva: Los datos que debiera contener son los nuevos y no los antiguos. Supongo que lo que hay que poner en marcha es una marca de "Anulado" y marcar el registro que ha sido anulado y generar otro con la substitucion, pero eso obliga a que el campo clave ya no es el numero de factura, sino el numero de factura y algo mas, lo cual es tener que darse una vuelta grande por todo el programa para insertar busqueda por numero de factura y un nuevo tipo.

En fin. Iremos asentando la cosa, como se asienta una cena a las 12 de la noche en el estomago

Cuando sea necesario subsanar la información que contiene un registro de facturación que ha sido enviado y aceptado o aceptado con errores por la AEAT, siempre y cuando no se trate de una causa que exija la emisión de una factura rectificativa, se podrá generar un fichero de subsanación que será enviado a la AEAT. Para esta operación el valor del campo de la cabecera <TipoRegistroAEAT> debe ser “T1” En el fichero subsanado se incluirá su propia huella del registro de facturación. Como siempre, el encadenamiento debe ser con el registro de facturación inmediatamente anterior, por orden cronológico de generación de registros de facturación en el SIF.
El registro de facturación recibido originalmente no podrá sufrir alteración alguna, y deberá conservarse en su estado original dentro del sistema informático del emisor de la factura para garantizar la integridad, conservación, trazabilidad e inviolabilidad del fichero generado por el SIF

[paquitohm]

Entre otras, ya ha salido la definicion del registro de eventos

https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Anexo_OM_RD-1007-2023(v0.5.0_2023-12-20).xlsx

[paquitohm]

65 ¿No os parece una chapuza descomunal que una PYME deba gestionar y enviar una
factura por FactuRAe Y POR vERIFACTU?
El proyecto de factura electrónica B2B obligatoria tiene como principales objetivos la
modernización de la sociedad y el control de la morosidad, que es un objetivo diferente
del reporting fiscal de los proyectos SII y Veri*factu, y además el proyecto de factura
electrónica B2B tiene un ámbito estatal diferente de los de reporting fiscal. Se procurará
que compartan elementos comunes (por ejemplo, identificación unívoca de factura y
elementos de semántica). Los proveedores de sistemas informáticos de facturación
tendrán que proporcionar ambas funcionalidades de factura electrónica y de reporting
fiscal Veri*factu. Se podrá estudiar más elementos de convergencia de estos proyectos
en el futuro, pero requeriría de modificaciones normativas.

https://www.agenciatributaria.es/static ... rm2023.pdf

[paquitohm]

La petición de documentos que ya obren en poder de la Administración


El art. 28 de la Ley 39/15 de procedimiento administrativo común de las Administraciones Públicas (LPAC), con la finalidad de reducir la burocracia y facilitarle los trámites a las personas que se relacionan con las Administraciones, después de establecer en su apartado 1º la obligación aportar al procedimiento administrativo los datos y documentos exigidos por las Administraciones Públicas de acuerdo con lo dispuesto en la normativa aplicable, en su apartado 2º aclara lo siguiente:


"2. Los interesados tienen derecho a no aportar documentos que ya se encuentren en poder de la Administración actuante o hayan sido elaborados por cualquier otra Administración. La administración actuante podrá consultar o recabar dichos documentos salvo que el interesado se opusiera a ello. No cabrá la oposición cuando la aportación del documento se exigiera en el marco del ejercicio de potestades sancionadoras o de inspección.


Las Administraciones Públicas deberán recabar los documentos electrónicamente a través de sus redes corporativas o mediante consulta a las plataformas de intermediación de datos u otros sistemas electrónicos habilitados al efecto.


Cuando se trate de informes preceptivos ya elaborados por un órgano administrativo distinto al que tramita el procedimiento, estos deberán ser remitidos en el plazo de diez días a contar desde su solicitud. Cumplido este plazo, se informará al interesado de que puede aportar este informe o esperar a su remisión por el órgano competente".


En el caso de que sean documentos que el interesado haya ya aportado, la regulación se completa con el párrafo 2º del apartado 3º de este mismo art. 28 LPAC:


"Asimismo, las Administraciones Públicas no requerirán a los interesados datos o documentos no exigidos por la normativa reguladora aplicable o que hayan sido aportados anteriormente por el interesado a cualquier Administración. A estos efectos, el interesado deberá indicar en qué momento y ante qué órgano administrativo presentó los citados documentos, debiendo las Administraciones Públicas recabarlos electrónicamente a través de sus redes corporativas o de una consulta a las plataformas de intermediación de datos u otros sistemas electrónicos habilitados al efecto, salvo que conste en el procedimiento la oposición expresa del interesado o la ley especial aplicable requiera su consentimiento expreso. Excepcionalmente, si las Administraciones Públicas no pudieran recabar los citados documentos, podrán solicitar nuevamente al interesado su aportación"

[Verhoven]

Va tomado forma la exigencia a aplicar a los sistemas informáticos.
Parece diseñado para quitar del medio a las empresas pequeñas, ¿a alguno le parece fácil adaptar sus sistemas de gestión a los requerimientos previstos que copio más abajo?. Por cierto, para los emisores de hasta 100 facturas al año los chicos de la aeat van a regalar un sistema informático, así les quitan algunos de sus clientes de paso. Lean con atención.

No puedo evitar que aflore en mi cabeza el recuerdo de ese mítico coche llamado "Kitt"; le decía Michael Knight (interpretado por el actor David Hasselhoff) algo así como: "Kitt, vete a buscar a la rubia y tráela a tomar unas cervezas al chiringuito de la playa", y se iba el coche sin pensarlo dos veces y lo hacía. Pues eso, sueño con ese momento en que ya estará lista una de esas IA, que sabrá que las normas están en el BOE (Boletín Oficial del Estado donde se publican las leyes y normas) y nos devolverá el programa hecho tal y como lo quiere hacienda, para que le digamos por ejemplo: Kitt, factura un euro veinte de la venta de un paquete de pipas y un par de caramelos y dale toda la gestión fiscal, contable y de todo tipo que corresponda y ya de paso descuenta la comisión del banco por la transacción, el mantenimiento del ordenador, los seguros sociales, la conexión a internet y ajusta el stock, ¡ah! y no te olvides de estar siempre conectado para si quiere entrar la aeat a revisarlo que pueda hacerlo en cualquier momento del día o de la noche de cualquier día del año, y guarda sin posibilidad de fallos toda la información durante seis años, porfi porfita.

Será un mundo tan maravilloso cuando llegue ese momento...No me digáis que no estáis vosotros deseando también vivamente que llegue ese momento.

Vaya pandilla...

Code: Select all  Expand view  RUN

Proyecto de Orden  (Las facturas deberán incluir un «QR» y la «URL» con acceso a los datos de expedición)

Esta orden desarrolla el Real Decreto 1007/2023, de 5 de diciembre, concretando y detallando los aspectos y contenidos de carácter técnico del diseño de los programas de facturación, así como los formatos de remisión de la información a la Sede electrónica de la Agencia Estatal de Administración Tributaria.
Proyecto de Orden por la que se desarrollan las especificaciones técnicas y funcionales a que se refieren tanto el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre; como el artículo 6.5 del Reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre (Documento sometido a trámite de audiencia e información pública el 4 de enero de 2024)

Materias afectadas:

    • Obligaciones de facturación.

    • Procedimiento de gestión tributaria.

    • Impuesto sobre el Valor Añadido.

    • Prevención del fraude fiscal.

Entrada en vigor: el día siguiente al de su publicación en el Boletín Oficial del Estado.

OBLIGACIÓN FORMAL INCORPORADA A LEY GENERAL TRIBUTARIA

Con el objetivo de impedir o dificultar la fabricación, producción, importación y tenencia de sistemas y programas informáticos que permitan o faciliten la manipulación u ocultación de datos contables, de facturación o de gestión a la Administración tributaria, el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, ha incorporado una nueva obligación tributaria formal, que establece que los productores, comercializadores y usuarios de los sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión de quienes desarrollen actividades económicas, deben garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin interpolaciones, omisiones o alteraciones de las que no quede la debida anotación en los sistemas mismos, así como la obligación de que los mismos estén debidamente certificados y utilicen formatos estándar para su legibilidad.

DESARROLLO REGLAMENTARIO (REAL DECRETO 1007/2023, DE 5 DE DICIEMBRE)

Recogido en el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, el Real Decreto 1007/2023, de 5 de diciembre, regula las normas que deben cumplir dichos sistemas con el fin de garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación.

Asimismo, se introducen determinadas modificaciones en el Reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre, entre las que se encuentra el nuevo apartado 5 introducido en el artículo 6 del Reglamento por el que se regulan las obligaciones de facturación, donde se establece la inclusión de un código «QR» y, en su caso, una frase en las facturas expedidas por los sistemas informáticos a que se refiere el artículo 7 del Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación.

CONTENIDO Y ESTRUCTURA DE LA ORDEN

— Artículo 1: determina la finalidad de la orden, que es la de detallar los aspectos técnicos, funcionales y de contenido recogidos en el Reglamento aprobado por el Real Decreto 1007/2023, así como concretar las especificaciones técnicas y funcionales de formación del código «QR» y, en su caso, de la frase que deberán incluirse en las facturas expedidas por los sistemas informáticos.

— Artículo 2: establece la posibilidad de que un mismo sistema informático de facturación pueda dar soporte a dos o más obligados tributarios, así como las condiciones que debe reunir este sistema informático, que se deberá comportar como si fueran sistemas informáticos independientes para cada obligado tributario gestionado.

Entre los requisitos exigidos se encuentran que deberá realizar de forma separada la gestión de los registros de facturación, generar cadenas independientes de registros de facturación para cada obligado tributario, permitir el funcionamiento como sistema VERI*FACTU de forma independiente para cada obligado tributario y visualizar claramente en todos los terminales conectados al mismo, el número total y la identificación de los obligados tributarios que gestiona.

— Artículo 3: trata de las particularidades aplicables a los «Sistemas VERI*FACTU», presumiéndose que los sistemas informáticos que tengan la consideración de «Sistemas de emisión de facturas verificables» o «Sistemas VERI*FACTU», cumplen por diseño los requisitos y características que recogen en esta orden.

— Artículo 4: regula que la capacidad de remisión de todos los registros de facturación generados implica que el sistema informático deberá poder realizar una serie de acciones tales como conectarse a Internet para comunicarse con Sede electrónica de la AEAT, gestionar certificados electrónicos, remitir los registros de facturación, con la estructura, formato y codificación requeridos, usando protocolos seguros de comunicación y recibir y procesar adecuadamente las respuestas generadas por la AEAT ante los envíos realizados.

— Artículo 5: establece los sistemas de identificación y autenticación válidos para remitir los registros de facturación a la Sede electrónica de la Agencia Estatal de Administración Tributaria.

Para remitir los registros de facturación a la Sede electrónica de la Agencia Estatal de Administración Tributaria, los sistemas informáticos deberán identificarse electrónicamente ante esta a través de los certificados electrónicos válidos en cada momento en la Sede electrónica de la Agencia Estatal de Administración Tributaria. Además, dichos certificados electrónicos deberán ajustarse a las condiciones que se establezcan en la normativa vigente en cada momento en relación con los atributos mínimos que deben incluir los certificados electrónicos cualificados y los mecanismos que permiten verificar su vigencia y contenido en el ámbito de las administraciones públicas.

— Artículo 6: trata sobre los requisitos que se deben cumplir para asegurar la integridad e inalterabilidad de los registros de facturación.

El sistema informático debe ser capaz de comprobar si es correcta la huella o «hash» de cualquier registro de facturación individual generado, debiendo firmar electrónicamente todos los registros de facturación que genere y comprobar si es correcta la firma electrónica de cualquier registro de facturación individual generado, así como toda o una determinada parte de la cadena de registros de facturación.

Cuando el sistema informático detecte cualquier tipo de circunstancia que impida garantizar o que pueda vulnerar la integridad e inalterabilidad de los registros de facturación generados, o de su encadenamiento, deberá mostrar una alarma que indique claramente este hecho y que sea visible en todos los terminales conectados al sistema informático, generando el correspondiente registro del evento.

— Artículo 7: regula la trazabilidad de los registros de facturación, estableciendo que cada registro de alta o de anulación deberá contener un conjunto de datos referido al registro de facturación, de alta o de anulación, inmediatamente anterior por orden cronológico de fecha de generación, tales como el NIF del obligado a expedir la factura a que se refiere el registro de facturación inmediatamente anterior, el número de serie y número de la factura a que se refiere el registro de facturación inmediatamente anterior, la fecha de expedición de la factura a que se refiere el registro de facturación inmediatamente anterior, los primeros 64 caracteres de la huella o “hash” del registro de facturación inmediatamente anterior, salvo que se trate del primer registro de facturación generado en el sistema informático desde su instalación o puesta en marcha inicial.

Para un determinado obligado tributario, el sistema informático producirá una única cadena de registros de facturación.

La cadena de registros de facturación generada deberá contener tanto los registros de facturación de alta como los registros de facturación de anulación y será necesario que el sistema informático incorpore a los registros de facturación la fecha y hora exactas del momento en que son generados, de acuerdo con el territorio desde donde se expide la correspondiente factura.

El sistema informático deberá permitir realizar el seguimiento de la secuencia de la cadena de registros de facturación, tanto hacia delante como hacia atrás, de forma rápida, fácil e intuitiva y avisar cuando detecte cualquier tipo de circunstancia que impida garantizar o que vulnere o pueda vulnerar la trazabilidad y el encadenamiento de los registros de facturación generados.

— Artículo 8: regula la conservación, accesibilidad y legibilidad de los registros de facturación, que deberá garantizarla, así como permitir el acceso a donde estos se conserven y su recuperación y consulta en formato electrónico legible por parte de la Administración tributaria.

Los registros de facturación podrán ser conservados fuera del sistema informático que los generó, por lo que este deberá permitir descargar, volcar o copiar y archivar de forma segura, mediante su exportación a un soporte de almacenamiento externo en formato electrónico que deberá contener la copia fidedigna de todos los registros de facturación exportados. Este proceso deberá ser independiente de la política de copias de seguridad de los datos que pudieran establecerse para el sistema informático.

— Artículo 9: establece las características del registro de eventos. En este sentido, el sistema informático deberá ser capaz de detectar y registrar cuando se produzcan, eventos tales como la instalación o puesta en marcha inicial del sistema informático, el inicio y fin del funcionamiento del sistema informático como sistema VERI*FACTU, el lanzamiento del proceso de detección de anomalías en los registros de facturación, la detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de facturación, el lanzamiento del proceso de detección de anomalías en los registros de eventos, la detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de evento, la restauración de copia de seguridad y la exportación de registros de facturación generados en un periodo y de registros de eventos generados en un periodo.

El sistema informático también deberá generar un registro resumen de eventos antes de cerrarse o apagarse en formato XML y codificación UTF-8.

— Artículo 12: trata sobre la información a suministrar en los casos de autorización o de resolución de no aplicación, por lo que antes de generar algún registro de facturación se deberá remitir copia de la autorización en el apartado previsto para aportar documentación complementaria dentro de la Sede electrónica de la AEAT; y cuando exista alguna resolución de no aplicación deberá consignarse el número de identificación de dicha resolución en los registros de facturación de alta y de anulación.

— Artículo 13: regula que la generación de la huella o «hash» de los registros de facturación se realizará mediante un fichero XML, usándose el algoritmo y codificación indicados en el documento técnico que se publicará la Sede electrónica de la AEAT, debiendo almacenarse junto con el registro de facturación al que corresponde.

— Artículo 14: establece que, en caso de ser requerida, la generación de la firma electrónica de los registros de facturación se realizará conforme a las especificaciones que se recojan en la Sede electrónica de la AEAT, debiendo almacenarse junto con el registro de facturación al que corresponde.

— Artículo 15: regula el contenido de la declaración responsable y la ubicación de la misma, comenzando con el título «DECLARACIÓN RESPONSABLE DEL SISTEMA INFORMÁTICO DE FACTURACIÓN», para, a continuación, contener una serie de datos tales como el nombre y código identificador del sistema informático, componentes, hardware y software, nombre y apellidos de la persona o razón social de la entidad productora del sistema informático a que se refiere la declaración responsable, NIF español de la persona o entidad productora del sistema informático a que se refiere la declaración responsable, dirección postal completa de contacto de la persona o entidad productora del sistema informático a que se refiere la declaración responsable y fecha y lugar en los que la persona o entidad productora del sistema informático suscribe la declaración responsable del mismo, entre otros.

— Artículo 16: establece las especificaciones técnicas de la remisión voluntaria, determinado su funcionamiento, de menare que el sistema informático realizará el envío del primer registro de facturación a la Agencia Estatal de Administración Tributaria, la Agencia Tributaria devolverá, entre otros datos, un valor actualizado de los parámetros (n,t) y, para poder realizar el siguiente envío, el sistema informático deberá esperar a tener acumulados n registros de facturación o a que transcurran t minutos desde el anterior envío, lo que ocurra primero. El sistema informático realizará entonces un nuevo envío cumpliendo los parámetros anteriores, pudiendo recibir entonces una nueva actualización de los parámetros.

Se contemplan dos tipos de ficheros para la remisión voluntaria: Registro(s) de facturación de alta y Registro(s) de facturación de anulación.

Las incidencias que habilitan el envío de registros de facturación agrupados deberán ser debidamente justificadas por el remitente si así se lo requiere la AEAT.

— Artículo 17: marca las condiciones y plazos de inicio y de renuncia a la remisión voluntaria, que podrá iniciar en cualquier momento su funcionamiento como sistema VERI*FACTU y deberá mantenerse siempre al menos hasta el final del año en que haya funcionado como tal, es decir, hasta el 31 de diciembre.

La forma de renunciar a que el sistema informático funcione como un sistema VERI*FACTU será mediante la cumplimentación del campo previsto a tal efecto en los mensajes de remisión de registros de facturación a la AEAT donde se indicará la última fecha en la que el sistema funcionará como VERI*FACTU. El primer mensaje en el que se rellene dicho campo informando de la fecha de fin de funcionamiento como sistema VERI*FACTU deberá remitirse antes del final del año natural en el que se quiera hacer efectiva la renuncia.

— Artículo 18: Indica las características y requisitos de la remisión de registros de facturación en caso de respuesta a un requerimiento, que serán los mismos que los especificados en esta orden para los sistemas VERI*FACTU, pero utilizando otro servicio específico, con la estructura y contenido adaptados de los registros de facturación.

— Artículo 19: determina las condiciones y límites de la aplicación informática de facturación que pueda desarrollar la Administración tributaria, que deberá ofrecer al menos funcionalidades como la captura, almacenamiento, consulta y descarga de los datos de las facturas, la expedición de la factura en formato imprimible en PDF, la descarga de la factura en PDF y la generación y almacenamiento del registro de facturación.

Respecto a los límites, sólo podrá ser utilizada para expedir facturas en nombre propio, no por un tercero o destinatario, por lo que no admitirá su uso en los supuestos de colaboración social ni apoderamiento; para poder acceder a la aplicación será necesario autenticarse mediante algún método admitido por la AEAT y podrá expedirse hasta un máximo de 100 facturas por año.

— Artículo 20: regula la representación gráfica a incluir en la factura, que, tanto si está impresa en soporte papel como si se trata de la imagen de la misma en soporte digital, deberá incluir un código «QR» y, en caso de facturas expedidas por «Sistemas de emisión de facturas verificables» o «Sistemas VERI*FACTU», la frase «Factura verificable en la sede electrónica de la AEAT» o «VERI*FACTU», que deberá tener un tipo de letra y tamaño bien visibles.

En caso de que la factura se expida en un formato digital que contenga la imagen equivalente al formato impreso de la misma, y se envíe por medios electrónicos, al lado del código «QR» se deberá incluir el texto de la «URL» que está codificada en el propio código «QR», con un hipervínculo o hiperenlace.

— Artículo 21: describe el formato y contenido del código «QR» que deberá tener un tamaño entre 30x30 y 40x40 milímetros y seguir las especificaciones de la norma ISO/IEC 18004, y para su generación deberá emplearse el nivel M (medio) de corrección de errores, lo que ofrece un 15 por 100 de recuperación de caracteres.

Respecto al contenido, incluirá la «URL» del servicio de cotejo o remisión de información por parte del receptor de la factura.

La información de la factura que formará parte de la «URL» estará integrada por el NIF del obligado a expedir la factura, el número de serie y número de la factura expedida, la fecha de expedición de la factura y el importe total de la factura.

    martes, 16 de enero de 2024

[VictorCasajuana]

información sobre las presentaciones de la semana pasada:
https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/20240211SeminVerifactEEDD-ONIF.pdf
https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/20240211SeminVerifactEEDD-DIT.pdf

[paquitohm]

información sobre las presentaciones de la semana pasada:
https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/20240211SeminVerifactEEDD-ONIF.pdf
https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/20240211SeminVerifactEEDD-DIT.pdf

Gracias !

[Xevi]

Una consulta a ver si alguien me puede aportar un poco de luz

En un software de Contabilidad, simplemente Contabilidad (Cuentas, Asientos, Balances, Libros...)
¿Sabeis como afecta o el alcance de la ley Anti Fraude?

Porque el tema por lo que voy leyendo e informando, todo gira entorno a la facturación y más concretamente al emitir la factura, pero queda un poco a nivel de programador o desarrollador todo el tema de trazabilidad, integridad... por lo que yo solamente he desarrollado un registro de eventos y además le he incluido una integridad a mi manera en cada apunte de la base de datos "asientos", pero como digo, no veo que haya una normativa específica, detallada para los sitemas de Contabilidad.

Agradezco cualquier aporte al respecto.

Gracias.

Un Saludo,
Xevi

[VictorCasajuana]

La ley Anti fraude solo habla de los sistemas de facturación SIF. "En teoría" no afecta a la contabilidad, porque si tú ya has enviado la factura y está tiene todos los controles de seguridad de la ley antifraude, veri*factu, etc.. poco vas a poder manipular en la contabilidad. No está de más meter un registro de eventos y una detección de modificación de datos por programas externos, a parte de "revisar" bien las opciones que tienen los programas de contabilidad a nivel de borrado, renumerado, etc...

Enviado desde mi motorola edge 20 mediante Tapatalk

[VictorCasajuana]

Preguntas y respuestas Verifactu publicadas por hacienda después de la última ponencia:
https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/20240214-Preguntas-respuestas-Verifactu.pdf

[Garbi]

Hola a todos,
Tengo una aplicaciones que generan facturas (España) y me gustaría pediros si alguien tiene las indicaciones claras que debe cumplir la aplicación para que sea correcta a partir de julio 2025 ( que creo que es cuando entra en vigor).
No unos manuales, que perdonarme pero no me aclaro con ellos.

Gracias.

[VictorCasajuana]

Hola a todos,
Tengo una aplicaciones que generan facturas (España) y me gustaría pediros si alguien tiene las indicaciones claras que debe cumplir la aplicación para que sea correcta a partir de julio 2025 ( que creo que es cuando entra en vigor).
No unos manuales, que perdonarme pero no me aclaro con ellos.

Gracias.

El reglamento está pendiente de publicación