FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Reflexiones del Fin de semana
Me gustaría hacer algunas reflexiones para arrojar luz sobre los puntos del artículo 201 bis de la ley 58/2003, que es el que deben de cumplir los sistemas informáticos
Cito el Artículo artículo 201 bis 1. Constituye infracción tributaria la fabricación, producción y comercialización de sistemas y programas informáticos o electrónicos que soporten los procesos contables, de facturación o de gestión por parte de las personas o entidades que desarrollen actividades económicas, cuando concurra cualquiera de las siguientes circunstancias: Estos apartados se centran sobre los programas de gestión, tpv y programas contables en general a)permitan llevar contabilidades distintas en los términos del artículo 200.1.d) de esta Ley; Sobre este apartado podríamos pensar que tenemos que asegurar que todos los apuntes contables que genera un sistema se tienen que exportar al programa contable evitando poner filtros de series y/o documentos y periodos de fecha para realizar este proceso. ¿Puede alguien aportar algo más o discrepar sobre lo dicho? b)permitan no reflejar, total o parcialmente, la anotación de transacciones realizadas; Entiendo que evitar ocultar series de documentos en las consultas de transacciones, tanto de ventas como de cobros, compras, documentos de almacén, inventarios, etc Impedir restaurar copias del sistema de fechas anteriores (salvo por el servicio técnico de la empresa instaladora) Mantener una numeración correlativa en la expedición de cualquier documento No permitir la inicialización de los datos registrados en la empresa ¿Puede alguien aportar algo más o discrepar sobre lo dicho? c)permitan registrar transacciones distintas a las anotaciones realizadas; Simular Ventas y/o Cobros acorde con la cantidad que queramos declarar. Sustituir el contenido de operaciones de Venta y cobro por datos simulados. ¿Puede alguien aportar algo más o discrepar sobre lo dicho? d)permitan alterar transacciones ya registradas incumpliendo la normativa aplicable; Modificar/Eliminar Facturas Expedidas. Modificar documentos contables (Ventas, cobros, compras, pagos, documentos de almacén) referidos a periodos ya cerrados y declaraciones. ¿Puede alguien aportar algo más o discrepar sobre lo dicho? Los apartados siguientes están regulados por el Reglamento que acaban de aprobar Real Decreto 1007/2023. Y claramente, hacen referencia a los registros de facturación, cuando en la cuarta página dice: …. Por ello, este real decreto se centra exclusivamente en garantizar que los sistemas informáticos que soporten los procesos de facturación de los obligados tributarios cumplan el conjunto de estos requisitos, quedando fuera de su ámbito objetivo los procesos contables y de gestión de empresarios y profesionales. Además, el artículo 8 en su punto 1 dice: Los sistemas informáticos a que se refiere el artículo 1 de este Reglamento deberán garantizar la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros de facturación regulados en los artículos 9, 10 y 11 de este Reglamento. Refiriéndose estrictamente a los registros de facturación de Alta y Anulación. 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; Cito la ley “La obligación, por parte de los productores, comercializadores y usuarios, de que 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, garanticen 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. Reglamentariamente se podrán establecer especificaciones técnicas que deban reunir dichos sistemas y programas, así como la obligación de que los mismos estén debidamente certificados y utilicen formatos estándar para su legibilidad” f)No se certifiquen, estando obligado a ello por disposición reglamentaria, los sistemas fabricados, producidos o comercializados; Empezando por el apartado e) Artículo 8. Requisitos de los sistemas informáticos de facturación 1. El sistema informático deberá tener capacidad de remitir por medios electrónicos a la Administración tributaria, de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente, todos los registros de facturación generados a que se refieren los artículos 9, 10 y 11 de este Reglamento Entiendo que utilices el modo VeriFactu (envío inmediato de los registros de facturación) o no (almacenamiento para posteriores requerimientos), el software debe cumplir con el en envío automático. 2. El sistema informático deberá garantizar a. La integridad e inalterabilidad de los registros de facturación de forma que, una vez generados y registrados, no puedan ser alterados sin que el sistema informático lo detecte y avise de ello. Se entiende que, una vez generados los registros, de alguna manera, tenemos que garantizar que fueron los originales que se crearon en un primer momento. No confundir esto con la adición de huellas hash o firmado electrónico de los registros para garantizar que no han sido modificados (que también hay que cumplir). Tenemos que demostrar que esos registros fueron los originales que se generaron en un primer momento ya que podemos generar una serie de registros simulados a posteriori alterando las fechas de creación de los registros mediante utilizades archiconocidas y manteniendo su encadenamiento y huellas hash. Estos registros simulados son tan válidos como los originales. Entiendo que deberíamos generar una clave hash de todo el fichero y almacenarla en una tabla donde se registre cada registro de facturación emitido. De esta manera, podemos comparar el hash del archivo de registro de facturación con el hash que tenemos en nuestra tabla de registros ¿Se les ocurre algún proceso técnico fiable que asegure que un registro generado coincide con su versión original? b. La trazabilidad de los registros de facturación. Se me ocurre que con el campo <RefExterna> del que disponemos en el fichero de alta y anulación para nuestro uso personal, podemos hacer referencia al nombre del fichero anterior y así poder trazarlos. Aunque también podríamos tener una tabla donde registráramos todos los archivos generados en orden y usarla como índice. ¿Se les ocurre algún otro proceso técnico fiable que lo resuelva? c. La conservación, durante el plazo previsto en la Ley 58/2003, de 17 de diciembre, General Tributaria, así como la accesibilidad y legibilidad, de todos los registros de facturación generados por el propio sistema informático. El sistema informático deberá contar con un procedimiento de descarga, volcado y archivo seguro de los registros de facturación generados por él, que deberán poder ser exportados a un almacenamiento externo en formato electrónico legible Si usamos el modo VeriFactu no nos preocupa el almacenamiento ya que los registros los tiene la aeat. En caso contrario, sí deberíamos contar con total seguridad de que no los vamos a perder. Nuestro software debe asegurar, ante una inspección, que dispone de un proceso técnico fiable que asegure la conservación, de al menos, los últimos 4 años. Si no lo podemos demostrar y se pierden los registros tendremos consecuencias como desarrolladores. Si podemos demostrar que nuestro sistema de copia es seguro y aun así se pierden los ficheros no nos podrían reclamar nada. Pienso que, además de la posibilidad de enviar registros a dispositivos externos de copia, deberíamos pensar en usar Onedrive (Microsoft), o Drive (Google) para tener siempre sincronizadas las copias de ficheros Entiendo que debemos disponer de una utilidad que permita visualizar estos registros en formato Xml, hacer algún tipo de búsqueda por algún campo del registro, Nif destinatario, Año de emisión, Fecha de emisión, etc. También hay que desarrollar una utilidad que permita el volcado parcial o total de los registros sobre unidades de almacenamiento. En particular, tengo una tabla donde registro todos los archivos generados. En ella, almaceno tanto el hash del archivo con los nombres de los registros y su orden para poder trazarlos. Además, creo que la adición de un campo VARBINARY para almacenar el archivo de registro de facturación comprimido en Zip sería una buena idea ya que dispondríamos de los registros en caso de pérdida sin tenemos una copia de seguridad de la base de datos. ¿Se les ocurre algún otro proceso técnico fiable que lo resuelva? Me gustaría que estas reflexiones nos ayudasen a concretar algunos aspectos del reglamento y entre todos podamos aportar algo más de luz a todo este follón Saludos |
#2
|
||||
|
||||
Todo este asunto de querer poner puertas al campo es ridículo, basta con no hacer factura si no se quiere declarar, y ahí se acabó el invento.
Aparte de todo esto, van a necesitar contratar a un millón de inspectores para verificar que las ¿3 millones de empresas y autónomos? del país llevan todo el sistema correctamente. |
#3
|
||||||
|
||||||
Cita:
Cita:
Cita:
Nota también que un sistema puede cumplir avisando si hay meras sospechas de alteración, aunque los registros son los originales, solo si pasa algo que no le cuadra al programa. Otra cosa: hay casos que precisan de ensanchar los registros del sistema de facturación. El sistema debe continuar a cumplir aunque necesariamente los registros ya no son los originales (que eran más estrechos). Cita:
Por tanto, si al generar o validar un registro compruebas que la huella del precedente (él que era el último) no coincide con la esperada, sabes que hay alguna alteración, y debes señalarla. Y ocurre que en su gran sabiduría, AEAT nos pide guardar dicha huella dentro del nuevo registro... Cita:
|
#4
|
|||
|
|||
Cita:
me imagino que deberíamos hacer algo más para certificar que esos registros fueron los creados originalmente. |
#5
|
|||
|
|||
Aún no han empezado a contar los 9 meses para los desarrolladores
|
#6
|
||||
|
||||
Cita:
¿Dónde pone que todavía no ha empezado el tiempo a contar? Edito: Vaaaaaaaaaaaaaaaaaaale... ha sido enviar el mensaje y ya lo he visto: "A este real decreto le seguirá la orden ministerial de desarrollo técnico, a partir de la cual los desarrolladores de programas informáticos deberán someterse a sus disposiciones en un plazo máximo de 9 meses." O sea, que hasta no publiquen el desarrollo técnico no empieza el plazo. Vale. Y ya puestos pregunto: También dicen que la gente puede usar el Kit Digital para estas modificaciones y yo tenía entendido que el Kit Digital no financia modificaciones de programas, solo nuevas soluciones y con unos requerimientos casi imposibles de cumplir. ¿Alguien sabe algo de esto? Saludos.
__________________
Be water my friend. |
#7
|
|||
|
|||
Cita:
Los requerimientos para la solución de Facturación Electronica del Kit Digital para los segmentos II y III estan adaptados para Veri*Factu. De hecho, los requerimientos son compatibles con TicketBAI y nosotros hemos justificado y financiado con los fondos del Kit Digital cientos de clientes que usan nuestro software de TicketBAI. Las evidencias que piden son, entre otras cosas, la posibilidad de la verificación de la factura (QR), REGISTRO DE FACTURACIÓN,(integridad, conservación, accesibilidad, legibilidad, trazabilidad, e inalterabilidad de los datos), una declaración responsable etc... Cruzamos dedos que quedan fondos para adaptar a todas las empresas y autonomos de españa ;-) |
#8
|
||||
|
||||
Cita:
Gracias por tu respuesta pero (corrígeme si estoy equivocado). ¿No piden que el programa tenga API? ¿por ejemplo? Aparte de que quiero recordar que dice expresamente que no financia modificaciones a lo que hay, tendría que rebuscar en la normativa pero creo que lo he leido en alguna parte. ¿Tú en las justificaciones de software no has tenido que informar del tema API? Saludos.
__________________
Be water my friend. |
#9
|
|||
|
|||
Cita:
Pero se puede discutir. |
#10
|
||||
|
||||
Cita:
Creo que no es posible, porque te olvidas de que cuando le entregas o le envías la factura/ticket al cliente, esa factura incluye el código QR (que para eso obligan a ponerlo). Ese código QR lleva información del firmado de la factura y del encadenamiento. Si vuelves a generar como tú dices y "regeneras" toda esa información, no coincidirá con lo que tiene el cliente. Por eso una vez enviada/impresa ya no se puede modificar. Imagino que si generas 2 facturas, no las envías al cliente (es decir, no han salido de tu sistema), esas 2 últimas facturas podrías borrarlas y volver a generarlas (y sus encadenamientos), pero en cuando el cliente tiene una copia, eso ya no es posible (al menos de esa factura y las anteriores).
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#11
|
|||
|
|||
Cita:
La integridad e inalterabilidad de los datos registrados se asegurará utilizando cualquier proceso técnico fiable que garantice el carácter fidedigno y completo de los registros de facturación desde que hayan sido grabados en el sistema informático |
#12
|
||||
|
||||
Cita:
A partir de ese momento (*) no se puede modificar y tu sistema debe implementar "algo" para asegurarlo. El qué ya será cosa de cada uno.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#13
|
|||
|
|||
Cita:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
|