Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por seccion__31

Buenos dias !

ese rumor del posteo anterior, yo veo que no tiene mucho que ver con lo publicado en el BOE.


Si el programa tiene alguna de estas caracteristicas:

a) permitan llevar contabilidades distintas en los términos del artículo 200.1.d) de esta Ley;
b) permitan no reflejar, total o parcialmente, la anotación de transacciones realizadas;
c) permitan registrar transacciones distintas a las anotaciones realizadas;
d) permitan alterar transacciones ya registradas incumpliendo la normativa aplicable;
e) no cumplan con las especificaciones técnicas que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, así como su legibilidad por parte de los órganos competentes de la Administración Tributaria, en los términos del artículo 29.2.j) de esta Ley;


Entonces si habria un problema. Entiendo que entonces se pasaria a valorar si realmente es para llevar una doble contabilidad.


A mi el punto (e), el de inalterabilidad de los registros me preocupa, trabajamos con .dbf y he pensado incluir una campo con un calculo md5 por registro (al que se le sumaria una cadena clave) para demostrar que no se han alterado los registros por via externa ajena al programa, al resto de puntos los puede controlar el propio programa.


Encriptar todo el contenido es imposible en el BDE, y quizas en un caso extremo podria considerarse como una falta de legibilidad.



¿que opinais?

Por cierto que tiempos los de los dbf, Clipper, Foxpro DBASE,


Si estas con programacion antigua te recomiendo que vayas mirando el comando CURL que te va a salvar la vida para todo esto que viene.

[[newtron]]

Hola a tod@s.


A mi forma de ver hasta que no desarrollen la ley lo único que podemos hacer es "rayarnos" con este tema sin ningún resultado práctico. Yo en mi caso lo que he optado es por guardar en una tabla todas las inserciones/modificaciones/anulaciones de los registros de ventas y compras porque lo que parece que si está claro es que pueden exigir la "trazabilidad" de las transacciones. De esta manera lo que haré es dejar de darle vueltas al tema, eso si, estando atento a cuando (si lo hacen) desarrollen esa ley y especifican qué diantres van a querer.



Saludos

[CarlosArjonomia]

Y los que tenemos en el país vasco y resto de España ¿qué tendremos que hacer?, ¿cumplir las dos normativas?. Y allí ya son dos diferentes ya que Bizkaia y Gipuzkoa no son iguales.

Espero que lo organicen bien de inicio, si no el mareo va a ser monumental.

Si no habrá que empezar a dedicarse a otra cosa.

[Casimiro Notevi]

Empezado por CarlosArjonomia

Y los que tenemos en el país vasco y resto de España ¿qué tendremos que hacer?, ¿cumplir las dos normativas?. Y allí ya son dos diferentes ya que Bizkaia y Gipuzkoa no son iguales.
Espero que lo organicen bien de inicio, si no el mareo va a ser monumental.
Si no habrá que empezar a dedicarse a otra cosa.

Por eso mismo "exageraba" yo en este comentario anterior:

El problema realmente no es ese, el problema es que hay como mínimo 17 españas distintas. Y si haces un software certificado para Valladolid, no servirá para Burgos, y si certificas para Burgos, seguirá sin servir para Palencia... y al final serán más de 50 españas. Todos esos certificados, quebraderos de cabeza, problemas con las distintas administraciones, etc. es imposible que lo podamos mantener desarrolladores independientes o pequeños, los únicos que podrán mantener algo así serán las grandes empresas que tienen mucha gente en plantilla y medios para adaptarlo todo.
Si algo así si hace, estamos condenados, porque bien sabéis que "España es diferente". En Portugal, por ejemplo, tienen algo similar, y según las noticias que me llegan, es algo implantado a nivel nacional, y no algo distinto para cada provincia.

[CarlosArjonomia]

Empezado por Casimiro Notevi

Por eso mismo "exageraba" yo en este comentario anterior:

Pues lo que dice el compañero más arriba, no me pienso rallar, a esperar acontecimientos. Nosotros no vamos a poder influir rn las decisiones que tomen.

Saludos.

[antoine0]

Buenos días:

