Vous êtes sur la page 1sur 90

Dédicaces

A celle qui a attendu avec impatience les fruits de sa bonne éducation, à ma


mère.
A celui qui m'a indiqué la bonne voie en me rappelant que la volonté fait
toujours les grands hommes, à mon père.
En témoignage de ma profonde gratitude et de mon incontestable
reconnaissance envers vous.
A mon frère et ma sœur auprès desquels j'ai trouvé un soutien sans
complaisance et des encouragements sincères, à Mouad et Soukaina
A toute ma famille et mes amis qui ont fait preuve de soutien et qui m’ont
donné une motivation sans prix.
A tous mes chers amis avec qui j'ai passé des instants inoubliables.

A mon école l'ENSIAS.


A toutes les personnes qui ont cru en mes succès.

Je dédie ce travail…
Remerciements
Avant tout développement sur cette expérience professionnelle, il apparaît opportun de
commencer par des remerciements, à ceux qui m'ont beaucoup appris au cours de ce stage, et
même à ceux qui ont eu la gentillesse de faire de ce stage un moment très profitable.

Je remercie Mr Mohamed Ahazzam le manager technique pour son suivi méticuleux du


sujet, en vue d’une bonne maîtrise de la qualité du produit final. Aussi, je remercie Mr Karim
Sefiani le co-manager technique qui a favorisé mon travail et m’a aidé à le concrétiser.

Ce n'est pas facile d'arriver à accomplir mon travail sans aide ni conseils à cause des
problèmes rencontrés tant pratiques que théoriques. Pour cela j’exprime toutes mes gratitudes et
mes plus vifs remerciements à mon encadrant Mr Raddouane Chiheb pour son soutien, sa
patience, ses conseils judicieux et pertinents.

Je remercie également l'ensemble des collaborateurs à ValuePass Consulting pour les conseils
qu'ils ont pu me prodiguer au cours de ces mois.

Mes remerciements s'adressent aussi à Mr Mohammed Abdou Janati Idrissi mon chef
du département et Mr Abdellah El Manouar mon chef d'option ainsi que tous mes enseignants
pour la formation qu’ils m’ont inculquée.

Projet de Fin d'Etudes 2010–2011

i
Résumé
Le rapport suivant porte sur le sujet du stage de fin d’études effectué au sein de ValuePass
Consulting. Le projet répond à un besoin initial exprimé par le pôle agroalimentaire du groupe
Mabrouk concernant l'intégration d'un nouveau système d'information SAP qui, en vue
d'améliorer la production et de gagner en temps et en qualité, m’a confié la mission d’analyser,
concevoir et réaliser une solution permettant la génération de formulaires imprimables et
l'automatisation des actions correctives. La solution vise à automatiser deux procédures
majeures :

- Le Reporting (Génération de documents imprimables).


