RechDom dans requête

[lmc71]

Bonjour le Forum

J'essaie d'utiliser la fonction RECHDOM dans une requête qui me permettrait de sélectionner un montant suite à un changement à une date d'anniversaire.
J'ai recherché sur la toile, mais je n'arrive pas à appliquer convenablement cette fonction, qui je pense est la clef de mon souci. Tout du moins c'est ce que je pense.
Dans le dossier joint j'explique clairement et en détail ce que je souhaiterais obtenir.
Si quelqu'un à une idée pour me débloquer je l'en remercie d'avance.
Amicalement à tous

 

[chris]

Re : RechDom dans requête

Bonjour

De façon générale éviter les fonctions de domaine très consommatrices de ressources : dans la plupart des cas, on peut s'en passer en remplaçant par une requête.

J'avoue n'avoir pas compris concrètement ton problème : peux tu expliciter (hors aspects BD) ce que tu cherches à faire entre tes appartements, tes loyers et autres...

 

[lmc71]

Re : RechDom dans requête

Bonjour Chris
Je suis toujours sur la même BD de l'autre discussion.
Il y a plusieurs immeubles, comprenant un ou plusieurs appartements chacun. Il y a des gains (Loyers, ou divers) et des dépenses (Impôt, dépenses, Assurances, Prêts, et autres charges.). Chaque année il y a des modifications du montant en gains comme en dépenses. Toutes ces modifications se font le 1/01/xxxx sauf le montant de l'assurance immeuble qui est modifié le mois anniversaire de l'achat de l'immeuble (Ex 1/4/xxxx).
Je souhaiterais, dans mon état récapitulatif trié par appartement et par mois, (Loyer -(Prêt+Assurance+Agios+Intérêt prêt +......)=Balance) que le montant de l'assurance (calculé par m² par appartement) montre l'augmentation effective au bon mois et que les précédents présentent fassent figurer le montant de l'assurance avant modification. (photo jointe).
J'ai tout essayé dans une requête, en créant des champs de tri en modifiant les relations soit par année, soit par date soit aucune relation entre tables, mais je n'arrive pas à obtenir le résultat escompté.
Je te remercie de te pencher sur la question car toute l'application fonctionne mis à part de détail.
Si j'effectue la modification au 1/1/xxxx tout baigne.
En ce qui concerne Rechdom, je ne maîtrise pas suffisamment cette fonction pour pouvoir constituer des formules complexes.
Merci de te pencher sur cette question, ce qui démontre encore une fois tout ton savoir faire.
Amicalement

 

[chris]

Re : RechDom dans requête

Bonjour

Concernant les prix, de façon générale on a deux solutions.

Je vais prendre l'exemple des factures qui qui pour moi est plus simple à expliquer.

Si j'émets une facture e jour et que ma table des produits contient le prix unitaire, je peux ne stocker que le code article et la quantité dans mon enregistrement ligne de facture.
Le problème si je fait cela c'est que quand le prix de mes produits aura changé, je serai incapable de réémettre la facture à l'identique, ce qui pose des problèmes légaux.

Pour parer à cela je peux :

• soit stocker le prix unitaire dans l'enregistrement facture afin d'en garder la valeur au jour de l'émission,
• soit prévoir une table des prix avec code article date de début et prix et donc ne pas stocker le prix dans la table des articles.
  Avec cette seconde solution, je suis capable par requête de croiser la date de facture avec les dates de la table prix pour réémettre la facture au prix en vigueur lors de son émission.
  Cela me permet aussi d'anticiper mes augmentations ou diminutions et d'avoir un historique.

Dans une requête tu peux mettre des champs calculée avec un SI (Vraifaux dans ACCESS) qui te calcule le montant mensuel selon la date anniversaire.

L'important en base de données c'est, avant de faire quoi que ce soit dans la base, de bien mettre à plat ce que tu veux gérer et une des méthodes consiste à "dessiner" tous les écrans ou états souhaités. Cela te permet de voir tous les éléments nécessaires et t'aide à structurer ta base.

 

[lmc71]

Re : RechDom dans requête

Bonjour,
Tes explications sont de vrais livres, mais pour moi j'ai du mal à transposer ta leçon.
Dans le fichier attaché lors de l'ouverture de cette discussion, j'ai ce que tu appelle table des prix (Charge Modif), avec Code Article (Appartement), date Début (Nvx Date) et prix (Nvx Montant). Jusque là je pense avoir tes arguments. Et c'est là que je n'arrive plus à suivre ton raisonnement, car j'ai douze date Facture (loyer pour mois) avec une seule date (prix) par année. J'ai même créer un table récupérant mensuellement le Prix. Je n'arrive pas à faire la relation Date Prix avec Date Loyer, que ce soit par année, mois ou jour. Je m'enlise. Je suis arrivé à faire un calcul similaire avec la modification des impôts foncier sur trois mois car c'est bloqué pour les mois de octobre à Décembre, mais je n'arrive pas à trouver la bonne formule pour les assurances de chaque immeuble en date volatile.
Merci de ta réponse
Amicalement

 

