Rapport de Stage d’Immersion en Entreprise

de quatre chapitres divisés comme suit :

Dans le premier chapitre, nous allons présenter le cadre

du projet et nous allons faire une étude de l’existant.

Le deuxième chapitre englobera les besoins fonctionnels

et non fonctionnels des utilisateurs du futur système.

Le troisième chapitre sera consacré pour la description

de la conception globale ainsi que la conception détaillée

du futur système.

Finalement, dans le dernier chapitre nous allons présen-

ter la réalisation a laquelle nous avons aboutit a travers

des imprimés écran.

2

Cadre du stage

Ce mémoire s’inscrit dans le cadre du stage d’immer-

sion dans une entreprise pour les élèves ingénieurs de

l’Ecole Nationale des Sciences de l’Informatique. Le tra-

vail est réalisé au sein de la société NeoTech durant la

période de 01 Juillet 2010 au 12 Août 2010. Le projet a

été encadré par Mr M’Hamed Essersi.

Présentation de l’organisme d’acceuil

NeoTech est une entreprise jeune et dynamique qui

opère dans le secteur des nouvelles technologies. Elle est

fondée en 2007 et son local se situe à 10 rue El Banafsej

La Corniche Bizerte.

Présentation du sujet

Notre sujet consiste à concevoir et développer une ap-

plication qui automatise la gestion des différents docu-

ments circulant au sein de l’entreprise NeoTech comme

elle doit gérer ses processus métiers.

3

Etat de l’Art

1

Avant d’entamer l’étude approfondie du projet, nous

nous proposons de présenter l’état actuel de la gestion

des documents au sein de NeoTech. Ensuite, nous allons

évaluer ce système.

Ce présent chapitre renfermera aussi une vue d’ensemble

sur la Gestion Electronique des Documents ainsi que ses

apports pour les organisations.

1.1 Etude Préalable

La société NeoTech est une société commerciale dont

l’activité est informatique. Elle est spécialisée dans la

vente et la location des matériels informatiques et de té-

lécommunication.

Dans cette section, nous allons décrire l’état actuel du

traitement documentaire au sein de NeoTech et nous al-

lons énoncer les problemes qui ont incité a la réalisation

de ce projet.

4

1.1.1 Etude de l’existant

Un document est un élément vivant de l’entreprise. Il

doit pouvoir être enrichi, diffusé et partagé afin de per-

mettre une meilleure communication entre les différents

services de l’entreprise.

Actuellement, les traitements documentaires existants

sont principalement ” Tout papier ” entrainant un volume

papier en croissance exponentielle.

Au sein de l’entreprise NeoTech-SARL, la gestion des

documents demeure manuelle. En effet, cette société ac-

quiert toutes formes de documentation sous forme de pa-

pier.

Ensuite, ils sont triés et traités manuellement. Pour l’étape

de classification, elle passe par l’indexation qui consiste à

l’attribution manuelle par les employés des marques dis-

tinctives à chaque document.

Ces marques renseignent avec pertinence sur la nature

des documents et facilitent ainsi leurs recherches.

Comme la communication entre les services s’avère

fondamentale afin de bien mener les tâches, ces docu-

ments doivent être diffusés. Au sein d’un même service,

les documents sont transmis de main en main alors qu’entre

les services, un duplicata est envoyé.

Finalement, pour le stockage, les documents sont archi-

vés selon des critères bien précis facilitant toute consulta-

tion ultérieure. C’est-à-dire, il reste possible de les consul-

5

ter par type, par nature, par date de modification...

1.1.2 Critique de l’existant

Etant donné que NeoTech-SARL est une entreprise qui

envoie et reçoit beaucoup de documents. Les conditions

actuelles de leurs gestion causent alors des problèmes qui

se résument en :

– Lenteur de la communication de l’information entre

les services : les agents de chaque service exécutent

leurs tâches de maniere dépendante, c’est-a-dire les

tâches sont réalisées les unes après les autres. Entre

les services, il y a une lenteur de diffusion des docu-

ments qui engendre une lenteur dans la réalisation

des traitements.

– Difficulté de la recherche des documents : même si

les documents sont indexés, une recherche manuelle

dans l’archive reste encore non agréable et fatigante.

– Perte de temps et par la suite d’argent qui est due

à la difficulté de la recherche des documents.

– Perte des documents qui sont parfois importants :

un grand volume papier augmente la probabilité de

la perte des documents.

– La ressaisie des montants pour calculer les décla-

rations et le TVA, en se référant à plusieurs docu-

