Pfe Chaimae Echchrif

Mémoire de Projet de Fin d’Études
Pour l’obtention du diplôme
Ingénieur d’État
Génie
Intégration et adaptation d’une solution SAP ABAP

pour le déroulement du flux de vente
Informatique
Promotion 2020 – 2021
M. /Mlle. Chaimae ECHCHRIF
Soutenu le :
28 Juin 2021
Membres de jury :
INTÉGRATION ET ADAPTATION D’UNE SOLUTION SAP ABAP POUR LE DÉROULEMENT DU FLUX
DE VENTE
Pr. CHRAYAH Mohamed Professeur ENSATé (Président)

Pr. AL ACHHAB Mohammed Professeur ENSATé (Examinateur)
M. EZ-ZAYATTE Zakaria Encadrant société
Pr. EL BOUHDIDI Jaber Encadrant ENSATé
Dédicaces
Du profond de mon cœur, je dédie ce travail à tous ceux qui me sont chers, À ma très
chère mère Saaïdia,qui m'a entouré d'amour, de soutien, et qui a œuvré pour ma réussite,
toute son assistance et sa présence dans ma vie, tous les sacrifices consentis et ses
précieux conseils, reçois à travers ce travail aussi modeste soit-il, l'expression de mes
sentiments et de mon éternelle gratitude.
À Mon cher père Mekki,Qui peut être fier et trouver ici le résultat de longues années de
sacrifices et de privations pour m'aider à avancer dans la vie. Puisse Dieu faire en sorte
que ce travail porte son fruit.
à Mes grandes sœurs Fatima et zineb ,mon frère Abdou, ma source de sécurité.Les
personnes qui m’ont consolidé afin de réaliser mes attentes et qui m’ont dirigé vers la
bonne voie de récolte des rêves.
A mes professeurs, enseignants, formateurs et tout le personnel de l'École Nationale des

Sciences Appliquées de Tétouan,
A toutes ces personnes qui ont fait de ma vie un instant de bonheur et qui ont partagé
mes joies et mes peines.
A tous mes ami(e)s, en témoignage de l’amitié sincère qui nous a liées et pour les bons
moments passés ensemble. Je vous dédie ce travail en vous souhaitant un avenir radieux
et plein de bonnes promesses.
Chaimae ECHCHRIF 2020-2021

DE VENTE
Remerciements
Ce n’est pas parce que c’est un rituel que je commence ce rapport par l’assurance de
mes immenses gratitudes à tous ceux qui m’ont épaulé pour l’accomplir, mais c’est
parce que je suis consciente de l’importance d’avouer ma louange à Dieu et à toutes
personnes sans lesquelles ce rapport n’aurait pu voir le jour. Mes remerciements les plus
cordiaux s’adressent à l’ensemble du corps professoral et administratif de l’Ecole
nationale des sciences appliquées de Tétouan pour l’inestimable qualité de
l'enseignement qui m’a été dispensée.
Je tiens à exprimer mes remerciements et mon profond respect à notre éminent

encadrant académique, M. Jaber EL BOUHDIDI, enseignant à l’ENSA Tétouan, qui
malgré les occupations et les responsabilités, a toujours consacré du temps pour nous
écouter et nous donner ses conseils.
Je tiens à remercier mon maître de stage, M. Zakaria EZ-ZAYATTE chef de

l’équipe technique INWI SAP chez ValuePass, pour son accueil et le partage de son
expertise au quotidien. Il m’a aidé à s’orienter dans une période très délicate et grâce à
lui j’ai pu découvrir la technologie SAP et ses perspectives comme étant une
compétence très demandée sur le marché de travail. Grâce aussi à sa confiance j'ai pu
m'accomplir totalement dans mes missions.
Je tiens à remercier en particulier M. Karim SEFIANI le directeur de l’équipe

technique, pour toutes les connaissances qu’il m’a apportées tout au long du stage.
Ainsi, mes remerciements les plus sincères vont à Anir MOUNTASSER consultant
technique au sein de ValuePass pour son estimable aide et ses précieux conseils.
Un grand merci à toute l’équipe technique et tout le personnel de ValuePass

Consulting, pour leur convivialité, leur soutien et leur contribution à ce travail. Ce fût
un réel plaisir de travailler à vos côtés chaque jour.

DE VENTE
Résumé
Le présent rapport constitue le fruit du travail accompli dans le cadre de mon projet de
fin d’études au sein de la société Valuepass Consulting. L’objectif fixé est de concevoir
et réaliser une solution SAP pour mieux gérer le flux de vente de la société INWI
(client de Valuepass) .
L’objectif principal de ce projet est de présenter les deux volets SAP dans le cadre de
son module SD (administration de ventes), l’un consiste à mettre en place le côté
paramétrage du module SD, le second comprend la partie technique, avec le
développement des solutions ABAP ,il s’agit en premier lieu d’intégrer le module SD
dans la solution SAP, tout en paramétrant sa structure organisationnelle ainsi que des
parties du flux SD.
La deuxième partie du projet a pour but de de concevoir et de réaliser une

application SAP devloppée avec la langage ABAP a fin de simplifier le déroulement du
flux d’achat depuis la création de la commande de vente jusqu’à sa livraison et
facturation .
Afin de bien comprendre le fonctionnement du système, nous avons d’abord procédé

par une formation sur l’environnement de SAP, son mode d’emploi à travers les
transactions, puis par étude conceptuelle des besoins déclinés par la problématique.
Par la suite nous avons réalisé une analyse préliminaire pour bien cerner la
problématique.
Après, une étude fonctionnelle et technique pour mieux comprendre et assimiler les
exigences du projet.
Enfin la partie de paramétrage et la réalisation pour mettre en place et finaliser le

travail demandé.
Ce rapport vise donc à décrire de manière détaillée les différentes étapes qui ont
permis la réalisation de ce projet.

DE VENTE
Mots clés : ERP, SAP, ABAP, vente et distributions, Flux de vente

DE VENTE
Abstract
This report is the result of the work done during my final year project at Valuepass
Consulting. The objective is to design and implement an SAP solution to better manage the
sales flow of the company INWI (Valuepass customer).
The main objective of this project is to present the two SAP components within the
framework of its SD module (sales administration), one consists of setting up the
parameterisation side of the SD module, the second includes the technical part, with the
development of ABAP solutions, it is a question first of integrating the SD module into the
SAP solution, while parameterising its organisational structure as well as parts of the SD
flow.
The second part of the project aims to design and implement an SAP application
developed with ABAP in order to simplify the purchase flow from the creation of the sales
order to its delivery and billing.
In order to understand the functioning of the system, we first proceeded with a training
on the SAP environment, its mode of use through the transactions, and then by a
conceptual study of the needs defined by the problem.
We then carried out a preliminary analysis to clearly define the problem.
Then, a functional and technical study to better understand and assimilate the project
requirements.
Finally, the parameterisation and realisation part to implement and finalise the work
required.
This report therefore aims to describe in detail the different stages that enabled the
realisation of this project.
Key words :ERP, SAP, ABAP, sales and distributions, Sales flow
CHAIMAE ECHCHRIF VI
DE VENTE
Table des Matières
Introduction Générale............................................................................................................
Chapitre 1 Contexte général du projet...................................................................................
1.1Organisme d’accueil........................................................................................................
1.1.1 Présentation générale de l’Entreprise...........................................................4
1.1.2 Missions de l’entreprise................................................................................5
Conseil en Management & Organisation :...............................................................6
Conseil et intégration ERP :.....................................................................................7
1.1.3 Solutions autorisées :....................................................................................8
1.2Clients de Value Pass.......................................................................................................
1.2.1 Organigramme............................................................................................10
1.2.2 Fiche technique :.........................................................................................11
1.3Présentation du projet....................................................................................................
1.3.1 Périmétre du projet.....................................................................................12
1.3.2 Présentation du client.................................................................................13
1.3.3 Cadre du projet...........................................................................................14
1.4Problématique................................................................................................................
1.5Solution proposée...........................................................................................................
1.5.1 Objectifs du projet......................................................................................17
1.6Gestion du projet............................................................................................................
1.6.1 Le choix du processus de développement :................................................18
1.6.2 Processus 2TUP..........................................................................................19
1.6.3 Planification du projet................................................................................20
1.7Conclusion.....................................................................................................................
CHAIMAE ECHCHRIF vii

DE VENTE
Chapitre 2 Spécification des exigences fonctionelles et techniques...................................
1.Analyse et identification des besoins...............................................................................
1.1. Étude de l’existant (Le AS IS)................................................................................
1.2Critique de l’existant......................................................................................................
1.3Expression de besoin (Le TO BE).................................................................................
1.4Diagramme Bête à corne................................................................................................
1.5Spécification des besoins...............................................................................................
1.5.1 Etude fonctionnelle générale......................................................................27
1.5.2 Informations générales...............................................................................27
1.5.3 Synthèse fonctionnelle du développement.................................................28
1.5.4 Ecran de sélection.......................................................................................28
1.5.5 Logique de sélection...................................................................................28
1.5.6 Maquette du Formulaire.............................................................................28
1.5.7 Règles de gestion détaillées........................................................................29
1.6Identification des processus à paramétrer......................................................................
1.7Spécification des exigences non-fonctionnelles............................................................
1.8Phase de conception.......................................................................................................
1.9Analyse des Besoins......................................................................................................
1.9.1 Cas d’utilisation (Use case)........................................................................34
1.9.2 Diagramme d’activité.................................................................................35
1.9.3 Diagramme de séquence.............................................................................36
1.10 Spécifications techniques : la solution SAP...........................................................
1.11 Vue générale de SAP..............................................................................................
1.11.1 Architecture modulaire...........................................................................38
1.12 Mise en place de la solution SAP...........................................................................
1.12.1 Mode de déploiement..............................................................................38
1.13 Conclusion..............................................................................................................
CHAIMAE ECHCHRIF viii

DE VENTE
Chapitre 3 Déploiement de SAP……………………………………………………….40

1. .Progiciel de gestion intégré-ERP :................................................................................
1.1.Définition......................................................................................................................
1.2.Enjeux............................................................................................................................
1.3.Avantages......................................................................................................................
1. Architecture physique :..................................................................................................
1.7architecture logicielle SAP............................................................................................
1.7.1 Architecture technique :.............................................................................46
1.7.2 SAP S/4 HANA..........................................................................................47
1.8Architecture modulaire..................................................................................................
2. Présentation du module SD............................................................................................
3. Paramétrage SD chez inwi.............................................................................................
3.1 Paramétrage de la structure organisationnelle SD.........................................................
3.2 Paramétrage du Flux de Vente INWI :..........................................................................
4. Création d’une Commande client INWI....................................................70
5. Conclusion....................................................................................................73
Chapitre 4 Réalisation …………………………………………………………...…….74

1. Environnement de développement..................................................................................
1.1ABAP Workbench.........................................................................................................
1.2Langage ABAP..............................................................................................................
1.2.1 Formulaire Bon livraison............................................................................84
1.3Application.....................................................................................................................
1.3.1 Création type de données............................................................................85
1.3.2 Création du programme..............................................................................86
Logique de sélection............................................................................................................
1.3.3 Création des transaction.............................................................................88
1.3.4 Création d’interface et formulaire..............................................................88
CHAIMAE ECHCHRIF ix
DE VENTE
1.4Tests...............................................................................................................................
1.4.1 Création d’une commande client................................................................91
1.4.2 Création livraison.......................................................................................93
1.4.3 Creation de la facture :...............................................................................96
1.5Conclusion.....................................................................................................................
Références........................................................................................................................101
CHAIMAE ECHCHRIF x
DE VENTE
Liste des Figures

Tableau 1.1. Une partie des Clients Value Pass............................................................10
Tableau 1.2. Fiche technique Valuepass........................................................................12
Tableau 1.3. Tableau QQOQCP.....................................................................................16
Tableau 2.1 Information générales.................................................................................28
Tableau 2.2. données ecran de selections.......................................................................28
Tableau 2.3. régles de gestion et specifications ……………………………………….31
Figure 1.1. Logo de Valuepass Consulting......................................................................5

Figure 1.2. Cartographie de Valuepass Consulting..........................................................6
Figure 1.3. Historique de Valuepass Consulting..............................................................9
Figure 1.4. Organigramme de Valuepass Consulting.....................................................11
Figure 1.5. Logo INWI...................................................................................................13
Figure 1.6.Le client inwi…………………………………………………...…………..14
Figure 1.7. solution d’integration de flux de vente........................................................17
Figure 1.8. Process de développement...........................................................................19
Figure 1.9.Cycle de vie en Y……………………………………………...…………..20
Figure 1.10. Diagramme de GANTT…………………………………………………..21
Figure 1.11. Diagramme de GANTT.............................................................................22
Figure 2.1. Diagramme bête a corne..............................................................................27
Figure 2.2. Maquette de bon de livraison.......................................................................29
Figure 2.3. Diagramme de cas d’utilisations..................................................................34
Figure 2.4. Diagramme d’activité d’impression formulaire...........................................35
Figure 2.5. Diagramme d’activité vérification des données...........................................36
Figure 2.6.Diagramme de séquence...............................................................................37
Figure 2.7. Mise en place solution SAP.........................................................................38
Figure 3.1. Architecture modulaire d’ERP.....................................................................42
Figure 3.2. Répartition des ERP dans le marché mondial..............................................43
Figure 3.3.Environnement de travail..............................................................................44
Figure 3.4. environnement de travail SAP ....................................................................44
CHAIMAE ECHCHRIF xi
DE VENTE
Figure 3.5.procedure de mise en œuvre du projet..........................................................45

Figure 3.6. Architecture technique SAP.........................................................................46
Figure 3.7. LOGO SAP S/4 HANA...............................................................................47
Figure 3.8.Architecture modulaire SAP........................................................................49
Figure 3.9.Flux de vente et distribution..........................................................................49
Figure 3.10. Flux global de processus de vente..............................................................50
Figure 3.11 Organisation structurelle SD.......................................................................51
Figure 3.12. Les fonctions partenaires...........................................................................54
Figure 3.13. BD pour module SD...................................................................................55
Figure 3.14 Modulisation des données...........................................................................55
Figure 3.15.Codes transactions d’un flux SD.................................................................56
Figure 3.16 Guide d’implementation.............................................................................58
Figure 3.17. Création d’une nouvelle organisation........................................................58
Figure 3.18. Details des objets crées..............................................................................59
Figure 3.19. Copier une organisation comercielle..........................................................59
Figure 3.20. Modification d’une organisation................................................................60
Figure 3.21. Définition d’un canal de distribution.........................................................60
Figure 3.22. Définition d’un secteur d’activité..............................................................61
Figure 3.23 Définition d’une société..............................................................................62
Figure 3.24.Définition d’un magasin..............................................................................62
Figure 3.25. Guide d’implémentation............................................................................63
Figure 3.26. Affectation d’organisation à la societé.......................................................64
Figure 3.27. Démarche d’affectation..............................................................................65
Figure 3.28. Types d’objets SAP sur flux de ventes......................................................65
Figure 3.29. point d’adaptation......................................................................................67
Figure 3.30. Paramétrage données client........................................................................68
Figure 3.31. Données générales client............................................................................68
Figure 3.32. Définir les types de commandes................................................................69
Figure 3.33. Types de commande client.........................................................................69
Figure 3.34. Créer commande client .............................................................................70
Figure 3.35. Affectation de type de poste......................................................................70
Figure 3.36. Créer condition client livraison..................................................................71
Figure 3.37.Information generales de vente...................................................................72
Figure 4.1. ABAP Workbench......................................................................................75
CHAIMAE ECHCHRIF xii

