Suivi de colis

Ces spécifications sont destinées à toutes les parties intervenant au projet : utilisateurs, concepteurs, équipe de développement.

Elles sont dans un état temporaire (draft). Les points marqués FIXME restent à préciser.

Il s'agit, pour un opérateur postal, de gérer le suivi des colis/courriers recommandés (ci-après désignés “envois”) collectés par lui, et de présenter le suivi aux clients.

Le processus est le suivant :

  • des étiquettes préimprimées sont fournies aux clients, qui les collent sur les envois à traiter. Sur ces étiquettes figurent un numéro unique d'envoi.
  • selon planification, les agent de l'opérateur réalisent des tournées de collectes chez les clients, pour récupérer les envois à expédier
  • les agents enregistrent les numéros d'envoi dans la base de données (les numéros ne se suivent pas obligatoirement), et l'envoi est expédié
  • lorsque l'agent dispose de l'information, il met à jour le statut de l'envoi dans la base. Le premier statut de l'envoi est “Pris en charge”.

Un envoi recommandé doit être distribuée dans les 48 heures.

Au départ le système devra traiter entre 50 et 250 colis par jour, nombre destiné à augmenter dans les mois à venir.

Le système souhaité devra permettre de présenter au client, en temps réel, l'état de son colis.

La solution s'appuie sur Gestan, complété par un front office web.

En terme d'architecture des données, il y a plusieurs possibilités :

  1. utiliser Gestan en client/serveur, et développer une interface en webdev venant lire le fichier des envois recommandés
  2. utiliser Gestan en mode classique ou client/serveur, et utiliser un fichier MySQL local
  3. utiliser Gestan en mode classique ou client/serveur, et que Gestan utilise un fichier distant MySQL pour suivre les colis, ce fichier MySQL étant exploité par le front-office
  4. utiliser Gestan en mode classique ou client/serveur, et que Gestan utilise un fichier distant MySQL en miroir d'un fichier local, pour suivre les colis, ce fichier MySQL étant exploité par le front-office

La comparaison des avantages-inconvénients donne ceci :

ModeAvantagesInconvénients
C/S + webdev Fichier de suivi des colis unique Développement en Webdev + disposition d'un serveur ouvert vers l'extérieur
MySQL Local Fichier de suivi des colis unique Installation d'un WAMP local + disposition d'un serveur ouvert vers l'extérieur
MySQL distant Fichier de suivi des colis unique Gestion des coupures de connexion avec la base distante
Local ou C/S + MySQL distant en miroir Gestion des coupures, fluidité, sécurité des données. Accès mobile avec l'utilisation C/S Gestion de la cohérence

Nous privilégions l'architecture 4 (Local ou C/S + MySQL distant en miroir). En effet, moyennant la gestion d'un flag contrôlant la bonne exécution de la dernière commande locale, cette architecture nous paraît présenter le meilleur compromis entre la simplicité, la sécurité des données et des serveurs, la facilité de déploiement, et la collaboration entre nos sociétés, si nous partons de l'hypothèse que la partie web est développée par l'opérateur de courrier. Il est possible de commencer en mode classique, mais, en vue de la future appli mobile, il est pertinent de commencer tout de suite en mode C/S.

Dans l'architecture 4 :

  • les bases Gestan (fichiers .fic) peuvent être hébergées localement, sur un serveur en LAN de l'opérateur postal, ou sur un serveur en WAN (cloud Gestan ou cloud autohébergé)
  • les bases distantes (fichiers MySQL) peuvent être hébergées sur le serveur qui héberge déjà le site NouveauxFacteurs, ou tout autre serveur disposant d'une base MySQL avec possibilité de connexion directe (et non limité à un accès HTTP).

Spécificité : l'opérateur est déjà un client Gestan Cloud. Dans cette configuration, il est préférable d'opter pour impression d'étiquettes sur des planches A4. En effet, nous avons observé qu'un certain nombre d'imprimantes à étiquettes ne sont pas prises en charges nativement par la surcouche cloud utilisée.

Développement, étape 1

Partie programme local

