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 La date représentant la date de la prochaine résa en attente. 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. |
|||
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. Module billetterie : Ecran Stock<segment |
|||
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 : La modale présente un tableau comprenant |
|||
3740 | Evolution | Transport<billeterie – Evolution des données | |
Calcul du nombre de pax à réserver. Alimentation automatique du critère ligne. |
|||
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. |
|||
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. 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 : |
|||
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. 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. |
|||
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. |
|||
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. |
|||
3752 | Evolution | Social : Contrat annulé | |
Création d’un nouveau critère de contrat 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 L’action annuler le contrat grise la ligne de contrat et bascule le statut Annulé à Oui. Ecran social<paie Fichier csv d’export des variables de paie. Transport<accompagnateur |
|||
Module Transport 2 | |||
3739 | Evolution | Ecran Transport<stock<segments – gestion des accompagnateurs | |
La règle de calcul du surbooking évolue Ajout d’une fonction d’export des données |
|||
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 » Transport<stock<segments Périodicité de mise à jour : |
|||
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. |
|||
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 : 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. 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. |
|||
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. – 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é. |
|||
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. Evolution : 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 Mettre le logo et le nom de l’instance qui se connecte Pages sous droit Superadmin TOP MENU |
|||
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. Mettre en place une tache qui remonte tous les id de connexion des super admin Vackélys au sein de VC. 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 |
|||
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 |
|||
3773 | Histoire | Service Vackelys | |
configuration des villes avec vackelys connect |
|||
3772 | Histoire | Service VackelysConnect | |
1. formulaire villes |
|||
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.
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 » Création d’un menu « Mes distributeurs » |
|||
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. Certains champs de correspondance devront être saisi par l’opérateur dans son instance Vackélys. D’autres seront alimentées automatiquement par la connexion API 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. |
|||
3667 | Tâche | création de l’écran séjours | |
l’écran séjour reprend l’ensemble des séjours remontés ID|ID correspondance|Ref|Nom|Début|Fin|Actif|Actif front|Destination|organisateur| Un clic sur l’ID permet d’afficher le séjour. 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. |
|||
3666 | Tâche | Création d’un écran organisateur | |
VC comprend un écran Organisateur :
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 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 Elle disposera d’une table organisateur avec des droits. Une instance Vackélys dispose de séjours produits par l’organisateur Entité Maître mais également de produits d’organisateurs simple. 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 : |
|||
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
Exemple :
Exemple : Afin de pouvoir réaliser ce projet il sera nécessaire :
|
|||
VACKELYS V3 16 | |||
3860 | Evolution | Supression d’un organisateur. | |
Ajouter une fonction Action<supprimer un 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. |
|||
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. |
|||
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. |
|||
3853 | Evolution | champs suivis dans les commandes | |
le champ est borné à 250 caractères. |
|||
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. |
|||
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. |
|||
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. |
|||
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. |
|||
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
Configuration<Communication<documents 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.
Fonction mail de la commande : 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 |