[lmc71]

Re : RechDom dans requête

Bonjour,
J'ai repensé à ton histoire de facture et de prix que j'ai comprise.
Dans mon histoire, en disant que facture est égal à Loyer et que produit est égal à appartement, il y a le soucis, tout du moins pour moi, je n'arrive pas à faire la relation entre loyer - appartement - prix et date. Je n'arrive pas à marier les requêtes.
Bon WE.
Amicalement

 

[chris]

Re : RechDom dans requête

Bonjour

Tant qu'on ne peut établir de relations 1 à n entre toutes tes tables on ne peut avancer.

J'avais soulevé la question de la clé primaire de la table des appartements : je n'ai toujours pas compris à quoi sert la date de cette table.

Tu as plein de tables qui peuvent peut-être remplacée par des requêtes...

Je ne connais pas ton domaine : si tu pouvais expliquer en 4 phrases simples ce que tu gères et comment tu veux le gérer cela faciliterai les choses.

 

[lmc71]

Re : RechDom dans requête

Bonjour Chris
Toutes mes tables sont en relations 1 à n.
En ce qui concerne la date dans la table appartement sert à éviter que les appartement soient pris en compte par une date antérieure à la date du mois. Je m'explique : l'appartement n° 4 acheté le 1/04/2008, s'il n'y a pas de date d'enregistrement dans la table Appartement, ledit appartement sera pris en compte par la date loyer des appartements n° 1-2 et 3 acheté en date du 1/03/2006 ou suivante mais avant le 1/4/2008. Ce que je ne veux pas. S'il y a une autre possibilité pour empêcher ce fait, je ne le connais pas.
En ce qui concerne le nombre table, je ne vois pas comment je pourrais faire pour mettre une valeur brute aux Frais de Gestion, aux montant des impôts, aux des Prêts, des dé, pense, de la vente des appartements ou immeubles, des agios bancaires et des mois. Peut-être de regrouper certaines données dans la même table, mais je ne pense pas que c'est là le soucis de mon problème ou alors je n'ai rien compris à access.
Je ne vois pas ce que tu veux dire par "Domaine". Mais comme je l'ai dire auparavant, c'est pour mes neveux, qui a crée une SCI et ont acheté des immeubles et ne connaissant pas Access, je me suis proposé de leur créer une application gérant tout ce qui concerne, l'achat d'un appartement, ses dépenses, ses frais bancaires, impôts, assurances et autres.
Je pars sur l'achat de l'immeuble comprenant X appartements, je renseigne les frais bancaires (prêts, Intérêts et assurance de prêt), le montant des charges Impôts fonciers et assurance, et en dernier les frais de gestion de chaque appartement.
Une fois toutes ces données incluses dans les tables respectives. Je mets à jour le mois en cause, puis j'ouvre le formulaire Loyer et je valide les appartements qui sont acquittés ou non, puis je mets à jour le montant des agios. Tous les calculs se font normalement à l'exception de l'assurance relative au lois de la modification du montant. Car c'est la seule données qui ne correspond pas au 1er de l'année.
J'espère avoir répondu à tes questions.
Merci
Amicalement

 

[lmc71]

Re : RechDom dans requête

Bonjour Chris
Dans le fichier joint Essai Relations 31, il n' y a que cinq tables Immeuble, Appartement, Charge modif, Loyer et Date mois. Ces cinq tables sont en relations 1 à n et pourtant sitôt que j'effectue une modification du montant dans la table Charge Modif l'année suivante, la relation au mois voulu ne s'effectue pas.
Donc le nombre de tables ne joue en rien, à mon sens si ce n'est que d'alourdir la BD, dans le problème de relations entre la modification d'un prix et la table Loyer.
Je suis entrain de faire comme le chat .......
Merci

 

[chris]

Re : RechDom dans requête

Bonjour

Je me suis basée sur ton post 1 : la base fournie n'a pas de relations 1 à n déclarées sauf 1

Si je comprends bien la SCI achète des biens et les loue. Il devrait y avoir

• une tables des biens : immeubles avec leur adresse
• une table des appartements, liés aux immeubles, et identifiés par un N° d'appartement voire un étage et une localisation. La date ne doit pas faire partie de la clé primaire.
  Si les appartements sont loués, selon que l'on souhaite garder ou non l'historique, il y aura la date de début du bail et la date de fin réelle ou prévue dans cette table et le loyer prévu ou tout cela sera dans une seconde table si on garde l'historique.

Toujours selon ma compréhension il y a des charges payées par le propriétaire, certaines répercutées sur le loyer (achat du bien) d'autres dans les charges facturées à l'occupant.

A priori je créerais une seule table des charges avec leur nature leur fréquence mensuelle ou annuelle, la date de référence 1er janvier ou date anniversaire du bail (ou autre) et le code bien concerné.
Cela implique pour les charges, éventuellement dans la table des appartements, deux clé de répartition : comment l'appartement participe aux charges propriétaire et comment il participe aux charges locataire.
Si cela ne peut se faire selon un % identique pour toutes les charges, il faut une table qui croise type de charge, appartement et les 2 clés de répartition pour les calculs.