Me parece importante este tema, y veo aquí muchas aportaciones, por cierto muy buenas, del punto de vista de los informáticos que, al mi parecer, no ha sido consultados en excesivo hasta ahora.
Soy francés aunque vivo en España, y tengo interés en la actualidad por el tema de la contabilidad, tanto francesa como española. Voy a intentar aportar más información en lo que ha pasado allá, creo que es interesante para adivinar lo que puede pasar aquí.

Empezado por seccion__31

Si copian el sistema frances, como estais comentando, entonces el tema no seria tan malo:
En este enlace:

https://stileex.xyz/es/certificacion-nf525/

Describen como se logra la certificacion para francia, seguramente algun forero ya la conoce, pero al final del documento deja entre abierto un sistema muy sencillo de certificacion:

Leido el documento, ¿ alguien tiene acceso a la norma NF 525 ?

Empezado por seccion__31

En francia y en otros paises como digo parece que existe la posibilidad del autocertificado.

A finales de 2015 el gobierno ha sacado (dentro de la ley ómnibus de final de año) una nueva obligación de certificación para «programas de caja» a partir del 1/1/2018.
Más o menos al mismo tiempo, AFNOR/Infocert ha sacado una nueva marca, NF 525, y un procedimiento de certificación anual para... programas de caja. No sé si es casualidad o no.
El proceso de certificación para tener la marca NF 525 es un poco secretivo (por ejemplo, está terminalmente prohibido difundir los documentos de Infocert), por tanto no tengo idea sobre el contenido técnico de NF 525. Solo he leído que no es una norma como tal (de hecho, no se difunde por los canales normales de AFNOR). Pero parece ser que se ha elaborado de la misma manera que una norma (comité de expertos, redactores, proceso de adopción, revisiones etc.) Esto lo explica bien el link pasado por el compañero arriba. Esta parte en 2017 era más o menos operacional.
Por cierto, Infocert no es el único certificador para estos programas en Francia: otra posibilidad es LNE, un organismo público (ayuda mucho las asociaciones de consumidores). Se puede visitar en http://www.lne.fr/fr/certification/c...ystemes-caisse en francés, http://www.lne.fr/en/certification/c...n-cash-systems en inglés. Incluyen documentos PDF de 60 páginas / 2 Mb (référentiel en francés y Standard en inglés) que son la mejor descripción que he leído de lo que se debe esperar para poder certificarse (resumen: escribir mucha documentación; pero el detalle es interesante).

Pero la otra parte, la preceptiva legislación, en 2016 no era nada claro (¿le suena de algo?) De hecho, la mera definición de «programas de caja» no era clara para nadie, particularmente para los programadores de gestión (que pensaban que a ellos no los afectaba; craso error). No fue hasta mediados de 2017, con un debate parlamentario, que se aclaro que todos los programas usados para registrar transacciones en efectivo con particulares entraban. Y que por tanto todos deberían cumplir con obligaciones de inalterabilidad, seguridad, conservación et archivado de los datos (menos abanico que en España), por la parte de los programas que está relacionada con operaciones de caja.
Una cosa sí era clara desde el principio: además de certificaciones expedidas por organismos tipo Infocert, desde el principio era previsto otro mecanismo individual (atestación) para los editores. Cómo se hacía fue aclarado luego en 2017. Así que el discurso de Infocert en Francia (ampliado por ejemplo en el link arriba) que insiste sobre la absoluta necesidad de la certificación NF525, parece bastante a una exageración comercial (quedando cortés).

Aunque las especificaciones son fijadas desde septiembre de 2017 (y en 2018 se ha anunciado mano blanda por parte de Hacienda), los editores Open Source (más sencillo de auditar desde fuera) han tardado más tiempo, y varias versiones, para presentar una solución estable. La marca NF525 está en su revisión 2.2, en base a las aclaraciones de 2019 (si piensen SII 1.1, están con migo).
En resumen, ha pasado por lo menos 4 años para que este proceso se estabilice, y el primer año ha sido mucho ruido pocas nueces.

Nota: soy novato y por tanto no puedo poner vínculos, ni nada que se parezca al algo que se pudiera hacer clic. Lo siento para vosotros lectores. Por supuesto doy autorización a los moderadores para editar este post y quitar los URL chapuzeras.

