From schutz at mathgen.ch  Wed Oct  3 15:04:20 2001
From: schutz at mathgen.ch (Frederic Schutz)
Date: Wed, 03 Oct 2001 23:04:20 +1000
Subject: Specifications
Message-ID: <kk2mrt0j3720j988amerp3jqpv25veuvet@4ax.com>

Bonjour,

j'ai plac? sur la page du projet compta (www.linux-gull.ch/projets/compta)
une copie plus que provisoire des sp?cifications. Il s'agit de ce qu'Alex
avait ?crit, traduit en SGML/DocBook, avec quelques trucs suppl?mentaires
provenant de discussions dans la liste, en priv? ou d'id?es personnelles.
Seules les premi?res tables sont d?finies, le reste est ? faire.

Ce serait bien si on pouvait faire quelque chose ? partir de ?a, en
particulier d?finir quelques tables en SQL. Personnellement, je n'ai pas
peur de partir sur une mauvaise voie et de tout jeter apr?s quelques
essais, tant que ?a avance.

Donc je vous propose:

  1) de faire des suggestions sur ce premier brouillon de d?but de
sp?cifications
  2) de regarder particuli?rement la table des soci?t?s pour voir quels
champs manqueraient, et comment coder les champs propos?s.

Toute id?e bienvenue !

Fr?d?ric


From schaefer at alphanet.ch  Wed Oct 10 12:33:43 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Wed, 10 Oct 2001 12:33:43 +0200 (MEST)
Subject: Specifications
In-Reply-To: <kk2mrt0j3720j988amerp3jqpv25veuvet@4ax.com>
Message-ID: <Pine.LNX.3.96.1011010114618.1509A-100000@defian.alphanet.ch>

On Wed, 3 Oct 2001, Frederic Schutz wrote:

> Ce serait bien si on pouvait faire quelque chose ? partir de ?a, en
> particulier d?finir quelques tables en SQL. Personnellement, je n'ai pas
> peur de partir sur une mauvaise voie et de tout jeter apr?s quelques
> essais, tant que ?a avance.

Ben alors voil?:

-- Projet GULL Compta
-- initial.sql -- D?finitions des structures de donn?es de la BD
-- AUTHOR
--    Marc SCHAEFER <schaefer at alphanet.ch>
-- LICENSE
--    (C) 2001 by Marc SCHAEFER, licensed under the terms of the
--    GNU General Public License as published by the Free Software
--    Foundation; either version 2 or later (at your option).
-- DESCRIPTION
--    Ceci d?finit les structures de donn?es, en fonction des contraintes
--    d?crites sur: http://www.linux-gull.ch/projets/compta/.
-- NOTES
--    - Cette premi?re version suppose:
--         - une base de donn?es PostgreSQL 7.x
--         - une allocation assez large des donn?es (utilisation de TEXT
--           plut?t que VARCHAR p.ex.)
--         - une insistance sur l'ad?quation ? la sp?cification.
--         - pour l'instant une simplification: on ?vite la prolif?ration
--           de tables adresse, code_pays, localit?, etc. Ce qui pourra ?tre
--           fait dans une deuxi?me ?tape.
--         - il manque des contraintes/triggers pour emp?cher la modification
--           de donn?es sensibles.
--         - il faut d?cider si l'on autorise des valeurs par d?faut.
-- BUGS
--    - Mix of French and English
--    - INT4 in REFERENCES to SERIAL must be specified.
-- TODO
--    - Check with PG7 if ok.
-- BASED-ON
--    Original work
-- $Id$
-- 

-- BUGS
--    - This shouldn't be an active table, it's just inherited. Alternatively
--      this could be REFERRED to.
CREATE TABLE adresse (adresse_1 TEXT NOT NULL,
                      adresse_2 TEXT,
                      adresse_3 TEXT,
                      localite TEXT NOT NULL,
                      code_ville TEXT NOT NULL,
                      code_pays TEXT DEFAULT 'CH' NOT NULL);

CREATE TABLE societe (id SERIAL NOT NULL, -- interne ? la base de donn?es
                      libelle TEXT NOT NULL,  -- libell?
                      UNIQUE(id), PRIMARY KEY(id))
   INHERITS (adresse);

-- NOTES
--    - REFERENCES ensures societe exists.
-- TODO
--    - Add trigger to disable add/modify once clotured, probably
--      on another table.
--    - Add trigger so that the devise cannot be changed once set.
--    - Add trigger to check that (societe, [intervalle]) is not
--      within any other intervalle (debut, fin).
CREATE TABLE exercice (id SERIAL NOT NULL, -- interne ? la base de donn?es
                       societe INT4 REFERENCES societe NOT NULL,
                       debut DATE DEFAULT CURRENT_DATE NOT NULL,
                       fin DATE NOT NULL,
                       cloture BOOLEAN DEFAULT 'f' NOT NULL,
                       devise VARCHAR(3) DEFAULT 'CHF' NOT NULL,
                       UNIQUE(id), PRIMARY KEY(id));

-- BUGS
--    - libell? non unique dans la sp?cification.
CREATE TABLE provenance (id SERIAL NOT NULL, -- interne ? la base de donn?es
                         libelle TEXT NOT NULL, -- libell?
                         UNIQUE(libelle),
                         UNIQUE(id), PRIMARY KEY(id));

CREATE TABLE lot (id SERIAL NOT NULL, -- interne ? la base de donn?es
                  libelle TEXT NOT NULL, -- libell?
                  UNIQUE(id), PRIMARY KEY(id));
-- BUGS
--    - This shouldn't be an active table
--    - Should that reference exercice, or not ?
--    - Missing tables: compte, 
-- TODO
--    - Complete, inclusive comments for triggers. See specification.
--      This is the most complicated table.
CREATE TABLE ecriture (id SERIAL NOT NULL, -- interne ? la base de donn?es
                       libelle TEXT NOT NULL,
                       societe INT4 REFERENCES societe NOT NULL,
                       provenance INT4 REFERENCES provenance NOT NULL,

                       numero INT4 NOT NULL,
                       lot INT4 REFERENCES lot NOT NULL,

                       date_valeur DATE NOT NULL,

                       date_saisie DATE DEFAULT CURRENT_DATE NOT NULL,
                       date_modification DATE DEFAULT CURRENT_DATE NOT NULL,

                       compte INT4 REFERENCES compte NOT NULL,

                       montant_signe MONEY NOT NULL,
                       montant_devise VARCHAR(3) DEFAULT 'CHF' NOT NULL,
                       taux_change MONEY, -- BUGS: type
                       montant_devise_signe MONEY NOT NULL,

                       createur INT4 REFERENCES utilisateur NOT NULL, -- ??
                       modificateur INT4 REFERENCES utilisateur NOT NULL,

                       comptabilise BOOLEAN NOT NULL,

                       UNIQUE(id), PRIMARY KEY(id));

CREATE TABLE groupe(id SERIAL NOT NULL, -- interne ? la base de donn?es
                    nom TEXT NOT NULL,
                    UNIQUE(nom),
                    UNIQUE(id), PRIMARY KEY(id));

CREATE TABLE utilisateur(id SERIAL NOT NULL,
			 nom TEXT NOT NULL,                         
                         pw_hash CHAR(32), -- md5sum en texte par exemple.
			 UNIQUE(nom),
			 UNIQUE(id), PRIMARY KEY(id));

CREATE TABLE membre_de(utilisateur INT4 REFERENCES utilisateur NOT NULL,
                       groupe INT4 REFERENCES groupe NOT NULL,
                       UNIQUE(utilisateur, groupe));