- L'automatisation d'actions correctives (Ajustement d'écarts).

Afin de répondre à ce besoin, j’ai procédé à une analyse préliminaire pour bien cerner la
problématique, ensuite une étude fonctionnelle afin de mieux comprendre le métier du client et
enfin une analyse portant sur l'architecture logicielle avant d'attaquer la partie réalisation et
paramétrage du travail demandé.

Projet de Fin d'Etudes 2010–2011

ii
Abstract
The following report is about the topic of graduation internship done in ValuePass
Consulting. The project was carried out so as to respond to a need expressed by the food hub of
the group Mabrouk for the integration of a new SAP information system, to improve production
and save time and quality, I was given the mission of the analysis, design and implement a
solution for the generation of printable forms and automating corrective actions. The solution is
to automate two major procedures:

- The Reporting (generation of printable documents).


- The automation of corrective actions (Adjustment of variances).

To cope with this need, I conducted a preliminary analysis to properly identify the
problem, then a functional study to better understand the client's business and finally an analysis
of software architecture before attacking the party achievement and testing work required.

Projet de Fin d'Etudes 2010–2011

iii
Liste des figures
Figure 1 - Cartographie de ValuePass..........................................................................................................3
Figure 2 - Les produits du pôle AA du groupe MABROUK........................................................................9
Figure 3 - Périmètre du futur SI du pôle AA..............................................................................................11
Figure 4 - Planning général du projet HERMES........................................................................................11
Figure 5 - Cycle de développement en Y...................................................................................................13
Figure 6 - Diagramme de GANTT.............................................................................................................15
Figure 7 - Processus d'un SmartForm.........................................................................................................19
Figure 8 - Flowchart Impression des formulaires.......................................................................................22
Figure 9 - Flowchart Traitement d'action corrective...................................................................................23
Figure 10 - Diagramme de contexte...........................................................................................................27
Figure 11 - Diagramme des cas d'utilisation « Module du reporting ».......................................................29
Figure 12 - Diagramme des cas d'utilisation « Module des actions correctives ».......................................34
Figure 13 - Diagramme de séquences « Traitement du Reporting »...........................................................36
Figure 14 - Diagramme de séquences « Traitement des actions correctives »............................................37
Figure 24 – Modèle logique de données « Traitement du Reporting ».......................................................38
Figure 25 – Modèle logique de données « Traitement des actions correctives »........................................39
Figure 15 - Architecture physique..............................................................................................................41
Figure 16 - Communication entre les systèmes DEV, QAS et PROD........................................................42
Figure 17 - Architecture logicielle..............................................................................................................43
Figure 18 - Architecture 3-tiers..................................................................................................................44
Figure 19 - Système R/3.............................................................................................................................46
Figure 20 - ABAP Workbench...................................................................................................................47
Figure 21 - Langage ABAP........................................................................................................................48
Figure 22 - Ecran initial des SmartForms...................................................................................................50
Figure 23 - Outils de transport....................................................................................................................51
Figure 26 - SAP Form Builder...................................................................................................................55
Figure 27 - Transaction ME51N pour la création d'une demande d'achat...................................................56
Figure 28 - Transaction ME41 pour la création de la demande d'offre.......................................................57
Figure 29 - Transaction ME9A d'édition de messages des demandes d'offre.............................................58
Figure 30 - Liste des messages d'impression des demandes d'offre............................................................58
Figure 31 - Demande d'offre « Aperçu avant impression »........................................................................59
Figure 32 - Transaction ME21N pour la création d'une commande d'achat................................................60
Figure 33 - Commande d'achat « Aperçu avant impression ».....................................................................61
Figure 34 - Ecran de sélection du programme d'ajustement d'écart............................................................62
Figure 35 - Dynpro d'ajustement d'écart.....................................................................................................63
Figure 36 - Transaction MIGO pour la réception de marchandises............................................................64

Projet de Fin d'Etudes 2010–2011

iv
Figure 37 - Transaction MIRO pour la création de facture/chargement.....................................................64

Liste des tableaux


Tableau 1 - Missions SAP............................................................................................................................7
Tableau 2 - Missions Organisation...............................................................................................................8
Tableau 3 - Descriptif des sociétés du pôle AA..........................................................................................10
Tableau 4 - Description des acteurs et de leurs rôles..................................................................................28
Tableau 5 - Description textuelle du UC « Visualiser la liste des messages »............................................30
Tableau 6 - Description textuelle du UC « Imprimer un message »...........................................................31
Tableau 7 - Description textuelle du UC « Rechercher un message »........................................................32
Tableau 8 - Description textuelle du UC « Ajouter un message »..............................................................33
Tableau 9 - Description textuelle du UC « Modifier un message »............................................................33
Tableau 10 - Description textuelle du UC « Affecter une action corrective »............................................35
Tableau 11 - Description textuelle du UC « Alerter les acteurs »...............................................................35

Table des matière

Projet de Fin d'Etudes 2010–2011

v
s
Remerciements..................................................................................................................................................... i
Résumé............................................................................................................................................................... ii
Abstract.............................................................................................................................................................. iii
Liste des figures.................................................................................................................................................. iv
Liste des tableaux................................................................................................................................................ v
Table des matières.............................................................................................................................................. vi
Introduction........................................................................................................................................................ 1
Chapitre I – Contexte général du projet................................................................................................................ 2
1. Présentation de l'organisme d'accueil........................................................................................................... 3
1.1. Introduction....................................................................................................................................................3
1.2. Missions..........................................................................................................................................................3
1.3. Métiers...........................................................................................................................................................4
1.3.1. Conseil et intégration ERP.....................................................................................................................4
1.3.2. Conseil en Management & Organisation..............................................................................................5
1.3.3. Formation aux ERP................................................................................................................................6
1.3.4. Développement Offshore......................................................................................................................6
1.4. Références......................................................................................................................................................7
2. Présentation du projet.................................................................................................................................. 8
2.1. Le cadre du projet..........................................................................................................................................8
2.1.1. Le client.................................................................................................................................................8
2.1.2. Le projet HERMES 2011.......................................................................................................................10
2.2. L'objectif du projet.......................................................................................................................................12
2.3. Résultats attendus et plan d’action.............................................................................................................12
3. Conduite du projet..................................................................................................................................... 13
2.4. La méthodologie...........................................................................................................................................13
2.5. Le planning...................................................................................................................................................15
4. Conclusion du chapitre............................................................................................................................... 16
Chapitre II – Etude préliminaire.......................................................................................................................... 17
1. Etude et critique de l’existant..................................................................................................................... 18
1.1. Analyse des procédures...............................................................................................................................18
1.1.1. Reporting.............................................................................................................................................18
1.1.2. Traitement des actions correctives.....................................................................................................19
1.2. Critique et refonte des procédures..............................................................................................................20
2. Spécification des besoins............................................................................................................................ 21
2.1. Formulation du besoin.................................................................................................................................21
2.2. Etude du besoin...........................................................................................................................................22
3. Solution proposée...................................................................................................................................... 24
4. Conclusion du chapitre............................................................................................................................... 24
Chapitre III – Etude fonctionnelle....................................................................................................................... 26
1. Choix d'UML............................................................................................................................................... 27
Projet de Fin d'Etudes 2010–2011

vi
2. Identification des acteurs............................................................................................................................ 27
3. Description textuelle des cas d’utilisation.................................................................................................... 28
2.1. Module du reporting....................................................................................................................................29
2.2. Module d'automatisation des actions correctives.......................................................................................33
4. Description dynamique des cas d’utilisation................................................................................................35
3.1. Module traitement du reporting.................................................................................................................36
4.2. Module traitement des actions correctives.................................................................................................36
5. Reverse engineering de la base de données.................................................................................................37
5.1. Traitement du reporting..............................................................................................................................37
5.2. Traitement des actions correctives..............................................................................................................38
Chapitre IV – Architecture logicielle du projet.................................................................................................... 40
1. Spécifications techniques............................................................................................................................ 41
1.1. Architecture physique..................................................................................................................................41
1.2. Architecture logicielle..................................................................................................................................43
2. Présentation SAP........................................................................................................................................ 44
2.1. SAP AG..........................................................................................................................................................44
2.2. SAP ERP........................................................................................................................................................45
3. Environnement de développement............................................................................................................. 47
3.1. ABAP Workbench.........................................................................................................................................47
3.2. ABAP.............................................................................................................................................................48
4. Outils de développement et transport......................................................................................................... 49
4.1. Outils de développement.............................................................................................................................49
4.2. Outils de transport.......................................................................................................................................51
5. Conclusion du chapitre............................................................................................................................... 52
Chapitre V – Réalisation..................................................................................................................................... 53
1. Réalisation................................................................................................................................................. 54
1.1. Module du Reporting...................................................................................................................................54
1.1.1. Développement...................................................................................................................................54
1.1.2. Paramétrage........................................................................................................................................56
1.2. Module d'automatisation des actions correctives.......................................................................................62
Conclusion......................................................................................................................................................... 65
Bibliographie & Webographie............................................................................................................................ 66
Annexes............................................................................................................................................................. 67
Annexe A: Plan Assurance Qualité............................................................................................................................67
Annexe B: Outils de modélisation.............................................................................................................................75

Projet de Fin d'Etudes 2010–2011

vii
Introduction
Dans le cadre de l’optimisation des processus de gestion , de l’intégrité et unicité
du système d’information, du partage du même système d’information facilitant la
communication interne et externe, de la synchronisation des traitements, de la maintenance
corrective et de l’amélioration des fonctionnalités, le pôle agro-alimentaire du groupe Mabrouk
tunisien a choisi d’intégrer un nouveau système d’information SAP en collaboration avec l’ SSII
marocaine d’intégration ERP et de conseil en organisation ValuePass Consulting.

L’entame du projet consiste donc à étudier le besoin initial en premier lieu, cela dit une étude de
faisabilité qui permet de définir le périmètre que l’application se chargera d’automatiser, il
s’ensuit une critique de l’existant qui se traduit par la refonte de l’ensemble des procédures
incluses dans le périmètre en question, tout cela contribue à la rédaction du cahier des charges
fonctionnel. En outre, l’étude des moyens et architectures techniques disponibles et la
justification des choix permettent la rédaction du cahier des charges technique.

L’ensemble des normes à respecter lors des différentes phases du projet (Analyse, conception,
réalisation) sont gérées par un document produit au début, qui est le Plan d’Assurance Qualité
Logicielle (PAQL) convenu avec l’ensemble des intervenants. [Annexe A]

Le présent mémoire aura donc pour but de rapporter l’ensemble des activités et démarches
suivies afin d’atteindre l’objectif du stage qui est de répondre au besoin initial, il s’articule selon
cinq chapitres :

- Le premier chapitre introduit le contexte général du projet.


- Le deuxième chapitre concerne l’étude préliminaire et une critique de l’existant.
- Le Troisième chapitre concerne l’étude fonctionnelle des deux volets du projet
- Le quatrième chapitre concerne l’architecture logicielle du projet.
- Le cinquième chapitre concerne la réalisation du projet.

Projet de Fin d'Etudes 2010–2011

1
Projet de Fin d'Etudes 2010–2011

2
Chapitre I

Contexte général du projet


Le chapitre suivant nous introduit le contexte général dans lequel le projet s’est déroulé,
cela dit une présentation de l’organisme d’accueil ValuePass ainsi que le projet en question et
enfin la méthodologie et le planning prévisionnel respectés lors de l’ensemble des phases
d’élaboration du projet.
Chapitre I Contexte général du projet

1. Présentation de l'organisme d'accueil


1.1. Introduction
ValuePass est un intégrateur d’ERP – SAP, mais aussi une boîte de conseil en Organisation.
Crée en 2005, elle constitue une réponse à un besoin accru en professionnels qualifiés maîtrisant
les standards internationaux en matière d’intégration d’ERP.

La société, qui s’appuie sur une équipe de consultants de très bon niveau, offre ses services
aux multinationales implantées au Maghreb et aux grands comptes publics et privés. Consciente
de l’évolution de l’économie nationale, ValuePass a développé une offre d’intégration de SAP
adaptée aux PME.

Figure 1 - Cartographie de ValuePass

1.2. Missions
La mission de ValuePass consiste à développer une offre de consulting basée sur la
proximité et l’excellence. A assurer également des services de qualité et un accompagnement
durable de ses clients.

Son offre comprend une palette de prestations organisées autour de quatre métiers:

 Conseil en management et Organisation


Projet de Fin d'Etudes 2010–2011

4
Chapitre I Contexte général du projet

 Conseil et Implémentation des ERP


 Formation aux ERP
 Développements Off-shore

1.3. Métiers

1.3.1. Conseil et intégration ERP

L’intégration des ERP constitue le cœur de métier de ValuePass, S’appuyant sur son fort
partenariat avec SAP ainsi qu’avec des intégrateurs de référence (IBM Global Business
Services), ValuePass participe à des projets complexes d’intégration, allant de la conception à
l’intégration et la mise en œuvre de solutions technologiques.

ValuePass met à la disposition des clients son expertise métier et technique à toutes les
étapes du processus d’intégration et s’appuie sur une démarche rigoureuse pour garantir la
réussite de leurs projets de transformation et de mise en œuvre de la solution SI retenue par
l'entreprise.

ValuePass se compose de consultants techniques et fonctionnels en SI, prêts à accompagner


l'entreprise depuis le choix de son ERP jusqu’à sa mise en œuvre

L'approche de ValuePass est basée sur les retours d’expériences de mise en œuvre de projets
ERP dans le monde et privilégie les chantiers à valeur ajoutée pour l’entreprise.

L'offre de ValuePass comprend:

 Pilotage des projets


 Intégration des projets ERP
 Assistance à maîtrise d’ouvrage
 Assistance au choix et comparaison des solutions
 Rédaction de cahier des charges et des spécifications fonctionnelles

Projet de Fin d'Etudes 2010–2011

5
Chapitre I Contexte général du projet

1.3.2. Conseil en Management & Organisation

Positionnée sur le marché du conseil en management et en organisation et dotée d’expertises


sectorielles et fonctionnelles de premier plan, ValuePass a pour ambition d'aider ses clients à
identifier, structurer et exécuter leurs projets de transformation qui impactent durablement leurs
croissance ou leurs compétitivité.

ValuePass les accompagne dans leurs phases de transition en portant une grande attention
aux facteurs clés d’une transformation réussie.

L'offre de ValuePass comprend :

 Accompagnement dans l’optimisation de l’organisation et des processus internes


 La cartographie des processus de l’entreprise
 La mise en place des processus, mise en place des procédures de gestion et métier
 Business Process Réengineering (BPR)
 Mise en œuvre d’une démarche outillée de modélisation des processus (Aris, Mega,
Visio)
 Diagnostic et rationalisation des processus / filières
 Refonte des organisations et des systèmes (Front-to-Back, comptables…)
 Etude des performances, Mise en place des indicateurs de performance des processus
 Mise en place de reporting (réglementaires ou de gestion)
 Afin d’aider les entreprises à se mettre en conformité avec les nouvelles exigences
règlementaires internationales en matière de gestion du risque et de contrôle interne
(Sarbanes Oxley) et dans le cadre de la mise en place des nouvelles normes
comptables et reporting (IFRS et IAS), l'offre s’étend à l’accompagnement dans la:

 Cartographie des risques


 Diagnostic du dispositif de contrôle des risques
 Définition de plans directeurs d’adaptation aux évolutions réglementaires et
intégration des dispositifs réglementaires
 Choix, mise en œuvre et homologation du modèle interne

Projet de Fin d'Etudes 2010–2011

6
Chapitre I Contexte général du projet

 Définition des stratégies adéquates de gestion des risques


 Assistance à la maîtrise d’ouvrage pour la mise en place des outils
 Définition et mise en place des Plans de Continuité Des Activités

1.3.3. Formation aux ERP

En fonction des besoins de l'entreprise, ValuePass assure des formations sur mesure,
destinées aux utilisateurs de son système ERP. Les formations sont dispensées par des
consultants experts en intégration des ERP doublé d’une maîtrise pédagogique acquise grâce
aux sessions de formations animées au Maroc et en France.

L'offre comprend :

 Organisation des formations sur mesure ;


 Rédaction des manuels de formation ;
 Formations organisées en petits groupes où l’accent sera mis sur l’utilisation du
système : Exercices ciblés avec exemples concrets ;
 Formations assurées sur place ou en centre de formation.

1.3.4. Développement Offshore

ValuePass s’appuie sur son expérience et son savoir-faire dans le domaine de l’intégration
des SI pour accompagner ses clients dans la prise en charge et l’évolution de leurs systèmes
d’information et à faire face avec eux à leurs enjeux métiers.

L'offre comprend :

 Développement sur les technologies ABAP


 Développement autour des outils décisionnels comme BW ;
 Maintenance applicative à distance des systèmes d’information des clients basés à
l’étranger ;
 Paramétrage en centre permettant de personnaliser le progiciel ;
 Analytique pour le compte des multinationales en utilisant des outils statistiques.

Projet de Fin d'Etudes 2010–2011

7
Chapitre I Contexte général du projet

1.4. Références
ValuePass a déjà effectué plusieurs projets SAP et Organisation dans les différents pays du
Maghreb notamment le Maroc, l'Algérie et la Tunisie qui font que sa renommée s'accroît de
plus de plus dans ses domaines. Voici donc une liste des différents projets achevés :

 Missions SAP

Entreprise Mission SAP


X Projet d’Implémentation SAP : Gestion commerciale, Logistique, Maintenance,
Production, Finance, Contrôle de Gestion et Décisionnel

Projet de mise en œuvre de SAP : Module Finance

 Accompagnement à la mise en place de SAP au sein de la filiale marocaine


d’International Paper (modules FI/CO/MM)
 Formation des utilisateurs
 Support – Assistance
 Mise en place de SAP sur les modules Finances, Commercial, Achats :
Bouclage du projet
 Maintenance de paramétrage: Evolution en fonction des nouveaux besoins
et correction
 Projet d’intégration de SAP GMAO: Intervention sur le module
Maintenance et sur le module gestion des stocks
 Session de formation utilisateurs finaux et décideurs
 Participation au projet de mise en place de SAP ISU CRM en partenariat
avec Cap Gemini France
 Intégration du module SAP CRM Customer Relationship Management
 Intégration du module SAP PM – Gestion de la maintenance
 Développement et mise en place de Reporting sur SAP
 Modélisation des processus et mise en place des procédures
 Mise en place des indicateurs de performance
Montée de version de my SAP CRM 3.0 vers my SAP CRM 4.0

Mise en place de my SAP CRM au sein de la filiale algérienne de Tunisie Leasing

Projet de Fin d'Etudes 2010–2011

8
Chapitre I Contexte général du projet

Tableau 1 - Missions SAP

 Missions Organisation

Entreprise Mission Organisation


Diagnostic Organisationnel et Humain préalablement à la mise en place d’un
nouveau système d’information au sein de la régie publicitaire de la SNRT

 Mise en place des procédures de suivi des dépenses marketing


 Gestion Facturation inter company (Coca-Cola et Embouteilleurs)

 Rédaction et mise en place des procédures de gestion


 Cadrage SI : étude & assistance au choix du SI cible
 Assistance au déploiement de Wingsm – logiciel de gestion intégrée dédiée
aux télécoms.
Diagnostic, définition des processus et mise en place des procédures au sein des
sociétés du Groupe SAHAM – POLE DISTRIBUTION

 Définition et modélisation des processus B2B


 Rédaction et mise en place de nouvelles procédures
 Assistance à la conduite du changement

Tableau 2 - Missions Organisation

2. Présentation du projet
2.1. Le cadre du projet

2.1.1. Le client

Le Pôle AA (Agro-alimentaire) du Groupe MABROUK est leader dans les segments de


marché visés avec une maîtrise marketing, commerciale et industrielle de ses métiers :

– Leadership dans les segments de marché visés ;

– Maîtrise marketing, commerciale et industrielle dans les métiers du Groupe ;

– Marques de forte notoriété ;

Projet de Fin d'Etudes 2010–2011

9
Chapitre I Contexte général du projet

– Capacité de développement de nouveaux produits selon les besoins identifiés du


consommateur ;

– Réalisation de partenariat de renom international dans le biscuit et le fromage ;

– Réalisation de programme de développement continue de la capacité de


production et d’expansion régionale.

Le Pôle AA est leader en Tunisie en :

Figure 2 - Les produits du pôle AA du groupe MABROUK

Il est composé de trois sociétés industrielles, comme décrit dans le tableau ci-dessous.

SOTUCHOC IAT
SOTUBI
Société Tunisienne de Industries
Société Tunisienne de
Chocolaterie et de Alimentaires de
Biscuiterie
confiserie Tunisie
Métier Industriel Industriel Industriel

Projet de Fin d'Etudes 2010–2011

10
Chapitre I Contexte général du projet

 Biscuits secs  Chocolat (Said,  Fromage fondu


(Saida, Start,...) Maestro, Club (Président, Fromy)
 Biscuits salés (Tuc) chocolat)  Fromage carré
 Biscuits  Chocolat en poudre (Président)
sandwichés (Major, (Saida, Chocoline)  Slice (Président,
Prince)  Crème à tartiner Fromy)
Produits  Gaufrettes (Saida, (Said)  Râpé (Président,
Croustina)  Barres chocolatées Fromy)
 Génoises (Break,  Fromage frais
PMG) barquette
 Autres (Fraidoux,
Rondelé, Goutella)

MP*: 120 MP: 500 MP: 150


Nombre d'articles PF*: 70 PF: 177 PF: 75
PR*:7500 PR: 3630 PR: 4500

 Grandes et moyennes surfaces


 Grossistes
Distribution
 Vente directe détaillants

Employés 1200 1100 600


Nombre de sites 1 2 1
Nombre Utilisateurs
200
SI

Tableau 3 - Descriptif des sociétés du pôle AA

2.1.2. Le projet HERMES 2011

Pour supporter son développement, le Pôle Agroalimentaire du Groupe MABROUK a


lancé un projet de refonte de son système d’information et a établi un cahier des charges avec
l’accompagnement d’Accenture ;

L’objectif du projet de refonte du SI consiste à optimiser le pilotage de la performance financière


et opérationnelle. Il s’agit d’améliorer sensiblement:

 Le Contrôle des flux (L’automatisation des règles de validation ; La sécurisation des


données)

Projet de Fin d'Etudes 2010–2011

11
Chapitre I Contexte général du projet

 La Fiabilité des données (La réduction des saisies manuelles ; l’unicité des données).

 La Visibilité sur l’activité (L’historisation des données ; L’intégration des flux).

 Le système d’information doit être :

 à la hauteur de la dimension que le groupe représente aujourd’hui,

 en phase avec les ambitions de croissance pour la décennie à venir.

Il s’agit d’un projet stratégique et représente un enjeu « fondamental ». Il s’agit en effet de


poser les éléments de fondation indispensables à la croissance du pôle.

Un système informatique intelligemment structuré et commun aux SAA :

 facilitera l’organisation du travail et la communication entre les équipes,

 garantira la fiabilité des processus et des données de gestion,

 assurera la réponse adéquate aux exigences de plus en plus fortes des marchés en
termes de suivi de la qualité et de respect des règlementations,

 génèrera des synergies transverses liées au partage de l’information

 C’est assurément un vecteur de progrès important et motivant pour le pôle.

Le périmètre du futur SI doit toucher aux différents domaines illustrés comme suit:

Projet de Fin d'Etudes 2010–2011

12
Chapitre I Contexte général du projet

Figure 3 - Périmètre du futur SI du pôle AA

Les grandes étapes du projet HERMES 2011 sont décrites dans la figure ci-dessous :

Figure 4 - Planning général du projet HERMES

Projet de Fin d'Etudes 2010–2011

13
Chapitre I Contexte général du projet

2.2. L'objectif du projet


Dans le cadre de l’intégration du progiciel SAP pour le groupe agro-alimentaire du groupe
MABROUK, nous serons donc amené à réaliser des développements spécifiques pour répondre
aux besoins du client non couvert par le standard du progiciel. Ces développements s’articulent
autour de trois axes :

 Reporting : développements d’états de suivi et de formulaires à imprimer (bon de


commande, bon de livraison)
 Extensions des fonctionnalités standards pour ajouter des contrôles, des zones ou des
écrans supplémentaires
 Interfaces et reprise des données

Le stage sera amené, si le client le demande, à faire du paramétrage et du développement dans


l’outil BW d’aide à la décision propre à SAP.

2.3. Résultats attendus et plan d’action 


Je serais amené à me former sur le langage de programmation ABAP du progiciel SAP.
Des supports de formation incluant des exercices pratiques et une assistance d’un expert
technique seront mis à la disposition.

Je dois réussir à m’intégrer dans l’équipe du projet. Je dois également réussir à implémenter les
demandes de développement qui me sont affectés tout en respectant :

 Les délais
 La qualité attendue des livrables (code source et documentation)
 Le respect des normes et standard du développement

Je dois soigner mes développements et mes documents et je dois m’assurer de la qualité des
programmes livrés en effectuant, au préalable, des tests unitaires sur les programmes développés.

Projet de Fin d'Etudes 2010–2011

14
Chapitre I Contexte général du projet

3. Conduite du projet
2.4. La méthodologie
La gestion de projet est une démarche visant à organiser de bout en bout le bon déroulement
d’un projet, elle permet une organisation vouée à être évolutive et temporaire. Mon projet de fin
d’études combine quatre aspects :

 Fonctionnel : réponse à un besoin


 Technique : respect des spécifications et des contraintes de mise en œuvre
 Organisationnel : respect du mode de fonctionnement de la structure cible
 Délais : respect des échéances (planning)

Pour bien structurer les phases du déroulement du projet j’ai effectué une étude comparative
entre les différentes méthodes de gestion de projet informatique afin de décider laquelle à adopter
en fonction des besoins spécifiques du projet.

Compte tenu des différents critères, de la complexité d’implémentation de la méthode et de


l’envergure du projet, j’ai opté pour la méthode 2TUP qui offre à l’instar des autres méthodes un
processus itératif avec un cycle de vie incrémental en Y.

La figure suivante représente le cycle de vie en Y :

Figure 5 - Cycle de développement en Y


Projet de Fin d'Etudes 2010–2011

15
Chapitre I Contexte général du projet

Ce cycle s’articule selon 3 branches :

 Branche fonctionnelle, comportant les deux phases suivantes :


 Capture des besoins fonctionnels, qui produit le modèle des besoins focalisé sur le
métier des utilisateurs. Elle qualifie, au plutôt le risque de produire un système
inadapté aux utilisateurs.
 L’analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière
à obtenir une idée de ce que va réaliser le système en terme de métier.
 Branche architecture technique qui quant à elle comporte les deux phases suivantes :
 La capture des besoins techniques, qui recense toutes les contraintes sur les choix
techniques du système. Les outils et le matériel sélectionné ainsi que la prise en
compte des contraintes d’intégration avec l’existant (pré requis d’architecture
technique).
 La conception générique, qui définit ensuite les composants nécessaires à la
construction de l’architecture technique. Cette conception est complètement
indépendante des aspects fonctionnels. Elle a pour objectif d’uniformiser et de
réutiliser les mêmes mécanismes pour tout système.

L’architecture technique construit le squelette du système, son importance est telle qu’il est
conseillé de réaliser un prototype.

 Et enfin la branche conception dont les phases sont les suivantes :


 La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d’analyse fonctionnelle dans l’architecture technique de manière à tracer la
cartographie des composants du système à développer ;
 La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
 L’étape de codage, qui produit ses composants et teste au fur et à mesure les unités de
code réalisées ;
 L’étape de recette, qui consiste enfin à valider les fonctionnalités du système
développé.

Projet de Fin d'Etudes 2010–2011

16
Chapitre I Contexte général du projet

2.5. Le planning
L’aspect des délais est un élément important de la conduite du projet qu’il faut respecter, car il
permet de bien ordonnancer les différentes taches selon une logique tenant compte de leurs criticités,
dépendances et durées. Dès l’entame du stage, j’ai procédé à un planning prévisionnel convenu avec
les intervenants projets, afin de bien définir les délais et les livrables de chaque phase. Le respect de ce
planning fait partie des normes rédigées lors de l’élaboration du plan d’assurance qualité et cela a été
réalisable grâce à l’outil MS Project 2007.

Microsoft Project (ou MS Project ou MSP) est un logiciel de gestion de projets édité


par Microsoft. Il permet aux chefs de projet et aux planificateurs de planifier et piloter les projets,
de gérer les ressources et le budget, ainsi que d'analyser et communiquer les données des
projets1.

Utilisé aujourd'hui (2011) par plus de 20 millions de chefs de projet, Microsoft Project est le
logiciel de gestion de projet le plus utilisé au monde. Plus de 10 000 entreprises ont aussi déployé
la version serveur de Microsoft Project, nommée Microsoft Project Server.

MS Project permet également la gestion des ressources de chaque projet, c’est-à-dire la création
de l’équipe projet puis l’affectation des ressources définies.

Figure 6 - Diagramme de GANTT

Projet de Fin d'Etudes 2010–2011

17
Chapitre I Contexte général du projet

4. Conclusion du chapitre
Dans ce chapitre nous avons pu avoir une idée générale sur l’organisme d’accueil ValuePass
qui est une SSII implantée dans le Maghreb, en l’occurrence au Maroc à Casablanca et en
Tunisie à Tunis dont nous avons cité les atouts ainsi que les missions réalisées. Par la suite nous
avons fait une présentation du cadre dans lequel s’inscrit le projet qui est le grand projet
HERMES 2011 pour le compte du groupe MABROUK qui est un leader de l’agroalimentaire
en Tunisie. Nous avons aussi pu avoir une idée sur l’objectif du projet ainsi que les résultats
attendus. Il s’est ensuit une description de la méthode de gestion de projet 2TUP ainsi que l’outil
MS Project permettant la construction du diagramme de GANTT qui illustre les grandes phases
du déroulement du projet.

Projet de Fin d'Etudes 2010–2011

18
Chapitre II
Etude préliminaire
Ce chapitre présente l’étude et critique de l’existant qui se concrétise par une refonte des
procédures adoptées pour le reporting et le traitement des actions correctives, il s’ensuit une
analyse pour proposer une solution qui se chargera de répondre au besoin initial.
Chapitre II Etude préliminaire

1. Etude et critique de l’existant


.1. Analyse des procédures

1.1.1. Reporting

Le système SAP offre la possibilité de générer des rapports imprimables pour les étapes du
flux logistique (par exemple). Voici donc les étapes de génération d’un bon de commande pour
un utilisateur finale du progiciel SAP :

 Création de la commande d’achat  :


L’utilisateur choisit les données du fournisseur, de l’acheteur appartenant à l’entreprise et
des articles commandés.
 Lancement de la commande d’achat  :
L’utilisateur lance la commande d’achat une fois qu’elle soit validée par le responsable
des achats
 Génération du bon de commande  :
L’utilisateur génère le bon de commande à imprimer en donnant comme paramètres
d’entrée les données relatives à la commande d’achat déjà créée et lancée.

Lors de la génération du formulaire imprimable, un job (traitement en arrière-plan) est


lancé qui fait appel au programme ABAP standard relatif au bon de commande. Ce programme
récupère les données d’achat (Acheteur, Fournisseur, Articles,...) et les met dans des structures et
tables internes.

Une fois le traitement est effectué, le programme appel un SmartForm (générateur de


formulaire SAP qu’on définira en détail par la suite) qui est chargé de mettre en place les données
correctement dans une page (ou plusieurs, cela dépend de la quantité des données à afficher), le
formatage du texte (suivant les paragraphes et caractères définis dans la feuille de style et
également l’insertion des logos (créés suivant la transaction SE78).

Voici donc un schéma représentatif de la génération d’un document imprimable suivant


un SmartForm en utilisant les données de la base :

Projet de Fin d'Etudes 2010–2011

20
Chapitre II Etude préliminaire

Figure 7 - Processus d'un SmartForm

On remarque dans la figure ci-dessus que le SmartForm génère un module fonction ABAP (qu’on
définira par la suite) qui se charge de générer le document imprimable en utilisant les données
envoyées par le programme d’application mais aussi des données récupérées directement de la
base de données.

Avant d’imprimer, l’utilisateur visualise le document sous une imprimante locale ou sur le
réseau. S’il clique sur le bouton Imprimer, il crée automatiquement un ordre de Spool qui utilisé
soit pour une impression immédiate, soit pour une impression ultérieure.

1.1.2. Traitement des actions correctives

Dans cette partie on va expliquer le traitement des actions correctives à la lumière d’un
ajustement qui fait suite au processus d’importation.
Lors du processus d’importation de vrac, la quantité qu’une société du groupe MABROUK
accepte de payer est parfois différente de la quantité réellement réceptionnée (pesée au port /
pesée usine).
Sauf dépassement de tolérance flagrant, la société paye la quantité figurant sur le Bon de
Livraison du fournisseur.

Projet de Fin d'Etudes 2010–2011

21
Chapitre II Etude préliminaire

Le navire est déchargé au port dans un stock tampon, stock qui est ensuite transféré à l’usine (par
camions). Lors du transfert, le stock est pesé sur un pont bascule :
 A la sortie du port
 A l’entrée dans l’usine

A la fin du transfert physique, il reste un stock logique (ou il manque du stock), c’est la quantité
qui doit faire l’objet de l’ajustement : delta.
Delta = quantité réceptionnée – quantité pesée au port
NB  : un autre delta correspondant à d’éventuelles pertes ou gains liés au transport sera
géré par ailleurs, ce n’est pas l’objet de ce traitement

La situation après ajustement doit être la suivante : le stock SAP (logique) doit être aligné sur le
stock physique, et la valeur de la quantité en delta doit être imputée sur ce stock (au prorata de la
quantité restante).

L’ajustement peut être fait manuellement à l’aide de 3 transactions, en fonction du signe du delta.

Ces 3 étapes sont faites à partir des informations suivantes :


 Numéro de commande d’achats
 Numéro de poste de commande
 Delta
 Date de l’ajustement

Toutes les autres informations nécessaires à la réalisation de ces étapes sont déduites ou fixes.

1.2. Critique et refonte des procédures


Les procédures citées précédemment présentent beaucoup d’inconvénients pour l’activité de
l’exploitation, de par leur qualité et leur aspect très répétitif ainsi que la complexité d’usage. En
effet, les formulaires fournis par le standard n’ont pas un design convivial, trop de données
affichées sans oublier qu’il n’existe pas une possibilité d’ajouter les logos des sociétés sur le
formulaire. Pour les actions correctives, le fait que le traitement est fait à la main rend le flux
Projet de Fin d'Etudes 2010–2011

22
Chapitre II Etude préliminaire

productif plus long et peux générer des erreurs dans la logique des données de la base, si un
utilisateur donné oublie une phase de l’ajustement comme par exemple.

L’aspect répétitif du traitement des actions correctives nous mène à une logique
d’automatisation et l’aspect design et qualité des données des rapports imprimables exige de
nouveaux développements spécifiques non fournis par le standard SAP.

2. Spécification des besoins


2.1. Formulation du besoin
Les besoins du client étaient axés principalement sur le temps et le design. La solution
proposée devrait palier aux limites des programmes fournis par le standard SAP. Ceci dit elle
devra répondre à deux aspects :

+ L’aspect fonctionnel :

- Proposer des formulaires en adéquat avec les maquettes du client.


- Proposer des jobs pouvant gérer tout type de contrôle relatif au périmètre de
l’exploitation.
- Permettre aux utilisateurs du système d’information de recentrer ses efforts
sur la chaine de production.

+ L’aspect technique :

- Les solutions devront être optimales en matière de performances et temps


d’exécution.
- Les programmes doivent être développés dans les environnements du client
MABROUK.
- Les solutions proposées devront répondre à la fois aux normes de qualité de
ValuePass ainsi qu’aux normes internes à MABROUK.
- La mise en production de tout ou une partie de l’application ne devra se faire
qu’après la validation croisée de tous les tests unitaires et des tests
d’homologation.

Projet de Fin d'Etudes 2010–2011

23
Chapitre II Etude préliminaire

2.2. Etude du besoin


Après la formulation des besoins fonctionnels et techniques respectivement par les
responsables fonctionnels et le manager technique, j’ai procédé à une analyse des spécifications
pour une meilleure compréhension du besoin du projet.

Pour ce faire, j’ai assisté autant de fois que possible à l’exploitation pour pouvoir appréhender
les procédures existantes, étudier la faisabilité du travail demandé et essayer par la suite de
délimiter le périmètre d’analyse, qui me permettra de concevoir un système qui s’aligne avec les
attentes des utilisateurs. J’ai ensuite modélisé les procédures dans des Flow Charts, afin d’avoir
une vue globale sur le périmètre d’étude :

Figure 8 - Flowchart Impression des formulaires


Le Flowchart précédent schématise l’ensemble des traitements à effectuer pour la procédure
d’impression des formulaires.

Projet de Fin d'Etudes 2010–2011

24
Chapitre II Etude préliminaire

Figure 9 - Flowchart Traitement d'action corrective


Le Flowchart précédent schématise l’ensemble des traitements à effectuer pour la procédure des
actions correctives.

Les notions techniques SAP (Transaction, Variante...) sont expliquées en annexe.

En élaborant ces diagrammes, j’ai eu une idée globale sur le périmètre du projet, les données,
traitements et exceptions dont se chargera ma solution ainsi que les informations existantes
(transactions, tables...) relatives aux procédures existantes.

Projet de Fin d'Etudes 2010–2011

25
Chapitre II Etude préliminaire

3. Solution proposée
Comme convenu avec le manager technique, afin de répondre au besoin initial, la solution
comportera deux volets majeurs relatifs aux reporting et à l’automatisation des actions
correctives.

- Le volet du traitement du reporting :

La solution comportera des développements spécifiques au niveau des programmes ABAP


pour la récupération des données et l’appel du SmartForm, qui vont être nommés suivant une
nomenclature spéciale tel que ZFOMM_BON_COMMANDE (Z : développement spécifique,
FO : Formulaire, MM : Logistique et BON_COMMANDE relatif au document imprimable
intitulé Bon de commande) et au niveau des formulaires qui vont être créés à l’aide de
SmartForm (pour le design et la récupération des données envoyés par les programmes appelants)
et Feuille de style (pour le formatage du texte affiché) spécifiques qui suivront la même
nomenclature que les programmes (exemples : ZMM_BON_COMMANDE pour le SmartForm et
ZMM_FEUILLE_STYLE pour la feuille de style).

- Le volet de l’automatisation des actions correctives :

La solution permettra en premier lieu de minimiser les traitements réalisés par l’utilisateur
et sera gérée par une transaction principale nommée par exemple ZMM_DELTA (Z :
développement spécifique, MM : Logistique et DELTA : l’action corrective est en rapport avec le
delta entre la quantité commandée et la quantité reçue), où il y aurait un écran de sélection à
remplir en spécifiant bien évidement les champs obligatoires au traitement de l’action corrective.
Une fois le traitement est terminé, un message sera affiché prouvant le bon déroulement de
l’action corrective et fournissant les données générées.

4. Conclusion du chapitre
Ce chapitre nous a permis de voir l’étude de l’existant, en décortiquant les deux procédures
de reporting et des actions correctives, il s’est ensuit une critique de l’existant qui nous a mené au
besoin exprimé par le client qui est axé sur la qualité et le gain en temps d’exploitation. Ensuite,

Projet de Fin d'Etudes 2010–2011

26
Chapitre II Etude préliminaire

nous avons procédé à une modélisation des traitements existants pour une meilleure
compréhension du besoin, ce qui nous a permis de prévoir les fonctionnalités et les grands axes
de la solution proposée.

Projet de Fin d'Etudes 2010–2011

27
Chapitre III
Etude fonctionnelle du projet
Ce chapitre s’emploie à présenter une étude des besoins du projet sur le volet fonctionnel,
une identification sommaire des acteurs et des différents cas d’utilisation, les scénarios
principaux du système étudié, ainsi que les modèles logiques de données définis à l'aide du
reverse engineering du standard SAP.
Chapitre III Etude fonctionnelle du projet

1. Choix d'UML
Le choix du langage UML comme outil de modélisation n’était pas arbitraire, du fait qu’UML
offre plusieurs possibilités telles :

 Une meilleure communication entre les différents intervenants du projet, dans la mesure
où il permet de capturer et de capitaliser les connaissances relatives au projet à travers ses
diagrammes.

 Avoir à la fois la possibilité d’examiner le projet dans son ensemble, et en partie, pour
une meilleure compréhension du système et de son fonctionnement.

 La notation UML s’impose comme un standard de fait, un label de qualité à l’heure


actuelle. Il est largement adopté par les grands constructeurs de logiciels sur le marché.

2. Identification des acteurs


L’entame de l’étude fonctionnelle consiste en l’identification des acteurs, qui sont
concernés par le périmètre du projet et avec lequel ils sont susceptibles d’interagir. Le diagramme
de contexte UML s’emploie à modéliser les différents acteurs et les interactions prévues :

Projet de Fin d'Etudes 2010–2011

29
Chapitre III Etude fonctionnelle du projet

Figure 10 - Diagramme de contexte


Le tableau ci-après représente l’ensemble des trois acteurs ainsi que leurs rôles respectifs :

Acteur Description du rôle

Demandeur - Créer, modifier et afficher une demande d’achat


- Lancer une demande d’achat (lancement individuel) ou
plusieurs à la fois (lancement groupé).
- Affecter, traiter ou archiver une demande d’achat

Acheteur - Modifier ou Afficher une commande d’achat


- Lancer une commande d’achat (lancement individuel) ou
plusieurs à la fois (lancement groupé).
- Affichage de la liste des commandes d’achat (suivant :
fournisseur, article, groupe de marchandises,..)
- Analyses
- Créer, Modifier ou afficher une livraison entrante
- Générer un document imprimable nommé « Bon de
commande »

Projet de Fin d'Etudes 2010–2011

30
Chapitre III Etude fonctionnelle du projet

Gestionnaire des stocks - Mouvement de stock


- Sortie de marchandises
- Transfert de stocks

Magasinier - Gestion des emplacements magasin (WM


Warehouse Management)
- Réception de marchandises

Tableau 4 - Description des acteurs et de leurs rôles

3. Description textuelle des cas d’utilisation


Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d'un système logiciel. Un cas d'utilisation représente
une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Il est une
unité significative de travail. Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés
acteurs (actors), ils interagissent avec les cas d'utilisation (use cases).

2.1. Module du reporting


Le diagramme suivant schématise les différents cas d’utilisation pour le module du reporting :

Projet de Fin d'Etudes 2010–2011

31
Chapitre III Etude fonctionnelle du projet

Figure 11 - Diagramme des cas d'utilisation « Module du reporting »


Le demandeur se charge de la gestion du reporting alors que l’acheteur se charge du traitement du
reporting concernant la gestion des achats. Le magasinier n’intervient pas dans ce processus alors
que le gestionnaire de stocks gère toute la procédure concernant la gestion de stocks.

Cas d’utilisation n°1 : « Visualiser la liste des messages »

Ce cas d’utilisation est réservé d’une part à l’acheteur, qui peut exécuter les transactions
ME9F (Commande d’achat), ME9A (Demande d’offre) ou ME9L (Programme de livraison) et
d’autre part au gestionnaire de stocks qui peut exécuter les transactions MB90 (Mouvement de
stock) pour visualiser la liste des messages afin de les analyser et détecter les erreurs qui peuvent
exister.

Cas d’utilisation Visualiser la liste des messages

Acteurs - Acheteur ou Gestionnaire de stocks


Contexte de déclenchement - Visualiser la liste des messages
Description du cas d’utilisation - L’affichage de la liste des messages
Projet de Fin d'Etudes 2010–2011

32
Chapitre III Etude fonctionnelle du projet

en cours, non encore lancés afin de


les traiter et puis les imprimer
Pré-conditions - Le demandeur a déjà effectué les
ajouts modifications et suppressions
concernant la demande d’achat et la
demande d’offre.
- Le gestionnaire de stocks a déjà
effectué les ajouts modifications et
suppressions concernant les
mouvements de stocks (Livraison,
Réception ou Transfert).
Post-conditions - Liste des messages visualisée
Scénario d’exception - Aucun message a été créé (Affichage
d’un message d’information)

Tableau 5 - Description textuelle du UC « Visualiser la liste des messages »

Cas d’utilisation n°2 : « Imprimer un message »

Ce cas d’utilisation permet tout d’abord un aperçu avant impression du document


logistique, puis le choix entre une impression locale ou à travers le réseau.

Cas d’utilisation Imprimer un message

Acteurs - Acheteur ou Gestionnaire de stocks


Contexte de déclenchement - Impression d’un document à partir d'un message
déjà créé
Description du cas d’utilisation - L’acheteur ou le gestionnaire de stocks peut
choisir un ou plusieurs messages à imprimer.
- Le choix de l’imprimante doit également être fait.
- Quand l’utilisateur clique sur le bouton imprimer,
Projet de Fin d'Etudes 2010–2011

33
Chapitre III Etude fonctionnelle du projet

une impression immédiate est lancée mais


également un ordre de spool est généré qui permet
également une impression ultérieure du document.
Pré-conditions - Le demandeur a déjà configuré un message
concernant la demande d’achat et la demande
d’offre.
- Le gestionnaire de stocks a déjà configuré un
message concernant les mouvements de stocks
(Livraison, Réception ou Transfert).
Post-conditions - Ordre de spool qui permet une impression
immédiate et une impression ultérieure (à la
demande)
Scénario d’exception - Manque de données fonctionnelles (Message
d’erreur).
- Problème de communication avec l’imprimante
(Message d’information).

Tableau 6 - Description textuelle du UC « Imprimer un message »

Cas d’utilisation n°3 : « Rechercher un message »

Permet de rechercher un message dans la base de données (Table TNAPR) afin d’avoir
plus d’informations détaillées (Conditions de relance, criticité...).

Cas d’utilisation Rechercher un message

Acteurs - Acheteur ou Gestionnaire de stocks


Contexte de déclenchement - Recherche d'un message pour plus
d'informations
Description du cas d’utilisation - L’acheteur ou le gestionnaire de
stocks peut rechercher un message
pour voir en détails sa configuration.
Pré-conditions - Le message a déjà été configuré.
Post-conditions - Liste des attributs de messages
affichée.
Scénario d’exception - Aucun message a été créé (Affichage

Projet de Fin d'Etudes 2010–2011

34
Chapitre III Etude fonctionnelle du projet

d’un message d’information)

Tableau 7 - Description textuelle du UC « Rechercher un message »

Cas d’utilisation n°4 : « Ajouter un message »

Permet d'ajouter un message (ou document imprimable) sur la transaction ME22N


concernant l'achat par exemple.

Cas d’utilisation Ajouter un message

Acteurs - Demandeur ou Gestionnaire


de stocks
Contexte de déclenchement - Nouveau message à configurer dans
le système
Description du cas d’utilisation - L’acheteur ou le gestionnaire de
stocks peut rechercher un message
pour voir en détails sa configuration.
Pré-conditions - Les étapes du processus d'achat ou
de stocks précédents ont déjà été
traités.
Post-conditions - Message créé et peut être traité
(visualisé, imprimé,..).
Scénario d’exception - Le message ne peut être créé car
données mal configurées (Affichage
d’un message d’erreur)

Tableau 8 - Description textuelle du UC « Ajouter un message »

Cas d’utilisation n°5 : « Modifier un message »

Permet d'ajouter un message (ou document imprimable) sur la transaction ME22N


concernant l'achat par exemple.

Cas d’utilisation Ajouter un message

Acteurs - Demandeur ou Gestionnaire


de stocks
Contexte de déclenchement - Modifier la configuration d'un

Projet de Fin d'Etudes 2010–2011

35
Chapitre III Etude fonctionnelle du projet

message
Description du cas d’utilisation - L’acheteur ou le gestionnaire de
stocks peut modifier la configuration
d'un message en cas de donnés
incorrectes.
Pré-conditions - Le message a déjà été configuré.
Post-conditions - Message modifié.
Scénario d’exception - Le message ne peut être modifié car
données saisies incohérents
(Affichage d’un message d’erreur)

Tableau 9 - Description textuelle du UC « Modifier un message »

2.2. Module d'automatisation des actions correctives


Ce module s'emploie à gérer les actions correctives automatisées en affectant une action
corrective à un mouvement de stocks par exemple (qui nécessite une modification de la réception
et la facture manuellement). Une fois l'action corrective effectué, le gestionnaire de stocks dans
ce cas doit alerter les autres acteurs.

Le diagramme suivant schématise les différents cas d’utilisation pour le module


d'automatisation des actions correctives :

Projet de Fin d'Etudes 2010–2011

36
Chapitre III Etude fonctionnelle du projet

Figure 12 - Diagramme des cas d'utilisation « Module des actions correctives »

Cas d’utilisation n°6 : « Affecter une action corrective »

Permet d'affecter une action corrective et la génération automatique de nouveaux objets


sur SAP en rapport avec le traitement. Dans le cas de la gestion de stocks un contrôle sur la
quantité reçue des marchandises va générer une nouvelle réception et une nouvelle facture.

Cas d’utilisation Affecter une action corrective

Acteurs - Gestionnaire de stocks


Contexte de déclenchement - Affecter une action corrective
Description du cas d’utilisation - En cas de marge entre les données
logiques et physiques, le gestionnaire
de stocks peut effectuer une action
corrective pour mettre à jour la
cohérence des données du système.
Pré-conditions - L'existence d'une réception et d'une
facture du mouvement de stock.
Post-conditions - Contrôle effectué.
Scénario d’exception - En cas de quantités négatives.
(Affichage d’un message d’erreur)

Tableau 10 - Description textuelle du UC « Affecter une action corrective »

Projet de Fin d'Etudes 2010–2011

37
Chapitre III Etude fonctionnelle du projet

Cas d’utilisation n°7 : « Alerter les acteurs »

Permet d'alerter les autres acteurs de l'effectuation d'une action corrective à l'aide du SAP
Business Workplace via la transaction SBWP.

Cas d’utilisation Alerter les acteurs

Acteurs - Gestionnaire de stocks


Contexte de déclenchement - Alerter les acteurs de l'action
corrective.
Description du cas d’utilisation - Une fois une action corrective a été
effectuée, le gestionnaire de stocks
se doit d'alerter les autres acteurs.
Pré-conditions - L'action corrective a été effectuée
avec succès.
Post-conditions - Acteurs alertés.
Scénario d’exception - En cas de la non-réception de l'alerte
(Affichage d'un message d'alerte)

Tableau 11 - Description textuelle du UC « Alerter les acteurs »

4. Description dynamique des cas d’utilisation


Nous aborderons dans cette partie les interactions entre les objets du système pour mettre
l’action sur l’ordre chronologique dans lequel s’effectuent les échanges de messages entre les
entités existantes qui seront décrites par les diagrammes de séquences.

3.1. Module traitement du reporting


Le diagramme ci-après représente l’interaction entre le demandeur et le système, afin de
traiter le reporting selon la procédure de la transaction standard ME9A :

Projet de Fin d'Etudes 2010–2011

38
Chapitre III Etude fonctionnelle du projet

Figure 13 - Diagramme de séquences « Traitement du Reporting »

4.2. Module traitement des actions correctives


Le diagramme ci-après représente l’interaction entre le gestionnaire de stocks et le système,
afin de traiter une action corrective selon la procédure de la transaction spécifique ZDELTA :

Projet de Fin d'Etudes 2010–2011

39
Chapitre III Etude fonctionnelle du projet

Figure 14 - Diagramme de séquences « Traitement des actions correctives »

5. Reverse engineering de la base de données


5.1. Traitement du reporting
Vu qu'on traite dans notre cas, le module MM de la logistique, on présentera ci-dessous les
principales données des documents d'achats et des articles utilisés dans l'élaboration de la
demande d'offre, le bon de commande, le programme de livraison (simple ou avec échéances)
sous forme de diagramme de classes.
Projet de Fin d'Etudes 2010–2011

40
Chapitre III Etude fonctionnelle du projet

Les modèles logiques de données présentés ne font qu’une partie d’un modèle colossal du
standard SAP concernant la logistique. La classe EKKO représente l'entête du document d'achat,
quant à la classe EKPO, elle représente le poste du document d'achat. EKET et EKEK ont rapport
avec le programme de livraison. Enfin, EKPA présente le rôle des partenaires dans les achats et
EKKN l'imputation dans le document d'achat.

Figure 15 – Modèle logique de données « Traitement du Reporting »

5.2. Traitement des actions correctives


Concernant le traitement des actions correctives, on présentera ci-dessous le modèle logique
des données représentant en particulier les transactions MIGO (Entrée de marchandises) et MIRO
(Facture) pour l'action corrective de contrôle des quantités de marchandises reçues.

Les différentes tables présentées ne font également qu’une partie principale du modèle
standard SAP concernant la gestion des stocks. La classe MKPF représente l'entête du document
article, quant à la classe MSEG, elle représente le segment du document article. RBKP concerne
l'entête de la facture du fournisseur. Enfin, RSEG présente le poste du document ou plus
précisément l'entrée de facture.
Projet de Fin d'Etudes 2010–2011

41
Chapitre III Etude fonctionnelle du projet

Figure 16 – Modèle logique de données « Traitement des actions correctives »

Projet de Fin d'Etudes 2010–2011

42
Chapitre IV
Architecture logicielle du projet
Ce chapitre est consacré à l’architecture logicielle du projet, à savoir l’étude technique de
la solution et l’environnement de développement du progiciel de gestion intégré SAP, dont on
donnera notamment une présentation au début. On citera par la suite l’ensemble des outils qui ont
permis la réalisation et les transports inter-systèmes SAP des différents modules de la solution.
Chapitre V Architecture logicielle du projet

1. Spécifications techniques
1.1. Architecture physique
Le présent projet est dans l’obligation de répondre à plusieurs contraintes techniques, qui
s’imposent dans le système du client MABROUK, à savoir l’architecture physique qui s’articule
selon la figure suivante :

Figure 17 - Architecture physique


Le projet est déployé dans les serveurs du groupe Mabrouk en Tunisie et s’articule selon trois
systèmes :

DEV100 : Système utilisé pour le développement spécifique


DEV120 : Système utilisé pour le paramétrage et les tests
QAS : Système de qualité et de consolidation
PROD : Système de production (Partie visible du client)

La mise en production du projet devrait donc suivre ce schéma :

Projet de Fin d'Etudes 2010–2011

44
Chapitre V Architecture logicielle du projet

Développement
Tests Projet Reporting et
automatisation des
Modification actions correctives

Système DEV

Tests OK

Tests
Qualité
Test KO
Système QAS

Tests OK

Tests Production
Test KO
Système PROD

Figure 18 - Communication entre les systèmes DEV, QAS et PROD

En outre, le projet, faisant partie du système de production du client MABROUK, doit


répondre à certains critères techniques :

 Conformité : Le code source doit être développé selon les normes MABROUK pour
permettre la traçabilité du travail effectué.
 Efficacité : Le programme doit être performant en temps d’exécution, et sollicitant le
minimum de ressources système et accès à la base de données.
Projet de Fin d'Etudes 2010–2011

45
Chapitre V Architecture logicielle du projet

 Maniabilité : Les solutions réalisées doivent être accompagnées des manuels


d’utilisation, et proposer des scénarios flexibles aux utilisateurs.

Le projet, étant réalisé dans le système SAP, bénéficie de plusieurs avantages et services
natifs, tels que l’interopérabilité, sécurité et testabilité.

1.2. Architecture logicielle


Compte tenu des contraintes techniques citées auparavant, le projet s’articule selon une
architecture dite 3-tiers, qui est composée de trois éléments, ou plus précisément dans ce cadre-là
de trois couches :

Figure 19 - Architecture logicielle


- Le niveau le plus bas est le niveau base de données. Les données y sont gérées grâce à
un système de gestion de base de données relationnelle (RDBMS). Outre les données de
base et les données de mouvement, les programmes et les métadonnées qui décrivent le
système R/3 y sont également stockés et gérés.

Projet de Fin d'Etudes 2010–2011

46
Chapitre V Architecture logicielle du projet

- Les programmes ABAP, qui comprennent aussi bien les applications fournies par SAP
que celles que nous développons nous-même, sont exécutés au niveau application. Ils
exploitent des données appelées au niveau base de données et y stockent de nouvelles
informations.
- Le troisième niveau est le niveau présentation (SAPGUI). Ce niveau comprend
l'interface utilisateur par lequel un utilisateur final peut accéder à une application, entrer
de nouvelles données et recevoir les résultats d'un processus de travail.

La répartition technique du logiciel est indépendante de sa localisation physique dans le


système. Dans le sens vertical, il est possible d'installer tous les niveaux les uns au-dessus
des autres sur un seul ordinateur ou sur des ordinateurs distincts. Dans le sens horizontal,
les composantes des niveaux fonctionnels et présentation peuvent être réparties sur un
nombre x de stations. La distribution horizontale des composantes des bases de données
dépend toutefois du type de base installé, comme le schématise la figure suivante :

Figure 20 - Architecture 3-tiers

Projet de Fin d'Etudes 2010–2011

47
Chapitre V Architecture logicielle du projet

2. Présentation SAP
2.1. SAP AG
SAP AG est le plus important concepteur de logiciels d’Europe, et le quatrième du monde. Il
fournit des systèmes de gestion et de maintenance à des entreprises de toutes tailles dans le
monde entier. Son siège se trouve à Waldorf, en Allemagne, et il dispose de bureaux régionaux
sur les cinq continents. La solution SAP la plus connue est le progiciel de gestion intégrée SAP
ERP.

SAP compte plus de 82 000 clients dans le monde, et 140 000 installations dans 120 pays.
L’approche éco-systémique adoptée par SAP se traduit par la collaboration entre 51 000
employés, dont 13 000 consultants et formateurs et 7 700 techniciens de service et de
maintenance. SAP compte aussi 185 000 employés vacataires, 77 centres de formation, 7 centres
d’assistance internationaux et 9 centres de développement d’applications et de contenu.

2.2. SAP ERP


SAP (Systems, Applications, and Products for data processing en anglais et Systeme,
Anwendungen und Produkte in der Datenverarbeitung en allemand) est par abus de langage
le nom utilisé pour désigner un progiciel de gestion intégré développé et commercialisé par
l'éditeur de ce produit (SAP AG).

Le nom exact du progiciel a été plusieurs fois modifié au fur et à mesure de l'évolution des
versions :

 R/1 puis R/2 (architecture mainframe)


 R/3 (apparition de l'architecture client-serveur, versions 2.1 à 4.6C)
 R/3 Entreprise (dit aussi version 4.70)
 ECC ou ERP Central Component (versions 5.0 puis 6.0)

Projet de Fin d'Etudes 2010–2011

48
Chapitre V Architecture logicielle du projet

Un ERP peut être défini comme un système dans lequel les différentes fonctions de
l'entreprise (comptabilité, finances, production, approvisionnement, marketing, ressources
humaines, qualité, maintenance, etc.) sont reliées entre elles par l'utilisation d'un système
d'information centralisé sur la base d'une configuration client/serveur.

La mise en œuvre d'un système complètement intégré permet de répondre de manière précise et
en temps réel aux questions du type : « Que se passe-t-il si je décide de faire ceci ? ». Par
exemple, si une entreprise reçoit une commande de marchandises, il est possible de savoir
presque instantanément les conséquences de cette demande sur les capacités de production, sur
les besoins d'approvisionnement, sur le personnel nécessaire pour accomplir cette tâche, sur les
délais requis pour satisfaire cette demande, sur les besoins de financement, sur la profitabilité de
cette opération, etc. Les modules sont les composants fonctionnels du système SAP ERP. On peut
distinguer trois familles de modules fonctionnels : logistique, gestion comptable et ressources
humaines. La figure suivante nous montre l’ensemble des composants fonctionnels SAP :

Figure 21 - Système R/3

Projet de Fin d'Etudes 2010–2011

49
Chapitre V Architecture logicielle du projet

3. Environnement de développement
3.1. ABAP Workbench
L’environnement de développement proposé par SAP est ABAP Workbench (Advanced
Business Application Programming). Il est basé sur ABAP, qui est un langage de programmation
propriétaire, faisant partie de l'ensemble logiciel SAP :

- Tous les objets de développement créés avec les outils de développement d’ABAP
Workbench sont classés comme objets du repository et sont stockés de manière centrale
dans le Repository R/3.

- Le Repository R/3 est une partie spéciale de la base de données centrale du système SAP.

- Le Repository s'organise selon l'application. Chaque application est encore subdivisée de


façon logique en classes de développement.

Figure 22 - ABAP Workbench


Projet de Fin d'Etudes 2010–2011

50
Chapitre V Architecture logicielle du projet

3.2. ABAP
ABAP est un langage de programmation propriétaire, faisant partie de l'ensemble logiciel
SAP. Il s'agit actuellement du langage utilisé dans la programmation des Web Application
Server, faisant partie de la plateforme NetWeaver pour la réalisation de progiciels. Le langage a
été par la suite étendu pour englober un modèle de données orienté objet (ABAP Objects) à
partir de sa version 4.5, pour être finalement intégré comme langage d'un produit plus général,
appelé NetWeaver. Ce dernier utilise aussi bien l'ABAP que le Java.

Figure 23 - Langage ABAP

Projet de Fin d'Etudes 2010–2011

51
Chapitre V Architecture logicielle du projet

4. Outils de développement et transport


4.1. Outils de développement
 Composants de l'ABAP Workbench

ABAP Workbench contient différents outils pour le traitement d'objets du Repository. Ces
outils fournissent une large gamme d'assistance qui couvre l'ensemble du cycle de développement
du logiciel. Les outils les plus importants à la création et à l'édition d'objets du Repository sont :

- Éditeur ABAP pour l'écriture et l'édition du code de programme.


- Dictionnaire ABAP pour le traitement des définitions de tables de base de données et la
récupération de types globaux.
- Menu Painter pour la conception d'interface utilisateur (barre de menus, barre d'outils
standard, barre d'outils d'application, allocation des touches de fonction).
- Screen Painter pour la conception d'écrans (programmes dynamiques) de dialogues
utilisateur.
- Form Painter permet de concevoir la mise en page des pages d'un formulaire de type
SmartForm, en incluant des fenêtres et des graphiques sur une page, de déterminer leurs
positions et de choisir la taille de la fenêtre.
- Analyse de performance, via la transaction SE30, nous permet d’analyser les performances
d’un programme (Temps d’exécution système, temps d’accès base de données...) afin
d’optimiser les ressources.
- Debugger, permet d’exécuter le programme étape par étape, afin de s’assurer des données et
traitements effectués ou en cas d’anomalie, de détecter et corriger l’erreur.

 SmartForms

SAP SmartForms a été introduit dans SAP 4.6C sortie à la base comme outil pour la création
et le maintien des formulaires. 

SAP SmartForms permet de créer des formulaires avec leur logique d'exécution en utilisant de
simples outils graphiques. Pour imprimer un formulaire, on a besoin d'un programme d'extraction

Projet de Fin d'Etudes 2010–2011

52
Chapitre V Architecture logicielle du projet

de données et d'un SmartForm qui contient la totalité de la logique (récupération de données et la


logique d'exécution). Le programme d'application transmet les données via une interface module
de fonction au SmartForm. Lors de l'activation du SmartForm, le système génère
automatiquement un module de fonction. A l'exécution, le système traite ce module de fonction. 

A l'aide du Form Painter on peut insérer des tableaux statiques et dynamiques. Cela inclut des
sauts de ligne dans des cellules individuelles, ce qui déclenche des événements pour les titres des
tableaux et sous-totaux, et le tri des données avant la sortie. 

On peut vérifier les nœuds individuels ainsi que le formulaire en entier et de trouver des erreurs
existantes dans l'arborescence. Les contrôles de flux de données d'analyse si tous les champs
(variables) ont une valeur définie au moment où ils sont affichés. SAP Smart Forms permet
d'inclure également des graphiques, qu'on peut afficher soit dans le cadre du formulaire ou dans
l'arrière-plan du formulaire.

Projet de Fin d'Etudes 2010–2011

53
Chapitre V Architecture logicielle du projet

Figure 24 - Ecran initial des SmartForms

4.2. Outils de transport

Les parties du projet sont toujours implémentés dans un système de développement et


transportés ensuite vers le système suivant. Un critère décisif pour la combinaison de parties est
d'ailleurs de savoir quels objets du Repository doivent être transportés ensemble en raison de
leurs dépendances.

Figure 25 - Outils de transport

Les programmes sont affectés à une classe de développement transportable (hors $TMP -
Objets locaux), afin de pouvoir être transportés éventuellement vers les autres systèmes de qualité
et de production.

Une fois le développement (création ou modification) de l’objet du Repository fini, Il faut créer
un ordre de transport sous la transaction SE10 afin d’y stocker les taches effectuées pour enfin le
libérer. Il s’ensuit la création d’une demande de transport pour cet ordre, en précisant les données
(id de l’ordre, système cible, système source, mandant.).

Il est à noter que si la demande en question est à destination du système de production, elle sera
sujette d’une validation de la part de son créateur.

Projet de Fin d'Etudes 2010–2011

54
Chapitre V Architecture logicielle du projet

Dans le système du client Mabrouk, toutes les demandes à destination du système QAS ou PROD
sont transportées grâce à un job périodique, qui s’exécute tout au long de la journée chaque
30minutes (00h0000h3001h0001h30...). Les demandes à destination du système de
production P93 quant à elles, sont transportées manuellement une fois par jour à 18h, tous les
jours ouvrables de la semaine, hormis le vendredi afin d’éviter toute éventuelle anomalie dans le
système de production, pendant le weekend en l’absence de l’équipe HERMES.

Il est à préciser qu’une tâche dont l’ordre de transport est libéré, ne peut aucunement être
modifiée, on doit créer comme alternative une autre tâche qu’on affectera à un nouvel ordre, où
bien au même ordre libéré sous réserve que le transport ne soit pas encore effectué (job de
transport pas encore actif).

5. Conclusion du chapitre
Le présent chapitre nous a permis d’identifier les contraintes techniques, à savoir
l’architecture physique du client MABROUK, dont dépend fortement mon projet, en décortiquant
l’ensemble des systèmes de développement, qualité, et production. Nous avons pu définir ensuite
l’architecture logicielle du projet, qui dépend bien entendu de l’architecture SAP (3-tiers). Il s’est
ensuit une présentation générale de la société mère SAP AG ainsi que son principal produit SAP
ERP, aussi bien la définition de son langage de programmation ABAP, que son environnement de
développement. Nous avons finalement pu connaître les différents outils, permettant le
développement des solutions, ainsi que les transports de/vers les différents systèmes du client
MABROUK.

Projet de Fin d'Etudes 2010–2011

55
Chapitre V
Réalisation
Ce chapitre a pour but de présenter la démarche suivie dans l'élaboration de la solution
proposée dans le cadre du projet, ceci dit, les interfaces utilisateur schématisant les principaux
scénarios, ainsi que les paramétrages effectués permettant la mise en production du projet.
Chapitre V Architecture logicielle du projet

1. Réalisation
1.1. Module du Reporting
1.1.1. Développement

Pour le traitement du Reporting, on se consacrera d'abord au développement du programme


ABAP qui fait appelle au SmartForm (document imprimable) et ensuite nous verrons
l'implémentation du SmartForm et de ces composants associés. Enfin nous expliquerons le
paramétrage des messages qui utilisent ce SmartForm pour créer un document à imprimer.

 Programme ABAP

Pour la demande d'offre, le bon de commande, le programme de livraison (simple ou avec


échéances) il a suffi de créer un seul programme ABAP qu'on a nommé
ZMMFO_BON_COMMANDE, dans lequel on procède sur deux traitements principaux comme
suit:

 Récupération des données

