Note de version 4.03 échéance du 8/11/2021

Note de version pour la mise à jour du 8 novembre 2021

 Billetterie 5
3770 Histoire Billeterie : Suivis des dossiers de résa en attente.

Dans l’écran Transport<billetterie insertion d’une fonction
Intégration d’un bouton action comprenant deux lignes
« XX Ref en attente »
« jj/mm/aaaa »

La date représentant la date de la prochaine résa en attente.
Un clic sur ce bouton action ouvre une modale comprenant tous les dossiers en attente
Un clic sur la ref ouvre le jour et la ref du dossier à traiter.

Un autre bouton « Surbook » est présent il reprend la même fonction que le module tableau de bord.

3769 Histoire Billetterie Calendrier de sélection

Dans le calendrier, permettant la sélection de la date de travail dans le module billetterie, l’opérateur pourra distinguer les dates sur lesquelles il existe des transports programmées.
Les dates sont sur un fond d’une autre couleur.
Le critère de colorisation de la date est l’activation de plan de transports sur cette date.

3768 Histoire Module billetterie – Gestion des demandes en attente

Lors de résas groupes auprès de compagnies de transport des références de dossiers peuvent être émises et saisies dans le module billetterie sans pour autant que les stocks demandées soient validés.
Il est alors nécessaire pour l’opérateur transport et pour l’opérateur billetterie de pouvoir être informé des dossiers en attente de validation.

Module billetterie :
Lors de la saisie d’une référence l’opérateur dispose d’une case à cocher sur la droite du champ de saisi. Le passage de la souris sur cette case informe l’opérateur « Référence en attente de validation ».
L’opérateur peut valider cette case si sa référence est encore en demande auprès de la compagnie de transport.
Une Référence en attente est écrite en rouge et est soulignée.
Le stock réservé est en rouge et souligné

Ecran Stock<segment
Un stock qui comprend des références en attente de validation est écrit en rouge et est souligné.

3766 Histoire Alerte module billetterie

Création d’un nouveau module de tableau de bord d’alerte sur les stocks de billets.

le visuel du tableau bord comprend :
le titre Surbook Billets
Prochain départ en Surbook

La modale présente un tableau comprenant
Date|Libellé|Réserver|Pax|
Sont injectés dans cette liste tous les dossiers pour lesquels Nb de pax >=Nb réservé*stock alerte transport (défini dans configuration<production<stock)

3740 Evolution Transport<billeterie – Evolution des données

Calcul du nombre de pax à réserver.
Le stock de la colonne « Réserver Global » qui comprend actuellement le nombre de pax comprendra maintenant le nombre de pax + le nombre d’accompagnateurs prévus; si Nb d’accompagnateurs prévu > Nb d’accompagnateurs affectés. Sinon le critère pris en compte est le nombre d’accompagnateurs affectés.
Le clic sur le critère numérique ouvre la modale comprenant les pax + les accompagnateurs
Si ce sont des accompagnateur prévus le tableau est alimenté par Accompagnateur 1, Accompagnateur 2…
Sinon le nom et prénom des Accompagnateurs est injecté : Type client contiendra le nom « Accompagnateur »
email et tel sont renseignés
les autres critères ne sont pas alimentés

Alimentation automatique du critère ligne.
En fonction des segments affectés dans une référence. les lignes auxquelles sont affectés les segments sont remontés dans la colonne.
Il pourra donc exister plusieurs ligne par référence

 Commande Collective 3
3888 Evolution Qestions de séjours et remontée dans les commandes

Lorsque des questions sont affectées à un séjour alors que la commande est déjà réalisée, ces dernières ne sont pas remontées dans la commande.
Prévoir un système de mise à jour des commandes dont date de départ est supérieure à date système afin d’affecter les nouvelles questions.
Gérer la problématique sur la commande standard également

3868 Evolution Contrôle des critères de séjour lors de la validation des séjours