CREATE TABLE autorisation(groupe INT4 REFERENCES groupe NOT NULL,
                          societe INT4 REFERENCES societe NOT NULL,
                          exercice INT4 REFERENCES exercice NOT NULL,
                          lecture BOOLEAN NOT NULL,
                          ecriture BOOLEAN NOT NULL,
                          modification BOOLEAN NOT NULL,
                          cloture BOOLEAN NOT NULL,
                          comptabilisation BOOLEAN NOT NULL,
                          UNIQUE(groupe, societe, exercice));

-- BUGS
--    - Not clear to me. Is that a session ?
CREATE TABLE parametre (id SERIAL NOT NULL, -- interne ? la base de donn?es
                        societe INT4 REFERENCES societe NOT NULL,
                        utilisateur INT4 REFERENCES utilisateur NOT NULL,
                        parametre TEXT, -- peut ?tre NULL
                        UNIQUE(id), PRIMARY KEY(id));






From Didier.Dubois at linkvest.com  Wed Oct 10 13:34:21 2001
From: Didier.Dubois at linkvest.com (Didier Dubois)
Date: Wed, 10 Oct 2001 13:34:21 +0200
Subject: Specifications
Message-ID: <B45465FD9C23D21193E90000F8D0F3DF015DCAB7@mailsrv.linkvest.com>

Hello,

Si je puis me permettre une suggestion:

peut-etre faudrait-il eviter d'utiliser des "features" speciaux tels que
les triggers, etc,.... a moins d'etre sur qu'on n'utilisera QUE
PostgresSQl (???).

Idem pour les autonum, etc,... qui ne sont pas compatibles d'une DB a
l'autre.

Pour plus d'infos je conseille le lien suivant (c'est une reference en
la matiere): http://www.ambysoft.com/persistenceLayer.html 
Cela vaut aussi le coup de surfer a partir de la...


Didier.

> -----Original Message-----
> From: Marc SCHAEFER [mailto:schaefer at alphanet.ch]
> Sent: 10 October 2001 12:34
> To: compta at linux-gull.ch
> Subject: Re: Specifications
> 
> 
> On Wed, 3 Oct 2001, Frederic Schutz wrote:
> 
> > Ce serait bien si on pouvait faire quelque chose ? partir de ?a, en
> > particulier d?finir quelques tables en SQL. 
> Personnellement, je n'ai pas
> > peur de partir sur une mauvaise voie et de tout jeter apr?s quelques
> > essais, tant que ?a avance.
> 
> Ben alors voil?:
> 
> -- Projet GULL Compta
> -- initial.sql -- D?finitions des structures de donn?es de la BD
> -- AUTHOR
> --    Marc SCHAEFER <schaefer at alphanet.ch>
> -- LICENSE
> --    (C) 2001 by Marc SCHAEFER, licensed under the terms of the
> --    GNU General Public License as published by the Free Software
> --    Foundation; either version 2 or later (at your option).
> -- DESCRIPTION
> --    Ceci d?finit les structures de donn?es, en fonction des 
> contraintes
> --    d?crites sur: http://www.linux-gull.ch/projets/compta/.
> -- NOTES
> --    - Cette premi?re version suppose:
> --         - une base de donn?es PostgreSQL 7.x
> --         - une allocation assez large des donn?es 
> (utilisation de TEXT
> --           plut?t que VARCHAR p.ex.)
> --         - une insistance sur l'ad?quation ? la sp?cification.
> --         - pour l'instant une simplification: on ?vite la 
> prolif?ration
> --           de tables adresse, code_pays, localit?, etc. Ce 
> qui pourra ?tre
> --           fait dans une deuxi?me ?tape.
> --         - il manque des contraintes/triggers pour emp?cher 
> la modification
> --           de donn?es sensibles.
> --         - il faut d?cider si l'on autorise des valeurs par d?faut.
> -- BUGS
> --    - Mix of French and English
> --    - INT4 in REFERENCES to SERIAL must be specified.
> -- TODO
> --    - Check with PG7 if ok.
> -- BASED-ON
> --    Original work
> -- $Id$
> -- 
> 
> -- BUGS
> --    - This shouldn't be an active table, it's just 
> inherited. Alternatively
> --      this could be REFERRED to.
> CREATE TABLE adresse (adresse_1 TEXT NOT NULL,
>                       adresse_2 TEXT,
>                       adresse_3 TEXT,
>                       localite TEXT NOT NULL,
>                       code_ville TEXT NOT NULL,
>                       code_pays TEXT DEFAULT 'CH' NOT NULL);
> 
> CREATE TABLE societe (id SERIAL NOT NULL, -- interne ? la 
> base de donn?es
>                       libelle TEXT NOT NULL,  -- libell?
>                       UNIQUE(id), PRIMARY KEY(id))
>    INHERITS (adresse);
> 
> -- NOTES
> --    - REFERENCES ensures societe exists.
> -- TODO
> --    - Add trigger to disable add/modify once clotured, probably
> --      on another table.
> --    - Add trigger so that the devise cannot be changed once set.
> --    - Add trigger to check that (societe, [intervalle]) is not
> --      within any other intervalle (debut, fin).
> CREATE TABLE exercice (id SERIAL NOT NULL, -- interne ? la 
> base de donn?es
>                        societe INT4 REFERENCES societe NOT NULL,
>                        debut DATE DEFAULT CURRENT_DATE NOT NULL,
>                        fin DATE NOT NULL,
>                        cloture BOOLEAN DEFAULT 'f' NOT NULL,
>                        devise VARCHAR(3) DEFAULT 'CHF' NOT NULL,
>                        UNIQUE(id), PRIMARY KEY(id));
> 
> -- BUGS
> --    - libell? non unique dans la sp?cification.
> CREATE TABLE provenance (id SERIAL NOT NULL, -- interne ? la 
> base de donn?es
>                          libelle TEXT NOT NULL, -- libell?
>                          UNIQUE(libelle),
>                          UNIQUE(id), PRIMARY KEY(id));
> 
> CREATE TABLE lot (id SERIAL NOT NULL, -- interne ? la base de donn?es
>                   libelle TEXT NOT NULL, -- libell?
>                   UNIQUE(id), PRIMARY KEY(id));
> -- BUGS
> --    - This shouldn't be an active table
> --    - Should that reference exercice, or not ?
> --    - Missing tables: compte, 
> -- TODO
> --    - Complete, inclusive comments for triggers. See specification.
> --      This is the most complicated table.
> CREATE TABLE ecriture (id SERIAL NOT NULL, -- interne ? la 
> base de donn?es
>                        libelle TEXT NOT NULL,
>                        societe INT4 REFERENCES societe NOT NULL,
>                        provenance INT4 REFERENCES provenance NOT NULL,
> 
>                        numero INT4 NOT NULL,
>                        lot INT4 REFERENCES lot NOT NULL,
> 
>                        date_valeur DATE NOT NULL,
> 
>                        date_saisie DATE DEFAULT CURRENT_DATE NOT NULL,
>                        date_modification DATE DEFAULT 
> CURRENT_DATE NOT NULL,
> 
>                        compte INT4 REFERENCES compte NOT NULL,
> 
>                        montant_signe MONEY NOT NULL,
>                        montant_devise VARCHAR(3) DEFAULT 
> 'CHF' NOT NULL,
>                        taux_change MONEY, -- BUGS: type
>                        montant_devise_signe MONEY NOT NULL,
> 
>                        createur INT4 REFERENCES utilisateur 
> NOT NULL, -- ??
>                        modificateur INT4 REFERENCES 
> utilisateur NOT NULL,
> 
>                        comptabilise BOOLEAN NOT NULL,
> 
>                        UNIQUE(id), PRIMARY KEY(id));
> 
> CREATE TABLE groupe(id SERIAL NOT NULL, -- interne ? la base 
> de donn?es
>                     nom TEXT NOT NULL,
>                     UNIQUE(nom),
>                     UNIQUE(id), PRIMARY KEY(id));
> 
> CREATE TABLE utilisateur(id SERIAL NOT NULL,
> 			 nom TEXT NOT NULL,                         
>                          pw_hash CHAR(32), -- md5sum en texte 
> par exemple.
> 			 UNIQUE(nom),
> 			 UNIQUE(id), PRIMARY KEY(id));
> 
> CREATE TABLE membre_de(utilisateur INT4 REFERENCES 
> utilisateur NOT NULL,
>                        groupe INT4 REFERENCES groupe NOT NULL,
>                        UNIQUE(utilisateur, groupe));
> 
> CREATE TABLE autorisation(groupe INT4 REFERENCES groupe NOT NULL,
>                           societe INT4 REFERENCES societe NOT NULL,
>                           exercice INT4 REFERENCES exercice NOT NULL,
>                           lecture BOOLEAN NOT NULL,
>                           ecriture BOOLEAN NOT NULL,
>                           modification BOOLEAN NOT NULL,
>                           cloture BOOLEAN NOT NULL,
>                           comptabilisation BOOLEAN NOT NULL,
>                           UNIQUE(groupe, societe, exercice));
> 
> -- BUGS
> --    - Not clear to me. Is that a session ?
> CREATE TABLE parametre (id SERIAL NOT NULL, -- interne ? la 
> base de donn?es
>                         societe INT4 REFERENCES societe NOT NULL,
>                         utilisateur INT4 REFERENCES 
> utilisateur NOT NULL,
>                         parametre TEXT, -- peut ?tre NULL
>                         UNIQUE(id), PRIMARY KEY(id));
> 
> 
> 
> 
> 


