From a.lefranc@domain.hid Wed May 07 08:43:22 2014 Received: from Debian-exim by gna.org with spam-scanned (Exim 4.80) (envelope-from ) id 1WhvZQ-0005U7-Sv for galette-devel@domain.hid; Wed, 07 May 2014 08:43:21 +0200 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.gna.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=3.3 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from smtpout4.laposte.net ([193.253.67.229] helo=smtpout.laposte.net) by gna.org with esmtp (Exim 4.80) (envelope-from ) id 1WhvZQ-0005T2-Mi for galette-devel@domain.hid; Wed, 07 May 2014 08:43:12 +0200 Received: from nord.home ([2.6.157.51]) by mwinf8508-out with ME id yuiX1n00816ovl603uiXdS; Wed, 07 May 2014 08:42:31 +0200 Message-ID: <5369D5D7.10304@domain.hid> Date: Wed, 07 May 2014 08:42:31 +0200 From: =?UTF-8?B?QW5kcsOpIExlZnJhbmM=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: galette-devel@domain.hid Content-Type: multipart/alternative; boundary="------------030406060209080301070108" Subject: [Galette-devel] =?utf-8?q?comptabilit=C3=A9_des_contributions_et_?= =?utf-8?q?transactions?= X-BeenThere: galette-devel@domain.hid X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Galette development list List-Id: Galette development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 06:43:22 -0000 This is a multi-part message in MIME format. --------------030406060209080301070108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Bonjour et encore merci pour cet outil. lors de la totalisation des contributions, il arrive que l'on butte sur une incohérence des données obtenue par la recherche des contributions; En effet, c'est la date de début de la cotisation qui est prise en compte, pour déterminer la période de comptabilisation, or cette date 1. n'est pas la date comptable de l'enregistrement en banque 2. n'est pas la date de validité au sens fiscal 3. ne permet pas de recouper avec les bordereaux des chèques 4. ne permet pas le recoupement bancaire Il serait judicieux que les dates des contributions prises en compte pour le calcul soit celle de l'enregistrement. D'autre part, nous utilisons volontiers les transactions, Nous serions très sensibles à ce que le même calcul des totaux des transactions soit disponibles sur la même base de référence. il serait très ergonomique que la page de saisie des transactions soit très semblable à celle de la saisie des contributions. en effet, la possibilité d'indiquer le type de versement (espèces, chèque, virement, et autres) est aussi nécessaire, voire peut plus que pour les contributions Faut-il ouvrir deux tickets ? Bonne journée à toutes et tous -- André Lefranc Trésorier du Réseau Environnement Santé --------------030406060209080301070108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Bonjour et encore merci pour cet outil.

lors de la totalisation des contributions,
il arrive que l'on butte sur une incohérence des données
obtenue par la recherche des contributions;

En effet, c'est la date de début de la cotisation qui est prise en compte,
pour déterminer la période de comptabilisation, or cette date

n'est pas la date comptable de l'enregistrement en banque
n'est pas la date de validité au sens fiscal
ne permet pas de recouper avec les bordereaux des chèques
ne permet pas le recoupement bancaire

Il serait judicieux que les dates des contributions prises en compte pour le calcul soit celle de l'enregistrement.

D'autre part, nous utilisons volontiers les transactions,
Nous serions très sensibles à ce que le même calcul des totaux des transactions soit disponibles
sur la même base de référence.
il serait très ergonomique que la page de saisie des transactions soit très semblable à celle de la saisie des contributions.
en effet, la possibilité d'indiquer le type de versement (espèces, chèque, virement, et autres) est aussi nécessaire,
voire peut plus que pour les contributions

Faut-il ouvrir deux tickets ?

Bonne journée à toutes et tous
--

André Lefranc
Trésorier du Réseau Environnement Santé

