A partir del 1 de enero de 2018, las empresas que registren los pagos de sus clientes mediante el software de contabilidad, gestión o caja registradora deberán cumplir con los nuevos requisitos legales: garantizar la inalterabilidad, la conservación y la conservación. archivo de entradas contables. Las plataformas OpenFlyers bajo la versión 4.2 ahora cumplen con esta nueva regulación al tiempo que ofrecen una nueva función para facilitar la cancelación de una entrada incorrecta y la generación automática de recibos de recibo enviados por correo electrónico.
INALTERABILIDAD DE LAS ESCRITURAS
OpenFlyers 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 (OpenFlyers cliente) y OpenFlyers. Del mismo modo que no modifica un importe registrado en un extracto de cuenta bancaria, no cambia las entradas validadas en OpenFlyers.
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 OpenFlyers 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 OpenFlyers 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.
Hasta ahora, cuando una actividad (por ejemplo, robo) tenía antes, y validado a continuación, si se detecta un error de forma retroactiva, tuvimos que introducir manualmente los asientos contables correctivas y cambiar las horas de vuelo totales de la aeronave para el cálculo del potencial restante no está distorsionado.
A partir de ahora, es suficiente cancelar el vuelo, a través de la nueva función creada para este fin, y luego volver a ingresarlo con los elementos buenos. La cancelación del vuelo genera automáticamente las siguientes entradas: creación de un nuevo vuelo cuya duración corresponde a la duración opuesta a la del vuelo que se va a cancelar (para un vuelo que se cancela que fue 1h20, el vuelo generado será -1h20), esto permite deducir directamente este tiempo de vuelo del total de horas de vuelo del diario de navegación del piloto y del diario de viaje de la aeronave. Por otro lado, se generan entradas contables que son estrictamente idénticas a las entradas contables iniciales pero opuestas. Por lo tanto, aquí de nuevo, el "efecto contable" de la primera entrada se cancela. Todos los registros generados en la base de datos se validan automáticamente y no se pueden cancelar. Al hacerlo, la trazabilidad de las operaciones está garantizada.
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