Bonjour,
Je vous propose une piste de correction concernant la gestion des organisations.
PARTIE I - OBSERVATION DE L'EXISTANT
A - Analyse du traitement des appels d’offres.
A.1.1 - Un devis est-il établi pour chaque AO?
Non, car si l'AO ne peut être satisfait, en raison de la non faisabilité de produits spécifiques, seul un courrier est envoyé au client. L'opération conceptuelle "traitement AO en attente" démontre bien que seule la règle d'émission "réalisable" et le résultat "AO specifique accepté" enclenche une proposition commerciale se traduisant par la construction du devis.
A.1.2 - Quel(s) poste(s) intervienne(nt) avant l'envoi d'une lettre au client en cas de rejet d'un AO?
Par définition, un poste de travail est un centre d'activités disposant de ressources nécessaires pour réaliser un certain nombre de traitements. Dans le cas du traitement d'un AO, accepté ou refusé, les postes "administration des ventes" et "bureau d'études" interviennent respectivement avant l'envoi d'une lettre de rejet au client.
A.1.3 - Dans quelles conditions un devis peut-il être prêt le jour même de la réception d'un AO?
Pour qu'un devis puisse être traîté et prêt le jour même, il faut impérativement que l'AO fasse uniquement référence à des produits du catalogue.
B – Étude de l’application existante.
B.1.1 - Un AO peut-il concerné plusieurs produits?
Au regard des enregistrements de la table DETAIL AO, on peut affirmer qu'un AO peut concerner plusieurs produits.
A titre d'exemple, deux produits sous les références (code) Cr55 et Cs33 sont concernés par l'AO n°332.
B.1.2 - Un même client peut-il être à l'origine de plusieurs AO?
Au regard des enregistrements de la table DETAIL AO, on peut affirmer qu'un même client peut être à l'origine de plusieurs AO.
A titre d'exemple, le client Bou003 est à l'origine des AO n°332 et 335.
B.1.3 - Un contact est-il lié à un client ou un AO?
Au regard des champs des tables CLIENT et DETAIL AO, je constate que seule la table DETAIL AO contient le champ "contact".
Dans ce cas, un contact est lié à un AO.
B.1.4 - Une même famille peut-elle concerner plusieurs produits?
Au regard du champ LibelléFamille et des enregistrements liés dans la table PRODUIT, je constate qu'une même famille peut concerner plusieurs produits.
A titre d'exemple, la famille "plateaux" concerne les produits référencés Pl55 et Cg80.
B.2.1 - Remédier à la répétition d'une même valeur LibelléFamille dans la table PRODUIT?
Pour remédier à la répétition d'une même valeur de LibelléFamille associée à CodeFamille Dans la table PRODUIT, il faudrait :
- dans un premier temps supprimer le champ LibelléFamille et modifier l'intitulé du champ CodeFamille par CodeFamille#,
- dans un second temps créer une table FAMILLE (CodeFamille, LibelléFamille) et la mettre en relation avec la table PRODUIT par l'intermédiaire de la clé étrangère CodeFamille# exprimant alors une contrainte d'intégrité fonctionnelle (CIF).
Nous aurions le schéma suivant :
PRODUIT (CodeProduit, DésignationProduit, PrixBase, CodeFamille#)
FAMILLE (CodeFamille, LibelléFamille)
PRODUIT (1,1) ---- (CIF) ---- (1,n) FAMILLE
B.2.2 - Remédier à la répétition d'une même valeur DateAO, Contact et CodeCient dans la table DETAIL AO?
Pour remédier à la répétition d'une même valeur des champs précités, il faudrait :
- dans un premier temps les supprimer de la table DETAIL AO pour n'avoir DETAIL AO (NumAO, CodeProduit, QtéProduit, PrixTotalProposé). Cette table DETAIL AO ainsi modifiée aurait les caractéristiques d'une pseudo-entité (ou contrainte d'intégrité multiple (CIM)), dont les clés composées NumAO et Codeproduit seraient issues des clés primaires des tables AO et PRODUIT.
- dans un second temps créer une nouvelle table AO (NumAO, DateAO, CodeClient#, CodeContact#), ainsi DateAO, CodeClient# et CodeContact# seraient dépendantes de NumAO.
- dans un troisième temps créer une nouvelle table CONTACT (CodeContact, NomContact, PrénomContact).
Nous aurions alors le schéma suivant :
AO (NumAO, DateAO, NumClient#, CodeContact#)
CLIENT (NumClient, NomClient, ..., VilleClient)
CONTACT (CodeContact, NomContact, PrénomContact)
PRODUIT (CodeProduit, DésignationProduit, PrixBase, CodeFamille#)
DETAIL AO (NumAO, CodeProduit, QtéProduit, PrixTotalProposé)
CONTACT (1,n) ---- (CIF)---- (1,1) AO (1,1) ---- (CIF) ---- (1,n) CLIENT
AO (1,n) ---- (DETAIL AO) ---- (0,n) PRODUIT
B.3.0.0 - Établissez le schéma de données (entités - associations) qui permettrait de réaliser cettee application personnelle
CLIENT (1,n) ---- (CIF) ---- (1,1) AO (1,n) ---- (DETAIL AO) ---- (0,n) PRODUIT (1,1) ---- (CIF) ---- (1,n) FAMILLE
I
CONTACT (1,n) ---- (CIF) ---- (1,1) -I
NB : DETAIL AO contient des données porteuse d'information QtéProduit et PrixTotalProposé
PARTIE II - ÉTUDE DU MODULE COMMERCIAL DU FUTUR PGI
A - Vérification de l'adéquation du module de gestion des appels d'offres
A.1 - Indiquez les termes qui correspondent dans GPIX-COM aux notions produit, famille produit, appels d'offres, contact et devis.
a - la notion de PRODUIT (DésignationProduit), dans l'organisation interne d'ONDULEX, sera identifiée dans le futur module GPIX-COM, sous le terme d'ARTICLE (NomArticle).
b - La notion de FamilleProduit, dans l'organisation interne d'ONDULEX, sera identifiée dans le futur module GPIX-COM sous le terme de LibelléCat..
c - la notion d'Appels d'offres, dans l'organisation interne d'ONDULEX, sera identifée dans le futur module GPIX-COM sous les termes associés APPEL D'OFFRES et Concerner.
d - Nous savons que le technico-commercial, dans l'organisation interne d'ONDULEX, qui reçoit et traîte les appels d'offres attribue un contact chez le client. Nous retrouvons cette notion sous le terme de NomCorrespondant dans le futur module GPIX-COM.
e - Nous savons selon l'annexe 1 et le schéma de traitement que tout appel d'offres pouvant être satisfait en totalité, aboutit à l'établissement d'un devis. Nous retrouvons cette notion sous le terme d'OFFRE dans le futur module GPIX-COM.
A.2 - Vérifiez à partir de l'annexe 4 et en justifiant votre réponse que GPIX-COM permet de déteerminer le CA attendu d'une offre et le CA généré par la commande associée.
- Nous savons que le prix des articles d'une offre peut faire l'objet d'un ajustement (PrixUnitProposé). Nous savons aussi que chaque article d'une offre doit être quantifié (QtéDevis). En créant une requête basée sur un champ calculé de type
sum(QtéDevis*PrixUnitProposé) nous pourrons déterminer le CA attendu d'une offre.
- Nous savons que le prix (PrixUnitAccepté) des articles d'une commande correspond au prix (PrixUnitProposé) de l'offre associée. Nous savons aussi que la quantité (QtéCommandée) par article de la commande peut être égale ou différente de la quantité (QtéDevis) de l'offre. Malgré cela, en créant une requête basée sur un champ calculé de type sum(QtéCommandée*PrixUnitAccepté), nous pourrons déterminer le CA généré par la commande associée.
A.3 - Rédigez les requêtes qui donnent les résultats suivants :
A.3.1 - Liste des articles "standard" (NomArticle, PrixCatalogue) du catalogue appartenant à la catégorie dont le libellé est "Plateaux".
SELECT ARTICLE.NomArticle, CATALOGUE.PrixCatalogue
FROM CATALOGUE, ARTICLE, CATEGORIE
WHERE ARTICLE.CodeArticle = CATALOGUE.CodeArticle
AND CATEGORIE.CodeCatégorie = ARTICLE.CodeCatégorie#
AND CATEGORIE.LibelléCateg = "Plateaux";
ou
SELECT ARTICLE.NomArticle, CATALOGUE.PrixCatalogue
FROM CATEGORIE INNER JOIN (CATALOGUE INNER JOIN ARTICLE ON CATALOGUE.CodeArticle = ARTICLE.CodeArticle) ON CATEGORIE.CodeCatégorie = ARTICLE.CodeCatégorie#
WHERE CATEGORIE.LibelléCateg = "Plateaux";
A.3.2 - le coût moyen des articles par catégorie (code et libellé catégorie)
SELECT CATEGORIE.CodeCatégorie, CATEGORIE.LibelléCateg, AVG(ARTICLE.CoûtUnitaire) AS CoûtMoyen
FROM CATEGORIE, ARTICLE
WHERE CATEGORIE.CodeCatégorie = ARTICLE.CodeCatégorie#
GROUP BY CATEGORIE.CodeCatégorie, CATEGORIE.LibelléCateg;
ou
SELECT CATEGORIE.CodeCategorie, CATEGORIE.LibelleCateg, AVG(ARTICLE.CoûtUnitaire) AS CoûtMoyen
FROM CATEGORIE INNER JOIN ARTICLE ON CATEGORIE.CodeCAtégorie = ARTICLE.CodeCatégorie#
GROUP BY CATEGORIE.CodeCatégorie, CATEGORIE.LibelléCateg;
B - Étude des autorisations d'accès
B.1 - Schématisez (Annexe A) les autorisations dans la vue organisationnelle d'un agent technico-commercial
Pour cette partie, il fallait faire le tableau comparatif Rôle Groupe "administration des ventes" - Rôle "Technico-commercial"
A titre d'exemple :
Objet CLIENT (Insert) - Groupe administration des ventes = oui - Techinco = indifférent donc CLIENT (Insert) = oui
Objet CLIENT (Select) - Groupe administration des ventes = oui - Techinco = indifférent donc CLIENT (Select) = oui
Objet CLIENT (Update) - Groupe administration des ventes = oui - Techinco = indifférent donc CLIENT (Update) = oui
Objet CLIENT (Delete) - Groupe administration des ventes = oui - Techinco = non donc CLIENT (Delete) = non
Donc dans la vue technico-commercial CLIENT [CIM]
Objet OFFRE (Insert) - Groupe administration des ventes = oui - Techinco = non donc OFFRE (Insert) = non
Objet OFFRE (Select) - Groupe administration des ventes = oui - Techinco = indifférent donc OFFRE (Select) = oui
Objet OFFRE (Update) - Groupe administration des ventes = oui - Techinco = non donc OFFRE (Update) = non
Objet OFFRE (Delete) - Groupe administration des ventes = non - Techinco = non donc OFFRE (Delete) = non
Donc dans la vue technico-commercial OFFRE [I]
Objet COMMANDE (Insert) - Groupe administration des ventes = oui - Techinco = non donc COMMANDE (Insert) = non
Objet COMMANDE (Select) - Groupe administration des ventes = oui - Techinco = indifférent donc COMMANDE (Select) = oui
Objet COMMANDE (Update) - Groupe administration des ventes = oui - Techinco = non donc COMMANDE (Update) = non
Objet COMMANDE (Delete) - Groupe administration des ventes = non - Techinco = non donc COMMANDE (Delete) = non
Donc dans la vue technico-commercial COMMANDE [I]
Objet OFFRIR (Insert) - Groupe administration des ventes = oui - Techinco = non donc OFFRIR (Insert) = non
Objet OFFRIR (Select) - Groupe administration des ventes = oui - Techinco = indifférent donc OFFRIR (Select) = oui
Objet OFFRIR (Update) - Groupe administration des ventes = oui - Techinco = non donc OFFRIR (Update) = non
Objet OFFRIR (Delete) - Groupe administration des ventes = oui - Techinco = non donc OFFRIR (Delete) = non
Donc dans la vue technico-commercial OFFRIR [I]
Objet CONFIRMER (Insert) - Groupe administration des ventes = oui - Techinco = non donc CONFIRMER (Insert) = non
Objet CONFIRMER (Select) - Groupe administration des ventes = oui - Techinco = indifférent donc CONFIRMER (Select) = oui
Objet CONFIRMER (Update) - Groupe administration des ventes = oui - Techinco = non donc CONFIRMER (Update) = non
Objet CONFIRMER (Delete) - Groupe administration des ventes = oui - Techinco = non donc CONFIRMER (Delete) = non
Donc dans la vue technico-commercial CONFIRMER [I]
Puis par extension :
Dans la vue technico-commercial APPEL D'OFFRES [I]
Dans la vue technico-commercial CORRESPONDANT [I]
Dans la vue technico-commercial CONCERNER [I]
Dans la vue technico-commercial ARTICLE [I]
Dans la vue technico-commercial CATEGORIE [I]
Dans la vue technico-commercial CATALOGUE [I]
Dans la vue technico-commercial SPECIFIQUE [I]
B.2 - Résumez en quelques lignes les avantages de la notion de groupe d'utilsateurs
Nous devons rappeler que la société ONDULEX emploie 200 salariés.
Dans l'exploitation d'un réseau, notamment pour les grandes sociétés, il est indispensable de déterminer qui à le droit de faire quoi. Les système d'exploitation de réseau doivent pouvoir gérer l'utilisation des ressources par les utilisateurs.
Rappelons qu'une ressource est une information, une application, un périphérique et qu'un utilisateur est une personne connue par le système d'exploitation de réseau (login et password).
Créer un groupe d'utilisateurs permet tout simplement d'attribuer les droits d'un groupe et non pas à chaque utilisateur.
Je rappelle que c'est une piste de correction et non pas la correction. Je ne suis pas à l'abris d'une erreur de jugement :dacc:
Si un accroc du P10 pouvait vérifier ma piste de correction.