From schaefer at alphanet.ch  Wed Oct 10 14:01:01 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Wed, 10 Oct 2001 14:01:01 +0200 (MEST)
Subject: Specifications
In-Reply-To: <B45465FD9C23D21193E90000F8D0F3DF015DCAB7@mailsrv.linkvest.com>
Message-ID: <Pine.LNX.3.96.1011010135833.2042A-100000@defian.alphanet.ch>

On Wed, 10 Oct 2001, Didier Dubois wrote:

> peut-etre faudrait-il eviter d'utiliser des "features" speciaux tels que
> les triggers, etc,.... a moins d'etre sur qu'on n'utilisera QUE
> PostgresSQl (???).

A mon avis il faut prendre PostgreSQL. Sinon on va arriver ? une
structuration de donn?es qui sera suboptimale et on devra automatiquement
coder de la s?curit? dans les programmes autour de la base de donn?es,
perdant du m?me coup un des avantages d'un vrai SGBD.

C'est un choix de design ? faire au plus vite. Il me semble que s'il faut
simplement adapter le fichier SQL pour une autre BD, au pire, ce n'est pas
un travail ?norme (m?me avec des triggers, etc). D?placer le code d'erreur
et de s?curit? dans le programme autour risque, lui, d'?tre moins
portable.

[ citation int?grale supprim?e ]



From Didier.Dubois at linkvest.com  Wed Oct 10 14:39:58 2001
From: Didier.Dubois at linkvest.com (Didier Dubois)
Date: Wed, 10 Oct 2001 14:39:58 +0200
Subject: Specifications
Message-ID: <B45465FD9C23D21193E90000F8D0F3DF019ED5F4@mailsrv.linkvest.com>

Mais je pensais aussi a d'autres DB telles que MySQL et meme Oracle...

Il n'est pas toujours evident de faire le portage avec ce genre
fonctionnalites.
En tous cas dans mon experience DB, on a toujours evite les triggers et
les autonums. (il y a des patterns pour remplacer.)

Un des problemes "RealLife" des Triggers, c'est le syndorme de la pieces
remplie de pieges a souris: des que tu touches une table il y a plein de
reactions en chaines qui se declenchent. Il devient tres difficile de
tout tracer et donc de debugger, surtout apres qq mois de
developpement...
(je connais une applic qui souffre de cela) 

Je ne suis pas personnelement contre. Simplement, comme tu le dit, il
faudrait peut etre etre clair sur ce point des le debut.

Idem pour les limitations et les conventions de nommage par exemple.
(desole si j'overlap un ancien thread mais je n'ai pas suivi la
discussion des le debut.)

My 5cts tip...


Tant que j'y suis j'ai une question: est-ce qu'on a evalue les applics
existantes en fonctions des prerequis? Y'a-t-il un doc la dessus?

Merci,
D.


> -----Original Message-----
> From: Marc SCHAEFER [mailto:schaefer at alphanet.ch]
> Sent: 10 October 2001 14:01
> To: compta at linux-gull.ch
> Subject: RE: Specifications
> 
> 
> On Wed, 10 Oct 2001, Didier Dubois wrote:
> 
> > peut-etre faudrait-il eviter d'utiliser des "features" 
> speciaux tels que
> > les triggers, etc,.... a moins d'etre sur qu'on n'utilisera QUE
> > PostgresSQl (???).
> 
> A mon avis il faut prendre PostgreSQL. Sinon on va arriver ? une
> structuration de donn?es qui sera suboptimale et on devra 
> automatiquement
> coder de la s?curit? dans les programmes autour de la base de donn?es,
> perdant du m?me coup un des avantages d'un vrai SGBD.
> 
> C'est un choix de design ? faire au plus vite. Il me semble 
> que s'il faut
> simplement adapter le fichier SQL pour une autre BD, au pire, 
> ce n'est pas
> un travail ?norme (m?me avec des triggers, etc). D?placer le 
> code d'erreur
> et de s?curit? dans le programme autour risque, lui, d'?tre moins
> portable.
> 
> [ citation int?grale supprim?e ]
> 
> 


From schutz at mathgen.ch  Wed Oct 10 15:24:22 2001
From: schutz at mathgen.ch (Frederic Schutz)
Date: Wed, 10 Oct 2001 23:24:22 +1000
Subject: Specifications
In-Reply-To: <B45465FD9C23D21193E90000F8D0F3DF019ED5F4@mailsrv.linkvest.com>
References: <B45465FD9C23D21193E90000F8D0F3DF019ED5F4@mailsrv.linkvest.com>
Message-ID: <qii8sto2rqnii4anii3bti6qlaia744620@4ax.com>

Le Wed, 10 Oct 2001 14:39:58 +0200, tu as ecrit :

>Tant que j'y suis j'ai une question: est-ce qu'on a evalue les applics
>existantes en fonctions des prerequis? Y'a-t-il un doc la dessus?

