Discussion :

[fomy]

Bonjour à tous,
Je vous expose mon projet :
Alors voilà, à l'heure d'aujourd'hui nous gérons le stock matériel et son attribution grâce à une feuille Excel, c'est pas top, mais efficace
Maintenant, je souhaite mettre tout ca sous Access, j'ai déjà développé en amateur plusieurs bases (gestion des arrivées de nouveaux collaborateurs, Gestion des commandes de matériel) mais là je me sens dépassé par le niveau nécessaire à ce développement, je vous demande donc humblement votre aide afin de réaliser cette base. Cela Pourrat donner naissance à une base open-source Je précise qu'il faut que ce développement ce fasse sous Access Xp (2002)
J’ai beaucoup cherché sur ce sujet mais rien ne correspond finalement à mon besoin, mais j'ai bizarrement lu des dizaines de postes (sur pas mal de forum) ou ce type de base était recherché....

Ci-dessous mon premier problème rencontré :
J’ai une liste de site correspondant aux sites ou les utilisateurs sont installés.
Cette liste contient actuellement 4 sites : site geo1, site geo2, site geo3, site geo4
Dans les tables "base_ecran", "base_impr", "base_pc" il y a un champ état dans lequel il y un choix à faire parmi
"installé / en panne / en stock site geo1 / en stock site geo2 / en stock site geo3 / en stock site geo4".
Le problème est dans les choix en stock …..
Comment avoir une liste de choix hybride, qui contient à la fois des valeurs pré-renseignées (installé / en panne) et en plus une extraction de la table "liste_site" à laquelle on ajoute un préfix "en stock_" !!! De plus, il faut que cette liste ce mette à jour automatiquement en fonction de ma liste de site, c-a-d que si un nouveau site est ajouté / ou supprimé dans la table "liste_site", cela ce répercute dans la liste des états possible en stock ???

D'avance encore merci de votre aide à tous

Vous trouverez ci-joint le cahier des charges et les relations actuellement mise en place entre les bases ainsi que la base:

Ps : toutes remarques est bienvenue, je ne suis pas sur d'avoir choisi une conception qui soit la plus efficace

Derniere MAJ : Le 31/03/2008 20:42

Liste des posts ouverts pour ce projet :
RESOLU select dans formulaire
RESOLU transformation lignes multiples vers colonne
RESOLU Insertion info formulaire indépendant dans table
RESOLU Variable publique dans requête
RESOLU Imbriquer deux requetes SQL
RESOLU mise à jour "en cascade"
RESOLU Affichage formulaire consécutif
RESOLU resultat requete dans variable texte
RESOLU info feuille de données
RESOLU Left join sur requete

[Ataturk]

Bonjour,

Pour ton premier soucis, pourquoi ne pas dissocier le paramètres d'état (Instal, Out, Stock) et le paramètres géographique ?

Cela ne simplifirai-t-il pas grandement tes traitements ?

[fomy]

Oui effectivement cela devrait simplifier les choses
je modifie les fichiers joints ds le premier post

[Ataturk]

Euh plutot que de liée chaque base à une site lie plutot le regroupement d'élément "Table_Princ" au site.

Mais n'as tu pas le cas d'une personne ayant 1 ou n configuration de postes ? Cas d'un commercial sans PC portable ?)

[fomy]

tu veux dire ajouter le champ site dans la table_princ et le lié a la liste site ?
quel est l'interet stp ?

Oui j'ai des utilisateurs (pas de commerciaux) ayant plusieurs bureaux avec plusieurs pc's / ecrans / imprimantes

Edit : heu en fait je crois que j'ai compris, il faut que ce soit la "configuration" (utilisateur + PC + ecran + imprimante) qui est un bureau / site car l'utilisateur peut avoir plusieurs bureaux / pc etc ???

[Ataturk]

Reponse à l'edit Oui c'est ça

Comment tu gères :

• un écran sur le site geo1
• une imprimante sur site geo2

mais entrant dans la même configuration ?

J'aurais fait de la manière suivante (pas forcement la bonne)

Table_princ :

• N°
• User
• Pc
• Impr
• ecran
• Site

ça permet de gérer une config/Site mais plusieurs config/User.