L'addon Gestan travaille simplement un seul fichier SUIVICOLIS, comportant les rubriques suivantes :

  • un identifiant (pour la base de données),
  • un identifiant de CONTACT (le client enregistré dans Gestan),
  • un numéro d'envoi sous la forme LNF-XXX XXX XXX (où X représente un chiffre),
  • une date de prise en charge
  • une date de remise au destinataire
  • un statut (Pris en charge, En cours de traitement, En cours de livraison, Livré, Avisé, Refusé, Retour à l'expéditeur)
  • date et heure de création et dernière modification, utilisateur de création et de dernière modification

Correctif : est-il possible d'enregistrer une date pour chaque statut ?

Le fichier local SUIVICOLIS est répliqué en temps réel vers un fichier distant MySQL, via une dll spécialisée (par exécution en double des opérations de création et de modification à la fois dans la base locale et dans la base distante).

Quel est l'intermédiaire entre Gestan et la base de données ? La base de données a-t-elle besoin d'identifiants de connexion valable pour une connexion externe au serveur hébergeant le site ?

Serait-il utile de stocker également dans le fichier SUIVICOLIS l'adresse du destinataire de l'envoi (sachant que l'adresse de l'expéditeur peut être retrouvée via le fichier CONTACT) ? D'autres données peuvent également être stockées dans ce fichier, comme par exemple la distance entre le point de collecte et le point de livraison. Il est possible de stocker l'information destinataire uniquement en local, et pas en web, ou inversement. Pour éviter de taper les adresses à chaque scan de code-barre, nous ne souhaitons conserver que le code postal du destinataire, information qui sera demandée au scan des code-barres.

Partie web

L'autre partie du système est un site internet exploitant le fichier distant MySql, reflet du fichier SUIVICOLIS local.

Sans qu'il soit besoin d'une identification par code et mot de passe, un champ de recherche sur le n° d'envoi permet au client de visualiser les informations d'état de son colis.

Le site Internet présentera aussi un formulaire de contact.

Ce site Internet pourra être développé dans tout langage permettant un accès à la base MySQL, voire comme une extension d'un CMS du marché, par exemple WordPress, sous lequel est déjà développé le site actuel de l'opérateur.

Développement, étape 2

Deux fonctions seront développées dans un second temps :

Utilisation d'étiquettes à code-barre

Les étiquettes actuelles comportent (entre autres) un numéro unique d'envoi.

Le logiciel va permettre l'impression directe des étiquettes, avec attribution des numéros unique d'envois, et impression du code-barre correspondant au numéro unique d'envoi. Les étiquettes contiendront la mention Les Nouveaux Facteurs Recommandé (en rouge), le numéro unique (LNF-…) sur la ligne du dessous et le code barre (encore en dessous). Le format des étiquettes est : 63.5 x 38.1 (code 64604).

Les numéros uniques d'envoi générés et imprimés à l'avance (format des étiquettes autocollantes à fournir) selon un ordre numérique croissant. Exemple : LNF-000 000 100, puis LNF-000 000 101, puis LNF-000 000 102, etc. Les étiquettes commencent à LNF-000 000 101 jusqu'à LNF-999 999 999. À ce chiffre, les numéros sont réinitialisées et recommencent à LNF-000 000 101. La base ayant été purgée des enregistrements obsolètes (sauvegardés en tant qu'historique).

Il sera possible aux agents, à la réception de l'envoi confié par le client, de scanner le code-barre avec une douchette, ce qui alimentera automatiquement les bases de données (gain de temps et de fiabilité).

Nous suggérons de développer tout de suite les étiquettes code-barre, ce développement présentant une charge faible pour un gain important d'efficacité. Nous sommes entièrement d'accord pour utiliser les étiquettes code-barre dès maintenant.

Gestion des tournées sur mobile

L'objectif à plus long terme est qu'une application mobile, reliée à ce système initial, permettent aux agents courriers d'avoir sur leurs téléphone la liste des recommandés à distribuer et le parcours le plus court pour y parvenir.

L'application permettra également de mettre à jour les états des lettres, elle aura donc un accès à la base de données. Nous débutons le développement de l'application mobile, il faut donc prévoir une synchronisation dans les deux sens de Gestan (la base pouvant être modifiée par l'application).

Développement, étape 3

Dans une troisième étape, sans que ces orientations ne soient définitives, pourront être développées les fonctions suivantes :

Module client d'édition d'étiquettes

Nous suggérons, pour les clients réguliers de l'opérateur, de leur fournir non pas des étiquettes pré-programmées, mais un module complet d'édition d'étiquettes, soit sous la forme d'un addon Gestan spécialisé, éventuellement téléchargeable sur le site de l'opérateur, soit sous la forme d'une application accessible via le web.

Ils pourraient ainsi éditer eux-même leurs étiquettes, comprenant leur adresse d'expéditeur, mais également leur adresse destinataire, qui seraient remplies automatiquement à partir du moment où le destinataire aurait été enregistré, ainsi que toute mention commerciale ou technique utile à l'opérateur.

Statistiques

Des écrans seront développés pour connaître les statistiques représentatives du fonctionnement :

  • nombre d'envois par jour, par mois, par utilisateur…
  • délai moyen entre la dépose et la livraison…
  • autres états statistiques à définir

Traçabilité de la livraison

En option pour une traçabilité plus fine, un fichier SUIVICOLISHISTO pourrait permettre de mémoriser l'historique du traitement : connaître par exemple le détail des étapes du suivi de colis, l'origine des informations de suivi, etc.

Purge des données anciennes

En option, un programme pourrait purger, dans Gestan et/ou dans la table MySQL les enregistrements obsolètes (envois livrés et absence de réclamation dans un délai de X jours).

Avant la purge, un enregistrement global pourra être inséré dans la base, à des fins de statistiques (par exemple, avant de supprimer tous les envois sans réclamation du mois X-n, conserver un enregistrement global mentionnant le nombre d'envois traités, et autres données à préciser.

Etape 1 + étiquettes

UO Type Libelle Opt. Charge
SUIV1 Ecran L Liste des envois R 0.5
SUIV2 Ecran F Fiche envoi + réplication MySQL R 0.75
ETQ1 Etat Étiquettes + code barre planche A4 F 0.5
ADM00 <N/A> Gestion de projet et tests - 0.5

R = requis F = facultatif


  • wiki/specs/suivi_colis.txt
  • Dernière modification: 2016/01/05 15:22
  • par specs