On alimente les différentes tables citées auparavant à savoir EKKO (l'entête du document
d'achat), EKPO (poste du document d'achat), EKET et EKEK (tables concernant le programme
de livraison), EKPA (Rôle des partenaires dans les achats) et EKKN (Imputation dans le
document d'achat), en utilisant des modules fonction standards de sélection. Puis on récupère
également les adresses de l'acheteur (en utilisant le module fonction MM_ADDRESS_GET
MM_ADRESS_GET qui prend en paramètre les données de la table EKKO) et du vendeur (en
utilisant le module fonction VENDOR_MASTER_DATA_SELECT_00 en ayant en paramètre
EKKO-LIFNR : Numéro de compte fournisseur).

 Appel du SmartForm

L'appel du SmartForm s'effectue sur deux temps en utilisant premièrement le module


fonction SSF_FUNCTION_MODULE_NAME pour récupérer le nom de la fonction
génératrice associé au SmartForm qu'on met en paramètre à un autre module fonction d'envoi des
données de tables récupérées auparavant.

Projet de Fin d'Etudes 2010–2011

57
Chapitre V Architecture logicielle du projet

 SmartForm

La figure ci-dessous montre les trois différentes zones du formulaire de SAP Builder:


 L'arborescence de navigation (structure hiérarchique d'un SmartForm) sur la gauche.
 L'écran de maintenance dans le milieu. 
 Le Form Painter sur la droite.
