Conception et développement de la gestion de visa sous Dynamics Ax R2

1
RAPPORT DE STAGE D’ETE
Spécialité : Informatique
Option : Ingénierie Informatique
Par
Rawdha MABROUKI
Entreprise d’accueil
Encadrant professionnel
Madame Malek MOKLINE
Année universitaire
2015/2016
Année universitaire 2015/2016
Conception et Développement d’un Module
Dynamics Ax de Gestion de Visa

ii
Remerciements
Mes remerciements les plus distingués sont adressé au membre des jurys qui m’ont fait
l’honneur de bien vouloir accepter d’évaluer ce modeste travail et d’avoir accepté de rapporter
ce modeste travail et d’avoir trouvé la force de lire, corriger et critiquer. Enfin je remercie
madame Safa RAFAI rapporteur pour les critiques relatives au rapport.
Je tiens à exprimer toutes mes gratitudes à Mme Malek Mokline pour avoir supervisé le
cheminement de ce travail, aussi pour ses encouragements et surtout pour ses conseils et ses
orientations précises émanant d’une rigueur et d’une expérience précieuse.

iii
Sommaire
Introduction générale............................................................................................................... 1
Chapitre I. Contexte de Projet............................................................................................ 3
1.1 Introduction ................................................................................................................ 3
1.2 Présentation de l’entreprise d’accueil ........................................................................ 3
Objectifs ................................................................................................................. 3
Domaines d’activités.............................................................................................. 3
1.3 Présentation du projet................................................................................................. 4
Motivations............................................................................................................. 4
Objectif du projet ................................................................................................... 4
1.4 Méthodologie et formalisme adoptées ....................................................................... 4
1.5 Etat de l’art................................................................................................................. 5
Entreprise Ressource Planning............................................................................... 5
Microsoft Dynamics............................................................................................... 5
Architecture fonctionnel de Dynamics AX............................................................ 6
Architecture en couches de Dynamics Ax ............................................................. 7
Architecture Technique de Dynamics Ax .............................................................. 7
Niveau accès aux données...................................................................................... 7
Niveau intermédiaire.............................................................................................. 7
Niveau présentation................................................................................................ 8
1.6 Problématiques........................................................................................................... 8
1.7 Conclusion.................................................................................................................. 8
Chapitre II. Mise en œuvre............................................................................................... 9
2.1 Introduction ................................................................................................................ 9
2.2 Spécification des besoins ........................................................................................... 9
Diagramme de cas d’utilisation générale ............................................................... 9
Prototypes............................................................................................................. 11
2.3 Conception ............................................................................................................... 17

iv
2.4 Environnement de développement........................................................................... 20
MorphX IDE ........................................................................................................ 20
Langage X++........................................................................................................ 21
Pattern de formulaire de Dynamics Ax ................................................................ 21
Service de reporting ............................................................................................. 22
2.5 Architecture de l’application.................................................................................... 22
2.6 Réalisation................................................................................................................ 23
2.7 Conclusion................................................................................................................ 27
Conclusion générale ............................................................................................................... 28
Bibliographies............................................................................................................................i
Webographies ...........................................................................................................................ii

iv
Liste des figures
Figure I-1 : Les différentes vues du langage UML .................................................................... 5
Figure I-2 : Architecture fonctionnel d’AX [W1]...................................................................... 6
Figure I-3 : WorkerList Page ..................................................................................................... 6
Figure I-4 : Architecture technique d’AX.................................................................................. 8
Figure II-1 : Diagramme de cas d'utilisation générale ............................................................. 10
Figure II-2 : Prototype List Page.............................................................................................. 11
Figure II-3 : Prototype demande de visa de sortie terminale ................................................... 12
Figure II-4 : Prototype demande de visa entré sortie pour plusieurs voyages ......................... 13
Figure II-5 : Prototype Demande de visa pour une mission Temporaire................................. 14
Figure II-6 : Prototype demande de visa pour une entré sortie un seul voyage ....................... 15
Figure II-7 : Prototype Demande de visa pour une résidence temporaire................................ 16
Figure II-8 : Modèle conceptuel de données............................................................................ 17
Figure II-9 : Diagramme de classe ........................................................................................... 18
Figure II-10 : Schéma relationnel de la base de données......................................................... 19
Figure II-11 : Table HCMPerson Private Details..................................................................... 19
Figure II-12 : MorphyX le Developper Workspace................................................................. 20
Figure II-13 : MorphX IDE éditeur de code X++ .................................................................... 21
Figure II-14 : Architecture d'une Business Application........................................................... 22
Figure II-15 : Interface Visa Request List page ....................................................................... 24
Figure II-16 : Interface Visa Request Master Détails Page...................................................... 24
Figure II-17 : Interface Master Détails page de gestion de visa pour un employé................... 25
Figure II-18 : Interface de grille de Modification de demande de Visa................................... 25
Figure II-19 : Interface vue en tête de la page Transactional détails d'ajout de demande ....... 26
Figure II-20 : Interface transactionnel Détails Page vue ligne................................................. 26

