Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por oscarperez-1980

Mi propuesta es bastante sencilla:
1.- Enumerar los puntos a cumplir.
2.- Cada participante expone como haría él el desarrollo o solución al punto.

Se puede hacer con un documento de gmail donde cada uno pueda agregar texto para poner lo en común, se comparte con los interesados y ya está.

Saludos.

Me parece bien y ya cuando tengamos algo lo subimos al foro para compartirlo.

[oscarperez-1980]

Alguien más interesado?
Yo ya lo tengo analizado y no lo veo complejo, el registro es de lo más curioso, lo quieren detallado para exportar a Excel y que no tengan que hacer nada.

[afxe]

Me apunto... pero tengo nula experiencia en ticketBai y blockchain.

De todas maneras, y para centrar el tema, estamos hablando que esto sólo afecta a la facturación. Imagino que no habrá que hacer un manual del todo el software ni registrar todos los eventos que no tengan que ver con la propia gestión de facturación.... ¿no?

Creo que se ha comentado que una posibilidad es "sacar" la gestión de facturación del ERP. Yo estaba planteándome esto, un programa básico: Cabecera-Detalle para registrar las facturas: sin clientes ni artículos ni comerciales, almacenes, stock, fabricación, envasado, órdenes de trabajo, gestión de averías... El ERP, llegado el momento de cerrar un servicio o entregar una mercancía, generaría un registro para ser procesado por este programa, que devolvería al ERP un identificador para el tratamiento y la gestión de cobro.

¿Obligarían a certificar el ERP principal aunque no tenga facturación?

[Sistel]

Empezado por afxe

...
Creo que se ha comentado que una posibilidad es "sacar" la gestión de facturación del ERP. Yo estaba planteándome esto, un programa básico: Cabecera-Detalle para registrar las facturas: sin clientes ni artículos ni comerciales, almacenes, stock, fabricación, envasado, órdenes de trabajo, gestión de averías... El ERP, llegado el momento de cerrar un servicio o entregar una mercancía, generaría un registro para ser procesado por este programa, que devolvería al ERP un identificador para el tratamiento y la gestión de cobro.

Hola afxe,

Es lo que hace nuestra API online para TicketBAI.
El cliente tiene un ERP, TPV o programa simple de facturación.
Cuando quiere emitir una factura, su sistema de facturación envía a nuestra API un JSON con los datos de la factura a emitir (datos del destinatario, tipo de factura, líneas de detalle, etc)
Nuestra API le devuelve un JSON con los datos de la factura emitida (serie, número, fecha y hora de la factura, desgloses de bases imponibles, IVAs y total de la factura, códigos TBAI y QR, ...)
Por separado, la API envía el fichero XML firmado de la factura a Hacienda.

De esta forma, independizas el sistema de facturación del sistema de generación y envío de facturas a Hacienda.
Y como el cliente no puede modificar ni borrar las facturas (que quedan en la BD de la API) queda todo protegido.

Saludos

[oscarperez-1980]

Hola, que api tenéis para el país vasco? Cual es la empresa?

Gracias

Empezado por Sistel

Hola afxe,

Es lo que hace nuestra API online para TicketBAI.
El cliente tiene un ERP, TPV o programa simple de facturación.
Cuando quiere emitir una factura, su sistema de facturación envía a nuestra API un JSON con los datos de la factura a emitir (datos del destinatario, tipo de factura, líneas de detalle, etc)
Nuestra API le devuelve un JSON con los datos de la factura emitida (serie, número, fecha y hora de la factura, desgloses de bases imponibles, IVAs y total de la factura, códigos TBAI y QR, ...)
Por separado, la API envía el fichero XML firmado de la factura a Hacienda.

De esta forma, independizas el sistema de facturación del sistema de generación y envío de facturas a Hacienda.
Y como el cliente no puede modificar ni borrar las facturas (que quedan en la BD de la API) queda todo protegido.

Saludos

[Sistel]

Empezado por oscarperez-1980

Hola, que api tenéis para el país vasco? Cual es la empresa?

Gracias

Hola oscarperez-1980