DE VENTE
Figure 4.2. Structure Adobe Form..................................................................................79

Figure 4.3 Transaction SFP............................................................................................79
Figure 4.4.Creation formulaire.......................................................................................80
Figure 4.5.Propriétés du formulaire................................................................................81
Figure 4.6. Composantes de l’interface du formulaire...................................................81
Figure 4.7.Les données du contexte du formulaire........................................................82
Figure 4.8. Les donées du mise en form.........................................................................83
Figure 4.9. Types de
données………………………………………………………......85
Figure 4.10. ZSD_BON_LIV_TOP...............................................................................86
Figure 4.11. ZSD_BON_LIV_TOP...............................................................................86
Figure 4.12. ZSD_BON_LIV_SEL................................................................................87
Figure 4.13. ZSD_BON_LIV_F01.................................................................................87
Figure 4.14. Création transaction...................................................................................88
Figure 4.15. Création d’interface....................................................................................88
Figure 4.16. Déclaration des données.............................................................................89
Figure 4.17. Déclaration des importations.....................................................................89
Figure 4.18. Création du formulaire...............................................................................89
Figure 4.19. Drag and drop.............................................................................................90
Figure 4.20. Mise en forme............................................................................................90
Figure 4.21. Module fonction BAPI...............................................................................91
Figure 4.22. Création commande...................................................................................92
Figure 4.23. Ecran de selection pour creation livraison.................................................93
Figure 4.24.SElection du num de commande.................................................................93
Figure 4.25. Messages de creation de bon de livraison..................................................94
Figure 4.26. Bon de livraison.........................................................................................94
Figure 4.27. Gabarits et mise en form du bon de livraison............................................95
CHAIMAE ECHCHRIF xiii

DE VENTE
Figure 4.28. Programme creation facture.......................................................................96

Figure 4.29. Ecran de selection pour creation de la facture...........................................96
Figure 4.30. Creation de la facture.................................................................................96
Figure 4.31. Mise en forme formulaire de la facture......................................................97
Figure 4.32.Interface du formulaire facture...................................................................97
Figure 4.33. Facture imprimée.......................................................................................98
Figure 4.34. Les données de facture (Exemple de test sur DEV)………………………
99
CHAIMAE ECHCHRIF xiv

DE VENTE
Liste des abréviations
ERP : Enterprise Ressource Planning

SAP : Système d’Applications et Produits
PDG : Président-Directeur Général
ABAP : Advanced Business Application Programming
DEV : Developpement
2TUP : 2 Tracks Unified Process
IHM : Interaction Homme Machine
CHAIMAE ECHCHRIF xv
DE VENTE
1Introduction Générale
L’administration des ventes est un facteur important dans le monde de commerce. Elle
supervise la gestion des contrats de vente, depuis la prise de commande jusqu’à l’émission
de la facture.
Bien que cette fonction soit au cœur des mouvements de négoce dans tous les secteurs
d’activité, il est évident que les organismes et les grands magasins spécialisés dans la vente
ont des difficultés à offrir des services organisés, avantageux permettant de satisfaire le
personnel compétent.
Pour cet objectif, notre client INWI a choisi d’integrer l’ERP SAP en collaboration
avec ValuePass Consulting, qui garantit une meilleure coordination des services afin de
survivre et améliorer sa performance globale (qualité, délais, coûts).
Le terme ERP vient de l’anglais « Enterprise Ressource Planning ». ERP a été traduit
en français par l’acronyme PGI (Progiciel de Gestion Intégré) et se définit comme un
groupe de modules reliés à une base de données unique.
L’ERP est un progiciel qui permet de gérer l’ensemble des processus opérationnels
d’une entreprise en intégrant plusieurs fonctions de gestion : solution de gestion des
commandes, solution de gestion des stocks, solution de gestion de la paie et de la
comptabilité, solution de gestion e-commerce, solution de gestion de commerce … dans un
système. Autrement dit, l’ERP représente la « colonne vertébrale » d’une entreprise.
Pour être qualifiée de « Progiciel de Gestion Intégré », une solution logicielle ERP doit
couvrir au moins deux principes fondamentaux qui sont les suivants :
 Construire des applications informatiques sous forme de modules indépendants mais
parfaitement compatibles sur une base de données unique et commune.
 L’usage d’un moteur de Workflow permet de définir l’ensemble des tâches d’un
processus et de gérer leur réalisation dans tous les modules du système qui en ont
besoin.
Un ERP se caractérise par l’usage systématique d’un moteur de workflow (système
permettant d’automatiser un flux d’information au sein d’une organisation) non toujours
visible par l’utilisateur, qui permet, lorsqu’une donnée est entrée dans le système
CHAIMAE ECHCHRIF 1
DE VENTE
d’information, de la propager dans tous les modules du système qui en ont besoin, selon
une programmation prédéfinie.
Les principaux acteurs de ce marché sont : SAP, Oracle, JdEdwards, PeopleSoft
(récemment racheté par Oracle), Baan, Intentia, IFS, Lawson. On notera une tendance à la
concentration des différents acteurs. SAP représente à lui seul pratiquement 50 % du
marché.
Le présent document constitue une synthèse du projet de fin d’études, effectué au sein
de ValuePass. Ce projet s’appuie sur la formulation de l’enchainement technique
prévisionnel et la mise en place de programmes spécifiques additionnels
Dans le cadre du projet de fin d’études, nous sommes amenés à analyser les besoins du
client et les fonctionnalités offertes par SAP, puis les concevoir en utilisant le langage de
programmation propriétaire de SAP connu sous le l’acronyme ABAP qui signifie
Advanced Business Application Programming.
Le plan de cette mémoire est subdivisé en cinq chapitres :
 Le premier chapitre comporte une présentation de l’entreprise d’accueil et le contexte
général du projet ;
 Le deuxième chapitre donne une présentation générale du projet en général, avec une
étude de l’existant, le cahier des charges associé et la conduite de projet ;
 Le troisième chapitre a été consacré à la présentation de la solution SAP et de son
langage de développement ABAP ;
 Le dernier aborde les développements et tests spécifiques réalisés.
CHAIMAE ECHCHRIF 2
DE VENTE
CHAPITRE Ⅰ
Contexte général du
projet
Ce chapitre va contenir une presentation de l’organisme d’accueil
ValuePass Consulting, le contexte général du projet, avec une étude
de l’existant, le cahier des charges associé et la conduite de projet,
ainsi que la méthode du développement et enfin la planification du
projet à travers diagramme de GANTT.
CHAIMAE ECHCHRIF 3
1.1 Organisme d’accueil
1.1.1 Présentation générale de l’Entreprise
Figure 1.1:Logo valuepass

Value Pass Consulting est une société marocaine spécialisée dans le conseil et le
déploiement du progiciel de gestion SAP. L’entreprise qui a démarré ses activités en 2005,
assure la prestation autour du progiciel SAP avec la vente des licences et une prise en
charge de la maintenance et de l’assistance.
La dynamique d’investissement dans les systèmes d’information dans la région du

Maghreb est prometteuse. De plus en plus de PME et de grands groupes investissent dans
des solutions SAP, pour mieux optimiser la gestion de leurs ressources humaines et leurs
processus de production.
Consciente de l’évolution de l’économie nationale, Value Pass s’internationalise et
décide d’étendre l’offre de ses services sur le Maghreb. « Capitalisant sur notre croissance
au Maroc, nous avons décidé d’étendre le périmètre de notre intervention pour couvrir les
pays du Maghreb », révèle le directeur associé de la société, Imad Haddour. Ce choix est
motivé par la dynamique d’investissement dans les systèmes d’information dans la région
du Maghreb qui est, selon la direction, très prometteuse.
Son centre de support est le premier certifié par SAP au Maghreb, L’entreprise a été
déjà certifiée en 2009 en tant que distributeur agréé des produits SAP sur le Maghreb. «
L’extension de nos activités en Algérie et en Tunisie n’est que la traduction opérationnelle
de nos ambitions », explique, Stéphane Henry, directeur-associé en charge du
développement. Pour preuve, l’entreprise réalise un chiffre d’affaires de plus de 20
millions de DH dont 40% à l’export.
Le premier semestre 2012 marque un tournant dans la vie de l’entreprise. Value Pass a
été accrédité par SAP en tant que premier centre assistance et de support SAP PCOE
(Partner Centre of Expertise). “Cette reconnaissance de l’expertise de nos équipes par
DE VENTE
l’éditeur allemand marque un tournant dans la montée en compétence de notre entreprise

en tant que point de référence technique dans la région du Maghreb”, se félicite le directeur
de l’entreprise Imad Haddour.
Le centre de support de Value Pass offre désormais aux entreprises qui ont déjà
déployés les solutions de SAP des services d’assistance de proximité en langue française.
Cette offre d’assistance sur les pays du Maghreb est multi-canal : téléphonique, via le Web,
à distance et en présentiel, en fonction des besoins des clients.
Parallèlement au développement à l’international, Value Pass renforce son
investissement dans la R&D (Recherche & Développement) en mettant en place une unité
“SAP mobility” dédiée au développement de solutions mobiles au profit des clients sur la
base de la plate-forme et les solutions SAP. C’est aussi un choix qui confirme le
positionnement de Value Pass sur la niche des services à valeur ajoutée autour des produits
SAP.
1.1.2 Missions de l’entreprise

Du point de vue technique, l’offre d’intégration de Value Pass autour des produits SAP
couvre les différents métiers de l’entreprise : finance, achat, logistique, commercial,
production, qualité, maintenance, gestion de la relation client et le décisionnel
Déploiement du module gestion des achats et approvisionnement dans l’environnement
SAP S/4 HANA 1909 On-Premise au profit d’un opérateur mobile Rapport du projet de fin
d’études 10 La mission de Value Pass 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.
 Conseil et Implémentation des ERP.
 Formation aux ERP.
 Développements Off-shore.
 Développement sur la technologie ABAP.
CHAIMAE ECHCHRIF 5
DE VENTE
Figure 1.2: Cartographie de Value Pass Consulting
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, Value Pass a pour ambition
d'aider ses clients à identifier, structurer et exécuter leurs projets de transformation qui
impactent durablement leurs croissances ou leurs compétitivités. Value Pass les
accompagne dans leurs phases de transition en portant une grande attention aux facteurs
clés d’une transformation réussie. L'offre de Value Pass 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 Reengineering (BPR)
CHAIMAE ECHCHRIF 6
DE VENTE
 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.
 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.
Conseil et intégration ERP :
L’intégration des ERP constitue le cœur de métier de Value Pass, s’appuyant sur son
fort partenariat avec SAP ainsi qu’avec des intégrateurs de référence (IBM Global
Business Services), Value Pass participe à des projets complexes d’intégration, allant de la
conception à l’intégration et la mise en œuvre de solutions technologiques.
Value Pass 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.
L'approche de Value Pass 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.
Son offre comprend le pilotage des projets, l’intégration des projets ERP, l’assistance à
maîtrise d’ouvrage, l’assistance au choix et comparaison des solutions et la rédaction de
cahier des charges et spécifications fonctionnelles. L'offre de Value Pass comprend :
 Pilotage des projets. - Intégration des projets ERP.
 Assistance à maîtrise d’ouvrage.
 Assistance au choix et comparaison des solutions.
CHAIMAE ECHCHRIF 7
DE VENTE
 Rédaction de cahier des charges et des spécifications fonctionnelles.
Formation aux ERP :
En fonction des besoins de l'entreprise, Value Pass 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.
Développement Offshore :
Value Pass 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.
Développement sur les technologies ABAP :
Ce volet comprend :
 Le développement autour des outils décisionnels comme BW.
 La maintenance applicative à distance des systèmes d’information des clients
basés à l’étranger.
 Le paramétrage en centre permettant de personnaliser le progiciel.
 L’analyse pour le compte des multinationales en utilisant des outils statistiques.
1.1.3 Solutions autorisées :

Les solutions autorisées par SAP pour l’entreprise Value Pass sont les suivantes :
 SAP Mobile Platform Sell Autorisation.
 Database & Technology Sell Authorization.
 SAP Business Intelligence Sell Authorization.
 SAP Business All-in-One Support Authorization.
CHAIMAE ECHCHRIF 8
DE VENTE
 SAP HANA Support Authorization.

 SAP Business All-in-One Sell Authorization.
 SAP Cloud Human Resources Sell Authorization.
Figure 1.3: Historique de Value Pass
1.2 Clients de Value Pass

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 en
plus dans ses domaines. Voici donc une liste des différents clients et projets achevés :
Clients Missions SAP

SONASID Projet d’Implémentation SAP : Logistique, Maintenance, Production,
Finance, Contrôle de Gestion et Décisionne
BIM Projet de mise en œuvre de SAP : Module Finance
CMCP 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
FEDEX Mise en place de SAP sur les modules Finances, Commercial, Achats :
EXPRESS Bouclage du projet Maintenance de paramétrage : Evolution en
fonction des nouveaux besoins et correction
CHAIMAE ECHCHRIF 9
DE VENTE
MAROC Projet d’intégration de SAP GMAO : Intervention sur le module

TELECOM Maintenance et sur le module gestion des stocks. Session de formation
utilisateurs finaux et décideurs
Office Participation au projet de mise en place de SAP ISU CRM en
Nationale De partenariat avec Cap Gemini France Intégration du module SAP CRM
L’Electricité Customer Relationship Management. Intégration du module SAP PM –
Gestion de la maintenance
PETROM 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
COCA COLA Mise en place des procédures de suivi des dépenses marketing Gestion
Facturation inter company (Coca-Cola et Embouteilleurs)
Groupe Diagnostic, définition des processus et mise en place des procédures au
SAHAM sein des sociétés du Groupe SAHAM – POLE DISTRIBUTION
AL Implémentation de SAP SRM Supplier Relationship management
OMRANE
OCP SA Implémentation de SAP SRM et module gestion des articles.
RAM Tierce maintenance applicative SAP (TMA SAP) pour les module MM
et SRM
Tableau 1.1 : Une partie des Clients Value Pass
1.2.1 Organigramme
L’organigramme ci-dessus nous donne une vision plus claire sur la structure
organisationnelle de ValuePass-Consulting.
L’entité est subdivisée en trois domaines fonctionnels, qui seront détaillés au niveau
des métiers de l’entreprise.
-Intégration SAP
- Business Consulting
- Business Process Outsourcing
Dans le cadre de notre projet, nous avons rejoint l’équipe technique

qui a pour vocation d’accompagner le client du début à la fin de la
réalisation de son projet, tout en adaptant les solutions offertes par SAP à
ses spécifications techniques afin de proposer à notre client les outils
CHAIMAE ECHCHRIF 10
DE VENTE
d’aide pour la gestion de métier.
1.2.2 Fiche technique :
Figure 5 : Organigramme de Valuepass Consulting
La fiche technique de l’entreprise Value Pass Consulting est représentée dans le tableau
suivant :
Entreprise Value Pass Consulting
Industrie Information Technology and Services
Activité Conseil pour les affaires et administration
d’entreprises
Spécialité SAP ALL in One – ECC ,Business
Objects ,Sybase,Succes Factors ,Hana
cloud platform,SAP Fiori , SAP SCP,SAP
HYBRIS,and SAP ARIBA
Site Web www.valuepass-consulting.com
Forme juridique Scieté à Responsablité Limitée à associé
Unique
Date de création 2005
CHAIMAE ECHCHRIF 11
DE VENTE
Directeur Associé - Fondateur M. Imad HADDOUR