v
Liste des tableaux
Tableau I-1 : Modèle de couches de Dynamics Ax.................................................................... 7
Tableau II-1 : Liste des classes................................................................................................. 18

1
Introduction générale
Un système d'information est un ensemble organisé de ressources qui permet de collecter,
regrouper, classifier, traiter et diffuser de l'information sur un environnement donné. C’est un
système dédié et ouvert sur son environnent. Il produit des informations en utilisant le cycle de
sortie du processus d’entrée. L'élément le plus important dans un système d'information est ces
données.
Les systèmes d'information traditionnels présentent un inconvénient majeur. En effet, ces
systèmes ne donnent que les informations, qui ont été conçus d’être produites au moment où ils
ont été construits. Or dans une entreprise, les employés appartenant à un département donné ne
disposent pas d'information sur les autres départements. Au niveau de la direction, les rapports
de synthèses sont distribués à tous départements, mais ces rapports ne permettent pas de capter
l’image réelle sur l’état globale de l’entreprise. D’où vient le besoin d’avoir une vue globale
sur différents départements d’une entreprise.
De nombreuses grandes entreprises utilisent les systèmes d’informations appelées progiciel de
gestion d’entreprise ou Entreprise Ressources Planning (ERP), car ils fournissent un soutien
rentable pour les employés, superviseurs, chef de projet et gestionnaires de l'entreprise.
L’ERP est prévu d'améliorer le flux de l'information et de formaliser, intégrer et automatiser
tous les processus et les flux de travail qui existent dans une organisation. L’ERP peut exécuter
des fonctions effectuées par les employés comme l’enregistrement des données, le contrôle des
procédures, les calculs ou la préparation des rapports.
Les ERP sont des applications permettant de coordonner l'ensemble des activités d'une
entreprise (activités dites verticales telles que la production, l'approvisionnement ou bien
horizontales comme le marketing, les ventes, la gestion des ressources humaines, etc.) autour
d'un même système d'information. Ils offrent à l'entreprise, une solution globale et transversale
[1]. Notamment, il garantit la fiabilité la non redondance et non modification non permise des
informations ainsi qu’il permet la visibilité en temps réel des activités et d’éviter la double
saisie.
Les principaux éditeurs des ERP propriétaires du marché on peut citer SAP (leader mondiale),
Oracle/People Soft, Sage ADONIX, Microsoft, SSA Globale etc. Microsoft vend des ERP,

2
nommé Dynamics tel que Microsoft Dynamics Navision pour petites et moyennes entreprises
et Dynamics Axapta pour les entreprises de grande taille.
Dans le cadre de stage d’été de la deuxième année ingénierie informatique, nous avons visité
une société travaillant dans le consulting ERP Microsoft. ODI.C Sarl est spécialisée dans le
domaine du consulting, sur les deux solutions de Microsoft Dynamics Navision et Axapta. Elle
prend en charge l’intégration ERP, la réalisation d’audit, le suivie des spécifications, la
formation des utilisateurs support clients et le suivie des projets. Les consultants en entreprise
sont des professionnels, qui se spécialisent dans le développement de techniques et de méthodes
pour faire face à la mise en œuvre et les différents problèmes. Ils sont experts dans
l’administration, la gestion et le contrôle des projets.
Le projet tel qu’il m’a été présenté à ODI.C consiste à développer une application sur Dynamics
Ax, permettant de gérer la totalité des dossiers de demande de Visa des employés d’une
compagnie libyenne d’activité pétrolière. Ce projet devra inclure la traduction des documents
en arabes à des prototype puis la conception et création des formulaires Dynamics Ax.
Afin de réaliser ces tâches, il sera nécessaire de définir les besoins fonctionnels ou cas
d’utilisation, et créer une nouvelle table dite VisaRequest.
Ce travail sera traité en deux chapitres. Le premier sera consacré à étudier l’environnement de
travail professionnel et technique ce qui inclut une étude de l’aspect technique et fonctionnel
de l’ERP Dynamics Ax. Le deuxième se penchera sur l’analyse et la conception de la solution
adéquate. En fin, nous montreront les formulaires que nous avons réussi à développer et nous
finirons par une conclusion rappelant les travaux réalisés.

