Discussion :

[mirooz]

Bonjour à tous !

J’ai créé une base de données Access permettant de gérer mes comptes personnels. J’y ai créé deux tables distinctes pour les encaissements et décaissements, possédant la structure suivante :

DECAISSEMENTS :

ID_DECAISSEMENT, DATE_DECAISSEMENT, LIBELLE_DECAISSEMENT, DESTINATAIRE_DECAISSEMENT, MOYEN_PAIEMENT, MONTANT_DECAISSEMENT

ENCAISSEMENTS :

ID_ENCAISSEMENT, DATE_ENCAISSEMENT, LIBELLE_ENCAISSEMENT, EMETTEUR_ENCAISSEMENT, MOYEN_RECOUVREMENT, MONTANT_ENCAISSEMENT

Je souhaite maintenant réaliser un état basé sur les données de ces deux tables afin de restituer leurs données de la façon suivante :

DATE_OPERATION, LIBELLE_OPERATION, TIERS_OPERATION, MOYEN_PAIEMENT_RECOUVREMENT, DEBIT, CREDIT

J’ai créé une requête d’union entre les deux tables afin de pouvoir restituer toutes les opérations quelque soit leur nature (encaissement ou décaissement). Cela fonctionne mais, en revanche, je ne vois pas comment afficher les deux dernières colonnes (Debit / Crédit) qui devront être remplies en fonction de la nature de l’opération (décaissement = débit, encaissement = crédit)
Vous trouverez en pièce jointe un fichier Excel avec un exemple plus parlant de ce que je souhaite obtenir.

Merci d’avance pour votre aide.

Edit: ma version d'Access est la 2010

[reedy]

Bonsoir,

Tout d'abord, il y'a des erreurs de modélisation dans ton application. Gérer les mouvements de sa finance dans 2 tables séparées n'est pas du tout une bonne chose. Pour une bonne modélisation, il faut prévoir une seule table "Mouvements" avec 2 clefs entrangères, la première pointant vers une table "SENS_MOUVEMENT" (débit ou crédit) et la 2ème pointant vers une table moyen de paiement (chèque, espèce, virement...)

T_MOUVEMENTS:
id_mouvement (num auto)
date
libelle
montant
id_moyen_paiement
id_sens_mouvement

T_MOYENS_PAIEMENT
id_moyen_paiement (num auto)
libelle_moyen_paiement

T_SENS_MOUVEMENT
id_sens_mouvement (num auto)
libelle_sens_mouvement

Une fois les tables et les relations crées dans Access, pour mettre en colonne les débits et les crédits à mon avis la meilleure solution c'est de passer par une requête croisée dynamique avec comme entête de ligne "id_mouvement", entête de colonne "libelle_mouvement" et comme valeur (intersection des lignes et des colonnes) le montant.

La requête croisée dynamique te donnerea un résultat ressemblant à ceci:

id_mouvement----débit---crédit
1----------------400
2-----------------------1000
3-----------------------300
4-----------------600


Ensuite pour faire apparaitre les autres informations sur le mouvement (date mouvement, moyen de paiement, bénéficiaire ou émetteur) il suffira de créer une requête selection avec jointure entre la requête croisée dynamique, la table "MOUVEMENTS" et la table "MOYENS_PAIEMENT"

date_mouvement-----libelle mouvement-moyen paiement---débit----crédit
date1----------------libelle1----------chèque-------------400
date2----------------libelle2----------virement--------------------1000
date3----------------libelle3----------versement-------------------300
date4----------------libelle4----------virement------------600


Cordialement

[mirooz]

Bonjour,

Merci reedy pour le temps passé sur la question. Effectivement je souhaitais éviter dans la mesure du possible d'avoir deux tables séparées, mais je l'ai fait car bien qu'ayant une structure proche, elles possèdent des clés étrangères les reliant à des tables différentes (par exemple une table "mode_paiement" et une "mode_recouvrement", une table "categorie_decaissement" et une "catégorie_encaissement)
Je me rends compte maintenant que mon modèle de données aurait effectivement pu être beaucoup plus simple. Je vais réduire le nombre de tables et tester ta solution.

[f-leb]

bonsoir,

Tout d'abord, il y'a des erreurs de modélisation dans ton application. Gérer les mouvements de sa finance dans 2 tables séparées n'est pas du tout une bonne chose.

La chose n'est pas forcément bonne si on regarde certains traitements, notamment ceux liés à la conception des formulaires/états. Toutefois, sur le strict plan de la modélisation, il n'y a pas à généraliser et faire deux tables pour les encaissements et décaissements peut très bien s'avérer être un bon choix de conception.

(voir http://warin.developpez.com/tutoriel...onnees-access/ ou selon le même modèle du tuto, un mouvement est soit un encaissement, soit un décaissement)

[reedy]

Bonjour,

f-leb, je suis d'accord avec vous. Effectivement, il est possible d'avoir 2 tables séparées "Encaissements" et "Décaissements" tout en ayant un bon modèle de données. En fait, le modèle que j'ai proposé était basé sur l'idée que mode de recouvrement voulait dire la même chose que mode de paiement, ce qui n'est pas le cas comme vient de le préciser mirooz dans son dernier post.
Le modèle utilisé par mirooz correpond, je pense, au modèle avec spécialisation totale pour reprendre la terminologie utilisée par Christophe WARIN dans son fameux tuto que je connais trés bien.

Ceci dit , l'utilisation d'une requete croisée dynamique pour mettre en colonne les débits et les crédits reste applicable aux 2 modèles à mon avis.

Cordialement

[mirooz]

Bonjour reedy, f-leb, le Forum,

Merci pour vos compléments d'information. Après plusieurs tests, je vous confirme que les deux solutions fonctionnent. Avec mon modèle de données initial, il me manquait simplement un élément permettant de faire la distinction entre un décaissement et un encaissement une fois les deux tables fusionnées. => réglé par l'ajout du champ "sens_mouvement"

Reedy, ta solution est intéressante dans le sens où elle permet de rendre mon application bien plus facile à maintenir, puisque le nombre de formulaires et de requêtes sera divisé par deux. J'ai donc créé une seule table "categories_transaction" dans laquelle j'ai ajouté un champ "nature_categorie". Ce dernier me permet de spécifier si une catégorie est propre aux décaissements et aux encaissements. Lors d'une saisie, je filtrerai seulement sur ceux impactés en fonction de la nature de la transaction.
Pour les modes de paiement et recouvrement, j'ai décidé de ne garder qu'une seule table car je n'ai finalement pas besoin d'une distinction par décaissement / encaissement.

Merci à vous !