Directeur Associé - Dirigeant M .Henry STEPHANE
Actionnaire Groupe GFI Informatique Maroc
Effectif 150-200
Tél +212 5 22 21 84 49
Capital 2 500 000 DHS
Localisation Bouskoura Business Park , Motorvillage
Tableau 1.2 :Fiche technique Valuepass
1.3 Présentation du projet
1.3.1 Périmétre du projet

Value Pass Consulting, intégrateur et partenaire SAP représente la maîtrise d'œuvre du
projet d'intégration du progiciel SAP dans sa dernière version S/4 HANA On-Premise au
profit de notre client , et est responsable de la réalisation du projet dans son intégralité.
Le périmètre de prestations de VALUE PASS pour ce projet est le suivant :
- Lancement du projet.
- Formation de l'équipe projet.
- Prototypage et conception générale.
- Conception détaillée.
- Paramétrage du progiciel.
- Tests d'intégration.
-Assistance aux tests de recette.
- Réalisation des développements et des tests unitaires.
CHAIMAE ECHCHRIF 12
DE VENTE
- Formation des utilisateurs.

- Correction des anomalies détectées durant la période de garantie.
Les modules mis en place seront les suivants :
- FI Comptabilité
- CO Contrôle de Gestion
- MM Achats et Stocks
- SD Ventes et Distribution
1.3.2 Présentation du client
Figure 1.5 : Logo client : INWI
Le présent client de ValuePass, pour lequel je suis sensée réaliser ce projet, est une
entreprise filiale du groupe holding ONA, INWI, qui occupe la troisième place autant
qu’opérateur de télécommunications.
Elle est créée en 1998 sous le nom de « MAROC CONNECT », ensuite elle va porter
le nom de « WANA CORPORATE », avant qu’elle soit nommée en fin de compte INWI
en 2010.
INWI est un fournisseur de référence sur le marché Entreprises, leader national des
services VPN IP pour entreprises, 2ème sur l’internet Entreprises. Aujourd’hui, nous
investissons dans des infrastructures propriétaires et nous nous sommes dotés d’atouts :
l’obtention de licences opérateur téléphonie fixe et mobile 3G, des partenaires
internationaux, un réseau national à très haut débit en fibre optique indépendant de
l’opérateur historique, des boucles locales avec des technologies nouvelle génération, un
cœur réseau full IP et une plateforme de services innovants.
Avec 3,5 millions de clients, inwi consacrée meilleure « Marque de Services » au

Maroc en 2010. Une consécration pour inwi, troisième opérateur global de
télécommunications au Maroc. Après seulement 10 mois d’existence au cours desquels il a
CHAIMAE ECHCHRIF 13
DE VENTE
gagné la confiance de 3,5 millions de clients, inwi a remporté le Trophée « Morocco

Awards » pour la « meilleure Marque de Services ». C’était au titre de la seconde édition
de cet événement qui rend hommage aux marques marocaines les plus dynamiques de leur
secteur d’activité.
Casablanca, le 19 décembre 2010 – « C’est un honneur pour inwi, une marque
marocaine, jeune et résolument innovante ainsi qu’une reconnaissance du respect de nos
engagements à l’égard du consommateur marocain ». C’est en ces termes que Frédéric
Debord, Directeur Général d’inwi, a qualifié la distinction reçue par l’opérateur de
télécommunications.
1.3.3 Cadre du projet
Ce projet a pour objectif de donner une solution performante et efficace qui va

permettre à inwi de bien gérer son flux de ventes. Elle se compose de deux parties
essentielles :
Une 1ère partie qui vise à adapter le standard SAP avec le besoin de INWI, à travers le
paramétrage du module de l’administration des ventes (SD), ce qui va permettre
d’exploiter la fonctionnalité standard offerte par SAP.
Une 2ème partie qui complètera la 1ère à travers un développement spécifique qui
couvrira des fonctionnalités non offertes par SAP. Ceci sera sous forme d’une application
SAP et sa base de données afin de faciliter et augmenter la fiabilité de la gestion et
administration des ventes.
CHAIMAE ECHCHRIF 14
DE VENTE
Figure 1.6. Le client INWI

Dans une optique de changement de son environnement et de ses activités, le système
de gestion de contrats de vente intégré cible doit permettre au client de relever l’intégralité
des défis que l’ancien système n’assurait pas, et accomplir l’ensemble des missions
souhaitées par l’activité du client.
1.4 Problématique
Auparavant, il y avait plusieurs systèmes d’information au sein de la chaine de
l’administration de ventes de INWI.
En particulier, notre client a besoin d’être plus productive en améliorant sa capacité à gérer
et à optimiser son processus de vente en passant d’ORACLE vers SAP S/4 HANA. En
effet, avec le nouveau système, la société cherche à suivre en temps réel les commandes,
les bon de livraison, les articles et les factures à l’aide des applications et transaction
devloppé sur SAP GUI, dans le but d’avoir un impact immédiat sur les résultats ainsi que
sur la position concurrentielle de l’entreprise. Contrairement à l’ancien ERP qui offrait des
approches d'approvisionnement classiques avec un traitement qui prenait une longue
période dues à la multiplicité des transactions et la complexité des stratégies de validation
des différents documents de vente. Dans l’objectif de mieux souligner la grande
problématique de ce projet, je la définis comme suit : Optimisation et simplification des
CHAIMAE ECHCHRIF 15
DE VENTE
opérations de ventes et le deroulement de son flux avec un système intégré, immédiat et

intelligent : SAP S/4 HANA.
Méthode QQOQCP
ValuePass Consulting
Qui est concerné par
Qui ? Equipe technique
ce projet ?
Client : INWI
L’intégration et adaptation d’une application de SAP

Quoi ? De quoi s’agit-il ? S4/Hana pour l’administration et le deroulement du
flux de vente .
L’amélioration et la simplification globale du

processus de vente et l’analyse des besoins et les
Où ? Où est le problème ?
fonctionnalités manquantes offertes par SAP
Quand ? Depuis quand ? Depuis l’intégration de SAP
- Analyse des besoins et les fonctionnalités

manquantes offertes par SAP ;
- Avoir une vision sur le TO BE ;
Comment ? De quelle manière ?
- Etude technique et fonctionnelle ;
- Conception et développement du programme ;
- Tests.
- Couvrir les besoins des clients ;

- Améliorer la gestion de vente en SAP ;
Pourquoi ? Dans quel but ?
- Suivre les unités de manutention pour le flux de
vente.
Tableau 1.3. QQOQCP
CHAIMAE ECHCHRIF 16
DE VENTE
J’ai utilisé la méthode QQOQCP afin de mieux définir la problématique de mon projet de
fin d’étude et mieux comprendre les éléments qui sont en interaction avec cette derniere.
1.5 Solution proposée

Figure 1.7 :solution d'integration du flux de vente
Afin de remédier à tous ces problèmes d’incohérence et permettre une éventuelle

analyse de données de ventes INWI, la solution proposée est l’intégration du module SD
dans la solution SAP mise en place , qui permettra d’avoir une base de données centralisée
avec des fonctionnalités adaptées au besoin de la société en assurant une grande fiabilité et
une meilleure performance , ainsi qu’un support d’une taille très importantes de données ,
chose qui n’était pas valable pour les applications existantes.
1.5.1 Objectifs du projet

Ce projet a pour objectif de donner une solution performante et efficace qui va
permettre à INWI de bien gérer son flux de ventes afin de remédier à la problématique
précédente en concevant et en réalisant une application SAP permettant de simplifier le
déroulement du flux de vente depuis la création de commande de vente jusqu’à la
facturation.
CHAIMAE ECHCHRIF 17
DE VENTE
Étant partie de l’équipe technico-fonctionnel et dans le cadre de l’intégration du

Module SD de SAP pour le client mes tâches confiées au cours de ce projet sont :
 Participation au paramétrage du module SD (Material Management).

 Développement et documentation des applications et programmes pour
répondre aux besoins spécifiques du client.
 Création des transactions spécifiques pour faciliter l’acces aux