3
Chapitre I. Contexte de Projet
1.1 Introduction
Dans ce chapitre nous présenterons le contexte général du projet. Nous commencerons par
présenter la société « ODIC ». Nous allons détailler les services qu’elle offre ainsi que les
domaines de compétences qui font sa renommée. Ensuite, nous introduisions le cadre général
de notre travail. Enfin nous présentant l’état de l’art et le problématique.
1.2 Présentation de l’entreprise d’accueil
Ce projet a été réalisé au sein de la société « Organisation Développement Intégration et
Consulting » ou « ODI.C » qui peut se targuer d’être le leader en Tunisie dans le domaine
d’intégration des progiciels centralisant les données et les fonctions de gestion de l'entreprise
dit « Progiciel de Gestion Intégrer » ou encore PGI de type « Microsoft Dynamics Axapta »
ODI.C une société de conseil en informatique spécialisée dans la mise en œuvre d’E.R.P. ODIC
Sarl est fondée en 2007 en Tunisie, ayant un effectif de 20 collaborateurs. Elles offrent des
solutions pour plus de 20 clients en Tunisie et à rangé pour les domaines d’industrie, textiles et
pétrole.
Objectifs
Les objectifs d’ODI.C se résument dans l’assistance des clients dans la définition de leur
politique informatique. Puis l’accompagnement des clients dans le développement de leur
système d’information, Anticipation des évolutions. Enfin le support des clients lors de la
gestion de leurs données.
Domaines d’activités
ODIC travaille dans trois domaines d’activités, ce sont : le consulting organisationnel, la mise
en place de système d’informations et l’analyse et exploitations des bases de données. Le
consulting est constitué des activités de la mise en place et suivi de l’application, les méthodes
de gestion ; stocks, ventes et approvisionnement …la mise en place de système d’information
consiste à l’assistance au déploiement d’ERP, la maîtrise d’ouvrage sur des projets ERP et
infrastructure, la gestion de projets, l’intégration et le développement de l’ERP Dynamics
Navision et Dynamics Axapta. En fin l’analyse des données consiste à développer le reporting
et business intelligence spécifique en utilisant les outils les outils BI de Microsoft.

4
1.3 Présentation du projet
L’objectif du stage consiste à développer un module de gestion des visas des employés dès
l’élaboration d’une demande vers la clôtures de leurs visas. Dans cette partie nous allons
présenter les motivations de choix du sujet et l‘objectif du projet.
Motivations
Le choix du projet de stage d’été est une étape délicate, puisqu’elle matérialise la transaction
entre l’environnement éducationnel et la vie professionnelle.
Plusieurs motivations ont orienté notre choix :
 En premier lieu, notre sujet fait le lien entre nos atouts qui sont l’informatique et la gestion.
 En second lieu, l’ERP est devenu un sujet très important voire un sujet d’actualité. Il est au
cœur des préoccupations de toutes les entreprises qui cherchent à automatiser ses processus
métiers.
 En troisième lieu, il nous permet d’approfondir encore plus nos connaissances en matière
d’ingénierie informatique en ayant l’occasion de travailler avec des technologies innovantes
telle que la technologie MorphX et SQL Server 2012.
Objectif du projet
Le travail demandé consiste à concevoir et à implémenter un module de gestion et suivi de visa
des employés d’une entreprise travaillant dans le domaine de production pétrolière. Notre
objectif est de développer une application Dynamics Ax qui permet le suivie des dossiers de
demande de visa en traduisant les documents de demande de visa en arabe en des formulaires.
1.4 Méthodologie et formalisme adoptées
Le plus grand avantage d’une méthode orientée objet est qu’elle permet de structurer un
système sans centrer l’analyse uniquement sur les données ou uniquement sur les traitements
mais sur les deux à la fois. Une telle approche a pour but de modéliser les propriétés statiques
et dynamiques de l’environnement du système. Elle met en correspondance le problème et la
solution, en préservant la structure et le comportement du système analysé.
Ceci, nous a conduit à adopter l’approche orientée objet pour modéliser notre système en se
basant sur les diagrammes UML [3].
La figure I-1 illustre les diagramme d’UML. Nous allons utiliser le diagramme de classe afin
de modéliser l’aspect statique du module, le diagramme de cas d’utilisation afin de modéliser
l’aspect fonctionnel.

