Anthony Bardy

Le but de ce projet était de développer mon propre Windows Media Player en m'appuyant essentiellement sur le Framework 4 et WPF.

• WPF layout
• XML serialization
• Use of LINQ
• Use of the binding engine
• MVVM pattern
• Media player (Image, sound, video)
• Media library handling (Image, sound, video)
• Possibility to apply filters (Album, artist, genre, ...)
• Playlist creation

Ce site a pour but, d'accompagner le client tout au long de ça prise de rendez-vous, de la sélection de son modèle, en passant par les différentes pannes constatées et une explication du problème ou des problèmes constatés, Jusqu’à sa prise de rendez-vous.
Il doit aussi gérer l'enregistrement des clients en base de données pour simplifier la création de la fiche client à son arrivé à la boutique.

Cahier des charges :

– Un site de réservation en ligne.
– Une interface simple.
– Permettant une sélection rapide du modèle et de la panne.
– Un style épuré.
– Intégrant des conseils et infos pratiquent.
– Un Back office simplifiant la mise à jour et l'entretien du site.
– Gérant l'envoie de mail automatique client, entreprise.
– Enregistrement des clients en base de données.
– Intégrant un outil CRM pour la création de facture, et la consultation
de fiche client.
– Permettre plus tard l'intégration d'un théme WordPress

Contexte du projet

Ma mission était de mettre en place un système d’EDI au sein de l’ERP du groupe SEPTEO pour le service Achat.
Echanges de données avec les grossistes au format XML.

A. Fonctionnement interne avant :

Avant mon arrivé le service achat disposé du minimum en terme de ressource pour le passage de commande auprès des fournisseurs.

Après ajouts dans un panier des différents articles présents en base de données, un bon de commande au format PDF était généré pour chaque fournisseur. Ces documents étaient ensuite transmis par E-Mail.
Une fois le bon de commande enregistré par le fournisseur, tous les retours était envoyés par E-mail :
Validation de commande
Bon de livraison
Facture

La modification en base de données, à la suite de ces retours, sont faites à la main.

Mais cela ne représente qu’une partie de différentes taches exécutées manuellement par le service achat.

Les fournisseurs mettent à disposition du service achat un Ftp leurs permettant de récupérer des fichiers postés et mise à jour régulièrement dans la journée par les fournisseurs.
Ces fichiers contiennent des éléments clés comme : les prix, la quantité disponible, le numéro de promotion et plusieurs autres information sur chaque article du catalogue produit.
Et là encore toutes ces informations sont saisies par une personne du service achat.
Tout cela implique une perte de temps lors de la saisies de ces données ainsi que des risques d’erreurs.

Changement grâce à mon projet :

Vous l’aurez compris avec la partie précédente, les échanges entre le service achat et les fournisseurs n’étaient pas aisés ni optimisés.

Mais heureusement, les fournisseurs proposent une solution complète d’ EDI.

Mon projet intervient au moment de la génération des bons de commandes au format PDF :

Le numéro de commande est transmis à mon programme.
La commande est récupérée en base de données.
Analysée afin de séparée les fournisseurs et les différentes adresses.
Ces informations divisées sont regroupé en plusieurs bons de commandes virtuelles.
Ces derniers sont sérialisés en XML puis transmis directement aux fournisseurs.

Les commandes ne seront donc plus générées au format PDF.

Quant aux E-Mail de retour, disparue eux aussi, mon programme s’occupe de récupérer les retours XML envoyés par les fournisseurs, les modifications en base données se font donc de façon dynamiques :
Etats de la livraison
Article non disponible
Facturation
…
Au début de paragraphe je vous ai dis que mon programme intervenait au moment de la génération du bon de commande, mais ce n’est quand partie vrai.
Vous vous souvenez dans la partie précédente ou je vous parlez des fichiers FTP en effet mon programme intervient bien-avant la commande.
Il récupère régulièrement les fichiers déposés par les fournisseurs et en crée un catalogue virtuel, ce-dernier est ensuite comparé avec la base produit du groupe Septeo enfin de faire les mise à jours possibles.

Babel est un logiciel de communication SIP, sur un protocole VOIP, tout comme Skype.
Il permet d'échanger des messages ainsi que des appels avec ses amis.
Les couches de transports utilisés, sont le TCP et l'UDP.
Nous pouvons définir le babel en deux partis :

Le Serveur :
Permet l'authentification des utilisateurs, la création de nouveaux comptes, la gestion des amis (ajout, suppression...), l'envoi de messages entre utilisateurs, la notification des actions aux utilisateurs (nouvelle connexion d'ami, nouveaux messages, nouvel appel, requête de demande en ami...), récoltent les informations à envoyer aux clients lors d'un appel etc.
Il gère donc les différentes demandes faites par les clients connectés en tcp.

Celui-ci est conçu de façon à pouvoir récupérer plusieurs parties qui pourrait être utile lors d'un prochain projet, comme la class Account permettant la gestion des utilisateurs ou bien l'abstraction Isocket permettant des actions simplifiées sur les sockets aussi bien sur Windows que sur Unix.

Le Client :
Communique avec le serveur et les clients, il permet l'envoi et la réception de commandes, celles-ci sont liées par une class « tremplin » à l'interface graphique
celle-ci communique de façon intuitive avec le serveur, elle simplifiera vos contacts avec vos amis.

Après avoir reçu les informations permettant l'appel avec un client celui-ci créera une connexion UDP directe avec le client cible pour envoyer et recevoir le son .