[Casimiro Notevi]

Muchas gracias por tu aporte, es muy interesante

[ermendalenda]

Empezado por antoine0

Buenos días:

Me parece importante este tema, y veo aquí muchas aportaciones, por cierto muy buenas, del punto de vista de los informáticos que, al mi parecer, no ha sido consultados en excesivo hasta ahora.
Soy francés aunque vivo en España, y tengo interés en la actualidad por el tema de la contabilidad, tanto francesa como española. Voy a intentar aportar más información en lo que ha pasado allá, creo que es interesante para adivinar lo que puede pasar aquí.





A finales de 2015 el gobierno ha sacado (dentro de la ley ómnibus de final de año) una nueva obligación de certificación para «programas de caja» a partir del 1/1/2018.
Más o menos al mismo tiempo, AFNOR/Infocert ha sacado una nueva marca, NF 525, y un procedimiento de certificación anual para... programas de caja. No sé si es casualidad o no.
El proceso de certificación para tener la marca NF 525 es un poco secretivo (por ejemplo, está terminalmente prohibido difundir los documentos de Infocert), por tanto no tengo idea sobre el contenido técnico de NF 525. Solo he leído que no es una norma como tal (de hecho, no se difunde por los canales normales de AFNOR). Pero parece ser que se ha elaborado de la misma manera que una norma (comité de expertos, redactores, proceso de adopción, revisiones etc.) Esto lo explica bien el link pasado por el compañero arriba. Esta parte en 2017 era más o menos operacional.
Por cierto, Infocert no es el único certificador para estos programas en Francia: otra posibilidad es LNE, un organismo público (ayuda mucho las asociaciones de consumidores). Se puede visitar en http://www.lne.fr/fr/certification/c...ystemes-caisse en francés, http://www.lne.fr/en/certification/c...n-cash-systems en inglés. Incluyen documentos PDF de 60 páginas / 2 Mb (référentiel en francés y Standard en inglés) que son la mejor descripción que he leído de lo que se debe esperar para poder certificarse (resumen: escribir mucha documentación; pero el detalle es interesante).

Pero la otra parte, la preceptiva legislación, en 2016 no era nada claro (¿le suena de algo?) De hecho, la mera definición de «programas de caja» no era clara para nadie, particularmente para los programadores de gestión (que pensaban que a ellos no los afectaba; craso error). No fue hasta mediados de 2017, con un debate parlamentario, que se aclaro que todos los programas usados para registrar transacciones en efectivo con particulares entraban. Y que por tanto todos deberían cumplir con obligaciones de inalterabilidad, seguridad, conservación et archivado de los datos (menos abanico que en España), por la parte de los programas que está relacionada con operaciones de caja.
Una cosa sí era clara desde el principio: además de certificaciones expedidas por organismos tipo Infocert, desde el principio era previsto otro mecanismo individual (atestación) para los editores. Cómo se hacía fue aclarado luego en 2017. Así que el discurso de Infocert en Francia (ampliado por ejemplo en el link arriba) que insiste sobre la absoluta necesidad de la certificación NF525, parece bastante a una exageración comercial (quedando cortés).

Aunque las especificaciones son fijadas desde septiembre de 2017 (y en 2018 se ha anunciado mano blanda por parte de Hacienda), los editores Open Source (más sencillo de auditar desde fuera) han tardado más tiempo, y varias versiones, para presentar una solución estable. La marca NF525 está en su revisión 2.2, en base a las aclaraciones de 2019 (si piensen SII 1.1, están con migo).
En resumen, ha pasado por lo menos 4 años para que este proceso se estabilice, y el primer año ha sido mucho ruido pocas nueces.

Nota: soy novato y por tanto no puedo poner vínculos, ni nada que se parezca al algo que se pudiera hacer clic. Lo siento para vosotros lectores. Por supuesto doy autorización a los moderadores para editar este post y quitar los URL chapuzeras.