ments, augmente les risques d’erreurs et engendre la

perte du temps.

6

1.2 Solution Proposée

A la suite de ces constatations, il parait clair qu’il faut

se pencher des a présent sur le sujet et de commencer

a réaliser un systeme qui permet l’automatisation de la

gestion des documents.

Dans cette section, nous allons détailler la solution que

nous allons concevoir.

1.2.1 La Gestion Electronique des Documents

La Gestion Electronique des Documents est une solu-

tion qui s’impose a toute organisation ou entreprise des

lors que se posent des problématiques d’optimisation des

informations.

La mise en place de la Gestion Electronique des Docu-

ments, qui recouvre l’ensemble des outils, des techniques

et des logiciels permettant le traitement et l’organisation

des documents qui pénetrent, sortent et circulent a l’in-

térieur d’une organisation d’une manière informatisée,

améliore les processus organisationnels existants.

Les techniques utilisées visent la dématérialisation, le

classement, la gestion et le stockage des documents à tra-

vers leurs numérisations visant la réduction du ” Volume

papier ”.

Elles assurent aussi l’intégration des documents, leurs

7

identifications, leurs archivages, leurs restitutions, leurs

administrations et leurs sécurités et facilitent par suite

leurs recherches, leurs consultations et leurs échanges.

La Gestion Electronique des Documents est catégori-

sée en différents domaines. Ainsi ce concept est subdivisé

en :

– GED Administrative : dédiée au classement des do-

cuments électroniques administratifs.

– GED Bureautique : dédiée à la production et au par-

tage de documents dans un groupe de travail.

– GED Documentaire : dédiée à l’indexation des res-

sources documentaires.

– GED Technique : dédiée à la gestion des documents

techniques, propre à un métier.

Il existe quatre étapes majeures dans la Gestion Elec-

tronique des Documents :[N 4]

– Acquisition des documents : qui est l’intégration des

documents papiers et électroniques existants.

– Classement des documents : qui passe par l’indexa-

tion selon des critères bien déterminés en vue de fa-

ciliter leurs exploitations.

– Stockage des documents : c’est la sauvegarde et l’ar-

8

chivage des documents d’une manière hiérarchique

en fonction du contenu.

– Diffusion des documents : c’est l’échange et le par-

tage des documents entre les différents agents de

l’entreprise.

1.2.2 Les Apports de la GED

La Gestion Electronique des Documents est devenue

une tendance des organisations pour ses apports indé-

niables sur le plan organisationnel ainsi que sur le plan

du profit. En effet, elle assure a l’entreprise un Systeme

d’Informations plus performant et plus efficace en par-

venant à constituer un référentiel de l’ensemble de ses

documents et en accordant la possibilité de gestion de

leurs cycles de vie, de leurs créations à leurs destruc-

tions.

Les avantages induits par un système GED se résument

en :

– L’organisation de l’information

La GED permet de limiter la masse de ” papiers”,

tout en garantissant l’homogénéité du support et en

standardisant les documents internes. En outre, les

informations sont classées dans un plan de classe-

ment adapté aux besoins spécifiques de l’organisa-

tion.

– Gestion du cycle de vie des documents

Depuis la création jusqu’à l’archivage, la GED prend

en charge l’ensemble des processus documentaire, en

garantissant au passage, la traçabilité, le contrôle et

9

les relations entre documents, ce qui optimise la re-

cherche et la mise à jour des informations.

– Centralisation et partage des documents

Grâce à la GED, il est possible de centraliser et

de partager les documents, les informations et les

connaissances, a partir d’une interface d’acces, of-

frant des moyens de recherche garantissant une ac-

quisition rapide et pertinente de l’information.

– Sécurisation de l’information

En intégrant une gestion pointue des différents ni-

veaux d’habilitation sur la consultation et la diffu-

sion des informations, la GED permet de sécuriser

l’accès aux documents. Ainsi, une information ne de-

vient consultable que par les ” ayant droit ”.

Conclusion

Dans ce chapitre, nous avons mené une étude préalable

qui nous a permis de comprendre le travail demandé.

Nous avons aussi présenté la solution dont nous spécifie-

rons les objectifs et nous éclaircissons les différents be-

soins dans le chapitre suivant.

10

Spécification et Analyse

des besoins

2

Ce chapitre consiste en une étape analytique dans la-

quelle nous allons recenser et factoriser les besoins des

utilisateurs de l’application. Ceci est fortement lié à l’étude

préalable menée au cours du premier chapitre.