Il y a quelques noms d'applications qui ont circul? dans la liste (cf les
archives) accompagn?es de quelques commentaires, mais on cherche toujours
des volontaires pour faire un document qui r?sume le tout (m?me si ce n'est
qu'une liste avec quelques liens et un minimum de commentaires pour
l'instant).

Pour les Specs, merci Marc et Didier d'avoir relanc? un peu le d?bat -- je
ne pensais pas que Marc irait si loin du premier coup, et il est largement
arriv? dans le zone "plus que brouillon" de mon document, et ?a explique un
grand nombre des "bugs" qu'il a signal?s. 

Je vais imprimer ?a et lire en d?tail demain (il est d?j? tard par ici...),
Alex pourra aussi jeter un coup d'oeil sur les specs et les tables
propos?es. En particulier, je n'?tais pas tr?s au clair non plus sur cette
table "param?tres".

Fr?d?ric


From schaefer at alphanet.ch  Wed Oct 10 15:19:28 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Wed, 10 Oct 2001 15:19:28 +0200 (MEST)
Subject: Specifications
In-Reply-To: <B45465FD9C23D21193E90000F8D0F3DF019ED5F4@mailsrv.linkvest.com>
Message-ID: <Pine.LNX.3.96.1011010151859.2462A-100000@defian.alphanet.ch>

On Wed, 10 Oct 2001, Didier Dubois wrote:

> Tant que j'y suis j'ai une question: est-ce qu'on a evalue les applics
> existantes en fonctions des prerequis? Y'a-t-il un doc la dessus?

J'ai vaguement souvenir que cela a ?t? trait? lors du cours du GULL.
(disponible http://www.linux-gull.ch/compta/)




From schaefer at alphanet.ch  Wed Oct 10 16:00:21 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Wed, 10 Oct 2001 16:00:21 +0200 (MEST)
Subject: Specifications
In-Reply-To: <qii8sto2rqnii4anii3bti6qlaia744620@4ax.com>
Message-ID: <Pine.LNX.3.96.1011010155856.2588B-100000@defian.alphanet.ch>

On Wed, 10 Oct 2001, Frederic Schutz wrote:

> Il y a quelques noms d'applications qui ont circul? dans la liste (cf les
> archives) accompagn?es de quelques commentaires, mais on cherche toujours
> des volontaires pour faire un document qui r?sume le tout (m?me si ce n'est
> qu'une liste avec quelques liens et un minimum de commentaires pour
> l'instant).

Ca serait pas mal oui!  En particulier en venant d'une personne qui
pourrait ? la fois ?valuer:

   - la pertinence face aux sp?cifications

   - la qualit? `g?nie logiciel' du logiciel

   - la qualit? `comptable' du logiciel

donc il faut quelqu'un d'assez g?n?raliste ...

> Je vais imprimer ?a et lire en d?tail demain (il est d?j? tard par ici...),

oh, on a le temps.  Et comme tu l'as dit, il faut se pr?parer ? jeter
quelques g?n?rations :->




From rossen at freesurf.ch  Wed Oct 10 18:36:44 2001
From: rossen at freesurf.ch (rossen at freesurf.ch)
Date: Wed, 10 Oct 2001 18:36:44 +0200
Subject: Specifications
In-Reply-To: <B45465FD9C23D21193E90000F8D0F3DF015DCAB7@mailsrv.linkvest.com>
References: <B45465FD9C23D21193E90000F8D0F3DF015DCAB7@mailsrv.linkvest.com>
Message-ID: <20011010183644.A17261@freesurf.ch>

On Wed, Oct 10, 2001 at 01:34:21PM +0200, Didier Dubois wrote:
> Si je puis me permettre une suggestion:
> 
> peut-etre faudrait-il eviter d'utiliser des "features" speciaux tels que
> les triggers, etc,.... a moins d'etre sur qu'on n'utilisera QUE
> PostgresSQl (???).

Nous avons d?j? eu cette d?bat le soir du CVS workshop et nous sommes arriv?s ?
la conclusion que la portabilit? n'a pas autant d'importance si le syst?me est
con?u pour tourner sur un SGBD libre.  C'est surtout les gens qui utilisent les
SGBDs propietaires qui devraient faire des soucies des changements sur lesquel
ils n'ont pas de contr?le.

Au fait, PostgreSQL est si avanc? qu'on peut imaginer de tourner TOUT le moteur
compta dedans sans aucune ajoute de logiciel exterieur.

-- 
Erik Rossen                         ^    GPG key ID: 2935D0B9
rossen at freesurf.ch                 /e\   "Use GnuPG, see the
http://www.multimania.com/rossen   ---    black helicopters."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://forum.linux-gull.ch/pipermail/compta/attachments/20011010/1a1e0521/attachment.pgp>

From Didier.Dubois at linkvest.com  Thu Oct 11 08:47:33 2001
From: Didier.Dubois at linkvest.com (Didier Dubois)
Date: Thu, 11 Oct 2001 08:47:33 +0200
Subject: Specifications
Message-ID: <B45465FD9C23D21193E90000F8D0F3DF015DCABA@mailsrv.linkvest.com>

Hello,

Tres bien. Je n'aie pas suivi la discussion du Workshop malheureusement.


Je ne savais pas que la portabilite n'avait pas d'importance dans le
cadre de ce projet.
Dans ce sens, PostgresSQL me semble etre un bon choix. 

Faire tout de meme attention aux changement eventuels de l'API et des
fonctionnalites. (ca peut toujours arriver :-)

Merci,
Didier


> -----Original Message-----
> From: rossen at freesurf.ch [mailto:rossen at freesurf.ch]
> Sent: 10 October 2001 18:37
> To: compta at linux-gull.ch
> Subject: Re: Specifications
> 
> 
> On Wed, Oct 10, 2001 at 01:34:21PM +0200, Didier Dubois wrote:
> > Si je puis me permettre une suggestion:
> > 
> > peut-etre faudrait-il eviter d'utiliser des "features" 
> speciaux tels que
> > les triggers, etc,.... a moins d'etre sur qu'on n'utilisera QUE
> > PostgresSQl (???).
> 
> Nous avons d?j? eu cette d?bat le soir du CVS workshop et 
> nous sommes arriv?s ?
> la conclusion que la portabilit? n'a pas autant d'importance 
> si le syst?me est
> con?u pour tourner sur un SGBD libre.  C'est surtout les gens 
> qui utilisent les
> SGBDs propietaires qui devraient faire des soucies des 
> changements sur lesquel
> ils n'ont pas de contr?le.
> 
> Au fait, PostgreSQL est si avanc? qu'on peut imaginer de 
> tourner TOUT le moteur
> compta dedans sans aucune ajoute de logiciel exterieur.
> 
> -- 
> Erik Rossen                         ^    GPG key ID: 2935D0B9
> rossen at freesurf.ch                 /e\   "Use GnuPG, see the
> http://www.multimania.com/rossen   ---    black helicopters."
> 


From schaefer at alphanet.ch  Thu Oct 11 20:12:26 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Thu, 11 Oct 2001 20:12:26 +0200 (MEST)
Subject: Specifications
In-Reply-To: <B45465FD9C23D21193E90000F8D0F3DF015DCABA@mailsrv.linkvest.com>
Message-ID: <Pine.LNX.3.96.1011011201049.671E-100000@defian.alphanet.ch>

On Thu, 11 Oct 2001, Didier Dubois wrote:

> Faire tout de meme attention aux changement eventuels de l'API et des
> fonctionnalites. (ca peut toujours arriver :-)

C'est juste: mais jusqu'? maintenant PostgreSQL a progress? dans le sens
de la conformance aux sp?cifications.

Il est vrai qu'il est possible que cela change: Great Bridge Inc. n'existe
plus, PostgreSQL Inc. existe toujours mais n'a pas ? ma connaissance
contribu? aux r?cents d?veloppements, et Red Hat est entrain d'essayer de
capturer ce segment avec son `Red Hat Database' (aka PostgreSQL + bugs? :->) 




From schutz at mathgen.ch  Mon Oct 15 14:32:44 2001
From: schutz at mathgen.ch (Frederic Schutz)
Date: Mon, 15 Oct 2001 22:32:44 +1000
Subject: Specifications
In-Reply-To: <Pine.LNX.3.96.1011010114618.1509A-100000@defian.alphanet.ch>
References: <kk2mrt0j3720j988amerp3jqpv25veuvet@4ax.com> <Pine.LNX.3.96.1011010114618.1509A-100000@defian.alphanet.ch>
Message-ID: <8pjlst88ar1v2mkpluj9q44amm7crhihga@4ax.com>

Le Wed, 10 Oct 2001 12:33:43 +0200, tu as ecrit :

>--         - il faut d?cider si l'on autorise des valeurs par d?faut.

A voir comme ?a, aucune pr?f?rence (sauf cas particuliers, voir plus bas).

>CREATE TABLE exercice (id SERIAL NOT NULL, -- interne ? la base de donn?es
>                       societe INT4 REFERENCES societe NOT NULL,
>                       debut DATE DEFAULT CURRENT_DATE NOT NULL,
>                       fin DATE NOT NULL,
>                       cloture BOOLEAN DEFAULT 'f' NOT NULL,
>                       devise VARCHAR(3) DEFAULT 'CHF' NOT NULL,
>                       UNIQUE(id), PRIMARY KEY(id));

(Question plut?t pour les comptables) Serait-il utile d'avoir un label
d'exercice "human readable" ? Par exemple, pour pouvoir se r?f?rer ? la
comptabilit? "GULL, 2001" au lieu de devoir donner les dates de d?but et de
fin ? J'avais l'habitude d'utiliser l'ann?e o? finit l'exercice comme label
(p.ex 1.7.2000-30.6.2001 --> exercice "2001"), mais ?a ne marche pas si une
soci?t? a un exercice plus court qu'une ann?e.

>-- BUGS
>--    - libell? non unique dans la sp?cification.
>CREATE TABLE provenance (id SERIAL NOT NULL, -- interne ? la base de donn?es

Je n'avais pas encore "mis au net" cette table dans les sp?cifications. Je
propose de la laisser tel quel pour l'instant (juste qu'on se souvienne
qu'elle est l?), car la "provenance" se r?f?re ? "quel module (compta
g?n?rale, facturation, etc) du programme a cr?? cette ?criture", et on n'en
est pas encore l?...

>CREATE TABLE lot (id SERIAL NOT NULL, -- interne ? la base de donn?es
>                  libelle TEXT NOT NULL, -- libell?
>                  UNIQUE(id), PRIMARY KEY(id));

Inutile ? mon avis. Le "lot" repr?sente un paquet d'?critures li?es, avec
la propri?t? que la somme des montants du lot est nulle. Comme "libell?",
on peut utiliser le num?ro de la premi?re ?criture du lot.

[table "ecriture"]
>--    - Should that reference exercice, or not ?

D?finitivement ! Il faut pouvoir attribuer chaque ?criture a une
comptabilit? distincte, c'est-?-dire ? une soci?t? et ? un exercice. Mais
en fait, comme chaque exercice (quelque soit la soci?t? concern?e) est
d?fini de fa?on unique par l'id dans la table correspondante, il suffit de
se r?f?rer ? celle-ci et d'annuler la r?f?rence ? la soci?t?. Ca ne devrait
pas poser de probl?me.

>--    - Missing tables: compte, 

Yep. Et c'est une table plus qu'importante. Je n'?tais pas encore au clair
avec ce qu'Alex avait mis dans les sp?cifications, je n'ai donc pas mis ?a
au net pour l'instant.

>                       numero INT4 NOT NULL,

Il faut une num?rotation s?quentielle diff?rente pour chaque exercice,
peut-on le faire automatiquement facilement ?

>                       lot INT4 REFERENCES lot NOT NULL,

Cf plus haut, le lot r?f?rence juste un numero ant?rieur, pas besoin de
table "lot".

>                       montant_signe MONEY NOT NULL,
>                       montant_devise VARCHAR(3) DEFAULT 'CHF' NOT NULL,

montant_devise --> devise

Je pense que la devise doit pouvoir ?tre nulle; dans ce cas, c'est la
devise d?finie dans la table "exercice" qui doit ?tre utilis?e (et ?a
implique qu'il ne doit pas y avoir un DEFAULT 'CHF', au contraire, puisque
le d?faut est d?fini ailleurs).

>                       taux_change MONEY, -- BUGS: type
>                       montant_devise_signe MONEY NOT NULL,

Les deux sont redondants, mais je peux imaginer qu'on veuille garder les
deux (pour ?viter des diff?rences d'arrondi, etc), est-ce vraiment
n?cessaire ?

>                       date_modification DATE DEFAULT CURRENT_DATE NOT NULL,
[...]
>                       modificateur INT4 REFERENCES utilisateur NOT NULL,

Comment faire si plusieurs modifications ont lieu ?

>CREATE TABLE groupe(id SERIAL NOT NULL, -- interne ? la base de donn?es
>CREATE TABLE utilisateur(id SERIAL NOT NULL,
>CREATE TABLE membre_de(utilisateur INT4 REFERENCES utilisateur NOT NULL,
>CREATE TABLE autorisation(groupe INT4 REFERENCES groupe NOT NULL,

Je n'ai pas encore r?fl?chi aux autorisations...

>--    - Not clear to me. Is that a session ?
>CREATE TABLE parametre (id SERIAL NOT NULL, -- interne ? la base de donn?es

J'ai besoin de pr?cisions d'Alex ici aussi. J'avais cru comprendre qu'il
s'agissait de stocker des param?tres pour chaque exercice (genre, quel
arrondi utiliser, etc), dis-moi si je me trompe ! Sinon, peut-?tre qu'on
peut ajouter ces param?tres ? la table exercice au fur et ? mesure qu'on en
a besoin ?

Ouf, pour des premiers commentaires, ?a fait beaucoup ? la fois. J'attends
avec impatience les commentaires sur les commentaires :-)

Fr?d?ric


From schaefer at alphanet.ch  Tue Oct 16 21:38:13 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Tue, 16 Oct 2001 21:38:13 +0200 (MEST)
Subject: Specifications
In-Reply-To: <8pjlst88ar1v2mkpluj9q44amm7crhihga@4ax.com>
Message-ID: <Pine.LNX.3.96.1011016205612.4302A-100000@defian.alphanet.ch>

On Mon, 15 Oct 2001, Frederic Schutz wrote:

> (Question plut?t pour les comptables) Serait-il utile d'avoir un label
> d'exercice "human readable" ? Par exemple, pour pouvoir se r?f?rer ? la

J'ajoute un libell? UNIQUE, obligatoire.

> >CREATE TABLE lot (id SERIAL NOT NULL, -- interne ? la base de donn?es
> >                  libelle TEXT NOT NULL, -- libell?
> >                  UNIQUE(id), PRIMARY KEY(id));
> 
> Inutile ? mon avis. Le "lot" repr?sente un paquet d'?critures li?es, avec
> la propri?t? que la somme des montants du lot est nulle. Comme "libell?",
> on peut utiliser le num?ro de la premi?re ?criture du lot.

J'aimais bien l'id?e d'avoir un lot comme concept externe. Par contre, il
est clair qu'il faut ajouter alors un ORDER BY numero ? ?criture si l'on
veut l'ordre.

Il faudra encore y r?fl?chir.

> [table "ecriture"]
> >--    - Should that reference exercice, or not ?
> 
> D?finitivement ! Il faut pouvoir attribuer chaque ?criture a une
> comptabilit? distincte, c'est-?-dire ? une soci?t? et ? un exercice. Mais

Ajout? lien exercice, supprim? lien transitivement existant ? soci?t?.

> >--    - Missing tables: compte, 
> 
> Yep. Et c'est une table plus qu'importante. Je n'?tais pas encore au clair
> avec ce qu'Alex avait mis dans les sp?cifications, je n'ai donc pas mis ?a
> au net pour l'instant.

Cr?? une classe/table temporaire.

> >                       numero INT4 NOT NULL,
> 
> Il faut une num?rotation s?quentielle diff?rente pour chaque exercice,
> peut-on le faire automatiquement facilement ?

Peux-tu me donner quelques exemples de num?rotation valables pour
plusieurs exercices (il n'y a pas de num?rotation externe ? exercice pour
le moment) ?  Doit-elle ?tre dans tous les cas compos?e de nombres qui se
suivent ?  De lettres et de nombres ?

> >                       lot INT4 REFERENCES lot NOT NULL,
> 
> Cf plus haut, le lot r?f?rence juste un numero ant?rieur, pas besoin de
> table "lot".

@@@

> montant_devise --> devise

ok

> Je pense que la devise doit pouvoir ?tre nulle; dans ce cas, c'est la
> devise d?finie dans la table "exercice" qui doit ?tre utilis?e (et ?a
> implique qu'il ne doit pas y avoir un DEFAULT 'CHF', au contraire, puisque
> le d?faut est d?fini ailleurs).

commentaire ajout? (rule, trigger, ou programme).

> >                       taux_change MONEY, -- BUGS: type
> >                       montant_devise_signe MONEY NOT NULL,
> 
> Les deux sont redondants, mais je peux imaginer qu'on veuille garder les
> deux (pour ?viter des diff?rences d'arrondi, etc), est-ce vraiment

faut-il automatiquement avoir un rounding au 20?me par exemple (MONEY ne
fait-il pas d?j? ?a) ?

> n?cessaire ?

Effectivement:

   Le 22 ? 13:30 j'ai vers? 30 US$ sur le compte 42, ce qui donne
   42 CHF.

Soit on m?morise devise, montant_signe et montant_devise_signe, soit
on m?morise devise, montage_signe et taux_change. Le reste est redondant.
A moins qu'il y ait des r?gles pr?cises qui m'?chappent.

> >                       date_modification DATE DEFAULT CURRENT_DATE NOT NULL,
> [...]
> >                       modificateur INT4 REFERENCES utilisateur NOT NULL,
> 
> Comment faire si plusieurs modifications ont lieu ?

Il faut alors cr?er une table ecriture_modification, c'est ce que j'ai
fait, qui r?f?rence ecriture (cardinalit? n-1).

> Ouf, pour des premiers commentaires, ?a fait beaucoup ? la fois.

merci!

Voil? la nouvelle version, test?e rapidement sur PostgreSQL 7.

-- Projet GULL Compta
-- initial.sql -- D?finitions des structures de donn?es de la BD
-- AUTHOR
--    Marc SCHAEFER <schaefer at alphanet.ch>
-- LICENSE
--    (C) 2001 by Marc SCHAEFER, licensed under the terms of the
--    GNU General Public License as published by the Free Software
--    Foundation; either version 2 or later (at your option).
-- DESCRIPTION
--    Ceci d?finit les structures de donn?es, en fonction des contraintes
--    d?crites sur: http://www.linux-gull.ch/projets/compta/.
-- NOTES
--    - Cette premi?re version suppose:
--         - une base de donn?es PostgreSQL 7.x
--         - une allocation assez large des donn?es (utilisation de TEXT
--           plut?t que VARCHAR p.ex.)
--         - une insistance sur l'ad?quation ? la sp?cification.
--         - pour l'instant une simplification: on ?vite la prolif?ration
--           de tables adresse, code_pays, localit?, etc. Ce qui pourra ?tre
--           fait dans une deuxi?me ?tape.
--         - il manque des contraintes/triggers pour emp?cher la modification
--           de donn?es sensibles.
--         - il faut d?cider si l'on autorise des valeurs par d?faut.
-- BUGS
--    - Mix of French and English
--    - INT4 in REFERENCES to SERIAL must be specified.
-- TODO
-- BASED-ON
--    Original work
-- $Id: initial.sql,v 1.3 2001/10/16 19:37:50 schaefer Exp $
-- 

-- BUGS
--    - This shouldn't be an active table, it's just inherited. Alternatively
--      this could be REFERRED to.
CREATE TABLE adresse (adresse_1 TEXT NOT NULL,
                      adresse_2 TEXT,
                      adresse_3 TEXT,
                      localite TEXT NOT NULL,
                      code_ville TEXT NOT NULL,
                      code_pays TEXT DEFAULT 'CH' NOT NULL);

-- BUGS
--    - libell? not unique in the specification.
CREATE TABLE societe (id SERIAL NOT NULL, -- interne ? la base de donn?es
                      libelle TEXT NOT NULL,  -- libell?
                      UNIQUE(libelle),
                      UNIQUE(id), PRIMARY KEY(id))
   INHERITS (adresse);

-- NOTES
--    - REFERENCES ensures societe exists.
-- BUGS
--    - libell? not unique in the specification.
-- TODO
--    - Add trigger to disable add/modify once clotured, probably
--      on another table.
--    - Add trigger so that the devise cannot be changed once set.
--    - Add trigger to check that (societe, [intervalle]) is not
--      within any other intervalle (debut, fin).
CREATE TABLE exercice (id SERIAL NOT NULL, -- interne ? la base de donn?es
                       societe INT4 REFERENCES societe NOT NULL,
                       debut DATE DEFAULT CURRENT_DATE NOT NULL,
                       fin DATE NOT NULL,
                       cloture BOOLEAN DEFAULT 'f' NOT NULL,
                       devise VARCHAR(3) DEFAULT 'CHF' NOT NULL,
		       libelle TEXT NOT NULL,  -- libell?
		       UNIQUE(libelle),
                       UNIQUE(id), PRIMARY KEY(id));

-- BUGS
--    - libell? not unique in the specification.
CREATE TABLE provenance (id SERIAL NOT NULL, -- interne ? la base de donn?es
                         libelle TEXT NOT NULL, -- libell?
                         UNIQUE(libelle),
                         UNIQUE(id), PRIMARY KEY(id));

-- BUGS
--    - libell? not unique in the specification.
--    - Not in the specification AFAIK.
--    - Some way to order ecriture in a lot (ORDER BY numero), or
--      forget this altogether and use some numbering scheme ?
CREATE TABLE lot (id SERIAL NOT NULL, -- interne ? la base de donn?es
                  libelle TEXT NOT NULL, -- libell?
                  UNIQUE(libelle),
                  UNIQUE(id), PRIMARY KEY(id));

-- BUGS
--    - Not in the specification.
CREATE TABLE compte(id SERIAL NOT NULL, -- interne ? la base de donn?es
		    libelle TEXT NOT NULL, -- libell?
		    UNIQUE(libelle),
                    UNIQUE(id), PRIMARY KEY(id));

CREATE TABLE utilisateur(id SERIAL NOT NULL,
			 nom TEXT NOT NULL,                         
                         pw_hash CHAR(32), -- md5sum en texte par exemple.
			 UNIQUE(nom),
			 UNIQUE(id), PRIMARY KEY(id));

-- BUGS
--    - This shouldn't be an active table
-- TODO
--    - Complete, inclusive comments for triggers. See specification.
--      This is the most complicated table.
--    - Add trigger/rules which if device is NULL, takes the one of
--      the exercice ... or code other programs accordingly.
--    - Check if MONEY has a 1/20th rounding.
--    - See if devise, montant_signe et montant_devise_signe and
--      taux_change are not redundant.  
CREATE TABLE ecriture (id SERIAL NOT NULL, -- interne ? la base de donn?es
                       libelle TEXT NOT NULL,

                       exercice INT4 REFERENCES exercice NOT NULL,
                       provenance INT4 REFERENCES provenance NOT NULL,

                       numero INT4 NOT NULL, -- One sequence per exercice?
                       lot INT4 REFERENCES lot NOT NULL,

                       date_valeur DATE NOT NULL,

                       date_saisie DATE DEFAULT CURRENT_DATE NOT NULL,

                       compte INT4 REFERENCES compte NOT NULL,

                       montant_signe MONEY NOT NULL,
                       devise VARCHAR(3),
                       taux_change MONEY, -- BUGS: type
                       montant_devise_signe MONEY NOT NULL,

                       createur INT4 REFERENCES utilisateur NOT NULL, -- ??

                       comptabilise BOOLEAN NOT NULL,

                       UNIQUE(id), PRIMARY KEY(id));

-- NOTES
-- BUGS
--    - Not in the specification.
--    - This allows multiple modifications on the same day, and multiple
--      modifications by the same utilisateur on the same day to the
--      same ecriture.
-- TODO
--    - Inherits from a (date, utilisateur) table that could be used
--      within ecriture.
CREATE TABLE ecriture_modification(ecriture INT4 REFERENCES ecriture NOT NULL,
                                   date_modification DATE
                                      DEFAULT CURRENT_DATE NOT NULL,
                                   modificateur INT4 REFERENCES utilisateur
                                      NOT NULL);

CREATE TABLE groupe(id SERIAL NOT NULL, -- interne ? la base de donn?es
                    nom TEXT NOT NULL,
                    UNIQUE(nom),
                    UNIQUE(id), PRIMARY KEY(id));

CREATE TABLE membre_de(utilisateur INT4 REFERENCES utilisateur NOT NULL,
                       groupe INT4 REFERENCES groupe NOT NULL,
                       UNIQUE(utilisateur, groupe));

CREATE TABLE autorisation(groupe INT4 REFERENCES groupe NOT NULL,
                          societe INT4 REFERENCES societe NOT NULL,
                          exercice INT4 REFERENCES exercice NOT NULL,
                          lecture BOOLEAN NOT NULL,
                          ecriture BOOLEAN NOT NULL,
                          modification BOOLEAN NOT NULL,
                          cloture BOOLEAN NOT NULL,
                          comptabilisation BOOLEAN NOT NULL,
                          UNIQUE(groupe, societe, exercice));

-- BUGS
--    - Not clear to me. Is that a session ?
CREATE TABLE parametre (id SERIAL NOT NULL, -- interne ? la base de donn?es
                        societe INT4 REFERENCES societe NOT NULL,
                        utilisateur INT4 REFERENCES utilisateur NOT NULL,
                        parametre TEXT, -- peut ?tre NULL
                        UNIQUE(id), PRIMARY KEY(id));






From schutz at mathgen.ch  Wed Oct 17 08:02:47 2001
From: schutz at mathgen.ch (Frederic Schutz)
Date: Wed, 17 Oct 2001 16:02:47 +1000
Subject: Info tiree de la liste de l'Aful
Message-ID: <ck7qst4np2mdjcvgohv51i92e7frcttnpp@4ax.com>

Lu dans la liste de l'AFUL, il ne me semble pas qu'on avait d?j? parl? de
cette compta... On recherche toujours quelqu'un qui pourrait faire une
liste de toutes ces applications de compta libre, pour pouvoir ensuite les
comparer...

Fr?d?ric
---
From: Philippe Allart <pallart at nordnet.fr>
To: membres at aful.org
Subject: Re: [Membres] Compta GPL
Date: Sat, 13 Oct 2001 08:50:39 +0200

Le Vendredi 12 Octobre 2001 16:57, vous avez ?crit :
> On en parlait ? l'AG :
>
> http://nomicmac.free.fr/
>
> quelqu'un connais ?

Non, mais ?a a l"air bien avanc?.

Pour r?ponder ? des besoins professionnels; il faut que le kogiciel
r?pondre ? certaines contraintes architecturales:

- les donn?es doivent ?tre stock?es dans une bases relationnelle de fa?on a
pouvoir g?n?rer des ?tats ? partir de requ?teurs ind?pendants (sinon on
fait une usine ? gaz)  et de fa?on ? partager l'information avec des
applications m?tiers (gestion de stocks, gestion de patrimoine, gestion de
moyens, ressources humaines; etc...)

- la mode est ? la gestion centralis?e des tiers. 

- il faut d?s maintenant penser ? l'interop?rabilit?. Comment circulent les
factures, les mandats, les bons de commandes, les tickets de caisse, etc...
Il faut pr?voir des points d'entr?e et de sortie pour g?rer ces ?v?nemants.
La compta n'est pas le coeur de l'entreprise, c'est un module charg? 
d'historiser toutes les transactions  financi?res, et d'en ?tablir certains
bilans selon certains formes r?glementtaires.



From rossen at freesurf.ch  Wed Oct 17 09:57:00 2001
From: rossen at freesurf.ch (Erik Rossen)
Date: Wed, 17 Oct 2001 09:57:00 +0200
Subject: Info tiree de la liste de l'Aful
In-Reply-To: <ck7qst4np2mdjcvgohv51i92e7frcttnpp@4ax.com>
References: <ck7qst4np2mdjcvgohv51i92e7frcttnpp@4ax.com>
Message-ID: <20011017095700.A7873@freesurf.ch>

On Wed, Oct 17, 2001 at 04:02:47PM +1000, Frederic Schutz wrote:
> Lu dans la liste de l'AFUL, il ne me semble pas qu'on avait d?j? parl? de
> cette compta... On recherche toujours quelqu'un qui pourrait faire une
> liste de toutes ces applications de compta libre, pour pouvoir ensuite les
> comparer...
> > On en parlait ? l'AG :
> >
> > http://nomicmac.free.fr/
> >
> > quelqu'un connais ?

Si, Gilbert et Alex (?) ont parl? de ce soft.  Il est bien pour la compta d'un
petite entreprise fran?aise, mais je crois que son interface est bien m?lang?
avec la reste, donc difficile de faire abstraction. 

--
Erik Rossen                         ^    GPG key ID: 2935D0B9
rossen at freesurf.ch                 /e\   "Use GnuPG, see the
http://www.multimania.com/rossen   ---    black helicopters."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://forum.linux-gull.ch/pipermail/compta/attachments/20011017/f763d379/attachment.pgp>

From schaefer at alphanet.ch  Wed Oct 17 11:32:23 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Wed, 17 Oct 2001 11:32:23 +0200 (MEST)
Subject: Specifications
In-Reply-To: <Pine.LNX.3.96.1011016205612.4302A-100000@defian.alphanet.ch>
Message-ID: <Pine.LNX.3.96.1011017113128.1535A-100000@defian.alphanet.ch>

Est-il possible de cr?er un CVS compta qui contiendrait la sp?cification,
le fichier SQL et ?v. des programmes par la suite ?

(PS: j'ai impl?ment? hier soir quelques triggers pour jouer).




From Didier.Dubois at linkvest.com  Wed Oct 17 17:41:16 2001
From: Didier.Dubois at linkvest.com (Didier Dubois)
Date: Wed, 17 Oct 2001 17:41:16 +0200
Subject: FreshMeat
Message-ID: <B45465FD9C23D21193E90000F8D0F3DF015DCAC2@mailsrv.linkvest.com>

Hello,

De nouveau je ne sais pas si je suis redondant (mes excuses dans ce cas)

Je suis alle sur Freshmeat et j'ai trouve ceci:
http://freshmeat.net/browse/76/?filter=&orderby=vitality_percent+DESC

Il est interessant de voir les resultats selon les filtres Vitality,
Popularity ou Rating.

Un des soft qui revient le plus est SQL-Ledger
http://www.sql-ledger.org/

Il contient entre autre:
- Ecritures comptables
- rapports 
- gestion des utilisateurs
- multi societe (avec meme templates !=)

Ces points sont dans l'intro du doc. de spec. :-)


  +
 +++
  +

- existe depuis 1998!!
- support Multi-langue!!!! (tres bien pour la Suisse!)
- Email invoice
- demo online
- PostgressSQL
- Multi vendeurs,...
....

De plus 2 Suisses sont deja inscrits comme utilisateurs. Ca peut
toujours servir...


Pour le reste je n'entend pas grand chose a la compta pure. Il faudrait
donc 1 pro pour tester. C'est meme possible en ligne, sans prendre bpc
de risques donc! 


Maintenant, j'imagine que certaines choses vont nous manquer ou ne
seront pas adequates. 

Mais peut-etre est il plus facile de commencer avec quelque chose qui
existe et de proposer des patches au team. Voir meme de proposer un
systeme de plugins avec un plugin "Switzerland"???

Je ne sais pas ce que vous en pensez? 

@+
Didier






From schutz at mathgen.ch  Sat Oct 20 07:48:57 2001
From: schutz at mathgen.ch (Frederic Schutz)
Date: Sat, 20 Oct 2001 15:48:57 +1000
Subject: Specifications
In-Reply-To: <Pine.LNX.3.96.1011016205612.4302A-100000@defian.alphanet.ch>
References: <8pjlst88ar1v2mkpluj9q44amm7crhihga@4ax.com> <Pine.LNX.3.96.1011016205612.4302A-100000@defian.alphanet.ch>
Message-ID: <nb12ttgevdnlqq33ai9m90q5oje7vmnst7@4ax.com>

Le Tue, 16 Oct 2001 21:38:13 +0200, tu as ecrit :

>> (Question plut?t pour les comptables) Serait-il utile d'avoir un label
>> d'exercice "human readable" ? Par exemple, pour pouvoir se r?f?rer ? la
>
>J'ajoute un libell? UNIQUE, obligatoire.

Pourquoi ? C'est le couple "Soci?t? - label de l'exercice" qui doit ?tre
unique (p.ex le GULL peut avoir un exercice 1999, ch/open aussi, mais le
GULL ne peut pas avoir 2 exercices 1999).

[table externe pour le lot]
>> Inutile ? mon avis. Le "lot" repr?sente un paquet d'?critures li?es, avec
>> la propri?t? que la somme des montants du lot est nulle. Comme "libell?",
>> on peut utiliser le num?ro de la premi?re ?criture du lot.
>
>J'aimais bien l'id?e d'avoir un lot comme concept externe.

L? comme ?a, je ne vois pas trop quoi en faire. Pour moi, le lot ne sert
qu'? reconna?tre une ?criture et ses contreparties de telle fa?on que le
total soit nul (par exemple, un d?bit de 50.- dans la caisse, et un cr?dit
de 50.- correspondant dans le compte "cotisations"). Une id?e ?

>> >--    - Missing tables: compte, 
>> 
>> Yep. Et c'est une table plus qu'importante. Je n'?tais pas encore au clair
>> avec ce qu'Alex avait mis dans les sp?cifications, je n'ai donc pas mis ?a
>> au net pour l'instant.
>
>Cr?? une classe/table temporaire.

En fait, il y avait une table "plan comptable" dans les sp?cifications qui
est cens?es contenir les comptes -- c'est ?a ta table "comptes".

>> >                       numero INT4 NOT NULL,
>> 
>> Il faut une num?rotation s?quentielle diff?rente pour chaque exercice,
>> peut-on le faire automatiquement facilement ?
>
>Peux-tu me donner quelques exemples de num?rotation valables pour
>plusieurs exercices (il n'y a pas de num?rotation externe ? exercice pour
>le moment) ?  Doit-elle ?tre dans tous les cas compos?e de nombres qui se
>suivent ?  De lettres et de nombres ?

Nombres qui se suivent. Dans chaque exercice (par exemple "GULL - 1999"),
les ?critures sont automatiquement num?rot?es ? partir de 1. Ca permet,
entre autres, d'imprimer un journal des ?critures et de s'assurer qu'on les
a toutes (p.ex. dans le cas d'un contr?le). En fait, les num?ros de lot
devraient ?tre cr??s en fonction de cette num?rotation (de mani?re ? ?tre
ind?pendants de l'"id", interne ? la db). Par exemple, une fois que la
compta est imprim?e, tu peux regarder dans le journal quels sont les autres
?critures du lot -- c'est ?a l'int?r?t de la num?rotation propre.

>faut-il automatiquement avoir un rounding au 20?me par exemple (MONEY ne
>fait-il pas d?j? ?a) ?

Non, c'est ? choix. Tu peux vouloir travailler au centime ou aux 5 cts.
Suivant la devise, tu peux m?me vouloir arrondir ? l'unit? (ex. les lires,
m?me si ce ne sera plus d'actualit? dans quelques mois). Ca doit ?tre un
param?tre pour chaque exercice.

>--    - Add trigger/rules which if device is NULL, takes the one of

Deformation d'UNIXien ?? :-)    device --> devise.

Fr?d?ric


From Gilbert.Robert at issco.unige.ch  Mon Oct 22 20:10:46 2001
From: Gilbert.Robert at issco.unige.ch (Gilbert Robert)
Date: Mon, 22 Oct 2001 19:10:46 +0100
Subject: (forw) Re: Specifications
Message-ID: <20011022191046.A27631@issco.unige.ch>

juste pour signaler une suite d'outils (pas OSS). Cela  peut ?tre 
d?but pour que des entreprises portent leurs applications:

http://valentine.thekompany.com/products/

Il y a un outil de compta (pour priv?) qui ? l'air pas mal (pour le prix)!

A essayer...

Gilbert




From schutz at mathgen.ch  Fri Oct 26 10:13:01 2001
From: schutz at mathgen.ch (Frederic Schutz)
Date: Fri, 26 Oct 2001 18:13:01 +1000
Subject: Compta
In-Reply-To: <sbd91735.095@gw.jura.ch>
References: <sbd91735.095@gw.jura.ch>
Message-ID: <in6itts8vqb7urv7r7dp8fe763dmpaf7gu@4ax.com>

En r?ponse ? Roberto Segalla <roberto.segalla at jura.ch>:

> Tr?s bonne id?e de cr?er une compta sous Linux.
> 
> Si je peux aider le projet n'h?sitez pas ? me contacter.

Et bien oui, une aide serait la bienvenue. Deux choses principales
a faire:

  - un certain nombre d'applications de compta sous Linux ont ete
    citees dans la liste (nomicmac, sql-ledger,...) . Il faudrait 
    commencer par faire une liste de ces compta (lien sur le site
    web, etc), et petit a petit, les essayer, pour voir ce qu'elles
    contiennent, leurs points forts et faibles, si elle pourrait
    convenir a une utilisation en Suisse, etc. C'est un boulot qui
    se distribue facilement a plusieurs, pas besoin de tout faire.

  - A partir des propositions d'Alex, j'ai redige un premier brouillon
    de specification, et Marc a propose quelques tables SQL. Il serait
    bien que quelqu'un d'autre regarde tout ca et fasse des commentaires
    (attention, les specifications sont encore peu lisibles).

Toute autre proposition est egalement bienvenue.

Frederic


From schaefer at alphanet.ch  Sat Oct 27 11:38:25 2001
From: schaefer at alphanet.ch (Marc SCHAEFER)
Date: Sat, 27 Oct 2001 11:38:25 +0200 (MEST)
Subject: Specifications
In-Reply-To: <nb12ttgevdnlqq33ai9m90q5oje7vmnst7@4ax.com>
Message-ID: <Pine.LNX.3.96.1011027110047.1256A-100000@defian.alphanet.ch>

On Sat, 20 Oct 2001, Frederic Schutz wrote:

> >J'ajoute un libell? UNIQUE, obligatoire.
> 
> Pourquoi ? C'est le couple "Soci?t? - label de l'exercice" qui doit ?tre
> unique (p.ex le GULL peut avoir un exercice 1999, ch/open aussi, mais le
> GULL ne peut pas avoir 2 exercices 1999).

ok,

UNIQUE(libelle, societe),

> Nombres qui se suivent. Dans chaque exercice (par exemple "GULL - 1999"),
> les ?critures sont automatiquement num?rot?es ? partir de 1. Ca permet,

Les s?quences de PostgreSQL ne garantissent pas l'absence de trous. En cas
de transaction avort?es par exemple.  On pourrait utiliser une table de
compteurs, il faut que je me renseigne.

(les autres commentaires sont pertinents, je les garde).

La version actuelle de *.sql est dans

   http://www-internal.alphanet.ch/~schaefer/some_files/GULL_COMPTA/

y compris avec quelques ?bauches de triggers. Les fichiers sont comment?s.