Pour valider un séjour un certain nombre de critères sont contrôlés afin qu’un séjour validé puisse basculer en ligne en respectant tous les critères juridiques et techniques.

Cependant il est possible dans la commande collective de créer des forfaits à la volée sans pour autant respecter l’ensemble des critères.
Ceci permet notamment à des opérateurs de créer rapidement dans le cadre de la commande un séjour spécifique qui ne sera jamais vendu en ligne.

Lors des modifications de commandes ou lors d’affectations de pax il arrive que les contrôles de stock et de statut de séjour bloque l’enregistrement de la commande et génère une alerte stock.

Evolution proposée :
La création d’un séjour à la volée depuis la commande collective sera automatiquement validé et coché « front désactivé »
Dans la table séjour : si un opérateur tague un séjour comme non actif front, le process de validation ne contrôlera pas l’ensemble des critères habituels afin de ne pas bloquer l’enregistrement.

3759 Evolution Commande collective – gestion des présents

Intégration d’une fonction de gestion des présences au niveau de chaque ligne de commande collective dans le menu action à l’extrême droite de la ligne.
Le clic sur « Présence » ouvre la même fonction que pour la commande standard.
Un participant tagué comme absent dispose d’un signe distinctif sur sa ligne de commande.

Mettre un carré rouge à droite du V vert de validation. Il faudra pour cela certainement diminuer la taille du V afin que le V et le carré puisse tenir sur la même ligne sans débordé de l’espace alloué à cette colonne et sans que la colonne augmente sa largeur.
le passage de la souris sur le carré ouvre la tooltype motif

 Front office sites mutualisés 1
3861 Evolution Calcul des stocks en front office

Afin d’éviter qu’un internaute ne réalise toute le process d’inscription pour apprendre qu’il n’y a plus de place sur le forfait choisi, étudier la possibilité de mettre en place Un contrôle du stock comme en commande standard lorsque l’internaute clique sur le bouton réserver.

 Module social 3
3857 Evolution Social : Profil – ville de naissance

La ville de naissance est obtenue à partir de l’API.
Il peut exister plusieurs villes avec le même nom qu’il est difficile de différencier pour le profil. Si une mauvaise sélection est opérée, cela perturbe alors la gestion du numéro insee.
Voir s’il est possible de remonter le département entre parenthèse à coté du nom de la ville. (69)

3753 Evolution Social<paie : contrôle des profils intégrés dans une période validée.

L’opérateur doit pouvoir visualiser facilement si un profil a déjà été intégré dans un fichier de validation de période.
Par défaut un profil attaché à un fichier de validation de période n’est plus affiché
Une fonction filtre case à cocher est présente « Afficher les profils validés »

3752 Evolution Social : Contrat annulé

Création d’un nouveau critère de contrat
Le contrat annulé
Dans certains cas des contrats sont émis, les variables de profils sont transmises au service paie qui intègre les profils et génère les DPAE.
Il est possible que certains salariés ne se présente pas sur le lieux de travail. Il n’y a alors aucun salaire à verser.

Cependant le profil reste dans les variables de paie et le service paie n’est pas alerté qu’aucun bulletin ne sera émis.

Ecran social<contrats
Ajouté une colonne à droite de la colonne Actif : ‘Annulé » (oui-non). Par défaut le contrat est sur Non.
Dans le menu action création d’une fonction « Annuler le contrat » et une fonction « Re valider le contrat »

L’action annuler le contrat grise la ligne de contrat et bascule le statut Annulé à Oui.
On ne peut pas annuler une contrat si le profil est affecté à un segment de transport. Un message system informe l’opérateur.

Ecran social<paie
Un contrat annulé est présent mais la ligne est grisée.
Les variables de paie : Le nombre d’unités est tagué à zéro
Un contrat annulé est intégrable dans une validation de période.

Fichier csv d’export des variables de paie.
Une nouvelle colonne est ajoutée « Annulé »

Transport<accompagnateur
Un contrat annulé ne remonte pas dans la liste des accompagnateurs affectables

 Module Transport 2