--------------030406060209080301070108-- From johan@domain.hid Thu May 08 07:50:42 2014 Received: from Debian-exim by gna.org with spam-scanned (Exim 4.80) (envelope-from ) id 1WiHE2-0007rL-LC for galette-devel@domain.hid; Thu, 08 May 2014 07:50:42 +0200 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.gna.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.3 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.2 Received: from 10.mo69.mail-out.ovh.net ([46.105.73.241] helo=mo69.mail-out.ovh.net) by gna.org with esmtp (Exim 4.80) (envelope-from ) id 1WiHE0-0007rD-Uv for galette-devel@domain.hid; Thu, 08 May 2014 07:50:34 +0200 Received: from mail611.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo69.mail-out.ovh.net (Postfix) with SMTP id 5215DFFAA6B for ; Thu, 8 May 2014 07:50:10 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 8 May 2014 07:50:23 +0200 Received: from 89-92-138-194.hfc.dyn.abo.bbox.fr (HELO ?192.168.1.2?) (trasher@domain.hid) by ns0.ovh.net with SMTP; 8 May 2014 07:50:20 +0200 Message-ID: <536B1B54.9080802@domain.hid> Date: Thu, 08 May 2014 07:51:16 +0200 From: Johan Cwiklinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Galette development list References: <5369D5D7.10304@domain.hid> In-Reply-To: <5369D5D7.10304@domain.hid> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k5Qm2UQ1Uf70KNPMtADpVLtouFQMOLPQS" X-Ovh-Tracer-Id: 1953436339466367152 X-Ovh-Remote: 89.92.138.194 (89-92-138-194.hfc.dyn.abo.bbox.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -200 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejvddrfeeiucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdengfhvvghrhghhihhtvgdqqdetucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -200 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejvddrfeeiucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdengfhvvghrhghhihhtvgdqqdetucdlqddutddtmd Subject: Re: [Galette-devel] =?iso-8859-1?q?comptabilit=E9_des_contributions_e?= =?iso-8859-1?q?t_transactions?= X-BeenThere: galette-devel@domain.hid X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Galette development list List-Id: Galette development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 05:50:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k5Qm2UQ1Uf70KNPMtADpVLtouFQMOLPQS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Salut, Le 07/05/2014 08:42, Andr=E9 Lefranc a =E9crit : > D'autre part, nous utilisons volontiers les transactions, > Nous serions tr=E8s sensibles =E0 ce que le m=EAme calcul des totaux de= s > transactions soit disponibles > sur la m=EAme base de r=E9f=E9rence. Pourquoi pas... Il faut ouvrir une demande en ce sens (il ne me semble pas que =E7a existe d=E9j=E0 - =E0 v=E9rifier). > il serait tr=E8s ergonomique que la page de saisie des transactions soi= t > tr=E8s semblable =E0 celle de la saisie des contributions. Elle l'est d=E9j=E0 ; je ne vois pas particuli=E8rement de probl=E8me d'e= rgonomie. > en effet, la possibilit=E9 d'indiquer le type de versement (esp=E8ces, > ch=E8que, virement, et autres) est aussi n=E9cessaire, > voire peut plus que pour les contributions Les transactions regroupent une ou plusieurs contributions. Dans Galette, ce sont ces derni=E8res qui contiennent le type de r=E8glement, ajouter =E7a dans les transactions, c'est ajouter le possibilit=E9 de dir= e qu'une transaction est pay=E9e par virement, et qu'elle contient une contribution pay=E9e par ch=E8que, et une autre en esp=E8ces ; o=F9 serai= t la logique ? D=E9patouiller =E7a c=F4t=E9 Galette serait trop compliqu=E9. Par ailleurs, tu as d=E9j=E0 cr=E9=E9 un ticket pour =E7a (#574). ++ --=20 Johan --k5Qm2UQ1Uf70KNPMtADpVLtouFQMOLPQS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNrG1QACgkQ7N2B+4uln5QNDwCePMPBHB2bZCyx5yfEM0InRIKB 7CQAn3tZBRRP0QeWbmPiMdgUx6dHikbT =lewt -----END PGP SIGNATURE----- --k5Qm2UQ1Uf70KNPMtADpVLtouFQMOLPQS-- From a.lefranc@domain.hid Thu May 08 08:45:26 2014 Received: from Debian-exim by gna.org with spam-scanned (Exim 4.80) (envelope-from ) id 1WiI50-0005Wv-0Y for galette-devel@domain.hid; Thu, 08 May 2014 08:45:25 +0200 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.gna.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=3.3 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from smtpout5.laposte.net ([193.253.67.230] helo=smtpout.laposte.net) by gna.org with esmtp (Exim 4.80) (envelope-from ) id 1WiI4z-0005W3-RS for galette-devel@domain.hid; Thu, 08 May 2014 08:45:17 +0200 Received: from nord.home ([2.6.28.15]) by mwinf8510-out with ME id zJkb1n00J0KZbD603JkcSQ; Thu, 08 May 2014 08:44:36 +0200 Message-ID: <536B27D3.8010106@domain.hid> Date: Thu, 08 May 2014 08:44:35 +0200 From: =?UTF-8?B?QW5kcsOpIExlZnJhbmM=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Galette development list References: <5369D5D7.10304@domain.hid> <536B1B54.9080802@domain.hid> In-Reply-To: <536B1B54.9080802@domain.hid> Content-Type: multipart/alternative; boundary="------------050205020902000702020708" Subject: Re: [Galette-devel] =?utf-8?q?comptabilit=C3=A9_des_contributions_et_?= =?utf-8?q?transactions?= X-BeenThere: galette-devel@domain.hid X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Galette development list List-Id: Galette development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 06:45:26 -0000 This is a multi-part message in MIME format. --------------050205020902000702020708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 08/05/14 07:51, Johan Cwiklinski a écrit : > Salut, > > Le 07/05/2014 08:42, André Lefranc a écrit : >> D'autre part, nous utilisons volontiers les transactions, >> Nous serions très sensibles à ce que le même calcul des totaux des >> transactions soit disponibles >> sur la même base de référence. > Pourquoi pas... Il faut ouvrir une demande en ce sens (il ne me semble > pas que ça existe déjà - à vérifier). > >> il serait très ergonomique que la page de saisie des transactions soit >> très semblable à celle de la saisie des contributions. > Elle l'est déjà ; je ne vois pas particulièrement de problème d'ergonomie. Juste sur la saisie de la nature du virement (espèces, chèque, virement, et autres) > >> en effet, la possibilité d'indiquer le type de versement (espèces, >> chèque, virement, et autres) est aussi nécessaire, >> voire peut plus que pour les contributions > Les transactions regroupent une ou plusieurs contributions. Dans > Galette, ce sont ces dernières qui contiennent le type de règlement, > ajouter ça dans les transactions, c'est ajouter le possibilité de dire > qu'une transaction est payée par virement, et qu'elle contient une > contribution payée par chèque, et une autre en espèces ; où serait la > logique ? Effectivement, si la saisie qui suit est incohérente, ça va cafouiller, mais là c'est la saisie qui serait en cause. Mais ce n'est pas Galette qui serait illogique, c'est la personne qui ventile !!! Parce que la transaction existe, elle sur le plan bancaire, sa nature et donc le tri d'après sa nature est un plus dans les vérifications des écritures de la banque. Quand je reçois un chèque de 50 € , en banque j'ai un crédit (sur un bordereau) de 50 € qui est le réel de l'encaissement, avec la banque, le montant, et y compris le nom du titulaire du compte qui peut être différent du nom de l'adhérent. Je ventile entre cotisations : 30 € et dons : 20 € (là je ne recopie pas les infos du chèque. puisque déjà fait dans la saisie de la transaction) Si je cherche un chèque de 30 € et/ou de 20 € en banque, impossible de trouver et faire un bordereau ça complique... Pour l'instant j'ai écrit une page basique qui cherche le mot "chq" dans la description de la transaction et qui établit un bordereau.. Ces références là ce serait plus logique de les mettre attachées à la transaction (ce que nous faisons). mais si le tri par nature (espèces, chèque, virement, et autres) dans la liste des transaction était possible ce serait un grand plus. de même si la liste des transactions pouvait permettre un recherche entre deux dates, avec total ce serait super... Bien cordialement > > Dépatouiller ça côté Galette serait trop compliqué. > > Par ailleurs, tu as déjà créé un ticket pour ça (#574). > > ++ > > > _______________________________________________ > Galette-devel mailing list > Galette-devel@domain.hid > https://mail.gna.org/listinfo/galette-devel --------------050205020902000702020708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Le 08/05/14 07:51, Johan Cwiklinski a écrit :