Como no me parece correcto que pongamos en este foro publicidad de nuestros negocios, te contestaré por mensaje privado.
Si alguien más está interesado en conocer (y probar, gratuitamente y sin compromiso alguno) nuestra API para TicketBAI, puede enviarme mensaje privado.

Gracias.

Saludos

[oscarperez-1980]

El log según pone es de TODO.
Si un programa no tiene facturación a ellos les da igual, si separas en dos programas pues lo implementa en uno.

Saludos.

Empezado por afxe

Me apunto... pero tengo nula experiencia en ticketBai y blockchain.

De todas maneras, y para centrar el tema, estamos hablando que esto sólo afecta a la facturación. Imagino que no habrá que hacer un manual del todo el software ni registrar todos los eventos que no tengan que ver con la propia gestión de facturación.... ¿no?

Creo que se ha comentado que una posibilidad es "sacar" la gestión de facturación del ERP. Yo estaba planteándome esto, un programa básico: Cabecera-Detalle para registrar las facturas: sin clientes ni artículos ni comerciales, almacenes, stock, fabricación, envasado, órdenes de trabajo, gestión de averías... El ERP, llegado el momento de cerrar un servicio o entregar una mercancía, generaría un registro para ser procesado por este programa, que devolvería al ERP un identificador para el tratamiento y la gestión de cobro.

¿Obligarían a certificar el ERP principal aunque no tenga facturación?

[Javierus]

Empezado por oscarperez-1980

El log según pone es de TODO.

Me he perdido algo, ¿podrías decirme dónde pone esto del log, por favor?

¡Gracias!

[ermendalenda]

Empezado por Javierus

Me he perdido algo, ¿podrías decirme dónde pone esto del log, por favor?

¡Gracias!

Llamalo mejor "eventos"

PROYECTO DE REAL DECRETO XX/2022, DE XX DE XXXX POR EL QUE SE APRUEBA 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.

4. El sistema informático deberá contar con un registro de eventos que recoja automáticamente
todas las interacciones con dicho sistema informático, las operaciones realizadas con él y los
sucesos producidos durante su uso, como el arranque y parada del sistema informático, la entrada
y salida de usuarios, los errores producidos, la instalación inicial y las actualizaciones realizadas.
Además, deberá guardar los datos correspondientes a cada uno de ellos, como el tipo, nombre y
descripción del evento; el usuario que lo ha realizado o bajo el cual se ha producido; el momento
en el que se ha dado y los datos propios representativos de cada evento.
Este registro de eventos podrá ser consultado desde el propio sistema informático y los datos
grabados automáticamente en él por dicho sistema informático no podrán ser alterados de
ninguna forma con posterioridad, ni desde el propio sistema informático ni desde fuera del mismo,lo que deberá garantizarse mediante el empleo de cualquier proceso técnico fiable. Cualquier
intento de alteración de este registro de eventos, o inconsistencia o irregularidad en él que sea
detectado por el sistema informático, deberá registrarlo también automáticamente en el propio
registro de eventos.
El registro de eventos deberá conservarse hasta el periodo de prescripción de las obligaciones
tributarias que se produzcan durante el funcionamiento del sistema informático y, mediante el
empleo de cualquier proceso técnico fiable, podrá ser exportado a un almacenamiento externo de
forma segura que garantice la integridad e inalterabilidad de sus datos, que tendrán una estructura
y formato estándares legibles.

[nincillo]

Empezado por oscarperez-1980

Alguien más interesado?
Yo ya lo tengo analizado y no lo veo complejo, el registro es de lo más curioso, lo quieren detallado para exportar a Excel y que no tengan que hacer nada.

Yo también estaría interesado. Pero de blockchain etc soy novato total...

[oscarperez-1980]

Exacto, como pone el compi lo llama registro de eventos


4. El sistema informático deberá contar con un registro de eventos que recoja automáticamente
todas las interacciones con dicho sistema informático, las operaciones realizadas con él y los
sucesos producidos durante su uso

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

Empezado por oscarperez-1980

4. El sistema informático deberá contar con un registro de eventos que recoja automáticamente
todas las interacciones con dicho sistema informático, las operaciones realizadas con él y los
sucesos producidos durante su uso