5
1.5 Etat de l’art
Dans cette partie nous allons présenter l’état de l’art de notre projet. Donc cette partie nous
allons détailler le système existant (l’ERP Dynamics Ax). Ainsi que nous allons présenter la
problématique du projet.
Entreprise Ressource Planning
Un ERP est un « logiciel qui permet de gérer l’ensemble des processus d’une entreprise en
intégrant l’ensemble des fonctions de cette dernière comme la gestion des ressources humaines,
la gestion comptable et financière, l’aide à la décision, et aussi la vente, la distribution,
l’approvisionnement, la commerce électronique ».
Microsoft Dynamics
Dynamics est une gamme de progiciels de gestion d’entreprise conçue par Microsoft. Cette
gamme, qui fut également connue sous le nom de Project Green. Il est le successeur de
l’ancienne famille de logiciels destinée à la gestion d’entreprise, Microsoft Business Solutions.
Il est présent dans 28 pays pour un effectif de 4 000 salariés. Il inclut les logiciels suivants,
Dynamics Ax, Dynamics GP (anciennement Great Plains), Dynamics NAV (anciennement
Navision) et Dynamics SL (anciennement Solomon). Étude fonctionnelle de Dynamics Ax.
Ax est un ERP générique conçu pour les entreprises de 200 à 7500 utilisateurs. Il soutient les
organisations mondiales en gérant plusieurs sites opérationnels par le biais de Master data et
les processus métier. Ainsi que les capacités propres à chaque pays sont gérées en une seule
instance.
Figure I-1 : Les différentes vues du langage UML

6
Architecture fonctionnel de Dynamics AX
La solution Microsoft Dynamics AX est un progiciel de gestion intégré PGI (ERP Entreprise
Resource Planning) qui intègre la gestion des ressources financière, la gestion de la chaine de
production, et le processus de gestion des ressources humaines (cf. figure I-2). Dynamics AX
inclut des fonctionnalités embarquées pour les secteurs de l’industrie, de la distribution, des
services, du commerce et y compris le secteur public [2].
La figure ci-dessus illustre un aperçu sur l’architecture fonctionnel de Dynamics Ax. Cette
architecture englobe aussi les fonctions de vente et marketing, des outils de reporting et
l’informatique décisionnel ainsi que le workflow et l’espace de travail collaboratif.
Enfin nous avons fait une étude sur le module gestion des ressources humaine existants tels que
List Page Workers.
La figure ci-dessus illustre la page liste des employées. Nous allons personnaliser cet interface.
MS
Dynamics
AX
Gestion
Financiére
production
Approvisionneme
nt
Marketing et
VentesGestion de
projet et
comptabili
té
Gestion des
Ressources
Humaine
Décisionnel et
reporting
Espace de
travail
collaboratif
Figure I-2 : Architecture fonctionnel d’AX [W1]
Figure I-3 : WorkerList Page

7
Architecture en couches de Dynamics Ax
Le tableau I-1 illustre chaque couche dans Microsoft Dynamics Ax. Nous allons créer notre
module sur la couche VAR.
Tableau I-1 : Modèle de couches de Dynamics Ax
Architecture Technique de Dynamics Ax
L'architecture logique du système est une architecture 3tier (cf. figure I-4). Divisée en trois
niveaux ou couches : niveau Accès aux données, niveau intermédiaire, niveau présentation.
Niveau accès aux données
La base de données est gérée par MS SQL Server 2012. Le serveur de base de données héberge
le contenu SharePoint Server et la configuration des bases de données, la base de données de
l’application, la base de données de SSRS et la base de données SSAS. Enfin les relations entre
les tables de la base de données sont gérées coté AOS (Application Object Server).
Niveau intermédiaire
Le niveau intermédiaire comprend le serveur Application Object Server. L’AOS est le serveur
d’application de MS Dynamics Ax. C’est là où le logique métier s’exécute. Notamment l’AOS
permet d’exécuter des services d'application MorphX. Les services sont invoqués par la
technologie RPC et Windows Communication Foundation (WCF) dans le .NET Framework.
L’AOS peut être hébergé sur un ordinateur, mais il peut aussi évoluer sur de nombreux
ordinateurs lorsque des sessions utilisateur simultanées supplémentaires ou des serveurs dédiés
sont nécessaires.
Couche Description
USR
User layer : La couche d’utilisateur pour les modifications réalisé par l’utilisateur, tels que les
rapports.
CUS
Customer layer : La couche de client permet d’apporter des modifications qui sont spécifiques à
une entreprise.
VAR
Value Reseller layer : Revendeurs à valeur ajoutée (VAR) peut apporter des modifications ou de
nouveaux développements de la couche VAR comme spécifié par les clients ou comme une
stratégie de création d’une solution spécifique de l’industrie.
ISV
Independent software vendor layer : Quand un fournisseur indépendant de logiciels (ISV) crée
sa propre solution, les modifications sont enregistrées dans la couche ISV.
SLN
Solution layer : La couche de solution est utilisée par les distributeurs à mettre en œuvre les
solutions des partenaires verticaux.
FPK
Feature Pack layer : La couche FPK est une couche de brassage de l’objet de l’application
réservée par Microsoft pour les mises à jour.
GLS
Globalisation layer : Lorsque l’application est modifiée en fonction de besoins juridiques propres
à chaque pays ou région, ces modifications sont enregistrées dans la couche GLS.
SYS
System layer : L’application standard est mise en œuvre au niveau le plus bas, dans la couche
SYS. Les objets d’application dans la couche SYS ne peuvent jamais être supprimés.

