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
Bonjour, j'ai créé un formulaire qui permet d'imprimer un devis à partir d'articles spécifiques entrés dans des sous-formulaires. L'activité étant très spécifique, il peut y avoir jusqu'à 30 articles différents dont la description peut être très longue avec des mesures, des quantités et des prix très variés également qui m'ont obligé à créer des tables et des requêtes bien séparées et reliées les unes au autres. J'ai donc dû créer 30 sous-formulaires, 1 par article possible. Mon problème est que si le devis ne fait apparaître que 2 ou 3 articles, mon formulaire affiche et imprime également tous les sous-formulaires vierges jusqu'à arriver au total général. Et donc, comment faire pour faire "sauter" les sous-formulaires vides, pour qu'ils ne s'affichent pas et que le formulaire n'imprime que le nombre d'articles renseignés ? A part cela, le moteur de la base et tous les autres éléments dont j'ai besoin fonctionnent parfaitement. Merci d'avance.

8 réponses

Utilisateur anonyme
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+
0
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
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.
0
Utilisateur anonyme
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+
0
Utilisateur anonyme
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 ?
0

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
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.
0
Utilisateur anonyme
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
0
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
0
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
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 !!
0