Re: Spécifications

[Frederic Schutz]

Le Mon, 21 May 2001 10:05:38 +0200, tu as ecrit :

Hello Alex et tout le monde,

>De façon a pouvoir commencer le développement de notre logiciel de compta
>j'ai ecrit tout ce qui me passait par la tete concernant ce projet. 
>Ces quelques lignes peuvent constituer le début de spécifications et
>j'attend vos remarques et questions a ce sujet.

Merci pour tout ça ! J'avais aussi écrit quelques idées sur papier, mais
n'ai jamais pris le temps de les taper... j'en intègre une partie dans mes
commentaires rapides ci-dessous.

>Le développement d'interfaces de saisie et de visualisation ne fait pas partie du présent projet.

J'ai entamé (enfin... à peine commencé) une interface Web avec PHP. 

>4. Le début de l'exercice doit constituer une date inviolable

Qu'entends-tu par là ? Sous-entends-tu que le début de l'exercice est
défini par la fin de l'exercice précédent, pour éviter un quelconque trou ?

>1. Le mot de passe ne doit jamais être repérable

Au niveau de la base de données, ça peut se traduire par une empreinte de
mot de passe (hash MD5 ou SHA-1), ou par une clé publique. Concernant la
sécurité durant un accès, et l'utilisation éventuelle de SSL, ça fait plus
partie de la partie interfaces.

>2. Sauvegarde des données simple, rapide et protégée par mot de passe

Dépend de la base de données, ou pensais-tu à un système d'export ?

>Les sociétés,
>- Le numéro de la société
>- Un libellé, une adresse
>- La monnaie de base

Un champ libre ? 

>Le plan comptable,
>- La société
>- L'exercice comptable
>- Le numéro du compte
>- Le libellé du compte
>- Une clé de regroupement qui en général est proche du numéro de compte. Elle permet de savoir a quel compte 'père' il appartient.
>- La devise (si compte en multi-monnaie)

Est-il nécessaire d'indiquer un type de compte (Actif, Passif, etc) ? Un
champ "solde du compte à l'ouverture de l'exercice" ne serait-il pas
nécessaire, si on ne veut pas obliger les utilisateurs à passer des
écritures d'ouverture ? 

Peux-tu préciser la notion de clé de regroupement ? Le compte père est-il
un compte faisant partie du plan comptable (et la clé est-elle simplement
le numéro de ce compte) ? Si oui, est-il aussi possible d'y enregistrer des
écritures ?

Sinon, ces comptes pères sont-ils listés quelque part  ?

Quand on veut générer un bilan, est-il nécessaire de parcourir toutes les
écritures pour calculer le solde des comptes, ou peut-on imaginer que
celui-ci soit stocké dans le plan comptable (champ "solde actuel") et mis à
jour à chaque ajout/modification ? Ce serait une sorte de cache qui
accélererait beaucoup les générations de bilan, surtout si aucune
modification n'a été faite. Bien sûr, ça nécessite une rigueur absolue du
point de vue de la mise à jour de ces soldes - mais nous voulons de toute
façon une rigueur absolue dans la compta :-)

>Le écritures,
>- La société

Son numéro

>- La provenance (CG, compta débiteurs, etc )
>- Le numéro de l'écriture

Chaque société doit avoir sa numérotation propre (ce qui empêche d'utiliser
l'"auto_increment" de la base de données). Où stocker le numéro de la
dernière écriture (si on veut éviter de devoir faire une requête sur toutes
les écritures à chaque enregistrement) ? Peut-être un nouveau champ dans la
description de la société ?

>- Le numéro du lot

Je proposerais d'utiliser le numéro de la première écriture du lot,
histoire de ne pas créer une autre numérotation.

>- Un numéro qui permet de retracer la comptabilisation (date, qui, etc)

Je ne comprends pas vraiment ce que tu veux intégrer dans ce champ qui ne
fasse pas double emploi avec les autres. As-tu un exemple ?

>Une fois une écriture comptabilisée il est IMPOSSIBLE de la modifier.

Hum. Je sais que c'est un des prérequis pour qu'une compta informatique
soit autorisée par le fisc français, mais c'est impossible dans le cas d'un
programme open-source (et pas beaucoup plus dans le cas d'un programme
closed-source).

Je pense que le comptable que tu es va hurler, mais à mon avis, cette
impossibilité de modification ne s'impose que pour une société plus ou
moins grande, et surtout si la compta admet plusieurs utilisateurs. Par
contre, quand je tiens la comptabilité d'une association (ou si un
indépendant fait sa compta, p.ex.), j'aime être libre et pouvoir faire ce
que je veux !

Je préférerais donc que cette propriété ne soit pas obligatoire. A voir
comment ça se traduit dans les options.

Plus généralement, penses-tu qu'il doit être possible d'effacer une
écriture ? (quand je dis effacer, je veux dire "marquer effacée", pour
qu'elle n'apparaisse plus dans les comptes, mais qu'elle figure toujours
dans le journal).

>La notion de 'provisoir / comptabilisé', 'nom de la personne qui a créé cette écriture', 'nom de la personne qui a fait la dernière modification de cette écriture', 'Le numéro qui permet de retracer la comptabilisation' étant identique pour toutes les écritures du même lot n'est-il pas mieux d'avoir ces info dans une table séparée ? 

Oui, c'est une bonne idée. Ca permet aussi d'alléger le tout si quelqu'un
utilise la compta en mono-utilisateurs ou mono-société, ou ne veut pas
utiliser la notion de provisoire/comptabilisé (cf mon commentaire plus haut
sur l'immuabilité des écritures...).

J'ajouterais un champ "libre" qui pourrait lier l'écriture à n'importe quoi
d'autre (une facture dans un autre programme, une pièce comptable scannée,
etc).

>- La provenance existe

Comment penses-tu lister les différentes provenances possibles ? Il faut
que le programme de compta les connaisse, même si les programmes
correspondants ont été créés et installés plus tard. On pourrait imaginer
que chaque module annexe (compta débiteurs, etc), au moment de son
installation, s'"enregistre" (p.ex. ajoute une ligne dans une table) pour
le programme soit au courant de son existence.

>- Personne ne modifie la même écriture a cet instant

Il doit y avoir moyen de faire des "locks" dans la base de données,
j'imagine (mais n'y connaît rien).

>Les authorisations:
>Chaque personne est membre d'un ou de plusieurs groups qui eux ont des authorisations d'écriture et de lecture (event. de modification) en fonction du numéro de compte, de la société et de l'exercice comptable.
>De plus il serait intéressant de donner des authorisations de 'processus'. Je pense en particulier a celui de la comptabilisation d'une écriture.

On pourrait également imaginer que chaque compta puisse être associée avec
une liste d'utilisateurs qui ont certains droits - l'équivalent des ACL
sous Unix, en comparaison avec le système de groupe. Ca reviendrait à créer
un groupe par compta, et augmenterait de beaucoup la taille des
autorisations. Mais je n'ai pas vraiment refléchi à la question des
utilisateurs.

Frédéric