Reste alors le problème de stockage si le matériel n'est pas affecté.
Sauf si dans le cas d'une affectation à une configuration, il y a mise à jour auto :
Du site géo

• graphique de stockage avec le site de la configuration.
• Modification de l'état (Stock -> Instal)

Dans ce cas on peux garder l'info de site dans chaque PC,Imp ou écran.

Pourquoi ne pas avoir créé une table unique pour PC,Imp ou écran ?

Table_El :

• N°Immo
• N°Series
• DateAchat
• Etat
• Site
• Model_PC
• Model_Imp
• Model_Ecran

[loufab]

Bonjour,

Plusieurs remarques :

Tu dissocies les n° immo du matériel. D'un point de vue comptable 1 matériel = 1 N° d'immo (il s'agit peut-être d'un N° d'identification les immo c'est différent attention). Pourquoi mettre ça dans une table séparée ?

Si 1 utilisateur possède plusieurs machines alors il faut une table intermédiaire.

A aucun moment on ne voie un PC rattaché à un écran... vos écrans sont nomades, vous vous les échangez ?

idem pour les types d'imprimantes, modele de pc et modele d'écran... si c'est pour alimenter des listes c'est un peu lourd, on peut facilement alimenter des listes avec les propres infos du champ.

Je ne vois pas trop l'interet d'une base user qui n'a pas de lien avec un matériel.