3739 Evolution Ecran Transport<stock<segments – gestion des accompagnateurs

La règle de calcul du surbooking évolue
Le segment s’affiche en rouge si
(Nb pax +Accompagnateurs)>= Stock
Pour le critère Accompagnateur le programme prend en compte le nombre d’accompagnateurs prévu sauf si Accompagnateurs affectés > Accompagnateurs prévus.

Ajout d’une fonction d’export des données
Un menu Action<export est ajouté
Il export en csv les données sélectionnées
Pour les colonnes présentant deux valeurs (Accompagnateurs – Pax – -12ans) Une colonne sera affecté par valeur.
Acc Validés|Acc Prévus|Nb de pax|dont Options|Nb de – 12 ans|Dont Options
Une dernière colonne liste les accompagnateurs affectés (Prénom NOM)

3738 Tâche Création d’une règle de calcul automatisé du nombre d’accompagnateur

Dans l’écran stock segments il est possible pour l’opérateur de paramétrer le nombre d’accompagnateurs prévus

Création d’une règle de calcul du nombre d’accompagnateur nécessaire pour un transport.

Configuration<production<stock

création d’un nouveau critère : « Nombre d’accompagnateurs par segments ». Rajouter une tooltype « Vous devez saisir le nombre de pax théorique par accompagnateur en saisissant un chiffre ou nombre. La règle sera comprise par le programme comme 1 accompagnateur pour XX pax »
critère numérique.
Une case à cocher : Activer la fonction du calcul automatique du nombre d’accompagnateurs

Transport<stock<segments
L’opérateur pourra visualiser le nombre d’accompagnateur théorique nécessaire sur chaque segment en fonction de la règle de calcul paramétrée.
Le nombre d’accompagnateurs prévus sera toujours un nombre entier égal au nombre de pax divisé par la règle de calcul validée arrondis à l’entier supérieur.
Le nombre d’accompagnateurs théoriques ne peut être inférieur à 1 si au moins 1 pax est attaché à un segment.

Périodicité de mise à jour :
Une tache automatique recalcule le nombre nécessaire deux fois par jour. Une fois la nuit et une fois entre 12h et 14h.

 V3-Facturation 6
3869 Evolution Echéance de règlement d’une facture

Dans la modale de facturation l’opérateur peut choisir la date d’échéance de règlement.
Le programme doit contrôler que la date proposée par défaut ne soit jamais inférieure à la date de facture

3832 Evolution Gestion des commissions sur factures d’annulation

A ce jour lors d’une annulation client la marge de la commande n’est représenté que par la marge sur les produits annexes.

La marge d’une facture d’annulation sur annulation client doit comprendre :
[la somme des marges sur produits annexes + (Indemnité d’annulation*coef commission) ]

Cette commission est remontée dans les états fournisseurs.

3818 Evolution Factures de services – gestion des règlements dans les pdf

Injecter les règlements dans les pdf de factures de services.
Calcule du solde à payer
Afficher une mention acquitter si facture solder

Stocker la donnée de solde en base de donnée afin qu’elle soit exploitable dans d’autres écrans

3804 Evolution Ecran Commercial<Facturation

Rajouter une colonne Statut de commande à droite de la ref commande.
Contrôler que cette nouvelle colonne soit bien dans la fonction export

3786 Histoire Edition pdf des factures – gestion de l’adresse de facturation différente.

Si la fonction adresse de facturation différente est activée dans le profil client.
Les factures sont émises à l’entête de cette adresse de substitution pour l’ensemble des commandes.

– Suppression de l’encart adresse de facturation différente dans la commande standard<onglet règlement. Afin de conserver l’historique ce champ est juste masqué.
– Modification de l’édition pdf des factures dans la commande standard prenant en compte ce nouveau critère
– Modification de l’édition pdf des factures dans le cadre de la commande collective
– Modification de l’édition pdf des factures multi commandes.

3785 Histoire Adresse de facturation différente dans la commande collective