applications du suivi des flux de ventes , transactions pour
(creation ,affichage commande , transaction pour creation affichage de
bon de livraison , transaction pour creation et l’affichage du facture.
 Participation à la préparation des supports de formation pour les Key-
User.
 Élaboration d‘un plan d’action avec les équipes fonctionnelle et
technique et suivi des actions déployées.
 Participation au tests et corrections en paramétrage pour vérifier le bon
déroulement des flux a fin d’améliorer les solutions proposées et
d’éviter toute anomalie tout en satisfaisant le client.
 Étude fonctionnelle du besoins client.
 Réalisation des tests, recettes et correction de paramétrage pour
s’assurer du bon déroulement des différents flux.
Tout en respectant les délais ,les specifications de client ,la qualité des livrables, les
normes et standards du développement.
1.6 Gestion du projet

La conduite de projet et le choix de la méthodologie peuvent influer grandement sur le
succès de ce dernier. Il convient donc en amont d’une prestation de se poser les bonnes
questions pour choisir la méthode la plus adaptée.
1.6.1 Le choix du processus de développement :

En analysant le besoin et les objectifs de notre projet, on observe des exigences
différentes en termes de travail en équipe, d’architecture et d'évolutivité.
CHAIMAE ECHCHRIF 18
DE VENTE
Figure 1.8 : process de développement

 Architecture Modulaire :
En fonction de nos nouveaux besoins qui peuvent évoluer au cours du projet, les
éléments de notre plateforme peuvent être assemblés puis séparément modifiés,
retirés, ou ajoutés sans interférer avec le fonctionnement de l’autre élément ou
changer toute l’architecture.
 Travail en équipe :
L'équipe de développement peut-être divisée en sous-groupes, chacun se

spécialisant dans le développement d'un module.
 L’évolutivité :
L’application doit être capable d’évoluer en fonction des besoins, des règlements
et des contraintes externes.
Donc la meilleure façon de réaliser cette combinaison, c’est d’adopter une
démarche itérative. C’est ce que propose le 2TUP en se basant sur un cycle de
développement en Y avec une séparation entre les aspects techniques et les aspects
fonctionnels.
1.6.2 Processus 2TUP
CHAIMAE ECHCHRIF 19
DE VENTE
Ce processus nous permet de mieux gérer les changements et de les intégrer le plus
rapidement possible en démarrant une itération au niveau de la conception et de la
réalisation de notre projet.
Le processus s'articule ensuite autour de trois phases essentielles :
 Une branche fonctionnelle qui capitalise la connaissance du métier de l’entreprise.

Cette branche capture des besoins fonctionnels, ce qui produit un modèle focalisé sur
le métier des utilisateurs finaux.
 Une branche technique qui capitalise un savoir-faire technique et/ou des contraintes
techniques. Les techniques développées pour le système sont indépendamment des
fonctions à réaliser.
 Une phase de réalisation consiste à réunir les deux branches, permettant de mener
une conception applicative et enfin la livraison d'une solution adaptée aux besoins.
La figure suivante présente le processus :
CHAIMAE ECHCHRIF 20
DE VENTE
Figure
1.9:Cycle de vie
en Y
1.6.3 Plani
fi catio
n du
projet
Le diagramme de GANTT est un outil permettant de modéliser la planification des
tâches nécessaires à la réalisation d'un projet.
Il représente un outil permettant de représenter graphiquement l'avancement du projet,

mais c'est également un bon moyen de communication entre les différents acteurs d'un
projet.
CHAIMAE ECHCHRIF 21
DE VENTE
la planification de projet adoptée en respectant le découpage fait et le cycle de vie

choisi.
Figure 1.10. Diagramme de GANTT
CHAIMAE ECHCHRIF 22
DE VENTE
Figure 1.11. Diagramme de GANTT
1.7 Conclusion
CHAIMAE ECHCHRIF 23
DE VENTE
Dans ce chapitre on a présenté le projet, décrit la problématique, annoncé les objectifs à

réaliser et finalement montré les détails de conduite du projet.
Dans le chapitre suivant, on entamera les exigences fonctionnelles et non-
fonctionnelles.
CHAIMAE ECHCHRIF 24
CHAPITRE II
Spécification des
exigences
fonctionnelles et
techniques
Dans ce chapitre nous allons aborder les exigences fonctionnelles
et non-fonctionnelles en analysant et identifiant les besoins du client
afin de proposer et définir la solution adéquate.
DE VENTE
1.Analyse et identification des besoins
1.1.Étude de l’existant (Le AS IS)
Le paramétrage qu’on va effectuer permettra à INWI d’utiliser son système SAP pour
la création des commandes clients.
Un utilisateur INWI s’en chargera de saisir les informations de la commande à travers à

la transaction paramétrée qu’on va créer afin de répondre à ce besoin. Il s’occupe donc de
la création de chaque commande en renseignant les champs nécessaires. Le processus
prend un temps considérable puisqu’il y a trop d’informations à alimenter pour une seule
commande et nécessite beaucoup de concentration afin d’éviter toute erreur possible.
L’entreprise a pour objectif d’améliorer ses 4 d omaines fonctionnels : -
 Comptabilité financière et contrôle de gestion

 Achat et logistique amont
 Gestion des stocks
 Vente et logistique
Le système d’information :
Notre projet porte sur le déroulement du flux de vente, INWI utilisait l’ERP Oracle
pour la gestion de ses ventes. La version ancienne est exécutée sur la base de données
Oracle, nécessite de longues durées de traitement, puisqu’il s’agit d’un système
transactionnel qui ne repose pas sur la synchronisation en temps réel.
Les commandes de ventes, les bon livraisons et les factures etaitent créés directement
sur le système, qui est le client graphique qui permet à la fois : Aux End users d'effectuer
les différentes transactions ou programmes définis dans l’ERP, aux développeurs et Key
users d'effectuer l'ensemble de leur développements et paramétrage du système. Le
système ne donne pas les reporting analytiques des différentes activités liées à
l’approvisionnement ce qui ne permet pas d’avoir des informations en temps réel sur les
dépenses, les évaluations, les scores et les contrats des fournisseurs, et diminue davantage
la capacité des responsables à détecter les écarts et à agir rapidement.
Cela impacte directement la position concurrentielle de l’entreprise et réduit la

compétitivité. Tandis que la gestion des contrats et des appels d’offre est hors système, ces
documents sont traités manuellement.
CHAIMAE ECHCHRIF 26
DE VENTE
1.2 Critique de l’existant
 La communication entre INWI et le client pour effectuer une simple commande se

fait via plusieurs canaux et nécessite le suivi d’une procédure, ce qui consomme un
temps considérable avec un effort et un manque de traçabilité parfois.
 L’intervention humaine pour la reprise des données de la commande dans SAP

augmente le pourcentage d’erreurs.
 Le processus de création d’une commande est un peu lent vu le nombre de champs

à alimenter.
1.3 Expression de besoin (Le TO BE)
Après plusieurs réunions de l’équipe SD de Value Pass avec le client au cours de la

préparation initiale du projet, la solution SAP S/4 HANA a été proposé afin de répondre
aux besoins exprimés par le client au niveau des ventes.
Le To Be : Le clients souhaite s’investir dans un projet de mise à niveau de son système

actuel, pour rationaliser son flux ventes , simplifier la manipulation de SAP pour les
utilisateurs et évaluer leurs fournisseurs en se basant sur multiples critères dans le but de
renforcer son position dans le marché.
Pour mieux cadrer le To Be, j’ai traduit l’ensemble de fonctionnalités demandées par le
client en fonctionnalités qui sont exécutables et gérables sur SAP.
1.4 Diagramme Bête à corne
CHAIMAE ECHCHRIF 27
DE VENTE
Afin de mieux cerner les besoins fonctionnels du client, le schéma suivant représente
graphiquement ces besoins en répondant aux trois questions : A qui rend-il service ? Sur
quoi agit-il ? Dans quel but ?
Figure 2.6. Diagramme bête a corne
Selon le schéma, « l’intégration du Module gestion des ventes et distributions dans

l’environnement SAP S/4 HANA, Développement ABAP rend service aux End users de
l’organisme du client en agissant sur processus des ventes et distributions.
1.5 Spécification des besoins
1.5.1 Etude fonctionnelle générale
Lors de cette phase, une analyse fonctionnelle des exigences du client est effectuée, où
il a exprimé ses besoins à travers un cahier de charge et des ateliers de conceptions.
1.5.2 Informations générales
Flux Description
Domaine Vente et distribution
Processus Préparation et Expédition
Libellé du développement Bon de livraison.
CHAIMAE ECHCHRIF 28
DE VENTE
Flux Description
Type de développement Développement d’un formulaire
Applications/transactions
VL01N/VL02N/VL03N
utilisées
Tableau 2.1. Informations génerales
1.5.3 Synthèse fonctionnelle du développement
Pour Chacune des livraisons éditées dans le système, un formulaire Bon de

livraison sera édité automatiquement au moment de la sortie de marchandises au
niveau de la livraison du même module.
Le formulaire Bon de livraison concerne les flux de vente suivants :
 Vente Standard.
1.5.4 Ecran de sélection
Champ Type Oblig Zone de référence (technique)

N° Livraison CHAR OUI LIKP-VBELN
Tableau 2.2. Données d’ecran de sélection
1.5.5 Logique de sélection
L’impression du formulaire Bon de livraison se fait livraison par livraison au niveau

des transactions VL02N et VL03N.Le numéro de livraison sera renseigné entrée des tables
LIKP et LIPS pour extraire les informations de poste et d’en-tête relatives au document.
1.5.6 Maquette du Formulaire
La création du formulaire passe par deux étapes principales :
 Création de la maquette
 Création du programme d’alimentation
 La transaction SFP (ADOBE FORMS) : permet de créer la maquette du formulaire en
ajoutant les différents zones nécessaires et aussi d’établir le lien entre les différents
champs et à alimenter et le programme d’alimentation.
Le respect de la mise en forme convenue avec le client reste un élément primordial lors de la
mise en place du formulaire.
CHAIMAE ECHCHRIF 29
DE VENTE
La figure ci-dessous représente la maquette du formulaire ZSD_bon_liv créé :
Figure 2.2 : maquette de bon de livraison
Les zones dont les valeurs sont à extraire du système sont codifiées comme suit
ZFXXX (XXX correspond à un chiffre de 000 à 999). A chaque zone sera attribuée une
règle de gestion dans le paragraphe suivant.
1.5.7 Règles de gestion détaillées
Code Libellé Règles de gestion du champ

Logo de
ZF000 Logo de l’entreprise en format png
l’entreprise
Date de sortie de marchandises réelle.
Zone LIKP-WADAT_IST de la livraison en cours de
ZF001 Date
traitement avec LIKP-VBELN est la livraison en cours de
traitement
ZF003 BL N° Numéro du Bon de livraison dans le système en format code
à barres
CHAIMAE ECHCHRIF 30
DE VENTE
Zone LIKP-VBELN.
Pagination du formulaire X/Y.
X/Y Page Avec X = Numéro de la page en cours de traitement.
Y = Nombre de pages du formulaire.
Nom du client réceptionnaire de marchandises.
Zone KNA1-NAME1 avec KNA1-KUNNR = LIKP-
ZF004 Client
KUNNR et LIKP-VBELN est la livraison en cours de
traitement.
Adresse du client réceptionnaire de marchandises.
Adresse de Zones STRAS (Rue), PSTLZ (Code Postal), ORT01(Ville),
ZF005
livraison LAND1(Pays) de la table KNA1, avec KNA1-KUNNR =
LIKP-KUNNR.
Adresse du client Destinataire de la facture.
Adresse de
ZF006 Zones STRAS (Rue), PSTLZ (Code Postal), ORT01(Ville),
facturation
LAND1(Pays) de la table KNA1.
Date de création livraison pour le document en cours de
traitement.
ZF007 Date de livraison
Zone LIKP-BLDAT avec LIKP-VBELN est la livraison en
cours de traitement.
Contenu de la zone de texte du même nom renseignée au
ZF008 Transporteur niveau de l’en-tête de la livraison.
Texte d’en-tête ZMTL.
ZF009 Livreur niveau de l’en-tête de la livraison.
Texte d’en-tête ZNEL.
Numéro de
ZF010 niveau de l’en-tête de la livraison.
déclaration
Texte d’en-tête ZNLI.
ZF011 N° de commande Imprimer le Texte suivant : Votre Commande N° ZF011du
ZF011’ reçue sous notre numéro ZF011’’.
Avec ZF011 : Numéro de la référence client dans la

commande associée. Numéro de la demande de transfert dans le
CHAIMAE ECHCHRIF 31
DE VENTE
cas d’un flux de transfert

Et ZF011’ : Date de référence de la commande client.
Et ZF011’’ : Numéro de la commande associée à cette
livraison.
Numéro du poste en cours de traitement.
ZF012 Poste Zone LIPS-POSNR avec LIPS-VBELN est la livraison en
Code article pour le poste en cours de traitement.
ZF013 Code Article Zone LIPS-MATNR avec LIPS-VBELN est la livraison en
Description de l’article pour le poste en cours de traitement.
ZF014 Description Zone LIPS-ARKTX avec LIPS-VBELN est la livraison en
Quantité commandée de l’article pour le poste en cours de
traitement.
ZF015 Qté Commandée
Accéder à la commande liée à la livraison en cours de
traitement par la table VBFA
Unité de quantité du poste en cours de traitement dans la
ZF016 UdM
livraison.
Quantité de livraison pour le poste en cours de traitement
ZF017 Qté livrée LIPS-LFIMG avec LIPS-VBELN est la livraison en cours de
traitement.
Zone de texte du même nom pour le poste en cours de
ZF018 Commentaire traitement
Texte de poste de livraison dont le code est ZCOM.
ZF019 Destinataire NOM1 du client réceptionnaire de marchandises.
Tableau 2.3. Régles de gestions et specifications
1.6 Identification des processus à paramétrer

Dans cette partie, j’ai identifié les processus métiers à paramétrer sur le système, tout
en répandant au mieux au besoin client que j’ai traduit par des règles de gestion dans la
partie suivante. Et donc, pour ce faire, je vais paramétrer les processus de vente de
l’expression du besoin au lancement de la commande : commande de vente , bon livraison,
CHAIMAE ECHCHRIF 32
DE VENTE
facture, ainsi que le paramétrage de la structure organisationnelle et les données de base

adaptées au besoin du maitre d’ouvrage.
1.6.1 Les critères
 Critères fonctionnels
- Proposer des formulaires qui répondent aux exigences des maquettes du client ;
- Proposer des traitements 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.
 Critères techniques
- Les solutions devront être optimales en matière de performances et de temps

d’exécution ;
- Les programmes doivent être développés dans les environnements SAP ;
- La mise en production de toute 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 ;
- Les solutions proposées devront répondre à la fois aux normes de qualité de
ValuePass Consulting ainsi qu’aux normes internes du client.
1.7 Spécification des exigences non-fonctionnelles
Les besoins non fonctionnels décrivent toutes les contraintes techniques, ergonomiques
et esthétiques auxquelles est soumis le système pour sa réalisation et pour son bon
fonctionnement. En ce qui concerne l’application, nous avons dégagé les besoins suivants :
 L’extensibilité : Après la réalisation du projet on a la possibilité d'ajouter ou de

modifier de nouvelles fonctionnalités.
 La sécurité exige :
- Les données de l'entreprise doivent être stockées dans des centres de données
sécurisés ;
- Les clients peuvent partager un équipement physique, mais leurs données restent
séparées ;
CHAIMAE ECHCHRIF 33
DE VENTE
- Les utilisateurs ayant besoin d'un accès aux données de l'entreprise doivent
s'authentifier, et leur identité doit être vérifiée par le module de gestion des
utilisateurs et des accès ;
- Les clients restent propriétaires de leurs données.
 L’Aptitude à la maintenance.
On doit s’assurer que le programme répond :
- La conformité aux standards d’architecture ;
- La conformité aux standards de design ;
- La conformité aux standards de développement.
 Performance : Le chargement de système doit être rapide ainsi on doit minimiser le
temps de réponse de programme ou bien d’une demande de formulaire par
l’utilisateur.
1.8 Phase de conception

J’ai contribué dans ce projet aux trois phases de la méthodologie ASAP : Préparation
du projet, conception générale et développement de la solution, réalisation et recettes.
Dans la phase de conception, notre équipe expose les fonctionnalités clés et les points
forts de la solution proposée ainsi que les règles de gestion de chaque fonctionnalité du
Module SD (Sales and Distribution) et approvisionnements adaptées aux besoins du client.
L’analyse d’écart est incluse dans cette partie, elle concrétise les exigences du client et
permet de voir l’adéquation de celles-ci avec ce que fourni le standard SAP.
Cette phase consiste pour le maître d'ouvrage à exprimer son besoin à la maîtrise
d'œuvre Value Pass.
Elle est essentielle car les fiches de conception qui en seront issus permettront de
paramétrer la solution dans le système SAP en question et d'identifier les développements
et les interfaces que le client aurait besoin avec d'autres éléments constituant le SI.
Le comité du programme valide la phase de conception après l’organisation de

plusieurs ateliers entre l’équipe SD , le client. Cette étape détaille les fiches de conception
présentées au client contenant les fonctionnalités clés des applications SAP ainsi que les
règles de gestion et les schémas des processus en question.
L’étape suivante est le prototype démontré au comité de pilotage, c’est au cours de

cette phase qu’on va présenter le 80% de la solution dans l’environnement DEV du
CHAIMAE ECHCHRIF 34
DE VENTE
système dans le but d’adapter le progiciel standard au besoin spécifique du client pour la
gestion de leur processus de vente.
Ensuite la phase de réalisation qui permet d’adapter à 100 % la solution aux exigences
métier du client.
1.9 Analyse des Besoins
1.9.1 Cas d’utilisation (Use case)
Figure 2.3. Diagramme cas d'utilisation
Chaque utilisation du système par les participants est représentée par un cas
d'utilisation. Chaque cas d'utilisation représente la fonctionnalité qui leur est fournie afin
de générer les résultats attendus.
Le diagramme de cas d'utilisation dans la 2.3 représente le fonctionnement général du

système, où l’utilisateur doit s’authentifier sur le système SAP tout d’abord, puis il peut
CHAIMAE ECHCHRIF 35
DE VENTE
lancer les transactions ,créer/afficher commande, créer/imprimer bon livraison et

créer/imprimer facture.
1.9.2 Diagramme d’activité
Le diagramme d’activité est un diagramme pour lequel les états se réduisent à de

simples actions ou activités et dont les transitions se déclenchent automatiquement avec
Figure 2.4. Diagramme d'activité impression document et gestion des erreurs
éventuellement des gardes.
Le diagramme précédent illustre le comportement du système face au contrôle de

gestion spécifique.il schématise l’ensemble des traitements à effectuer pour la procédure de
creation de bon de livraison (meme cas pour la creation du facture).
Le diagramme suivant présente l’ensemble des traitements à effectuer pour la

procédure de l’impression des formulaires.
CHAIMAE ECHCHRIF 36
DE VENTE
Figure 2.5. Diagramme d'activité d’impression des formulaires
1.9.3 Diagramme de séquence
Pour mieux comprendre l’interaction des différents éléments du système, un

diagramme de séquence est modélisé pour illustrer l’interférence des différents acteurs.
Alors le diagramme de séquence suivant explique l’interaction de l’utilisateur avec le

systéme sap ainsi que la base de données tout en modélisant le process de flux de vente
standard , commencant par l’appel de transaction pour creation du commande jusqu’à
l’impression du facture .
CHAIMAE ECHCHRIF 37
DE VENTE
Figure 2.6. Diagramme de séquence
1.10 Spécifications techniques : la solution SAP

Après avoir étudier les besoins fonctionnels et techniques, il était obligatoire d’étudier
l’ERP SAP qui a été proposé par l’entreprise d’accueil pour répondre aux besoins
identifiés.
1.11 Vue générale de SAP

SAP est 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.
CHAIMAE ECHCHRIF 38
DE VENTE
SAP est un progiciel bien répandu aujourd’hui. On dénombre plus de 1041111

installations dans plus de 120 pays à travers le monde. Ce qui représente plus de 12
millions d’utilisateurs. La plupart des grandes entreprises l’ayant installé afin d’améliorer
leur rentabilité, la demande en consultants ne cesse de croitre notamment dans l’espace
francophone.
L'une des raisons du succès de ce progiciel, est le fait qu’il soit possible de paramétrer
chacune de ses composante s afin de l’adapter aux besoins spécifiques d'une entreprise.
Il peut être installé sous Windows, Unix, Linux, Solaris. Il est aussi indépendant du
système de gestion des bases : il peut être installé sur Oracle, MS-SQL, IBM DB2,
MaxDB. Ayant un support multilingue, Il peut être installe en plus de 41 langues
internationales.
1.11.1Architecture modulaire
SAP repose sur un ensemble de modules dont la manipulation ainsi que le paramétrage
se font selon les besoins de chaque entreprise. La diversité de ses modules permet de
couvrir toutes les fonctionnalités pertinentes au sein d’une entreprise et comme tout
progiciel, sa modularité signifie qu'il est possible d'intégrer tout ou une partie de l'ERP. Les
modules de SAP sont principalement liés à ces trois grandes catégories :
 Gestion comptable (FI, CO).

 Ressources humaines (HCM).
 Logistique (SD, MM, PP ...).
1.12Mise en place de la solution SAP
1.12.1Mode de déploiement
Pour tout passage à SAP S/4HANA, SAP propose deux options de déploiement
différentes : Cloud et On-Premise.
Notre client INWI souhaite avoir un logiciel accessible uniquement sur les postes de
travail, une connexion interne, SAP S/4HANA On-Premise est la suite SAP ERP Business
Suite basée sur la base de données in-memory SAP HANA. Il s’agit d’une plate-forme
interne, située sur nos propres serveurs et gérée par notre entreprise. En tant qu’entreprise,
nous gérons et nous contrôlons donc tout, y compris la base de données HANA, les
applications, les serveurs, les réseaux et autres systèmes connexes.
CHAIMAE ECHCHRIF 39
DE VENTE
Pour toute mise en place d’une solution SAP, on trouve trois notions importantes qui
interviennent afin de répondre finalement à un besoin exprimé par le client :
l’achat de licence, le paramétrage et le développement spécifique .
Figure 2.7 Mise en place de la solution SAP
1.13Conclusion
Ce chapitre étant clos, avait pour objectif dans un premier lieu mesurer et analyser
l’état actuel de l’entreprise client en analysant les besoins fonctionnels, non fonctionnels et
en modélisant le diagramme d’activité, de cas d’utilisation et de séquence. Ainsi de
dégager les problèmes observés par les consultants fonctionnels et par le client, ce qui
constitue une ouverture du sujet en mettant le doigt sur les problèmes majeurs et
CHAIMAE ECHCHRIF 40
DE VENTE
suggestion des solutions d’amélioration, dans un deuxième lieu, nous avons fait une
présentation globale de la solution SAP et de notre environnement de travail.
CHAPITRE III
Déploiement de SAP
Ce chapitre nous permettra d’avoir un bref aperçu sur
l’environnement de projet de fin d’étude avant de passer à la
conception et la configuration de la solution SAP S/4 HANA en
précisant ses apports et aussi les flux des processus de vente dans SAP
SD. Ce dernier a pour finalité de d’exposer globalement les solutions
adéquates à la réalisation de ce projet.
CHAIMAE ECHCHRIF 41
DE VENTE
1. .Progiciel de gestion intégré-ERP :
1.1.Définition
Dans un système d’information classique d'une grande entreprise, on trouve
généralement les ERP et les systèmes appelés spécifiques (non standards, développés
sur mesure, que l'on ne trouve pas sur le marché). Un ERP (Enterprise Resource
Planning) et en français PGI (Progiciel de Gestion Intégré) est un logiciel qui permet
de gérer l’ensemble des processus d’une entreprise, en intégrant toutes les fonctions de
cette dernière. C’est une application informatique constituée de plusieurs modules
encore connues sous le nom d’applications métier (AM), en anglais Business Object
(BO) (ex : approvisionnement, vente, production, finance, paie, ressources humaines,
stocks, transports...) indépendants entre eux, mais partageant une base de donnée
commune.
Les données sont standardisées, stockées sur des tables uniques et partagées entre les
modules, ce qui élimine les saisies multiples et évite l’ambiguïté des données
multiples de même nature. L’ERP remplace donc les différentes applications du
système d’information par un unique système plus cohérent. Il facilite le pilotage de
l’entreprise (d’où son nom anglais : Enterprise Ressource Planning).
1.2.Enjeux
L'implantation d'un ERP pousse l’entreprise à des améliorations du fonctionnement
interne. Plus l'entreprise est grande, plus elle souhaite élargir le domaine d'application
de son ERP et plus elle va devoir changer sa manière de fonctionner. Au-delà de
l'aspect technique et matériel, le changement reste bicéphale ; D’une part, il touche
surtout les ressources humaines, d'autre part, la manière de fonctionner de l'entreprise
dans sa globalité. C'est pourquoi l'implémentation d'un ERP ne doit pas être considéré
un projet informatique géré par la direction des systèmes d’information, il doit
notamment être lancé, suivi et soutenu par la direction générale et toutes les directions,
ainsi qu’il reste complexe et peut prendre beaucoup de temps.
L’implémentation d'un ERP dans une entreprise entraîne des changements

considérables pour les utilisateurs finaux. Cette conduite du changement doit être
CHAIMAE ECHCHRIF 42
DE VENTE
particulièrement préparée et suivie pour s'assurer de la collaboration de l'ensemble des

utilisateurs et donc de la réussite du projet.
1.3.Avantages
Les avantages d’un PGI / ERP :
 Une gestion complète et simplifiée de votre activité sur un seul logiciel.

 Une base de données unique et partagée en local et à distance pour un travail
collaboratif en temps réel.
 Une solution facile à prendre en main et intuitive.
 Un logiciel évolutif qui s'adapte à vos besoins des données sécurisées.
 La suppression de tous les problèmes liés à des transferts de données
Dans un tel système, la redondance des données entre départements n’existe plus,
l’information étant disponible pour tous en temps réel, une meilleure coordination
interservices devient possible et prend moins de temps ce qui améliore la productivité.
Figure 3.1: Architecture modulaire de l'ERP
1.4.Inconvénients
CHAIMAE ECHCHRIF 43
DE VENTE
Comme il y’a des avantages, les ERP ont leurs propres inconvénients aussi :
- Résistance au changement des utilisateurs finaux.
- Retard ou échec.
- Complexité de mise en œuvre.
- Dépendance de l’éditeur.
- Adaptation spécifique du besoin métier au standard ERP.
- Lorsque l'ERP s'arrête l'entreprise s'arrête aussi.
1.5.Éditeurs d’ERP
Open Source ou propriétaires, le marché des ERP tend à se diversifier pour venir
concurrencer SAP, leader incontesté des solutions ERP. On distingue deux types d’ERP :
les ERP propriétaires, édités par des sociétés, ce qui implique l’achat d’une licence, et les
ERP open source qui sont "gratuits".
Figure 3.2 : Répartition des ERP dans le marché mondial
Les principaux ERP propriétaires du marché :
 SAP (leader mondial)

 ORACLE/PEOPLESOFT
 SAGE ADONIX
 MICROSOFT
1.6 Environnement de travail
CHAIMAE ECHCHRIF 44
DE VENTE
SAP repose généralement sur l’existence de trois environnements de travail (serveurs

ou systèmes) connus par ‘ SAP Landscape ’ composés de plusieurs mandants.
Les consultants BC se chargent de créer ces environnements ainsi que définir les
utilisateurs pour y accéder.
Le mandant représente un sousensemble de données au sein de la machine : Lorsque les

utilisateurs se connectent à une machine SAP et ils interrogent une table de la base de
données, ils accèdent uniquement aux données pour le mandant ; si des données existent
pour un autre mandant, elles ne sont pas présentées .
Figure 3.3 :Environnement de travail
Figure 3.4 : Environnement de travail SAP Lanscape
1. Architecture physique :
CHAIMAE ECHCHRIF 45
DE VENTE
Avant d’exposer les détails des besoins liés à notre projet pilote, nous présentons dans
cette section la procédure envisagée pour la mise en œuvre de ce projet. Cette procédure
s’aligne avec celle adoptée au sein de Value Pass. Elle consiste en trois phases et par la
suite, l’utilisation de trois sous-systèmes distincts de développement et de test comme
l’illustre la figure : elle décrit en détail les phases du déroulement d’un projet au sein de
Value Pass du développement jusqu’à la livraison en passant par les tests.
Figure 3.5. procédure de mise en œuvre du projet
Les principaux environnements sur lesquels se base l’installation de SAP sont les suivants :
- Environnement de développement (DEV) : Au niveau de cette partie, les différents

paramétrages, solutions techniques et fonctionnelles sont mises en place afin de répondre
aux exigences client.
- Environnement de qualité (QUAL/QAS) : Dans cet environnement, les consultants

évaluent les modifications et leurs adéquations avec le besoin du client après la
transportation des différents paramétrages réalisés dans l’environnement DEV à l’aide d’un
ordre de transport (OT).
- Environnement de production (PROD) : Cet environnement est exploité pour les

activités métiers et l'enregistrement des données réelles du client.
L'environnement PROD représente le système final sous la charge du client, aucune

modification, test ne doit être appliquée sur ce système.
1.7 architecture logicielle SAP
CHAIMAE ECHCHRIF 46
DE VENTE
1.7.1 Architecture technique :
Figure 3.6: Architecture technique SAP
Le système SAP ECC (ERP Central components) est basé sur une architecture
client/serveur à trois niveaux, 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 illustré dans la figure 10.
Couche de présentation : SAP GUI Graphical User Interface SAPGUI est l’interface
client dans SAP ERP de l’architecture à 3 niveaux : base de données, serveur d'applications
et client.
Cet interface utilisateur qui permet d’accéder à SAP, entrer de nouvelles données et
recevoir le résultat d’un processus de travail.
Couche d’application: La couche intermédiaire chargée des fonctions administratives de
SAP, comme la gestion des utilisateurs et le contrôle du système, ainsi que de l’exécution
des programmes
CHAIMAE ECHCHRIF 47
DE VENTE
Bases de données: Le serveur où sont stockés les enregistrements de tous les

traitements réalisés.
La base de données de SAP comprend plus de 12000 tables constituant un schéma de
base de données relationnel.
Ce schéma est implémenté sur tous les SGBD du marché, à savoir : Oracle, SQL
Server, DB2, Sybase, etc
1.7.2 SAP S/4 HANA
Figure 3.7. Logo SAP S/4 Hana S/4 Hana, le nouvel ERP de SAP, représente une rupture
Figure 3.7 .LOGO SAP S/4 HANA
majeure dans la ligne de produits du leader des progiciels. Ne serait-ce que parce cette
génération ne fonctionnera que sur la base de données maison, Hana. Depuis plus de quatre
décennies, le progiciel de gestion intégré (ERP) a été un élément central de l'activité de
l'éditeur allemand SAP. Ce n'est pas pour rien si, en février 2015 lors de la sortie du nouvel
ERP, le CEO Bill McDermott a déclaré que S/4HANA représentait « le lancement le plus
important que l'entreprise ait connu depuis 23 ans, voire même le plus important de toute
l'histoire de l'éditeur ». L’exécution de S/4 en mémoire apporte plusieurs avantages : elle
permet à SAP d’offrir une suite centralisée et rationalisée aux entreprises qui veulent
exploiter les flux croissants de données, celles des ventes en ligne, mais aussi les données
de l'internet des objets (IoT) dont l’usage commence à se répandre .
1.8 Architecture modulaire
CHAIMAE ECHCHRIF 48
DE VENTE
SAP repose sur un ensemble de modules dont la manipulation ainsi que le paramétrage
se font selon les besoins de chaque entreprise. La diversité de ses modules permet de
couvrir toutes les fonctionnalités pertinentes au sein d’une entreprise et comme tout
progiciel, sa modularité signifie qu'il est possible d'intégrer tout ou une partie de l'ERP.
Les modules de SAP sont principalement liés à ces trois grandes catégories :
- Gestion comptable (FI, CO).
- Ressources humaines (HCM).
- Logistique (SD, MM, PP...).
La Gestion comptable : La gestion comptable contient toutes les écritures des ventes et
achats, lesquelles se déversent dans la comptabilité générale via la comptabilité client ou
fournisseur.
Il concerne aussi le contrôle de gestion et la gestion des investissements financiers
La gestion comptable s'effectue à travers plusieurs modules : "FI" pour "Finance",
"CO" pour " Contrôle de gestion ".
La ressource humaine : SAP permet de gérer les recrutements, les paies des employés,
les compétences des employés, de suivre les temps de travail et les évolutions de carrière,
de gérer les demandes et les frais de déplacement.
Logistique : Le module logistique ou encore appelé Negoce, est le module le plus
convoité par les entreprises car il permet de gérer tout ce qui se rapporte aux ventes/achats,
en particulier la gestion des stocks qui coûtent chers aux entreprises.
Ce module assure une liaison directe avec le compte de résultats et le système de
production.
Il permet l’optimisation des processus de Workflow, la gestion précise des stocks, des
contrôles qualités et factures. La composante logistique de la solution SAP est divisée en
plusieurs modules, dont les principaux se présentent dans un module SD de gestion
commerciale, un module MM de gestion des articles d’un point de vue achats et gestion de
stocks, et un module PP de planification de la production.
CHAIMAE ECHCHRIF 49
DE VENTE
Figure 3.8 : Architecture modulaire SAP
2. Présentation du module SD
2.1 Définition du module SD :

SD est une abréviation anglaise signifiant ‘Sales and Distribution’, elle présente le
module de l’ERP SAP qui permet la gestion des ventes et de l’expédition des
marchandises, tout en prenant en charge le processus dans sa globalité. Le module SD est
capable de s’adapter aux spécificités des produits/biens vendus ou services rendus par les
entreprises .
CHAIMAE ECHCHRIF 50
DE VENTE
Figure 3.9 :Flux de vente et distribution
Il se décompose en 4 grandes parties :
 Les supports de ventes : fiche client, fiche article …

 Les ventes : gestion des offres de prix, des contrats cadres, traitement des
commandes client
 Les expéditions : planification de la préparation de commande, exécution de la
préparation de commande, sortie marchandise, bulletin de livraison
 Facturation : facture sur bulletin de livraison, factures de prestations de services,
avoirs, facture pro-forma
Il intègre plusieurs points d’intégration avec les modules :
- MM (Gestion article)
- PP (Gestion de production)
- LE (Logistique et expédition)
- FI (Finance)
2.1.1 Flux du module SD SAP :

L’évolution du système d’administration des flux de vente suit le shéma suivant :
Figure 3.10. flux global du processus de vente
CHAIMAE ECHCHRIF 51
DE VENTE
Explications des éléments du schéma d’administration des ventes et expéditions :
 Préparation et alimentation du système SAP par des supports de ventes (données de

base) à savoir la fiche client, fiche article, condition de prix.
 Enregistrement des offres exprimées par les clients,
 Commandes sans ou en référence à une offre : dans certain cas, il y a des
conventions/contrats signés par le client et le fournisseur permettant de régulariser/
programmer des livraisons périodiques, ici on parle donc d’une commande sans
référence à une offre exprimée directement par le client à chaque fois qu’il a besoin
des produits [Le fournisseur à une vision globale préventive sur les besoins de
quelques clients].
 Livraison d’une commande : chaque commande conforme sera destinée à être
livrée à son demandeur
 Lancement de la facturation : génération du document de la facture.
2.1.2 Organisation structurelle dans le module SD SAP :
CHAIMAE ECHCHRIF 52
DE VENTE
Figure 3.11. Organisation struturelle SD

a) Les entités organisationnelles
 La société