Quand on sélectionne un arbre dans le nœud, le système met à jour l'écran de maintenance et
marque la fenêtre correspondante dans le Form Painter. On peut également sélectionner une
fenêtre directement dans le Form Painter, le système ainsi le nœud approprié dans l'arborescence.

Figure 26 - SAP Form Builder


Après avoir récupérer les données émis par le programme depuis l'interface du formulaire, on
procède à la mise en forme du formulaire à l'aide du Form Painter à droite du SAP Form Builder,
puis à l'alimentation des différentes fenêtres en utilisant les données récupérés.

Pour les quatre formulaires traités par ce SmartForm, ils possèdent tous la même mise en forme
suivante :

 Entête de la page contenant le titre (suivant le document traité) le logo et l'adresse de la


société qui effectue l'achat (suivant la société) et enfin l'adresse du destinataire (qui
dépend du fournisseur)
Projet de Fin d'Etudes 2010–2011

58
Chapitre V Architecture logicielle du projet

 Fenêtre principale contenant les données des articles à acheter (Code article,
désignation, unité, quantité demandée). C'est une fenêtre qui génère dynamiquement des
pages en fonction du volume des données à afficher.
 Pied de page contenant le cachet de la société, les totaux (TTC, Net, TVA) et les logos
des pieds de page en fonction de la société passée en paramètre.
1.1.2. Paramétrage

