Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre du Club
    Bonjour,

    Après un weekend end chargé, j'ai effectué les modifications concernant le MCD.
    Et j'ai quelque questions.
    MCD:

    Je me retrouve donc avec une boucle au niveau de mon entité exemplaire.
    et je me pose une question sur la cardinalité entre Exemplaire-----[1,1]-----Concerner-------[1,n]-------Location.
    J'ai mis [1,1] mais je pense avoir mal réfléchit. En effet un exemplaire ne concerne qu'une et une seul location à un instant t (ou pas) mais au sein de la base, il y aura pas mal de location prévisionnelle et donc il vaudrait mieux mettre [1,n].
    Que pensez vous du modèle ? J'ai même séparer l'entité Constructeur et Modele de mon Article

    Concernant le planning ( en référence à mes premiers postes) est ce que vous auriez des conseilles concernant la gestion des dates ?
    Pour l'instant je ne récupère que le nombre de dispo par jour et par appareil et je ne suis pas sur de la méthode.

  2. #22
    Expert éminent sénior
    Bonjour,

    Très rapidement faute de temps, il faut modéliser

    [EXEMPLAIRE] 0,n --- concerner --- 1,? [LOCATION]


    Mini zéro coté exemplaire, car un exemplaire peut exister sans jamais avoir été loué (nouveau produit par exemple)
    Maxi zéro car un exemplaire peut être loué successivement plusieurs fois

  3. #23
    Membre du Club

    Mini zéro coté exemplaire, car un exemplaire peut exister sans jamais avoir été loué (nouveau produit par exemple)
    Merci pour la nuance.
    Maxi zéro car un exemplaire peut être loué successivement plusieurs fois
    Minimum 0 et maxi 0 ? Je suis pas sur de saisir, plutôt n ?

  4. #24
    Expert éminent sénior
    Citation Envoyé par LecGaël Voir le message

    R002a: Une Location concerne qu'un et un seul article à la fois
    R002b : Un Article peut être concerné par 0 ou plusieurs locations
    Du coup, vous confirmez qu'une location ne concerne qu'un seul article, mais qu'il peut y avoir plusieurs exemplaires de cet article (comme l'autorise votre MCD ?)
    exemple : location de 5 multimètres => OK, location d'un multimètre et d'une perceuse => KO ?

  5. #25
    Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Du coup, vous confirmez qu'une location ne concerne qu'un seul article, mais qu'il peut y avoir plusieurs exemplaires de cet article (comme l'autorise votre MCD ?)
    exemple : location de 5 multimètres => OK, location d'un multimètre et d'une perceuse => KO ?
    Absolument ! je le jure !

  6. #26
    Membre du Club
    Bonjour à tous ,
    Je sens que j'approche du but, j'ai rempli mes tables etc, j'ai modifié quelques requêtes et ça commence à ressembler à quelque chose.
    J'ai cependant encore quelques questions concernant le point le plus important de mon projet.


    Concernant le MCD:
    J'aimerais faire un historique des locations: Est t'il préférable d'avoir un attribut BOOL "rendu" dans location permettant de filtrer les locations (normalement finies et rendues) pour faire un historique.
    Ou alors un trigger qui stock les locations dans une autre table ?

    Concernant le planning, est t'il possible en SQL de détecter les périodes de chevauchements de locations et le nombre d'exemplaire concerné afin de faire des réservations ?

    Voici comment je procède actuellement:

    Prenons le scénario : Un utilisateur consulte la page des multimètres, il veut en louer 3 exemplaires (sur les 5 ) du 30/06/2020 au 30/07/2020. Je voudrais dans un premier temps pouvoir "diriger" la sélection de l'utilisateur et donc récupérer les dates de dispos pour une location de 3 exemplaires. Ce serait à l'étape d'initialisation de la page.
    Ensuite une fois la période saisie, je veux vérifier que celle-ci soit encore valable.
    Donc pour l'instant je récupère la date de début et la date de fin. Je reconstruit un tableau de jours entre les deux. Pour chaque jours je fais une requête qui retourne le nombre d'exemplaire de disponible avec une validation, si ma requête retourne un tableau avec 3 éléments ce jour alors je continue sinon false => et je déroule la tambouille du "ladate n'est plus dispo RAFRAICHIT TA PAGE !.(Plus poliment bien évidemment )

    Voila pour l'instant comment je déroule la logique, mais cela me parait lourd côté requête. Si un utilisateur sélectionne une période de 2 mois il faut balancer entre 60 et 62 requêtes (une par jour).

  7. #27
    Expert éminent sénior
    Citation Envoyé par LecGaël Voir le message
    Merci pour la nuance.

    Minimum 0 et maxi 0 ? Je suis pas sur de saisir, plutôt n ?
    Bien sûr , j'aurais dû me relire

  8. #28
    Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Bien sûr , j'aurais dû me relire
    C'est surtout que vu mon niveau, je me suis dit, "C'est peut être une astuce de big boss"

  9. #29
    Membre du Club
    Bonjour !

    Après révisions du modèle avec le client:

    Les règles:
    R005a: Une Etagère se situe dans une et une seule Armoire.
    R005b: Une Armoire contient 0 ou plusieurs Etagères

    Ont changées en

    R005a: Une Etagère se situe dans 0 ou plusieurs Armoires.
    R005b: Une Armoire contient 0 ou plusieurs Etagères

    En effet nous avons des noms d'étagères similaires d'une armoire à l'autre. Ce sont les règles du 5S.
    Donc si je ne me trompe pas cela donne: Armoire------[0,n]------Avoir-------[0,n]-----Étagère.

    Une relation [0,n] donne donc une table intermédiaire entre les deux qui va lier les id_etagere avec les id_armoire.
    Pour l'instant je devrais avoir 30 étagères maximum dans ma table.

    Qu'en pensez vous ? Est-ce dangereux de procéder de la sorte ?

    Pour ce qui est de ma question concernant la gestion de mes requêtes SQL pour mon planning, devrais-je ouvrir un nouveau sujet dans la rubrique SQL ?

    Bonne journée

    ===================================================================================================
    EDIT:
    ===================================================================================================

    Finalement ce que j'ai écris plus haut ne correspondait pas: il ne répond pas au besoin.
    Il faut que je reste sur le fait qu'une étagère est une entité physique présente que dans une seule armoire en revanche les étagères peuvent avoir le même nom.
    J'opterais donc pour une table d'association Position entre Etagères et Armoires pour faire la composition des différentes armoires avec les étagères mais au niveau MLD cette table aurait un id_unique qui sera associé à l'article en question.


    Position
    id_position id_armoire id_etagere


    Je n'arrive pas a le modéliser en MCD avec JMerise.

    Il y a eu du changement au niveau de mes règles des gestions également:

    R001a: Un User peut Faire 1 à n Location(s)
    R001b: Une Location est effectuée par un et un seul User

    R002a: Un Article possède 0 à n Exemplaires.
    R002b: Un Exemplaire concerne 1 et 1 seul Article.

    R003a: Une Location concerne qu'un et un seul Exemplaire d'article à la fois
    R003b : Un Exemplaire peut être concerné par 0 ou plusieurs locations


    R004a: Un Article appartient à un seul Sous-ensemble
    R004b : Un Sous-ensemble concerne un ou plusieurs Articles.

    R005a: Un Article se situe sur une et une seule Etageres
    R005b: Une Étagère "contient" 0 ou plusieurs Articles

    R006a: Une Etagère se situe dans une et une seule Armoire.
    R006b: Une Armoire contient 0 ou plusieurs Etagères

    R007a: Une Location débute à un et un seul jours du Calendrier
    R007b: Le Calendrier contient 0 ou plusieurs Locations.

    R008a: Une Location finit à un seul jour du Calendrier.
    R008b: Le Calendrier contient 0 ou plusieurs Locations.

    Le but maintenant est d'avoir un planning individuel par exemplaire, un utilisateur doit pouvoir choisir l'exemplaire qu'il souhaite réserver, par contrainte technique (marge d’erreur de l'appareil qui doit rester la même, etc)

  10. #30
    Expert éminent sénior
    Bonjour LecGaël

    Désolé pour mon manque de disponibilité, je reviens sur ce dernier message.

    Citation Envoyé par LecGaël Voir le message
    Il faut que je reste sur le fait qu'une étagère est une entité physique présente que dans une seule armoire en revanche les étagères peuvent avoir le même nom.
    Tout à fait, c'est essentiel


    Citation Envoyé par LecGaël Voir le message
    J'opterais donc pour une table d'association Position entre Etagères et Armoires pour faire la composition des différentes armoires avec les étagères mais au niveau MLD cette table aurait un id_unique qui sera associé à l'article en question.
    Inutile de se compliquer la vie. Il faut simplement considérer que l'étagère est ce qu'on appelle une entité-type faible : sans armoire, pas d'étagère.
    Dans ce type de cas, on applique l'identification relative : l'identifiant de l'armoire contribue à identifier l'étagère

    Au niveau du MCD ça se matérialise, selon le logiciel de modélisation par des parenthèses autour des cardinalités ou bien d'un R en suffixe de celles-ci.
    Par exemple : ARMOIRE 0,n --- posseder --- 1,1R ETAGERE

    Au niveau tabulaire, on trouve les tables suivantes (PK soulignées, FK suffixées #)
    AR_ARMOIRE(AR_ident, AR_attribut1, AR_attribut2, ...)
    ET_ETAGERE(AR_ident#, ET_ident, ET_attribut1, ET_attribut2...)
    On constate que la PK de ET_etagere comporte comme première colonne la FK AR_ident


    Par ailleurs, attention à ne pas renuméroter les règles de gestion (R005 est devenue R006), c'est un peu dangereux, on risque de s'y perdre : les précédents commentaires qui concernaient R005 concernent maintenant R006...
    Si des règles obsolètes sont supprimées, ne réutilisez pas les numéros de règles, peu importe
    Si de nouvelles règles surviennent, continuez en séquence la numérotation

    Citation Envoyé par LecGaël Voir le message
    Le but maintenant est d'avoir un planning individuel par exemplaire, un utilisateur doit pouvoir choisir l'exemplaire qu'il souhaite réserver, par contrainte technique (marge d’erreur de l'appareil qui doit rester la même, etc)
    Ca signifie que les caractéristiques concernées ne sont pas des attributs de l'article, mais de l'exemplaire (si c'est potentiellement différent pour chaque exemplaire), ou qu'il faut créer des articles différents.
    Ou encore, solution intermédiaire, créer des groupes de plages de caractéristiques et rattacher les exemplaires à ces groupes.


    également

    Citation Envoyé par LecGaël Voir le message

    Citation Envoyé par escartefigue Voir le message
    Du coup, vous confirmez qu'une location ne concerne qu'un seul article, mais qu'il peut y avoir plusieurs exemplaires de cet article (comme l'autorise votre MCD ?)
    exemple : location de 5 multimètres => OK, location d'un multimètre et d'une perceuse => KO ?
    Absolument ! je le jure !

    Citation Envoyé par LecGaël Voir le message

    R003a: Une Location concerne qu'un et un seul Exemplaire d'article à la fois
    R003b : Un Exemplaire peut être concerné par 0 ou plusieurs locations
    Cette règle de gestion est moins claire que ce qui ressort de nos échanges précédents, je propose la reformulation suivante :
    R003a : une Location concerne 1 seul Article, pour un à plusieurs Exemplaires de cet Article.
    R003b : un Exemplaire peut être concerné par 0 ou plusieurs Locations

  11. #31
    Membre du Club
    Bonjour

    Désolé pour mon manque de disponibilité, je reviens sur ce dernier message.
    Pas de soucis, je me doutes que ce n'est pas une période facile, je poste au fur et a mesure de mes réflexions




    Inutile de se compliquer la vie. Il faut simplement considérer que l'étagère est ce qu'on appelle une entité-type faible : sans armoire, pas d'étagère.
    Dans ce type de cas, on applique l'identification relative : l'identifiant de l'armoire contribue à identifier l'étagère

    Au niveau du MCD ça se matérialise, selon le logiciel de modélisation par des parenthèses autour des cardinalités ou bien d'un R en suffixe de celles-ci.
    Par exemple : ARMOIRE 0,n --- posseder --- 1,1R ETAGERE

    Au niveau tabulaire, on trouve les tables suivantes (PK soulignées, FK suffixées #)
    AR_ARMOIRE(AR_ident, AR_attribut1, AR_attribut2, ...)
    ET_ETAGERE(AR_ident#, ET_ident, ET_attribut1, ET_attribut2...)
    On constate que la PK de ET_etagere comporte comme première colonne la FK AR_ident
    Du fait que AR_ident#, ET_ident compose la "clef" primaire de l'entité Etagere ça assure donc qu'il n'y ai pas deux fois la même étagère dans une seule et même armoire ! Mais c'est génial et quand on y pense c'est super logique (Mais il faut y penser )
    Je n'ai pas trouvé l'option sur JMerise pour modéliser ce type d'entité, je vais me pencher vers Looping.


    Par ailleurs, attention à ne pas renuméroter les règles de gestion (R005 est devenue R006), c'est un peu dangereux, on risque de s'y perdre : les précédents commentaires qui concernaient R005 concernent maintenant R006...
    Si des règles obsolètes sont supprimées, ne réutilisez pas les numéros de règles, peu importe
    Si de nouvelles règles surviennent, continuez en séquence la numérotation
    Je ferais attention dans le futur .


    Ca signifie que les caractéristiques concernées ne sont pas des attributs de l'article, mais de l'exemplaire (si c'est potentiellement différent pour chaque exemplaire), ou qu'il faut créer des articles différents.
    Ou encore, solution intermédiaire, créer des groupes de plages de caractéristiques et rattacher les exemplaires à ces groupes.

    En fin de compte l'entité Article peut rester telle quelle je pense:
    Exemple: L'article multimètre FLUKE, j'en possède trois exemplaires. l'article contient toujours de l'information sur l'exemplaire.
    Finalement l'entité exemplaire contiendra juste une désignation_inventaire (une étiquette avec un numéro unique est collée sur l'appareil pour que l'opérateur ne se trompe pas lors de l'emprunt.)

    Une légère modification de la règle R003a qui répondrait exactement à mon besoin:


    R003a : une Location concerne 1 seul Article, pour un et un seul Exemplaires de cet Article.
    R003b : un Exemplaire peut être concerné par 0 ou plusieurs Locations

    On me demande qu'une location ne concerne qu'un seul article. Après j'ai du mal a faire la distinction entre ce que j'imagine côté IHM WEB/programmation et la base de données.
    La façon de penser est bien différente parfois

    EDIT

    J'ai effectivement réussi avec Looping

    En revanche je me pose la question de conserver l'entité Article , car finalement les association qui concerne l'entité Article peuvent très bien concerner les exemplaires de la mêmes façon.
    Je peux très bien considérer les exemplaires comme des "Article" avec une désignation_inventaire unique (comme une seconde clef primaire).
    Je manque de recul là ^^"

  12. #32
    Expert éminent sénior
    Citation Envoyé par LecGaël Voir le message
    Du fait que AR_ident#, ET_ident compose la "clef" primaire de l'entité Etagere ça assure donc qu'il n'y ai pas deux fois la même étagère dans une seule et même armoire ! Mais c'est génial et quand on y pense c'est super logique (Mais il faut y penser )
    Je n'ai pas trouvé l'option sur JMerise pour modéliser ce type d'entité, je vais me pencher vers Looping.
    Avec looping, à partir du moment où la cardinalité est 1,1, une case à cocher "identifiant relatif" est proposée



    Citation Envoyé par LecGaël Voir le message

    Une légère modification de la règle R003a qui répondrait exactement à mon besoin:
    R003a : une Location concerne 1 seul Article, pour un et un seul Exemplaires de cet Article.
    R003b : un Exemplaire peut être concerné par 0 ou plusieurs Locations

    On me demande qu'une location ne concerne qu'un seul article.
    Du coup c'est en contradiction avec nos nos échanges n°24 et 25...

  13. #33
    Membre du Club

    Du coup c'est en contradiction avec nos nos échanges n°24 et 25...
    Oui j'ai présenté une maquette de mon outil ce matin et il y a eu beaucoup de remontés, de suggestions etc.
    Et effectivement c'est une modification à faire.

    ===========================================
    EDIT
    ===========================================

    Pour symboliser ma question deux MCD fait avec looping.
    Avec Article:


    Sans Article:

  14. #34
    Expert éminent sénior
    Je ne vois aucune différence entre les deux MCD

  15. #35
    Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Je ne vois aucune différence entre les deux MCD
    C'est normal, c'est bibi qui est c**

    J'ai modifié sur le post.

  16. #36
    Expert éminent sénior
    bonjour,

    Quelques nouvelles (ou pas ) remarques


    Cohérence entre les règles de gestion et les noms d'associations
    Les verbes utilisés dans les règles de gestion doivent se retrouver dans les noms d'associations, sans quoi on s'y perd un peu
    Par exemple, vous rédigez
    R006a : Une Etagère se situe dans une et une seule Armoire.
    R006b : Une Armoire contient 0 ou plusieurs Etagères
    Et l'association s'appelle composer

    à modifier ainsi :
    R006a : Une Etagère est contenue dans une et une seule Armoire.
    R006b : Une Armoire contient 0 ou plusieurs Etagères
    et l'association devient "contenir"

    Il n'est pas toujours facile de trouver des noms pertinents pour les assos. "etre" et "avoir" par exemple sont assez peu précis.
    La bonne nouvelle est que les associations dont une patte au moins a une cardinalité maxi de 1 ne deviennent pas des tables, du coup on peut s'économiser l'effort de rechercher un nom parlant et laisser un nom laconique tel que "asso1", "asso2"...
    Par contre ça ne vous autorise pas à oublier les règles de gestion de ces assos. Celles là comme les autres doivent être rédigées



    Entités-type MODELE, ARTICLE et EXEMPLAIRE
    Je pense que ce vous appelez MODELE est ce que j'avais compris comme étant l'article.
    Auquel cas ces deux entité-type ne font qu'un en effet.



    Entité-type ROLE
    Il n'y a aucune règle de gestion concernant les rôles.
    Un utilisateur peut il avoir plusieurs rôles, aucun rôle, changer de rôle ? à préciser



    Association concerner
    un utilisateur qui veut louer le même jour un multimètre et une perceuse devra donc souscrire deux contrats de location.
    Pourquoi pas, mais à bien faire valider par vos experts métier.



    Entité-type CATEGORIE
    Il n'y a aucune règle de gestion concernant les catégories.
    Que réprésente une catégorie ? S'agit il de modéliser des groupes de plages de caractéristiques comme je l'avais proposé hier (réponse n° 30) ?
    Donnez des exemples de catégories pour plus de clarté.



    Association localiser
    La cardinalité 1,1 coté exemplaire ne va pas : quand un exemplaire est en location, il n'est sur aucune étagère
    Profitez-en pour reformuler la règle R005 puisque l'article disparaît



    Entité-type CONSTRUCTEUR
    N'est-ce pas plutôt le fournisseur qui vous intéresse, voire les deux ?
    Qu'est-ce que la date de création du constructeur ?



    D'une façon générale, il y a très peu d'attributs dans les types d'entité, à compléter.

  17. #37
    Membre du Club
    Bonjour

    Cohérence entre les règles de gestion et les noms d'associations
    Les verbes utilisés dans les règles de gestion doivent se retrouver dans les noms d'associations, sans quoi on s'y perd un peu
    Par exemple, vous rédigez
    R006a : Une Etagère se situe dans une et une seule Armoire.
    R006b : Une Armoire contient 0 ou plusieurs Etagères
    Et l'association s'appelle composer

    à modifier ainsi :
    R006a : Une Etagère est contenue dans une et une seule Armoire.
    R006b : Une Armoire contient 0 ou plusieurs Etagères
    et l'association devient "contenir"
    Effectivement c'est mieux



    Entités-type MODELE, ARTICLE et EXEMPLAIRE
    Je pense que ce vous appelez MODELE est ce que j'avais compris comme étant l'article.
    Auquel cas ces deux entité-type ne font qu'un en effet.
    Oui c'est pour ça, en fin de compte modele contiendra les caractéristique de l'appareil finalement.



    Entité-type ROLE
    Il n'y a aucune règle de gestion concernant les rôles.
    Un utilisateur peut il avoir plusieurs rôles, aucun rôle, changer de rôle ? à préciser
    En effet j'ai oublié d'en parler, il s'agit juste de rôle pour le site en question:
    R009a: Un Utilisateur possède un et un seul Rôle.
    R009b: Un Rôle peut concerner 0 ou n Utilisateurs.

    Il n'y aura que deux rôles, Admin et Utilisateur.


    Entité-type CATEGORIE
    Il n'y a aucune règle de gestion concernant les catégories.
    Que réprésente une catégorie ? S'agit il de modéliser des groupes de plages de caractéristiques comme je l'avais proposé hier (réponse n° 30) ?
    Donnez des exemples de catégories pour plus de clarté.
    Oui il s'agit de former des groupes pour filtrer les recherches tels que , Multimètres, Enregistreurs,Oscilloscopes,Ordinateurs,...


    Association concerner
    un utilisateur qui veut louer le même jour un multimètre et une perceuse devra donc souscrire deux contrats de location.
    Pourquoi pas, mais à bien faire valider par vos experts métier.
    Cela est normalement validé.



    Association localiser
    La cardinalité 1,1 coté exemplaire ne va pas : quand un exemplaire est en location, il n'est sur aucune étagère
    Profitez-en pour reformuler la règle R005 puisque l'article disparaît
    La localisation sert uniquement pour trouver l'appareil lorsque l'on veut le réserver. Après on se retourne vers la personne qui l'a emprunté.

    R005a: Un Exemplaire se situe sur une et une seule Etageres
    R005b: Une Étagère "contient" 0 ou plusieurs Exemplaires

    Entité-type CONSTRUCTEUR
    N'est-ce pas plutôt le fournisseur qui vous intéresse, voire les deux ?
    Qu'est-ce que la date de création du constructeur ?
    La table Constructeur et Modele servent à avoir plus d'informations sur l'appareil à titre informatif, je pourrais rajouter des champs en fonctions des retours des agents. Pour ce qui est des fournisseurs il me faudrait plutôt rajouter une entité fournisseur associé avec l'entité exemplaire, imaginons que l'on change de fournisseur en cours de route, les appareils conservent le même constructeur. Je l'ai gardé dans un coin de ma tête pour l'instant car ma suggestion n'a pas fait suite

    D'une façon générale, il y a très peu d'attributs dans les types d'entité, à compléter.
    Effectivement, mais l'objectif est de faire un site de réservation assez simpliste en soit. J'espère juste arriver à avoir un modèle maintenable et ouvert à l'amélioration.

  18. #38
    Expert éminent sénior
    Citation Envoyé par escartefigue Voir le message

    Cohérence entre les règles de gestion et les noms d'associations
    Les verbes utilisés dans les règles de gestion doivent se retrouver dans les noms d'associations, sans quoi on s'y perd un peu
    Par exemple, vous rédigez
    R006a : Une Etagère se situe dans une et une seule Armoire.
    R006b : Une Armoire contient 0 ou plusieurs Etagères
    Et l'association s'appelle composer

    à modifier ainsi :
    R006a : Une Etagère est contenue dans une et une seule Armoire.
    R006b : Une Armoire contient 0 ou plusieurs Etagères
    et l'association devient "contenir"


    Citation Envoyé par LecGaël Voir le message

    Effectivement c'est mieux

    [. . .]

    La localisation sert uniquement pour trouver l'appareil lorsque l'on veut le réserver. Après on se retourne vers la personne qui l'a emprunté.

    R005a: Un Exemplaire se situe sur une et une seule Etageres
    R005b: Une Étagère "contient" 0 ou plusieurs Exemplaires

    Oui mais non du coup , même combat ici : un même verbe à utiliser dans les deux sens de l'asso et dans le MCD
    Un même verbe ne pouvant pas être utilisé pour deux asso distinctes
    Et comme les règles de gestion doivent être le reflet de la stricte vérité, on doit bien avoir
    R005a: Un Exemplaire est localisé sur zéro à une Etagere
    R005b: Sur une Étagère sont localisés 0 à plusieurs Exemplaires

  19. #39
    Membre du Club
    Citation Envoyé par escartefigue Voir le message
    Oui mais non du coup , même combat ici : un même verbe à utiliser dans les deux sens de l'asso et dans le MCD
    Un même verbe ne pouvant pas être utilisé pour deux asso distinctes
    Et comme les règles de gestion doivent être le reflet de la stricte vérité, on doit bien avoir
    R005a: Un Exemplaire est localisé sur zéro à une Etagere
    R005b: Sur une Étagère sont localisés 0 à plusieurs Exemplaires
    Merci il faut que je m'y fasse