Salut,

Le 07/05/2014 08:42, André Lefranc a écrit :

D'autre part, nous utilisons volontiers les transactions,
Nous serions très sensibles à ce que le même calcul des totaux des
transactions soit disponibles
sur la même base de référence.

Pourquoi pas... Il faut ouvrir une demande en ce sens (il ne me semble
pas que ça existe déjà - à vérifier).

il serait très ergonomique que la page de saisie des transactions soit
très semblable à celle de la saisie des contributions.

Elle l'est déjà ; je ne vois pas particulièrement de problème d'ergonomie.

Juste sur la saisie de la nature du virement (espèces, chèque, virement, et autres)

en effet, la possibilité d'indiquer le type de versement (espèces,
chèque, virement, et autres) est aussi nécessaire,
voire peut plus que pour les contributions

Les transactions regroupent une ou plusieurs contributions. Dans
Galette, ce sont ces dernières qui contiennent le type de règlement,
ajouter ça dans les transactions, c'est ajouter le possibilité de dire
qu'une transaction est payée par virement, et qu'elle contient une
contribution payée par chèque, et une autre en espèces ; où serait la
logique ?

Effectivement, si la saisie qui suit est incohérente, ça va cafouiller, mais là c'est la saisie qui serait en cause.
Mais ce n'est pas Galette qui serait illogique, c'est la personne qui ventile !!!