Ainsi afin de tester si le document imprimable se génère d'une manière cohérente et


conforme aux exigences fonctionnelles et techniques. On crée une demande d'achat à l'aide de la
transaction standard ME51N soit en remplissant à zéro les données d'entête de la demande d'achat
et puis les données des postes - articles, soit en copiant une demande d'achat existante depuis la
fenêtre « Synthèse des documents » si l'achat va concerner les mêmes articles demandés.

Figure 27 - Transaction ME51N pour la création d'une demande d'achat


Après la création de la demande d'achat, on peut lui associer une demande d'offre si on n'a pas un
fournisseur de confiance, ou si les articles vont être achetés pour la première fois. La transaction
avec laquelle on va créer la demande d'offre est ME41 en données en entrée à l'écran de sélection
le type de la demande d'offre, le délai, les données d'organisation (Organisation d'achat, Groupe
d'acheteurs) et les données par défaut des postes - articles (Type d'article, Date de livraison,
Projet de Fin d'Etudes 2010–2011

59
Chapitre V Architecture logicielle du projet

Division, Magasin,...),. Des aides à la recherche existent en général pour chaque champ de la
transaction pour éviter de taper à chaque fois les données d'achat à la main. Cette demande d'offre
est enfin associée à la demande d'achat qu'on a créé auparavant.

