INALTERABILIDAD DE LAS ESCRITURAS

ReservationAutoEcole.com siempre se ha negado a modificar las entradas contables validadas en la base de datos. De hecho, la confianza en el software es compartido entre las tres partes que son el usuario final (a menudo estructura de clientes), la estructura (ReservationAutoEcole.com cliente) y ReservationAutoEcole.com. Del mismo modo que no modifica un importe registrado en un extracto de cuenta bancaria, no cambia las entradas validadas en ReservationAutoEcole.com.

ARTÍCULO 286 DE CGI

Sin embargo, esta regla, que se basó únicamente en nuestra voluntad, no es suficiente en virtud del nuevo artículo 286 del Código General de Impuestos que entra en vigor el 1 de enero de 2018:
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000034309494&cidTexte=LEGITEXT000006069577&categorieLien=id&dateTexte=20180101

mediante el artículo 88 de la Ley de finanzas para 2016:
https://www.legifrance.gouv.fr/eli/loi/2015/12/29/FCPX1519907L/jo#JORFARTI000031732968

El nuevo párrafo en este artículo es sobre software de contabilidad o administración o sistemas de efectivo. Su objetivo es luchar contra el fraude del IVA.

La versión 4.2 de ReservationAutoEcole.com cumple con la ley. La modificación esencial es la implementación de la encriptación de las escrituras para garantizar que no haya modificación de los datos validados y registrados en la base de datos.

Si su negocio está sujeto a IVA y que su organización no utiliza una plataforma ReservationAutoEcole.com bajo la versión 4, a continuación, le recomendamos que pida más fuertemente la migración en enero de 2018. Para otras estructuras, es necesario que usted compruebe si están preocupados por esta ley y si, por lo tanto, necesitan aprobar rápidamente en la versión 4.

Los clientes que lo deseen pueden encontrar un certificado de conformidad para completar y presentar a las autoridades fiscales en caso de control. Este certificado está disponible en el menú del área del cliente Ficha contacto › Arte de certificación. 286 del CGI.

MECANISMO DE ENCRIPTACIÓN

Estamos hablando de cifrado encadenado, porque el cifrado de un escrito genera un sello que tiene en cuenta el sello de la escritura anterior.

Visualmente, la inalterabilidad de la escritura está simbolizada por un candado que aparece en la columna Acciones de la línea correspondiente en los estados de cuenta. Este candado solo aparece cuando la cadena de scripting está en su lugar.

Se implementó una prueba para garantizar que el sello de la escritura no se falsificó. Esta prueba se basa en la regeneración de un sello para la escritura en cuestión teniendo en cuenta el sello anterior. Si los datos de "origen" son idénticos, el sello regenerado debe ser idéntico al sello registrado. Si este no es el caso, entonces esto significa que uno de los datos ha sido modificado: la cadena está rota. En este caso, el símbolo del candado aparece atenuado con una cruz roja. Normalmente este pictograma nunca debe ser visible.

Por supuesto, esta santificación de la base de datos no cambia el uso del software.

Para que este encadenamiento esté completamente garantizado, es necesario que el sello de encadenamiento esté en manos de un tercero de confianza. De hecho, siempre se podría imaginar el uso de la base de datos para modificar una entrada contable y luego regenerar todos los sellos en la cadena "descendente" de esta entrada, es decir, del conjunto de escritos que se han registrado a posteriori de la escritura modificada.

Al distribuir el sello inicial a un tercero, se hace público y, por lo tanto, se pierde la posibilidad de modificarlo "en secreto".

De hecho, cualquier persona puede comparar el sello inicialmente transmitido al tercero de confianza y el sello almacenado en la base de datos para verificar que no haya cambios.

Para la elección de un tercero de confianza, imaginamos una solución original: los propios usuarios a través de la implementación de una nueva función: el recibo de pago.

RECIBO DE PAGO

En el plazo de un minuto desde la validación del recibo, el software genera automáticamente un recibo, en forma de archivo PDF, por cada pago recibido. Este recibo contiene el sello de la cadena como una secuencia de 56 caracteres y una marca de tiempo. Se envía automáticamente por correo electrónico a la persona interesada. También está disponible en los estados de cuenta donde está simbolizado por un boleto.

Por lo tanto, al transmitir el recibo, con el sello, a cada usuario afectado, transmitimos cada vez a un tercero la información y no podemos "retroceder".

El interés de esta solución es doble:

• no es necesario recurrir a un tercero caro y confiable que sería incompatible con nuestros recursos
• esto hace posible establecer una nueva doble funcionalidad: la generación de recibos Y el envío automático de estos recibos.

Además, hemos añadido un campo en el formulario de entrada recibos que captura la dirección de correo electrónico de un cliente externo si la persona que realiza el pago no se ha registrado en la base de datos como usuario Esto permitirá que las estructuras automáticamente y simplemente envíen un recibo de recibo a sus clientes externos.

La documentación referente a esta santificación está disponible aquí:
https://openflyers.com/fr/doc/of4/Comptabilité#Inaltérabilité-des-données

CORRECCIÓN DE ERRORES DE ENTRADAS DE ACTIVIDADES

Para marcar este santuario, quisimos acompañarlo con una segunda característica nueva que apunta a simplificar la corrección de errores en la incautación de actividades.

La documentación relativa a esta nueva función está disponible aquí:
https://openflyers.com/fr/doc/of4/Gestion-des-activités#Annuler-une-activité-validée