8
Niveau présentation
Le niveua présentation est constitué du client Windows et Entreprise Portal. Le Client Windows
exécute les applications Microsoft Dynamics AX et .NET développées dans MorphX et Visual
Studio. L'application client communique avec l'AOS principalement en utilisant RPC (cf.
Figure I-4). Client Workspace ou Rich Client présente deux parties : navigation pane et content
pane. Navigation pane est le menu à gauche qui affiche tous les modules accessibles par
l’utilisateur selon son rôle défini. Le content Pane affiche tous les données spécifiques (reports,
alerts, tasks …) d’un module selon le rôle de l’utilisateur. Ils existent des patterns d’interface
de Dynamics Ax : nous allons utiliser seulement : ListPage, MasterDétails, Transactional
Détails.
1.6 Problématiques
La gestion de demande de visa doit comprendre les demandes pour une mission temporaire,
demande de résidence temporaire, le renouvellement d’un visa de résidence temporaire,
l’extension d’un visa, la demande de sortie et entré etc. Le problème des systèmes de gestion
de visa c’est qu’il coute très cher. En fait ces applications ne permettent pas une interopérabilité
avec les autres modules de Dynamics ax tel que le module de gestion de ressources humaines.
Puis ces systèmes n’offrent pas la fonctionnalité de traduction vers d’autre langue tel que
l’arabe. Donc le développement d’un nouveau module Dynamics Ax de gestion de visa est
nécessaire afin de garantir les besoins de l’entreprise cliente.
1.7 Conclusion
Dans ce chapitre nous avons introduit la technologie d’ERP Dynamics AX de Microsoft. Nous
avons détaillé l’aspect fonctionnel et technique de cet ERP. Nous avons présenté les outils de
développement que nous allons utiliser afin d’implémenter notre application. Ainsi que nous
avons présenté les différents outils de Reporting utilisé au niveau de Dynamics Ax. Plus
précisément l’outil de SSRS qui sera la suite de notre projet si enfin nous avons terminé avec
les formulaires.
Figure I-4 : Architecture technique d’AX

9
Chapitre II. Mise en œuvre
2.1 Introduction
Dans ce chapitre nous allons détailler le design de notre application en mettant en œuvre
l’expérience utilisateur. Afin de concevoir une application en suivant les patterns de Dynamics
Ax nous allons réaliser le prototypage. Avons tous nous allons définir les besoins de l’utilisateur
puis concevoir la structure de données. Enfin nous allons réaliser les interfaces utilisateurs.
2.2 Spécification des besoins
Afin de dégager les besoins de notre application nous avons examiné les différents documents
(version papier) de demande de visa d’une employée. Nous avons convertie chaque document
en un prototype.
Diagramme de cas d’utilisation générale
Cette étude nous a donné les cas d’utilisation suivant :
 Demander visa pour une mission temporaire
 Demander visa de résidence temporaire
 Renouveler un visa de résidence temporaire
 Extension d’un visa
 Demander visa de sortie et entré pour un seul voyage
 Demander visa de sortie et entré pour plusieurs voyages
 Déclarer un changement de données
 Demander visa de sortie finale
 Demander visa business trip
 Choisir catégorie de visa
 Imprimer information
Chaque cas d’utilisation peut être fini par l’exécution d’un cas d’utilisation de reporting
imprimer information (cf. Figure II-1).

10
La figure ci-dessus illustre le diagramme de cas d’utilisation générale.
Figure II-1 : Diagramme de cas d'utilisation générale

11
Prototypes
Afin de développer un prototype nous avons choisi GUI design Studio. C’est un logiciel
professionnel qui permet de crée des maquettes pour le design des interfaces graphique des
utilisateurs pour les applications windows. GUI design studio permet de vérifier le design,
documenter la spécification des besoins, évalué les différents scénarios et démontrer les
prototypes. Afin de convertir les informations citées sur les papiers de visa en arabe à des
informations numérique en anglais, nous avons créé pour chaque document un prototype.
La figure ci-dessus illustre le prototype de la page de type List Page. Nous envisageons à
afficher les détails d’une demande et les informations du demandeur.
Figure II-2 : Prototype List Page

12
La figure ci-dessus illustre le prototype du document de demande de visa de sortie terminale.
Figure II-3 : Prototype demande de visa de sortie terminale

13
La figure ci-dessus illustre le prototype de la demande d’une entrée et sortie pour plusieurs
voyages.
Figure II-4 : Prototype demande de visa entré sortie pour plusieurs voyages

14
La figure ci-dessus illustre le prototype converti du document d’une demande de visa pour une
mission temporaire.
Figure II-5 : Prototype Demande de visa pour une mission Temporaire