Elle représente une entité légale distincte pour laquelle des états financiers complets
(bilans…) sont requis. Les sociétés sont indépendantes les unes des autres sur le plan
juridique mais elles peuvent être affectées à un même mandant.
Le mandant : C’est une séparation logique des bases de données à l’intérieur d’une
installation du système SAP. Donc, toutes les organisations qui peuvent accéder à un
même ensemble de données doivent être créées sous le même mandant. C’est la plus haute
entité organisationnelle du système SAP. Il est caractérisé par un ensemble commun de
règles (tables de paramétrage communes, fichiers maîtres communs, base de données
commune).
 Le Domaine commercial
L’entité la plus importante de la structure organisationnelle de l’administration des

ventes est le domaine commercial. Un domaine commercial est la combinaison des trois
entités commerciales que sont une organisation commerciale, un canal de distribution et un
secteur d’activité.
Un canal de distribution unique peut être affecté à plusieurs organisations
commerciales ; de même un secteur d’activité unique peut être affecté à différents canaux
de distribution.
Une organisation commerciale peut appartenir à différents domaines commerciaux
c’est-à-dire être subdivisée en différents canaux de distribution et/ou être affectée à
différents secteurs d’activité.
Un domaine commercial détermine donc, le canal de distribution pouvant être utilisé
pour vendre les produits d'un secteur d'activité dans une organisation commerciale.
 Organisation commerciale
