Conception d'un logiciel de gestion de stock des produits périssables

CHAPITRE III :

MODELISATION DU SYSTEME

L'objectif poursuivit dans ce chapitre est d'établir un modèle qui décrit la nature des transactions relatives à la gestion de stock pour les produits périssables.

III.1 Niveau conceptuel

L'objectif à ce niveau est de représenter l'activité telle quelle devrait se faire au sein de l'entreprise. Ce niveau comprend les modèles suivants : le Modèle Conceptuel de Communication, le modèle conceptuel de traitement et le modèle conceptuel des données.

III.1.1. Modèle conceptuel de communication

Nous faisons ici une représentation de la circulation des informations en interaction avec les acteurs internes et les acteurs externes. Cette représentation est identique au schéma représentant les flux. C'est la figure n° 1.

III.1.2. Modèle conceptuel des données (MCD)

Nous faisons ici une représentation statique du système d'information de l'entreprise qui met en évidence sa sémantique. Nous décrivons donc, de façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc d'une représentation des données, facilement compréhensibles. Cet aspect recouvre les mots qui décrivent le système ainsi que les liens existants entre ces mots. Le formalisme adopté par la méthode Merise pour réaliser cette description est basé sur les concepts « entités-associations » (M. Muyisa, 2014).

24

Les règles de gestion suivantes nous ont permis de préciser les différentes contraintes qui seront respectées par notre modèle conceptuel des données.

1. Le fournisseur est identifié par un nom, a une référence (numéro), une adresse et un téléphone

2. Un client est identifié par un nom, a une référence (numéro), une adresse et un téléphone

3. Un article est identifié par une référence et a une description, une unité, une date de fabrication et date de péremption.

4. Chaque article appartient à un lot qui a une quantité donnée.

5. A une date donnée un bon d'entrée est à notre disposition qui a une référence, une description et le nom du fournisseur.

6. Le prix d'achat dépend d'un produit, du fournisseur et de la date d'entrée

7. A une date un bon de sortie est livré à un client. Le bon de sortie est identifié par une référence, une description

8. Le prix de vente dépend du produit et de la facture.

9. La facture à une référence, une description, désignation, quantité.

a. Dictionnaire des données

Tableau 2 Dictionnaire des données

N°	Mnémoniques	Signification	Type	Mode d'obtention	C.I
1.	Num_Cli	Numéro du client	A.N	Mémorisé	Unique		2.
Nom_Cli	Nom du client	A.N	Mémorisé	-	3.
Adr_Cli	Adresse du client	A.N	Mémorisé	-	4.
Tel_Client	Téléphone du client	N	Mémorisé	-	5.
Code_prod	Code du produit	A.N	Mémorisé	Unique	6.
Descr_Prod	Description du produit	A.N	Mémorisé	-	7.
Num_Fourni	Numéro du fournisseur	A.N	Mémorisé	Unique	8.
Nom_Fourni	Nom du fournisseur	A.N	Mémorisé	-	9.
Adre_Fourni	Adresse du fournisseur	A.N	Mémorisé	-	10.
Tel_Fourni	Téléphone fournisseur	N	Mémorisé	-	11.
Num_Bon_Entre	Numéro bon d'entrée	A.N	Mémorisé	Unique	12.
Descr_Bon_Entre	Description bon d'entrée	A.N	Mémorisé	-	13.
Date_Entrer	Date d'entré	Date	Mémorisé	Unique	14.
Ref_Det_Bn_Ac	Référence Bon d'achat	A.N	Mémorisé	-

25

15.	Prix_U_A_P	Prix Unitaire Achat	Monétaire	Mémorisé		-	16.
Date_Entre_St	Date d'entrée en stock	Date	Mémorisé	-		17.
Qté_Art_En	Quantité d'article entré	N	Mémorisé	-		18.
Num_Bon_V	Numéro du bon de vente	A.N	Mémorisé	Unique		19.
Descr_Vent	Description de la vente	A.N	Mémorisé	-		20.
Nb_pce	Pièces vendues	N	Mémorisé	>0		21.
Pr_Un_Vn	Prix unitaire de vente	Monétaire	Mémorisé	-		22.
Date_Vent	Date de la vente	Date	Mémorisé	-

b. Graphe des dépendances fonctionnelles

NumFourn

NumCatg

NomFourn AdreFourn TelFourn

DateFact ModePay

NomClient AdreClient TelClient

DescBonSort DatBonSort Unité

Qté

NomCatg

NumArt

DescArt Unité

NumBnEntrer

DesciBnEntre Date Unité Qté

NumFact

NumBonSort

NumClient

NumLot

DescLot QtéLot DateFabri DateExpir DateEntrer