15
La figure ci-dessus illustre le prototype converti du document demande de visa pour une entrée
et sortie pour un seul voyage.
Figure II-6 : Prototype demande de visa pour une entré sortie un seul voyage

16
La figure ci-dessus illustre le prototype converti du document d’une demande de visa pour une
résidence temporaire.
Figure II-7 : Prototype Demande de visa pour une résidence temporaire

17
2.3 Conception
Afin de concevoir notre module, nous avons créé le modèle conceptuel de données avec la
spécification des relations et clé primaires. En effet un employé inscrit dans les activités de
l’entreprise peut être affecté à une nouvelle demande de visa.
 Une demande de visa est relative à un et un seul employé
 Un employé peut être affecté à un ou plusieurs demandes de visa
La figure ci-dessus illustre le modèle conceptuel de données qui permet de convertir les
Business rules à des entités et relations.
VisaRequest
#
o
o
o
o
o
o
o
o
o
o
NumVisa
ResidenceN
DateExpiration
ResidenceType
Travel to
ReasonOfTrip
DateOFTrip
PasseportNum
ExpirationPasseport
DateIssue
PlaceIssue
Number
Number
Date
Text
Text
Text
Date
Number
Date
Date
Text
Person
#
o
o
o
PersonID
FirstName
LastName
PersonBirthCountryRegion
Number
Text
Text
Text
HCMWorker
#
o
o
o
reqId
coût($/H)
Partitien
PersonelNumber
Integer
Number
Variable characters (254)
Variable characters (254)
HCMPersonPrivateDetails
o
o
o
o
o
o
o
o
o
o
o
BirthDate
CitizenshipCountryRegion
DeceasedDate
DisabledVerificationDate
Education
EthnicOrigin
FatherBirthCountryRegion
Gender
IsDisabled
IsFullTimeStudent
NativeLanguage
Date
Text
Date
Boolean
Text
Text
Text
Short integer
Boolean
Boolean
Text
demander pour
1,1
0,n
détail
1,1
0,n
identifier par
1,1
0,n
Figure II-8 : Modèle conceptuel de données

18
Nous avons défini le diagramme de classe avec une précision de nouvelles classes. Nous avons
ainsi ajouté la classe VisaRequest dans le systéme existant. La figure ci-dessus le diagramme
de classe de module.
Tableau II-1 : Liste des classes
Classe Détails
HCMPersonPrivateDetails Permet de stocker les information privées d’un employé afin de
l’utiliser dans la demande de visa.
HCMWorker Permet d’explorer la liste des employé inscrit dans l’entreprise, qui
peuvent être candidatas d’une acceptation de visa
Person Permet de stocker les détails d’une personne
VisaRequest Créer afin de stocker les informations relatives à une demande de
visa pour un employé candidat d’une sortie
Le tableau ci-dessus illustre les détails des classes du module.
VisaRequest
+
+
+
+
+
+
+
+
+
+
+
NumVisa
ResidenceN
DateExpiration
ResidenceType
Travel to
ReasonOfTrip
DateOFTrip
PasseportNum
ExpirationPasseport
DateIssue
PlaceIssue
: double
: double
: Date
: String
: String
: String
: Date
: double
: Date
: Date
: String
+
+
+
Add ()
Update ()
Delete ()
Person
+
+
+
+
PersonID
FirstName
LastName
: double
: String
: String
: String
HCMWorker
+
+
+
+
reqId
coût($/H)
Partitien
PersonelNumber
: int
: double
: String
: String
+
+
+
+
+
+
+
+
+
+
+
BirthDate
DeceasedDate
Education
EthnicOrigin
Gender
IsDisabled
IsFullTimeStudent
NativeLanguage
: Date
: String
: Date
: boolean
: String
: String
: String
: short
: boolean
: boolean
: String
Figure II-9 : Diagramme de classe

19
Nous avons transformé le modèle orienté objet en modèle physique de données. Notamment le
modèle physique de données permet de valider le schéma de la base de données en spécifiant
les clés étrangères à partir des cardinalités et relations entre classes.
Afin de créer la table VisaRequest nous avons utilisé les champs des tables HCMWorker,
HCMApplicant (candidature) et HCMPerson.
La figure ci-dessus illustre la table existante HCMPersonPrivateDetails et la table DirPerson.
VisaRequest
NumVisa
reqId
ResidenceN
DateExpiration
ResidenceType
Travel to
ReasonOfTrip
DateOFTrip
PasseportNum
ExpirationPasseport
DateIssue
PlaceIssue
numeric
int
numeric
datetime
varchar(254)
varchar(254)
varchar(254)
datetime
numeric
datetime
datetime
varchar(254)
<pk>
<fk>
Person
PersonID
FirstName
LastName
numeric
varchar(254)
varchar(254)
varchar(254)
<pk>
HCMWorker
reqId
PersonID
coût($/H)
Partitien
PersonelNumber
int
numeric
numeric
varchar(254)
varchar(254)
<pk>
<fk>
PersonID
BirthDate
DeceasedDate
Education
EthnicOrigin
Gender
IsDisabled
IsFullTimeStudent
NativeLanguage
numeric
datetime
varchar(254)
datetime
bit
varchar(254)
varchar(254)
varchar(254)
smallint
bit
bit
varchar(254)
<fk>
reqId = reqId
0..*
PersonID = PersonID
0..*
PersonID = PersonID0..*
Figure II-11 : Schéma relationnel de la base de données
Figure II-10 : Table DirPerson et HCMPersonProvateDetails

