Discussion :

[Benzozia]

Bonjour à tous,

J'aime bien AC mais je suis novice et par expérience, j'ai compris qu'il valait mieux bien partir avant d'aller trop loin, au risque de tout recommencer... Voilà pourquoi je viens vers vous.

Je sais qu'il n'ai pas convenu de mettre un fichier joint lors du 1er message mais j'espère que les images, elles, le sont ? Cela m'évitera de tout récrire et je pense, plus lisible.

Ci-dessus, mon tableau de relation.

Voilà l'idée ; Je veux gérer un parc de produits, de l'achat à la vente. Produits pouvant passer par une ou plusieurs locations ou locataires avant la vente.

Donc, avant d'aller plus loin, je voudrais savoir si je démarre correctement ?

En résumé, un produit peut être vendu ou loué. S'il est loué, il peut être loué à un ou plusieurs locataires (1 à la fois) avant d'être vendu potentiellement à un client "non locataire".

Mon idée, c'est d'un formulaire de base du Produit, je puisse gérer, vérifier et contrôler l'état et l'amortissement du parc des produits à l'instant T.

Je rajoute ci-dessous les copies d'écrans de mes différentes tables si besoin.


Vous remerciant de l'aide que vous pourrez me donner, je vous souhaite une bonne journée.
Cordialement,

[marot_r]

Bonjour.

Les relations en "diamant" sont generalement un signe de probleme de conception.

Est-ce que tu peux avoir la location d'un instrument qui appartient a un client X par un client Y ?

Ou c'est toujours un client <-> un instrument <-> une location ?

A+

[Benzozia]

Merci de l'intérêt que vous portez à mon projet.

Les relations en "diamant" sont generalement un signe de probleme de conception.

Je ne sais pas pourquoi ! mais je me doutais bien que cela n'était pas très logique....

Est-ce que tu peux avoir la location d'un instrument qui appartient a un client X par un client Y ?

Non. chaque instruments est achetés par l'entreprise chez un fournisseur ou un particulier. De là, soit je le vends à un client, soit je le loue. Dans ce 2ème cas, au long des années, le même instrument peut se retrouvé loué à différents clients. ex : Un client loue l'instrument une 1ère année. Il arrête. Un autre client loue ce même instru (à nouveau disponible) x année... ainsi de suite. Jusqu'où, cet instrument soit un jour vendu.

Ou c'est toujours un client <-> un instrument <-> une location ?

Dans ma tête, ce serait plutôt dans cette ordre ci :

un instrument -> un client<-> une location (on est bien d'accord ! Dans la vie de l'instrument, il pourra y avoir plusieurs clients et plusieurs locations...)
ou
un instrument -> un client<-> une vente

Merci pour votre aide !

[hyperion13]

Salut,
Une proposition
Instrument(idInstrument, libelle, etc.)
Client(idClient, nomcli, pnomcli, etc.)
Louer(idInstrumentfk, idClientfk, datedebloc, datefinloc, etc.) le champ durée est inutile. on peut l'obtenir par la différence des 2 dates.
Vendre(idInstrumentfk, idClientfk, datevente, etc.)

[Benzozia]

Salut !

Merci hyperion13.

Voici ce que cela donne si j'ai bien suivi :


Je peux continuer ? Si oui et si j'essai de comprendre, je crée maintenant mon formulaire principale Instruments, j'incorpore des boutons cliquables (LOCATION ou VENDU) qui renverrons vers le formulaire de la table en question ?

Pour voir le client qui loue, ou à loué, ou à acheté faut-il l'intégrer la table CLIENTS en sous-formulaire de LOUER et VENDRE ?

Merci pour les tuyaux !

[hyperion13]

Les tbl vendre et louer ont une double clé primaire.
Pour vos form, à l'aide de l'assistant créez un form principal (instrument) et 2 sform (louer) et (vendre)

[marot_r]

Bonjour.

Petite suggestion d'architecture bien que les ventes et les locations soient des entites distinctes :

Traiter les ventes comme des locations jusqu'en 9999-12-31.
Eventuellement ajouter un champ et une table "TypeOpperation" ou "TypeTransaction" qui offer le choix entre "Location" ou "Vente".
L"ajout d'un champ type permet de facilement identifier les ventes ou les locations.

Cela pernet de :

1. N'avoir qu'une seule source de donnees ce qui permet de faire facilement la somme de toute les "transactions".
2. N'avoir qu'un seul ecran qui gere les 2 types de transactions.

C'est juste une idee et si les ventes et les locations devaient avoir des attributs vraiment differents ce ne se serait peut-etre pas forcement rentable ni pratique.

A+

[marot_r]

Aussi tu mentionnes que tu achetes tes instruments, donc une table "Fournisseur" serait peut-etre utile.

tblFournisseur
ClefFournisseur
Autres infos (ex : Nom)

tblInstrument
ClefInstrument
ClefFournisseur
Autres infos (ex : Nom, date d'achat)

Relation entre tblInstrument et tblFournisseur.

A+

[hyperion13]

Salut marot_r
Effectivement. Mais je suis un adepte du jeu j'affiche ou je masque des objets (sform, btn) fonction d'une condition RecordsetClone.RecordCount
@+