Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[seccion__31]

Buenos dias !

aunque mi usuario es nuevo, ya estuve presente en este foro en otro momento critico, durante la implantacion del SII, (bajo seccion31), como no pude recuperar la contraseña, he decidido crear un usuario nuevo para dar seguimiento a este hilo.

He leido todos los posteos, y voy a dar mi opinion y quizas alguna informacion nueva:

Cumplir los requisitos para adaptarse a la ley es una oportunidad de negocio y seguramente todos los que estamos aqui una vez se publique la informacion tecnica no tendremos problemas en adaptar los programas.

Podremos hablar de eso con mas exactitud cuando sepamos mas.


Lo que mas me preocupa es el tema de la certificacion: porque no se ha dado informacion.

Si exigen una certificacion onerosa por un certificador independiente, muchos pequeños negocios de programacion quizas tengan que cerrar, mas aun si la certificacion es necesaria con cualquier cambio del software, el coste a los usuarios aumentara y quizas a alguno, les resulte mas rentable, emitir facturas con un word, o una excel. El resultado final puede ser un monopolio de unas cuantas empreas que se queden con el mercado de programas de gestion. Quizas sea muy apocaliptico...

¿van a exigir una certificacion por cada modificacion? ¿por periodo de tiempo?
¿van a exigir el mismo nivel de certificacion a un programa que vale 60.000 euros que a otro que cuesta 200?
¿van a exigir el mismo nivel de certificacion a un comerciante que vende 2 programas al año que otro que tiene 2000 instalaciones?

Bueno...

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:

NF525 : Lo que cambia en el lado de los comerciantes

Como ya se ha mencionado, si desea utilizar un software de contabilidad, gestión o sistema de caja registradora, el minorista está obligado a elegir uno que cumpla con la certificación NF 525.

Para probar esto a las autoridades fiscales, tiene la opción de elegir entre dos opciones :

por un lado, tenga un documento que acredite la certificación NF525 del software que ha elegido y que normalmente se suministra con este último para su compra,
o, por otro lado, tener una autocertificación individual proporcionada por el editor del software.

La autocertificación es una alternativa al largo procedimiento de certificación y se hace en binomio con el comerciante que desea utilizar un software aún no certificado NF525.



En este caso, los dos protagonistas se dirigen juntos a las autoridades fiscales rellenando una solicitud en dos partes, en la primera de las cuales se presenta la información sobre el editor y en la segunda la información sobre el comerciante. Una vez validada la solicitud, se considera que el software cumple con las normas de certificación NF525 y, por lo tanto, es legalmente utilizable.

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

La AEAT ya esta haciendo algo similar homologando programas de digitalizacion de facturas

En fin,
un saludo a todos

copiado de otro foro:

dolibarr.es

(lo pongo asi porque no me deja)

Buenos días,

Hace tiempo hice consulta en hacienda, y hoy me han comentado esto:

"...Esta nueva obligación se aplicará a partir del próximo 11 de octubre. No obstante, la propia norma establece que
el desarrollo de esta se producirá reglamentariamente y la misma todavía no se ha producido, por lo que hasta la
fecha no se disponen de las especificaciones necesarias para que las empresas fabricantes, productoras y
comercializadoras de software puedan dar cumplimiento a los requisitos establecidos en el artículo 29.2.j) de la
LGT, así como poder certificar su software.
Lo que implica que mientras no se disponga de dicho desarrollo reglamentario, la compañía no podrá certificar su
software y a su vez, los usuarios no estarán incumpliendo la normativa, lo que comportará la no aplicación del
régimen sancionador establecido para la misma.
En cuanto se establezca reglamentariamente el desarrollo de dicha norma, se podrán realizar las actuaciones
oportunas para adecuar el software a la normativa actual...."

[Casimiro Notevi]

Bien, todavía no hay nada, así que a esperar.

Buenos días,
Hace tiempo hice consulta en hacienda, y hoy me han comentado esto:
"...Esta nueva obligación se aplicará a partir del próximo 11 de octubre. No obstante, la propia norma establece que
el desarrollo de esta se producirá reglamentariamente y la misma todavía no se ha producido, por lo que hasta la
fecha no se disponen de las especificaciones necesarias para que las empresas fabricantes, productoras y
comercializadoras de software puedan dar cumplimiento a los requisitos establecidos en el artículo 29.2.j) de la
LGT, así como poder certificar su software.
Lo que implica que mientras no se disponga de dicho desarrollo reglamentario, la compañía no podrá certificar su
software y a su vez, los usuarios no estarán incumpliendo la normativa, lo que comportará la no aplicación del
régimen sancionador establecido para la misma.
En cuanto se establezca reglamentariamente el desarrollo de dicha norma, se podrán realizar las actuaciones
oportunas para adecuar el software a la normativa actual...."

[ermendalenda]

Empezado por Casimiro Notevi

Bien, todavía no hay nada, así que a esperar.

Como pidan una certificación ISO por una empresa homologada como AENOR, nos vamos al paro el 90%.
Yo pienso que la certificación puede ir más a algo más trivial, con un formulario de compromiso que el software cumple las normas establecidas

[seccion__31]

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


El fabricate paymash, lo utiliza:

¿Por qué Paymash decidió obtener una certificación individual?
Como se describe en este artículo, Paymash cumple los requisitos de las autoridades fiscales y los supera en muchos aspectos.


Por ejemplo, Paymash también cumple con las obligaciones fiscales en otros países europeos como Austria o Alemania. Paymash ha optado por la certificación individual.


Como suele ocurrir cuando una ley quiere regular un mercado, hay empresas que quieren beneficiarse de ella. En Francia, se trata principalmente de empresas privadas como INFOCERT con su norma NF525 o de organismos estatales como el Laboratoire National d'Essais.


El uso de estos organismos es obligatorio por ley cuando los distribuidores desarrollan su propio software de punto de venta.


Esto es especialmente cierto para los grandes distribuidores que quieren controlar su proceso de venta de principio a fin. En el caso de un minorista que confía en un proveedor de TPV independiente como Paymash, el uso de un certificador de terceros es opcional.


Paymash no quería recurrir a estas organizaciones porque las especificaciones que ofrecen son demasiado rígidas y nos frenan en la innovación.

[josemmerida]

La información que manejo ahora mismo proviene de nuestro asesor fiscal y la suya de lo que se cuece en Hacienda:

-Los programadores deberán firmar una Declaración Responsable comprometiéndose a que su software cumple con la normativa. Si no la cumple 150.000€ de multa.
-Las empresas que usen ese Software “solo” pagarán 1000€ de multa.
-Este año el régimen sancionador no se aplicará.

Ahora mismo me parece más un rumor que otra cosa.

Saludos

[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?

[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?

Tiene más que ver en el envío de los registros con un formato determinado y con firma electrónica a un webservice. Lo que a mi me preocupa es que datos van a querer, aunque supongo que empezarán por las facturas y espero que se planten.

[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.

[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.

[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.