Pues la norma NF525 no hace otra cosa que confirmar mis sospechas.
Resumen:
Firma electrónica Encadenada
Guardar los ficheros firmados en un lugar que no se puedan modificar
y que el programa cumpla con la legislación de facturación.
NECEAIDADES:
Garantía de cumplimiento de reqyuisitos: Que aún no sabemos si va a ser un Co promise o a través de una empresa certificada.
Certificado pa la firma de cada fichero, que puede ser: de empresa, autónomo, dispositivo o de tercero, no se si se me escapa alguno.
Y mucho curro.

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

Para intentar "concretar" sobre lo abstracto de la documentación, yo empezaría por centrarnos en el siguiente párrafo:

"Con el objetivo de no permitir la producción y tenencia de programas y sistemas informáticos que permitan la manipulación de los datos contables y de gestión, se establece la obligación de que los sistemas informáticos o electrónicos que soporten los procesos contables o de gestión empresarial se ajusten a ciertos requisitos que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, requisitos cuya especificación técnica puede ser objeto de desarrollo reglamentario, incluyendo en este la posibilidad de someterlo a certificación."

Y especialmente en estos elementos:

...que soporten los procesos contables o de gestión empresarial se ajusten a ciertos requisitos que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalalterabilidad.

Estraído de aquí: https://www.congreso.es/public_ofici...4_196_1907.PDF

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

Como hemos hecho en otros casos (en otros hilos), he modificado (e iré ampliando) el primer mensaje de este hilo, para ir añadiendo la información más relevante.

[[newtron]]

Perfecto. Pues para resumir yo en particular de esto deduzco que, de momento, lo único que podemos hacer es garantizar la integridad, conservación, bla bla bla.

¿Qué significa esto? (siempre a mi entender) que hay que llevar una "trazabilidad" de todo lo que se hace. Por ejemplo: Se mete una linea de venta (creamos una especie de log con la linea de venta creada), se modifica esa linea de venta (otro log con la modificación), y así sucesivamente.

Creo que todos estaremos de acuerdo en que lo más sano sería no permitir modificar/anular movimientos pero en la práctica eso es poco menos que imposible porque nuestros clientes lo exigen. En la banca por ejemplo no hay modificaciones ni anulaciones, hay movimientos de corrección y absolutamente todo se queda reflejado pero no es nuestro caso.

De esta manera en caso de que al cliente le toque la lotería y reciba la siempre grata visita del inspector de turno podrá mostrarle todo el proceso de una venta/compra hasta llegar al resultado final que es el que tiene que quedar en la máquina.

Seguramente en el futuro nos pedirán algún tipo de certificación del software, que esos logs que se generan sean imposibles de modificar y cosas así pero adivinar eso ya para mi es demasiado y no pienso de momento hacer ningún movimiento al respecto.

Saludos

[ermendalenda]

Empezado por newtron

Perfecto. Pues para resumir yo en particular de esto deduzco que, de momento, lo único que podemos hacer es garantizar la integridad, conservación, bla bla bla.


¿Qué significa esto? (siempre a mi entender) que hay que llevar una "trazabilidad" de todo lo que se hace. Por ejemplo: Se mete una linea de venta (creamos una especie de log con la linea de venta creada), se modifica esa linea de venta (otro log con la modificación), y así sucesivamente.


Creo que todos estaremos de acuerdo en que lo más sano sería no permitir modificar/anular movimientos pero en la práctica eso es poco menos que imposible porque nuestros clientes lo exigen. En la banca por ejemplo no hay modificaciones ni anulaciones, hay movimientos de corrección y absolutamente todo se queda reflejado pero no es nuestro caso.



De esta manera en caso de que al cliente le toque la lotería y reciba la siempre grata visita del inspector de turno podrá mostrarle todo el proceso de una venta/compra hasta llegar al resultado final que es el que tiene que quedar en la máquina.


Seguramente en el futuro nos pedirán algún tipo de certificación del software, que esos logs que se generan sean imposibles de modificar y cosas así pero adivinar eso ya para mi es demasiado y no pienso de momento hacer ningún movimiento al respecto.


Saludos

