Re: Spécifications

[Frederic Schutz]

Le Wed, 23 May 2001 12:16:06 +0200, tu as ecrit :

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

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
particulièrement découragées, plutôt que de les interdire.

Quels sont les avis des autres sur ce sujet pas spécifiquement comptable ?

Sur le fond, je suis d'accord avec toi (d'ailleurs, je n'ai jamais vu un
exercice changer de date de début après coup).

>Je pense qu'un exercice comporte une date de debut ET une date de fin,
>quitte a avoir un 'trou'.

Oui.

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

Comme pour les écritures, je pensais à pouvoir faire des liens sur p.ex. le
logo de la société pour imprimer les documents, ou je ne sais quoi. Pas
capital.

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

J'ai longtemps utilisé un programme de compta (pour l'anectode, il
fonctionne toujours parfaitement (modulo le bug de l'an 2000 qui oblige à
quelques acrobaties) sur un ordinateur DATA GENERAL installé au bureau de
mon père en 1984 - quand on dit que l'informatique évolue vite...) qui
classait les comptes selon leur type (compte d'écritures, compte de
regroupement, libellé (pas d'écriture, uniquement utilisé pour structurer
la compta, p.ex. compte n° 1, "Actif", type libellé (et il y avait un autre
compte n° 1999, "Total des actifs", type regroupement), et par classe (de
mémoire il y avait actif, passif, tiers, et d'autre dont je ne me souviens
plus).

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

Donc les comptes de regroupement dans l'exemple seraient "32" et "42" si je
suis bien ?

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

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

Pourrais-tu spécifier cette partie pour qu'on en discute plus en détails ?

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

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

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

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

Bien sûr... mais la liberté dont je parle ne concerne que les moyens de
tenir la compta, et ne change pas le résultat final, qui sera quand même
correct (ce qui n'est pas le cas si je comptabilise les écritures dans le
mauvais exercice).

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

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

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

On pourrait imaginer qu'une autre table rassemble toutes les pièces, mais
il faut quand même qu'il ait un lien dans l'écriture (sinon, il faut faire
à chaque fois une requête sur la table des pièces pour vérifier qu'il n'y a
rien à afficher).

Peux-tu reposter une mise à jour de tes spécifications, et on pourrait déjà
commencer à discuter comment les transposer en SQL ?

Frédéric