Figure 28 - Transaction ME41 pour la création de la demande d'offre

Après la création de la demande d'offre sur le système, on peut à présent générer son document
imprimable à l'aide de la transaction ME9A d'édition de message des demandes d'offres en
données en entrée de l'écran de sélection les données du document d'achat (N° de document,
Fournisseur, Organisation d'achats, Groupe d'acheteurs,...) et ceux du message (Application EA
pour : Achat Demande d'offre, Dates d'envoi et de création,...).

Projet de Fin d'Etudes 2010–2011

60
Chapitre V Architecture logicielle du projet

Figure 29 - Transaction ME9A d'édition de messages des demandes d'offre

On peut choisir d'afficher tous les demandes d'offres, ou soit de sélectionner à partir de données
relatifs à une demande d'offre bien spécifique. Dans le cas où on veut afficher tous les messages,
on aura la liste suivante :

Figure 30 - Liste des messages d'impression des demandes d'offre

Projet de Fin d'Etudes 2010–2011

61
Chapitre V Architecture logicielle du projet

Une fois choisit une demande d'offre, on peut donc choisir d'afficher le message pour ainsi avoir
un aperçu avant impression de la demande d'offre. Un ordre de spool sera aussi créé en cas de
l'impression du document qu'on pourrait utiliser par la suite pour impression ultérieure,
conversion en PDF ou encore envoi par mail du document. La demande d'offre aura la forme
suivante :