Pour ce faire, cette phase doit répondre aux questions

suivantes :

– Que doit offrir le système pour les utilisateurs ?

– Quels sont les besoins fonctionnels du système ?

– Quelles sont les contraintes qui doivent être prises

en considération ?

2.1 Spécification

La solution à développer doit prendre en considération

des besoins fonctionnels et non fonctionnels. Dans ce qui

suit, nous allons recenser ces différents besoins.

2.1.1 Spécification des besoins fonctionnels

Notre application doit fournir aux différents utilisa-

teurs tels que le personnel et le gérant de NeoTech les

11

fonctionnalités que nous allons spécifier dans cette sec-

tion.

Le système de Gestion des Documents doit :

– Permettre à l’utilisateur de créer des documents, de

les consulter et de les mettre à jour.

– Stocker et archiver toutes formes de documentation

de tailles connues de manière persistante ou tempo-

raire.

– Echanger les documents entre les différents agents

d’un même service et entre les services.

– Automatiser le calcul de la TVA tout en respectant

les pourcentages et les lois fiscales.

2.1.2 Spécification des besoins non fonctionnels

Cette application doit satisfaire une série des besoins

non fonctionnels tels que :

– Interface Homme Machine conviviale et agréable.

– L’application peut tourner sur réseau local de l’en-

treprise ou via l’internet.

– L’application peut être étendue à d’autres fonction-

nalités.

– Optimiser le temps de réponse.

12

2.2 Analyse des Besoins

Pour spécifier de façon formelle les besoins requis par

l’application, nous avons opté pour la réalisation du dia-

gramme des cas d’utilisation pour avoir une meilleure

compréhension des besoins.

2.2.1 Identification des acteurs

Un acteur est un élément externe, qui peut être un

homme, une machine, ou un autre système, qui interagit

avec le système pour avoir un résultat. Il prend des dé-

cisions et des initiatives.

Dans le cas de notre application, les acteurs que nous

identifions sont : l’administrateur(le gestionnaire ou le

gérant) qui a des tâches de contrôle, l’employé qui a des

tâches d’ajout, de saisie, d’impression et d’envoie des do-

cuments. Finalement, le comptable qui vérifie les calculs

des déclarations.

2.2.2 Modèle de cas d’utilisation

Le modèle des cas d’utilisation définit les activités at-

tendues des différents utilisateurs par rapport à l’appli-

cation. Il doit répondre aux questions suivantes :

– Quels sont les tâches principales réalisées par les ac-

teurs ?

– Quels sont les informations manipulées par les ac-

teurs ?

13

Le diagramme des cas d’utilisation contient les acteurs,

les cas d’utilisation c’est-à-dire les services offertes par le

système et les applications.

Un cas d’utilisation est l’ensemble des actions logique-

ment ordonnées représentant les échanges entre les ac-

teurs et le système.

La figure ci-dessous FIGURE 2.1 illustre le diagramme

de cas d’utilisation de notre application.

Figure 2.1 – Diagramme de cas d’utilisation

2.2.3 Les Scénarios

Dans cette section nous allons détailler quelques cas

d’utilisation par des diagrammes de séquence.

Pour tous les scénarios de cas d’utilisation, tout utilisa-

teur doit s’authentifier en indiquant un nom d’utilisateur

14

et un mot de passe.

Figure 2.2 – Phase d’Authentification

2.2.3.1 Ajout Document

Lors de la phase de création, l’utilisateur remplit les

champs propres à un document et des listes de choix de

type, de destination lui seront fournies pour lui faciliter

cette tâche.

Le diagramme ci dessous FIGURE 2.3 présente les

étapes nécessaires pour la création d’un nouveau docu-

ment.

15

Figure 2.3 – Diagramme de séquence ”Ajout document”

2.2.3.2 Mise à jour Document

La mise à jour des documents est une fonctionnalité

restreinte à l’administrateur. Il est le seul qui peut mo-

difier les champs d’un document validé.

16

Figure 2.4 – Diagramme de séquence ”Mise à Jour document”

2.2.3.3 Consultation Document

Le diagramme de séquence ci dessous FIGURE 2.5

présente les étapes nécessaires pour un utilisateur pour

consulter un document.

Pour réussir cette tâche, le document doit être existant.

17

Figure 2.5 – Diagramme de séquence ”Consulter document”

2.2.3.4 Echanger Document

Le succès de cette tâche exige que l’utilisateur soit

connecté sur le serveur local de l’entreprise. Pour cela,