C’est une entité organisationnelle au sein de la logistique qui est responsable de
la vente et de la distribution des biens et services. Elle représente l’unité de vente en
tant qu’entité juridique. Chaque organisation commerciale doit être affectée à une et
une seule société. Toutefois, il convient de remarquer qu’une société peut regrouper
plusieurs organisations commerciales.
CHAIMAE ECHCHRIF 53
DE VENTE
 Canal de distribution
Il indique le canal par lequel les articles ou services commercialisables
atteignent les clients. Comme exemples, on peut citer la vente en gros, la
distribution de détail et les ventes directes.
 Secteur d’activité
Dans le système SAP, le secteur d’activité correspond à la famille de produits. Il
permet donc, de grouper des produits et services pour des fins de rapport.
Pour assurer le suivi du stock article, il est nécessaire de pouvoir enregistrer dans le
système les emplacements où les articles sont stockés. Pour ce faire, SAP utilise les
concepts « division » et « magasin ».
 La division
C’est une entité manufacturière ou d’entreposage où se retrouvent des stocks. La

vérification de la disponibilité des stocks s’effectue généralement au niveau de la division.
De même, la valorisation des inventaires se fait souvent au niveau de la division.
 Le magasin
C’est un entrepôt. Une division peut être composée de plusieurs magasins.
 Le point d’expédition
Correspond à un emplacement physique, proche de la division chargée de la livraison.

Une livraison est toujours exécutée par un seul point d’expédition. Il dépend de la division,
du type d’expédition, du moyen de chargement nécessaire.
b) Le client
Le terme « client » qualifie tous les personnes/entités avec lesquels l'entreprise est en
contact, ce dernier qui doit obligatoirement exister dans le système pour pouvoir passer une
commande.
 La fiche client
La fiche client contient toutes les informations relatives au client, Les données de la
fiche client peuvent être catégorisées comme suite :
 Données générales : nom, adresse …
CHAIMAE ECHCHRIF 54
DE VENTE
 Données société : données comptables

 Données domaine commercial : vues spécifiques à une activité (conditions de
livraison, fonctions partenaires …)
 Fonctions partenaires
Une entreprise interagit avec différentes personnes morales et physiques lors de
transactions commerciales. Un client commande des marchandises auprès d'une entreprise.
Toutes les fonctions qu'une personne morale ou physique peut assumer sont
représentées par des partenaires dans le système SAP.
Les rôles partenaire servent à définir les droits et responsabilités de chaque partenaire
dans la transaction. Comme rôles partenaire en standard dans SAP, on peut citer :
Figure 3.12.Les fonctions partenaire
CHAIMAE ECHCHRIF 55
DE VENTE
Cette figure illustre l’architecture complète de la base de données standard du module

SD de SAP.
Figure 3.13. Base de données pour le module SD
Le schéma suivant illustre les diffèrentes tables standards de SAP utilisées pour la
réalisation des programmes voulus par le client
Figure 3.14. Modélisation des données
CHAIMAE ECHCHRIF 56
DE VENTE
En fait, pour chaque commande, on trouve une table entête « VEKP » qui contient des
informations générales sur la commande, une table des postes « VEPO » qui contient des
informations sur chaque article à savoir la quantité, la désignation, l’unité, etc.
Ensuite, pour la livraison on trouve deux tables principales, une pour l’entête « LIKP »
contenant les informations générales de la livraison, et une table des postes livrés « LIPS ».
Finalement pour la facture, on trouve aussi deux tables principales, une pour l’entête «
VBRK » et une pour les postes « VBRP » , la table « MAKT » contient les données de
l’article et finalement concernant les données du client on les trouve dans la table «
KNA1»
CHAIMAE ECHCHRIF 57
DE VENTE
2.1.3 Les transactions Module SD (Flux de vente)
3. Paramétrage SD chez inwi

L’administration des ventes dans SAP repose sur des structures de base. Chaque
entreprise est structurée d’une certaine façon.
Il est donc indispensable de représenter la structure de l’entreprise dans le système SAP

pour permettre son utilisation.
 C’EST LA REPRISE DE L’IMAGE DE L’ENTREPRISE SUR LE SYSTÈME

SAP
Figure 3.15 : Codes des transactions d'un flux SD
CHAIMAE ECHCHRIF 58
DE VENTE
Le paramétrage du module d’administration de ventes se base donc essentiellement sur

la mise en place de la structure organisationnelle correspondante à la société dans un
premier lieu et ensuite , le paramétrage du flux de ventes, à travers la création des données
de base (fiche client, fiche article…), et de l’enchaînement des documents de ventes (offre,
commande, livraison…).
C’est dans cette optique que s’inscrit la première partie de mon projet qui vise à
paramétrer le module de gestion de vente et d’expédition standard SAP afin de
l’adapter aux besoins exprimés par le client INWI.
3.1 Paramétrage de la structure organisationnelle SD

Chaque entreprise possède une structure spécifique et une organisation typique.
Dans le système SAP, les structures organisationnelles de l'entreprise forment un cadre

dans lequel toutes les transactions commerciales peuvent être gérées.
Le paramétrage de la structure organisationnelle commence par la définition des entités

et se termine par leur affectation. Il est important d’opérer dans cet ordre.
Définition des entités organisationnelles pour une entreprise
 Création Organisation commerciale :

 Lancement du guide de paramétrage SAP (Transaction SPRO)
 Aller vers le lien :
CHAIMAE ECHCHRIF 59
DE VENTE
Structure de l’entreprise →Définition→ Administration des ventes→ Définir,

copier, supprimer, contrôler Org. Commerciale
Figure 3.16: Guide d'implementation
Figure 3.18 :Détail des objets créés
Cet écran permet la création d’une nouvelle organisation commerciale.
Figure 3.17 Creation d’une nouvelle organisation

Le bouton ‘nouvelles entrées’ permet d’accéder à l’écran de sélection qui
permet la création d’une nouvelle organisation de ventes.
CHAIMAE ECHCHRIF 60
DE VENTE
Après la saisie d’un code de 4 caractères, qui représentera l’identifiant de l’organisation

commerciale créée, La désignation puis la devise, l’icône ‘sauvegarder’ permet
d’enregistrer la nouvelle organisation.
 Copier une organisation commerciale
Dans ce sens, la copie d’une organisation commerciale du standard SAP ou d’une

organisation commerciale déjà créée dans le système est recommandé afin d’éviter les
erreurs et respecter les normes.
Pour copier l’organisation commerciale modèle, il suffit de la sélectionner et de suivre

le chemin Traiter → Copier sous (voir l’image ci-dessous).
Figure 3.19 : copier une organisation commerciale
Figure 3.20 . Modification organisations commerciales
Les informations de l’organisation commerciale source doivent être remplacées par les
données cibles (ZKTS). Cela permet de profiter des données d’une organisation
commerciale existante pour créer une nouvelle demandée.
CHAIMAE ECHCHRIF 61
DE VENTE
 Définir un canal de distribution
Ce chemin d’implémentation autorise la création d’un nouveau canal de Distribution

via ce chemin
IMG > Structure de l’entreprise →Définition →Administration des ventes(ADV)

→Définir, copier, supprimer, contrôler canal de distribution →Définir le canal de
distribution.
Après avoir cliqué sur ‘Nouvelles entrées’, la création d’un canal de distribution
nécessite la saisie d’un code sur 2 caractères et une désignation.
Les informations relatives au canal de distribution tiennent sur une ligne. Il n’y a pas
d’écran de détail.
 Définir un secteur d’activité
Figure 3.21. Définition d’un canal de distribution
CHAIMAE ECHCHRIF 62
DE VENTE
IMG →Structure de l’entreprise →Définition →Logistique – données Générales

→Définir, copier, supprimer, contrôler secteur d’activité →Définir le secteur
d’activité
La création d’un nouveau secteur d’activité, suit la même procédure que le canal de
distribution. Le nouveau secteur admet un code de 2 caractères et une désignation.
De même, l’agence commerciale, la division et le point d’expédition. A noter que les

trois entrées possèdent une adresse. La saisie de celle-ci est facultative.
Ces entités sont définies dans le système par une clé de quatre caractères.
Figure 3.22. définition d’un secteur d’activité
 Définir une société
CHAIMAE ECHCHRIF 63
DE VENTE
IMG →Structure de l’entreprise →Définition →Comptabilité financière→Traiter,

copier, supprimer, contrôler société →Traiter données société
Après la saisie des données nécessaires pour créer une société, l’icône entourée d’un
cercle rouge sur l’illustration en dessus, autorise l’affectation d’une adresse à la société.
Figure 3.23. Définition d’une société

 Définir un magasin
IMG →Structure de l’entreprise →Définition →Gestion des articles →Gérer

magasin
La création d’un magasin dépend d’une division donnée comme illustré dans l’écran de
saisie, ensuite, la sélection de l’onglet ‘Magasins’, autorise l’accès à l’écran de sélection
Figure 3.24. Définition d’un magasin
pour la création.
L’affectation des entités de la structure organisationnelle des ventes
CHAIMAE ECHCHRIF 64
DE VENTE
Afin de compléter l’implémentation de la structure organisationnelle, la structure

organisationnelle doit contenir une suite d’affectations comme suit :
 Affecter le canal de distribution à l’organisation commerciale.

 Définir le domaine commercial :
 comprend l'affectation des trois entités composantes du domaine commercial,
 l’organisation commerciale, le canal de distribution, et le secteur d’activité.
 Affecter l’agence commerciale au domaine commercial.
 Affecter la division à la société.
 Affecter la division à l’organisation commerciale/canal de distribution.
 Affecter le point d’expédition à la division
L’affectation des différentes entités organisationnelles au sein de l’administration des

ventes est faite via le chemin : IMG →Structure de l’entreprise →Affectation
→Administration des ventes(ADV).
Figure 3.25 . Guide d’implémentation
 Exemple : affectation de l’organisation commerciale à la société.
CHAIMAE ECHCHRIF 65
DE VENTE
IMG > Structure de l’entreprise →Affectation →Administration des ventes(ADV)

→Affecter organisation commerciale à société.
Cet écran permet d’associer une organisation commerciale à une société bien définie.
La démarche de l’affectation à suivre est la suivante :
 Sélectionner la société concernée.

 Cliquer sur ‘affecter’
 cocher l’organisation commerciale à affecter.
 Valider la mise à jour.
Figure 3.26. Affectation d’organisation commerciales à societé

- A noter qu’une organisation commerciale ne peut être affectée qu’à une seule
Figure 3.27 démarche d’affectation
société.
Remarque : La création de n’importe quel document commerciale (offre, commande,

contrat, livraison, facture…) dans l’administration de vente dépend nécessairement de
l’existence d’une structure organisationnelle de l’entreprise.
3.2 Paramétrage du Flux de Vente INWI :

Après la première partie de paramétrage qui consiste à reprendre l’image de l’entreprise
sur le système SAP à travers la création et l’affectation des entités organisationnelles des
ventes , une 2éme partie encore plus importante concerne le paramétrage des différents
CHAIMAE ECHCHRIF 66
DE VENTE
type de documents de ventes en définissant et affectant l’ensemble des types d’objets SAP
en relation avec le flux.
Vue globale des types Objets SAP sur les flux de ventes :
Les objets SAP du flux de ventes sont reliés à des documents qui représentent un
regroupement d’informations qui doivent être alimentées pour la définition des éléments
d’une commande.
Le type de document de vente représente donc une catégorie de commandes. Dans le

cas du flux INWI, on a les types suivants :
 Commande standard
 Demande note Crédit
 Demande note Débit
 Retours
Figure 3.28. Types d'objets SAP sur les flux de vente
A chaque type de document de vente, on affecte les types de poste de commande
autorisés / type de livraison et enfin type de facture + schéma de prix.
 Type de Document de vente : type de commande qui sera paramétrable sur le

système
 Catégorie de poste : type poste de commande autorisé sur une commande
CHAIMAE ECHCHRIF 67
DE VENTE
 Type de livraison : type d’objet d’expédition qui permettra la gestion de la sortie

de marchandise
 Type de facture : type de l’objet FI permettant la facturation d’une commande de
vente. Cette facture peut être créée :
- en référence à une commande client
- en référence à une livraison
Autrement dit, Elle peut concerner tous les postes, une sélection de postes ou
une quantité donnée.
 Schéma de prix : règle de calcule de coût d’un article vendable + commission

possible .
Exemple Pratique : Mise en place du flux ZCDE
Le flux ZCDE représente un flux d’une commande de type standard paramétré pour
le système INWI. Le processus d’adaptation reste le même pour les autres types de
commande, seules les données qui varient.
Flux de la commande de vente standars ZCDE et les transactions équivalentes :
- Création de la commande de vente

- Créatin d’une livraison sortante
- Edition et envoi de bon de livraison
- Création du facture
Points d’adaptation SAP pour la mise en place d’une commande

ZCDE :
CHAIMAE ECHCHRIF 68
DE VENTE
Avant la mise en place d’une commande ZCDE (commande standard) , un

paramétrage/alimentation est nécessaire sur le système de trois éléments essentiels :
 Données client/Article : Les données du client qui va être concernées

doivent être enregistré sur le système, ainsi que les informations relatives
Figure 3.29. Points d'adaptation SAP
aux articles qui vont figurer dans la commande.

 Document de vente (en-tête + poste) : le type de document de vente utilisé
ainsi que le type des documents reliés doivent être déjà paramétré sur le
système SAP, en prenant en considération les liaisons autorisées.
 Schémas de prix : les règles de calcule de coût des articles contenus dans la
commande doivent être déjà définies.
 Point de paramétrage des Données client

Logistique  Administration des ventes  Données de base Créer
Partenaire  Client  Créer  Administration des ventes
CHAIMAE ECHCHRIF 69
DE VENTE
Ou taper le code transaction VD01 .
Figure 3.30. Paramétrage données client
Figure 3.31. Données générales client
 Point de paramétrage des Données commande (Type
commande)
CHAIMAE ECHCHRIF 70
DE VENTE
Administration des ventes →Vente→ Documents de vente→ En-tête du

document de vente→ Définir les types de commande .
Figure 3.32 Définir les types de commande
Figure 3.33. Types de commandes des clients
CHAIMAE ECHCHRIF 71
DE VENTE
 Point de paramétrage des Données commande (Type

Poste commande)
Administration des ventes →Vente→ Documents de vente→ Poste de
document de vente→ Affecter les types de poste
 Paramétrage Schéma de prix (Condition de prix)
Figure 3.34. Affectation de type de poste

Affectation des Schémas de prix au type de commande :
Administration des ventes →Détermination du prix→ Pilotage de la

détermination du prix→ Affecter schémas de documents types de commande
client
1. Création d’une Commande client INWI
Après la phase de paramétrage du système SAP INWI , un utilisateur du système sera

capable de créer une commande à l’aide d’une transaction SAP , en alimentant plusieurs
zones sur des écrans de sélections.
cette partie illustre la démarche de la création d’une commande de vente standard sous
SAP INWI.
Logistique →Gestion des articles → Commerce extérieur/Douanes

→Gestion générale commerce extérieur →Environnement > Vente –
CHAIMAE ECHCHRIF 72
DE VENTE
Exportation → Vente → Offre → Commande client > VA01 – Créer [ou la

transaction VA01]
Les différentes transactions commerciales exécutées lors du traitement d’une

commande client utilisent le type de document de vente.
Le type de document de vente utilisé est déjà créé, avec des contraintes
correspondantes aux besoins spécifiques. Le type de document de vente défini avec un
code ‘ZCDE’, présente un document de type ‘commande client standard’.
Les entités organisationnelles nécessaires pour définir le domaine commerciale , qui se