20
la figure ci-dessus illustre la table HCMWorker.
2.4 Environnement de développement
Microsoft Dynamics AX comprend un ensemble d'outils de développement ou IDE, que nous
pouvons utiliser pour construire et modifier notre application.
La figure ci-dessus illustre le workspace développeur nommé MorphyX. Nous avons utilisé cet
outil afin de créer les tables, les énumérations, les type de données étendues dans le dictionnaire
de donnes et les formulaires.
MorphX IDE
MorphX est un environnement intégré de développement dans Microsoft Dynamics AX qui
permet de développer des modèles de données et des codes en utilisant un outil de modélisation
Figure II-13 : MorphyX le Developper Workspace
Figure II-12 : Table HCMWorker

21
de l'application AOT (Application Object Tree). Ainsi qu’il permet de réaliser des
personnalisations faites graphiquement pour concevoir des types de données, des tables, des
requêtes, des formulaires, des menus et des rapports. Cet environnement de développement
accède aux services de serveur d'applications AOS grâce à RPC (Remote Procedure Call) [2]
L’AOT est le point principal pour l’activité de développement. Il permet de parcourir le
référentiel (repository) de tous les éléments qui composent l’application. Nous pouvons utiliser
l’AOT pour invoquer des autres outils et d'inspecter et de créer des formulaires, des Rapports
et des Requêtes.
Langage X++
Le langage utilisé pour développer des applications Dynamics AX se nomme X++. Il s’agit
d’un langage respectant les principes de la programmation orientée objet tels que
l’encapsulation, l’héritage, les classes, les objets, les méthodes et les propriétés. La syntaxe du
langage X++ est proche de celle du langage C# ou java. Ajoutons aussi que X++ permet la
manipulation des données par l'intermédiaire du langage SQL [2].
La figure ci-dessus illustre l’éditeur de code X++ sous MorphX.
Pattern de formulaire de Dynamics Ax
Les formulaires sont créés de telle sorte que l'utilisateur final peut entrer et afficher des données
de manière flexible. Les patterns de formulaires permettent la navigation plus facile pour
l'utilisateur final, les menus et les options de menu sera créé sur tout type de formulaire.
Type des formulaires
 List Page
Figure II-14 : MorphX IDE éditeur de code X++

22
 DetailsFormMaster
 DetailsFormTransaction
 SimpleListDetails
 SimpleList
 TableOfContents
 Dialogue
 DropDialog
Service de reporting
Le terme "reporting" désigne une famille d'outils de business intelligence destinés à assurer la
réalisation, la publication et la diffusion de rapports d'activité selon un format prédéterminé.
[W6]. Le reporting permet de prendre des décisions stratégiques ou des actions sur la base des
connaissances acquises (analysis) à partir de sources de données. Il permet donc de réduire la
charge du service informatique grâce à l’auto-génération de rapports. SQL Server Reporting
Services crée des rapports standards ou personnalisables. [W1] Microsoft SQL Server
Reporting Services est la plateforme basique de reporting dans Microsoft Dynamics AX.
2.5 Architecture de l’application
Elle est constituée généralement de trois niveaux : l’interface utilisateur, le logique métier et la
structure de donnée (cf. figure24).
Nous allons développer des formulaires et des menus constituant l’interface utilisateur. Puis
nous allons attacher pour chaque interface des classes constituant le logique métier de notre
module. Mais avons tous allons créer une table constituant la structure de données de notre
module.
User Interaction
(Layout)
Forms
Menus
Business Logic
Classe
Méthode
Data Structures
Data
Dictionnary
Tables
Filds
Figure II-15 : Architecture d'une Business Application

23
2.6 Réalisation
Dans cette phase, les concepts et les objectifs sont traduits en actions concrètes, et en
conséquence, il est peut-être l’une des phases les plus difficiles du projet. Nous décrivons
brièvement les interfaces créées.