Quiero entender que eso sólo afecta todo lo que se refiera a "facturación" (es decir, lo que concierne a la AEAT).
En el caso de TBAI (que parece lógico), esto afecta sóo estrictamente a los campos que "le interesan a la hacienda vasca" (los que se envían).
Lo digo por aclarar, es que ese "TODAS" creo que no queda claro y puede llevar a confusión.

NOTA: O al menos eso "quiero" entender yo. Habrá que esperar a que lo aclaren.

[oscarperez-1980]

Yo entiendo que todo es de todo, no solo de facturación y tiene lógica, para ver si hay algo raro oculto...
Además ya que se pone un log.. Pues mejor de todo, es mi opinión.

Saludos.

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

Quiero entender que eso sólo afecta todo lo que se refiera a "facturación" (es decir, lo que concierne a la AEAT).
En el caso de TBAI (que parece lógico), esto afecta sóo estrictamente a los campos que "le interesan a la hacienda vasca" (los que se envían).
Lo digo por aclarar, es que ese "TODAS" creo que no queda claro y puede llevar a confusión.

NOTA: O al menos eso "quiero" entender yo. Habrá que esperar a que lo aclaren.

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

Empezado por oscarperez-1980

Yo entiendo que todo es de todo, no solo de facturación y tiene lógica, para ver si hay algo raro oculto...

Pero estamos dentro de un contexto de ley antifraude, que se refiere a "facturación".
¿Crees que esto me debe obligar a almacenar eventos de todos mis cambios en todas mis tablas?
Pienso en tablas como (por poner alguna): REPRESENTANTES, LOGOS, POBLACIONES, PAISES, CODIGOS_ISO, OFERTAS, CONTACTOS, DIRECCIONES_ENVIO, EMBALAJES, FASES, PIEZAS, INMUEBLES,...

Yo no le veo sentido ni justificación a que la ley antifraude me obligue a guardar "logs" de las operaciones realizadas en la tabla FASES (por poner un ejemplo).

Empezado por oscarperez-1980

...para ver si hay algo raro oculto...

¿Algo "oculto" en mi mantenimiento de provincias? (por decir algo)

Empezado por oscarperez-1980

Además ya que se pone un log.. Pues mejor de todo, es mi opinión.

Si tienes una Base Bases de Datos de cliente con 6GB/400 tablas y X operaciones diarias, la decisión no es tan sencilla como "ya que lo ponemos, lo ponemos a todo".
Piensa que eso implica no sólo cambios en la aplicación, sino seguramente en otros muchos aspectos.
Lo primero que se me ocurre es ¿Cómo puede crecer esa Base de Datos si a las 400 tablas les debo añadir "eventos" para todas las operaciones?

¿Porqué pienso esto? (lo dicho anteriomente)
Me baso en la experiencia de TicketBAI (y en la idea final que se ha implementado), en donde ellos quieren asegurar al final, que una factura no pueda ser modificada de ninguna forma, una vez emitida.

Esto dicho así, parece que significa que una vez generada una factura la debes poner en "sólo-lectura".
La respuesta de ellos fue que no.
Se puede modificar una factura emitida/enviada/Aceptada siempre y cuando no alteres los campos que afectan a TBAI. Si en tu factura incluyes NOTAS, REPRESENTANTES, CENTROSDECOSTE, LOGO, DIR_ENVIO, ALARMAS, RIESGO, DOMICILIACIONESBANCARIAS,... (por decir algo), puedes modificarlos sin problemas. A ellos esos campos NO LES INTERESAN (sólo los que afectan a la generación del XML de la factura).

Por eso creo que la "idea" en este caso irá por el mismo camino. Creo que cuando hablan de TODO, se refieren a temas de facturación (además de otros temas genéricos que tienen sentido, como login de usuarios, inicio y fin,...); Lo que pueda afectar a un fraude a la AEAT. Pero que yo modifique un CODIGO_ISO o una PROVINCIA no puede afectar a eso.

De todas formas, como ya hemos dicho, creo que nos estamos adelantando. Lo único que hay es un decreto ley (o documentación legal), no hay documentación técnica y por lo tanto técnicamente creo que no se debería empezar a desarrollar nada.