compose de l’organisation commerciale ‘2200’, le canal de distribution ‘10’ et le secteur
d’activité ‘00’, sont déjà définies et affectées sur le système ( Voir partie paramétrage ) .
 Une commande de ventes contient :

 Des informations du client donneur d’ordre (commandant) et le client
réceptionnaire (livré) à définir dans l’entête de l’écran de la création de la
commande.
 Des informations générales de ventes dans l’onglet ‘ventes’, concernant le
 processus de la réception souhaitée, le paiement.
Figure 3.35. Créer condition client livraison
 l’affectation des articles relatifs à la commande client, en mentionnant le numéro
Figure 3.37. Informations générales de vente
du poste, la quantité demandée, le type de l’article (un poste de marchandises

(ZTAN) par exemple) et des conditions sur le prix de l’article acheté.
Figure 3.36. Créer commande client
CHAIMAE ECHCHRIF 73
DE VENTE
Informations supplémentaires :
 Informations des informations sur les schémas de prix, avec un double-clic sur
un seul article, dans l’onglet ‘conditions’, s’affiche les conditions de prix
enregistrées préalablement pour ce client/article.
 l’onglet ‘partenaires’ comprend les rôles du client concerné par la commande,
le client donneur d’ordre, le réceptionnaire, le payeur et le facturé.
2. Conclusion
Dans ce chapitre, on a préparé un système SAP utilisable avec des fonctionnalités

prêtes à exploiter. A ce stade, INWI est capable de mieux gérer ses ventes et ses flux SD
CHAIMAE ECHCHRIF 74
DE VENTE
d’une façon performante et efficace en se basant sur la puissante du système SAP et ce qui
est offert par son standard.
Cette partie prend généralement une beaucoup de temps, puisque elle est en relation
directe avec le client demandeur INWI et son objectif majeur est de bien adapter ce qui
offert par SAP avec le besoin interne de l’entreprise, du coup, on doit bien comprendre le
besoin pour bien offrir une solution fiable et efficace.
Cette partie reste toujours dans le cadre du standard , pourtant , SAP ne peut pas surement
couvrir tous les besoins de tous les clients qui l’utilise , c’est pour cela qu’il offre un outil
de développement basé sur son langage ABAP , afin de permettre aux entreprises clientes
de créer leurs propres programme , dans le but de répondre à des besoins spécifique et c’est
exactement ce qu’on va faire dans la 2ème partie du projet .
CHAIMAE ECHCHRIF 75
DE VENTE
CHAPITRE IV
Réalisation
Après avoir terminé la partie d’intégration et de paramétrage du module SD dans le
système SAP de INWI, des besoins spécifiques exprimés par l’entreprise , afin de bien
gérer son flux et améliorer la performance de son système d’administration de vente ,
imposent l’utilisation de l’outil de développement ABAP offert par SAP pour créer des
programmes spécifiques complémentaires à ce qui est offert par le standard SAP .Dans
ce qui suit, on va aborder la partie de développement spécifique effectué pour le compte
du client INWI .
1. Environnement de développement
CHAIMAE ECHCHRIF 76
DE VENTE
1.1 ABAP Workbench

Figure 4.1. ABAP Workbench
1.2 Langage 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 Net Weaver pour la réalisation de
progiciels.
ABAP a évolué pour intégrer la programmation objets. Tous les concepts de la

programmation objets se retrouvent dans ABAP Objects. ABAP Objects constitue une
extension du langage ABAP, avec lequel il est totalement compatible : ainsi il est possible
qu'un programme comporte à la fois une partie procédurale et une partie orientée objets,
car le déroulement procédural du programme peut à tout moment instancier une classe puis
appeler les méthodes de l'objet qu'il vient de créer.
1.2.1 Composants du langage :
Avant d’attaquer la partie technique, il est nécessaire de préciser la signification de

quelques termes techniques standards en ABAP qui seront utilisés dans la suite de ce
rapport.
Le code source : il est écrit directement dans un composant de SAP appelé SAP
Workbench et il sera stocké dans la base d'information de l'outil. Ce langage, de même que
java, a besoin d'être compilé pour pouvoir être exécuté. Cependant, à la différence de java,
CHAIMAE ECHCHRIF 77
DE VENTE
avant chaque utilisation d'un programme, le processeur SAP vérifie qu'il possède la
dernière version du programme. Si ce n'est pas le cas, ce dernier est recompilé à la volée.
Un outil de transport. À chaque modification d'un programme, celui-ci doit être transporté
de l'environnement dans lequel il est créé vers un environnement de test puis dans
l'environnement de production (chacun de ces environnements dispose de jeux de données
distincts, il peut exister plus de trois environnements dans un système d'information
donné). Cette opération est réalisée par la mise en œuvre d'un ordre de transport.
- Table interne :
Les tables internes sont l'équivalent en ABAP des tableaux (en C, C++), ou des
Vecteurs (en Java). Une table interne contient un nombre n d'enregistrements du même
type, et la taille d'une table interne est dynamique (elle grossit en fonction du nombre
d'enregistrements que l'on insère).
On les appelle interne parce qu’ils ne sont visibles et utilisables que dans le programme
où ils sont déclaré
- Dictionnaire de données
Le dictionnaire de données (DDIC) : la base de données est masquée pour le programmeur. Il y