Il est à ce jour possible de réaliser une facture dans une commande standard avec une adresse de facturation différente.
Cette fonctionnalité n’existe pas actuellement dans la commande collective.
De plus certaines institutions disposent de plusieurs adresses. Les adresses administratives et les adresses de facturation.

Evolution :
La table client s’enrichit d’un critère adresse de facturation: Ce critère n’existe que pour les clients de type professionnel.
Dans l’écran client<onglet facturation
Ajout des champs de saisie pour une adresse de facturation différente.
Une case à cocher permet de rendre actif ces champs de saisi et et d’activer l’adresse de facturation différente.
Raison sociale
Civilité
Prénom
Nom
adresse
Complément adresse
CP
Ville

Aucun de ces critères ne sont obligatoires

 VACKELYS Connect API 19
3843 Tâche Synchronise des commandes
3839 Histoire Création d’une instance dev de vackelys connect

url actuelle : p4s.vackelys.fr

3830 Histoire Gestion de l’environnement utilisateur

Optimisation de l’affichage
Menus de gauche

Mettre le logo et le nom de l’instance qui se connecte
Masquer les menus suivants
– Starter Pages
– Active Page
– Inactive Page

Pages sous droit Superadmin
– Instances
– Partage Séjour
– Gestion des partages
– Villes

TOP MENU
Masquer le menu contact
Masquer les icônes qui n’ont pas d’utilité.

3829 Histoire Accès Utilisateurs à Vackélys Connect

Création d’un module de tableau de bord dans Vackélys permettant un accès à vacKélys connect.

Le lien ouvre un nouvel onglet de navigateur pointant sur connect.vackelys.fr

La page présente un design très épuré avec uniquement le logo VC qui prend toute la page.
Les utilisateurs peuvent se connecter avec leurs identifiants de super admin.
Seul les super admin peuvent se connecter à VC.

Mettre en place une tache qui remonte tous les id de connexion des super admin Vackélys au sein de VC.
Attention de bien gérer également le statut actif-inactif de l’utilisateur.

Une fois connecté l’utilisateur accède à une page présentant les logos de l’ensemble des enseignes Vackélys.

3814 Histoire gestion des logs api

enregistrement des actions effectuées via l’api en utilisant les clés api

3813 Histoire gestion des autorisations de partage entreles instances

mise en place d’un ecran pour permettre à l’admin de choisir avec qui une instance donnée peut partager ses séjours

3812 Histoire création des instances vackelys de test
3783 Tâche Api partage sejour

1. synchronisation séjour id
2. envoyer la liste de séjour partagé
3. envoyer la liste de séjour accepté
4. récupérer la liste de séjour partagé
5. récupérer la liste de séjour accepté
6. action modifier organisateur, destination, séjour

3779 Tâche page partage séjour

crée un page séjour pour partage avec les instances

3777 Tâche configuration ville avec id connect
3774 Histoire Service Synchronization

module python pour synchroniser les données entre les instances vackelys
1. nouveau partage
2. modification organisateur
3. modification destination
4. modification séjour
5. modification tarif
6. log message

3773 Histoire Service Vackelys

configuration des villes avec vackelys connect
menu connect (droit admin)
page partage séjour
page accepte séjour

3772 Histoire Service VackelysConnect

1. formulaire villes
2. datatable
3. service email, sms
4. log

3669 Histoire Diffusion d’une offre produit d’une de VC vers une ou plusieurs instances Vackélys.
Une offre séjour pour être diffusée sur une autre instance devra disposer d’une double validation.

  • La validation de l’organisateur fournisseur
  • La validation de l’organisateur distributeur

Un organisateur OU le super administrateur pourra décidé de la diffusion d’une offre sur une autre instance.

Création d’un menu « Mes fournisseurs »
L’organisateur pourra ainsi valider les fournisseurs avec lesquels il souhaite travailler.
Création d’un statut actif-inactif

Création d’un menu « Mes distributeurs »
L’organisateur pourra ainsi valider les organisateurs qui vont valider son offre séjours.

