Forum AtoutFox : Re: Quid du respect des conditions fiscales et légales des logiciels de gestion commerciale et ou de caisse ?   

jeu. 17 novembre 2016, 12h36

GLS
France
atoutfox.public.association

Re: Quid du respect des conditions fiscales et légales des logiciels de gestion commerciale et ou de caisse ?

Bonjour Thierry

<div class="citation1">

La loi impose de conserver chaque mouvement unitaire, sans modification des écritures passées; il faut donc:
- ajouter des références internes dans la table liant les opérations successives (self join)
</div>
GLS -> Ce que tu appelles références internes pourraient - elles être la clé primaire auto-incrément. Et si oui dans chaque nouvel enregistrement il y a une colonne contenant la clé primaire de l'enregistrement précédent ?
<div class="citation1">
- remplacer les UPDATE par des INSERT
- remplacer les vues par des cursorAdapter (select recursif) pour présenter les enregistrements dans leur état courant compte tenu des évolutions successives
</div>
GLS -> je ne maitrise pas encore les cursoradapter et encore moins un SELECT récursif..
GLS -> La loi de conservation des mouvements unitaires ne semblent pas s'adresser à l'ensemble des données gérées par le logiciel, mais uniquement aux données liées aux règlements/encaissement/décaissement, aux factures et aux opérations de clôture.
Cela limite le champ des données à traiter. Seuls des INSERT avec un horodatage seraient à utiliser, sans possibilité d'UPDATE ou de DELETE, pour gérer des tables d'historisation des règlements/encaissement/décaissement, factures et opérations de clôture.
Est-ce que mon analyse est pertinente ?
La gestion de type self join, ni d'ailleurs la gestion simple d'un historique des élements financiers de facturation et d'encaissement, n'empêche une modification à postériori par une application externe. Ce que le fisc veut a tout pris éviter, c'est que l'éditeur du logiciel certifié puisse modifier en toute connaissance de moyen ces données sensibles.
C'est cette problématique qui me parait extrêmement difficile à résoudre!!

<div class="citation1">

- par NTFS, donner aux utilisateur l'accès en lecture/écriture, pas d'accès complet permettant l'effacement ou le remplacement d'une table
</div>
GLS -> Je suis béotien en la matière. Ces commandes NTFS peuvent elles être lancée directement par l'application certifiée ? et si oui sur tout OS compatible avec VFP ?
<div class="citation1">
- par DBC event, en cas d'ouverture d'une table dans l'IDE (_VFP.startmode = 0), demander une identification
</div>
GLS -> Cela règle, l'ouverture par un IDE VFP et quid d'un OLEDB ou d'un ODBC pour Foxpro, ainsi que le bidouillage directe sur les fichiers dbf, dbc, etc.. Cet aspect de sécurisation des accès aux données est à parfaitement traiter, surtout pour empêcher une utilisation par des logiciels externes. C'est idem au cas 1
<div class="citation1">
- par règles de tables, journaliser l'identité de l'utilisateur à chaque UPDATE/INSERT
- encrypter les informations sensibles (MD5)
</div>
GLS -> Cela fait parti des action à mener, mais il me semble que ce ne soit pas suffisant lorsque seul le contenu des tables est encrypté. La structure des DBF étant parfaitement maitrisée et connue, rien n'empêche avec editeur binaire de venir supprimer des enregistrements ou des données cryptées, ou alors il faudrait que ce soient l'ensemble des fichiers dees tables qui soient cryptés ??

<div class="citation1">

pour ça les solutions ne manquent pas…
</div>
GLS -> Accessoirement je suis d'accord. Seulement aucune ne permet de gérer dans sa globalité l'ensemble des processus y compris celui de l'archivage / purge des données du logiciel certifié.
Trouver dans toutes ces nombreuses solutions, celles permettant d'accorder automatiquement tous les processus sous controle unique du logiciel certifié, me parait être un enjeu important à maitriser.

Amicalement
Gilles

Permalink : http://www.atoutfox.org/nntp.asp?ID=0000017962