accède donc au travers de clauses faisant partie du langage lui-même. De même, la gestion du
modèle de données est réalisée au travers d'un composant qui créera ou modifiera lui-même les
tables de données. Ce dictionnaire de données comprend :
Des domaines représentant un concept élémentaire (par exemple un

fournisseur, une référence article) ; chaque élément de donnée comprend au
minimum un type de donnée et la spécification de son occupation mémoire.
Des éléments de données. Chaque élément de donnée est construit à partir d'un
domaine et correspond à une utilisation particulière de ce dernier pour stocker
une information, ou pour afficher un champ. Chaque élément de donnée
comprend quatre descriptions textuelles qui peuvent être traduites (de manière à
rendre l'application utilisable par des locuteurs de différentes langues).
CHAIMAE ECHCHRIF 78
DE VENTE
Des structures et des tables de différents types permettant de stocker des

informations, d'utiliser des types composites pour les transferts de données entre
programmes et de stocker de l'information dans la base.
- Module Fonction :
Les modules de fonction sont des procédures définies uniquement dans des
programmes ABAP spéciaux, appelés groupes de fonctions, mais peuvent être appelés à
partir de tous les programmes ABAP. Ils vous permettent d'encapsuler et de réutiliser des
fonctions globales dans le système SAP.
Ils sont gérés dans une bibliothèque de fonctions centrale. Le système SAP contient
plusieurs modules de fonctions prédéfinis qui peuvent être appelés à partir de n'importe
quel programme ABAP. Les modules fonctionnels jouent également un rôle important lors
de la mise à jour et de l'interaction entre différents systèmes SAP, ou entre des systèmes
SAP et des systèmes distants via des communications à distance.
BAPI (Business Application Programming Interface)
SAP BAPI (Business Application Programming Interface) est une interface standard
pour les modèles d'objet métier dans les produits SAP.
Les BAPI sont la principale méthode par laquelle le code client et les applications
tierces interagissent avec les produits SAP. Les BAPI enveloppent les couches internes du
modèle d'objet métier de SAP pour garantir que toute la logique métier, les validations et
les contrôles d'autorisation sont correctement exécutés lors de l'accès ou de la modification
des objets métier.
Fonctionnement d’une bapi :

Les BAPIs sont implémentées en tant que modules fonction qui appellent le code
interne SAP. Selon le type de BAPI utilisé, ils peuvent appeler des modèles d'objet métier
définis à l'aide du BOPF (Business Objects Processing Framework) ou des modèles hérités
définis à l'aide de programmes, de tables et de modules fonction.
Les BAPIs exposent une interface formelle et stable que les développeurs de code
client et tiers peuvent utiliser pour accéder et interagir avec les objets de gestion SAP de
manière à ce que les garanties SAP fonctionnent dans le futur. L'accès aux tables sous-
jacentes et aux modules, programmes et classes de fonctions non BAPI est également
CHAIMAE ECHCHRIF 79
DE VENTE
possible dans les systèmes SAP, mais il n'a pas la même garantie que le code fonctionnera
dans le futur ou que les objets accédés existeront même.
Une telle utilisation d'interfaces non-BAPI peut entraîner des problèmes lors des mises
à niveau ou nécessiter de petits correctifs si la signature d'un module de fonction interne
change, ce qui rend le code qui en dépend non valide.
 BAPI pour création des commandes : 'BAPI_SALESORDER_CREATEFROMDAT2'
Lorsqu’on intègre un appel de BAPI dans le programme applicatif, on doit spécifier les
informations d'interface appropriées. L’utilisation d’une BAPI dans un programme ABAP
passe par les étapes suivantes :
 Mappage : La BAPI prend en entrée des paramètres d’un type prédéfini. Avant
l’appel on doit effectuer un mappage entre nos données récupérées et les données
que la BAPI va prendre en paramètres.
 Contrôles d’exécution: La spécification de quelque attribut de contrôle que la

BAPI va utiliser dans sa procédure d’exécution.
 Mise à jour : Si aucune erreur n’est rencontrée, utilisation du module fonction

BAPI_TRANSACTION_COMMIT pour effectuer la mise à jour de la base de
données.
La Transaction BAPI fournit la documentation de chaque BAPI. La figure ci-dessous

montre la disponibilité de la documentation relative à cette BAPI dans la transaction «
BAPI ». Et la BAPI 'BAPI_SALESORDER_CREATEFROMDAT2' qui sera utilisée
pour la création des commandes client pour ce projet.
 Valider / annuler le traitement d’une BAPI :
L’appel d’une BAPI doit être suivi par un appel au module fonction
BAPI_TRANSACTION_COMMIT ou BAPI_TRANSACTION_ROLLBACK afin de
valider ou annuler les opérations effectuées par celle-ci.
Ces deux modules fonctions sont exposés par le système SAP.
- Adobe form : LES FORMULAIRES SAP
CHAIMAE ECHCHRIF 80
DE VENTE
Le système SAP offre la possibilité de générer des rapports imprimables pour les
étapes du flux logistique, c’est pour cela Adobe form offre une interface graphique de
conception conviviale qui simplifie la création des formulaires. Pour imprimer des
formulaires, on a besoin d’un programme d’extraction de données et la mise en page
des données .
Figure 4.2. Structure Adobe Form
Nous pouvons accèder à Adobe Form dans l’environnement SAP via la transaction
SFP.
Figure 4.3. Transaction SFP pour Adobe form dans SAP
Structure du formulaire ADOBE :

Les étapes impliquées dans le développement de ADOBE sont :
 Interface
définition des paramètres.
Une interface de formulaire qui envoie les données de l’application au formulaire.
L’interface est accessible via une transaction SFP.
L’interface dans les formulaires intelligents et PDF ne sont pas compatibles.
CHAIMAE ECHCHRIF 81
DE VENTE
Le PDF ne peut pas récupérer les informations de devise dans le dictionnaire de

données. Ces détails doivent être fournis dans les champs de devise au stade même de
l’interface.
 Contexte
Mappage des paramètres depuis l’interface.
Un contexte de formulaire qui contient la logique du formulaire. Cette logique contrôle
la mise en forme dynamique du formulaire.
Dans le contexte (également appelé contexte de formulaire), vous spécifiez les données
copiées de l’interface vers le formulaire.
 Mise en page
Conception de formulaires.
Mise en page dans laquelle vous définissez la manière dont les données de sortie sont
positionnées, leur apparence dans les graphiques et la conception des pages.
Les interfaces de formulaire et les contextes de formulaire avec mise en page sont
appelés en tant qu’objets de formulaire.
Il s’agit de différents types d’objets transportables. La même interface peut être utilisée
par plusieurs formulaires (comme par exemple dans le bon de commande, les
formulaires de planification, etc.)
- Transaction :
Une transaction est un raccourci d’un programme qui permet d’accéder directement à
un écran sans se déplacer dans les menus. Chaque écran correspond à une transaction qui
lui est propre.
LANCEMENT DU TRANSACTION:
CHAIMAE ECHCHRIF 82
DE VENTE
Figure 4.4. Creation du formulaire ADOBE
 Au 1er écran de la transaction, si on clique sur AFFICHER, MODIFIER ou CREER, on affiche

le formulaire dont le nom a été renseigné
 AFFICHAGE Des PROPRIETES DU FORMULAIRE
Figure 4.5.Proprietés du formulaire
PRESENTATION DES ELEMENTS D'UN FORMULAIRE
CHAIMAE ECHCHRIF 83
DE VENTE
Interface de formulaire
Lors de la création d'un formulaire, il faut créer l’interface du formulaire et définir des
paramètres d'import/export et les exceptions nécessaires au fonctionnement du
formulaire .On trouve 2 types de données (pour tous les onglets import, export...).
 Données globales (encadré jaune) : Déclaration des variables globales.

 Types (encadré rouge : Déclaration des TYPE pour les variables internes au Adobe
Froms.
 Symb. zones :Déclaration des Fields-Symbol.
 Initialisation du code (encadré vert) : Clear, Refresh des tables/structures, valeurs
d'initialisation ( ex : w_col = 1. ).
 Routines FORM (encadré bleu) : C'est à ce niveau que l'on définit les forms des
performs qui seront utilisés dans Adobe forms.
Figure 4.6. composantes du interface de formulaire.
CHAIMAE ECHCHRIF 84
DE VENTE
 Les interfaces de formulaire et les contextes de formulaire avec mise en page sont
appelés objets de formulaire. Il s'agit de différents types d'objets transportables. La
même interface peut être utilisée par plusieurs formulaires .
Figure 4.7. Les données du contexte du fomulaire
Contexte : paramètres de mappage de l'interface.

Un contexte de formulaire contient la logique du formulaire. Cette logique contrôle le
formatage dynamique du formulaire. Dans le contexte (également appelé contexte de
formulaire), vous spécifiez les données qui sont importées de l'interface vers le formulaire.
CHAIMAE ECHCHRIF 85
DE VENTE
Figure 4.8 Les données du Mise en form (MeF)
 Mise en form (MeF)- conception du formulaire.

Une mise en page dans laquelle vous définissez la façon dont les données de sortie
sont positionnées ainsi que leur apparence dans les graphiques et la conception des
pages.
 Editeur de mise en forme

L'éditeur de mise en forme sert à créer et à gérer ces modèles de formulaires.
Il contient les quatre panneaux suivants :
 Vue de conception, panneau

Affiche les pages constituant votre conception de formulaire. Les pages de la vue
de conception présentent le contenu de la conception de formulaire. La première
fois que vous lancez Designer ou créez une conception de formulaire, le panneau
Vue de conception affiche une page prête à recevoir des objets. Les objets du
gabarit qui apparaissent dans la page sont impossibles à sélectionner.
 Gabarits, panneau
Affiche les gabarits applicables aux pages en mode Vue de conception. Les gabarits
indiquent la mise en forme et l'arrière-plan du modèle de formulaire. Ils contiennent
des objets qui figureront au même endroit dans toute la conception de formulaire.
Le panneau Gabarits est masqué par défaut. Les objets figurant sur la page Vue de
conception ne s'affichent pas dans le gabarit .
1.2.1 Formulaire Bon livraison
CHAIMAE ECHCHRIF 86
DE VENTE
Pour le formulaire Bon livraison, on a eu recours aux tableau suivants :

 LIKP : les données d’entête du formulaire ;
 VBELN : Numéro du document ;
 KUNNR : Code client livré ;
 BTGEW : Poids total net des articles ;
 GEWEI : Unité du poids.
 LIPS : Donnée des articles ;
 PSTYV : Unité gratuite ;
 CHARG : Lot ;
 VFDAT : Date limite de consommation du lot ;
 FLIMG : Quantité livré ;
 VRLME : Unité.
 MAKT : Désignation des articles.
 MATNR : Numéro d’article ;
 MAKTX : Désignation d’article.
1.3 Application
1.3.1 Création type de données
CHAIMAE ECHCHRIF 87
DE VENTE
En utilisant le Dictionnaire de données via la transaction SE11, on a créé type de

donnée pour les détails de l’article de livraison VBDPL qui sont les suivant :
 POSNR : Numéro de poste du document ;
 MATNR : Numéro d’article ;
 MATWA : Article saisi
La figure suivante montre la structure créée dans l’environnement DEV du client :
Figure 4.9. types de données
1.3.2 Création du programme
CHAIMAE ECHCHRIF 88
DE VENTE
Logique de sélection
À l’aide de l’outil éditeur ABAP via la transaction SE38, on a créé le programme
« ZSD_BON_LIV» relatif au formulaire ZSD_BON_LIV pour l’interaction avec
l’utilisateur et l’extraction des données depuis la base de données.
La fenêtre suivante présente la création du programme « ZSD_BON_LIV » :
Figure 4.10. Creation du programme ZSD_BON_LIV
ZSD_BON_LIV se compose de trois parties principales :
 ZSD_BON_LIV _TOP : pour la création des variables nécessaires au programme ;

 ZSD_BON_LIV_SEL : pour la création de l’interface d’interaction avec l’utilisateur ;
 ZSD_BON_LIV_F01 : Extraction des données et l’appel au formulaire.
Figure 4.11. Contenu du programme ZSD_BON_LIV
CHAIMAE ECHCHRIF 89
DE VENTE
La figure suivante présente la partie ZSD_BON_LIV_TOP dédiée à la création aux

variables importantes du programme :
Figure 4.12. ZSD_BON_LIV_TOP
Figure 4.13 ZSD_BON_LIV_SEL
La capture suivante illustre ZSD_BON_LIV_SEL consacré à la création de la fenêtre
d’interaction avec l’utilisateur du programme :
L’écran suivant consiste à afficher la partie ZSD_BON_LIV_F01 qui pour but de
grouper toutes les fonctions nécessaires au programme pour l’extraction des données et
l’appel au formulaire :
Figure 4.13. ZSD_BON_LIV_F01
Nous avons eu recourt à plusieurs module de fonction pour réaliser notre code.
1.3.3 Création des transaction
La création des transaction d’execution des programme se fait via la transaction SE80.
CHAIMAE ECHCHRIF 90
DE VENTE
La figure suivante représente la création de la transaction vl02n pour le programme

ZSD_BON_LIV de bon de livraison créé auparavant.
Figure 4.14. Création transaction
L’appel du programme se fera donc par l’appel de la transaction VL02N pour lancer la
fonctionnalité de création de bon de livraison.
1.3.4 Création d’interface et formulaire
Nous avons créé d'abord une interface pour le formulaire Adobe.
Figure 4.15. Création d’interface
CHAIMAE ECHCHRIF 91
DE VENTE
Figure 4.16. Déclaration des données globales
Nous avons déclaré certaines données globales à utiliser comme variables dynamiques
sous la forme Adobe (voir Figure ).
Nous avons également déclaré les données importer depuis le programme (voir Figure
).
Figure 4.17. Déclaration des importations
Nous avons ensuite créé une mise en page de formulaire Adobe.
Figure 4.18. Création du formulaire
CHAIMAE ECHCHRIF 92
DE VENTE
Nous avons glissé et déposé les variables globales de l'interface dans le contexte de
notre mise en page de formulaire Adobe.
Figure 4.19. Drag and drop
Et nous avons finalement placé nos variables dynamiques dans la mise en page partout
où cela est nécessaire.
Figure 4.20. Mise en forme
1.4 Tests
Nous alons traiter comme cas de test le flux ZCS qui représente un flux d’une
commande de type standard paramétré pour le système INWI.
Le processus d’adaptation reste le même pour les autres types de commande, seules les
données qui varient.
CHAIMAE ECHCHRIF 93
DE VENTE
1.4.1 Création d’une commande client
Après la phase de paramétrage/adaptation du système SAP INWI , un utilisateur du

système sera capable de créer une commande à l’aide d’une transaction SAP , en
alimentant plusieurs zones sur des écrans de sélections.
Cette partie illustre la démarche de la création d’une commande de vente standard sous
SAP INWI.
Figure 4.21. Création commande
 Les informations générales de ventes dans l’écran de selection ,concernant tout le

processus de du vente et reception souhaité.
 l’affectation des articles relatifs à la commande client, en mentionnant le numéro du
poste, la quantité demandée, le type de l’article et des conditions sur le prix de l’article
et tou les informations necessaires pour la creation du commande .
CHAIMAE ECHCHRIF 94
DE VENTE
Informations supplémentaires :
Le type de document de vente utilisé est déjà créé, avec des contraintes
correspondantes aux besoins spécifiques. Le type de document de vente défini avec un
code ‘ZCS’, présente un document de type ‘commande client standard’.
Les entités organisationnelles nécessaires pour définir le domaine commerciale , qui se
compose de l’organisation commerciale ‘MCO’, le canal de distribution ‘10’ et le secteur
d’activité ‘10’, sont déjà définies et affectées sur le système pendant la phase de
paramétrage.
Une commande de ventes contient :
 Des informations du client donneur d’ordre (commandant) et le client réceptionnaire
(livré) à définir dans l’entête de l’écran de la création de la commande.
Figure 4.22. Creation de la commande en utilisant le module de fonction BAPI
Utilisation du module de fonction bapi_salesDocu_createfromdata1 pour la creation du

commande client à partir des données saisies au niveau de l’écran de sélection .
CHAIMAE ECHCHRIF 95
DE VENTE
1.4.2 Création livraison
 Ecran de sélection :
Un écran de sélection est l’écran permettant de présenter aux utilisateurs des zones de
saisie afin d’interagir avec le programme . C’est la présentation graphique de certaines
variables du programme.
Cette présentation graphique est gérée par programmation.
 Sélection d’une seule commande :
Figure 4.23. Ecran de séléction pour creation de la livraison
A travers cette écran de selection on peut saisir le numero du commande à fin
d’alimenter la livraison qu’on souhaite créer.
Figure 4.24.Remplissage du numero du commande

Figure 4.25. Création livraison avec référence à la commande
CHAIMAE ECHCHRIF 96
DE VENTE
Une deuxieme ecran pour saisir les données afin de continuer le process de creation du
livraison avec référence à la commande.
Figure 4.25: Message de creation de livraison
Après validation du statut de la commande au près du responsable des workflows de

validation, la création de la livraison s’impose afin de générer le bon de livraison.
Une fois la création de la livraison est enregistrée le bon de livraison s’affiche afin de
l’imprimer.
Configuration des options de sortie :

Avant de lancer l’impression , il est nécessaire de renseigner les difféernets
informations de sortie . Le champ relatif à l’unité de sortie ( l’imprimante ) est obligatoire.
Screeen lp01
Aperçu avant impression :

L’image ci-dessous illustre l’étiquette générée avant de lancer l’impression . SAP offre
la possibilité d’un aperçu avant impression ce qui nous permettra de visualiser les
étiquettes avant de lancer l’impression .
CHAIMAE ECHCHRIF 97
DE VENTE
Figure 4.27 : Gabarits mise en form du formulaire de bon de livraison

Figure 4.26. Bon de livraison
CHAIMAE ECHCHRIF 98
DE VENTE
1.4.3 Creation de la facture :
Figure 4.28.Programme pour creation d’écran de séléction pour creation du facture.
Figure 4.29.Ecran de séléction.
Pour créer notre facture il faut juste mettre le numero du livraison concernée , puis
alimentation de notre facture se fait grace aux données du livraison et commandes stockés .
Figure 4.30 :Creation de la facture
Message de creation de la facture avec succés.
CHAIMAE ECHCHRIF 99
DE VENTE
Figure 4.32. Interface du formilaire avec le programme d’alimentation du données .
Figure 4.33. La facture après l’impression
CHAIMAE ECHCHRIF 100

DE VENTE
Figure 4.34. Les données de facture (Exemple de test sur DEV)
1.5 Conclusion
Ce dernier chapitre a montré le travail effectué durant la période de stage, d’où on a

présenté l’environnement du développement, puis les étapes suivies pour la réalisation des
différents programmes et du formulaire et enfin les tests mis en place pour vérifier le bon
fonctionnement des programmes.

DE VENTE
Conclusion Générale
Le présent travail m’a permis de se familiariser et maitriser un des ERP les plus
important au niveau international, il s'agit bien évidemment du SAP.
Grâce à ce sujet j’ai pu découvrir plusieurs technologies et fonctionnalités SAP , chose
qui va me permettre d’avoir une base solide dans le volet technique et fonctionnel afin de
se lancer dans le marché de travail SAP.
Ce projet pointe sur le paramétrage des principales fonctionnalités d’administration de
ventes, via des programmes ABAP et des processus de ventes , ce qui va permettre à INWI
d’avoir une solution complète et fiable pour mieux gérer ses ventes .
La perspective de ce projet est l’intégration des autres modules de SAP prenant en
considération la satisfaction des besoins du client, ainsi que l’utilisation de SAP GUI .
En effet, l’objectif principal du projet était de faire une étude de la conception et la

réalisation de plusieurs solutions pour le Reporting de système SAP S4/Hana, le
développement des nouvelles solutions spécifiques demandées par notre client au gré
d’améliorer sa productivité.
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, le gain en temps d’exécution, ainsi en
offrant aux différents acteurs une flexibilité aussi bien technique que fonctionnelle.
Pour conclure, durant environ quatre mois de stage, j’ai eu l’opportunité de découvrir un
domaine qu’on a pas eu la chance de le découvrir durant notre formation à l’école , un
progiciel SAP complet et une solution prometteuse qui représentera surement une tendance
pour les sociétés au futur . Au-delà des connaissances acquises techniquement, la présence
quotidienne dans une société multinationale représente surement un plus dans un début de
carrière d’une jeune diplômée , cela permettra d’accélérer son intégration et facilitera son
insertion dans le monde professionnel.

DE VENTE
Références
[1] http://sap.technique.free.fr/
[2] https://www.guru99.com/
[3] http://saptechnical.com/Tutorials/AdobeForms/
[4] https://blogs.sap.com/
[5] https://wiki.scn.sap.com/
[6] https://www.tutorialspoint.com/
[7] https://help.sap.com/
[8] https://www.hebergementwebs.com/tutoriel-sap-abap/sap-abap-modules-de-fonction
[9] https://scn.sap.com/
[10] http://www.tutorialspoint.com/sap/sap_modules.htm
[11] http://www.erpgenie.com/sap/abap/tables_sd.htm
[12] http://www.michaelmanagement.com/sap-documentation.asp
[13] http://www.sap-integration.net
[14] https://open.sap.com
[15] http://www.sap-integration.net/Portals/16/PDF/JFO-ABAP-SCREEN.pdf
[16] http://www.chb.aphp.fr/rechercheClinique/definition/index.phtml
[17] http://www.sap123.com
[18] http://www.sap-basis-abap.com

Pfe Chaimae Echchrif

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pfe Chaimae Echchrif

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire de Projet de Fin d’Études

Pour l’obtention du diplôme

Intégration et adaptation d’une solution SAP ABAP

Promotion 2020 – 2021

M. /Mlle. Chaimae ECHCHRIF

Pr. CHRAYAH Mohamed Professeur ENSATé (Président)

A mes professeurs, enseignants, formateurs et tout le personnel de l'École Nationale des

Chaimae ECHCHRIF 2020-2021

Je tiens à exprimer mes remerciements et mon profond respect à notre éminent

Je tiens à remercier mon maître de stage, M. Zakaria EZ-ZAYATTE chef de

Je tiens à remercier en particulier M. Karim SEFIANI le directeur de l’équipe

Un grand merci à toute l’équipe technique et tout le personnel de ValuePass

Chaimae ECHCHRIF 2020-2021

La deuxième partie du projet a pour but de de concevoir et de réaliser une

Afin de bien comprendre le fonctionnement du système, nous avons d’abord procédé

Enfin la partie de paramétrage et la réalisation pour mettre en place et finaliser le

Chaimae ECHCHRIF 2020-2021

Mots clés : ERP, SAP, ABAP, vente et distributions, Flux de vente

Chaimae ECHCHRIF 2020-2021

Key words :ERP, SAP, ABAP, sales and distributions, Sales flow

Table des Matières

Chapitre 1 Contexte général du projet...................................................................................

1.1.1 Présentation générale de l’Entreprise...........................................................4

1.1.2 Missions de l’entreprise................................................................................5

Conseil en Management & Organisation :...............................................................6

Conseil et intégration ERP :.....................................................................................7

1.1.3 Solutions autorisées :....................................................................................8

1.2Clients de Value Pass.......................................................................................................

1.2.2 Fiche technique :.........................................................................................11

1.3.1 Périmétre du projet.....................................................................................12

1.3.2 Présentation du client.................................................................................13

1.3.3 Cadre du projet...........................................................................................14

1.5.1 Objectifs du projet......................................................................................17

1.6.1 Le choix du processus de développement :................................................18

1.6.2 Processus 2TUP..........................................................................................19

1.6.3 Planification du projet................................................................................20

CHAIMAE ECHCHRIF vii

Chapitre 2 Spécification des exigences fonctionelles et techniques...................................

1.Analyse et identification des besoins...............................................................................

1.1. Étude de l’existant (Le AS IS)................................................................................

1.3Expression de besoin (Le TO BE).................................................................................

1.4Diagramme Bête à corne................................................................................................

1.5Spécification des besoins...............................................................................................

1.5.1 Etude fonctionnelle générale......................................................................27

1.5.2 Informations générales...............................................................................27

1.5.3 Synthèse fonctionnelle du développement.................................................28

1.5.4 Ecran de sélection.......................................................................................28

1.5.5 Logique de sélection...................................................................................28

1.5.6 Maquette du Formulaire.............................................................................28

1.5.7 Règles de gestion détaillées........................................................................29

1.6Identification des processus à paramétrer......................................................................

1.7Spécification des exigences non-fonctionnelles............................................................

1.9Analyse des Besoins......................................................................................................

1.9.1 Cas d’utilisation (Use case)........................................................................34

1.9.2 Diagramme d’activité.................................................................................35

1.9.3 Diagramme de séquence.............................................................................36

1.10 Spécifications techniques : la solution SAP...........................................................

1.11 Vue générale de SAP..............................................................................................

1.11.1 Architecture modulaire...........................................................................38

1.12 Mise en place de la solution SAP...........................................................................

1.12.1 Mode de déploiement..............................................................................38

CHAIMAE ECHCHRIF viii

Chapitre 3 Déploiement de SAP……………………………………………………….40