Figure 31 - Demande d'offre « Aperçu avant impression »

Projet de Fin d'Etudes 2010–2011

62
Chapitre V Architecture logicielle du projet

Après la création de la demande d'offre, et le choix du fournisseur vient la partie commande et la


création du bon de commande. En effet, à l'aide de la transaction ME21N on peut créer une
commande d'achat soit à partir d'une commande d'achat existante à l'aide de la « Synthèse des
documents », ou soit en donnant tous les données nécessaires concernant l'entête de la
commande, les articles commandées, les données de livraison et facture et les données
organisationnelles.

Figure 32 - Transaction ME21N pour la création d'une commande d'achat

Après avoir créé la commande d'achat, on peut donc générer le bon de commande à l'aide de la
transaction d'édition de messages ME9F qui ressemble à la transaction de génération des
demandes d'offre. Ainsi après la visualisation de la liste des commandes d'achats. On choisit
d'afficher le message si jamais on a envie d'avoir un aperçu avant impression du document qu'on
veut imprimer. Ensuite l'impression générera comme pour la demande d'offre un ordre de spool
avec lequel on peut l'utiliser pour une impression ultérieure ou l'envoi par mail du document par
exemples. Le bon de commande qu'on générera aura la forme suivante :

Projet de Fin d'Etudes 2010–2011

63
Chapitre V Architecture logicielle du projet

Figure 33 - Commande d'achat « Aperçu avant impression »

Pour la génération du programme de livraison on aura à utiliser la transaction ME9L pour les
programmes de livraisons simples et la transaction ME9E pour les programmes de livraison avec
échéances.

Projet de Fin d'Etudes 2010–2011

64
Chapitre V Architecture logicielle du projet

1.2. Module d'automatisation des actions correctives


Pour le développement de l'automatisation des actions correctives, nous allons définir les
étapes de développement de l'ajustement d'écart concernant le cas (définit précédemment) où la
quantité reçue du fournisseur et différente de la quantité commandée par l'entreprise.

Ce module a été développé en utilisant un programme ABAP et un Dynpro comme suit:

 Programme ABAP

Ce programme est chargé dans un premier temps d'afficher un écran de sélection pour la
récupération du N° de la commande d'achat et du N° de poste du document d'achat afin de
sélectionner la ligne qui représente la commande d'achat concerné par l'ajustement.

Figure 34 - Ecran de sélection du programme d'ajustement d'écart


Une fois l'utilisateur remplit l'écran de sélection et clique sur F8 pour valider, un Dynpro
représentant la commande d'achat sera affiché afin de donner l'écart de l'ajustement.

Projet de Fin d'Etudes 2010–2011

65
Chapitre V Architecture logicielle du projet

 Dynpro

Le Dynpro qu'on a créé a comme Screen 0100 contenant une table controle pour saisir les
données d'ajustement et leurs appliquer des contrôles nécessaires au bon fonctionnement des
traitements.

Figure 35 - Dynpro d'ajustement d'écart