3668 Tâche Evolution des tables de données VACKELYS

Modification des tables de données Vackélys afin de rajouter un champs de correspondance avec Vackélys Connect.
libellé du champ : « Correspondance VC »

Certains champs de correspondance devront être saisi par l’opérateur dans son instance Vackélys.
Ce sont les données communes à toutes les instances vackélys.
Les tables de données suivantes doivent être traitées :
ID séjour
ID Destination
ID Villes
ID pays

D’autres seront alimentées automatiquement par la connexion API
Il s’agit des ID de critères qui ne sont pas communes à l’ensemble des instances
Questions de séjours
Options de séjours
Formalités
brevets

Certains critères de séjours devront être validé par l’opérateur de l’instance de destination en fonction de l’organisation de sa base produit.
Comme les catégories, les activités, types séjours, types forfaits, type restauration, type hébergement.
Ces critères seront validés une seule fois afin d’obtenir le statut actif front sur l’instance de destination.
Les nouveaux séjours importés automatiquement sur une instance seront donc automatiquement sous statut demande de validation.

3667 Tâche création de l’écran séjours

l’écran séjour reprend l’ensemble des séjours remontés
Il est très proche de l’écran séjours des instance Vackélys

ID|ID correspondance|Ref|Nom|Début|Fin|Actif|Actif front|Destination|organisateur|

Un clic sur l’ID permet d’afficher le séjour.
Est il nécessaire à ce stade que l’on puisse visualiser l’ensemble des onglets d’un séjour comme sur Vackélys. Je ne suis pas persuadé.
Je pense que la consultation seule des critères important de diffusion de l’offre sont nécessaire.

A ce stade seul l’onglet départs semble intéressant d’être ouvert en consultation.

Dans le futur il est envisageable d’ouvrir VACKELYS CONNECT à des organisateurs non clients de Vackélys.
Ceci afin qu’ils puissent proposer leur offre séjour en distribution.
Il faudra alors qu’ils puissent disposer d’un process de création très proche de celui existant sous Vackélys actuellement.

3666 Tâche Création d’un écran organisateur
VC comprend un écran Organisateur :

  • Le développeur devra estimer les critères important pour cet écran:
  • Nom de l’organisateur
  • Nom de l’utilisateur
  • identifiant
  • mdp
  • url de l’instance Vackélys.
  • ID de l’instance Vackélys sur Cubiq1??
  • Champ actif-inactif.

Création des fonctions de modification et création d’organisateur.

3665 Histoire Création de la plate forme VACKELYS CONNECT

Création d’une instance VACKELYS CONNECT
Les techniciens devront déterminer :
Le framework utilisé ainsi que l’ensemble des langages de programmation, type de bases de données…

La plate forme sera localisée sur un domaine du type vackélys-connect.fr

Il sera décidé si une instance preprod.vackelys-connect.fr est mise en place dès le début du projet.

Structure de données base produits
Cette plate forme disposera d’une base de données séjours et destination très proche des tables Vackelys.

Elle disposera d’une table organisateur avec des droits.
Un organisateur sera un organisateur Entité Maître Vackélys.
Un super administrateur disposera de la visibilité de l’ensemble des base produits de l’ensemble des organisateurs.

Une instance Vackélys dispose de séjours produits par l’organisateur Entité Maître mais également de produits d’organisateurs simple.
Seul les produits attachés à l’organisateur Entité Maître pourront être remontés.

Cas des enseignes. Chaque produit sera attaché à une enseigne. Si plusieurs enseignes sont attaché au produit, VC ne prendra en compte que l’enseigne attaché à l’organisateur entité maître.

Champs de correspondance :
Les ID des différents critères de base de données de VC seront les critères de correspondance avec l’ensemble des instances Vackélys.
Ainsi chaque gestionnaire d’instance Vackélys devra saisir les champs de correspondance avec VC.
Exemple si l’ID Ville Paris = 28 sur VC le gestionnaire d’instance Vackélys devra saisir cette même référence dans le champ de correspondance VC de son instance.