il doit avoir un compte valide ainsi que son destinataire.

Les causes d’échec sont, soit le nom d’utilisateur ou

le mot de passe indiqué sont erronés, soit le compte du

destinataire est invalide.

Le diagramme ci-dessous FIGURE 2.6 représente le cas

de succès.

18

Figure 2.6 – Diagramme de séquence ”Echanger document”

2.2.3.5 Suppression Document

Pour la phase de suppression, la préexistence du do-

cument s’avère fondamentale. En outre, l’utilisateur doit

être un administrateur.

Si l’utilisateur souhaitant faire la suppression n’est pas

l’administrateur, le système affichera un message d’er-

reur.

Le diagramme ci-dessous FIGURE 2.7 représente le cas

de réussite de cette tâche.

19

Figure 2.7 – Diagramme de séquence ”Supprimer Document”

2.2.3.6 Calcul TVA

Cette fonctionnalité prend en compte plusieurs contraintes :

les factures sélectionnées doivent être non déclarées au-

paravant ainsi que les certificats de retenu impôt. Le cal-

cul doit être conforme aux pourcentages exigés par la

finance.

Le diagramme ci-dessous FIGURE 2.8 représente le cas

de réussite de calcul de TVA.

20

Figure 2.8 – Diagramme de séquence ”Calculer TVA”

2.3 Diagramme d’Activité

Pour décrire le comportement générique d’un cas d’uti-

lisation ou détailler une opération complexe on utilise le

diagramme d’activité. Ce dernier permet aussi de modé-

liser la dynamique d’une tâche[4].

La figure ci-dessous représente le diagramme d’activité

propre à notre application.

21

Figure 2.9 – Diagramme d’Activité

Conclusion

Dans ce chapitre, nous avons essayé de spécifier les

besoins de notre application afin de délimiter le cadre de

notre travail et de préparer un terrain favorable pour la

prochaine phase qui est la phase de conception.

Cette étape aura pour but global de concevoir clairement

l’architecture de notre solution.

22

Conception

3

La phase d’analyse et de conception a pour objectif de

permettre la formalisation des étapes préliminaires du

développement d’un système. Ainsi, ce dernier devient

plus fidèle aux besoins du client.

La phase de conception permet de décrire la manière

du fonctionnement désiré du système afin d’en faciliter

la réalisation et la maintenance.

Pour ce faire, nous présentons dans une première partie

une conception globale de notre application ensuite dans

la deuxième partie nous détaillerons la conception.

3.1 Conception Globale

Notre application consiste à concevoir et développer

un systeme qui réalise la gestion des documents des leurs

arrivée jusqu’à leurs archivage. Afin de mieux réaliser la

gestion des documents, nous devons concevoir toutes les

étapes par lesquelles ils passent.

Ci-dessous une figure résumant la vue globale de notre

23

application.

Figure 3.1 – Vue globale de la solution

Le système de gestion des documents doit réaliser toutes

les étapes présentées par la figure ci-dessus.

Un document entrant doit être enregistré dans la base

des documents reçus, l’enregistrement se fait par identi-

fication du document c’est-à-dire l’attribution automa-

tique d’un identifiant unique et la saisie des champs né-

cessaires ensuite le scanne du document est nécessaire

pour avoir toujours un duplicata du document réel.

24

Après l’enregistrement, le document peut être imprimé,

distribué entre les services concernés ou bien il servira

pour effectuer les déclarations mensuelles de l’entreprise

s’il s’agit d’une facture ou d’un certificat de retenu im-

pôts.

Pour envoyer un document à un destinataire extérieur

à l’entreprise NeoTech-SARL, l’employé doit créer un

nouveau document selon les besoins c’est-à-dire choisir

le type désiré, ensuite il fait la saisie des champs néces-

saires avec l’identification du document. Une fois la saisie

est terminée, le document est enregistré dans la base des

documents émis, il est ensuite imprimé pour être finale-

ment envoyée au destinataire.

Notre application doit, alors, prendre en considération

ces différentes étapes. Elle doit aussi détailler les diffé-

rents types des documents que l’entreprise utilise afin de

faciliter le travail des employés.

Dans ce qui suit, nous allons entamer la conception

détaillée.

3.2 Conception Détaillée

Dans cette section, nous décrirons plus en détails notre

application. Nous allons présenter le diagramme de classes

qui résume la structure générale du système.

25

3.2.1 Les Contraintes

Lors de la saisie des champs d’un nouveau document,

il existe plusieurs contraintes qui doivent être vérifiées.

