Re: Spécifications

[Alexandre Galletet]

On Sat, 26 May 2001, Frederic Schutz wrote:

> Le Wed, 23 May 2001 12:16:06 +0200, tu as ecrit :
> 
> 
> Comme je l'ai déjà dit, de façon générale, je ne suis pas très convaincu
> par ce qui doit être IMPOSSIBLE. En plus du fait qu'il est impossible de
> rendre quelque chose impossible dans une compta open-source, j'ai vu trop
> de programmes qui brident leurs utilisateurs pour vouloir faire la même
> chose. Je pense qu'il faudrait définit une politique où toute une série de
> choses ne sont autorisées qu'au super-user (= celui qui de toute façon peut
> modifier ce qu'il veut en faisant directement des requêtes SQL), et sont
Quand je dis impossible je pense par là : impossible a faire normalement,
sans hacker le programme ou la DB. Il est claire qu'un administrateur
(informaticien) avec l'aide d'un comptable (de préférence) peuvent faire
ce qu'ils veulent; mais dans ce cas je ne prends plus aucune
responsabilité pour la cohérence des données (vu la GPL, en temps normal
non plus).

> >> Est-il nécessaire d'indiquer un type de compte (Actif, Passif, etc) ? Un
> >Oui, cela est envisageable (actif, passif, mixte, resultat)
> 
> Là, j'avoue ne pas y connaître grand chose. Qu'est-ce qu'un compte mixte ?
C'est un compte qui peut aussi bien etre à l'actif qu'au
passif. Tipiquement un compte de banque, un compte courant, etc. La
position Actif ou passif est determinée par le solde +/-.

> 
> Donc les comptes de regroupement dans l'exemple seraient "32" et "42" si je
> suis bien ?
Je pense que les 'comptes de regroupement' doivent se trouver 'listés' au
niveau de l'interface. Ce que nous devons fournir c'est la possibilité
d'avoir la somme de 101??? ou de 2????? p.ex.

> 
> Ou dans le plan comptable, mais comme compte de regroupements qui
> n'acceptent pas d'écritures, juste des reports (cf ce que je disais plus
> haut).
Comme je le dis plus haut, je pense pas que nous devions lister les
comptes de regroupement.
> >> 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 qui influe néanmoins sur les spécifications des tables.
Oui, mais je ne connais pas assez les DB (et en particulier leur
rapidité) pour dire si oui ou non il faut garder en memoir le solde des
comptes.

> 
> >> 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é ?
> 
> Ok pour ajouter ce champ dans les specifications ?
OK voir les 'parametres' dans nvelles spec.

> >> >- 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.
> 
> Ok, donc ce n'est pas vraiment un numéro, ce serait un champ du genre
> "FS/24.5.2001" (utilisateur + date de comptabilisation)
Oui, mais comme plusieurs écritures sont concernée par les memes infos, je
pense qu'il est mieux de garder ces donnees dans une autre table.

> >> 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.
> 
> De nouveau, un "root" devrait être capable de faire ça dans certains cas
> précis. Problème que j'ai rencontré concrètement: un module de compta
> débiteurs comptabilisait des écritures qu'on ne pouvait plus effacer depuis
> la compta générale (normal). Le module a planté une fois, et a généré une
> partie des écritures, qu'il n'a jamais plus reconnues ensuite. Résultat,
> aucun des modules ne pouvait toucher à ces écritures. Je ne me souviens
> d'ailleurs plus comment on avait résolu le problème (je crois qu'on ne
> l'avait pas résolu).
Oui tu as raison 'root' et un comptable doivent avoir ce droit.
> 
> > > 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
> 
> Je pose la question autrement: dans ton idée, quand une écriture
> comptabilisée doit être annulée, y a-t-il une autre façon que de passer une
> extourne (écriture qui annule la précédente) ? (d'ailleurs dans ce cas, il
> faudrait néanmoins pouvoir marquer qu'une écriture a été extournée)
> 
> Je pense qu'il doit aussi y avoir de la flexibilité sur ce point de vue là.
> Dans une banque par exemple, il est hors de question d'effacer une
> écriture, seule des extournes seraient admises. Dans une PME (cas que je
> connais mieux), on préfère souvent effacer l'écriture, qui apparaît
> toujours dans le journal (deux fois, une fois pour l'écriture, une fois
> pour l'effacement, avec date et personne qui l'a effacée), mais qui
> n'apparaît plus dans les comptes/grand livre.
Dans le cas d'une erreur purement comptable seul une extourne permet une
annulation d'écriture. Dans le cas d'une erreur technique je pense que
'root' peut faire 'DELETE FROM table WHERE id=xxx ;' pour corriger cette
errreur.

> >> 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.
> 
> Exemple concret et réel. Je suis encore trésorier d'une musique en Suisse.
> Bien sûr, d'autres que moi s'occupent de la gestion au jour le jour et de
> comptabiliser le tout. Quand ils ne savent pas où comptabiliser une recette
> quelque chose, ils scannent la pièce, me l'envoient par email pour que je
> leur réponde.
> 
> J'aimerais bien qu'ils aient une compta dans laquelle ils passeraient les
> écritures (en les comptabilisant p.ex. dans un compte d'attente), et y
> associeraient directement la pièce scannée. De cette manière, je pourrais
> régulièrement consulter ce compte via le web, voir le libellé de
> l'écriture, et si ça ne me suffit pas, cliquer pour voir s'afficher la
> pièce comptable, pour voir où comptabiliser le tout après.
La je maintient ma position, à mon avis ce champ est un doublon pour les
raison évoquée plus haut. Mais ton problème devrait ^etre résolu au niveau
de l'interface et non pas au niveau de notre projet, car je pense qu'il
est trop spécifique pour qu'on en tienne compte (ne le prend pas mal :-).

> Peux-tu reposter une mise à jour de tes spécifications, et on pourrait déjà
> commencer à discuter comment les transposer en SQL ?
Oui, je vais juste y mettre un peu d'ordre.

Merci 
Alex