Cacher des sous formulaires vides dans un formulaire principal
Fermé
jeanlouismaso
Messages postés
4
Date d'inscription
lundi 24 octobre 2016
Statut
Membre
Dernière intervention
26 octobre 2016
-
24 oct. 2016 à 09:31
jeanlouismaso Messages postés 4 Date d'inscription lundi 24 octobre 2016 Statut Membre Dernière intervention 26 octobre 2016 - 26 oct. 2016 à 08:54
jeanlouismaso Messages postés 4 Date d'inscription lundi 24 octobre 2016 Statut Membre Dernière intervention 26 octobre 2016 - 26 oct. 2016 à 08:54
A voir également:
- Cacher des sous formulaires vides dans un formulaire principal
- Formulaire de réclamation facebook - Guide
- Cacher conversation whatsapp - Guide
- Application pour cacher des applications - Guide
- Formulaire instagram compte suspendu - Guide
- Formulaire rempli - Guide
8 réponses
Utilisateur anonyme
24 oct. 2016 à 21:30
24 oct. 2016 à 21:30
Bonjour,
cela sent à plein nez le défaut de conception.
Mais bon, tant que l'on n'aura pas vu ta base, on ne peut être certain.
Ce qui est par contre certain, c'est que l'on n'imprime pas un formulaire, c'est un état qu'il te faut, et là ton sous état sans donnée sera ...... vide, donc pas imprimé.
Si tu veux, mets ta base sur cjoint, que l'on puisse se faire une idée et t'aider.
A+
cela sent à plein nez le défaut de conception.
Mais bon, tant que l'on n'aura pas vu ta base, on ne peut être certain.
Ce qui est par contre certain, c'est que l'on n'imprime pas un formulaire, c'est un état qu'il te faut, et là ton sous état sans donnée sera ...... vide, donc pas imprimé.
Si tu veux, mets ta base sur cjoint, que l'on puisse se faire une idée et t'aider.
A+
jeanlouismaso
Messages postés
4
Date d'inscription
lundi 24 octobre 2016
Statut
Membre
Dernière intervention
26 octobre 2016
25 oct. 2016 à 14:17
25 oct. 2016 à 14:17
Bonjour HDU et merci pour ta réponse, sympa !
Peut-être as-tu raison sur la conception, je suis en plein "développement" mais si j'utilise un formulaire plutôt qu'un état c'est qu'il y a parfois un besoin de modifications avant l'impression d'un devis.
Concernant le masquage des sous-formulaires à l'impression j'ai résolu le problème avec le code suivant pour chaque sous-formulaire qui fonctionne très bien dans le formulaire principal F_DEVIS :
"Private Sub Form_Current()
With Me![SUBF_E1].Form
' Check the RecordCount of the Subform.
If Forms![F_DEVIS]![SUBF_E1].Form![Q11] = 0 Then
' Hide the subform.
.Visible = False
End If
End With"
Ceci ne me règle pas le problème des lignes de mesures vierges qui s'impriment quand même dans chaque formulaire... Peut-être une autre commande VBA ?
Concernant la base que tu peux trouver ici :
https://drive.google.com/file/d/0B2xB-Hg8vStiakdYZ3R5NGhpZU0/view?usp=sharing
c'est vrai qu'elle semble complexe mais ceci est dû à l'activité que j'essaie d'automatiser et que je peux résumer ainsi :
nous sommes une entreprise de pose de menuiseries alu haut de gamme dont les métreurs réalisent les devis "à la main" puis qui les donnent aux secrétaires qui ressaisissaient tout sur le logiciel de gestion commerciale avec une perte de temps évidente et un archivage nul. L'élaboration des devis est complexe avec pour le même client jusqu'à 20 étiquettes différentes de produits donnant lieu à chaque fois à un maximum de 10 mesures de 4 variables (type de produit, mesures, quantité et prix) elles aussi différentes. Tout mettre sur la même base ou requête serait impossible et exploserait la limite de 255 champs. J'ai donc scindé le problème en créant une table ACTION principale (une action pouvant être un rendez-vous se transformant en devis puis en commande) liée évidemment à la table CLIENTS et contenant uniquement les numéros d'étiquettes correspondant, les mesures étant traitées indépendamment dans les tables PRODUITS (1, 2, 3, etc...) associées strictement aux actions par leur numéros d'index. Le moteur fonctionne bien et enregistre tous les éléments à partir du formulaire principal F_ACTION dépendant de la requête principale R_REQUETE_PRINCIPALE. Le problème central reste l'impression automatique du devis que j'ai testé avec 3 étiquettes seulement sachant qu'il y en aura 20 pour la base définitive. Les autres requêtes ou formulaires sont présents pour créer les boutons d'un futur menu principal (formulaire F_MENU) vers des listes filtrées ou des recherches ciblées comme pour le formulaires de consultation à onglets F_LISTES qui permet d'accéder aux informations et aux actions correspondantes de façon synthétique.
Je sais qu'il y a certainement beaucoup de choses à rationaliser, en particulier je pense au niveau des tables et des requêtes comme par exemple imaginer une seule table PRODUITS associée aux ACTIONS mais aussi aux ETIQUETTES (si cela est possible, je n'ai pas essayé), ce qui simplifierait grandement la base de données.
Merci encore à toi et très bonne journée.
Peut-être as-tu raison sur la conception, je suis en plein "développement" mais si j'utilise un formulaire plutôt qu'un état c'est qu'il y a parfois un besoin de modifications avant l'impression d'un devis.
Concernant le masquage des sous-formulaires à l'impression j'ai résolu le problème avec le code suivant pour chaque sous-formulaire qui fonctionne très bien dans le formulaire principal F_DEVIS :
"Private Sub Form_Current()
With Me![SUBF_E1].Form
' Check the RecordCount of the Subform.
If Forms![F_DEVIS]![SUBF_E1].Form![Q11] = 0 Then
' Hide the subform.
.Visible = False
End If
End With"
Ceci ne me règle pas le problème des lignes de mesures vierges qui s'impriment quand même dans chaque formulaire... Peut-être une autre commande VBA ?
Concernant la base que tu peux trouver ici :
https://drive.google.com/file/d/0B2xB-Hg8vStiakdYZ3R5NGhpZU0/view?usp=sharing
c'est vrai qu'elle semble complexe mais ceci est dû à l'activité que j'essaie d'automatiser et que je peux résumer ainsi :
nous sommes une entreprise de pose de menuiseries alu haut de gamme dont les métreurs réalisent les devis "à la main" puis qui les donnent aux secrétaires qui ressaisissaient tout sur le logiciel de gestion commerciale avec une perte de temps évidente et un archivage nul. L'élaboration des devis est complexe avec pour le même client jusqu'à 20 étiquettes différentes de produits donnant lieu à chaque fois à un maximum de 10 mesures de 4 variables (type de produit, mesures, quantité et prix) elles aussi différentes. Tout mettre sur la même base ou requête serait impossible et exploserait la limite de 255 champs. J'ai donc scindé le problème en créant une table ACTION principale (une action pouvant être un rendez-vous se transformant en devis puis en commande) liée évidemment à la table CLIENTS et contenant uniquement les numéros d'étiquettes correspondant, les mesures étant traitées indépendamment dans les tables PRODUITS (1, 2, 3, etc...) associées strictement aux actions par leur numéros d'index. Le moteur fonctionne bien et enregistre tous les éléments à partir du formulaire principal F_ACTION dépendant de la requête principale R_REQUETE_PRINCIPALE. Le problème central reste l'impression automatique du devis que j'ai testé avec 3 étiquettes seulement sachant qu'il y en aura 20 pour la base définitive. Les autres requêtes ou formulaires sont présents pour créer les boutons d'un futur menu principal (formulaire F_MENU) vers des listes filtrées ou des recherches ciblées comme pour le formulaires de consultation à onglets F_LISTES qui permet d'accéder aux informations et aux actions correspondantes de façon synthétique.
Je sais qu'il y a certainement beaucoup de choses à rationaliser, en particulier je pense au niveau des tables et des requêtes comme par exemple imaginer une seule table PRODUITS associée aux ACTIONS mais aussi aux ETIQUETTES (si cela est possible, je n'ai pas essayé), ce qui simplifierait grandement la base de données.
Merci encore à toi et très bonne journée.
Utilisateur anonyme
25 oct. 2016 à 21:51
25 oct. 2016 à 21:51
Bonjour HDU et merci pour ta réponse, sympa !
No pb, le forum est fait pour cela !
Peut-être as-tu raison sur la conception, je suis en plein "développement" mais si j'utilise un formulaire plutôt qu'un état c'est qu'il y a parfois un besoin de modifications avant l'impression d'un devis.
Base ton état sur la même source que le formulaire...
Concernant le masquage des sous-formulaires à l'impression j'ai résolu le problème avec le code suivant pour chaque sous-formulaire qui fonctionne très bien dans le formulaire principal F_DEVIS :
Comme dit auparavant, l'état sert à imprimer, le formulaire à saisir ou consulter...
Après, j'ai téléchargé ta base, effectivement, beaucoup d'objets inutiles... A première vue.
Dis moi exactement où cela bloque.
A+
No pb, le forum est fait pour cela !
Peut-être as-tu raison sur la conception, je suis en plein "développement" mais si j'utilise un formulaire plutôt qu'un état c'est qu'il y a parfois un besoin de modifications avant l'impression d'un devis.
Base ton état sur la même source que le formulaire...
Concernant le masquage des sous-formulaires à l'impression j'ai résolu le problème avec le code suivant pour chaque sous-formulaire qui fonctionne très bien dans le formulaire principal F_DEVIS :
Comme dit auparavant, l'état sert à imprimer, le formulaire à saisir ou consulter...
Après, j'ai téléchargé ta base, effectivement, beaucoup d'objets inutiles... A première vue.
Dis moi exactement où cela bloque.
A+
Utilisateur anonyme
25 oct. 2016 à 23:24
25 oct. 2016 à 23:24
Je ne comprends pas ce que "étiquette1" et suivantes veulent dire...
Je pense qu'il te manque une table en fait
Quand je regarde tes relations, ce n'est pas correct...
Une table intermédiaire "devis" et "devis_client" pourrait simplifier.
No ?
Je pense qu'il te manque une table en fait
Quand je regarde tes relations, ce n'est pas correct...
Une table intermédiaire "devis" et "devis_client" pourrait simplifier.
No ?
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
jeanlouismaso
Messages postés
4
Date d'inscription
lundi 24 octobre 2016
Statut
Membre
Dernière intervention
26 octobre 2016
26 oct. 2016 à 00:05
26 oct. 2016 à 00:05
Salut et merci encore pour ton attention. Je vais effectivement passer mon formulaire F_DEVIS en état. Pour les étiquettes, il s'agit des différents produits que nous vendons, 266 références en tout avec fournisseurs, type, etc..qui se trouvent dans la table ETIQUETTES, pas énorme mais il peut y avoir jusqu'à 20 étiquettes différentes par devis qu'il faut pouvoir sélectionner par liste déroulante d'où ma numérotation des tables ETIQUETTES1, 2, 3 que je vais continuer jusqu'à 20 donc avec autant de type de produits, mesures, quantités et prix, renseignés dans les tables PRODUITS1, 2, 3..., le tout associé au niveau des relations au numéro unique d'index de l'ACTION (Rdv, Devis ou Commande) correspondante. Tout ceci pour ne pas dépasser la limite de 255 champs par table et requête. J'aurai donc au final 20 onglets E1, E2, E3, etc...dans mon formulaire principal F_ACTION et 20 sous-formulaires ou plutôt 20 sous-états dans mon état principal E_DEVIS. C'est le seul moyen que j'ai trouvé pour ne pas avoir de pages blanches dans mon devis entre les étiquettes et le total calculé en fin d'état si comme en moyenne un devis contient 3 à 4 étiquettes de produits différentes, 20 étant le maximum. Donc effectivement mon problème est d'essayer de simplifier tout ça parce que pour l'instant tout fonctionne, ça ne coince pas. Ton idée de tables intermédiaires est certainement à creuser, j'y réfléchis. L'idéal serait d'avoir à ajouter les étiquettes au fur et à mesure qu'on en a besoin au niveau du formulaire principal F_ACTION, par un bouton par exemple ?, sans être obligé de prévoir ce maximum de 20 qui alourdit tout mon travail... Mais pour ça, j'ai pas trouvé d'astuce... Merci encore.
Utilisateur anonyme
26 oct. 2016 à 00:41
26 oct. 2016 à 00:41
Re,
une table "étiquette" avec toutes les produits différents (donc pas de limite à 255), et une table ligne_devis (avec num_client, num_devis, etiquette) ferait l'affaire
une table "étiquette" avec toutes les produits différents (donc pas de limite à 255), et une table ligne_devis (avec num_client, num_devis, etiquette) ferait l'affaire
Utilisateur anonyme
Modifié par HDU le 26/10/2016 à 01:10
Modifié par HDU le 26/10/2016 à 01:10
Et, dis moi, le champ détail est lié à quoi ?
Au type ? A la gamme ? Au fournisseur ? A la famille ? Aux quatre ?
A+
PS : je suis en train de refaire ta base, mais il me faut cette info
Quand Jimmy dit What'd I say
I love you baby
C'est comme qui dirait
Toute la province qui chante en anglais
Au type ? A la gamme ? Au fournisseur ? A la famille ? Aux quatre ?
A+
PS : je suis en train de refaire ta base, mais il me faut cette info
Quand Jimmy dit What'd I say
I love you baby
C'est comme qui dirait
Toute la province qui chante en anglais
jeanlouismaso
Messages postés
4
Date d'inscription
lundi 24 octobre 2016
Statut
Membre
Dernière intervention
26 octobre 2016
26 oct. 2016 à 08:54
26 oct. 2016 à 08:54
Salut, le champ détail est le seul qui est unique dans la table ETIQUETTES et qui caractérise vraiment le produit, il dépend des 4 autres. De plus il peut être modifié au dernier moment avant l'impression du devis parce que nous travaillons vraiment "sur mesure" et chaque produit que nous sortons est unique lui aussi et vraiment différent d'un client à l'autre.
Ton idée d'une seule table ETIQUETTES avec les détails et les mesures (mes tables PRODUITS distinctes) ensemble est séduisante ! ça allègerait le tout avec seulement 20 tables au lieu de 40, il suffirait de rajouter le Numéro d'étiquette et son détail ainsi que le Numéro de l'Action correspondante dans les tables PRODUITS1, 2,... qui remplaceraient en les renommant les tables ETIQUETTES1, 2... Je vais essayer ça rapidement !!! Merci !!
Ton idée d'une seule table ETIQUETTES avec les détails et les mesures (mes tables PRODUITS distinctes) ensemble est séduisante ! ça allègerait le tout avec seulement 20 tables au lieu de 40, il suffirait de rajouter le Numéro d'étiquette et son détail ainsi que le Numéro de l'Action correspondante dans les tables PRODUITS1, 2,... qui remplaceraient en les renommant les tables ETIQUETTES1, 2... Je vais essayer ça rapidement !!! Merci !!