Afin d’en tenir compte, lors de l’implémentation, nous

devons ajouter des contrôles qui se résument en :

– L’ID de tout type de documents doit être unique.

– Lorsqu’il s’agit d’un document reçu, le champ Desti-

nation est automatiquement rempli par NeoTech et

en cas inverse c’est-à-dire le document est émis, le

champ Source est automatiquement rempli par Neo-

Tech.

– Comme les types des documents circulant au sein de

NeoTech sont bien déterminés, le champ Type dans

un document est rempli à partir d’une liste fournie

et qui est mise à jour en cas de saisie d’un nouveau

type.

– Pour les champs Source et Destination d’un docu-

ment, leur remplissage obéit aux mêmes conditions

que celle du champ Type.

– Les deux dates, date de remise au comptable et date

de déclaration, doivent être postérieures à celle du

document.

– Il y a aussi des champs qui sont récupérés à partir

d’autres champs à noter les champs Jour, Mois et

Année qui seront déduis automatiquement à partir

du champ Date.

26

– Il existe des champs dont le remplissage est condi-

tionné par une certaine valeur des champs précé-

dents. Pour s’assurer que l’utilisateur saisie ces champs

lorsque la condition est satisfaite, nous allons utiliser

des boites de dialogues jouant le rôle de rappel.

Toutes ces contraintes visent à réduire la saisie afin de

minimiser les erreurs.

3.2.2 Diagramme de Classes

La figure ci-dessous FIGURE 3.2 représente le dia-

gramme de classes qui traduit les relations entre les dif-

férentes classes.

27

Figure 3.2 – Diagramme de classes

Remarque : Dans Domino Designer, chaque classe de-

vient un document.

La classe Général est une classe mère qui regroupe

tous les attributs communs a tous les documents a par-

tir de laquelle héritent deux classes Objet règlement et

Moyen règlement.

28

La classe Objet règlement représente les redevances et les

recettes de l’entreprise qui sont réglées par les Moyen règlement.

En effet, les classes Facture, Note honoraire et Quittance

sont des sous classes de Objet règlement mais seule la

classe Facture qui contient la TVA.

La classe Facture contient plusieurs ligne de facture dont

chacune fait référence à un article.

Il existe aussi une forme particulière de quittance qui hé-

rite de Facture qui est Quittance douane car elle contient

le champ TVA.

La classe Déclaration douane qui fait référence à plu-

sieurs ligne de facture en incluant des paramètres comme

le taux et le droit de douane.

Pour les classes Chèque, Traite et Virement, elles sont

des Moyen reglement, mais la classe Traite possede une

date d’échéance.

La classe Bulletin versement chèque traduit les opéra-

tions de versement des différents cheques a la banque.

La classe Relevé compte regroupe toutes les opérations

effectuées dans le compte de l’entreprise pendant un mois.

Elle comporte les références des Chèque.

La classe Déclaration comporte les deux méthodes cal-

culer TVA() et Calculer impots() qui traduit les décla-

rations mensuelles de l’entreprise sur ses bénéfices et sur

son personnel. Les déclarations effectuées se basent sur

les classes Certificat retenu impot qui calcule les impôts

sur les sociétés et Facture qui fournit le montant de TVA

à déclarer.

La classe Domiciliation contient les paiements des frais

de douane pour une expédition.

Dans un document domiciliation, le montant doit être

en devise, le fournisseur et le taux de change doivent

être les même c’est pour cela que nous avons utilisé les

29

opérations Verif meme frns(), Verif mt devise() et Ve-

rif mem tx chg().

Conclusion

A travers ce chapitre, nous avons présenté notre concep-

tion de l’application. Nous avons fourni, dans un premier

lieu, une conception globale à travers un schéma géné-

ral décrivant le parcours d’un document. Ensuite, nous

avons présenté la conception détaillée de l’application à

travers le diagramme de classes. A présent, nous sommes

capables d’entamer la partie réalisation.

30

Réalisation

4

La phase de réalisation consiste a construire le systeme

en se référant aux autres phases et principalement à la

phase de conception détaillée auparavant.

Cette phase met l’accent sur la gestion des ressources et

le contrôle des opérations pour optimiser les coûts, les

délais et la qualité.

En tenant compte des besoins fixés et des choix concep-

tuels effectués, nous consacrons ce chapitre à la descrip-

tion du travail réalisé.

Nous commençons par décrire l’environnement matériel

et logiciel sur lequel notre application est réalisée. En-

suite, nous présenterons quelques captures d’écran de