Figure 2 Graphe des dépendances fonctionnelles

1,n

c. Modèle Entité-Association (MEA)

Facture

NumFact
DateFact
ModePay

1,1

Facture

1,n

Client

NumClient NomClient AdreClient TelClient

Figure 3 Modèle Entité-Association

Article

1,n

Qté, PV

Sortir

1,1

Appartenir

NumArt DescArt Unité

1,n

1,1

Qté, PA

Entrer

1,n

NumBnEntr DescBnEntr DateBnEntr Unité

1,1

Appartenir

Bon Entrer

NumBonSort
DescBonSort
DatBonSort

1,n

Fournisseur

Lot

NumLot DescLot QtéLot Qté DateFabri DateExpi DateEntrer

1,1

Appartenir

Categories

NumCatg
NomCatg

1,n

0,n

Avoir

1,1

Bon Sortie

26

NumFourn NomFourn AdreFourn TelFourn

27

III.1.3. Modèle conceptuel de traitement

C'est un modèle constitué d'une succession d'opérations, chaque opération étant déclenchée par un ou plusieurs événements liés par une condition de synchronisation. L'opération exécute des traitements et produits un ou plusieurs résultats qui peuvent éventuellement être conditionnés par des règles. Celles-ci tiennent compte de la proposition de solution que nous avons suggérée dans les pages précédentes (M. CHIRAC 2011).

La gestion de stock sous OHADA des produits en péremption préconise que le produit qui s'expire bientôt doit constituer la première sortie avant les autres qui ont encore une durée de vie considérable. Ainsi notre MCT se présentera de la sorte :

28

Figure 4 Modèle Conceptuel de traitement

Toujours

Fin

OPERATION N°1

Vérification du stock

Suffisant

Critique

Confirmation

Rapp ort

Marchandises

Facture Achat

Bon de livraison

ET

OPERATION N°2

Analyse de l'arrivage

Retour des biens

Accord

Bon d'entr ée

Refus

OPERATION N°3

Enregistrement d'entrée
en stock

Toujours

Reçu du client

Fiche de stock

ET

OPERATION N°4

Analyse reçu et
vérification stock

Refus

Accord

Fin analyse

Annulation de la commande

Bon de sortie

ET

OPERATION N°5

Livraison et
enregistrement

29

III.2. Niveau logique

L'objectif à ce point est la définition des moyens informatiques à disposition des

postes de travail afin d'effectuer les opérations organisées. III.2.1. Modèle logique des données (MLD)

En appliquant les règles de passage du MCD au MLD nous pouvons obtenir le MLD suivant :

1. Fournisseur (Num_Fourni, Nom_Fourni, Adresse_Four, Tel_Four)

2. Client (Num_Client, Nom_Client, Adresse_Cli, Tel_Cli)

3. Catégorie (NumCate, Descrip)