Ya hay quien ha preguntado a hacienda. No hay que hacer nada de eso hasta que digan que hay que hacer, o sea que publiquen la regulación. Lo único que dicen es que no te pillen doble contabilidad que se te cae el pelo (sin ánimo de ofender a nadie)
Las logs no garantizan nada. Quien dice que no se modifican. Lo único que garantiza algo es que, ya sean logs o grabar en un servidor externo(controlados por hacienda o empresa en representación de ellos) , haya firma electrónica. Ni ningun inspector se va a sentar con cada informático para verificar que el algoritmo usado para que nadie toque es infalible.

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

Empezado por newtron

¿Qué significa esto? (siempre a mi entender) que hay que llevar una "trazabilidad" de todo lo que se hace.

Si.
Por ahora y hasta que no concreten más, parece que es lo único que se puede hacer. Implementar la trazabilidad.
Creo que al final llegaremos al punto de que no se puedan modificar facturas, pero para realizar esos cambios hay que estar seguros.

[[newtron]]

Compañer@s.

Me es grato pasar esta información que nos dejará a todos algo más tranquilos (de momento).

Saludos

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

Gracias.

[CarlosArjonomia]

Bueno, llegó el día.

No me quedo muy tranquilo con la información del enlace de arriba.

Cualquier programa de gestión no cumple las 3 primeras opciones indicadas.

Saludos.

[[newtron]]

Empezado por CarlosArjonomia

Bueno, llegó el día.

Cualquier programa de gestión no cumple las 3 primeras opciones indicadas.

Efectivamente, pero exactamente igual que antes de la ley antifraude. Esto no es nuevo y si antes no sancionaban dudo que lo hagan ahora.


Saludos

[antoine0]

Empezado por newtron

[...] que hay que llevar una "trazabilidad" de todo lo que se hace. Por ejemplo: Se mete una linea de venta (creamos una especie de log con la linea de venta creada), se modifica esa linea de venta (otro log con la modificación), y así sucesivamente.

No creo que vamos a hacerlo con las ventas. Ya será suficientemente volumen hacerlo con los asientos de contabilidad, y/o el contenido de las facturas.

Empezado por newtron

Creo que todos estaremos de acuerdo en que lo más sano sería no permitir modificar/anular movimientos pero en la práctica eso es poco menos que imposible porque nuestros clientes lo exigen.

... y aquí discrepo. Si solo se mira la contabilidad, no hay muchas razones para anular (o modificar) movimientos. Como bien comentas, en los bancos no se permite, ellos pasan movimientos de inversión. Y no solos los bancos, si no básicamente todos los contables lo aprenden así.

Pero nosotros los informáticos nos hemos dado cuenta que podíamos cambiar los asientos y las facturas para que «salga más bonito»; sin mal pensar.
Y luego los clientes se han dado cuenta también; y algunos han abusado de esas posibilidades.

[antoine0]

Empezado por ermendalenda

Lo único que garantiza algo es que, ya sean logs o grabar en un servidor externo(controlados por hacienda o empresa en representación de ellos) , haya firma electrónica.

No lo sé. Si las facturas están reflejadas en un servidor externo controlado por Hacienda (que es exactamente lo que hace el S.I.I.), aunque no estén firmadas electrónicamente, ¿cuál puede ser el interés por parte de Hacienda de endurecer las condiciones? ¿Impedir que alguien «redistribuye» a posteriori el contenido de una factura (sin cambiar los totales)? ¿Obligar a emitir nota más nueva factura por rectificar una dirección, un vencimiento o un Incoterm?

Empezado por ermendalenda

Ni ningun inspector se va a sentar con cada informático para verificar que el algoritmo usado para que nadie toque es infalible.

No es la idea. Al contrario de lo que ha ocurrido en Francia, en España solo existe la posibilidad de ser certificado. Por tanto, el inspector solo se preocupará de saber si la empresa tiene el certificado (y válido).
Será el certificador que eventualmente se va a sentar con los informáticos.

[keys]

Hola a todos.

Hoy me ha llegado esto.

http://mktsp.conthub.io/f/a/MMyzs-qV...QubmV0WAQAAAAN

Además hay otro webinar el día 28.

https://www.tecnowebinars.com/webinar/49324