Il y aura aussi une table des charges effectives liée à celle-ci : code type charge, bien, date et montant notamment...

Reste à voir où on stocke les données pour la réévaluation des loyers et charges : il doit y avoir des lois donc cela en dépend.

En début d'année on doit pouvoir par requête (enchainement de requêtes sans doute) lister seulement, et/ou créer dans une table, les enregistrements correspondant à l'ensemble des données loyer, charges par appartement et mois soit les montants à encaisser.
En cours d'année il peut sans doute y avoir des changements si un locataire part...

Après les paiements ou retards sont des problème de gestion. Tu peux prévoir dans la table citée ci-dessus une date de règlement qui servira à vérifier les paiements effectifs, les retards et calculer les agios si j'ai bien compris.

 

[lmc71]

Re : RechDom dans requête

Bonjour Chris
Tu as vu juste en parti. Si tu reprends la dernière version du Fichier Essai Relation 31 posté ce jour à 11h46, tu verras que les cinq tables concernées sont en relation 1 à n.
Dans ma BD initiale, j'ai déjà prévu ce que tu dis en ce qui concerne la relation entre immeuble, appartement, charges.......
Cette application n'a pas but la gestion des locataires, mais seulement le récapitulatif Gains - Dépenses diverses = Bénéfice ou perte. Il n'y a aucune charge imputable au locataire. C'est un tableau de bord pour une vue globale que ce soit par immeuble, appartement, concernant les montants : LOYER - IMPÔT - PRÊT - ASSURANCE - FRAIS DE GESTION - et autres.......
Si un appartement est vacant, si un locataire a du retard dans ses paiements tout ceci est pris en compte et fonctionnent à merveille dans la version complète de mon application..

Je me répète surement, mais le fichier ESSAI RELATION 31, n'est qu'un exemple du souci dans le calcul de la relation Mois Loyer et Mois charge si, et seulement, la date de modification n'est pas le 1/01/ de chaque année. .
J'ai déjà la Table concernant les Charges. Elle se nomme dans ce fichier "Charge Modif". J'ai un champ Nom charge qui prend en compte l'assurance et Impôt foncier. Elle porte sur deux années ce qui me permet d'effectuer un calcul de différence et de taux entre les deux montants. Elle est en relation avec la Table Immeuble. La valeur de la charge par appartement est calculée au m² dans la requête "Charge par appartement au mois" et renvoyée dans la table Charge Mensuel pour ce qui est assurance et Charge Impôt pour ce qui est de l'impôt (ne fait pas attention au nom des tables ou requêtes qui ne sont pas significatif dans cet exemple).

Pour l'instant je pense avoir suivi tes précieux conseils, Relations - non concordance et pourtant je bute toujours sur cette relation date Loyer et date modification charge anniversaire.
Merci
Amicalement

 

[chris]

Re : RechDom dans requête

RE

Je n'ai vu ta seconde base qu'après avoir commencé ma réponse qui a pris du temps.

Néanmoins je ne comprends pas la structure de ta table charges modif :
tu devrais avoir

• Ref immeuble
• Nom charge
• Date début de validité
• Montant

Je ne vois pas non plus l’intérêt d'avoir des tables pour chaque type de charge. Une seule table avec une colonne type charge serait plus gérable.

Dans toutes les tables l'année ne sert à rien puisqu'on peut la déduire de la date.

J'ai modifié ta table charges modif et deux requêtes (indice 2) : cela semble répondre à ton problème.

 

[lmc71]

Re : RechDom dans requête

Re
Effectivement, tu as fait du bon travail. J'ai regardé grossièrement tes modifications et demain je vais approfondir. Il me restera à trouver la solution pour effectuer le calcul des différences entre les deux années, du fait que tu as supprimer un jeu de champs.
Merci encore. Je te tiendrai informé.
Amicalement;

 

[chris]

Re : RechDom dans requête

Re

La différence se calcule facilement par requête sur table charges modif...

 

[lmc71]

Re : RechDom dans requête

Bonjour Chris
Bonjour le Forum
J'ai regardé en détail les modifications que tu as apporté et la clef de ma solution est la formule utilisée dans la requête (>=[Nvx Date] Et <AjDate("m";12;[nvx date])).
J'ai supprimé la clef primaire relative à la date d'enregistrement dans la table Appartement et j'ai conservé l'ossature de toutes les autres tables. J'ai inséré ta formule au bon endroit et la magie a opéré. Toute mon application fonctionne comme je le souhaite.
J'avais essayé une formule du style qui triait le champs Date Mois sur les douze mois antérieure, mais je n'avais jamais pensé avec le ET.
Tu es un Merlin l'enchanteur, car tu m'a enlevé une belle épine.
Je vais pouvoir donner aux neveux un superbe produit.
C'est le troisième problème que tu me résolves en je t'en remercie.
Amicalement
Dossier clos