España: Normativa sancionadora sistemas informáticos

[VictorCasajuana]

Para conocer la que _ encima ...
Un resumen magnífico por parte de David y compañeros de FoxPro

https://davidacuna.wordpress.com/2023/1 ... on-foxpro/

Saludos

En el artículo pasa de puntillas conell problema más grande que tenemos los que aún utilizamos DBF. No se puede evitar el acceso desde terceros.
Posibles soluciones serían:
- utilizar el sistema de usuarios, roles y permisos de Windows aplicado a las carpetas del programa
- encriptar los dbf de facturas, esto supondría desencriptar y encriptar los _ vez que se trabaja en ellos, lo veo inestable y para ficheros grandes muy lento.
- cambiar el primer bit del fichero para que no se detecte como dbf por programas externos

Alguna idea más?

Enviado desde mi motorola edge 20 mediante Tapatalk

[Joaquim Ferrer]

Victor, en mi modesto entender, creo que no se trata de impedir el acceso a los datos, informáticamente esto no es posible y todo el mundo lo sabe
Se trata de que tu programa, garantice que si se produce la modificación de una factura una vez presentada, quede un rastro, es decir, un log si ha habido alguna modificación
Además, si tienes por ejemplo un campo del registro de factura con un hash encriptado, con una clave sólo conocida externamente al programa y que dicho hash contiene los datos críticos de una factura (fecha,numero,nif,base,iva,total,...)
y además produces el encadenamiento con otro hash encriptado de una factura anterior, cualquier modificación 'externa' del registro de una factura, producirá que se rompa la cadena de facturas y la no verificación de tu algoritmo hash comentado y así poder demostrar ante una inspección que alguien ha manipulado los datos, pero que TU No has sido
Otra posible solución es la firma electrónica (autofirma o similar) de una factura y guardarla en un servidor privado o público cuando se habilite la facturación electrónica obligatoria
Una simple comparación entre la factura generada actual, con la que se envió en su momento, podrá determinar si fue manipulada
Saludos

[VictorCasajuana]

Hola Joaquim
Efectivamente tener un hash encriptado con los datos críticos de la factura es la forma más fácil de detectar el manipulado por programas externos. Esto ya lo incluí en mis programas hace tiempo cuando empezó a sonar la ley antifraude. Ahora hay que mejorarlo con el encadenamiento tal y como cita el reglamento en el apartado I-d.
Referente al acceso por terceros a los datos, los sistemas con tecnología de BD cliente servidor, ya están más protegidos, ya que no puede acceder cualquier a la base de datos salvo que tenga las claves de acceso, no obstante, lo mejor es utilizar el servicio de hacienda para salvaguardar las facturas emitidas, de este modo ya te liberas de muchos requisitos tal y como comentas.
La verdad es que este reglamento va a dar más robustez y fiabilidad a los sistemas de facturación. Hay que intentar ver el lado positivo de las cosas
Salud!

[Joaquim Ferrer]

Un poco más de literatura sobre este tema ...

https://www.tendencias.kpmg.es/2023/12/ ... 14-12-2023

[paquitohm]

Con respecto al hash que valide la no modificacion de registro

Hacer un hash de todos _ o incluso de algunos puede dar problemas si se modifica la estructura (se añaden o quitan campos o incluso se modifica la longitud de alguno de ellos)
Se me ocurre que el hash tendria que tener asociada la estructura de registro sobre la que se hizo

[VictorCasajuana]

Con respecto al hash que valide la no modificacion de registro

Hacer un hash de todos _ o incluso de algunos puede dar problemas si se modifica la estructura (se añaden o quitan campos o incluso se modifica la longitud de alguno de ellos)
Se me ocurre que el hash tendria que tener asociada la estructura de registro sobre la que se hizo

Se podrían pasar _ a validar a un string en formato Json y realizar el hash sobre dicho string, asi no dependes tanto de la estructura.

Enviado desde mi motorola edge 20 mediante Tapatalk

[VictorCasajuana]

Un poco más de literatura sobre este tema ...

https://www.tendencias.kpmg.es/2023/12/ ... 14-12-2023

Eso ya es otro tema. La factura electrónica B2B será entre profesionales y también se comunicarán los pagos de las facturas, para controlar que se cumpla la ley de morosidad. Por lo que al emitir una factura, podrás enviar un Veri*Factu ( Ley AntiFraude ) y también la factura electrónica B2B.

Respecto al Verifactu, aquí un artículo de hacienda sobre el reglamento https://sede.agenciatributaria.gob.es/S ... actu_.html
Ahora hay que esperar a que saquen la orden ministerial de desarrollo técnico, ahí es cuando empezaremos a "tocar tecla" a fondo.

Se vienen tiempos entretenidos para los ERP's

[paquitohm]

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

[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 ... b_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 ... 2-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"