Au niveau information : N° IP, gestion des licences, les autres matériels (hub, routeur, scanner...), gestion de garantie mais sans le matériel rattaché au poste (écran, souris, clavier... ça aussi c'est garantie)

En bref il faut revoir sérieusement ton analyse des données avant de commencer, tu risques de te retrouver bloqué ou de devoir monter une usine à gaz à chaque fois que tu veux extraire des infos.

cordialement,

[fomy]

Comment tu gères :

• un écran sur le site geo1
• une imprimante sur site geo2

mais entrant dans la même configuration ?

Aujourd'hui j'ai une feuille excel avec les colonnes suivantes :
Nom | prénom | UID | Equipe | site | bureau | N°d'immoPC | N°seriePC | TypePC | ModelPC | N°d'immoImpr | N°serieImpr | ModelImpr | N°d'immoEcran | N°serieEcran | ModelEcran
donc un utilisateur ayant plusieurs machines ou / et plusieurs bureaux a tout simplement plusieurs lignes dans le fichiers Excel

J'aurais fait de la manière suivante (pas forcement la bonne)

Table_princ :

• N°
• User
• Pc
• Impr
• ecran
• Site

ça permet de gérer une config/Site mais plusieurs config/User.

c'est la modif que je viens d'apporter suite à ta précedente remarque

Reste alors le problème de stockage si le matériel n'est pas affecté.
Sauf si dans le cas d'une affectation à une configuration, il y a mise à jour auto :
Du site géo

• graphique de stockage avec le site de la configuration.
• Modification de l'état (Stock -> Instal)

Dans ce cas on peux garder l'info de site dans chaque PC,Imp ou écran.

je saisis pas bien le probleme

Pourquoi ne pas avoir créé une table unique pour PC,Imp ou écran ?

Table_El :

• N°Immo
• N°Series
• DateAchat
• Etat
• Site
• Model_PC
• Model_Imp
• Model_Ecran

je trouvais plus logique d'avoir plusieurs tables car cela me permet d'avoir une obligation de remplir le champ model

[Ataturk]

Tu dissocies les n° immo du matériel. D'un point de vue comptable 1 matériel = 1 N° d'immo (il s'agit peut-être d'un N° d'identification les immo c'est différent attention). Pourquoi mettre ça dans une table séparée ?

Je comprends pas ce paramètre

Si 1 utilisateur possède plusieurs machines alors il faut une table intermédiaire.

Ne peut-on pas gerer 1 User pour N config avec 2 tables ?

Sauf si on fait N user pour N config seulement dans le cas une une config servirait à plusieur User

A aucun moment on ne voie un PC rattaché à un écran... vos écrans sont nomades, vous vous les échangez ?
idem pour les types d'imprimantes, modele de pc et modele d'écran... si c'est pour alimenter des listes c'est un peu lourd, on peut facilement alimenter des listes avec les propres infos du champ.
Je ne vois pas trop l'interet d'une base user qui n'a pas de lien avec un matériel.

Si, il ratache tout cela dans sa Table_princ

Au niveau information : N° IP, gestion des licences, les autres matériels (hub, routeur, scanner...), gestion de garantie mais sans le matériel rattaché au poste (écran, souris, clavier... ça aussi c'est garantie)

D'ou le regroupement proposé du type :

Table_El :

* N°Immo
* N°Series
* DateAchat
* Etat
* Site
* Model_PC
* Model_Imp
* Model_Ecran

Car cela permettait de rajouté des paramètres (IP, date de fin garantie...)



@ Fomy : Faute de frappe...

Reste alors le problème de stockage si le matériel n'est pas affecté.
Sauf si dans le cas d'une affectation à une configuration, il y a mise à jour auto :

• Du site géographique de stockage avec le site de la configuration.
• Modification de l'état (Stock -> Instal)

Je voulais dire que tant que ton matériel n'est pas dans une config, tu doit pouvoir le situé geographiquement. Et que lorsque que tu l'affecte à une config les param (Statut et geo) se mettent à jour en fonction de la configuration

je trouvais plus logique d'avoir plusieurs tables car cela me permet d'avoir une obligation de remplir le champ model

Gère ça avec le formulaire

[fomy]

Bonjour,

Plusieurs remarques :

Tu dissocies les n° immo du matériel. D'un point de vue comptable 1 matériel = 1 N° d'immo (il s'agit peut-être d'un N° d'identification les immo c'est différent attention). Pourquoi mettre ça dans une table séparée ?

non ils ne sont pas (ou ne devrait pas) etre séparés
j'ai une table dans laquelle sont par exemple les pc's (1N° de serie a 1N° d'immo) un pc = effectivement un N° d'immo (étiquette qui est colée sur le matériel)et c'est son identifiant unique & définitive.

Si 1 utilisateur possède plusieurs machines alors il faut une table intermédiaire.

c'est ce que je pensais avoir fait avec la table "Table_prin"
on y rassemble toutes les attributions utilisateurs - matériel

A aucun moment on ne voie un PC rattaché à un écran... vos écrans sont nomades, vous vous les échangez ?

Heu je ne comprends pas, effectivement lors d'un déménagement utilisateur, l'écran reste le plus souvent sur place, il n'est de ce point de vue pas rataché au pc (c'etait ça la question ??? )

idem pour les types d'imprimantes, modele de pc et modele d'écran... si c'est pour alimenter des listes c'est un peu lourd, on peut facilement alimenter des listes avec les propres infos du champ.

ca me semblait etre la solution la plus simple au vu des changements régulier de la gamme matériel dans la boite ou je suis

Je ne vois pas trop l'interet d'une base user qui n'a pas de lien avec un matériel.

c'est normalement le role de la base table_prin

Au niveau information : N° IP, gestion des licences, les autres matériels (hub, routeur, scanner...), gestion de garantie mais sans le matériel rattaché au poste (écran, souris, clavier... ça aussi c'est garantie)

pas de gestion du "petit matériel" disons que cela est considéré comme du consomable PAs de gestion non plus des Ip's ou des licences applicatives. Par contre effectivement je gere le renouvellement du parc d'ou la date d'achat dans les tables

En bref il faut revoir sérieusement ton analyse des données avant de commencer, tu risques de te retrouver bloqué ou de devoir monter une usine à gaz à chaque fois que tu veux extraire des infos.

cordialement,

Merci pour ton aide, mais au vue de mes réponses, cela est-il toujours d'actualité ?

[fomy]

@ Fomy : Faute de frappe...
Je voulais dire que tant que ton matériel n'est pas dans une config, tu doit pouvoir le situé geographiquement. Et que lorsque que tu l'affecte à une config les param (Statut et geo) se mettent à jour en fonction de la configuration
Gère ça avec le formulaire

Ok, c'est effectivement comme ca que je perçois la chose
que pense tu de ma remarque concernant le fait de rassembler tt le matériel dans une seule et unique table ? est-ce vraiment indispensable ? je ne pourrais alors pas controler le fait que le champ model soit bien renseigné
et puis j'ai peur d'avoir une table énorme (j'ai 600 utilisateur qui ont au minimum un pc / imprimante / ecran voir plus)

[Ataturk]

Disons que regrouper PC, Ecran, Imprimante dans la même table va effectivement te donner un table assez volumineuse. Mais à part le type de matériel, beaucoup d'autres paramètres vont être commun (Garantie, Geographie...).

De plus, cela facilitera le traitement des stocks.

[fomy]

Disons que regrouper PC, Ecran, Imprimante dans la même table va effectivement te donner un table assez volumineuse. Mais à part le type de matériel, beaucoup d'autres paramètres vont être commun (Garantie, Geographie...).

De plus, cela facilitera le traitement des stocks.

Ok, je m'y colle

[fomy]

Bon je suis en train de recréer la table contenant le matériel "base_mat", j'ai aussi remplacer les tables model_pc/impr/ecran par "model_mat", qui regroupe elle aussi le tout.
elle a deux colonnes :
type | model

La table "base_mat" contient les champs suivants :
N° (NuméroAuto)
Num_immo (texte)
Num_serie (texte)
type (texte)
le type est une liste déroulante dont le contenu est extrait de la table model_mat.type en faisant un regroupement
cela me donne la commande sql suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT model_mat.type FROM model_mat GROUP BY model_mat.type;

model (texte)
là je voudrais mettre une commande sql qui me donne la liste des models de la table model_mat dont le type correspond au choix fait dans la précédente colonne(type):
mais rien y fait je n'y arrive pas !!!
j'ai essayé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT model_mat.model FROM model_mat WHERE ((base_mat.type)=model_mat.type);

mais j'obtiens une fenetre me demandant d'entrer la valeur base_mat.Type si je la rentre manuellement dans cette fenetre, cela fonctionne;

date_d'achat (texte)
etat (texte)
site (texte)

Pouvez vous m'aider sur cette requete ?

[Ataturk]

Dans le champ type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT model_mat.type FROM model_mat GROUP BY model_mat.type;

Dans le champ model :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT model_mat.model FROM model_mat INNER JOIN base_mat ON model_mat.type=base_mat.type;

[fomy]

Dans le champ type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT model_mat.type FROM model_mat GROUP BY model_mat.type;

Dans le champ model :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT model_mat.model FROM model_mat INNER JOIN base_mat ON model_mat.type=base_mat.type;

Bonjour Ataturk,
Désolé pour le délai
Mais j'ai pas mal de travail et celui ci va surement durer un petit moment
Bon, concernant ta solution, je l’avais déjà essayé mais le problème est qu'il faut que je ferme la table et la ré-ouvre afin que cela soit fonctionnel (requery ?)!!!
Je crois que je verrais cela dans les formulaires devant remplir la table.

[fomy]

Petite mise à jour de la base (fichier zip)
J’ai commencé à créer les formulaires, mais je commence surtout à avoir l'impression qu'il y a des obstacles insurmontables...
Je reviens ici très vites...

[fomy]

Bonsoir a tous,
je rencontre un soucis.
je n'arrive pas dans un formulaire à récupérer le nom correspondant à un uid
pour rappel cf base jointe, la table "base_user" contient nottament :
UID | Nom | Prénom

au chargement de ce formulaire, j'ai le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
Private sub Form_open(cancel as integer)
dim UID as string
If guid = "" Then
DoCmd.close
DoCmd.openForm "entreruid"
Else
Me.UID = guid
End If
 
End Sub

Le probleme est que j'essaye de récuperer le nom correspondant à l'uid (guid)
dans la table base_user !
J'essaye donc de mettre dans la propriété source controle d'un text box nomé fuid de mettre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select base_user.nom from base_user where base_user.uid = me.fuid

mais le résultat est invariablement #NOM...
merci de votre aide

[fomy]

personne ?

PS: la derniere version de la base est mise a jour

[loufab]

Bonjour,

tu aurais plus de chance en postant dans le sous-forum VBA sous une nouvelle discussion.

Si ta demande de conception pure est terminé le Tag Résolu est obligatoire.

Cordialement,