3664 Histoire PLATE FORME VACKELYS CONNECT

VACKELYS CONNECT (VC) est nouvelles plate forme dont le but est de facilité le commerce entre les différentes instances de Vackélys.

VACKELYS CONNECT aurait deux fonctions importantes

  1. La centralisation des bases produits de toutes les instances afin de permettre une mise à jour automatisée.

Exemple :
L’instance A dispose de 20 séjours: Elle souhaite que son offre soit distribuée sur l’instance B et C.
Son offre va donc être remonté sur VACKELYS CONNECT et sera mise à jour automatiquement sur les instances B et C.
Il sera donc nécessaire de développer des flux entre les instances et VC afin que les produits soient toujours à jour. La notion de produits regroupe la base séjour, la base destination. Dans la base séjour l’ensemble des critères d’un séjour (descriptif, dates, tarifs, stock, formalité…)

  1. La remontée des commandes d’une instance à une autre

Exemple :
L’instance B à fait une vente sur un produit de l’instance A. Cette dernière est remontée automatiquement sur l’instance A. L’opérateur n’a plus besoin de ressaisir la commande.

Afin de pouvoir réaliser ce projet il sera nécessaire :

  • De créer une plate forme VC capable de d’agréger les ressources séjours
  • De modifier la structure de données des instances Vackélys afin d’intégrer des critères de correspondance. (l’ID Ville Paris de l’instance A ne correspondant pas forcément à l’ID Ville Paris de l’instance B)
  • De créer la structure de flux alimentant VC
  • De créer la structure de flux alimentant les instances
  • De créer la structure de flux de contrôle des stocks et tarifs avant vente entre instance.
  • De créer la structure de flux de remontée des commandes inter instances.
 VACKELYS V3 16
3860 Evolution Supression d’un organisateur.

Ajouter une fonction Action<supprimer un organisateur
La fonction n’est possible que si aucun séjour ou destination n’est attaché à cet organisateur.

3858 Evolution Commercial<documents-nomage des documents

Lors de l’export des documents le zip comprend les documents classé par ordre croissante d’un ID.
format : ID-nomdudocument
Est il possible de remplacer l’ID par le nom des participants de la commande?
Classé par ordre alphabétique.
Une contrainte de nommage apparaitra dans les commandes standards multi pax.

3855 Evolution Stock détail – Evolution

L’opérateur doit pouvoir choisir son mois à partir d’un sélecteur de mois et d’année afin d’éviter de devoir faire défiler plusieurs mois manuellement.
Dans le détail d’une journée seul le critère pax ouvre une modale. Il faudrait que le critère option ouvre également la modale.
Dans la modale Pax, ajouter une colonne « statut » afin d’afficher le statut de la commande.

3854 Evolution Provenance de la commande

Lors de la saisie d’une commande standard par un opérateur le critère provenance est systématiquement pré saisi sur Internet.
Il faudrait que l’opérateur soit obligé de sélectionner une provenance.

3853 Evolution champs suivis dans les commandes

le champ est borné à 250 caractères.
Augmenter la taille du champ.

3852 Evolution Ecran règlement multiple

Ajout d’une colonne « Correspondance » qui remonte l’id de correspondance d’une commande en provenance d’une autre instance ou d’un autre canal de vente.

3846 Evolution Code iso pays Monetico paiement

Monetico paiement est le premier mode de paiement CB déployé sur Vacéklys.
Le code payas appelé à l’époque dans la transaction était le nom abrégé.
Il faudrait remplacer ce code par le code iso.
En effet certaines instances, pour des raisons qui leur sont propre, ont mdoifiées ces noms abrégés entrainant des erreurs 404 lors des process de paiement CB.

3836 Evolution Intégration des séjours type forfaits au stock<migration

Intégration des séjours type forfaits au module stock<migration.

3835 Evolution Gestion de la suppression de participants