l’Interface Homme/Machine traduisant l’utilisation de notre

application.

4.1 Environnement et outils de travail

Cette partie est consacrée à la présentation de l’envi-

ronnement matériel et logiciel utilisé pour la réalisation

de notre application.

31

4.1.1 Environnement matériel

Le tableau ci-dessous illustre la configuration maté-

rielle utilisée dans notre projet.

4.1.2 Environnement logiciel

Du point de vue logiciel, nous avons travaillé sur une

plateforme Windows XP sur laquelle sont installés les

outils nécessaires à la réalisation de notre travail :

– Système d’exploitation : Microsoft Windows XP pro-

fessionnel Version 2002

– Environnement de développement : Domino Desi-

gner 8.5, Lotus Notes 8.5

– Outils de modélisation UML : ArgoUML

– L’outil de traitement de textes : Latex Comme lan-

gage de programmation et TeXnicCenter comme Edi-

teur latex pour la rédaction du rapport.

Comme nous utilisons le logiciel Lotus Notes pour la

première fois, nous allons consacrer une section dans la-

quelle nous allons le présenter et nous détaillerons les

32

principes de base du langage utilisé Lotus Script.

4.1.2.1 Lotus Notes

Lotus Notes est un logiciel de travail collaboratif, uti-

lisé dans des entreprises et des administrations pour de

nombreuses applications y compris les e-mails, calendrier,

messagerie instantanée, navigation sur le Web ainsi que

pour une variété d’applications riches en fonctionnalités

personnalisée.

Il peut être utilisé pour accéder à la fois en local et aussi

aux applications basées sur serveur.

Il permet de gérer les projets et les échanges d’informa-

tions autour d’une base commune.

Ce logiciel permet aussi aux utilisateurs de rationaliser

leur façon de travailler. Il est facile a utiliser et il aide a

faire le travail plus rapidement.

33

Figure 4.1 – Interface de Lotus Notes

Il supporte plusieurs langages : Java, Java Script, Lo-

tus Script, Lotus Formula language

Mais le langage le plus utilisé dans la programmation des

bases Notes de domino est : Lotus Script.

4.1.2.2 Lotus Script

Lotus Script est un dialecte du langage de program-

mation BASIC utilisé par Lotus Notes.

Il est accessible via l’outil Designer. Ce langage est in-

terprété à l’exécution mais il est avant tout un langage

objet. Il peut être exécuté coté client s’il est mis dans des

actions de masques ainsi que du coté serveur s’il est mis

dans des agents de base.

D’un point de vue syntaxique, il s’apparente à Visual

Basic mais il contient des objets-classes propres à Do-

mino, parmi lesquelles :

– NotesItem : champ d’un document.

34

– NotesUiDocument : document ”actif”.

– NotesView : représente une vue.

Comme ce langage est destiné aux bases Lotus Notes,

le développement en Lotus Script se fait avec le client

Domino Designer. Il s’agit de la même interface de déve-

loppement utilisée pour la création de bases Notes.

Figure 4.2 – Interface de Développement

4.2 Interface Homme/Machine

Dans cette section, nous allons présenter les vues les

plus importantes de notre application. Ces vues servent

à donner une idée plus claire sur l’avancement de notre

travail. En effet, elles sont le résultat des trois phases :

analyse, conception et implémentation.

Ces vues seront présentées à l’aide des imprimés écran

que nous avons réalisé.

35

4.2.1 Création Document

La figure ci-dessous FIGURE 4.3 montre l’interface de

création d’un document.

Lorsqu’un utilisateur souhaite créer un document, il doit

aller au workspace, cliquer sur ”Create” et choisir le type

du document qu’il souhaite créer.

Figure 4.3 – Création Document

4.2.2 Ouvrir/Consulter Document

L’ouverture d’un document se fait à partir des vues,

qui sont des sélections ou des catégories de documents

d’une base Notes.

La figure ci-dessous FIGURE 4.4 montre comment ou-

vrir un document.

36

Figure 4.4 – Consulter Document

Les documents dans notre application sont catégorisés

selon les besoins fondamentaux et quotidiens de l’entre-

prise.

Tous les documents sont classés par nature : Emis ou

Reçus pour alléger et faciliter leurs recherches.

– Factures : sont divisées selon la déclaration de TVA

(TVA déclarée, TVA non déclarée, TVA non déduc-

tible) ou par critere de reglement et remboursement.

– Certificats Retenues Impôts : sont catégorisés en se

basant sur l’indice déclaration.