Le laboratoire Galaxy Swiss Bourdin (GSB) est issu de la fusion entre le géant américain Galaxy et le conglomérat européen Swiss Bourdin, lui-même déjà union de trois petits laboratoires.
Dans l’objectif d’uniformiser la gestion des frais des visiteurs médicaux des différents laboratoires, une application web sera mise en place.
Le contexte en détail :
Pour télécharger le cahier des charges :
Logiciels utilisés :
-Phpmyadmin pour la gestion et la configuration de la base de données
-Laragon pour le développement (serveur,...)
-Github pour déposer/récupérer le code facilement
Langages utilisés :
-PHP avec le framework Yii
-HTML
-CSS
-Javascript
Diagramme d'utilisation d'Applifrais :
Schéma de la base de donnée :
Au départ, nous avions récupéré une version d'applifrais faite sur du PHP ancien.
Nous avons d'abord procédé à un débuggage de cette application pour tenter de la remettre en marche, malheuresement utilisant du PHP trop ancien certaines fonctions étaient dépassées et les failles de sécurité trop importante.
Personnellement cela m'a quand même permis de me faire une idée de ce à quoi devait ressembler Applifrais dans les grandes lignes.
On a donc décidé de passer sur une architecture MVC (Modèle Vue Controlleur) qui est plus d'actualité, avec le framework PHP Yii.
Login et table Visiteur :
Tout d'abord je me suis occupé de la table "Visiteur" qui contient toutes les informations
des personnes pouvant se connecter à l'application : ID, Prénom, Nom...
Pour pouvoir se connecter à Applifrais avec les informations des utilisateurs j'ai du relier le modèle de base "User" au modèle nouvellement crée "Visiteur" qui contient les infos.
Le modèle "User" possède des fonctions natives qui permettent de gérer l'authentification, la validation de mot de passe, "l'identité" qui permettent de pouvoir implémenter un système de login avec une base de donnée.
Plus tard à la table "Visiteur" j'ai rajouté deux champs "idfkm" et "user_type" qui me permettront de gérer les frais kilométriques et si l'utilisateur est un simple visiteur ou un comptable.
Voici ce à quoi ressemble le formulaire de connexion pour s'authentifier →
L'utilisateur rentre son identifiant et son mot de passe.
Les frais forfaitisés et hors forfait :
Il faut gérer ces deux types de frais j'ai donc choisi de faire deux pages distinctes (modèle et controlleur aussi).
Au niveau des restrictions sur les frais hors forfait, l'utilisateur ne peut pas rentrer une date postérieure à la
date à laquelle il se connecte pour renseigner ses frais du mois en cours.
Pour cela j'ai rajouter une règle de validation au modèle "Horsforfait" ↓
Pour les frais forfaitisés c'était plus compliqué, il faut gérer le fait que les frais kilométriques dépendent du nombre de chevaux de la voiture du visiteur,
j'ai donc du créer une table en plus "fraiskilometrique" et donc ensuite l'appli va chercher "idfkm" du visiteur
et regarde dans la table "fraiskilometrique" à quoi il correspond et remplace le taux par défaut inscrit dans la table "baremeforfait".
De plus, l'utilisateur ne peut rentrer qu'une seule fois le même type de frais par exemple les frais kilométrique.
Personellement j'ai opté pour le fonctionnement suivant : Si l'utilisateur avait déjà rentré un frais alors on le renvoie vers la page de modification de ce même frais avec un message. ↓
L'historique des frais :
L'utilisateur a accès à tous ses frais (forfait et hors forfait) renseignés sur l'année en cours.
Pour créer cette page j'ai afficher le tableau des frais comme sur les pages Forfait et HorsForfait mais ici sur la même page et pour que l'utilisateur puisse choisir quel mois il veut consulter, il y a une liste de boutons qui correspond aux dates où l'utilisateur a renseigné des frais.
(Ces boutons sont le résultat d'une reqûete SQL, donc si l'utilisateur rentre des frais un nouveau mois, un nouveau bouton apparaîtra avec la date.)
Dans Applifrais d'origine, l'historique n'existe pas.
Ce sont les fiches de frais, la fiche de frais permet de mettre un état sur les frais par exemple "crée" ou "remboursée" et à l'origine de regrouper les frais.
Mais ce fonctionnement étant très mal réalisé, j'ai donc décidé de créer "Historique" pour regrouper les frais.
Cependant les fiches de frais existent toujours, j'ai crée une table "fichefrais" avec un ID, la date et l'ID du visiteur qui a renseigné des frais, une nouvelle fiche de frais se crée tous les mois dès lors que l'utilisateur a renseigné
au moins UN frais (forfait OU horsforfait).
Mais pour les créer j'ai ajouté une procédure dans ma base de données. →
La première partie vérifie s'il n'y a pas déjà une fiche de frais qui existe pour le mois en cours si le compte est égale à 0 (aucune fiche) , alors j'insère une nouvelle ligne dans ma table fichefrais. Cette procédure est appelé chaque fois qu'un nouveau frais est inséré dans une des deux tables.
Partie Comptable :
Pour finir, je me suis occupé de la partie "Comptable" de l'application.
Pour vérifier si l'utilisateur est un comptable j'utilise le champ user_type que j'ai rajouté à la table `visiteur`, il y a deux possibilités : C (comptable) ou V (visiteur).
Le comptable a accès à deux onglet en plus : fiche et visiteur. →
Ce sont les deux fonctionnalités principales du comptable. Dans "visiteur", l'utilisateur a accès à la liste des visiteur enregistré dans la base de données et cela lui permet de changer le nombre de chevaux du visiteur en fonction de la carte grise de celui-ci.
Le dernier onglet "fiche" permet au comptable de consulter une fiche de frais ou
encore de changer son état pour la cloturer/valider, etc...