A ce jour, lorsqu’un participant d’une commande standard est absent, la fonction de suppression du participant n’apparait plus.
Il faudrait tout de même pouvoir archiver ce participant.
La fonction d’archivage doit permettre de mettre à 0 tous les tarifs liés au participant.

3831 Evolution Intégration des départs règles dans les pdf séjours

Intégration des départs règles dans les pdf de séjours

3820 Evolution Commercial<documents

ajouter une colonne Groupe

3817 Evolution Evolution statistique<export<présents

Dans l’export csv rajouter une colonne RL et une colonne Client

3778 Evolution Optimisation des affichages onglet worflow des commandes

Avec la commande collective, le nombre d’actions enregistrées et le nombre d’historiques de pdfs commerciaux sont devenus très important au point de fabriquer des pages d’une grande longueur.
mise en place de deux ascenseurs sur ces deux modules workflow au delà d’une quinzaine de lignes d’affichage.

3748 Evolution Recherche auto complétion de commandes par client

La recherche d’un client dans le moteur à auto complétion du back office ne fonctionne pas sur la recherche de raison sociale qui ne s’affiche pas dans le déroulée.
La recherche client doit pouvoir se réaliser sur le nom d’un client de type particulier mais également sur le critère raison sociale dans le cadre d’un client Pro

3679 Evolution Uniformisation de la génération des pdf

Certains documents bénéficient d’un bundle de génération de pdf récent et d’autres, comme les pdf de commande et de facture d’un bundle plus ancien ne permettant pas la bonne intégration de certaines balises.

Généralisation sur l’ensemble des pdf du bundle plus récent.

3452 Histoire Création d’un document « Attestation de présence »
Une attestation de présence est un document permettant à un client d’attester la présence d’un participant au sein d’un séjour.
Cette attestation de présence est un pdf reprenant le template des documents commerciaux.
Le corps du document est remplacé par deux champs

  • Un champ paramétrable en configuration
  • Un champ de saisie libre
    Une attestation de présence se réalise par participant à un séjour.

Configuration<Communication<documents
Ajout d’un nouvel onglet : Attestation de présence
Cet écran comprend un champ configurable avec wysiwyg, dans lequel l’opérateur pourra saisir le texte par défaut de son attestation.
L’écran reprend en colonne de droite, tout comme dans les écrans CRM, les variables présentes dans la commande afin que l’opérateur puisse réaliser des opération de fusion.

Une fonction par case à cocher est présente en haut de l’écran « Génération automatique en date de retour ». En pratique l’attestation de présence sera générée dans la nuit suivant le retour du participant.
Cette attestation se génère uniquement si le participant est tagué comme présent dans la commande et que pour les commandes sont sous statut validé.


Ecran de commande :

Le menu action s’enrichit d’une ligne « Présence »
Ce menu action ouvre une modale comprenant un champ de saisie libre qui viendra compléter le champ de saisi pré paramétré dans configuration<documents
L’ensemble des participant d’une commande sont présents dans une liste.
Une case à cocher permet de sélectionner les participants pour lesquels on souhaite générer cette attestation de présence.
Un bouton imprimer permet de générer manuellement l’attestation.
Une fois l’attestation générée est apparait sous forme d’un picto pdf à droite de la liste.
Une fonction suppression permet de supprimer un document généré.

Fonction mail de la commande :
Cette attestation de présence fait parti des documents qu’un opérateur pourra joindre à un mail.

CRM : pas de CRM client dédiée à ce document. L’opérateur pourra cependant enrichir le CRM 89 dédié à l’envoi d’une enquête qualité à J+1 après le retour pour informer le client de l’existence de ce document dans son compte client.

Compte client et RL
Ce document est à disposition des tiers dans leur compte dès J+1 après retour.
Il est disponible dans l’onglet « Documents de voyages » colonne de droite sous le module « Autres documents de voyage »
Il prend la forme d’un lien de téléchargement « Attestation de présence de Prénom Nom »

Retour en haut