24
Le premier formulaire qui s’affiche dans l’application est le List Page. Il fournit une vue simple
et ergonomique.
Nous pouvons ajouter une nouvelle demande de visa en cliquant sur le boutant new ou nous
pouvons modifier un enregistrement sélectionné. La figure ci-dessus illustre l’interface listPage
de demande de visa.
La figure ci-dessus illustre la page de type master détails de gestion de demande de visa.
Figure II-17 : Interface Visa Request Master Détails Page
Figure II-16 : Interface Visa Request List page

25
Si l’utilisateur a choisi de modifier les enregistrements il peut ouvrir la grille de modification
pour éditer les enregistrements. La figure ci-dessus illustre la page de modification de la
demande sur la grille.
La figure ci-dessus illustre l’interface master détails de gestion de gestion d’un visa.
Or, si l’utilisateur a choisi de modifier un enregistrement particulier il peut continuer avec le
formulaire type détails page et modifier sur la grille.
La figure ci-dessus illustre l’interface de modification dans la grille.
Figure II-19 : Interface de grille de Modification de demande de Visa
Figure II-18 : Interface Master Détails page de gestion de visa pour un employé

26
La figure ci-dessus illustre l’interface de gestion des demandes de type Transactional détails.
Ce formulaire à deux pages : en tête et ligne.
La figure ci-dessus illustre la vue en tête de la page Transactional détails d’ajout d’une
demande. Dans cette page l’utilisateur peut ajouter les dépendants d’un demandeur de visa dans
la grille.
Figure II-21 : Interface transactionnel Détails Page vue ligne
Figure II-20 : Interface vue en tête de la page Transactional détails d'ajout de demande

27
2.7 Conclusion
Dans ce chapitre nous avons réussi à définir exactement les besoins fonctionnels de notre
application en utilisant le diagramme de cas d’utilisation et les prototypes. Puis nous avons
réussi à concevoir le module en utilisant le diagramme de classe et les modèles physique et
conceptuel. Ainsi que nous avons présenté les différents formulaires que nous avons réussis à
implémenter.

28
Conclusion générale
Ou cour de ce stage d’été nous avons bénéficié d’une expérience enrichissante du milieu
professionnel. Nous avons profité d’une expérience théorique et pratique afin de saisir les
différents aspects technique et fonctionnels d’un ERP Puissant : Dynamics Ax. Alors, Nous
avons eu deux semaines pour la recherche des informations relatives à cet ERP. Puis nous avons
eu deux autres semaines pour faire des études pratiques des différents composants et outils de
développement sur Dynamics Ax. Nous avons réalisé la spécification des besoins en deux
semaines et une autre pour la conception. Afin de réaliser la spécification des besoins nous
avons converti les documents de visa en arabe en des prototype en anglais. Puis nous avons
réalisé les interfaces dans une semaine.
Enfin, nous avons réussi à concevoir et à implémenter un module de gestion des demandes de
visa sous les exigences demandés et les standards de Microsoft Dynamics Ax.
Notre module nécessite d’autre amélioration en termes de navigation entre formulaires et design
de l’expérience utilisateur. Ainsi qu’une extension de ce module peut être le sujet d’une
perspective. Nous pouvons donc développer une application mobile qui permet de gérer les
visas en communiquant avec notre module.

Bibliographies
[1] Enterprise Resource Planning by Alexis Leon L&L Consultancy Services Prt Ltd Chennao
Tata McGraw-Hill Publishing Company Limited New Delhi
[2] Inside Microsoft Dynamics® AX 2012, by the Microsoft Dynamics AX Team, Published
by Microsoft Press
[3] Microsoft Dynamics AX 2012 – Une nouvelle génération de système ERP AD Ultima
Group
[4] Microsoft System Center Reporting Cookbook Samuel Erskine Dieter Gasser Kurt Van
Hoecke Nasira Ismail BIRMINGHAM - MUMBAI

Webographies
[W1] https://msdn.microsoft.com Consulter le 29/07/2015
[W2] https://community.dynamics.com/ Consulter le 31/7/2015
[W3] https://technet.microsoft.com Consulter le 30/7/2015
[W4] http://www.ignify.com/axapta.asp Consulter le 30/7/2015
[W5] http://blogs.adobe.com/ consulter le 31/07/15
[W6] http://www.piloter.org/ consulter le 03/08/2015
[W7] https://www.youtube.com/ Consulter le 16/08/2015

Conception et développement de la gestion de visa sous Dynamics Ax R2

Conception et développement de la gestion de visa sous Dynamics Ax R2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Conception et développement de la gestion de visa sous Dynamics Ax R2

Similaire à Conception et développement de la gestion de visa sous Dynamics Ax R2 (20)

Plus de Rawdha MABROUKI

Plus de Rawdha MABROUKI (6)

Conception et développement de la gestion de visa sous Dynamics Ax R2