Parce que la transaction existe, elle sur le plan bancaire, sa nature
et donc le tri d'après sa nature est un plus dans les vérifications des écritures de la banque.
Quand je reçois un chèque de 50 € , en banque j'ai un crédit (sur un bordereau) de 50 € qui est le réel de l'encaissement,
avec la banque, le montant, et y compris le nom du titulaire du compte qui peut être différent du nom de l'adhérent.
Je ventile entre cotisations : 30 € et dons : 20 € (là je ne recopie pas les infos du chèque. puisque déjà fait dans la saisie de la transaction)

Si je cherche un chèque de 30 € et/ou de 20 € en banque, impossible de trouver et faire un bordereau ça complique...
Pour l'instant j'ai écrit une page basique qui cherche le mot "chq" dans la description de la transaction et qui établit un bordereau..

Ces références là ce serait plus logique de les mettre attachées à la transaction (ce que nous faisons).
mais si le tri par nature (espèces, chèque, virement, et autres) dans la liste des transaction était possible ce serait un grand plus.

de même si la liste des transactions pouvait permettre un recherche entre deux dates, avec total ce serait super...

Bien cordialement


Dépatouiller ça côté Galette serait trop compliqué.

Par ailleurs, tu as déjà créé un ticket pour ça (#574).

++

_______________________________________________
Galette-devel mailing list
Galette-devel@domain.hid
https://mail.gna.org/listinfo/galette-devel

--------------050205020902000702020708-- From johan@domain.hid Sun May 11 10:02:39 2014 Received: from Debian-exim by gna.org with spam-scanned (Exim 4.80) (envelope-from ) id 1WjOiN-0002BX-9u for galette-devel@domain.hid; Sun, 11 May 2014 10:02:39 +0200 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.gna.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.3 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.2 Received: from 3.mo4.mail-out.ovh.net ([46.105.57.129] helo=mo4.mail-out.ovh.net) by gna.org with esmtp (Exim 4.80) (envelope-from ) id 1WjOiN-00029s-1o for galette-devel@domain.hid; Sun, 11 May 2014 10:02:31 +0200 Received: from mail615.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo4.mail-out.ovh.net (Postfix) with SMTP id 949FAFF900F for ; Sun, 11 May 2014 10:02:10 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 11 May 2014 10:02:23 +0200 Received: from 89-92-138-194.hfc.dyn.abo.bbox.fr (HELO ?192.168.1.2?) (trasher@domain.hid) by ns0.ovh.net with SMTP; 11 May 2014 10:02:22 +0200 Message-ID: <536F2ECA.7060105@domain.hid> Date: Sun, 11 May 2014 10:03:22 +0200 From: Johan Cwiklinski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Galette development list References: <5369D5D7.10304@domain.hid> <536B1B54.9080802@domain.hid> <536B27D3.8010106@domain.hid> In-Reply-To: <536B27D3.8010106@domain.hid> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VpF1JFUH1qSOjKSOgINa9sBvmaxHqIQ1r" X-Ovh-Tracer-Id: 3354618772805021872 X-Ovh-Remote: 89.92.138.194 (89-92-138-194.hfc.dyn.abo.bbox.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -200 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejvddrfeelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdengfhvvghrhghhihhtvgdqqdetucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -200 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejvddrfeelucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdengfhvvghrhghhihhtvgdqqdetucdlqddutddtmd Subject: Re: [Galette-devel] =?windows-1252?q?comptabilit=E9_des_contributions?= =?windows-1252?q?_et_transactions?= X-BeenThere: galette-devel@domain.hid X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Galette development list List-Id: Galette development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 08:02:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VpF1JFUH1qSOjKSOgINa9sBvmaxHqIQ1r Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Salut, Le 08/05/2014 08:44, Andr=E9 Lefranc a =E9crit : >>> il serait tr=E8s ergonomique que la page de saisie des transactions s= oit >>> tr=E8s semblable =E0 celle de la saisie des contributions. >> Elle l'est d=E9j=E0 ; je ne vois pas particuli=E8rement de probl=E8me >> d'ergonomie. > Juste sur la saisie de la nature du virement (esp=E8ces, ch=E8que, vire= ment, > et autres) OK, =C7a n'a donc strictement rien =E0 voir avec de l'ergonomie. >> Les transactions regroupent une ou plusieurs contributions. Dans >> Galette, ce sont ces derni=E8res qui contiennent le type de r=E8glemen= t, >> ajouter =E7a dans les transactions, c'est ajouter le possibilit=E9 de = dire >> qu'une transaction est pay=E9e par virement, et qu'elle contient une >> contribution pay=E9e par ch=E8que, et une autre en esp=E8ces ; o=F9 se= rait la >> logique ? > Effectivement, si la saisie qui suit est incoh=E9rente, =E7a va cafouil= ler, > mais l=E0 c'est la saisie qui serait en cause. > Mais ce n'est pas Galette qui serait illogique, c'est la personne qui > ventile !!! Heu... Si le logiciel permet de faire n'importe quoi, il y aura toujours quelqu'un pour faire n'importe quoi (et s'en plaindre) ; donc je ne suis pas vraiment d'accord. Bref. > Parce que la transaction existe, elle sur le plan bancaire, sa nature > et donc le tri d'apr=E8s sa nature est un plus dans les v=E9rifications= des > =E9critures de la banque. > Quand je re=E7ois un ch=E8que de 50 =80 , en banque j'ai un cr=E9dit (s= ur un > bordereau) de 50 =80 qui est le r=E9el de l'encaissement, > avec la banque, le montant, et y compris le nom du titulaire du compte > qui peut =EAtre diff=E9rent du nom de l'adh=E9rent. > Je ventile entre cotisations : 30 =80 et dons : 20 =80 (l=E0 je ne rec= opie > pas les infos du ch=E8que. puisque d=E9j=E0 fait dans la saisie de la > transaction) Les consid=E9rations de rapprochements bancaires, =E7a d=E9passe largemen= t le cadre du projet. > Ces r=E9f=E9rences l=E0 ce serait plus logique de les mettre attach=E9e= s =E0 la > transaction (ce que nous faisons). Puisque tout ce dont tu as besoin existe d=E9j=E0 dans les contributions,= il suffirait pour le moment de renseigner ces informations dans les contributions elles-m=EAmes (le seul probl=E8me que je vois, c'est de dev= oir saisir le num=E9ro du ch=E8que sur les X contributions). Il faut =E0 mon = avis voir les transactions comme un moyen de regrouper des contributions (et je me demande si =E7a doit vraiment aller plus loin que =E7a). En fait le type de paiement devrait logiquement =EAtre dans la transaction, et non dans la contribution. Sauf que peu de gens utilisent les transactions. Il faudrait donc que ce soit dans les transactions pour ceux qui les utilisent, et dans les contributions pour les autres, ce qui n'est pas possible ; d'autant que l'on peut mixer les deux ! Il faudrait donc que ce soit pr=E9sent des deux c=F4t=E9s ; sauf que =E7a= pose des probl=E8mes : - possibles incoh=E9rences entre transactions et contributions attach=E9e= s, - comportement difficile =E0 comprendre si l'on mixe l'utilisation des deux syst=E8mes, - recherches impossibles (puisque ce n'est pas centralis=E9), - ... Bien que ces probl=E8mes pourraient =EAtre r=E9gl=E9s par l'utilisateur (= et encore...), le but de Galette est de diriger la saisie et de limiter les erreurs, pas de donner les possibilit=E9s d'un tableur. En clair, le probl=E8me est loin de se limiter =E0 l'ajout d'un champ dan= s un formulaire :) ++ --=20 Johan --VpF1JFUH1qSOjKSOgINa9sBvmaxHqIQ1r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNvLsoACgkQ7N2B+4uln5SNXgCffi0KxH9g/VlpXE3FU0m3YEbe t8kAn37GA1jVfeeM/HUyNbEdq9iNnNba =YHcT -----END PGP SIGNATURE----- --VpF1JFUH1qSOjKSOgINa9sBvmaxHqIQ1r--