Discussion :

[MachA57]

J'aurai plutôt remplacé l'intitulé "TlbClient" par "TblDirigeant" car juridiquement notre client est l'entreprise et non pas son dirigeant.

De même, c'est l'entreprise qui souscrit au pack "chef d'entreprise" (même si le nom de ce pack peut prêter à confusion). D'ailleurs, un dirigeant peut diriger une ou plusieurs entreprises mais sans que toutes ces entreprises ne bénéficient nécessairement du pack. Donc "IDPack" irait plutôt selon moi dans la table "TblEntreprise" non ?

[bertiny]

Bonsoir
Oui bien sûr selon votre explication, IDPack de la table TblClient ira plutôt dans la table TblEntreprise.
Pour le nom des tables, tu as la latitude de les appeler comme tu veux à partir du moment où tu ne t'égare pas sur le sens que tu les accordes.

un dirigeant peut diriger une ou plusieurs entreprises mais sans que toutes ces entreprises ne bénéficient nécessairement du pack

Si on considère donc que tu nommés ta table TblDirigeant tu modifiera donc ta base ainsi

TblDirigeant(IDDirigeant, Nom, Prenom,...)
TblMission(IDMission,Date,...)
TblEffectue(IDMission, IDDirigeant)
TblPack(IDPack, Intitule,..)
TblEntreprise(IDEntreprise, IDDirigeant, IDPack, NomEntreprise,....)

[MachA57]

A quoi sert la table "TblEffectue" dans ton exemple ?

[bertiny]

A quoi sert la table "TblEffectue" dans ton exemple ?

C'est une table relation entre TblMission et TblDirigeant.

[MachA57]

Pourquoi faudrait-il créer une table "TblPack" ?

Le pack chef d'entreprise est finalement une option que certaines entreprises souscrivent (ou pas).
Un champ dans la table "Tblentreprise" type "oui/non" ne suffirait-il pas ?

[hyperion13]

En compta géné, nous faisons bien des travaux périodiques pour des entreprises qui sont représentées par des personnes physiques (exploitants, dirigeants).
Les travaux de l'expert-comptable sont bien et toujours définis par la lettre de mission.
La lettre de mission va lier l'entreprise avec son expert-comptable. C'est bien toujours d'actualité.
La lettre de mission prend à date d'effet et peut-être ponctuelle ou récurrente par tacite reconduction.
La lettre de mission définit avec exactitude les prestations réalisées (et non prévues) par l'expert-comptable ainsi que les honoraires (et révision des honoraires).
La lettre de mission identifie les personnes du cabinet en charge de l'exécution de la mission.
Etc.

[bertiny]

Bonjour

Un champ dans la table "Tblentreprise" type "oui/non" ne suffirait-il pas ?

Bien sûr. Si ce champ existe et qu'elle est juste une valeur booléenne alors çà résoud le problème.

[MachA57]

Suivant vos observations, ma BDD pourrait-elle ressembler à cela ?

[bertiny]

Bonsoir
Pas de critiques à mon niveau à part si d'autres membres ont quelque chose à dire. Je pense que ça va

[hyperion13]

Peut-être relire mon post#26
De plus le statut juridique peut évoluer dans le temps, tout comme le régime fiscal et de TVA, ainsi que le représentant de l'entreprise.
Le lettre de mission identifie l'entreprise, les différentes prestations (pack), les honoraires, les prestations non prévues et leur coût, les collaborateurs, etc.

[MachA57]

Comment gérer effectivement cet historique de la forme juridique, du dirigeant ou du régime fiscal par exemple ?

Je suis désolé mais la relecture de votre post #26 ne m'en dit pas plus...

Comment faire ensuite pour créer des formulaires de saisie ?

Merci d'avance

[MachA57]

Edit : j'ai solutionné cette question...Désolé

Je suis perdu avec les zones de listes, la saisie de données dans les tables et la présentation d'états qui en découlent.

Actuellement, tel que vous me l'avez conseillé, j'ai des relations entre la clé primaire d'une table et un champ de type "numérique" dans une autre table. Ex : IDFormeJur dans TblEntreprise vers IDFormeJur dans TblFormeJuridique.

Dans TblFormeJuridique, les enregistrements sont :
IDFormeJur => NomFormeJur
1 => SAS
2 => SARL
3 => SA
etc...

Mon problème réside dans le remplissage des enregistrements dans TblEntreprise.
Comment faire pour que ce soit intuitif pour l'utilisateur. Celui qui saisit ne va pas retenir que 1 correspond à SAS, que 2 correspond à SARL, etc... Il est plus aisé de saisie SARL ou SA même si après la valeur apparaissant dans la table est 1 ou 2.

[MachA57]

Je reviens sur ma question précédente.

Une entreprise a une forme juridique. Cette forme juridique est susceptible de changer lors d'une formalité juridique (transformation d'une SARL en SAS par exemple).
Une entreprise a aussi un dirigeant. Ce dirigeant est susceptible de changer lors d'une autre formalité juridique.
J'aurai voulu que la TblEntreprise soit mise à jour automatiquement lors de la saisie de l'enregistrement lié à cette formalité juridique. Est-ce possible et si oui, commet bien sûr

[hyperion13]

Salut
Pour pouvoir enregistrer un changement de dirigeant, un changement de statut juridique, de régime fiscal, etc. il faudrait procéder comme indiqué en image.

[MachA57]

Cela signifierait-il que je ne dois pas avoir le champ IDFormJur dans TblEntreprise puisqu'il serait dans une table distincte reliée à TblEntreprise ?
Dans ce cas, comment compléter la BDD au départ....il faut bien un point de départ de la saisie des données initiales.
Je mets en oeuvre cette BDD mais nous n'allons pas reconstituer tout l'historique. Le point de départ sera la situation actuelle avec la forme juridique, le dirigeant en place actuellement.
Cela ne remet-il pas en cause votre exemple ?

Et pourquoi 2 clé primaires dans tblStatChange dans votre exemple ?

Voici un résultat de ma BDD suivant vos indications :

[MachA57]

Je me permets de reposer la question en instance :

pourquoi 2 clés primaires dans tblStatChange dans votre exemple ?

[hyperion13]

Alors idEtsfk et idStatfk sont 2 clés étrangères qui composent une clé primaire. Les explications sont là.
Un peu beaucoup de lecture pour comprendre l'analyse conceptuelle ici.