Re: Spécifications

[Alexandre Galletet]

On Wed, 23 May 2001, Frederic Schutz wrote:

> Le Mon, 21 May 2001 10:05:38 +0200, tu as ecrit :
> 
> >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 ?
A mon avis cela signifie que une fois l'exercice defini (date de debut et
date de fin) et qu'il comporte une écriture, il est impossible de modifier
la date de debut de l'exercice.

Je pense qu'un exercice comporte une date de debut ET une date de fin,
quitte a avoir un '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.
OK

> >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 ?
Non, cela dépend de la base de donnée.

> >Les sociétés, 
>- Le numéro de la société 
>- Un libellé, une adresse
> >- La monnaie de base
> 
> Un champ libre ? 
Heu... oui, mais pourquoi ?
> 
> >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
Oui, cela est envisageable (actif, passif, mixte, resultat)
> 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 ? 
Oui, j'ai déjà ajouté ce champ dans un nouvelle spec.
> 
> 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 ?
TOUS les comptes font partie du plan comptable!

Ls cle de regroupement permet d'avoir rapidement des chiffres clé et de
présenter un compte bilan/pp bien structuré.

Si le plan comptable est bien structuré la clé de regroupement est un
doublon du numéro de compte. Imaginons ce cas la (no compte == cle
regroupement).
La somme des comptes 1????? = montant des actifs
La somme des comptes 3????? =montant des ventes
La somme des comptes 32???? = montant des ventes(3) de marchandise(2)
La somme des comptes 34???? = montant des ventes(3) de prest. de
service(4)
La somme des comptes 42???? = montant des achats(4) de marchandise(2)

Ce qui implique 32???? - 42???? = résultat brut des ventes de marchandise
Si au 3eme digite on précise '0' a la place de '?' ce ne cera que les
marchandise du secteur 'A' et non plus de tous les secteurs.

n.b. ces cles de regroupement sont tirées du Plan Comptable Général PME et
peuvent varier d'une compta à une autre et d'un pays à un autre.


> Sinon, ces comptes pères sont-ils listés quelque part  ?
Il n'y a donc pas de compte 'pere', mais plustot des regroupement a lister
dans une autre table. (le mot compte pere est une erreur de ma 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 :-)
C'est un problème purement informatique, mais ta solution de cache est
envisageable et deja utilisée par certains logiciels. Si on retient cette
solution, 'absolue' doit s'écrire en majuscule :-)

> >Le écritures,
> >- La société
> 
> Son numéro
Tout a fait
 
> >- 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
Oui
> 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.
Ca me semble une bonne idée

> >- 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 ?
Les écritures sont saisie (provisoire) par qqn puis comptabilisée
(validée) par une autre ou meme personne a une autre date. Ces deux
dernieres infos (date et personne) meritent d'^etre enregistrées.
 
> >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 !
OK, mais libre a toi aussi de ne comptabiliser les écritures 2001 en 2002
ou 2003.
> Je préférerais donc que cette propriété ne soit pas obligatoire. A voir
> comment ça se traduit dans les options.
A mon avis c'est dangereux.
Prend l'exemple ou une écriture est générée par la compta débiteur (donc
comptabilisé) et que tu viens toi en compta générale supprimer cette
écriture... bonjour les dégats : tu aurais (p.ex.) en CG un compte
débiteur de 20000 et un total des débiteurs en compta débiteurs de 19000
tu risques de recherche longtemps la cause de cette différence.


 > 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).
Mouais .... a voire

> >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).
A mon avis il y a doublon : 
- si c'est une écriture de CG il y a le libellé pour ca.
- si l'écriture vient d'un autre programme la provenance permet cette
recherche premierement et l'écriture correspond en générale a plusieurs
autres écritures (p.ex. a 20 encaissments débiteur) donc il est difficile
de lister 20 pieces scannées.

> >- 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.
Tu as raison
 
> >- 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).
J'espère


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

Merci pour ton aide et tes questions

A+
Alex