Une fois l'utilisateur effectue les saisies nécessaires à l'ajustement (Lot, Delta, Date de
l'ajustement,...). Un traitement aura dépendant de l'écart (Positif /Négatif) aura lieu comme suit:

Si Delta est positif

 Annulation de réception MIGO


 Avoir MIRO
 Chargement ultérieur MIRO
Si Delta est négatif

 Réception complémentaire MIGO


 Facture complémentaire MIRO
 Déchargement ultérieur MIRO
MIGO et MIRO sont les deux transactions dont la saisie a été automatisée.

Projet de Fin d'Etudes 2010–2011

66
Chapitre V Architecture logicielle du projet

Figure 36 - Transaction MIGO pour la réception de marchandises

Figure 37 - Transaction MIRO pour la création de facture/chargement

Projet de Fin d'Etudes 2010–2011

67
Conclusion
Le stage que j’ai effectué au sein de ValuePass Consulting, dans le cadre du projet
HERMES 2011, consistait en l’étude, la conception et la réalisation d’une solution pour le
reporting et l'automatisation des actions correctives. Ce projet s’aligne avec les plans stratégiques
actuels des entités concernées ; Améliorer la productivité du client MABROUK à travers la
rentabilité du contrat HERMES de ValuePass.

En effet, le principal besoin exprimé par les intervenants, évoquait la notion du temps comme
facteur principal, qui leur permettra de maitriser les coûts et passer de la phase de réactivité à la
pro activité, afin d’anticiper les anomalies, se focaliser sur les analyses et éradiquer les tâches
redondantes, pour assurer la satisfaction client d’un côté et gagner en productivité de l’autre côté.

L’intégralité du projet a été réalisée, répondant ainsi à l’ensemble des attentes du client, à savoir
la qualité des développements spécifiques et le gain en temps d'exécution et a ainsi offert aux
différents acteurs une flexibilité aussi bien technique que fonctionnelle.

Des perspectives s’annoncent notamment pour le projet, à savoir l’automatisation complète du


volet des actions correctives.
Bibliographie & Webographie
But Source
ABAP dictionnaire Formation ValuePass: ABAP dictionnary 1 & 2
ABAP Workbench Formation ValuePass: BC 400
ABAP Avancé Formation ValuePass: ABAP avancé 1 & 2 & 3
http://www.abapprogramming.net/
SAP SmartForms eBook: BC-SRV-SCR
Dynpros Formation ValuePass: Screen Painter
Forum de discussion SAP http://forums.sdn.sap.com/
http://www.sap-integration.net/
Définitions des outils http://fr.wikipedia.org/
http://www.sap.com/
SAP Module Logistique http://www.logistiqueconseil.org/
SAP Transactions fonctionnelles http://www.faq-logistique.com/

Projet de Fin d'Etudes 2010–2011

69
Annexes

Annexe A: Plan Assurance Qualité

Projet de Fin d'Etudes 2010–2011

70
Plan d’Assurance Qualité
Logicielle

Reporting et Automatisation des actions


correctives

Date  :  16/04/2011

Version :  1.3

Statut : Final

Auteur : Younes ASRI

Projet de Fin d'Etudes 2010–2011

71
Table de révisions
Version Date Auteur Modification
0.1 16/04/2011 Y.ASRI Création du document
0.2 22/04/2011 M.AHAZZAM Revue du document

0.3 03/05/2011 Y.ASRI Correction du document

Projet de Fin d'Etudes 2010–2011

72
1. But, portée, responsabilité

1.1 Objectif du document


Le plan d'assurance qualité (PAQL) a pour but de définir les méthodes et outils utilisés par
le projet, ainsi que les mesures à prendre et les étapes pour contrôler et s'assurer  de la qualité du
projet.

Tout document produit sera soumis au contrôle de qualité. Il devra être conforme aux  règles
définies dans ce document. Tout document non conforme devra être corrigé.

1.2 Portée du document


Ce document est destiné :

 Au Manager technique : MOHAMED AHAZZAM


 Au responsable de la formation  : RADDOUANE CHIHEB
 Au Responsable du module MM : AMAL OUADY

1.3 Procédures d’évolution du PAQL


Le PAQL est élaboré au début du projet. A chaque étape, il est susceptible  d’être modifié,
auquel cas la modification sera indiquée dans la table des révisions.

2. Documentation utilisée

2.1 Documents de référence


Le tableau suivant récapitule les principales sources documentaires qui seront  utilisées
dans le cadre de ce projet :

But Source
ABAP dictionnaire Formation ValuePass: ABAP dictionnary 1 & 2
ABAP Workbench Formation ValuePass: BC 400
ABAP Avancé Formation ValuePass: ABAP avancé 1 & 2 & 3
SAP SmartForms eBook: BC-SRV-SCR
Dynpros Formation ValuePass: Screen Painter

Projet de Fin d'Etudes 2010–2011

73
Forum de discussion SAP http://forums.sdn.sap.com/
SAP Module Logistique http://www.logistiqueconseil.org/
SAP Transactions fonctionnelles http://www.faq-logistique.com/

3. Terminologie
Abréviatio
Désignation
n
ABAP Advanced Business Application Programming
DYNPRO DYNamisches Program (programme dynamique)
ERP Enterprise Resource Planning
MOA Maitrise d’ouvrage
MOE Maitrise d’œuvre
2 TUP 2 Track Unified Process
SAP Systems, Applications, and Products for data processing
UML Unified Modeling Language

4. Organisation

4.1 Maitrise d'ouvrage


La maitrise d'ouvrage se compose d'une équipe technique et d'une équipe fonctionnelle
représentés respectivement par Mr. MOHAMMED AHAZZAM et Mme. AMAL OUADY.

4.2 Maitrise d'œuvre

La maitrise d'œuvre est assurée par l’élève ingénieur Younes ASRI, qui aura pour but de
concevoir et réaliser une solution pour le Reporting et l'automatisation des actions correctives en
vue de satisfaire les besoins de la MOA. Pour ce faire :

 Tous les documents demandés doivent être fournis.


 Le planning doit être observé et réajusté d’un commun accord si besoin.
 Les normes sont définies et doivent être respectées.

Projet de Fin d'Etudes 2010–2011

74
 Les validations se font conformément avec le PAQL.

5. Cycle de vie
5.1 Justification du choix
On a opté pour un cycle de vie en Y assuré par la méthode 2TUP, qui va garantir une
simplicité de mise en place et un processus itératif qui permettra la séparation des branches
fonctionnelles et techniques. Le produit final sera livré par lots successifs ce qui permettra
d’avoir en outre un cycle de vie incrémental.

Projet de Fin d'Etudes 2010–2011

75
5.2 Description des étapes de cycle de vie

 Branche fonctionnelle, comportant les deux phases suivantes :

Projet de Fin d'Etudes 2010–2011

76
 Capture des besoins fonctionnels, qui produit le modèle des besoins focalisé sur le
métier des utilisateurs. Elle qualifie, au plutôt le risque de produire un système
inadapté aux utilisateurs.
 L’analyse, qui consiste à étudier précisément la spécification fonctionnelle de
manière à obtenir une idée de ce que va réaliser le système en terme de métier.
 Branche architecture technique qui quant à elle comporte les deux phases suivantes :
 La capture des besoins techniques, qui recense toutes les contraintes sur les choix
techniques du système. Les outils et le matériel sélectionné ainsi que la prise en
compte des contraintes d’intégration avec l’existant (pré requis d’architecture
technique).
 La conception générique, qui définit ensuite les composants nécessaires à la
construction de l’architecture technique. Cette conception est complètement
indépendante des aspects fonctionnels. Elle a pour objectif d’uniformiser et de
réutiliser les mêmes mécanismes pour tout système.

L’architecture technique construit le squelette du système, son importance est telle qu’il est
conseillé de réaliser un prototype.

 Et enfin la branche conception dont les phases sont les suivantes :


 La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d’analyse fonctionnelle dans l’architecture technique de manière à tracer la
cartographie des composants du système à développer ;
 La conception détaillée, qui étudie ensuite comment réaliser chaque composant ;
 L’étape de codage, qui produit ses composants et teste au fur et à mesure les unités de
code réalisées ;
 L’étape de recette, qui consiste enfin à valider les fonctionnalités du système
développé.

6. Méthodes, outils, règles et normes


6.1 Méthodes
Le langage de modélisation unifié UML sera utilisé pendant toutes les phases d’analyse du
projet. La préparation des tests se fera dès les premières étapes :
Projet de Fin d'Etudes 2010–2011

77
 Analyse des besoins  : Tests d’acceptation
 Spécifications : Tests système
 Conception globale : Tests d’intégration
 Conception détaillée : Tests unitaires

6.2 Outils

Fonctions Outils
Lay-out des dialogues utilisateurs Screen Painter
Gestion des menus utilisateurs Menu Painter
Design des formulaires Form Painter
L’exécution par étape des programmes Débogueur
Dictionnaire de données ABAP ABAP DDIC
Programmes dynamiques Dynpro
Développement des programmes ABAP Editeur ABAP

L’ensemble de ces outils est fourni par ABAP Workbench et SmartForms et permettra la
structuration des programmes et des formulaires pour une bonne compréhension en cas
d’éventuelle modification ainsi que l’adaptation à l’environnement du système SAP.

6.3 Règles et normes


La solution sera développée en langage ABAP elle devra donc respecter les normes du
standard SAP à savoir le nommage des développements spécifiques qui doivent toujours
commencer par un 'Z' ou un 'Y'. En outre les programmes devront respecter les normes de
nommage spécifique à MABROUK.

Projet de Fin d'Etudes 2010–2011

78
Annexe B: Outils de modélisation

Projet de Fin d'Etudes 2010–2011

79
Présentation d'UML
UML est un langage de modélisation objet assurant un
certain niveau d’abstraction, mais aussi pertinent de la réalité.
Issu de la fusion des méthodes objets dominantes (OMT, Booch
et OOSE), puis normalisé par l’OMG en 1997, UML s’est
rapidement imposé comme un standard incontournable dans le
monde du génie logiciel.

UML n’est pas à l’origine des concepts objet, mais il en donne une définition plus
formelle et apporte la dimension méthodologique qui faisait défaut à l’approche objet. UML
définit maints diagrammes pour donner à l’utilisateur les moyens de visualiser et manipuler les
éléments de modélisation.

 UML se décompose en plusieurs sous-ensembles


o Les vues : Les vues sont les observables du système. Elles décrivent le système
d'un point de vue donné, qui peut être organisationnel, dynamique, temporel,
architectural, géographique, logique, etc. En combinant toutes ces vues, il est
possible de définir (ou retrouver) le système complet.
o Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci
décrivent le contenu des vues, qui sont des notions abstraites. Les diagrammes
peuvent faire partie de plusieurs vues.
o Les modèles d'élément : Les modèles d'élément sont les briques des diagrammes
UML, ces modèles sont utilisés dans plusieurs types de diagramme. Exemple
d'élément : cas d'utilisation (CU ou cadut'), classe, association, etc.

Présentation du Reverse engineering


La rétro-ingénierie s'applique au logiciel comme au progiciel. Ceci peut être réalisé en
utilisant des outils d'analyse comme le désassembleur ou le dé compilateur. Les méthodes
employées sont similaires à celle du débogage.

Projet de Fin d'Etudes 2010–2011

80
La rétro-ingénierie logicielle est fréquemment appliquée aux structures de données : il s'agit,
dans ce cas de figure, d'effectuer une rétro documentation des structures de données physiques
peu ou mal documentées (applications vieillissantes). On essaie de reconstituer un modèle de
données à partir des structures physiques des fichiers ou des tables.

La rétro-ingénierie logicielle fut popularisée avec le détournement des protections anti


copie des jeux vidéo. Cette activité est appelée craking.

En cryptographie, la rétro-ingénierie prend plusieurs formes avec des attaques


cryptanalytiques. Le but est d'extraire des informations secrètes depuis la « boîte noire »
symbolisant la procédure de chiffrement.

Projet de Fin d'Etudes 2010–2011

81

Vous aimerez peut-être aussi