Relations entre table pour une application comptable
3 réponses
kolele
Je cherche à faire une petite application comptable (en partie double,
débit-crédit), avec au minimum :
- Une table "Journal des écritures". Champs : Numéro de l'écriture
(numéroAuto et clé primaire), date, montant, commentaire, compte débité,
compte crédité.
- Une table "Comptes". Champs : Code du compte (numéroAuto et clé primaire),
nom du compte, Numéro du compte (plan comptable).
- Relations entre les 2 tables : un (Code du compte de la table "Comptes") à
plusieurs (Code du compte de la table "Journal des écritures"), avec
application de l'intégrité référentielle.
Mon problème, c'est que, dans ma table "Journal des Ecritures", je dois
faire 2 fois référence à un champ de la table "Compte" : une fois pour le
compte débité, une fois pour le compte crédité. Et je n'arrive pas à penser
cette architecture.
J'ai un pis-aller : créer 2 tables pour les comptes (une table "Compte de
débit", une table "compte de crédit") mais ça me gêne. D'abord, il va me
falloir à chaque création d'un nouveau compte l'ouvrir 2 fois, dans chaque
table. Ensuite et surtout, l'intérêt d'une telle appli, c'est d'éditer une
fiche de compte, avec pour un même compte, les montants débités et les
montants crédités. Trop dangereux pour la compta, d'avoir deux tables
jumelles Compte crédité et Compte débité. Et puis ce n'est pas Accessement
correct.
Je n'ai pas encore trouvé la solution dans la littérature Access.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
pgz
Bonjour,
Si tu considères qu'une inscription au livre journal correspond au débit d'un compte et au crédit d'un autre, pour chaque enregistrement, tu prévois un champ 'compte débité' et un champ 'compte crédité'. Ca ne pose pas de pb Access.
Mais attention, à ma connaissance, ce n'est pas si simple. Par exemple un achat de marchandise se décompose ainsi : 607 : achats de marchandises : montant HT au débit 44566 : TVA sur autre biens et services : TVA au débit 401 : Fournisseurs : Montant TTC au crédit.
Bon courage,
pgz -- pgz _____________________________
Je cherche à faire une petite application comptable (en partie double, débit-crédit), avec au minimum : - Une table "Journal des écritures". Champs : Numéro de l'écriture (numéroAuto et clé primaire), date, montant, commentaire, compte débité, compte crédité. - Une table "Comptes". Champs : Code du compte (numéroAuto et clé primaire), nom du compte, Numéro du compte (plan comptable). - Relations entre les 2 tables : un (Code du compte de la table "Comptes") à plusieurs (Code du compte de la table "Journal des écritures"), avec application de l'intégrité référentielle.
Mon problème, c'est que, dans ma table "Journal des Ecritures", je dois faire 2 fois référence à un champ de la table "Compte" : une fois pour le compte débité, une fois pour le compte crédité. Et je n'arrive pas à penser cette architecture. J'ai un pis-aller : créer 2 tables pour les comptes (une table "Compte de débit", une table "compte de crédit") mais ça me gêne. D'abord, il va me falloir à chaque création d'un nouveau compte l'ouvrir 2 fois, dans chaque table. Ensuite et surtout, l'intérêt d'une telle appli, c'est d'éditer une fiche de compte, avec pour un même compte, les montants débités et les montants crédités. Trop dangereux pour la compta, d'avoir deux tables jumelles Compte crédité et Compte débité. Et puis ce n'est pas Accessement correct.
Je n'ai pas encore trouvé la solution dans la littérature Access.
Bonjour,
Si tu considères qu'une inscription au livre journal correspond au débit
d'un compte et au crédit d'un autre, pour chaque enregistrement, tu prévois
un champ 'compte débité' et un champ 'compte crédité'. Ca ne pose pas de pb
Access.
Mais attention, à ma connaissance, ce n'est pas si simple. Par exemple un
achat de marchandise se décompose ainsi :
607 : achats de marchandises : montant HT au débit
44566 : TVA sur autre biens et services : TVA au débit
401 : Fournisseurs : Montant TTC au crédit.
Je cherche à faire une petite application comptable (en partie double,
débit-crédit), avec au minimum :
- Une table "Journal des écritures". Champs : Numéro de l'écriture
(numéroAuto et clé primaire), date, montant, commentaire, compte débité,
compte crédité.
- Une table "Comptes". Champs : Code du compte (numéroAuto et clé primaire),
nom du compte, Numéro du compte (plan comptable).
- Relations entre les 2 tables : un (Code du compte de la table "Comptes") à
plusieurs (Code du compte de la table "Journal des écritures"), avec
application de l'intégrité référentielle.
Mon problème, c'est que, dans ma table "Journal des Ecritures", je dois
faire 2 fois référence à un champ de la table "Compte" : une fois pour le
compte débité, une fois pour le compte crédité. Et je n'arrive pas à penser
cette architecture.
J'ai un pis-aller : créer 2 tables pour les comptes (une table "Compte de
débit", une table "compte de crédit") mais ça me gêne. D'abord, il va me
falloir à chaque création d'un nouveau compte l'ouvrir 2 fois, dans chaque
table. Ensuite et surtout, l'intérêt d'une telle appli, c'est d'éditer une
fiche de compte, avec pour un même compte, les montants débités et les
montants crédités. Trop dangereux pour la compta, d'avoir deux tables
jumelles Compte crédité et Compte débité. Et puis ce n'est pas Accessement
correct.
Je n'ai pas encore trouvé la solution dans la littérature Access.
Si tu considères qu'une inscription au livre journal correspond au débit d'un compte et au crédit d'un autre, pour chaque enregistrement, tu prévois un champ 'compte débité' et un champ 'compte crédité'. Ca ne pose pas de pb Access.
Mais attention, à ma connaissance, ce n'est pas si simple. Par exemple un achat de marchandise se décompose ainsi : 607 : achats de marchandises : montant HT au débit 44566 : TVA sur autre biens et services : TVA au débit 401 : Fournisseurs : Montant TTC au crédit.
Bon courage,
pgz -- pgz _____________________________
Je cherche à faire une petite application comptable (en partie double, débit-crédit), avec au minimum : - Une table "Journal des écritures". Champs : Numéro de l'écriture (numéroAuto et clé primaire), date, montant, commentaire, compte débité, compte crédité. - Une table "Comptes". Champs : Code du compte (numéroAuto et clé primaire), nom du compte, Numéro du compte (plan comptable). - Relations entre les 2 tables : un (Code du compte de la table "Comptes") à plusieurs (Code du compte de la table "Journal des écritures"), avec application de l'intégrité référentielle.
Mon problème, c'est que, dans ma table "Journal des Ecritures", je dois faire 2 fois référence à un champ de la table "Compte" : une fois pour le compte débité, une fois pour le compte crédité. Et je n'arrive pas à penser cette architecture. J'ai un pis-aller : créer 2 tables pour les comptes (une table "Compte de débit", une table "compte de crédit") mais ça me gêne. D'abord, il va me falloir à chaque création d'un nouveau compte l'ouvrir 2 fois, dans chaque table. Ensuite et surtout, l'intérêt d'une telle appli, c'est d'éditer une fiche de compte, avec pour un même compte, les montants débités et les montants crédités. Trop dangereux pour la compta, d'avoir deux tables jumelles Compte crédité et Compte débité. Et puis ce n'est pas Accessement correct.
Je n'ai pas encore trouvé la solution dans la littérature Access.
Dan
Salut Kolele
Je ne suis pas expert en comptabilité privée, mais il me semble qu'il y a une alternative à ton problème :
- la table des écritures ne contiendrait qu'une seule référence à celle des comptes, - mais elle contiendrait en plus un indicateur "Depénses ou Débit" ou "Recettes ou Crédit", selon l'opération, à l'aide d'un entier saisi via un groupe d'options... - accessoirement, on peut ajouter un Montant_Ecriture, passant en négatif le montant saisi si l'indicateur est Dépenses...
Avantages : - le lien avec la table des comptes est plus facile à paramétrer - un compte peut être utilisé en Débit ou en Crédit, indifféremment, selon son paramétrage - les différents journaux sont totalisables beaucoup plus facilement...
A+ Dan
Salut Kolele
Je ne suis pas expert en comptabilité privée, mais il me semble qu'il y a
une alternative à ton problème :
- la table des écritures ne contiendrait qu'une seule référence à celle des
comptes,
- mais elle contiendrait en plus un indicateur "Depénses ou Débit" ou
"Recettes ou Crédit", selon l'opération, à l'aide d'un entier saisi via un
groupe d'options...
- accessoirement, on peut ajouter un Montant_Ecriture, passant en négatif le
montant saisi si l'indicateur est Dépenses...
Avantages :
- le lien avec la table des comptes est plus facile à paramétrer
- un compte peut être utilisé en Débit ou en Crédit, indifféremment, selon
son paramétrage
- les différents journaux sont totalisables beaucoup plus facilement...
Je ne suis pas expert en comptabilité privée, mais il me semble qu'il y a une alternative à ton problème :
- la table des écritures ne contiendrait qu'une seule référence à celle des comptes, - mais elle contiendrait en plus un indicateur "Depénses ou Débit" ou "Recettes ou Crédit", selon l'opération, à l'aide d'un entier saisi via un groupe d'options... - accessoirement, on peut ajouter un Montant_Ecriture, passant en négatif le montant saisi si l'indicateur est Dépenses...
Avantages : - le lien avec la table des comptes est plus facile à paramétrer - un compte peut être utilisé en Débit ou en Crédit, indifféremment, selon son paramétrage - les différents journaux sont totalisables beaucoup plus facilement...
A+ Dan
J-Pierre
Bonjour,
Il me semble qu'une écriture se compose d'autant de lignes dans ta table qu'il y a de comptes débités ou crédités, au minimum 2, une au débit, l'autre au crédit. Dans ce cas, ta table "Journal des écritures" ne comprendra plus qu'un seul champ "compteImputé".
Avantage: Tu restes dans une architecture SQLement correcte, facile de développer. Contraintes: 1-Le numéroAuto dans ta table "Journal des écritures" ne suffit plus. Tu dois créer un nouveau champ "NumeroEcriture" grâce auquel tu pourras regrouper les différentes lignes d'une même écriture. Et tu dois gérer ce N° toi-même, mais je sais qu'il y a du code tout prêt sur le site de Pierre ou celui de Raymond. 2-Pour créer une écriture, soit plusieurs lignes, tu dois travailler avec des transactions (BeginTrans, RollbackTrans, CommitTrans), ce qui te permet de garantir que soit toutes des lignes de ton NuméroEcriture ont été écrites, soit qu'aucune ne l'a été, l'intégrité de la base est toujours respectée. Ca, ce n'est pas en standard dans Access, il faudra passer par du code VBA, si ce n'est pas sur l'un des sites mentionnés, je te passerai le code.
Autre possibilité que je ne discuterai pas en détail, en tout cas, pas tout de suite: La table "Journal des écritures" ne contient que les informations en-tête, commentaire, date, etc... Une nouvelle table "Detail des écritures" contient une ligne par compte imputé. Sa clé, N° de l'écriture plus un champAutoNum. Ca, c'est encore plus SQLement correct, car il n'y a pas de redondance d'information.
Pendant que tu y es, tu pourrais prévoir le(s) champ(s) qui te permettra(permettront) de faire de l'analytique:
Par exemple: Combien ai-je dépensé ce mois-çi pour ma femme ? Pas assez, espèce de goujat :-)
J-Pierre
"kolele" a écrit dans le message de news:
Je cherche à faire une petite application comptable (en partie double, débit-crédit), avec au minimum : - Une table "Journal des écritures". Champs : Numéro de l'écriture (numéroAuto et clé primaire), date, montant, commentaire, compte débité, compte crédité. - Une table "Comptes". Champs : Code du compte (numéroAuto et clé primaire), nom du compte, Numéro du compte (plan comptable). - Relations entre les 2 tables : un (Code du compte de la table "Comptes") à plusieurs (Code du compte de la table "Journal des écritures"), avec application de l'intégrité référentielle.
Mon problème, c'est que, dans ma table "Journal des Ecritures", je dois faire 2 fois référence à un champ de la table "Compte" : une fois pour le compte débité, une fois pour le compte crédité. Et je n'arrive pas à penser cette architecture. J'ai un pis-aller : créer 2 tables pour les comptes (une table "Compte de débit", une table "compte de crédit") mais ça me gêne. D'abord, il va me falloir à chaque création d'un nouveau compte l'ouvrir 2 fois, dans chaque table. Ensuite et surtout, l'intérêt d'une telle appli, c'est d'éditer une fiche de compte, avec pour un même compte, les montants débités et les montants crédités. Trop dangereux pour la compta, d'avoir deux tables jumelles Compte crédité et Compte débité. Et puis ce n'est pas Accessement correct.
Je n'ai pas encore trouvé la solution dans la littérature Access.
Bonjour,
Il me semble qu'une écriture se compose d'autant de lignes dans ta table qu'il y a de comptes débités ou crédités, au minimum
2, une au débit, l'autre au crédit. Dans ce cas, ta table "Journal des écritures" ne comprendra plus qu'un seul champ
"compteImputé".
Avantage: Tu restes dans une architecture SQLement correcte, facile de développer.
Contraintes:
1-Le numéroAuto dans ta table "Journal des écritures" ne suffit plus. Tu dois créer un nouveau champ "NumeroEcriture" grâce
auquel tu pourras regrouper les différentes lignes d'une même écriture. Et tu dois gérer ce N° toi-même, mais je sais qu'il y
a du code tout prêt sur le site de Pierre ou celui de Raymond.
2-Pour créer une écriture, soit plusieurs lignes, tu dois travailler avec des transactions (BeginTrans, RollbackTrans,
CommitTrans), ce qui te permet de garantir que soit toutes des lignes de ton NuméroEcriture ont été écrites, soit qu'aucune ne
l'a été, l'intégrité de la base est toujours respectée. Ca, ce n'est pas en standard dans Access, il faudra passer par du code
VBA, si ce n'est pas sur l'un des sites mentionnés, je te passerai le code.
Autre possibilité que je ne discuterai pas en détail, en tout cas, pas tout de suite:
La table "Journal des écritures" ne contient que les informations en-tête, commentaire, date, etc...
Une nouvelle table "Detail des écritures" contient une ligne par compte imputé. Sa clé, N° de l'écriture plus un champAutoNum.
Ca, c'est encore plus SQLement correct, car il n'y a pas de redondance d'information.
Pendant que tu y es, tu pourrais prévoir le(s) champ(s) qui te permettra(permettront) de faire de l'analytique:
Par exemple:
Combien ai-je dépensé ce mois-çi pour ma femme ?
Pas assez, espèce de goujat :-)
J-Pierre
"kolele" <kolele@discussions.microsoft.com> a écrit dans le message de news:
361C985B-7259-4175-AFDE-1D1B9A0920AA@microsoft.com...
Je cherche à faire une petite application comptable (en partie double,
débit-crédit), avec au minimum :
- Une table "Journal des écritures". Champs : Numéro de l'écriture
(numéroAuto et clé primaire), date, montant, commentaire, compte débité,
compte crédité.
- Une table "Comptes". Champs : Code du compte (numéroAuto et clé primaire),
nom du compte, Numéro du compte (plan comptable).
- Relations entre les 2 tables : un (Code du compte de la table "Comptes") à
plusieurs (Code du compte de la table "Journal des écritures"), avec
application de l'intégrité référentielle.
Mon problème, c'est que, dans ma table "Journal des Ecritures", je dois
faire 2 fois référence à un champ de la table "Compte" : une fois pour le
compte débité, une fois pour le compte crédité. Et je n'arrive pas à penser
cette architecture.
J'ai un pis-aller : créer 2 tables pour les comptes (une table "Compte de
débit", une table "compte de crédit") mais ça me gêne. D'abord, il va me
falloir à chaque création d'un nouveau compte l'ouvrir 2 fois, dans chaque
table. Ensuite et surtout, l'intérêt d'une telle appli, c'est d'éditer une
fiche de compte, avec pour un même compte, les montants débités et les
montants crédités. Trop dangereux pour la compta, d'avoir deux tables
jumelles Compte crédité et Compte débité. Et puis ce n'est pas Accessement
correct.
Je n'ai pas encore trouvé la solution dans la littérature Access.
Il me semble qu'une écriture se compose d'autant de lignes dans ta table qu'il y a de comptes débités ou crédités, au minimum 2, une au débit, l'autre au crédit. Dans ce cas, ta table "Journal des écritures" ne comprendra plus qu'un seul champ "compteImputé".
Avantage: Tu restes dans une architecture SQLement correcte, facile de développer. Contraintes: 1-Le numéroAuto dans ta table "Journal des écritures" ne suffit plus. Tu dois créer un nouveau champ "NumeroEcriture" grâce auquel tu pourras regrouper les différentes lignes d'une même écriture. Et tu dois gérer ce N° toi-même, mais je sais qu'il y a du code tout prêt sur le site de Pierre ou celui de Raymond. 2-Pour créer une écriture, soit plusieurs lignes, tu dois travailler avec des transactions (BeginTrans, RollbackTrans, CommitTrans), ce qui te permet de garantir que soit toutes des lignes de ton NuméroEcriture ont été écrites, soit qu'aucune ne l'a été, l'intégrité de la base est toujours respectée. Ca, ce n'est pas en standard dans Access, il faudra passer par du code VBA, si ce n'est pas sur l'un des sites mentionnés, je te passerai le code.
Autre possibilité que je ne discuterai pas en détail, en tout cas, pas tout de suite: La table "Journal des écritures" ne contient que les informations en-tête, commentaire, date, etc... Une nouvelle table "Detail des écritures" contient une ligne par compte imputé. Sa clé, N° de l'écriture plus un champAutoNum. Ca, c'est encore plus SQLement correct, car il n'y a pas de redondance d'information.
Pendant que tu y es, tu pourrais prévoir le(s) champ(s) qui te permettra(permettront) de faire de l'analytique:
Par exemple: Combien ai-je dépensé ce mois-çi pour ma femme ? Pas assez, espèce de goujat :-)
J-Pierre
"kolele" a écrit dans le message de news:
Je cherche à faire une petite application comptable (en partie double, débit-crédit), avec au minimum : - Une table "Journal des écritures". Champs : Numéro de l'écriture (numéroAuto et clé primaire), date, montant, commentaire, compte débité, compte crédité. - Une table "Comptes". Champs : Code du compte (numéroAuto et clé primaire), nom du compte, Numéro du compte (plan comptable). - Relations entre les 2 tables : un (Code du compte de la table "Comptes") à plusieurs (Code du compte de la table "Journal des écritures"), avec application de l'intégrité référentielle.
Mon problème, c'est que, dans ma table "Journal des Ecritures", je dois faire 2 fois référence à un champ de la table "Compte" : une fois pour le compte débité, une fois pour le compte crédité. Et je n'arrive pas à penser cette architecture. J'ai un pis-aller : créer 2 tables pour les comptes (une table "Compte de débit", une table "compte de crédit") mais ça me gêne. D'abord, il va me falloir à chaque création d'un nouveau compte l'ouvrir 2 fois, dans chaque table. Ensuite et surtout, l'intérêt d'une telle appli, c'est d'éditer une fiche de compte, avec pour un même compte, les montants débités et les montants crédités. Trop dangereux pour la compta, d'avoir deux tables jumelles Compte crédité et Compte débité. Et puis ce n'est pas Accessement correct.
Je n'ai pas encore trouvé la solution dans la littérature Access.