4. Facture Achat (NumFact, DescfactAch, Date, ModePay, #NumClient)

5. Lot (Num lot, Desc_Lot, Qté, DateFabri, DateExpir, DateEntrer, PA, #NumBnEntre, #NumArt)

6. Article (Num Arti, Descri_Art, Unité, #NumCatg)

7. Bon Sortie (NumBnStr, DescBnStr, Unité, Date, #NumFact)

8. Bon Entrée (NumBnEnt, DescriBnEnt, Date, Unité, #NumFourni)

9. Sortir (#NumLot, #NumBonSort, Qté, PV)

III.2.2. Modèle organisationnelle de traitement Le MOT permet de répondre aux questions suivantes :

? Où ? C'est le lieu où se fera la procédure fonctionnelle (poste de travail)

? Quand ? Le moment où se concrétisera la procédure fonctionnelle ? Comment ? Le type de traitement de la procédure fonctionnelle

? Pourquoi ? Le moyen de traitement de la procédure fonctionnelle.

30

Soulignons qu'une procédure fonctionnelle est un traitement exécuté sans interruption par un même poste de travail utilisant les moyens de traitement de type déterminé, pendant un moment d'activité déterminé (O. MASIVI, 2007-2008, cité par CHIRAC, TFC 2011).

a. Détermination des procédures fonctionnelles

Le système OHADA ne préconisant pas une méthode appropriée pour la gestion des produits périssables. Il préconise la sortie première des produits qui seront expirés avant d'autres sans tenir compte de la date d'entrée de ce produit. Ce système est vraisemblable à l'ancien système (le système général Congolais)

Tableau 3 Description des tâches en procédure

PF	Poste de travail	Exercice	Type de données	Période	N° Op.
1	Service de dépôt	Vérification Etat de stock	Semi-automatique	A chaque demande	1
2	Service de dépôt	Analyse arrivage	Semi-automatique	A chaque arrivage	2
3	Service de dépôt	Enregistrement des entrées en stock	Semi-automatique	Après analyse	3
4	Service de dépôt	Analyse reçu et vérification stock	Semi-automatique	Pour chaque arrivé du client	4
5	Service de dépôt	Livraison et enregistrement de la sortie en stock	Semi-automatique	Après analyse	5

31

b. Modèle organisationnel de traitement

Le MOT est une répartition des opérations du MCT dans les différents postes ainsi que l'attribution de la périodicité. Cette répartition implique le découpage de ses opérations en procédures fonctionnelles selon les postes qui interviennent, les moyens utilisés et les étapes de déroulement.

Tableau 4 Modèle Organisationnel de traitement

Période

Procédure fonctionnelle

Poste de travail

Type de traitement

Heures de service A l'arrivage Après analyse A l'arrivée du client Après analyse

Demande d'avis stock

Service de dépôt Chargé du dépôt Service de dépôt Service de dépôt Service de dépôt

Semi-automatique Manuel Semi-automatique Semi-automatique Semi-automatique

PF 1

Vérification stock

Facture

Marchandises achat

Rapport Bon de livraison

PF 2

Analyse arrivage

Refus Accord

B E

Retour

PF 3

Enregistrement

F. St.

Reçu client

PF 4

Analyse reçu et vérification stock

Refus

Accord

B S

Retour

PF 4

Livraison et enregistrement

F. St. FIN

32

III.3. Niveau physique

III.3.1. Modèle physique des données

A ce niveau on implante le système d'informations à partir d'un logiciel nommé

Système de gestion de base de données (S.G.B.D). Alors le système d'information devient ainsi une base de données.

Figure 5 Modèle Physique des données

33

III.3.2. Modèle Opérationnel de traitement III.3.2.1. Architecture des écrans

Ce croquis ci-dessous nous permet d'organiser l'architecture des menus devant aboutir à un découpage du logiciel en transactions. Il n'y a pas de spécificité sous OHADA

Formulaire de
saisi des données

Menu principal

Quitter
l'application

ETATS

Nouveau fournisseur

Nouveau client

Nouvel article

Entrée en stock

Fiche de stock

Sortie en stock

Liste des

Liste des produits

Liste des clients

Liste des entrées

Liste des sorties

fournisseurs

Figure 6 Modèle Opérationnel de Traitement

Pour chacun des écrans d'entée nous avons créés des formulaires avec C#.

34

III.3.2.2. Interrogation de la base de données.

Pour obtenir les données en entrée, nous avons créés des requêtes avec SQL. Voici les requêtes principales :

? Pour obtenir toutes les entrées et leurs informations :

SELECT dbo.T_Lot.Num_Lot, dbo.T_Lot.Desc_Lot, dbo.T_Lot.Quantite, dbo.T_Lot.Date_Fabi,dbo.T_Lot.Date_Expir,dbo.T_Lot.Date_Entrer, dbo.T_Lot.Prix_Achat, dbo.T_Produit.Num_Art,dbo.T_Produit.Nom_Art,dbo.T_Bon_Entrer.Num_Entrer, dbo.T_Bon_Entrer.Descr_Entrer,dbo.T_Fournisseur.Num_Fourni,dbo.T_Fournisseur.Nom_ Fourni FROM dbo.T_Lot INNER JOIN dbo.T_Produit ON dbo.T_Lot.Ref_Art = dbo.T_Produit.Num_Art INNER JOIN dbo.T_Bon_Entrer ON dbo.T_Lot.Ref_Bn_Entr = dbo.T_Bon_Entrer.Num_Entrer INNER JOIN dbo.T_Fournisseur ON dbo.T_Bon_Entrer.Ref_Fourni = dbo.T_Fournisseur.Num_Fourni

? Pour obtenir tous les articles en magasin :

SELECT dbo.T_Categorie.Num_Catg, dbo.T_Categorie.Nom_Catg, dbo.T_Produit.Num_Art, dbo.T_Produit.Nom_Art, dbo.T_Produit.Num_Etag,

dbo.T_Produit.Unite FROM dbo.T_Produit INNER JOIN dbo.T_Categorie ON
dbo.T_Produit.Ref_Catg = dbo.T_Categorie.Num_Cat

? Pour obtenir la quantité et la date d'expiration la plus proche du produit choisi : SELECT Ref_Art, MAX (Date_Expir) FROM T_Lot WHERE Ref_Art = Nom_Art

? Pour voir la quantité correspondante au produit ayant à sa date d'expiration la plus proche

SELECT Ref_Art, SUM (Quantite) AS Somme FROM T_Lot GROUP BY Ref_Art